Visualizza messaggio singolo
Vecchio 17 settembre 12, 10:52   #19 (permalink)  Top
qpidgiga
User
 
Data registr.: 10-07-2009
Residenza: pesaro
Messaggi: 415
Citazione:
Originalmente inviato da romoloman Visualizza messaggio
Dipende... linux embedded real time si presta bene allo scopo...
Oltretutto proprio la presenza di un multitasking ben gestito può facilitare i compiti separando task critici e task secondari in modo che qualora qualcosa debba andare storto in un task sia lo stesso S.O. a prendersi cura della disallocazione delle risorse e del riavvio dello stesso.
Proprio la capacità di settare le priority in modo efficacie consente di gestire con maggior sicurezza le cose.
Certo esistono anche microkernel realtime tipo freertos o cooxos per gestire le stesse cose, ma rimane la problematica delle periferiche che si intendono gestire.
Non ti dico cosa non stiamo penando per implementare un USB Mass Storage Device su un processore ARM.
Con linux il gioco sarebbe bello e fatto separando in modo estremamente efficace la parte utente da quella kernel.
Ciao, mi dispiace ma non hanno ancora sviluppato un kernel real time per raspberry pi (ma sembra che qualcosa si stia muovendo), questa cosa mi disturba perche' mi interessava un porting di linuxCNC che pare per ora non ci sara'.
Accoppiare un raspberry pi a arduino (o un microcontrollore a propria scelta) non e' una cosa completamente errata, l'interfacciamento via GPIO ha latenze tali (e non sempre prevedibili) che in mancanza di un kernel + librerie realtime rende problematico un controllo affidabile di un modello "volante".
Sto seguendo con attenzione il progetto di un inglese che vuole realizzare un Unmanned Surface Vehicle marino utilizzando di base un raspi, il progetto e' in avanzamento ed e' consultabile sul sito FishPi | An autonomos drop in the Ocean, e basa la "mente" del modello su questa interfaccia, l'interfacciamento a servo e regolatori tramite scheda servo i2c e il gps sulla uart del gpio. Tutti collegamenti sono "asincroni" quantomeno non hanno temporizzazioni critiche.
Un microcontrollore dedicato alla navigazione si presta meglio a questa gestione, finche il raspi non gli trasmette variazioni lui continua imperterrito, demandando i calcoli piu' complessi come il calcolo della rotta, lo streaming di 2 o 3 webcam a risoluzione standard e presto anche Computer vision per evitare collisioni.
Stavo verificando la possibilita' di interfacciare due o piu' atmega328 su bus i2c per la gestione di servi, sensori e gps e allo stato attuale risulta fattibile (pur non essendo una cima in elettronica e programmazione).
Il raspi ha la straordinaria caratteristica di mettere a disposizione 7 porte IO digitali (23 se non si ha bisogno di bus i2c e spi) ma a mio avviso allo stato attuale non sono pratiche come quelle di un microcontrollore; apparte i problemi di latenza manca un supporto per la conversione analogico/digitale e c'e' solo una porta pwm.
Fortunatamente siamo solo agli inizi e come piattaforma promette molto bene, aspetto fiducioso che queste lacune vengano colmate.
Saluti
Alex
qpidgiga non è collegato   Rispondi citando