[KaiserPro]

> The Intel N100 is incredibly capable for the price.

Hard agree, I have one and I love it. Its currently doing the VM work of what a £10k server did in 2012.

But if I want GPIO, and or battery powered things with linux, then the pi is the way forward still.

Anything else, and a pico/esp32 will do well.

[jsheard]

TBH for projects that need GPIO I would be inclined to use an RP2040 or similar hooked up to USB, then any machine can be used as the host. That's pretty much how the Pi5 works anyway, the GPIOs are driven by the RP1 southbridge which is more or less an overgrown RP2040.

[Aurornis]

> TBH for projects that need GPIO I would be inclined to use an RP2040 or similar hooked up to USB, then any machine can be used as the host

Two separate platforms connected over USB is substantially more complicated, expensive, power hungry, and consumes a lot more space.

The value prop of SBCs is that they're compact and you can do low-level work in a single package. Connecting an RP2040 to a PC and writing software for both is the opposite end of the complexity spectrum.

[moffkalast]

Yeah but why aren't there more boards with a built in coprocessor like that given how cheap they are now? Iirc only Lattepanda and the Pi Foundation make these sort of boards, and the former is overpriced beyond any common sense.

[jsheard]

Keeping the GPIO interface separate does have its advantages, if you accidentally explode a GPIO pin on an external RP2040 board then you've lost a couple of dollars instead of an entire >$50 SBC.

It doesn't have to take up much space either: https://www.waveshare.com/product/rp2040-one.htm

[moffkalast]

If USB is involved you can't really make a production ready system with it. At least they could put some proper ZH or whatever connectors for UART that don't unplug when you look at them wrong. That's one of the things they did right with the Pi 5 at least.

[varispeed]

What kind of GPIO you need? If you need slow (under 1MHz) you can easily slap some USB to GPIO device and Bob's your uncle.

[tombert]

Any reason you can't do GPIO with the ESP32? I've had pretty good luck with GPIO in NodeMCU.

[KaiserPro]

I do! as I said the pico/esp32/rp2040 are useful tools to have lying around. I'm currently using one to be a stepper controller for a project I'm doing now.

However the best thing about the Rpi GPIO stack is the support. If I google "how do I do x with y on pi" I will get lots of resources, along with the official docs (the rp2040 docs are great by the way) and a bunch of hardware that is mostly plug and play.

[tombert]

Yeah, fair; there's something nice about the fact that the Raspberry Pi is "just Linux"; it's not some attempt at an embedded version of POSIX.

You have the full Linux kernel and packages to play with, the GPIO stuff (if performance isn't a huge deal) can easily be controlled by simply writing to files, meaning that you can do quasi-embedded stuff in basically any language you want, or at least any language that has an ARM port to Linux, which is basically everything nowadays.

Still, I'm quite partial to the ESP32 with NodeMCU just because the power consumption is so ridiculously low and NodeMCU + Lua is pretty easy since it has full GC and gives you a node.js-style callbacks that I think are generally easier to work with than doing it myself in C. Most of my embedded projects have moved to the ESP32 as a result.

[Marsymars]

The top-end Alder-Lake-N N305 is good too! Double the threads, and probably a bit worse performance-per-dollar.

[graphe]

When do you use GPIO with Linux?

[KaiserPro]

Something with higher order processing requirements.

the rp2040w has wifi, micropython and a bunch of GPIO, all running at low hundreds of megs. Great for motor controllers and that sort of stuff. I use them a lot for the sort of things I would have used Pis for.

However thats because its python. If you want rust, or javascript, then the pi is probably still a good option (I know there are native ports, but they are not as common or easy. )

But if you want computer vision, or, can't be arsed with micro based programms, then pi is where its at.

The other type of application is home assistant. I have an N100 running HA in a VM. It would have been easier with all the home security stuff to have it running on a pi directly. (yes you can use esp32 as binary sensors, which is what I do, but its expensive to have things that aren't wifi.)

[colejohnson66]

The same things you'd use GPIO with Linux for on a Raspberry Pi: anything.

[graphe]

Anything is not a useful comment. When? I'm asking for a use case, I haven't seen anyone use them for a specific reason to use Linux. I'm asking about sensors and software that works together better than using it with an MCU

[ianburrell]

One example that I'm working on is GPS receiver and NTP server. Accuracy requires PPS signal through GPIO. It would be possible to wire up GPS receiver board to microcontroller. But still need server to run NTPd. Or could put GPS Hat on Raspberry Pi and have everything in one unit. It will run on the cheapest $35 Pi, or extra one in my case.

Another I have thought doing is ADS-B receiver mounted outside. It helps to put the receiver close to antenna so would put the SDR and Pi in enclosure, and power it from PoE. Microcontroller can't run the SDR. Micro PC is overkill and wouldn't work in enclosure. Doesn't use GPIO pins.

[graphe]

Very interesting, I haven't used gps but that definitely does need more power (or optimizations). Have you heard of this? https://hackerwarehouse.com/product/portapack-h2-for-hackrf-...

Linux would probably be very easy to built without needing firmware

[ssl-3]

I've used GPIO on a Raspberry Pi Zero W to talk with DS18B20 temperature sensors, along with an SDR attached with USB tuning in radio traffic and decoding AX.25 packets in software.

I've also used GPIO on a Raspberry PI Zero W to build a Stratum 1 NTP server with nearly spooky accuracy with the PPS line.

Both things worked very well. They were compact, performant, used an inconsequential amount of power, and were very inexpensive.

And both things were very easy for me to implement, largely due to the tremendous amount of software available in the Linux-ey ecosystem.

If I were trying to bodge an MCU into performing these tasks without involving Linux, I'd probably have never gotten either of them done.