5 ms·

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful placement of about a dozen components, including a crystal. Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes. Third, the ESP32-S3 has 14 GPIO pins that can be configured to do capacitive touch, while the RP2040 has none. Most of the projects that use RP2040 and capacitive touch rely on the MPR121, an IC that past its EOL and will likely cause a lot of hasty redesigns over the next few months. It's also worth saying that eventually RP2040 will likely release more or less powerful versions, and hopefully versions in a module format. I doubt they will ever let it become an STM or PIC situation, but the ESP32 product lineup doesn't look so crazy once you are acclimatized to it.

geerlingguy 2y ago
It seems like Espressif are in the same situation as Pi w/r/t PlatformIO[1]. As an outsider, it sounds like PlatformIO was trying to extract a very large annual payment from RPi and Espressif, and that was after the initial support was added in, and some of the community started adopting it. It's a weird situation, but I think PlatformIO built up a dominant position by supporting all these platforms and accepting community contributions to do so, then tried extracting value from the manufacturers directly after the fact, blocking further community PRs that would add new board revisions or fix bugs. See related: [2] [1] https://github.com/platformio/platform-espressif32/issues/1225 https://github.com/platformio/platform-espressif32/issues/12... [2] https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36
- peteforde 2y ago
  Thanks for all of your rational contributions to those many threads, Jeff. It is an extremely weird situation, and a deeply bad look. If I was pressed for an opinion, I would say that I wish Eben had taken the high road and gone all in on supporting PIO despite the tangy mystery aftertaste for the simple reason that it would be a net-positive for developers. The way things stand, migrating away from the Arduino IDE to using VSCode with RP2040 feels like you're being actively messed with; there's so many projects and forum posts that sound like the right path, when it seems like the actual answer should be super simple. This is super painful for newcomers.
  - throwup238 2y ago
    Can you provide a TLDR to what the state of things are? I was under the impression that ESPHome was built on top of PlatformIO so this sounds scary...
  - gchadwick 2y ago
    > It is an extremely weird situation, and a deeply bad look I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36 the following happened: - Developer independent of RPi opens PR to add RP2040 support to PlatformIO - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems reasonable) - They discuss this with RPi, ultimately RPi don't want to pay the asked contributions so that PlatformIO are happy maintaining support (this also seems reasonable) - End result is no RP2040 support in PlatformIO Ultimately maintaining things isn't free. RPi have chosen the development environment(s) they wish to support and it hasn't included PlatformIO. What's weird or a bad look?
    - sangnoir 2y ago
      > Ultimately maintaining things isn't free. This is a hypocritical stance for any project that accepts free contributions from the public. Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?
      - KaiserPro 2y ago
        > Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)? Platformio I suspect.
    - moefh 2y ago
      The problem (to me) is that they welcomed that PR and requested corrections until it was in a good enough shape to be accepted, without any indication that it wouldn't be accepted unless/until they had financial support from RPi. That only became clear almost a year after the PR was opened.
127 2y ago
You can do capacitive touch with RP2040 just fine. Turn on, turn off, measure time. Plus I don't like modules as they seem pointless complexity when I just want to order a ready-assembled, self-designed PCB.
- _Microft 2y ago
  I also did not understand this complaint. On a Pico, any GPIO can be used for touch (using PIO of course). Example with 23 touch buttons if I counted that correctly: https://github.com/todbot/picotouch https://github.com/todbot/picotouch
  - peteforde 2y ago
    Thanks for this! I am happy to have been wrong about the touch stuff, because I'm learning a lot.
    - _Microft 2y ago
      The same user has also got a board with touch sliders, consisting of inversely tapering touch areas that allow to compute the touch position along the axis (same for rotary sliders that use three of these in a circle configuration). https://github.com/todbot/picoslidertoy https://github.com/todbot/picoslidertoy
