ARDUINO a 32bit

[ciskje]

Se non ho sbagliato a selezionare le frequenze:

[redfox74]

Se non ho sbagliato a selezionare le frequenze:

Ciao Francesco,
pensavi di prendermi in castagna ? E' ovvio che se fai girare in stack il codice , quindi nella ram va piu' veloce che nella flash interna
Qui il benchmark corretto , la MP32 gestisce due processori il 72 mhz che e' un pochino piu' lento di 8 mhz del PIC , e il 120 , e li andiamo mooolto piu' veloci anche in flash non impiegando la ram.
Sicuramente siamo ad anni luce dall'Arduino Mega non c'e' dubbio.
La MP32 appena disponibile il micro STM32F205 in mass production e' gia' pronta per supportarlo.
Saluti
Roberto

[ciskje]

Ciao Francesco,
pensavi di prendermi in castagna ? E' ovvio che se fai girare in stack il codice , quindi nella ram va piu' veloce che nella flash interna
Qui il benchmark corretto , la MP32 gestisce due processori il 72 mhz che e' un pochino piu' lento di 8 mhz del PIC , e il 120

Hai selezionato l'MX440 invece del MX795 per il PIC32 e se dai il 120mhz (oltretutto con la tecnologia a 90nanometri) allo stesso prezzo del 72 sei un benefattore!
Sulla flash il pic32 ha 0 waitstate come sulla ram (sia lodato il prefetch), sicuro influenzi le prestazioni?

Comunque la decisione di rendere gratuito il compilatore di Microchip è qualcosa di meraviglioso, e denota quanto arduino abbia influenzato il mercato.

In sostanza per 35 euro si ha una scheda di una potenza devastante, con l'interfaccia di rete e la semplicità di programmazione di arduino (premi scarica e lancia).

[redfox74]

Hai selezionato l'MX440 invece del MX795 per il PIC32 e se dai il 120mhz (oltretutto con la tecnologia a 90nanometri) allo stesso prezzo del 72 sei un benefattore!
Sulla flash il pic32 ha 0 waitstate come sulla ram (sia lodato il prefetch), sicuro influenzi le prestazioni?

Comunque la decisione di rendere gratuito il compilatore di Microchip è qualcosa di meraviglioso, e denota quanto arduino abbia influenzato il mercato.

In sostanza per 35 euro si ha una scheda di una potenza devastante, con l'interfaccia di rete e la semplicità di programmazione di arduino (premi scarica e lancia).

Dai Francesco un bel baronpilot Su pic32 Lo vedo bene così riaccendiamo la competizione io con i piccolo non Ho mai avuto un gran feeling preferisco ARM gusti personali

[ciskje]

Dai Francesco un bel baronpilot Su pic32 Lo vedo bene così riaccendiamo la competizione

Ho motori esc arduini vari qui e quintali di sensori a prender polvere... sigh sob. Non farmi piangere.

[redfox74]

@Ciskje,
dai fatti forza che si ricomincia che succede ?
@Jijuja
Ciao Alessandro,
in realta' rispetto all'mk grosse novita' non ce ne sono se non che le potenzialita' dell'arm che sull'mk trovi sulla navy le hai a disposizione anche sulla flight control .
Mk ha un architettura basata sull'approccio multiprocessore .
AVR 644P a 20 mhz fratellino maggiore dei classici arduino per l'assetto.
e un ARM per le funzionalita' piu' evolute di navigazione , return to home ecc.
Diciamo che su di un arm hai piu' spazio per fare quello che vuoi e hai device che ti consentono di avere maggiore precisione sui sensori , il convertitore analogico e' a 12 bit e piu' precisione sui servi il pwm e' a 16 bit quindi 32000 passi contro 127.
La potenza di calcolo e' ovviamente un bel di cui e ti puo' servire per algoritmi un po' piu' sofisticati.
Su MP32 grazie a tutte queste componenti e al processore a 32 bit si puo' mettere tutto quello che c'e' su fc e su navy e avanza ancora spazio
Saluti
Roberto

[ElNonino]

Bella scheda, uso i prodotti Microchip da molti anni per applicazioni professionali e devo dire che mi son sempre trovato bene con i compilatori C proprietari; hanno il non sotto valutabile vantaggio di essere gratuiti e senza limiti di dimensioni, al massimo riducono le ottimizzazioni.

Qualche bug lo si trova nelle librerie originali ma in genere vengono rapidamente risolti dalla casa stessa, inoltre trovo confortevole avere un ambiente di sviluppo unico per tutta la famiglia di micro da 10F a DS33 e 32F supportato da alcuni programmer/debugger universali offerti a prezzi accessibili.

