Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have just one question: is this product meant for the "hobbyist" space only?


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.


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?


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


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/


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.


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.


Yes. Pico SDK is C with CMake and Rust is bare metal (I think).


Maybe with the Arduino CLI?


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.


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.


Ok, but does it fulfill military or automotive standards?


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.


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.


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!


Probably yes, but it doesn't have the paperwork AFAIK.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: