[MK4Duo + Marlin2] Nuovo compilatore Arduino di serie in IDE 1.8.10, dà problemi

Nella nuova IDE c'è di serie il pacchetto AVR 1.8.1 (che comunque vi verrà proposto come upgrade pure se tenete l'IDE 1.8.9 che invece esce di serie con pacchetto AVR 1.6.22 mi pare).

Tale pacchetto contiene GCC 7.3.0 (prima era GCC 4.9.2 se con AVR 1.6.21 o GCC 5.4.0 se con AVR 1.6.22 e 23) ed i firmware per stampanti hanno problemi con esso.

Marlin 2.0 non compila neanche più (errori: non-constant condition for static assertion + reinterpret_cast from integer to pointer), mentre MK4Duo compila ma poi ha problemi di grafica corrotta sul GLCD.

Anche chiedere un downgrade a pacchetto AVR 1.6.23 non risolve perché poi fallisce (su MK4Duo) la fase di linking con errore:
lto1.exe: fatal error: bytecode stream generated with LTO version 6.0 instead of the expected 4.1
Ma questo deve essere un errore come quello qui descritto (ed un bug del downgrade fatto dall'ide): [github.com]

Edited 1 time(s). Last edit at 10/01/2019 09:12PM by FabryR.

Ok il problema di linking è dovuto al file core_arduino_avr_mega_cpu_atmega2560_cca835c6296db4eb3f4b5500ec929c80.a che la compilazione di MK4 genera e che poi ricicla tra le varie build anche quando viene cambiato il compilatore.
Risultato quando cambiate versione di GCC vi trovate in linking un file fatto da un compilatore diverso che non può essere usato.

Basta cancellare quel file (sta nella cartella arduino_cache_numero6cifre che viene creata nella cartella temp, di solito roba tipo C:\Users\VsUtente\AppData\Local\Temp) per farlo rigenerare ed il downgrade (o l'upgrade) di compilatore poi è possibile.

Rimane però il problema che il firmware MK4Duo generato con il nuovo compilatore 7.3.0 ha la grafica LCD corrotta (e chissà che altro, ovviamente non provato seriamente, anche se da seriale sembra funzionare OK nei pochi test di movimento fatti).

Per Marlin rimane (anche con i sorgenti di oggi) il problema di compilazione.
I due errori (cast a ptr da int senza dichiarare reinterpret_cast e static_assert usato con condizione non statica) sono nel file endstop_interrupts.h (dentro cartella HAL_AVR) e sono già stati segnalati anni fa più volte da chi aveva provato a compilare con GCC più recenti (ma mai corretti dato che con il GCC ufficiale funzionava).
Forse ora che il GCC v7 è il default di Arduino 1.8.10 prima o poi proveranno a sistemare, anche se non ci conto molto perché il problema ce l'hanno solo quelli che usano ENDSTOP_INTERRUPTS_FEATURE.

Disattivando gli IRQ per gli endstop, anche Marlin2 compila correttamente con il nuovo compilatore ed anche lui mostra grafica LCD corrotta

Quindi per ora bisogna rimanere al compilatore del package AVR 1.6.23, facendo downgrade (e cancellando le varie cache dentro le cartelle temp) se si installa IDE 1.8.10

Edited 1 time(s). Last edit at 10/02/2019 03:50PM by FabryR.

Grazie... Pensavo fosse la nuova versione 4.4.0 che dava problemi alla grafica del display. Visto che però ci sto ancora lavorando l'avevo messa come cose da fare...
Bisogna capire cosa hanno aggiunto o tolto per dargli problemi...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Probabilmente gli errori del GCC sono delle cose più serie e legate alla compilazione del codice, o meglio alle conversioni implicite che vengono fatte tra tipi di dati,

Una piccola ricerca mi porta a pensare che almeno il secondo errore sia legato al cast di un pointer da un formato di integer sbagliato.

Pointers are 16 bits wide but you are using a 32-bit value like a pointer. That's worth a warning because 16 bits will be lost.

Probabilmente con i vecchi compilatori questi emettevano solo dei warning (che in genere veniva detto a tutti di ignorare) che avvertivano che stavi facendo "cose strane" e che nelle future versioni del compilatore queste "cose strane" sarebbero diventati errori.

MA i warning in genere sono messi perché si sta commettendo qualcosa di "sbagliato" o che può portare ad errori.

Probabilmente nelle istruzioni che generano l'errore si sta assegando un numero ad un puntatore facendo magari "indirizzo locazione di memoria" del tipo int16 sommato ad un numero int32 ma il risultato può portare a degli indirizzi di memoria "non validi" o al peggio "maliziosi" per cui ad esempio se dai ad un puntatore di memoria un indirizzo int32 il compilatore non lo accetta più, magari prima lo troncava ai primi 16bit emettendo un warning.

In soldoni sono la conseguenza di parti di codice che fanno "qualcosa di strano" tipo mutare i tipi in modo implicito e cose simili.

Saluti

Carlo D.

Edited 1 time(s). Last edit at 10/03/2019 07:49AM by onekk.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

Gli errori per Marlin2 (ma anche Marlin1) sono esattamente questi:

reinterpret_cast from integer to pointer sul frammento

#define digitalPinToPCICR(p)    ( WITHIN(p, 10, 15) || \
                                    WITHIN(p, 50, 53) || \
                                    WITHIN(p, 62, 69) ? &PCICR : nullptr )

Non piace il &PCICR

Poi c'è un altro frammento che il compilatore potrebbe segnalare con lo stesso errore (ma probabilmente si ferma al primo errore per tipo)

non-constant condition for static assertion sul frammento

#if HAS_X_MAX
    #if (digitalPinToInterrupt(X_MAX_PIN) != NOT_AN_INTERRUPT)
      _ATTACH(X_MAX_PIN);
    #else
      static_assert(digitalPinToPCICR(X_MAX_PIN), "X_MAX_PIN is not interrupt-capable");
      pciSetup(X_MAX_PIN);
    #endif
  #endif

dice che il contenuto passato alla funzione static_assert non è costante e questo non è ammesso (forse in passato erano warning ora sono error).

Di questi frammenti (il compilatore segnala solo il primo) ce ne sono decine (Min_Pin e Max_Pin per ogni asse, spesso asse doppio tipo X e X2 se non triplo più Z_Min_Probe) ed alcuni utenti per risolvere in passato si limitavano a commentare il blocco.

Ora magari qualcuno (se glielo risegnalano ancora) lo sistemerà prima o poi.
Però purtroppo esce solo a quelli che attivano gli IRQ per gli endstop, sennò passa inosservato il problema.

Edited 2 time(s). Last edit at 10/03/2019 03:01PM by FabryR.

Onekk tu hai ragione i warning sono solo degli avvertimenti che il compilatore ti da per segnalarti qualcosa che secondo lui non va... Ma sono a volte informazioni inutili che io conosco e che l'utente invece no e si spaventa.
Faccio un esempio, creo una funzione

void test(int var) { print var; }

Questa funzione non viene usata mai nel software a meno che non si abilita un #define PROVA_COMANDO_M123 che userà quella funzione... Ecco che il warning mi avvisa che il void test non viene usato da nessuna parte e non lo compila. E per me va bene cosi in questo modo c'è sempre e lo uso solo quando mi serve.
Tu mi dirai mettici un #ifdef PROVA_COMANDO_M123 prima del void cosi quando PROVA_COMANDO_M123 non è abilitato non compila il void, ma immaginiamo che io lo uso per decine di #define diversi dovrei metterci una serie infiniti di controlli tipo
#if define PROVA_COMANDO_M123 || define PROVA_COMANDO_M456 || define PROVA_COMANDO_M789 per attivare il void test...
Invece lo lascio li c'è ma non viene compilato e chissene frega del warning....

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Mago, hai ragione, però per gli errori segnalati presumo che un'occhiata ai casting dei tipi in generale farebbe bene, lo so che è un lavoro lungo e noioso, ma da programmatore a programmatore, va fatto prima o poi.

Specie se vuoi passare a compilatori diversi da quelli che usi che magari sono più "pedanti" su errori di questo tipo.

Il problema però rimane sempre la "genesi" del codice, cioè quando fatto "a molte mani" le scelte di style o sono lasciate ad un unico soggetto che "detta le regole" e revisiona ogni linea di codice oppure incappi spesso in questi errori.

E' una rogna comunque, ma alcune cose si potrebbe fare con appositi programmi di refactorig di codice, in genere gli IDE hanno qualcosa di rudimentale nei "code check" "validate code" o nomi simili, e sono dei delli aiuti, anche se è scoraggiante vedere che ti segnalano 1000 errori di cui 500 perché non hai messo lo spazio dopo la virgola, o perché la riga è più lunga di 80 caratteri.

A volte basta quello per evitare problemi grossolani e grattacapi a non finire per un casting eseguito "male" oppure per una divisione oppure un check di variabile = 0 quando poi il risultato è float che quello 0 può essere -0.000001 oppure 0.000001 è quell'uguaglianza non si verifica mai, in genere in quei casi è meglio mettere < 0.9 e >0.9 per 1 oppure forchette simili per altri check, ma a volte se non puoi salvare i dati in altri modi che in float questi artifizi ti emplificano la vita, io uso un parser di file INI in C# che ahime non ammette valori interi e boleani ma necessità di passare solo float, ovviamente cercando meglio magari avrei trovato una libreria migliore, ma tant'è devi convivere con quello che hai, o che ti puoi permettere (io in genere uso solo strumenti Open Source, per ovvi motivi di "costo").

Ho appena finito di discutere su un forum dove il programmatore principale usa solo Windows, e raramente Linux, cosa che io uso regolarmente, un paio dei miei consigli li hanno fatto comodo, ma sai il punto di vista di due persone a volte permette di raggiungere una visione più "corretta" del problema, semplicemente perché "l'angolo di visione" diventa più ampio.

Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

Quote
FabryR
Gli errori per Marlin2 (ma anche Marlin1) sono esattamente questi:

reinterpret_cast from integer to pointer sul frammento

#define digitalPinToPCICR(p)    ( WITHIN(p, 10, 15) || \
                                    WITHIN(p, 50, 53) || \
                                    WITHIN(p, 62, 69) ? &PCICR : nullptr )

