DIRECTION_PIN is set LOW on start up. After receiving the DISCOVERY CMD, it sets HIGH and stays that way. Obviously, it can't "receive" it the RS485 transceiver is in transmit mode.
How/where do I look to see that: 1.) the data response packet was sent/finished sending. 2.) that the DIRECTION_PIN is set to idle in RECV mode.
Thanks
LXSAMD21DMX library for SAMD21
-
- Posts: 17
- Joined: Wed Jun 22, 2022 10:18 pm
Re: LXSAMD21DMX library for SAMD21
I commented out the sequence that mutes the discovery CMD after receiving.
if ( pid == RDM_DISC_MUTE ) {
if ( destination == SAMD21DMX.THIS_DEVICE_ID ) {
//discovery_enabled = 0; <------------------------------ commented out the following lines.
// send ACK
// UID source;
//source.setBytes(&rdmdata[RDM_IDX_SOURCE_UID]);
//SAMD21DMX.sendMuteAckRDMResponse(RDM_DISC_COMMAND_RESPONSE, source, RDM_DISC_MUTE);
I attached a RS485 capture terminal (REALTERM) to the DMX/RDM data lines to capture the data transaction. I can see the DIRECTION_PIN toggling properly, so I'm still working on trying to debug why it stops HIGH if the above code is uncommented.
The good news is I can see the firmware is transmitting even though the DMXit doesn't recognize the response.
The Discovery CMD from the DMXit
CC0124FFFFFFFFFFFF43540000000032010000001000010C000000000000FFFFFFFFFFFF0DCCFEFEFEFEFEFEFEAAEE7DFA7DAF5FAA5FAE5DAE5FAF57BB550000
The Discovery RESPONSE from the LXSAMD21 RDMdeviceTest_SAMD21
(only difference is serial.xxx is changed to serialUSB.xxx and the DMX/RDM RxTx is set to 30, 31)
CC01186C780F0A0C0E4354000000003E010000001000020002E400
CC01186C780F0A0C0E4354000000003F010000001000020002E500
CC01186C780F0A0C0E43540000000040010000001000020002E600
CC01186C780F0A0C0E43540000000041010000001000020002E700
CC01186C780F0A0C0E43540000000042010000001000020002E800
CC01186C780F0A0C0E43540000000043010000001000020002E900
CC01186C780F0A0C0E43540000000044010000001000020002EA00
CC01186C780F0A0C0E43540000000045010000001000020002EB00
CC01186C780F0A0C0E43540000000046010000001000020002EC00
CC01186C780F0A0C0E43540000000047010000001000020002ED00
Similar response is sent 10 times before DMX repeats its Discovery CMD. The only difference appear to be a message transaction counter and adjusted Checksum.
So, either the RDM response is incorrect, or the Checksum calculation is incorrect. Trying to sort out which
if ( pid == RDM_DISC_MUTE ) {
if ( destination == SAMD21DMX.THIS_DEVICE_ID ) {
//discovery_enabled = 0; <------------------------------ commented out the following lines.
// send ACK
// UID source;
//source.setBytes(&rdmdata[RDM_IDX_SOURCE_UID]);
//SAMD21DMX.sendMuteAckRDMResponse(RDM_DISC_COMMAND_RESPONSE, source, RDM_DISC_MUTE);
I attached a RS485 capture terminal (REALTERM) to the DMX/RDM data lines to capture the data transaction. I can see the DIRECTION_PIN toggling properly, so I'm still working on trying to debug why it stops HIGH if the above code is uncommented.
The good news is I can see the firmware is transmitting even though the DMXit doesn't recognize the response.
The Discovery CMD from the DMXit
CC0124FFFFFFFFFFFF43540000000032010000001000010C000000000000FFFFFFFFFFFF0DCCFEFEFEFEFEFEFEAAEE7DFA7DAF5FAA5FAE5DAE5FAF57BB550000
The Discovery RESPONSE from the LXSAMD21 RDMdeviceTest_SAMD21
(only difference is serial.xxx is changed to serialUSB.xxx and the DMX/RDM RxTx is set to 30, 31)
CC01186C780F0A0C0E4354000000003E010000001000020002E400
CC01186C780F0A0C0E4354000000003F010000001000020002E500
CC01186C780F0A0C0E43540000000040010000001000020002E600
CC01186C780F0A0C0E43540000000041010000001000020002E700
CC01186C780F0A0C0E43540000000042010000001000020002E800
CC01186C780F0A0C0E43540000000043010000001000020002E900
CC01186C780F0A0C0E43540000000044010000001000020002EA00
CC01186C780F0A0C0E43540000000045010000001000020002EB00
CC01186C780F0A0C0E43540000000046010000001000020002EC00
CC01186C780F0A0C0E43540000000047010000001000020002ED00
Similar response is sent 10 times before DMX repeats its Discovery CMD. The only difference appear to be a message transaction counter and adjusted Checksum.
So, either the RDM response is incorrect, or the Checksum calculation is incorrect. Trying to sort out which
Re: LXSAMD21DMX library for SAMD21
It is possible that the interrupt handler is not getting called. You can try changing
to
in LXSAMD21DMX.cpp line 450 in sendRawRDMPacket() to insure that the interrupt trips and the outgoing RDM is sent.
This would involve restoring the lines you commented out which are responsible for sending a reply to the RDM tester's query. Without sendMuteAckRDMResponse, the tester will never know your device is there.
I don't know a downside to doing this. It is possible that there was a leftover interrupt that triggered the handler when the example was first tested. But, this was just by chance, rather than a guarantee that the interrupt is tripped every time sendRawRDMPacket() is called.
Also, there is a wait loop at the end of sendRawRDMPacket() and you can set a pin or some other debugging device to see if the code ever gets past that loop.
Code: Select all
DMX_SERCOM->USART.INTENSET.reg = SERCOM_USART_INTENSET_TXC | SERCOM_USART_INTENSET_ERROR;
to
Code: Select all
DMX_SERCOM->USART.INTENSET.reg = SERCOM_USART_INTENSET_TXC | SERCOM_USART_INTENSET_ERROR | SERCOM_USART_INTENSET_DRE;
in LXSAMD21DMX.cpp line 450 in sendRawRDMPacket() to insure that the interrupt trips and the outgoing RDM is sent.
This would involve restoring the lines you commented out which are responsible for sending a reply to the RDM tester's query. Without sendMuteAckRDMResponse, the tester will never know your device is there.
I don't know a downside to doing this. It is possible that there was a leftover interrupt that triggered the handler when the example was first tested. But, this was just by chance, rather than a guarantee that the interrupt is tripped every time sendRawRDMPacket() is called.
Also, there is a wait loop at the end of sendRawRDMPacket() and you can set a pin or some other debugging device to see if the code ever gets past that loop.