Limiti C++ con Arduino

Salve

Devo programmare Arduino in C++ in quanto DEVO creare oggetti (quindi tutta programmazione object oriented). Leggendo sul forum e sulla rete, tempo fa aprii già un post sul vecchio forum: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1280152007

Cito MB: Arduino supporta un sottoinsieme del C++ (per esempio le classi sono supportate, la maggior parte delle librerie sono classi)

Circa questo link è stato scritto: questa frase "Obviously, none of the C++ related standard functions, classes, and template classes are available." indica che non sono disponibili le funzioni, classi e template che vengono di solito fornite con il c++ però il concetto di funzioni, classi e template sono disponibili

Sono un pò confuso sulla questione C++ e non riesco a trovare documentazione se non testando in prima persona i limiti (un pò pesante come cosa).

Qualcuno che ha avuto esperienza con C++ su Arduino sa farmi luce? Anche qualche link è gradito :)

grazie a tutti

Il C++ puoi sicuramente usarlo in micro quali il FEZ Domino o Panda oppure il NET Duino :) io però non ho mai visto ne utilizzato programmi scritti in oo in arduino :( mi dispiace....

ratto93: Il C++ puoi sicuramente usarlo in micro quali il FEZ Domino o Panda oppure il NET Duino :) io però non ho mai visto ne utilizzato programmi scritti in oo in arduino :( mi dispiace....

confondi col C# ;)

Da qualche parte ho letto che si può usare il C++ non vorrei dire stupidate però :) controlla potrei sbagliarmi....

ratto93: Da qualche parte ho letto che si può usare il C++ non vorrei dire stupidate però :) controlla potrei sbagliarmi....

Hai letto bene, ma come dicevo prima, non è pientamente supportato e vorrei capire, con il vostro aiuto, quali sono i limiti.

A "naso" direi che tale affermazione è corretta. Saranno disponibili le librerie indipendenti dalla piattaforma hardware, ossia ad esempio non potrai usare su un Atmega una libreria per l'input/output da terminale dato che l'Atmega non è un computer e conseguentemente non può gestire l'input da tastiera :D

Io immagino che i limiti citati si riferiscano a cose come queste.

skaxxo: Devo programmare Arduino in C++ in quanto DEVO creare oggetti (quindi tutta programmazione object oriented). Leggendo sul forum e sulla rete, tempo fa aprii già un post sul vecchio forum: http://www.arduino.cc/cgi-

Le parole "devo" e "c++" non vanno per nulla d'accordo con le piccole mcu, devi tenere ben presente i limiti hardware di questi micro, sono solo degli 8 bit RISC, hanno pochissima ram e pochissima flash, per giunta tra loro fisicamente separate, non hanno il dma e tutti i sistemi di indirizzamento presenti sui microprocessori di classe superiore. Volersi incaponire ad usare il C++ con questi micro è solo volersi fare del gran male, usa il C ANSI e vedrai che tutto funziona benissimo, anche perché l'architettura è ottimizzata per tale linguaggio.

astrobeed: usa il C ANSI e vedrai che tutto funziona benissimo, anche perché l'architettura è ottimizzata per tale linguaggio.

Grazie mille. Penso che di fare dietrofront e programmare in C.

Il mio "devo" era riferito al fatto che avevo alcune idee da voler realizzare ma davo per scontato che Arduino supportasse pienamente C++.... devo ri-ri-riprogettare le mie idee ;)

skaxxo: Il mio "devo" era riferito al fatto che avevo alcune idee da voler realizzare ma davo per scontato che Arduino supportasse pienamente C++.... devo ri-ri-riprogettare le mie idee ;)

Il compilatore usato, che è il GCC, ovviamente supporta il C++, è il micro che non è adatto per la programmazione C++. Vai benissimo con il C ANSI dove puoi fare tutto quello che ti pare, anche giocare low level con l'hardware e includere, se necessario, istruzioni assembly per ottimizzare al massimo le funzioni time critical. Per programmare in C ti consiglio di lasciar perdere l'IDE di Arduino e passare a AVR Studio, è free pure lui ed è l'ambiente di sviluppo ufficiale di Atmel.

Le classi di C++ sono supportate a pieno, non è supportato il casting dinamico degli oggetti, e quindi invece di fare

Oggetto *o;
...
o = new Oggetto();

dovrai accontentarti di

Oggetto o;

Una alternativa può essere quella di riscrivere le operazioni di allocazione dinamica della memoria (malloc) in questo modo:

#include <stdlib.h> // for malloc and free
void* operator new(size_t size) { return malloc(size); }
void operator delete(void* ptr) { free(ptr); }

Spero di esserti stato utile… Comunque non è molto consigliabile giocare con malloc e free sulle architetture Harvard, in quanto la loro particolarità è di tenere ben separati dati (ram) e istruzioni (flash), a differenza dei processori con architettura di Von Neumann che hanno dati e istruzioni insieme in ram (pc-like).

La parziale compatibilità col C++ deriva (l’ho testato a mie spese XD) soprattutto da queste differenze architetturali.

Arrivederci

seppe

seppe: Le classi di C++ sono supportate a pieno, non è supportato il casting dinamico degli oggetti,

