Porting AsyncLabs WiShield 2.0 and uIP stack to Maple

LeafLabs Garden » Support » Maple Hardware Support

Porting AsyncLabs WiShield 2.0 and uIP stack to Maple

(49 posts) (7 voices)

Started 5 years ago by Adam
Latest reply from perry

12…4 Next »

Adam
Member

Folks,

AsyncLabs makes an open hardware Arduino wifi shield called WiShield 2.0: http://www.asynclabs.com/store?page=shop.product_details&flypage=flypage.tpl&product_id=26&category_id=6

It uses the MicroChip/ZeroG G2100 wifi module. AsyncLabs ported the uIP TCP/IP stack to run on the Arduino and wrote a driver for the G2100. Here is the development wiki page for the board:

http://asynclabs.com/wiki/index.php?title=WiShield_2.0

I'm thinking of porting the WiShield drivers and the uIP stack to run on the Maple.

There are two parts to the project - porting the uIP stack and porting the G2100 drivers.

I was wondering: has anyone here done either or both of these already? It seems like to get ethernet working on the Maple, that would need a uIP stack, so that's why I'm asking. If not, I'm happy to work on these, I just wanted to ask before I started.

(Why I'm interested in doing this: I want to build a data acquisition device that can provide about 2000 24bit ADC readings per second via HTTP. I believe Arduino is not capable of this throughput, but the Maple's Arm Cortex M3 is more powerful, and by my estimates it should work because the Maple is 4.5 times faster and has 20x more RAM for the TCP/IP buffers.)

If neither of these have been done yet - I'm also interested in advice or resources. I searched, but haven't seen any Arm Cortex M3 uIP ports on the web yet.

cheers
adam
--
Adam Feuer
Seattle, WA, USA
adamf@pobox.com

Posted 5 years ago #
poslathian
LeafLabs

Great idea, keep us posted! The ethernet shield we have used (successfully) with Maple had its own MCU that (as far as i know) actually implemented the TCP stack and interfaced with the PHY layer. And that board you just get a serial interface from Maple to the ethernet shield.

I have been working on LWIP for another project and got excited about the prospect of LWIP or uIP on Maple, I think its definitely possible. You wouldnt be stepping on our toes if you did it, we might even be able to help!

Posted 5 years ago #
Adam
Member

Ok, I'm working on it. I got the uIP stack to compile for Maple. Now I'm working on the ZG2100M driver. The SPI on Maple is a little different from the SPI on Arduino via C++, and I'm an SPI newbie, so it might take me a while.

Do you have any examples of how to use SPI from C++? Seeing some more code would certainly help.

cheers
adam
--
Adam Feuer

Posted 5 years ago #
Adam
Member

By the way - the reason I'm using uIP is because AsyncLabs ported it for use with the ZG2100M, and includes it in their distribution. I'm going to first try to get that working with as few modifications as possible.

Both uIP and LWIP seem to be under active development. Which one is better?

-adam

Posted 5 years ago #
perry
Administrator

hi adam,

try taking a look at this example for how to use the SPI as a master.

http://github.com/leaflabs/libmaple/blob/master/examples/spi_master.cpp

feel free to ask questions

Posted 5 years ago #
Adam
Member

Perry,

Thank you - I have libmaple checked out and will base my SPI master code on this example. I'll report back when I get some results!

-adam

Posted 5 years ago #
poslathian
LeafLabs

as far as i know, uIP is branched off of lwIP. lwIP is pretty fully featured, supporting everything from raw UDP all the way to BSD style sockets and integration with threaded kernels. I dont know the exact details, but uIP should be decidedly less than this.

