New product under development Spinneret Web Server
David Carrier
Posts: 294
It is time for the Propeller to have its own official Ethernet development board. After a thorough search of the available MAC/PHY layer devices, we have settled on the WIZNet W5100. The Propeller is very capable of running its own TCP/IP stack, but the W5100, which has a built-in TCP/IP stack, still cost less than most equivalent MAC/PHY only devices. It works with 10/100Base-Tx and it will connect to the Propeller through an 8-bit parallel bus, which will make it much faster than an SPI only connection. The SPI bus is still connected though, for compatibility with SPI based W5100 objects.
The development board will have an SD card socket, a header with six GPIO pins, a three-pin servo-style serial connection, a Prop Plug port, and plenty of status LEDs. The EEPROM will be 64K x 8, with more than enough room to store the MAC address, network settings, and non-volatile variables. We will probably ship it with an SD card boot loader in the EEPROM, so that the firmware can be upgraded by updating a file on the SD card.
At Parallax we have had a long history of releasing the schematic and example code for the boards that we build, even before open source was popular. Now that open source hardware has caught on, it has become more important to be organized about it. So, we are now using official licenses and other such lawyer stuff. The design will be released under the United States version of the Creative Commons Attribution 3.0 license.
There is no reason to wait until we have boards in stock to release the design, so I have attached the schematic. We haven't even started the layout yet, so feel free to give your input. We will begin selling the boards as soon as we finish the design and get them manufactured. There is already a useful amount of W5100 code available on this forum, but we also plan on creating an official firmware to ensure that the board is useful to those who aren't Propeller developers. We will prioritize the hardware first, to make sure that it is available a soon as we develop it.
Here are the features that we will incorporate in the official firmware:
And this are some more advanced features that are still on the table:
The firmware will also be usable as an object, so you can have your applications simultaneously run on unused cogs in the Propeller.
Again, it is still under development, so whether you have grandiose ideas or simple comments, let us know. Of course, we can't implement everything everyone suggests, but unless you suggest it, we won't know you want it.
-- David Carrier
Parallax Inc.
The development board will have an SD card socket, a header with six GPIO pins, a three-pin servo-style serial connection, a Prop Plug port, and plenty of status LEDs. The EEPROM will be 64K x 8, with more than enough room to store the MAC address, network settings, and non-volatile variables. We will probably ship it with an SD card boot loader in the EEPROM, so that the firmware can be upgraded by updating a file on the SD card.
At Parallax we have had a long history of releasing the schematic and example code for the boards that we build, even before open source was popular. Now that open source hardware has caught on, it has become more important to be organized about it. So, we are now using official licenses and other such lawyer stuff. The design will be released under the United States version of the Creative Commons Attribution 3.0 license.
There is no reason to wait until we have boards in stock to release the design, so I have attached the schematic. We haven't even started the layout yet, so feel free to give your input. We will begin selling the boards as soon as we finish the design and get them manufactured. There is already a useful amount of W5100 code available on this forum, but we also plan on creating an official firmware to ensure that the board is useful to those who aren't Propeller developers. We will prioritize the hardware first, to make sure that it is available a soon as we develop it.
Here are the features that we will incorporate in the official firmware:
- UDP
- TCP/IP
- DHCP
- DNS client
- HTTP
- Dynamical variables within HTTP files served from an SD card
- A default web interface
- FTP
- SMTP
- POP
- Serial interface to other microcontrollers for dynamic HTTP pages
- A command protocol compatible with our upcoming WiFi module (for changing settings remotely)
- An open source GUI for connecting and changing settings from a PC (yes that includes Apple's PCs running OS X)
And this are some more advanced features that are still on the table:
- DDNS
- NTP client
- Parallel SD card support
- IMAP
- SSL/TLS
- SSH
- A secure version of the command protocol (for changing settings remotely over an insecure network)
- SOAP support, or some form of generic XML support
The firmware will also be usable as an object, so you can have your applications simultaneously run on unused cogs in the Propeller.
Again, it is still under development, so whether you have grandiose ideas or simple comments, let us know. Of course, we can't implement everything everyone suggests, but unless you suggest it, we won't know you want it.
-- David Carrier
Parallax Inc.
Comments
Also, does parallax plan to write an SD card driver or use open source code avialable on the forums? I've pretty much got most of the problems banged out with my driver that I'm developing.
When I finish it if I could get some serious help testing SD cards and MMC cards I could make sure that it is not suffering from any problems.
If parallax is considering writing an SD card driver that support the the full SD card bus protcol... well I would say that's a very bad idea and it should not be done.
Reasons:
The full SD card protocol requires CRC checks on all data, while its good to do this it will slow down file system speeds dramatically.
Its also lincensed so you would have to pay royalties on the product.
You'll need to get an engineer to write the driver. Which takes a long time to get working... And my code, rokicki's and lonesock's SPI code would be of no use for reference. Sandisk may provide source code to work with however...
...Actually, now that I think about it, implementing the full SD card spec would no be that horrible. However, there is not enough COG ram to do so easily as I have tried to implement all of the checks needed for the SPI mode and I hav still run out of memory as I am down to a little over 50 longs and not done yet.
It may not be possible to get everything needed for full SD mode done in one cog's ram, but I am using alot of variable space...
...Anyway those are my thoughts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
--jc
Agreed. this is pretty standard in other devices.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's Only A Stupid Question If You Have Not Googled It First!!
Re: "An open source GUI for connecting and changing settings from a PC (yes that includes Apple's PCs running OS X)"
This is very encouraging. I'm glad to see that Parallax is finally moving beyond dependence on Delphi for GUI development. Hopefully this is the beginning of a trend that will propagate to other dev software as well.
I like your choice of the WizNet W5100, too. Although the Prop has been shown to be capable of network protocol support, it seems unnecessarily burdensome, given the capabilities of economical and very capable chips like the W5100.
-Phil
www.ewiznet.com/goods_detail.php?goodsIdx=124
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
I probably should have introduced David as our new internal Open-Source Advocate (OSA). In addition to understanding design, he know the various open-source initiatives quite well (notice how he chooses the most open, free one he can find). To know what he's all about all you have to do is to take a look at his Wii - it runs Linux and boots games from memory. Long before his appointment as our OSA he's chatted about various open-source projects throughout the office. So, you will see David coordinating the Parallax open-source aspect of new and older products at this point. You'll see complete Gerber data, BOMs and OS licenses attached to the downloads where products are sold on our web site.
And when he manages a new product the design will set forth the right open-source approach from the onset.
We're not just looking for "atta boy!" from the OS community, but applying the idea for sales generation. We're trying to make it really easy for developers to snatch up our designs and make them their own. Especially if it uses a Propeller.
Ken Gracey
Parallax Inc.
For now, I am sticking with the ENC28J60 for my upcoming products, giving up speed for a lower pin count interface and DIP device [noparse]:)[/noparse]
I will admit to having recently received two W5100 modules though.
Has the SD 4 bit mode licensing issue been resolved yet? That is why I have stayed away from 4 bit mode, even though I've run across "how to do it"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
*I agree with Kye, put the pull-up resistor on both I2C lines - SDC and SCL.
*You could use a switching voltage regulator for the 3.3V such at the National Intruments LM2594, or similar for more current. The switching reglator could allow for a wider input voltage range, like 6V DC to 24V DC.
*The schematic mentions 5V DC, why? Is it there for prototyping sake?
*You said you haven't started layout yet, but do you have a sketch on where you are going with the layout size? I would recommend making the layout such that baords can be stacked on top of this board (without covering LEDs of course) or that this board could be plugged into another board. Either options means thinking through the placement of the user interface component and where the expansion headers are for easy plugging and sharing of signals.
*Nice job bringing the all the LED signals out. How about a 3.3V power indicator LED as well?
*You mentioned a 3-pin servo style serial header, how about a four pin header for I2C, 3.3V and Gnd? At least a place for one that the user could easily populate.
*Nice job including adding all the caps on the Prop power supply.
Are you using mostly surface mount components? QFP Prop? What crystal are you thinking about?
I attached the design I was working on. One thing about the design that I was doing is that I wanted to make the device configurable for either SPI or 8-bit. The user could then design their project understanding I/O count, ethernet interface speed, etc. I was picturing that one side of the board layout would have solder jumpers (or it could be 3 pin headers with shunts). Solder down one side of the solder jumpers and all the SPI connections would be made as well as routing the unused Prop signals to the expansion headers where the other free I/O was. Solder down the other side of the solder jumpers and all the 8-bit bus interface connections would be made. Of course this meant that the user couldn't use the device directly out of the box, but instead needed solder or jumper their chosen interface. I searched breifly for a DIP switch like device for this kind of trick because I was thinking low profile and easy to use/reconfigure, but I got distracted before I completed my searching.
Do keep us posted. I'd love to help out with some code and hardware design. I started with the W5100 some time ago, but set it aside to pursue some other priorities.
Edit: Attached the file. As you can see I was going to call my device PropNet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Timothy D. Swieter) : 1/26/2010 5:38:06 AM GMT
The only problem is that the product's MAC address would show up under a Microchip OUI, but it would seem the benefits greatly outweigh this minor issue. It will also take up a free I/O pin since Microchip's smaller EEPROMs don't support addressing.
Other than that, the product looks pretty awesome. An official ethernet connectivity product will definitely make the Propeller much more popular.
Post Edited (Harrison.) : 1/26/2010 5:49:09 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
*It looks like you got both the SPI and the 8-bit items wired. This still allows flexibility for those who want to use SPI, but it ties up I/O lines. I suppose you could just chose one interface over the other for the design or maybe consider something like I proposed with solder jumpers or some switches to pick the interface and leave the maximum amount of I/O free and easy to interface to.
*I also see you wired a Prop output to the W5100 'SEN'. This is to enable/disable SPI on the W5100. Could this be a jumper position instead of a Prop pin? Again, just trying to free up some Prop pins for expansion opportunities.
*I like the jumper for enabling/disabling the RES signal on the Prop Plug. I recall a forum member requested something similar in a thread here not too long ago.
edit: corrected spelling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Timothy D. Swieter) : 1/26/2010 6:20:12 AM GMT
In other words (correct me if I am wrong). I2C devices have Address High byte and Address Low byte. The external A0 to A2 lines usually manipulate part of the address low byte. The Address high byte is the same for identical ICs. The question is if the address high byte is the same for the MAC IC as it is for the 24LCxxx.
edit: corrected spelling
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Timothy D. Swieter) : 1/26/2010 6:22:35 AM GMT
YES! Excellent!
I'm almost scared to ask. Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
You can often order parts with a difference base address, so you can actually hang 2x the number of parts. 512Kib parts only have A1 and A0, 1024Kib parts have only A0. By ordering two parts with the base address of 0xa0 and two with the alternate base address, you can hang 4096Kib of EEPROM on one I2C bus.
There's a good explanation of pages 9 and 10 of the Atmel AT24C128/ATC256 part. atmel.com/dyn/resources/prod_documents/doc5279.pdf
--jc
(edit: remove extraneous URL, add some stuff)
Post Edited (jcwren) : 1/26/2010 2:22:01 PM GMT
I'm almost scared to ask. Linux running on ARM or PowerPC or anywhere ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was just reading about a cool project (http://www.wizwiki.net/blog/regina/43) and found their solution interesting!
Just dig out an old PC ethernet card out of the closet and use it's MAC address...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I second the need for an NTP client. Embedded Web device servers are all about remote sensing, time-stamping and serving up the data. Consider putting a settable real-time clock on the board too.
We need to program the Propeller Web Server remotely (bye-bye Prop-Plug, this isn't going to go over well with Parallax Marketing).
If you can do SSH/TLS/SCP clients on the Propeller board than you stand-out from the crowd in a big way. Good luck with that, I seriously doubt the Propeller has the resources. Prove me wrong. Please. Keep in-mind the current version of TLS (V1.2 if memory serves) has a major security hole. The next version (ff not already available) will fix this.
Just for fun, take a look at this new Web Server board. Go to the link below.
dangerousprototypes.com/2009/12/11/prototype-web-platform/
They're available now and cost $37 USD. (I'm not commercially or development-wise affiliated with this project in any way)
Finally, consider that you can do a Web server running Linux or xBSD on a hacked ~40 USD consumer router with NAT/PAT (the venerable WRT54GL comes ot mind) running the likes of OpenWRT, DD-WRT, Tomato, etc. Hardware-wise you get two serial ports (one general purpose, one console plus SSH log-in), and if you're lucky a few GPIO pins for SPI/I2C expansion. No MAC address issues, the MAC is included in the price of the router. If you pick your router carefully, you get an IPSec end-point, NTP client, lots of routing options, a firewall with configurable holes. on and on. But you don't get much in terms of GPIO unless you can drag at least a few pins out for SPI or I2C expansion. You're not limited to 4-sockets like with the W5100, (eight with the W5300 but it seems the W5300 doesn't support an SPI interface).
All said, I fully support the Propeller Web-Server project. We need a Web-server with lots of GPIO and as always, multiple cogs frees us from interrupt-handler nightmares.
Regards, David
Post Edited (Drone) : 1/26/2010 8:21:46 PM GMT
Nice catch on the SCL resistor. When the I2C bus is only used internally, and none of the devices support clock stretching, we have the Propeller drive the clock in a push pull configuration. When the I2C bus is accessible, the pull-up resistor should be there.
We haven't decided if we want the features in the second list, so we may still use the SD card in SPI mode. The SD Association has released a simplified version of their specifications that does not require registration or an NDA: http://www.sdcard.org/developers/tech/host_controller/simple_spec/. We do not plan to duplicate efforts, but to build on to existing code. We also plan on paying people to write new portions of code, as needed.
JC and Brian,
An NTP client is a good idea, but it is useless without a real-time clock. This brings up a good point; a real-time clock would be very useful. If for nothing else, it would be needed to make date stamps in logs and to keep track of DHCP leases. I was originally thinking it could be an add-on, but now I am thinking it should be built in. Every feature adds a little bit of cost, whether you use it or not. What are everyones' thoughts on including a real-time clock?
Phil, BradC, and heater,
We will be hiring someone, as a consultant, to write the GUI. We will be able to specify what they use to develop the software. I would prefer for them to use the Lazarus RAD to create it, because it has a high compatibility with Delphi, and it has a wide target support, including Windows, OS X, Linux, and FreeBSD. It can even compile to an ARM or PowerPC platform.
SLRM,
I did look at the W5300. Besides costing a little more, it does not have an SPI bus, and we want to make a development platform that can be used to design for both parallel and SPI buses. If the final application needs extra I/O pins, but doesn't need a high speed connection, it will be better to use the SPI bus.
Timothy,
I'll look at the switching regulators, but they do have a cost and board size trade off. The 5 volt connection is for connecting to BASIC Stamps or other 5 volt microcontrollers. There is a FET functioning as a bidirectional logic level translator.
I added a power LED, which brought my attention to the other LEDs, which were wired incorrectly, so I fixed them.
I'll probably use the QFN Propeller package, because it makes probing easier. I haven't settled on any specific crystals, but I'll probably pick something smaller than the HC-49/U-S package. I would like to make the board as small as is reasonable, but I will include mounting holes, which could be used to stack boards. For the I2C, 3.3 V, and ground connections you mentioned, you could use the 12-pin header. I made the layout on the schematic follow what I was imagining for the board, with he headers on one end, the Ethernet jack on the other end, LEDs along one edge, and the SD card socket on the other edge.
The SPI and 8-bit parallel lines are shared. There is only one line that would not be needed if the 8-bit parallel bus were used alone — SEN. The Propeller can set SEN then reset the W5100 to switch buses. I just added a pull-up resistor to the SEN line to make it default to SPI. To keep it small and simple, I'm not adding connections to the pins that are freed when using SPI mode.
Harrison,
I had looked at the MAC address EEROMs, but we will need to procure a block of MAC addresses for the WiFi module we are working on anyway, so we will have enough available for this project. The cost difference between the 32K x 8 and the 64K x 8 EEPROMs was also less than the cost of the MAC address EEPROMs.
Jon,
I fixed the pin-out on the servo-style connector, thanks for pointing it out.
Thanks everyone for your input,
David Carrier
Parallax Inc.
And even if you don't do calibration, you can hit the NTP server (preferably on a local network!) frequently to stay within a couple milliseconds or better.
--jc
--jc
There are lots of great software and hardware ideas here. I bet David has his hands and head full of contemplating all of the possibilities and trade offs and other design decisions.
For those that are really hungry to write software (and some of you are masters are knowing what and how to write it), there is no reason we have to wait for the actual device. A Prop Proto Board, An Ethernet WizModule and a SD card socket should be enough to get started. Wiring these items to a Propeller Proto Board wouldn't be too bad - an hour or two and then we can start creating the software as a parallel development to the hardware. Thus, when the product is released, there is some sold software ready to run. What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Whatever module is decided upon, I'll produce high quality I2C code for it for free, Its not too much work since I can just reuse most of the code I have made for my DS1307 RTC and my generic I2C EEprom driver.
---
I'm still going strong on my full FAT filesystem driver. Most of the recent updates have been made to it only to make it faster and have more capable error handling in every situation.
Getting pathing to work is really ugly however. The string processing is awful, really awful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Preaching to the choir [noparse]:)[/noparse] Lazarus works well once you get your platform specific support stuff right.
As for the webserver, I'd second the calls for NTP and DDNS support if you can jam it in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Also, the 5 volt supply is only a requirement for 5-volt I/O; the six-pin header has 3.3 volt I/O and a connection to the 3.3 volt supply rail.
— David Carrier
Parallax Inc.
If I could make a request regarding the expansion port header: one thing I would like to see Parallax do more often is leverage the products they already have when designing new ones. This means looking at how to make existing products plug into new ones, or vice-versa. The Parallax MoBo product line, including the Propeller Backpack, uses a 12-pin two-row female header connector (DigiKey link) for expansion that the daughterboards (including the very popular Proto-DB) plug into. Using this connector with the pinout shown below would open a broad range of current and planned products that would be immediately compatible with your board.
The pins designated SDA and SCL also perform these functions with the MoBoStamp-pe, along with all daughterboards that use the I2C bus. It would be nice if A0-A3 could be used, as shown, for the AUX pins, instead of A24-A27 to permit using the (perenially-delayed) PropCAM. OTOH, with A24-A27 you get a continuous bank of eight pins to work with. (Note that I've omitted A23 in favor of +Vin, which is a daughterboard standard.) I would also use 4.7K pullups on A28-A31 (daughterboard standard for these four expansion pins). Putting pullups on RX and TX holds them in their normal marking state during reset and when the Prop Plug is disconnected, thus preventing unwanted BREAKs on the serial I/O lines.
Anyway, if this sounds intriquing (and it should
Thanks for considering this. I believe it will add even more value to your board.
-Phil
Phil,
I didn't realize that the MoBo products had such a similar 12-pin connector. I also like the smaller metric lead spacing. The connector does have one less I/O pin, though. The 5-volt pin is really an input, but the user could provide power on the three-pin header. It is also tempting to use the Vin pin for the fifth I/O. It would mean that anyone that connects the power-I/O daughter board would instantly fry the whole thing. I am assigning the extra I/O pin to a button and an LED. It is always nice to be able to do something, even if it is just blinking an LED, without adding any extra hardware.
— David Carrier
Parallax Inc.