incompatibilità tra core e attiny45

Sto introducendo il core tiny nel core arduino e mi sono accorto che BIN è già definito qui /* avr/iotnx5.h - definitions for ATtiny25, ATtiny45 and ATtiny85 */

Ovviamente, ho compilato senza sopprimere i warning, quindi mi ha segnalato che BIN è stato ridefinito.

BIN viene usato nella funzione Print. Come risolvere?

Ho usato un enum nello scope publico della classe Print.

Ciao.

A parte che non ho capito cosa stai facendo... :sweat_smile:
il core Tiny è un core a sé stante, basato sul core Arduino ma modificato per lavorare sui micro Attiny.

Nella cartella /hardware è infatti inserito in una sua cartella, proprio per non mescolare i file, altrimenti trovi un sacco di doppioni. Durante la compilazione, si sceglie infatti da Tools/Board il tipo di micro contro cui compilare.

Forse tu stai lavorando sulla tua IDE?

/* I/O registers */

/* Reserved [0x00..0x02] */

#define ADCSRB  _SFR_IO8 (0x03)
#define BIN     7
#define ACME    6
#define IPR     5
#define ADTS2   2
#define ADTS1   1
#define ADTS0   0

#ifndef __ASSEMBLER__
#define ADC     _SFR_IO16(0x04)
#endif
#define ADCW    _SFR_IO16(0x04)
#define ADCL    _SFR_IO8(0x04)
#define ADCH    _SFR_IO8(0x05)

Questo è parte del contenuto del file iotnx5.h, questo è parte delle avr-libc, come si vede BIN è un registro è vale 7. Nel core arduino la stessa costante viene definità (ridefinita) è vale 2. Quindi ora il registro BIN vale 2 anzichè 7.

Non ho idea di cosa comporta questo problema, ma sicuramente è da evitare.

A parte che non ho capito cosa stai facendo... smiley-sweat
il core Tiny è un core a sé stante, basato sul core Arduino ma modificato per lavorare sui micro Attiny.

Si mi dai il link da dove prendere il core tiny? Io lo preso da un tuo post, ma ora non ricordo e non so se è quello giusto.
Ho preso il codice del tiny è lo infilato nel core arduino 0021, apportando le dovute modifiche.

Nella cartella /hardware è infatti inserito in una sua cartella, proprio per non mescolare i file, altrimenti trovi un sacco di doppioni. Durante la compilazione, si sceglie infatti da Tools/Board il tipo di micro contro cui compilare.

Forse tu stai lavorando sulla tua IDE?

Si diciamo che non importa cosa sto usando, ma di sicuro non uso L'ide Arduino, ma QtCreator, kate, Gedit ecc, ormai da tanto tempo.
L'importante invece è che abilitando i warning esce fuori l'avvertimento del generato da preprocessore C++.

Io ho risolto così:

