Is the design of Raspberry Pi stored in a memory component?

[pairofstrings]

Hello. I have a following C programming language code that blinks an LED ON and OFF.

#include<bcm2835.h>
#define LED RPI_GPIO_P1_12

int main(int argc, char **argv)
{
    if(!bcm2835_init()) return 1;
    bcm2835_gpio_fsel(LED, BCM2835_GPIO_FSEL_OUTP);
    unsigned int delay(1000);
    while(1)
    {
     bcm2835_gpio_set(LED);
     bcm2835_delay(delay);
     bcm2835_gpio_clr(LED);
     bcm2835_delay(delay);
     }
}

I fetched the code from here.
The code blinks an LED ON and OFF at pin 12.
My question is, how does the program precisely locate pin 12 on the board and does not go astray and access some other pin mistakenly.
So, I have a question like this: Is the design of Raspberry Pi's architecture, pin locations, components on board are stored some where on the Raspberry Pi device itself? And in this case how does an LED blink correctly at pin 12 as per the program?

I intend to write custom library functions for Raspberry Pi.
I have downloaded bcm2835.c file and saw the code but cannot figure out how the above code makes a precise move to blink an LED at pin 12.

Thank you.

 

[FactChecker]

The second line defines LED to be set equal to RPI_GPIO_P1_12. That will be an address or index that the function bcm2835_gpio_set and others use to know which output device to manipulate. There will be some driver software that those functions use to know what to do at the lowest level. The driver software will be designed for that specific hardware. That is often just "poking" a 1 or 0 into a specific memory address.

 

[pairofstrings]

The second line defines LED to be set equal to RPI_GPIO_P1_12.

So, do you agree that RPI_GPIO_P1_12 is a address and is stored in a memory component of Raspberry Pi board where addresses of other Raspberry Pi's other components are also stored and is described in data sheet, so that I can make use of the address and create a library?

 

[Svein]

Do you agree that RPI_GPIO_P1_12 is stored in a memory component of Raspberry Pi board and is described in data sheet, so that I can make use of the address and create a library?

