Hi David.
Will be a nice & usefull board to play with !!
Please correct the schematic, the real time clock part, it is not a 24LC256, also the xtal should be 38Khz ?, pin names too.
If this is to be a development board, it would be useful to be able to connect/download firmware directly via a USB connection (aka the Demo board) rather than needing a PropPlug.
The ability to connect the USB data-logger would be useful; the Web access/error messages could be logged to a USB stick allowing a split/seperation between the SD card (web content) and USB log data.
This looks a great little board. For years we have been promised "net aware" appliances but the cost has been such a barrier. In the past there is little point in adding a fridge temp sensor when it costs over $100 to interface a $1 part to the internet. Especially when you can get an entire WiFi netbook for only $20 more.
The components used in this board look much more realistically priced, so hopefully the final board will also be realistically priced.
Interesting comments from Timothy re switchers. I've gone 100% for switchers as I think they save money if the current is more than about 100mA - especially when you add in the cost of a heatsink and/or the cost per square inch of board that is purely dedicated to heatsink area. Caps are the same/similar for both linear and switching, so by way of indicative prices a LM2575T-5 form futurlec is $1.55, a 1N5819 is 14c and an inductor is about $2. So $3.69. A 7805 is ?25c and a heatsink varies depending on how much current you are drawing and the input volts. I'm not sure of the crossover point where it is worthwhile going switcher but I'm guessing it is around 100mA.
I'm looking forward to adding the internet to my ever growing propeller wireless network!
Both +5V and +Vin can be either inputs or outputs. On some daughterboard connectors (e.g. Propeller Backpack), Vin is omitted. The only daughterboard that sources Vin, so far, is the PWR-I/O-DB, and that connection is jumper enabled. The MoBoStamp-pe (schematic in the user docs) has jumpers to select the power source. You could include jumpers to select between +Vin and A23 for that pin. But an even better option might be to port A23 to a separate 3-pin "servo style" connector for things like the Parallax serial LCD display.
Or ... you could combine the best of both worlds like this:
The five-pin header doubles as a 3-pin servo-style connector and a way to jumper either A23 or +Vin (or neither) to the 12-pin expansion connector.
The W5100 looks like an interesting device to use. On the subject of RTCs I have been using these little PCF8563s as they are cheap and very low-power. The Seiko part looks good and is cheaper again. I haven't used batteries with my RTCs for years but rather I use a small supercap. Usually a value of around 0.1F is very small (10mm), soldered to the board, never needs replacing, and keeps the RTC going for at least a few days. As for any equipment that's been off for a few days it's not a problem to reenter the time and date anyway, the fact that it's off power for that long is very unusual. Now with the 8563s I am using smaller supercaps again, these ones are only 0.03F which should be good for 1-2 days which is all that I am interested in. Here's a pic.
The Microchip eeprom/unique ID chip could share the same EEPROM address as the boot EEPROM if you use the old trick of reversing the SCL and SDA lines.
Peter that is a great idea of using a super cap. I haven't done much experimenting in embedded electronics with those. How big and what size would a super cap have to be to keep the RTC on for say a week? Depending on the users application, when it connects to the internet it could possibly get the latest time from a time server. Moreover is there a cost or board space spacing versus what David has drawn up?
This is so interesting to see the collaborative ideas coming together. Are we creating a monster?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The 0.1F (10mm) keeps the RTC going for up to a week but that was on a DS1302 which consumed 300na down to 2V. The PCF8563 consumes 250na down to 1V so I don't expect to have a problem with using the 0.03F (4.8mm) instead. The Seiko part has similar specs to the PCF8563. My design goal is 1-2 days only for the reasons that I mentioned earlier. Some think that the RTC has to keep going for "years" (ok, months) on standby power but that would be ridiculous if that's the way the design is being utilized then. Batteries at some point need replacing and clips take up room plus you need access to change the battery. Way too much angst.
It's also important on these low-power designs to make sure that your pcb is clean of flux around the RTC and especially the crystal. The leakage current from this alone could be more than the standby power of the chip!
Peter Jakacki said...
The Microchip eeprom/unique ID chip could share the same EEPROM address as the boot EEPROM if you use the old trick of reversing the SCL and SDA lines.
If the Prop can read the '5100's MAC address, would this be necessary?
We should try and use common connections. Digilent PMod (1x6 & 2x6) is another common connector being used www.digilentinc.com with a number of add-on boards available. A lot of the FPGA boards are supporting this interface.
It doesn't seem that the chip has a unique MAC address, which is not altogether unusual for many chips I believe. The idea is that you have a unique ID from somewhere and write this into the W5100's MAC address register. But don't quote me on that one, I will have to read the datasheet.
As far I recall from my experimentation with the W5100 it doesn't have a MAC ID. As Peter pointed out, not many of them do. Not having a MAC ID allows product designers to apply the device utilizing their own IDs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
David Carrier (Parallax) said...
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.
Hello,
Does the project have a website or how to collaborate?
I like to help with the things I can, absolutely gratis:
- Testing the program: report bugs and / or fix them.
- Translate to Spanish.
- Send some code that can be useful, idea, etc.
Peter, is right - the PCF8583's are great; I use them on Morpheus (and a couple of upcoming designs).
I got well over one week of retention with a 330uF electrolytic (and no battery) before I powered up the board again, and I am sure it would have lasted a lot longer.
Peter Jakacki said...
The W5100 looks like an interesting device to use. On the subject of RTCs I have been using these little PCF8563s as they are cheap and very low-power. The Seiko part looks good and is cheaper again. I haven't used batteries with my RTCs for years but rather I use a small supercap. Usually a value of around 0.1F is very small (10mm), soldered to the board, never needs replacing, and keeps the RTC going for at least a few days. As for any equipment that's been off for a few days it's not a problem to reenter the time and date anyway, the fact that it's off power for that long is very unusual. Now with the 8563s I am using smaller supercaps again, these ones are only 0.03F which should be good for 1-2 days which is all that I am interested in. Here's a pic.
The Microchip eeprom/unique ID chip could share the same EEPROM address as the boot EEPROM if you use the old trick of reversing the SCL and SDA lines.
Then it would be reasonably easy to use it with 'professional' systems like CA Unicenter and similar stuff.
(Of course, SNMP is a real mess to understand. And creating .MIF files will be a bit of a task... )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Alberto,
Thanks for the heads-up. I fixed the part number and the crystal frequency
he1957,
It will be a development board, but it is also designed to be used by people that just need an embedded web server. There will be a significant number of customers that will only be updating it via the SD card or the network interface, and we don't want them to have to pay thee added costs of the USB circuitry.
If you want to use the USB data logger with it, you can connect the data logger to the auxiliary I/O pins.
Dr_Acula,
I would like to have this board priced under $50. The hard part now is avoiding feature creep. Every dollar in component cost adds several dollars to the final cost. The 1A LDO regulator that we have been using costs less than 23 cents at a quantity of 1000. At the same quantities, the least expensive switching regulator I could find cost 88.16 cents, with an inductor that cost 26.25 cents. The output capacitor had to be much larger, requiring two at 11.44 cents each. With a 5.0 volt input, and a 500 mA current draw, the linear regulator will dissipate 850 mW of power, which can use the PCB itself as a heat sink.
Peter,
I really like the super capacitor idea. It will cost a little bit more for parts, but it will save a lot of labor, and avoid all of the added difficulties of stocking, handling, and shipping a part with batteries. I found a 0.33 farad super capacitor that costs 70.8 cents each for 1000. It is 33.3 cents more than the battery and clip, but it doesn't need any added manufacturing steps like the battery does. It will be charged to just under 3 volts, and the S-35390A clock will work down to a typical voltage of 0.85 volts. The current consumption is typically 300 μA, so the clock will typically run for 1155 hours, which is more than 48 days. I was planning on having the battery on the bottom of the board, so even a vertically mounted super capacitor will take a little more space, but I think it is worth it.
Luis,
Right now the best place to collaborate is on this forum. Since the hardware doesn't even exist yet, there is not much work that can be done on the software. The feedback that I have been getting has been very useful at this stage in the design.
Real PoE is unfortunately expensive. However, "hack" PoE (supplying non-current limited, unregulated voltage) down the wire can be accomplished with a few well placed jumpers to switch the unused pairs into the regulator input.
--jc
Mike Petry said...
Any thought of PoE (Power over Ethernet)? I could see this as a remote probe using the leftover I/O.
PoE would be way, way cool - but I think that is beyond the scope of this product. Maybe there will be a derivation product with PoE for those that want to pay the cost.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I've kept my silence on this thread up to now because I didn't want to come across negative...
Grandmother always said that "if you didn't have something nice to say...."
(Some prompting from Ken this evening made me change my mind convinced me to speak up.)
Devil's advocate perhaps, but why not (other than perhaps some love loss between Parallax and Microchip) move forward from the excellent development which has been done with the ENC28J60?
Several people have really poured blood, sweat, and life into very good spin and hardware solutions for the ENC28J60 solutions, it seems a shame to walk away to something which appears to really just be a different microcontroller with onboard ethernet.
Have we really reached a wall which cannot be leaped without going to WIZnet?
Actually I think the WIZ5100 is an excellent product, and it can get far higher throughput than the ENC28J60 - albeit at the expense of a lot of pins.
I am sure Parallax will be very successful with their WIZ5100 board, it will address the 100BaseT market, and they will sell them by the truckload if they can keep the $50 target price - especially if they get 4 bit SD access working, and use the parallel mode so the Wiz can do 100Mbps with the prop. It will make a great little embedded web server.
Don't worry OBC, I will be bringing out an ENC28J60 based board soon.
Oldbitcollector said...
I've kept my silence on this thread up to now because I didn't want to come across negative...
Grandmother always said that "if you didn't have something nice to say...."
(Some prompting from Ken this evening made me change my mind convinced me to speak up.)
Devil's advocate perhaps, but why not (other than perhaps some love loss between Parallax and Microchip) move forward from the excellent development which has been done with the ENC28J60?
Several people have really poured blood, sweat, and life into very good spin and hardware solutions for the ENC28J60 solutions, it seems a shame to walk away to something which appears to really just be a different microcontroller with onboard ethernet.
Have we really reached a wall which cannot be leaped without going to WIZnet?
I don't think your concerns are negative at all: you pose a legitimate question. But I think it all boils down to cost/benefit. The ENC28J60 quantity one price from DigiKey is $3.80. The W5100 quantity one price from Saelig is $4.22. That's not the best basis of comparison, I know, but it's not a stretch to assume that this small price differential prevails over larger quantities from other sources. But what a difference in features and performance! I don't think the efforts of the Parallax community have been slighted in the least by David's choice of the W5100. The main reason the ENC28J60 has been so attractive thus far is that it's available in a DIP, which makes it more accessible to hobbyist DIYers. But Parallax is not so constrained when developing new products. I really believe that the benefits obtainable from the W5100 far outweigh the extant traction that the ENC28J60 enjoys. It's a forward-looking choice, and I believe David has made the right one.
Is it a problem that there are pull-ups on the RX/TX line? By the expansion connector pull-ups are added, will this cause trouble with using the Prop Plug and downloading?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just out of curiosity, have you looked at the new ENC424J600 and ENC624J600 from Microchip? Sort of big brothers to the ENC28J60. I am sticking with the ENC28J60 in one application just because I'm using the SPI interface, and it is faster on the ENC28J60 (20 Mbps) than on the other two (14 Mbps).
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Timothy D. Swieter said...
Is it a problem that there are pull-ups on the RX/TX line? By the expansion connector pull-ups are added, will this cause trouble with using the Prop Plug and downloading?
No, not at all. What they do is hold the lines in their normal marking state when they're not being driven. It eliminates problems on both ends of the line that an unwanted BREAK might cause. I use them on the Propeller Backpack, in conjunction with the Prop Plug, and the consequences have only been good. Plus, as a side effect, it eliminates unwanted resetting of the Prop when the Prop Plug is plugged in and the USB cable is not (assuming they're 4.7K or less).
Great choice of device! I have one on the bench that I got back in the contest days, but never got the time to do a lot with it. The last thing I did was wire it up and test some of Timothy's initial code - it's still connected the demo board! It's a nice device with a lot to offer. Looking forward to watching this develop - perhaps even contribute at some point!
Paul
David Carrier (Parallax) said...
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:
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 command protocol (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.
Personally, I'm with OBC; the only advantage I see to the WizNet device is the hub RAM savings for not having to implement a software TCP stack. That's significant, but I lean toward having more control of the device rather than faster throughput for which I have no use.
What on earth does a Prop need with 100baseT? With 10baseT it takes less than a millisecond to send a 1.6K packet. BUT the nasty backside of ethernet comms is the timeouts in a normal TCP stack. Lose a packet, and the whole thing locks up on you for seconds. Not milliseconds, seconds. And note that the WizNet TCP stack (like Harrison's ENC28J60 stack) does not handle out of order packets. So if your cool plan is to stream audio, you had better be ready for the dropouts. In fact, despite its fundamental speed ethernet is generally horrible for any kind of low-latency comms; even at the hardware level collisions and retransmit timeouts are part of the specification. Serial comms may use much lower baud rates but when you are doing machine controls you have absolute timing reliability at the sub-millisecond level, so you can use all of the bandwidth. That is not so for ethernet. And don't even get me started on Nagle delays that can't be turned off.
100baseT also means more power and more complicated wiring.
So why do we want ethernet at all? By presenting VERY SMALL pages (think TEXT ONLY) via HTTP we can leverage web browsers as a user interface that doesn't have to be implemented in Hub RAM. Those pages can then be saved on hard drives and printed on winprinters without implementing all that jazz on the Prop. They can be viewed from multiple locations across existing network connections. If the computer's already there it saves the user yet another HMI to learn. All good.
By sending VERY SMALL messages (think messages that fit in a packet) we can get comms ALMOST as good as serial to do machine controls across existing network wiring or the internet. This is particularly neat for prop-to-prop comms since you can use UDP for routing or even raw ethernet packets on a subnet and ignore the TCP cruft. Of course the WizNet does UDP, but so does the ENC28J60 without a lot of code. And with the ENC28J60 you have a lot more control over the low-level timing.
Let me tell you a true story. There is a product called AnyBus-S which is a lot like the WizNet on steroids, intended to network enable embedded devices. I sell a product which has AnyBus-S support for serving webpages, doing raw sockets, and all that jazz. One of my competitors sold six of these in a distant city, with the promise that they could open a raw socket and treat it like a serial port, without running serial cables. We're talking about $20,000 or so worth of equipment. (Incidentally, AnyBus doesn't bother with 100baseT; their products do 10baseT because how much data is a thermometer or a scale going to generate, after all?)
And they couldn't keep it working. The connections would freeze for seconds at a time as the TCP stacks in the AnyBus and PC would time out, and it messed up their operators who were trying to fill boxes and print labels. I came to their attention because I'd done a similar system and made it work. In order to get the latency in this intranet system down to reasonable levels for printing box labels, this is what I had to do:
To send a message from the AnyBus to the PC, I had to issue a send email command. But I couldn't finish the transaction, because that involves several nagle delayed bounces. The very first message from the AnyBus to the fake SMTP server was the destination, which I treated as 64 bytes of random data. Then the fake SMTP server had to then slam the port shut, which tells the AnyBus card to free up the socket IMMEDIATELY.
And in order to send a message from the PC back to the AnyBus, I had to "load a webpage" consisting of some SSI embeds which actually parsed the HTTP URL parameters and inserted them into appropriate variables in the embedded device for further processing. Then, as soon as the AnyBus webserver acknowledges the GET, the fake "browser" has to slam the port shut instead of loading the "webpage" which it never wanted anyway, which tells the AnyBus to free up the socket IMMEDIATELY.
If a packet is lost that socket times out, but it's OK because each side will just allocate another one for the next transaction which will still happen on schedule, instead of waiting and waiting and waiting for the first to time out. Using these theatrics I can get reliable 200 msec latency over a LAN. It's just barely good enough for typing (on a membrane keyboard at least) with echo across the network, or a realtime weight display. I sent the IT guys sample code in VB6 and they integrated it into their application, which saved the deal for the manufacturer we represent and got us that customer's future business.
As for generically getting things ethernet enabled -- I have told our sales guys to listen for two phrases in particular, "We want to get it in the computer" and "we want to get it on the network." If you hear either of those phrases, and the person doesn't have a specific application they want to get the data into, RUN, because they don't know what they want, nothing we do will make them happy, and even if we technically fulfill what they specify it won't be what they want, they will think we ripped them off, and we'll be lucky if they even bother to pay the bill.
Roger, you are absolutely right about the non-deterministic aspects of Ethernet.
Back in the late 80's (or was it early 90's?) I designed a distributed SCADA system running under OS/2. The system was peer to peer, message based, supporting an arbitrary number of HMI's and "kernels" (process control / monitoring daemons) and device interfaces (Modbus, Modbus+, ModbusTCP, Allan Bradley Data Highway+). You could run HMI's, kernels, and utility daemons on the same box - or spread over a network.
Guess what lay under the messaging layer?
A custom UDP based API that essentially was an aggressive low timeout way of sending messages from 1 byte to 64KB in size using UDP, allowing for out of order packet transmission and reception. The API took care of lost packets, retransmissions etc., and if more than a configurable number of packets were not ACK'ed in a configurable period of time, it reported a transmission error to the upper layer. There were no hidden low level delays - which was the primary reason for not using sockets. Later, the system was ported to Windows NT 3.1, etc.
Sure, it could not guarantee delivery in X ms, but it could report if a message was not delivered in X ms.
localroger said...
Personally, I'm with OBC; the only advantage I see to the WizNet device is the hub RAM savings for not having to implement a software TCP stack. That's significant, but I lean toward having more control of the device rather than faster throughput for which I have no use.
What on earth does a Prop need with 100baseT? With 10baseT it takes less than a millisecond to send a 1.6K packet. BUT the nasty backside of ethernet comms is the timeouts in a normal TCP stack. Lose a packet, and the whole thing locks up on you for seconds. Not milliseconds, seconds. And note that the WizNet TCP stack (like Harrison's ENC28J60 stack) does not handle out of order packets. So if your cool plan is to stream audio, you had better be ready for the dropouts. In fact, despite its fundamental speed ethernet is generally horrible for any kind of low-latency comms; even at the hardware level collisions and retransmit timeouts are part of the specification. Serial comms may use much lower baud rates but when you are doing machine controls you have absolute timing reliability at the sub-millisecond level, so you can use all of the bandwidth. That is not so for ethernet. And don't even get me started on Nagle delays that can't be turned off.
100baseT also means more power and more complicated wiring.
So why do we want ethernet at all? By presenting VERY SMALL pages (think TEXT ONLY) via HTTP we can leverage web browsers as a user interface that doesn't have to be implemented in Hub RAM. Those pages can then be saved on hard drives and printed on winprinters without implementing all that jazz on the Prop. They can be viewed from multiple locations across existing network connections. If the computer's already there it saves the user yet another HMI to learn. All good.
By sending VERY SMALL messages (think messages that fit in a packet) we can get comms ALMOST as good as serial to do machine controls across existing network wiring or the internet. This is particularly neat for prop-to-prop comms since you can use UDP for routing or even raw ethernet packets on a subnet and ignore the TCP cruft. Of course the WizNet does UDP, but so does the ENC28J60 without a lot of code. And with the ENC28J60 you have a lot more control over the low-level timing.
Let me tell you a true story. There is a product called AnyBus-S which is a lot like the WizNet on steroids, intended to network enable embedded devices. I sell a product which has AnyBus-S support for serving webpages, doing raw sockets, and all that jazz. One of my competitors sold six of these in a distant city, with the promise that they could open a raw socket and treat it like a serial port, without running serial cables. We're talking about $20,000 or so worth of equipment. (Incidentally, AnyBus doesn't bother with 100baseT; their products do 10baseT because how much data is a thermometer or a scale going to generate, after all?)
And they couldn't keep it working. The connections would freeze for seconds at a time as the TCP stacks in the AnyBus and PC would time out, and it messed up their operators who were trying to fill boxes and print labels. I came to their attention because I'd done a similar system and made it work. In order to get the latency in this intranet system down to reasonable levels for printing box labels, this is what I had to do:
To send a message from the AnyBus to the PC, I had to issue a send email command. But I couldn't finish the transaction, because that involves several nagle delayed bounces. The very first message from the AnyBus to the fake SMTP server was the destination, which I treated as 64 bytes of random data. Then the fake SMTP server had to then slam the port shut, which tells the AnyBus card to free up the socket IMMEDIATELY.
And in order to send a message from the PC back to the AnyBus, I had to "load a webpage" consisting of some SSI embeds which actually parsed the HTTP URL parameters and inserted them into appropriate variables in the embedded device for further processing. Then, as soon as the AnyBus webserver acknowledges the GET, the fake "browser" has to slam the port shut instead of loading the "webpage" which it never wanted anyway, which tells the AnyBus to free up the socket IMMEDIATELY.
If a packet is lost that socket times out, but it's OK because each side will just allocate another one for the next transaction which will still happen on schedule, instead of waiting and waiting and waiting for the first to time out. Using these theatrics I can get reliable 200 msec latency over a LAN. It's just barely good enough for typing (on a membrane keyboard at least) with echo across the network, or a realtime weight display. I sent the IT guys sample code in VB6 and they integrated it into their application, which saved the deal for the manufacturer we represent and got us that customer's future business.
As for generically getting things ethernet enabled -- I have told our sales guys to listen for two phrases in particular, "We want to get it in the computer" and "we want to get it on the network." If you hear either of those phrases, and the person doesn't have a specific application they want to get the data into, RUN, because they don't know what they want, nothing we do will make them happy, and even if we technically fulfill what they specify it won't be what they want, they will think we ripped them off, and we'll be lucky if they even bother to pay the bill.
Comments
Will be a nice & usefull board to play with !!
Please correct the schematic, the real time clock part, it is not a 24LC256, also the xtal should be 38Khz ?, pin names too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
The ability to connect the USB data-logger would be useful; the Web access/error messages could be logged to a USB stick allowing a split/seperation between the SD card (web content) and USB log data.
The components used in this board look much more realistically priced, so hopefully the final board will also be realistically priced.
Interesting comments from Timothy re switchers. I've gone 100% for switchers as I think they save money if the current is more than about 100mA - especially when you add in the cost of a heatsink and/or the cost per square inch of board that is purely dedicated to heatsink area. Caps are the same/similar for both linear and switching, so by way of indicative prices a LM2575T-5 form futurlec is $1.55, a 1N5819 is 14c and an inductor is about $2. So $3.69. A 7805 is ?25c and a heatsink varies depending on how much current you are drawing and the input volts. I'm not sure of the crossover point where it is worthwhile going switcher but I'm guessing it is around 100mA.
I'm looking forward to adding the internet to my ever growing propeller wireless network!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Both +5V and +Vin can be either inputs or outputs. On some daughterboard connectors (e.g. Propeller Backpack), Vin is omitted. The only daughterboard that sources Vin, so far, is the PWR-I/O-DB, and that connection is jumper enabled. The MoBoStamp-pe (schematic in the user docs) has jumpers to select the power source. You could include jumpers to select between +Vin and A23 for that pin. But an even better option might be to port A23 to a separate 3-pin "servo style" connector for things like the Parallax serial LCD display.
Or ... you could combine the best of both worlds like this:
The five-pin header doubles as a 3-pin servo-style connector and a way to jumper either A23 or +Vin (or neither) to the 12-pin expansion connector.
-Phil
The Microchip eeprom/unique ID chip could share the same EEPROM address as the boot EEPROM if you use the old trick of reversing the SCL and SDA lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
This is so interesting to see the collaborative ideas coming together. Are we creating a monster?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It's also important on these low-power designs to make sure that your pcb is clean of flux around the RTC and especially the crystal. The leakage current from this alone could be more than the standby power of the chip!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
-Phil
If you look at my RamBlade thread·http://forums.parallax.com/showthread.php?p=849265 , you will find the connector I use which has a number of connections to various boards shown.
I strongly recommend the use of 0.1" pitch as other connectors are harder to buy. Cables can also be found in old computer equipment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hello,
Does the project have a website or how to collaborate?
I like to help with the things I can, absolutely gratis:
- Testing the program: report bugs and / or fix them.
- Translate to Spanish.
- Send some code that can be useful, idea, etc.
Thank you.
I got well over one week of retention with a 330uF electrolytic (and no battery) before I powered up the board again, and I am sure it would have lasted a lot longer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Then it would be reasonably easy to use it with 'professional' systems like CA Unicenter and similar stuff.
(Of course, SNMP is a real mess to understand. And creating .MIF files will be a bit of a task... )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Thanks for the heads-up. I fixed the part number and the crystal frequency
he1957,
It will be a development board, but it is also designed to be used by people that just need an embedded web server. There will be a significant number of customers that will only be updating it via the SD card or the network interface, and we don't want them to have to pay thee added costs of the USB circuitry.
If you want to use the USB data logger with it, you can connect the data logger to the auxiliary I/O pins.
Dr_Acula,
I would like to have this board priced under $50. The hard part now is avoiding feature creep. Every dollar in component cost adds several dollars to the final cost. The 1A LDO regulator that we have been using costs less than 23 cents at a quantity of 1000. At the same quantities, the least expensive switching regulator I could find cost 88.16 cents, with an inductor that cost 26.25 cents. The output capacitor had to be much larger, requiring two at 11.44 cents each. With a 5.0 volt input, and a 500 mA current draw, the linear regulator will dissipate 850 mW of power, which can use the PCB itself as a heat sink.
Peter,
I really like the super capacitor idea. It will cost a little bit more for parts, but it will save a lot of labor, and avoid all of the added difficulties of stocking, handling, and shipping a part with batteries. I found a 0.33 farad super capacitor that costs 70.8 cents each for 1000. It is 33.3 cents more than the battery and clip, but it doesn't need any added manufacturing steps like the battery does. It will be charged to just under 3 volts, and the S-35390A clock will work down to a typical voltage of 0.85 volts. The current consumption is typically 300 μA, so the clock will typically run for 1155 hours, which is more than 48 days. I was planning on having the battery on the bottom of the board, so even a vertically mounted super capacitor will take a little more space, but I think it is worth it.
Luis,
Right now the best place to collaborate is on this forum. Since the hardware doesn't even exist yet, there is not much work that can be done on the software. The feedback that I have been getting has been very useful at this stage in the design.
— David Carrier
Parallax Inc.
Mike
--jc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
-Phil
Grandmother always said that "if you didn't have something nice to say...."
(Some prompting from Ken this evening made me change my mind convinced me to speak up.)
Devil's advocate perhaps, but why not (other than perhaps some love loss between Parallax and Microchip) move forward from the excellent development which has been done with the ENC28J60?
Several people have really poured blood, sweat, and life into very good spin and hardware solutions for the ENC28J60 solutions, it seems a shame to walk away to something which appears to really just be a different microcontroller with onboard ethernet.
Have we really reached a wall which cannot be leaped without going to WIZnet?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I am sure Parallax will be very successful with their WIZ5100 board, it will address the 100BaseT market, and they will sell them by the truckload if they can keep the $50 target price - especially if they get 4 bit SD access working, and use the parallel mode so the Wiz can do 100Mbps with the prop. It will make a great little embedded web server.
Don't worry OBC, I will be bringing out an ENC28J60 based board soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Bill Henning) : 1/28/2010 5:36:44 AM GMT
I don't think your concerns are negative at all: you pose a legitimate question. But I think it all boils down to cost/benefit. The ENC28J60 quantity one price from DigiKey is $3.80. The W5100 quantity one price from Saelig is $4.22. That's not the best basis of comparison, I know, but it's not a stretch to assume that this small price differential prevails over larger quantities from other sources. But what a difference in features and performance! I don't think the efforts of the Parallax community have been slighted in the least by David's choice of the W5100. The main reason the ENC28J60 has been so attractive thus far is that it's available in a DIP, which makes it more accessible to hobbyist DIYers. But Parallax is not so constrained when developing new products. I really believe that the benefits obtainable from the W5100 far outweigh the extant traction that the ENC28J60 enjoys. It's a forward-looking choice, and I believe David has made the right one.
-Phil
Do you intend to socket the Prop xtal (as on the Proto Board)? I think this would be good for us overclocking freaks.
Is the 24LC256·meant to be 24LC512 ? Should the pullups on SDA & SCL be 10K ?
This should prove to be a great prop based board if the price objective can be achieved.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
-Phil
Great choice of device! I have one on the bench that I got back in the contest days, but never got the time to do a lot with it. The last thing I did was wire it up and test some of Timothy's initial code - it's still connected the demo board! It's a nice device with a lot to offer. Looking forward to watching this develop - perhaps even contribute at some point!
Paul
What on earth does a Prop need with 100baseT? With 10baseT it takes less than a millisecond to send a 1.6K packet. BUT the nasty backside of ethernet comms is the timeouts in a normal TCP stack. Lose a packet, and the whole thing locks up on you for seconds. Not milliseconds, seconds. And note that the WizNet TCP stack (like Harrison's ENC28J60 stack) does not handle out of order packets. So if your cool plan is to stream audio, you had better be ready for the dropouts. In fact, despite its fundamental speed ethernet is generally horrible for any kind of low-latency comms; even at the hardware level collisions and retransmit timeouts are part of the specification. Serial comms may use much lower baud rates but when you are doing machine controls you have absolute timing reliability at the sub-millisecond level, so you can use all of the bandwidth. That is not so for ethernet. And don't even get me started on Nagle delays that can't be turned off.
100baseT also means more power and more complicated wiring.
So why do we want ethernet at all? By presenting VERY SMALL pages (think TEXT ONLY) via HTTP we can leverage web browsers as a user interface that doesn't have to be implemented in Hub RAM. Those pages can then be saved on hard drives and printed on winprinters without implementing all that jazz on the Prop. They can be viewed from multiple locations across existing network connections. If the computer's already there it saves the user yet another HMI to learn. All good.
By sending VERY SMALL messages (think messages that fit in a packet) we can get comms ALMOST as good as serial to do machine controls across existing network wiring or the internet. This is particularly neat for prop-to-prop comms since you can use UDP for routing or even raw ethernet packets on a subnet and ignore the TCP cruft. Of course the WizNet does UDP, but so does the ENC28J60 without a lot of code. And with the ENC28J60 you have a lot more control over the low-level timing.
Let me tell you a true story. There is a product called AnyBus-S which is a lot like the WizNet on steroids, intended to network enable embedded devices. I sell a product which has AnyBus-S support for serving webpages, doing raw sockets, and all that jazz. One of my competitors sold six of these in a distant city, with the promise that they could open a raw socket and treat it like a serial port, without running serial cables. We're talking about $20,000 or so worth of equipment. (Incidentally, AnyBus doesn't bother with 100baseT; their products do 10baseT because how much data is a thermometer or a scale going to generate, after all?)
And they couldn't keep it working. The connections would freeze for seconds at a time as the TCP stacks in the AnyBus and PC would time out, and it messed up their operators who were trying to fill boxes and print labels. I came to their attention because I'd done a similar system and made it work. In order to get the latency in this intranet system down to reasonable levels for printing box labels, this is what I had to do:
To send a message from the AnyBus to the PC, I had to issue a send email command. But I couldn't finish the transaction, because that involves several nagle delayed bounces. The very first message from the AnyBus to the fake SMTP server was the destination, which I treated as 64 bytes of random data. Then the fake SMTP server had to then slam the port shut, which tells the AnyBus card to free up the socket IMMEDIATELY.
And in order to send a message from the PC back to the AnyBus, I had to "load a webpage" consisting of some SSI embeds which actually parsed the HTTP URL parameters and inserted them into appropriate variables in the embedded device for further processing. Then, as soon as the AnyBus webserver acknowledges the GET, the fake "browser" has to slam the port shut instead of loading the "webpage" which it never wanted anyway, which tells the AnyBus to free up the socket IMMEDIATELY.
If a packet is lost that socket times out, but it's OK because each side will just allocate another one for the next transaction which will still happen on schedule, instead of waiting and waiting and waiting for the first to time out. Using these theatrics I can get reliable 200 msec latency over a LAN. It's just barely good enough for typing (on a membrane keyboard at least) with echo across the network, or a realtime weight display. I sent the IT guys sample code in VB6 and they integrated it into their application, which saved the deal for the manufacturer we represent and got us that customer's future business.
As for generically getting things ethernet enabled -- I have told our sales guys to listen for two phrases in particular, "We want to get it in the computer" and "we want to get it on the network." If you hear either of those phrases, and the person doesn't have a specific application they want to get the data into, RUN, because they don't know what they want, nothing we do will make them happy, and even if we technically fulfill what they specify it won't be what they want, they will think we ripped them off, and we'll be lucky if they even bother to pay the bill.
Back in the late 80's (or was it early 90's?) I designed a distributed SCADA system running under OS/2. The system was peer to peer, message based, supporting an arbitrary number of HMI's and "kernels" (process control / monitoring daemons) and device interfaces (Modbus, Modbus+, ModbusTCP, Allan Bradley Data Highway+). You could run HMI's, kernels, and utility daemons on the same box - or spread over a network.
Guess what lay under the messaging layer?
A custom UDP based API that essentially was an aggressive low timeout way of sending messages from 1 byte to 64KB in size using UDP, allowing for out of order packet transmission and reception. The API took care of lost packets, retransmissions etc., and if more than a configurable number of packets were not ACK'ed in a configurable period of time, it reported a transmission error to the upper layer. There were no hidden low level delays - which was the primary reason for not using sockets. Later, the system was ported to Windows NT 3.1, etc.
Sure, it could not guarantee delivery in X ms, but it could report if a message was not delivered in X ms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Bill Henning) : 1/28/2010 6:33:44 PM GMT