Brief update: A couple PropNET PCBs are out in the wild now. Gadget Gangster is working on a providing kits and I need to find time to review some info from Nick to ensure we got everything correctly. I spent a brief amount of time last night trying to make my SPI driver faster based on the idea of using the COG counters. I had some progress, but not there yet. When I dropped in the W5100 counter example that DynamoBen did I found that data wasn't reading back properly. I will need to investigate with a scope once I get a moment.
Software plan:
-get SPI driver core working as fast as possible.
-fork the code and start a Parallel/indirect version
-get the indirect version working
-start adding commands/processes for accessing sockets and connections, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
This evening I got to spend a little more time with the counters and my logic analyzer and got the fast ASM counter serial code working. I know have the W5100 driver operating as fast as it can, which is probably similar to what DynamoBen has done already. I need to go through the process myself because there are several other projects where I need to use the fast counter/SPI/serial method and therefore I needed to learn it. The code is documented for others that want to learn this method.
I attached another basic demo of setting the addresses in the W5100. This demo is using the fast version of the SPI/counter method. As reference, the previous version, the slow version, took ~8.17uS to write and ~11.36uS to read (my slow coding!). The counter version takes ~3.36uS to write and ~3.55uS to read!! That is a large increase. These measurements were made from the dropping of the SCS signal to the rising of the signal for a 32-bit packet.
The next step I need to is to add more functions in both SPIN and ASM for operating the W5100. Once I get a bit more functionality into the ASM portion I will fork the code and develop the indirect/parallel driver. The core code will stay the same, it will only be the calls to the clocking of data that will change.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
PCBs are still available through Brilldea if you would like to get the hardware and test the drivers and code or contribute to programming www.brilldea.com/product_PropNET.html
Gadget Gangster will be selling kits soon.
I've posted a rough schematic on the Brilldea product page. The schematic closely follows the schematic for the Propeller Web Server that Parallax is working on
This weekend I hope to return to working on the W5100 SPI ASM drivers. It was two weeks ago when I last touch them, and right when I stopped I was getting the UDP to work and needed to finish testing and creating a demo for that. Then I can release that and get feedback.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 Brilldea W5100 driver now has the capability to send and receive UDP packets on any socket. The UDP rx/tx routines are a combination of SPIN/ASM. At some point it could be moved to ASM, but I am watching the size of the ASM routine and wanted to at least get the basic functions working in teh driver first before adding more to ASM or doing any optimizing. I attached demo code for a simple echoing of UDP data. The program receives data on the 5000 port and then turns it around and immediately sends it out.
I've been sending test packets with the UDP Test Tool 2.5 by SimpleComTools. This is a free program, you just have to provide your e-mail address to get the links for the download. I've also been using WireShark to review packet data and timing.
I found one hitch that I am not sure if it is the UDP Test Tool or a WIZnet limitation, but I was only able to send a UDP packet with 1472 bytes of payload data. I don't think this is a limitation of the driver I wrote, but if someone sees that it is please let me know.
How about some stats? I sent a UDP packet with 1472 bytes of data from my laptop via wifi to a router, via a cable, to the PropNET and then back out over the cable, to the router and over wifi to my laptop. According to WireShark delta time from previously captured frame (the outgoing frame to the incoming frame) was 18.61ms. That is to say the round trip time was 18.67ms. Of course this time depends on network traffic and the like, but I think it is safe to say that packets are processed fast.
I should conduct some test to determine how fast packets are processed in the Prop. The packet data is read in via ASM, so I imagine that it is fast, but I should get some numbers. Maybe I should toggle a pin at packet start/stop, what do you think?
I've conducted tests on different sockets and also conducted tests with varying size packets and buffer rollovers. So far things look OK, but again if someone else can test and play with it let me know so I can fix any bugs found.
Next up is some sort of UDP demo such as DHCP or NTP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 - as mentioned in another thread I am setting my UDP demo aside for the moment and moving on the real goal which is getting the TCP portion working.
Attached is another snapshot of my development with the initial portions of the TCP coded. Again it is a mix of ASM/SPIN and eventually may all be ASM. If anyone out there is testing the code let me know if you find problems. In the demo there is a sample TCP client and a sample TCP server. Very simple, very crude.
Next step is to review the overall code and adjust add any further functions and then review what should/shouldn't be in ASM for speed. There is probably more functions to be added since this is generic driver and I want to include lots of options.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
This weekend I hope to work on the indirect driver and do some speed testing to compare the indirect version with the SPI version. If anyone has any thoughts on how best to benchmark the speed testing please feel free to throw them out.
Also there are a few kits over at Gadget Gangster for the PropNET module. All you have to do is add a WIZnet module and a uSD module (if you want that). Otherwise I think Nick has most of the parts there. Check it out: www.gadgetgangster.com/find-a-project/56?projectnum=286 Thanks Nick for doing this!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
I spent some time working on the indirect driver and debugging the code parts I wrote.
The latest version, which you will find in the attachements, is now able to communicate with the W5100 chip via indirect bus mode.
While testing this version, I was able to:
- set the MAC, IP address, Gateway and Subnet
- read the MAC, IP address, Gateway and Subnet from the chip
- open a TCP socket
- listen on a port
and recognize that a TCP connection had been established
Only reading data with the rxTCP function does not seem to work.
Has someone tried the SPI driver yet? I would like to now whether this is a general problem or if it is caused by the code changes I made.
Now, something different:
Is there a way to make the following code even faster (assuming that the output pins are not connected in ascending order)?
I was able to reduce the number of instructions from 24 to 16 by eliminating the bitmask variable, which had to be shifted after each bit comparison. Less than 16 would be even better
test t2, #%0000_0001 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D0mask ' Set data 0 pin to the value of the current bit
test t2, #%0000_0010 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D1mask ' Set data 1 pin to the value of the current bit
test t2, #%0000_0100 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D2mask ' Set data 2 pin to the value of the current bit
test t2, #%0000_1000 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D3mask ' Set data 3 pin to the value of the current bit
test t2, #%0001_0000 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D4mask ' Set data 4 pin to the value of the current bit
test t2, #%0010_0000 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D5mask ' Set data 5 pin to the value of the current bit
test t2, #%0100_0000 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D6mask ' Set data 6 pin to the value of the current bit
test t2, #%1000_0000 wc ' Pull current bit out of t2 and put it on wc
muxc outa, D7mask ' Set data 7 pin to the value of the current bit
Oh dear.
I wanted to publish a new version of the driver this weekend and now my computer is broken:
Last thing I heard was a harddisk powering down.
Now it's going to be a busy weekend checking all my harddisks one by one and the power supply
Patrick1ab said...
Oh dear.
I wanted to publish a new version of the driver this weekend and now my computer is broken:
Last thing I heard was a harddisk powering down.
Now it's going to be a busy weekend checking all my harddisks one by one and the power supply
I offer my condolence. I hope your backups are recent and working!
This reminds me: time to do a full HD backup again.
Okay, after hours of data recovery, search for the broken harddisk (as it turned out: a 12 year old SCSI) and a defective y power cable (which temporarily prevented my CPU Fan control from working ), I'm finally back online.
Here is the new driver version, which now uses a data basepin and ascending order data pins.
If I did not make a mistake in my calculations, these are the speeds the PASM part of the driver should be able to provide:
(Please note, that address calculation and refreshing the data buffer has not been considered)
I want to try out your driver. Am I correct in assuming that your latest version in your last post is working? and can send and receive TCP packets? In order for me to try out your driver, I had to have a PCB made, is this schematic good for use of your indirect W5100 mode driver? Just wanted to make sure, even though you told me last post what to pull down and pull up.
as far as I can see your schematic looks good, except for the following things:
- There is a connection with no voltage description on the right side (should be Vdd I guess)
- and you have to take care of your /Reset pin:
At the moment you are just pulling it to low, which will keep the chip in reset all the time.
Either you have to spend a Propeller pin to switch it to high after some time or you could make a slight change to your schematic:
10 uF capacitor from Vss to /Reset and a 10k resistor from /Reset to Vdd
While the capacitor is discharged, it will behave like a short circuit. So the chip will be reset on power up.
When the capacitor is fully charged, it will behave like open clamps. So 3,3V are applied to /Reset and the chip will come out of reset.
I have to tell you that there is one weakness of this circuit I proposed: If the time between power off and power on is too short (a second for example), the capacitor will not have enough time to discharge. So the chip won't reset the next time you switch it on. This is a reason this circuit should not be used in commercial products.
edlikestoboogie said...
Am I correct in assuming that your latest version in your last post is working? and can send and receive TCP packets?
This is correct. Although you have to take care of several things at the moment:
- Add this function to the driver:
'***************************************
PUB SocketTCPdisconnect(_socket) | temp0
'***************************************
'If the ASM cog is running, execute the command
if (W5100flags & _Flag_ASMstarted)
'Tell the W5100 to disconnect the particular socket
temp0 := _DISCON
writeSPI(true, (_S0_CR + (_socket * $0100)), @temp0, 1)
It should be used when the requested data has been sent, since SocketClose won't send a FIN.
- Your receive buffer should be 2048 bytes and the transmission buffer should be less than 2048 bytes.
- and don't be too disappointed in terms of speed. At the moment it is dead slow (5KByte/s) and there is still a lot to be done to make it much faster.
- added the "SetSocketMemory" function to assign memory to the sockets (if it's not called default is 2K each socket)
!Please note: since this is still experimental, you will have to change the masks in the txTCP/rxTCP procedures manually; look for "_TX_expmask"/"_RX_expmask"
and change it to "_TX_mask"/"_RX_mask" if you like to use 2K buffers each or you could also modify the "_TX_expmask"/"_RX_expmask" constants. Be sure that the mask always corresponds to the socket memory you assigned! (at the moment the masks are set to 1K receive buffer and 8K transmit buffer)
- added support for the address auto increment functionality of the W5100 chip
just set the last parameter of "startINDIRECT" to true if you want to use it or false if not
I have also done some new speed tests (downloading a file from sd card):
txTCP with 8K buffer; no address auto increment @ 80MHz clock: 307 KBytes / s
txTCP with 8K buffer; with address auto increment @ 80MHz clock: 511 KBytes / s
I was also able to stream a divx video, even without address auto increment.
I am finishing my PCB layout, and I am a bit confused on how I should place the 6 decoupling capacitors for the 3.3V supply on the W5100. The reference schematics I've seen for the W5100 all have five 0.1uF capacitors, and one 4.7 uF. But I only see 3 supply pins for 3.3V.... Where do I place the other two 0.1 uF caps? and where should I place the 4.7uF cap?
Any help would be appreciated. I attached my current layout with the 3.3V trace highlighted.
I'm back to Singapore. In the next week or so I hope to get back into working on the indirect driver software. Thanks for hanging in there everyone and thanks Patrick1ab for forging ahead and tackling the driver tasks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
OK - I'm back!! Lets make the Propeller and W5100 speed burn!!
Last weekend and this weekend I have been working on the W5100 indirect driver. I had hit a brick wall with the W5100 documentation. I think it was some of the same problems that Patrick1ab experienced. After a couple of PMs he clued me in on what my problems were - it had to deal with the sequencing of the /RD, /WR and /CS. I was thinking that the changing of the /RD or /WR happened after the /CS, but Patrick1ab showed that that logic is wrong according to the values on the table with the timing diagram.
Patrick1ab's code has the /RD or /WR change before the /CS. I had a EUREKA moment last week. Why do they have to change before, why not at the same time? After all the W5100 data sheet was simply saying don't change /RD or /WR more than one nano-second after /CS - so they change at the "same time". I'll post the code soon, but basically it is that there is a RDCS mask and a WRCS mask which makes the /RD or /WR line low at the same time as /CS.
I did some speed testing with the latest driver. We should standardize a speed test so that we can compare drivers and optimization. My test consisted of a program that initialized the W5100 addresses and then waits for a UDP packet. The Prop/W5100 receive the packet and then echo it back. I have a logic analyzer setup on a couple of the data pins of the W5100 as well as the /RD, /WR, A0, A1 and /CS. I set up markers in the analyzer from the first /CS fall on setting the A0/A1 to read a data register to the rise of the /CS on the last bit of the last byte. Then I sent a 1000 byte packet to the W5100.
Reading and writing were about the same speed. The Prop consumed the 1000 byte packet from the W5100 in 0.60ms! Writing was the just slightly longer at 0.601ms. I did a couple runs and got similar results.
Next I tried to hookup Patrick1ab driver, but the code isn't initializing the UDP port. It is getting late in my day, so I won't troubleshoot if for now.
I have some more work on a demo for the drivers and more cleanup of the code. I also noticed that the my driver is failing with larger packets over 1200 bytes so I need to find this problem. I recall this problem from before, I thought I fixed it, must not have.
@Patrick1ab - can you post demo code on how you did your test or try what I did above to compare results? I'm curious. We should probably have a test that works over a couple seconds, because if you multiple out my one-shot timing values it is an unrealistic theoretical speed value.
TDS: edited text for better reading.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Post Edited (Timothy D. Swieter) : 6/13/2010 12:24:36 AM GMT
I did these tests using a modified web server program, which was originally designed for the ENC28J60 chip.
I added a copy of this program to the attachments, but I'm not sure if it works, because I tried to fix a bug recently and had no chance to test it yet.
The bug I tried to fix occured when the client side canceled/aborted the file transmission. The web server didn't go back to "listen" mode in this case, so it was completely blocked.
I tried to fix it by adding this
while web.SocketTCPestablished(0)==true
to the data sending loop at the bottom of the main program.
It should work, but as I said, it's untested.
There is another bug which may not occur while using this web server in a LAN, but if you like to access it from the internet it appears:
If no file name is specified in the url, the server should send back a list of files.
While accessing the server from the internet this will lead to a timeout error on the client side.
Edit: After a first test it seems that I have eliminated the first bug, but created several new bugs.
I checked with Fiddler and saw that the server always returned "HTTP/1.0 501 Not Implemented" (most likely due to a incomplete header).
Adding a pause time of several ms to the beginning of "webServerThread" solves this problem.
Another problem turned up because the "receivewebBuffer" wasn't initialized. I fixed this too.
Post Edited (Patrick1ab) : 6/13/2010 12:06:51 PM GMT
Patrick - The test in May was your driver. The test you just did today was your driver modified or my indirect driver as provided?
Test: May 6
txTCP with 8K buffer; no address auto increment @ 80MHz clock: 307 KBytes / s
txTCP with 8K buffer; with address auto increment @ 80MHz clock: 511 KBytes / s
Test: June 13
470 kBytes/s @ 80 MHz with 2K TX memory
543 kBytes/s @ 80 MHz with 8K TX memory
I assume these tests were the same (mostly with the exception of auto-increment). Why is there such a large change in speed with a larger buffer? I can understand some improvement because the code doesn't jump around as much, is that the only reason for improvements?
Is the test testing both reading and writing or mostly writing from the Prop to the W5100? I think reading from the W5100 to the Prop would be fast. I need to count instructions/cycles and see if there are any other improvements in the writing from the Prop to the W5100.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Timothy D. Swieter said...
The test you just did today was your driver modified or my indirect driver as provided?
I tested this with your driver, but added some procedures from my version (see my PM): str, dec, SetSocketMemory, SocketTCPdisconnect
Timothy D. Swieter said...
Why is there such a large change in speed with a larger buffer? I can understand some improvement because the code doesn't jump around as much, is that the only reason for improvements?
I think this is exactly the reason. In particular the address calculation is consuming most of the processing power.
When I made my first tests a few months ago without address auto increment and only a 2K buffer, I got speeds you would only expect from a 56K modem.
Timothy D. Swieter said...
Is the test testing both reading and writing or mostly writing from the Prop to the W5100? I think reading from the W5100 to the Prop would be fast. I need to count instructions/cycles and see if there are any other improvements in the writing from the Prop to the W5100.
It's mostly writing from the Prop to the W5100, because I download a 350MB video file from a sd card and save it to my computer.
Thanks for the quick response! One of the things I am considering is writing the tx/rx UDP/TCP routines in ASM. This would of course speed things up! Question is the space and my time to do this. I might save that task for a rainy day.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Timothy D. Swieter said...
Thanks for the quick response! One of the things I am considering is writing the tx/rx UDP/TCP routines in ASM. This would of course speed things up! Question is the space and my time to do this. I might save that task for a rainy day.
Write 'em in BASIC! <g,d,r>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Sorry to be so delayed in responding. I haven't had the "processing power" to handle all the items I am working on as well as keeping up with PropBasic. Tell me more about what you mean? PropBasic compiles to ASM? Can a PropBasic routine be launched in another cog. What advantages to using PropBasic for this application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Timothy, · Yes PropBasic compiles to straight PASM. I've even written VGA video drivers in pure PropBasic. It is that fast. · PropBasic can also generate LMM code by simply appending "LMM" to the PROGRAM command. LMM is about 5 times slower than PASM.
· Routines in other cogs are called TASKs. Each task can be either straight PASM or LMM.
· PropBasic code is MUCH easier to maintain than PASM because it handles alot of the little details for you.
· I'd be willing (more than willing) to assist you. Just let me know.
P.S. PropBasic runs·under BST, plus it is multiplatform.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life: · 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
Thanks Bean for the response. Using PropBasic sounds tempting. I have two W5100 drivers already coded in ASM, and both are pretty fast. I have my doubts if PropBasic could compile to be as fast.....however I don't know for sure until we try it.
Beyond speed in the W5100 driver would be overall code speed, readability and maintainabiliy for the whole Spinneret project. The advantage that many things would be faster if it was all in PropBasic would be great.
Any superb SDcard driver in PropBasic yet that can be launched as a task? This is one area I was hoping to utilize other SPIN/ASM objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Bean - there is a W5100 SPI and Indirect driver in the OBEX. There is also a demo SPIN file for a UDP demo. I am working on some additions to the drivers as well as TCP demos.
Personally I could probably trade off speed in just the W5100 driver if I also gain speed in the rest of the application like HTML parsing or protocol handling, etc. The audience for the Spinneret will of course want speed, speed, speed in every portion of the application as possible. I'd have to make the call to commit soon to which language to use before I code too much more in one direction.
The lack of SD support could make the choice though. This isn't something I should be coding, there are far more experienced people out there in this area. The SD card is a key feature of the Spinneret.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51 www.tdswieter.com
Comments
Software plan:
-get SPI driver core working as fast as possible.
-fork the code and start a Parallel/indirect version
-get the indirect version working
-start adding commands/processes for accessing sockets and connections, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 attached another basic demo of setting the addresses in the W5100. This demo is using the fast version of the SPI/counter method. As reference, the previous version, the slow version, took ~8.17uS to write and ~11.36uS to read (my slow coding!). The counter version takes ~3.36uS to write and ~3.55uS to read!! That is a large increase. These measurements were made from the dropping of the SCS signal to the rising of the signal for a 32-bit packet.
The next step I need to is to add more functions in both SPIN and ASM for operating the W5100. Once I get a bit more functionality into the ASM portion I will fork the code and develop the indirect/parallel driver. The core code will stay the same, it will only be the calls to the clocking of data that will change.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
- PCBs are still available through Brilldea if you would like to get the hardware and test the drivers and code or contribute to programming www.brilldea.com/product_PropNET.html
- Gadget Gangster will be selling kits soon.
- I've posted a rough schematic on the Brilldea product page. The schematic closely follows the schematic for the Propeller Web Server that Parallax is working on
- This weekend I hope to return to working on the W5100 SPI ASM drivers. It was two weeks ago when I last touch them, and right when I stopped I was getting the UDP to work and needed to finish testing and creating a demo for that. Then I can release that and get feedback.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔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 been sending test packets with the UDP Test Tool 2.5 by SimpleComTools. This is a free program, you just have to provide your e-mail address to get the links for the download. I've also been using WireShark to review packet data and timing.
I found one hitch that I am not sure if it is the UDP Test Tool or a WIZnet limitation, but I was only able to send a UDP packet with 1472 bytes of payload data. I don't think this is a limitation of the driver I wrote, but if someone sees that it is please let me know.
How about some stats? I sent a UDP packet with 1472 bytes of data from my laptop via wifi to a router, via a cable, to the PropNET and then back out over the cable, to the router and over wifi to my laptop. According to WireShark delta time from previously captured frame (the outgoing frame to the incoming frame) was 18.61ms. That is to say the round trip time was 18.67ms. Of course this time depends on network traffic and the like, but I think it is safe to say that packets are processed fast.
I should conduct some test to determine how fast packets are processed in the Prop. The packet data is read in via ASM, so I imagine that it is fast, but I should get some numbers. Maybe I should toggle a pin at packet start/stop, what do you think?
I've conducted tests on different sockets and also conducted tests with varying size packets and buffer rollovers. So far things look OK, but again if someone else can test and play with it let me know so I can fix any bugs found.
Next up is some sort of UDP demo such as DHCP or NTP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Attached is another snapshot of my development with the initial portions of the TCP coded. Again it is a mix of ASM/SPIN and eventually may all be ASM. If anyone out there is testing the code let me know if you find problems. In the demo there is a sample TCP client and a sample TCP server. Very simple, very crude.
Next step is to review the overall code and adjust add any further functions and then review what should/shouldn't be in ASM for speed. There is probably more functions to be added since this is generic driver and I want to include lots of options.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
This weekend I hope to work on the indirect driver and do some speed testing to compare the indirect version with the SPI version. If anyone has any thoughts on how best to benchmark the speed testing please feel free to throw them out.
Also there are a few kits over at Gadget Gangster for the PropNET module. All you have to do is add a WIZnet module and a uSD module (if you want that). Otherwise I think Nick has most of the parts there. Check it out: www.gadgetgangster.com/find-a-project/56?projectnum=286 Thanks Nick for doing this!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
I spent some time working on the indirect driver and debugging the code parts I wrote.
The latest version, which you will find in the attachements, is now able to communicate with the W5100 chip via indirect bus mode.
While testing this version, I was able to:
- set the MAC, IP address, Gateway and Subnet
- read the MAC, IP address, Gateway and Subnet from the chip
- open a TCP socket
- listen on a port
and recognize that a TCP connection had been established
Only reading data with the rxTCP function does not seem to work.
Has someone tried the SPI driver yet? I would like to now whether this is a general problem or if it is caused by the code changes I made.
Now, something different:
Is there a way to make the following code even faster (assuming that the output pins are not connected in ascending order)?
I was able to reduce the number of instructions from 24 to 16 by eliminating the bitmask variable, which had to be shifted after each bit comparison. Less than 16 would be even better
test t2, #%0000_0001 wc ' Pull current bit out of t2 and put it on wc muxc outa, D0mask ' Set data 0 pin to the value of the current bit test t2, #%0000_0010 wc ' Pull current bit out of t2 and put it on wc muxc outa, D1mask ' Set data 1 pin to the value of the current bit test t2, #%0000_0100 wc ' Pull current bit out of t2 and put it on wc muxc outa, D2mask ' Set data 2 pin to the value of the current bit test t2, #%0000_1000 wc ' Pull current bit out of t2 and put it on wc muxc outa, D3mask ' Set data 3 pin to the value of the current bit test t2, #%0001_0000 wc ' Pull current bit out of t2 and put it on wc muxc outa, D4mask ' Set data 4 pin to the value of the current bit test t2, #%0010_0000 wc ' Pull current bit out of t2 and put it on wc muxc outa, D5mask ' Set data 5 pin to the value of the current bit test t2, #%0100_0000 wc ' Pull current bit out of t2 and put it on wc muxc outa, D6mask ' Set data 6 pin to the value of the current bit test t2, #%1000_0000 wc ' Pull current bit out of t2 and put it on wc muxc outa, D7mask ' Set data 7 pin to the value of the current bitI wanted to publish a new version of the driver this weekend and now my computer is broken:
Last thing I heard was a harddisk powering down.
Now it's going to be a busy weekend checking all my harddisks one by one and the power supply
I offer my condolence. I hope your backups are recent and working!
This reminds me: time to do a full HD backup again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Here is the new driver version, which now uses a data basepin and ascending order data pins.
If I did not make a mistake in my calculations, these are the speeds the PASM part of the driver should be able to provide:
(Please note, that address calculation and refreshing the data buffer has not been considered)
write (with address): 32 PASM instructions / payload byte => 610 kByte / s @80 MHz clock
write (dataonly): 10 PASM instructions / payload byte => 1950 kByte / s @80 MHz clock
write (with address): 32 PASM instructions / payload byte => 760 kByte / s @100 MHz clock
write (dataonly): 10 PASM instructions / payload byte => 2440 kByte / s @100 MHz clock
read (with address): 35 PASM instructions / payload byte => 560 kByte / s @80 MHz clock
read (data only): 12 PASM instructions /payload byte => 1630 kByte / s @80 MHz clock
read (with address): 35 PASM instructions / payload byte => 700 kByte / s @100 MHz clock
read (data only): 12 PASM instructions /payload byte => 2030 kByte / s @100 MHz clock
I want to try out your driver. Am I correct in assuming that your latest version in your last post is working? and can send and receive TCP packets? In order for me to try out your driver, I had to have a PCB made, is this schematic good for use of your indirect W5100 mode driver? Just wanted to make sure, even though you told me last post what to pull down and pull up.
-Ed
as far as I can see your schematic looks good, except for the following things:
- There is a connection with no voltage description on the right side (should be Vdd I guess)
- and you have to take care of your /Reset pin:
At the moment you are just pulling it to low, which will keep the chip in reset all the time.
Either you have to spend a Propeller pin to switch it to high after some time or you could make a slight change to your schematic:
10 uF capacitor from Vss to /Reset and a 10k resistor from /Reset to Vdd
While the capacitor is discharged, it will behave like a short circuit. So the chip will be reset on power up.
When the capacitor is fully charged, it will behave like open clamps. So 3,3V are applied to /Reset and the chip will come out of reset.
I have to tell you that there is one weakness of this circuit I proposed: If the time between power off and power on is too short (a second for example), the capacitor will not have enough time to discharge. So the chip won't reset the next time you switch it on. This is a reason this circuit should not be used in commercial products.
This is correct. Although you have to take care of several things at the moment:
- Add this function to the driver:
'*************************************** PUB SocketTCPdisconnect(_socket) | temp0 '*************************************** 'If the ASM cog is running, execute the command if (W5100flags & _Flag_ASMstarted) 'Tell the W5100 to disconnect the particular socket temp0 := _DISCON writeSPI(true, (_S0_CR + (_socket * $0100)), @temp0, 1)It should be used when the requested data has been sent, since SocketClose won't send a FIN.
- Your receive buffer should be 2048 bytes and the transmission buffer should be less than 2048 bytes.
- and don't be too disappointed in terms of speed. At the moment it is dead slow (5KByte/s) and there is still a lot to be done to make it much faster.
Regards
Patrick
These are the changes:
- fixed a bug in the "dec" function
- added the "SetSocketMemory" function to assign memory to the sockets (if it's not called default is 2K each socket)
!Please note: since this is still experimental, you will have to change the masks in the txTCP/rxTCP procedures manually; look for "_TX_expmask"/"_RX_expmask"
and change it to "_TX_mask"/"_RX_mask" if you like to use 2K buffers each or you could also modify the "_TX_expmask"/"_RX_expmask" constants.
Be sure that the mask always corresponds to the socket memory you assigned! (at the moment the masks are set to 1K receive buffer and 8K transmit buffer)
- added support for the address auto increment functionality of the W5100 chip
just set the last parameter of "startINDIRECT" to true if you want to use it or false if not
I have also done some new speed tests (downloading a file from sd card):
txTCP with 8K buffer; no address auto increment @ 80MHz clock: 307 KBytes / s
txTCP with 8K buffer; with address auto increment @ 80MHz clock: 511 KBytes / s
I was also able to stream a divx video, even without address auto increment.
I am finishing my PCB layout, and I am a bit confused on how I should place the 6 decoupling capacitors for the 3.3V supply on the W5100. The reference schematics I've seen for the W5100 all have five 0.1uF capacitors, and one 4.7 uF. But I only see 3 supply pins for 3.3V.... Where do I place the other two 0.1 uF caps? and where should I place the 4.7uF cap?
Any help would be appreciated. I attached my current layout with the 3.3V trace highlighted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
Last weekend and this weekend I have been working on the W5100 indirect driver. I had hit a brick wall with the W5100 documentation. I think it was some of the same problems that Patrick1ab experienced. After a couple of PMs he clued me in on what my problems were - it had to deal with the sequencing of the /RD, /WR and /CS. I was thinking that the changing of the /RD or /WR happened after the /CS, but Patrick1ab showed that that logic is wrong according to the values on the table with the timing diagram.
Patrick1ab's code has the /RD or /WR change before the /CS. I had a EUREKA moment last week. Why do they have to change before, why not at the same time? After all the W5100 data sheet was simply saying don't change /RD or /WR more than one nano-second after /CS - so they change at the "same time". I'll post the code soon, but basically it is that there is a RDCS mask and a WRCS mask which makes the /RD or /WR line low at the same time as /CS.
I did some speed testing with the latest driver. We should standardize a speed test so that we can compare drivers and optimization. My test consisted of a program that initialized the W5100 addresses and then waits for a UDP packet. The Prop/W5100 receive the packet and then echo it back. I have a logic analyzer setup on a couple of the data pins of the W5100 as well as the /RD, /WR, A0, A1 and /CS. I set up markers in the analyzer from the first /CS fall on setting the A0/A1 to read a data register to the rise of the /CS on the last bit of the last byte. Then I sent a 1000 byte packet to the W5100.
Reading and writing were about the same speed. The Prop consumed the 1000 byte packet from the W5100 in 0.60ms! Writing was the just slightly longer at 0.601ms. I did a couple runs and got similar results.
Next I tried to hookup Patrick1ab driver, but the code isn't initializing the UDP port. It is getting late in my day, so I won't troubleshoot if for now.
I have some more work on a demo for the drivers and more cleanup of the code. I also noticed that the my driver is failing with larger packets over 1200 bytes so I need to find this problem. I recall this problem from before, I thought I fixed it, must not have.
@Patrick1ab - can you post demo code on how you did your test or try what I did above to compare results? I'm curious. We should probably have a test that works over a couple seconds, because if you multiple out my one-shot timing values it is an unrealistic theoretical speed value.
TDS: edited text for better reading.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
Post Edited (Timothy D. Swieter) : 6/13/2010 12:24:36 AM GMT
I did these tests using a modified web server program, which was originally designed for the ENC28J60 chip.
I added a copy of this program to the attachments, but I'm not sure if it works, because I tried to fix a bug recently and had no chance to test it yet.
The bug I tried to fix occured when the client side canceled/aborted the file transmission. The web server didn't go back to "listen" mode in this case, so it was completely blocked.
I tried to fix it by adding this
to the data sending loop at the bottom of the main program.
It should work, but as I said, it's untested.
There is another bug which may not occur while using this web server in a LAN, but if you like to access it from the internet it appears:
If no file name is specified in the url, the server should send back a list of files.
While accessing the server from the internet this will lead to a timeout error on the client side.
Edit: After a first test it seems that I have eliminated the first bug, but created several new bugs.
I checked with Fiddler and saw that the server always returned "HTTP/1.0 501 Not Implemented" (most likely due to a incomplete header).
Adding a pause time of several ms to the beginning of "webServerThread" solves this problem.
Another problem turned up because the "receivewebBuffer" wasn't initialized. I fixed this too.
Post Edited (Patrick1ab) : 6/13/2010 12:06:51 PM GMT
470 kBytes/s @ 80 MHz with 2K TX memory
543 kBytes/s @ 80 MHz with 8K TX memory
Test: May 6
txTCP with 8K buffer; no address auto increment @ 80MHz clock: 307 KBytes / s
txTCP with 8K buffer; with address auto increment @ 80MHz clock: 511 KBytes / s
Test: June 13
470 kBytes/s @ 80 MHz with 2K TX memory
543 kBytes/s @ 80 MHz with 8K TX memory
I assume these tests were the same (mostly with the exception of auto-increment). Why is there such a large change in speed with a larger buffer? I can understand some improvement because the code doesn't jump around as much, is that the only reason for improvements?
Is the test testing both reading and writing or mostly writing from the Prop to the W5100? I think reading from the W5100 to the Prop would be fast. I need to count instructions/cycles and see if there are any other improvements in the writing from the Prop to the W5100.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
I tested this with your driver, but added some procedures from my version (see my PM): str, dec, SetSocketMemory, SocketTCPdisconnect
I think this is exactly the reason. In particular the address calculation is consuming most of the processing power.
When I made my first tests a few months ago without address auto increment and only a 2K buffer, I got speeds you would only expect from a 56K modem.
It's mostly writing from the Prop to the W5100, because I download a 350MB video file from a sd card and save it to my computer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
Write 'em in BASIC! <g,d,r>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Sorry to be so delayed in responding. I haven't had the "processing power" to handle all the items I am working on as well as keeping up with PropBasic. Tell me more about what you mean? PropBasic compiles to ASM? Can a PropBasic routine be launched in another cog. What advantages to using PropBasic for this application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
· Yes PropBasic compiles to straight PASM. I've even written VGA video drivers in pure PropBasic. It is that fast.
· PropBasic can also generate LMM code by simply appending "LMM" to the PROGRAM command. LMM is about 5 times slower than PASM.
· Routines in other cogs are called TASKs. Each task can be either straight PASM or LMM.
· PropBasic code is MUCH easier to maintain than PASM because it handles alot of the little details for you.
· I'd be willing (more than willing) to assist you. Just let me know.
P.S. PropBasic runs·under BST, plus it is multiplatform.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
Beyond speed in the W5100 driver would be overall code speed, readability and maintainabiliy for the whole Spinneret project. The advantage that many things would be faster if it was all in PropBasic would be great.
Any superb SDcard driver in PropBasic yet that can be launched as a task? This is one area I was hoping to utilize other SPIN/ASM objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com
I doubt PropBasic is going to be faster than hand coded PASM, but it does generate logical code without a lot of fluff.
No SD card driver yet.
Using spin objects is not easy, but would be the same for using spin objects from a pasm program too.
But, Serial, I2C, 1-Wire etc commands are built-in so you don't need any of those objects.
If you post some code I'll try converting it to show you what it would look like in PropBasic.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
Personally I could probably trade off speed in just the W5100 driver if I also gain speed in the rest of the application like HTML parsing or protocol handling, etc. The audience for the Spinneret will of course want speed, speed, speed in every portion of the application as possible. I'd have to make the call to commit soon to which language to use before I code too much more in one direction.
The lack of SD support could make the choice though. This isn't something I should be coding, there are far more experienced people out there in this area. The SD card is a key feature of the Spinneret.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com