danhor 2y ago
The Pi Pico is intended to be the module format (and can be delivered on reels and used with some PnP machines), though it is much larger than it needs to be for this purpose (and this might be why you didn't mention it). I have only implement touch buttons for hobby projects using a different MCU, but is there a reason to not just use the PIOs for touch sensing?
- deleted 2y ago
  [deleted]
- peteforde 2y ago
  I can appreciate intentions, but a Pi Pico does not compare favorably to a chip module in any regard. It's huge, it only exposes 26 GPIOs. I'm not saying Pico sucks by any means. It has uses and places. It's just very not this: https://www.digikey.ca/en/products/detail/espressif-systems/ESP32-S3-MINI-1U-N8/17728863 https://www.digikey.ca/en/products/detail/espressif-systems/...
crote 2y ago
> The RP2040 requires careful placement of about a dozen components, including a crystal. To be fair, the chip is designed to make these really easy to place. There's pretty much one single layout which makes sense, and it provides easy access to all the pins you could possibly want. Combine that with the excellent documentation they have provided, and it's essentially just a multi-part drop-in design you don't ever have to think about again. It did look a little bit intimidating at first, but it was a genuinely pleasure to implement.
- peteforde 2y ago
  You're kind of making my point for me; when every engineer has to place a dozen components, a non-zero number of them are going to make facepalm mistakes. Even if you create a sub-module layout that you include in every project you work on... that's still n slightly different permutations of the same thing, even if they are all perfect. (They aren't.)
  - petsfed 2y ago
    A non-zero number of engineers will implement "hello world" wrong when they're first learning a language. That's not an argument against any given programming language either. "I made a design error that the documentation specifically calls out as something to avoid" doesn't hold much water as a legitimate criticism. Especially when the design error is "I didn't put the decoupling cap very close to the pin it's supposed to be decoupling for". (as an aside, you should read the "minimal design example" chapter from the RP2040 Hardware Design Guide[0], even if you have zero intention of designing with the chip. It's a literal masterclass in beginner-level pcb design.) Literally none of this is actually a hazard if you design more than one PCBA with a microcontroller on it in your entire life. I'd argue that designing around a castellated-edge module is much MUCH harder to get right on the first try than discrete components, even though the parameter space is apparently much smaller. 0. https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf https://datasheets.raspberrypi.com/rp2040/hardware-design-wi...
  - 15155 2y ago
    > Even if you create a sub-module layout that you include in every project you work on... that's still n slightly different permutations of the same thing, even if they are all perfect. (They aren't.) Part of hardware design is letting go of your neuroses. The real world isn't a perfect place. You operate with the situation you have for the design at hand. Ask yourself why you really need everything to be the exact same. Laying down a handful of capacitors, a single of QSPI flash, and a crystal should become second nature to anyone professionally practicing in this field.. it should take 30 seconds to position and rotate these components near the appropriate pins and not too much longer to route (minutes at most if you've done it before for this MCU.)
olabyne 2y ago
what is the drama with platformIO ?
- peteforde 2y ago
  https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36
SAI_Peregrinus 2y ago
I did manual capacitive touch on an ATMega328. Peripheral support is easier and more reliable, but not strictly necessary. You "just" need a GPIO with analog input and a timer.
adriancr 2y ago
> First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. I'm out of the loop, have been using rp2040 since launch and never used platformIO. How did you use it and what rubbed you the wrong way? Developing locally either with cmake and pico sdk or micropython seems very easy... why add platformio in the mix?
petsfed 2y ago
>Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes. And we've never found a way around that for the decades we've been putting Atmel, STM, TI, Ambiq, Nordic, etc chips in our designs... There's an intern 2 yards away from me who will be wrestling with getting the right components in place around an STM, for his very first pcb design. This is not a hard problem for anyone who has been doing this for any period of time. And anyway, those dozen or so components are the oscillator/crystal circuit, the reset holdup, and the 3.3v supply. And then like a bazillion decoupling caps. Certainly, antenna tuning can be hard, but if you can use chip antennas, its not that hard. All of those are so bog standard that when I looked at e.g. the adafruit RP2040 Feather's schematic, I was sort of surprised at how much is just lifted wholesale from all of their other feathers. Like, the only difference between the RP2040 feather and the nRF52840 feather is the micro itself, the timing circuit (all 5 components of it for the RP2040), and the antenna circuit for the Nordic board. As to the convenience of modules, I submit that they are very handy for sale to the hobbyist market, but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost), so the benefit is a lot more mixed. Even so, you're only saving the antenna tuning step, which is usually done as a BOM variation, not a major trace adjustment. As to the dozens of STM and PIC chips, TI has the same situation. Customers want to pay for only what they need and those manufacturers have the manufacturing capacity to support that desire. Its not daunting if the difference matters. This is very much akin to complaining that Home Depot sells too many different kinds of lumber. As for capacitive touch ICs, sure Adafruit only carries one. But mouser carries 199 that are not end of life. To keep that functionality going, adafruit need only pick up one of them. The cheapest one is even in a TSOT package, so the DFM will be pretty easy. Hell, if I'm not too tired from my job designing and programming these things, I might go home and spin one up tonight. Ought to only take me an hour or so. And the I2C driver another couple hours.
- floating-io 2y ago
  > but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost) I doubt it was your intention given the disclaimer there, but based on my own research into this issue, this is a highly misleading statement, especially for small volume products. Full FCC RF certification is not only very expensive, but also very complex from what I understand. It is NOT an easy process. That is why these modules are so popular in many actual commercial products. If you need FCC certification for your product and use a pre-certified module (and presuming no other radio hardware is present), you only have to undergo the testing for an unintentional radiator I believe, which is a much simpler prospect. The difference in cost is said to be in the neighborhood of $5K to $10K, though I haven't gotten any actual quotes yet, so I can't give anything definitive there. Disclaimer: IANAL of any description, and I have not yet gone through this process myself; I'm just researching it as I get ready to produce a product. Do your own research, or better yet, hire someone who truly knows this stuff!
