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

I got almost all of my wishes granted with RP2350

dmitry.gr

Post reply on HN
Print view View original

341–350 of 356 posts

Re: I got almost all of my wishes granted with RP2350

#341

Post by ryukoposting »

valdiorn wrote: post #279
ryukoposting wrote: post #106

I can't imagine someone using an RP2040 in a real product, but the RP2350 fixes enough of my complaints that I'd be really excited to give it a shot. There's a lot going for the 2040, don't get me wrong. TBMAN is a really cool concept. It overclocks like crazy. PIO is truly innovative, and it's super valuable for boatloads of companies looking to replace their 8051s/whatever with a daughterboard-adapted ARM core. But…

> I can't imagine someone using an RP2040 in a real product Why not? It's a great chip, even if it has some limitations. I use it in several of my pro audio products (a midi controller, a Eurorack module, and a series of guitar pedals). they are absolutely perfect as utility chips, the USB stack is good, the USB bootloader makes it incredibly easy for customers to update the firmware without me having to write a cust…

Given the way the RP2040 is set up, I cannot conceive of a proper secure boot chain for it. So, for basically everything I work on professionally, it's a non-starter. I think the key in your use case is that "hackability" is a feature, not a potentially life-threatening risk.

Re: I got almost all of my wishes granted with RP2350

#342

Post by TaylorAlexander »

rscott2049 wrote: post #324
crote wrote: post #275

Earlier quoted context omitted.

You run into issues if you try to implement something like RMII, which requires an incoming 50MHz clock. There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of p…

Almost correct - the third implementation does generate the clock, but it isn't necessary to drive the clock directly from the system clock, as there are m/n clock dividers available. I use a 300 MHz system clock, and divide down to 50 MHz which works well. (I've also addressed a few other shortcomings of this library, but am not done yet...) Haven't looked at the 10 MHz half duplex mode, though.

Do you have your code publicly available? I was just discussing with a friend it would be nice to add an optional Ethernet mode to my motor controller, but the limitations of this library or other approaches limit the appeal.

Also, are there any other approaches that might be better and would offer 100meg or even gigabit links with the RP2350? Thanks!

Re: I got almost all of my wishes granted with RP2350

#343

Post by alfanick »

dmitrygr wrote: post #38
tecleandor wrote: post #37

Not off topic but a bit tangentially... How difficult would be emulating an old SRAM chip with an RP2040 or an RP2350? It's an early 80s (or older) 2048 word, 200ns access time CMOS SRAM that is used to save presets on an old Casio synth. It's not a continuous memory read, it just reads when loading the preset to memory. I feel like PIO would be perfect for that.

I did that, not just SRAM but also ROM, to fool a MC68EZ328 successfully. It works well. PIO + DMA does it well. Specifically i replaced rom & ram in an old Palm Pilot with an RP2040: https://photos.app.goo.gl/KabVe5CrfckqnFEt7 https://photos.app.goo.gl/LGAkp6HoYAJc3Uft7 Edit: I did not yet update the rePalm article but much about that is in the Palm discord. https://discord.gg/qs8wQ4Bf see #repalm-project channel

Pokemon are nice touch here

Re: I got almost all of my wishes granted with RP2350

#344

Post by steeve »

dheera wrote: post #143
kaycebasques wrote: post #142

Big day for my team (Pigweed)! Some of our work got mentioned in the main RP2350/Pico2 announcement [1] but for many months we've been working on a new end-to-end SDK [2] built on top of Bazel [3] with support for both RP2040 and RP2350, including upstreaming Bazel support to the Pico SDK. Our new "Tour of Pigweed" [4] shows a bunch of Pigweed features working together in a single codebase, e.g. hermetic builds, on-d…

I hate Bazel. A build system for C/C++ should not require a Java JVM. Please keep Java out of microcontroller ecosystem please -__--

Bazel is amazing and doing C++ with anything other is like going back to the stone age.

The Bazel team has done an amazing job, the VM is embedded and trimmed. It’s as easy and download and run.

And worst case you can invest in Buck2.

Re: I got almost all of my wishes granted with RP2350

#345

Post by jacobmarble »

andylinpersonal wrote: post #312
repelsteeltje wrote: post #11

Earlier quoted context omitted.

... And RP2354A/B even has 2MB built in flash!

Indeed an in-package winbond flash die though.

Please explain. What is a better alternative that could have been chosen?

I’m just happy to have one fewer component on my boards.

Re: I got almost all of my wishes granted with RP2350

#346

