New Atmel board for ASF development!

I started off really excited when I first found the new SAMD10 X-Mini development board. http://www.atmel.com/tools/atsamd10-xmini.aspx

The Good News 

• It includes a Debugger built-in! It uses the meDBG protocol, through an ATMega32U4. Which could be hacked and used as a USB device and restore the firmware if you have a stand-alone hardware programmer. 
• Supports the ASF
• It's a 32-bit ARM M0+ based board
• Has pins in the right place to be Arduino Shield compatible!
• 16 kB FLASH, 4 kB SRAM
• 48 MHz operating speed.
• It has a QTouch button
• It's less than $10
• It's less than $10 (Yes it needs to be said twice!)
• + More http://www.atmel.com/Images/Atmel-42242-SAM-D10_Datasheet.pdf

The main reason for my excitement was the Arduino shield compatiblity w/ ASF support. I've made no secret that I like the readability of the ASF source code, it's great because the source code migrates well between all of the supported Atmel microcontrollers. The Arduino eco-system has so many good shields for prototyping designs that grabbing this SAMD10 XMini board and a shield is a great way to implement the code for a component like a Real-Time Clock or motion sensor IC's, even a classic character LCD. Write some code get it running then add that to your personal code library for larger projects. When you don't have to create the prototype board it's a big savings in time and money. Hint: This is what I'll be working on, I plan to share on Github anything that even kind of works.

Neutral News

A few details that are pretty neutral for me but should be clear.

• Only supports 3.3V I/O
• Doesn't include the header pins to attach a shield.
• Requires the use of Atmel Studio vs. the Arduino IDE.
• The SAMD10 doesn't have a crystal installed although there is an external clock line from the ATMega32U4 into PA08.
• The following SAM D10 pins are schematically shared with "Arduino" pins.
• PA07 w/ QTouch button
• PA09 w/ LED and w/ SPI Header
• PA10, PA11 w/ Serial on ATMega32U4 which gets routed to USB connector
• PA22, PA24 w/ SPI Header
• PA25 Mechanical button
• PA30, PA31 Debugger on ATMega32U4
• The ATMega32U4 isn't routed for much besides debugging, for hacking there is:
• The USB Device Lines to USB connector
• An LED
• 4 Pins on a tiny 10-pin header intended for JTAG use, but could be re-purposed.
• UART lines to the SAM D10
• Power Enable for the SAM D10

The Bad News

1. Digital Pin 8 and 9 are Not Connected (N/C) 
1. This is because of the limited number of pins available.
2. There is an issue between Atmel Studio and the documentation 
• The board silk screen and the schematic show PA27
• Atmel Studio says PA27 is NOT available with a compiler error.

I was able to address #1 with a couple of small wires and moving pins PA14 and PA15 to the N/C pins. This probably isn't a big deal if you are using Arduino shields that are pre 1.0 shield and many shields made after 1.0 don't use the extra I2C pins.

Issue #2 just needs to be tested it's a nuisance but more disappointing. 

I'm still looking forward to the Arduino Zero which according to the schematic does have all of the shield pins routed. Compared to this boards $10 price tag and "close enough" features against the Zero's approx $50 price, I'll probably order and use the SAM D10 XMini for most of my little projects. 

To be cont'd as I experiment more with the board!

P.S.

If you really like the classic ATMega328 that is in the Arduino UNO I suggest the ATMega328 XMini same chip, same Arduino shield pinout, except it's less than $10 and includes a real debugger. It does use Atmel Studio instead of the Arduino IDE, so you trade more power for a higher learning curve.
http://www.atmel.com/tools/mega328p-xmini.aspx

Notice the controller schema details

I received an email related to a game controller product that I designed previously and they asked a great question. It ended up being a pretty long exchange of questions and answers that I thought would be valuable to a wider audience.

"I'm putting some resources into game development and want to be aware of any steps I need to take to enable controller support on all platforms [especially] iOS." 

Their primary development platform is iOS so the answer would seem obvious "iOS Controller Support". It's been available since iOS7 and now with iOS 9 being released some 90+% of devices have the support built-in.

This easy answer becomes a little more complicated even before leaving the Apple realm since there are two different layouts, then if you want to support multiple platforms with the same code base it gets even more complicated.

