Wrong Define Topic is solved

[tfAteba]

Hi Giovanni,

I'm trying to implement the serial communication to exchange data with an RFID card Reader.

I then try to do it by using event like in this documentation: http://www.chibios.org/dokuwiki/doku.php?id=chibios:book:kernel_events
But the code don't compile because:
SERIAL_FRAMING_ERROR, not define
SERIAL_PARITY_ERROR, not define
SERIAL_DATA_IN, not define

I saw that in the HAL RM 4.0.3 there was similar definition:
SERIAL_FRAMING_ERROR define as: SD_FRAMING_ERROR.
SERIAL_PARITY_ERROR define as: SD_PARITY_ERROR.
For SERIAL_DATA_IN, I din't found a definition on the reference manual. I will try to look on the HAL Driver.

So may be you have to update the documentation?
What about SERIAL_DATA_IN then?

Cheers,

Theo.

[Giovanni]

The book uses generic definitions, not HAL ones.

About HAL, the serial driver adds its defitions to those defined in hal_channels.h:

Code: Select all

/**
 * @name    I/O status flags added to the event listener
 * @{
 */
/** @brief No pending conditions.*/
#define CHN_NO_ERROR            (eventflags_t)0
/** @brief Connection happened.*/
#define CHN_CONNECTED           (eventflags_t)1
/** @brief Disconnection happened.*/
#define CHN_DISCONNECTED        (eventflags_t)2
/** @brief Data available in the input queue.*/
#define CHN_INPUT_AVAILABLE     (eventflags_t)4
/** @brief Output queue empty.*/
#define CHN_OUTPUT_EMPTY        (eventflags_t)8
/** @brief Transmission end.*/
#define CHN_TRANSMISSION_END    (eventflags_t)16
/** @} */

Giovanni

[tfAteba]

Hi,

Thanks Giovanni.

While waiting your answer, I try to implement the serial reception without event. I used a trhead to with the non blocking function to check every 100ms for example to see id data were transmeted.

Then I want to understand the difference if I use an event to do the job .

And wath is the best way to receive an undefine nomber of data? Because when I will read my RFID card serial Number, no problem it is a fixed size but it is not the case of other parameter I need to read.

I will appreciate if you have a topic or document on the subject.

Thanks,

Theo

[Giovanni]

The best way is to write a state machine around your protocol, wait for serial events and read/write data in non-blocking mode (TIME_IMMEDIATE), then drive the state machine with the received data. The only point where you would wait is chEvtWaitTimeout().

The state machine also allows you you handle errors and timeouts. If you think to not have to handle errors and timeouts then you are doing something wrong

Giovanni

[tfAteba]

Hi,

Cool, I'm then first going to look how make a state machines.

thanks.

[steved]

The best way is to write a state machine around your protocol, wait for serial events and read/write data in non-blocking mode (TIME_IMMEDIATE), then drive the state machine with the received data. The only point where you would wait is chEvtWaitTimeout().

The state machine also allows you you handle errors and timeouts. If you think to not have to handle errors and timeouts then you are doing something wrong

Giovanni

Just to clarify, I'm sure the advice used to be to use the UART driver (rather than the serial driver) when you need a state machine operating off the received data - because of the support for "per character" callbacks. (Certainly works fine for me, especially using the UART interrupt-driven). Has this advice changed at all?

[tfAteba]

Hi steved,

I don't konw, I did not understand it like that.

[Giovanni]

Both the serial and UART driver are suitable for state machines.

The main difference is events vs callbacks. Serial is best if the state machine is not driven by just the serial port but also other event sources, UART is preferable if it is mostly a callback/ISR kind of state machine.

It also depends if there are also large transfers involved, in this case UART is best. If it is mostly a char by char thing then serial is OK too.

Giovanni

[tfAteba]

Thanks for those clarifications Giovanni!