Describe the bug
The OSDP library code needs to have a way to pass in a GPIO that controls the DE pin (or NULL for no control).
Background
We are working on a project that will use OSDP to communicate between an Access Card reader (peripheral device, PD) and an Access Control unit (control panel, CP). We would like to use the OSDP library (zephyr\subsys\mgmt\osdp\src) and have been looking at the peripheral_device sample project (zephyr\samples\subsys\mgmt\osdp\peripheral_device) as the example.
The sample project is very simple with almost all of the OSDP communication supported by the OSDP library file, osdp.c. In this file, the osdp_init function uses the default configurations, CONFIG_OSDP_xxx, the minimal prj.conf configurations, and a DTS defined zephyr,osdp-uart to receive and send OSDP protocol messages. After fixing the minor issues from https://github.com/zephyrproject-rtos/zephyr/issues/66289 and creating a build for my hardware (that includes the SP481EEN RS-485 transceiver) and debugging, I see that the library has no provision for activating or deactivating the Driver Enable (DE) pin common to most RS-485 transceivers and therefore the example does not work for me (because the code cannot send responses to the CP).
Seems like the OSDP library code needs to have a way to pass in a GPIO that controls the DE pin (or NULL if not using RS-485). This could be done similar to how the led0 alias is specified in the DTS file, e.g. osdp_de.
Expected behavior
The OSDP library should have a way to pass in a GPIO to control the RS-485 DE pin (or NULL for no control).
Impact
The peripheral_device sample application will not work with RS-485 transceiver hardware (RS-485 is the expected physical layer for OSDP messaging).
Logs and console output
Will include Saleae Logic trace of OSDP RX, TX, and RTS(DE) from my hardware. Trace shows the code responding to incoming OSDP messages for broadcast address (0x7F) and default device address (0x01), but not progressing further due to lack of DE control.
peripheral_device OSDP trace.zip
Environment (please complete the following information):
Describe the bug The OSDP library code needs to have a way to pass in a GPIO that controls the DE pin (or NULL for no control).
Background We are working on a project that will use OSDP to communicate between an Access Card reader (peripheral device, PD) and an Access Control unit (control panel, CP). We would like to use the OSDP library (zephyr\subsys\mgmt\osdp\src) and have been looking at the peripheral_device sample project (zephyr\samples\subsys\mgmt\osdp\peripheral_device) as the example.
The sample project is very simple with almost all of the OSDP communication supported by the OSDP library file, osdp.c. In this file, the osdp_init function uses the default configurations, CONFIG_OSDP_xxx, the minimal prj.conf configurations, and a DTS defined zephyr,osdp-uart to receive and send OSDP protocol messages. After fixing the minor issues from https://github.com/zephyrproject-rtos/zephyr/issues/66289 and creating a build for my hardware (that includes the SP481EEN RS-485 transceiver) and debugging, I see that the library has no provision for activating or deactivating the Driver Enable (DE) pin common to most RS-485 transceivers and therefore the example does not work for me (because the code cannot send responses to the CP).
Seems like the OSDP library code needs to have a way to pass in a GPIO that controls the DE pin (or NULL if not using RS-485). This could be done similar to how the led0 alias is specified in the DTS file, e.g. osdp_de.
Expected behavior The OSDP library should have a way to pass in a GPIO to control the RS-485 DE pin (or NULL for no control).
Impact The peripheral_device sample application will not work with RS-485 transceiver hardware (RS-485 is the expected physical layer for OSDP messaging).
Logs and console output Will include Saleae Logic trace of OSDP RX, TX, and RTS(DE) from my hardware. Trace shows the code responding to incoming OSDP messages for broadcast address (0x7F) and default device address (0x01), but not progressing further due to lack of DE control. peripheral_device OSDP trace.zip
Environment (please complete the following information):
Additional context None