search

platformio / platform-raspberrypi

Raspberry Pi: development platform for PlatformIO
https://registry.platformio.org/platforms/platformio/raspberrypi
Apache License 2.0
73 stars 96 forks source link

Arduino-Pico (Earlephilhower) support, PicoProbe Debugging #36

Closed maxgerhardt closed 6 months ago

maxgerhardt commented 2 years ago

Massive upgrade.

grafik

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):

maxgerhardt commented 2 years ago

I saw you already already added the ota.o object file to the builder script, I will take care to add the espota.py upload method to main.py like platform-espressif8266 does, with the added build logic to build the signed .bin file of course.

maxgerhardt commented 2 years ago

The first PlatformIO integration for regular and also signed OTA updates for the Pico W is working and tested now. See arduino-ota example.

Also comes with improved upload_protocol = mbed logic that resets the serial port to make the boot drive appear. Code not yet final, improvements pending, but it's a good working state for now.

taf2 commented 2 years ago

Thank you for putting in the time to make this happen. I am testing this out on a project I have and currently getting a linker error:

/Users/taf2/.platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: .pio/build/pico/src/main.cpp.o: in function `_Z13connectToWiFiPKcS0_':
main.cpp:(.text._Z13connectToWiFiPKcS0_+0x40): undefined reference to `_ZN9WiFiClass5beginEPKcS1_'
collect2: error: ld returned 1 exit status
*** [.pio/build/pico/firmware.elf] Error 1

Here is my platformio.ini file:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0m
upload_protocol = cmsis-dap
debug_tool = cmsis-dap

build_flags = -D PICOW

Here's my project files that use this: https://github.com/taf2/tinypico-fridge-alarm

make pico
maxgerhardt commented 2 years ago

If you use the WiFi library, are you sure you don't want to use board = rpipicow?

taf2 commented 2 years ago

@maxgerhardt aahh! brilliant! This worked! amazing :D

henrygab commented 2 years ago

Looks good to me!

I have used the following platformio.ini. So far, it was easy to build, upload (program), and monitor a second PICO using a picoprobe. I'll try debugging next, but very happy to see so much working smoothly already!

platformio.ini

```ini [env:pico] platform = https://github.com/maxgerhardt/platform-raspberrypi.git board = pico framework = arduino board_build.core = earlephilhower board_build.filesystem_size = 0.5m lib_deps = https://github.com/SimpleHacks/QDEC.git#dev-pio-rp2040 upload_protocol = picoprobe debug_tool = picoprobe debug_init_break = tbreak loop debug_extra_cmds = thread 1 ```

I do have one last question... **Q: Does this already support compiling PIO assembly files using `pioasm`?** (I looked, but nothing caught my eye...)
maxgerhardt commented 2 years ago

Q: Does this already support compiling PIO assembly files using pioasm? (I looked, but nothing caught my eye...)

No it doesn't (yet). That means you have to do some preprocessing step (I'm not sure which tool) to directly generate the C code with the assembled instructions, like arduino-pico does.

earlephilhower commented 2 years ago

The SDK docs have good descriptions of using pioasm, but basically it's just

pioasm -o c-sdk [path-to-source-file.pio] > [path-to-genrated-pio.h]

How to integrate that into an app is left as an exercise for the reader. :laughing: (Actually, the SDK docs here are also very good!)

henrygab commented 2 years ago

Yes, I have manually run the tool, and agree it's easy to use.

Since it seems like a source file, and the result is a generated file used in compiling a corresponding project, it seemed a natural fit.

Given the amazing work you've already done, I was just hopeful this was also included in your solution. I now understand that it was not included in the current scope. 👍

MrTechGadget commented 2 years ago

Is this awaiting anything else? Looks to me like the requested changes are in and the outstanding issues resolved.

hexeguitar commented 1 year ago

Regarding the pioasm integration, i have recently found a way to automate it using the platformio scriptiing, the procedure is explained in this gist:
https://gist.github.com/hexeguitar/f4533bc697c956ac1245b6843e2ef438
The script checks whether the pioasm package is installed, then scans the src directory for any .pio files and compiles them into header files.

