Software per decoder...

[Davide]

Ciao a tutti,
ho iniziato a sviluppare (riprendendo quanto gia' fatto tempo fa insieme a despx) un software per decoder sviluppato con un linguaggio "ad alto livello", che sia capibile un po' per tutti al contrario dell'ostico assembler Microchip. Per questo sviluppo ho scelto i tools della Mikroelectronika (Pascal,C e Basic) in quanto sono free (per programmi sotto 2K) e la versione demo non ha altre limitazioni. Come primo passo ho integrato la routine di decodifica DCC (purtroppo questa e' parzialmente in assembler perche' molto critica, ma sara' l'unica parte in questo linguaggio) all'interno di un convertitore DCC->Seriale per poterne testare appieno le potenzialita', collegandolo direttamente alla COM port del PC con un programmino di test/log che mi faccia vedere tutti i pacchetti che escono dalla stazione di controllo. I prossimi passi secondo me dovrebbero essere la decodifica dei pacchetti, il service mode, il decoder per accessori ed infine il decoder per loco in un cammino a complessita' sempre crescente. Se qualcuno e' interessato a "tradurre" in Basic e C questo programma (il mio sorgente e' in Pascal) e/o ovviamente a collaborare nello sviluppo di questo progetto digitale, mi piacerebbe arrivare a un programma nel quale tutti (proprio tutti) possano mettere le mani e personalizzare il tutto per le proprie esigenze, indipendentemente dal linguaggio di programmazione che conoscono. Unica limitazione: questo programma nasce freeware e quindi non dovra' avere nessuna limitazione di distribuzione.

Ciao

Davide

[Despx]

Ciau Davide, ben ritornato!
Sono sempre interessato ad ampliare le mie esperienze ed a confrontarmi con nuove problematiche.
Due cose però....x eperienza, certe limitazioni intrinseche dei pic, non lasciano piena libertà  sulla scelta del linguaggio di programmazione amenochè non si parta già  con un clock di 20MHz; i prodotti di Mikroelektronika sono buoni ma in certe situazioni critiche, risultano troppo pesanti e lenti.
Realizzare decoder x locomotive ti posso garantire che non è una cosa semplice specie se vuoi prestazioni di alto livello, io dopo quasi 2 anni di lavoro sono arrivato ad un decoder da 8MHz, con luci, 2 funzioni, controllo di carico, il tutto in 16x33 mm.....ti consiglio di rimanere sugli accessori fissi....x non impazzire!
Ultima cosa.....occhio a rendere opensource il materiale....la rete è piena di "furboni"......

Ciau e buon lavoro!
Despx

[Davide]