No - and yes. RPI_GPIO_P1_12 is defined in bcm2835.h (I do not know exactly what's in there, but all C programs rely on the header files handling all the dreary bits and pieces).

 

[pairofstrings]

If a program wants a device driver to drive the pin 12 to be ON and OFF then how does device driver knows that there is a something called pin 12 on board?

 

[Svein]

If a program wants a device driver to drive the pin 12 to be ON and OFF then how does device driver knows that there is a something called pin 12 on board?

There are several levels here.

1. You (the programmer) have to decide what pin the LED should be connected to.
   
2. You (the programmer) have to find out from the documentation what symbolic name that pin has and what function to use to manipulate the pin.
   
3. Finally you write the program, following the guidelines given and using the specified function to set the pin high or low.

Thus - there is no "driver" as such. You (the programmer) have to do everything. Yes, there are some basic functions, definitions and macros in the header file, but you must decide what to use and how to use it.

 

[pairofstrings]

You (the programmer) have to find out from the documentation what symbolic name that pin has and what function to use to manipulate the pin.

Why are symbolic names for pins maintained in documentation when I have to do everything?

 

[anorlunda]

I intend to write custom library functions for Raspberry Pi.

How will your custom library functions differ from the ones that already exist?

[/PLAIN]
Physical Addresses
The functions bcm2835_peri_read(), bcm2835_peri_write() and bcm2835_peri_set_bits() are low level peripheral register access functions. They are designed to use physical addresses as described in section 1.2.3 ARM physical addresses of the BCM2835 ARM Peripherals manual. Physical addresses range from 0x20000000 to 0x20FFFFFF for peripherals. The bus addresses for peripherals are set up to map onto the peripheral bus address range starting at 0x7E000000. Thus a peripheral advertised in the manual at bus address 0x7Ennnnnn is available at physical address 0x20nnnnnn.

On RPI 2, the peripheral addresses are different and the bcm2835 library gets them from reading /proc/device-tree/soc/ranges. This is only availble with recent versions of the kernel on RPI 2.

After initialisation, the base address of the various peripheral registers are available with the following externals: bcm2835_gpio bcm2835_pwm bcm2835_clk bcm2835_pads bcm2835_spio0 bcm2835_st bcm2835_bsc0 bcm2835_bsc1

 

[pairofstrings]

How will your custom library functions differ from the ones that already exist?

I am a learner these days, I am told to have the capability to even create custom library functions.

Why are symbolic names for pins maintained in documentation when I have to do everything?

My question is: Are symbolic names of pins hard-coded in a memory component of Raspberry Pi? If yes, what else is hard-coded to build functions?

 

[anorlunda]

Hard coded constants mere"y reflect the hard wired nature of the underlying circuits. The manual "BCM2835 ARM Peripherals manual" should have the answers you seek.

 

[Svein]

My question is: Are symbolic names of pins hard-coded in a memory component of Raspberry Pi? If yes, what else is hard-coded to build functions?

No!

You can do everything out from port addresses, pin numbers and so on. Somebody has taken the trouble to give the ports and pins symbolic addresses. If you do not want to use them, feel free to do it your way.

 

[FactChecker]

You can do everything out from port addresses, pin numbers and so on. Somebody has taken the trouble to give the ports and pins symbolic addresses. If you do not want to use them, feel free to do it your way.

I agree with this. The pin is a "device" that is a very simple to control. If you want to, you can probably get or make a "memory map" that tells you what address to "poke" a 0/1 value into that will set the pin output voltage low or high.

But this is a complicated road to go down. Most device drivers are much more complicated than a pin. Unless you want to learn about programming device drivers, it is better to use them as tools that others have provided. You do that as you have done in your example code, by including the header files (bcm2835.h) that define the constants (RPI_GPIO_P1_12) and functions (bcm2835_gpio_set) they have provided.

 

[pairofstrings]

Somebody has taken the trouble to give the ports and pins symbolic addresses.

So, where are these symbolic addresses of ports and pins present on the Raspberry Pi board?

#define LED RPI_GPIO_P1_12

In the above line of code, how does the compiler know that there is something called "RPI_GPIO_P1_12" on the board?
How does the header file "bcm2835.h" know that there is a "RPI_GPIO_P1_12" on the Raspberry Pi board?
Is there a table in a memory component of the board where all the components of the board are catalogued, for instance, like BIOS settings that gives an option to set primary boot device for an OS to load - like HDD, CD-ROM, Pen-drive - as the BIOS knows what peripherals are attached?

 

[FactChecker]

So, where are these symbolic addresses of ports and pins present on the Raspberry Pi board?

#define LED RPI_GPIO_P1_12

In the above line of code, how does the compiler know that there is something called "RPI_GPIO_P1_12" on the board?

No. The variable RPI_GPIO_P1_12 is defined in the header file bcm2835.h and is set equal (directly or indirectly) to the memory address that controls pin 12.

How does the header file "bcm2835.h" know that there is a "RPI_GPIO_P1_12" on the Raspberry Pi board?

The header file defines RPI_GPIO_P1_12 and sets it equal to the correct memory address value for controlling pin 12.

Is there a table in a memory component of the board where all the components of the board are catalogued, for instance, like BIOS settings that gives an option to set primary boot device of an OS - like HDD, CD-ROM, Pen-drive.

BIOS is usually only the most basic stuff that the computer needs to read in more detailed information like complicated device drivers. Since pin 12 is not used to read in that information, its control code would not be in the BIOS. It would be in the information that BIOS reads in. Then the BIOS starts running the more complicated boot process that it read in.

PS. I have never worked with device drivers, BIOS, or the boot process, so this post is at (and maybe beyond) the limit of my knowledge. I will have to defer to others for any more information.

 

[nsaspook]

So, where are these symbolic addresses of ports and pins present on the Raspberry Pi board?

Example of a kernel GPIO driver function for the Raspberry Pi. The underlying hardware is accessed by a series of memory registers. The 'pin' is typically a key to a lookup table and/or routine that interacts with the device MMU that remaps the requests to actual hardware.

/*
 * digitalRead:
*      Read the value of a given Pin, returning HIGH or LOW
*******************************************************************
*/

static int32_t digitalReadWPi(struct comedi_device *dev,
                  int32_t pin)
{
    struct daqgert_private *devpriv = dev->private;
    int32_t *pinToGpio = devpriv->pinToGpio;

    pin = pinToGpio [pin & 63]; // user pin lookup table to gpio
    if ((ioread32((__iomem uint32_t*) dev->mmio + gpioToGPLEV [pin]) // hardware pin read
    & (1 << (pin & 31))) != 0)
        return HIGH;
    else
        return LOW;
}

You can build your own custom kernel module functions that talk directly to hardware but it requires a bit of coding with knowledge of Linux device drivers. The information is all online (somewhere).
https://raw.githubusercontent.com/nsaspook/daq_gert/master/daq_gert.c

 

[pairofstrings]

The underlying hardware is accessed by a series of memory registers.

What is the mechanism that is used to read from these memory registers? Is the mechanism electrical or programmatic? What is the mechanism that makes a bridge between electrical entities and software constructs?
If memory register holds some data then how does a software code catches it?
If memory register holds some data then how does a software code absorb it?
Assume that, a memory register hold a numerical data "3" then how can this "3" be made available to software and be used in software? What is the mechanism involved here?

 

[nsaspook]

What is the mechanism that is used to read from these memory registers? Is the mechanism electrical or programmatic? What is the mechanism that makes a bridge between electrical entities and software constructs?

Take some time to study this material about memory-mapped I/O. The question of electrical or programmatic is not really the right question as one without the other is useless in a real computer system that runs machine code sequences on native hardware.
https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/IO/mapped.html

 

[Windadct]

There is a fundamental theorem in CS that any function can be implemented in ether software or hardware - so some of what you are asking there is no one answer.

For this type of program - you are compiling the code. The Chip does not see what you have in your program, the program is compiled and the compiler (another program running in your computer) knows the destination chip and creates the actual code loaded into the uC. Think of the compiler as an interpreter - it takes language you can understand and converts it to language the uC can understand. - Generally if we look at what is sent to the uC we call it Hex ( haxadecimal) - but really to the uC it becomes a binary. (Hex makes it convenient as one digit of Hex = 16 bits, a common register size)

The mechanism of how the uC executes the code you need to look at that chips architecture ( EXAMPLE)

 

[rbelli1]

one digit of Hex = 16 bits

One digit of Hexadecimal is 4 bits. Processors almost always have their parts a multiple of 4 bits wide.

4 bits for the first ones
8 bits for the next ones
Some Pics use 12 bit instructions.
There are 16 bit computers. Many had 20 or 24 bit memory buses.
32 bit is bog-standard these days
64 bitters are getting popular
80 bit values are common for high precision calculations
128 bit is starting to be available in some instances

I'm sure there are exceptions for example the 1-bit bit-slice processors.

BoB

 

[Averagesupernova]

I think the advice given here: https://www.physicsforums.com/threa...signal-physically-flow-in-a-processor.895089/
might be helpful to the OP in this thread.

 

[Windadct]

Doh - 16 states, not 16 bits