maxgerhardt commented 1 year ago

Thanks for the script, I'll be looking to integrate this into the platform code.

Marius-Alexandru commented 1 year ago

Massive upgrade.

grafik

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

ToDo:

Hello!

I receive the following error:

Linking /data/technical-room-pico-w/.pioenvs/technical-room-pico-w/firmware.elf /data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: /data/technical-room-pico-w/.pioenvs/technical-room-pico-w/src/main.cpp.o: in function setup': main.cpp:(.text.setup+0x814): undefined reference to_ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE' /data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: main.cpp:(.text.setup+0x81c): undefined reference to `_ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE' collect2: error: ld returned 1 exit status *** [/data/technical-room-pico-w/.pioenvs/technical-room-pico-w/firmware.elf] Error 1

The code in yaml: remote_transmitter: pin: GPIO2 carrier_duty_percent: 50%

maxgerhardt commented 1 year ago

There was no need to quote the entire PR description, it just takes up space.

undefined reference to `_ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE'

Is demangled

vtable for esphome::remote_transmitter::RemoteTransmitterComponent

I have no deep knowledge of ESPHome. Please open an issue in their repository: https://github.com/esphome/issues

MCUdude commented 1 year ago

Is this awaiting anything else? Looks to me like the requested changes are in and the outstanding issues resolved.

@valeros could you look into this? Would be incredible if the Earlephilhower Arduino RP2040 could be natively supported by PlatformIO

MCUdude commented 1 year ago

It looks to me like @maxgerhardt is just keeping this PR up to date in case it gets merged someday. I have not followed the discussion, but this PR is flagged with "Changes requested". Has this been resolved?

If yes, are you @valeros planning to review this PR soon and hopefully merge it? After all, support for the "earlphilhower" RP2040 Arduino core is kind of a big deal!

Thank you for your work with this PR @maxgerhardt!

Dantali0n commented 1 year ago

To reflect on @MCUdude all the changes requested by @valeros have been implemented by @maxgerhardt. So why this patch is still blocked is not clear to me, is there any remaining work before we can merge this, how can we move this forward?

Cpasjuste commented 1 year ago

Just a little user report, it's working very fine here, good job @maxgerhardt :) I guess it should get more attention and maybe be merged.

Dantali0n commented 1 year ago

I doubt we will see movement in getting this patch merged soon, its been up for half a year.

Take into account there are only 2/3 core developers managing the whole of platformio and both are located in Ukraine. We have seen a strong stagnation across the board but we can't really blame them for it imo.

ivankravets commented 1 year ago

Dear @Dantali0n,

Thank you for bringing up the issue of missing official integration for PlatformIO and Raspberry Pi products. We understand that this is an important concern for many of our users.

