porting Microchip Tcpip stack

[dannyf]

Just curious if anyone has attempted to port the microchip stack to a different vendors chip.

the microchip stack is quite interesting, with very small ram usage. Plus, the enc28 adapters are everywhere.

I'm tempted.

[andersm]

It would be against the license terms, so probably not.

[dannyf]

It doesn't seem to be that difficult - I am trying to see if I can get it to run on STM32F103RB.

The Microchip guys did a very good job in writing the codebase - very modular and user configurable.

The only complaint I have so far is the organization of the code.

[dannyf]

I am left with some pin definitions to be changed, implement a timer isr, and spi status registers.

[SirNick]

What's the memory footprint like?  (Not flash, but RAM.)  I started writing a stack just for grins, and it didn't take long to realize that a reasonably well-rounded implementation is going to take a substantial chunk out of any typical microcontroller.  Something as simple as a transmit queue or waiting for TCP ACK could easily eat tens to hundreds of KB depending on packet size, fragmentation, TCP window size, etc...

[nctnico]

uIP is my goto TCP-IP stack if size matters but it does have issues. The biggest problem with uIP is that the creator thought that obfustigated code compiles to a small binary 

[Bored@Work]

And what exactly is your motivatin to violate Microchip's license:

(b) Software License Grant. Subject to the terms of this Agreement, Microchip grants strictly to Licensee a personal, worldwide,
non-exclusive, non-transferable limited license to use, modify (except as limited by Section 1(f) below), copy and distribute the
Software only when the Software is embedded on a Microchip Product that is integrated into Licensee Product or Third Party
Product pursuant to Section 2(d) below.
Any portion of the Software (including derivatives or modifications thereof) may not be:
(i) embedded on a non-Microchip microcontroller or digital signal controller;
(ii) distributed (in Source Code or Object Code), except as described in Section 2(d) below.

Don't tell us the government made you do it.

[Kjelt]

It doesn't seem to be that difficult - I am trying to see if I can get it to run on STM32F103RB.

What am I missing then, a STM32F103 has no ethernet peripheral, the STM32F107 does.
And why not use LWIP ?

[dannyf]

What am I missing then, a STM32F103 has no ethernet peripheral, the STM32F107 does.

It utilizes ENC28/624 and has support for a variety of wireless chips / protocols.

I use it for small (ram) footprint, extensive functionality, and no need for OS.

It is fairly expensive for rom space.

[Kjelt]

So if I get this right it uses an external ethernet peripheral connected through SPI with the micro?
Is that not more expensive than a built in peripheral? And I thought (not sure)the 107 has DMA transfer on the ethernet peripheral which is also very nice.
Still an interesting experiment you're doing keep us updated of the progress.

[dannyf]

It will be more expensive: a mcu with native phy support would be far simpler / cheaper.

The point here is to allow smaller (ram) chips to access the net - however, we are not talking about the really small chips given the rom footprint.

[Kjelt]

The point here is to allow smaller (ram) chips to access the net - however, we are not talking about the really small chips given the rom footprint.

So you want microcontroller with less RAM but still fair amount of ROM to access the net.
If that is your goal, then what is the exact difference then between a 103 and 107, both are not Value Line processors, the 103 (Mainstream Performance line) and 107 (Mainstream Connectivity line) having the same amount of RAM (64kB)?
If you only allow few or even a single socket, use UDP and no DTLS security, reduce the MTU and thereby the required RAM buffers I heard you can get LWIP with 32kB RAM up and running but I am no expert on this matter.

[dannyf]

what is the exact difference then between a 103 and 107

No difference - the 103RB was chosen for its (estimated) sufficiently large rom. I could have picked something else as a target to port.

[nctnico]

With uIP I managed to get a BSD socket layer, web server, web client, DHCP client, telnet server, nslookup, a proprietary UDP protocol and a user application to work in an ARM controller with 32kB of flash and 8kB of RAM. I think a couple of hundred maybe a thousand of these devices are installed somewhere by now.

[andyturk]

With uIP I managed to get a BSD socket layer, web server, web client, DHCP client, telnet server, nslookup, a proprietary UDP protocol and a user application to work in an ARM controller with 32kB of flash and 8kB of RAM. I think a couple of hundred maybe a thousand of these devices are installed somewhere by now.

