Go Down

Topic: New optiboot; beta testers welcome... (Read 124082 times) previous topic - next topic

westfw

This is http://code.google.com/p/optiboot/issues/detail?id=47

I have a patch but am away till next week, and it needs more testing.  Basically, remove this piece:
Code: [Select]

/* Switch in soft UART for hard baud rates */
#if (F_CPU/BAUD_RATE) > 280 // > 57600 for 16MHz
#ifndef SOFT_UART
#define SOFT_UART
#endif
#endif

I dunno what it's supposed to do, but it ends up trying to use the soft uart even for bitrates that would work fine with the hw uart...

putyn

#106
Nov 18, 2011, 01:19 pm Last Edit: Nov 18, 2011, 02:24 pm by putyn Reason: 1
ok mate - thanks i will try and report back
i got it working with the atmega8 bootloader - but the delay between power on/rest and the application start its huge
anyway this is just for testing this http://www.recursion.jp/avrcdc/ and so far its working great :P and its cheap compared to a commercial usb to serial converter - only downside its that the baud rate its max 38400

//later
ok ive tried your suggestion and it worked compiled for 9600,19200 and 38400 without any problems also - ive tested bootloaders and they worked

NATO

I need to get soft UART working with optiboot (to eventually re-assign TX and RX pins). For now, though, I'm using all default settings with the exception of this change to the make file:

Code: [Select]
atmega328: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' '-DSOFT_UART'

The addition of the -DSOFT_UART should enable the soft UART, but after burning the bootloader, I can no longer upload sketches. When I compile without the soft uart option, the bootloader works fine. Also, it seems strange to me that the size of the two bootloaders differs by less than 10 bytes. I would think that the addition of the soft uart would increase the size of the bootloader significantly. Thanks.

westfw

Hmm.  I haven't tried the soft_uart support since I started working on optiboot (the main concern has been the "supported" platforms, which all have hardware uarts.)  I would try a lower bitrate;  At 115200bps, the time between bits isn't really long enough to have the "slack" introduced by software delay loops.  The calculation for the delay loop count is (F_CPU/bitrate-20)/6, which yields 19 with about 4% error already (even assuming the calculation and code are perfect to that point.
(the only example using soft_uart in the makefile runs 9600bps at 1MHz, which is "slower", but the calculation is much closer to correct.)

Try 38400 instead...

NATO

I did try lower bitrates, but from what I gather the soft uart is meant for high bitrates. In fact, when I lower the bitrate, the compiler errors-out because of the following:

Code: [Select]
#ifdef SOFT_UART
// AVR350 equation: #define UART_B_VALUE (((F_CPU/BAUD_RATE)-23)/6)
// Adding 3 to numerator simulates nearest rounding for more accurate baud rates
#define UART_B_VALUE (((F_CPU/BAUD_RATE)-20)/6)
#if UART_B_VALUE > 255
#error Baud rate too slow for soft UART
#endif


Also, it's automatically enabled for higher bitrates. Like you, I assume that it would work better at lower bitrates. Maybe I'll kill the above code, and force it to use lower bitrates, just to see...

westfw

(While it's counter-intuitive that the code doesn't gain more size, it looks like using the HW uart involves a bunch of double-length instructions to access the uart registers ("lds r, REGISTERADDDRESS", "sbrs r,BIT") while the bit manipulation of the IO registers is much easier (one single-length instruction actually tests the bit... ("sbic registeraddress,bit")))  So it's not completely impossible.

Yes, using a slower bitrate is subject to being TOO slow.  The "delay" has to fit in a single byte.  At 16MHz, it looks like the slowest supportable common rate would be 19200)  My interpretation is that the loop count it comes up with should either be "large" or "exact."  38400 and 19200 look like they should be OK.

You'll notice that the comment doesn't match the code here, so the supposed rounding doesn't happen:
Quote
// Adding 3 to numerator simulates nearest rounding for more accurate baud rates
#define UART_B_VALUE (((F_CPU/BAUD_RATE)-20)/6)


NATO

Hmm, it appears I have that mixed-up. Soft uart is automatically enabled for: 9600<=bitrate<57600. It errors-out for any bitrate under 9600. Also, the AVR305 is an app note for a soft uart. I'm looking over it.

NATO

Thanks for your help. I'll try 38400 tonight and see how it goes. Also in the following from the pin definitions:

Code: [Select]
/* Ports for soft UART */
#ifdef SOFT_UART
#define UART_PORT   PORTD
#define UART_PIN    PIND
#define UART_DDR    DDRD
#define UART_TX_BIT 1
#define UART_RX_BIT 0
#endif
#endif


I don't understand what PIND and DDRD are for. Any idea? Thanks again.

Coding Badly

I don't understand what PIND and DDRD are for. Any idea?


http://www.arduino.cc/en/Reference/PortManipulation

NATO

Just an update on my efforts to get the soft UART working. I put a loop in the bootloader to repeatedly output a single character. With the hardware UART, the character was transmitted and received properly. With the soft UART, the wrong character is transmitted (or received). I tried many different baud rates with no success. I'm trying to figure out if the soft UART inverts the logic (maybe for simpler connection to RS232). I will put it on a scope tonight and see what is really going on.  I think I'm close...

Also, after looking at the soft UART, it is indeed very small, so it makes sense that it's barely larger than the hardware UART.

westfw

It might be easier to debug if you copy the soft uart code into a sketch...

NATO

Westfw, could you fill me in a bit on the history of optiboot? I've read some old posts from the original author, Peter Knight,  indicating that soft UART worked fine in V2 and V3. (I need to test this to see if it is the case).

On the google code repository I see V4_4, which is what I'm working with now. Was there an intermediate version, (like V4_1) that was released by Peter at some point? Or, are all the changes between V3 and V4_4 added by you?

I'd like to go back to a working version of the soft UART and move forward to see where it may have been broken. Thanks!

westfw

There was in intermediate version from Peter created after the 3.0zip file create (it never had a number.)  For some time after the world became aware of optiboot ("Uno" release?), people who pulled a source tree from the optiboot repository would get different code than people who pulled the version3 zip file.
The whole history is preserved by the code control system, either at the optiboot project for peter's changes: http://code.google.com/p/optiboot/source/list
Or in the Arduino repository for my changes: https://github.com/WestfW/Arduino/commits/master

I don't see anything that cries out to have broken the soft uart, but the "automatic soft uart detection" change was a little odd (and prevents optiboot from using the HW uart at lower bitrates, for no good reason that I know of.)

The app note referenced is here: http://www.avrfreaks.net/index.php?module=Freaks%20Files&func=viewFile&id=39&showinfo=1
Beware the typo that says "AVR350"; the correct app-note is AVR305


FYI, I added support for 1284P.  Very little changes needed.  Patch is up as optiboot issue 51.  It's just enough to build the bootloader and upload from command line.  Haven't added it to the boards.txt file and tested it in the IDE yet.

leo72

Where's the patch? I cannot find it on Googlecode Optiboot's page

Go Up