New Pico2

People loved to laugh at that over many, many years. I’m not sure how much paper we’re producing nowadays compared to, say, 30 years ago, but as a proportion of the total amount of data we are typically dealing with in our everyday lives, I think paper now accounts for maybe something on the order of 1%.

This is why you didn’t have the sequence go up in steps of 1, but use larger steps, like say 100. That made it easier to insert new cards with in-between numbers.

VHDL, ULAs and FPGAs happened to it.

Oh we've pretty much achieved it by now, more than forty years on from that sign.

That's how all chip design works today. Except we write code, not schematics. Code - VHDL/(System)Verilog, higher level hardware description langauges like Bluespec and Chisel - scale better than schematics.

The compiler takes that and produces a netlist of 'gates' (often more complicated things than regular logic gates, eg lookup tables, adders, memory elements and such) and the place and route tool decides how to pack them onto the chip (either laying down transistor shapes for an ASIC or fititng to existing structures as on FPGAs) and wire them up.

Theo

Its been hard, but by dint of scanning almost every bit of paper I get, I am nearly there.

That definitely helps. But certain operations, e.g. re-factoring code, involve moving large blocks of code around. That's when things break down. Oh well, there's still the diagonal strip along the top of the deck - although that too gets messed up when moving large blocks of code.

Still, the real problem is not the paper, but the stuff written on it. And without paper slowing things down, bureaucratic bloat is free to grow faster than ever.

I don't think they know much about how to do ADCs yet.

Have a look at the performance of the RP2040 ADC - it is awful!

It's tough to put a good 12-bit ADC on a 70 cent dual-core CPU chip. The silicon process, the thermals, the ground loop and noise environment, are all wrong.

The 2040 ADC has chunks of missing codes. It's probably usable as a

We use the ADCs in FPGAs and some other ARM processors, for crude things like checking power supplies. Not for sellable instrumentation.

Hi All, Anyone doing stuff with both cores on the Pico? I just grabbed the Pico extension for Visual Code to poke it & see what it does, had an interesting first adventure. It does not seem to know anything about setting up a muticore project, so I had it generate a simple project that it did understand, just "example" level stuff, replaced the generated .c file with my own little test case...#include "pico/multicore.h" is not findable. So, looking at the generated compiler commands file, I added in a -I/home/.../include explicitly to see what happens. No change, still not found. hmm. Is there some magic caching going on here? Next, I added a -D for the multicore library, still no change. Noticed that I had forgotten to add the pico_multicore lib to the CMakeLists.txt file and behold it builds now, no missing .h files. So my "solution" isn't really good for anything more than a casual kicking the tires thing, and I'd really appreciate it if sommeone could guide me a little on how to do this "right". Do I just have to wait for the VSCode extension to get smarter, or is there a better way to get those .h & .lib paths known to the compiler? Thanks, Bill

That’s why you draw a diagonal line across the top of the deck/tray with a magic marker! And why you use different color markers as significant revisions are made. ;-)

Am 13.08.24 um 17:55 schrieb John Larkin:

I could not find a CPU chip manual in an hour for my new 8GB RP5 that allowed me to use SPI, so I shelved it and went with the old BBB and its PRU. So far about documentation excellence.

Gerhard

Try a media optimised OS such as Kodi, rather than a general purpose distro if you want to use a Pi as a media player.

Don't confuse the availability of a larger power supply with the Pi 5 taking more power - it's not much different to the Pi 4. However, as you

No, it's a new SOC which is about 3x faster than a Pi 4, and can use NVME SSDs and other PCIe devices.

---druck

Presumably that was only to activate the decoder hardware. Otherwise FFmpeg, VLC etc could play it just fine, just with a bit more CPU usage.

No, that is true, and my Pi 4 can just handle two USB SSD drives. JUST. Not three though.

BUT even doing sod all it still draws enough to get its temperature up into the 50's°C. As do the drives into the 40s°C

Which the Pi zero also does

I think that as a desktop machine Pi 4s and 5s power consumption is approaching that of a good intel chipset *for equivalent performance*.

(these temps may be of interest)

PI 4B (headless) equipped with 2 SSD ======================= CPU temp=52.1'C Disk 1= 40°C Disk 2 =44°C

PI zero 1 (headless) =========== CPU temp=43.9'C

PI zero 2 (headless) =========== CPU temp=39.5'C

The rise of ARM caused Intel and AMD to pay a *lot* more attention to power consumption which has indeed resulted in the gap closing especially at desktop levels of performance.

It was to pay the patent licence fees for using the hardware decoder. FOSS software decode got around them by not having anyone the patent holders could meaningfully sue.

Since that was 12 years ago, perhaps the patents have now expired?

Theo

Well MIPs per mW is where its at these days as parallelism can sorta increase MIPS to whatever level you want.

Funnily enuff, the race to more MIPS is likely to drive adoption of nuclear power more than any other factor...

I don't see data centres 'throttling back' servers after sunset, or on calm days...