Hacker News Reader

4. It's available ~'everywhere'.

RPi foundation has done a great job at making it's product available to buy at the time of announcement in over 50 countries and I think that's underrated.

It shows 5 different websites for me to buy in India, which is not usually the case here for new hardware except few exceptions like Nvidia Jetson; if at all they ever make it to the country. Also RPi foundation/partners seems to be actively working with the Govt. to keep the prices competitive.

To give you a comparison, PinePhone costs >$200 (+tax) to get it here that is if at all it doesn't get blocked at the customs due to licensing requirements for telecommunication hardware, taxes for CBU(Completely Built Unit) smart phones, blockade on shipments from the country to the North. That's a tragedy considering huge number of Linux enthusiasts in the country and that alternate smartphone OS can indeed help Govt.'s self reliance goals.

P.S. That was not to diss on Pine64's efforts, but to show the state of enthusiast hardware availability in India.

+1. It is amazing seeing how well they’ve managed this.

There were educational launch videos out from the authorised Indian resellers on the day of launch, even.

"...doesn't get blocked at the customs due to licensing requirements for telecommunication hardware, taxes for CBU(Completely Built Unit) smart phones, blockade on shipments from the country to the North...."

OMG. I had forgotten. What a mess. Politics is a drag

Mostly corruption. Big companies pay politicians to introduce more barriers to enter the market so that there is less competition.

> Whilst there are certainly other boards with...

This IS the other boards!

I think if you look here:

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...

Scroll down and you'll see the RP2040 has been released on many boards simultaneously.

- Adafruit Feather RP 2040

- Adafruit ItsyBitsy RP 2040

- Arduino Nano RP2040 Connect

- Pimoroni PicoSystem

- Pimoroni Pico Explorer Base

- SparkFun Thing Plus – RP2040

- SparkFun MicroMod RP2040 Processor

- SparkFun Pro Micro – RP2040

4. Excellent documentation which will only likely get better. SDK in C/C++, and MicroPython. You can even learn concepts like PIO and DMA in MicroPython. Adafruit expressed confidence in their MicroPython libraries working out of the box, too.

The form-factor on the Pico is also a little nicer than and ESP32.

Pin duplicators are also available. This idea has a lot of potential, as it allows one to break out modules. It's much better than the Arduino shield for two reasons: 1. shields have quirky pin alignments, making it hard to create your own boards. 2. shields stack on top of the other, obscuring the layer below.

The Pico will be another stellar success from the Pi Foundation. I have no doubt.

What could be the reason to use DMA on a hobby micro-controller board? Honest question, I'm just curious. I can imagine some high reliability production systems that may prefer micro vs CPU, but why would you bother doing any more advanced graphics or anything like that on a microcontroller? I mean I played with VGA on arduino but that was because there were no cheap SBCc back then.

VHF radio transmitter? You construct some complex wave pattern and then push it out high-speed via DMA.

Battery life, having data transferred via DMA means the cpu can chillout/wfi/wfe which on some chips turns off the cpu clock altogether

> one set of DMA operations can program and trigger another channel.

I once worked around a very unfortunate hardware shortcoming in a DMA engine by doing exactly this. Each channel supported a list of descriptors, so I used the last descriptor to actually perform DMA operations on the configuration registers of the other channel.

The possibilities are endless with this kinda stuff

The possibilities are endless

So is the time wasted when there are bugs in the docs :P Don't remember the exact chip, but it was on the first job I had and it took me weeks to find out why the thing didn't want to do what I told it to. Turned out some names of registers were swapped in the docs. But indeed, once I figured that out, it was really nice to work with and things like interleaving data from multiple ADCs just worked with basically no CPU interaction.

Thanks for this summary.

I am excited about the DMA and PIOs having used BeagleBoard PRUs, but what about the quality of the ADCs/DACs?

Isn't all the talk of hard real-time applications and so on somewhat moot if those aren't high quality enough?

(afraid I haven't had time to read the datasheet yet!)

From the devboard datasheet:

> The RP2040 ADC does not have an on-board reference and therefore uses its own power supply as a reference. On Pico the ADC_AVDD pin (the ADC supply) is generated from the SMPS 3.3V by using an R-C filter (201 ohms into 2.2μF)

Which doesn't sound promising and I don't see a DAC in the RP2040 datasheet.

Right. I wonder if the Arduino version will be better for this, or whether we might need to wait for future boards from RPi.

It's good and bad. Nice that they've filtered AVCC pretty heavily-- 360Hz corner frequency-- lots of microcontroller boards don't.

Less nice that the ADC scale will be affected by power supply offset, though that all depends upon how "good" the board 3V3 is. The bandgap and error amplifier on the DC-DC converter IC is good at least-- max +/- 1%.

Is there a good guide that you recommend on the PIO or DMA features?

I've just been reading the datasheet here: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...

It does have some examples and the Pico SDK has various PIO programs you can look at for inspiration. The getting started page links to a few projects including the HDMI/DVI: https://www.raspberrypi.org/documentation/pico/getting-start...

Note that the HDMI/DVI code overclocks the Cortex M0 from its normal 133Mhz to 252Mhz. So it's a cool hack, but I think it would have wonky behavior. https://github.com/Wren6991/picodvi/blob/34bc82555860de4b35e...

On the upside, it looks as though the production silicon has a lot of performance headroom. The 800x600 mode overclocks it all the way to 400 MHz!

That is cool, and at $4, I suppose the risk is pretty low :)

