After a lot of digging I learned that some boards (e.g. RP2040, UNO R4) use the so called Arduino Core API. And this uses non-standard definitions for digitalRead() and pinMode().

Thus, you’ll get errors like this: 

invalid conversion from ‚int‘ to ‚PinStatus‘ 

…when you use these two functions.

This problem is know and discussed in this issue here.

One solution is to block boards that use this API. Works of course, but locks out some users.
Another option (which I chose) is to typecast the pins (see my Hardware.h):

void pinMode(int pin, int mode) {
        ::pinMode(pin, static_cast(mode));    
}    
void digitalWrite(int pin, int value) {
        ::digitalWrite(pin, static_cast(value));    
}

This solves the problem.

I finally took the time to start learning how to write unit tests for Arduino/ESPs.

The first tests I wrote were for the button class. Even though I know in theory how to use it as was as time-consuming to get it started – one reasons why I delayed it quite a bit.

I used AUnit as a framework and the tests run on the devices (for now). I’ll look into abstraction with ExpoyDuino later – first steps first.
Some of my learnings: 

• Memory is an issue on these devices (duh!). Some tests randomly did not work due to memory constraints. Took me a while to figure it out.
• Execution speeds of the devices (ESP8266, ESP32, Uno, Nano) vary significantly. I had to increase buffer times for some devices because they were too fast at executing code, causing debounce times to be triggered.
• After getting accustomed to it, writing the tests became quite fast. I went through the readme and wrote tests based on it.
• A small annoyance – the execution order of tests is based on their name with AUnit – not the order found in code. So, I spent some time renaming groups and tests to have a decent order.

Next, I plan to add unit tests to the other two popular classes, ESPTelnet and ESPRotary.

This is part of a larger series, you might want to consider reading parts one and two first.

As promised, I will now discuss the parts of the platform in more detail – starting with the server.

The main job of the server is to connect the prototype’s HTML and the ESP devices via MQTT and WebSockets. In the first iteration, I used Node.js​ and Express to write it, resulting in about 600 lines of code. But since I am a UX designer and not a developer it’s probably best when I don’t write (a lot of) code.
The source code felt a bit crude and overly complex to me. It was hard for someone with little coding experience to get how the server worked. And that made maintaining and changing it hard for regular folks.

continue >

„Umwege erhöhen die Ortskenntnis“ (detours expand local knowledge) was a common saying of my philosophy professor after he went on a tangent during class.

I love the saying and I know the feeling pretty well – it frequently happens to me when I start to get interested in a topic. I start to research something, then I notice another interesting aspect, then another, and then another, and then… I guess you can see a pattern there. It’s similar to the process Dory experiences when she is trying to do something in Finding Nemo.

continue >