AVR-CoreLib

MauroTec ti riferisci a questa ?
http://www.nongnu.org/avr-libc/avr-corelib/

Il mio sogno sarebbe un porting delle funzioni arduiniche da C++ a C, mantenendo l'alto livello (l'astrazione) del linguaggio tipico di arduino ?

Sicuro di aver capito bene?
"AVR Core Library (avr-corelib) is a free and open library to make it easier to program in C for Atmel AVR microcontrollers. The focus of this library is to simplify and abstract programming tasks common to many applications, such as communications and . AVR Core Library complements and builds off of AVR Libc at a higher level."

Non mi pare si parli di scassare la parte C++ per fare solo C. Oppure ho capito male quel che intendevi ? :astonished:

non sono sicuro, infatti chiedevo, ma comunque la LIbC e' C, non c'e' C++ dentro, quindi una libreria che rende piu' facile programmare (alza il livello) che parte dalla LIbC sarebbe appunto cio' che nel messaggio (stavolta l'ho corretto io dopo di te :grin:) chiamo sogno.

cioe' fare un porting dellìintero core arduinico in C secondo me e' lavoro immane, non da poco, ma sarebbe utile.
Perche' Arduino ha scelto di scrivere in C++ ?

Mah, tieni conto che alcune cose del C++ sono comode in Arduino.

  1. l'overloading delle funzioni
  2. classi che ereditano altre classi, la qual cosa permette ad esempio di avere la print() su molti oggetti.

viste le limitate capacita' del micro usato in partenza (ATmega8) io sarei partito con un progetto interamente in C, capisco i vantaggi (o meglio li intuisco visto che non conosco C++), ma tecnicamente da piu' parti e' smepre stato detto che il C++ su questi device e' troppo pesante.
Secondo me l'ideatore originale di arduino (non Banzi), aveva conoscenze piu' di C++ che di C e quindi fece quella scelta.
E' stato un peccato averlo perso per strada :frowning:

Il C++ ha molti vantaggi rispetto al C ma li perdi per strada quando ti ritrovi il compilato crescere di centinaia di byte. :sweat_smile: solo che Arduino è semplificazione per i novelli, quindi si paga qualcosa un pò dappertutto con Arduino.

Allo stato attuale, poi, riconvertire il core di Arduino a C sarebbe improponibile.

Testato:
MauroTec ti riferisci a questa ?
AVR Core Library

Il mio sogno sarebbe un porting delle funzioni arduiniche da C++ a C, mantenendo l’alto livello (l’astrazione) del linguaggio tipico di arduino ?

Esatto.

Continua a sognare, perché non si può trasformare in realtà, anzi per me non avrebbe senso. Se scrivessi in C tutto quello che fa il core lib di arduino il codice finirebbe per essere lento e ingombrante uguale, e sarebbe pure più complesso da usare.

Dimmi se ha senso leggere dalla flash la corrispondenza dei pin se desidero efficienza?
Arduino è pensato per essere semplice e non conosco altro modo che quello usato da arduino, cioè nascondere la complessità. Nascondere la complessità significa ridurre la flessibilità.

Quando le risorse sono limitate come quelle di Arduino UNO le librerie preconfezionate sono da evitare. avr-corelib sarà un livello superiore a avr-libc ma non nasconderà la complessità e ridurrà la flessibilità ed efficienza che sono gli obbiettivi principali.

Comunque qualcosa di Atmel c’è già parzialmente pronta, principalmente perché e multi architettura e multicompilatore, parlo della asf di Atmel, date uno sguardo al modo di gestire i gpio e ditemi cosa ne pensate.
Osservate i registri memory mapped di un Atmega e ditemi se da un indirizzo posso ricavare l’accesso tramite una comodo struttura (struct) tramite cast e anche i campi di bit senza creare nulla in memoria.

Questa è parte di quella che uso alle volte io (simile a asf):

#include <avr/io.h>

// Definizione del tipo di argomento GPIO
#define GPIO_T port_t *port, uint8_t bit

// port define
#define GPIOA ((port_t *) &_SFR_IO8(0x00))
#define GPIOB ((port_t *) &_SFR_IO8(0x03))
#define GPIOC ((port_t *) &_SFR_IO8(0x06))
#define GPIOD ((port_t *) &_SFR_IO8(0x09))

