Lpc2000

--- In lpc2000@yahoogroups.com, "jamesasteres" <jamesasteres@y...> 
wrote:
> 
> Mark,
> All I can say is "wow".  Is this a board level product?  I don't 
> have the luxury of time to support two microcontrollers and also 
> write my own TCP/IP stack.  How much time did it take to write the 
> stack?  Did you do it from the ground up or did you adapt someone 
> else's code?
> James
Hi James

Sorry for the delay - but for completeness a short(ish) answer:

My product is board level and is a typical embedded internet 
application. I have been working on it mainly in my free time since 
the end of 2004 (I think I started on 24.12.2004).
Step 1. Bought MC9S12NE64 DEMO board
Step 2. Installed GNU compiler for HC11/12
Step 3. Wrote a disassembler and dedugger for the HC12 (they have 
boot code allowing debugging and download over serial with break 
points, stepping etc.) - experimental project in parallel.
Step 4. Ported my Operating system to MC9S12NE64 and integrated new 
Ethernet driver.
Step 5. Wrote (parts of) TCP/IP stack in steps using OpenTCP as 
reference (result is a different solution but reference code helps a 
great deal - also comments about what is allowed to be left out by 
RFCs etc.). Debugging on hardware with own debugger but mainly using 
Visual studio for development [MC9S12NE64 does LAN<->RS232 
conversion and the project sends and receives via COM port, although 
the routines use direct LAN driver when compiled for target].
Using Ethereal I record reference sequences and 'play' these back 
through the stack in a 'simulated' environment. You learn very 
quickly the details doing this and detailed study of the flags and 
sequence numbers and so on is rarely necessary.
Step 6. SPI driver between MC9S12NE64 and LPC210x. The main goal was 
to prove that the operating system and stack are really hardware 
independent. It is possible to compile the project to configure the 
MC9S12NE64 as LAN<->SPI converter and put the stack and application 
in the LPC210x. The LPC210x opens an SPI driver instead of the LAN 
driver and can access the Internet without the code needing to know 
the details. Alternatively it is possible to configure the system to 
leave the stack in the MC9S12NE64 and the application runs on the 
the LPC210x - in this case it communicates via SPI based sockets. [I 
must admit that this needs some more work due to the necessary 
protocol at the SPI communication level..]
Step 7. Application and more TCP/IP frills.
EG: When I turn on the device it gets its IP config from the DHCP 
server and then the IP address of my POP3 Email provider via DNS - 
it checks whether I have mail and can give me some details about 
what is waiting on an LCD Display. Saves booting the PC to see 
whether there is post...
NOTE: I am using a non-preemptive operating system. This restricts 
the support possibilites with TCP (mainly) but for small embedded 
devices which need Internet connectivity these can be tolerated on 
the whole.. (at least until now).

What I haven't integrated yet is HTTP but this will probably be step 
8.

Was it worth while? I began with zero knowledge of GNU/HC12 and 
TCP/IP (quite good knowlegde of LPC210x and IAR) and have now 
learned enough to get them working together. I almost have a product 
ready which can do quite a lot on a remote basis, is quite cheap and 
flexible. There will certainly be some backlashes where I have to 
find out why things doesn't always run so smoothly in certain 
circumstances (traffic overload, error handling which has not been 
properly tested and so on) but I am prepared. So I think that it has 
been a worthwhile, if time consuming investment [BTW - the most time 
consuming development step was getting the SPI interface in the 
LPC210x to work correctly!! I actually gave up in slave mode with 
the conclusion that it essentially doesn't work correctly..].

Cheers

Mark