zbrozek 2y ago
I really don't think there's any significant value to be gained by turning this into a module. Everyone wants a slightly different form factor and the thing is so easy to design around that a module isn't meaningfully achieving anything. Touch is a niche single tasker. I'm glad they didn't include it. Using another ic for that makes sense, and folks being lazy and sticking to an EOL part to provide that functionality isn't RPi's problem. Or do it in software. I'm with the OP on this one, I really think the foundation nailed the product definition.
- aswanson 2y ago
  The pico board is the de facto module for me. Very cheap and breaks out every useful signal.
aswanson 2y ago
Pico board is the module. I agree that placing the xtal etc is too much.
- 15155 2y ago
  Why is placing a single component with massive pads next to the two relevant MCU pins "too much?" I expect to do this exact same exercise with absolutely every single semi-complex IC (MCU or not) I use - it's a routine activity.
deleted 2y ago
[deleted]
g15jv2dp 2y ago
Honestly you just don't need platformio for programming esp32. I tried, and it was just easier to deal with esp-idf than have a middleware with its own quirks on top of esp-idf's own quirks.
mordae 2y ago
> The RP2040 requires careful placement of about a dozen components, including a crystal. I have had 14yo kids do the PCB layout for RP2040 on our custom handheld console. They had no trouble. Nor did I with my ~10 boards. Crystal is the simplest, decoupling can be a chore, but only if you add them too late. Power can be 90% done with a pour under the package.

geerlingguy 2y ago

It seems like Espressif are in the same situation as Pi w/r/t PlatformIO[1]. As an outsider, it sounds like PlatformIO was trying to extract a very large annual payment from RPi and Espressif, and that was after the initial support was added in, and some of the community started adopting it. It's a weird situation, but I think PlatformIO built up a dominant position by supporting all these platforms and accepting community contributions to do so, then tried extracting value from the manufacturers directly after the fact, blocking further community PRs that would add new board revisions or fix bugs. See related: [2] [1] https://github.com/platformio/platform-espressif32/issues/1225 https://github.com/platformio/platform-espressif32/issues/12... [2] https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36

peteforde 2y ago
Thanks for all of your rational contributions to those many threads, Jeff. It is an extremely weird situation, and a deeply bad look. If I was pressed for an opinion, I would say that I wish Eben had taken the high road and gone all in on supporting PIO despite the tangy mystery aftertaste for the simple reason that it would be a net-positive for developers. The way things stand, migrating away from the Arduino IDE to using VSCode with RP2040 feels like you're being actively messed with; there's so many projects and forum posts that sound like the right path, when it seems like the actual answer should be super simple. This is super painful for newcomers.
- throwup238 2y ago
  Can you provide a TLDR to what the state of things are? I was under the impression that ESPHome was built on top of PlatformIO so this sounds scary...
- gchadwick 2y ago
  > It is an extremely weird situation, and a deeply bad look I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36 the following happened: - Developer independent of RPi opens PR to add RP2040 support to PlatformIO - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems reasonable) - They discuss this with RPi, ultimately RPi don't want to pay the asked contributions so that PlatformIO are happy maintaining support (this also seems reasonable) - End result is no RP2040 support in PlatformIO Ultimately maintaining things isn't free. RPi have chosen the development environment(s) they wish to support and it hasn't included PlatformIO. What's weird or a bad look?
  - sangnoir 2y ago
    > Ultimately maintaining things isn't free. This is a hypocritical stance for any project that accepts free contributions from the public. Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?
    - KaiserPro 2y ago
      > Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)? Platformio I suspect.
  - moefh 2y ago
    The problem (to me) is that they welcomed that PR and requested corrections until it was in a good enough shape to be accepted, without any indication that it wouldn't be accepted unless/until they had financial support from RPi. That only became clear almost a year after the PR was opened.

