31–40 of 54 posts
> Power is applied to the chip, and the RUN pin is high. The chip will be held in reset for as long as RUN is not high. Is that a typo, or do I not understand this? Should it be "as long as RUN is high"? Because I assume that the RUN pin is active low, so as long as it is high, the chip will be held in reset?
This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…
> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find i…
Earlier quoted context omitted.
I think it depends on what you want. Having worked quite a bit with both, I think the average beginner would find the rp2040's cmake based SDK more accessible than stm32cube, which I dislike immensely. The CircuitPython support is also really interesting for somebody who isn't a programmer but wants to experiment. But if you're already an experienced programmer and want to roll your own stuff, I absolutely agree stm3…
I’m a programmer but appreciate CircuitPython. I used the KB2040 to build two bespoke mini keyboards. It took just a few dozen lines of Python. Couldn’t be happier with it.
Earlier quoted context omitted.
I get the perspective. And I agree that RP2040 needs the equivalent of STMCube or even CubeMX. But they're not there yet. Are they banking on the community to provide that with the same amount of love that RPi got? I don't see that happening for multiple reasons.
I think their aggressive price point is at odds with their mission. The mission used to be "unit of computing for education and makers at a super low pricepoint". This feels more like "create the lowest pricepoint possible".
Arduino is now going through the same experience, they have a "pro" line where they're trying to compete with existing Linux SBCs in the industrial space like Phytec, Variscite, or Kontron. But they can't match on cost yet.
Earlier quoted context omitted.
> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find i…
Personally, I want a processor agnostic platform. I don't want to invest in one processor only to find out later that I needed USB2.0 instead of USB1.1, and then needing to read 500 pages of datasheets to move to a different platform. Reading datasheets was nice at one point, but now it feels more like filling out tax forms.
Earlier quoted context omitted.
That doesn't seem unusual to me, given that to get to this page you either have to be searching for the specific terms already (and know what they are) or come from the homepage -> RP2040 (Raspberry Pi Pico) projects -> Custom serial bootloader for the RP2040 -> Preliminary reading RP2040 boot sequence
I came to that page directly from the front page of HN. I think it's reasonable to assume a significant portion of their traffic today directly to this page didn't already know what RP2040 is. Missed opportunity to educate readers.
Do you expect every SF Chronicle article to explain to you what SF is?
For those wondering about why there's both a boot ROM and the boot2 in flash: The flash chips used support both a basic SPI mode, and an advanced QSPI mode. There is a well-defined standard protocol for basic SPI mode, so virtually all chips will respond to the same read command for simple slow byte-by-byte reading. The only thing left to try is the four SPI modes (Does clock idle high or low? Do we transfer on the f…
For those wondering about why there's both a boot ROM and the boot2 in flash: The flash chips used support both a basic SPI mode, and an advanced QSPI mode. There is a well-defined standard protocol for basic SPI mode, so virtually all chips will respond to the same read command for simple slow byte-by-byte reading. The only thing left to try is the four SPI modes (Does clock idle high or low? Do we transfer on the f…
Great info, and now some chips are supporting Octo-SPI which is even more vendor dependent. At some point we're basically back to parallel flash...
This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…
Once you get into ARM territory it inherently gets very complex very quickly. They are massive chips made of multiple IP blocks from different vendors which have been glued together. Full documentation easily gets into the thousands of pages. The RP2040 has excellent documentation, and even that is barely enough to be usable.
With the exception of a very small group of people at the design company, essentially nobody is hand-writing assembly. There's just no point: it's incredibly complicated, and it takes orders of magnitude longer than just using the provided SDK. This makes hand-writing it only an option for hobbyists: nobody wants to pay for their engineer to spend a lot of time doing it in a worse way. Turns out "I hate cmake" isn't a very good reason to waste tens of thousand of dollars in engineer-hours.
But even for the hobbyist the SDK is probably the better choice. The one provided for the RP2040 is quite well-made, and even if you hate cmake just copy/pasting its C code into your own cmake-less toy SDK probably makes more sense than reinventing the wheel yourself.
Earlier quoted context omitted.
> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find i…
Isn't the toolchain for the esp almost fully open source (ESP-IDF)? The only part that aren't super open on the esp32 are the radio related firmware and blobs, but those are just not even there in the rp2040 anyways and not related to the toolchain itself.
It's still open-source so a lot better than having to use a proprietary compiler or IDE, but it's a lot more involved than just your regular bundle of C libraries you can use with your normal tooling.