LXSAMD21DMX library for SAMD21

Questions concerning any LXSeries open source projects.
Comments and requests can also be posted on GitHub.
xldaedalus
Posts: 17
Joined: Wed Jun 22, 2022 10:18 pm

Re: LXSAMD21DMX library for SAMD21

Postby xldaedalus » Fri Jul 15, 2022 10:09 pm

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

xldaedalus
Posts: 17
Joined: Wed Jun 22, 2022 10:18 pm

Re: LXSAMD21DMX library for SAMD21

Postby xldaedalus » Sat Jul 16, 2022 7:39 pm

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

admin
Site Admin
Posts: 229
Joined: Mon Nov 20, 2017 4:31 pm

Re: LXSAMD21DMX library for SAMD21

Postby admin » Sun Jul 17, 2022 3:34 pm

It is possible that the interrupt handler is not getting called. You can try changing

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.