From the developers website (http://www.sics.se/~adam/software.html ):

uIP is the worlds smallest full TCP/IP stack. Intended for tiny microcontroller systems where code size and RAM are severly constrained, uIP only requires 4-5 kilobytes of code space and a few hundred bytes of RAM. uIP has been ported to a wide range of systems and has found its way into many commercial products.

lwIP is a small TCP/IP implementation for embedded systems. lwIP is larger than uIP, but provides better throughput. lwIP was initially written by me but is now developed by a group of developers distributed world-wide. lwIP is used in many commercial products.

Posted 5 years ago #
Adam
Member

poslathian,

Great info about lwIP! Ok, after I get the ZG2100 driver and uIP working on Maple, I will see if I can get the driver working with lwIP. I want higher throughput and a more fully-featured IP implementation.

-adam
--
Adam Feuer

Posted 5 years ago #
poslathian
LeafLabs

I dont recall the exact requirements for LWIP, but i believe it was right at the boundary of what we can support. Perhaps 20K of ram...or something. With the bootloader, we give 17K, but we have 20 to play with if you play games with the bootloader. Itll be close. Good luck!

Posted 5 years ago #
Adam
Member

Hmmmm. I thought I can run programs directly out of flash, and just use the RAM for data storage. Is this not the case?

If not, what does the option in the IDE called "Leaf Labs Maple R3 to FLASH" mean? I looked at the bootloader source code, and it seems to test for a magic value in flash, then seems to jump directly to code located in the flash. Is that right?

Posted 5 years ago #
poslathian
LeafLabs

You are correct. But lwIP (might) require 20k of ram as well. This is the runtime memory lwIP would need for things like packet buffers and its own stack and heap. Its likely possible to reduce this requirement by, for example, reducing the number of packet buffers in the buffer pool. In fact, this is one of the built-in configuration options for lwIP, i believe the default is 8 (1k?) buffers.

Posted 5 years ago #
poslathian
LeafLabs

I should be more specific. Only program code is stored in ROM (flash). The actual variables and runtime data structures that you modify, as well as the stack, are stored in RAM for both Maple-RAM and Maple-FLASH. You CAN (and should!) use flash memory for storing large constant data structures (like a small bitmap, or a wave table or something...) - as arduino allows you to do with the 'progmem' decorator. We dont support "progmem" syntax yet, but its coming! However, be sparing in your use of writing to flash inside of your programs. Thankfully, it is impossible to do this by accident, as there is a somewhat convoluted process required (including writing a magic number to an unlock register) to actually write to flash.

In addition to performance considerations (flash writes are slow), flash is generally only appropriate for ROM because flash has a finite number of write cycles. While this number is quite large (usually many tens of thousands of writes) it makes flash memory unsuitable for runtime operations. For example, if you did nothing but reprogram maple all day long, you might eventually get bit errors after a few years (keep this in mind if you have a thumb drive youve had for one too many years!). However, if you wrote a program to consecutively erase and write to flash pages, you could probably corrupt the memory in a few minutes.

In fact, there was an arduino project out there (I forget the name) whose sole purpose was to time how long it took to destroy flash memory via consecutive reads and writes, and in general it took an order of magnitude more r/w cycles than the spec sheet suggested - which is good!

Posted 5 years ago #
Adam
Member

Wow, thank you for the detailed answer! That was very helpful.

So that matches my mental model of how things work on the Maple - program and nonvolatile data storage in flash, volatile data in RAM.

uIP has a single 400 byte buffer by default. (!) That can be changed to be larger, but at its current size it really limits the data transfer speed. I will check out lwIP's RAM requirements. Using more RAM will allow faster data transfer, which is what I want, but I need enough RAM to run programs too. I'll see how it balances.

Posted 5 years ago #
poslathian
LeafLabs

exactly. well put.

Posted 5 years ago #
Adam
Member

I got the driver's ZG2100 and SPI HAL ported over - with interrupts, SPI, and LEDs. The driver and the uIP stack compile without error. There are a few warnings like this:

<command-line>:0: note: this is the location of the previous definition

Has anyone seen these? What do they mean?

However, the code does not link properly... somewhere there is still a stray reference to the 'strlen_P' function, which doesn't exist on the Maple. The error is this:

o: In function `fill_buf':
undefined reference to `strlen_P'

However, I grep the code for 'strlen_P' and 'fill_buf', but don't see them.

So my next task is to trace this down. Does anyone have any ideas on how to find out where this is being referenced?

Posted 5 years ago #

RSS feed for this topic

12…4 Next »

Reply »

You must log in to post.