127 2y ago

You can do capacitive touch with RP2040 just fine. Turn on, turn off, measure time. Plus I don't like modules as they seem pointless complexity when I just want to order a ready-assembled, self-designed PCB.

_Microft 2y ago
I also did not understand this complaint. On a Pico, any GPIO can be used for touch (using PIO of course). Example with 23 touch buttons if I counted that correctly: https://github.com/todbot/picotouch https://github.com/todbot/picotouch
- peteforde 2y ago
  Thanks for this! I am happy to have been wrong about the touch stuff, because I'm learning a lot.
  - _Microft 2y ago
    The same user has also got a board with touch sliders, consisting of inversely tapering touch areas that allow to compute the touch position along the axis (same for rotary sliders that use three of these in a circle configuration). https://github.com/todbot/picoslidertoy https://github.com/todbot/picoslidertoy

danhor 2y ago

The Pi Pico is intended to be the module format (and can be delivered on reels and used with some PnP machines), though it is much larger than it needs to be for this purpose (and this might be why you didn't mention it). I have only implement touch buttons for hobby projects using a different MCU, but is there a reason to not just use the PIOs for touch sensing?

deleted 2y ago
[deleted]
peteforde 2y ago
I can appreciate intentions, but a Pi Pico does not compare favorably to a chip module in any regard. It's huge, it only exposes 26 GPIOs. I'm not saying Pico sucks by any means. It has uses and places. It's just very not this: https://www.digikey.ca/en/products/detail/espressif-systems/ESP32-S3-MINI-1U-N8/17728863 https://www.digikey.ca/en/products/detail/espressif-systems/...

crote 2y ago

> The RP2040 requires careful placement of about a dozen components, including a crystal. To be fair, the chip is designed to make these really easy to place. There's pretty much one single layout which makes sense, and it provides easy access to all the pins you could possibly want. Combine that with the excellent documentation they have provided, and it's essentially just a multi-part drop-in design you don't ever have to think about again. It did look a little bit intimidating at first, but it was a genuinely pleasure to implement.

peteforde 2y ago
You're kind of making my point for me; when every engineer has to place a dozen components, a non-zero number of them are going to make facepalm mistakes. Even if you create a sub-module layout that you include in every project you work on... that's still n slightly different permutations of the same thing, even if they are all perfect. (They aren't.)
- petsfed 2y ago
  A non-zero number of engineers will implement "hello world" wrong when they're first learning a language. That's not an argument against any given programming language either. "I made a design error that the documentation specifically calls out as something to avoid" doesn't hold much water as a legitimate criticism. Especially when the design error is "I didn't put the decoupling cap very close to the pin it's supposed to be decoupling for". (as an aside, you should read the "minimal design example" chapter from the RP2040 Hardware Design Guide[0], even if you have zero intention of designing with the chip. It's a literal masterclass in beginner-level pcb design.) Literally none of this is actually a hazard if you design more than one PCBA with a microcontroller on it in your entire life. I'd argue that designing around a castellated-edge module is much MUCH harder to get right on the first try than discrete components, even though the parameter space is apparently much smaller. 0. https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf https://datasheets.raspberrypi.com/rp2040/hardware-design-wi...
- 15155 2y ago
  > Even if you create a sub-module layout that you include in every project you work on... that's still n slightly different permutations of the same thing, even if they are all perfect. (They aren't.) Part of hardware design is letting go of your neuroses. The real world isn't a perfect place. You operate with the situation you have for the design at hand. Ask yourself why you really need everything to be the exact same. Laying down a handful of capacitors, a single of QSPI flash, and a crystal should become second nature to anyone professionally practicing in this field.. it should take 30 seconds to position and rotate these components near the appropriate pins and not too much longer to route (minutes at most if you've done it before for this MCU.)

olabyne 2y ago

what is the drama with platformIO ?

peteforde 2y ago
https://github.com/platformio/platform-raspberrypi/pull/36 https://github.com/platformio/platform-raspberrypi/pull/36