Non piace il &PCICR

Poi c'è un altro frammento che il compilatore potrebbe segnalare con lo stesso errore (ma probabilmente si ferma al primo errore per tipo)

non-constant condition for static assertion sul frammento

#if HAS_X_MAX
    #if (digitalPinToInterrupt(X_MAX_PIN) != NOT_AN_INTERRUPT)
      _ATTACH(X_MAX_PIN);
    #else
      static_assert(digitalPinToPCICR(X_MAX_PIN), "X_MAX_PIN is not interrupt-capable");
      pciSetup(X_MAX_PIN);
    #endif
  #endif

dice che il contenuto passato alla funzione static_assert non è costante e questo non è ammesso (forse in passato erano warning ora sono error).

Di questi frammenti (il compilatore segnala solo il primo) ce ne sono decine (Min_Pin e Max_Pin per ogni asse, spesso asse doppio tipo X e X2 se non triplo più Z_Min_Probe) ed alcuni utenti per risolvere in passato si limitavano a commentare il blocco.

Ora magari qualcuno (se glielo risegnalano ancora) lo sistemerà prima o poi.
Però purtroppo esce solo a quelli che attivano gli IRQ per gli endstop, sennò passa inosservato il problema.

Questi errori sono stati corretti in Marlin a partire dal commit 35b1149d... del 30 Ottobre.

