I Wonder where our Friends in Shenzhen are with this because on the 22nd of this month a LOT of crap from there is going to be devalued a bit due to the Due and just how many DFRobot shield issues there are going to be... the one with a bi-polar in place of a Mosfet?.

Bob

--> WA7EMS "The solution of every problem is another problem." -Johann Wolfgang von GoetheI do answer technical questions PM'd to me with whatever is in my clipboard

This makes me wonder: Are ARM7 processors in smartphones (like the one in the iPhone) somehow designed for extremely low current draw? Shouldn't they consume more current than a 84-Mhz SAM3X would... As in, how do smartphones still get such long lifetimes while the processor is handling presumably a LOT of instructions, and also additionally using display, graphics driver, Wi-fi, GPS, etc.

@Si: But doesn't that mean that ALL ARM Cortex M3 and various other companies' 32-bit microcontrollers, have no applications?

Not amongst Hobbyists I expect.

Still waiting for the flood of examples

Ah, but what if a 32 bit MCU came in a DIP package and was roughly the samecost as the 8 bit AVR?Wouldn't it make sense to take a serious look at it?and perhaps leave the 8 bit world behind?

I think something like the new Microchip pic32 28pin dip parts would be a much better option thanall these ARMs for hobbiests. ARM is really a technology and not a processor.ARM is great for embedding in custom silicon designs, something hobbyists will probably never need.

Consider this.An Arduino board based on the pic32 28 pin dip parts would return Arduino back to its roots, which is what got all the interest to begin with.The pic32 parts are currently readily available and only cost slightly more than a mega328in QTY 1.

It is 32 bit vs 8 bit with a linear address space so no more hassles with having to deal with thingslike progmem and having to constantly declare things 8 bit in order to optimize code.For beginners I think it would actually be an easier environment to work with than the AVR architecture while offering much more processing power and RAM than the AVR based parts.

The pic32 DIP parts seems to hit a very nice sweet spot in that it solves many of the wants for moreperformance and resources yet still can provide a nice easy to work with package for hobbyists,students, and DIYers.

My fear is that the DUE product has strayed a bit far away from the hobby and educational markets that originally made Arduino so popular.

I think something like the new Microchip pic32 28pin dip parts would be a much better option thanall these ARMs for hobbiests.

The hobbyists market is a total irrelevance for all semiconductor manufacturers, it is just a flee byte in there sales. Even the Arduino has hardly made a blip for Atmel. Massimo said this in his talk to the Open Source conference in 2011.

What hobbyists are doing is riding the wave on the back of industry. Just at the moment we can do this however it will become increasingly more difficult.

Quote

For beginners I think it would actually be an easier environment to work withthan the AVR architecture

The whole point of the arduino is that it abstracts the AVR environment out of existence, as does the Due. It is still under the hood if you want it but most do not venture into those parts.

Quote

My fear is that the DUE product has strayed a bit far away from the hobby and educational marketsthat originally made Arduino so popular.

I think something like the new Microchip pic32 28pin dip parts would be a much better option thanall these ARMs for hobbiests.

The hobbyists market is a total irrelevance for all semiconductor manufacturers, it is just a flee byte in there sales. Even the Arduino has hardly made a blip for Atmel. Massimo said this in his talk to the Open Source conference in 2011.

Obviously. While irrelevant in terms of revenue, it can be very relevant in terms of mind share asstudents that learn/know a particular technology in school might carry that knowledge/familiarityforward into their real-world jobs, where they will be making product design decisions that willaffect manufacturers revenue.

All that said, I'm guessing that vast majority of Arduino sales go to the hobbyist/educational marketand that was the point I was trying to make. "The Arduino market *IS* the hobbyist market."High density pin count surface mount or BGA packages are pretty much non-starters for most DIYers tryingtrying to build their own projects. Those types of users are much more likely toexperiment with parts in DIP packages.

My guess is that many current Arduino users would be very happy with afaster 32 bit processor with more flash and RAM than the mega238 in the same 28 pin DIP package.Particularly when that part can offer additional features like DMA, USB, 5v tolerant inputs,and real-time clock all at pretty much the same price point.

If I were a teacher, I'd much rather put more rugged devices into the hands of studentsthat won't blow up when they accidentally do things like hook up a MCU pin to a 5v sensor.Having a pic32 based Arduino would offer the chance to use 3v devices or 5v deviceswhile playing with a 32 bit environment all at the same price point and same ability to movedesigns to to a standalone board as the current UNO.This is something that simply cannot be done with DUE.

