WIZnet Module Software Architecture Thoughts

Timothy D. Swieter

I have my WIZnet module 'working'.· I can ping it and I can exchange UDP data with it.· I have some base code for writing a driver now.· The hard part is determining the structure of the driver.
·
My thought is that the driver should be a·purely TCP server/client driver or a purely UDP driver.· Writing one large driver seems like a waste of code space and complexity.· A specific driver though would be better,·right?·
·
So let’s say I am writing a purely UDP driver.· What features and functions would you want included?· How can I make it generic enough that others can use it?· I started thinking down some of my 'old roads traveled' with regards to software design, but the Propeller's multiprocessors throw a wrench in the works.
·
One thought is to have a driver that runs in its own cog.· It would be a driver for using the WIZnet module in SPI mode.· The driver would always be exchanging data with the chip and retain data in the Prop for other code to call it out.· The cog is then always running, watching for new data from the chip or getting data from the chip.··To me, it seems like the cog should do so much more if it is running all the time.·
·
Maybe a better approach would be to have a·driver·that·provides routines for opening a socket and reading/writing data but doesn’t consume a whole cog.· Usually one needs to decode the data anyway so it may be inefficient to bring over the encoded data from the WIZnet only to be stored in another buffer on the Prop.
·
What are your thoughts?·
·
I am second guessing my initial thoughts.· I think my plan of·action·is to code an·SPI/data·exchange·engine and buffers in ASM.· The engine would be launched into another cog.· Included with the drivers would be routines to send or receive certain data or to perform routine functions.· These routines would place commands and data into the buffers that the SPI engine is watching.· Users that use the driver would then have their main code periodically call the driver to look for new data.· I think this driver is similar in concept to how FullDuplexSerial is implemented.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

hippy

Perhaps the real issue is what is "driver" and what is client or server. I'd envisage the "driver" being nothing more than a single thread (Cog) which receives packets and puts them in some 'received pool' while taking from a 'transmit pool' and sending them out. That is perhaps what your "second guessing" is ?

Another thread can run which takes packets from the receive pool, deals with them ( easy for ARP, RARP, etc, and even UDP ), passes them off to others ( for TCP services, clients or servers ), or discards them.

I think your driver has to be generic, allowing whatever 'service' objects a user may wish to include, DHCP, UDP, TCP etc. Break the system down into individual layers of a TCP/IP stack whether run in a single thread with switching depending on packet type received or as separate threads.

That's the way I wrote a TCP/IP stack which ran under MS-DOS and it worked quite well although my lack of experience with TCP had me stumble there.

The advantage of a central pool for receive and transmit packets is that it becomes easier to add additional real world interfaces, PPP and SLIP over serial or wireless ( such as XBee ), Direct Cable Connection (DCC) to PC and so on. Your WIZnet driver would simply be another real world interface between the pools and the hardware.

It also means you can focus on things separately and in isolation, pool filling and emptying ( hardware interfacing ), packet dispatching and routing, and the separate higher level services. Try to put it into one big monolithic inter-dependant lump and I think you may run into problems when it comes to scaling or re-use.

Rayman

Congrats! My module has been sitting on the shelf for a month now... To me, the most important thing to do is a TCP port 80 web server...

Fred Hawkins

So here you are, it works (or it could/should work) and you have 7 cogs left. What can else can you do to win the contest? It needs to be..
1) clever
2) useful
3) cool

Yeah, even so (you're not in it to win) the open forum question is what will win?

My bet: photos of the intruder at the door posted on the web.

BTX

Great Timothy !!

Sorry, I don't understand nothing about TCP/IP, UDP, etc.
My target (maybe yours too) is to comunicate a PC or "Video equipment" that converts the Ethernet link into a DMX link to send video movies to LED panels.
I hope·my mean·is clear, i'm·working·with my "led screen" at many shows, and I can see every times, that people uses a computer to send video data through ethernet, to·many "LED pipes" (like you did, and you show in another thread).
People uses about 200-300 LED pipes, putting all them making a big square (all linked by DMX, using about six DMX universes) and show the video images on them.·They have a computer linked to a "Scan converter" and this out to the DMX boxes by ethernet sending the video data.

Of course, I think I'll need to write an "asm", and parallel mode driver for that, but maybe I could get it translating the "SPI driver", my opor problem is "how to get the data from PC to the Pchip at high speed", and then, how to compatibilize with the comercial video equipment protocoll.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

hippy

Fred Hawkins said...
What can else can you do to win the contest? It needs to be..
1) clever
2) useful
3) cool

Streaming music player ? Not that clever really as transmission compression can be simple and the server can do the hard work decoding MP3 or whatever into compressed packets to send.

Paul Baker

I like the idea of "MUD in a tin", use an altoids tin with a board inside that has· (1) PS/2, RCA, and RJ45. Plug it into a TV, a keyboard and your network and it runs a mud client (like tintin++, Maybe could call the project "tintin in a tin") and connects you to a chosen website to play your favorite text-based multi - user dimension (MUD). Sadly most of these have shriveled up and died, but SlothMud is still alive and kicking http://www.slothmud.org


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