Recentemente ho utilizzato un piccolo DSPic per un lavoro 'volante' ed ho trovato comoda la possibilità di assegnare pin fisici alle periferiche via sw nonchè la buona libreria DSP che ha funzioni di PID, FIR ed IIR decisamente valide.

Questo è il mio giocattolino di preserie:



Quando vedremo una altra schedina basata su Freescale Kinetic ?

[Ingo]

real world

Riflettevo sui risvolti pratici:
Questi proci a 32bit hanno gli adc a 32bit? Domanda banale ma non ho anora guardato, imamgino di si.
sarebbe la vera svolta, soprattutto se esce una imu decente a basso prezzo, quella di diydrones mi ha veramente deluso (solo 3g, sensori survoltati del 10% il che genera inutili drift, molti pin dei sensori che sono fondamentali come la temperatura interna e le uscite amplificate non collegati) e le altre che conosco o costano troppo oppure non risentirebbero molto del passaggio a 32bit in termini di risoluzione (wii per dirne una è in i2c..c'è poco da fare)
Anche se usiamo la imu diydrones con un 32bit non cambia niente a livello di risoluzione, questa cosa mi sturba, volevo parlarne con navoni, se sei qui mi contatti?

[redfox74]

Ciao Ingo,
eccomi ... ma tu sei quello di MK ?!? Nooo se no parleresti solo in tedesco
Allora la risoluzione dei micro a 32bit del convertitore adc e' di "soli" 12 bit , direi comunque piu' che sufficienti rispetto ai 10 bit di arduino standard , questo non ti richiede ad esempio l'uso di un convertitore adc aggiuntivo come accade sulla oilpan.
In merito all'uso dell'i2c come bus digitale di comunicazione nelle nostre applicazioni , dopo diversi test ti posso dire che va bene giusto per i giochini , ma per le cose serie e' meglio lasciar perdere , finche' hai un solo sensore non sofri dei problemi principali che hai di collisioni, le collissioni su un bus troppo popolato ti portano a volte al freeze del micro no buono.
Tutti noi stiamo aspettando la serie inversense MPU6000 con bus spi anzic'he' i2c quello potrebbe essere un bel passo avanti.
In merito alle risoluzioni dei chip e alla oilpan . In che senso ti ha deluso ? Su quella fascia di prodotti non c'e' molto di meglio . A livello costruttivo lascia molto a desiderare sofre molto il problema di chip che si dissaldano ma per problemi di tipo meccanico se continui a toglierla e metterla dalla cpu per esempio.
Le risoluzioni per un volato di quad sono piu' che sufficienti , anzi se fossero piu' alte avremmo problemi a fare lo zero dell'orizzonte a basse velocita' ... i problemi dei drift sono abbastanza normali in questi tipi di chip mems . Per averne meno dovresti usare gyro laser , ma siamo su un'altra classe di costi.
Ti faccio un esempio MK vs OIlpan ,
MK usa sensori con 2g su acc e 3x300 °/S su gyro
il micro della FC MK e'un avr 8 bit che usa gli adc integrati a 10 bit
quindi gli step letti dall'adc equivalgono a
2g/1024 = 0,001
300°/1024 = 0,292
La Oilpan invece usa un convertitore analog 2 spi da 12 bit
quindi usa adc
3g/4096 = 0.0007 g
500°/S / 4096 = 0.122
Quindi diciamo che rispetto al benchmark di mercato fa' molto meglio a livello di fluidita' di rilevamento.
In realta' ci sono problemi di altro tipo come il ritardo di conversione che e' piu' alto rispetto all'uso dell'adc integrato e le compensazioni in temperatura che non ci sono su oggetti di questa fascia anche se a differenza di mk che non ha nemmeno i sensori collegati con il pin temperatura su oilpan lo sono , ma non sono gestiti e in realta' ce ne' solo 1 e non tutti e due.
Non so' se hai visto la vrimu che e' la imu di MP32 , in questa versione io ho cercato di superare i limiti della oilpan e aggiunto i vantaggi della mk impiegando i sensori adxr che hanno una migliore immunita' alle vibrazioni , in realta' il trucco sta li' :
Immunita' alle vibrazioni e compensazione delle temperature.
Per certi versi e' meglio usare i sensori analogici anziche' quelli digitali almeno se parliamo di sensori con bus i2c , perche oltretutto i2c non e' gestito in dma dai micro a 32 bit mentre l'spi si.
Comunque il tema e' complesso e richiederebbe ulteriori approfondimenti
questo e' il link alla mia IMU : VRIMU
VR IMU 1.0 - FOXTEAM UAV CLAN
La prossima settimana sara' pronta anche la versione light , che e' un downgrade della attuale versione per app entry level ma che ha una novita' nell'allestimento base i sensori sono collegati direttamente agli ingressi analogici.
Per contattarmi live .. aggiungi ai tuoi contatti skype virtualrobotix e mi troverai li' ...
Saluti
Roberto

[lol21]

fossi voi in questi giorni terrei d'occhio il blog di arduino in una settimana è prevista una novità (ne aveva parlato Massimo Banzi sul forum ufficiale proprio su un topic di questa scheda 32 bit)

ciao
lol21

[redfox74]

fossi voi in questi giorni terrei d'occhio il blog di arduino in una settimana è prevista una novità (ne aveva parlato Massimo Banzi sul forum ufficiale proprio su un topic di questa scheda 32 bit)

ciao
lol21

Potrei sapere gia' di cosa si tratta ... Appena lui presenta la sua io presento la mia evoluzione di MP32 , gia' in giro c'e' qualcosa ;)
Saluti
Roberto

