another newbie question.
I have a piece of code that I am porting from PICC. In PICC, you can make reference to specific pins ("#define sclk GPIO5" for example), and in your code, you can write to sclk to change the pin output on GPOI5. This makes porting code or changing pin layout so much easier as you can simple redefine sclk to a different pin to make the code work.
ARM seems to prefer to change its pin output through IOSET / IOCLR.
To make the existing PICC code work, I would prefer to be able to define certain pins logically, and change their states by referencing their logic names.
how do you do that in ARM? Thanks in advance.
But f in this case represents a register similar to the SFR in the 8051, i.e. it is a special region of memory.
For a PIC16, f is a value between 0 and 127, specifying a memory address within this special SFR memory region. Some of these bytes will represent the status register (carry or zero bit) and some of these bytes will represent GPIO pins.
The ARM has real hard registers. The registers in the ARM does not have a memory address, so a memory pointer can not access the ARM registers. And instructions working on registers can only modify the existing registers, not bytes or words in memory.
In the end - if you want a processor that can declare bit-sized variables, you may consider a PIC or 8051 processor. The ARM core is not designed for bit variables. It has no bit-addressable memory, and no instructions to read or write individual bits in any such memory. Working with bytes or larger, the ARM requires either the hardware or the software to perform and/or/xor/not to modify individual bits in a memory cell - and since it separates registers from memory, the GPIO control will have to be memory-mapped.
It would be possible to create an ARM core that either drops some of the registers, to use the name of these registers to control I/O. Or create an ARM core that keeps all registers, but defines that BFI/BFC are exception instructions that will only be able to access a subset of the registers, but instead also access GPIO. But ARM hasn't seen a reason to, since the customers has not shown any interest. And the customers can not modify an ARM core, since they will just get a hard macro cell to connect to their own logic.
In the end, you will have to either select another processor, or live with the design choices that ARM has made for the processor core. The ARM is not a PIC and it is not a 8051. But for most users, this doesn't matter. The important thing isn't what instruction sequences you need to access a port pin. The important thing is how fast you can toggle them, and what cost it will take to run the chip at the required clock frequency and to have the required amount of flash.
In the end, there is very few situations where the ARM can't match a 8051 in capability, cost or speed. The biggest reason for a PIC is probably if you need very, very few pins or need one of the NanoWatt series chips.
"The ARM core is not designed for bit variables."
I think that's the case. the reasons given earlier about latency, gpio off bus, or the business model, etc. are really not fundamental. It appears that for some reason, ARM or their vendors decided that that was the way for this particular chip. why / how they did that I don't know, maybe we will never know.
"It has no bit-addressable memory,"
apparently until the Cortex chips.