Una centrale digitale scritta in Rust su ESP32

[cc90202]

Buongiorno a tutti, mi chiamo Cristiano Chieppa e sono un appassionato di modellismo e un developer di professione. Da tempo sviluppo in linguaggio Rust e ho voluto coniugare la mia professione con la passione e a Natale 2025 ho iniziato a scrivere la mia centrale DCC+Railcom fatta in casa. Devo dire che è stata una bella sfida, soprattutto il railcom che mi ha fatto sputare sangue. Non sono un ingegnere elettronico e ho chiesto consigli ad amici che fanno questo di professione.
Oggi la scheda è su breadboard (brutta a vedersi perchè è piena di jumper, visto gli integrati usati). Ma sto facendo un PCB. Per chi è mastica di sw il progetto è totalmente open source e lo trovate qui: https://github.com/cc90202/DCC-esp32

Ho anche implementato il protocollo (di dominio pubblico) di comunicazione Roco Z21 basato su UDP cosi che la centralina funziona in LAN comandata dall'app Z21 senza dover inventare l'acqua calda.

L'hw utilizzato oggi consta di un esp32-c6 (mini), un ponte H DRV8874 che funge da driver di potenza, un 74hc08 che mi serve per il corto railcom, un inverter 74hc14 per la DCC invertita e il comparatore LM339 per convertire le microcorrenti railcom in bit che vanno sulla UART di ESP.

Ad oggi ho testato diverse motrici Trix e Roco e una Rivarossi e hanno funzionato.

Ho iniziato a implementare la parta OTA (fw update). Appena ho dei momenti liberi provo a terminare.

Saluti

[Buddace]

Benvenuto complimenti per il progetto e la dedizione e ...buon lavoro!
Vorrei più post come questi su questo forum;)

[Fidax]

Ciao, gran bel progetto! Hai preso in considerazione di valutare un ESP32-S31 (https://documentation.espressif.com/esp ... eet_en.pdf) ? E' un dual core, RISC V, da 320MHz, potrebbe darti ulteriore margine per aggiornamenti firmware futuri

[cc90202]

Si, è qui davanti a me
In realtà ho voluto iniziare da una scheda piccola cosi da testare la bontà di tutto lo stack Rust + Embassy e la backpressure dovuto a una ottimizzazione del codice.

Adesso sono alla prese con un PCB che vorrei avere una scheda e non una breaboard incasinata per ovvi motivi di cablaggio.

ieri ho fatto girare iCE4 di trix ed è andato senza problema alcuno. Peccato che non sia railcom...

[Buddace]

Curiosità, come gestisci l'eco dei comandi locomotiva inviati da dispositivo wifi?

[cc90202]

Ciao, partiamo da un passo prima. I comandi normali vengono inviati a intervalli di tempo regolare. Ad esempio la velocità viene inviata ogni 8ms. Se ho altri gruppi funzione, come ad esempio le luci, le ripetizioni si diradano. In questo caso, 16ms (8ms le luci e poi 8ms per la velocità). Ci sono poi comandi prioritari, come lo stop. Ha una priorità alta rispetto a quelli normali e vengono ripetuti 5 volte . Questo perchè sul binario c'è rumore e anche le spec NMRA dicono di ripetere i comandi. Se penso all'architettura del fw, lo possiamo vedere a layer. Un di questi si chiama scheduler che è responsabile di tenere in memoria 12 slot che sono il numero di loco che gestisce contemporanemaente. In realtà il driver che utilizzo , il DRV8874 , non ha la capacità di gestire contemporaneamente 12 loco marcianti perchè ha un picco massimo di 3 ampere se ricordo bene, e lo dovrei cambiare con il fratello più grande. ma direi che il concetto di slot è questo: uno slot corrisponde a una loco sui circuito con il suo stato. Fatto sto pippone propedeutico, quando arriva un comando dalla app, il primo layer che si incontra nel fw è il layer che implementa un UDP server sulla ESP32 e il protocollo z21. A quel punto se il comando è valido, non ci sono corti, il comando viene passato allo scheduler che lo indirizza allo slot del decoder associato. Il fw invia il comando e risponde alla app con un messaggio LAN_X_LOCO_INFO con velocità, direzione e funzioni aggiornate. Quindi l’eco riporta lo stato accettato dalla centrale; non è una conferma ricevuta dal decoder perchè DCC non ha feedback (a differenza di MFX...). Ad oggi supoorto solo una app z21 per volta (in roadmap c'è la gestione multiclient) e per questo ad oggi il fw risponde sempre UDP, ma senza broadcast verso tutti i client (è solo 1). Ho implementato anche un meccanismo di lease, per cui quando chiudi la app z21, il fw lo rileva e ferma l'erogazione di corrente per sicurezza.


Adesso sto facendo il PCB e sto guardando al loconet. Oltre ai messaggi del protocollo z21 vorrei integrare anche i comandi (invio e risposta) loconet.

C