Go Down

Topic: Dove iniziare per programmare SAM3U (Read 7118 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.

MauroTec

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

Quote
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.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Janos

ehm... ehm ehm....  :smiley-roll-sweat: :smiley-roll-sweat: :smiley-roll-sweat: :smiley-roll-sweat:
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...

lesto

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 :)
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

astrobeed


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.


astrobeed


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.


lesto

quello che intendevo è che gli interrupt su tutti i pin sono raggruppati in 3 gruppi da 8, mentre quei 2 pin hano dei registri (e penso delle funzionalità) dedicate. In un altra discussione c'è un PDF che mette a confronto i tempi dell'uso del "gestore generico" dell'interrupt CHANGE su tutti i pin con quello "specializzato" dei due pin, e si dimostrava (con tanto di esempi di codice da testare) che il gestore "specializzato" è quasi il doppio più veloce
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

leo72


quello che intendevo è che gli interrupt su tutti i pin sono raggruppati in 3 gruppi da 8, mentre quei 2 pin hano dei registri (e penso delle funzionalità) dedicate. In un altra discussione c'è un PDF che mette a confronto i tempi dell'uso del "gestore generico" dell'interrupt CHANGE su tutti i pin con quello "specializzato" dei due pin, e si dimostrava (con tanto di esempi di codice da testare) che il gestore "specializzato" è quasi il doppio più veloce

Non ti devi però dimenticare che gli INT esterni hanno una priorità maggiore rispetto agli INT interni (i PCINT) quindi anche l'MCU li esegue con una solerzia maggiore. Poi va vista la circuiteria interna, tieni conto che alcuni interrupt esterni come ad esempio l'INT0 restano attivi anche in diverse modalità di risparmio energetico, probabilmente a causa di una divisione modulare interna differente.

lesto

ah ecco, nei miei post precedenti sostituite "gestore generico" con PCINT e "gestore dedicato" con INT.
cmq il link al PDF, per completezza: http://arduino-pinchangeint.googlecode.com/files/PinChangeInt%20Speed%20Test-1.3.pdf
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

astrobeed


quello che intendevo è che gli interrupt su tutti i pin sono raggruppati in 3 gruppi da 8, mentre quei 2 pin hano dei registri (e penso delle funzionalità) dedicate. In un altra discussione c'è un PDF che mette a confronto i tempi dell'uso del "gestore generico" dell'interrupt CHANGE su tutti i pin con quello "specializzato" dei due pin


Non esiste un gestore generico e uno specializzato degli interrupt, c'è solo una lista di priorità in base al tipo di evento con valenza maggiore per il valore minore nel vettore di interrupt, INT0 e INT1 hanno valenza maggiore di PCINT0-2 e vengono eseguiti prima in caso di eventi simultanei, se arrivano singolarmente non cambia nulla.
La differenza la può fare la ISR dove nel caso di pin generici potresti avere la necessità di capire da quale pin, degli otto possibili, è arrivato l'interrupt,  questo richiede qualche ciclo macchina in più rispetto agli interrupt INT0 e INT1 che possiedono vettori distinti e univoci.

astrobeed


quindi anche l'MCU li esegue con una solerzia maggiore.


No, il tempo di risposta è identico per tutti gli interrupt, da 3 a 4 tre cicli macchina per saltare alla ISR, quello che cambia è solo la precedenza.
Se arrivano in simultanea INT0 e PCINT0 prima viene eseguita la ISR di INT0 e poi la ISR di PCINT0, se PCINT0 arriva da solo il tempo di salto alla ISR è identico a quello della INT0.
La gestione della ISR richiede un certo tempo dato dalla somma di quello necessario per salvare lo stato macchina nello stack, eseguire la ISR, ripristinare lo stato macchina recuperandolo dallo stack.
Mediamente la fase di entrata/uscita dalla ISR e salvataggio/ripristino dello stato macchina richiede circa 1.2 us su Arduino, poi va aggiunto il tempo richiesto dal codice contenuto nella ISR.

Go Up