A couple of cents about microcontrollers
I had the opportunity to work for three years in a company that was engaged in embedded systems, namely, automation, that drives the trains. Hard real time, serious testing and gnawing microseconds wherever possible. I’ll try to give a couple of tips to those who are interested in embedded systems (and from the posts on the hub, I realized that there are quite a few of them ;-) The
hardware was not weak at all - C167, 16 MHz clock, external bus with 4 chipset, a bunch of peripherals on a stone ... Yes, and the tasks were such that they barely had enough glands - polling almost 2000 discrete inputs, and even with a clever cyclogram, packing data into special structures and exchanging this information over CAN networks ... And all this - in 1 millisecond !
And now - tips :-) Not always true and applicable to your stone, but suddenly help.
Consider all your systems to be brutal real-time systems. That is, systems where the response to external influences should be no later than the nth amount of time. A minimum is also desirable ;-)
The main () function should end with an infinite loop. Without any return whatsoever. For the devil knows where control will be transferred after leaving it!
Consider the state of the system in which it will bring minimal harm! The so-called protective failure. If suddenly the position sensor of the executive body falls off at the robot - it must STOP, and not try to move to a safe position (where it goes with the chopped off sensor - it also knows the devil). It would be nice for the user to know that the device is in this state. For example, setting the clock to 88:88 is better than leaving the display unchanged. It is very useful to check the equipment connected to the microcontroller, at least during initialization. Not everything can be verified, but what is possible is a must!
About real time. The program for the microcontroller is multi-threaded in most cases, and main () should be a thread with minimal priority. Higher priority threads are interrupt handlers. Interrupts should not be disabled unless absolutely necessary (for example, switching to a protective failure state). The interrupt handler should not be executed longer than the minimum period between interruptions, otherwise the time system for less priority tasks will not remain. And as time to evaluate - it's so simple. One leg of the output of the microcontroller should not be very important for the functioning of the device. It is ideal to connect an LED to it and signal to them about everything that is possible :-) In general, switching the state of this leg will help with the help of an oscillator to measure the execution time of anything :-)
Properly prioritize interrupts! In watches, priority is given to control buttons. If there is an emergency stop button, it should have the highest priority: you never know what will happen in the device and where it will loop, but it should be possible to stop it. Alarms are the highest priority, followed by the importance of device functions.
It is very important to consider the execution time of the processor and the frequency of interruptions for communication tasks. Suddenly it turns out that interrupts on the COM port occur every 10 μs and the processor hangs in it 9 μs. As I wrote above, programs are multi-threaded, so use synchronization when accessing the same object from different threads. Especially to the transmission and reception queues. One small bug in the queues, combined with the high priority of communication interruptions - does terrible things! :-)
Know and love the equipment! Problems on the bus can result in long hours of debugging and irreproducible glitches. Using assembler is far from always justified: winning in percentages of time can lead to poor readability of the code, especially considering good compilers for some stones :-)
Here, it seems, he remembered most of the underwater rake he was attacking. Maybe you are making completely frivolous gadgets for fun, and hard real-time is not necessary at all, but why not making gadgets with a serious approach? Suddenly, exactly with these “toys” will your road to serious systems begin? Good luck to everyone in the design, programming and debugging :)
PS. If the public says that there is a collective blog for something like that, I will postpone it right there.
PPS Thanks to the commentators - they came up with yet another piece of advice: interrupts are good, but polling in a loop where interrupts can be used is evil! Although the interruptions seem scary and terrible :-)
hardware was not weak at all - C167, 16 MHz clock, external bus with 4 chipset, a bunch of peripherals on a stone ... Yes, and the tasks were such that they barely had enough glands - polling almost 2000 discrete inputs, and even with a clever cyclogram, packing data into special structures and exchanging this information over CAN networks ... And all this - in 1 millisecond !
And now - tips :-) Not always true and applicable to your stone, but suddenly help.
Consider all your systems to be brutal real-time systems. That is, systems where the response to external influences should be no later than the nth amount of time. A minimum is also desirable ;-)
The main () function should end with an infinite loop. Without any return whatsoever. For the devil knows where control will be transferred after leaving it!
Consider the state of the system in which it will bring minimal harm! The so-called protective failure. If suddenly the position sensor of the executive body falls off at the robot - it must STOP, and not try to move to a safe position (where it goes with the chopped off sensor - it also knows the devil). It would be nice for the user to know that the device is in this state. For example, setting the clock to 88:88 is better than leaving the display unchanged. It is very useful to check the equipment connected to the microcontroller, at least during initialization. Not everything can be verified, but what is possible is a must!
About real time. The program for the microcontroller is multi-threaded in most cases, and main () should be a thread with minimal priority. Higher priority threads are interrupt handlers. Interrupts should not be disabled unless absolutely necessary (for example, switching to a protective failure state). The interrupt handler should not be executed longer than the minimum period between interruptions, otherwise the time system for less priority tasks will not remain. And as time to evaluate - it's so simple. One leg of the output of the microcontroller should not be very important for the functioning of the device. It is ideal to connect an LED to it and signal to them about everything that is possible :-) In general, switching the state of this leg will help with the help of an oscillator to measure the execution time of anything :-)
Properly prioritize interrupts! In watches, priority is given to control buttons. If there is an emergency stop button, it should have the highest priority: you never know what will happen in the device and where it will loop, but it should be possible to stop it. Alarms are the highest priority, followed by the importance of device functions.
It is very important to consider the execution time of the processor and the frequency of interruptions for communication tasks. Suddenly it turns out that interrupts on the COM port occur every 10 μs and the processor hangs in it 9 μs. As I wrote above, programs are multi-threaded, so use synchronization when accessing the same object from different threads. Especially to the transmission and reception queues. One small bug in the queues, combined with the high priority of communication interruptions - does terrible things! :-)
Know and love the equipment! Problems on the bus can result in long hours of debugging and irreproducible glitches. Using assembler is far from always justified: winning in percentages of time can lead to poor readability of the code, especially considering good compilers for some stones :-)
Here, it seems, he remembered most of the underwater rake he was attacking. Maybe you are making completely frivolous gadgets for fun, and hard real-time is not necessary at all, but why not making gadgets with a serious approach? Suddenly, exactly with these “toys” will your road to serious systems begin? Good luck to everyone in the design, programming and debugging :)
PS. If the public says that there is a collective blog for something like that, I will postpone it right there.
PPS Thanks to the commentators - they came up with yet another piece of advice: interrupts are good, but polling in a loop where interrupts can be used is evil! Although the interruptions seem scary and terrible :-)