[HN Gopher] I like the RP2040
___________________________________________________________________
I like the RP2040
Author : dgroshev
Score : 391 points
Date : 2024-06-11 13:39 UTC (9 hours ago)
(HTM) web link (dgroshev.com)
(TXT) w3m dump (dgroshev.com)
| written-beyond wrote:
| Inb4 esp32
| cockings wrote:
| It's mentioned in the article.
| topspin wrote:
| That bit of snark is about the ESP32 brigade that plagues
| every project or story that involves any non-ESP32 MCU,
| including this one. Yesterday I watched a long live video by
| the engineer of a open source engine management system, and
| he too had to deal with the ESP32 brigade in live chat. He
| has entirely reasonable technical justifications for his
| choices, and his explanation had about as much impact with
| the ESP32 brigade as I've come to expect.
| written-beyond wrote:
| Look my comment was just a place holder for that brigade, I
| was just trying to keep it isolated to this comment so it
| doesn't plague the rest of the article. I genuinely find
| other MCUs very interesting and love reading about them and
| exploring them. However I do this Espressif has earned the
| fans and following they have.
|
| I've had the liberty of working with older platforms like
| the PIC32, and while I agree that every MCU has it's own
| use case, the developer community Microchip has no
| comparison to Espressifs. I will admit that I may be
| comparing apples to oranges.
| cide1 wrote:
| The lack of security features really limits where this can be
| used in commercial designs.
| hitekker wrote:
| Can you explain how? Genuinely curious. The author only refers
| to "security theater" which seems to be when a product or
| system around a product makes people feel like they're safer,
| when actually it's not making anything more safer or more
| secure.
|
| https://en.wikipedia.org/wiki/Security_theater
| kj4ips wrote:
| I suspect this mostly refers to "Code Protect" or similar
| functions, that are designed to stop the user for extracting
| the firmware from a device in the field. Typically, when this
| is enabled, large parts of the debug interface stop working,
| and turning it off requires a "secure" erase, that clears the
| loaded firmware.
|
| While many CP implementations are flawed, or can be bypassed
| by a skilled attacker (power glitching, &c), I wouldn't say
| they are purely theater, as they raise the required
| investment from a <$10 ISP to $$$+ for something like a
| chipwhisperer.
| relaxing wrote:
| Consider that in other fields of computer security we treat
| a device where attackers have physical access to be de
| facto compromised.
| riskable wrote:
| Even with chip security features this is still the case
| (if an attacker gets their hands on it it can be
| compromised). There's no chip that exists that I'm aware
| of that can't be compromised to have its firmware dumped.
|
| It's like locks: Every time a manufacture claims to have
| made an unpickable lock someone goes and picks it. It's
| the same for chip security features.
|
| Microcontroller "security" features really are security
| theater and not actual security. The only _real_ reason
| they exist is because certain vendors /"big buyers" will
| require it as part of their parts checklists (which is
| silly) and it provides a way for chip manufacturers to
| wriggle more money out of each sale.
| ndiddy wrote:
| In general, read-out protection provides a very limited level
| of protection that I wouldn't rely on to stop cloning. There's
| quite a few firms that will extract the firmware from protected
| microcontrollers for a couple thousand dollars (i.e.
| https://russiansemiresearch.com/ ) which is a drop in the
| bucket considering the potential profit from industrialized
| cloning. Lots of microcontroller series also have exploits that
| can allow hobbyists with very little funding to bypass read-out
| protection (here's one for the STM32F0 series for example:
| https://github.com/racerxdl/stm32f0-pico-dump ).
| the__alchemist wrote:
| I suspect the use cases where MCU security features are useful
| is dwarfed by those that are not.
| cockings wrote:
| > The RP2040 is impossible to brick. It comes with a read-only
| bootloader that can either mount as a USB mass storage device
| (firmware updates can just be copypasted to the "storage
| device"), or use its own simple USB protocol.
|
| Can anyone explain what this means? How is it both read-only and
| updateable? If the latter, how is it unbrickable?
| orlp wrote:
| The bootloader is read-only. What the bootloader loads isn't.
| If the thing you're trying to boot into is faulty, it doesn't
| matter because you can just replace the thing the bootloader is
| trying to load.
|
| If the bootloader itself was faulty, the device would be
| bricked.
| sshine wrote:
| To elaborate on the alternative:
|
| When the bootloader is not read-only, you can upload another
| bootloader.
|
| This is great in a different way because custom bootloaders
| allow for more flexibility.
|
| For example, you may want to keep two copies of your firmware
| on the chip: One that you're uploading, and one you can fall
| back to if the most recent one has problems. This protects
| you against failure during firmware upload or post-deployment
| failure, because you only overwrite one of the two. So if the
| device switches off while flashing it, and you boot back up,
| a custom bootloader can just default to the older copy.
|
| But... what if you update the bootloader and _it_ fails?
|
| Then you can't use the bootloader to upload new firmware.
| Bricked.
|
| To unbrick a bootloader you need to overwrite the bootloader
| using alternative methods that don't involve the bootloader,
| which usually involves attaching wires to the print. This is
| highly inconvenient in a production setting: Maybe your
| hardware is encased, embedded in a bigger thing, or located
| on a pole on a mountain top in a different country.
|
| So a read-only bootloader is a safe choice, and you can make
| other workarounds wrt. flexibility.
| HyulianGrader wrote:
| Nobody in their right mind is updating a bootloader in the
| field OTA, let alone one inaccessible on a mountain top.
| freedomben wrote:
| I don't disagree, but it leads to the question from the
| security guy: how do you fix CVEs in the bootloader after
| it's shipped (aka in the field)?
| HyulianGrader wrote:
| If you anticipate the need to update the bootloader, you
| would use a multistage bootloader approach where the
| first is never altered (as the bootloader should never be
| altered) and its main function is to select which
| updatable second stage bootloader to load from multiple
| options (multiple so that even if one is interrupted mid-
| update by the application, there is a valid fallback).
|
| My gut says if you're worried about this in the
| bootloader, it might be doing too much.
| dfox wrote:
| Particularly neat approach to both reducing the attack
| surface of the bootloader and improving the reliability
| of the actual OTA update process is to have only the
| bootloader flash the active application/second-stage
| flash partition. The idea is that the normal application
| code somehow acquires the new version, verifies it and
| writes it into separate flash partition and then reboots,
| bootloader sees that record and, does minimal check for
| correctness and flashes that to right location. That way
| the bootloader does not have to know anything about how
| to get the new firmware image and does not process any
| untrusted input.
| AlotOfReading wrote:
| You don't.
|
| When I actually have these conversations with security
| guys, it's because they've either missed their window on
| contributing to part selection (in one case because that
| team hadn't been hired yet!) or no one consulted them in
| the first place. In both cases the solution is to write
| some guidelines and get the EEs to use them during part
| selection in the future.
| dave78 wrote:
| I used to work on a product where we did exactly that,
| and the devices literally ran on mountain tops. Our
| development and testing process was very rigorous and
| would be unrecognizable to most developers today,
| however. We certainly weren't shipping new code to those
| devices after every sprint.
| dgroshev wrote:
| You can have several bootloader stages, and in fact that's
| how the RP2040 works [1]!
|
| Stage 1 bootloader is the one in ROM and it normally just
| reads stage 2 from the flash chip. Stage 2 then initialises
| the flash properly, and you can have further stages like
| [2] to implement the trial-rollback procedure.
|
| Stage 1 is a safety net, even if the trial-rollback
| procedure goes terribly wrong the device can still be
| unbricked over USB.
|
| [1]: https://blog.usedbytes.com/2021/12/pico-serial-
| bootloader/
|
| [2]: https://embassy.dev/book/#_bootloader
| ndiddy wrote:
| He's saying that the bootloader is in ROM so it's unbrickable,
| but the application code that the bootloader jumps into can be
| updated over USB. Most mid-range and higher microcontrollers
| have a similar feature, but they almost always have a custom
| protocol that requires a specialized flashing program rather
| than showing up as a mass storage device.
| seba_dos1 wrote:
| To be frank, I don't get its appeal at all. Most hobbyist uCs
| were already unbrickable, and using mass storage mode for
| flashing is rather cumbersome and clunky to automate as soon
| as you're past hello worlds.
| jrockway wrote:
| I've never had great luck with the mass storage flashing.
| It works fine, but boy is it slow. I bought a J-Link a few
| years ago and haven't looked back.
|
| (It just takes a long time for the OS to recognize a USB
| device. And you have to press the reset button yourself in
| order to enter the bootloader. With something like J-Link,
| your build script can handle pressing the reset button and
| sending the code, saving you quite a bit of time between
| iterations.)
| drrotmos wrote:
| A debug probe is nice (quite possibly a must) if you're
| actively developing, but for _deploying_ in a hobbyist
| environment, USB is hard to beat.
|
| I make open source espresso machine hardware
| (github.com/variegated-coffee), and it's nice to be able
| to give users a wired way to update firmwares that
| doesn't require extra hardware.
| timenova wrote:
| Hence they made the Pico Debug Probe [0]. It makes it super
| easy to reflash firmware to the Pico in a quick iterative
| loop.
|
| However, the appeal of mounting as a mass storage device is
| not for iterative development (as you mentioned).
| Invariably something breaks, and the easiest way to get
| back on track is to reflash their default blank firmware
| using the mass storage interface.
|
| [0] https://www.raspberrypi.com/products/debug-probe/
| seba_dos1 wrote:
| I can use things like dfu-util or esptool for quick
| iterative loops without any additional hardware. Hence my
| point - mass storage is a downgrade over what other uCs
| on the market were already doing with their ROM
| bootloaders before RP2040.
| moefh wrote:
| Just to note: with the RP2040 you don't need additional
| hardware (debug probe) for quick iterative development,
| you can use picotool[1] (using -f allows you to flash and
| reboot without needing to get it to bootsel mode).
|
| [1] https://github.com/raspberrypi/picotool
| seba_dos1 wrote:
| ...and it doesn't use mass storage at all, blocking
| access to it in a clunky way to prevent simultaneous
| usage.
|
| UMS seems like a nice idea when you first hear about it,
| but it doesn't really offer much once you look at it
| closer. The only proper argument for it is "no special
| software needed", but it a world where picotool is `apt
| install picotool` away that's not very advantageous
| anyway and only causes automount annoyances.
|
| UMS shines where you have a device with a filesystem in
| its flash that you can access to actually manage the
| files stored there. Super useful for stuff like
| MicroPython. In contrast, pseudo-mass storage like on
| RP2040 doesn't seem very useful at all. It makes it
| _appear_ more approachable, but only superficially.
| dfox wrote:
| The whole UF2 idea has to do with the educational
| background of RaspberryPi. The protocol was invented by
| Microsoft for use in some kind of similar educational
| board with the express purpose of not needing drivers,
| being reasonably crossplatform and crucially not needing
| any special permissions to access the device. The end
| result is that in some kind of educational setting you
| can use some kind of cloud/remote IDE on iPad, stick the
| RPi-Pico into the iPad and flash it, no blessing from
| Apple needed.
| seba_dos1 wrote:
| Oh. So it's just a result of locked-down walled gardens
| being so widespread that they influence the world around
| them. Depressing, but thank you for pointing it out
| anyway; on my phone I can just run picotool itself and
| it's easy to forget how dystopian it all got outside of
| the niche I'm in.
| dgroshev wrote:
| I completely agree that it's inconvenient as a developer
| tool, a debug probe is much, much nicer.
|
| I just think that despite all testing and care bugs are
| still possible, and the ROM bootloader is a backup that's
| always there. Plop a tiny switch on the PCB, and even if I
| screw up an OTA update customers will still be able to
| flash with no special tools (if the device has a USB port,
| that is).
|
| I also use it as a recovery state for panics, makes the
| device impossible to brick by a panic loop.
| seba_dos1 wrote:
| > I just think that despite all testing and care bugs are
| still possible, and the ROM bootloader is a backup that's
| always there.
|
| That's orthogonal to mass storage mode. ROM bootloaders
| were standard in this class of microcontrollers for
| years, but they usually don't use UMS. One could argue
| that UMS is perhaps better than some custom incompatible
| solutions, but then that's what DFU is there for - a
| standard way to flash things over USB.
| crote wrote:
| Interesting, I've got the exact opposite experience.
|
| Small to medium production runs are always a bit of a pain,
| because you have to do a lot of coordination with the
| factory when it comes to tooling. You have to ship a custom
| programmer, get them to install the drivers on _whatever_
| OS they are using, and then find a way to write custom code
| to interact with the programmer and deal with all the
| possible error conditions.
|
| The RP2040? A simple script which detects the presence of a
| RPI-labelled flash drive, copies a file, and repeats.
| Written in half an hour. Drivers? Not an issue. Hardware?
| Everyone has a USB cable lying around already. Error
| conditions? It either succeeds, or it doesn't - the OS
| handles the rest.
| perbu wrote:
| The bootloader is read-only, the firmware it boots is
| updateable.
|
| The bootloader allows you to update the device with new
| firmware. MCU are different than computers. And since you can't
| overwrite the bootloader, you can't brick the MCU. You can
| always just reset it.
|
| fwiw; I've never bricked an MCU buy flashing something weird
| onto it. The hobbyist MCUs sold are typically quite easy to re-
| flash with new firmware.
| mkj wrote:
| Unbrickable for the RP2040 itself, but most SPI flash chips
| (including ones on the RP Pico) have permanently lockable
| regions. You can lock them open though.
| cryptonector wrote:
| I think it's saying that firmware updates are not persistent.
| You have to apply them every time at boot time. So if it boots
| once, it will boot every time. If you ever get bad firmware,
| you just rollback or roll further forward in your boot media.
| BruceEel wrote:
| data sheet:
| https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
| HyulianGrader wrote:
| nit: There are 6 different espressif microcontrollers in that
| table, not "dozens".
|
| Espressif also went many years with only the ESP8266, then many
| years more after introducing the ESP32 before this recent binge
| of releasing a new series every time they blink. ESP-IDF is
| really suffering for it, so I hope Raspberry avoid this fate or
| at least find a better way to support them all.
| em3rgent0rdr wrote:
| Considering how many different Raspberry Pis are out there now,
| I wouldn't be surprised if the Raspberry Foundation makes a
| plethora of newer microcontrollers.
| rdlw wrote:
| https://products.espressif.com/#/product-selector?language=e...
|
| This is the official Espressif "ESP Product Selector". I
| checked everything in the ESP series, and limited to "Mass
| Production" status, and then it showed me a list of 175
| products.
|
| I'm sure some of those are doubled up, or just the same chip
| with different packaging options or whatever, but as a
| potential customer I'm still presented with 175 things and told
| to pick one.
| dfox wrote:
| Most of that are not bare microcontrollers (or "SoC"s as
| Espressif calls it), but entire modules with different
| combinations of SoC, Flash, PSRAM, antenna configuration and
| packaging. If you filter only SoCs, you get 39 products,
| which in fact are 9 different chips and rest are packaging
| variants and versions with package-on-package Flash.
| ajsnigrutin wrote:
| Many of the variants listed are the same chip but with
| different amounts of storage, oboard vs external (vs both)
| options, etc.
| g15jv2dp wrote:
| How is ESP-IDF "suffering for it"?
| antirez wrote:
| I 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 project, the SPIRAM is really a
| great asset. Other than that, everything about the RP2040 is just
| great.
| dgroshev wrote:
| I ended up cutting a section on Rust support from the post, but
| if you're open to Rust (iirc you were sceptical at some
| point?), async Rust is really pleasant to use in embedded.
| Dario Nieuwenhuis, one of the main people behind Embassy, gave
| a great overview talk at RustNL:
| https://www.youtube.com/watch?v=H7NtzyP9q8E
| the__alchemist wrote:
| I disagree. Rust on embedded is fantastic (I do STM32
| programming on rust all the time, and have used the RISC-V
| ESP chips and nRF-52 as well), but Async Rust on embedded
| suffers from the same problems of contagion and coloring that
| non-embedded async rust has.
| fleventynine wrote:
| Everything had tradeoffs, but the composability of the
| state machines built by the compiler's async support allows
| you to easily build multi-tasking bare-metal systems with
| thousands of "tasks" and no RTOS (or SRAM-wasting threads).
| I highly recommend playing with Embassy for a week before
| discounting this approach for embedded software.
|
| If you care about RAM consumption, you need to share the
| stack between tasks, forcing you to write event-driven
| code. Rust async makes this easy, and a bit of function
| coloring is no big deal compared to converting blocking
| code into event-driven code the traditional way...
| the__alchemist wrote:
| I have - it does not avoid the structural and
| compatibility problems of Async in other contexts.
| fleventynine wrote:
| Can you go into more details? Most of the criticism I've
| read tends to be more abstract ("I don't like how ALL my
| blocking-style calls need to be async"), and doesn't
| propose an alternative mechanism to async that can
| provide a similar coding style in the same tight RAM
| footprint.
| the__alchemist wrote:
| I think you'll find details regarding any discussion of
| async in rust and other languages - I don't mean to
| casually dismiss your question, but my objections are not
| unique.
|
| The alternative mechanism is to use interrupts, DMA,
| multiple cores, distributed devices (eg a CAN network) a
| state machine, an RTOS, or, it sounds like in context of
| this thread, PIOs! You get the point. Do these provide a
| similar coding style? No, and that's the point. The
| coding style _is_ the objection.
|
| I find the "how else would you do it" style questions
| that come up frequently re Async rust (embedded or not)
| amusing. It's as if there is a new method of
| accomplishing a task, and asking a world that has been
| accomplishing this task for decades how it's possible to
| accomplish the task without the new thing!
| fleventynine wrote:
| As I see it, if you need everything to run on a single
| cpu core, the alternatives are to either implement
| threads (wasting memory on redundant stacks) or to write
| the event-driven state machines manually. Whether the
| state machine is pumped by interrupts or not doesn't
| change anything IMHO.
|
| Because of RAM constraints, all the bare-metal projects
| I've worked on have used manually-written state machines,
| and I'm comfortable enough with this approach. But
| sometimes these state machines can be hard to understand
| when the control flow is complicated, and I am seriously
| considering adding some compiler-generated state machines
| that will fit nicely into my existing model.
| kragen wrote:
| none of this will be news to _you_ , but it's probably of
| interest to other people reading the discussion. you can
| do stuff inside the interrupt handler itself, and while
| what you do there does have to be an event-driven
| explicit state machine, interrupts introduce two key
| differences:
|
| - the _rest_ of your program doesn 't have to be an
| explicit state machine; it can use structured control
| flow with nested loops and conditionals and subroutines
|
| - the interaction between the interrupt handlers and the
| rest of the program is almost completely asynchronous,
| because as long as interrupts are enabled, the interrupt
| can fire between any two instructions of the rest of the
| program; if you look at it as multitasking, it's
| preemptive multitasking rather than cooperative
| multitasking. preemptive multitasking introduces a lot of
| hairy error cases, and this is only moderately simplified
| by the fact that the rest of the program can't preempt
| your interrupt handler, only vice versa. arguably that
| makes the problem worse rather than better because you
| can't solve the problem with locks (except by disabling
| interrupts as a sort of global lock)
| fleventynine wrote:
| > the rest of your program doesn't have to be an explicit
| state machine; it can use structured control flow with
| nested loops and conditionals and subroutines
|
| This works well until the requirements change and you
| have to run two structured control flows simultaneously.
| If I find myself in such a situation and have no SRAM for
| a second thread, rust async may be the quickest way to
| accomplish the goal without a major rewrite into manual
| event driven code.
| kragen wrote:
| i don't have experience with rust async, although i used
| to maintain a csp protocol stack in python async, which
| is pretty similar, so tell me if this is wrong
|
| i feel like the same kind of thing can happen even if you
| start entirely async, because something that was
| previously synchronous may have to become asynchronous,
| which leads to having to revalidate all your concurrency
| assumptions all the way up its (static) call stack.
| wherever you were depending on not getting preempted, you
| need to change the code to not depend on that anymore.
| but if ram is so tight that you're concerned about the
| sram for a second stack, maybe that's a pretty small task
| rather than a major rewrite
|
| that said, i don't recall having actually had that
| problem
| antirez wrote:
| Thanks, I prefer using C :) But happy that there are options
| out there.
| j-krieger wrote:
| 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.
| throwaway15968 wrote:
| Completely agreed. ESP-IDF is incredible and the dev
| experience is miles beyond STM32 (my opinion).
| mardifoufs wrote:
| Did you use esp-idf? Or the Arduino libs?
| antirez wrote:
| ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.
| MegaDeKay wrote:
| 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.
| jsheard wrote:
| 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, and why the Pico
| Ws radio is a separate off-the-shelf part rather than fully
| integrated like it is on the ESP32.
| nimish wrote:
| Analog is large area and expensive in general so sticking to
| good digital and passable analog is a very good strategy to
| keep costs down.
| dragontamer wrote:
| Modern Microcontrollers focus on analog because modern
| microprocessors start at like $5, maybe even cheaper.
|
| If you need digital girth, don't mess with lol 264kB RP2040
| systems. Just buy $3 of DDR3L RAM (aka: 128MB) and run
| Linux for goodness sake.
|
| ---------
|
| Even ESP32 is a glorified Bluetooth/Wifi chip first and
| everything secondary. You have to have a niche at this
| price point to be competitive.
|
| RP2040's niche is the 264kB of SRAM, but not much else. It
| needs a bunch of external parts before it can become a
| reasonable solution as well, so its not really cost
| optimized IMO.
| immibis wrote:
| You can't run Linux on DRAM. You need a CPU.
| dragontamer wrote:
| 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 cost effective
| external components.
|
| --------
|
| Analog-focused designs like ATMega, ESP32 or STM32
| comfortably do things that the real computers or MPUs
| cannot do. Like read a voltage, work with OpAMPs or other
| analog stuff that cannot fit on a proper Linux computer
| chip like SAM9x60D1G. And to do so without any external
| parts, so that you have the simplest design possible.
| dgacmu wrote:
| 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.)
| dvdbloc wrote:
| Where can I learn more about how they are used in console
| hacking? This sounds very interesting
| nereye wrote:
| One use case is related to the Nintendo Switch, as mentioned
| in another post.
|
| E.g. see https://github.com/Ansem-SoD/Picofly.
| MegaDeKay wrote:
| Here you go. There might be more but these are all I can
| think of off the top of my head.
|
| Nintendo Switch modchip - PicoFly:
| https://github.com/rehius/usk. That is the OG source of the
| firmware behind the already mentioned
| https://github.com/Ansem-SoD/Picofly
|
| OG XBox Modchip - Modxo: https://github.com/shalxmva/modxo
| (see initial impressions from ModzvilleUSA at
| https://www.youtube.com/watch?v=uUsov3i6jL0)
|
| XBox360 NAND reader / writer - Picoflasher:
| https://github.com/X360Tools/PicoFlasher (used in the RGH3
| hack for some versions of the console as described at
| https://consolemods.org/wiki/Xbox_360:RGH/RGH3)
|
| Gamecube Modchip - Picoboot:
| https://github.com/webhdx/PicoBoot
|
| Gamecube Optical Drive Emulator - Flippydrive:
| https://github.com/OffBroadway/flippydrive as described at
| https://teamoffbroadway.com/
| mewse-hn wrote:
| The flippydrive is such a nice, clean install on a gamecube
| that it leaves me wondering if the rp2040 could make better
| ODE's for every other console (psx, saturn in particular)
| morsch wrote:
| Related: retro PC stuff.
|
| https://github.com/polpo/picogus
|
| Emulates all kinds of sound cards, including the Gravis
| Ultrasound.
|
| https://github.com/FreddyVRetro/ISA-PicoMEM
|
| Emulates a memory extension, but also so much more stuff.
| JAlexoid wrote:
| 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.
| vardump wrote:
| > There are many options for other MCUs, that compare
| favorably to with RP2040
|
| That's pretty interesting, could you list some?
| jayyhu wrote:
| The STM32 F0/G0/C0 lines come to mind. More I/O, more
| peripherals and built-in flash.
|
| For hobbyist levels, buying 1-10 pcs they are comparable in
| price to an RP2040 + SPI flash. However at volume pricing,
| the STM32 MCU's can be cheaper than just the RP2040 itself.
| I do think Raspberry Pi needs to figure out volume pricing
| if they want to be competitive for anything that's not just
| hobbyists.
| Johanx64 wrote:
| rp2040 is 64cents @ 1000qty, thats a good price,
| compatible winbond 16mbit flash is 12cents.
|
| You need to go up way above a dollar to get comparable
| specs, given the unique nature of rp2040, two cores with
| fairly high clock, 264kb sram, pio.
|
| The only thing i dont like about rp2040 is the package,
| not hobbyist home soldering friendly for custom board
| designs.
| moffkalast wrote:
| 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.
| Teknoman117 wrote:
| You don't even need the 8 :), 4 quadrature inputs will fit on
| one PIO block.
|
| 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.
| moffkalast wrote:
| I mean yeah one block is 8 units right? Two pins per
| encoder which both need a unit each.
| crote wrote:
| The most annoying part about the PIO is that there are only two
| of them (though with 4 sub-units each), they only have space
| for 32 instructions, and they don't have an external clock
| input.
|
| They are _great_ for implementing very basic peripherals, but
| more than once I 've started to implement something more
| complex just to realize it would be unacceptably slow and run
| out of space. If they were to beef them up just a little, they
| could easily replace the more trivial FPGA applications.
| boznz wrote:
| Availability is the star of the show for me. One IC, long
| product lifetime, always in stock, after the shitshow that was
| 2021/2022 I'm not going to bother trying to shave a few cents
| to compromise this again.
| nkozyra wrote:
| Don't cycle sleeps help on the esp32? I typically run on power
| but I know a lot of people get all day with wifi on reasonable
| LiPo
| Havoc wrote:
| How are people using this in practice?
|
| I've never worked with a BGA device. I'm guessing you need to
| design a board send it to say pcbway and then have the equipment
| to solder the bga in?
| eulgro wrote:
| It's not a BGA, it's a QFN with a ground pad.
| Havoc wrote:
| I see. What does that change in terms of process needed?
| a1o wrote:
| BGA you need hot air and reflow but a QFN I think you can
| just position and solder by the side with a simple solder
| iron with a knife like tip.
| neilo40 wrote:
| Although it looks like BGA, it actually uses a QFN package
| where all the contacts are accessible at the edge. With a
| little practice they are relatively easy to hand solder (I've
| done many, not just rp2040)
| dvdkon wrote:
| QFN packages are very nice to hand-solder in my experience,
| considering the pitch. Better than the bridge-prone pins of
| QFP. The bottom pads do need some preparation, but you don't
| need hot air or reflow.
| kragen wrote:
| i admit to being intimidated by qfns still. any tips for
| hand-soldering them successfully?
| dfox wrote:
| Kind of cheating trick for the QFN substrate pad is to put
| a grid of somewhat higher diameter vias in there and solder
| the pad from the other side of the board through these
| vias. Another approach is to just ignore the substrate pad
| altogether (in many devices it should not be connected to
| anything anyway and has no real thermal management
| purpose).
| kragen wrote:
| i wonder if you could use the vias trick for the regular
| pins too, and bga balls
| dfox wrote:
| I have in fact seen the via trick used for 50mil pitch
| BGAs, but cannot remember where. I even vaguely recollect
| some board where that was used for CGA, which seems like
| really ridiculous idea (you don't use CGA packages and
| then invent some weird kludge pseudo-process).
| kragen wrote:
| wow, i'd never even heard of cgas
| GlibMonkeyDeath wrote:
| Almost universally a hobbyist would purchase the RP2040 mounted
| to a pcb with other i/o components (e.g. the Seeeduino Xiao
| https://wiki.seeedstudio.com/XIAO-RP2040/) There are other
| versions which bring out more lines to accessible solder
| points.
|
| Of course you can design your own custom board, but I'd wager
| most people don't need or want to do this.
| the__alchemist wrote:
| That's the desired approach, yes, but... hot take incoming!
|
| I think BGAs are easier to "hand" solder than other footprints
| (QFP, QFN etc). You drop the item in place, place it on a hot
| plate and or heat gun, and start melting it. Of course, if you
| screw it up, you are screwed. (Reballing sounds not worth it
| for most cases). And, you can't visually inspect.
|
| I think this is because, at least for me, most of the soldering
| faults I have are due to uneven application, or improper amount
| of solder. BGA solves this.
| dave78 wrote:
| I built a custom RP2040-based board by designing it KiCad and
| then sending it off to JLCPCB to be fabbed and they assembled
| the SMT components. I didn't do a direct comparison, but it was
| cheap - cheap enough that it's possible that getting the board
| pre-assembled from JLC was cheaper than buying the raw parts in
| low quantities from Digikey and assembling it myself (which,
| given my experience level, would be pushing the edge of my
| capabilities). I made a second run recently and even added some
| through-hole to the assembly and the board cost was still
| single digit dollars per board. The major problem was that
| shipping prices from JLC seem to have gone up significantly in
| the past year.
|
| Keep in mind that it's not just the RP2040 that is difficult to
| solder. To do a decent PCB layout you'll need to use very small
| passives in order to get the placement right. I did my layout
| with mostly 0402 resistors and capacitors - I know plenty of
| people are capable of hand-soldering those but I think it would
| be difficult for most. Perhaps easier if you had a decent
| microscope, which I do not have yet. I don't think my
| magnifying visor would be nearly enough.
| dragontamer wrote:
| > To do a decent PCB layout you'll need to use very small
| passives in order to get the placement right.
|
| 0402 (inches) is small but doable. They really start to feel
| like grains of sand at that point.
|
| But I personally stick with 0805 and 0603 when doing my own
| board layouts. I can't say I've ever felt space constrained.
| The placement of decoupling capacitors can be a few mil off,
| and in fact the "extra space" for placement helps your
| tweezers anyway, so you don't really want to push everything
| so close together.
|
| Especially for hobby projects, I don't think anyone is really
| in the business of counting up the savings of 0.01" in the
| hobby world. Like, how small are you actually aiming for, and
| is it really so bad that you can't add another 0.5" to your
| board?
|
| --------
|
| Professionals use 0201 (inches) for maximum flexibility and
| minimal sizes. So even 0402 is larger than professional
| projects. If we're all accepting "larger hobbyist sizes"
| anyway, might as well go all the way up to the much easier
| 0603 or 0805 parts.
|
| While a 0402 is slightly larger than a grain of sand, I'd say
| 0805 is approximately the size of a grain of rice. So yeah,
| doable with tweezers and solder paste. Just imagine lining up
| dry rice and its well within the capabilities of most
| hobbyists.
|
| Its just problematic when you get smaller than that.
| dave78 wrote:
| > Especially for hobby projects, I don't think anyone is
| really in the business of counting up the savings of 0.01"
| in the hobby world. Like, how small are you actually aiming
| for, and is it really so bad that you can't add another
| 0.5" to your board?
|
| It's not really about saving board space. Decoupling
| capacitors need to be placed "close" to the chip, and at
| higher clock frequencies this can be an issue. There's
| enough decoupling caps needed on a RP2040 that doing them
| in 0805 would require moving them quite a bit further away
| from the chip just to have room to place them all.
|
| An ATmega (Arduino) at something like 8MHz is really
| forgiving and you can take a lot of liberties with the
| layout. The RP2040 runs much faster at 133MHz, so
| presumably the tolerances are much tighter. Admittedly, I
| didn't try a doing a design with 0805s for the RP2040 but I
| read enough from people more experienced than me that gave
| me the impression that compromising the layout with larger
| passives had a greater chance of things not working right.
|
| Since assembly is so cheap at places like JLC these days,
| even in small quantities, it really wasn't worth the
| hassle. I've done many other boards by hand with 0805s and
| and agree they're pretty easy to deal with.
| dragontamer wrote:
| > 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 100mil or 0805 would cause any serious problem.
|
| -------------
|
| So the "secret" is that all faster designs (100MHz to
| 300MHz) have substantial on-package capacitance.
|
| Take a look at this design, which I admit is
| Microchip/Atmel MCU, but its running at 300MHz and not
| just the relatively low 133MHz of the RP2040.
|
| https://lcamtuf.coredump.cx/bob-the-cat/
|
| Those are LARGE 1206 1uF capacitors. Which is actually
| scary to me because we're not looking at tight 100nF
| decoupling caps anymore but instead substantially relying
| upon "on-package" capacitance.
|
| Still, it shows that lcamtuf was confident in this 300MHz
| processor handling far-away 1206 capacitors, showing how
| much wiggle room we have in practice in these designs.
|
| You shouldn't worry about 100mil of movement of 0805 caps
| on a 133MHz design. After all, there are real designs
| that are closer to 500 mil that use 1206 caps on a 300MHz
| MCU.
|
| --------
|
| I'm honestly scared for lcamtuf here and would never
| design a board like this. But I'm really not worried
| about 0805 caps on relatively low speed 100MHz (or even
| 133MHz) MCUs. Especially if you're properly "teaming"
| them up so that their resistances are paralleled and
| inductances are paralleled. (Notice that lcamtuf's 300MHz
| design doesn't even have the 10x recommended parallel
| 100nF capacitors close to any of the pins!! He's really
| stretching the specs)
|
| -----------
|
| But yeah, my personal preference is majority of 0805s and
| 0603s for the "close" decoupling capacitors. I know
| there's plenty of wiggle room here (even if I'm not as
| aggressive as lcamtuf's designs).
|
| If you're using PCBA from another shop, I guess its all
| "free" to you to use 0402s or whatever they got loaded in
| their chip-shooters. So might as well take your free pre-
| loaded resistors. But if I'm assembling a board myself, I
| definitely prefer the larger size.
| dave78 wrote:
| 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 that where possible,
| to try to learn to do things the "right way" - but I
| definitely don't have enough experience to know when the
| rules of thumb can be broken or not.
|
| It's good to know that the "closeness" requirement of
| decoupling caps is perhaps not as important as I had
| believed.
| dragontamer wrote:
| The professionals use PCB-design software with physical
| modeling / FEA to calculate estimates to all of the
| important parameters of the circuit board (including how
| much trace lengths matter... but also board-capacitance,
| resistances, and resonance frequencies of the board
| itself, etc. etc.)
|
| 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.
| floxy wrote:
| You would probably be surprised what you can do with a $65 hot
| plate [0], no-refrigeration-required solder paste[1] and the
| matching laser-cut solder stencil[2].
|
| [0] -- https://www.amazon.com/Soiiw-Microcomputer-Soldering-
| Preheat...
|
| [1] --
| https://www.chipquik.com/store/index.php?cPath=470&osCsid=8t...
|
| [2] -- https://www.pololu.com/product/446/
| dragontamer wrote:
| Pololu's stencils leave much to be desired. They do work but
| I feel like https://www.oshstencils.com/ makes a higher
| quality stencil instead at similar prices.
|
| -----
|
| Note that BGA chips mostly come pre-soldered / solder balls.
| You also design PCBs so that there is a "well" for the balls
| to melt into and settle into place, and molten-solder has a
| significant amount of surface tension, so you can magically
| watch the solder "pull" your designs into place. Of course,
| the OP is likely talking about QFN not BGA, but... just in
| case people are worried about BGAs its not terrible... (its
| just impossible to inspect a BGA XRays).
|
| The surface-tension can be harmful in the case of tombstoning
| (ex: a resistor or capacitor with two leads, especially a
| "sideways" low-inductance capacitor, will get "pulled up" by
| one side, lifting off the 2nd pad).
|
| If you have a solder-plate + hot-gun, you can "feel" the
| surface tension by just grabbing a toothpick and pushing on
| these components as they're still hot. You'll find the
| pressure to be far higher than you expect.
| floxy wrote:
| 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 matter for a tiny board, but for a 4" board,
| the difference adds up, so that if you align the apertures
| on one end of the board, they don't on the other side of
| the board. Like the aperture was off by a whole 0603 pad or
| more). I went back to Pololu for that same board, and
| everything was spot on. And I have had zero complaints with
| them since. If I had to complain about something, I might
| slightly ding them slightly on the super-tiny aperture
| shapes and the kerf width of their laser. But everything
| has always worked. Apparently YMMV.
| dragontamer wrote:
| 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.
| botdan wrote:
| Just in case you were unaware, the RP2040 is available on
| dozens of ready-made, arduino-compatible boards like the Pi
| Pico, the Adafruit feather boards, of the Seeed XIAO RP2040
| boards. Those have all (or at least most) of the IO already
| mapped to pins, USB headers, booatloaders, reset buttons, etc
| already mapped.
|
| Things like the Pico are really easy to solder onto a designed
| PCB as well because of the castellations, so it's easy enough
| to design a board around the footprint and then just solder the
| entire pico onto your PCB with a soldering iron, avoiding the
| need to use something like a hot-plate or reflow oven. This has
| been my preferred way of working with it.
| Havoc wrote:
| Yeah I've got a variety of dev boards already, but thought
| moving away from that as part of a move to PCBs might make
| sense. Esp given the cost diff - raw rp2040 seems to be at
| least 1/5 of the dev boards. Dev boards are probably the
| better deal overall, but also less scope for learning
| dragontamer wrote:
| RP2040 is QFN, not BGA.
|
| QFN is doable at home, though more difficult than TQFP leads or
| larger SOIC-chips. Still, far too many components are QFN today
| so its a good skill to pickup.
|
| ------
|
| The techninque is:
|
| 1. Reflow soldering brings the _whole_ board to soldering
| temperatures, and then relies upon surface-tension to pull all
| the devices into proper place.
|
| 2. Solder paste is applies ahead of time. You can cleanup
| solder paste with a toothpick before you bring the board up to
| temperature. Solder paste tends to go bad pretty quickly
| however. When doing prototypes, opt for the more expensive low-
| melt solder paste to minimize potential heat damage.
|
| 3. Prefer to use a stencil to apply solder paste. But its more
| than doable to be sloppy with a syringe and then rely upon the
| solder mask + surface tension to magically cleanup things
| during reflow temperatures.
|
| 4. Use a hot-air gun to fix any issues. The #1 issue you'll
| have is tombstoning, QFNs or TQFP chips are usually pretty good
| about settling into place. For TQFP issues (ex: bridging),
| you'll need solder-wick + soldering iron. EDIT: And flux: lots
| of flux helps. Also, flux goes bad, so throw away Flux all the
| time and keep buying new batches.
|
| ---------
|
| BGA is also doable at home btw, thanks to the above principles.
| But its even harder than QFN. The real issue of BGAs is that
| you're looking at 4-layer minimum, maybe 6, 8, or 10-layer
| designs. There's also substantial grounding and other advanced
| PCB concepts you need before you can layout a BGA-capable PCB.
|
| Its not so much the physical activity of soldering that's hard
| or difficult for BGAs. Its all the theory you need to study to
| breakout BGAs + minimize inductance + deal with impedance
| matching and trace-length matching.
| morio wrote:
| I find hand soldering QFN is faster, easier and more reliable
| than (T)QFP once you got enough practice. If you need to
| rework the QFN part the key is to FLOOD the footprint with
| good solder flux from a syringe. Do not use one of those flux
| pens, those do not dispense enough flux.
| dragontamer wrote:
| > If you need to rework the QFN part the key is to FLOOD
| the footprint with good solder flux from a syringe.
|
| I've never tried this but this makes a lot of sense in my
| mind's eye. I'll try this next time I have such an issue.
|
| -------
|
| TQFP seems nice because I can sloppily shove tons of solder
| down, and then just wick up all the excess solder with
| solder wick. In fact, I purposefully over-solder all the
| TQFP joints for this practice. (Too much solder during
| reflow, and then just a quick cleanup step with a soldering
| iron later).
| KaiserPro wrote:
| Yeah I've been seeing a bunch of chip swaps that use this
| method, its wild how forgiving it appears to be.
| tiku wrote:
| My Switch is unlocked by a rp2040. A lot of devices could be
| modded with it, given the size etc.
| axoltl wrote:
| "(This is the same microcontroller, just two bugfix revisions.)"
|
| It is exactly the same microcontroller! They're just two
| different packaging options. One is a 7" reel with 500 units the
| other is a 13" reel with 3400 units. (See "Ordering code" in the
| datasheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datas
| heet.p...))
| dgroshev wrote:
| Ooops, you're right! Fixed & attributed.
| jsheard wrote:
| That said they have done a few bugfix revisions, RP2040-B0 is
| the original, -B1 has some refinements to the ROM code, and -B2
| has further ROM changes and also fixes some silicon bugs from
| the earlier versions. If you're using the official SDK you
| probably don't need to care too much about which version you
| have though, because the standard high level libraries detect
| the hardware revision at runtime and enable or disable
| workarounds as needed.
| nickcw wrote:
| If you are an electronics hobbyist but don't want to make/design
| your own surface mount boards (like me) there are lots of very
| accessible RP2040 boards at very low prices.
|
| I've used it in the Raspbery Pi Pico ($5) which comes on a nice
| board with lots of IO. There is a W version for a bit more with
| WiFi.
|
| If you don't mind slightly less IO then you can order an RP-2040
| Zero. I got 6 off AliExpress for about $12. These only have 23 IO
| pins but they have a reset button, USB-C and are tiny (1.5cm x
| 2.5cm).
|
| The nice thing about all of these is that they use the standard
| Raspberry Pi dev tools, micropython, C++ just works with
| convenient USB loading of the firmware.
| willis936 wrote:
| I like to shout out the pico ice. Most of the $30 price tag is
| for the UP5K tied at the hip, but for embedded projects where
| you have some sub-microsecond activities it's a (relatively)
| inexpensive option with open source tooling.
| moffkalast wrote:
| Unless you're incredibly space constrained I don't really get
| the point of that 2040 Zero, it just costs more for fewer
| features. The Pico is already pretty tiny.
|
| The Pico is really good at pin interoperability at least, in
| the land of ESP, what appears to be lots of IO pins quickly
| turns into barely enough if you're lucky, with pins connected
| internally to flash or the bootloader or whatever. I really
| wonder why they even bother breaking those out. The ESP32-CAM
| comes with 10 data pins, and only 4 of them are actually
| generally usable lol.
| dgacmu wrote:
| I think it's about the clones on aliexpress, which are about
| $2.50, vs $5 for the pico.
| crote wrote:
| I also highly recommend shopping around for alternative
| RP2040-based dev boards. The official Pi Pico is surprisingly
| bad, and just about every alternative out there is better in
| one way or another.
|
| I mean, come on: no reset, huge form factor, only 2Mbit flash,
| micro USB - in 2024? Just about the only pro it has is that it
| is widely available.
| joemi wrote:
| The Pi Pico is not a "huge form factor". It fits better on
| breadboard than pretty much anything with an ESP32 on it
| (since it's less wide), and it provides access to most of the
| RP2040 pins. Since the PIO can drive a lot of pins at once,
| this lets you really unleash the RP2040's power to do things
| like DVI output. Having access to more pins is something many
| people consider a plus not a minus.
|
| As to your other points, I wouldn't mind more flash but I
| don't think the amount it has is particularly small. The
| micro USB, though, is a disappointment, though.
| IshKebab wrote:
| TL;DR: he likes it because there's only one version available,
| whereas most microcontrollers have many more than one variant.
|
| This seems like a very weak argument.
|
| IMO (just based on the specs; haven't actually used it), the main
| reason to use this is for the PIO stuff. That's a _very_ niche
| use case though.
| t43562 wrote:
| ...because that means there's a lot of support and
| documentation for that 1 variant and lots of people have solved
| problems and written about it,
|
| This is like the iPhone strategy against Nokia. When I worked
| at Nokia it produced many variant phones - each with a little
| more ram or a bit less or a better screen or a different
| chipset. This was because they thought that people bought on
| price and wanted to have a product at every price point.
|
| The builds took more than a week to finish, the bug fixing was
| horrendous. The software sometimes had to work with not enough
| RAM sometimes with different chipset bugs, different graphics
| limitations. It was a nightmare to produce a quality product.
| Then out of e.g. 18 phone models we had to customise each one
| for 1000 operators in the world which intensified the pain and
| effort.
|
| At that time Apple had one iPhone. It was over specified - lots
| of RAM, great graphics etc. They only had to test their code
| once - not 18 times.
| vitiral wrote:
| ... and because they designed the chip to be a jack of all
| trades, which he really likes.
| SillyUsername wrote:
| The ESP8266 and ESP32 from what I've seen have got far more
| documentation and support (also due to library compatibility
| between the two chips). I've personally not come across any
| lack of documentation or compatibility issues, which I guess
| only happens if you need to target many versions of a chip,
| which isn't a problem for most people unless you're an API
| developer.
| miunau wrote:
| Making software for all those models was exhausting. It took
| an entire team just to profile phones and make configurations
| for compilers (what is the screen resolution? does it have
| feature x? is there a physical keyboard, and how many buttons
| does it have? where are the crucial buttons located? ...),
| and then you ended up with hundreds of targets taking days or
| weeks to make a build. I know many programmers that quit the
| industry altogether during those times.
| CamperBob2 wrote:
| The real risk with the chips that offer the same die in dozens
| of slightly-different packages is the supply chain. Rest
| assured about 80% of those variants will be out of stock more
| or less permanently in a few years, once a few major customers
| have settled on a few specific parts. Good luck guessing which
| ones you'll be able to get.
| dragontamer wrote:
| > IMO (just based on the specs; haven't actually used it), the
| main reason to use this is for the PIO stuff. That's a very
| niche use case though.
|
| PIO is interesting but I'm not fully convinced they're better
| than a suite of dedicated timers, especially in the realm of
| power-efficiency.
|
| The _real_ wtf?!?!? spec here is 264kB of SRAM. At this price
| point / power-consumption, that's a _LOT_ of SRAM. Any
| application that needs a ton of SRAM (ex: 300 x 200 pixel 8-bit
| LCD screen) will find good use in the RP2040.
|
| A lot of the other parts of the RP2040 are quite lackluster.
| PIO is "interesting" but seem somewhat overhyped to me.
| amelius wrote:
| I have just one question: is this product meant for the
| "hobbyist" space only?
| mmoskal wrote:
| Definitely not. My understanding is they got significant market
| share on lunch - since it was during the pandemic chip shortage
| and they were the only ones with sub year lead times.
| amelius wrote:
| Ok, but does it fulfill military or automotive standards?
| mordae wrote:
| Probably yes, but it doesn't have the paperwork AFAIK.
| riskable wrote:
| I don't know about military standards but there's only ONE
| automotive standard and it's ISO 26262:
|
| https://en.wikipedia.org/wiki/ISO_26262
|
| There's nothing in ISO 26262 that would prevent someone
| from using an RP2040 in a car. You'd just have to be
| redundant about everything which you have to do _anyway_
| regardless of the chip you choose.
|
| Also, ISO 26262 is not a law. It's up to the auto
| manufacturer whether or not they'd require it and no single
| chip on its own can claim to be "certified" (or similar)
| for ISO 26262 since the focus is on redundancy and error
| checking (which means one chip would check the status of
| the other and vice versa, not some special internal
| consistency checking feature... That's just marketing).
|
| Most "automotive" versions of chips (e.g. Atmel's stuff)
| are just branded that way. Atmel will make a claim like,
| "this chip has been tested to function properly under these
| sort of extreme conditions..." (that happen to match what
| car manufacturers are looking for) and then a car company
| would just _trust_ that and make it so that only chips that
| are marked "automotive" and manufactured by Atmel will be
| allowed to be used by their electrical engineers (or
| suppliers).
|
| It's all entirely arbitrary though: If you can convince the
| manufacturer that your board works fine under the
| conditions they require they'll probably buy it. Well, they
| won't hold it against you that you used one chip or the
| other. They just want some assurances.
| aaronmdjones wrote:
| There are several automotive standards for electronic
| components. GP was probably asking about e.g. AEC-Q100,
| AEC-Q101, and/or AEC-Q200. These establish that the
| device is going to work in automotive environments
| (temperature, humidity, vibration & shock) by verifying
| functionality while subjecting them to those conditions.
| A component may work without these tests, but you are
| merely hoping that that is the case if they haven't been
| tested. Hope is not a viable strategy for product design.
| riskable wrote:
| The AEC standards aren't enforced by anything and are
| mostly just _promises_ that chip manufacturers make (the
| AEC itself is a private entity). Specifically, that any
| given chip will still be available in 15 years and that
| it 'll operate fine within certain temperature ranges.
|
| If some part claims to be AEC compliant it's basically
| just the manufacturer saying so. There's no independent
| body or even standardized tests to prove a part adheres
| to any given AEC document. Their own docs state as much:
| AEC Certification Note that there are no
| "certifications" for AEC-Q100 qualification and there
| is no certification board run by AEC to qualify parts.
| Each supplier performs their qualification to AEC
| standards, considers customer requirements and
| submits the data to the user to verify compliance to Q100
|
| In other words, it would be up to any given car
| manufacturer to verify the claims of any chip vendor
| using their own testing methods. Since they're going to
| have to do that _anyway_ , slapping AEC-(whatever) on a
| product doesn't mean much.
|
| If you test your part in similar conditions and make some
| availability promises you too can slap an AEC-Q100 label
| on to your chip!
| dgroshev wrote:
| Personally I wouldn't put it into a toothbrush (the benefit of
| right sizing is too high when you produce tens of millions of
| those), but for lower volumes I'd go for it.
|
| Fwiw I'm working on my own consumer product/dev tool and I'm
| very happy with the RP2040.
| joezydeco wrote:
| I was on the fence about using it for a small commercial
| project I'm doing, but the lifetime has been put out long
| enough (2041 at this point), and it's so freaking cheap that
| I'm going to do a one-time buy of 10 years worth of parts.
|
| Lack of code security and onboard flash weren't dealbreakers
| for me here, but others will have more stringent requirements.
| QSPI is so incredibly cheap now.
| amelius wrote:
| Ok. One thing I'm worried about is that the tooling is made
| for hobbyists only. Is there a way to do everything from the
| commandline with FOSS tools and without installing e.g. the
| Arduino-IDE?
| dgroshev wrote:
| I'm not sure how things are in the C land, but if you write
| Rust take a look at this book [1], Embassy has a very good
| support for the RP2040.
|
| Probe-rs [2] works perfectly well with GDB and the CLion
| debugger.
|
| [1]: https://embassy.dev/book/
|
| [2]: https://probe.rs/
| mordae wrote:
| Yes. Pico SDK is C with CMake and Rust is bare metal (I
| think).
| joezydeco wrote:
| I'm using the CircuitPython environment. I'm editing in vi
| and writing directly to the USB storage on the RP2040,
| which reboots upon write and runs the code. It's no big
| deal. There's also a virtual UART off that USB connection
| for light debugging.
| riskable wrote:
| Since the RP2040 uses external flash you can pre-program
| the flash chips before they even get soldered on to the
| board. Other standard methods still work like breaking out
| the debug pins to some spot on your PCB so you can quickly
| "pogo flash" it as part of an assembly process.
| silvanocerza wrote:
| Maybe with the Arduino CLI?
| dave78 wrote:
| > Is there a way to do everything from the commandline with
| FOSS tools and without installing e.g. the Arduino-IDE?
|
| Yes. In fact, the official getting started guide[0] is all
| command-line based, with an optional chapter later on about
| using VS Code if you wish.
|
| I have a low volume product in production using the RP2040
| and I've never once opened up any sort of GUI for
| developing the software or programming it.
|
| [0] https://datasheets.raspberrypi.com/pico/getting-
| started-with...
| jcalvinowens wrote:
| The 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.
| jsheard wrote:
| > I love the generic PIO though, I really hope other
| manufacturers pick up on that.
|
| Unfortunately the Pi Foundation is seeking patents on the PIO
| architecture. I don't think they've been granted yet though.
| jcalvinowens wrote:
| That's really disappointing :/
| vitiral wrote:
| seeking patents to then open source it?
|
| Right?... Right?!?
| amelius wrote:
| Isn't that already covered by FPGAs? I mean, it is just a way
| of configuring ports. And FPGAs are much broader (also
| configuring computation).
| arlort wrote:
| The same features of pio can be implemented via FPGA, but
| it's a lot more complicated to do so, and probably you
| won't find FPGAs as cheap as on the pi
| nereye wrote:
| One example (PIO implemented in Verilog for use in
| FPGAs):
|
| https://github.com/lawrie/fpga_pio
| crote wrote:
| No, FPGAs work substantially different.
|
| You can think of an FPGA as a bunch of "programmable
| transistors". You've got a whole bunch of basic logic
| building blocks, and you program the wires between them to
| build a logic circuit. This means it is _great_ for
| building relatively simple but high-speed logic (grab
| sample from sensor, do some additions and multiplications,
| store result in external DRAM chip, repeat at 5GHz).
| However, they are really inflexible: getting them to do
| different operations depending on some condition is
| extremely costly.
|
| The PIO, on the other hand, is essentially a really basic
| CPU core. It reads and executes a stream of instructions,
| and it can do (very simple) math and conditional logic.
| This means it is great for building some kind of state
| machine, which dynamically adjusts it behaviour based on
| some kind of external condition. The unique selling point
| of the PIO is that the instruction set is completely
| designed around super-fast IO, so reading or writing two
| dozen pins can be done in one or even zero(!) instructions.
| And because every instruction executes in exactly one
| cycle, you've got really good control over the exact
| timing. This makes it ideal for implementing hardware-level
| protocols in software.
| amelius wrote:
| In that case, it sounds like they reinvented the
| coprocessor. I don't see any fundamental difference
| between that and what they did.
| KaiserPro wrote:
| Source? I've not seen a patent for that, plus I suspect its
| not actually patentable
| jsheard wrote:
| https://forums.raspberrypi.com/viewtopic.php?p=1837408&sid=
| 6...
|
| I haven't seen a more recent update, unsure if they
| abandoned the patent bid or if it's just taking a while to
| go through the system.
| joezydeco wrote:
| Are you gated on PCB real estate, or cost? 8 megabits of QSPI
| is under 50 cents. I really don't care that it's external if
| the entire chipset is under 2 bucks.
| the__alchemist wrote:
| Not the OP, but I'll say, whenever designing a fresh board,
| this sort of convenience built-in is nice. Individually, it's
| not a huge deal, but when you start adding things that are
| sometimes built in (external crystal vice internal? flash?
| PDs on USB or a bus?), you appreciate when it's one less
| component to allow spacing for, that might be out of stock at
| a given order etc. Also note that QSPI flash has a number of
| connections, you have to check the datasheet etc to know what
| to wire where, if you are changing MCU footprint you have to
| re-wire it each design etc.
| jcalvinowens wrote:
| Exactly this, it's just another thing to deal with and I
| save a little time by not having to.
| joezydeco wrote:
| I'd agree with most of those points, but in my decades of
| experience here...YAGNI.
| bangaladore wrote:
| That chip has over 10x less RAM and only 60k flash. It has only
| one core and that core is clocked at half the speeds compared
| to both the RP2040 cores.
|
| And it cost six bucks from US distributors. I can buy a single
| RP2040 chip from Digikey for 70 cents. Even if you add another
| dollar for flash memory, you are still far better off.
| jcalvinowens wrote:
| I mean, that's sort of my point: the rp2040 has an absurd
| amount of RAM for a micro, I don't need it and don't want to
| pay for it.
|
| I care more about the cost to manufacture boards with the
| part, than the cost to get sample parts mailed to me in the
| US :)
| riskable wrote:
| 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 considerably.
|
| Once I decided to start using the RP2040 I realized the
| "strange" flash situation turned into a feature, not a
| drawback! With STM32 you pick your part and then you can order
| an expensive version (if it's available!) with the max RAM of
| say, 512Kb or you can save a few bucks and go with say, 64Kb.
| Either way you're paying like $2.50-4 for a single chip.
|
| Now compare that with the super fast, dual-core RP2040 which
| costs $1 (yeah it's technically $0.70 in bulk) paired with a 16
| FUCKING MEGABYTE SPI flash chip (W25Q128JVSIQ, basic part at
| JLCPCB :thumbsup:) that costs $0.60. You get a _vastly_ more
| capable MCU with so much goddamned flash space you could fit a
| truck in there!
|
| You can even _partition_ that flash chip 's space so that your
| RP2040 firmware is reserved to the say, the first 2MB (or
| wherever you wish!) and the rest can be used for storing stuff
| like settings. It eliminates the need for an EEPROM! Not to
| mention there's enough storage space in there to store all your
| settings in something absurdly inefficient like JSON and the
| chip is fast enough to parse it too!
|
| Working with the RP2040 _in reality_ is just SO NICE.
| Seriously, try it! You won 't be disappointed.
| dave78 wrote:
| I agree with all that and would add that the documentation is
| fantastic, and the software tooling and SDK is well-done.
| That's a big advantage that vastly outweighs small
| differences in cost (unless you're selling millions of
| something).
| diydsp wrote:
| Haven't used the RP2040 yet, but having worked with SPIRAM
| and SPIflash on the ESP32, and also on many different STM32s,
| I can say this: if your project reaches a certain size, lots
| of tasks or multiple chunks of discontiguous memory, then the
| caching of the SPI memories becomes a traffic jam and things
| that should be really fast get really slow. And you start
| running into lots of weird error messages from inside the
| esp-idf drivers that you can't do much about. It will drive
| you crazy. You have to start strategically partitioning your
| memory, create/delete tasks dynamically, adjust lots of
| params in menuconfig, etc etc.
|
| Not a problem for most hobbyist projects, but when you start
| to push the limits the ESP32 feels like a chipboard apartment
| building compared to STM32's concrete and rebar. Hopefully
| the RP2040 doesn't suffer the same problems.
| djfergus wrote:
| For hobbists buying dev boards note that an ESP32 comes with WiFi
| and maybe Bluetooth depending on the model, whereas a vanilla Pi
| Pico has no radio - you need a Pi Pico W for that, which in my
| experience is double the cost of an esp32 board.
|
| I agree with the authors points that the RP2040 is a great chip
| would love to see the Pico W pricing come down as popularity
| grows.
| snufkin97 wrote:
| YES! TL;DR: its more powerful yet cheaper than most of MCU
| market, well documented and very straightforward yet extendable
| on many levels
|
| I agree with the post in 100%, I use RP2040 for both hobby
| projects and my keyboard startup project (arrowmechanics.com in
| case sb was interested).
|
| IMHO What RP foundation did is the greatest breakthrough in the
| world of embedded tech projects since the popularization of
| atmegas.
| metadat wrote:
| If this RPi main chip costs $0.70, why does the finished product
| currently cost $93.00 (RPi 5)? They're quite expensive nowadays,
| I miss when you could purchase them for ~$30.00.
|
| Meanwhile, Expressif chips are literally everywhere and becoming
| ever more ubiquitous.
|
| Edit: Thanks friends for the correction. It is cool you can still
| buy an RPi Pico for $13.00 :)
| smcameron wrote:
| The RP2040 is not what the RPi 5 uses.
| wheybags wrote:
| Because it's not the same chip?
| https://en.m.wikipedia.org/wiki/RP2040 read the the specs and
| it's clear that is not the main chip in an rpi 5
| j_leboulanger wrote:
| Because the RP2040 is not the main controller of the RPi.
|
| It's a micro controller, on which the Raspberry Pi Pico is
| based, at $4
| seveibar wrote:
| A raspberry pi 5 doesn't use this chip (at least as the main
| chip). The RP2040 is for microcontrollers/embedded
| applications.
| oakesm9 wrote:
| The main chip in a Raspberry Pi 5 is a Broadcom BCM2712.
|
| The main chip in the Raspberry Pi Pico is the RP2040, which
| costs $4.
| flohoff wrote:
| The issue is that its a comparison about apples to peaches. The
| RPI2040 is JUST the chip whereas the ESP32 come with tons of
| peripherals for your liking.
|
| From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet
| whatever, Display or Camera Connector - You choose.
|
| And then we have a multitude of even CPU choices and when running
| on a coin cell it makes a difference powering a second,
| unnecessary core or even wifi.
|
| And with the C6 variants, Espressif even switches ISA again, from
| 8266, to ESP32 to a RISC-V based ISA.
|
| So you are comparing the first of its kind SOC with a decade old
| Family of SBCs.
| snufkin97 wrote:
| You're right about the technicals, but I think its about the
| use cases. RP2040 is indeed one of its kind and is suddenly a
| great choice for so many projects, both hobby/educational and
| proffessional embedded devices. With its price vs possibilities
| it just covers soooo much when You know it's just one single
| chip version. To me, this is what tech progress is all about.
| HyulianGrader wrote:
| 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.
| sophacles wrote:
| So is GP.
|
| The silicon chip itself for an ESP has:
|
| bluetooth, ethernet, wifi, SD/EMMC, and a bunch more
| "peripherals" built into it.
|
| The RP2040 does not.
|
| To make this painfully clear:
|
| For an esp32 to do wifi you wire the esp32 to an antenna.
|
| For an RP2040 to do wifi you wire the 2040 to another chip,
| and that other chip to an antenna.
|
| Do you see the difference?
| HyulianGrader wrote:
| No, that's both "just the chip", the chips have different
| peripherals. They both have the usual SPI, I2C, UART, ADC,
| etc., and they have their differences too.
|
| I could just as well say "For an RP2040 to do USB you wire
| the RP2040 to the connector. For an ESP32 to do USB you
| wire the 32 to another chip, and that other chip to a
| connector."
|
| It's clear to me GP has the impression that ESP32 is
| something more (a development board with an ESP32?) than
| the ESP32 "chip" itself.
| krisoft wrote:
| Maybe look at the ESP32 chip's datasheet? [1] This is the
| first sentence in it: "ESP32 is a single 2.4 GHz Wi-Fi-
| and-Bluetooth combo chip designed with the TSMC low-power
| 40 nm technology." That's the chip. Not the development
| board.
|
| 1: https://www.espressif.com/sites/default/files/document
| ation/...
| HyulianGrader wrote:
| What part of that contradicts my comment?
|
| To be clear, GP is the one saying the ESP32 is more than
| just the chip itself, complete with battery controller
| and camera connector.
| krisoft wrote:
| Hmm. You are right.
|
| On a second re-read it seems we agree.
| Aurornis wrote:
| The Espressif chips are available as cheap modules, and
| frequently used as such.
|
| People generally refer to the module, not the isolated
| chip. The modules are effectively like a chip that you
| solder to the board.
| 0x457 wrote:
| Modules are "just" chip + all necessary hardware to start
| + antenna connector/pcb antenna. Those modules don't add
| any functionality to the chip.
|
| The main benefit of those modules is: it's already
| certified with FCC and others, so you don't have to re-
| certify your design for radio communication. Since RP2040
| does not have a radio, this is unnecessary.
| moefh wrote:
| GP is clearly talking about ESP32 boards, not the chip;
| they mentioned "LI Battery Controller", and "Display or
| Camera Connector". People sell RP2040 boards with those
| too, for example:
|
| - board with a battery charger:
| https://learn.adafruit.com/adafruit-feather-
| rp2040-pico/powe...
|
| - board with camera: https://www.waveshare.com/pico-
| cam-a.htm
| Aurornis wrote:
| ESP32 is available as a tiny module that is soldered to
| the board as if it was a chip.
|
| Ignoring the module results in a flawed comparison. The
| module is chip and frequently used.
|
| If they encased the module in plastic and called it a
| chip, it would be the same. You can think of it as a
| chip.
| moefh wrote:
| Do they sell chip-like modules with camera connectors and
| battery controllers, though? I don't deny that ESP32
| modules look like and are soldered as though they were
| chips, but to me it's clear that GP was mixing up chips
| (and chip-like modules) with boards.
| tbyehl wrote:
| Espressif sell bare chips, modules with castellations for
| soldering to a PCB, and complete boards that typically
| contain a module. Some 3rd-party boards use a bare chip.
| Some 3rd-party boards also have castellations, as do
| Picos sold without pre-soldered headers. 3rd-party
| modules are also a thing.
|
| Here's a pic of a module and several boards that
| demonstrates all of that.
|
| https://imgur.com/a/yxjG8vh
| milesvp wrote:
| 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
| every peripheral, which can make chip selection even
| trickier. It really sucks to start designing around a chip
| that looks like it does everything you need with enough pins
| to only find out that once you start doing pin layouts you
| can't use both USART2 and I2C because they use the same pins.
| Worse, is when the datasheet makes this difficult to discern,
| and you only find out when doing some firmware work on a
| devboard.
| HyulianGrader wrote:
| FYI the RP2040 has peripherals too, a lot of the same ones.
|
| It's very clear that GP has an odd misconception that an
| ESP32 is some kind of development board complete with
| "connectors" and possibly a battery charger, while an
| RP2040 is just the SoC itself.
| 0x457 wrote:
| > 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.
| g15jv2dp wrote:
| Except it's not at all how GP used the word:
|
| > From Wifi/Bluetooth Antenna, LI Battery Controller,
| Ethernet whatever, Display or Camera Connector - You
| choose.
|
| None of those are in-chip peripherals. Besides, the RP2040
| comes with a lot of peripherals too. Not as much as an
| ESP32 by a wide margin, but still.
| croes wrote:
| But if it's about the chip then just grab any ESP32.
| jvanderbot wrote:
| Is there a non-Chinese equivalent of ESP that compares in terms
| of module integration re: Wifi et al? (but perhaps not cost)
| kragen wrote:
| no, of course not
| jvanderbot wrote:
| I dont see why that's obvious.
| kragen wrote:
| many new chips don't even have non-chinese datasheets
| jvanderbot wrote:
| You're making a probabilistic argument against the
| existence of an American made (or designed) equivalent to
| a Wifi+MCU module on a chip?
| kragen wrote:
| how is america in any way relevant here? we were
| discussing china
|
| you might be able to find american-designed (or european-
| designed, african-designed, antarctica-designed, etc.)
| chips that do something similar, but you can be pretty
| sure they will be made either in taiwan or in the rest of
| china
|
| in a now-deleted response to this comment, you asked,
| 'How is it relevant in the thread I started by asking for
| american designed chips?'
|
| you _didn 't_ ask for american-designed chips. you asked
| for _non-chinese_ chips, but many chinese chips are
| american-designed (in some sense, all of them, since
| transistors and integrated circuits are both american
| inventions). literally what you said was
|
| > _Is there a non-Chinese equivalent of ESP that compares
| in terms of module integration re: Wifi et al? (but
| perhaps not cost)_
|
| i just went back to see if you'd edited your comment, but
| no, that's literally what you said, byte for byte
| jvanderbot wrote:
| That's very helpful.
| Youden wrote:
| There aren't a whole lot of options for wifi specifically;
| there's tons of choice for Bluetooth though.
|
| For Wifi, the only competition I'm aware of is the wireless
| STM32 series from ST Microelectronics:
| https://www.st.com/en/microcontrollers-
| microprocessors/stm32...
|
| For BT, Nordic's nRF series is pretty popular. In the DIY
| world, I mostly know it in the form of the nice!nano, a
| keyboard controller.
| jvanderbot wrote:
| I see some microchip offerings, but am not clear on how
| they fit into this trade space.
| https://www.microchip.com/en-us/products/wireless-
| connectivi...
|
| These range from $4 to $14 for MPU + Wifi.
| Youden wrote:
| > The RPI2040 is JUST the chip whereas the ESP32 come with tons
| of peripherals for your liking.
|
| I think you're mistaking the ESP32 devkits for the ESP32
| itself. The thing that comes with an antenna, battery
| controller and any kind of connector whatsoever is a devkit or
| at least a module. The ESP32 itself is a small IC just like the
| RP2040.
|
| For example you might be thinking of a devkit like this:
| https://docs.espressif.com/projects/esp-idf/en/latest/esp32s...
|
| Which is itself based on a module (e.g. ESP32-S3-WROOM-1),
| which just bundles the ESP32-S3 IC with a few niceties (like
| wifi antenna or connector).
|
| The equivalent for the RP2040 would be the Raspberry Pi Pico,
| which does come with some minor niceties (like a wifi variant).
| There are other products that package it with different
| peripherals.
|
| > So you are comparing the first of its kind SOC with a decade
| old Family of SBCs.
|
| Neither the RP2040 nor ESP32 series are SBCs and neither has
| any SBC lineage. The Raspberry Pi SBCs were all Broadcom based,
| the RP2040 is a brand new IC developed by Raspberry Pi and
| afaik has no IP licensed by Broadcom.
| smcameron wrote:
| We'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 be any fun):
| https://github.com/HackRVA/badge2024
|
| [1] Video of the 2023 badge:
| https://www.youtube.com/watch?v=KWZriUMNpLc [2]
| https://rvasec.com/
| brcmthrowaway wrote:
| Why custom and not use NXP stuff?
| JohnFen wrote:
| The RP2040 is pretty cool. I've used them in a half dozen
| projects now.
|
| > Raspberry Pi pulled a Henry Ford and boldly went with just one
| microcontroller.
|
| However, this one size fits all thing doesn't work for me. I
| prefer to use the least microcontroller that will do the job I
| need done.
|
| > There is no choice, no right sizing, but that might be OK! An
| RP2040 costs ~70 cents, and not all gizmos are produced by the
| million.
|
| The reason I like to use the wimpiest microcontroller possible is
| not related to monetary cost. It's related to my power budget.
| Most of my projects are battery-powered, and having them use the
| least possible amount of juice is a huge advantage.
|
| But even so, why use a $1 microcontroller when a 20 cent one will
| do the job equally well?
| samatman wrote:
| A much larger pool of online documentation, example code, and
| experienced hobbyists who like answering questions, is worth a
| great deal more than eighty cents.
|
| Getting more use out of the battery is a good and sufficient
| reason to use a less powerful controller, though. It being
| cheaper is nice in theory, but almost meaningless for a one-off
| project, in practice. I can't remember the last time I made a
| purchase which was a fraction of a dollar, it just doesn't move
| the needle.
| peteforde wrote:
| 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 wrote:
| 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/12...
|
| [2] https://github.com/platformio/platform-raspberrypi/pull/36
| peteforde wrote:
| 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 wrote:
| 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 wrote:
| > 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
| 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 wrote:
| > 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 wrote:
| > 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.
| 127 wrote:
| 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 wrote:
| 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
| peteforde wrote:
| Thanks for this! I am happy to have been wrong about the
| touch stuff, because I'm learning a lot.
| _Microft wrote:
| 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
| danhor wrote:
| 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?
| peteforde wrote:
| 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/...
| crote wrote:
| > 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 wrote:
| 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 wrote:
| 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-wi...
| olabyne wrote:
| what is the drama with platformIO ?
| peteforde wrote:
| https://github.com/platformio/platform-raspberrypi/pull/36
| SAI_Peregrinus wrote:
| 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 wrote:
| > 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 wrote:
| > _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.
| zbrozek wrote:
| 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 wrote:
| The pico board is the de facto module for me. Very cheap and
| breaks out every useful signal.
| aswanson wrote:
| Pico board is the module. I agree that placing the xtal etc is
| too much.
| g15jv2dp wrote:
| 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.
| a1o wrote:
| Well it's still young so of course there's only RP2040. I
| remember the 8051, 8052, 80C51, up to the recent ADuC845...
| seba_dos1 wrote:
| > Dozens of slightly different controllers. Why?
|
| Many of those listed are the same controllers in various modules.
| Espressif has a bunch of different uC series, but not _that_
| many. In contrast, aside of the whole Pico dev board, Raspberry
| Pi does not offer _any_ ready-made module with RP2040.
| dragontamer wrote:
| RP2040 is awkward in my experience.
|
| Everyone needs Flash, and RP2040 has none. Very few projects need
| more than 32kB of SRAM (especially on an anemic Cortex-M0+ core).
| You're missing an FPU (like on Cortex-M4 or higher chip), so DSP
| capabilities are awful even if your clock speed is high.
|
| RP2040 has awful power consumption: 20mA. The M0+ competitors are
| 10mA, 5mA, or even sub 1mA. Once we get to more recent Cortex-M23
| or Cortex-M33 (or the 8-bitters)... many competitors sleep in the
| under 1uA (!!!) regime, meaning "always on" chips (when you're
| under 15uA or so, you're undercutting many battery's internal
| leakage currents, so your chip's current usage becomes a rounding
| error). RP2040 is incapable of "always on" computation like this,
| so this limits applicability.
|
| RP2040 has some peripherals, but its missing common modern
| components. Many competitors (AVR DB, TI's MSP430 and MSPM0,
| STM32G4) have OpAmps for mixed-signal conditioning. Most
| competitors have multiple analog-comparators. DACs are somewhat
| uncommon but AVR and TI offer them.
|
| -------
|
| So comes the question: what kind of project are people using
| RP2040 for? It can't be cost-optimized, because by the time you
| buy a flash-chip and external oscillator you've overrun the costs
| of the competitors.
|
| Its not power-efficiency, because RP2040 is a power-hog. You're
| getting far less battery life compared to competitors. (Case in
| point: the microcontroller that handles your wireless credit-card
| transactions is battery-less, running purely off of the energy of
| latent energy waves in the NFC protocol. RP2040 will never reach
| these low levels of power consumption).
|
| Where I see RP2040 as useful, is utilizing its absurd 264kB SRAM
| (far, far larger figure than most chips). If you need a graphics
| framebuffer for a small 300x200 8-bit color screen or something,
| then RP2040 is probably the right choice. (60kB for the
| framebuffer, and likely 2 or 3 of them for various computations
| on the frame buffer).
|
| But outside of a display driver, its difficult for me to find
| projects where RP2040 is actually the correct choice. Besides,
| screens are relatively expensive (in both $ and in power
| consumption), so if you're getting a screen you probably can
| upgrade to a SAM9x75 with full 2D GPU, DDR3L 800MHz and Linux
| support for like $12 for those SiP packages.
|
| -------
|
| At a minimum, the next version of RP2040 needs to include on-
| board Flash / on-board programming. This is something _every_
| project needs (RP2040 needs to run its code off of _something_
| anyway). The fact that it ships flash-free is incredibly absurd
| to me at least.
|
| RP2040 forces a microprocessor-mindset ("one chip" where you add
| a bunch of addons) inside of the low-cost microcontroller market
| segment. Its very strange.
| jsheard wrote:
| > At a minimum, the next version of RP2040 needs to include on-
| board Flash / on-board programming. This is something _every_
| project needs (RP2040 needs to run its code off of _something_
| anyway). The fact that it ships flash-free is incredibly absurd
| to me at least.
|
| You might get your wish there with their next chips, their last
| investor report revealed that it will be the "RP235x family".
| Based on the naming scheme they established with the RP2040
| that would be two Cortex-M3 cores with ~512kb RAM, and the "X"
| placeholder being the amount of onboard flash where the RP2040
| had a "0" for "no flash", so that implies there will be a range
| of models with different amounts of integrated flash.
| 127 wrote:
| PIO is fantastic. Revolutionary. Not trivial to use but extremely
| powerful and adaptable. Too bad about the ADC. To be clear: the
| ADC is not "OK". It' s BAD.
| GeorgeTirebiter wrote:
| Unfortunately, the poor ADC performance is due to a design /
| simulation error; at least you have to give them credit that
| they 'came clean' on the crappy performance, and explained it
| in the official documentation:
| https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
| section 4.9
|
| See https://pico-adc.markomo.me/ for a thorough analysis of the
| problems.
|
| Especially look at the DNL.
| uncletaco wrote:
| RP2040 has single handedly reinvigorated a really niche market:
| custom controllers. Due to the wonderful work done on gp2040[1]
| which is open source game pad firmware, people can buy cheap,
| quality, fightsticks and leverless controllers for a lot cheaper
| than they can from vendors like Victrix or Razer. Not only that
| but because its open sourced the hobbyist side of the controller
| community are building RP2040 pcbs to accommodate all kinds of
| projects and weird controller ideas.
|
| [1] https://gp2040-ce.info
| crote wrote:
| I do wonder how much of that can be accounted directly to the
| RP2040. Projects like QMK[0] have been using a technically
| quite similar codebase for making DIY keyboards for quite a
| while now.
|
| At first glance I'm not really seeing anything in GP2040 which
| couldn't have been done with any other somewhat-modern MCU. The
| RP2040 has undoubtedly been the catalyst leading to GP2040's
| widespread adoption, but it seems the same could've happened
| with a Pro Micro instead.
|
| [0]: https://github.com/qmk/qmk_firmware
| CarVac wrote:
| Not to mention PhobGCC (I'm the lead dev) and its less-
| Gamecube-specific descendents such as ProGCC V3 and GC Ultimate
| and Phizard...
| uncletaco wrote:
| I'll mention it. PhobGCC is awesome and thank you for making
| it!
| opello wrote:
| Doesn't this discount things like the Brook boards (e.g., Zero-
| Pi[1]) that came before? I only take issue with "single
| handedly" because it seems not quite true to the history here.
|
| [1] https://www.brookaccessory.com/detail/53169470/
| uncletaco wrote:
| It doesn't. Brook boards always added like an extra $100
| dollars to any custom or DIY fight stick. The reinvigoration
| came because sticks that used to be $250 new are now closer
| to $100 and in some cases less, particularly leverless
| controllers. If you've heard of the Haute 42 or any of the
| countless leverless controllers that have been flooding Ali
| Express, Amazon, and other sites they're possible because of
| the firmware gp2040. For a lot of these new makers all they
| have to do is get the pcb printed and build an enclosure.
| crote wrote:
| 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 interface is great - but it doesn't support
| writing so you can't hook up an FRAM chip and expand your memory.
| That PIO interface is amazing - but having only 2x32 instructions
| is quite limiting once you try to implement more complex
| interfaces. And where are my Timer/Counters? No capacitive touch?
| Analog on only four pins? No 5V tolerance? No high-speed clock
| input for the PIO modules? Why can't I run the bootloader off the
| internal ring oscillator? Hmm, a USB-C PHY sure would've been
| helpful...
|
| I was also surprised about its poor ESD performance. An Atmega or
| STM32 can handle the occasional zap just fine - ESD protection is
| more of a nice-to-have on external-facing ports. The RP2040? If
| you don't add external protection to _every single pin_ you are
| basically guaranteed to see a few of them die due to day-to-day
| use.
|
| To summarize: neat chip, great for hobbyists, wouldn't be my
| first choice in professional environments.
| doubloon wrote:
| Raspberry pi was originally an educational non profit
| dfox wrote:
| I suspect that the Synopsys DesignWare SSI macro in RP2040 can
| in fact be used for R/W PSRAM or FRAM, but the abridged
| documentation of it in RP2040 datasheet is not sufficient for
| one to configure it that way.
| stefan_ wrote:
| 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.
| ChiefNotAClue wrote:
| Well said. I'll add that, as a hobbyist, you'll eventually work
| on more involved projects and run into those exact limitations.
| kragen wrote:
| i'm curious what kinds of applications you've found fram most
| useful for. it seems like a really cool technology, but the
| price point is so high that i struggle to understand when you'd
| use it rather than a combination of sram (or psram) and nand
| dragontamer wrote:
| I assume that most people's use of FRAM is when its
| integrated into TI's MSP430 microcontrollers
|
| IE: if FRAM comes free with your MCU, might as well use it
| and take advantage of its benefits. For example:
| MSP430FR4132, just picking one such MCU off of Digikey
| (https://www.digikey.com/en/products/detail/texas-
| instruments...)
|
| ------
|
| Most of what I know of FRAM comes from TI's marketing pages.
| https://www.ti.com/document-viewer/lit/html/SSZTA32
| kragen wrote:
| probably so, but crote was talking about external fram
| chips
|
| the msp430fr4132 you linked costs 160C/ in quantity 35,
| which is actually considerably cheaper than comparable
| flash-based chips like the msp430f233
| https://www.digikey.com/en/products/detail/texas-
| instruments... which is 500C/ in quantity 25. so that's
| maybe one reason people would use fram: evidently it's
| cheaper than nor? but i'm pretty sure there are mcs with 8k
| of nor flash that are cheaper than that and in fact cheaper
| than the price difference. is this pricing policy some sort
| of loss leader by ti to drive fram adoption? it seems
| unlikely. does using fram instead of nor make it cheaper
| for ti to make the chip? surely 8k of nor couldn't account
| for such a large cost
|
| on further investigation, i _don 't_ find mcs with 8k of
| nor flash that are cheaper than that, at least in stock at
| digi-key and still in production. https://www.digikey.com/e
| n/products/filter/embedded/microcon... is the link to my
| search, which i trust hn will abbreviate in a useful way.
| but lcsc has the ch32v203 in stock for 39C/ in quantity 100
| https://www.lcsc.com/product-detail/Microcontroller-Units-
| MC... and that has 20k of sram, 64k of flash (presumably
| nor!), and 24 gpios. that's half the gpios of the ti chip,
| but i believe my digi-key search linked above was not
| limited by pin count
|
| so maybe the only reason fram costs more is that ti doesn't
| license the fram patents to chinese companies? it still
| beggars belief that ti (and microchip, st, etc.) would be
| spending three dollars a chip on 8k of nor, or even three
| dollars a chip divided by two layers of profit margin
| dragontamer wrote:
| AVR64DD14 is $1.20 qty25 for 64kB of Flash and 8kB of
| SRAM (and quite a bit more analog features, like dual-
| power supplies, more ACs, DAC, Differential ADC...).
|
| So I'm pretty sure NOR Flash remains quite cheap. TI's
| MSP430 are all cheapest with FRAM though, so your
| question is curious. I admit I don't know where to go or
| how to investigate your question however. I don't really
| use MSP430 myself, I just know thats what is commonly
| associated with FRAM in the literature I've read.
| fxtentacle wrote:
| The real competition is the STM32 line-up, in my opinion. Much
| more computing power at a comparable price. Or half price if you
| only need a few MHz.
| AtillaBosma wrote:
| I want to shout out the fighting game community with:
| https://gp2040-ce.info/
|
| It has been using the RP2040 to create cheap and easy to make
| controllers for fighting games while providing the lowest
| possible input delay.
|
| The RP2040 does a great job acting as a chip for the base of a
| gamepad, so it doesn't even have to be for a fighting game
| controller, but any controller you want to create.
| weinzierl wrote:
| I think the PIO state machines are pretty cool and relatively
| unique. I am also glad the Foundation resisted the temptation to
| market them as extra cores and sell the RP2040 as 10-core
| processor.
|
| When it comes to the Raspi Pico and similar devices[1], I think
| UF2 flashing is the best thing since sliced bread. This alone
| lowers the barrier for beginners significantly.
|
| Things I don't like: power consumption.
|
| But you can't have everything...
|
| [1] I know it is not restricted to RP2040 boards, but I think it
| is nowhere as common as there.
| mdp2021 wrote:
| > _Things I don 't like: power consumption_
|
| I understand it could use ~0.08W, given it draws 3.3V at
| ~24mA... I am not a specialist, is that a lot?
|
| Ref.: https://learn.sparkfun.com/tutorials/rp2040-thing-plus-
| hooku...
| dragontamer wrote:
| TI's MSPM0G350x (also a low-cost Cortex-M0+ design) runs
| full-tilt at 8mA, STOP-sleeps at 400uA, STANDBY-sleeps at
| 5uA, and SHUTDOWN-sleeps at 80nA.
|
| https://www.ti.com/lit/ds/symlink/mspm0g3507-q1.pdf
|
| --------
|
| RP2040's full-speed is okay. 20+mA is a lot but it is easily
| explained by the absurdly huge SRAM banks it has.
|
| But RP2040's sleep states are absolutely AWFUL. The
| Cortex-M0+ chips are all extremely power-competitive vs each
| other, because Cortex-M0+ is extremely low-end with regards
| to core-design.
|
| You're pretty much only getting a Cortex-M0+ because its the
| absolute minimum 32-bit processor on the market. (8-bitters
| and 4-bitters exist if you're willing to go even lower-end,
| but Cortex-M0+ is the bottom of ARM's offerings). So low-
| power seems to be a must in this market, IMO anyway.
|
| If you're willing to use higher amounts of power, you really
| should get a few more features, like an FPU on the Cortex-M4.
| seba_dos1 wrote:
| Yes, it's a lot. It will empty a 1000mAh battery in about two
| days. In sleep states, you'll find it challenging to reach a
| single month on RP2040 while you can build things with other
| controllers that would last years on the same battery.
| vbezhenar wrote:
| The main issue is that there's no low power sleep mode. There
| are sleep modes, but they consume tremendous amount of power,
| so there's no way to build a battery-powered device.
| gbin wrote:
| Indeed the software support is awesome, even using rust on it is
| a pleasure!
| ta988 wrote:
| Posted yesterday, info about the successor to the RP2040:
| https://news.ycombinator.com/item?id=40642268
| Teknoman117 wrote:
| Admittedly this is from a hobbyist perspective, but I'm hard
| pressed to reach for an ATmega for basically anything these days
| due to the RP2040, the Pico, and its clones.
|
| I do wish there were more ADC channels though. Even an external
| analog mux costs more than the whole RP2040...
| dheera wrote:
| I much prefer the ESP32, the RP2040 doesn't even have WiFi or
| bluetooth, you would think every microcontroller should have
| those things these days.
| robomartin wrote:
| Back a few years ago, due to chip shortages I was forced to use
| the RP2040 on an industrial project. No option really.
|
| The first problem with the chip is that it has zero security. Not
| important for hobbyist, I get it, however, for professional
| applications, this can be very important.
|
| Not, it isn't always about not wanting people to read your code.
| The application in question was a networked industrial controller
| with a thousand nodes. At a minimum, there's a need to ensure
| that the code and data cannot be altered. External memory does
| not allow for this. Our customer understood supply chain issues
| and agreed to accept the RP2040 design provided we replaced all
| nodes (at a cost) once a non-RP2040 node could be manufactured.
|
| Before I talk about the other problem I have to admit not having
| looked at the RP2040 ecosystem for about two years. No idea if
| this has changed.
|
| The other problem is that the RP2040 team was --again, don't know
| if this changed-- down-right hostile about Windows. They would
| respond to requests for better Windows support with moronic
| statement like (paraphrasing) "Just switch to Linux. It isn't
| that difficult".
|
| These statements were both tone-deaf and ignorant of realities
| out there. When you start dealing with non-trivial, non-hobby
| designs, there's a need for practices such as PLM (Product
| Lifecycle Management). When your entire engineering organization
| is using CAD, CAM, EDA and other tools rooted in the Windows
| ecosystem, you might not have the freedom to switch to Linux just
| because you bought a little $0.50 chip. It doesn't work that way.
|
| Even worse, if we did that, we would be forced to store a full VM
| with the working Linux distribution and RP2040 toolchain with
| every single release of the design. Note I did not say
| "software". I am talking about mechanical, electrical, optical,
| multi-board firmware with different processors, tests,
| manufacturing, manufacturing testing, etc.
|
| In other words, the ill-informed "just switch to Linux" attitude
| simply revealed that --at least at that time-- this organization
| did not understand the professional/industrial embedded world in
| the way companies like ST and others actually do.
|
| The net result was that, as much as the chip was super-
| interesting, we dropped it like a hot potato as soon as we could
| and moved back to the STM ecosystem, where the chip provider
| doesn't think that asking us to upend our entire workflow for
| single chip is a sensible suggestion.
___________________________________________________________________
(page generated 2024-06-11 23:00 UTC)