Otherwise, NXP FlexIO is very similar to PIO and these are much more capable chips.
I like the RP2040
281–290 of 413 posts
Re: I like the RP2040
#282Earlier quoted context omitted.
FYI. In the embedded space, peripherals refer to the chip's built in capabilities. Typically there is a peripheral that handles SPI, a peripheral that handles I2C, a peripheral that handles USART. There might be a peripheral that handles USB, or I2S, or any number of different abilities. It's either transistors or microcode on more sophisticated MCUs that allows these peripherals, and not every pin is connected to ev…
> Worse, is when the datasheet makes this difficult to discern, That's why I like RP2040 so much. Datasheet is amazing and clear, even for someone like me who hasn't spent too much time in embedded world. There is a special, much shorter document just for hardware design that makes designing a board that uses RP2040 even easier.
Look at any Nordic part or NXP part to see what a datasheet is supposed to look like. 3000+ pages with register documentation and behavioral examples.
Re: I like the RP2040
#283Earlier quoted context omitted.
You can't run Linux on DRAM. You need a CPU.
You can't run anything on an RP2040. There's no Flash or code space. RP2040 sits at an awkward placement. It requires external parts, but low end SPI parts and not the nicer proper RAM like DDR3L or the like. ------ My point is that if you have a design that fundamentally requires external parts like the RP2040, the accurate comparison is against MPUs. Chips that are specifically designed to work with powerful and co…
https://www.microchip.com/en-us/products/microcontrollers-an...
Re: I like the RP2040
#284I 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…
I heavily disagree. I‘ve been working with the Espressif ecosystem for a couple of months now and it‘s the best documented microcontroller platform out there.
Re: I like the RP2040
#285Earlier quoted context omitted.
Funny, I had the exact opposite experience. For OSH Stencils, they had a scaling issue with their setup that I pointed out to them, and they just shrugged and said that was the nature of the beast essentially and they couldn't do anything about it. They might have said something about Kapton shrinkage or some such. (I don't currently have the exact numbers, but it was off a couple of percent linearly, which doesn't m…
Hmmm, maybe my designs have been small enough that it hasn't been an issue. I'll keep your experience in mind then. Thanks for sharing your experience.
Re: I like the RP2040
#286Earlier quoted context omitted.
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…
Though it's a continuing puzzle to me why ESPs have worse ADCs than the rp2040, given their relative maturity. (Neither is particularly good, mind you, but I'm generally ok with the rp for my toy applications.)
Re: I like the RP2040
#287Earlier quoted context omitted.
> Worse, is when the datasheet makes this difficult to discern, That's why I like RP2040 so much. Datasheet is amazing and clear, even for someone like me who hasn't spent too much time in embedded world. There is a special, much shorter document just for hardware design that makes designing a board that uses RP2040 even easier.
The RP2040 has one of the shortest datasheets of any MCU. Look at any Nordic part or NXP part to see what a datasheet is supposed to look like. 3000+ pages with register documentation and behavioral examples.
I’m not talking size of documentation, but it’s “bio-availability”.
Re: I like the RP2040
#288The lack of built-in flash kills it for me. STM32 M3s with comparable throughput are cheaper and don't require an external flash chip (example: STM32F103C8T6 for $1.20 from jlc). I love the generic PIO though, I really hope other manufacturers pick up on that.
I used to have the same beliefs but the flexibility of being able to use just about any pin for any purpose really sold me on the RP2040. When I decide to add a new feature to my boards I don't have to spend an hour examining the minutiae of the data sheet to see if I can use a given pin for SPI (oops: no, I can't because I enabled alternate function 3...). It saves a TON of track routing time and simplifies boards c…
The pin flexibility is nice, I agree with you there. But I spend more time dealing with the flash chip than that saves me.
I don't want more capability. An STM32 M3 has far far more processing throughput than I need for 99.9% of what I do. I want the smaller thing, even if it isn't cheaper. It is sufficient.
I love stm32s because I can write bare metal C without using any of stmicro's libraries at all (except the one header defining the register offsets). Here's an example: https://github.com/jcalvinowens/ledboard/blob/master/firmwar...
The rp2040 is not set up to easily let you do minimalist stuff like that. And after all, why would they go to the trouble? You have 16MB of flash to waste on library code you never call... it's like buying a mack truck to commute to work.
I'll also echo the other comment about the cache: if you actually have megabytes of .text, you're gonna have a bad time.
Re: I like the RP2040
#289I 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 plac…
> 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…
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!
Re: I like the RP2040
#290Earlier quoted context omitted.
Did you use esp-idf? Or the Arduino libs?
ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.