Spero di esserti stato utile... Comunque non è molto consigliabile giocare con malloc e free sulle architetture Harvard, in quanto la loro particolarità è di tenere ben separati dati (ram) e istruzioni (flash), a differenza dei processori con architettura di Von Neumann che hanno dati e istruzioni insieme in ram (pc-like).

E' qui che non capivo: che senso ha avere il supporto pieno di classi quando poi non hai abbastanza memoria per allocare dinamicamente oggetti?

Alla fine mi son deciso di scrivere tutto su SD e fare molti accessi in memoria (SD).

Per quanto riguarda AVR-Studio, si è vero, credo che sia un ottima IDE per fare programmi un pò più impegnativi però, mi sembra di capire, che dovrei configurarlo a puntino per adattarlo ad arduino e poi capire come fare l'upload automaticamente...

Spero che prima o poi qualcuno faccia un plugin per eclipse.... sapevo che era in progetto da tempo... speriamo!

skaxxo: Per quanto riguarda AVR-Studio, si è vero, credo che sia un ottima IDE per fare programmi un pò più impegnativi però, mi sembra di capire, che dovrei configurarlo a puntino per adattarlo ad arduino e poi capire come fare l'upload automaticamente...

Non devi configurare nulla, basta che scegli come micro di lavoro l'ATmega328p e sei a posto, le librerie di base sono sempre quelle della AVRlib che trovi assieme a AVRgcc (si trova tutto dentro WinAvr), cioè le stesse usate da Arduino. Ovviamente non hai le funzioni "pappa pronta" messe a disposizione da wiring, anche se volendo molte cose puoi facilmente importarle partendo dai sorgenti acclusi all'IDE di Arduino. Per il discorso programmazione devi usare AVRdude da riga di comando, l'emulazione STK500 del bootloader di Arduino non è riconosciuta come valida dal supporto integrato in AVRstudio, ma basta che ti fai un file batch, che puoi pure lanciare direttamente da AVRstudio, e il problema è risolto.

seppe:
Le classi di C++ sono supportate a pieno, non è supportato il casting dinamico degli oggetti, e quindi invece di fare

Oggetto *o;


o = new Oggetto();




dovrai accontentarti di



Oggetto o;




Una alternativa può essere quella di riscrivere le operazioni di allocazione dinamica della memoria (malloc) in questo modo:



#include <stdlib.h> // for malloc and free
void* operator new(size_t size) { return malloc(size); }
void operator delete(void* ptr) { free(ptr); }




Spero di esserti stato utile... Comunque non è molto consigliabile giocare con malloc e free sulle architetture Harvard, in quanto la loro particolarità è di tenere ben separati dati (ram) e istruzioni (flash), a differenza dei processori con architettura di Von Neumann che hanno dati e istruzioni insieme in ram (pc-like). 

La parziale compatibilità col C++ deriva (l'ho testato a mie spese XD) soprattutto da queste differenze architetturali.

Arrivederci

seppe

Anche i pc utilizzano una architettura Harvard per migliorare le prestazioni utilizzando stadi multipli di pipeline, solo che la separazione tra memoria istruzioni e dati è a livello della memoria cache…

Sei sicuro che i dati sono caricati in sram e le istruzioni vengono lette direttamente dalla memoria flash? Io pensavo che la eeprom fosse più lenta e perciò la sram venisse utilizzata anche come cache istruzioni. In effetti le memorie sram sono generalmente usate come cache…

Uhm... stai facendo un po' di confusione coi tipi di memoria. La EEPROM contenuta nel micro serve come memoria non volatile, non contiene il codice. Il codice utente è contenuto invece nella Flash, anch'essa non volatile ma più facile da riprogrammare. Le variabili vengono invece create nella SRAM, perché è volatile (spento il micro, i dati vanno via) e perché non ha un limite di scritture come invece ha la Flash.

leo72: Uhm... stai facendo un po' di confusione coi tipi di memoria. La EEPROM contenuta nel micro serve come memoria non volatile, non contiene il codice. Il codice utente è contenuto invece nella Flash, anch'essa non volatile ma più facile da riprogrammare. Le variabili vengono invece create nella SRAM, perché è volatile (spento il micro, i dati vanno via) e perché non ha un limite di scritture come invece ha la Flash.

dunque:

eeprom -> bootloader flash -> programmi utente sram -> variabili dei programmi utente

giusto?

no

skaxxo: dunque: eeprom -> bootloader flash -> programmi utente sram -> variabili dei programmi utente

Il bootloader si trova nella flash in una apposita area riservata. La EEPROM la puoi paragonare ad una sorta di hard disk dove metti i dati che non devono essere allo spegnimento o in seguito ad un reset.

astrobeed:

skaxxo: dunque: eeprom -> bootloader flash -> programmi utente sram -> variabili dei programmi utente

Il bootloader si trova nella flash in una apposita area riservata. La EEPROM la puoi paragonare ad una sorta di hard disk dove metti i dati che non devono essere allo spegnimento o in seguito ad un reset.

non sapevo dell'esistenza di questa eeprom... potrebbe tornarmi utile. grazie

Attenzione che ha una vita di 100.000 scritture, quindi va bene per mantenere dati stabili nel tempo ma non per frequenti riscritture.

leo72: Attenzione che ha una vita di 100.000 scritture, quindi va bene per mantenere dati stabili nel tempo ma non per frequenti riscritture.

cavoli...