Mike,
As others have mentioned, PoE has added costs, and there aren't many people who use it. It wouldn't be worth increasing the costs for everyone for a feature that only a few will use.
OBC and lonesock and localroger,
We first looked at the ENC28J60, but it was only SPI and 10Base-T. From there we found the ENC424J600, which is far more capable. After looking at the W5100, it was hard to decide between it and the ENC424J600. There were a few deciding factors. First, the W5100 only has a slight increase in cost, but a significant increase in functionality. Offloading the TCP/IP stack means that the Propeller will have more resources available for other tasks. Second, more Propeller customers have been using the W5100. Even though there is a useful amount of Propeller code for the ENC28J60, there isn't any for the ENC424J600. Finally, as a company WizNet is a lot easier to work with than Microchip.
Originally I had written off the W5100, because the Propeller is perfectly capable of running its own TCP/IP stack. I had just assumed that the W5100 was going to be significantly more expensive. Based on the capabilities, I was thinking it would be in the $10 price range. You also don't have to use their built-in TCP/IP stack, the W5100 also you create your own packets.
Cluso99,
Weather or not the LEDs are high brightness, the current they are supplied determines their brightness. High brightness LEDs can handle more current without burning out, but at the same current they are essentially the same brightness. (Different LED chemistries do have different efficiencies, but it is not generally related to their current rating.)
Thanks for pointing out the 24LC256. I thought I had changed it. I will update it on the next schematic.
The 4.7k pull-up resistors are within I2C specifications, and Phil Pilgrim requested them for compatibility with the MoBo series.
Timothy,
The pull-up resistors on RX/TX are also by request of Phil Pilgrim for the MoBo series. They do not affect communications with the Prop Plug.
Thanks, David! (I just noticed the updated schematic.) The conformance with the MoBo standard that comes from using A24-A31, with pullups on A28-A31, is totally serendipitous. It couldn't have worked out better. I had to refer back to the MoBo schematic and PBASIC manual to make sure that SDA and SCL not only ended up on the right pins, but in the right order. It's an astonishing bit of luck that they did!
@David Carrier: You also don't have to use their built-in TCP/IP stack, the W5100 also you create your own packets.
Well that's good; sounds like if I develop for the ENC porting to the W should be straightforward, and that could make a useful escape hatch if I run out of RAM.
Also: Finally, as a company WizNet is a lot easier to work with than Microchip.
@Bill Henning: Guess what lay under the messaging layer?
LOL. I know some people who took on a job we refused (the customer had a totally unreasonable time frame). Their programmer, who was still writing the software on site on New Year's Eve, proudly bragged to me that they had gone with modbus TCP throughout. Part of their task requires knocking product off a moving conveyor with a pneumatic arm as it passes by at several feet per second. They made the demo kindasorta work by slowing all the belts down but they're never going to make their throughput goal or eliminate the stuff that gets lost at random, and this is going to end up costing someone about 2 million dollars.
Modbus TCP is not bad, but I would not use it for message passing / everything!
For my design, we got ridiculously good throughput and latency on the _LOCAL_ network, but when someone thought "well, how about we try to control Modicon devices at a remote plant by running the Modbus/TCP daemon there, but the kernel here, over the internet"... you are free to guess how well that worked.
What did work well was running remote HMI's that used the message passing layer.
localroger said...
@Bill Henning: Guess what lay under the messaging layer?
LOL. I know some people who took on a job we refused (the customer had a totally unreasonable time frame). Their programmer, who was still writing the software on site on New Year's Eve, proudly bragged to me that they had gone with modbus TCP throughout. Part of their task requires knocking product off a moving conveyor with a pneumatic arm as it passes by at several feet per second. They made the demo kindasorta work by slowing all the belts down but they're never going to make their throughput goal or eliminate the stuff that gets lost at random, and this is going to end up costing someone about 2 million dollars.
David - thanks for listening to the feedback and directly trying to respond to everyone. Thank you too Phil for pointing out the good side to the pull-ups on the Tx/Rx lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 said...
Cluso99,
Weather or not the LEDs are high brightness, the current they are supplied determines their brightness. High brightness LEDs can handle more current without burning out, but at the same current they are essentially the same brightness. (Different LED chemistries do have different efficiencies, but it is not generally related to their current rating.)
Sorry David, but your statement is incorrect. If you look at the LED current/brightness curves you will see why.
I have been using high and super bright LEDs for years with currents at less than 1mA that are easily bright enough to see indoors. My modems used SMT leds and light pipes with 3K3 resistors and 5V. In fact, I use the onboard 10K pullup on the P24..P28 pins on the Protoboard for·Superbright LEDs. Admittedly they·are not that easy to see in bright daylight indoors. IIRC the blue led is about 10,000mcd.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Bringing up the MAC ID topic once more. It is OK if the IC mentioned isn't in the design, but will the board have enough room to leave a footprint for the IC should a user decide to add one after they bought the device?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Scratch that thought about leaving a place for the Microchip 24AA02E48. I finally did the research on device ID to see if the EEPROM and the MAC ID/EEPROM IC would play together, but it turns out they have the same device ID of 1010. I suppose one could do the trick of swapping the SDA/SCL lines.
Another option would be to use something like the Maxim DS2502-E48 which is a one-wire device. The device could attach to P13 with is the /INT from the W5100. On power-up the Prop could hold the W5100 in reset and then get the data it needs from the DS2502-E48. Once the Prop got the Mac ID it could start the W5100. The DS2502-E48 isn't cheap though, so it would have to be a footprint left for the user to populate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 said the board will have a 64KB eeprom. He can just document a 64 byte block (to leave some spare bytes) for MAC, IP, netmask etc information in the eeprom.
Since Parallax intends to get a MAC block, it could even be pre-programmed during testing with a Parallax MAC address.
Poof, no extra chip needed!
Timothy D. Swieter said...
Scratch that thought about leaving a place for the Microchip 24AA02E48. I finally did the research on device ID to see if the EEPROM and the MAC ID/EEPROM IC would play together, but it turns out they have the same device ID of 1010. I suppose one could do the trick of swapping the SDA/SCL lines.
Another option would be to use something like the Maxim DS2502-E48 which is a one-wire device. The device could attach to P13 with is the /INT from the W5100. On power-up the Prop could hold the W5100 in reset and then get the data it needs from the DS2502-E48. Once the Prop got the Mac ID it could start the W5100. The DS2502-E48 isn't cheap though, so it would have to be a footprint left for the user to populate.
Timothy D. Swieter said...
Scratch that thought about leaving a place for the Microchip 24AA02E48. I finally did the research on device ID to see if the EEPROM and the MAC ID/EEPROM IC would play together, but it turns out they have the same device ID of 1010.
That's okay. The SOIC version has three address lines like a regular EEPROM: A2..A0. As long as one of these is tied high, it won't conflict with the 24LC512, since that one has to be strapped to address 000.
Timothy D. Swieter said...
Scratch that thought about leaving a place for the Microchip 24AA02E48. I finally did the research on device ID to see if the EEPROM and the MAC ID/EEPROM IC would play together, but it turns out they have the same device ID of 1010.
That's okay. The SOIC version has three address lines like a regular EEPROM: A2..A0. As long as one of these is tied high, it won't conflict with the 24LC512, since that one has to be strapped to address 000.
-Phil
Well that's what we all thought but a careful examination of the datasheet (p7) reveals that these pins are not connected, even on the soic version. The swapping of the scl and sda works even if it is a kludge. Can't figure why Microchip even bothers to label the pins then.
I agree, why name the pins?! Heck, why not use them? I am sure there is some good engineering IC design reasoning. Perhaps just a reuse of the silicon from the package.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
OK - lets get back to talking about the software aspect. Here are a list of stepping stones that we as a community could work on prior to the arrival of the product.
*I2C Advance driver - I know there are I2C drivers in the obex, however those drivers don't seem complete to me. For one reason, those drivers just run flat out, I haven't noticed timing in the drivers such that it is limited to the various I2C bus speeds such as 400KHz. Therefore the code could break when used on an over/under clocked IC or when the Prop II comes out. The advance driver would be in ASM with appropriate access routines in SPIN. I picture the ASM loop may be similar to like a graphic engine structure where most of the time the loop is sitting around waiting for a command passed in from the SPIN routine. Then the ASM loop leaps into action. Good idea?
*SPI WIZNET Driver UDP - This area I am a little unsure of. Can there be a generic SPI UDP/TCP driver or should they all be separate? There is work on the forum by others who have made code or attempts that may satisfy these categories. I was thinking we could start an effort to unify the way those drivers are structured and document the drivers. Same variable names, same method of accessing the driver, same layout in ASM/SPIN process with comments on how the interface works. Further resources include the HydraEther Card and perhaps the new Propeller book that can give insight or code towards completing this.
*SPI WizNET Driver TCP - ditto
*8-Bit WizNET Driver UDP - ditto
*8-Bit WizNET Driver TCP - ditto
For implementing all the desired protocols, I was thinking the software would be proven using one of the above drivers and then, if it is appropriate, the software could be distilled to its own one or two cogs including all the WizNET interface. There may be speed advantages to this, however it may mean only one protocol software could run at a time. If the above drivers are designed in such a way with buffers and interfaces so that multiple protocols could be running at the same time that would be a bonus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As an aside, I spent today reverse engineering sdspiqasm from the original fsrw so I could do some reworking on it, and I have got to say there is some seriously clever use of the counters levereging the determinant instruction timing in there.
Would be nice to have PHP support for some nice Dynamic pages from SD card.
Probably a while before anyone ports it to pasm though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"powered by Propeller" domed stickers $1.50 - Find them here
Check out my Design and Technology project for my Higher School Certificate www.ecosureblog.net
I am willing to work on an ART-NET (think DMX512-A over UDP/ethernet) driver for the ethernet module as this has been one of my desires since I bought the W5100 module.
For those that may have not seen the other thread, I threw together a board for mounting a WIZ812MJ and a Parallax uSD Card adapter and a couple other ICs. The purpose is to encourage development of software now while David works on the hardware. I expect to get PCBs by Tuesday or Wednesday next week. I will update my PropNET thread: http://forums.parallax.com/forums/default.aspx?f=25&m=422860
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
* 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
======================================================================
I think the parallex and wiznet solution is the best choice because I'm working for Wiznet in Korea. [noparse]:)[/noparse]
And the S/W spec. is also wonderful !!
I have some knowledge about in the S/W spec. except the SSL/TLS, SSH.
Is there anybody have an experience about these?
Something I didn't realize, but maybe others did, is that with MAC addresses there is such a thing as "Locally Administered". I learned this while reading the January issue of Circuit Cellar and looking up MAC on Wikipedia. en.wikipedia.org/wiki/MAC_address Between locally administered, stealing a MAC ID from old/unused ethernet equipment, getting an EEPROM with MAC ID and Parallax potentially registering for some address space there shouldn't be an qualms on MAC 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
Has Parallax ever considered an ARM based coprocessor for the Propeller?
I started using an ARM on another project and that thing only costs $3-5 even in low quantities.
The only part you need with the ARM to give ethernet is the ethernet socket/magnetics and an SD socket for SD.· File system/TCP are all easily added as software.
Total price would be under $10 in parts.
You can add additional options like USB and LCD by just adding the socket also.
SDRAM can also be added to the ARM cheap for more storage.
For those still interested in starting some software development I have cooked up a Propeller Platform module which uses the WIZ812MJ. Think of this as an effort to spark the software development. The module is based on the latest published schematic. The module could be used with the Propeller Platform or easily attached to any other Propeller development board. Check the thread out here: http://forums.parallax.com/showthread.php?p=882070
My software goal at the moment is to make a well documented, easy to understand SPI driver for the W5100. A key feature of the driver will be the ability to replace the core SPI with the parallel interface code. For those interested in helping with the software, I think the first thing we should do is develop a standard API (function names, parameters, etc) so that anyone making a driver can use that interface so application code can easily change between drivers. What do you think? Perhaps another thread for that topic?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Status bump. This thread is forking a bit. Lets keep this thread alive with the hardware status and progress and review and start another thread for the software. The software thread is located: http://forums.parallax.com/showthread.php?p=892553
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 have updated the schematic, with a few minor changes, and I have added reference designators. I also started a new thread, What would you call a Propeller-based embedded network server?, for recommended names. Please leave name-related posts on that thread and technical posts on this thread.
As for a status update, the schematic has been stable for some time now, and layout is in progress. We have also contracted with Timothy Swieter to work on the firmware. He is creating a high-performance parallel W5100 object, among other firmware functions. We have a PCB prototyping mill, and the parts on order, so that we can test the layout as soon as it is finished. Once the layout is approved, we will build up a small batch to send out to developers and beta testers. They will be able to work with the hardware while we create the documentation and processes to manufacture the final product.
Comments
As others have mentioned, PoE has added costs, and there aren't many people who use it. It wouldn't be worth increasing the costs for everyone for a feature that only a few will use.
OBC and lonesock and localroger,
We first looked at the ENC28J60, but it was only SPI and 10Base-T. From there we found the ENC424J600, which is far more capable. After looking at the W5100, it was hard to decide between it and the ENC424J600. There were a few deciding factors. First, the W5100 only has a slight increase in cost, but a significant increase in functionality. Offloading the TCP/IP stack means that the Propeller will have more resources available for other tasks. Second, more Propeller customers have been using the W5100. Even though there is a useful amount of Propeller code for the ENC28J60, there isn't any for the ENC424J600. Finally, as a company WizNet is a lot easier to work with than Microchip.
Originally I had written off the W5100, because the Propeller is perfectly capable of running its own TCP/IP stack. I had just assumed that the W5100 was going to be significantly more expensive. Based on the capabilities, I was thinking it would be in the $10 price range. You also don't have to use their built-in TCP/IP stack, the W5100 also you create your own packets.
Cluso99,
Weather or not the LEDs are high brightness, the current they are supplied determines their brightness. High brightness LEDs can handle more current without burning out, but at the same current they are essentially the same brightness. (Different LED chemistries do have different efficiencies, but it is not generally related to their current rating.)
Thanks for pointing out the 24LC256. I thought I had changed it. I will update it on the next schematic.
The 4.7k pull-up resistors are within I2C specifications, and Phil Pilgrim requested them for compatibility with the MoBo series.
Timothy,
The pull-up resistors on RX/TX are also by request of Phil Pilgrim for the MoBo series. They do not affect communications with the Prop Plug.
— David Carrier
Parallax Inc.
-Phil
Well that's good; sounds like if I develop for the ENC porting to the W should be straightforward, and that could make a useful escape hatch if I run out of RAM.
Also: Finally, as a company WizNet is a lot easier to work with than Microchip.
I totally understand this.
LOL. I know some people who took on a job we refused (the customer had a totally unreasonable time frame). Their programmer, who was still writing the software on site on New Year's Eve, proudly bragged to me that they had gone with modbus TCP throughout. Part of their task requires knocking product off a moving conveyor with a pneumatic arm as it passes by at several feet per second. They made the demo kindasorta work by slowing all the belts down but they're never going to make their throughput goal or eliminate the stuff that gets lost at random, and this is going to end up costing someone about 2 million dollars.
Modbus TCP is not bad, but I would not use it for message passing / everything!
For my design, we got ridiculously good throughput and latency on the _LOCAL_ network, but when someone thought "well, how about we try to control Modicon devices at a remote plant by running the Modbus/TCP daemon there, but the kernel here, over the internet"... you are free to guess how well that worked.
What did work well was running remote HMI's that used the message passing layer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 have been using high and super bright LEDs for years with currents at less than 1mA that are easily bright enough to see indoors. My modems used SMT leds and light pipes with 3K3 resistors and 5V. In fact, I use the onboard 10K pullup on the P24..P28 pins on the Protoboard for·Superbright LEDs. Admittedly they·are not that easy to see in bright daylight indoors. IIRC the blue led is about 10,000mcd.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Another option would be to use something like the Maxim DS2502-E48 which is a one-wire device. The device could attach to P13 with is the /INT from the W5100. On power-up the Prop could hold the W5100 in reset and then get the data it needs from the DS2502-E48. Once the Prop got the Mac ID it could start the W5100. The DS2502-E48 isn't cheap though, so it would have to be a footprint left for the user to populate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 said the board will have a 64KB eeprom. He can just document a 64 byte block (to leave some spare bytes) for MAC, IP, netmask etc information in the eeprom.
Since Parallax intends to get a MAC block, it could even be pre-programmed during testing with a Parallax MAC address.
Poof, no extra chip needed!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
-Phil
Well that's what we all thought but a careful examination of the datasheet (p7) reveals that these pins are not connected, even on the soic version. The swapping of the scl and sda works even if it is a kludge. Can't figure why Microchip even bothers to label the pins then.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
*I2C Advance driver - I know there are I2C drivers in the obex, however those drivers don't seem complete to me. For one reason, those drivers just run flat out, I haven't noticed timing in the drivers such that it is limited to the various I2C bus speeds such as 400KHz. Therefore the code could break when used on an over/under clocked IC or when the Prop II comes out. The advance driver would be in ASM with appropriate access routines in SPIN. I picture the ASM loop may be similar to like a graphic engine structure where most of the time the loop is sitting around waiting for a command passed in from the SPIN routine. Then the ASM loop leaps into action. Good idea?
*SPI WIZNET Driver UDP - This area I am a little unsure of. Can there be a generic SPI UDP/TCP driver or should they all be separate? There is work on the forum by others who have made code or attempts that may satisfy these categories. I was thinking we could start an effort to unify the way those drivers are structured and document the drivers. Same variable names, same method of accessing the driver, same layout in ASM/SPIN process with comments on how the interface works. Further resources include the HydraEther Card and perhaps the new Propeller book that can give insight or code towards completing this.
*SPI WizNET Driver TCP - ditto
*8-Bit WizNET Driver UDP - ditto
*8-Bit WizNET Driver TCP - ditto
For implementing all the desired protocols, I was thinking the software would be proven using one of the above drivers and then, if it is appropriate, the software could be distilled to its own one or two cogs including all the WizNET interface. There may be speed advantages to this, however it may mean only one protocol software could run at a time. If the above drivers are designed in such a way with buffers and interfaces so that multiple protocols could be running at the same time that would be a bonus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Probably a while before anyone ports it to pasm though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"powered by Propeller" domed stickers $1.50 - Find them here
Check out my Design and Technology project for my Higher School Certificate www.ecosureblog.net
For those that may have not seen the other thread, I threw together a board for mounting a WIZ812MJ and a Parallax uSD Card adapter and a couple other ICs. The purpose is to encourage development of software now while David works on the hardware. I expect to get PCBs by Tuesday or Wednesday next week. I will update my PropNET thread: http://forums.parallax.com/forums/default.aspx?f=25&m=422860
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
* 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
======================================================================
I think the parallex and wiznet solution is the best choice because I'm working for Wiznet in Korea. [noparse]:)[/noparse]
And the S/W spec. is also wonderful !!
I have some knowledge about in the S/W spec. except the SSL/TLS, SSH.
Is there anybody have an experience about these?
JB, Kim
Post Edited (JB Kim) : 2/3/2010 10:50:30 AM GMT
I could build something that works like full duplex serial but sends I2C data instead of serial data.
It would be easy to have that run at 400KHZ in asm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 started using an ARM on another project and that thing only costs $3-5 even in low quantities.
The only part you need with the ARM to give ethernet is the ethernet socket/magnetics and an SD socket for SD.· File system/TCP are all easily added as software.
Total price would be under $10 in parts.
You can add additional options like USB and LCD by just adding the socket also.
SDRAM can also be added to the ARM cheap for more storage.
I wouldnt go there http://forums.parallax.com/forums/emoticons/nono.gif , you will be excommunicated by the clergy.
Joan of Arc ( aka Leon) was seriously flamed for his religious beliefs (Xmos)
http://forums.parallax.com/forums/emoticons/tongue.gif
Mike
I think Leon has no problem, it is an open person, realistic.
The fullspeceng idea is good but Parallax not going to like. Although WIZNet really is another microcontroller with embedded Ethernet.
David - how goes the design? What is the latest?
For those still interested in starting some software development I have cooked up a Propeller Platform module which uses the WIZ812MJ. Think of this as an effort to spark the software development. The module is based on the latest published schematic. The module could be used with the Propeller Platform or easily attached to any other Propeller development board. Check the thread out here: http://forums.parallax.com/showthread.php?p=882070
My software goal at the moment is to make a well documented, easy to understand SPI driver for the W5100. A key feature of the driver will be the ability to replace the core SPI with the parallel interface code. For those interested in helping with the software, I think the first thing we should do is develop a standard API (function names, parameters, etc) so that anyone making a driver can use that interface so application code can easily change between drivers. What do you think? Perhaps another thread for that topic?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As for a status update, the schematic has been stable for some time now, and layout is in progress. We have also contracted with Timothy Swieter to work on the firmware. He is creating a high-performance parallel W5100 object, among other firmware functions. We have a PCB prototyping mill, and the parts on order, so that we can test the layout as soon as it is finished. Once the layout is approved, we will build up a small batch to send out to developers and beta testers. They will be able to work with the hardware while we create the documentation and processes to manufacture the final product.
— David Carrier
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New ICON coming, gotta wait for the INK to heal, now we have colour!
Post Edited (Yendor) : 4/26/2010 9:48:23 AM GMT