Hi rep8
I could be interested.
What would be really ***nice*** is if you post what you are doing and perhaps how you are doing it.
I picked up Alibre Design a couple of years ago thinking I might get round to do some mech - but my brain wasn't able to make it work thoughI didn't try very hard
Solid products - need a design enclosure that works for the application. Easy to say, but takes a lot of figuring out the application. The experts politely call it iterative design.

Typically a product design starts with the enclosure and the electronics fit to that design - as designers think more of the user and what they want from it, the Smart Designer will start with the enclosure. There is a talk this week
http://www.meetup.com/The-San-Francisco-Internet-of-Things-Meetup/events/118177032/
(http://smartdesignworldwide.com/ - I'm not affiliated, but plan on going to the talk)
A really nice concept is being released by www.electricImp.com - a "SD Card" that has WiFi on it - the SD card format is low cost-  and a fantastic idea to be able to be able to let it be retrofitted layer. The design is simple and very sweet - (disclosure - I hadn't hear of two weeks ago)
So yup, be great to hear about what works for the current designs - maybe what the challenges are - and who knows might feedback into the next generation of XXX - on how to make it work as an application.

These boards are coming out with some simple enclosures -
http://rayshobby.net/ Mega328 board
http://cubieboard.org/  Allwinner ARM A8 with 1Gram + Ehternet +USB Host+HDMI
http://www.alwaysinnovating.com/products/hdmidongle.htm - I think this is Open Source Android HDMI dongle, but maybe not - nice simple concept.

These don't appear to have enclosures yet - roll your own-
http://pinocc.io/  - Mega256RF
http://www.pcduino.com/ - Allwinner ARM A8 with 1Gram +Ethernet+USB HOST+HDMI

so be fantastic to hear what you're process is, what the difficulties are and results pictures etc

If you think of it as its being pitched  ~ the Linux/Liminio side that can do the networking ~ then it becomes really powerful, and only the web interfacing becomes the programmable area.
This can be into the internet - or if  WiFi supports 802.11s - Mesh Networking - then there is a mesh networking.
Also, what might really work is being able to do an HTTP based UI - if a decent java script server can be got running on the YUNs web page.

Another way of doing the same thing - a Arduino board with USB to an OpenWRT device - eg Netgear WNR3500L - its about the same thing.
So instead  http://rayshobby.net/ Atmega328 (or Pi) irrigation controller, it can be relays off a YUN with wireless or wired networking whatever is available, and a more sophisticated mash up of weather information.

The Maker 2013 in San Mateo did show a limitation of WiFi - there was so many SIDs broadcasting - none of them could work .

Looks like some interesting work on USB host - I've had to put my project aside but interested to try this out at some point.

I believe the USB Host powering on external power has some issues - here is my reading of it, see my posts
http://arduino.cc/forum/index.php/topic,140839.0.html
http://arduino.cc/forum/index.php/topic,135399.0.html
http://arduino.cc/forum/index.php/topic,146574.msg1173826.html#msg1173826
I was wondering if there was a place to post this as a bug?

Hi, I'm wondering about the logic for the USB Host port supplying power, and your cct documentation
So just checking if anybody else is seeing this as an issue.

If the USB port is  to be used as HOST  and is to supply power, then there needs to be an external power supply capable of delivering the 0.5A on the USB Host +5V.
The LM2734 is capable of doing that from 7-12V

The comment on UOTGVBOF is I believe accurate - but erroneous in what it should do - the circuit has a bug,  the IC1B/LMV3518 +/- inputs are switched around (easy to do - I've got +/- wrong way round before)
I verified it working with the DUE hardware. There is a software fix for disabling the UOTGVBOF hw processing so that a Vin>7V can be used, but its a kluge and OTG isn't then supported.
It seems to me the "Taijiuino_Pro_ArduinoDue_V1.1" has an approach that works (but I haven't tested the hw), however it doesn't detect in hw if the input drops below 7V

http://arduino.cc/forum/index.php/topic,140839.0.html
http://arduino.cc/forum/index.php/topic,135399.0.html

I guess you need to work through why you would want the features and how you would use it to decide which is the 'best' for you.
If you don't know then just experiment with the lowest cost, as the POE is for specific remote powering.

I found this as well and posted my fix
http://arduino.cc/forum/index.php/topic,134907.msg1144567.html#msg1144567

The fix seems to be change AS6 to be the sames as the arduino-1.5.1r2 in
C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\ARMGCC\3.3.1.128\ARMSupportFiles\Device\ATMEL\sam.h
/* Entire SAM3XA series */
#define SAM3XA_SERIES (SAM3X4 || SAM3X8 || SAM3A4 || SAM3A8)
from
#define SAM3XA_SERIES (SAM3A4 || SAM3A8)

I got it from
\My Documents\Arduino\arduino-1.5.1r2\hardware\arduino\sam\system\CMSIS\Device\ATMEL\sam.h
/* Entire SAM3XA series */
#define SAM3XA_SERIES ( SAM3X4 || SAM3X8 || SAM3A4 || SAM3A8)

Hmm yes I remember I got that problem as well and here is my correction -
The fix seems to be change AS6 to be the sames as the arduino-1.5.1r2 in
C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\ARMGCC\3.3.1.128\ARMSupportFiles\Device\ATMEL\sam.h
/* Entire SAM3XA series */
#define SAM3XA_SERIES (SAM3X4 || SAM3X8 || SAM3A4 || SAM3A8)
from
#define SAM3XA_SERIES (SAM3A4 || SAM3A8)

I got it from
\My Documents\Arduino\arduino-1.5.1r2\hardware\arduino\sam\system\CMSIS\Device\ATMEL\sam.h
/* Entire SAM3XA series */
#define SAM3XA_SERIES ( SAM3X4 || SAM3X8 || SAM3A4 || SAM3A8)

Let me know if that works for you.

Background: The fix is in the AS6 toolchain so it makes me nervous.
I did send it through to Eric Weddington Jan 10th,2013 and though he responded, he didn't say if the fix I proposed was good.
I see from
http://www.atmel.com/tools/atmelstudio.aspx
that there is another release
Atmel Studio 6.1 beta (build 2440)
and 6.1 has an upgraded  ARM Toolchain 4.7.2
from AS 6.0  ARM Toolchain 4.7.0.59 - GCC  4.7.0

Well here is the reference on github.com
git@github.com:neilh10/at91sam3xaz01.git
It incorporates an Arduino compilable port for Atmel Studio 6.
I've ported through Arduino SAM release 1.5.2 (but not run it) but it doesn't incorporate all Arduino SAM libray files. I did download and run tests on a version that had release 1.5.1 - so not that different.
I've  download the github zip file into a temporary directory, and in n AS6.0.1996 opened the project file  sam3xApp01\sam3xApp01.atsln
and then build the solution.
It compiled and linked OK - but I haven't tested it by downloading it through the JTAG.
AS6.0.1996 is the lowest rev  that supports JTAG/SAM-ICE through ATSAM3X JTAG.
It is "As Is" - a development snapshot for unit testing some of the hardware drivers.
See the "ReadMe-AboutThisBuild-SAM3XAZ.docx" - I intend to label any specific differences between my hw and this build as HWSAM3XAZA but not done yet.
Its also my first time through using github.com - and incredibly impressive as it is a fair number of files.
Last time I did such an impressive remote source control was in 2001 with a commerical system called "Continuus" that operated on a private network between two sites and that ended up supporting 50+ working programmers. The simplicity of GIT so far blows me away (though it took about 4 hours to get all of this uploaded). Thanks to all the people contributed to the gitHub online tutorials as well as the git cmd line utility and Git Gui and SSH to work.
Be interested in what you can share about the project you are working on.

My criteria for wanting to use the Atmel Studio IDE with the SAM3X is you've got the lovely exquisitely "just works" Arduino IDE humming and its just taking toooooo long to compile those expanding programs ....
AND you want some symbolics with a JTAG
AND you've read a goodly portion of the SAM3X manual and you really really REALLY want to try out some of those features that are implemented in hardware  with all your other modules
AND using the Arduino IDE & your favourite editor is just so frustrating navigating Arm Toolchain directories

THEN
the Atmel IDE is worth digging into - and its got a very nice helper to dig through all the .h files in the ARM environment to help you.
Also the ASF gives you an idea of what can be done with the hardware, and of course the objective is to write a C++ object to make it all work.
BUT the Atmel Studio is built has its own quirks, built on M$ Studio
and you have to learn (and praise/curse/grin/growl about) the ARM architecture - now why do so many people like it, of yes its common across all the modern processors.
...........a 2cents throwaway

I'll see what I can do. I haven't done much with Atmel DUE port since the post, though I did merge in the 1.5.2 update and it broke some of the hooks. I'd be happy to try and get something going - though might be a few days.
I'm very focused on the USB Host and also low power implementation, so there changes to the Arduino Due approach to support that.
I've also got a rain gauge - tipping bucket that I'm interfacing to an extension board that goes on the DUE + Ehternet board. This is using the Arduino Due framework.

This problem was seen and spotted with a fix at
http://arduino.cc/forum/index.php/topic,135399.0.html
The fix for keeping the power ON (for the native USB port) is  to
in loop(), immediately after the line usb.Task();  add the line
uhd_set_vbof_active_high();
Thanks to stimmer who posted it.
It works as it is turning on native USB power all the time, and there is no fault handling.
It looks to me like it is a DueR3 issue and could be  be fixed in
hardware\arduino\sam\system\libsam\source\uotghs_host.c:UHD_Init()
However, this file appears to be pre-compiled to
hardware\arduino\sam\variants\arduino_due_x\libsam_sam3x8e_gcc_rel.a

FYI I have symbolics working with Atmel Studio 6.0.1996  (released Nov 2012)
So the  toolchain is DUEX powered externally with 9volts,  DUE JTAG connector (10pin 0.05")  -- cable ARM-JTAG-10-10 --(20pin 0.1") Atmel SAM-ICE JTAG emulator to USB port with Atmel Studio 6.0.1966 running on Win XP latest.
The SAM3X has something like 5 hardware breakpoints on chip, and as from AS6.0 Build 1996 supports symbolic decoding,  watching internal variables.
I used it on the USB Host code, Uhi_cdc.c: so haven't tested it on any .cpp yet.
The SAM-ICE JTAG is happier connected directly to a USB port. When it goes through a hub it would periodically get upset.
Even connected directly to a hub sometimes the segger JLINK.exe has an exception.

For a discussion this is pretty good. http://arduino.cc/forum/index.php?topic=77362.0
Seems like the AYEs are with ChibiOS

Hi, I'm having a few issues with turning on power to the Native USB port in Host mode/
I wonder if anybody has this working and if I'm missing something.?
I'm using the  V1.5.1r2 with the Keyboard Controller and referencing the Arduino_DUE_V02b schematic. My board is marked DUE R3
I'm powering the board from a 9V external source.
The voltage coming off F1 power the "Native USB" OTG Host - never turns on.

T1 FDN340P switches the+5V to USBVCC to F1. T1 Gate pin 3 must be pulled low to turn it on from IC1b "GATE_CMD" and effectively seems like it should be wiring ANDing  VIn >6.6V  and the processor UOTGVBOF being active low.
However looking at the schematic - its got some puzzling notes:
"Forces OFF the power supply to USB port when the USB port is in HOST mode (board powered from external power supply)"

I would have thought that the "Native USB" port in HOST mode supplies power to port, and it requires the DUE to be externally powered for this to happen.

What is currently happening, is if  Vin is below 6V6 then IC1B pin 5 is less  than pin6@3v3 which means that pin 7 goes low - switching on T1 .
So it seems to me that  IC1B pins 5 & 6 are the wrong way around. That is when Vin is above 6V6, there is +5V power available to supply the USB Host powering ?
OR am I missing something?

So a simple fix for this rev3 is to set VBUSP0 "0" - its default mode to make  UOTGVBOF high for turning on power to USBVCC.
 It seems like the code is in  uotghs_host.c/h: UHD_init()

Code:

// Signal is active low (because all SAM3X Pins are high after startup)
// Hence VBOF must be low after connection request to power up the remote device
uhd_set_vbof_active_low();

and .h
//! Set USB_VBOF output pin polarity
#define uhd_set_vbof_active_high()            (Set_bits(UOTGHS->UOTGHS_CTRL, UOTGHS_CTRL_VBUSPO))
#define uhd_set_vbof_active_low()             (Clr_bits(UOTGHS->UOTGHS_CTRL, UOTGHS_CTRL_VBUSPO))

Anybody got this working?

Hey good to see the SCoop - I haven't been able to try it out yet - but fantastic to see something published.
I've put a simple multi-loop tasker together myself - based on the TinyOs.net way of doing it. However I haven't had time to be able to test it out or publish.
I look forward to checking out SCoop.
IMHO the value of a co-operative scheduler, is to have a simple move into multi-tasking.
It seems to me the value of pre-emptive schedulers is to be able to do system level heavy lifting - especially for buffered IO process tcp/ip interrupts, and to be able to meet other hard deadlines.  The cost of the pre-emptive scheduler, IMHO, is high in terms of system complexity and maintaining stability.
In a previous life with a 100 realtime software engineers, the Software VP owned the pre-emptive schedulers priorities to stop just anyone optomizing it for their functional systems.  In fact most of the processes ran at the same priority, and just the few processes that were managing the hardware redundancy and I/O had higher priorities.

My experience in software has been to simplify the design and use as simple as possible primitives to implement it. For this type of design event based designing is extremely valuable .  That is encouraging a discussion of what events are coming into the board and what are the outputs.  So having the ability to collect user input in a buffer via an interrupt and then process/schedule a task::loop to parse the input on a terminating  <CR> or '?' is very simple. Very simple primitives - user input collection - and the ability to schedule a task::loop. Also supports the architecture for low power processing.
Wishing everyone a nice seasonal holiday - Cheers Neil