We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
"Note that they target a register, not a memory address. "
OK. how about BSF/BCF? here is what Microchip has to say about them:
"BCF Bit Clear f Syntax: [ label ] BCF f,b ... Description: Bit 'b' in register 'f' is cleared."
"BSF Bit Set f Syntax: [ label ] BSF f,b ... Description: Bit 'b' in register 'f' is set."
does it look like BCF/BSF also work on registers?
wouldn't that make them identical to the ARM instructions?
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.
Ashely; It still appears that you are more intent on defending the PIC design than understanding the ARM when no one has challanged the PIC design. The statement is just the ARM concept is different. Instead of attempting to redesign the ARM core, why don't you review a few of the examples in the Keil toolset. What part of setting/clearing a bit troubles you?
The GPIO register addresses are defined in the furnished header files. The Mask and Direction registers are normally set one time in a GPIO init module.
Then: #define sensor_pwr_on 0x00001000 #define sensor_pwr_off 0x00001000 #define set_two_bit_on 0x00001001
IOSET1 = sensor_pwr_on; //Zero bits are ignored IOCLR1 = sensor_pwr_off;
IOSET1 = set_two_bits_on;
In the MCB23xx Blinky example they use a macro definition then write:
LED_E(0) // LED OFF LED_E(1) // LED ON
So there are many different ways to get symbolic addressing of single bits.
Bradford
"It still appears that you are more intent on defending the PIC design than understanding the ARM when no one has challanged the PIC design. "
Al, once you start questioning a person's intent, you are going down a very slippery slope.
let's just leave it at that.
"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.