SAI_Peregrinus 2y ago

I did manual capacitive touch on an ATMega328. Peripheral support is easier and more reliable, but not strictly necessary. You "just" need a GPIO with analog input and a timer.

adriancr 2y ago

> First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. I'm out of the loop, have been using rp2040 since launch and never used platformIO. How did you use it and what rubbed you the wrong way? Developing locally either with cmake and pico sdk or micropython seems very easy... why add platformio in the mix?

petsfed 2y ago

>Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes. And we've never found a way around that for the decades we've been putting Atmel, STM, TI, Ambiq, Nordic, etc chips in our designs... There's an intern 2 yards away from me who will be wrestling with getting the right components in place around an STM, for his very first pcb design. This is not a hard problem for anyone who has been doing this for any period of time. And anyway, those dozen or so components are the oscillator/crystal circuit, the reset holdup, and the 3.3v supply. And then like a bazillion decoupling caps. Certainly, antenna tuning can be hard, but if you can use chip antennas, its not that hard. All of those are so bog standard that when I looked at e.g. the adafruit RP2040 Feather's schematic, I was sort of surprised at how much is just lifted wholesale from all of their other feathers. Like, the only difference between the RP2040 feather and the nRF52840 feather is the micro itself, the timing circuit (all 5 components of it for the RP2040), and the antenna circuit for the Nordic board. As to the convenience of modules, I submit that they are very handy for sale to the hobbyist market, but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost), so the benefit is a lot more mixed. Even so, you're only saving the antenna tuning step, which is usually done as a BOM variation, not a major trace adjustment. As to the dozens of STM and PIC chips, TI has the same situation. Customers want to pay for only what they need and those manufacturers have the manufacturing capacity to support that desire. Its not daunting if the difference matters. This is very much akin to complaining that Home Depot sells too many different kinds of lumber. As for capacitive touch ICs, sure Adafruit only carries one. But mouser carries 199 that are not end of life. To keep that functionality going, adafruit need only pick up one of them. The cheapest one is even in a TSOT package, so the DFM will be pretty easy. Hell, if I'm not too tired from my job designing and programming these things, I might go home and spin one up tonight. Ought to only take me an hour or so. And the I2C driver another couple hours.

floating-io 2y ago
> but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost) I doubt it was your intention given the disclaimer there, but based on my own research into this issue, this is a highly misleading statement, especially for small volume products. Full FCC RF certification is not only very expensive, but also very complex from what I understand. It is NOT an easy process. That is why these modules are so popular in many actual commercial products. If you need FCC certification for your product and use a pre-certified module (and presuming no other radio hardware is present), you only have to undergo the testing for an unintentional radiator I believe, which is a much simpler prospect. The difference in cost is said to be in the neighborhood of $5K to $10K, though I haven't gotten any actual quotes yet, so I can't give anything definitive there. Disclaimer: IANAL of any description, and I have not yet gone through this process myself; I'm just researching it as I get ready to produce a product. Do your own research, or better yet, hire someone who truly knows this stuff!

zbrozek 2y ago

I really don't think there's any significant value to be gained by turning this into a module. Everyone wants a slightly different form factor and the thing is so easy to design around that a module isn't meaningfully achieving anything. Touch is a niche single tasker. I'm glad they didn't include it. Using another ic for that makes sense, and folks being lazy and sticking to an EOL part to provide that functionality isn't RPi's problem. Or do it in software. I'm with the OP on this one, I really think the foundation nailed the product definition.

aswanson 2y ago
The pico board is the de facto module for me. Very cheap and breaks out every useful signal.

aswanson 2y ago

Pico board is the module. I agree that placing the xtal etc is too much.

15155 2y ago
Why is placing a single component with massive pads next to the two relevant MCU pins "too much?" I expect to do this exact same exercise with absolutely every single semi-complex IC (MCU or not) I use - it's a routine activity.

deleted 2y ago

[deleted]

g15jv2dp 2y ago

Honestly you just don't need platformio for programming esp32. I tried, and it was just easier to deal with esp-idf than have a middleware with its own quirks on top of esp-idf's own quirks.

mordae 2y ago

> The RP2040 requires careful placement of about a dozen components, including a crystal. I have had 14yo kids do the PCB layout for RP2040 on our custom handheld console. They had no trouble. Nor did I with my ~10 boards. Crystal is the simplest, decoupling can be a chore, but only if you add them too late. Power can be 90% done with a pour under the package.