Ciao Despx! Ho letto che hai completato il tuo decoder, complimenti! Anch'io ho finito il mio, pero' avendolo fatto tutto in assembler, praticamente non e' utilizzabile da altri (e qualche volta mi incasino anch'io a fare alcune modifiche). Anch'io ho tirato alla miniaturizzazione estrema (15x8mm) perche' ho uno zio (sfigatissimo) che fa scala Z. Hai ragione sulla frequenza di clock (almeno 8MHz, non ho trovato nulla di Microchip 16F che vada senza quarzo ad una frequenza piu' alta) e sicuramente con la "poca" ottimizzazione propria dei linguaggi ad alto livello sara' una bella sfida... Sul freeware, lo sai, io la penso diversamente... secondo me chi ha la possibilita' di vendere migliaia di pezzi (l'elettronica ha un senso a questi volumi, sotto e' hobby - se consideriamo il costo ridicolo di un decoder) non ha alcun problema a farsi fare un programma 100 volte migliore di quello fatto da un bischero come me...

Ciao e a presto!!!!

[Davide]

Non penso sia un problema, anzi: se tu conosci il mikrobasic potresti "tradurre" in questo linguaggio i vari pezzi di programma per far si che anche chi usa questo linguaggio (molto diffuso) possa avvicinarsi ai programmi dcc quando magari vedendo solo sorgenti in mikropascal passerebbe oltre...

Ciao

P.S. Non penso di essere un esempio "digitale"... solo trovo ridicolo che non si trovi in Italia un esempio di programma di codifica/decodifica dcc per chi vuole "capire come fare" e si debba ricorrere a programmi di tedeschi, Inglesi e per di piu' in assembler... quando invece anche in Italia c'e' un sacco di gente che fa progetti dcc tostissimi e questo sito ne e' un esempio lampante...

Ri-ciao

[renato]

Il minimo che si possa fare è aiutarti nell'esperimento.
Come si dice a Napoli.......a disposizione sua.
ciao

[Davide]

Ciao a tutti,
ho cominciato a scrivere la descrizione del firmware decoder a questo indirizzo:

http://web.tiscali.it/digitale_treni/

Per ora ho messo la parte piu' "rognosa" sulla decodifica del segnale DCC. Malgrado possa sembrare una cosa "strutturata" ho cominciato a scrivere le cose così come mi venivano quindi potrebbero anche esserci delle cose non chiare (o scritte alla cavolo). Vi prego di farmi qualsiasi appunto per migliorare il risultato finale.

Ciao

[renato]

Confermo la "rognosità " dell'argomento.
Anche perchè il mio sapere di assembler e <0.
Spriamo sempre nel basic per poter passare a =>0
cmq ottimo lavoro
ciao

[Davide]

Renato, hai perfettamente ragione! Questo assembler dei PIC e' una sfiga incredibile, anche dopo anni di esperienza lo trovo una palla incredibile. Per aiutare nella comprensione della routine la troduco (ora) in Pascal, almeno e' un linguaggio umano...

Ciao

[Despx]

Ciao Davide, come al solito, un bel lavoro peccato che non venga apprezzato dalla massa.
Fossi in te, più che far capire il codice asm, proporrei progetti tematici già  confezionati come decoder accessori, decoder funzioni, ecc.
Il DCC in Italia è ancora mooolto lotano dal "popolo", interessano solo le locomotive che fanno ciuf ciuf e che emettono fumo, i pacchetti dcc vengono scambiati per una nuova marca di sigarette ecc.
Se leggi nel forum c'è ancora chi chiede se il dcc fa andare in automatico l'intero plastico o chiede se montando un decoder, la locomotiva va meglio in analogico....

Convoglia le tue forze in progetti concreti, forse qualche persona ti seguirà .

Ciau
Despx

[r302]

Non ci capisco niente di programmazione e non vi posso aiutare, comunque a voi il mio solidale pensiero, per quello che può servire, per un dcc alla portata di tutti.
Saluti
Gianmarco

[Davide]

Hai ragionissima Despx... infatti io volevo "fondere" le due cose cioe' spiegare i pacchetti passo passo (bella quella delle sigarette ) e insieme costruire tutto il programma e l'hardware di un decoder per accessori (cominciamo dal semplice). In questo modo, come facevi giustamente notare, avere un progetto "concreto" puo' essere interessante per tutti, anche per chi dei pacchetti non gliene frega nulla...

[SpurN_DB]

ciao complimenti per la descrizione puntuale del tuo lavoro!!!!

mi sembra scritto molto bene e il relativo pascal è rivelatorio!!!!

continua così

[dccvr]

Ciao David.
Premetto che sfruttando la vicinanza (io anche firenze-pistoia) avrei voglia di incontrarti per scambiare direttamente qualche idea,mi sento di dissentire dall'approccio che stai dando alla questione..siccome le cose che non condivido sono diverse cerco di sintetizzare e focalizzare il discorso sulla questione principaleper non essere logorroico, rimandando eventuali chiarimenti in altra sede!

In particolare non condivido la tua intenzione di cercare di rinventare l'acqua calda per arrivare a servire un brodino tiepido (chiamiamolo cosi'!).

E' come se chi contribusce allo sviluppo del LInux free invece di aggiungere qualcosa e dare il proprio contributo ripartisse tutte le volte da zero!

Nel caso dei decoder e centrali visto che delle persone a cui dobbiamo essere grati hanno messo a disposizione i loro listati, (i decoder hanno ad esempio un unico babbo come riportato nei riconoscimenti) perche non riversare le proprie capacita' e risorse per migliorarli intervenendo sulle basi gia' funzionali e sperimentate?

Anche per il discorso asssembler, basic pascal e C (tralasciando altri)...il discorso e' che prima o poi devi infognarti con il primo per vari motivi...(come espresso in parte anche da te e Despx).

Sentiamoci.

[SpurN_DB]

un' idea ce l'avrei di un "cazzillo" in grado di riolvere un pò di rognette

un rallentatore che non faccia casino con le luci!

si ricordi i parametri indirizzo e direzione ottenuti dai pacchetti di centrale e anche se in ritardo e sfalsati li butti sulla tratta di rallentamentocon velocità =0.

il casino è che i pacchetti di centrale sarebbero sempre più corti di quelli della tratta di rallentamento quindi ci sarebbe sempre qualche pacchetto da escludere

[dccvr]

il casino è che i pacchetti di centrale sarebbero sempre più corti di quelli della tratta di rallentamento

VERO!

quindi ci sarebbe sempre qualche pacchetto da escludere

escludi quelli delle funzioni! basta che tu abbia salvato il pacchetto address+direzione&velocita' e ristrasmetti i pacchetti con i vari address in ballo ed il successivo con la giusta direzione mascherando la parte della speed ( e chiaramente ricalcolando il check) ed il cazzillo e' belleccheppronto!