I have just downloaded uVision v4 (sept 09) and am using the following code:
#include <AT91SAM7S256.h> #define LED (1<<0) // PA0 #define INPUT_PIN (1<<1) // PA1 #define INT_PIN (1<<2) // PA2 static void initialize( void); int main(void) { volatile long input; initialize(); volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA; while(1) { input = pPIOA->PIO_PDSR; //for debugging. Watch input variable to check if inputs working. pPIOA->PIO_CODR = LED; pPIOA->PIO_CODR = 0x01; pPIOA->PIO_SODR = LED; } } static void initialize(void) { //Turn on the peripheral clock. Without this on, inputs do not actually register in the PDSR register volatile AT91PS_PMC pPMC = AT91C_BASE_PMC; // pointer to PMC data structure pPMC->PMC_PCER = (1<<AT91C_ID_PIOA); // enable Timer0 peripheral clock volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA; pPIOA->PIO_PER = (LED | INPUT_PIN); // Set PIO to control LED and button. // Initialize Input pPIOA->PIO_ODR = INPUT_PIN ; // Disable outputs for INPUT pins. (not needed as all pins default input on reset) pPIOA->PIO_PPUER = INPUT_PIN; //Pullup Enable (not needed as all pullups are enabled on reset) // Initialize Output pPIOA->PIO_OER = LED; // Enable output for LED. pPIOA->PIO_SODR = LED; // Turn LED off. pPIOA->PIO_PPUDR = LED; //Pullup disable }
and it throws up the following compile error:
main.c(14): error: #268: declaration may not appear after executable statement in block
with lines:
volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA;
and:
What am I doing wrong. It compiles OK with my other compiler.
Please let me know
"What am I doing wrong"
You are doing what the message tells you that you may not do!
So don't do it!
If A may not appear after B, then where must B appear relative to A...?
Remember that ANSI 'C' is not quite the same as C++ in this respect...
Hi Andy
Thanks for the kick in the backside - I needed it. I actually copied this bit of code from someone else. If I were writing the code, I would put all my declarations at the top. It is much neater too! I realise the error of my ways now. Sorry!
They probably wrote it for a C++ compiler; or, at least, a 'C' compiler that allows some of the C++ features - like this...
actually copied this bit of code from someone else
It is fairly uncommon for people here to make such admissions. I commend you (but I still think you should have told us in the beginning...)!
It is quite common that people copies initialization code for ADC, UART etc from the application notes or sample codes from the chip vendor. For bigger processors, you may be an extremely good programmer but still not have the required time to figure out a "good" value for several hundred configuration bits for one single peripherial device.
Just look at the amount of data you may have to supply to configure a memory controller for use with virtual memory and dynamic memory. The quickest solution is often to check if the cost/availability of the memory chips on an evaluation board are acceptable and then rip that solution unless the units are expected to be sold in 100k volumes.
I think my predicament is more basic than that. After writing about 50,000 lines of code for the PIC over the years (in both assembler and C), I have taken that leap of faith over to the ARM core. It is completely different in every way....
If something does not work, you assume the problem is way too complex for your abilities and end up overlooking the obvious!
Ah yes - the, "have you switched it on?" scenario...
;-)
I switched from hardware platform A to platform B and spent a lot of time figuring out why an output signal was so very noisy, very much suspecting a firmware bug or something wrong with the hardware. Especially since the platform B unit was rescued from the heap of old prototypes.
It seems the connectors between platform A and B had two pins switched (signal out and ground). Suddenly, the noise problems did go away when the idle-high output signal wasn't shorted to ground through a long wire ;)
It is so much easier to assume "the worst".