Arduino Zero

So I just had this pop up in my Facebook news feed:

Cool! I thought... A new 32 bit Arduino to base my own board designs around. And the processor on it is nice and small, unlike the Due's enormous 144 pin beast. Hm, I wonder what that QFN package next to it is?

Then I checked Digikey for stock on the chip. BUZZKILL! ZIP. NADA. NOTHING.

Oemstrade? Again, ZILCH.

Hm, looks like the ZERO is living up to it's name already. There's ZERO chips in stock anywhere!

Okay well that's disappointing... Well maybe we could use the D20 instead? Hm... they're compatible, and lots of those in stock... but, oh dear, those don't support USB. The D11 then? Those support USB and are also compatible, I wonder what they're missing... hm, before I waste my time figuring that out better check the stock... oh for Pete's sake! There's none of those in stock anywhere either!

Why in the hell would they release a new Arduino based on a chip which isn't available anywhere? I mean I get why Atmel would want to release one to promote their new chip, but this has the official Arduino seal on it and everything. Why do we get this instead of something based on the Xmega which is widely available? I know some have done most of the work porting the IDE to that, so it seems like a logical step to take. I mean it's 8 bit, but it's 32mhz and at least you can get the chips. :confused:

Oh well, maybe in a year this will be a viable option for real products. I doubt Atmel is gonna flood the market with tens of thousands of these chips in the next few months when Digikey doesn't even have a listing for them.

I wonder how the Atmel proprietary debugging chip is going to fit in with the open-source philosophy?

Why in the hell would they release a new Arduino based on a chip which isn't available anywhere?

They haven't released it they have announced it.
It is a new chip. It will be available when the Zero is available or shortly after.

This post on hackaday is very informative especially addressing the debugger question.

Also you can purchase the ATSAMD21-XPRO-ND on digikey which I am betting is what they used to develop the Zero.

scswift:
Oh well, maybe in a year this will be a viable option for real products. I doubt Atmel is gonna flood the market with tens of thousands of these chips in the next few months when Digikey doesn't even have a listing for them.

I think you are simply expecting too much here.
For one, they just barely announced the board and showed off some prototypes. I don't think that anyone would/should seriously expect that the chips/parts for this board, that isn't really 'official' just yet being readily available already.
Not that I personally would ever bother to hunt for the parts and build my own board(s), I much rather use what is readily available and usable to fulfill my purpose. And this might just do it, at least if the price decision on this is a bit more level-headed than what they just showed with the Arduino Tre...

Ralf

Does Atmel announce the exact day of publish the board?

Atmel said that release details are up to the Arduino team.
(in the interview posted on hackaday.)

I've read a few things about hardware debugging but can't get my mind round what it actually is, either theoretically or in a practical sense.

Could someone clue me in please?

Basically it is a way of stopping the program at any point and being able to examin the memory and even write values to it.
So that means you can single step through a program or set break points and track the value of variables and various stacks.

Ah ok, and then presumably there's a "debug interface" and some continual communications to and fro so the board reports selected variables' values and / or the user submits new values?

Yes debug windows can get quite complex.
They can even show the source code being stepped through and the equivalent machine code section. They can be quite intimidating to drive at first.
It is much simple to do this with a system that runs from RAM rather than one from flash memory.

Well, you know how you can use "ISP programming" to read and write the flash memory and fuses of an AVR?
It's a short jump from that to being able to use "some protocol" to also be able to read and write RAM, and all the other internal registers of the chip. And you can sort-of picture one of those registers meaning "stop executing code and sit there while I look at you." And an instruction "breakpoint" that means "go to the 'stop executing and let the debugger look at you' state. And maybe a comparison register so that when you access certain memory locations in a certain way, it also goes to that state.

At that point, you can watch the chip execute as slowly as you might want, and keep track of everything that happens. "This number is supposed to be between 1 and 10 - why is it actually 250 ?" "Wait; why are we back at setup() instead of continuing to loop?" "Oh look! It's going to one of the null interrupt vectors that does nothing but infinite loop."

Naturally, at this level everything is in machine code, with numbers (well, bit patterns) for variable addresses and such. You need (well, "want") a piece of software that will interpret the raw numbers and translate them back into something that looks like your sketch with its meaningful function and variable names. But that just a SMOP.

Note that unlike putting Serial.print() all over your code, this sort of debugging does not consume memory of any kind, or interfere with interrupts (like trying to use print() in an ISR.) With a bit of cooperation and care, most of your program can run at full speed, or near full speed even if the debugger is sampling information every now and then.

There are a couple of common concepts:

  1. Breakpoints - give control to the debugger when the code reaches a particular point in the program.
  2. Watchpoints (aka "data breakpoints") - give control to the debugger when a particular data variable is modified. Also, show the value of these variable periodically (whenever the debugger has control of the chip, at least.)
  3. Stepping - execute one instruction, or one line, or one function of the program and go back to the debugger. (also: "finish the current subroutine.")

, this sort of debugging does not consume memory of any kind,

Well normally there is a debug build that does add some extra code into your code.
Also you normally have the choice of
Step in or step over for functions / subroutines.

normally there is a debug build that does add some extra code into your code.

Bah humbug. Some people like to turn off some optimizations when debugging, just because it requires less non-linear thinking, and less tracking down of variables whose existence is too ephemeral for the debugger to keep track of. :slight_smile:

So a bit like the 'Action Replay' cartridge from many years ago, for those old enough to remember such things? I can't remember if it was for C64 or Amiga.

EarthLCD/EarthMake wants Early access to Arduino zero for LCD related product development. I did not see this discussed at all in the developer list. Can I get a private or public response for early access to the Zero?