James Newman

I played a MUD for 10 years (I'm only 22). Infact, my first large code project was a MUD written in VB4.0. I get the urge to make one about once a month .

I would have loved to have 'MUD in a tin' back when I was allowed one hour of computer time a day...

Harrison.

You could also look at my PropTCP code to see if it would help in designing your driver. The API provides the user with a handle (socket index) that they use to manipulate sockets with. Interaction is done through global variables and circular buffers to ensure multiple cog access compatibility. I used FullDuplexSerial as a model for the circular buffering (I like how it doesn't use locks since it uses a head/tail pointer).

code.google.com/p/proptcp/wiki/TelnetServer (scroll down to Beta API)

Harrison

Timothy D. Swieter

Thanks guys for the feedback. The responses sort of help - sort of.

The WIZnet chip handles all of the stack and 'noise' of working with Ethernet. The Propeller code in this case exchanges a few parameters with the WIZnet chip and away we go. The Prop then reads data out of buffers or writes data to buffers to send. This is a wonderful solution because I don't have to write a TCP/IP stack, just a state machine to send data into a buffer and flag the correct registers. Form my little understanding of the other Ethernet chips being used they are more involved than what I just described.

After some of my own brain storming on what I want to do with the chip, I think the first driver I will pursue is a UDP driver. I was hoping to get to it today but didn't. The UDP driver will be bland in that others can use it as a learning tool to see how the interface to the WIZnet chip works. My recommendation would be that each application actually has a driver written specifically for it. I think it is more efficient to decode and parse the data as you bring it over from the WIZnet chip then to store it in another Propeller buffer and have yet another cog handle it. Does this make sense?

Again, thanks for the feedback and stay tuned for more info and code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

hippy

Timothy D. Swieter said...
The WIZnet chip handles all of the stack and 'noise' of working with Ethernet.

I should have paid more attention. I thought it was basically a packet handler like the ENC28J60. My bad.

Timothy D. Swieter

No worries. I didn't explain it that well. Some times I get caught up in an idea I just assume everyone knows what I am talking about.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

bambino

That sounds good Timothy, one thing I have been pondering is a way the propeller might know post connection whether it's TCP/IP or UDP. Assuming that the wiznet, as a listener(Client), can make a connection to either Caller(Server) on its own.

But, Then again, I guess that to would be up to the Prop to determine! I'll figure this joker out some day.

Timothy D. Swieter

I have attached the code I used to get the WIZnet module running, respond to a ping and to echo data sent over a UDP connection.· The code is very (very) ugly but for those curious it is a start to understanding how to connect.· There is much more work to do to make a driver.

I am getting short on time before Christmas,·so the driver coding work may not happen until after Christmas.· It is a pitty I can't travel better with my Prop Demo Board and WIZnet module.· :-) 16 hours on a plane (and an outlet to plug my laptop into) should resovle my time lack of time problem.

Bambino - depending on how the driver comes out, the software or at least the software design and designer·would know if it is connecting over UDP or TCP because of what connection the software invokes.· The connection schemes are different and which connection is used is important for the design you are implementing.

I think the WIZnet module is rather easy to grasp because it takes care of what I would call the dirty work of TCP or UDP.· The Propeller simple needs to read data out of registers and clear/set flags appropriately.

P.S. I used the WIZnet 5100 datasheet, Fred's article in Circuit Cellar and other forum posts as references for creating my code.· I remember writing code based on Fred's code, but there was an important register write that wasn't shown in his code.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

Capdiamont

Tim, have you done any more with the wiznet module?

Ziggy252

There was a Wiznet 5100-based module developed for the Hydra:
http://www.parallax.com/Store/Microcontrollers/PropellerTools/tabid/143/ProductID/540/List/1/Default.aspx?SortField=ProductName,ProductName
The manual contains driver code, and I think you can download source and examples from the author's website.

Capdiamont

I have one of the free modules from the contest. I'll check in to that.

Ziggy252

Me too. Haven't had a chance to hook it up, but it looks like it will work with the freebie, you have to connect 5 pins to the Prop:
Prop Pin : Function : W5100 Module Group/Pin
19 : SCLK : 1/7
20 : SCS : 1/10
21 : MOSI : 1/9
22 : MISO : 1/12
23 : RSET : 2/2

Then tie a few lines high/low to set operating mode.

Timothy D. Swieter

Thanks for asking Capdiamont. Actually I didn't go too much further with the code, however I am working on a design of hardware for the Propeller and a WIZnet module right now. I hope to wrap up the design in the next couple weeks. The module will use the newer WIZ812MJ module but it still contains the W5100 IC.

I looked at the Hydra EtherX card/module a couple weeks ago and it looks like you should be able to use that module just as Ziggy252 suggested.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com