> How different is it from programming the GPIO on the Raspberry Pi?

Conceptually they are they same (just flipping GPIO bits), but practically you can do things with one which you can't do with the other.

There is no operating system on an Arduino, like there is on a Pi. This means you can do much more "real-time" things on an Arduino, like bit-bang a serial port. This is hard to do on a platform with an OS, because the OS process scheduler might pull your program off of the CPU for a few milliseconds. If you need to do something to those pins 1,000 times per second or more, you're out of luck.

If you've ever seen a large scrolling LED marquee sign which appeared to have an occasional "stutter" in the scrolling, that's most likely because it was being controlled by an operating system.

I kinda disagree with you here. You can do bare metal (no OS) and real time (on bare metal or with an RTOS) on a Pi no problem.

The difference between the two has to do with resources, architecture, and peripherals. Arduino is a low power, low cost, low memory, low speed 8-16bit microcontroller. A raspberry pi is a complete 64 bit computing system with 1-2GB of RAM and the peripherals you'd expect on most desktops. Arduino use Atmega chips while Pis use ARM cores. You need to program in a language supported by gcc for Arduino, but RPis can use the LLVM infrastructure.

But on a pi, how accurate is the CPU and gpio speed? On an Arduino mega it's guaranteed to be 68.5ns give or take a tiny amount because that's how long an instruction takes for gpio bitbanging registers. This makes it possible to interface with hardware that requires this precision timing. On a pi even if you're at 700mhz constant clock, caching supposedly will mess up your timings for gpio. On top of that I haven't seen much in what the lowest stable delay is for the pi gpio.

You have me curious; how do I do baremetal on the Raspberry Pi? Which RTOS do you use?

They've got a whole stickied thread on the forums about it:

https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=7226...

And I think I was totally mistaken on RTOS's, I could have sworn there was a port of FreeRTOS for the RPi but it looks like that isn't really floating around.

RTAI &/or Xenomai are RTOSes based on Linux, both support ARM. Xenomai has support for the Pi Zero, Pi 2 model B, and Pi 3 Model B[1]. I've never used it, but it's probably easier than porting another OS from scratch.

[1] https://gitlab.denx.de/Xenomai/xenomai/wikis/Supported_Hardw...

Arduino is for quick validation and prototyping. Pick up an Arduino nano for couple of $ and try it out. The programming language is easy to pick up and will get you a quick app(though basic) app running. It has made electronics accessible to a lot of people. Raspi opens a different world as you have a bunch of other peripherals available for you already builtin, without having to get "shields". There is a large ecosystem of shields available in the arduino world that make prototyping easy. So it may eventually boil down to what you want to do and how much effort you are willing to put in for the project. In my opinion, arduino are good for initial protoyping/weekend projects, and microcontrollers/embedded linux are good for engineering projects and will set you up for a long haul in systems engineering.

The Arduino IDE is fine to begin with. Eventually you may want to grow into dealing with more of the family of Atmel chips, tiny85s can be fun for miniature projects for example. You'll start to outgrow the Arduino libraries at some point though and may want to switch to the Atmel compilers directly.

For resources the Arduino.cc forum and tutorials are a great place to start. Should be able to find some project ideas as well.

That's an excellent question; one to which I would also like to know (more) about. So far I've thrown a bunch of money at it to just buy random pieces and cobble them together in spare time and see what happens.

So I have raspberry pis; I have arduinos. I've done some simple programming for both, to read from sensors. Water sensors and thermal sensors and buttons and sound pins all on breadboards were fun.

I figured I was ready for the next step: soldering together a kit. So I soldered together an ethernet kit for the arduino. That project fell flat: the arduino powered up while the ethernet shield did not; the arduino reported that it didn't even "find" the ethernet controller even though it was piggy-backed onto it. Usually when you plug in the RJ45 jack to a NIC you at least get the lights on the RJ45 port to light up. But no dice for me here either. And I have no idea how to debug that problem.

Sounds like you need to triage your circuit. Every trace should be connected to a certain number of other points. Turn off power and use a multimeter on the continuity setting to verify each trace connects to where it's supposed to.

After that, turn on power and verify that each trace has the correct voltage on it.

The two steps above should let you determine which part is failing.

If you have a local makerspace, take it down there and see if they know of anyone who would be willing and able to help you.

I have several of each, but I have to say I tend to prefer an RPi Zero W to any of the alternatives. Right now I have three running, one logging air quality and other sensor data, one acting as a grandfather clock, driving a servo that strikes a long chime on the hour (and is silent at night, when I am at work, etc.), and another which is making calls to a couple of APIs when someone presses my doorbell. The last one likely would be simpler on an Arduino (well, really an ESP8266 like a Wemos D1 mini, say); the other two benefit from having cron, ntp, etc. none of which is as easy on Arduino.

There's a learning curve, but it's not that bad. The biggest constraint is that you are in a very limited "world" in Arduino land, it's very systems programm-y. You don't have a proper OS, you don't have a filesystem. You don't have near unlimited resources. Depending on the chip you use you may have a small amount of RAM. Also, arduino enforces a basic structure on you of having setup() and loop() functions. Once you get used to it it's fine, but it takes some experience to get the hang of it fully.