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.
thanks, per.
I took a different approach.
#define sclk_pin 2 ... IOSET=1<<sclk_pin; // set sclk_pin high; ... IOCLR=1<<sclk_pin; // clear sclk_pin; ...
so if I were to change to the pin connection (sclk on pin 5 for example), I would just change it to "#define sclk_pin 5"), and the rest code remains.
not as elegant as PIC but works.
did some experiment and here is what I learned about GPIO direct reference.
It looks like you CAN indeed directly reference GPIO ports / bits in a way similar to that used by PIC for some ARM chips and possibly all of them.
For example, LED=~LED where LED is defined as GPIO_PORTA_DATA_R for LM3S628 will flip all bits on PORTA. ARM chips from ADI and ST do allow GPIO direct referrencing - the header files have clear reference to GPIO data bits, control bits, etc.
if you really think about it, it makes perfect sense as those "registers" are nothing but memory addresses linked to certain hardware. writing to them in bits / bytes would then be natural.
now, it does seem that certain manufacturers prefer certain ways to "access" their chips: NXP wants to go through the IO control registers and ADI/ST/Luminary and possibly others want to go through the ports directly, and provide header files to help in the implementation of such approaches, respectively.
but I don't doubt for a second that you can create your own header files that will allow a nxp chip to have direct port access and ADI/ST/Luminary chips to use IO control registers.
the conclusion? the ways those chips access GPIO and potentially other peripherals are vendor specific, and software-customizeable. there is nothing foundamental about either the cores, architecture, or business model(s) that prevent the use of any of the approaches, though most (all?) vendors seem to prefer one approach over others.