... it should not be the first step.
The whole idea is that this is the only step, which saves you time which you would otherwise spent on other steps, also will decrease bloat in your code. I'll try to explain by example:
I did this for example with the UART.
Ok, Let's take UART as an example. Let's say I have to receive something by UART in my code. Here's how I would do it.
1. ThinkingI first think how I receive the characters from UART. I can create an ISR for UART, or I can poll in the main loop, or I can poll from within a timer ISR (shared with other processes), or I can use DMA. This depends on the UART speed, the overall structure of the program, the structure of the information etc.
Then I think of where and when I am going to parse and process the data. I may do parsing immediate. Or I may delayed until I have more time, in which case I need a buffer.
Then I think of buffering, which must meet few criterea:
- the buffer must be big enough to store all the data I receive until the parser is able to process it
- the buffer must be able to continue receiving characters while the parser processes it
- if the information comes in chuncks (e.g. packets or lines), the buffer must be big enough to fit full chuncks (although this might be impossible)
I may decide that I don't need any buffers at all (e.g. hardware FIFO with UART module is sufficient), or I may use a circular buffer, or I may need a ping-pong buffers (i.e. one buffer gets processed while the other is filled in), or I may decide on a linked list of packets. Whatever I can see fit.
Then I think how parser is going to read data from the buffer, and make sure that it will be easy to write the parser.
Once I thought this through, I can start writing code, but I don't write anything until all the parts of the system are thought through.
How long does the thinking take? In simple case less than a minute. But it may take couple hours if the case is unusual or difficult. I may consult the UART module datasheet, DMA datasheet etc.
2. CodingI usually write in pieces - I write the smallest piece than I can, then I test and verify that it works, then I add the next piece.
UART is very simple, so I would probably make an exception and wrote receiving and buffering all at once. Most likely, I have already written something similar, so I find it, paste it, and edit it - this saves lots of typing. Instead of the parser, I create a small routine which outputs the data with printf or similar. This way I can see what will be received by the parser.
Once written I compile to eliminate all typos and make sure there's no compiler warning.
Coding will take about 10 minutes. But it totally depends on how much you need to type and whether or not you need intermediary testing.
3. TestingI would create use cases trying to break my receiving mechanism by varying speed, content, limits. For example, if the receiving involves parsing the input into the lines, I would test various line delimiters, empty lines, enormously long lines etc.
Testing usually takes the longest. It is only few minutes with a simple circular buffer, but if something is not working it will need fixing. Or if buffers are more complex, it may take hours to fully test and fix all the bugs.
I don't feel that if someone would give me a code I could incorporate it into my process in any way. I would still need to do some coding interfacing the foreign code. I would have to eliminate thinking and succumb to whatever is offered by the foreign code. The data for the parser would arrive in the format dictated by the foreign code, and with timing dictated by the foreign code. This would create problems later, when I need to write parser. Overall, instead of doing my own design as I please, I would have to adjust everything to meet the requirements of the foreign code. What for?
Home
Help
Search
Login
Register
Topic: Is ST Cube IDE a piece of buggy crap? (Read 211622 times)