I bet that took some work to squeeze all that functionality into 32k. If they only shipped a thousand units, why didn't they just choose a bigger chip and save some NRE?

[mazurov]

I bet that took some work to squeeze all that functionality into 32k. If they only shipped a thousand units, why didn't they just choose a bigger chip and save some NRE?

You can reuse the code or add features using the space.

[nctnico]

With uIP I managed to get a BSD socket layer, web server, web client, DHCP client, telnet server, nslookup, a proprietary UDP protocol and a user application to work in an ARM controller with 32kB of flash and 8kB of RAM. I think a couple of hundred maybe a thousand of these devices are installed somewhere by now.

I bet that took some work to squeeze all that functionality into 32k. If they only shipped a thousand units, why didn't they just choose a bigger chip and save some NRE?

When I did that project I worked for an employer who focussed more on component cost than NRE. And the project got a bit out of hand. I think in the end the same board got used in 20 different products. Later on it got redesigned using a bigger controller for adding even more functionality.

[hans]

I just did a count of a DIY TCP/IP stack running on a STM32F407 chip, and it takes 5668 bytes of FLASH and 160 bytes of RAM (4 TCP connection slots). The on-chip ethernet MAC takes 16kB though because it runs 5 tx & 5 rx buffers (need 100Mbit throughput rate).
That stack implements (a very minimalistic) TCP, a simple webserver, UDP, a custom UDP protocol, ARP, IMCP and IPv4.

If you need to add all those extra features listed by nctnico, I estimate it would take a few kB extra. Maybe it's application is "richer" for ethernet, then it may take another few kB extra. All in all I don't think it's that tight of a squeeze.

The STM32F103 vs STM32F107 only difference is the 107 packs an ethernet controller.. but as I said those ethernet buffers take quite a lot of RAM. You can run less than I do (down to 1/1 tx/rx), but suffer on throughput. You do get 100Mbit speeds in return for "hosting" it on chip.
Other than that, I think the cost difference (if it's hobby I am assuming) between ENC28J60 and an phy is negligible , and it comes down to if you want a generic SPI <> Ethernet chip, or a (R)MII <> Ethernet chip, which is more tied to a select few CPU's.
The nice thing about chips like ENC28J60 is you can easily port it over to smaller platforms; I run my DIY TCP/IP stack on a PIC24 with 8KB of RAM and that works nicely.

As for the TCP/IP stack; it seems to me that it must be fairly easy to port. It compiles on XC16/32 which is basically GCC. There are only so few things that are platform dependent, like SPI, UART, Timer and external interrupts.
You can probably run the TCP/IP stack on a on-chip phy easily if you cut the code "in half" at the points of macTx and macRx(). From my own experience, the layers on top are often just doing some juggling with a bunch of structs, some if(), switch() and CRC calculations; and that's it.

[nctnico]

There is another option to get onto ethernet: a bit banging MII interface. In the project I mentioned before we used a switch chip. An ethernet phy is always the master and provides the clock to the slave (the microcontroller). On a switch chip however you usually can configure the MII port as a slave and bit-bang the whole thing. Since the MII port is asynchronous the logic inside the switch chip will take care of clock domain crossing issues. An added bonues is buffering incoming and outgoing packets.

[dannyf]

As for the TCP/IP stack

It is not difficult to port, unless you want to make the target chip part of the original software package - meaning that it should still compile to the PIC chips.

Take the port / pin operations for an example. The ENC28 implementation used lots of bit field references that you don't normally see in the ARM world. It is not difficult to implement, however.

What's difficult is the direction registers. The PIC's have one so a set / clear via the bit fields does the trick. For most ARM chips, it is done via multiple fields, or multiple registers. Figuring out an elegant way around that can take some time.

[Richard Crowley]

And what exactly is your motivatin to violate Microchip's license:

Porting it for your own personal use in your own home is not a violation of the license.
The violation is DISTRIBUTING the ported code to others (or, typically, using it yourself for commercial purposes).

[andersm]

Porting it for your own personal use in your own home is not a violation of the license.
The violation is DISTRIBUTING the ported code to others (or, typically, using it yourself for commercial purposes).

Notice the word "use" in the license. Porting the stack to non-Microchip devices is completely pointless except as an academic excercise.