EndStop Irq e Ramps 1.4

Ho visto le ultime (beh mi pare già da un po') versioni dei firmware hanno la possibilità di mettere la gestione EndStop in modalità Irq (mentre di default è in polling).

Mi risulta che il Mega abbia solo 6 pin che possono gestire (scatenare) gli IRQ e che tali pin non si mappino correttamente su pin usati dal Ramps 1.4 per gli endstop

X-Min : pin 3 => OK
X-Max : pin 2 => OK
Y-Min : pin 14 => NO OK
Y-Max : pin 15 => NO OK
Z-Min : pin 18 => OK
Z-Max : pin 19 => OK

Quindi in teoria l'unica modifica è spostare Y-Min (e Y-Max nel caso si usi), giusto ?
Vicino al connettore endstop, c'è il connettore I2C che ha giusto i pin 20 e 21 che sono Irq Capable, quindi basta spostare il connettore di Y-Min sui pin I2C (prendendo così D20 + GND) e si è risolto.

Ah naturalmente poi nel config firmware va spostata la definizione di Y-Min per usare Digital Pin 20

Giusto così o c'è dell'altro ?
Magari la risposta può anche essere "non si può su Ramps + Mega"

PS
Fatto una prova veloce con MK 4.3.8 ma facendo quelle due modifiche (Irq on e Y-Min su D20) fallisce la compilazione (o meglio la fase di linking)
Quindi o non si può fare o c'è altro da fare nel config.
Provato anche a rimappare Y-Max su D21 ma uguale.

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

Rifatto un testo con il nuovo 4.3.9 ma ancora non va, o meglio non crea il firmware.

Ho configurato i pins come:

#define X_MIN_PIN ORIG_X_MIN_PIN
#define X_MAX_PIN NoPin
#define Y_MIN_PIN ORIG_X_MAX_PIN
#define Y_MAX_PIN NoPin
#define Z_MIN_PIN ORIG_Z_MIN_PIN
#define Z_MAX_PIN NoPin

Che dovrebbe usare solo pins Irq ready e poi ho attivato il flag
#define ENDSTOP_INTERRUPTS_FEATURE

ma così come come era successo sul 4.3.8 anche sul 4.3.9 viene fallita la fase di linking

libraries\SoftwareSerial\SoftwareSerial.cpp.o (symbol from plugin): In function `SoftwareSerial::read()':

(.text+0x0): multiple definition of `__vector_9'

sketch\src\core\endstop\endstops.cpp.o (symbol from plugin).text+0x0): first defined here

c:/arduino/arduino-1.8.9/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions

libraries\SoftwareSerial\SoftwareSerial.cpp.o (symbol from plugin): In function `SoftwareSerial::read()':

(.text+0x0): multiple definition of `__vector_10'

sketch\src\core\endstop\endstops.cpp.o (symbol from plugin).text+0x0): first defined here

libraries\SoftwareSerial\SoftwareSerial.cpp.o (symbol from plugin): In function `SoftwareSerial::read()':

(.text+0x0): multiple definition of `__vector_11'

sketch\src\core\endstop\endstops.cpp.o (symbol from plugin).text+0x0): first defined here

collect2.exe: error: ld returned 1 exit status

Gli errori che ti da sono i soliti warning che devi disabilitare da arduino ide.. Poi una volta disabilitati allora vediamo se escono altri errori

---

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

A che opzione ti riferisci ?

Se intendi "Warning del compilatore" era già su "Nessuno" (e comunque è il linker LD a sollevare il problema)

Se c'è un'altra opzione da cambiare allora non ho capito quale.

Ok fatto qualche ricerca internet e l'errore (che non è un Warning) è dovuto all'uso contemporeaneo della libreria SoftwareSerial e PinChangeInt

La seconda è attivata ovviamente dalla richiesta di avere gli IRQ per gli EndStop e la prima è invece attivata dall'uso dei TMC2130.
Anche se il modello 2130 non usa le seriali (lo fanno altri modelli) la libreria dei TMC include sempre SoftwareSerial creando il conflitto per linker (che si trova due punti di collegamento diversi per una stessa firma di funzione).

Del problema noto da anni, ci sono varie soluzioni proposte sui thread Arduino.

Ci sono anche alcune di richieste di bug-fix pure su Marlin2 aperte a fine 2018.
Apparentemente Marlin2 per ora ha optato per non fixare nulla ma almeno ha messo un sanity-check
Infatti compilando esce il ben più comprensibile errore : "TMCStepper includes SoftwareSerial.h which is incompatible with ENDSTOP_INTERRUPTS_FEATURE. Disable ENDSTOP_INTERRUPTS_FEATURE to continue."

Diciamo che non è il max per gli utenti TMC2130.
Forse sarebbe meglio esplorare le soluzioni di patch proposte.
Dalla brutale disattivazione di SoftwareSerial se si usano solo i TMC2130 al riscrivere il codice per usare librerie che non fanno più collisione pur mantenendo le funzionalità.

I thread generici Arduino consigliano di usare EnableInterrupt al posto di PinChangeInt (considerata deprecata), l'autore delle due librerie pare sia per lo più lo stesso.
Anche per SoftwareSerial sono consigliate alternative (una è NeoSWSerial)

Ok per MK4 come workaround FUNZIONANTE basta aprire il file TMCStepper.h (che va cercato in ...sketchbook\libraries\TMCStepper\src\ non è certo nei sorgenti del firmware) e metterci un
#define SW_CAPABLE_PLATFORM 0
dopo il #define SW_CAPABLE_PLATFORM già presente (ed eventualmente da commentare).

Così si dichiarono tutte le piattaforme non in grando di fare SoftwareSerial e quindi il codice di TMCStepper non lo userà mai.

Poi con questa modifica non so che succederà per gli utenti di driver TMC2208 e TMC2209 (probabilmente dovranno usare solo HW Serial ma non ce ne saranno a sufficienza), ma per gli utenti di driver TMC2130 o degli altri modelli TMC supportati dalla libreria si otterrà che si avrà il build corretto del firmware che ora dovrebbe avere gli EndStop gestiti via IRQ.
Non so come verificare che davvero gli EndStop siano ora via IRQ, però in ogni caso il firmware viene realizzato e se caricato funziona e gli endstop anche.

PS
Nel caso di Marlin2 oltre alla modifica indicata sopra bisogna anche disattivare nel Sanity Check il pezzo:

#if HAS_TRINAMIC && ENABLED(ENDSTOP_INTERRUPTS_FEATURE)
  #error "TMCStepper includes SoftwareSerial.h which is incompatible with ENDSTOP_INTERRUPTS_FEATURE. Disable ENDSTOP_INTERRUPTS_FEATURE to continue."
#endif

c'è un sanity check per ogni piattaforma, quella per il Mega2560 sta in ...src\HAL\HAL_AVR\inc\SanityCheck.h e credo tra l'altro sia pure l'unico Sanity Check che implementi l'errore qui sopra indicato.

Edited 2 time(s). Last edit at 08/20/2019 12:29PM by FabryR.