I normally choose to have an additional 18.4320MHz external oscillator which then ensures there is very good data synchronization and no problems with data errors.

@pmd34 do you mind elaborating on how you add an additional external oscillator? I'm still trying to get this issue figured out.

 

Hi @mbxs3 , well I tend to use the ATMEGA micorcontrollers which allow an external crystal to be used instead of the on-board clock (which is selected by programming some fuses in ISP mode), with 18.4320MHz the baud rate timing all matches up very well.

Have you checked the baud rate error for your own controller? And also try reducing the baud rate (the slower it is compared to the microcontroller clock the less likely it is to produce errors.

 

@pmd34 I may be off base in my thinking, as I am really figuring this stuff out as I go. But I have the Beaglebone Black that my app runs on and I can control the baud rate of the communication over the UART and I am attempting to communicate with a device made by some company that runs on a PIC24FJ256DA210. This vendors app communicates at 115200. I am making an assumption that, since I can't control anything their microcontroller is doing, that attempting to communicate at anything other than 115200 would lead to garbage.

I am honestly not sure how I would calculate the baud rate error for my controller.

 

Well I'll be damned...I dropped to 57600 and it started working. Thanks for pointing me in that direction @pmd34

 

Ah thats great to hear! Then it sounds like simply a timing problem.. if you really have to go faster I would look at using an external clock to reduce the % error.

 

Glad it's working for the poster.

RS232 still uses a handshake- I know I've built lots of TTL<->RS232C daughterboards for various projects. Here's an image showing the START/STOP handshake, from an online source-

https://www.best-microcontroller-pr...orks-tx-diag.png.pagespeed.ic.VNdjdQVNTl.webp