[merendaiomax]

Ragazzi non si inizia mica a correre dietro al modello nuovo ? Sennò come dice Panariello " ho preso il computer nuovo all'uscita del negozio mi sono accorto che mi mancava il mouse sono rientrato e il commesso mi ha detto che il mouse di quel modello non lo facevano piu perche è uscito il modello nuovo.........."
Saluti

[lol21]

Potrei sapere gia' di cosa si tratta ... Appena lui presenta la sua io presento la mia evoluzione di MP32 , gia' in giro c'e' qualcosa ;)
Saluti
Roberto

presenterà magari un arduino dual core 1GHz snappdragon a 32 bit


magari

ciao
lol21

[Ingo]

Ciao Ingo,
eccomi ... ma tu sei quello di MK ?!? Nooo se no parleresti solo in tedesco
Allora la risoluzione dei micro a 32bit del convertitore adc e' di "soli" 12 bit , direi comunque piu' che sufficienti rispetto ai 10 bit di arduino standard , questo non ti richiede ad esempio l'uso di un convertitore adc aggiuntivo come accade sulla oilpan.
In merito all'uso dell'i2c come bus digitale di comunicazione nelle nostre applicazioni , dopo diversi test ti posso dire che va bene giusto per i giochini , ma per le cose serie e' meglio lasciar perdere , finche' hai un solo sensore non sofri dei problemi principali che hai di collisioni, le collissioni su un bus troppo popolato ti portano a volte al freeze del micro no buono.
Tutti noi stiamo aspettando la serie inversense MPU6000 con bus spi anzic'he' i2c quello potrebbe essere un bel passo avanti.
In merito alle risoluzioni dei chip e alla oilpan . In che senso ti ha deluso ? Su quella fascia di prodotti non c'e' molto di meglio . A livello costruttivo lascia molto a desiderare sofre molto il problema di chip che si dissaldano ma per problemi di tipo meccanico se continui a toglierla e metterla dalla cpu per esempio.
Le risoluzioni per un volato di quad sono piu' che sufficienti , anzi se fossero piu' alte avremmo problemi a fare lo zero dell'orizzonte a basse velocita' ... i problemi dei drift sono abbastanza normali in questi tipi di chip mems . Per averne meno dovresti usare gyro laser , ma siamo su un'altra classe di costi.
Ti faccio un esempio MK vs OIlpan ,
MK usa sensori con 2g su acc e 3x300 °/S su gyro
il micro della FC MK e'un avr 8 bit che usa gli adc integrati a 10 bit
quindi gli step letti dall'adc equivalgono a
2g/1024 = 0,001
300°/1024 = 0,292
La Oilpan invece usa un convertitore analog 2 spi da 12 bit
quindi usa adc
3g/4096 = 0.0007 g
500°/S / 4096 = 0.122
Quindi diciamo che rispetto al benchmark di mercato fa' molto meglio a livello di fluidita' di rilevamento.
In realta' ci sono problemi di altro tipo come il ritardo di conversione che e' piu' alto rispetto all'uso dell'adc integrato e le compensazioni in temperatura che non ci sono su oggetti di questa fascia anche se a differenza di mk che non ha nemmeno i sensori collegati con il pin temperatura su oilpan lo sono , ma non sono gestiti e in realta' ce ne' solo 1 e non tutti e due.
Non so' se hai visto la vrimu che e' la imu di MP32 , in questa versione io ho cercato di superare i limiti della oilpan e aggiunto i vantaggi della mk impiegando i sensori adxr che hanno una migliore immunita' alle vibrazioni , in realta' il trucco sta li' :
Immunita' alle vibrazioni e compensazione delle temperature.
Per certi versi e' meglio usare i sensori analogici anziche' quelli digitali almeno se parliamo di sensori con bus i2c , perche oltretutto i2c non e' gestito in dma dai micro a 32 bit mentre l'spi si.
Comunque il tema e' complesso e richiederebbe ulteriori approfondimenti
questo e' il link alla mia IMU : VRIMU
VR IMU 1.0 - FOXTEAM UAV CLAN
La prossima settimana sara' pronta anche la versione light , che e' un downgrade della attuale versione per app entry level ma che ha una novita' nell'allestimento base i sensori sono collegati direttamente agli ingressi analogici.
Per contattarmi live .. aggiungi ai tuoi contatti skype virtualrobotix e mi troverai li' ...
Saluti
Roberto

