Buongiorno,
come da titolo vorrei capire se è possibile modificare la variabile appartenente a una libreria senza andare a modificare il file xxxxxxxx.h, per evitare ad ogni aggiornamento di ricordarsi di andare a manipolare manualmente la libreria.
Quindi vorrei intervenire da codice, è possibile ?
Grazie in anticipo. 
Forse si, forse no. Dipende da cosa vuoi modificare, chiarisci meglio, indica quel'è la libreria a cui fai riferimento, cosa vuoi modificare e anche il perché hai necessità di modificare tale valore.
Così al buoi è quasi impossibile rispondere
la libreria è pubSubClient.h, voglio modificare la dimensione massima concessa dei pacchetti inviabili, di default è 128 byte.
// MQTT_MAX_PACKET_SIZE : Maximum packet size
#ifndef MQTT_MAX_PACKET_SIZE
#define MQTT_MAX_PACKET_SIZE 128
#endif
Ovvio basta modificare nella libreria, ma io volevo evitarlo come detto prima.
Sono rimasto generico perché mi era capitato altre volte, di imbattermi in questo "problema" e volevo vedere se esisteva una risposta univoca 8)
Si ma per esperienza a volte si usano termini non corretti. Tu hai indicato la modifica di una variabile mentre è una define .
La risposta è... SI, vedi che la define della dimensione massima del pacchetto è racchiusa in una direttiva di precompilazione? Questa indica alla libreria di definire MQTT_MAX_PACKET_SIZE paria a 128 se non è già stata definita prima (ifndef = if non defined).
nei tuoi programmi puoi mettere come prima riga prima di importare la libreria
#define MQTT_MAX_PACKET_SIZE [DIMENSIONE_CHE_VUOI]
e risolvi 
fabpolli:
... nei tuoi programmi puoi mettere come prima riga prima di importare la libreria#define MQTT_MAX_PACKET_SIZE [DIMENSIONE_CHE_VUOI]e risolvi
... purtroppo, per come funziona l'IDE e per come riarrangia le cose, NON è detto che sempre funzioni, ovvero, NON è detto che mettendo la tua #define prima della #include, l'IDE, in fase di riorganizzazione del sorgente, rispetti veramente la sequenza ... :
Guglielmo
fabpolli:
Si ma per esperienza a volte si usano termini non corretti. Tu hai indicato la modifica di una variabile mentre è una define .
Errore mio chiedo perdono 
gpb01:
NON è detto che mettendo la tua #define prima della #include, l'IDE, in fase di riorganizzazione del sorgente, rispetti veramente la sequenza
Infatti non funziona... altre strade percorribili esistono ? :
Moce993:
Infatti non funziona... altre strade percorribili esistono ? :
Beh ... o NON usare l'IDE ed usare altri ambienti di sviluppo (... ma richiede una certa esperienza) o ... purtroppo mettere le mani dentro la libreria (... che è la cosa più rapida ed indolore).
Guglielmo
Dananto ide >:( con la libreria PJON a me ha sempre funzionato mettere le define prima dela libreria, con questa non va vabbé peccato
La butto lì (perché non l'ho provata): ma mettere la tua #define dentro ad un file parametri.h che includi nella prima riga del file .ino?
Non potrebbe modificare la libreria una volta per tutte facendola andare a prendere il valore di una variabile da lui impostata a piacimento? Dovrebbe cercare MQTT_MAX_PACKET_SIZE e sostituirlo con DIMENSIONE, variabile globale definita nel suo programma. Funzionerebbe?... Oppure aggiungere un parametro quando la chiama.
DOCDOC: Mi sa che come dici tu si avrebbe lo stesso problema dell'ordine non seguito dal compilatore...
Datman:
Non potrebbe modificare la libreria una volta per tutte facendola andare a prendere il valore di una variabile da lui impostata a piacimento?
Mmmm ... potrebbe aggiungere un metodo, che dovrebbe richiamare per prima cosa prima di ogni altra, per passare quel valore oppure, non ho visto come è fatta la libreria, ma se ha un costruttore o un begin() a cui si puô passare un parametro, protebbe forse farlo in quell'occasione ...
... però si perde il fatto che l'OP vorrebbe poter fare la cosa SENZA mettere mani alla libreria 
Guglielmo
Ah, ho capito. Credevo che non volesse dover modificare la libreria ogni volta che la usa secondo le sue esigenze del caso, invece il discorso è diverso!
Datman:
Ah, ho capito. Credevo che non volesse dover modificare la libreria ogni volta che la usa secondo le sue esigenze del caso, invece il discorso è diverso!
eh già, voglio evitare possibili errori/dimenticanze causate dall'aggiornamento delle librerie, ma a quanto pare con l'IDE di Arduino non è possibile.
gpb01:
Beh ... o NON usare l'IDE ed usare altri ambienti di sviluppo (... ma richiede una certa esperienza) o ...
Potrei provare con Eclipse ma dubito cambi qualcosa visto che il compilatore è sempre lo stesso, coretto ?
Moce993:
Potrei provare con Eclipse ma dubito cambi qualcosa visto che il compilatore è sempre lo stesso, coretto ?
NON è questione di compilatore, ma di IDE che, per semplificare la vita agli utenti, nasconde una serie di cose facendole lui ... non sempre come sarebbe meglio fossero fatte.
Non so Eclipse se si appoggia sempre sul IDE di Arduino o meno ... :
Guglielmo
fabpolli:
...con la libreria PJON a me ha sempre funzionato...
sarà forse perché PJON non ha la parte CPP, è solo punto-h
questo mi fa pensare che lo IDE pre-compili i CPP inclusi, prima di "leggere realmente" il programma
ho dato uno sguardo a come si comporta lo IDE, ma secondo me fa cosa strana
ho dato uno sguardo ai file temporanei, e mi sembra proprio dagli orari che crei prima i punto-o compilati dai punto-ccp, e solo dopo il resto
ma ho trovato una incongruenza:
ho usato per prova il mio albaetramonto, fatto qualche tempo fa, mi sono limitato a citare, senza usare, la softserial
ora, se guardiamo i tre file scopriamo una cosa interessante:
lo IDE crea un file "albatramonto.ino.cpp" dove vengono creati ad esempio i prototipi, citata la libreria arduino.h
ma non c'é la main(), e il pre-compilatore non ha ancora lavorato: ci sono ancore le define e le include, li poi si vede benissomo che manca l'espansione della macro X(
in una cartella a parte crea invece: "ctags_target_for_gcc_minus_e.cpp" che credevo fosse l'esito del pre-compilatore, e invece no:
le macro sono espanse, anche la macro X(
ma non c'é traccia della main() ne delle definizione che ci dovrebbero essere nei vari punto-h
non ci sono nemmeno i prototipi, quindi non è la fase successiva alla creazione dei prototipi da parte dello IDE
quindi esiste ancora un "livello" tra IDE -> Pre-compilatore -> compilatore, livello che non vediamo (o almeno io ho perso di vista)
Guglielmo, aiutaci tu....
albatramonto.ino (4.36 KB)
albatramonto.ino.cpp (5.22 KB)
ctags_target_for_gcc_minus_e.cpp (4.5 KB)
... il main() fa parte del "core" e si trova nel modulo main.cpp :
#include <Arduino.h>
// Declared weak in Arduino.h to allow user redefinitions.
int atexit(void (* /*func*/ )()) { return 0; }
// Weak empty variant initialization function.
// May be redefined by variant files.
void initVariant() __attribute__((weak));
void initVariant() { }
void setupUSB() __attribute__((weak));
void setupUSB() { }
int main(void)
{
init();
initVariant();
#if defined(USBCON)
USBDevice.attach();
#endif
setup();
for (;;) {
loop();
if (serialEventRun) serialEventRun();
}
return 0;
}
... è lui che chiama prima la setup() e poi, in una "for" infinita, il loop() e, se definita dall'utente (quella di base è una (weak) vuota), la serialEventRun()
Guglielmo
quindi in realtà il programma principale è questo
il file "xxx.ino.o" verrà linkato dentro li...
ma all'ora loop() e setup() dovrebbero essere dichiarate extern.....
altrimenti non compilerebbe, boh, forse sbaglio
Standardoil:
ma all'ora loop() e setup() dovrebbero essere dichiarate extern.....
NO, ci sono i "prototipi" delle funzioni in Arduino.h che veine incluso ...
...
void setup(void);
void loop(void);
...
... e difatti, se poi tu ometti una delle due funzioni ... il compilatore si innervosisce parecchio
Ricorda inoltre che tutto finisce in un "gran calderone" e tutto viene compilato assieme ...
Guglielmo
comunque ho appena messo a punto un trucco per fare quello che si vuole fare
è un po' sporco, ma permette di rispettare le due prescrizioni originali:
naturalmente c'é uno "sporco trucco"
però, stabiliamo: se funziona e sodddisfa le specifiche non è ne sporco ne trucco
all'ora, visto che nei tempi passati ho avuto occasione ampiamente di scornarmi con persone che fanno del "language nazi" più di me, e che poi fanno assegnazioni inutili di macro eccedenti su test ridondanti....
non sono disposto a mettere in discussione questa tecnica
voglio esplicita assicurazione che che le due o tre persone che in passato mi hanno martellato perché usavo le stringhe "A my manera" o il passaggio di puntatori a costante o simili "acrobazie" che saranno anche "molto sporco trucco" ma ottengono il loro "sporco risultato"
ecco, queste persone non mi "stresseranno l'anima"
Sì/No: grazie
Vogliamo vedere il trucco!