Chapter 3 – “Cylon” LED Bar: smooth flowing light with pre-calculated real-time delays

Releases
, , ,
1

Hello everyone,

I have just published Chapter 3 of the Raspberry Pi Pico Ada Tutorial.

This time we build a flowing LED bar with ten LEDs connected to the Pico. We start with a straight-forward port of the Freenove example (Sketch_03_1_Flowing_Light) using an array of RP.GPIO.GPIO_Point (aliased limited tagged types). Then we upgrade it to a proper Cylon scanner (Cylon_Light) with smooth, organic movement created by a pre-calculated sine-harmonic delay table – all using Ada.Real_Time and zero floating-point at runtime.

Everything is available as an Alire (eventually) crate, with full GNATdoc documentation.

Full chapter (including source code and photos):

Feedback and questions are very welcome!

Best regards,
Martin

5 Likes
2

Nice!

By the way, the conflict you had with the ROM floating point bindings is resolved in rp2040_hal version 2.7.0. It looks like your project is using an older version.

You can ensure that version 2.7.0 is used by updating your local Alire index:

alr index --update-all

and then adding this to your project’s alire.toml:

[[depends-on]]
rp2040_hal = "^2.7.0"
1 Like
3

But rp2040_hal is already an indirect dependency.

   +   atomic       1.1.0  (new,indirect)
   +   bbqueue      1.0.0  (new,indirect)
   +   cortex_m     1.1.0  (new,indirect)
   +📦 gnat         15.2.1 (new,gnat_arm_elf,indirect,binary)
   +📦 gnat_arm_elf 15.2.1 (new,indirect,binary)
   +📦 gnatprove    15.1.0 (new,binary)
   +   hal          1.0.0  (new,indirect)
   +   pico_bsp     2.2.0  (new)
   +   rp2040_hal   2.7.0  (new,indirect)
   +   usb_embedded 1.0.1  (new,indirect)

Is it wise to add the dependency explicitly as well?

4

Indeed it has an indirect dependency via pico_bsp, but pico_bsp depends on any 2.x.x version, including versions before 2.7.0. My assumption was that your Alire environment had picked up an older rp2040_hal version, before 2.7.0, but it seems that you already have the latest version.

Do you still get the issues when using floating point with those crate versions?

5

The problem is that I used to a more efficient implementation that doesn’t use Float. So I don’t have the problem any more.

I can add separate version with Float just to see how that goes. Might be worth it to see if the problem percists.

6

I added the floating point version back to the code as a new cylon_light_float.adb main procedure inside an also new feature/float branch. The Error is still there. If you want to you can clone the git repository (git://git.code.sf.net/p/pi-ada-tutorial/code) and have a look.

7

Thanks for trying that out. I’m able to reproduce the linker error, I’ll look into it.

1 Like
8

So it looks like the symbol clash wasn’t completely fixed in rp2040_hal v2.7.0. There are still a few float functions (sqrtf in this case) that are missing the RP_ prefix when Use_Startup = false. I’ll propose a patch to fix it in rp2040_hal.

2 Likes
9

The symbol conflict is fixed in rp2040_hal 2.7.1.

In your project directory:

alr index --update-all
alr update
alr build
2 Likes
10

Something for tomorrow. Why is the rp2040_hall pull request through and mine are all stuck :face_holding_back_tears:.

11

Looks like the CI checks are failing on your crates, but I don’t think it’s your fault; I think it’s because alr test on Windows is erroneously expecting a .exe extension on the executable but the executable built by gnat_arm_elf lacks that suffix.

12

iirc, if gnat_arm_elf (or any other cross toolchain) is in the depends-on list for your test crate, the CI runner won’t try to execute it.