I find this much more readable than KCL[0], but I also understand the ultimate goals of the two are probably a bit different.

[0]: https://zoo.dev/docs/kcl-samples/pillow-block-bearing

That's why I run my server on 7100 chips made for me by Sam Zeloof in his garage on a software stack hand coded by me, on copper I ran personally to everyone's house.

You are joking but working on making decentralization more viable would indeed be more healthy than throwing hands up and accepting Cloudflare as the only option.

But that bears no relation to what happened in the video.

>As I understand it, this is sort of simulating what it would be like to capture this, by recreating the laser pulse and capturing different phases of it each time, then assembling them; so what is represented in the final composite is not a single pulse of the laser beam.

It is not different phases, but it is a composite! On his second channel he describes the process[0]. Basically, it's a photomultiplier tube (PMT) attached to a precise motion control rig and a 2B sample/second oscilloscope. So he ends up capturing the actual signal from the PMT over that timespan at a resolution of 2B samples/s, and then repeating the experiment for the next pixel over. Then after some DSP and mosaicing, you get the video.

>It seems like if you could measure the pulse's propagation in one direction, and the other (as measured by when it scatters of the smoke at various positions in both directions), this seems like it would get around it?

The point here isn't to measure the speed of light, and my general response when someone asks "can I get around physics with this trick" by answer is no. But I'd be lying if I said I totally understood your question.

[0] https://www.youtube.com/watch?v=-KOFbvW2A-o

I remember programming in Forth on my Palm Pilot, as there was a Forth interpreter for it.

How many years were you in kindergarten?

Some days it feels like I never escaped.

And yet there is clearly a market for easy-to-program MCUs for hobby and educational purposes.

I would argue the RP2040/2350 fills that niche. Cheap, available, easy to program, flexible peripherals, fast enough for many projects, good documentation, and good community support.

RPi's toolchain situation is awful for beginners/hobbyists. CMake and non-manifest-versioned toolchains are a huge barrier to entry. I'd love to use the hardware but have given up multiple times because I'd rather spend my time writing code than wrestling with toolchain setup. And they won't support platformio which could make things massively easier for beginners to set up.

I've never used their toolchain, I use Rust on the RP2040 and it's a breeze to set up.

But yeah there's also CircuitPython where you literally drag and drop a firmware blob onto the volume that shows up when plugging in an RP2040 board, and then you're just editing a Python-esque script to do stuff. Not sure what could be easier when it comes to starting with embedded stuff. You can even use the Arduino IDE with RP2040 boards if you like.

https://learn.adafruit.com/getting-started-with-raspberry-pi...

While I've written Rpi Pico applications in C++, IMO CircuitPython/MicroPython is a far better environment for that processor.

I'm using the RP2040s with FreeRTOS for a hobby project. I think the Pico probe is a much better debugging story than buying a Blackmagic (or if you got the dough, a Segger), to debug the "modern" Arduinos. I have one of the Atmel programmers for the Uno R3/2560/Mega boards and that's nice.

But for people getting started, the ability to just plug in an Uno R3 and stack a motor controller shield on it, is pretty attractive. I like the Cytron break out boards for the Picos, but I still think the path from opening the box to working thing is still easiest with Arduino.

Once you know what you're doing, (and maybe that's when you realize you need a debugger), you move on to something else. And with the Pico I can spend the $800 on an O-scope instead of the Segger.

As a hobby user, RP2040/2350 seems like the best to for beginners. As long as it's not battery powered.

Arduino was around long before RP2040, therefore RP2040 shouldn’t exist because the niche was already filled.

I'll remember that next time I'm developing an FPGA keyboard for my Gateway computer.

Many of the latest gaming mobos still have PS/2 exactly because of the low latency.

The FPGA is a Lattice LFE5U-25F, about $20

https://www.digikey.com/en/products/detail/lattice-semicondu...

Or about $5 on LCSC.

Thank you for surfacing that info, was wondering if I seriously had to go start opening files to find out.

Btw, that's a 256 pin BGA part, grandad's Weller cannot help.

Curious why they didn't use the LFE5U-12F, I can't imagine this project maxing out even the smallest modern FPGA.

Even better. The LFE5U-12F is just a 25F in terms of resources you can full utilize it with nextpnr. I expect lattice didn't find it economical to have a truly separate production process for it.