C/C++ Library

[adamgreen]

I have been following the development of your PicoSDK based C library with much interest. I have been thinking to switch out the lowest layers of the Arduino library that I just ported to use your C APIs at the lowest layer. Today I use a mishmash of Arduino, mbed, and PicoSDK calls. Consolidating on the PicoSDK would make it cleaner.

What are your thoughts? Do you have future plans for an official Arduino library for this robot as well? If you do have such plans should I put a pin in what I am doing and wait for your official library or is there some work that I can do to help with the development of that official library?

[DavidEGrayson]

Thank you very much for the help! I saw your forum post but haven't looked carefully at your Arduino library yet. We do eventually want to have an official Arduino library but we have not started on it yet, so you should not feel like you have to wait for us. The preferred name for our official library would probably be Pololu3pi2040 (without Plus), so your library will not cause a name conflict.

Eventually I would like to have C, Arduino, and Python libraries for the robot that all have very similar features and interfaces, so that people can switch between languages without extra friction. I think we should have our C libraries directly available in the Arduino environment so people can directly copy code from C to Arduino. But it is also nice to have Arduino-style classes for that functionality. For some of the more complex libraries like display.c, it probably makes sense for the Arduino library to just be a wrapper around the C functions. For simpler libraries, it might make more sense just to copy the C code and rewrite it in Arduino-style. It's hard to tell exactly what is best until we sit down and work out the details. In some cases, we might want to adapt the C code (e.g. to make it more object oriented) so it can be used better from Arduino. And maybe in some cases there's a built-in Arduino library (like Wire) that we should be using, so the code will be very different.

We just merged a LOT of changes in for the C code the other day, including documentation, Unicode text support, etc. Have you seen the latest changes?

[adamgreen]

The main goal for me when I created my port of the Arduino library was to require the fewest changes to the existing examples so that it would look very familiar to people switching from the 32U4 version of the library.

I think the best plan for me is to just keep the library as is for now. I don't plan to do much more development on it anyways. Just fix bugs that I or others encounter. If you guys release an official version then I will archive my GitHub repository after adding a link to your official version. I can even add a #warning message to the main header letting people know that an official version of the library exists.

I looked at about half of your C code in the source branch of the merge a few days ago and it looked like it was coming along quite well. I haven't read through it all though.

If I were to refactor my library to start using your code then it would give you an additional active tester since I would be reading through your code, integrating it, and testing it on the bot with the ported Arduino samples which might prove as a useful data point. Thoughts?

[adamgreen]

As an experiment, I created a new branch, pulled in a copy of your C library and switched a few of the Arduino classes over. It went pretty smoothly:

• ledYellow
• readBatteryMillivolts
• ButtonA, ButtonB, ButtonC: https://github.com/adamgreen/pololu-3pi-plus-2040-arduino-library/blob/v0.2.x/src/Pololu3piPlus2040Buttons.h
• Motors: https://github.com/adamgreen/pololu-3pi-plus-2040-arduino-library/blob/v0.2.x/src/Pololu3piPlus2040Motors.h

Those were easy to create an inline C++ wrapper around. Many of the others should be easy to wrap similarly.

As you hinted to above, the OLED display class will take some more thought. My current inclinations are towards keeping the current OLED class and creating a new one which wraps your new C display API. I could then take one of the examples, probably the Demo for OLED, and refactor it to use the new display driver instead.