[Solved] Compiling a working Firmata firmware for PRi Pico?

[PizzaProgram]

First of all, I'd like to thank for this excellent library! I've red only great things about it everywhere.

I try to improve [ConfigurableFirmata <-> NodeRED] communication to create a reliable solution to handle attached extra boards. (My progress so far is documented here...)
Only CofigurableFirmata can handle Pico boards, StandardFirmata can not.

I've reached the point where the default firmware is not enough for Pico boards. Would like to implement:

• a watchdog (for auto-restart)
• a timer based LED blinking to report board state + hello/keepalive signals
• ... and maybe other functions too. (converted Temperature, etc)

These are all easy with this great library, but nearly impossible with default EmbedOS.

But when I compile Firmata, based on this library, the board stops responding.
It is complicated to debug code running on the board (without spec. cable + other debugger board), so I'm asking for help:

Did anybody run CofigurableFirmata successfully using this lib ?

[maxgerhardt]

But when I compile Firmata, based on this library, the board stops responding.

Can you show which exact sketch you're uploading to the Raspberry Pi Pico, and what serial input you're sending it that makes it stop responding? Or does it immediately lose the serial port after uploading the sketch? I'm looking for a minimum, complete and verifiable example (MVCE) here.

[maxgerhardt]

The ConfigurableFirmata library is buggy as.. well.

It just casually tries to go through all pins that the board offers, from 0 to 29 (TOTAL_PINS = 30), and uses that pin number in an index of Servo points. But that array only has 8 entries.

Notice how pin = 8, #define PIN_TO_SERVO(p) p and MAX_SERVOS = 8, with Servo *servos[MAX_SERVOS];.

The library code completely neglects to check if the index it uses for the array is actually in bounds. It reads a garbage object pointer, tries to interpret that as a Servo object and then calls detach() on it, causing the crash.

The library badly needs a fix to not do such things. The Arduino-Pico core has no problem, as far as I can see.

[maxgerhardt]

Jesus Christ. Someone has already found out the exact same thing that I found out, 3 months ago.

The issue you're having is all documented already.

firmata/ConfigurableFirmata#176

[maxgerhardt]

You were also already aware of this issue blocking the boot? I'm a bit confused now. (firmata/ConfigurableFirmata#115 (comment))

[maxgerhardt]

See firmata/ConfigurableFirmata#184.

[PizzaProgram]

Wow! You are amazing!!! Than you very very much for debugging it. 🎆
You are right:

• I've disabled SERVO, so:

Firmata WORKS NOW with this library too! 👍

OFF:

You were also already aware of this issue blocking the boot? I'm a bit confused now.

Well, me too. That was 6 weeks ago. I've already forgot about that. Probably slept only 3 hours that night, instead of the usual 4.5 .

