Memory mapped I/O?

Question

Does the compiler have memory mapped I/O - at least byte wide?

rew · Answer

I don't know too much about that Crystalfonz module, but it is most likely just like the pi. The CPU has a bunch of GPIO pins. They are possibly grouped by eights, sixteens or thirty-two. For each group, you can "set all outputs with one write". GPIO->DATA_REGISER = values; I just checked the datasheet for you, and the broadcom processor surprises me in that it cannot do this. It has a register to SET and another register to RESET bits in the output register. That on the one hand might slow you down a factor of two, but it also speeds you up more than a factor of two! Now to write your eight-bit bus to the value you want, you simply RESET all 8 bits of your 8 bit bus: GPIO->GPCLR0 = 0x003FC0000; and then write the 8 bits you want to the SET register: GPIO->GPSET0 = data << 22; (assuming your 8bit bus is on GPIO 22 through 29). The biggest problem is that on the first pi, routing of the PCB influenced which GPIOs came where on the GPIO connector. Thus it might prove difficult to find 8 free GPIOs that are contiguous. So you might need to assemble a few parts of the 8 bits of data into the 32-bit write to the GPSETx register. So on the GPIO connector we have access to: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21, 22, 23, 24, 25, 26, 27. So, you are in luck! There ARE 8-bit contiguous stretches of GPIO pins available that allow easy single-instruction access to that databus. One thing you might run into is that some of these have a "special function". So if you need the UART as well, that's on pin 14-15, so that creates a hole there. 2-3 is I2C, 7-11 is SPI. But 20-27 remains together as a byte. It's scattered around physically on the connector, but in software you can do it in one go. That said... the reason you're seeing things go slow is unlikely related to accessing separate bits in memory mapped IO. Suppose I chose to connect my 8-bit bus on GPIO4, 14, 15, 17, 18, 27, 22,23 because those are nicely together on the connector. then I'd write GPIO->GPSET0 = (data&0x01)<<(4-0) | (data&0x02)<<(14-1) | (data&0x04)<<(15-2) | (data&0x08)<<(17-3) | (data&0x10)<<(18-4) | (data&0x20)<<(27-5) | (data&0x40)<<(22-6) | (data&0x80)<<(23-7); Because we have three "stretches" of contiguous bits, we can simplify this: GPIO->GPSET0 = (data&0x01)<<(4-0) | (data&0x06)<<(14-1) | (data&0x18)<<(17-3) | (data&0x20)<<(27-5) | (data&0xc0)<<(22-6); Now if you know this in advance, you can optimize this even further by choosing longer stretches of contiguous bits. I have written and compiled this, and it turns into twelve instructions. So at 1.2MHz that would evaluate in 10ns! (assuming you're doing this often enough to load the code into cache). If you are complaining about bitwise access and slowness, then I suspect that you might be accessing the Linux GPIO driver through /sys or someting. THAT is going to be horribly slow no matter what.