Earlier quoted context omitted.
no, of course not
I dont see why that's obvious.
I like the RP2040
241–250 of 413 posts
Re: I like the RP2040
#242Earlier quoted context omitted.
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.
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
Re: I like the RP2040
#243I switched from ESP32 to the RP2040 because it's a much more reliable and documented device. My only concern right now with the RP2040 is that there are many ESP32 models with SPIRAM but it's not so simple to find a SPIRAM equipped RP2040 board. To be honest, given that the C development environment of the RP2040 is so good, you can make good use of the memory, but when one wants to develop a large MicroPython projec…
Re: I like the RP2040
#244We've been using the RP2040 in the electronic badges[1] for the RVASec security conference[2] for the past several years, and it's been very nice to write software for. Here's the github repo for this year's badge (there's a software-only badge simulator so you can kind of play around with it even without the hardware, although some of the multi-player things that rely on infrared badge-to-badge communication won't b…
Re: I like the RP2040
#245The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Things like battery life will probably improve with experience, I was talking to a silicon guy about the RP2040 and they said it's pretty characteristic of a first generation design. The digital logic that can be validated on an FPGA is fine for the most part, but the analog elements are much more difficult to fine tune, hence the poor power consumption, poor ADCs, and lack of internal DACs or opamps in the RP2040, a…
Re: I like the RP2040
#246The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Ditto for robotics. 8 PIO units are enough to read and log four quadrature encoders at practically no interrupt cost, so it's possible to build a perfectly performant closed loop controller in something as slow as Micropython.
Some lovely person got a quadrature decoder into 24 instructions, so you can potentially still do something useful on the same PIO block if you only need one or two quadrature encoders.
Re: I like the RP2040
#247Earlier quoted context omitted.
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
Thanks for this! I am happy to have been wrong about the touch stuff, because I'm learning a lot.
Re: I like the RP2040
#248The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Comparing ESP32 to RP2040 is like comparing oranges to apples. If you need a lot of IO - you're probably not looking at ESP32. It's just cheap and has WiFi builtin. There are many options for other MCUs, that compare favorably to with RP2040... though majority aren't for the hobbyist market.
That's pretty interesting, could you list some?
Re: I like the RP2040
#249Earlier quoted context omitted.
> Decoupling capacitors need to be placed "close" to the chip All of these rules are just rules of thumb. The "rule" is that your Power Delivery Network (PDN) needs to have low-enough impedance to function properly. High parallel capacitance and low series inductance/resistance. Longer leads increases inductance and resistance so closer is preferred. But for even 100MHz designs, you're well under the size where 100mi…
Fair enough. I've taken digital logic classes etc. in college but when it comes to practical circuit design I'm mostly self-taught, having worked my way up from all through-hole components with ATmega and similar devices to dipping my toe in the SMD waters with larger TQFP parts to now doing a few designs with the RP2040. I've tried to educate myself on best practices and follow recommended layouts and things like th…
In contrast, we hobbyists deal with "rules of thumb", because none of us will spend $4000+ on professional PCB software that run these calculations for us. And furthermore, we aim very conservative because its very difficult to debug a PCB layout issue... as we hobbyists are functionally blind to all of these issues (ex: trace inductance, trace capacitance, or other issues).
I think spending a good bit of time on PDN / grounding / etc. etc. study is very worth your while.
https://www.youtube.com/watch?v=ySuUZEjARPY
2+ hour talk on just the issue of good "grounding" design in PCBs, but it does relate to this issue of capacitors, trace-lengths and the like. I feel like you'd benefit from this talk.
The "correct" way of thinking is exceptionally complex, far more complex than what is taught in colleges. But you have all the basic ideas thanks to the old rules of thumb. You just need to take the next step to see what the problems are.
--------
And as you'll see, traces on the same side of a board are cake. Its things like vias that actually wreck you.