What gets in the way of your Raspberry Pi project?

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.

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 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....

I've used three different libaries to access the Pi's GPIO's over the years. I first started with RPi.gpio, then gpiozero and most recently pigpio. I liked gpiozero but the latest version referenced pigpio as the ideal solution for supporting servo's. I would prefer to one-stop-shop and not have to jump between different libraries to accomplish a task. My programming skills are not strong so learning and relearning are taxing.

Your programming skills are much stronger than mine. You might find more benefit in pigpio than the others. The library is strongly invested in remote capabilities. That is something nice to have in your toolbox.

Thanks for the kind words and advise. The pigpio looks like a pretty powerful library, as it will bitbang any gpio pin via dma to create a pwm output. Or will send pin change notification via a linux file pipe.

I've not used that library or hardware PWM on the Pi so far. One thing worth checking with any library is if they are using hardware register accesses for GPIO, or Linux device files (/dev), because the latter is slow. Sometimes I'll write code and attach hardware differently with Pi compared to if I were using a microcontroller, simply to work around issues, or to accommodate the level of real-timeness that is practical with Linux in user-space code. For instance, I can reduce the number of inputs I poll, by using a single pin with all inputs OR'd, that way the code is speedy until I need to read a specific pin (for example). With a microcontroller that would be less necessary although it can still be handy. Also, I/O expanders can be handy since I2C or SPI is a very solved problem for any Linux SBC, and will run fast from your user-space code since it uses the I2C/SPI device drivers.