This discussion of non standard baud rates follows immediately after a table of standard baud rates that are selected using class constants that have values from 0 to 15. There’s no info whatsoever on how you’re supposed to set a non standard baud. So, how do I set a baud rate that doesn’t have an entry in the table? I’m running OSX 10.10 and the FTDI driver docs say that it can handle any baud rate from 183 baud to 3 Mbaud just by passing the value to the driver, much as the above quote implies. For example, how do I set a baud rate of 250k?
Just to confirm, it did work exactly as Tim described. Too bad the documentation wasn’t more clear.
I used the following:
And it’s communicating fast and flawlessly.
Mark, the program is communicating with a PIC microcontroller which has a built in USART that derives its baud rate from its 4 MHz system clock and a divider register. It works well up to about 19200 baud, but after that, there isn’t enough resolution in the divider register to match standard baud rates accurately enough. For example if I try to set it to 38400, the closest it will get is 35714 which is off by 7%, and then the communications fail. As it happens, 250000 baud is a value that the microcontroller can generate exactly, and so there is no problem with timing errors as long as the serial driver on the computer end can communicate at that speed.
I use PIC in many projects, that 7% difference should be no issue, it does not need to be so accurate as one might imagine.
one issue you may find at some point is that very high baud rates will suffer with drift issues related to temperature more than lower baud rates, and at that very high rate your running code will need to be very short in execution before it impacts on the processors ability to receive data.
the system clock at 4mhz on 16 and 18f devices is actually divided by 4 which means the system clock is only 1mhz.
using BRGH should allow the divider to cover all the baud rates without any issue in actual use.
serial systems are pretty good at dealing with errors in rate as the sample will be at a point in time rather than over the whole high or low period.
just worth bearing in mind if you start to get missing data in the future when your PIC code expands.
I did my initial testing with stored data that the PIC sent repeatedly in a loop, and the PIC program was able to keep up with the 250k data rate. It’s now running its intended program and it doesn’t generate data as fast as the port can send it. This doesn’t seem to be a problem though. The port just sends it as it receives it. BTW, I have the RTS/CTS flow control working, so there’s no problem with data overrun. FYI, from the FTDI website: the drivers built in to OSX 10.10 and earlier don’t handle flow control properly, and so the driver available from the FTDI site should be installed. I confirmed this. I couldn’t get the flow control to work properly with the OSX 10.10 native driver, but when I installed the FTDI driver, it fixed the problem. This was apparently also a problem in older versions of Windows too. However, according to FTDI, the native drivers in the latest versions of OSX and Windows handle it correctly.
I never use RTS/DTS so have not come up with those problems, as I found in another thread about the serial port, which was related to RTS/DTS, all my serial PIC RX/TX is in custom interrupt code which removes the need for hardware handshake.
An issue which caused me some real headaches when El capitan was launched was to do with some “improvements” to security which stopped all third party serial drivers working.
I had no choice but to revert to 10.10.5 which I still work with, to date I have not looked for drivers that will work post 10.10.5.
Do you have any information on that picked up in your testing???