Guarda cho ho trovato 
prova a guardare sugli starter kit o sulle education board, hanno prezzi interessanti...
http://www.embeddedartists.com/products/education/edu_2103.php
bha, con la potenza di calcolo che si ritrova direi di NON usare un SO.
Cioè mi stai consigliando che sarebbe meglio installare un kernel linux anche sulla SAM3U, che è un microcontrollore?
No nessun consiglio diretto all'uso di os con il SAM3U, principalmente perchè non ho studiato il datasheet e quindi non posso parlare con cognizione di causa, però prima di studiarlo con l'intenzione di scrivere codice C++ direttamente vaglierei la possibilità di avere uno o più layer, priocipalmente qualcosa che ti permetta di fare programmazione concorrente.
il tipo di layer dipende dall'applicazione ad es un RTOS è sicuramente più rapido di linux e se la velocità (intesa con reattività) è un fattore importante, anche se...... vedi qui http://www.at91.com/linux4sam/bin/view/Linux4SAM dove avevo cominciato a documentarmi.
bha, con la potenza di calcolo che si ritrova direi di NON usare un SO.
Perchè ti sembra scarso?
Ciao.
non vedo il vantaggio dell'uso di un kernel in generale, e solo per avere il multithreading in particolare.
molto meglio delle librerie simil-arduino
Da profano sono dell'idea di lesto... Se devo prendere un processore veloce solo per appesantirlo con un kernel allora continuo ad usare gli atmega... =)
Dico parlo da profano perché per mettere un kernel su un micro non saprei da che parte iniziare... 
@ratto
quelle schede sono veramente interessanti. Per iniziare questa potrebbe essere niente male, monta un micro basato su Cortex M3...
Janos:
Da profano sono dell'idea di lesto... Se devo prendere un processore veloce solo per appesantirlo con un kernel allora continuo ad usare gli atmega... =)
Dico parlo da profano perché per mettere un kernel su un micro non saprei da che parte iniziare...
Sul SAM3U un RTOS puoi metterlo, ne esistono diversi free molto leggeri e molto utili, però pensare di metterci sopra Linux è un suicidio, è troppo lento come micro e la quantità di flash/ram disponibili sono assolutamente insufficienti, è vero che il SAM3U permette di collegare device mappati in memoria fino a 16 mega, però non è la stessa cosa della ram collegata direttamente sul bus dati e address della CPU.
Ho appena finito di leggere molto velocemente tutto il datasheet (circa mezzora a velocità supersonica grazie al fatto che il mio inglese è migliorato).
Non ricordavo molto di questo microcontroller e devo dire che linux ci sta stretto, ma un RTOS credo sia quasi un obbligo, principalmente perchè per fare andare veloce il micro c'è il modo altrimenti si rischia di non sfruttarlo per niente.
Vi assicuro che è molto comlesso gestirlo al meglio, siamo almeno 4/5 la complessita di un ATmega.
C'è la possibilità come dice astro di extendere la RAM fino a 16Mb x 4 e fare operazioni di trasferimento tramite DMA (direct memory access) impegnando al minimo la cpu.
Ogni device integrato ha un suo udi (unique device identifier) da 128 bit.
C'è un timer di sistema, un RTT (real-time timer) con possibilità di registrare l'allarme, un RTC.
C'è qualcosa di simile a protect mode di i386, con 4 livelli, thread mode, handler mode, non privileggiato, privileggiato.
Il kernel ad esempio gira in handler mode e l'applicazione in thread mode.
Due stacks, uno per thread mode e uno per handler mode.
C'è la gestione di eccezioni via hardware.
Gli interrupt con 16 livelli di priorità
Vedi pag 340 per arbitration matrix bus (è nato per un RTOS)
e un mare di altre cose che neanche io sono riuscito a capire come gestire, anche, se non principalmente per questo io userei un RTOS, per evitare di dovere impazzire con il basso livello, lasciando al kernel il compito di fare la gestione sicura del micro.
Poi ci sarebbe da vedere cosa offre la toolchain, se c'è il modulo di libreria thread, e se le eccezioni C++ sono supportate.
Da profano sono dell'idea di lesto... Se devo prendere un processore veloce solo per appesantirlo con un kernel allora continuo ad usare gli atmega... =)
Dico parlo da profano perché per mettere un kernel su un micro non saprei da che parte iniziare... smiley-mr-green
Io penso che devi avere un motivo valido per fare a meno di un RTOS il quale ti offre risposte real-time che sono sufficienti nella quasi totalità dei casi e solo nel caso sporadico in cui la tua applicazione è time critical sempre e continuamente allora devi evitare l'uso di un RTOS e fare tutto a manina sperando che basti.
(discussione interessante)
Ciao.
Sì , discussione interessante. Soprattutto perché siamo arrivati agli RTOS, argomento che mi interessa e non poco 
Entriamo nel merito.
Mettiamo che io abbia un RTOS. Gli RTOS (per lo meno quelli per micro ad 8 bit) so che funzionano a tick, una specie di "finestra" temporale entro la quale il micro cede tutte le risorse ad un processo. Terminato il tempo a sua disposizione, l'RTOS congela lo stato della CPU (i registri e gli stack) e passa il controllo al processo successivo, caricando nella CPU registri e stack congelati precedentemente in modo che l'elaborazione riprenda dal punto in cui è stata interrotta. Fin qui tutto giusto, vero? Correggetemi se sbaglio.
Ora viene la domanda.
Mettiamo che il tick duri (ipotesi) 10 mS. Mettiamo che a circa 8 ms il processo debba leggere da un sensore che, mediamente, risponde in 15 ms. Il processo avvia la lettura e poi, dopo 2 mS, "scade" il suo tempo e l'RTOS lo congela. Che succede alla lettura? Resta a mezzo? Oppure in questi casi esistono delle priorità per cui il processo porta comunque a compimento il suo incarico?
Gli RTOS per 8 bit non possono fare affidamento sull'hardware che invece è presente nel SAM3U, cioè c'è supporto hardware che un RTOS può sfruttare presto e bene.
Però in genere è come hai detto tu, il timer di sistema scandisce il tempo e già il fatto che il system timer è hardware facilita le cose.
Nella maggior parte dei casi si dovrebbe poter risolvere assegnado priorità alta al processo o thread che si vuole più reattivo, ma se anche così non basta o si passa a micro con velocità di clock maggiore o si fa a meno di RTOS.
C'è una cosa che emerge dal datasheet, cioè ci sono buffer hardware su GPIO almeno mi pare di aver capito e c'è anche debounce e triggering hardware sulle porte, quindi se non ho capito male scrivi sul buffer e l'RTOS passa a fare altro il tempo che ritorna a scrivere nel buffer questo ancora non si è svuotato e quindi il flusso di dati è costante.
Poi si può contare sulle operazioni Atomic, se una operazione è atomica l'RTOS non stacca la spina al processo, ti immagini lo facesse mentre scrive su disco.
Ciao.
MauroTec:
Poi si può contare sulle operazioni Atomic, se una operazione è atomica l'RTOS non stacca la spina al processo, ti immagini lo facesse mentre scrive su disco.
Chiaro. Difatti il dubbio sugli RTOS mi sorge sempre se analizzo una situazione in cui devono gestire cose che non hanno una durata breve o prodefinita.
La mia necessità è di leggere un encoder incrementale che viaggi sui 10KHz su 4 fronti (quindi 40000 chiamate ad interrupt al secondo), gestire una comunicazione modbus su RS485, e gestire 4 lame di perforazione con un errore massimo (di tempo) di 120us (devo commettere un errore sull'attivazione delle uscite di non più di mezzo millimetro ad una velocità di 250mt/min). Tutto questo già lo fa l'ATmega2560 ma sono all'incirca sull'ordine dei 260us di tempo ciclo, da qui nasce l'esigenza di hardware più potente ed è per questo che avevo pensato al SAM3U. Dite che con un RTOS riesco a gestire queste velocità?
Janos:
@ratto
quelle schede sono veramente interessanti. Per iniziare questa potrebbe essere niente male, monta un micro basato su Cortex M3...
Già Già, ora sto cercando di capire se serve un Jtag per programmarle o se hanno già tutto a bordo e per il futuro un pensierino potrei farcelo...
Hai valutato l'idea di usare l'ATmega 2560 a 20MHz anzichè 16 ?
Noi siamo abituati ora a pensare ai dual core che in effetti eseguono istruzioni paralelle, ma anche il cortex può fare questo senza essere dual core. Ma prima dei dual core c'èrano i 32 bit e come si faceva a copiare dati da una cartella all'altra senza bloccare la gui, la cache del disco aiuta ma non basta per trasferire 1GB, quindi si deve gestire tutto in base all'hardware che si ha sottomano e neanche se avessimo un quad core potremmo avere la certezza che i tempi vengano rispettati e in tal caso siamo in presenza di applicazioni time-critical e si risolve aumentando la frequenza di clock. Insomma siamo sempre la, la ricetta cambia in base a quello che devi fare, ad esempio pensa ad una stampante laser dove non basta un SAM3U (ci vuole un 300MHZ) ma basterebbe per una getto di inchiostro a bassa risoluzione.
Io come RTOS ho trovato questo http://www.at91.com/component/resource/article/Tools/28-Software/1247-coocox-coosfree-and-open-rtos-specially-designed-for-arm-cortex-mcus.html
Chiaro. Difatti il dubbio sugli RTOS mi sorge sempre se analizzo una situazione in cui devono gestire cose che non hanno una durata breve o prodefinita.
Ok però fammi un esempio.
La mia necessità è di leggere un encoder incrementale che viaggi sui 10KHz su 4 fronti (quindi 40000 chiamate ad interrupt al secondo), gestire una comunicazione modbus su RS485, e gestire 4 lame di perforazione con un errore massimo (di tempo) di 120us (devo commettere un errore sull'attivazione delle uscite di non più di mezzo millimetro ad una velocità di 250mt/min). Tutto questo già lo fa l'ATmega2560 ma sono all'incirca sull'ordine dei 260us di tempo ciclo, da qui nasce l'esigenza di hardware più potente ed è per questo che avevo pensato al SAM3U. Dite che con un RTOS riesco a gestire queste velocità?
Vedi se Xmega ti può essere di aiuto. Vedi il 2560 non ha interfacce specifiche per l'uso che ne devi fare tu, mentre XMega c'è l'ha, anche molti pic hanno questa periferica speciale.
Ciao.
Però prendetevi una pausa tra un post e l'altro così posso postare anche io.
Cavolo, l'Xmega potrebbe essere un'ottima soluzione... Ci sono già le librerie a bordo per il modbus?
MauroTec:
Noi siamo abituati ora a pensare ai dual core che in effetti eseguono istruzioni paralelle, ma anche il cortex può fare questo senza essere dual core. Ma prima dei dual core c'èrano i 32 bit e come si faceva a copiare dati da una cartella all'altra senza bloccare la gui, la cache del disco aiuta ma non basta per trasferire 1GB, quindi si deve gestire tutto in base all'hardware che si ha sottomano e neanche se avessimo un quad core potremmo avere la certezza che i tempi vengano rispettati e in tal caso siamo in presenza di applicazioni time-critical e si risolve aumentando la frequenza di clock. Insomma siamo sempre la, la ricetta cambia in base a quello che devi fare, ad esempio pensa ad una stampante laser dove non basta un SAM3U (ci vuole un 300MHZ) ma basterebbe per una getto di inchiostro a bassa risoluzione.
Una volta, durante la copia, il computer semplicemente si fermava e faceva solo quello. D'altronde era un "compito", e come tale l'utente attendeva paziente che venisse eseguito 
Poi sono cresciute la potenza di calcolo, la memoria, la tecnologia dei SO ed adesso abbiamo anche i filesystem con journaling che, anche se gli diciamo di copiare un file, quelli non te lo copiano subito ma si trascrivono sull'agendina delle cose da fare l'operazione e la compiono non appena hanno un attimo libero, novelle massaie degli anni 2000 XD
Io come RTOS ho trovato questo http://www.at91.com/component/resource/article/Tools/28-Software/1247-coocox-coosfree-and-open-rtos-specially-designed-for-arm-cortex-mcus.html
Io avevo studiato molto il FemtoOS
e il FreeRTOS:
Chiaro. Difatti il dubbio sugli RTOS mi sorge sempre se analizzo una situazione in cui devono gestire cose che non hanno una durata breve o prodefinita.
Ok però fammi un esempio.
L'esempio era quello di prima. Leggere un sensore il cui tempo è superiore al tick a disposizione. Ma abbiamo chiarito.
@janos
Io penso che tu hai ottimizzato le ISR cioè non hai utilizzato attachInterrupt vero?
Comunque penso che con il 2560 che viaggia a 20MHZ e ottimizzando le ISR e anche il resto del codice c'è la fai.
Si XMega ha l'interfaccia encoder. Si ma a quale cose ti riferisci?
L'esempio era quello di prima. Leggere un sensore il cui tempo è superiore al tick a disposizione. Ma abbiamo chiarito.
In ambito RTOS con ARM quello e lavoro da svolgere in handler mode, diciamo in kernel space, sempre se ho capito come lavora ARM.
Ciao.
ehm... ehm ehm.... 
Si perde tanto in prestazioni usando attachInterrupt invece che utilizzare direttamente le ISR? Io pensavo che attachInterrupt non facesse altro che indirizzare un jump alla funzione richiesta...
La attachinterrupt lavora usando un gestore interruppe apposito che è solo su due Pin. Se poi usi questo sistema da isr fai il colpaccio.
Più parli della tua applicazione, che gira tranquilla su Arduino, meno vedo la necessità di sporcarsi le mani con roba in più.
Kiss rule
Janos:
Si perde tanto in prestazioni usando attachInterrupt invece che utilizzare direttamente le ISR? Io pensavo che attachInterrupt non facesse altro che indirizzare un jump alla funzione richiesta...
Infatti la attachinterrupt non fa altro che settare come serve i registri macchina interessati, dopo di che non ha più alcun utilizzo ai fini dell'interrupt, semmai c'è da stare attenti a quello che si fa all'interno della ISR che deve sempre essere molto piccola e molto rapida.
lesto:
La attachinterrupt lavora usando un gestore interruppe apposito che è solo su due Pin.
No, la attachinterrupt ti permette solo di collegare gli interrupt esterni, non usa nessun gestore "speciale", perché tutti gli altri interrupt sono normalmente gestiti dal "sistema operativo" di Arduino e non ti serve toccarli.
Ovviamente nulla vieta di scavalcare la gestione fatta da Arduino e ridefinire le ISR degli interrupt interni, però è una operazione da farsi solo se si hanno ben chiare le idee su come funzionano gli interrupt e come vanno gestiti.