We want to clarify that the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use. We have provided the link to the list of currently officially supported development platforms, and we encourage you to refer to this list for your project needs ( https://registry.platformio.org/search?t=platform ).

We want to assure you that we are working closely with the Raspberry Pi company to add official support for their products to the PlatformIO ecosystem, and provide the best developer experience in the market for their customers. We will keep you updated on any developments regarding this matter.

In the meantime, we encourage you to refer to the Raspberry Pi documentation and use their officially supported tools and IDEs.

Thank you for your understanding, and we appreciate your continued support of PlatformIO.

Best regards, Your friends at PlatformIO.

cc: @ghollingworth

sstaub commented 1 year ago

@ivankravets Sorry Ivan, I know that you are under extreme stress to do your job in Ukraine and I'm also understand that your business need to generate money. But the world is not only AI, Zephyr, RISC-V and iOT and your company get more and more away from the claim to create a universal platform for all type of users. I'm working maybe for more than 8 years with your platform and every year I get more and more frustrated how PIO developed from an open source platform to a commercial company. To ignore the most popular microcontroller for the open source community is unintelligible. Wish you the best for the unknown future. Stefan Staub

ivankravets commented 1 year ago

Hi @sstaub ,

Thank you for sharing your thoughts and feedback regarding PlatformIO's support for microcontrollers. We appreciate your loyalty and the time you've invested in our platform.

We understand that PlatformIO has evolved over the years, but we want to assure you that our commitment to open source remains strong. Our solutions for end developers are free and licensed under the Apache 2.0 license. Additionally, we invest in community OSS development platforms every month, even if they are not our official technology partners.

However, we do face challenges when it comes to providing support for certain microcontrollers. Many silicon vendors do not see the value in open source and communities, which can make it difficult for us to add support for their products. This is especially true if they already have their own proprietary tools and IDEs.

That being said, we do not want to compromise the quality of our support by adding all development platforms and architectures. If a silicon vendor does not officially support PlatformIO, it's unlikely that customers will use it for production or commercial products. We believe in following official recommendations to ensure the best user experience for our customers.

We suggest reaching out to silicon vendors directly to discuss their vision for open source communities like PlatformIO. We've seen success with companies like Espressif, who value the importance of open source and have demonstrated this financially. If you have any ideas on how we can solve this issue, we are open to discussion.

Once again, thank you for your support and feedback. We will continue to work towards creating a universal platform for all types of users while staying committed to open source and vibrant communities.

Best regards, The PlatformIO Team

Riffer commented 1 year ago

I read this as a "Raspberry does not want you to include a much better core into our system, because they don't want concurrency in their own property".

Given this fact, you fail to be a support for the open source community any longer.

Under this circumstances platformio sooner or later must be replaced by independent structures.

sstaub commented 1 year ago

@ivankravets There is a nearly 2 years old issue requesting support of the official sdk, but also nothing happens.

ivankravets commented 1 year ago

Dear @Riffer ,

Thank you for your comment. I understand that the decision to not include a particular core in the current development platform may have been misconstrued as a lack of support for the open source community.

If you do not require official support from Raspberry Pi Ltd., please feel free to refer to the instructions provided by @maxgerhardt in the original post of this PR. However, it is important to note that we at PlatformIO Labs currently do not recommend using this development platform for commercial or production purposes due to integration and functionality limitations (missed official Raspberry Pi Pico SDK support, etc).

As you mentioned, we are actively engaged in conversations with Raspberry Pi Ltd. to find a solution to this issue. We appreciate your patience and continued support of the open source community.

Best regards, The PlatformIO Team

JonnyHaystack commented 1 year ago

@ivankravets

As others have said, I understand that the situation in your country is very difficult, and my greatest sympathies for that. However, I don't understand why you're answering everything except the actual question people are asking. These corporate sounding responses are part of why you're getting a negative reaction. We are talking about this specific PR for arduino-pico support. I have been using the arduino-pico support from Max's fork for almost a year and it works extremely well, and makes cross-platform support very easy. It's pretty much objectively better in every way than the MBed core that you officially support (even if you only consider that "demonstrative"). But from what you're saying, it seems like you are only willing to work with companies and have no intention of merging these fantastic contributions from independent individuals? That does not seem in the spirit of open source to me if that is the case.

We want to assure you that we are working closely with the Raspberry Pi company to add official support for their products to the PlatformIO ecosystem, and provide the best developer experience in the market for their customers.

I'm pretty sure everyone here is a customer of theirs... shouldn't we have a say in what developer experience we would like, or does it not count because we aren't business owners?

We suggest reaching out to silicon vendors directly to discuss their vision for open source communities like PlatformIO.

Does the company's "vision" of a community matter more than the community itself who is putting in the work?

I wouldn't have thought the Raspberry Pi foundation would actually pay you to not support other platforms/cores for their microcontrollers, so I am really confused why this PR was reviewed and Max was requested to make changes, which he has made, and then after that the work just gets ignored. Maybe eventually you get an official primary platform to replace your MBed core, but even then it may not be what a lot of the community wants. And for people who are already maintaining projects using this platform, it may not be worth the effort to switch. I totally understand that you want to have an official platform that is officially supported/endorsed by Raspberry Pi foundation, and I don't think that's a bad thing, but I fail to see why that cannot coexist with unofficial community platforms.

Sorry if I come across blunt/harsh, and obviously I don't know all sides of the issue, but I find it quite frustrating to see high quality work, done for free, being neglected just because it doesn't align with some company's ideal.

Dantali0n commented 1 year ago

Dear @ivankravets,

Thank you for these clarifications, I understand that as a commercial entity adding support for platforms from different vendors without their approval raises political tensions that is not within the best interest of your company. However, I do think that such barriers can be better communicated to contributors as it seems to be the first time this is being put forward when this patch has been up for roughly half a year.

While we can not add support to official repositories for platforms without vendors approval. many third party libraries that can be integrated using the method described by @maxgerhardt here exist (https://github.com/Community-PIO-CH32V/platform-ch32v, https://github.com/CommunityGD32Cores/platform-gd32) Maybe as a community we can create an list of such repository, describe the method to integrate them into platformio-core and warn about it being unofficially supported and the limitations that arise from that.

This list can either be created in a GitHub repository or ideally is maintained as a separate website (that will of course NOT use the PlatformIO name) that also runs an extended instance of the documentation repository as to provide documentation for these unofficially supported boards.

Using this methodology contributors can create support for their boards, thinkers can try out these new boards knowing risks and limitations and PlatformIO can continue as a business without tension by supporting boards without vendor approval / agreements.

Does this seem like a workable solution to you?

Kind regards, Dantali0n

Dantali0n commented 1 year ago

@JonnyHaystack

I wouldn't have thought the Raspberry Pi foundation would actually pay you to not support other platforms/cores for their microcontrollers

Please refrain from such nonconstructive discussion based on nothing but assumption as it doesn't contribute to anything.

Cpasjuste commented 1 year ago

Hi guys,

I feel a little sorry as I didn't expect my "bump" to go this way. I do personally think it's up to platformio guys to take this sort of decision, and I think we should respect it. As @Dantali0n said, and because platformio is well developed (to me), we can already use it with very little effort in a non official way, thanks to all platformio dev and @maxgerhardt, and we should be thanks full for that, no need to enter in a long argument fight. Again, as @Dantali0n said, it could be great to just give more visibility to something like this, maybe on platformio forums if they do agree, maybe by adding an unofficial board section or something.

MrTucks commented 1 year ago

My 2 cents as a beginner who is just moving past official Arduinos with the Arduino-IDE (and I haven't used Platformio before): I understand that you want something official. However, the current raspberrypi platform already is not official. (No official tag in the registry.) So why not replace something unofficial with something (still unofficial) but way better? Maybe I'm misunderstanding what the "Community" Tag on the registry means. I guess that the earlephilhower core with maxgerhardts Platformio integration would fall under the Community tag.

You write that you're working with the Raspberry Pi company to add official support. As far as I know, only the "bare metal" C/C++ SDK is official from the Raspberry Pi company. And while official C/C++ SDK support would be great, it would not replace the earlephilhower arduino-core, especially for beginners and hobbyists.

Your comment is the first time that I'm reading "that the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use". Sure, there is no "official" or "verified" label on the registry, just a "top 10"-hearth. From looking at the registry, I honestly expected way more. Maybe not something production-ready. But I kind of expected being able to blink the built-in LED on the one year old and pretty popular Raspberry Pi pico w board.

If you don't want to add the earlephilhower core to the registry, I would suggest to at least write "the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use" on the platformio registry page. And I would add a link to the earlephilhower core, too. I know that I can (and do) just use the earlephilhower core without it being in the official platformio registry. But actually warning people not to use the "demonstrative character" version and making the better version easier to find really reduces unnecessary frustrations.

Don't understand me wrong, I really like Platformio in general. With the earlephilhower core, making a simple program was just as easy as in the Arduino IDE except Platformio+VS Code is way better.

Best Regards

sstaub commented 1 year ago

@ivankravets I don't understand the term "official" support by the vendors. Many of your supported frameworks and platforms started at an open source community project like STM32duino. What about Arduino? Are they official by the vendors? Their NanoRP2040 is also not official supported by Mbed(ARM), they forked the repository and made an own solution. Official??? Arduino don't want that their product will supported by Mbed officially.

Many silicon vendors do not see the value in open source and communities, which can make it difficult for us to add support for their products.

The DNA from Raspberry Pi is open source.

PIO is focused on the silicon vendors and this one of the problem.

MrTechGadget commented 1 year ago

If inclusion criteria is official commercial vendor support, perhaps you need to remove this key point from platformio.org website.

A place where Developers and Teams have true Freedom! No more vendor lock-in!

On Sat, Apr 15, 2023 at 9:48 AM Stefan Staub @.***> wrote:

@ivankravets https://github.com/ivankravets I don't understand the term "official" support by the vendors. Many of your supported frameworks and platforms started at an open source community project like STM32duino. What about Arduino? Are they official by the vendors? Their NanoRP2040 is also not official supported by Mbed(ARM), they forked the repository and made an own solution. Official??? Arduino don't want that their product will supported by Mbed officially.

Many silicon vendors do not see the value in open source and communities, which can make it difficult for us to add support for their products.

The DNA from Raspberry Pi is open source.

PIO is focused on the silicon vendors and this one of the problem.

— Reply to this email directly, view it on GitHub https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1509837833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECUW5ITPS4T56LAGIUYL43XBKRL5ANCNFSM5YLJED5Q . You are receiving this because you commented.Message ID: @.***>

JonnyHaystack commented 1 year ago

@Dantali0n I am not making any assumption one way or the other, just voicing my thoughts and trying to understand the situation. As I said previously, I don't know every side of the situation nor the complex relationships between entities involved. But I am having trouble understanding why the unofficial and demonstrative mbed core is fine, but the much better arduino-pico core cannot be included as a community/unofficial core, as others have also suggested. There appears to be plenty of other precedent as well, so that doesn't seem unreasonable. I don't believe anyone is suggesting it should be considered official, or the primary supported core for Raspberry Pi hardware.

I do feel you took that phrase from my previous comment out of context and dismissed the rest, but I can understand if you think I did not communicate my thoughts clearly enough. No insinuation was intended, and it was merely an oversimplified way of phrasing my thought process. I have no desire to mislead or offend anyone, and am simply hoping to reach mutual understanding through openness and transparency. I see others still have the exact same questions I do, so it would seem that more communication is needed.

Edit: okay, very constructive thumbs down reaction :+1:

Garfius commented 1 year ago

@ivankravets

I just want you to know i ONLY use Platformio because of windows rp2040 debug capabilities without extra hardware. If by chance this stops working i will leave Platformio for good.

I guess there are many developers like me, who need such capabilities. Which are the best way to get into microcontroller development. If "platform = https://github.com/maxgerhardt/platform-raspberrypi.git" ever stops working many people will jump out.

Regards.

ghollingworth commented 1 year ago

Just to note the official Pico Windows installer also supports simple debug out of the box without extra hardware...

Garfius commented 1 year ago

@ghollingworth

Not bad, but it's not Arduino, shrinks software compatibility, just not "the best" option 4 me.

ghollingworth commented 1 year ago

Ah, so not the 'ONLY' reason then!

valeros commented 1 year ago

Hi there, my 5 cents as one of the developers. We would like to clarify that as maintainers, we have a responsibility to carefully consider the features that are added to the community development platforms. Adding new functionality can bring additional burden for maintaining it, which can result in increased costs and resources which we reserved for OSS investment.

We want to emphasize that our ecosystem is vendor-agnostic and open to any architecture, hardware, or software commercial products. We do not have any lock-ins to specific companies or products. We also would like to clarify that as a company, we use an open core business model, which allows us to offer additional features and services to enterprise clients such as Raspberry Pi (Trading) Ltd for a fee. See https://registry.platformio.org/pricing

We would like to encourage you to kindly suggest to RPi to reach out to us to inquire about the possibility of adding the functionality you need. This would allow us to engage in a conversation with RPi about their specific requirements and explore the feasibility of incorporating these features in our open source project.

Thank you for your understanding.

Regards, Your friends at PlatformIO

MCUdude commented 1 year ago

Thanks for your clarification @valeros!

But even if Raspberry Pi Ltd. reached out to you, it would only mean native RP2040 support and not Arduino support that's not based on mbed, wouldn't it?

As an Arduino core maintainer myself I see it as my personal duty to make sure the PlatformIO integration with my cores works as expected. I'm sure the maintainers of Earlphilhowers RP2040 Arduino core will also try their best to keep the work off your shoulders as much as possible.

diminDDL commented 1 year ago

I've been following the discussion around this pull request for a while. I understand the complexity of the issue and see that official support from silicon vendors is crucial for the stability of PlatformIO.

However, I, along with many others, have found the contributions made in this PR to be highly beneficial and more usable than the current Mbed solution. The work done here aligns well with the spirit of open source, which is all about community contributions and collaboration.

Given this, I would greatly appreciate it if you could provide an update on the current status of this PR. Has there been any progress in your discussions with Raspberry Pi Ltd? Additionally, could you please elaborate on the reasons for this PR being left unmerged for such an extended period of time, despite its apparent advantages over the existing solution?

Your transparency and communication on this matter would be appreciated by everyone involved.

maxgerhardt commented 1 year ago

Last week I was contacted by a high level C-suite of the Raspberry Pi foundation to get this resolved, I replied back, but the conversation hasn't gone on yet.

ivankravets commented 1 year ago

@maxgerhardt, thank you for bringing this information to my attention. I must admit, I was taken aback by the situation involving Raspberry Pi Trading Ltd. I had previously held a different perspective on the Raspberry Pi company and its relationship with the open-source community. It is crucial for us to address this issue promptly and allow the community to voice their concerns regarding a commercial entity leveraging PlatformIO for their business interests, using the PlatformIO Community as a guise to evade technology licensing fees.

At PlatformIO Labs, we firmly believe in upholding the principles of transparency and fairness within the open-source ecosystem. While many silicon vendors often consider open-source communities as entities they can freely benefit from, it is important to recognize that open source does not equate to "free." We have adopted an open-core business model at PlatformIO Labs, which means that most solutions for embedded developers are licensed under the highly permissive Apache 2.0 license. Our intention is to provide access to professional embedded software without charging developers directly.

To ensure the smooth operation of our business and to continue investing in innovative solutions for embedded development, we charge licensing fees to silicon vendors seeking access to our ecosystem. This approach enables us to sustainably scale the PlatformIO business. It is critical to emphasize that leveraging the PlatformIO community as a means to avoid these licensing fees is not a viable strategy. Please note that any attempts by commercial entities to integrate their packages without adhering to our licensing requirements will not be approved, as clearly outlined on our pricing page (https://registry.platformio.org/pricing).

Thank you once again for bringing this matter to our attention. We appreciate your support in upholding the integrity of the PlatformIO community and ensuring fair and transparent practices within the open-source ecosystem 🙏

P.S.: We are currently engaged in ongoing discussions with "Raspberry Pi Trading Ltd." and eagerly await their response to our business proposal.

maxgerhardt commented 1 year ago

The email was actually signed with the company name "Raspberry Pi Limited", so I think it's the right entity. But still no further response-- eagerly awaiting.

ivankravets commented 1 year ago

Thank you for the prompt update. I have made the necessary amendment to my comment, removing any mention of the "Raspberry Pi Foundation," as they are not implicated.

ebenupton commented 1 year ago

First off, I'd like to express our gratitude to Max for his amazing work. It's exciting that people have the opportunity to use a high-quality integration of PlatformIO with Raspberry Pi silicon.

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.

As it has been made clear that this PR will not be accepted in the absence of a commercial agreement between Raspberry Pi and PlatformIO Labs, I think it would be best to close it.

nicewrld commented 1 year ago

As an outsider, reading this on Hacker News, this looks like rent-seeking behavior from PlatformIO, looking for a piece of the Raspberry Pi (hah!)

Can PlatformIO provide succinct points for the reasoning against this?

diminDDL commented 1 year ago

As an outsider, reading this on Hacker News, this looks like rent-seeking behavior from PlatformIO, looking for a piece of the Raspberry Pi (hah!)

Can PlatformIO provide succinct points for the reasoning against this?

I second this, I don't think either Microchip or ST is paying PlatformIO to support their chips, yet here we are.

jameshilliard commented 1 year ago

To ensure the smooth operation of our business and to continue investing in innovative solutions for embedded development, we charge licensing fees to silicon vendors seeking access to our ecosystem. This approach enables us to sustainably scale the PlatformIO business. It is critical to emphasize that leveraging the PlatformIO community as a means to avoid these licensing fees is not a viable strategy. Please note that any attempts by commercial entities to integrate their packages without adhering to our licensing requirements will not be approved, as clearly outlined on our pricing page (https://registry.platformio.org/pricing).

I think some of the confusion here is due to seemingly contradicting terminology in various places, if your ecosystem is only open to hardware vendors that have commercial licensing agreements with PlatformIO that would appear to contradict statements such as this on your homepage "A place where Developers and Teams have true Freedom(Use favorite OS, IDE, Hardware and Software tools)! No more vendor lock-in!" which implies developers are free to use and contribute support for new vendor hardware platforms to the open source areas of PlatformIO regardless of whether or not a hardware vendor has made a licensing agreement with PlatformIO.

If I'm understanding the situation correctly you might want to clarify somewhere that PlatformIO is only supported with hardware produced by hardware vendors that have licensing agreements with PlatformIO and that developers need to choose amongst those supported hardware platforms.

It's also unclear what would happen if a hardware vendor were to say stop paying recurring licensing fees/terminate a licensing agreement with PlatformIO or go out of business. Would that mean that PlatformIO would also drop support for the hardware platform as soon as the hardware vendor stopped paying for PlatformIO support?

At PlatformIO Labs, we firmly believe in upholding the principles of transparency and fairness within the open-source ecosystem. While many silicon vendors often consider open-source communities as entities they can freely benefit from, it is important to recognize that open source does not equate to "free." We have adopted an open-core business model at PlatformIO Labs, which means that most solutions for embedded developers are licensed under the highly permissive Apache 2.0 license. Our intention is to provide access to professional embedded software without charging developers directly.

Isn't an open-core business model just one where the closed source components of a project have license fees/restrictions while the open source components on their own do not(aside from any of the usual open source license requirements for a particular component)? It seems odd to use open-core business model as a reason for gatekeeping external contributions to the open source components of a project like in this case.

Many companies build non-opensource applications that run on top of the Linux kernel, however it would be unusual if vendors or community contributors were required to pay licensing fees to say the Linux Foundation or some other organization simply in order to be allowed to submit patches adding new hardware support to the upstream Linux kernel.

A policy such as that would make a project like Linux much less likely to be used in general as that would discourage usage/contributions by hardware vendors and thus in turn would discourage usage of the kernel by software developers.

Thank you once again for bringing this matter to our attention. We appreciate your support in upholding the integrity of the PlatformIO community and ensuring fair and transparent practices within the open-source ecosystem 🙏

As a matter of transparency I think it would be a good idea to add some more detailed vendor hardware license cost information to the pricing page (https://registry.platformio.org/pricing) as it's not clear at all what it costs for a vendor to add support for a new hardware to PlatformIO.

Timvrakas commented 1 year ago

I would imagine that the funding for a specific feature needs to come either from users who are willing to pay, or vendors who are willing to pay. There are enough users willing to pay for Atmel/STM32 support to justify supporting it, and that demand probably doesn't exist yet for RPi.

This request seems reasonable, but the response is also reasonable.

jameshilliard commented 1 year ago

I would imagine that the funding for a specific feature needs to come either from users who are willing to pay, or vendors who are willing to pay.

From what it appears the specific feature in question is already written and the licensing fee is effectively just for merging support.

Since it was stated that "Our intention is to provide access to professional embedded software without charging developers directly." it doesn't seem PlatformIO even has an option for users/developers to pay for new hardware support licensing, it seems PlatformIO specifically wants hardware vendors to have licensing agreements for adding new hardware platforms, although this approach seems to directly contradict the no vendor lock-in statements made in numerous places so I'm not really sure.

There are enough users willing to pay for Atmel/STM32 support to justify supporting it, and that demand probably doesn't exist yet for RPi.

Did users or the hardware vendor pay for Atmel/STM32 support?