IoAbstraction
IoAbstraction copied to clipboard
davetcc
Support Arduino-Pico alternative RP2040 core in platform determination
First param is different between these guys, one uses uint32_t and the other uses unit8_t, causing build failures on alternate architectures like RasPi Pico. Thought you'd like to know.
Normally these two types are the same if the board is detected. The likely cause of this is that https://github.com/davetcc/TaskManagerIO/blob/master/src/TaskPlatformDeps.h doesn't recognise the board, and would therefore need changing to pick up on that board type, alongside IoAbstraction's PlatformDetermination.h. The bigger issue is that atomic operations would need to be properly handled in order for task manager to work properly.
There are two problems here, firstly, there are just too many boards for us to support them all, secondly, hardly anyone uses tcMenu outside of STM32, ESP*, and genuine Arduino boards. Supporting other boards takes a lot of effort, not just immediately, but over a long period of time. We did it for mbed and hardly anyone uses it as far as I can tell (not even me).
I mean using the Pico with Arduino framework (if that is even possible, I don't know, the boards don't interest me TBH, so I'd be doing it for others) may be possible with a minimum amount of work. Is that even possible, and would anyone want it if it were?
Oh! There ya go, I guess I didn't need to change those to get them working after all. :3 That would make sense since I was trying things out with Pi Pico, and yours wasn't the only lib complaining (OneWire was complaining, also). And yeah, you can now program Pi Pico with https://github.com/earlephilhower/arduino-pico (I'm doing it through Visual Studio Code, but same diff) - very similar setup to Teensy/ESP/Etc with the added URL through boards URL in preferences.
And yeah, no worries on support, the Pico caught my eye because of the 2MB Flash memory and 264kB of RAM at only 5$ USD/chip. First of RasPi microcontrollers. I def encountered a good deal of issues with it already tho, so I'm probably going to wait for it to get ironed out more. Still, very interesting little guy.
As far as usage though, I mean, I'm writing Hydroponics software and envision it to behave very similarly to that of a 3D Printer, with the various cute little menus and such. I am nearly completion for the main bulk of the work, save bug fixes and stabilization and moving onto the UI implementation side, but anything you do on tcMenu to support anything else I am planning on trying my best to utilize. I see all the hard work you've put into it already just by diving into your files every now and again, so not all is lost. I have definitely been there with writing code for things that barely anyone uses, alas. In case anyone hasn't said it yet: thank you for all your hard work.
Looking while on the train earlier I saw there is a core for Arduino for pico. This means with a small tweak in the two platform determination files it should just work. Given they are really cheap I’ll try and pick one up and see if it would be easy. I suspect it would. I need to pick up an esp32s3 to do another tweak for that anyway.
Hey there ya go! They are pretty cheap, that's what I think attracted to me to it initially. My application doesn't require a lot, but it does require objects in simulation stay memory resident somehow (along with data storage for all the crop data). With 264kB of that it's wayyyy more of an improvement over trying to make it work at a min of 8kB. Anyways, don't feel like this is a huge request or anything, just figured I'd help out a fellow programmer with the data points. :)
Your usage sounds great. Actually, now I see it has a workable Arduino core this makes it a lot more interesting.
Let me know how this turns out here - I think that as the RP2040 core stabilizes it's going to really attract a lot of attention. Not just because of the price point (okay a lot because of that), but also because it's just a really nice little microcontroller the more I look into it. Really hoping that the ecosystem there continues strengthening itself.
Also you mentioned about the mbed work you did - tbh, if my application takes off in any way then I have already done the work needed to support that (yay template aliases!), so it'll naturally carry over. The Nano 33 IoT in particular I think would be about perfect for what I'm doing, but also the Pico or ESP32.
Support coverage is going to attract you a lot of attention though, especially for those who are writing things that they want to be agnostic as possible to the kind of platform used in order to reach the widest audience. I'm not saying you should have to slay Dracula or anything obnoxious, but hey, anything you do I plan on using, so.
Alas, I'm still at the beginning of the process for building out any UI - still working out a few more bugs in the main system. I wanted to take some time off coding to go through a usage flow on paper to figure out how I wanted to do it. I've played around with a few of the tcMenu examples and think there is a lot of promise there - especially when you start adding in the cost of it all. I can let you know how it goes in retrospect if you'd like to hear about it.
Are you sure you're on the latest versions of TaskManagerIO, SimpleCollections, IoAbstraction and tcMenu? I've got an RPI2040 and I didn't realize it is actually an mbed board that's already supported by very helpful recent PR by another user.
So I've tried it myself with buttonRotaryEncoder sketch on a Pico with the rotary encoder test sketch, and so far so good.
Versions:
TcMenu 2.3.1 IoAbstraction 2.3.4 TaskManagerIO 1.3.3 SimpleCollections - 1.2.0
EDIT - also taskManager tested and working properly too
I can get it working with the mbed Arduino core, that much I've been able to do (read as: at least compile, not sure how to upload just yet) - I think maybe what I'm getting more at is that with the arduino-pico core I linked above, that you put into the boards manager URL and such, you apparently get access to RTOS and better multithreading (at least that is what I have read).
I made sure that I am on the recent versions though and haven't any local modifications, and still no dice on the arduino-pico build.
Another thing to note about the arduino-pico core is that you get a whole host of more options for building that you do not get at all with the Arduino mbed core.
OK, to be honest, I personally would use the mbed core if I'm honest, you can still use CMSIS, you can still use any underlying APIs that were provided, but you have a starting point that the core Arduino team look after. It should also support RTOS under mbed, which I've used before and is very good and quite standard across boards (and I say that as someone who regularly works on highly multithreaded Java server code).
I'm not against the other option being available though, if you have some experience with the other core and know how I could handle atomic operations with it, I'd provide as much help as I could if you wanted to try and get it working, but to be honest, I suspect most would want to use the Arduino provided core (including me).
Give me a bit of time to try the standard core myself and evaluate if the threading and other options work as well as they do under mbed proper. Arduino as I understand it is owned by the same holding company as mbed/ARM, so anything they do is likely to move in the mbed direction and I don't think that's a bad thing as long as compatibility is high on the list.
I've actually uploaded using platformIO the rotary encoder and task manager test sketches using the mbed based core. They both work fine for me. The next step is to add a TFT and set up TFT_eSPI then get tcMenu going on it.
Well, I think that for the reasons you given I should def see what I can do within the Arduino mbed framework to avoid the extra work there. I will definitely take your advice, since it seems like that's still a perfectly reasonable path to go down.
It's a tempting offer otherwise but it's probably outside of what I'm willing to chew atm. :3
By all means stay focused on your next tasks, I just appreciate you even taking a look at it and offering the advice. :)
Long answer -
End of the day, the other package probably wouldn't be that much work to add, it's more that it adds complexity to the platform determination. You see task manager needs an assured atomic (exclusive compare and set) means of writing ints and pointers, with a backup of falling back onto Arduino noInterrupts/interrupts call, these only work for single-core devices. I have an ARM assembly level answer for this based around LDREX/STREX that you can see in SimpleCollections repo, but it only works on Cortex 4 and above, pico is a Cortex 0+. Because mbed has a standard way of handling this, we can rely on that even in Arduino mbed. It would probably need implementing safely using the other core using whatever memory barrier constructs M0+ has.
Also, in the old days it used to be easy to work out what type the pin number in the call to IO functions was, it was always uint8_t, now it's not, mbed and Arduino mbed using a pin type that is essentially a 32-bit unsigned integer, which is where this error crept in..
Yeah, I admit that this is not my native platform that I usually do my main horde of development work on (am mostly iOS/Android mobile based, but also love me some embedded since that is what my father was more into - he being a hardware guy always asking me programming questions, which then got me into it and here I am :p), so I def appreciate the detailed responses. Thanks for taking the time to write it out!
I definitely took a gander through your source files just to get the general jist of your solution, even picking out some of the things like pintype_t decls (which I similarly have started using - knew uint8_t as a pin type was too good to be true), so I can definitely see what you mean by just adding more complexity to it all.
TLDR; after more analysis, I now see why many are using the other core and will support it once it's available in platformio.
So after all this, I think I've determined that the alternative core will be needed as otherwise far too many boards will be missing. To me, it's a highly unfortunate situation that two board definitions have been created for RP2040 and it will cost all developers and library writers for a long time to come.
It seems the situation at the moment is that the new core (non-official) is not yet supported in platformio, and I really don't want to install any other build tools and IDEs. I'm too accustomed to JetBrains CLion with platformio integration.
However, platformIO are adding this support at the moment, like me, it sounds like they too really don't like the idea of having to support two cores, but to coin a phrase, the stable door is open and the horse has already bolted some time ago, leaving library writers, IDEs and build tools having to support both. I'll add support once it is in platformio main line.
For now, it is tested and works with TFT_eSPI with the official core, it works well as far as I can tell.
See https://github.com/davetcc/TaskManagerIO/issues/43 that adds support for this board to task manager. See https://github.com/davetcc/SimpleCollections/issues/9 that adds support for it in simple collections
Once complete all libraries are complete, it will be safe to add tasks from any core, and use circular buffers across cores.
All the commits are in, I've built a menu on the top of this core using the main branch of each library. Thread/interrupt/core safety should be assured for task manager and circular buffers. I'll be running a full test soon once I've finished with the bug round up for 2.4.1 of tcMenu, then I'll release each in turn.
This was a particularly tricky one because there are two cores with similar definitions, but I think that is solved safely too.
My settings were:
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
build_flags = -DIO_LOGGING_DEBUG=1 -DLoggingPort=Serial1
board = pico
framework = arduino
board_build.core = earlephilhower
upload_protocol = picoprobe
debug_tool = picoprobe
lib_ldf_mode = chain+
monitor_speed = 115200