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 


Mark wrote at 19 Sep 2015, 1.30:

Many thanks Roger Wolff for your contribution :-)

Roger Wolff wrote at 26 Apr 2015, 7.56:

For those without avr-gcc: http://prive.bitwizard.nl/autobaud.hex

Sprite_tm wrote at 22 Oct 2012, 10.11:

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.

c0mp1337 wrote at 18 Oct 2012, 18.27:

hey, was wondering if this nifty baudrate converter would work on midi signals. thanks

Mark wrote at 20 Mar 2011, 1.03:

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."

Sprite_tm wrote at 6 Dec 2010, 11.19:

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.

CRJEEA wrote at 6 Dec 2010, 1.50:

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?

Balbo wrote at 30 Sep 2010, 4.52:

Did not see the 'included .HEX' file. Would you please correct this? Looks like a great project, 1 I'd like to make. :-)

Talha wrote at 20 Apr 2010, 6.05:

Good work dear!

biosman wrote at 30 Oct 2009, 2.55:

What a Hack ! Great jobs , use-full stuff

MPep wrote at 25 Aug 2009, 6.06:

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.

bbsux wrote at 8 Aug 2009, 19.26:

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

bbsux wrote at 8 Aug 2009, 19.20:

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?

Sprite_tm wrote at 7 Aug 2009, 9.46:

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.

bbsux wrote at 6 Aug 2009, 23.47:

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

Chaz wrote at 6 Aug 2009, 13.23:

Nice! Good project idea, simple implementation, together they add up to a creative, useful piece of hardware.

Leave a comment:

Your name:

What does this picture say?
Sorry, this is a captcha

Your comment:

© 2006-2016 Sprite_tm - Contact