Shop OBEX P1 Docs P2 Docs Learn Events
Working P2/Spin2 example of W5500 Wiznet adapter? — Parallax Forums

Working P2/Spin2 example of W5500 Wiznet adapter?

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

Comments

  • 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.

  • 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.

  • 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.

  • 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.

  • JonnyMacJonnyMac Posts: 8,912
    edited 2021-10-19 16:26

    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) 
    
  • 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.

  • kwagnerkwagner Posts: 48
    edited 2021-10-20 16:17

    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.

Sign In or Register to comment.