I've seen all the issues with 300 baud comms in the past ans also saw that the hardware serial core for the most recent build had the fixes updated to use 300 baud now. Problem is I'm using 1.0.1 and 300 baud still will not work correctly. It works at 1200 and above, but as soon as I change to Serial.begin(300); it spits out garbage to the monitor.
Any ideas why this might still not be working?
Can you confirm the 300 baud outputis bad with a different serial program?
Yes, I'm using hyper terminal . It works on higher bauds and did verify that hyper term works with different device at 300 baud.
To clarify, I'm using the USB serial and not tx/rx through a max232 type setup.
Dunno, sounds like a library issue or something software related.
Can you grab serial files from 1.0 and replace them in the 1.0.1 core files/library or something along those lines?
Or wait a bit, see if a more knowledgeable S/W person joins the conversation.
for the record I was just messing with arcane baud speeds, both 300 and 600, nothing worked properly till hitting the 1200 mark
for me it was a sanity check, I cant imagine why anyone would actually want to use those speeds, even the 1986 computer I was using with a 1984 rom nails 9600 (actually 115,200 if you get into twiddling bits in machine language)
So no real need then.
The Arduino (actually the ATMega chip) sets the baud rate using a combination of clock speed and clock divider settings. There are some baud rates where it just can't hit the right bps with enough accuracy, i.e. instead of 300 baud it might be going at 310 or 312 or something like that. There is a margin of error that devices on either end can cope with, but the slower baud rates might be too far outside that margin to be workable.
The datasheet for the ATMega328 gives examples for baud rates (with the % of error) but it only goes down to 2400 baud in its examples.
There's also something about interrupts, the serial module uses interrupts to handle things behind-the-scenes (this is why you can't use Serial inside an interupt handler) and at the low baud rates the uC can spend so much time in interrupts that the rest of the sketch gets starved out for cycles.
Cheers!
Wasn't there a change to how the baudrate clock was setup by the arduino at one time, something about using the 'double' speed divider option. Could that effect the divider size available such that it can no longer support 300 baud option?
Lefty
CrossRoads: I'll try the 1.0 software and see what happens. I've seen other posts in the forum where the change to the hardwareserial.cpp fixed the issue at 300 for a few people but not sure why not in my case.
Osgeld: I agree with you with the fact that the need should not exist for 300 baud anymore. Unfortunately, I work for the US government and we still have some weather data recorders in our legacy systems that are 300 baud limited.
My actual usage in this case is nothing more than a serial programmer. I have about 5 minutes worth of serial entries I have to make in order to program one of these devices. I work at a repair facility so we do a number of them all the time. Trying to cut down on time and loss of my sanity by pushing a button and having the Arduino send the commands for me. I'm not aware of another serial program (HyperTerm, Pro-Comm, RealTerm, etc) where you can build a "script" of entries with delays inbetween for such action. If you know of one please advise and I'll give it a try and leave Arduino up to some tasks that might be a little more current.
OK, I got it working through the RX/TX on digital 0/1 and a MAX232 setup. Must be a restriction or other issue in the atmega usb IC code.
Thanks for the assistance!
I'm not aware of another serial program (HyperTerm, Pro-Comm, RealTerm, etc) where you can build a "script" of entries with delays inbetween for such action
using custom software, but then you have to lug a pc around