Ciao,
ti ho aggiunto su skype.
ho altir problemi con al imu diydrones, l'asse z dell'acc è influenzato dall'y, non ho ancora capito se dipende dall adc o dal acc e ha solo pochi giorni di vita...altra delusione.
comunque ha 6G/4000 hai dimenticato che i 3g sono in 2 versi e comunque alal fine della storia se vai a vedere sei sui 400 scatti per g. a me delude perchè vengo dal LIS3LV02DQ e credimi quando ti dico che mi sento come se fossi passato da un ferrari a una duna, per giunta ho questo problema dell'asse z, se ti va di dargli un occhiata...wrong values acc - DIY Drones

tornando ai 32bit.. io non ho nemmeno un valore che abbisogna di 32bit, gia con difficoltà ho cose a 16, l'unico vantaggio per me è adc a 12bit invece di 11 (mah, prefeisco usare un 16 bit esterno a questo punto) e piu potenza, ma a cosa ci serve realmente il fatto che sia a 32bit? c'è la risoluzione in floating point ma poi alla fine della fiera muoviamo servi e esc che hanno risoluzioni inferiori di diversi ordini di grandezza, è come uccidere una zanzara con un cannone.
concordo con te sull'inutile rigidità dell'accoppiamento tra imu e apm.

[redfox74]

tornando ai 32bit.. io non ho nemmeno un valore che abbisogna di 32bit, gia con difficoltà ho cose a 16, l'unico vantaggio per me è adc a 12bit invece di 11 (mah, prefeisco usare un 16 bit esterno a questo punto) e piu potenza, ma a cosa ci serve realmente il fatto che sia a 32bit? c'è la risoluzione in floating point ma poi alla fine della fiera muoviamo servi e esc che hanno risoluzioni inferiori di diversi ordini di grandezza, è come uccidere una zanzara con un cannone.
concordo con te sull'inutile rigidità dell'accoppiamento tra imu e apm.

Ciao Ingo,
purtroppo mi sa' che ti e' capitata l'ennesima Oilpan buggata , hanno prodotto una partita con difetti , a me me ne erano capitate 3 su cinque che avevo preso da loro prima di entrare in produzione con vrimu.
Penso di aver fatto la scelta giusta cioe' quello di rifare tutto in casa .
Per quanto riguarda i sensori acc e giroscopi io posso usare sia quelli dell'mk che quelli originali del progetto Aeroquad e Diydrones.
Quindi uno puo' scegliere in base a quanto vuole spendere , piu' che sull'accelerometro e' meglio lavorare sul giroscopio.
Per quanto riguarda i 32 bit , mi dispiace contraddarti ma c'e' una bella differenza tra i micro a 8 bit e quelli a 32 .. se guardi i coremark rispetto ad un apm siamo 200 volte piu' veloci rispetto al micro piu' evoluto della mp32 .
Oltre a quello abbiamo 512 kbyte contro 128/256 e 64 kbyte di ram contro penso 16 non ricordo bene , questo lascia spazio a sviluppi e implementazioni successivi senza perdere tempo a continuare a rimpicciolire il codice per cercare di farlo stare nel micro.
Il futuro e' sui micro a 32 bit gli 8 sono destinati a morire , ma e' un trend in atto da almeno 10 anni .. e' solo arduino che ha rinvigorito un po' gli 8 bit .. ma e' stato il canto del cigno ... presto anche arduino abdichera gli 8 per andare a 32.
Le architetture sono piu' moderne e con un colpo di clock fai 4 volte quello che facevi prima non e' acqua ...
Saluti
Roberto