// define pin name for atmega164, 324 or 644
//      Name        PORTx,      Bit
#define GPIO_A0     GPIOA,      0
#define GPIO_A1     GPIOA,      1
#define GPIO_A2     GPIOA,      2
#define GPIO_A3     GPIOA,      3
#define GPIO_A4     GPIOA,      4
#define GPIO_A5     GPIOA,      5
#define GPIO_A6     GPIOA,      6
#define GPIO_A7     GPIOA,      7

#define GPIO_B0     GPIOB,      0
#define GPIO_B1     GPIOB,      1
#define GPIO_B2     GPIOB,      2
#define GPIO_B3     GPIOB,      3
#define GPIO_B4     GPIOB,      4
#define GPIO_B5     GPIOB,      5
#define GPIO_B6     GPIOB,      6
#define GPIO_B7     GPIOB,      7

#define GPIO_C0     GPIOC,      0
#define GPIO_C1     GPIOC,      1
#define GPIO_C2     GPIOC,      2
#define GPIO_C3     GPIOC,      3
#define GPIO_C4     GPIOC,      4
#define GPIO_C5     GPIOC,      5
#define GPIO_C6     GPIOC,      6
#define GPIO_C7     GPIOC,      7

#define GPIO_D0     GPIOD,      0
#define GPIO_D1     GPIOD,      1
#define GPIO_D2     GPIOD,      2
#define GPIO_D3     GPIOD,      3
#define GPIO_D4     GPIOD,      4
#define GPIO_D5     GPIOD,      5
#define GPIO_D6     GPIOD,      6
#define GPIO_D7     GPIOD,      7

typedef volatile uint8_t 	reg8b_t;

typedef enum
{
    out_mode,
    inp_mode,
    analog_mode,
    inp_pullup_mode
} pin_mode;


typedef struct
{
    reg8b_t r_pin;
    reg8b_t r_ddr;
    reg8b_t r_pout;

} port_t;

void gpio_modes(GPIO_T, pin_mode mode);

inline void gpio_off(GPIO_T)
{
    port->r_pout &= ~_BV(bit);       // imposta il bit off
}

inline void gpio_on(GPIO_T)
{
    port->r_pout |= _BV(bit);       // imposta il bit off
}

void gpio_set_to(GPIO_T, Bool bit_value);

inline void gpio_set(GPIO_T, Bool bit_value)
{
    (0==bit_value) ? (port->r_pout &= ~_BV(bit)) : (port->r_pout |= _BV(bit));
}

inline void gpio_flip(GPIO_T)
{
    //port->pout ^= _BV(bit);       // inverte il bit di porta out
    // il toggle bit hardware impiega meno codice e fa risparmiare circa 6 byte
    port->r_pin |= _BV(bit);
}

Bool gpio_state(GPIO_T);
Bool gpio_read(GPIO_T);

Allo stato attuale, poi, riconvertire il core di Arduino a C sarebbe improponibile.

Infatti, inoltre lo sviluppo C standard e cosa molto differente dallo sviluppo su Arduino dove non esiste
proprio il concetto di translation unit, in quando il preprocessore mortifica la flessibilità del C/C++ che in ottica arduino user rappresenta una complicazione. Complicato lo è per davvero, non è facile scrivere applicazioni con più moduli e non si impara dall’oggi al domani.

Ciao.

Ho notato ASF tempo fa, devo metterci mano. Il codice da te postato e' proprio quello che intendo, andare oltre quel livello di astrazione non serve, altrimentio appunto c'e' arduino.
Non e' forse una Struct l'antesignana di una classe C++ ?

Ma questa CoreLib non ho capito esiste gia' o no ? la pagina indica

Last updated 10/17/2009

:fearful:

La mailing list è attiva ancora (vedo gli ultimi messaggi che sono di oggi) ma San Google non è riuscito a trovarmi un link da cui scaricare questo avr-corelib.
L'unica cosa che poteva contenere dei file è vuota:

Non vorrei che alla fine siano solo discussioni sulle linee guida del progetto ma che di concreto ancora non ci sia nulla.
Tu hai Avr Studio, no? Imposta un progetto in C puro e scrivi con quello, mi sa che: fai prima; ottieni codice ottimizzato; non hai problemi di supporto :wink:

Esiste e non esiste, come tutti i progetti c'è un'inizio, in cui n programmatori dicono la loro, buttano giù del codice di test, altri osservano è fanno considerazioni, sollevano obbiezioni, apportano modifiche ecc, fino ad arrivare ad avere coscienza di come deve essere strutturato il progetto.

