porting Microchip Tcpip stack - Page 1
Forum section: electronics / general

author: dannyf
author_rank: Super Contributor
timestamp: August 08, 2014, 06:23:22 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: August 08, 2014, 07:23:43 pm
content: It would be against the license terms, so probably not.

author: dannyf
author_rank: Super Contributor
timestamp: August 08, 2014, 08:43:08 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: August 08, 2014, 09:02:24 pm
content: I am left with some pin definitions to be changed, implement a timer isr, and spi status registers.

author: SirNick
author_rank: Frequent Contributor
timestamp: August 08, 2014, 09:33:56 pm
content: 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...

author: nctnico
author_rank: Super Contributor
timestamp: August 08, 2014, 09:51:04 pm
content: 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

author: Bored@Work
author_rank: Super Contributor
timestamp: August 08, 2014, 10:06:29 pm
content: And what exactly is your motivatin to violate Microchip's license:QuoteDon't tell us the government made you do it.

author: Kjelt
author_rank: Super Contributor
timestamp: August 08, 2014, 11:14:00 pm
content: Quote from: dannyf on August 08, 2014, 08:43:08 pmWhat am I missing then, a STM32F103 has no ethernet peripheral, the STM32F107 does.And why not use LWIP ?

author: dannyf
author_rank: Super Contributor
timestamp: August 08, 2014, 11:29:38 pm
content: QuoteIt 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.

author: Kjelt
author_rank: Super Contributor
timestamp: August 08, 2014, 11:52:09 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: August 09, 2014, 12:14:29 am
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: August 09, 2014, 10:53:16 am
content: Quote from: dannyf on August 09, 2014, 12:14:29 amSo 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.

author: dannyf
author_rank: Super Contributor
timestamp: August 09, 2014, 11:16:34 am
content: QuoteNo difference - the 103RB was chosen for its (estimated) sufficiently large rom. I could have picked something else as a target to port.

author: nctnico
author_rank: Super Contributor
timestamp: August 09, 2014, 12:45:24 pm
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 09, 2014, 05:48:39 pm
content: Quote from: nctnico on August 09, 2014, 12:45:24 pmI 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?

author: mazurov
author_rank: Frequent Contributor
timestamp: August 09, 2014, 06:06:41 pm
content: Quote from: andyturk on August 09, 2014, 05:48:39 pmYou can reuse the code or add features using the space.

author: nctnico
author_rank: Super Contributor
timestamp: August 09, 2014, 06:41:02 pm
content: Quote from: andyturk on August 09, 2014, 05:48:39 pmWhen 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.

author: hans
author_rank: Super Contributor
timestamp: August 10, 2014, 07:46:09 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 10, 2014, 10:39:34 am
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: August 10, 2014, 02:11:02 pm
content: QuoteIt 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.

author: Richard Crowley
author_rank: Super Contributor
timestamp: August 10, 2014, 02:23:56 pm
content: Quote from: Bored@Work on August 08, 2014, 10:06:29 pmPorting 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).

author: andersm
author_rank: Super Contributor
timestamp: August 10, 2014, 07:15:19 pm
content: Quote from: Richard Crowley on August 10, 2014, 02:23:56 pmNotice the word "use" in the license. Porting the stack to non-Microchip devices is completely pointless except as an academic excercise.