ARMGuy

I am currently using the Atmel Studio 6.1 and the Atmel Software Framework with my Arduino Due. The reason I am doing this is the Arduino IDE keeps a lot of things under the hood that I am trying to see. So, I am using the Atmel Studio 6.1 in order to better learn the Cortex M3 ARM microcontroller.

Unfortunately, the complexity has already gotten the best of me. I searched for the answers myself but came up empty-handed.

What I am basically trying to do is a simple program to toggle a pin, say what is commonly referred to as PIN 13 on the Arduino Due board, which is LED "L". I used the New Project template, specifying the Arduino Due board and also added the GPIO, System Clock, and Delay ASF libraries. I cannot get the LED to flash on and off at a 1 Hz rate, and I am stumped as to why. Here's the body of my main:

// Insert application code here, after the board has been initialized.}

I tried some of the other gpio and pio configure and set functions to no avail. It would be nice to have documentation that shows how the ASF relates to the chip itself. For instance, to configure the port bin PB_27 as output, first do this then that. I have yet to find any documentation like this, so I have resorted to trial and error.

Oh, I am also aware that the Atmel database has an example on PWMing PWM Channels 0 and 1 to make an LED glow, but my scope shows nothing is happening. I believe I am programming the board correctly with bossac, as the verify portion of the programming says it was successful.

ARMGuy

The answer is...both. Using the Arduino 1.5.2 IDE results in the behavior I want, which is a blinking LED on my board.

I actually resolved my issue. It's a combination of following an outdated video from Atmel using a deprecated ASF API and my burning the wrong file onto the chip. I was using the gpio configure and set functions. They have actually been superceded by the IOPORT functions. Additionally, I was burning the hex instead of the bin file. Here's my code:

Replace COM5 with the COM port your Arduino Due is connected. Of course, also hold the Erase and Reset button then let go after one second if bossac complains it cannot find a device on the specified COM port. bossac should then be able to locate the device. Also, once the Due is programmed, you may have to press the Reset button on the board to start the program. On my board, I have had to do this even though I specified the "-R" parameter to bossac.exe

I see a lot of "I want to learn more about ARM programming" threads, but the truth is 99% of programming on ARMs is nothing to do with the ARM CPU, it's all about peripherals or just plane C code.

gpio_set_pin_high(LED0_GPIO) is no closer to the hardware than digitalWrite() in terms of learning anything, it's just another name for a function to set a pin. As noted, even if you get down and dirty with the port control registers that's nothing to do with "ARM".

You could start writing code in assembler, that really is learning ARM. Apart from that offhand I think the only ARM things you can play with is the NVIC or the systick counter.

_____Rob

Rob Gray aka the GRAYnomad www.robgray.com

ARMGuy

gpio_set_pin_high(LED0_GPIO) is no closer to the hardware than digitalWrite() in terms of learning anything, it's just another name for a function to set a pin. As noted, even if you get down and dirty with the port control registers that's nothing to do with "ARM".

You could start writing code in assembler, that really is learning ARM. Apart from that offhand I think the only ARM things you can play with is the NVIC or the systick counter.

I'm quickly realizing this as I delve further into the ASF: I'm really just learning what APIs to use and in what order so as to configure the peripherals I want. I may have to go back to the modest days of assembly, like I did when I was playing with the 8051, in order to really learn the hardware. Of course, I have to be pragmatic about things, too. A big reason I am doing this is to say I know how to program the ARM to prospective employers. I think they lean more towards C code bases and API calls rather than expecting a prospective employee to intimately know the chip's architecture well.

I may have to go back to the modest days of assembly ... in order to really learn the hardware.

Nah, it's all there and accessible to C; you just have to bypass the ASF functions. And maybe CMSIS as well. Things are to the point where most ARM vendors document their chips with C examples, so you shouldn't really need to go deeper than that.

Quote

say I know how to program the ARM to prospective employers.

I guess. When an employer says "I want someone who programs ARM", what they really want is someone who will be able to sit down and start churning out code with a minimal amount of downtime for training/learning. Unfortunately, with ARM, that can range from "can you write a CMSIS library for a bare metal CMx family" to "can you administer an ARM linux distribution" to "can you write apps for Android?" It seems to be pretty common for "can you program in x" to mean "are you familiar with the standard libraries used to build our sort of applications in our sort of environment. If someone asks you whether you know C#; they're not really wanting you to offer a paper on the technical differences between C# and C++; they want to know whether you can write windows apps, including the libraries/etc. (perhaps ESPECIALLY the libraries/etc.)