Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | NE64 DHCP and MAC address
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
NE64 DHCP and MAC address - hc08jb8 - Dec 6 1:36:00 2005
Hello Guys
1.) I am looking to use the NE64 for a simple Ethernet based I/O
system, I plan to use the OpenTCP with DHCP scheme. The following link
has an example based on OpenTCP with DHCP.
http://sourceforge.net/project/showfiles.php?group_id=119500
However its not documented as to which hardware board it uses. Anyone
has tried this?
2.) The NE64 has a PHY built in, most other chips come with a MAC
address, so as for the NE64, where does one get MAC address from? IEEE?
is there a standard procedure to obtain a MAC address, does it cost
money?
3.) If the NE64 designs were to be used intenally within an
organisation's network, i.e. no link to real world outside of the
company, could I use some mock up MAC ids? is it legal? in this case,
each board has to have a unique MAC id, how can this be done so that a
unique MAC id is burned onto every chip without having to recompile the
code over and over for each flashing? (serilisation?) Thanks for your help.
Jay
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
1.) I am looking to use the NE64 for a simple Ethernet based I/O
system, I plan to use the OpenTCP with DHCP scheme. The following link
has an example based on OpenTCP with DHCP.
http://sourceforge.net/project/showfiles.php?group_id=119500
However its not documented as to which hardware board it uses. Anyone
has tried this?
2.) The NE64 has a PHY built in, most other chips come with a MAC
address, so as for the NE64, where does one get MAC address from? IEEE?
is there a standard procedure to obtain a MAC address, does it cost
money?
3.) If the NE64 designs were to be used intenally within an
organisation's network, i.e. no link to real world outside of the
company, could I use some mock up MAC ids? is it legal? in this case,
each board has to have a unique MAC id, how can this be done so that a
unique MAC id is burned onto every chip without having to recompile the
code over and over for each flashing? (serilisation?) Thanks for your help.
Jay
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - John-Mark Gurney - Dec 6 2:17:00 2005
hc08jb8 wrote this message on Tue, Dec 06, 2005 at 05:36 -0000:
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
Make sure you apply the patches that are part of the project... The
people who programmed the code made quite a few junior programming
bugs, and even though they released a new version after some of the
patches were submitted, they still haven't applied them...
> However its not documented as to which hardware board it uses. Anyone
> has tried this?
They don't "need" to support any different hardware, since the code
is generic enough that it should work on any hardware... They even
have defines to support an external ethernet phy, though I haven't
tried to use it...
I'm using this code with both my own hardware and DEMO9S12NE64 from
Freescale...
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from? IEEE?
> is there a standard procedure to obtain a MAC address, does it cost
> money?
Yeh, you gotta get one yourself, or as other people have suggested,
use a retired card, though that could get confusing...
take a look at:
http://standards.ieee.org/faqs/OUI.html#q5
you can either get a small block of 4096 addresses, or a larger 16mil
block...
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this case,
> each board has to have a unique MAC id, how can this be done so that a
> unique MAC id is burned onto every chip without having to recompile the
> code over and over for each flashing? (serilisation?)
Yes, there is a bit that is reserved for local address assignment...
I believe it's bit 1 of the first byte... so any address that starts
w/ 0x02 is reservered for local use...
http://www.certsoft.com/mac.htm
http://en.wikipedia.org/wiki/Locally_Administered_Address
Hope this helps...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
Make sure you apply the patches that are part of the project... The
people who programmed the code made quite a few junior programming
bugs, and even though they released a new version after some of the
patches were submitted, they still haven't applied them...
> However its not documented as to which hardware board it uses. Anyone
> has tried this?
They don't "need" to support any different hardware, since the code
is generic enough that it should work on any hardware... They even
have defines to support an external ethernet phy, though I haven't
tried to use it...
I'm using this code with both my own hardware and DEMO9S12NE64 from
Freescale...
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from? IEEE?
> is there a standard procedure to obtain a MAC address, does it cost
> money?
Yeh, you gotta get one yourself, or as other people have suggested,
use a retired card, though that could get confusing...
take a look at:
http://standards.ieee.org/faqs/OUI.html#q5
you can either get a small block of 4096 addresses, or a larger 16mil
block...
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this case,
> each board has to have a unique MAC id, how can this be done so that a
> unique MAC id is burned onto every chip without having to recompile the
> code over and over for each flashing? (serilisation?)
Yes, there is a bit that is reserved for local address assignment...
I believe it's bit 1 of the first byte... so any address that starts
w/ 0x02 is reservered for local use...
http://www.certsoft.com/mac.htm
http://en.wikipedia.org/wiki/Locally_Administered_Address
Hope this helps...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - David Kelly - Dec 6 2:20:00 2005
On Dec 5, 2005, at 11:36 PM, hc08jb8 wrote:
> Hello Guys
>
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
Use NE64OpenTCPforCW31_090104g.ZIP because FSOTCP_1-0.tgz is missing
files and won't compile for other reasons. And NE64_Vend_OpenTCP.ZIP
requires the full 64k or more of program memory, therefore won't
compile with the free version of CW but might be useful for borrowing
code for server-side includes for the HTTP server, and possibly other
examples.
Is not critical for my project right now but I'd like to have 10/100
and half/full duplex auto negotiation.
NE64OpenTCPforCW31_090104g.ZIP has several bugs. See Sourceforge. In
particular the DHCP section is not enabled by default and has a
glaring timing bug. Also reports its own MAC in the body of the
packet with the wrong byte order. The wrong byte order works with
many systems anyhow but will fail if your DHCP server reconfigures
network bridges. Otherwise the MAC address is simply reported
backwards in DHCP logs and runs the risk of colliding with a "real"
MAC address.
> However its not documented as to which hardware board it uses. Anyone
> has tried this?
Uh, all it needs is power to the CPU and the interface magnetics
connected the only way they go. Works fine on the Freescale NE64 demo
kit in the clear plastic enclosure. About $75 IIRC.
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from?
> IEEE?
> is there a standard procedure to obtain a MAC address, does it cost
> money?
$1650 for a 24-bit block. Blocks of 4096 are "only" $550. http://
standards.ieee.org/regauth/oui/pilot-ind.html
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal?
Its legal but its risking being a bad network citizen.
> in this case,
> each board has to have a unique MAC id, how can this be done so that a
> unique MAC id is burned onto every chip without having to recompile
> the
> code over and over for each flashing? (serilisation?)
Yes, you will have to serialize each and every one you build. That
doesn't mean one must recompile for each unit. Either store the MAC
in code space FLASH or in an external component as the NE64 does not
have onboard EEPROM. The fancier device programmers have the ability
to generate serial sequences.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - hc08jb8 - Dec 6 6:37:00 2005
Thanks guys for the clarification.
>Make sure you apply the patches that are part of the project...
May I know where these patches can be found, I could not seem to
locate it on the SF project page.
> The fancier device programmers have the ability
> to generate serial sequences.
Would P&E Cyclone Pro be able to do this? anyways, how does this
process work, i.e. the generated serial no is inserted into the s19
automatically before every flash session?
Thanks again for your time.
Cheers
Jay
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - Nigel Johnson - Dec 6 7:58:00 2005
We went through this at a place where I worked. Yes, you can buy them from the IEEE.
The minimum price was $700 I thing for a block, of, I think 4096 addresses. However, if
you are building onesies and twosies for a project, one method is to go and buy old ISA
net cards at your local junk store, take their MAC addresses, and junk them. This way you
will have a unique address for a buck or two each.
cheers
Nigel hc08jb8 <jameelh@jame...> wrote: Hello Guys
1.) I am looking to use the NE64 for a simple Ethernet based I/O
system, I plan to use the OpenTCP with DHCP scheme. The following link
has an example based on OpenTCP with DHCP.
http://sourceforge.net/project/showfiles.php?group_id=119500
However its not documented as to which hardware board it uses. Anyone
has tried this?
2.) The NE64 has a PHY built in, most other chips come with a MAC
address, so as for the NE64, where does one get MAC address from? IEEE?
is there a standard procedure to obtain a MAC address, does it cost
money?
3.) If the NE64 designs were to be used intenally within an
organisation's network, i.e. no link to real world outside of the
company, could I use some mock up MAC ids? is it legal? in this case,
each board has to have a unique MAC id, how can this be done so that a
unique MAC id is burned onto every chip without having to recompile the
code over and over for each flashing? (serilisation?) Thanks for your help.
Jay
Yahoo! Groups Links
---------------------------------
Find your next car at Yahoo! Canada Autos
---------------------------------
Find your next car at Yahoo! Canada Autos
[Non-text portions of this message have been removed]
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
cheers
Nigel hc08jb8 <jameelh@jame...> wrote: Hello Guys
1.) I am looking to use the NE64 for a simple Ethernet based I/O
system, I plan to use the OpenTCP with DHCP scheme. The following link
has an example based on OpenTCP with DHCP.
http://sourceforge.net/project/showfiles.php?group_id=119500
However its not documented as to which hardware board it uses. Anyone
has tried this?
2.) The NE64 has a PHY built in, most other chips come with a MAC
address, so as for the NE64, where does one get MAC address from? IEEE?
is there a standard procedure to obtain a MAC address, does it cost
money?
3.) If the NE64 designs were to be used intenally within an
organisation's network, i.e. no link to real world outside of the
company, could I use some mock up MAC ids? is it legal? in this case,
each board has to have a unique MAC id, how can this be done so that a
unique MAC id is burned onto every chip without having to recompile the
code over and over for each flashing? (serilisation?) Thanks for your help.
Jay
Yahoo! Groups Links
---------------------------------
Find your next car at Yahoo! Canada Autos
---------------------------------
Find your next car at Yahoo! Canada Autos
[Non-text portions of this message have been removed]
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - hc08jb8 - Dec 6 9:15:00 2005
Hello Nigel
I would definetly need more than 1 or 2 MACs, around 90 nodes to be
specific. Buying 4096 maybe a waste, and these nodes will never be
part of the "real-world" network, they will mostly stay wihin a Class
C internal network, so I am looking up documents to see if I could
use my own MAC address scheme.
Thanks for your tip.
Cheers
Jay
--- In 68HC12@68HC..., Nigel Johnson <ve3id@y...> wrote:
>
> We went through this at a place where I worked. Yes, you can buy
them from the IEEE. The minimum price was $700 I thing for a block,
of, I think 4096 addresses. However, if you are building onesies
and twosies for a project, one method is to go and buy old ISA net
cards at your local junk store, take their MAC addresses, and junk
them. This way you will have a unique address for a buck or two
each.
>
> cheers
> Nigel > hc08jb8 <jameelh@g...> wrote: Hello Guys
>
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following
link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
>
> However its not documented as to which hardware board it uses.
Anyone
> has tried this?
>
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from?
IEEE?
> is there a standard procedure to obtain a MAC address, does it cost
> money?
>
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this
case,
> each board has to have a unique MAC id, how can this be done so
that a
> unique MAC id is burned onto every chip without having to recompile
the
> code over and over for each flashing? (serilisation?) > Thanks for your help.
> Jay >
> Yahoo! Groups Links >
>
> ---------------------------------
> Find your next car at Yahoo! Canada Autos
>
> ---------------------------------
> Find your next car at Yahoo! Canada Autos
>
> [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I would definetly need more than 1 or 2 MACs, around 90 nodes to be
specific. Buying 4096 maybe a waste, and these nodes will never be
part of the "real-world" network, they will mostly stay wihin a Class
C internal network, so I am looking up documents to see if I could
use my own MAC address scheme.
Thanks for your tip.
Cheers
Jay
--- In 68HC12@68HC..., Nigel Johnson <ve3id@y...> wrote:
>
> We went through this at a place where I worked. Yes, you can buy
them from the IEEE. The minimum price was $700 I thing for a block,
of, I think 4096 addresses. However, if you are building onesies
and twosies for a project, one method is to go and buy old ISA net
cards at your local junk store, take their MAC addresses, and junk
them. This way you will have a unique address for a buck or two
each.
>
> cheers
> Nigel > hc08jb8 <jameelh@g...> wrote: Hello Guys
>
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following
link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
>
> However its not documented as to which hardware board it uses.
Anyone
> has tried this?
>
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from?
IEEE?
> is there a standard procedure to obtain a MAC address, does it cost
> money?
>
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this
case,
> each board has to have a unique MAC id, how can this be done so
that a
> unique MAC id is burned onto every chip without having to recompile
the
> code over and over for each flashing? (serilisation?) > Thanks for your help.
> Jay >
> Yahoo! Groups Links >
>
> ---------------------------------
> Find your next car at Yahoo! Canada Autos
>
> ---------------------------------
> Find your next car at Yahoo! Canada Autos
>
> [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - BobG...@... - Dec 6 9:26:00 2005
In a message dated 12/6/05 8:19:03 A.M. Eastern Standard Time,
jameelh@jame... writes:
these nodes will never be
part of the "real-world" network, they will mostly stay wihin a Class
C internal network, so I am looking up documents to see if I could
use my own MAC address scheme.
===============================
I thought you needed to buy your Organizationally Unique Identifier (1st 3
bytes of eth address) and then you have the bottom 3 bytes for serial number
(24 million). Just use JAY for the OUI 0x4a 0x41 0x59 and start numbering at 00
00 00 [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - zeta_alpha2002 - Dec 6 10:27:00 2005
> each board has to have a unique MAC id, how can this be done so that a
> unique MAC id is burned onto every chip without having to recompile the
> code over and over for each flashing? (serilisation?)
Give it a default MAC value then you can change it via Serial after,
taht way you don't need to recompile for every MAC changes.
I implemented IP change via serial but easy enough to add MAC address
changes since it just SCI parsing. See link, log in and grab it.
http://support.technologicalarts.ca/forum/viewtopic.php?t=131
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> unique MAC id is burned onto every chip without having to recompile the
> code over and over for each flashing? (serilisation?)
Give it a default MAC value then you can change it via Serial after,
taht way you don't need to recompile for every MAC changes.
I implemented IP change via serial but easy enough to add MAC address
changes since it just SCI parsing. See link, log in and grab it.
http://support.technologicalarts.ca/forum/viewtopic.php?t=131
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - David Kelly - Dec 6 11:06:00 2005
On Tue, Dec 06, 2005 at 08:26:08AM -0500, BobGardner@BobG... wrote:
>
> ===============================
> I thought you needed to buy your Organizationally Unique Identifier
> (1st 3 bytes of eth address) and then you have the bottom 3 bytes for
> serial number (24 million).
2^(3x8) = 16M.
> Just use JAY for the OUI 0x4a 0x41 0x59 and start numbering at
> 00 00 00
The only "legal" issue is whether or not you collide with a device
wearing a legit MAC address traceable to IEEE. Then that user has
justification to slap you around.
As already suggested many hobbiests transfer MAC addresses from junk.
Another way is to surf the OUI database at the link I provided
previously looking for defunct organizations and use their OUI for your
internal project. Certainly want to avoid Cisco, Apple, IBM, 3-Com, etc,
OUI blocks.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> ===============================
> I thought you needed to buy your Organizationally Unique Identifier
> (1st 3 bytes of eth address) and then you have the bottom 3 bytes for
> serial number (24 million).
2^(3x8) = 16M.
> Just use JAY for the OUI 0x4a 0x41 0x59 and start numbering at
> 00 00 00
The only "legal" issue is whether or not you collide with a device
wearing a legit MAC address traceable to IEEE. Then that user has
justification to slap you around.
As already suggested many hobbiests transfer MAC addresses from junk.
Another way is to surf the OUI database at the link I provided
previously looking for defunct organizations and use their OUI for your
internal project. Certainly want to avoid Cisco, Apple, IBM, 3-Com, etc,
OUI blocks.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - BobG...@... - Dec 6 11:14:00 2005
In a message dated 12/6/05 10:10:03 A.M. Eastern Standard Time,
dkelly@dkel... writes:
> I thought you needed to buy your Organizationally Unique Identifier
> (1st 3 bytes of eth address) and then you have the bottom 3 bytes for
> serial number (24 million).
2^(3x8) = 16M.
=========================
Oops! Ya got me! My only defense is that the number of bits is correct.... 24
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - David Kelly - Dec 6 11:25:00 2005
On Tue, Dec 06, 2005 at 10:37:33AM -0000, hc08jb8 wrote:
>
> Thanks guys for the clarification.
>
> >Make sure you apply the patches that are part of the project...
>
> May I know where these patches can be found, I could not seem to
> locate it on the SF project page.
Not automaticly-applyable patches but notes in the Bugs section as to
what one needs to correct.
IMO the code is suffering from neglect and bitrot. Ran my copy thru GNU
Indent with some aggressive settings in order to unify the various
coding styles used.
Added VLAN to my project and found the ethernet header length was
defined in the Freescale section with one #define, in the Viola secion
with a different #define, and simply as 14 in a couple places in the
code. Bitrot.
I couldn't build the version in CVS. Haven't tried in a long time but
believe it is the same as the .tar.gz file. The CVS repository wrongly
has CRLF line endings in the files yet has them tagged as text. Force
your CVS client to recieve as binary else make a mess.
> > The fancier device programmers have the ability
> > to generate serial sequences.
>
> Would P&E Cyclone Pro be able to do this? anyways, how does this
> process work, i.e. the generated serial no is inserted into the s19
> automatically before every flash session?
I believe the Cyclone Pro is one of the units capable of serialization.
I don't have one, yet. The idea is the code image is edited inside the
programmer per specific instructions each time the "Program" button is
pressed. Is intended to be operated by $7/hr ex-burger flippers.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> Thanks guys for the clarification.
>
> >Make sure you apply the patches that are part of the project...
>
> May I know where these patches can be found, I could not seem to
> locate it on the SF project page.
Not automaticly-applyable patches but notes in the Bugs section as to
what one needs to correct.
IMO the code is suffering from neglect and bitrot. Ran my copy thru GNU
Indent with some aggressive settings in order to unify the various
coding styles used.
Added VLAN to my project and found the ethernet header length was
defined in the Freescale section with one #define, in the Viola secion
with a different #define, and simply as 14 in a couple places in the
code. Bitrot.
I couldn't build the version in CVS. Haven't tried in a long time but
believe it is the same as the .tar.gz file. The CVS repository wrongly
has CRLF line endings in the files yet has them tagged as text. Force
your CVS client to recieve as binary else make a mess.
> > The fancier device programmers have the ability
> > to generate serial sequences.
>
> Would P&E Cyclone Pro be able to do this? anyways, how does this
> process work, i.e. the generated serial no is inserted into the s19
> automatically before every flash session?
I believe the Cyclone Pro is one of the units capable of serialization.
I don't have one, yet. The idea is the code image is edited inside the
programmer per specific instructions each time the "Program" button is
pressed. Is intended to be operated by $7/hr ex-burger flippers.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - hc08jb8 - Dec 6 12:17:00 2005
Thank you all for the information. Now I am going to build a simple
circuit to get myself familiar with the NE64 :-)
1.) Does anyone have Eagle library/footprint for either of the NE64
package? if not I'll create one and upload to the file section later.
2.) Which would be a cost effective option for the
connector+transformer, RJ45 with integrated magnetics or RJ45 and
magnetics separate? Is there a popular part no for this which I could
easily obtain from say DigiKey,Farnell et.al?
Thanks :-)
Jay --- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
>
> On Tue, Dec 06, 2005 at 10:37:33AM -0000, hc08jb8 wrote:
> >
> > Thanks guys for the clarification.
> >
> > >Make sure you apply the patches that are part of the project...
> >
> > May I know where these patches can be found, I could not seem to
> > locate it on the SF project page.
>
> Not automaticly-applyable patches but notes in the Bugs section as
to
> what one needs to correct.
>
> IMO the code is suffering from neglect and bitrot. Ran my copy thru
GNU
> Indent with some aggressive settings in order to unify the various
> coding styles used.
>
> Added VLAN to my project and found the ethernet header length was
> defined in the Freescale section with one #define, in the Viola
secion
> with a different #define, and simply as 14 in a couple places in the
> code. Bitrot.
>
> I couldn't build the version in CVS. Haven't tried in a long time
but
> believe it is the same as the .tar.gz file. The CVS repository
wrongly
> has CRLF line endings in the files yet has them tagged as text.
Force
> your CVS client to recieve as binary else make a mess.
>
> > > The fancier device programmers have the ability
> > > to generate serial sequences.
> >
> > Would P&E Cyclone Pro be able to do this? anyways, how does this
> > process work, i.e. the generated serial no is inserted into the
s19
> > automatically before every flash session?
>
> I believe the Cyclone Pro is one of the units capable of
serialization.
> I don't have one, yet. The idea is the code image is edited inside
the
> programmer per specific instructions each time the "Program" button
is
> pressed. Is intended to be operated by $7/hr ex-burger flippers.
>
> --
> David Kelly N4HHE, dkelly@H...
>
======================================================================
==
> Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - John-Mark Gurney - Dec 6 14:07:00 2005
hc08jb8 wrote this message on Tue, Dec 06, 2005 at 16:17 -0000:
>
> Thank you all for the information. Now I am going to build a simple
> circuit to get myself familiar with the NE64 :-)
>
> 1.) Does anyone have Eagle library/footprint for either of the NE64
> package? if not I'll create one and upload to the file section later.
I have one, but it's for the VTU version, 80 pin...
> 2.) Which would be a cost effective option for the
> connector+transformer, RJ45 with integrated magnetics or RJ45 and
> magnetics separate? Is there a popular part no for this which I could
> easily obtain from say DigiKey,Farnell et.al?
Yep, I use the Pulse J00-0065, there is a cheaper one for small
quantities, but had the tab going the wrong way... this one turns
out to be cheaper in quantities than the other one I was looking at...
If you need the RJ45 jack on the opposite side of the board, look at
the J01 series...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> Thank you all for the information. Now I am going to build a simple
> circuit to get myself familiar with the NE64 :-)
>
> 1.) Does anyone have Eagle library/footprint for either of the NE64
> package? if not I'll create one and upload to the file section later.
I have one, but it's for the VTU version, 80 pin...
> 2.) Which would be a cost effective option for the
> connector+transformer, RJ45 with integrated magnetics or RJ45 and
> magnetics separate? Is there a popular part no for this which I could
> easily obtain from say DigiKey,Farnell et.al?
Yep, I use the Pulse J00-0065, there is a cheaper one for small
quantities, but had the tab going the wrong way... this one turns
out to be cheaper in quantities than the other one I was looking at...
If you need the RJ45 jack on the opposite side of the board, look at
the J01 series...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - Mark Butcher - Dec 7 20:53:00 2005
Hi Jay
I have used the NE64 for some time now - see the photos section for
an example hardware.
I looked into OpenTCP but decided against it since it doesn't
support IPV6 (without a total re-write) and doesn't include useful
services such as FTP,dynamic HTTP, TELNET etc. (it doesn't integrate
into an operating system and is quite in-efficient) Wrote my own
TCP/IP stack and have been using it successfully for about 6 months
now.
You can log into a number of devices at http://212.254.22.36/
http://212.254.22.36/ is an Internet background debugger (All user
and passwords are (anon / anon)
http://212.254.22.36/8080 is a webcam where you can see the things
being controlled
http://212.254.22.36/8081 allows control of the LCD in the
demo.http://212.254.22.36/8082 is the temperatur sensor in the demo
with termperature logging (log file can be viewed)
http://212.254.22.36/8088 is a simple web server with Email support -
you can send it Emails and see the being received.
Links to the demos and more details are at my web site www.mjbc.ch.
For first steps behind a fire wall any old MAC address will do (as
long as it is not the same as another internal one) since it is only
visible internally. I recommend the DEMONE64 from Freescale - very
cheap and works great for initial work and even most Internet device
development - also cheap (much cheaper that building anything
yourself at the beginning) Being in a cute enclosure it can even be
used for prototypes to be delivered..
If you are buying a block of MAC addresses but need only say 100 of
them we could maybe do a deal (if it allowed) where I buy the unused
ones from you for our stuff.
There is another interesting little project with an NE64 at
http://www.celestialaudio.com/MC9S12NE64/ I talked to the guy when I
started my developments and he has some good tips there. I think he
was one of teh very first to use the chip since the demo board was
not even available when he started...
I store MAC addresses in the internal FLASH. The software uses a
default MAC / IP etc. when nothing is previously programmed. Then I
load some web pages by FTP which allow all configuration via a web
server (much more comfortable than serial etc.). Via the web page I
save and reset and the new values are valid (for field changes there
is a security mechanism which requires the user to contact the web
server again with a period of 2 minutes otherwise the previous
settings are returned again - this avoids a device becoming
unreachable if something was changed incorrectly). For classic setup
it is also possible via TELNET. You can telnet a device using telnet
212.254.22.36 and change its MAC, IP and a lot of other things. This
is a project which I am presently working on, which I leave on line
for testing (it is in a demiliterized zone and so records a lot of
activity - request stats using "show_ip_stat" Compare this with the
inbuild statistics page in the other test devices to see how much
better a couple of simple dynamic web pages make the device....). An
interesting test with the Telnet demo is to enter "ping
192.168.0.41". This makes the device send an internal ping test to
192.168.0.41 (+ the address one lower = 192.168.0.40). There sould
be 2 ping responses since there are in fact two computers internally
with these IP addresses which will answer. (it tests parallel ARP
resolve for instance and it allows pinging of internal devices -
behind the fire wall - to check on their connection if needed...)
Use "quit" to terminate the TELNET session, although it will timeout
after 10 minutes (which can be set via a command to be between 1s
and 17 hours).
By the way, a typical demo project with FTP, WEB and application
requires about 24k of FLASH (using IAR compiler or 40k with GNU
compiler). Although the NE64 is small, you can pack quite a lot of
useful things in it...
Hope this gives you some ideas - cheers
Mark Butcher
www.mjbc.ch
--- In 68HC12@68HC..., "hc08jb8" <jameelh@g...> wrote:
>
> Hello Guys
>
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following
link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
>
> However its not documented as to which hardware board it uses.
Anyone
> has tried this?
>
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from?
IEEE?
> is there a standard procedure to obtain a MAC address, does it
cost
> money?
>
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this
case,
> each board has to have a unique MAC id, how can this be done so
that a
> unique MAC id is burned onto every chip without having to
recompile the
> code over and over for each flashing? (serilisation?) > Thanks for your help.
> Jay
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I have used the NE64 for some time now - see the photos section for
an example hardware.
I looked into OpenTCP but decided against it since it doesn't
support IPV6 (without a total re-write) and doesn't include useful
services such as FTP,dynamic HTTP, TELNET etc. (it doesn't integrate
into an operating system and is quite in-efficient) Wrote my own
TCP/IP stack and have been using it successfully for about 6 months
now.
You can log into a number of devices at http://212.254.22.36/
http://212.254.22.36/ is an Internet background debugger (All user
and passwords are (anon / anon)
http://212.254.22.36/8080 is a webcam where you can see the things
being controlled
http://212.254.22.36/8081 allows control of the LCD in the
demo.http://212.254.22.36/8082 is the temperatur sensor in the demo
with termperature logging (log file can be viewed)
http://212.254.22.36/8088 is a simple web server with Email support -
you can send it Emails and see the being received.
Links to the demos and more details are at my web site www.mjbc.ch.
For first steps behind a fire wall any old MAC address will do (as
long as it is not the same as another internal one) since it is only
visible internally. I recommend the DEMONE64 from Freescale - very
cheap and works great for initial work and even most Internet device
development - also cheap (much cheaper that building anything
yourself at the beginning) Being in a cute enclosure it can even be
used for prototypes to be delivered..
If you are buying a block of MAC addresses but need only say 100 of
them we could maybe do a deal (if it allowed) where I buy the unused
ones from you for our stuff.
There is another interesting little project with an NE64 at
http://www.celestialaudio.com/MC9S12NE64/ I talked to the guy when I
started my developments and he has some good tips there. I think he
was one of teh very first to use the chip since the demo board was
not even available when he started...
I store MAC addresses in the internal FLASH. The software uses a
default MAC / IP etc. when nothing is previously programmed. Then I
load some web pages by FTP which allow all configuration via a web
server (much more comfortable than serial etc.). Via the web page I
save and reset and the new values are valid (for field changes there
is a security mechanism which requires the user to contact the web
server again with a period of 2 minutes otherwise the previous
settings are returned again - this avoids a device becoming
unreachable if something was changed incorrectly). For classic setup
it is also possible via TELNET. You can telnet a device using telnet
212.254.22.36 and change its MAC, IP and a lot of other things. This
is a project which I am presently working on, which I leave on line
for testing (it is in a demiliterized zone and so records a lot of
activity - request stats using "show_ip_stat" Compare this with the
inbuild statistics page in the other test devices to see how much
better a couple of simple dynamic web pages make the device....). An
interesting test with the Telnet demo is to enter "ping
192.168.0.41". This makes the device send an internal ping test to
192.168.0.41 (+ the address one lower = 192.168.0.40). There sould
be 2 ping responses since there are in fact two computers internally
with these IP addresses which will answer. (it tests parallel ARP
resolve for instance and it allows pinging of internal devices -
behind the fire wall - to check on their connection if needed...)
Use "quit" to terminate the TELNET session, although it will timeout
after 10 minutes (which can be set via a command to be between 1s
and 17 hours).
By the way, a typical demo project with FTP, WEB and application
requires about 24k of FLASH (using IAR compiler or 40k with GNU
compiler). Although the NE64 is small, you can pack quite a lot of
useful things in it...
Hope this gives you some ideas - cheers
Mark Butcher
www.mjbc.ch
--- In 68HC12@68HC..., "hc08jb8" <jameelh@g...> wrote:
>
> Hello Guys
>
> 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> system, I plan to use the OpenTCP with DHCP scheme. The following
link
> has an example based on OpenTCP with DHCP.
> http://sourceforge.net/project/showfiles.php?group_id=119500
>
> However its not documented as to which hardware board it uses.
Anyone
> has tried this?
>
> 2.) The NE64 has a PHY built in, most other chips come with a MAC
> address, so as for the NE64, where does one get MAC address from?
IEEE?
> is there a standard procedure to obtain a MAC address, does it
cost
> money?
>
> 3.) If the NE64 designs were to be used intenally within an
> organisation's network, i.e. no link to real world outside of the
> company, could I use some mock up MAC ids? is it legal? in this
case,
> each board has to have a unique MAC id, how can this be done so
that a
> unique MAC id is burned onto every chip without having to
recompile the
> code over and over for each flashing? (serilisation?) > Thanks for your help.
> Jay
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - griglack - Dec 8 10:46:00 2005
--- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
> On Dec 5, 2005, at 11:36 PM, hc08jb8 wrote:
>
> > Hello Guys
> >
> > 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> > system, I plan to use the OpenTCP with DHCP scheme. The following link
> > has an example based on OpenTCP with DHCP.
> > http://sourceforge.net/project/showfiles.php?group_id=119500
>
> Use NE64OpenTCPforCW31_090104g.ZIP because FSOTCP_1-0.tgz is missing
> files and won't compile for other reasons. And NE64_Vend_OpenTCP.ZIP
> requires the full 64k or more of program memory, therefore won't
> compile with the free version of CW but might be useful for borrowing
> code for server-side includes for the HTTP server, and possibly other
> examples.
>
> Is not critical for my project right now but I'd like to have 10/100
> and half/full duplex auto negotiation.
>
> NE64OpenTCPforCW31_090104g.ZIP has several bugs. See Sourceforge. In
> particular the DHCP section is not enabled by default and has a
> glaring timing bug. Also reports its own MAC in the body of the
> packet with the wrong byte order. The wrong byte order works with
> many systems anyhow but will fail if your DHCP server reconfigures
> network bridges. Otherwise the MAC address is simply reported
> backwards in DHCP logs and runs the risk of colliding with a "real"
> MAC address.
I have run across these and other bugs and have fixed them in my code.
Now we have run into additional problems where it will not connect
on certain networks (haven't figured out just why, yet) but other
devices do. There is also a problem with talking to some DHCP servers
and working with some boundry routing protocols. The code is clunky,
support is non-existant, testing was probably cursory, and the
documentation is minimal, but you get what you pay for.
Is there a commercial OTS stack that is more robust, has some support
behind it, but won't cost an arm and a leg? At some point, you just
have to cut your losses when you find yourself spending too much time
supporting networking issues with an old product, and not enough time
working on the new product (new one based on MC9S12DG256).
> > However its not documented as to which hardware board it uses. Anyone
> > has tried this?
>
> Uh, all it needs is power to the CPU and the interface magnetics
> connected the only way they go. Works fine on the Freescale NE64 demo
> kit in the clear plastic enclosure. About $75 IIRC.
Yes, it works fine as far as that demo goes. That demo is minimal at
best and only sets the device up as a passive server. If you want to
set your device up to collect information and send it out, you will
have to give ARP an initial "kick in the head" to get it started and
build a local ARP table.
Auto negotiation works to a point, but works better with some routers
than others.
>
> > 2.) The NE64 has a PHY built in, most other chips come with a MAC
> > address, so as for the NE64, where does one get MAC address from?
> > IEEE?
> > is there a standard procedure to obtain a MAC address, does it cost
> > money?
>
> $1650 for a 24-bit block. Blocks of 4096 are "only" $550. http://
> standards.ieee.org/regauth/oui/pilot-ind.html
If you are building a commercial product, this is the only way to go.
If you are just fooling around, or until you need to ship the
product, you can get away with a faked MAC.
The IEEE frowns on companies or individuals sharing or selling part of
a block of numbers. In fact, the agreement when you buy a block says
that you cannot do this.
> > 3.) If the NE64 designs were to be used intenally within an
> > organisation's network, i.e. no link to real world outside of the
> > company, could I use some mock up MAC ids? is it legal?
>
> Its legal but its risking being a bad network citizen.
>
> > in this case,
> > each board has to have a unique MAC id, how can this be done so that a
> > unique MAC id is burned onto every chip without having to recompile
> > the
> > code over and over for each flashing? (serilisation?)
>
> Yes, you will have to serialize each and every one you build. That
> doesn't mean one must recompile for each unit. Either store the MAC
> in code space FLASH or in an external component as the NE64 does not
> have onboard EEPROM. The fancier device programmers have the ability
> to generate serial sequences.
You can do this with the Cyclone Pro in interactive mode. You should
be able to do it with the Multilink as well, since that's always
interactive, but I don't know how. Check out http://www.pemicro.com
for more information.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> > Hello Guys
> >
> > 1.) I am looking to use the NE64 for a simple Ethernet based I/O
> > system, I plan to use the OpenTCP with DHCP scheme. The following link
> > has an example based on OpenTCP with DHCP.
> > http://sourceforge.net/project/showfiles.php?group_id=119500
>
> Use NE64OpenTCPforCW31_090104g.ZIP because FSOTCP_1-0.tgz is missing
> files and won't compile for other reasons. And NE64_Vend_OpenTCP.ZIP
> requires the full 64k or more of program memory, therefore won't
> compile with the free version of CW but might be useful for borrowing
> code for server-side includes for the HTTP server, and possibly other
> examples.
>
> Is not critical for my project right now but I'd like to have 10/100
> and half/full duplex auto negotiation.
>
> NE64OpenTCPforCW31_090104g.ZIP has several bugs. See Sourceforge. In
> particular the DHCP section is not enabled by default and has a
> glaring timing bug. Also reports its own MAC in the body of the
> packet with the wrong byte order. The wrong byte order works with
> many systems anyhow but will fail if your DHCP server reconfigures
> network bridges. Otherwise the MAC address is simply reported
> backwards in DHCP logs and runs the risk of colliding with a "real"
> MAC address.
I have run across these and other bugs and have fixed them in my code.
Now we have run into additional problems where it will not connect
on certain networks (haven't figured out just why, yet) but other
devices do. There is also a problem with talking to some DHCP servers
and working with some boundry routing protocols. The code is clunky,
support is non-existant, testing was probably cursory, and the
documentation is minimal, but you get what you pay for.
Is there a commercial OTS stack that is more robust, has some support
behind it, but won't cost an arm and a leg? At some point, you just
have to cut your losses when you find yourself spending too much time
supporting networking issues with an old product, and not enough time
working on the new product (new one based on MC9S12DG256).
> > However its not documented as to which hardware board it uses. Anyone
> > has tried this?
>
> Uh, all it needs is power to the CPU and the interface magnetics
> connected the only way they go. Works fine on the Freescale NE64 demo
> kit in the clear plastic enclosure. About $75 IIRC.
Yes, it works fine as far as that demo goes. That demo is minimal at
best and only sets the device up as a passive server. If you want to
set your device up to collect information and send it out, you will
have to give ARP an initial "kick in the head" to get it started and
build a local ARP table.
Auto negotiation works to a point, but works better with some routers
than others.
>
> > 2.) The NE64 has a PHY built in, most other chips come with a MAC
> > address, so as for the NE64, where does one get MAC address from?
> > IEEE?
> > is there a standard procedure to obtain a MAC address, does it cost
> > money?
>
> $1650 for a 24-bit block. Blocks of 4096 are "only" $550. http://
> standards.ieee.org/regauth/oui/pilot-ind.html
If you are building a commercial product, this is the only way to go.
If you are just fooling around, or until you need to ship the
product, you can get away with a faked MAC.
The IEEE frowns on companies or individuals sharing or selling part of
a block of numbers. In fact, the agreement when you buy a block says
that you cannot do this.
> > 3.) If the NE64 designs were to be used intenally within an
> > organisation's network, i.e. no link to real world outside of the
> > company, could I use some mock up MAC ids? is it legal?
>
> Its legal but its risking being a bad network citizen.
>
> > in this case,
> > each board has to have a unique MAC id, how can this be done so that a
> > unique MAC id is burned onto every chip without having to recompile
> > the
> > code over and over for each flashing? (serilisation?)
>
> Yes, you will have to serialize each and every one you build. That
> doesn't mean one must recompile for each unit. Either store the MAC
> in code space FLASH or in an external component as the NE64 does not
> have onboard EEPROM. The fancier device programmers have the ability
> to generate serial sequences.
You can do this with the Cyclone Pro in interactive mode. You should
be able to do it with the Multilink as well, since that's always
interactive, but I don't know how. Check out http://www.pemicro.com
for more information.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - David Kelly - Dec 8 13:55:00 2005
On Thu, Dec 08, 2005 at 02:46:56PM -0000, griglack wrote:
> > NE64OpenTCPforCW31_090104g.ZIP has several bugs. See Sourceforge. In
> > particular the DHCP section is not enabled by default and has a
> > glaring timing bug. Also reports its own MAC in the body of the
> > packet with the wrong byte order. The wrong byte order works with
> > many systems anyhow but will fail if your DHCP server reconfigures
> > network bridges. Otherwise the MAC address is simply reported
> > backwards in DHCP logs and runs the risk of colliding with a "real"
> > MAC address.
>
> I have run across these and other bugs and have fixed them in my code.
> Now we have run into additional problems where it will not connect
> on certain networks (haven't figured out just why, yet) but other
> devices do.
OpenTCP DHCP runs in broadcast mode. IIRC the hack to operate unicast
was to enable the unicast request bit in the initial request, and to
modify the UDP code so that port 68 incoming bypasses the IP address
match test.
> The code is clunky, support is non-existant, testing was probably
> cursory, and the documentation is minimal, but you get what you pay
> for.
Agreed. Its not a class act.
> Is there a commercial OTS stack that is more robust, has some support
> behind it, but won't cost an arm and a leg?
CMX and Treck. Depends on your definition of an arm and a leg but they
are likely over your (and my) limits.
> At some point, you just have to cut your losses when you find yourself
> spending too much time supporting networking issues with an old
> product, and not enough time working on the new product (new one based
> on MC9S12DG256).
I think the best alternative would be to study uIP and lwIP. Not exactly
clear what the difference is between the two. But something like that
and the Freescale ethernet driver code should result in a free high
quality solution.
The NE64 appears to be a dead end anyway.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> > NE64OpenTCPforCW31_090104g.ZIP has several bugs. See Sourceforge. In
> > particular the DHCP section is not enabled by default and has a
> > glaring timing bug. Also reports its own MAC in the body of the
> > packet with the wrong byte order. The wrong byte order works with
> > many systems anyhow but will fail if your DHCP server reconfigures
> > network bridges. Otherwise the MAC address is simply reported
> > backwards in DHCP logs and runs the risk of colliding with a "real"
> > MAC address.
>
> I have run across these and other bugs and have fixed them in my code.
> Now we have run into additional problems where it will not connect
> on certain networks (haven't figured out just why, yet) but other
> devices do.
OpenTCP DHCP runs in broadcast mode. IIRC the hack to operate unicast
was to enable the unicast request bit in the initial request, and to
modify the UDP code so that port 68 incoming bypasses the IP address
match test.
> The code is clunky, support is non-existant, testing was probably
> cursory, and the documentation is minimal, but you get what you pay
> for.
Agreed. Its not a class act.
> Is there a commercial OTS stack that is more robust, has some support
> behind it, but won't cost an arm and a leg?
CMX and Treck. Depends on your definition of an arm and a leg but they
are likely over your (and my) limits.
> At some point, you just have to cut your losses when you find yourself
> spending too much time supporting networking issues with an old
> product, and not enough time working on the new product (new one based
> on MC9S12DG256).
I think the best alternative would be to study uIP and lwIP. Not exactly
clear what the difference is between the two. But something like that
and the Freescale ethernet driver code should result in a free high
quality solution.
The NE64 appears to be a dead end anyway.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: NE64 DHCP and MAC address - griglack - Dec 8 18:09:00 2005
--- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
>
> On Thu, Dec 08, 2005 at 02:46:56PM -0000, griglack wrote:
> > Is there a commercial OTS stack that is more robust, has some support
> > behind it, but won't cost an arm and a leg?
>
> CMX and Treck. Depends on your definition of an arm and a leg but they
> are likely over your (and my) limits.
I talked to both of them today. Treck says that they have it working
on the NE64, but that there would be no memory for anything else. CMX
sounds like a nice solution, both memory and footprint-wise, but they
want between $7500 and $8000 to do what we want. My boss will not go
for that (I asked, he told).
> > At some point, you just have to cut your losses when you find yourself
> > spending too much time supporting networking issues with an old
> > product, and not enough time working on the new product (new one based
> > on MC9S12DG256).
>
> I think the best alternative would be to study uIP and lwIP. Not exactly
> clear what the difference is between the two. But something like that
> and the Freescale ethernet driver code should result in a free high
> quality solution.
You think that either of these are better than the OpenTCP stack?
> The NE64 appears to be a dead end anyway.
Now that's an interesting comment. Why do you say that? Is it the
severly limited RAM, or do you know something about support at
Freescale? The sales guy from Treck said that he thought the NE64 was
dead, but then (in an email) recanted and said that there was some new
chip called "Kirin" that was a better solution from Freescale.
Our board is based on the NE64. It will stay on the NE64 until it
gets scrapped. I doubt we can afford to respin the board and with a
new processor at this stage.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> On Thu, Dec 08, 2005 at 02:46:56PM -0000, griglack wrote:
> > Is there a commercial OTS stack that is more robust, has some support
> > behind it, but won't cost an arm and a leg?
>
> CMX and Treck. Depends on your definition of an arm and a leg but they
> are likely over your (and my) limits.
I talked to both of them today. Treck says that they have it working
on the NE64, but that there would be no memory for anything else. CMX
sounds like a nice solution, both memory and footprint-wise, but they
want between $7500 and $8000 to do what we want. My boss will not go
for that (I asked, he told).
> > At some point, you just have to cut your losses when you find yourself
> > spending too much time supporting networking issues with an old
> > product, and not enough time working on the new product (new one based
> > on MC9S12DG256).
>
> I think the best alternative would be to study uIP and lwIP. Not exactly
> clear what the difference is between the two. But something like that
> and the Freescale ethernet driver code should result in a free high
> quality solution.
You think that either of these are better than the OpenTCP stack?
> The NE64 appears to be a dead end anyway.
Now that's an interesting comment. Why do you say that? Is it the
severly limited RAM, or do you know something about support at
Freescale? The sales guy from Treck said that he thought the NE64 was
dead, but then (in an email) recanted and said that there was some new
chip called "Kirin" that was a better solution from Freescale.
Our board is based on the NE64. It will stay on the NE64 until it
gets scrapped. I doubt we can afford to respin the board and with a
new processor at this stage.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: NE64 DHCP and MAC address - David Kelly - Dec 8 19:38:00 2005
On Thu, Dec 08, 2005 at 10:09:26PM -0000, griglack wrote:
> --- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
> >
> > I think the best alternative would be to study uIP and lwIP. Not
> > exactly clear what the difference is between the two. But something
> > like that and the Freescale ethernet driver code should result in a
> > free high quality solution.
>
> You think that either of these are better than the OpenTCP stack?
lwIP is based on uIP. Any active user community is better than the
non-active OpenTCP user community.
The issue is how far into the future are you looking? uIP is going to
require some work to be grafted onto an NE64. I think a year from now
things will be very interesting once the Microchip ENC28J60 has some
maturity. If it were not just a promise when making my selection would
probably have used AVR and ENC28J60 rather than NE64. If I had to make
the descision today the AT91SAM7X128 would be a top choice:
http://www.edn.com/article/CA6255477.html
> > The NE64 appears to be a dead end anyway.
>
> Now that's an interesting comment. Why do you say that?
A dead end is not a closed road but one which doesn't connect to any
other road. The NE64 is first and last HC12 with ethernet.
> The sales guy from Treck said that he thought the NE64 was dead, but
> then (in an email) recanted and said that there was some new chip
> called "Kirin" that was a better solution from Freescale.
Kirin is why the NE64 is a dead end. Kirin is low cost Coldfire with
integrated RAM and FLASH. IIRC Kirin-II added onboard ethernet, which
other Coldfires already have but without both RAM and FLASH.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> --- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
> >
> > I think the best alternative would be to study uIP and lwIP. Not
> > exactly clear what the difference is between the two. But something
> > like that and the Freescale ethernet driver code should result in a
> > free high quality solution.
>
> You think that either of these are better than the OpenTCP stack?
lwIP is based on uIP. Any active user community is better than the
non-active OpenTCP user community.
The issue is how far into the future are you looking? uIP is going to
require some work to be grafted onto an NE64. I think a year from now
things will be very interesting once the Microchip ENC28J60 has some
maturity. If it were not just a promise when making my selection would
probably have used AVR and ENC28J60 rather than NE64. If I had to make
the descision today the AT91SAM7X128 would be a top choice:
http://www.edn.com/article/CA6255477.html
> > The NE64 appears to be a dead end anyway.
>
> Now that's an interesting comment. Why do you say that?
A dead end is not a closed road but one which doesn't connect to any
other road. The NE64 is first and last HC12 with ethernet.
> The sales guy from Treck said that he thought the NE64 was dead, but
> then (in an email) recanted and said that there was some new chip
> called "Kirin" that was a better solution from Freescale.
Kirin is why the NE64 is a dead end. Kirin is low cost Coldfire with
integrated RAM and FLASH. IIRC Kirin-II added onboard ethernet, which
other Coldfires already have but without both RAM and FLASH.
--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )