4
\$\begingroup\$

My MCU cannot wake up from UART data, so I wanted it to wake up from the RTS line, but Im having problems understanding the concept.

When Im sending data from my MCU to the peripheral, I see the peripheral set its line to HIGH when its buffer is full. And as soon as I set my line to HIGH, the peripheral stops sending me any data.

This allows for full-duplex communication, but I expected the peripheral to notify me before sending any data, by setting its own line to HIGH. This doesnt allow for full-duplex communication, but this peripheral doesnt support simultanous TX/RX anyway, so that would be no problem.

So are there two modes of CTS/RTS flow-control? And do I just have bad luck that the peripheral supports the wrong mode? Does anyone have any other suggestions how I can wake my MCU before the UART data is coming in?

\$\endgroup\$
  • \$\begingroup\$ Are you sure you cannot wake up the mico using an edge interrupt on the RX pin (look in the GPIO section of the references, not the UART section). Or perhaps you can also run the RX signal into a spare interrupt input. \$\endgroup\$ – Chris Stratton Jan 29 '13 at 17:12
  • \$\begingroup\$ @ChrisStratton The MCU's wakeup time is around 65 microseconds, and the baudrate is 115200, so I expect that I will miss the first few characters using your method? \$\endgroup\$ – Muis Jan 29 '13 at 17:26
  • \$\begingroup\$ Can you precede your data with a bunch of nulls and define the protocol to ignore any which get through? Or have a re-sendable attention command and response you look for, before starting with the real data? Or explicitly blip the RTS line, manipulating it as a GPIO (or ioctl or whatever) if needed, then wait a bit before sending data. \$\endgroup\$ – Chris Stratton Jan 29 '13 at 17:36
  • \$\begingroup\$ @ChrisStratton The problem is waking up my MCU from data received by a 3rd party pheripheral (a bluetooth module). I cannot control how it behaves, or modify its firmware. \$\endgroup\$ – Muis Jan 29 '13 at 17:48
  • \$\begingroup\$ Does the blueooth module originate the data, or just do something such as convert bluetooth serial data to serial data? If the latter, you can fix it by adding wakeup time into the protocol as sent from the other end of the bluetooth link. \$\endgroup\$ – Chris Stratton Jan 29 '13 at 17:52
3
\$\begingroup\$

What you want is to be able to use other control lines (DTR / DSR). It's Data Set Ready / Data Terminal Ready, and it would solve your problem if your peripheral (or the BT module used) supported such behavior.

Are you able to add some HW at your side? Maybe you could implement a simple delay line by clocking incoming data through some shift registers, and waking up your MCU on incoming data so that (hopefully) it would be ready to receive it?

\$\endgroup\$
0
\$\begingroup\$

The easiest way to do this is to use a wake-on-falling-edge triggered interrupt and wire the serial input in parallel with the interrupt input.

If you have control of the protocol, simply have each packet start with a "FF" byte, which will be all-high except for the start bit, which will be low. This will basically just generate a low pulse on the wire, which can give you enough time to wake up, and receive the real packet data.

\$\endgroup\$
  • \$\begingroup\$ It may be worth noting that a nice advantage of "FF" bytes is that while an FF byte may not be correctly received following a byte with a framing error, the byte after the FF will always be correctly be received. Depending upon the UART design, some byte values FE, FC, F8, F0, E0, C0, and 80 may be usable for this purpose as well. Note that if you're using a 9-bit protocol, the MSB of the "synchronizing" byte must be set. \$\endgroup\$ – supercat Jul 31 '13 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.