Dai post sembra ci sia la volontà di creare una libreria separata per ogni micro.
Una parte di avr-corelib dovrebbe essere proprio time.h e tutti il resto che ho descritto, che è visibile nel repo che ho linkato. Per il momento non si è scelto di gestire un repositor separato dalla avr-libc e penso per il fatto che al momento non c'è nulla di stabilito con precisione, sicuramente non sono stati assegnati compiti.

La cosa è da seguire altrimenti se non c'è interesse le cose vanno a rilento, capite che gli sviluppatori hanno bisogno di consenso, contributo, critiche ecc. Ho letto velocemente alcune discussioni e mi sembra che il primo obbiettivo sia un driver ISP.

@leo72
Tu se non ricordo male hai qualche nozione di astronomia, vedi se capisci i commenti e il codice nel repositor avr-libc/avr-libc/libc/time at master · vancegroup-mirrors/avr-libc · GitHub
Io vedo che c'è il calendario iso, cioè quello che come primo giorno della settimana ha il lunedi, poi ci sono cose che in 10 minuti non riesco a seguire.

Ciao.

E' una lib con alcune funzioni temporali, ma anche con funzioni astronomiche. Ad esempio calcola il tempo di greenwich dal tempo locale e viceversa, dà il tempo ISO (aaaa-mm-gg hh:mm:ss), gestisce il DST (ora legale), e poi come detto alcune funzioni più prettamente usate in ambito astronomico come sorgere/tramonto del sole, fase lunare, tempo siderale locale.

Qui c'è l'header:

Comunque sono formule molto approssimative, quelle astronomiche. Avranno una precisione buona per uno che deve alzarsi prima dell'alba per andare a cercar funghi o a caccia, non di più. :wink:

Mauro grazie dei chiarimenti
Leo non e’ che io ho AtmelStudio, io uso solo AtmelStudio, da quando l’ho provato la prima volta non l’ho lasciato piu’ XD

E allora non vedo il problema di replicarti in C le funzioni di Arduino che ti interessano ;), di avr-corelib non mi pare ci sia nulla di usabile al momento

Io se potessi AtmelStudio lo proverei anche, ma mi manca windows. Sono curioso circa AtmelStudio, in particolare la gestione di progetti modulari abbastanza complessi, composti da sotto progetti che possono essere librerie specifiche per l'applicazione embedded, applicazioni di test, insomma una struttura di progetto articolata come quelle che uso io, dove nell'ide ci sono più progetti aperti di cui alcuni sono applicazioni per PC che usano una o più librerie di sistema o toolkit. Mi chiedo se genera dei makefile o li devo scrivere a manina (che palle). Come includo le librerie nell'applicazione? Posso creare e gestire repositor git da dentro AtmelStudio?

Di buono c'è sicuramente il debugger, per il resto non so se mi ci ritroverei a lavorare, poi penso che la base di AtmelStudio è eclipse e mi passa la curiosità. :stuck_out_tongue:

E allora non vedo il problema di replicarti in C le funzioni di Arduino che ti interessano smiley-wink, di avr-corelib non mi pare ci sia nulla di usabile al momento

Esattamente, non c'è nulla di più che time, sempre che passi all'interno di corelib, io penso che di time alcune cose dovrebbero rimanere in avr-libc e altre passare in corelib. Staremo a vedere.

@Testato
Perché intanto non ti scarichi asf e inizi a prenderci confidenza e inoltre ci sbirci dentro, visto che ci sono cose interessanti. Uno degli obbiettivi ambiziosi è unificare le api e fino ora sembra ci siano riusciti, certo ARM ha
dei gpio particolari, e anche il resto è molto differente da un atmega, ma sapere che port_t è un tipo di dato presente in tutte le architetture è rassicurante e dovrebbe permetterti di passare da una architettura all'altra
minimizzando la confusione mentale. Per ATmega purtroppo ci sono pochi driver, la seriale c'è, lo stack usb ??
twi mi pare di si, comunque io sono indietro di versione, l'ultima volta che ho provato a scaricare si è corrotto il pacchetto e poi mi scoccia che devo scaricare tutto, se ci fosse un repo git rimarrei sicuramente aggiornato.

Ciao.

leo72:
E allora non vedo il problema di replicarti in C le funzioni di Arduino che ti interessano :wink:

yes, l'interesse per la CoreLib e' semplicemente per risparmiare tempo, se qualcuno ha gia' convertito millis in c perche' reinventare la ruota ? :wink:

