A bit of background: I have a LS7366R buffer board (Link: https://lsicsi.com/datasheets/LS7366R.pdf) that I have successfully established SPI connection with on Arduino and Raspberry Pi 4B (via Python's spidev library).
I am now trying to establish the same SPI comm via Codesys, but noticed that you must have a SPI device driver for your slave (there's posts about writing your own device drivers, but I feel out of my depth in that regard).
My question is: why do I need to specify a driver for this SPI device? What did spidev handle that Codesys' SPI doesn't?
And: if I can't write my own driver, what other options do I have?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might be wrong but i am fairly sure codesys is leveraging the same low level linux spi driver as the python library does.
A driver for codesys would be equal to the library for python.
However there are very flexible drivers that lets you define the protocol yourself to write "soft" drivers in plc code and then feed it to a function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, both using the same SPI driver sounds right: I'm sure when you state your device that Codesys makes certain assumptions about how comm protocols will be handled.
By "soft drivers", do you mean drivers specified through an XML file + Library?
I'm still not sure as to why we use such roundabout methods when RPI4 has its own SPI library to use; not like the buffer board has anything special about the way it sends its bytes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
XML file + Library would be one way if you want to hard code a driver.
Otherwise you can do it in logic using the method "SPI_master.transferExt(...)". Then you can define what you want to send and receive at runtime.
For example, the messages sent/received will be different for the MCP23017 (Microchip 16xGPIO chip) and MCP3208 (Microchip 8xADC inputs).
Look at the example project "PiFace_FB.project" to see how it is used. It is very flexible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A bit of background: I have a LS7366R buffer board (Link: https://lsicsi.com/datasheets/LS7366R.pdf) that I have successfully established SPI connection with on Arduino and Raspberry Pi 4B (via Python's spidev library).
I am now trying to establish the same SPI comm via Codesys, but noticed that you must have a SPI device driver for your slave (there's posts about writing your own device drivers, but I feel out of my depth in that regard).
My question is: why do I need to specify a driver for this SPI device? What did spidev handle that Codesys' SPI doesn't?
And: if I can't write my own driver, what other options do I have?
I might be wrong but i am fairly sure codesys is leveraging the same low level linux spi driver as the python library does.
A driver for codesys would be equal to the library for python.
However there are very flexible drivers that lets you define the protocol yourself to write "soft" drivers in plc code and then feed it to a function.
Yeah, both using the same SPI driver sounds right: I'm sure when you state your device that Codesys makes certain assumptions about how comm protocols will be handled.
By "soft drivers", do you mean drivers specified through an XML file + Library?
I'm still not sure as to why we use such roundabout methods when RPI4 has its own SPI library to use; not like the buffer board has anything special about the way it sends its bytes.
XML file + Library would be one way if you want to hard code a driver.
Otherwise you can do it in logic using the method "SPI_master.transferExt(...)". Then you can define what you want to send and receive at runtime.
For example, the messages sent/received will be different for the MCP23017 (Microchip 16xGPIO chip) and MCP3208 (Microchip 8xADC inputs).
Look at the example project "PiFace_FB.project" to see how it is used. It is very flexible.