mayo ha scritto:Ho già ripetuto 2 volte la reinstallazione dell' IDE. Domanda: potrebbe essere che alcune librerie siano state unite ma compaiono ancora i loro INCLUDE isolati che ne costituiscono una ridondanza che porta all'errore ?
Non conosco in dettaglio l'ambiente di sviluppo citato, ma approfitterei dell'occasione per qualche info di carattere generale sull'argomento linguaggi di programmazione, compilatori, e le cosiddette "librerie".
Il linguaggio di programmazione non è altro che un modo per sopperire all'attuale incapacità delle macchine di capire al volo un discorso diretto in italiano, in inglese o in altro idioma a piacere.
Se le macchine potessero capire direttamente "apri la porta del garage quando piove", non ci sarebbe bisogno di scrivere "LD A, #1", "OUT (25),A", "if (k < 2) { PORTD |= 1 };" e robe simili, e non servirebbe nemmeno un compilatore.
A differenza dell'italiano o dell'inglese, che sono lingue adatte alle persone, una "lingua" adatta alle macchine dev'essere concepita rispettando almeno due regole di base: avere un vocabolario ridotto a pochi termini; non avere ambiguità, cioè non usare parole e regole che possano assumere più di un significato non desumibile dal contesto.
Il problema dell'ambiguità è sentito anche in italiano, e può essere messo in luce già con una frase banalissima come "venti secchi".
Sfido chiunque a stabilire al volo se sto parlando di un'informazione meteorologica o sto citando una voce d'inventario di un negozio di casalinghi.
Anche parole brevi e semplici come "sale" possono indicare locali da ballo o d'attesa; un ingrediente in cucina o in farmacia; un'azione riferita alla Borsa in Piazza Affari o al movimento di un aereo di linea.
Basta oltrepassare le Alpi, e sale diventa sinonimo di sporcizia. Basta oltrepassare la Manica, e sale diventa una vendita.
La necessità di farsi capire dai computer senza usare le convenzioni valide per gli esseri umani ha dato origine ai cosiddetti "linguaggi di programmazione".
I primi grandi computer che costavano cifre altissime erano destinati più che altro all'esecuzione di calcoli aritmetici, e quindi, come linguaggio preferito, usavano il FORTRAN (FORmula TRANslator).
Più tardi i computer son diventati accessibili al pubblico, e qualcuno ha inventato il BASIC (Beginner's All-Purpose Symbolic Instruction Code).
Nel frattempo i computer sono entrati anche negli uffici contabili e commerciali, e qualcuno ha inventato il COBOL (COmmon Business-Oriented Language).
Come primo approccio per ampliare gli orizzonti verso l'astrazione è uscito fuori anche il PASCAL, e per applicazioni più vicine all'hardware e scaturito anche il C.
Ciascun linguaggio ha le sue debolezze e i suoi punti di forza, ma tutti seguono regole assolutamente non ambigue, altrimenti tanto varrebbe tradurre direttamente dall'italiano o dall'inglese.
In pratica, il compilatore è un programma che traduce in blocco un intero discorso prima che la macchina cominci a svolgere i compiti descritti in ciascuna frase.
In quanto programma per computer, anche il compilatore è stato in qualche modo "compilato" prima di poter funzionare, e visto che svolge operazioni molto varie e complesse, è plausibile che dietro abbia il lavoro più o meno coordinato di molte, molte persone.
L'idea che molte persone "smanettino" in simultanea otto ore al giorno sullo stesso, grandissimo, file sorgente è ridicola, quindi la scartiamo a priori.
L'idea che molte persone "smanettino" singolarmente su un proprio piccolo file è già più bella, ma ci espone alla necessità di condividere in qualche modo le informazioni, soprattutto al momento di raggruppare migliaia di pezzi sciolti in un singolo "sorgentone" da compilare.
Uno dei metodi più in voga per raggruppare più sorgenti al momento di compilare è l'inclusione: se so che qualcun altro ha già scritto un pezzo di programma per aprire il garage, e lo ha chiamato "aprigar", invece di procedere al copia e incolla fisico di tutte le righe di "aprigar" posso chiedere al compilatore di fare da solo, semplicemente scrivendo in una riga del mio sorgente l'indicazione "includi aprigar".
Nel caso del linguaggio C, che in genere è (o almeno è stato a lungo) proprio il linguaggio preferito da chi scrive compilatori per linguaggi di programmazione, è prevista la parola "#include", seguita dal nome del file da includere posto tra parentesi angolari o doppie virgolette.
Ora, finché la responsabilità di scegliere come spezzettare i sorgenti è circoscritta, di solito si vedono una o due righe #include in cima al testo principale, ma se il lavoro è sparso in metà globo e coinvolge tantissimi addetti (esempio tipico il sorgente del kernel di GNU/Linux), i pezzi da far combaciare diventano ben presto centinaia, migliaia, decine di migliaia, e il rischio che da qualche parte sorga un'incongruenza diventa inevitabile.
L'incongruenza consiste nel fatto che un file incluso possa a sua volta citarne in inclusione altri, e questi facciano altrettanto fino ad includersi a vicenda, cosa non permessa per ovvi motivi di ambiguità.
L'errore citato nel primo messaggio, "Never include LIBRERIA.h directly; include Usb.h instead" è legato a un'inclusione che non dovrebbe esserci ma c'è, probabilmente a causa di una riga #ifdef o #ifndef che dovrebbe dare un certo risultato ma invece ne dà un altro.
Ho detto in apertura di non conoscere i dettagli dell'ambiente di sviluppo usato, ma immagino che uno "sketch" non sia un sorgente C che viene trattato con un compilatore C, ma qualcosa di molto simile ad un sorgente C che viene trattato da qualcosa di molto simile a un compilatore C.
Se poi nello sketch vengono citate delle funzioni "simil C" che non compaiono altrove in formato sorgente, eccoci a parlare delle famose "librerie".
A dispetto del nome, in informatica una "libreria" non è un negozio che vende libri, ma piuttosto una "biblioteca", ovvero un luogo dove si conservano libri (intesi come fonti d'informazioni) che chiunque può consultare. Il termine inglese d'origine è infatti "library", non "bookshop", e library andrebbe tradotto come biblioteca, non come libreria.
Nomi a parte, anche se in uno sketch non dovessero comparire inclusioni esplicite, e non si vedessero da qualche parte i "corpi" sorgenti delle funzioni citate, prima o poi, in sede di compilazione, le cose devono andare a posto, pena la comparsa di uno o più messaggi d'errore.
Se il processo di compilazione è gestito con dei "makefile" (è una roba brutta che non illustro qui ma invito a decifrare in rete), è probabile che uno di questi stia pensando di operare verso un "target" (microcontroller) diverso dall'attuale, o comunque abbia dei riferimenti diversi dalla realtà.
Il messaggio d'errore a proposito di un'inclusione fuori luogo non viene prodotto dal compilatore vero e proprio, ma piuttosto dal "preprocessor", cioè dal programma che si attiva in automatico prima della compilazione e provvede, fra le altre cose, anche alla verifica di congruenza delle inclusioni.
Purtroppo, se tali inclusioni non sono in vista nei sorgenti perché gestite in automatico dall'IDE, l'unica via percorribile è l'IDE stesso. Non è un gioco di parole: in qualche schermata può esserci una casella che sceglie questo o quel parametro, o questa o quella "libreria" da includere o escludere in base a qualche criterio prestabilito.
Se il problema fosse davvero nella configurazione di default dell'IDE, si spiegherebbe anche perché il sorgente venga accettato senza errori se compilato da altri. Buona ricerca!
Se sbagli perché non sai, commetti un errore. Se sbagli perché non vuoi sapere, ne commetti due.
- da mars