Provo a rispondere alle domande di MauroTec per quello che so fino ad ora:

MauroTec:
Io se potessi AtmelStudio lo proverei anche, ma mi manca windows.

Non mi sono mai spiegato questa scelta, e' vero che windows e' ancora il SO piu' utilizzato al mondo, ma i programmatori per loro natura nascono in ambiente Linux, calcolando anche il grande parco Mac, si spiega ancora meno, se non per mero piccolo investimento di sviluppo, che pero' una come Atmel dovrebbe poter sopportare.
C'e' da ricordare pero', e qui rispondo alla domanda successiva, che non deriva da Eclipse (sarebbe stata migliore la situazione per un porting multipiattaforma). AtmelStudio e' semplicemente una veste diversa di Microsoft VisualStudio (infatti se vuoi puoi usare anche direttamente VisualStudio), e qui si spiega la difficolta' di un prodotto multipiattaforma.

MauroTec:
insomma una struttura di progetto articolata come quelle che uso io, dove nell'ide ci sono più progetti aperti di cui alcuni sono applicazioni per PC che usano una o più librerie di sistema o toolkit.

Si, ogni progetto e' organizzato in solutions con una propria estensione (blink.atsln), nella solution puoi integrare sia il sorgente che andra' al micro che magari un programmino che andra' lato PC.

MauroTec:
Mi chiedo se genera dei makefile

Si, fai tutto via GUI, il makefile puoi anche non andarlo ad aprire, se vuoi dargli uno sguardo comunque non puoi modificarlo a mano. Di questo non e' che tutti sono contenti, vedo che molti programmatori non accettano che il makefile non sia modificabile. Per la pace di tutti AtmelStudio permette entrambi i modi lavorativi. Pensa ad esempio ad un gruppo di lavoro, l'importante e' il risultato, non e' che puoi obbligare ad un programmatore di usare AtmelStudio, quindi e' giusto in certi ambiti non usare la funzione di creazione utomatica dei Makefile. Sul lavoro che sto' portando avanti in questi giorni (la mia versione del Transistor Tester, il TestatoTester) sto' usando il Makefile manuale, ma il mio obiettivo finale e' rimuoverlo.

MauroTec:
Come includo le librerie nell'applicazione?

Una delle modifiche che ho apportato al progetto e' stata il passaggio da LCD parallelo ad LCD I2C, per TWI ho usato una libreria open trovata in giro, come "driver" per gestire l'HD44780 via PCF8574 ho modificato una libreria partendo dalla libreria che ho in firma (ulteriore modifica di altra libreria). In definitiva i file .c .h sono integrati nel progetto mettendoli semplicemente tutti nella stessa cartellina, e modificando manualmente il makefile e logicamente modificando/aggiornando tutte le funzioni del progetto originale per usare le nuove chiamate a fuinzione. Ho creato un file di alias intermedio chiamato lcd_i2c in modo da non dover mettere mano ad infiniti file). Cioe' ho fatto tutto a mano, non ho ancora pprofondito se esistono concetti di importazione libreria stile arduino (lasciando da parte ASF che e' tutta altra cosa)

Ti rispondo poi in generale sulla parte ASF:
Non si deve scaricare a parte, e' integrato (almeno nella versione mia attuale la 6.2Beta).
Si il vantaggio e' che si puo' passare da una piattaforma ad un altra piu' facilmente (da un micro ad un altro della stessa famiglia e' immediatissimo), ma di preciso non so altro perche' non ho mai ancora lavorato su altro di diverso da AVR 8 bit.
Da come velocemente ho visto in ASF c'e' gia' TWI-Seriale-Usb.
Come debugger stavo per prendere il dragon quando poi e' uscito un novo modello e sono impantanato, nessuno lo vende ancora, incluso i vari RS-Mouser,ecc. Aggiungici che la Zero avra' il debugger integrato e la confuzione aumenta.
Devo decidere uno standard, visto che il chippino di debug costa poco e che Atmel lo sta infilando dappertutto forse sono sprecati i soldi per un debugger esterno ? Non so a quanto viene venduto il mEDBG (attenzione alla m iniziale), se costa poco si puo' pensare di integrarlo su tutto, ma come filosofia non mi piace.

Tu usi spesso il debugger ? Che modello hai ?