Let's talk about controller compatibility, there are a lot of options. In addition to the iOS Controller support for Apple devices, there is the Android Phone/Tablet market. The most popular game controller on Android is the controller that Sony created for their PlayStation 3. So lets compare the main competitors for portable gaming controllers. Originally I was going to use a Logitech Controller but I couldn't find a clear description on their site of which inputs are analog and digital so I used mine sorry for the "bias".

iOS Standard Layout	iOS Extended Layout	Sony PS3	Evolution Controllers Drone
A,B,X,Y Analog D-Pad Analog L,R Analog Pause Digital	A,B,X,Y Analog D-Pad Analog L,R Analog L,R, Joysticks Analog L,R Triggers Analog Pause Digital	Square, Circle, Triangle, X Analog (i.e. A,B,X,Y) D-Pad Analog L1, R1 Analog L,R Joysticks Analog L2, R2 Triggers Analog Start, Select, PS, L3, R3 Digital	A,B,X,Y Digital D-Pad Digital L,R Joystick Analog LB,RB, Digital LT,RT, Digital Start, Select Digital

Reminder all of these controllers are used for mobile gaming, the iOS ones are a defined standard from Apple that hardware companies can make. The PS3 controller was a familiar layout with a standard Bluetooth connection, Sony of course was only trying to create a standard for their own platform, although I doubt they are disappointed by the additional sales. The Drone was initially created for use with classic console emulators on an Android phone, but has been very popular with PC gamers for extended play sessions.

Even between these 4 controllers there is a lot of variation in the hardware and the game programming side gets more complex too. All of the game controllers have the following buttons:

• A,B,X,Y
• D-Pad
• L,R
• Start/Pause 

Most of them have analog versions of those buttons but I forgot to mention that PC gamers don't usually get analog buttons, their buttons are actually very comparable to the Drone. So if your game is coming to a PC near you, remember that most buttons are digital. Analog buttons may have limited use since an average player might create about 4 different levels on an analog button, a good gamer might get 16 different levels. 

Best compatibility with the most platforms/controllers:

Essentially the iOS Standard Layout with digital buttons. If this is a good controller scheme for your game consider the iCade specification it's based on a keyboard input device and does work on iOS. http://www.ionaudio.com/downloads/ION%20Arcade%20Dev%20Resource%20v1.5.pdf.

• A, B, X, Y
• D-PAD (Up, Down, Left, Right)
• L, R
• Start/Pause

Best experience/compatibility combination:

Nice compromise for most games is analog joysticks but mostly digital buttons. (Not compatible with iOS Standard Layout) This is a great layout for PC games also consider using it for testing your game, using a simulator or emulator with a PC game controller may be quicker than using the actual hardware.

• Left Joystick (Analog)
• Right Joystick (Analog)
• Left Trigger Analog (or Digital for increased compatibility)
• Left Trigger Analog (or Digital for increased compatibility)
• Buttons (Digital)
• Start and/or Select
• A, B, X, Y
• 8-Way D-Pad (Up, Down, Left, Right, + combinations)
• Left/Right Bumper 

Best experience 

Same buttons and inputs as the above combination with the addition of any of the buttons in analog mode.
(Not compatible with iOS Standard Layout, or Drone)

• Left Joystick (Analog)
• Right Joystick (Analog)
• Left Trigger (Analog)
• Left Trigger (Analog)
• Buttons (Analog)
• Start/Pause
• A, B, X, Y
• 8-Way D-Pad (Up, Down, Left, Right, + combinations)
• Left/Right Bumper 

That is my "long winded" answer to a great question. 

Current project uses an ATtiny

My current project doesn't need the features of even the lowest featured ATXmega, it actually doesn't even need an ATMega. This one is happy to run on an ATtiny 8+ I/O pins, a couple of timers for PWM an ADC and I'm done, right?

What I forgot about the ATtiny is that it doesn't use the ASF, it's considered too memory constrained. More likely it would overly complicate (conditional compilation) the ASF source code.

The result is I'm really getting familiar with the actual registers. I can almost imagine the TTL chips it would take to perform the exact task I'm configuring. The good part is understanding a feature at the register level is great for troubleshooting when your abstraction leaks. It also makes you appreciate the amount of "heavy lifting" the ASF is doing for us.

XMega - ASF Performance

ASF Performance

The other day I noticed in my news feed that Sparkfun had a great post talking about "Performance" of the Arduino. While the post itself was a great start, the comments really added to the conversation. The short version is they tested toggling a pin using the Arduino digitalWrite command. If a user simply reads the specs of the ATMega328P (Arduino microcontroller) it's easy to take the 16 MHz clock speed and the estimate of 1 instruction per clock cycle and think the pin should toggle close to 8 MHz.

