next topic »

[Reply #15 on:]

@astrobeed

http://www.amazon.it/The-Definitive-Guide-Cortex-M3-Newnes/dp/185617963X/ref=sr_1_1?ie=UTF8&qid=1336553881&sr=8-1
 

[Reply #16 on:]

Ora non voglio fare polemica, ancora di più se si tratta di Astro.
La digitalWrite impiega tanto tempo anche perchè fa una cosa che richiede tempo, ora ho un ricordo lontano ma mi pare che legga dalla flash per ricavare i dati delle porte.

Io non credo che il C++ sia tanto più lento rispetto al C, dipende tutto da cosa ci fai e come lo fai, esiste la possibilità di scrivere codice fatto male sia in c che c++, quindi alla fine se si è in grado di scrivere buon codice in c o in c++ le differenze di velocità di esecuzione e minima. Spesso scrivere codice facile da usare comporta una lentezza in esecuzione, arduino core ne è l'esempio. Nota che anche in c può essere usato il paradigma della programmazione ad oggetti. Leggi questo libro http://books.google.it/books?id=UnpIKZmodSAC&pg=PA308&dq=design+pattern+C%2B%2B&hl=it&sa=X&ei=JGeTT8KdL8XP4QT1w8TQDw&ved=0CDkQuwUwATha#v=onepage&q=design%20pattern%20C%2B%2B&f=false

Arm e avr32 possono essere programmati in C++ con le Qt lib di Nokia, tramite l'ide qtcreator e così è possibile scegliere tra tante classi efficienti, certo se usi una lista di mappe ovviamente questo è codice che richiede tempo per essere eseguito, però grazie alle qt le stringhe, mappe e altre classi sono di tipo implicit shared e questo a fronte di un consumo di ram in più porta velocità e flessibilità di uso.

Non ho un arm e neanche un avr32 ma uso le qt da tempo e ne ho studiato il codice interno almeno in parte e se avessi la necessità di usare un arm lo farei con su un kernel linux e le qt.

Ciao.

[Reply #17 on:]

Questa cosa della digitalWrite mi ha incuriosito e sono andato a guardarmi il codice.
La digitalWrite esegue prima una conversione tra numero del pin passato come parametro e pin fisico del micro mediante delle macro, poi nel caso sia un pin agganciato ad un timer, spenge l'eventuale segnale PWM, poi disattiva gli interrupt, modifica lo stato del pin, ed infine riattiva gli interrupt.
Insomma, un bel po' di lavoro. Ecco perché alla fine è così lenta. Ma si tratta tutte di operazioni necessarie per come è strutturato l'Arduino, che è tutto "sui generis" e non deve dare nulla per scontato.

Se io manipolo i pin del micro, sono ad un livello di competenza tale per cui so anche le implicazioni che ha sullo stato del pin la presenza di un segnale PWM. Ma se io non so neanche come lo genero, questo segnale PWM, come posso sapere che se ho un timer agganciato a quel pin, ho un segnale ad onda quadra che esce da lì? Quindi "dietro le quinte" il core mi stacca in automatico quel segnale, mi controlla varie cose e mi fa apparire tutto bello e preciso come voglio io, 0V se metto LOW e 5V se metto HIGH. Ovviamente al costo di diverse operazioni compiute senza che l'utente se ne accorga.

[Reply #18 on:]

In effetti c'è il modo di fare quello che fa la digitalWrite in modo preventivo e poi usare le macro per impostare la porta, questo torna utile quando c'è la necessità di cambiare stato di uno o più bit molto più velocemente di come lo fa digitalWrite.

Cioè si tratta di scrivere codice per fare la cosa in due fasi, ricavi l'indirizzo della/e porta/e e su questi operi con bitwise, questo non significa che digitalWrite è codice cattivo, piùttosto è il reference ad essere pessimo perchè non fa menzione al tempo impiegato da ogni funzione e non spiega come aggirare i vari problemi ecc, e questo mi sta bene anche perchè da modo di publicare libri con buona probabilità di acquisto.

Certo che usare un ARM senza un sistema operativo è compito duro e devi avere un valido motivo per farlo. Su un arm c'è spazio per i thread, processi, eventi ecc.

Chissa se c'è un RTOS per arm in GPL o equivalente?
Ciao. 

[Reply #19 on:]

Cioè mi stai consigliando che sarebbe meglio installare un kernel linux anche sulla SAM3U, che è un microcontrollore?

[Reply #20 on:]

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

[Reply #21 on:]

bha, con la potenza di calcolo che si ritrova direi di NON usare un SO.

[Reply #22 on:]

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.

[Reply #23 on:]

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

[Reply #24 on:]

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

[Reply #25 on:]

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.

[Reply #26 on:]

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.

[Reply #27 on:]

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?

[Reply #28 on:]

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.

[Reply #29 on:]

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.