Conversation
Massive upgrade.
- Add support for building for https://github.com/earlephilhower/arduino-pico
- As in the style of platform-ststm32, boards that can be used with both cores can be switched to the other core using
board_build.core = earlephilhower - Integrates with my already merged builder script at https://github.com/earlephilhower/arduino-pico/blob/master/tools/platformio-build.py
- Added all Arduino-Pico boards (Earle auto-gen'ed them through https://github.com/earlephilhower/arduino-pico/blob/master/tools/makeboards.py)
- Arduino core must use toolchain and tools from https://github.com/earlephilhower/pico-quick-toolchain/releases, which are finally in the registry
- no more
platform_packagesinjectionplatformio.inineeded, all tools (except framework) sourced from registry
- no more
- Replace outdated
platformio/tool-openocd-raspberrypi(1 year old, before picoprobe merge) withearlephilhower/tool-openocd-rp2040-earlephilhower-- works for all frameworks and cores (also the mbed-os core) - Added support for LittleFS filesystem building + uploading through picotool and OpenOCD (picoprobe etc.); Arduino-Pico core supports LittleFS
- Added and tested Picoprobe support for both ArduinoCore-mbed and Arduino-Pico, works great
- Reduced default debugging and OpenOCD upload speed to 1000kHz, the 5000kHz was giving me verification errors
- Add Arduino-Pico examples to CI
- Reprogrammed
upload_protocol = mbedto make more sense, it previously tried to upload the.binfile to the drive instead of the.uf2file - Update SVD file with latest from https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/rp2040.svd
Test at will with
[env] platform = https://github.com/maxgerhardt/platform-raspberrypi.git framework = arduino board_build.core = earlephilhower board_build.filesystem_size = 0.5m [env:pico] board = pico ; if using picoprobe SWD upload / debugging ;upload_protocol = picoprobe ;debug_tool = picoprobe ; note: newer PicoProbe firmwares emulate a CMSIS-DAP, so you ; use "cmsis-dap" as upload_protocol and debug_tool. ; for more info see docs https://arduino-pico.readthedocs.io/en/latest/platformio.html
ToDo (all done at the moment of writing):
- create PR for platformio-docs, previous docs at https://arduino-pico.readthedocs.io/en/latest/platformio.html are outdated
- create PR for arduino-pico docs as docs is now outdated
- fix Update PlatformIO builder script + docs earlephilhower/arduino-pico#612
- upload / make Earle upload
framework-arduinopicopackage (after fix of course)
because of the logic selecting elf or firm (bin), we need to default to no offset on normal firmware upload because we already defaulted to elf a few lines below if upload.offset_address is not user set so when no offset is needed. programming fails otherwise Unfortunately, my way of modifying the code probably sucks because I've never written anything in python but I assumed the second arg is the default n case the first is missing. Haven't had time to dig too much into it.
I'm pretty new to platformio and making in general. I'm doing a hacker box which is using the Earl repo.
How can I get the Earl repo installed into platformio to be used?
Thank you.
Out of all the jaw-dropping statements by @ivankravets this one stood out to me the most:
If Raspberry Pi Trading truly values freedom for their customers, they should have engaged in a discussion about the licensing fee.
And it looks like the same is now happening with Espressif support: platformio/platform-espressif32#1225
Once we gather enough interest from the Espressif community, we plan to reach out to the Espressif company and request a reconsideration of support for PlatformIO.
Same situation here with RPi Ltd. Now that I have a better perspective I fully support Espressif and RPi Ltd and will move away from PlatformIO and focus on alternatives or forks. Sad.
update arduino-pico to Release 3.7.2
change default picoprobe speed to 5000 kHz
If there are no code changes requested on this PR and you are still not going to merge it, then you should close it. Clearly Raspberry Pi are not going to pay you and I'd be surprised if they ever want to deal with PIO.
I've just recently got aware of this topic, as searching for running RP2040 over PlatformIO to support it over a framework H4Plugins with a prepared PIO environment H4Plugins_Env.
I know this thread is full of words and statement, I understood everyone's perspective, developers, PIO, and RPI.
What I'd like to say here that we (developers) owe PlatformIO a lot, great IDE with great experience, unifying everything for us to a single place.
Which is the thing that PIO had invested in: Make it totally free to developers. But we need to see the whole image.. I mean, they don't sell data as Google and Facebook, neither running ads to get revenue. Here I understand where they monetize from: The silicon manufacturers.
Yet also me don't like that resulting in absence or lack of support to some popular MCUs, but I should also respect that decision.
Now I'll check how to run RP2040 over PlatformIO even with non-standard ways (as it's available AFAIK), but I'm not ready to consider other IDEs, except for very serious reasons.
The best solution I see is that RPI and PIO agree on a fair deal.
With thanks,
Eben Upton wrote:
We received a proposal from PlatformIO Labs in October 2022. While we absolutely empathise with the challenges of funding open-source projects, we were unable to justify paying the very substantial recurring fees involved. We indicated that we would not be proceeding, and have subsequently made some investments elsewhere, notably in the Raspberry Pi Pico Windows Installer.
Now that is ... beyond imaginable.
PlatformIO, a minuscule company (in terms of finance) compared to Raspberry Pi Ltd and nanoscopic compared to Microsoft is being refused financial support.
It's Raspberry Pi Ltd investing in.... developing tools for use on the mastodon Microsoft platform Window$ !
PlatformIO works perfectly on M$Window$.
The world is upside down...
Couldn't have the folks at PIO and RPi Ltd come to an agreement? If it's too expensive then talk!
If we, users, voted for which solution we'd like, the Windows installer or a RP2040 (pico and other boards) integrated in PlatformIO, I am overly confident the later would come out first.
Right now we all lose:
- users still don't have proper support for the RP2040 chip in PlatformIO
- PlatformIO didn't get anything financially from Raspberry Pi Ltd,
- Raspberry Pi Ltd invested in a tool gathering only 240 stars on github (vs 7.7k for PlatformIO core only) and last updated in 2023 as of writing, and the RP2040 competitor, Espressif, benefits from PlatformIO immense capabilities.
Who is happy to observe the argument? Well... certainly Espressif, and in fact, they don't even need to care.
Come on PlatformIO and RaspberryPi Ltd... make up the disagreements, you both have a lot to earn from working together one way or another.
This situation is not primarily a financial issue. Raspberry Pi Trading Ltd. is a publicly traded company with a market capitalization exceeding £750 million. You can find more details on their financial standing here: Raspberry Pi Holdings on London Stock Exchange.
What we're seeing is a classic issue in the semiconductor industry: the larger the company, the wider the gap between its customers. Often, company stakeholders rely on input from their technical teams, who believe they understand what embedded developers need in terms of development tools and IDEs. However, these teams frequently prefer legacy tools developed decades ago, assuming that all embedded engineers should adopt these outdated tools and workflows. Unfortunately, this approach often neglects the actual developer experience, focusing more on chip sales than on the quality of development tools.
Raspberry Pi Trading Ltd. is not unique in facing these challenges. Public statistics highlight similar trends across the industry: Embedded Development in VS Code Statistics.
Many excellent projects have faltered due to this disconnect between stakeholders and end customers. For example, consider Arm Mbed OS, which was a promising project before Arm acquired it. You can read about its decline here: End of the Line for Arm’s Mbed OS.
This was referenced
