Hello,
has anyone out there got working modbus rtu code running on the MODM7AE70 that they are willing to share?
Or can anyone offer assistance on how to get it to work.
I have come across a tutorial here on the forum dating back to 2017, Tutorial Serial Port Processing Function using callback. This predates the MODM7AE70, so again can anyone point me in the right directions for assistance on corresponding code/functions that works on the Arm module?
All assistance greatly appreciated,
Regards,
Michael.
modbus rtu on MODM7AE70
Re: modbus rtu on MODM7AE70
It operates the same as on previous platforms. You set a function pointer to a callback function that receives an interrupt for every character. Example is located here: \nburn\examples\serial\SerialReceiveCallback
Re: modbus rtu on MODM7AE70
Hi Tom,
the callback function for the serial receive ( \nburn\examples\serial\SerialReceiveCallback) is exactly what I was looking for. It allows us to call our own serial handler, and start a timer to implement delays.
But we would also need access to a callback function for the serial transmit. This to keep the transmitter fed wih bytes as the modbus transmit message is happening. And also to time the disabling of the hardware (RS422/RS485) transmitter on our board. Must be disabled after the last byte in the message has been transmitted.
the callback function for the serial receive ( \nburn\examples\serial\SerialReceiveCallback) is exactly what I was looking for. It allows us to call our own serial handler, and start a timer to implement delays.
But we would also need access to a callback function for the serial transmit. This to keep the transmitter fed wih bytes as the modbus transmit message is happening. And also to time the disabling of the hardware (RS422/RS485) transmitter on our board. Must be disabled after the last byte in the message has been transmitted.
Re: modbus rtu on MODM7AE70
Realize the call back is at interrupt scope.
So the things you can do there are really limited.
No calls to any RTOS functions, no delays, none of the nice timer interfaces.
You basically can only stuff things in fifios and wake up tasks with post functions...
Read the interrupt section in the programmers manual....
Many customers have not heeded this advice and it sort of seems to work, but causes instability and random timing based crashes.
As for TX if you enable the 485 mode the RTS pin will automatically do the drive enable on transmit your looking for with no intervention on your part.
If you use the normal write interface there will be no gaps in the transmit.
(assuming your writes have no gaps.)
So send you message in one write, absolutly no gaps in serial output.
You can also send your message in multiple writes and as long as the subsequent writes occur
before the tx buffer is empty there will bee no gaps.
Writing single chars will probably be ok as long as the FIRST write is not a single char, ie you need to have enough data in your write that it wont
immediately empty the buffer when it moves data from buffer to hardware register.
Even if you do single char writes from the start the possible gaps will be short ie 1 bit time, well below the modbus gap spec.
So the things you can do there are really limited.
No calls to any RTOS functions, no delays, none of the nice timer interfaces.
You basically can only stuff things in fifios and wake up tasks with post functions...
Read the interrupt section in the programmers manual....
Many customers have not heeded this advice and it sort of seems to work, but causes instability and random timing based crashes.
As for TX if you enable the 485 mode the RTS pin will automatically do the drive enable on transmit your looking for with no intervention on your part.
If you use the normal write interface there will be no gaps in the transmit.
(assuming your writes have no gaps.)
So send you message in one write, absolutly no gaps in serial output.
You can also send your message in multiple writes and as long as the subsequent writes occur
before the tx buffer is empty there will bee no gaps.
Writing single chars will probably be ok as long as the FIRST write is not a single char, ie you need to have enough data in your write that it wont
immediately empty the buffer when it moves data from buffer to hardware register.
Even if you do single char writes from the start the possible gaps will be short ie 1 bit time, well below the modbus gap spec.