yes, l'interesse per la CoreLib e' semplicemente per risparmiare tempo, se qualcuno ha gia' convertito millis in c perche' reinventare la ruota ? smiley-wink

Per millis o simile c'è time.h di quel repo, che però va configurato per renderlo flessibile, da quello che ho capito al volo, può ricevere gli impulsi da clock esterno (RTCC) o da timer hardware interno al micro. Ricordo di aver visto la variabile __system_time (o simile).

Comunque a parte time.h la millis si può creare facilmente, se specificamente legata all'applicazione è ancora più semplice, se ti interessa pezzi di codice li posso postare poi però li devi adattare tu. Tra l'altro @leo72 ha già scritto la swRTC da cui puoi prendere la ISR per il tick per poi aggiungere la millis e te la fai tu la libreria.

AtmelStudio e' semplicemente una veste diversa di Microsoft VisualStudio (infatti se vuoi puoi usare anche direttamente VisualStudio), e qui si spiega la difficolta' di un prodotto multipiattaforma.

Vero mi sono confuso. Il port di VisualStudio è qualcosa che non ci sarà mai, l'unica cosa che mi manca di windows sono proprio gli ambienti di sviluppo che sono molto semplici, potenti e flessibili, come dire quando vogliono le cose buone le sanno pure fare.

Non si deve scaricare a parte, e' integrato (almeno nella versione mia attuale la 6.2Beta).

Inoltre ho scoperto che c'è il repo git, l'ho scoperto cercando "atmel asf git" http://spaces.atmel.com/gf/project/asf/scmgit/?p=asf;a=tree e dovrebbe bastare dare da terminale bash:

git clone https://anonymous@spaces.atmel.com/git/asf

Ancora non ho clonato ma lo farò.

Tu usi spesso il debugger ? Che modello hai ?

No purtroppo per ATmega niente debug hardware, penso che in qualche occasione sarebbe utile, ma non indispensabile almeno per l'uso classico di debug perché gli ATmega sono abbastanza semplici, mentre per ottimizzare i cicli il debbugger hardware sarebbe l'ideale. Per ARM il debugger hardware è di primaria importanza
perché internamente sono abbastanza complessi, anche il cortex-0 che dovrebbe essere quello più semplice.

Ciao.

Testato:
AtmelStudio e' semplicemente una veste diversa di Microsoft VisualStudio (infatti se vuoi puoi usare anche direttamente VisualStudio), e qui si spiega la difficolta' di un prodotto multipiattaforma.

Difatti Microchip per il suo MPLAB X IDE ha usato Eclipse e gira su ogni piattaforma. Io l'ho usato su Linux e Mac senza differenze. Ma Microchip fornisce anche i compilatori per le 3 piattaforme, mentre Atmel di suo credo che fornisca il compilatore solo per Windows. Per Linux e Mac il compilator è mantenuto da Gnu.

Comunque a parte time.h la millis si può creare facilmente, se specificamente legata all'applicazione è ancora più semplice, se ti interessa pezzi di codice li posso postare poi però li devi adattare tu. Tra l'altro @leo72 ha già scritto la swRTC da cui puoi prendere la ISR per il tick per poi aggiungere la millis e te la fai tu la libreria.

Alla fine è una cosa banale. Se andate a vedere in quel mega-thread sulle MCU non Atmel, nelle prime pagine (prima che si riempisse di spam) avevo messo anche i miei test sui PIC dove avevo ricreato la millis con veramente poche righe di codice.

Ottimizzare per uno specifico progetto è il modo migliore per rendere il codice supersnello. Arduino in questo aiuta i neofiti ma infila nello sketch centinaia di byte di roba inutile.

Si ricordo il post in questione e anche il codice.

Ottimizzare per uno specifico progetto è il modo migliore per rendere il codice supersnello. Arduino in questo aiuta i neofiti ma infila nello sketch centinaia di byte di roba inutile.

Io è da un po che scrivo le applicazioni dividendola in libreria e applicazione e capita spesso che qualche parte di libreria può essere unita ad una solo libreria generica che offre varie alternative, es la seriale bufferizzata (comoda ma alle volte…) la seriale non bufferizzata, le gpio funzioni, macro e inline così nell’applicazione decido cosa usare per fare la stessa cosa, la twi senza buffer e quella con il buffer e gli interrup, abiltare o meno il timeout su seriale o twi ecc.

Solo che mettere tutto insieme e curare la documentazione non mi è ancora riuscito e forse non mi riuscirà mai.

Ciao.