We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
I've never understood the perceived requirement to use CMSIS.
If it can be used and does the job, then fine.
If it doesn't do something needed, write an alternative. It's certainly not difficult to write a UART driver from scratch. Then, the only person you can complain to when something doesn't work is yourself.
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.
"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.