class Print
{

private:
    void printNumber(unsigned long, uint8_t);
    void printFloat(double, uint8_t);
public:
    enum formato {Byte=0, Bin=2, Oct=8, Dec=10, Hex=16};
    virtual void write(uint8_t) = 0;
    virtual void write(const char *str);

L'enum formato sostituisce le costanti seguenti
//#define DEC 10
//#define HEX 16
//#define OCT 8
//#define BIN 2
//#define BYTE 0
che contengono la ridefinizione di BIN.

Ciao.

Il è questo:
http://code.google.com/p/arduino-tiny/

ma, ripeto: non puoi mescolarli. Il core Tiny è un duplicato del core Arduino, avrai sempre doppie dichiarazioni.

Ok, il core che avevo è diverso da questo che mi hai linkato, però il problema è sempre presente, perche la classe Print ha ancora quelle define.
Io non ho un micro tiny su cui provare quali sono gli effetti e quando si verificano, tuttavia ridefinire un registro non è buona cosa.

Questo problema non emerge perchè ho integrato il codice in una sola libreria, si presenta anche se compili il core a parte.

L'integrazione si può fare grazie al preprocessore c/c++, es:
#if defined(AVR_ATtiny45) || ecc.

Il codice nella if verrà compilato in base al micro scelto passando l'argomente -mmcu=nomemcu che poi è quello che hanno fatto i programmatori di arduino per fornire supporto per più microcontroller.

C'è una alternativa agli, ed è quella di inserire il nome dei file che cambiano contenuto e attivare la compilazione di quel file solo se il micro scelto lo prevede. Ciò che ottieni e la compilazione condizionale di uno o più file in base alla architettura. Ma questo è un'altro discorso, comunque, si possono fare queste cose con un IDE serio oppure manualmente tramite gli auto-tools, che poi è la tecnica usata da tutto il codice sorgente GNU, tanto che gli auto-tools li hanno creati loro.

Ricordo che dicevi che i tiny hanno un funzionamento anomalo, pensi possa dipendere da questa ridefinizione?

Ciao.

Quando dissi che funzionavano in modo anomalo ero ancora agli "albori" della loro conoscenza :sweat_smile:
Questo perché il core Tiny non ha documentazione e col tempo ho imparato a conoscere i micro e come sono utilizzati dal core solo analizzando i file del core stesso.

PS:
il core Tiny non supporta solo gli Attinyx5, ma anche gli Attinyx4 (Attiny24/44/84) e Attiny2313. Seguendo il tuo schema, devi mettere i controlli anche per essi.

PS2:
non è che forse stavi usando il core di Saporetti e non il core Tiny?

Non so che saporetto ha :), è questo:
http://hlt.media.mit.edu/wp-content/uploads/2011/06/attiny45_85.zip

Trovato nel tuo post "Giocando con l'attiny85".

il core Tiny non supporta solo gli Attinyx5, ma anche gli Attinyx4 (Attiny24/44/84) e Attiny2313. Seguendo il tuo schema, devi mettere i controlli anche per essi.

Si, anche se per adesso sto giocando più che altro per vedere fino a dove posso spingermi con l'IDE QtCreator, per questo stavo compilando varie cose che ho trovato in giro, e ne escono delle belle abilitando i warning.

L'intento sarebbe quello di creare più moduli di libreria. uno di tipo noarch, cioè non dipendente dalla architettura. Es, manipolazione di stringhe, liste concatenate, funzioni matematiche ecc, non dipendono dalle funzionalità del micro. Un più moduli dipendenti dal micro uno per ogni famiglia.
Penso che così sarà molto facile fornire supporto per altri microcontroller sensa toccare le librerie. C'è una cosa che non ho capito, perchè i pin e i registri del micro vengono mappati in flash?. Non riesco a trovare un buon motivo, veramente non mi viene in mente il perchè siano mappati in flash, qual'è il vantaggio?

Comunque ora che ho il core del tiny che mi hai linkato mi concentro su questo, e lasci perdere quello che avevo.

Ciao.

Sì, era quello di Saporetti. Che non va usato perché basato su una vecchia versione dell'IDE.

C'è una cosa che non ho capito, perchè i pin e i registri del micro vengono mappati in flash?. Non riesco a trovare un buon motivo, veramente non mi viene in mente il perchè siano mappati in flash, qual'è il vantaggio?

Questa mi giunge nuova. Nel core Tiny? E dove, scusa? Da quale file capisci questo?

Forse mappati non è il termine più adatto, mi è venuto questo.

const uint8_t PROGMEM port_to_mode_PGM[] = {
        NOT_A_PORT,
        &DDRB,
};

const uint8_t PROGMEM port_to_output_PGM[] = {
        NOT_A_PORT,
        &PORTB,

Un pezzo di codice da "pin_arduino.c"
Per cambiare stato ad un pin tramite digitalWrite c'è un bel passagio un po' contorto:
da digitalWrite:

uint8_t timer = digitalPinToTimer(pin);
	uint8_t bit = digitalPinToBitMask(pin);
	uint8_t port = digitalPinToPort(pin);

queste macro vanno a leggere in PROGMEM.

Probabilmente c'è un valido motivo ma io non riesco a trovarne neanche uno non valido.

Ciao.

L'unico valido motivo che mi viene a mente è quello di ridurre al minimo il consumo di RAM. Altrimenti non si spiega. Forse con 1 pin non cambia nulla, ma quando i pin sono diverse decine (vedi il Mega), la situazione può cambiare, penso io.