Broadcom chipset C code

[lilzz]

Code: Select all

// Function select
// pin is a BCM2835 GPIO pin number NOT RPi pin number
//      There are 6 control registers, each control the functions of a block
//      of 10 pins.
//      Each control register has 10 sets of 3 bits per GPIO pin:
//
//      000 = GPIO Pin X is an input
//      001 = GPIO Pin X is an output
//      100 = GPIO Pin X takes alternate function 0
//      101 = GPIO Pin X takes alternate function 1
//      110 = GPIO Pin X takes alternate function 2
//      111 = GPIO Pin X takes alternate function 3
//      011 = GPIO Pin X takes alternate function 4
//      010 = GPIO Pin X takes alternate function 5
//
// So the 3 bits for port X are:
//      X / 10 + ((X % 10) * 3)
void bcm2835_gpio_fsel(uint8_t pin, uint8_t mode)
{
    // Function selects are 10 pins per 32 bit word, 3 bits per pin
    
    
    //using the gpio already mapped address
    
    volatile uint32_t* paddr = gpio + BCM2835_GPFSEL0/4 + (pin/10);
    uint8_t   shift = (pin % 10) * 3;
    uint32_t  mask = BCM2835_GPIO_FSEL_MASK << shift;
    uint32_t  value = mode << shift;
    bcm2835_peri_set_bits(paddr, value, mask);
}

In bcm2835.h
#define BCM2835_GPFSEL0 0x0000 ///< GPIO Function Select 0


what's the point from above code BCM2835_GPFSEL0/4 which is 0x0000/4 =0 anyway.?

[vadim]

For uniform addressing of all control registers, perhaps. There will be different shifts for other controls.

[joan]

To highlight that you are accessing a word at a byte address.

[lilzz]

To highlight that you are accessing a word at a byte address.

gpio is 32 bit address and adding to it is more like an offset. padder is also 32 bit address.
so why do you say it's a byte address?

[lilzz]

For uniform addressing of all control registers, perhaps. There will be different shifts for other controls.

why divide by 4? why not 1, 2, or 8?

[rurwin]

what's the point from above code BCM2835_GPFSEL0/4 which is 0x0000/4 =0 anyway.?

That is good code. The programmer who wrote that knew what they were doing.

1. The whole point of using macros is that you do not then need to worry about what the value is.
2. If you later copy and paste that code, or just change that piece, to use B2835_GPFSEL1, the new code will still be right.

[rpdom]

why divide by 4? why not 1, 2, or 8?

Presumably BCM2835_GPFSEL0 is a byte (8-bit) offset and it needs to be a word (32-bit) value.

[DougieLawson]

For uniform addressing of all control registers, perhaps. There will be different shifts for other controls.

why divide by 4? why not 1, 2, or 8?

It could be because lazy assembler programmers have been taught that divide takes fewer cycles than a shift. Which may or may not be true.

I'd always use divide for maths and shift for bits as I think it makes the code easier to read.

[rpdom]

It could be because lazy assembler programmers have been taught that divide takes fewer cycles than a shift. Which may or may not be true.

I'd always use divide for maths and shift for bits as I think it makes the code easier to read

That might be true for floating point maths, but as the ARM has no integer divide instruction a shift is just one instruction for byte or word values (and can often be combined with another instruction at the same time) and therefore much faster. If the compiler is decent it will convert part of that line to an add with shift.

[jamesh]

In fact, I think the compiler will have optimised out the CONSTANT/8 completely.

[jojopi]

It could be because lazy assembler programmers have been taught that divide takes fewer cycles than a shift. Which may or may not be true.

I doubt that anyone would think that. It is always quite the opposite.

You are right to write code the way you think is clearest, because the compiler will not mind. I am not sure that shifting by two is clearer than dividing by four, however, and it requires extra parentheses.

Incidentally, right shift is not necessarily equivalent to division, for negative values. In that case the shift is implementation-defined, which in practice on a two's-complement machine means it rounds towards negative, whereas division rounds towards zero. (Except in Python, where integer division rounds towards negative!)

[DougieLawson]

Compiler NO! Assembler YES.

I'm not used to these funny RISC machines. The machines (S/360, S/370, S/390, zSeries) that I write most assembler code for now has nearly a thousand instructions and four different flavours of maths (64-bit integer, float, packed decimal & IEEE).

I've still got to do the 700 page reading assignment for the RPi's ARM processor and it's instruction set.

I've also got to stop thinking in EBCDIC and try to get used to this new-fangled ASCII thing.

[rurwin]

For uniform addressing of all control registers, perhaps. There will be different shifts for other controls.

why divide by 4? why not 1, 2, or 8?

paddr is a pointer to a 32-bit integer. In C when you add one to a pointer you get the next object of the same size. However BCM2835_GPFSEL0 is a byte offset, so it needs to be divided by 4 to make it into a 32-bit offset (32bits/4 = 8bits).

Let's assume we have a pointer to an 32-bit integer called x, and it's value happens to be 100.
So the integer pointed to by x will be at (byte) addresses 100, 101, 102 and 103.
If we add 1 to x the compiler will multiply that by 4 and give us 104, which is the address of the next integer.
Similarly, if we have a byte offset from x, say 8, we will have to divide that by 4 so that when the compiler multiplies it by 4 it will be right.
x = x + 8/4
Now x is 108.

The whole thing will be optimised out by the compiler anyway.

[jojopi]

I'm not used to these funny RISC machines. The machines (S/360, S/370, S/390, zSeries) that I write most assembler code for now has nearly a thousand instructions and four different flavours of maths (64-bit integer, float, packed decimal & IEEE).

Those architectures certainly support some complex old instruction sets. The integer representation is 32/64bit two's-complement, however, just like the most modern machines. There is no excuse on any binary platform for a shift to be slower than a divide; it should always be the reverse.

The only timing information I can find is for the ancient S/360 Model 40, where if I read the Functional Characteristics correctly the slowest shift is 23.13µs, and the fastest divide 136.30µs. Presumably on current implementations these kinds of figures, and the whole concept of cycle times, are meaningless due to pipelining.

GCC does not seem to think that divide should be faster than shift. It compiles a divide by four as SRA ,2 on all supported S/390 and zSeries CPU types. (On the 64bit CPUs it converts a divide by ten to a multiply by 7378697629483820647 as well.)

[lilzz]

paddr is a pointer to a 32-bit integer. In C when you add one to a pointer you get the next object of the same size. However BCM2835_GPFSEL0 is a byte offset, so it needs to be divided by 4 to make it into a 32-bit offset (32bits/4 = 8bits).

Let's assume we have a pointer to an 32-bit integer called x, and it's value happens to be 100.
So the integer pointed to by x will be at (byte) addresses 100, 101, 102 and 103.
If we add 1 to x the compiler will multiply that by 4 and give us 104, which is the address of the next integer.
Similarly, if we have a byte offset from x, say 8, we will have to divide that by 4 so that when the compiler multiplies it by 4 it will be right.
x = x + 8/4
Now x is 108.

The whole thing will be optimised out by the compiler anyway.

BCM2835_GPFSEL0 is 32 bit offset (not 8 bit offset) as defined in .h

#define BCM2835_GPFSEL0 0x0000

#define BCM2835_GPFSEL1 0x0004 ///< GPIO Function Select 1

those are 32 bits offset.

[joan]

The code is using a pointer to a 32 bit object to access a byte address. The code is highlighting that you need to divide byte addresses by 4 when accessing them through a 32 bit object. It's highlighting C's pointer arithmetic.

[rurwin]

BCM2835_GPFSEL0 is 32 bit offset (not 8 bit offset) as defined in .h

#define BCM2835_GPFSEL0 0x0000

#define BCM2835_GPFSEL1 0x0004 ///< GPIO Function Select 1

those are 32 bits offset.

It's an offset of 32-bits, yes, but that's not what I meant.
It's an offset that is counted in bytes, groups of 8-bits. The second #define indicates that GPFSEL1 is 4 bytes beyond GPFSEL0.
Because paddr and gpio are uint32_t pointers they need an offset that is counted in uint32_t's, groups of 32-bits. GPFSEL1 is 1 uint32_t beyond GPFSEL0.

That's a feature of the C language.