371–380 of 413 posts
Earlier quoted context omitted.
It's literally a ROM. You can't overwrite a ROM. There's no flash or EEPROM on the chip at all.
You don’t understand. If there is no DFU the next application cannot be fixed if it broken. Hence bricked. If the boot rom goes right to the sd card image then there is no problem. Almost all embedded devices have a secondary boot loader. Do you understand my question now?
Yes, it has a DFU on the boot ROM.
Earlier quoted context omitted.
You don’t understand. If there is no DFU the next application cannot be fixed if it broken. Hence bricked. If the boot rom goes right to the sd card image then there is no problem. Almost all embedded devices have a secondary boot loader. Do you understand my question now?
Sorry, misread your question. Yes, it has a DFU on the boot ROM.
The 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.
No love for NXP in this thread? They make a very similar peripheral called FlexIO [1] on devices like the K32. >[FlexIO is a] Highly configurable module providing a wide range of functionality including emulation of a variety of communication protocols It is extremely capable! I have used it to hack together an octo-SPI... which stretches the definition of the S in SPI ;) [1] https://www.nxp.com/docs/en/supporting-in…
Earlier quoted context omitted.
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.
Many, many cheap MCUs have peripherals that can decode quadrature in hardware. E.g, PCNT on ESP32, timer modes on STM32 etc. Might as well use PIO to implement I2C or UART :)
Damn TIL, never heard of that. I'll have to try it, thanks!
Earlier quoted context omitted.
Completely agreed. ESP-IDF is incredible and the dev experience is miles beyond STM32 (my opinion).
> STM32 (my opinion). STM32 is horrible, if you don't want to use the HAL.. Everything I used (Atmel, ESP32, rp2040) was better than that - Tho I heard NXP is bad.
The same code will more or less run abstractly on an RP2040, as well (for common peripherals/traits.)
Earlier quoted context omitted.
Did you use esp-idf? Or the Arduino libs?
ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.
If you must use C, ESP-IDF/Arduino aren't terrible. But you still don't really have a package manager or means to abstract anything, especially across devices.
The cohesion present in Embassy between the HALs, probe-rs, etc. is really amazing.
With Embassy for example, I can run the same async/interrupt-driven I2C driver code on any number of different MCUs across various manufacturers. This holds true for many, many different types of peripherals in the ecosystem. For the unique peripherals, implementation style and interface are extremely consistent and high-quality.
Earlier quoted context omitted.
It's safe to assume he's talking about the chip in both cases. You can connect either of them to a battery charger, camera, or nuclear reactor but all of those 'peripherals' are completely irrelevant to this comparison.
But if it's about the chip then just grab any ESP32.
I have mixed feelings about the RP2040. On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application. On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine , but once you start looking into the details it's easy to run into limitations. That XIP int…
What do you mean by USB-C PHY? USB-C is the connector, and you can run USB 1.1/2.0/3.0/3.1 through it, but realistically a RP2040 can not feed even a USB 2.0 PHY.
With PIO or the SPI master and DMA you could absolutely make use of a USB HS PHY.
Earlier quoted context omitted.
> 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…
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.)
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.)
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 plac…
Pico board is the module. I agree that placing the xtal etc is 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.