Is this code guaranteed to only effect pin 22?
int* FIO0PIN = (int*)0x2009C014; *FIO0PIN ^= (1<<22);
At first it seems like a dumb question but I remember working with a PIC18 microcontroller where you could corrupt the port output by doing this. Corruption happened when a previous write to the the output latch was not yet reflected by the output state (pin is driving a capacitive load), XORing an unrelated bit meant reading the port, doing the XOR and writing back to the output latch (with the old value of said unrelated pin).
int* FIO0PIN = (int*)0x2009C014; *FIO0PIN &= (1<<4); //set bit 4 *FIO0PIN ^= (1<<22); //if pin 4 has not yet transitioned to 1 because of capacitive load //will this clear it again?
How does the Cortex avoid this problem? Or does it?
I am aware of the FIOxSET and FIOxCLR registers, bit toggeling through them is however much less efficent if one does not know the current value of the bit in question. I am writing a domain specific language using C++ meta programming which abstracts all basic IO functions and preforms optomizations on sets of them. With the LPC11xx parts implementing the bit toggeling is super easy, I just use the dedicated register, I would like to get the LPC17xx implementation as efficient as possible.
Here is the code in case anyone is interested: https://github.com/porkybrain/Kvasir the "register action" is created by the "makeToggle" factory here https://github.com/kvasir-io/Kvasir/blob/master/Lib/Io/Io.hpp using a template specialization here https://github.com/kvasir-io/Kvasir/blob/master/Lib/Chip/NXP/LPC17/M3/5x6x/Io.hpp I currently make a XorAction out of it for this chip, however I am not sure if it is correct.
I am aware that the FIOxPIN is in the bit band addressable reigion, however according to UM10360.pdf page 749 "Data accesses to this region are remapped to bit band region. A write operation is performed as read-modify-write. Instruction accesses are not permitted" which in my opinion would be just as suseptable to the above mentioned problem.