The last training course that I followed was about programming microcontrollers. The course was given by Leon van Snippenberg, who has very good expertise in microcontrollers.
For the practical part of the course we used the Microchip dsPIC33F, a 16-bit architecture 40 MHZ microcontroller (system on a chip solution). I admit that I'm not very fond of this proprietary platform, so I enjoyed the theoretical part of the course much more than the practical. I would be more excited if we have used an open hardware solution like arduino, Raspberry Pi, or something comparable.
A few highlights from the course:
Continued with adding some basic components like a button
And at some point I built my first practical prototype: a darkness-activated LED
Isn't that nice? In my future posts the plan is to spend more time on explaining the code of prototypes like the last one. For now you can check my mbed repository page.
For the practical part of the course we used the Microchip dsPIC33F, a 16-bit architecture 40 MHZ microcontroller (system on a chip solution). I admit that I'm not very fond of this proprietary platform, so I enjoyed the theoretical part of the course much more than the practical. I would be more excited if we have used an open hardware solution like arduino, Raspberry Pi, or something comparable.
A few highlights from the course:
- A three-operand assembly instruction does not necessarily mean that three registers are used. For example ADD W0, W1, W0 uses only one register.
- Most microcontrollers use the Harvard instead of the Von Neumann architecture. This means that there are two distinct address buses, as well as two data buses (instead of one address and one data bus).
- When writing code in assembly we should avoid thinking about code optimisation, since the code is usually very fast to execute (but very slow to produce).
- A common problem when programming microcontrollers is read-modify-write. One way to solve it is using shadow registers.
- When programming a microcontroller using a C interface and interrupts, it is very important to use the volatile keyword to disable optimisations that might remove code that seems to be dead but is actually used. Because of that, it is also very important to test the code with all compiler optimisation levels enabled, to ensure that it doesn't break.
- The hardware timers of a platform do not need to follow the same architecture with the processor. For example a platform might use a 16-bit processor with 32-bit timers.
- Buffers and interrupts are used to solve communication problems between different devices (e.g. a computer communicating with a microcontroller using the serial port).
- When dealing with non-deterministic problems, disabling interrupts is the most favoured solution.
- Using a real-time operating system (RTOS) simplifies programming, because we avoid the need to write complex state machines and custom schedulers (those problems are already solved in the RTOS).
- Multicore support in RTOS is a challenge (unsolved problem?).
We (me and my colleague) challenged Leon by questioning why would one prefer a much more expensive solution like the dsPIC* family of Microchip instead of Raspberry Pi or arduino. The price of the latest Pi is unbeatable. The response was that we should use whatever fits our purpose, and that the Pi manages to achieve such a low price because its makers can estimate in advance the minimum numbers of units that will be sold. Those manufacturing deals are critical in forming the end price of a prototyping platform.
So far I only own an mbed LPC1768 and I'm very satisfied with it. I hope that I'll build some more advanced prototypes in the future, but you have to start from something. I began with flashing LEDs
Continued with adding some basic components like a button
And at some point I built my first practical prototype: a darkness-activated LED
Isn't that nice? In my future posts the plan is to spend more time on explaining the code of prototypes like the last one. For now you can check my mbed repository page.