Ora il firmware Marlin 2.0 compila correttamente con il nuovo compilatore GCC 7.3 (anche con gli EndStop Irq).

Rimane però il problema della corruzione grafica.
Per quello nessuno ha segnalato nulla relativo al nuovo Ide Arduino (mi sa che ormai molti lo compilano con Platformio) però ci sono errori simili se non identici su alcune CPU a 32 bit (in particolare LPC1768) ed il tutto sembra dovuto a problemi di Timings.
Ho provato il workaround proposto anche su AVR 8bit + gcc 7.3 ed in effetti risolve il problema e lo schermo LCD 128x64 torna ad essere disegnato correttamente.

Il workaround consiste nel mettere dei Delay aggiungendo sotto a

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

che trovate in Configuration.h in Marlin e Configuration_Overall.h in Mk4Duo, il codice

#define ST7920_DELAY_1 DELAY_NS(125) //these help keep the display from being weird
#define ST7920_DELAY_2 DELAY_NS(125)
#define ST7920_DELAY_3 DELAY_NS(125)

I valori dei delay probabilmente non sono ottimizzati (altri utenti consigliano valori diversi sia più bassi che più alti o si limitano a specificare solo ST7920_DELAY_3) e sono pure quelli consigliati per un processore a 32 bit, in ogni caso funzionano sia su Marlin 2.0 che su Mk4Duo 4.3.9 e non ho perso tempo a provare altri valori.

