Jump to content

[ATS] Firmware per ESP8266/ESP32


Post raccomandati

Il 4/5/2020 alle 12:58, GianCann ha scritto:

@BOLTO@ hai avuto modo di dare un'occhiata al progetto?
Se si riuscisse a fare un merge delle funzionalità tra questo e quello che hai sviluppato te, si prosegue su un unico... binario 😄

Si, gli ho dato un occhio (i miei complimenti) e questo we vedo di allinearmi a quanto fatto (topic, logiche di base, ...) così da iniziare a capire come fare un unico sorgente.

Ciao

Link to comment
Condividi su altri siti

I complimenti vanno in maggior parte a @sky7176 che ha scritto buona parte del codice. Io gli ho giusto indicato le funzionalità che avrebbe dovuto avere il controller.

Tieni conto che il la versione attuale del firmware ha queste caratteristiche:

1) Gestisce un solo motore (conto già domani di aggiungere il secondo)

2) È aggiornabile via OTA (quindi, una volta effettuato il primo upload via seriale, si può aggiornare tramite WiFi)

3) Oltre che con MQTT, è controllabile via comandi HTTP.

4) Utilizza il file system SPIFFS (1 MB) per memorizzare alcune pagine HTML per mostrate le info sul chip e per procedere con l'upload di un nuovo firmware (e per impostare alcuni parametri.

5) Buona parte del firmware (WiFi/MQTT/OTA/Configurazione) sarà utilizzata per il Controller Sensore (se guardi nel codice, c'è una variabile "ControlType" che servirà proprio a selezionare la modalità di funzionamento).

Su quest'ultimo punto c'è da valutare se lavorare con due firmware separati oppure uno unico, magari scrivendo una classe Controller che implementa entrambe le funzionalità.

Per quanto riguarda la gestione dei motori, penso che sia più opportuno ragionare in termini di Porte e non di Motori, come ora. Un po' come l'Hub Powered Up: "Port A" e "Port B". Porte sulle quali ci si potrà collegare un motore, un LED, un servo o un qualsiasi altro dispositivo pilotabile in PWM.

Altra cosa da aggiungere è la modalità Combo: due motori controllati contemporaneamente come se fosse uno solo, per movimentare treni più pesanti.

Se avete altri suggerimenti/idee, fatevi sotto! 😉

Ultima modifica: da GianCann
Link to comment
Condividi su altri siti

Ora mi è più chiara la direzione! Allora, procederei come segue:

  • riorganizzo il codice in modo che il controller sia gestito da una CU
  • integro la gestione tramite HTTP
  • integro la scrittura su FS

Personalmente concordo con l'idea di creare librerie comuni, ma proverei a gestire il codice dei controller a cluster, soprattutto per evitare che poi diventi una insieme di codice non sempre affine allo scopo e che per funzionare ci chiede configurazioni fin troppo complesse.

Se siamo tutti concordi su questo approccio, inizierei ad identificare i cluster (quello che su hai definito ControlType) e tracciare le librerie.

La butto lì:

  • MotorControl
  • TrackControl
  • StationControl
  • LevelCrossingControl
  • LightsControl
  • ...

Cosa ne pensate?

Ciao

Link to comment
Condividi su altri siti

Considerando che io e Fritzing ci stiamo ancora conoscendo, questa è la bozza del nodo per la gestione delle sezioni di tracciato.

Non ho trovato il relé tra i componenti e quindi ho messo un "switch" rappresentativo.

Il ponte raddrizzatore lo sto prendendo come componente, a seguire del quale pensavo di metterci un altro diodo per evitare che passasse nulla superiore ai 12V (per le sezioni ad alta velocità) e sovraccaricare troppo il convertitore DC-DC.

Come board ho messo quella su cui sto sperimentando, ma servendo pochi pin si può tranquillamente pensare ad una unità più piccola.

CiaoTrackNode_schema.thumb.jpg.5ec3e33be5559b713ca0ded110d83f2e.jpg

Link to comment
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente registrato per postare un commento

Crea un account

Iscriviti per un nuovo account nella nostra community. È facile!

Registra un nuovo account

Accedi

Hai un account? Accedi .

Accedi ora
  • Visualizzato ora da   0 utenti

    • Nessun utente registrato su questa pagina.
×
×
  • Crea nuovo...