1

I am looking for a reliable serial protocol that can be used for communication between PC host and a MCU programmer. Currently I've devised a prompt-like protocol, which has been great for testing, but I need reliability and functionality in terms of error checking, ACK/NACKs, parameter parsing, etc. The device I am working on will communicate with the host PC via UART.

I've done some testing with the current protocol, and it turns out the PC sends data too fast for the MCU to react, and a lot of data is lost. In the beginning I though I would be able to get away with a custom protocol, which I've used a lot (prompt-like, no error checking, ASCII-based), however it appears it's not good for the application.

Edit: The programmer I am working on will be used with the BDM protocol of some very old MPC55x processors. The custom serial protocol currently has the following properties:

  • Data from MCU is encapsulated in STX and ETX\r\n symbols
  • Data from host (PC) is not encapsulated but must end with \r. That's makes it easier to use a terminal
  • Each command returns a response
  • The MCU returns an error response if the command is not recognized
  • The host software waits for a valid response a number of seconds after each command is sent. If no response is returned, application takes action
  • The host app provides error checking in terms of reading back data which has been written in the flash

My question is: Is there a serial protocol, which I can employ, and which would have all the features above (and possibly CRC/checksum).

Now when writing it all down, it appears that such a protocol will be a hard thing to find, since I want to be able to use the console for debug - that makes encapsulating messages hard. Therefore I am considering moving away from that concept towards a more machine-friendly interface.

awjlogan
  • 7,879
  • 2
  • 29
  • 45
Slav
  • 63
  • 7
  • First make a list of things you would like it to do. I've never heard of corrupted data being a problem, are you sure you need to detect corruption? If so, add a checksum at the end of each command. To solve the speed problem, just make the PC wait for the ack or for a timeout. – user253751 Mar 05 '21 at 09:38
  • For a uart programmer, you need some minimal error checking. It can be as simple as reading back each block of the flash/eeprom (and auto retry from the pc side app). That's pretty trivial. A per-line checksum or crc (at the end of each line in a text format) like in modbus-ascii or Intel-hex format, is also quite easy. – Pete W Mar 05 '21 at 13:02
  • 1
    also it sounds like you're talking about a bootloader interface? there are free ones out there. If making your own for whatever reason, keep it simple: it can be half duplex, you only need a handful of commands - e.g. push/pop data (to/from buffer), read/write flash or eeprom page (from buffer), reset, boot ... ascii is fine if you're not in a hurry – Pete W Mar 05 '21 at 13:09
  • ["Good RS232-based Protocols for Embedded to Computer Communication"](https://electronics.stackexchange.com/questions/69504/good-rs232-based-protocols-for-embedded-to-computer-communication) has a long list of protocols -- some of them are very simple protocols that simply encapsulate a string with a header and a checksum. – davidcary Mar 18 '21 at 22:33

1 Answers1

2

it turns out the PC sends data too fast for the MCU to react, and a lot of data is lost

There are four standard solutions for this:

  • turn down the baud rate

  • hardware flow control: the RTS/CTS lines (not always supported on the PC end!)

  • software flow control: "XON/XOFF". Doesn't work terribly well since data may be in flight by the time the microcontroller is sending the "stop, I'm overloaded" character.

  • increase the receive buffer. Almost all microcontrollers can keep up with 115k baud if all the interrupt handler is doing is adding characters to a buffer.

pjc50
  • 46,540
  • 4
  • 64
  • 126