Wondering if anyone has a PASM driver for the Wiznet W5500.
You've asked this question before and you wanted "PASM drivers" but unless you are willing to adapt the PASM code that have been written for this into whatever software it is you are interfacing too then you may be treading water for quite some time.
That's all I'm looking for is any existing prop assembly language code for the W5500. There are PASM drivers in the OBEX for the W5100 and W5200, and I have used and contributed to both, but I can't find anything for the 5500.
That's all I'm looking for is any existing prop assembly language code for the W5500. There are PASM drivers in the OBEX for the W5100 and W5200, and I have used and contributed to both, but I can't find anything for the 5500.
I keep trying to tell you that it should be easy enough to adapt the stuff that's published such as this document here which lists the primitives to perform reads and writes to the chip using SPI. The SPI methods that it refers to could be duplicated with an SPI object but I basically read or write 8-bit SPI. The timing diagrams are also in the document to confirm what happens when it accesses the chip. Bear in mind that there is a 5-bit field that selects the "block" such as the receive buffer for a socket so that you don't have to work out the absolute address and mask etc as we did in the older chips.
Anyway the Tachyon code makes it easy for you to explore the W5500 and should be a great stepping stone to rolling your own code which I gather you intend to write in Spin but you haven't leaked the slightest clue as to what you intend to and want to do.
I've been reading your docs, interesting project. I have some understanding of what you're doing now, and yes it looks like a good tool for playing with hardware.
I currently use the 5200 (WIZ820IO) in a pixel controller that I sell as a commercial product. The W5200 driver from the OBEX uses the timer-based Fast SPI code to write to the W5200 at 20mb/s and read at 10mb/s.
I've been reading your docs, interesting project. I have some understanding of what you're doing now, and yes it looks like a good tool for playing with hardware.
I currently use the 5200 (WIZ820IO) in a pixel controller that I sell as a commercial product. The W5200 driver from the OBEX uses the timer-based Fast SPI code to write to the W5200 at 20mb/s and read at 10mb/s.
Well you saw the W5500 module that I have in the same footprint as the WIZ820io anyway. However this thing about "Fast SPI" is that it is a bit misleading because the rest of the Spin stuff that is responsible for interfacing to the SPI is so slow anyway that it doesn't matter how fast SPI runs as the application lags way behind. Only by writing a dedicated block transfer mode that accesses the SD card directly can you hope to maximise the throughput.
I looked at whether I would speed up SPI by dedicating a cog to it in Tachyon but I get very good transfer rates as it is now. Remember to walk before you can run though, or to put it another way, functionality first, features second. So get it working first then look at what you "need" to improve.
I believe you are referring to the W5200 code that I have posted to the OBEX a couple of years ago. For what it's worth when I created that code I reviewed both datasheets noting the differences between the W5100 and W5200. I then took the existing W5100 SPI code and made the needed modifications. After a bunch of code changes, some trial and error, and a fair amount of debugging with a logic analyzer I had working code which I was proud to share with the community. So to Peter's point it's a matter of sitting down and doing the work, which I've found is much easier when you have a project that needs it done.
With that said when the W5500 first came out I started adapting the W5200 code for the W5500 but stopped because I needed to spend my time on other portions of the project. I think Wiznet posted some example code for the Propeller but I've not reviewed it. I do intend on doubling back at some point but I'm not sure when, if you beat me to it please post your code to the OBEX for all to enjoy.
Hey Ben, good to hear from you. Yes, I'm looking to revise your 5200 driver. I sat down last night and went through the data sheets to compare. It looks like the main difference is that the 5500 addresses everything using a 5-bit block number and an offset address where the 5200 maps everything into a 64k address space.
Also the 5500 uses CS to control transfer length instead of passing the transfer length as part of the SPI sequence.
As far as registers, for the most part it looks like the layouts are unchanged. There are a few new features in the 5500 but unless those are needed the old code should work.
I know there was mention at some point that the 5500 reversed the bit order in the SPI sequence but I don't think that's the case.
Overall, it looks like it will take less code because of the new addressing scheme. I'm not 100% sure but I think the 5500 will automatically wrap from end of buffer back to beginning. If that's the case then ot won't require 2 separate read or write operations when crossing the end of buffer boundary. Need to verify that.
Seems the biggest changes are a single control byte in the W550 vs a word in the W5200 and the W5200 had a packet length which seems to have been dropped in the W5500.
Hey Ben, good to hear from you. Yes, I'm looking to revise your 5200 driver. I sat down last night and went through the data sheets to compare. It looks like the main difference is that the 5500 addresses everything using a 5-bit block number and an offset address where the 5200 maps everything into a 64k address space.
Also the 5500 uses CS to control transfer length instead of passing the transfer length as part of the SPI sequence.
As far as registers, for the most part it looks like the layouts are unchanged. There are a few new features in the 5500 but unless those are needed the old code should work.
I know there was mention at some point that the 5500 reversed the bit order in the SPI sequence but I don't think that's the case.
Overall, it looks like it will take less code because of the new addressing scheme. I'm not 100% sure but I think the 5500 will automatically wrap from end of buffer back to beginning. If that's the case then ot won't require 2 separate read or write operations when crossing the end of buffer boundary. Need to verify that.
It's easy enough to verify anything and to do so interactively with the hardware itself, just load up "hardware explorer" and copy & paste this driver document through the terminal and there you are, interacting with the W5500 registers etc.
btw, it does wrap automatically but it still has the problem that the read/write pointers are only accessible once the connection is established as my ifconfig shows. I maintain a validity flag and a shadow register.
[color=red][font=courier]************ NETWORK STATUS ************
LINK *UP*
HARDWARE: P1432 +P8 using WIZnet W5500 V4
SRC IP 192.168.016.150
MASK 255.255.255.000
GATEWAY 192.168.016.001
MAC 02.FF.4B.6B.8F.00.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#1 16:43:50 TCP 21 42522 . . . . . 08 14 LISTEN
#3 16:43:50 TCP 10001 . . . . . 00 14 LISTEN
#4 16:43:50 TCP 80 42103 . . . . . 0C 14 LISTEN
#5 16:43:50 TCP 911 . . . . . 00 14 LISTEN
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#4 16:48:48 TCP 80 46841 7B7A.7B7A. . C5. C5. 0C 17 ESTABLISHED 182.118.055.196
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#4 16:48:48 TCP 80 46841 7B7A.7B7A. . C5. C5. 0C 18 FIN WAIT 182.118.055.196
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#4 16:48:48 TCP 80 46841 . . . . . 0C 14 LISTEN
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#4 16:55:07 TCP 80 13789 . . . . . 0C 14 LISTEN ok[/font][/color]
I have now got an application where I am interested in using the W5500 chip, several years after the above was written.
Thank you to all involved with this forum, it has made my job easier.
Several of the links mentioned above are now obsolete, though the GitHub & google docs ones are still valid, so to do my bit here are the new forum & GitHub links to the quoted dead links.
I've ported my W5200 to the W5500. I'm testing now and things look good. Is there still a need for it?
Posted in the obex: obex.parallax.com/object/840
I wonder if anyone who has used the W5500 chip can answer a question for me?
I want to use it with a P1 (P2 could also be an option but I have not used one yet) to act as a serial to Ethernet converter, 6 RS-232 serial ports at 9600 baud plus some supervisory data for remote monitoring.
I would use the propeller to communicate with the real RS232 ports and send/receive the serial data via SPI to/from the W5500 from separate TCP/IP ports.
My limited knowledge (given that I have not done it) would suggest this is possible but perhaps I have missed something obvious?
Sound feasible anyone? Thanks for any help.
I do it with one P1, 8 serials 19200baud. (4 in one cog)
My serial data is a burst of 80 characters tree times /sec.
If the data is different, I update the variable dat.
I use the W5200, but tested good with W5500.
You can only use 7 different ports on the w5200 and w5500
I do not use the setup as serial bridge to tcp and it is really special application for monitoring and tracking motorbikes during bicycle races.
It update webpages, plot on google earth, generate graphics, and tracking antennas
Thank you very much Danial @Ltech , it is re-assuring to know that I am on the right track with this.
Your application sounds more exciting than mine though.
It sounds like you are using 2 instances of the FullDuplexSerial4port Object driver for your application. I was planing to do that too as I am already using it for another application and it works very well, with a small bug fix and a baud change mod.
I did see some references here to people using the P2 to do similar things to this (i.e. multiple serial ports and Wiznet chips), but I am not sure if that is a better way to go yet as I am more familiar with the P1 and your application is working and seems rather similar to mine.
You said you can only use 7 different ports on these chips? Were you referring to sockets?
You can only use 7 different ports on the w5200 and w5500
I thought that these chips supported 8 sockets?
The W5500 datasheet says "Supports 8 independent sockets simultaneously" and the document here https://forums.parallax.com/discussion/150024/new-wiznet-chip-w5500 by @DynamoBen
"W5200 vs W5500.pdf" also says "8 sockets".
Am i misunderstanding your comment here?
jstjohnz
Posts: 91
Comments
You've asked this question before and you wanted "PASM drivers" but unless you are willing to adapt the PASM code that have been written for this into whatever software it is you are interfacing too then you may be treading water for quite some time.
I keep trying to tell you that it should be easy enough to adapt the stuff that's published such as this document here which lists the primitives to perform reads and writes to the chip using SPI. The SPI methods that it refers to could be duplicated with an SPI object but I basically read or write 8-bit SPI. The timing diagrams are also in the document to confirm what happens when it accesses the chip. Bear in mind that there is a 5-bit field that selects the "block" such as the receive buffer for a socket so that you don't have to work out the absolute address and mask etc as we did in the older chips.
Anyway the Tachyon code makes it easy for you to explore the W5500 and should be a great stepping stone to rolling your own code which I gather you intend to write in Spin but you haven't leaked the slightest clue as to what you intend to and want to do.
I currently use the 5200 (WIZ820IO) in a pixel controller that I sell as a commercial product. The W5200 driver from the OBEX uses the timer-based Fast SPI code to write to the W5200 at 20mb/s and read at 10mb/s.
Well you saw the W5500 module that I have in the same footprint as the WIZ820io anyway. However this thing about "Fast SPI" is that it is a bit misleading because the rest of the Spin stuff that is responsible for interfacing to the SPI is so slow anyway that it doesn't matter how fast SPI runs as the application lags way behind. Only by writing a dedicated block transfer mode that accesses the SD card directly can you hope to maximise the throughput.
I looked at whether I would speed up SPI by dedicating a cog to it in Tachyon but I get very good transfer rates as it is now. Remember to walk before you can run though, or to put it another way, functionality first, features second. So get it working first then look at what you "need" to improve.
With that said when the W5500 first came out I started adapting the W5200 code for the W5500 but stopped because I needed to spend my time on other portions of the project. I think Wiznet posted some example code for the Propeller but I've not reviewed it. I do intend on doubling back at some point but I'm not sure when, if you beat me to it please post your code to the OBEX for all to enjoy.
BTW See my post in this thread for a document that contains the differences between the W5200 and W5500. http://forums.parallax.com/showthread.php/150024-New-Wiznet-Chip-W5500
Also the 5500 uses CS to control transfer length instead of passing the transfer length as part of the SPI sequence.
As far as registers, for the most part it looks like the layouts are unchanged. There are a few new features in the 5500 but unless those are needed the old code should work.
I know there was mention at some point that the 5500 reversed the bit order in the SPI sequence but I don't think that's the case.
Overall, it looks like it will take less code because of the new addressing scheme. I'm not 100% sure but I think the 5500 will automatically wrap from end of buffer back to beginning. If that's the case then ot won't require 2 separate read or write operations when crossing the end of buffer boundary. Need to verify that.
Seems the biggest changes are a single control byte in the W550 vs a word in the W5200 and the W5200 had a packet length which seems to have been dropped in the W5500.
It's easy enough to verify anything and to do so interactively with the hardware itself, just load up "hardware explorer" and copy & paste this driver document through the terminal and there you are, interacting with the W5500 registers etc.
btw, it does wrap automatically but it still has the problem that the read/write pointers are only accessible once the connection is established as my ifconfig shows. I maintain a validity flag and a shadow register.
I think I saw that a while back, it's all in Spin so I'm not that interested.
I have now got an application where I am interested in using the W5500 chip, several years after the above was written.
Thank you to all involved with this forum, it has made my job easier.
Several of the links mentioned above are now obsolete, though the GitHub & google docs ones are still valid, so to do my bit here are the new forum & GitHub links to the quoted dead links.
Both these were originally posted by DynamoBen
Now located at:- https://forums.parallax.com/discussion/150024/new-wiznet-chip-w5500
Now located at:- https://github.com/parallaxinc/propeller/tree/master/libraries/community/p1/All/Wiznet W5500 Driver
I hope this helps someone in the future.
I wonder if anyone who has used the W5500 chip can answer a question for me?
I want to use it with a P1 (P2 could also be an option but I have not used one yet) to act as a serial to Ethernet converter, 6 RS-232 serial ports at 9600 baud plus some supervisory data for remote monitoring.
I would use the propeller to communicate with the real RS232 ports and send/receive the serial data via SPI to/from the W5500 from separate TCP/IP ports.
My limited knowledge (given that I have not done it) would suggest this is possible but perhaps I have missed something obvious?
Sound feasible anyone? Thanks for any help.
Yes you can.
I do it with one P1, 8 serials 19200baud. (4 in one cog)
My serial data is a burst of 80 characters tree times /sec.
If the data is different, I update the variable dat.
I use the W5200, but tested good with W5500.
You can only use 7 different ports on the w5200 and w5500
I do not use the setup as serial bridge to tcp and it is really special application for monitoring and tracking motorbikes during bicycle races.
It update webpages, plot on google earth, generate graphics, and tracking antennas
Daniel
Thank you very much Danial @Ltech , it is re-assuring to know that I am on the right track with this.
Your application sounds more exciting than mine though.
It sounds like you are using 2 instances of the FullDuplexSerial4port Object driver for your application. I was planing to do that too as I am already using it for another application and it works very well, with a small bug fix and a baud change mod.
I did see some references here to people using the P2 to do similar things to this (i.e. multiple serial ports and Wiznet chips), but I am not sure if that is a better way to go yet as I am more familiar with the P1 and your application is working and seems rather similar to mine.
You said you can only use 7 different ports on these chips? Were you referring to sockets?
I thought that these chips supported 8 sockets?
The W5500 datasheet says "Supports 8 independent sockets simultaneously" and the document here
https://forums.parallax.com/discussion/150024/new-wiznet-chip-w5500 by @DynamoBen
"W5200 vs W5500.pdf" also says "8 sockets".
Am i misunderstanding your comment here?
Thanks again,
Glen