The clock signal issue was due to the SPI default speed of 1.25 MHz(!); I have changed it to 1000 Hz and I can now see the clock signal perfectly. The oscilloscope also showed me that MOSI was sending bytes 0x88, 0x03 then 0x90, 0x00: the write commands referenced in the setup method. I wonder if this program is just never getting past the setup method.
Hello again! Previously I had written a simple program that write to a register and reads from it. It works beautifully. Now, I am trying to expand upon that and write a program that sets up the buffer board's mode, then continuously reads the encoder value from the 'CNTR' register. Unfortunately, now there isn't even a clock signal; and, when I go online, all values (except for constants) show as '???' (invalid value). My guess is that there's an issue with how I set up the Task Configuration, but...
I figured out what was wrong...dumb me :X I forgot that it was shifting out on the falling edge and therefore MOSI would lead SCLK; so the original signal is correct 😅 Anyways. Still don't know why SPI mode shows 4 at runtime, but it's obviously still on mode 0. Problem solved!
Hello all, I have made progress on SPI comm to my buffer board (hooray!), in that there is a decipherable SCLK and MOSI signal. However, I've noticed that the MOSI signal is bit shifted to the left by one; for example, trying to send 72 (#01001000) instead shows on the oscilloscope as #10010000. After a bit of research the consensus seemed to be that it is a SPI mode issue, and indeed, when I check my SPI parameters it shows a diMode = 4; which makes no sense. From the datasheet I can see that I...
Hello all, I have made progress on SPI comm to my buffer board (hooray!), in that there is a decipherable SCLK and MOSI signal. However, I've noticed that the MOSI signal is bit shifted to the left by one; for example, trying to send 72 (#01001000) instead shows on the oscilloscope as #10010000. After a bit of research the consensus seemed to be that it is a SPI mode issue, and indeed, when I check my SPI parameters it shows a diMode = 4; which makes no sense. From the datasheet I can see that I...
I'd like to ask about that last part. Why do we specify speed in the SPI_master options when we have to specify it anyway when we call .transferExt?
(SPI is enabled on the RPi) I took a look at that link and gave it a try, creating a class that extended SPI. It seems that CODESYS wants BeforeWriteOutputs, AfterReadInputs, and Initialize to be overloaded with a call to SUPER. Wouldn't that mean I'd also have to write the .xml file? Is there any way to get around this?
Hello all, I am trying to initiate SPI communication with a LS3667R buffer board (https://lsicsi.com/datasheets/LS7366R.pdf). Following suggestions for my previous post (https://forge.codesys.com/forge/talk/Runtime/thread/80ca780e26/?limit=25#7ed3/bb06), I decided to execute SPI communication directly in my PLC_PRG with a call to a "read" and "write" method; these methods in turn (ideally) start SPI communication using SPI_master.transferExt(pabyTxBuffer, pabyRxBuffer, udiLen, uiDelayus, udiSpeedHz)...