I have been playing around with Basic Atom Pro 28 code to see if I can make it reliably output at the baud rate of 115200, which hopefully soon I will have assembly code to do this. But I keep thinking it would be great if I could simply use the hardware serial port on the BAP28 to communicate with the SSC-32. The problem is that the baud rates on the BAP28 work in multiples of 32 clocks so the closest real baud rate is 125000.
So then I wondered how hard it would be to make the SSC-32 run at 125000. I think it would be reasonably doable with a minor patch to the SSC-32 code. Looking at a previous version of the code, I believe the ATmega168 is running at a clock speed of 14745600 and if I do my calculations correctly if you use an UBRR0 value of 117 the actual generated baud rate would be: 124,962.7118644068 which is pretty darn close, with maybe a .03% error.
Personally I would not change the normal settings as my guess is the boat loader assumes 115200 and the like. But I believe you have a special test if the two baud rate pins are jumpered to each other than assume 115200. Could this simply be changed to 125000?
Yah, Maybe for those who connect with other devices other than a Basic Atom/Pro.
But it is a standard HSERIAL baud rate H125000 and there is no H112500. And since there are lots of the robots around here that are based on the Bap28s and maybe later with the Bap40s and it may be possible to generate a version of the SSC-32 that for example Xans code could output to over 3 times faster with maybe only 1 line of code changed in the SSC-32 source code, I thought I would ask.
Kurt
P.S - I personally would not mind that instead of overlading the shorting of the two IO pins to take over the baud rate of 2400.
Agree that the higher speed is changing the standard but if it could be user configurable then why not? This stuff is over my head anyway, I mean, it’s hard enough for me to select the right baud rate, never mind about trying to tweek for more speed.
I don’t think 125000 will work. The ATmega168 has an extra divide by 16 in the Baud rate calculation. So the numbers are
14745600/16/125000 = 7.3728. Using 7 as the Baud rate divisor would result in 131657 Baud, which is a 5.3% error.
There is a “fast” mode that uses a divide by 8 instead of 16: 14745600/8/125000 = 14.7456. Using a Baud rate divisor of 15 results in 122880 Baud, which is a 1.7% error. This is better, but the fast mode is sensitive to Baud rate mismatch so I am not confident it would work reliably.
