-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arduino-Pico (Earlephilhower) support, PicoProbe Debugging #36
Conversation
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.
Update main.py
I'm pretty new to platformio and making in general. I'm doing a hacker box which is using the Earl repo. Thank you. |
We've documented the install process in the Arduino-Pico documentation. |
Out of all the jaw-dropping statements by @ivankravets this one stood out to me the most:
And it looks like the same is now happening with Espressif support: platformio/platform-espressif32#1225
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
Sync master
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:
Now that is ... beyond imaginable. 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:
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. |
Massive upgrade.
board_build.core = earlephilhower
platform_packages
injectionplatformio.ini
needed, all tools (except framework) sourced from registryplatformio/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)upload_protocol = mbed
to make more sense, it previously tried to upload the.bin
file to the drive instead of the.uf2
fileTest at will with
ToDo (all done at the moment of writing):
framework-arduinopico
package (after fix of course)