I’ve been working through the first CE projects and having a lot of fun with it. I didn’t send out any boards for manufacture for Getting To Blinky because I had a stupid idea to do something more with that. I’ll write about it when it’s finished. It’s nothing very exciting, but I find it quite amusing: programmatically generating Morse code blinkies with some Python code for placing logic onto 74xx chips and using SKIDL to generate netlists. Totally useless, but good for learning some things. I’m going to work on that tomorrow, and hopefully get it finished so I can go on to more useful things.
In a more sensible vein though, I’ve been working on the CE Header project. That has been interesting mostly because of the huge amount of time I took trying to make sure the various connectors were the right way round. It’s amazing how confusing that can be. First I tried to do it in my head, just staring at the footprints in KiCad.
Then I gave up with that and made some paper models, one for the Teensy, one for the Teensy breakout board and one for the sensor board, and sat at my desk trying to convince myself that things would line up right. That was enough to convince myself that I had things the right way round for connecting the Teensy to the breakout board.
It wasn’t quite convincing enough for the CE header itself though, so I spent an hour or two working out how to quickly get 3D models for a “CE header plug” and “CE header socket” together. That was easy enough in FreeCad, because it just involved chopping some pins out of existing models for 2x10 pin headers and sockets (make a “cube”, do a Boolean difference, repeat until done). Finally convinced that everything was OK, I just ordered the boards!
The main lesson learned from this was that some little things can be surprisingly time consuming…
I’ve also been doing some nRF52840 firmware programming for work this week. I had been having all sorts of problems with instability using the OpenThread networking protocol, and had been blaming it on all sorts of things, none of which were my fault. It turns out though, that when Nordic say “the OpenThread SDK is not thread-safe”, they really mean it! I had been trying to protect all the OpenThread SDK calls with mutexes (I’m using FreeRTOS), but there always seemed to be one more place that wasn’t properly protected, so I was making race conditions rarer but they never really went away.
In the end, I gave in and did what I should have done in the first place, which was to turn everything inside out and make the OpenThread SDK access “manifestly thread-safe” by using message-passing through a FreeRTOS queue from the other threads that wanted to do OpenThread things, and having a single “OpenThread server” task pull commands from that queue and service them. That ensures that all OpenThread SDK calls happen in the context of that one task, and also that all callbacks from the OpenThread SDK happen in the context of a single thread (I think this is what had been causing the trouble before).
Fingers crossed, but it’s been running without problems for 6.5 hours now…