There are several reasons this number isn't what you would think.

• The C compiler adds additional instructions that may not be needed.
• Multiple checks and other actions are performed before the pin state is set.
• Instructions for managing the loop

The reality in their tests result was 117 kHz or 1/130th the speed expected. This suggests that there were approximately 130 assembly language instructions executed for each on/off cycle of the pin.

Before we get much further I'd like to clarify that this isn't a real world use case. For the simple action of toggling a pin at any speed the job is generally given to a built-in timer. In the case of the XMega we previously covered the ability to output the actual oscillator speed on a couple of supported pins (depends on XMega model how many and which ones). 

The real point here is to examine the Atmel Software Framework (ASF ) on the XMega and compare the overhead to the Arduino. Also we can explore some techniques to improve this situation.

First step is a "New Project .." "GCC C ASF Board Project", etc. For these tests we are going to set the clock speed to match the Arduino aka 16 MHz. See this post and based on your hardware use either the external crystal or the internal 32 MHz clock, both will require the use of PLL to achieve 16 MHz.

I'm going to compromise a little on the ASF code location standards and put everything in 'main.c' this is to be clear about the code being tested. The clock code remains where it is supposed to because that wont be changing over the course of these tests. My code in 'main.c' now looks like this:

#include

int main (void)
{
#define TOGGLE_PIN IOPORT_CREATE_PIN(PORTD, 6)
#define FREQ_OUT IOPORT_CREATE_PIN(PORTD, 7)

ioport_set_pin_dir  (TOGGLE_PIN, IOPORT_DIR_OUTPUT);
ioport_set_pin_dir  (FREQ_OUT, IOPORT_DIR_OUTPUT);

PORTCFG.CLKEVOUT = PORTCFG_CLKOUT_PD7_gc;
sysclk_init();

for (;;)
{
ioport_set_pin_level(TOGGLE_PIN, true);
ioport_set_pin_level(TOGGLE_PIN, false);
}
}

In this code you can see the extra 3 lines of initialization that I use to output the actual clock frequency out on Pin D7. This is for a quick validation of the operating frequency and should have no impact on the performance test in the for loop.

Actual clock frequency output is 15,999,883 or 16 MHz
The Frequency Counter shows the toggle speed on Port D6 is 2.6 MHz. Oscilloscope showed 3 MHz.

This is a great result but not exactly what I was expecting. My expectation was probably 1 MHz or less. So now lets work on some theories as to why.

The two pieces of test equipment show different values, this isn't usually a good sign. In this case we can assume that they use different methods for counting cycles.

Let talk about what the signal on the pin should look like. In it's simplest form the code is:

Loop -> High -> Low->Loop->High->Low
The Loop statement is really a low not knowing how many instructions are being executed it's still reasonable to say that the pin will be Low for twice as long as it's High. So this isn't really the type of wave that a frequency counter is good at counting.

Since the results weren't what I was expecting I changed the for loop to see what would happen.

for (;;)
{
ioport_toggle_pin_level(TOGGLE_PIN);
}

This code should give us equal High and Low times. Now both the O-Scope and the Frequency Counter show 2 MHz even. So less code, provides a lower toggle speed? 

This is only a theory, I'm sure someone smarter than me can confirm it or explain it better. When the two toggle instructions occur inside the loop the counting algorithms count the time between the high's since the wave isn't sinusoidal it leans toward the smaller of the two values. 

Improve Performance

Originally I was going to play with the code and see if it could be optimized to toggle the pin any faster. While researching the unexpected behavior I opened the '\Output\*.lss' file which contains the assembly source code with c source code as comments. What I found was well optimized code, 4 assembly instructions for the 2 lines toggle and 3 assembly instructions for the single line toggle code. In both cases one of the instructions is a jump which is defined to take 2 instruction cycles. I don't know if it could be done better, I couldn't do any better manually assigning registers and the loss of code readability is too valuable for me to mess with it. 

Conclusion

As a reminder toggling a pin manually with code, is about the worst way to implement functionality. By using the Clock out or a timer, better and more accurate results can be attained. Also remember if the processor is running at full speed toggling a pin, it can't go to sleep. This will impact battery life, and any other function you are trying to accomplish on the same microcontroller.