While it may not seem so, from last log entry I made significant advances on this new revision of the project. Thus, I wanted to tell a bit of the project status.
You may also noticed I renamed the project to BicycleCompanion (dropped the MINI suffix) since I feel this is still the original project but with one more refinement step. I also renamed the (never finished) teensy-based project so that no confusion is generated.
It is also interesting that from all my (four) projects on Hackaday, this one received a constant influx of about 100 views per week. While it may be the result of google crawling the site I choose to think that there's at least some interested people. So, I hope to provide more project updates soon to show my progress.
While it may not be the typical choice, I'm particularly inclined towards writing the firmware for my electronics projects using the NuttX real-time operating system. In contrast to other RTOS, NuttX feels like a "tiny Linux" in that it is POSIX compatible and aims for high-level hardware abstractions. This is very good to decouple the logic from the specific hardware and maximize re-usability. However, it also comes at the cost of a steeper learning curve and friction than simple hacking something using Arduino.
As an initial development platform for BicycleCompanion, I chose to work on the ST Nucleo L476RG board, which has very good support on NuttX and also provides a very nice set of features. However, there are always some little (and not so little) things to improve in NuttX once one starts to poke around various parts of the OS.
Besides some small required changes (like adding support for low-power hardware timers or LPTIM) I found that the power-management algorithm baked into NuttX was a bit high-level and did not let one to have tight control over entering and exiting low-power run modes. For this reason, during the last few weeks I reworked NuttX PM system to allow for different PM algorithms. In particular, I added a separate "greedy" algorithm that always tries to go as soon as possible into a low-power run mode (unless an application or driver requests it to stay at a specific level). This is working really well and I have already handled STOP mode on the STM32L4 succesfully.
A second important step was to tame the Sharp Memory LCD. While a driver was already present in NuttX it didn't quite fit in a low-power setting. Specifically, the Sharp Memory LCD requires a pulse between 1-60Hz to be sent all time to maintain the currently displayed data visible and at the same time avoid burn-in. The NuttX driver used a simply pin toggling mechanism tied to a timer interrupt. Thus, taking advantage of one of the LPTIM timers, I added support for PWM generation using this peripheral, which allows me to send the required pulse, even while the MCU is in deep sleep. This is also working perfectly.
In regards to the display, I also added support for the latest littlevgl library in NuttX (it officially supports an older version) and developed a simpler driver to access the LCD from littlevgl. So far I have managed to start designing a very simple system of different screens (time, speed, etc.) and a boring splash screen.
My next and final step before going into building a BicycleCompanion prototype is to test the other LPTIM in pulse-counting mode, to sense the bicycle wheel turning. I originally considered (as in the previous BicycleCompanion design) a latching hall sensor to receive pulses whenever the magnet of the wheel passed over it. However, after looking at various models, all Hall sensors tend to be a bit power hungry (a few mA when measuring). After much consideration I decided to go the easy and zero-power way: use a plain reed switch. This also has the advantage that I do not need to fabricate all the sensor mounting and so on, since there are hundreds of cheap bicycle computers and can try this on.
I have more or less finalized the schematic for BicycleCompanion. I added everything I could think I would need but I could probably add other (experimental) components. For example, I'm unsure if I should add some front light system for the LCD or not. I'm not sure if it would look good enough to justify its use. Anyway, I have many free pins so if you have a recommendation for something else to add, please let me know! (but please have in mind that I'm looking into supply currents measured in uA).
At the moment this is how much of the MCU is under used. As I said, many free pins (and peripherals) still available. The USART will probably be exposed to pins for easy access to NuttX console.And this is the typical basic set of components required for most MCUs. I'm using the HSI 16MHz internal clock so I only need the 32.768Hz crystal to feed the RTC (and also devices such as the LPTIMs). There is the reset pin and all decoupling caps. The included jumper is to allow me to measure the current consumption of the final device by placing a meter in series.