What gets in the way of your Raspberry Pi project?

People will just spend that saved time on things like Wordle

Jan Cumps said:

This just requires a few iterations

That's true - once it's set up, simply duplicating an SD card is pretty much all that's needed (and setting computer name, I suppose).

And you made a good point about boot time - in most applications that happens once and then it just keeps running. My server hasn't been rebooted in months.

I don't work with Linux often enough to get good at it and retain the knowledge.  So when I do, it seems like I'm constantly having to search for something on the internet that I know can be done, but can't remember or don't know how to do it.  I also find it easier to work with timers, GPIO, I2C, and SPI on microcontrollers.  That is partly familiarity but also because it is a main function of microcontrollers but seems almost an afterthought on the Raspberry Pi (not the Pico).  As a result, the libraries aren't as good and the header is awkward as others have pointed out.  Simpler devices like microcontrollers seem to better suit my simple mind, so I don't use the Pi unless a real OS is really needed.

I agree with the comments from others that the RPi ecosystem has evolved to the point that it's generally very easy to get up and running with a project and for most projects requiring an SBC the RPi is my go to board.  I have had issues because of the evolution however.  I'm just the typical old dog that likes to reuse stuff as much as I can to save development time - e.g. configuration files and code.  I recently ran into problems with both hardware and software due to changes (improvements).  

The first was not being able to use old firmware moving from an RPi Zero W to an RPi Zero 2 W.  That should have been an obvious one since the processor chip changed and the new board needs a new device tree.  That just means that you can't reuse SD card images (either your own or from others).  I ran into this problem with the MotionEyeOS.

The second was due to the change to the Bullseye OS removing the RaspiCam functionality and replacing it with libcamera.  That made a lot of stuff that I use not work, so in some cases I have not changed to Bullseye from Buster.  Not sure why they couldn't have left that functionality in - I guess because they don't want to use anything that isn't open source.

This is just the cost of improvement, so I'm not complaining - but these are the type of things that do slow me down...

I have a similar experience but with MS Windows. At one point I could navigate select menus to accomplish tasks but upgrades in the OS have removed those avenues and I'm left with only knowing how it was done in the past and not now. I have double difficulty trying to use a Mac.

I think the largest barrier for me is the fear/interest/time on learning something new. Taking Jan's roadtest as an example, I would have no problem using a Pi hat where the software is supplied. But, if I wanted to make my own custom Hat and develop my own software I have no idea where I would even start.

Both of the new RPI products the zero 2w & Pico are pretty amazing for endless number of projects.

Start here on element14 : )

Here's an approach. Firstly, there's only about 4 types of interface available on the PI, so you'd design your circuit as normal, and attach to the interfaces (3.3V logic levels):
(a) GPIO
(b) I2C
(c) SPI
(d) UART

Interface (d) I'd avoid where possible because it comes in handy as an emergency serial console into Linux.

Next step, is to decide on programming language (you could even combine different languages). If you want good speed and similarity to Arduino, then a good choice is C. Otherwise, Python. I'll discuss the C option only here:

For the different interface types (a) to (d), if it were me, then I'd follow these paths:

(a) Use WiringPi library - it used digitalRead etc just like Arduino
(b) I'd use my I2C library, I've not found anything simpler, and although there may be bugs, it has worked so far at every I2C chip I've tried, and it is quite flexible. The I2C library is here (you just need the files called i2cfunc.c and i2cfunc.h) 
Note that if you are using it with Pi 4, then the definition for I2C_BASE needs changing in the header file, from 0x3f804000 to 0xfe804000 - this could be done in code automatically depending on Pi type, I just have not got around to implementing it. It's low-pri for me so I have not done it.
(c) For SPI, examine a file called spidev.c (google'able) and copy that, it works well : )
(d) I don't use UART for reason mentioned : )

Note that for (b) and (c), I've not discussed any specific chips like temperature, I/O expanders, etc. That's because generally it is easy to see from the chip datasheet how to control it, and then I'll write my own code. Especially for chips that just need one-way communication, it can be extremely trivial. For instance, with the LCD code here (which isn't for the Pi, but the principle is the same), writing to an LCD screen is as simple as:

void
lcd_print(char* str)
{
    char data[2];
    data[0]=0x40;
    while(*str != '\0')
    {
        data[1]=*str++;
        i2c_write(data, 2);
    }
}

It's not worth finding an I2C library for an LCD when it is this trivial.

I've not addressed the EEPROM that HAT boards used, that should be documented on the raspberrypi.org website, but it's not essential for any custom board you create. It is not of much importance for projects where you know what boards are plugged in.

Regarding power, the Pi board has 5V and 3.3V outputs on the header pins, so you could use those (within reason) or power from an external supply.

You can follow along it 'll all be out there:

Github daqhats_scpi_service

I have been, and enjoying learning from them:). They are great blogs as usual, keep it up!

You have me convinced this is a skill I need to add to my repertoire. In the limited time I have played with my pi zero 2w, I have been impressed its a pretty capable device (essentially a Pi3) and I could run it off an ordinary dollar store 5V/1A powerbank.

I tired using the hardware pwm output using the pigs gpio library and it worked well enough. As a noobie to PI hardware is pigs the new way of gpio or just another I wasn't really sure? The piscope is pretty cool you can see any of the GPIO pin states even if they are being driven by a hardware peripheral.

Looking to the future I assume the PI designers are cooking up a new chip to replace the broadcom SoC. I hope they target something like the zero2w but maybe a little lower price and a RP2040 in shared memory on die too. I don't personally need a 16 core raspi for $200, though I'm sure there are millions who would love that. Have to wait and see....