Go Down

Topic: Dove iniziare per programmare SAM3U (Read 6 times) previous topic - next topic

Janos

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à?

ratto93


@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 ?
Se corri veloce come un fulmine, ti schianterai come un tuono.

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.

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

Quote
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.

@janos
Quote
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.

AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Janos

Cavolo, l'Xmega potrebbe essere un'ottima soluzione... Ci sono già le librerie a bordo per il modbus?

leo72


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

Quote

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
http://www.femtoos.org/
e il FreeRTOS:
http://www.freertos.org/RTOS.html

Quote

Quote
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.

Go Up