|
From: | Tomás Glaria |
Subject: | Re: [uracoli-devel] error in UART baudrate? |
Date: | Mon, 22 Dec 2014 10:02:37 -0300 |
To get a snapshot of the repo, see here: http://hg.savannah.gnu.org/hgweb/uracoli/Here is the changeset that fixes the issue:but well ... this one was already in 2012 ... which version you use?Axel.Gesendet: Montag, 22. Dezember 2014 um 13:27 Uhr
Von: "Tomás Glaria" <address@hidden>
An: "Axel Wachtler" <address@hidden>
Cc: address@hidden
Betreff: Re: [uracoli-devel] error in UART baudrate?I'll try to quote to make it clearly what I'm answering to:Me:Axel:
>>>The problem lies, according to me, that when you call the macro inside
>>>the function, the baudrate variable is a 16bit variable so the value 65535
>>>is 0xffff and the value 65536 is 0x0000 (should be 0x10000 but it's truncated)
>As for uint16_t br in HIF_UART_INIT: br is not the baudrate, br is the
>value for the UBRRxH and UBRRxL register. According to the data sheet
>the value for UBRR (br) has a range of 0 ... 4095 - the higher values it
>gets for lower baud rates.Me:I meant the 'baudrate value', not the 'encoded value'.In the code I see:#define ENCODE_BAUDRATE(br) ((F_CPU)/((br)*16l)-1)
inline void HIF_UART_INIT(uint16_t baudrate)
{
uint16_t br;
br = ENCODE_BAUDRATE(baudrate);
/* Set baud rate */
if ( br & 0x8000 )
{
HIF_UART_STATUS = _BV(U2X0); //Enable 2x speed
br &= ~0x8000;
}
UBRR1H = (uint8_t)(br>>8);
UBRR1L = (uint8_t) br;
....
}The second line is the interesting one, the definition on the HIF_UART_INIT() function uses an uint16_t variable type.Which means that the ENCODE_BAUDRATE(br) macro is using a 16bit variable as an input.When I call the function with the value 0xfffF, HIF_UART_INIT(0xffff), I'm actually calling the ENCODE_BAUDRATE macro as: ENCODE_BAUDRATE(0xFFFF)But when I call the function with the value 0x10000, HIF_UART_INIT(0x10000), I'm actually calling the ENCODE_BAUDRATE macro as: ENCODE_BAUDRATE(0x0000)Am I wrong here?(and yes, the br variable inside the HIF_UART_INIT() function is the output of the ENCODE_BAUDRATE macre and should overflow under any circumstance)>I just tried 250kbps/16MHz on Radiofaro - together with a python terminal (sterm.py) it worked.>However this was with the current Mercurial version, but with the last release 0.4.2, I failed the>same way like you. (250kbs fit better to the 16MHz).Could you give me a link to the mercurial version?I might find the differences that are causing the serial communication error.On Fri, Dec 19, 2014 at 5:31 PM, Axel Wachtler <address@hidden> wrote:Hi Tomás,
I just tried 250kbps/16MHz on Radiofaro - together with a python terminal (sterm.py) it worked. However this was with the current Mercurial version, but with the last release 0.4.2, I failed the same way like you. (250kbs fit better to the 16MHz).
I could not yet find the code change that is causing the repair,
some lines in hif_uart.h had changed ... but they need some review.
If you don't want to start with scons, I can roll you a package from the current snapshot.
Next release needs some more time, we added some sensor stuff to the
lib, that is not yet completely documented.
Cheers, Axel.
Am 19.12.2014 um 14:13 schrieb Axel Wachtler:Just a short response, ... for testing the UART, you can use xmpl_hif.c,
with 16MHz and Megarfa1 the rate 57600bps is proven and tested.
Having this running will be a solid starting point before pushing it
more to the limit.
As for uint16_t br in HIF_UART_INIT: br is not the baudrate, br is the
value for the UBRRxH and UBRRxL register. According to the data sheet
the value for UBRR (br) has a range of 0 ... 4095 - the higher values it
gets for lower baud rates.
In the code the MSB of br is set, if U2X is used, that bit is masked out
before writing UBRR.
Let's hear, how it goes with the UART and standard baudrates on your
project.
Cheers, Axel.
[Prev in Thread] | Current Thread | [Next in Thread] |