Working P2/Spin2 example of W5500 Wiznet adapter?

kwagner

Hi all,

I'm probably doing something stupid but I can't determine what. I have a W5500 click that I have in the eval click adapter. I changed the pin assignments in W5500.spin to match, but when I run the UdpSocketClientDemo from https://github.com/jbkim/Parallax_W5500 (with my attempts to modify it for Spin2), I see no output in Wireshark. Has anyone else already adapted the code that can share the result?

Thanks

Circuitsoft

Do you have a logic analyzer you can attach to the pins? If not, I highly recommend one. The "8ch 24MHz" Saleae clones that cost ~$10 work very well with Pulseview.

kwagner

I don't, but that's a great idea. I'll check it out, thanks.

I was able to get it working. The end culprit was not waiting enough between opening the connection and transmitting packets, so the first however many disappeared never to be sent. The original version apparently either didn't have this issue, or its timing logic was different because of spin1. It seems to work for my purposes for now. I have to add a bit to my main program to fit it in and see how robust it is long-term.

JRoark

When you get this working, would you be willing to post your code? I’m about to travel the W5500 road and could use some code that I know works.

kwagner

My example code changes attached.
Caveats:

• I just tested UDP, I didn't do the other examples since that's what I'm using.
• I commented out the old serial terminal, I'm sure a new one could be added in.
• I may have messed up the timing when I converted from P1 to P2, maybe that's why I needed the pause between the Open() and Send (which I renamed WSend since Send is now a reserved word).
• I have it wait 10 seconds "just to be sure", it could most likely be reduced.
• I'm using the W5500 Click module, so my pinouts may be different than yours (modify in W5500.spin2)

My code sends 2500 UDP messages with the last two bytes set as counters (first 1-10, second 1-250) so I could see what packets come through when. It's not super robust but it's a starting point. Modify addresses/pinouts as necessary for your application.

JonnyMac

You could speed up your SPI transfers with a small change in the transfer routine. Using inline PASM2, you could push the W5500 as fast as it will go.

pri spi_transfer(value, bits) : result

  value ror= bits 

  repeat bits
    pinw(SPI_MOSI, value rol= 1) 
    pinh(SPI_SCK)
    result := (result << 1) | pinr(SPI_MISO)
    pinl(SPI_SCK)

pri spi_transfer(value, bits) : result | hp

  hp := (clkfreq / 50_000_000)                                  ' for ~25MHz

  org
                ror       value, bits
                rep       @.loop, bits
                 shl      value, #1                     wc
                 drvc     #SPI_MOSI
                 waitx    hp
                 drvh     #SPI_SCK
                 waitx    hp
                 testp    #SPI_MISO                     wc
                 rcl      result, #1
                 drvl     #SPI_SCK
.loop
  end

Then you could do something like this:

pri write_byte(addrSel, value)

  pinl(SPI_CS)

  addrSel := ((addrSel | ($01 << 2)) << 8) | (value & $FF)

  spi_transfer(addrSel, 32)

  pinh(SPI_CS) 

JRoark

Thank you for this! Muchly appreciated.

Once my Click arrives, I’ll start the deconstruction process. My end goal is to morph this into pure FlexBASIC. No particular reason, except it forces me to dig-in deeper and really understand the module.

kwagner

Thanks JonnyMac. I modified the routines in W5500 (attached, would welcome a second set of eyes for verification), and compared with the old. The results were interesting:

Compiler	W5500	W5500_jm
Propeller Tool	338	1557
FlexProp, no optimization	717	3000
FlexProp, default optimization	1986	xxxx
FlexProp, full optimization	2007	3755

I was unable to test W5500_jm on FlexProp on default optimization, as for some reason it "optimized out" the ReadByte function, which results in a compile error. As far as I can tell, packets look identical on all versions. It's obvious the modified SPI routines are an improvement as they increase transfer at each optimization level. I'm curious as to the differences in performance between the Propeller Tool and no optimization FlexProp.