I have ca 10 different .ino files, tried many things. Most of them was saved with disabled SERVO,
but to test this new board-library, I've re-started from a new sample.
(And forgot to disable the servo. Especially, because it's not on the direct list, along with all the others, but starting with:
ifndef ESP32.
So because Pico is not ESP32 -> My eyes ignored that block. It's also hard to see the difference between ifdef vs ifndef . )

And I never have thought, that running based on this library can have anything to do with SERVO...

Anyway, many thanks ❤️ again, especially the FIX with PUSH. 🥇

PS: I'm a delphi / pascal programmer, with some C# + JS knowledge. C and C++ is not my fav. at all. Especially without proper debugging possibilities.

[PizzaProgram]

Summary - Solution:

The old (<= v3.3.0) ConfigurableFirmata code had a bug, if SERVO was enabled.
Disabling this line helps:

#define ENABLE_SERVO 

About servo - Null problem:

The board.h has a nice definition for all boards:

IS_PIN_SERVO(p)

Don't you think it would be great to add a condition to the first line, like this:

if ( ! IS_PIN_SERVO(p) ) return 0;

?

Temperature

It is very strange, that reading analogue-4 (5th) works great at setup,

float f = analogReadTemp();

but if I do the same with Firmata, no data is coming.

[maxgerhardt]

Every pin on the RP2040 is servo capable. It makes no difference. That check is also already in place.

[PizzaProgram]

Every pin on the RP2040 is servo capable.

No, not every.

Also FYI, Please note, that:

• Firmata isn't just used with Pico only,
• PIN_TO_SERVO is not the same, as IS_PIN_SERVO macro.

For example the ESP32 def is:

#define IS_PIN_DIGITAL(p)       ((p) == 0 || (p) == 2 || (p) == 4 || (p) == 5 || ((p) >= 12 && (p) < 24) || ((p) >= 25 && (p) < 28) || ((p) >= 32 && (p) <= 39))
#define IS_PIN_SERVO(p)         IS_PIN_DIGITAL(p)

[PizzaProgram]

About Temperature (again) - SOLVED too!

but if I do the same with Firmata, no data is coming.

I've solved the temperature reading by adding following lines to the setup() part:

void setup()
{
...
  analogReadResolution(12);
  // send TEMP °C + RawTempValue, formatted as JSON.
#include <stdio.h>
  float c = analogReadTemp();
  char buf[50], buf2[25];
  snprintf(buf , 25, "{\"celsius\": %f, ", c);

#include <hardware/structs/adc.h>
  hw_set_bits(&adc_hw->cs, ADC_CS_TS_EN_BITS);
  delay(1); // Allow things to settle.  Without this, readings can be erratic
  int _rt = analogRead(TOTAL_PINS - 1);
  snprintf(buf2, 25, "\"rawTemp\": %d }", _rt);
  strcat  (buf , buf2);
  Firmata.sendString(F( buf ));	//  float celsius = 27.0f - ((v * vref / 4096.0f) - 0.706f) / 0.001721f;  // const float vref = 3.3f; 
}

Result is:

{"celsius": 23.3933, "rawTemp": 881 }

The main difference was this: analogReadResolution(12);

Without that line, only values like: 219, 220 came always. (Probably because the default resolution is 10bit.)

I can read the same value with Node-RED too ! :-)
Anyway the interesting thing is, that even at max resolution (12 bit) the temp values having too big jumps if I apply the math.
Ca. 0.47 °C jumps between 2 values.

860 => 34.628632 
861 => 34.160488 
862 => 33.692379 
863 => 33.224236 
864 => 32.756092 
865 => 32.287949 
866 => 31.819803 
867 => 31.351692 
868 => 30.883549 
869 => 30.415405 
870 => 29.947262 
871 => 29.479116 
872 => 29.011007 
873 => 28.542864 
874 => 28.074718 
875 => 27.606575 
876 => 27.138432 
877 => 26.670322 
878 => 26.202177 
879 => 25.734034 
880 => 25.265888 
881 => 24.797745 
882 => 24.329636 
883 => 23.861492 
884 => 23.393347 
885 => 22.925203 
886 => 22.457060 
887 => 21.988949 
888 => 21.520805 
889 => 21.052662 
890 => 20.584518 
891 => 20.116373 
892 => 19.648264 
893 => 19.180119 
894 => 18.711975 
895 => 18.243832 
896 => 17.775688 
897 => 17.307579 
898 => 16.839434 
899 => 16.371290 
900 => 15.903146 
901 => 15.435001 
902 => 14.966892 
903 => 14.498748 
904 => 14.030603 
905 => 13.562460 
906 => 13.094316 
907 => 12.626206 
908 => 12.158062 
909 => 11.689918 
910 => 11.221774 
911 => 10.753630 