Quote

Quote

For beginners I think it would actually be an easier environment to work withthan the AVR architecture

The whole point of the arduino is that it abstracts the AVR environment out of existence, as does the Due. It is still under the hood if you want it but most do not venture into those parts.

But Arduino doest extract away enough AVR, which is why it is difficult to bring up new processor like the ARM on DUE.It is missing many things in the core library that are needed for higher level i/o libraries.It wasn't even until recently that the pin numbers for certain functions like LED, analog pins, etc...were abstracted on the AVR chips.And then don't forget the progmem and 8 bit variable issues that have to be dealt with inuser code (sketch). Arduino code is littered with these types of needed optimizations even in sketch/user-land code.Things like progmem go completely away when using other non-harvardarchitectures and you no longer have to educate users on the s/w complexities of having touse multiple address spaces. Instead, things like "const" in C/C++ code just workand you can start to use ints for loops and counters without fear of reduced performanceor increased code size.

Quote

Quote

My fear is that the DUE product has strayed a bit far away from the hobby and educational marketsthat originally made Arduino so popular.

But Arduino doest extract away enough AVR, which is why it is difficult to bring up new processor like the ARM on DUE.It is missing many things in the core library that are needed for higher level i/o libraries.

One advantage of the relatively simple AVR architecture is that it provides a gentle transition for the beginner to intermediate stage when the programmer needs to (or simply wants to) go beyond what's offered by the Arduino/wiring core libs. Direct port IO for faster/multiple pin manipulation. Managing multiple interrupt handlers. Inline assembly code. On AVR, all pretty easy stuff to get a handle on for the novice ready to move to next step for the AVR chips.

OTOH, the ARM architecture is much more complex. Nested interrupt handlers, anyone? Even porting conceptually straightforward code from the AVR world to the ARM can raise some tricky questions. For example, I ported Dean Camera's ATOMIC BLOCK routines from AVR to ARM, so I could use them on the Maple... which yielded some interesting and curly questions on how to emulate something as conceptually simple as "cli" an a processor like the ARM, where there is potentially _a lot_ of stuff happening in parallel in the silicon.

Anyway, I don't see the one step transition from Arduino to ARM in the same way you can go from Arduino to AVR. If you were teaching the principles of uC programming, you certainly wouldn't start with ARM in any case (or at least, I wouldn't); something like an AVR, 8051 or 6502 architecture and instruction set is far more tractable. I'd introduce ARM only at the sophomore or senior level once the students had passed the intro uC course.

So is the the Due a suitable dev board design for beginners? It might turn out to be OK, but it's certainly far from optimal. OTOH, it may yet turn out to be a white elephant stuck in the netherworld between niches. I agree with Bill that an electrically more robust chip, preferably still in a DIP package (like the Microchip pic32 part Bill mentions), would be much more consistent with what made the first gen Arduinos attractive to neophytes in the first place. (While even MIPS is not exactly ideal as a learning architecture, it's still a hell of a lot simpler than ARM.)

I haven't tested it yet and may have a -- in the wrong place or something but the idea is that I disable all interrupts at the start of an atomic block but only re-enable them if they were enabled when I entered the block.

I haven't tested it yet and may have a -- in the wrong place or something but the idea is that I disable all interrupts at the start of an atomic block but only re-enable them if they were enabled when I entered the block.

You still need to consider the many and several membar/memory fence instructions if you really want a robust equivalent of cli. You would have to look at what __disable_irq()/__enable_irq() do exactly, but if they simply compile down to the the standard single special register instructions -- CPSID I and CPSIE I -- not enough to fully emulate cli...

As I say, there are some threads on the Leaflabs forum where this was discussed in some gory detail.

if they simply compile down to the the standard single special register instructions -- CPSID I and CPSIE I --

They do, so I've added the three barrier instructions along the lines of what x893 had in one of those threads. As nobody argued his code in the last two months I'm figure it's kosher until I look into this more deeply.

As I understand it though as I'm using an M0 it's not important, but makes the macro pore portable.

I'm using GCC (Code red/LPC Xpresso IDE) so I'll add the ::: memory, I get the need to flush pipelines etc but don't really understand these instructions yet. No matter, meanwhile I'll do do what others have done, shoulders of giants and all that.

If you are using gcc, you should be fine. The "memory" directive tells the compiler not to reorder the assembly instructions with respect to the C code statements in an optimisation step -- at least from from memory.