It's obvious whoever designed that, did it so that they could do fun things with it; very flexible PIO and DMA with lots of neat corners; and mention of fun things like 8080 bus interfacing and the like.

> [PIO] allows you to add support for protocols you don't have hardware for.

PHY level support, yes. But nothing higher than that. You would still need to implement the protocol in software for the most part. So at 133Mhz, it’s probably fast enough to toggle a CAN transceiver correctly, but would have very little comprehension of bus arbitration or CRC or what makes a message valid (RTR, IDE, DLC, etc).

It’s very cool, but the example they used of making a simple waveform for the serial driven LEDs is more what they were going for.

That example is pretty much already taken care of with an SPI or PWM that runs off DMA though. You can easily make a waveform for those LEDs. I’ve never understood why the enthusiasts use bit banging and special hardware.

Didn't study Pico but I don't think PIO can interface CAN bus.

The physical layer uses differential wired-AND scheme where any device can pull it into dominant state but recessive state is possible only if no device is driving the bus. In most cases CAN requires a dedicated HW transceiver, I would be pleasantly surprised if Pico can pull it off without external components.

And a 120 ohm termination at the end of the bus.

This is not a required item. It is suggested that the termination is 120ohms, but depends entirely on the length of the bus and number of modules. You can have short runs of can with no transceiver and no termination.

CAN uses a dominant/recessive transmission method, similar to I2C. The termination resistors are absolutely required, as they are what drive the bus back to the recessive state.

Perhaps you were thinking of RS-485, which actively drives both bus states and therefore can get away with unterminated buses at low bitrates / short runs.

No, I was not thinking RJ485 where termination is optional.

You are forgetting that CAN can work at short distances without being a differential bus at all.

I mention this where I wrote “no transceiver AND no termination”.

In that case, it's not really CAN, it's more like CAN-tranceiver-control-signals. That may work, but would realistically be limited to only two devices, at which point it probably makes more sense to just use a protocol that's meant for short point-to-point links, like U[S]ART or SPI.

I think a better way to describe it that it’s CAN all the way up until the PHY. It’s still CAN protocol, you still need CAN modules, and really, nothing looks different at all to them.

You just lose out on the differential pair... but even that isn’t required when you look at fault tolerance CAN in single wire mode, or single wire CAN PHY transceiver options, as to the original point about termination, I can’t remember if Single Wire CAN is terminated in a loop or pulled up or down, but I promise it’s not 120ohm termination like differential CAN is.

Imo, safer to say that CAN is a protocol that can take many physical forms, and one of them is direct A to B modules with no termination.

Yes. You could do all-point-to-point CAN by or-ing all of the CAN-TX logic-level outputs, perhaps in an inverted tree, and then fanning out the global OR result to all CAN-TX logic-level inputs. Or, at short distances, just use wired-or at logic levels.

Single resistor can easily be added yourself. It doesn't have to be inside the transceiver, just close enough to end of cable. Bigger issue is the arbitration feedback as others noted.

Agreed. However, going from zero external parts to one is a big step in terms of easy experience and sharing of code/projects.

Arduino “took off” because it was easy and standardized. You and I could probably lay hands on a 120R today, but fewer than 0.01% of the population could without ordering something (at which point you could just as well order an MCP2515 module).

It’s a “what’s in my hand right now?” hurdle not an “it’s technically advanced” hurdle that makes 0 external parts such a selling point.

Yes. Did you notice where I wrote ”fast enough to toggle a CAN transceiver”.

The point is the PIO may be great at wiggling pins, but that doesn’t mean you can “support hardware protocols” you don’t have peripherals for. It means it gets you a pin wiggler, and the rest of the protocol would have to be software.

It's a game-changer in the hobbyist marine-electronics world. The marine electronics field is littered with various weird proprietary protocols that are _almost_ the same as open standards in other industries, but not quite. Examples include:

- NMEA0183, which is electrically RS-422 (similar to the ubiquitous RS-232, but only sometimes)

- NMEA2000, which is basically CAN

- Seatalk, which looks like NMEA0183 but is electrically inverted (1 is 0 and vice versa) and also uses weird byte lengths (9-bit?)

- Seatalk-ng, which is basically NMEA2000 with a few more message types

A $4 device that can translate arbitrary weird PHY protocols into a bitstream on a USB port is awesome in this world.

I am beyond skeptical this will be adequate for NMEA/CAN for the very reason myself and others explain in the rest of the thread.

This will get you wiggling output pins, not a replacement for dedicated protocol hardware or a actual programmable logic.

I think CAN is the special case here, since it more or less requires hard real time feedback within a bit cell. Almost all of the other weird protocols don't do that, so you can have the simple scan in/out handling the phy like you said and are no longer dedicating a full core 80% of your time to bit twiddling.

That’s fair enough. CAN is pretty complex. But still, I’m seeing a lot of ability to mimic waveforms being passed off as “custom hardware protocols”. It’s a cool peripheral, but IDK about any type of “game changer”.

If we look at Cypress’s PSOC, that’s real FPGA fabric on their micros and it’s barely capable of making some hardware protocols. I’m pretty sure there isn’t enough there for CAN going back to that example.