Modbus Implementation for TM4C 123 launchpad

Modbus rs485 protocol does not have a start or end packet.  The bus is master/slave response so that idle condition of the line is used for start and end of message.  There is a timeout of something like 3 to 5 characters of line being idle.  

The modbus message start of message is

address

count

function code

---

---

16 bit crc.

The message is validated by count field and the 2 crc fields.

The only way to know when a modbus message is ended is for the transmission to stop.  That is why I used an external timer tied to my uart interrupt handlers to detect timeout.

My question is there a way to detect an idle condition without an interrupt handler.  I tried line break interrupt but did not work.

Thanks

Glenn

Ok you are using RTU frame format, the most complicate and not really faster than ASCII it require at almost 3.5 character (28 bit) as start and same for stop , Pak some time ago suggested a possible solution to sense end of transmission but I left this to future, now its that time and need a solution.
http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/348362/1284914#1284914
Glenn, please report if can help you.

Truth in advertising - I'm (at best) a signature-block free, [beginner guru] (credit Roberto) in matters Modbus.

That said - if trying to detect when the 485 bus goes "inactive" - might it be possible to route the 485 xcvr's RX to a 2nd MCU pin (beyond the UART RX) - this one chosen from among the MCU's Timer group?   

This Timer - configured as periodic - could then either interrupt - or be periodically "examined" - to determine if the 485 RX line has "gone quiet."  (i.e. any activity upon 485 RX causes the periodic timer to reset.   Absence of such activity - in excess of the timer's period - generates an interrupt and/or special, timer bit toggle) 

We've past used such method within a "bit-banged" (enfeebled) communication "add-on" - where a similar, EOT was not readily available.  Cost is one GPIO & a Timer - and some investigation of timer "nooks/crannies."

Hi Gleen, I remember the term "Line Break" was from the early time of serial communication, when a terminal was in need of interrupting unresponsive task then line was driven to "space"  for a time longer than xx bit. This never can be fired on idle period where line is "MARK" and never stay to break long  "SPACE" and never fire corresponding interrupt too.

Reading again UART section is forever a good learning about, so RX timeout can help, revceiving the transmitted character this is a quite perfect idle detector, modbus specify at almost 3.5 character period, this fire at 4th character so 1/2 char is ok :

"Interrupts are always cleared (for both the UARTMIS and UARTRIS registers) by writing a 1 to the

corresponding bit in the UART Interrupt Clear (UARTICR) register (see page 931).

The receive timeout interrupt is asserted when the receive FIFO is not empty, and no further data

is received over a 32-bit period when the HSE bit is clear or over a 64-bit period when the HSE bit

is set. The receive timeout interrupt is cleared either when the FIFO becomes empty through reading

all the data (or by reading the holding register), or when a 1 is written to the corresponding bit in the

UARTICR register

tm4c123gh6pm microcontroller data sheet rev (C) november 15 2013

 page 899

 And here brk bit description as "Line Break" rule in the past:

 Edit: Two lines barred are not pertaining to BRK bit.
0 Parity is disabled and no parity bit is added to the data frame.
1 Parity checking and generation is enabled.
UART Send Break
Value Description
0 Normal use.
1 A Low level is continually output on the UnTx signal, after
completing transmission of the current character. For the proper
execution of the break command, software must set this bit for
at least two frames (character periods).

Roberto,

Great post - terrific "tie-in" to past, serial communication - when "break" was so prevalent.  (and necessary)   Shames my feeble post - and I see now that Glenn had a similar (perhaps identical) method - also employing a timer.

Lesson learned - may be (unwise) to, "Drive, Walk or Post while drinking."  (Oh well...)

cb1_mobile said:

that Glenn had a similar (perhaps identical) method - also employing a timer.

 Hi CB1, when a poster is accurate and kind is a pleasure learn something new, reading again a so complex data sheet as TIVA are we learn some new feature to use for our trick of saving bit and code.. Has sense on this processor?

 Again I don't think port my protocol here using this feature, I forever prefer have a uniform code across processors to tailor to all application, an HAL library adapt TIVA timer to what where on my library and continue use as is from adoption of MSP. Systick here is by library at early time adoption MSP I wrote my tick timer and drivers as from OS theory.

cb1_mobile said:

Lesson learned - may be (unwise) to, "Drive, Walk or Post while drinking."  (Oh well...)

 About this, no problem till you spill a good drink over keyboard damaging both ;)

Roberto Romano said:

no problem till you spill a good drink over keyboard damaging both ;)

Hi Roberto,

Should it be a, "Good drink" - doubt that it would (stay) spilled for long.   (cats are not the only creatures able to quickly "lap up" desired liquids...)

And - if not mistaken - adult beverages often serve to "refresh" switch contacts - although that "bonus" was (clearly) unintended...

And - to your point - "Prefer have a uniform code across processors to tailor to all application."   That's of course the "holy grail of MCUs" yet most often - unachievable!  Look right here - this vendor's mix of (just) Cortex M4s - reveals that (unwanted/unexpected) "Special Handling" of I2C handshake/delay is required by new 129 family!  

As we serve a reasonably broad client base - no one vendor supplies "best/brightest" devices - over all operating specs/conditions/price targets.  And - even as we confine our selection to ARM (5 vendors, now) there are (most always) differences - which eliminate any (hope) for your, "uniform code across processors..."  

Yet - by sticking w/in the general ARM Cortex family (M0, M3, M4 & M7) and employing a "pro" multi-source accepting IDE (i.e. IAR) our ability to accommodate wide-ranging projects benefits greatly from the heightened similarity & predictablility - across ARM.