Post by 4gotunameagain »

KaiserPro wrote: post #284
4gotunameagain wrote: post #155

Earlier quoted context omitted.

afaik that is a whole different rodeo on the silicon level

yeah lockstep requires a whole bunch of things to verify and break deadlocks. I suspect you need three processors to do that as well (so you know which one has fucked up.)

It is not necessary that there is triple modular redundancy with lockstep, I know of microcontrollers with two processors, who throw an error when the results from instructions don't match.

Re: I got almost all of my wishes granted with RP2350

#347

Post by soneil »

4gotunameagain wrote: post #346
KaiserPro wrote: post #284

Earlier quoted context omitted.

yeah lockstep requires a whole bunch of things to verify and break deadlocks. I suspect you need three processors to do that as well (so you know which one has fucked up.)

It is not necessary that there is triple modular redundancy with lockstep, I know of microcontrollers with two processors, who throw an error when the results from instructions don't match.

yes - two votes allows you to detect a disagreement, three votes allows two votes to win.

Re: I got almost all of my wishes granted with RP2350

#348

Post by rscott2049 »

TaylorAlexander wrote: post #342
rscott2049 wrote: post #324

Earlier quoted context omitted.

Almost correct - the third implementation does generate the clock, but it isn't necessary to drive the clock directly from the system clock, as there are m/n clock dividers available. I use a 300 MHz system clock, and divide down to 50 MHz which works well. (I've also addressed a few other shortcomings of this library, but am not done yet...) Haven't looked at the 10 MHz half duplex mode, though.

Do you have your code publicly available? I was just discussing with a friend it would be nice to add an optional Ethernet mode to my motor controller, but the limitations of this library or other approaches limit the appeal. Also, are there any other approaches that might be better and would offer 100meg or even gigabit links with the RP2350? Thanks!

I'm still working on it - hopefully will be on the DECstation2040 github soon. The interface uses the LAN8720/8740 MAC chips, which provide 10/100 Mbit. (I haven't tried 10 Mbit, so no idea if it works or not). FYI, here's a test result: ping -q -i 0.005 192.168.1.6 PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data. 229501/229501 packets, 0% loss, min/avg/ewma/max = 0.063/76.725/88.698/160.145 ms 295393/295987 packets, 0% loss, min/avg/ewma/max = 0.063/76.792/37.003/160.171 ms 295393/296278 packets, 0% loss, min/avg/ewma/max = 0.063/76.792/37.003/160.171 ms

(Above is with killall -s QUIT ping) As you can see, it eventually hangs, and CMSIS reports: target halted due to breakpoint, current mode: Handler HardFault xPSR: 0x61000003 pc: 0x200001c4 msp: 0x20040f40

Re: I got almost all of my wishes granted with RP2350

#349

Post by rldjbpin »

g15jv2dp wrote: post #302
rldjbpin wrote: post #291

Earlier quoted context omitted.

devil's advocate: cables for an average user is a different story. also not to forget the vast range of cables already existing out there. also "proper" usb-c support is another can of worms, and maybe sticking to an older standard gives you freedom from all that.

You're confusing USB C and USB 3.1+. USB C is just the physical spec. You can design a cheap device that will only support USB 2 if you just connect ground, Vbus, D+ and D- and gasp add two resistors. It will work just as well as the micro-usb plug.

completely valid, but i would like to think the org is still designing for accessibility for newbies in mind.

like you said, the connector does not have to follow the standards. i have seen hdmi ports being used to carry pcie signal (not a good like but here is one such device https://pipci.jeffgeerling.com/cards_adapter/pce164p-no6-ver...) amgon other things. it is still non-standard behaviour.

Re: I got almost all of my wishes granted with RP2350

#350

Post by g15jv2dp »

rldjbpin wrote: post #349
g15jv2dp wrote: post #302

Earlier quoted context omitted.

You're confusing USB C and USB 3.1+. USB C is just the physical spec. You can design a cheap device that will only support USB 2 if you just connect ground, Vbus, D+ and D- and gasp add two resistors. It will work just as well as the micro-usb plug.

completely valid, but i would like to think the org is still designing for accessibility for newbies in mind. like you said, the connector does not have to follow the standards. i have seen hdmi ports being used to carry pcie signal (not a good like but here is one such device https://pipci.jeffgeerling.com/cards_adapter/pce164p-no6-ver... ) amgon other things. it is still non-standard behaviour.

Using an USB C port to carry an USB 2.0 signal is perfectly within the standards.
Post reply on HN