Input is never simple, but this is about as simple as it gets. This is an extract from a recent book in the I Programmer Library, all about the Pico/W in C.

Programming the Raspberry Pi Pico In C

By Harry Fairhead

Buy from Amazon.

Contents

• Preface
• Chapter 1 The Raspberry Pi Pico – Before We Begin
• Chapter 2 Getting Started
• Chapter 3 Getting Started With The GPIO
• Chapter 4 Simple Output
• Chapter 5 Some Electronics
• Chapter 6 Simple Input
      Extract:   GPIO Input ***NEW!
• Chapter 7 Advanced Input – Events and Interrupts
• Chapter 8 Pulse Width Modulation
      Extract: Basic PWM
• Chapter 9 Controlling Motors And Servos
• Chapter 10 Getting Started With The SPI Bus
• Chapter 11 A-To-D and The SPI Bus
• Chapter 12 Using The I2C Bus
• Chapter 13 Using The PIO
      Extract: A 1-Wire PIO Program  
• Chapter 14 The DHT22 Sensor Implementing A Custom Protocol
• Chapter 15 The 1‑Wire Bus And The DS1820
• Chapter 16 The Serial Port
• Chapter 17 Using the Pico W
     Extract: Simple Web Client
     Extract:A Better Connect
• Chapter 18 The Pico/W In C: Direct To Hardware 

Extra: Adding WiFi To The Pico 2

<ASIN:1871962803>

<ASIN:187196279X>

Simple Input

There is no doubt that input is more difficult than output. When you need to drive a line high or low you are in command of when it happens, but input is in the hands of the outside world. If your program isn't ready to read the input, or if it reads it at the wrong time, then things just don't work. What is worse, you have no idea what your program is doing relative to the event you are trying to capture. Welcome to the world of input.

In this chapter we look at the simplest approach to input – the polling loop. This may be simple, but it is a good way to approach many tasks. In Chapter 8 we look at more sophisticated alternatives – events and interrupts.

GPIO Input

GPIO input is a much more difficult problem than output from the point of view of measurement and verification. For output at least you can see the change in the signal on a logic analyzer and know the exact time that it occurred. This makes it possible to track down timing problems and fine tune things with good accuracy. 

Input on the other hand is "silent" and unobservable. When did you read in the status of the line? Usually the timing of the read is with respect to some other action that the device has taken. For example, you read the input line 20 µs after setting the output line high. But how do you know when the input line changed state during that 20 microseconds? The simple answer is in most cases you don’t.

In some applications the times are long and/or unimportant but in some they are critical and so we need some strategies for monitoring and controlling read events. The usual rule of thumb is to assume that it takes as long to read a GPIO line as it does to set it. This means we can use the delay mechanisms that we looked at with regard to output for input as well. 

One common and very useful trick when you are trying to get the timing of input correct is to substitute an output command to a spare GPIO line and monitor it with a logic analyzer. Place the output instruction just before the input instruction and where you see the line change on the logic analyzer should be close to the time that the input would be read in the unmodified program. You can use this to debug and fine tune and then remove the output statement.