(generate full list here

[PizzaProgram]

Question:

• How can I know, if this library is active, so I can put an #ifdef ... around this code?

[PizzaProgram]

Can you give me a hint to this question too ?

[earlephilhower]

Sorry, I don't understand the question. The ifdef stuff in the other note detects the core (arduino-pico vs mbed-rp2040).

[PizzaProgram]

Well, if this is the only way:

!defined(__MBED__)

and there is nothing specific to identify your library, (something like: ifdef(EALREPHIL)), than I accept it.
Let's "hope" there will be no 3th library in the future.

[PizzaProgram]

Question2:

• How can I add Pico2 (and compatible) boards to the list of boards.h ?

This is the current code for Pico(1) :

#elif defined(TARGET_RP2040) || defined(TARGET_RASPBERRY_PI_PICO)
...

I've tried these, but none worked:

#elif ... || defined(TARGET_RP2350) || defined(GENERIC_RP2350) || defined(RASPBERRY_PI_PICO_2)

Thanks for the help in forward!

[maxgerhardt]

The https://github.com/arduino/ArduinoCore-mbed core also supports RP2040 (only the Raspberry Pi Pico variant), and is mbed-os based, so this is checking essentially for the that specific core.

[PizzaProgram]

@earlephilhower IMHO it would have been made things much easier if you had simple defined "B" too.
instead of:

#if defined(PICO_RP2350A) && !PICO_RP2350A

Because now we have to make complicated conditions to distinguish between RP2040 and RP2350A ...
instead of simply writing:

#if defined(PICO_RP2350B)
  #define TOTAL_ANALOG_PINS       9
  #define TOTAL_PINS                     49
#else 
  // ... valid both RP2040 + RP2350A
  #define TOTAL_ANALOG_PINS       5
  #define TOTAL_PINS                     31

Since RP2350B is the one, that differs from the other 2 chips.

• Is it too late?
• Or can you maybe add that +1 line to your next release?

[earlephilhower]

That is the way the SDK does it, so we match. Not really a fan, but that's where we are now. See the SDK and raspberrypi/pico-sdk#2364

[PizzaProgram]

Found that PICO_RP2350B definition in your code! See here ...

[earlephilhower]

Bug, fixed in #2910

[PizzaProgram]

Anyway, has anybody else realised:

Those numbers defined here are BOTH WRONG !

#if defined(PICO_RP2350) && !PICO_RP2350A
#define __GPIOCNT 48
...
#else
#define __GPIOCNT 30
...

Because actually there are 49 & 31 pins, if we count the ADC Temperature sensor !

This code only works, because you are subtracting a 0th item based array from a "counter" (which starts from: 1th):

extern "C" float analogReadTemp(float vref) {
...
    adc_select_input(__GPIOCNT - __FIRSTANALOGGPIO); // Temperature sensor

I know, it's not your fault, because the whole RPI documentation is strange. Even if I summarise it with IA, it says it's just 30/48 pins, while it is NOT.
Crazy engineers. It's like they were not sure, if the TEMP reader would work properly, and added only as a "hint" to the docs, and not counting with it from start on.

26+4+1 = ?
40+8+1 = ?

[earlephilhower]

No, there are only those # of GPIOs. The ADC has an extra input leg but it's not general purpose, wired to a pad mux, or part of the SIO.

If you really want to manually read out the raw temp ADC value, then you'll need to use the raw SDK calls, but be sure to restore any state that the wiring_analog uses.

[PizzaProgram]

OFF

If you really want to manually read out the raw temp ADC value, then you'll need to use the raw SDK calls, but be sure to restore any state that the wiring_analog uses.

Thank you for the warning!

I'm not talking about physical GPIOs, but programmable analogue ports.
That's what counts for us, programmers.
There are many other boards, which offer much less phisical IO than the chip would support, yet, we do not block the function of those. Do we?
Since I've fixed the code at Firmata, by increasing the port numbers by +1, everything works fine!
I did not wrote Firmata, and it's not me, who will rewrite the whole thing to support 1-2 type of board better, than how it is now.
So raw temp ADC it is, how it is working now.

Your code is awesome! I really like how you guys built up all of this, and I would like to thank you all in name of all PRi programmers. 🥇