This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CMSIS UART Driver, permanent receive not available?

Hello All,

in the CMSIS there is a framework for UART communication.
However I have to know in advance how many characters to receive.

I would have expected that UART driver write to kind of circular buffer permanently.

Because usually I do not know WHEN there is communication and HOW MANY data will be transmitted.
I assume that when I abort the receive function with timeout and start again the receive function that in the mean time I might loose data on the hardware. Because if the receive function is not active no DATA AVAILABLE event will be handled.

In my real live projects I only use the UART transmit functions and reimplement my custom receive functions.

How does CMSIS address this issue?
What is the best practice here?

Best regards.

Adib.

Parents
  • The reason I did ask about if the CMSIS implementation could make use of any FIFO or similar between the calls is that I prefer lots of control - so I use own code as often as possible, and have stayed away from all CMSIS functionality.

    It's often very quick to port code between processors and I get the same API for the business logic. Own code means I can always take advantage of any extra hardware features. And I can do it the same day I see the need, instead of having to wait and hope for a driver-layer update.

    The biggest advantage with own code is that it forces me to read the datasheet and evaluate each individual configuration bit to see what nice bonus functionality I can find and make use of. With a pre-cooked driver layer, it's easy to forget to read the processor documentation and figure out exactly what limits the hardware has.

    Quite a lot of the hardware tends to be quite easy to control until reaching the Linux-class of processors.

Reply
  • The reason I did ask about if the CMSIS implementation could make use of any FIFO or similar between the calls is that I prefer lots of control - so I use own code as often as possible, and have stayed away from all CMSIS functionality.

    It's often very quick to port code between processors and I get the same API for the business logic. Own code means I can always take advantage of any extra hardware features. And I can do it the same day I see the need, instead of having to wait and hope for a driver-layer update.

    The biggest advantage with own code is that it forces me to read the datasheet and evaluate each individual configuration bit to see what nice bonus functionality I can find and make use of. With a pre-cooked driver layer, it's easy to forget to read the processor documentation and figure out exactly what limits the hardware has.

    Quite a lot of the hardware tends to be quite easy to control until reaching the Linux-class of processors.

Children
  • "The biggest advantage with own code is that it forces me to read the datasheet and ..."

    Exactly so and I've always done the same.

    Actually, I agree with all you wrote there.

    Unfortunately, in my experience I'd say that it's not a very common point of view; and for various reasons. Just yesterday a new manager was forced on me. He comes from a Windows/Microsoft background and thinks embedded systems must be developed in the same way. Why develop a component when you can just drop an existing one from someone else into a project? Heated discussions ahead.