Understanding the Serial driver

[Fishleg]

Hi there on the other end of the internet,

I want to receive some data via the serial driver and ChibiOS 2.6.6 using an Olimex STM32E407 development board. The sender of the serial data is EnOcean Pi, which is connected to 3,3V, GND, RX and TX. TX of Sender is connected to PD6 (USART2 RX) and RX of sender is connected to PD5 (USART2 TX). I configured PD5 and PD6 in board.h file like USART6 (based on lwip example on Olimex STM32-E407) but using PD5 and PD6 and alternate 7 (which is alternate for USART2, USART6 has alternate 8). In halconf.h I enabled

Code: Select all

#define HAL_USE_SERIAL   TRUE

and in mcuconf.h i enabled USART2

Code: Select all

#define STM32_SERIAL_USE_USART2             TRUE

The SD2 is started as following:

Code: Select all

SerialConfig usartconfig;
usartconfig.speed=57600;
sdStart(&SD2, &usartconfig);

In documentation of Enocean Pi, they use a bitrate of 58823, but they write also, that 57600 should work. However, some of my experiments used 58800 and 58823 bit.
When I send a radio telegram to the Enocean Pi, the TX pin of it emits some toggling (I connected the TX-Pin for some tests to PD0 and read it using palReadPad(GPIOD,GPIOD_PIN0);), so i assumed, that this is the data I want. But the input queue of SD2 (tested with qspace = chQSpaceI(&(&SD2)->iqueue);) stayed empty and reading with sdRead(&SD2, (uint8_t*)&cha, 1); blocked (which is no miracle, if input queue is empty).
So I wrote a byte to SD2 and bing! the input queue contains a byte, which i can read with sdRead(). I had expected, that the byte would be written to the output queue (which qspace stays 64, means no byte in there). So I assume i forgot somewhere to connect the iqueue with the USART2 RX and the oqueue with the USART2 TX.
Same game if i use SD6 and the corresponding pins.
Ok, how can i connect the TX of sender with the iqueue of SD2?

Thank you very much in advance,

Dirk.

[Giovanni]

Hi,

Queues are handled by the driver, you don't need to do anything except calling the API functions.

A problem could be the baud rate, you cannot select an arbitrary value but only values that can be obtained using the USART divider. If you enable assertions in chconf.h you will get an error when trying to start the driver if the value is invalid, also make sure to initialize all fields for the configuration structure, not just the baud rate.

Giovanni

[Fishleg]

Hi Giovanni,

thank you very much. In my sdStart, I configured now some bits found in the STM32F4-Manual for CR1, CR2 and CR2. This did the trick! Wohoo!
After a closer look, I saw that these were exactly the same bits like defaulted in usart_init(). The exact trick was to zero out the CR3 in SerialConfig variable before in-or-ing USART_CR3_EIE.
So I see (repeatedly in my life), that uninitilized variables are evil.

Thank you very much for your commitment, you helped me already a lot of times with ChibiOS!

Greetings, Dirk.

[rew]

For the baud rate, I would expect that the "en PI" also tried to use 57600 baud, but that because of divisors, they got the 58823.

I would then specify 58823 as the baud rate. The code should try to get "as close as possible" to that number, which would be "on average" closer than when you specify 57600. Worst case, the 57600 gets rounded down a bit, so that you end up just outside of the range around 58823 that "works".

(When the assertions indicate that you're not allowed to use this baud rate, search with the manual in hand for a baud rate inside the range!)