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 | commercial TCP/IP stacks
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
commercial TCP/IP stacks - timjenison - Oct 31 18:12:00 2005
Anyone here have any experience with the CMX or Treck TCP/IP stacks
for the HC12?
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
for the HC12?
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: commercial TCP/IP stacks - David Kelly - Nov 1 18:17:00 2005
On Oct 31, 2005, at 4:12 PM, timjenison wrote:
> Anyone here have any experience with the CMX or Treck TCP/IP stacks
> for the HC12?
Wish I had. The free-to-use OpenTCP reference design works but isn't
what I would consider of high quality.
I had to add VLAN for our application. Found the ethernet header size
was defined in 4 or 5 different places. Once as a #define in
Freescale's code. Once as a #define in Viola's code. And several more
places as "14". Its 4 bytes bigger for a VLAN. I didn't bother to
attempt supporting both VLAN and non-VLAN connections.
Would like to have IPsec but can't see OpenTCP as worth the effort.
The DHCP client reports the hardware address in wrong byte order. It
works this way anyhow because the DHCP server will continue to
reissue the IP address so long as one asks with the same MAC address.
But the info in the DHCP server logs will be wrong.
DHCP client runs in the simplest mode possible, broadcast. UDP would
not receive unicast if packet was not addressed to the broadcast IP
address or device's configured IP address (Catch-22). I punched a
hole in UDP specifically for DHCP. VLAN or not if one is on a large
network broadcast DHCP isn't acceptable.
As shipped the timer routines were either not initialized or started.
The http server seemed to work so long as there was no network error
or collision. Without timers the dhcp client spit out a storm of
packets.
There are a couple of so-called manuals generated with Doxygen
extracted from specially formatted comments in the code. No system
overview or theory of operation.
Multiple authors with differing styles made code hard to read. Ran my
copy thru GNU Indent with a good number of custom settings. The
result closely resembles original K&R style.
The so-called support forums hosted by Viola Systems at opentcp.org
apparently allow spammers to post porn but I've never been able to
view any post. Replied to the forum owner email address, same address
as was used to email my account information and email bounced,
"address unknown."
When I started this project was told the Atmel ARM7 w/ ethernet would
not be available in time. Same for the Microchip 28J60. The only
reason I'd use an NE64 again was if legacy compatibility with my
current project was necessary.
--
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: commercial TCP/IP stacks - timjenison - Nov 1 19:09:00 2005
Thanks for the info!
>
> > Anyone here have any experience with the CMX or Treck TCP/IP stacks
> > for the HC12?
>
> Wish I had. The free-to-use OpenTCP reference design works but
isn't
> what I would consider of high quality.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> > Anyone here have any experience with the CMX or Treck TCP/IP stacks
> > for the HC12?
>
> Wish I had. The free-to-use OpenTCP reference design works but
isn't
> what I would consider of high quality.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: commercial TCP/IP stacks - John-Mark Gurney - Nov 1 19:27:00 2005
David Kelly wrote this message on Tue, Nov 01, 2005 at 16:17 -0600:
> On Oct 31, 2005, at 4:12 PM, timjenison wrote:
>
> > Anyone here have any experience with the CMX or Treck TCP/IP stacks
> > for the HC12?
>
> Wish I had. The free-to-use OpenTCP reference design works but isn't
> what I would consider of high quality.
It's of crappy quality... The programmers don't even have a basic
understanding of how cpp macros work... They added fudge factors
because of stuff like:
#define SIZEA 14 + SIZEB
#define SIZEB 20
#define SIZEC 1500 - SIZEA + fudge
Really bad.... :(
> I had to add VLAN for our application. Found the ethernet header size
> was defined in 4 or 5 different places. Once as a #define in
> Freescale's code. Once as a #define in Viola's code. And several more
> places as "14". Its 4 bytes bigger for a VLAN. I didn't bother to
> attempt supporting both VLAN and non-VLAN connections.
>
> Would like to have IPsec but can't see OpenTCP as worth the effort.
>
> The DHCP client reports the hardware address in wrong byte order. It
> works this way anyhow because the DHCP server will continue to
> reissue the IP address so long as one asks with the same MAC address.
> But the info in the DHCP server logs will be wrong.
Hmmm.. never noticed this, but also I am using an odd ball dhcp server...
> DHCP client runs in the simplest mode possible, broadcast. UDP would
> not receive unicast if packet was not addressed to the broadcast IP
> address or device's configured IP address (Catch-22). I punched a
> hole in UDP specifically for DHCP. VLAN or not if one is on a large
> network broadcast DHCP isn't acceptable.
I ran into a problem where the lease time was calculated as 0.. which
caused a flurry of requests:
- dhcpc_t1=(UINT32)((UINT16)(0.5)*temp);
- dhcpc_t2=(UINT32)((UINT16)(0.875)*temp);
+ dhcpc_t1=temp / 2;
+ dhcpc_t2=((temp << 3) >> 3) * 7 / 8;
There were a couple places that did this.. :(
> As shipped the timer routines were either not initialized or started.
> The http server seemed to work so long as there was no network error
> or collision. Without timers the dhcp client spit out a storm of
> packets.
>
> There are a couple of so-called manuals generated with Doxygen
> extracted from specially formatted comments in the code. No system
> overview or theory of operation.
>
> Multiple authors with differing styles made code hard to read. Ran my
> copy thru GNU Indent with a good number of custom settings. The
> result closely resembles original K&R style.
>
> The so-called support forums hosted by Viola Systems at opentcp.org
> apparently allow spammers to post porn but I've never been able to
> view any post. Replied to the forum owner email address, same address
> as was used to email my account information and email bounced,
> "address unknown."
Yeh, and they haven't integrated my patches posted to sourceforge...
> When I started this project was told the Atmel ARM7 w/ ethernet would
> not be available in time. Same for the Microchip 28J60. The only
> reason I'd use an NE64 again was if legacy compatibility with my
> current project was necessary.
I personally like having the PHY on the chip.. I haven't any other chips
that you can do a design w/o requiring another chip like ram or
flash/eeprom or PHY...
I'll probably use it again, since I already have the code that I want/need
working... and switching to another design would be a problem, but
it would be nice it OpenTCP wasn't so anal about their name, or at least
gave up the name to let other people maintain it if they weren't...
--
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 )
> On Oct 31, 2005, at 4:12 PM, timjenison wrote:
>
> > Anyone here have any experience with the CMX or Treck TCP/IP stacks
> > for the HC12?
>
> Wish I had. The free-to-use OpenTCP reference design works but isn't
> what I would consider of high quality.
It's of crappy quality... The programmers don't even have a basic
understanding of how cpp macros work... They added fudge factors
because of stuff like:
#define SIZEA 14 + SIZEB
#define SIZEB 20
#define SIZEC 1500 - SIZEA + fudge
Really bad.... :(
> I had to add VLAN for our application. Found the ethernet header size
> was defined in 4 or 5 different places. Once as a #define in
> Freescale's code. Once as a #define in Viola's code. And several more
> places as "14". Its 4 bytes bigger for a VLAN. I didn't bother to
> attempt supporting both VLAN and non-VLAN connections.
>
> Would like to have IPsec but can't see OpenTCP as worth the effort.
>
> The DHCP client reports the hardware address in wrong byte order. It
> works this way anyhow because the DHCP server will continue to
> reissue the IP address so long as one asks with the same MAC address.
> But the info in the DHCP server logs will be wrong.
Hmmm.. never noticed this, but also I am using an odd ball dhcp server...
> DHCP client runs in the simplest mode possible, broadcast. UDP would
> not receive unicast if packet was not addressed to the broadcast IP
> address or device's configured IP address (Catch-22). I punched a
> hole in UDP specifically for DHCP. VLAN or not if one is on a large
> network broadcast DHCP isn't acceptable.
I ran into a problem where the lease time was calculated as 0.. which
caused a flurry of requests:
- dhcpc_t1=(UINT32)((UINT16)(0.5)*temp);
- dhcpc_t2=(UINT32)((UINT16)(0.875)*temp);
+ dhcpc_t1=temp / 2;
+ dhcpc_t2=((temp << 3) >> 3) * 7 / 8;
There were a couple places that did this.. :(
> As shipped the timer routines were either not initialized or started.
> The http server seemed to work so long as there was no network error
> or collision. Without timers the dhcp client spit out a storm of
> packets.
>
> There are a couple of so-called manuals generated with Doxygen
> extracted from specially formatted comments in the code. No system
> overview or theory of operation.
>
> Multiple authors with differing styles made code hard to read. Ran my
> copy thru GNU Indent with a good number of custom settings. The
> result closely resembles original K&R style.
>
> The so-called support forums hosted by Viola Systems at opentcp.org
> apparently allow spammers to post porn but I've never been able to
> view any post. Replied to the forum owner email address, same address
> as was used to email my account information and email bounced,
> "address unknown."
Yeh, and they haven't integrated my patches posted to sourceforge...
> When I started this project was told the Atmel ARM7 w/ ethernet would
> not be available in time. Same for the Microchip 28J60. The only
> reason I'd use an NE64 again was if legacy compatibility with my
> current project was necessary.
I personally like having the PHY on the chip.. I haven't any other chips
that you can do a design w/o requiring another chip like ram or
flash/eeprom or PHY...
I'll probably use it again, since I already have the code that I want/need
working... and switching to another design would be a problem, but
it would be nice it OpenTCP wasn't so anal about their name, or at least
gave up the name to let other people maintain it if they weren't...
--
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: commercial TCP/IP stacks - David Kelly - Nov 1 20:41:00 2005
On Nov 1, 2005, at 5:27 PM, John-Mark Gurney wrote:
> David Kelly wrote this message on Tue, Nov 01, 2005 at 16:17 -0600:
>
>> Wish I had. The free-to-use OpenTCP reference design works but isn't
>> what I would consider of high quality.
>
> It's of crappy quality... The programmers don't even have a basic
> understanding of how cpp macros work... They added fudge factors
> because of stuff like:
> #define SIZEA 14 + SIZEB
> #define SIZEB 20
> #define SIZEC 1500 - SIZEA + fudge
>
> Really bad.... :(
Metrowerks CW12 is happy with the "prototyping" but I'm not. IMO if
its in a header file then it shall be declared "extern".
The code looks like it has a lot of bitrot. That its clearly written
to be "portable" and probably originally came from an 8 bit system
with ISA MAC on I/O port pins where each byte has to be latched thru
one at a time. That nothing more was done to "port" than "make it work."
>> The DHCP client reports the hardware address in wrong byte order. It
>> works this way anyhow because the DHCP server will continue to
>> reissue the IP address so long as one asks with the same MAC address.
>> But the info in the DHCP server logs will be wrong.
>
> Hmmm.. never noticed this, but also I am using an odd ball dhcp
> server...
Doesn't matter, it works for most and worked for me but was wrong.
Simply compare the MAC addresses in the DHCP server log to those in
your arp table to those reported by ifconfig (or ipconfig for some).
The order is the same everywhere but in the DHCP server log for the
OpenTCP clients. With Ethereal or tcpdump can see the bytes sent in
wrong order. Different than WinXP or FreeBSD.
Searched with Google for anything like the above. Found some irate
users of a personal router/firewall in England who were having
problems with the reversed MAC and their ISP's DCHP proxies. That the
DHCP proxy used the MAC contained in the DHCP packet (vs header) to
open the bridging in the network and nothing got thru because the MAC
used on ethernet headers was different. Solution was to use the
configurable MAC option and fake one which read same left to right as
right to left. Don't know how those guys figured it out. Sounds like
OpenTCP.
> I ran into a problem where the lease time was calculated as 0.. which
> caused a flurry of requests:
> -
> dhcpc_t1=(UINT32)((UINT16)(0.5)*temp);
> -
> dhcpc_t2=(UINT32)((UINT16)(0.875)*temp);
> +
> dhcpc_t1=temp / 2;
> +
> dhcpc_t2=((temp << 3) >> 3) * 7 / 8;
>
> There were a couple places that did this.. :(
Glad to make your acquaintance. Saw your bug report on Sourceforge.
Verified same in my code. Added your patches. I'm "n4hhe", the other
one who bothered to post anything.
[...]
> Yeh, and they haven't integrated my patches posted to sourceforge...
The tar.gz image is newer than the .zip image so initially I started
with that. Don't know why the tar.gz is there because its totally
hosed. Missing files. Corrupt CW project files cause CW to complain
that a newer version of CW was used to create them so this version is
setting unknown parameters to default.
Then there is the CVS version which has CR LF line endings. Must be
checked out in binary mode else have CR LF LF (or is it CR CR LF) files.
> I personally like having the PHY on the chip.. I haven't any other
> chips
> that you can do a design w/o requiring another chip like ram or
> flash/eeprom or PHY...
The Atmel AT91SAM7X family requires outboard PHY. I don't think an
outboard PHY is a terribly bad idea. The SAM7X is said to be sampling
now, but a few months ago was told that it was still a dream.
--
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: commercial TCP/IP stacks - Jefferson Smith - Nov 2 10:40:00 2005
--- In 68HC12@68HC..., David Kelly <dkelly@h...> wrote:
>
> On Nov 1, 2005, at 5:27 PM, John-Mark Gurney wrote:
>
> > David Kelly wrote this message on Tue, Nov 01, 2005 at 16:17 -0600:
> >
> >> Wish I had. The free-to-use OpenTCP reference design works but
If you're considering writing some good stuff for NE64, have you
looked at the FreeRTOS TCP/IP software? It's new at the Freescale
16-bit MCU, but I think it's moving quickly.
http://www.freertos.org
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> On Nov 1, 2005, at 5:27 PM, John-Mark Gurney wrote:
>
> > David Kelly wrote this message on Tue, Nov 01, 2005 at 16:17 -0600:
> >
> >> Wish I had. The free-to-use OpenTCP reference design works but
If you're considering writing some good stuff for NE64, have you
looked at the FreeRTOS TCP/IP software? It's new at the Freescale
16-bit MCU, but I think it's moving quickly.
http://www.freertos.org
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: commercial TCP/IP stacks - David Kelly - Nov 2 11:23:00 2005
On Wed, Nov 02, 2005 at 02:40:40PM -0000, Jefferson Smith wrote:
>
> If you're considering writing some good stuff for NE64, have you
> looked at the FreeRTOS TCP/IP software? It's new at the Freescale
> 16-bit MCU, but I think it's moving quickly.
>
> http://www.freertos.org
Yes, uIP was high on my list but the time to port and integrate were not
on my budget (nor was OpenTCP bug fixes). As for an RTOS, have rarely
had a need for one. Some insist "Assembly language is the only way!" but
what works for me is C without an RTOS.
FreeRTOS doesn't yet list the NE64 with uIP or lwip, only SAM7X.
--
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 )
>
> If you're considering writing some good stuff for NE64, have you
> looked at the FreeRTOS TCP/IP software? It's new at the Freescale
> 16-bit MCU, but I think it's moving quickly.
>
> http://www.freertos.org
Yes, uIP was high on my list but the time to port and integrate were not
on my budget (nor was OpenTCP bug fixes). As for an RTOS, have rarely
had a need for one. Some insist "Assembly language is the only way!" but
what works for me is C without an RTOS.
FreeRTOS doesn't yet list the NE64 with uIP or lwip, only SAM7X.
--
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: commercial TCP/IP stacks - Mark Butcher - Nov 2 12:18:00 2005
Hi All
Nice to see some discussion about the NE64 and TCP/IP stacks again.
Interesting points and thoughts...
I have a lot of experience with the NE64 after writing my own TCP/IP
stack as a consequence of studying OpenTCP and deciding against it;
done a few projects and will be starting with the SAM7 in the near
future.
The NE64 is space limited but you can still do a bunch of things
with it. If you can use it it is still probably the best solution
for minimum cost and space. Otherwise the ATMEL ARM 7 is the next
step up.
I have settled for a nice mix of FTP and HTTP supporting (basic)
security, dynamic web page generation and control. I use either the
3d page or an external 32K SPI EEPROM as file system for the web
pages and logging functions. Non of this support is supplied with
OpenTCP so it is still not a lot of use, even if it does/can work.
I have a number of demos using the NE64 - go to
http://212.254.22.36:8080 to see them via webcam.
- HCS12 Internet background debugger at http://212.254.22.36/
- Internet enabled Display at http://212.254.22.36:8081
- Temperature monitor with date and time and log history at
http://212.254.22.36:8082
[User name and passwork always anon/anon. All are set up for 8 user
support]. Check out the internal web pages showing Ethernet
statistics, help etc..
It is also possible to check out ftp at http://212.254.22.36
(anonymous login) - only 1 user support - but please don't upload
anything (the file system is only very small...)
More details and links on my homepage at www.mjbc.ch.
The uTasker environment (GNU based with operating system, TCP/IP
stack, Simulator and Debugger) are offered free for educational use
and a beta release with full documentation is presently being
evaluated for the simulator and operating system - the stack being
added shortly.) the uTasker project also supports IAR Embedded
Workbench if anyone uses it [tyical project sizes 24k FLASH with IAR
or 45k with GNU...]
Check it out - I welcome all feedback and critic...
Regards
Mark Butcher
www.mjb.ch
______________________________
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 )
Nice to see some discussion about the NE64 and TCP/IP stacks again.
Interesting points and thoughts...
I have a lot of experience with the NE64 after writing my own TCP/IP
stack as a consequence of studying OpenTCP and deciding against it;
done a few projects and will be starting with the SAM7 in the near
future.
The NE64 is space limited but you can still do a bunch of things
with it. If you can use it it is still probably the best solution
for minimum cost and space. Otherwise the ATMEL ARM 7 is the next
step up.
I have settled for a nice mix of FTP and HTTP supporting (basic)
security, dynamic web page generation and control. I use either the
3d page or an external 32K SPI EEPROM as file system for the web
pages and logging functions. Non of this support is supplied with
OpenTCP so it is still not a lot of use, even if it does/can work.
I have a number of demos using the NE64 - go to
http://212.254.22.36:8080 to see them via webcam.
- HCS12 Internet background debugger at http://212.254.22.36/
- Internet enabled Display at http://212.254.22.36:8081
- Temperature monitor with date and time and log history at
http://212.254.22.36:8082
[User name and passwork always anon/anon. All are set up for 8 user
support]. Check out the internal web pages showing Ethernet
statistics, help etc..
It is also possible to check out ftp at http://212.254.22.36
(anonymous login) - only 1 user support - but please don't upload
anything (the file system is only very small...)
More details and links on my homepage at www.mjbc.ch.
The uTasker environment (GNU based with operating system, TCP/IP
stack, Simulator and Debugger) are offered free for educational use
and a beta release with full documentation is presently being
evaluated for the simulator and operating system - the stack being
added shortly.) the uTasker project also supports IAR Embedded
Workbench if anyone uses it [tyical project sizes 24k FLASH with IAR
or 45k with GNU...]
Check it out - I welcome all feedback and critic...
Regards
Mark Butcher
www.mjb.ch
______________________________
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 )