ESP-8266 Compatibility unconfirmed

[BjarneBitscrambler]

ESP-8266 compatibility isn't confirmed by actual testing on hardware.

I've ordered a d1_mini for this purpose.

[DanielG86]

Hello Bjarne,
I've got a d1 mini, so I could help (if I've got the time).
I'm a bit struggling with the code if it is not integrated into SensESP, which I sort of understand. I'm running on a Mac, so the NXP software to test is not much of a help for me.

[BjarneBitscrambler]

Hi Daniel, Great! Being on a Mac shouldn't be too much of a problem, as I have enough of a "wrapper" around the fusion code now that you can get output in the form of regular text streamed to a serial port, for example. If you really did want to try the Toolbox, then perhaps it would run under Parallels or something like that on the Mac, but it isn't essential to use it. If you clone the sensor fusion repository ( https://github.com/BjarneBitscrambler/OrientationSensorFusion-ESP.git) to your local drive, and compile the main.cc that is in the /src folder of the project (*not* the SensESP main.cpp), then you should end up with an executable that prints a timestamp, heading, pitch, roll, and turn rate constantly to the serial terminal every 250ms. It also outputs the same data to a WiFi TCP connection to port 23 of the ESP board, but I'd try seeing if the serial port output works first. So basically, try compiling and running the fusion code as a totally new ESP8266 project (without any SensESP code/libraries). There's some more detail on compiling the project in the Readme.md, but if any of this isn't clear enough then let me know what's puzzling and I'll fix up the documentation. I'd love to hear whether it runs on an ESP8266 processor, and if not hopefully get it working there too. One of the reasons it might not, right away, is differences in things like the WiFi library. I believe I have put in the right stuff, but... Good luck, and let me know how it goes! Cheers, Bjarne

…

On Sun, Nov 29, 2020 at 11:47 AM DanielG86 ***@***.***> wrote: Hello Bjarne, I've got a d1 mini, so I could help (if I've got the time). I'm a bit struggling with the code if it is not integrated into SensESP, which I sort of understand. I'm running on a Mac, so the NXP software to test is not much of a help for me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQJATFLE6QB26V2KHNIPE4DSSKQLZANCNFSM4T6A4MPA> .

[BjarneBitscrambler]

I received a couple d1_minis, and will start testing.

After making a few changes to the example main.cc (found in the /examples/ project subfolder), now have orientation output on the d1_mini (ESP8266). It turns out that the ESP8266 treats the loop() function differently than the ESP32 does. On the ESP32 it is acceptable to continuously execute a while() loop inside loop(), whereas on the ESP8266 this causes a watchdog timeout.

The solution was to pull the sensor read & fusion & print code out of the while(true) and just have it standing alone in loop(). This also required moving the variables that were declared at the top of loop() outside the function (i.e. making them globals).

I'll do some more in-depth testing, but for now it looks like the code works on the ESP8266.

[BjarneBitscrambler]

An interesting difference between the two platforms popped up: the compiler for ESP8266 catches an error that is missed by the ESP32 compiler. In the sample main.cc. there was an unterminated while( true ) { ... in the loop() function. That is, there was no ending } brace for the while. The compiler saw the ending brace for the loop() function and was happy enough with that, when compiling for ESP32. As soon as the platform was switched to ESP8266, there was a compile error about the missing brace.

This is possibly related to the observation of the previous comment, in which the loop() function is treated differently on the two platforms.