Use
I've tried to make the device as straightforward to use as possible. Connect it to a FT232-board (or MAX232 or whatever), enter a terminal-emulator and set the baudrate to 115200 baud. Now you're ready to connect your unknown serial port. As soon as that's done and a few characters have been sent, the firmware will have figured out the baudrate and will send you that. It'll then proceed to 'translate' between the PC and the device, sending out any byte received with the baudrate adjusted apropriately.
If the device notices there are a lot of errors in what it receives, it'll assume the baudrate is wrong and will retry the autobauding procedure. It'll again tell you the detected baudrate. FYI: the autodetection routines will eat the first few characters after a baudrate-change so don't be surprised if you miss the first part of the initialization notice on your nifty device-to-be-debugged. Be sure to turn on hardware handshaking in the terminal program, by the way, or the transmit buffer inside the AVR will overrun and bytes will fall out.
For an example: here the following text is sent at the indicated baudrates:
Hello world! This is sent at 115200 baud.
Switched to 1200 baud now...
And we're back to 15200 baud!
And this is what it looks like on the receiving side:
As you can see, I've not limited the baudrates to the standard values of 1200, 2400, 4800 etc baud. This is a good thing because now the device can be used to debug devices with non-standard baudrates, wrongly-set uart baud rate dividers and devices with PLL-problems too. It does mean you'll get the baudrate including any detection and timing errors, so it may be a few percent off, especially on faster connections. The autobauding works from 110 to 115200 baud, by the way. The conversion between baudrates, in contrast, has 1200 as the lowest baudrate. Slower than that and you will see the speed the connection is on being detected, but no connecion will be set up. As a final gotcha: The connection may not send or receive 100% of the bytes correctly at 115200 baud; that rate really pushes the limits of the small AVR and every now and then a byte may get corrupted.
As usual, the software is released under the GPLv3 and can be downloaded here. There's a compiled .hex in there too for people without the avr-gcc toolchain installed. Happy hacking!
« Prev 4
18 commentsseria possível usar este circuito para converter a saida de um dispositivo que é originalmente 4800bps para imprimir dados em uma impressora que é 9600bps ? Grato por qualquer ajuda
Many thanks Roger Wolff for your contribution :-)
For those without avr-gcc: http://prive.bitwizard.nl/autobaud.hex
The MIDI baud rate is 31250, which is well within the range this device works in. It should work fine, as long as it gets some MIDI-data to synchronize to.
hey, was wondering if this nifty baudrate converter would work on midi signals. thanks
Hi Sprite, Any sign of the HEX file? I don\'t know enough about compiling code, and you did mention that the HEX file would be included ;-) quote: \"There\'s a compiled .hex in there too for people without the avr-gcc toolchain installed.\"
CRJEEA: First of all: why would you want a multi-processor beast when a simple AVR can do the job too, as I demonstrated? Secondly, if you go just by the time the lowest signal is low, you only have one measurement of data per byte; with my approach, you have up to 5 measurements. This is especially useful if the data has different slew rates for the lowering and raising edges, which would make the smallest low time different from what the bit-time really is.
Hmm... Seems an odd way to go about things to me Would this not work better??? Record what comes out of the debug pin at the highest possible speed then asses the shortest pulse timing giving you the baud? Just curious, of course it would need the memory capacity to store what ever the debug pin can through out and the speed to cope with gathering it in but after that it could work at it\'s own pace. Maybe even to the extent of having two cores or two chips working from the same memory. One chasing the other ones data. And then passing it on to the pc?
Did not see the \'included .HEX\' file. Would you please correct this? Looks like a great project, 1 I\'d like to make. :-)
Good work dear!
What a Hack ! Great jobs , use-full stuff
Cool gadget. A stand-alone device would be good too. Just add a (serial) LCD, say 1x16 just to print out the detected baud-rate. Otherwise you need a computer at all times. From a service technician's perspective.
The only reason I want to use the at90s2313 is that I have some laying around here. I feel they should be of some use.... oh and maybe I'm having a brain fart -- but I don't see the hex file in the download... Thanks
Actually, I'd actually prefer a version that simply tells you the baud rate and doesn't do any forwarding at all... Once I know the baud I would hook it up solid... Could we do a version like that?
bbsux: Wow, an at90s, that's oldschool :-) As far as I recall, I don't use any of the functionality that's been added between these chips. You might wanna try and see if these chips can take 20MHz, but if not, you can run them at 10MHz by changing the code (namely F_CPU in io.h and the baudrate setting in io.c.) This would probably mean you'd lose forwwarding of data at 115200 baud, though; everything below that should work just fine.
Can you use a at90s2313-10pc or would it be too slow? It would needs a few parts that the attiny2313 doesn't, right? thanks
Nice! Good project idea, simple implementation, together they add up to a creative, useful piece of hardware.
Would it be possible to use this circuit to convert the output of a device that is capable of 4800bps to print data on a printer that is 9600bps? Thanks for any help