A questo punto suppongo che il nuovo GCC ottimizzi meglio certe parti di codice rendendole troppo veloci anche su AVR.

In ogni caso adesso (beh già da un po' di tempo) il nuovo compilatore si può usare (se non verranno trovati altri problemi)!

Edited 1 time(s). Last edit at 11/16/2019 01:46PM by FabryR.

Bisogna vedere come vengono eseguiti delay, se si usa il timer interno in teoria dovrebbero dipendere solo dalla velocità del processore, e in nessuna parte dal compilatore, se invece sono emulati via software, a questo punto dipende dall'emulazione se ad esempio erano calcolati a "manina" su un compilatore, non è mica detto che su un altra versione del compilatore, (diversa, anche più vecchia o più nuova), i timing siano identici.

Per risolvere bisognerebbe identificare:

- quale parte del codice calcola i delay, magari la libreria dell'LCD e vedere se facendo un "bug report" allo sviluppatore si ottiene qualche lume.
- se non sia possibile usare ad esempio in fase di init alcuni workaround:
-- ai vecchi tempi avevo visto che alcune emulazioni seriali usavano un trucco in fase di inizializzazione, di impostare un timer fisico e calcolare quanti cicli venivano eseguiti di una istruzione ragionevole e calcolarsi in runtime il tempo necessario per ottenere un certo timing.
-- altri modi potrebbero essere quello di impostare un timer interno ogni 100 ms ad esempio e poi impostare con un interrupt ogni tot e incrementare una variabile che poi viene letta periodicamente da tutte le parti del programma per avere una sincronizzazione precisa, un po' come le variabili di tempo di "rete", se io leggo che un certo messaggio è stato spedito 1234567890 secondi dopo una certa epoca e ora sono 1234567900 secondi vuol dire che è stato spedito 10 secondi fa.

Solo qualche idea a riguardo.

Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

Secondo me senza specifiche non c'erano Delay ma tanto si contava sul fatto che AVR era comunque abbastanza lento da non creare il problema.

Su altre guide, questa volta per AVR, anni fa si indicava che se si avevano problemi di corruzione LCD bisognava decommentare il codice

//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_0_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP

che in realtà non è più presente nei config (e va scritto da zero) e sperimentare con i valori DELAY_0_NOP, DELAY_1_NOP, DELAY_2_NOP, DELAY_3_NOP, DELAY_4_NOP, finché si risolveva.

Io non ho provato i valori in NOP e lasciato quelli in nanosec dei processori 32bit (dove alcuni consigliano 65ns, altri 125ns e alcuni pure 200ns).

Edited 1 time(s). Last edit at 11/17/2019 01:57PM by FabryR.

Grazie per la segnalazione.. Devo indagare... Se avete soluzioni o qualsiasi altro suggerimento postate cosi vedo e magari aggiusto se non dovessi trovare da solo la soluzione...

Per quanto riguarda i warning, quello che ho suggerito, cioè di toglierli in fase di compilazione è per gli utenti, io invece ce li ho proprio per verificare se ci sono warning seri e di errore di programmazione, ma una volta verificati che sono solo avvertimenti inutili o che possono essere bypassati allora li tolgo per portare a termine la compilazione...

Edited 1 time(s). Last edit at 11/17/2019 03:12PM by MagoKimbra.

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse