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

401–410 of 413 posts

Re: I like the RP2040

#401

Post by crote »

15155 wrote: post #395
crote wrote: post #167

Earlier quoted context omitted.

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

Add a $2.80 ICE40 with built-in NVM and your problems are solved.

Considering the RP2040 is only $0.70, not exactly an attractive option.

Re: I like the RP2040

#402

Post by snvzz »

15155 wrote: post #397
snvzz wrote: post #396

Earlier quoted context omitted.

Of course not, those are proprietary technologies specific to ARM. If anything, they implement RISC-V debug and trace specs, or earlier vendor-specific, as these specs are relatively new.

Which is why I stated "resembling." TIL about the RV debug/trace specs, this has been one of my major complaints. The vendor-specific stuff is plainly terrible. I don't see anything like SWD being consistently defined by this spec, though?

I advice to join the RISC-V Foundation, participate, and get what you want.

Re: I like the RP2040

#403

Post by Brusco_RF »

15155 wrote: post #388
Brusco_RF wrote: post #364

Earlier quoted context omitted.

I also happen to be working on an ultra-low power project with an ESP32. It is hard to beat that 5uA deep-sleep current!

Try active current consumption on the Ambiq Apollo4 chips.

Thanks for that, looks interesting. One note, their website [1] claims 5uA/MHz, not 1

[1] https://ambiq.com/apollo4/

Re: I like the RP2040

#404

Post by 15155 »

crote wrote: post #401
15155 wrote: post #395

Earlier quoted context omitted.

Add a $2.80 ICE40 with built-in NVM and your problems are solved.

Considering the RP2040 is only $0.70, not exactly an attractive option.

If an RP2040 doesn't fit the task because it has a pitiful amount of IO, you're now into using two anyway. Two chips, two SPI flashes, two crystals - likely more than the FPGA.

If it matters for the task, that FPGA will be able to achieve nanosecond-order IO/clock-to-clock skew times - PIO is painfully bad at this (and is executed serially.)

If the task will fit FlexIO's restrictions, the NXP IMXRT1011 at $1.70 blows away the $0.70 RP2040 in basically every metric.

Re: I like the RP2040

#405

Post by 15155 »

Brusco_RF wrote: post #403
15155 wrote: post #388

Earlier quoted context omitted.

Try active current consumption on the Ambiq Apollo4 chips.

Thanks for that, looks interesting. One note, their website [1] claims 5uA/MHz, not 1 [1] https://ambiq.com/apollo4/

Yes, that's correct. I had confused it with the total consumption at rated speed - ~1mA and mixed up my figures.

Re: I like the RP2040

#406

Post by 15155 »

Teknoman117 wrote: post #252

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

https://www.lcsc.com/product-detail/Analog-To-Digital-Conver...

Commercial 16-bit/4ch ADCs can be obtained for The RP2040 ADC is not good, and I am not often sampling something close to my noisy MCU. I'd rather route I2C anywhere than worry about signal integrity routing my analog signal a mile across the board.

Re: I like the RP2040

#407

Post by kragen »

crote wrote: post #399
kragen wrote: post #215

Earlier quoted context omitted.

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

The main application here would be that the RP2040 only has a single XIP QSPI bus. If you extend its memory by hooking up PSRAM to that bus, you can't boot because the chip loads all its code from QSPI. If you hook flash up to that bus, you don't have any way to add extra memory. FRAM would allow you to have your cake and write it: your application code survives a reboot, and (if the chip were to gain write support)…

i see, that makes a certain amount of sense, thank you. normally you can share a single spi or dual/quad spi bus between multiple peripherals with different /cs lines, but i guess that would be pretty tough to make work for instruction fetches. older chips like the 8086 had a pin to tell the memory system when it was fetching an instruction, but i haven't seen that feature in a long time, not even enabled by a fuse

you can probably use qpi that way (with both psram and flash) if you sacrifice xip and settle for loading overlays? you could even store them on qpi nand

Re: I like the RP2040

#408

Post by jcalvinowens »

15155 wrote: post #384
jcalvinowens wrote: post #288

Earlier quoted context omitted.

I'm speaking from experience, I built two boards with the rp2040 before I decided to stop using it. The pin flexibility is nice, I agree with you there. But I spend more time dealing with the flash chip than that saves me. I don't want more capability. An STM32 M3 has far far more processing throughput than I need for 99.9% of what I do. I want the smaller thing, even if it isn't cheaper. It is sufficient. I love stm…

How much time does it take to place a DFN-8 flash chip and 6 routes in reality? The RP2040 is absolutely usable from simple registers and documentation, not sure where you got this idea. The reason you want multiple megabytes of space in a professional product: identically-sized bootloader partitions for trial boots.

It takes more time than doing nothing, so it's a waste of time unless I require it.

Obviously it's usable that way, I said it wasn't as simple (the hardware is more complex to initialize).

Using "megabytes of space" for "trial boots" sounds like a rube goldberg machine that would cause more problems than it would ever solve on a chip you can't OTA, but feel free to argue with me :)

Re: I like the RP2040

#409

Post by vardump »

15155 wrote: post #368
vardump wrote: post #350

Earlier quoted context omitted.

PIO can be PWM, SPI, I2C, USB, DVI, VGA, ISA-bus, PS1 memory card, that weird protocol some old EL-display uses and hundreds of other peripherals. Lots of exotic protocols for which you would have previously needed an FPGA. That's why you'd choose RP2040.

Or I would just choose an NXP IMRXT-series MCU with FlexIO (which can do 90% of these protocols) and actually be able to protect my product to some degree (encrypted XIP, high-assurance boot, SWD lockout.)

> encrypted XIP, high-assurance boot, SWD lockout

Yeah, would love these on RP2040.

As well as better ADC, "halved" (half mem, IO, PIO and CPU) cheaper version, "doubled" version (2x mem, IO, PIO and M4f CPU cores), integrated flash version, etc. Better power consumption.

That said, I do like PIO and you can use RP2040 as a PIO-peripheral to something more protected.

Re: I like the RP2040

#410

Post by nsteel »

trealira wrote: post #370
nsteel wrote: post #366

Earlier quoted context omitted.

There's no maybe about it. And it goes beyond greetings. But I do agree it was non-sensical here

You're right, people do use it neutrally in greetings, not just maybe. And in more than greetings, more as a general form of address. More specifically, I would say that when not used to address multiple people in the second person (i.e. when saying "you guys"), then the word "guy" implies that the referent is male.

Except for idioms like "I've got a guy" where you just mean you've got someone in mind. And that's where I was coming from with "silicon guy" or "hardware guy", "software guy" etc. Just as generic terms for your goto person in those fields, no gender implied.
Post reply on HN