Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

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

  1. Dec 3, 2016 #1
    Hello. I have a following C programming language code that blinks an LED ON and OFF.
    Code (C):
    #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.
     
    Last edited: Dec 3, 2016
  2. jcsd
  3. Dec 3, 2016 #2

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    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.
     
  4. Dec 4, 2016 #3
    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?
     
    Last edited: Dec 4, 2016
  5. Dec 4, 2016 #4

    Svein

    User Avatar
    Science Advisor

    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).
     
  6. Dec 4, 2016 #5
    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?
     
  7. Dec 4, 2016 #6

    Svein

    User Avatar
    Science Advisor

    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.
     
  8. Dec 4, 2016 #7
    Why are symbolic names for pins maintained in documentation when I have to do everything?
     
  9. Dec 4, 2016 #8

    anorlunda

    User Avatar
    Science Advisor
    Gold Member

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


     
    Last edited by a moderator: May 8, 2017
  10. Dec 4, 2016 #9
    I am a learner these days, I am told to have the capability to even create custom library functions.

    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?
     
  11. Dec 4, 2016 #10

    anorlunda

    User Avatar
    Science Advisor
    Gold Member

    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.
     
  12. Dec 4, 2016 #11

    Svein

    User Avatar
    Science Advisor

    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.
     
  13. Dec 4, 2016 #12

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    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.
     
  14. Dec 4, 2016 #13
    So, where are these symbolic addresses of ports and pins present on the Raspberry Pi board?

    Code (C):
    #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?
     
    Last edited: Dec 4, 2016
  15. Dec 4, 2016 #14

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    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.
    The header file defines RPI_GPIO_P1_12 and sets it equal to the correct memory address value for controlling pin 12.
    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.
     
    Last edited: Dec 4, 2016
  16. Dec 4, 2016 #15

    nsaspook

    User Avatar
    Science Advisor

    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.

    Code (C):

    /*
     * 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
     
  17. Dec 5, 2016 #16
    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?
     
    Last edited: Dec 5, 2016
  18. Dec 5, 2016 #17

    nsaspook

    User Avatar
    Science Advisor

    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

     
  19. Dec 5, 2016 #18
    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)
     
    Last edited: Dec 5, 2016
  20. Dec 8, 2016 #19

    rbelli1

    User Avatar
    Gold Member

    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
     
  21. Dec 8, 2016 #20

    Averagesupernova

    User Avatar
    Science Advisor
    Gold Member

Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted



Similar Discussions: Is the design of Raspberry Pi stored in a memory component?
Loading...