This next step is probably the most difficult part of the entire process because there is no one-size-fits-all method for getting the information and every board is different. So rather than concentrating on a specific set of steps, this guide will be discussing various strategies for acquiring the information. It also depends on which GPIO library you went with.

Strategies can range from looking at the microprocessor data sheet to finding similar code that already has the pins figured out, to having the GPIO library just tell you. Another strategy is simple trial and error by just setting a line and seeing if it changes the value. Often times though, it is a combination of different strategies combined together.

It's entirely possible that you may not need to create a chip file. If a chip file for your board already exists or one that is close enough exists, you should definitely use that one. If you do find that you need to create one, it's probably best to see what already exists and make a copy of that file to use as a starting point. When you make a copy, you will want to copy the entire folder.

If you followed the instruction in the software setup, you should have the Adafruit_Blinka folder in your home directory. Inside of there you'll want to navigate to src/adafruit_blinka/microcontroller which is where all of the chip files are located, sorted by manufacturer.

In the case of the Pine64, the AllWinner H3 chip is already set up, so I'll make a copy of the h3 folder and leave it under the allwinner folder. The new folder is called a64.

If you create a new folder from scratch, be sure that __init__.py exists inside the folder or PyPI won't install it along with Blinka.

At a minimum, the folder should contain an __init__.py and pin.py file. The init file will most likely be empty or only contain a comment. The pin.py file will contain all of the Chip pin information. Here's what the h3 pin.py file looks like:

Temporarily unable to load content:

Checking with the GPIO library

You'll start with the easiest strategy, which is to check with the GPIO library. The first thing you want to do is map out the chip. You will start off by seeing how many GPIO chips are detected. There should be at least one, but there may be a few. To do this you type:

  • sudo gpiodetect

This tells us that there are 3 GPIO chips on the Pine64 and the number of lines that each controls. It's likely the bulk of them are on gpiochip1.

Next you will look for some more detailed information by typing:

  • sudo gpioinfo

In this case, most of the lines are unnamed. In some chips, they may actually have the pin numbers which makes things much easier.

For the Pine64, since there are multiple GPIO chips and there are only 32 lines associated with the first chip. This means the bulk of the lines will most likely be associated with the GPIO chip 1.

For the H3 chip, only an integer is passed, which means that it associates all the pin numbers with GPIO chip 0. However, for the A64 chip, it will likely need specified which chip each of the lines is on, so instead of specifying something like:

PC0 = Pin(64)

If line 64 was based off gpiochip1, it would need to use a tuple instead of an integer and specify it more like:

PC0 = Pin((1, 64))

How do you know which line is associated with which GPIO chip? That involves a little bit of guess work. You can see there are 32 lines in the first GPIO chip and 256 lines in the second. The third has only 2 lines, so it most likely will not be used.

Looking Up a Pinout Diagram

Sometimes looking up a Pinout diagram can help yield clues. A web search for Pine64 Pinout, yielded this pinout diagram available at http://joey.hazlett.us/pine64/pine64_pins.html, which is very helpful:

According to the diagram, it appears PC0 is using GPIO 64, which matches what is in the h3 pin mappings.

Checking Data Sheets

The next thing you would do is try and find a data sheet with a web search. The Pine A64 uses the AllWinner A64 chip, which you can figure by doing some web searches and doing some reading. For this chip, there is a data sheet available here.

The important part of this data sheet is section 4 titled Pin Characteristics. It shows us the Pin Names grouped by GPIO blocks starting with GPIO B. You may notice that these Pin names match those in the Pinout Diagram.

Testing a physical GPIO Pin

Just to help out with figuring out the layout, you can test to see if setting a libgpiod line on a chip corresponds to the pin you think it should correspond to. For this example,  look at pin PC0, which appears to be physically connected to Pin 19 of the 40-pin Pi header according to the Pinout diagram. The next thing to do is to connect an LED up to it to test turning it off and on:

As mentioned earlier, this pin uses line 64 and is most likely connected to gpiochip1 since that's the only GPIO chip with enough lines. To test, you can type in the gpioset command like:

  • sudo gpioset gpiochip1 64=1

If everything is correct, the LED should turn on, which confirms the hypothesis. To try out the same thing with pins such as PB1, which says GPIO 33 in the pin diagram, it would also most likely be on gpiochip1, and after testing, this is in fact the case.

Interpolating the Numbering

Now you may notice that according to the Pinout Diagram, it says pins such as PL10 are using GPIO 362 and you can see that none of the GPIO chips have that many lines, so it looks like taking a different approach is in order. There was no GPIO block A, so what if gpiochip0 controls GPIO block L onwards? The next thing to try is connecting PL10, which appears to be connected to Physical Pin 7 up to the LED.

So based on the hypothesis that PL10 is using gpiochip0 and line 10, I'll try typing the command:

  • sudo gpioset gpiochip0 10=1

Unfortunately, it didn't turn on the LED. However, after digging through some documentation a bit further, I found that PL10 does in fact correspond to GPIO 10 on gpiochip1. According to the Pinout, 362 refers to the GPIO pin number when accessing the pin via SysFs, which is an old way of accessing the pins and is not terribly efficient. When I set the pin via SysFs, it also did not light up the LED, but when running the gpioset command again, this time I got the error message:

gpioset: error setting the GPIO line values: Device or resource busy

The LED isn't turning on either way, which means 3 of the pins on the Pi 2 header may not be able to run, but this is acceptable and perhaps this can be revisited in the future. The important thing is the pin mapping has been verified.

For the rest of the GPIO pins, it appears that all of the pins from GPIO B through GPIO H are fine and definitely running off gpiochip1. The next thing is to take a look at a few known values and see if a pattern emerges.

According to the pinout diagram, PC0, PC1, and PC2 correspond to 64, 65, and 66 respectively, so it appears they are in order. PC5 is 69 and PC9 is 73. Thus it can be inferred PC6 through PC8 are likely 70 through 72.

Ok, next look at the pins starting with PB0, which appears to correspond to 32. According to the data sheet, there are only 10 pins in GPIO block B, so while 42 through 63 would normally be in this block, they are not used and can be ignored. In fact, based on the note at the bottom of the Pinout, you can see that every GPIO block has 32 numbers allocated to it which makes figuring out the exact numbers much easier.

Finishing up the GPIO Pins

If there are any GPIO pins that don't belong, go ahead and remove those from the chip.py file. Add only the pins that are going to be used. If the chip.py file already existed from another board, add any new pins that your board uses that the other board may not have used.

Pin Aliases

If you need any aliases, after defining a pin, just refer to the already defined pin rather than making a new pin. For instance, if you wanted to create Pin PC0 and also have the name SPI0_MOSI, you would do something like the following:

PC0 = Pin((1, 64))
SPI0_MOSI = PC0

I2C, SPI and UART Ports

You will add any I2C, SPI, and UART pins in a later section and address both the chip and board files at the same time.

Additional Resources

This guide was first published on Apr 01, 2020. It was last updated on Jun 17, 2024.

This page (Adding the Chip File) was last updated on Jun 17, 2024.

Text editor powered by tinymce.