Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I like the RP2040

dgroshev.com

Post reply on HN
Print view View original

211–220 of 413 posts

Re: I like the RP2040

#211

Post by kragen »

jvanderbot wrote: post #156
flohoff wrote: post #80

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.…

Is there a non-Chinese equivalent of ESP that compares in terms of module integration re: Wifi et al? (but perhaps not cost)

no, of course not

Re: I like the RP2040

#212

Post by KaiserPro »

jsheard wrote: post #46
jcalvinowens wrote: post #44

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.

> 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.

Source? I've not seen a patent for that, plus I suspect its not actually patentable

Re: I like the RP2040

#213

Post by _Microft »

127 wrote: post #145
peteforde wrote: post #120

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful plac…

You can do capacitive touch with RP2040 just fine. Turn on, turn off, measure time. Plus I don't like modules as they seem pointless complexity when I just want to order a ready-assembled, self-designed PCB.

I also did not understand this complaint. On a Pico, any GPIO can be used for touch (using PIO of course).

Example with 23 touch buttons if I counted that correctly:

https://github.com/todbot/picotouch

Re: I like the RP2040

#214

Post by kragen »

fleventynine wrote: post #118
the__alchemist wrote: post #101

Earlier quoted context omitted.

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?…

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 comfor…

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)

Re: I like the RP2040

#215

Post by kragen »

crote wrote: post #153

I have mixed feelings about the RP2040. On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application. On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine , but once you start looking into the details it's easy to run into limitations. That XIP int…

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

Re: I like the RP2040

#216

Post by written-beyond »

topspin wrote: post #177
cockings wrote: post #5

Earlier quoted context omitted.

It's mentioned in the article.

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…

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.

Re: I like the RP2040

#218

Post by Havoc »

botdan wrote: post #116
Havoc wrote: post #18

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?

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,…

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

Re: I like the RP2040

#219

Post by jsheard »

KaiserPro wrote: post #212
jsheard wrote: post #46

Earlier quoted context omitted.

> 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.

Source? I've not seen a patent for that, plus I suspect its not actually patentable

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.

Re: I like the RP2040

#220

Post by dragontamer »

dave78 wrote: post #198
dragontamer wrote: post #176

Earlier quoted context omitted.

> 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 plac…

> 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 eno…

> 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.

Post reply on HN