OpenSprinkler Forums OpenSprinkler Unified Firmware Problems with gpiod v2

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #83335

    psmedley
    Participant

    Hey all,

    Heads up – I updated one of my Pi’s that runs opensprinkler to trixie, and it comes with gpiod v2 which has a different API.

    I get the following trying to rebuild the firmware:

    gpio.cpp: In function ‘int assert_gpiod_chip()’:
    gpio.cpp:242:25: error: ‘gpiod_chip_iter’ was not declared in this scope; did you mean ‘gpiod_chip_open’?
      242 |                         gpiod_chip_iter *iter = gpiod_chip_iter_new();
          |                         ^~~~~~~~~~~~~~~
          |                         gpiod_chip_open
    gpio.cpp:242:42: error: ‘iter’ was not declared in this scope
      242 |                         gpiod_chip_iter *iter = gpiod_chip_iter_new();
          |                                          ^~~~
    gpio.cpp:242:49: error: ‘gpiod_chip_iter_new’ was not declared in this scope; did you mean ‘gpiod_chip_open’?
      242 |                         gpiod_chip_iter *iter = gpiod_chip_iter_new();
          |                                                 ^~~~~~~~~~~~~~~~~~~
          |                                                 gpiod_chip_open
    gpio.cpp:244:43: error: ‘gpiod_chip_iter_next’ was not declared in this scope; did you mean ‘gpiod_chip_open’?
      244 |                         while (tmp_chip = gpiod_chip_iter_next(iter)) {
          |                                           ^~~~~~~~~~~~~~~~~~~~
          |                                           gpiod_chip_open
    gpio.cpp:245:45: error: ‘gpiod_chip_label’ was not declared in this scope; did you mean ‘gpiod_chip_open’?
      245 |                                 if (!strcmp(gpiod_chip_label(tmp_chip), chip_name)) {
          |                                             ^~~~~~~~~~~~~~~~
          |                                             gpiod_chip_open
    gpio.cpp:247:41: error: ‘gpiod_chip_iter_free_noclose’ was not declared in this scope
      247 |                                         gpiod_chip_iter_free_noclose(iter);
          |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    gpio.cpp:253:25: error: ‘gpiod_chip_iter_free’ was not declared in this scope; did you mean ‘gpiod_chip_info_free’?
      253 |                         gpiod_chip_iter_free(iter);
          |                         ^~~~~~~~~~~~~~~~~~~~
          |                         gpiod_chip_info_free
    gpio.cpp:255:32: error: ‘gpiod_chip_open_by_name’ was not declared in this scope; did you mean ‘gpiod_chip_info_get_name’?
      255 |                         chip = gpiod_chip_open_by_name("gpiochip0");
          |                                ^~~~~~~~~~~~~~~~~~~~~~~
          |                                gpiod_chip_info_get_name
    gpio.cpp: In function ‘int assert_gpiod_line(int)’:
    gpio.cpp:271:35: error: ‘gpiod_chip_get_line’ was not declared in this scope; did you mean ‘gpiod_chip_get_info’?
      271 |                 gpio_lines[pin] = gpiod_chip_get_line(chip, pin);
          |                                   ^~~~~~~~~~~~~~~~~~~
          |                                   gpiod_chip_get_info
    gpio.cpp: In function ‘void pinMode(int, unsigned char)’:
    gpio.cpp:290:25: error: ‘gpiod_line_request_input’ was not declared in this scope; did you mean ‘gpiod_line_request_get_fd’?
      290 |                         gpiod_line_request_input(gpio_lines[pin], gpio_consumer);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~
          |                         gpiod_line_request_get_fd
    gpio.cpp:293:88: error: ‘GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP’ was not declared in this scope
      293 | od_line_request_input_flags(gpio_lines[pin], gpio_consumer, GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP);
          |                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    gpio.cpp:293:25: error: ‘gpiod_line_request_input_flags’ was not declared in this scope; did you mean ‘gpiod_line_request_set_values’?
      293 |                         gpiod_line_request_input_flags(gpio_lines[pin], gpio_consumer, GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |                         gpiod_line_request_set_values
    gpio.cpp:296:25: error: ‘gpiod_line_request_output’ was not declared in this scope; did you mean ‘gpiod_line_request_get_fd’?
      296 |                         gpiod_line_request_output(gpio_lines[pin], gpio_consumer, LOW);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
          |                         gpiod_line_request_get_fd
    gpio.cpp: In function ‘unsigned char digitalRead(int)’:
    gpio.cpp:313:19: error: ‘gpiod_line_get_value’ was not declared in this scope; did you mean ‘gpiod_line_value’?
      313 |         int val = gpiod_line_get_value(gpio_lines[pin]);
          |                   ^~~~~~~~~~~~~~~~~~~~
          |                   gpiod_line_value
    gpio.cpp: In function ‘void digitalWrite(int, unsigned char)’:
    gpio.cpp:331:15: error: ‘gpiod_line_set_value’ was not declared in this scope; did you mean ‘gpiod_line_value’?
      331 |         res = gpiod_line_set_value(gpio_lines[pin], value);
          |               ^~~~~~~~~~~~~~~~~~~~
          |               gpiod_line_value

    Not urgent for me as it’s still winter in Adelaide 😉

    #83344

    Ray
    Keymaster

    Well, it’s that game again: every couple of years, there’s another breaking change to how GPIOs work, and we have to update firmware code just to keep up.

    I don’t understand why, for something as basic as GPIO control, the Raspberry Pi Foundation can’t provide a stable API that lasts for many years. On Arduino, the same pinMode, digitalWrite, and digitalRead functions have worked for decades—you never have to worry about core GPIO functions breaking after a system upgrade, let alone breaking repeatedly every couple of years.

    The original WiringPi library existed to solve exactly this problem, making GPIO access straightforward, but it’s now unmaintained and only kept alive as a community fork. I understand that Raspberry Pi OS now sits on top of Debian and inherits upstream changes, but the reality is that anyone using it for embedded projects needs GPIO access. At the current pace, the changes feel messy and disruptive.

    We’ve essentially had to write our own “wrapper” library in our firmware just to shield our code from these changes—something that really should have been provided and maintained by the platform itself.

    Anyway, apologies for the rant, but I doubt I’m the only one feeling this frustration. My advice is to stick with Bookworm unless there’s a feature in Trixie you absolutely need.

    #83346

    psmedley
    Participant

    Hi Ray – I remembered as soon as I saw the issue the problems with bookworm, and no need to apologise for the rant 🙂

    I had no real reason to upgrade this Pi to trixie, it was one of those ‘I could, so I will’ things 🙂 I knew there was risk, but was happy to be the one to identify any issues.

    I’ll likely just swap out the SD card next time I’m at the holiday house and stick with bookworm 🙂 Or one lazy day I may try and rewrite the code.

    #83369

    psmedley
    Participant

    I still need to test the code, but I used Gemini to help re-write things – source at https://github.com/psmedley/OpenSprinkler-Firmware/tree/libgpiod-2.x

    I also need to find a way to determine if the installed libgpiod is v1 or v2 – right now, the v1 code is wrapped in a ‘#if 0’

    Interestingly, when I load the GUI, I get a ‘Stations Currently Paused’ message that I don’t seem to be able to clear 🙁

    #83384

    psmedley
    Participant

    So I haven’t been able to get the writes to success with libgpiod 2.2; however, I did manage to compile libgpiod v1.6.5 on trixie; and build ospi against the older library.

    I’m still seeing the ‘Stations Currently Paused’ message that I don’t seem to be able to clear. Any clues on what causes this? searching the code didn’t give too many clues.

    #84182

    Michael
    Participant

    Hmm, I was just thinking of updating the Opensprinkler Pi (along with the others) to Trixie, but I guess I’ll hold off on that.
    Good call!

    #84183

    Ray
    Keymaster

    Firmware 2.2.1(4), which will be released this weekend:
    https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/381
    addresses this issue by switching from gpiod to lgpio, which works on trixie and doesn’t make breaking changes across raspbian versions.

    #84184

    Michael
    Participant

    Sounds perfect!

    #84203

    GregT
    Participant

    With the release of 2.2.1(4), the note “firmware currently does NOT work with Trixie due to the breaking changes it made regarding GPIO operations” on https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospi is no longer valid, correct? Thank you!

    #84205

    Ray
    Keymaster

    Correct. I’ve updated those statements.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Problems with gpiod v2