Delucidazione indirizzo Lungo

[Fidax]

Buonasera, vorrei chiedere a chi ne sa di più una spiegazione sulla logica che governa l'indirizzo lungo.
Mi spiego: l'indirizzo lungo serve per quegli indirizzi superiori a 127 (primo dubbio, se una CV può valere fino a 255 perché la CV1 si ferma a 127?? ), da informatico mi aspettavo che l'indirizzo lungo altro non fosse che la concatenazione di due byte: per fare un esempio il valore 255 sarebbe dato da cv17 = 0 e cv18 = 255, il valore 256 da CV17 =1 e CV18 = 0.
Tale concatenazione permette di arrivare ad indirizzi pari a 65535 (2^16 - 1).
Invece no, scopro che il valore 128 nell'indirizzo lungo si forma con la CV17 = 192 e la CV18 = 128 (dal manuale esu).
Non riesco proprio a capirne il senso, qualcuno sa darmi delle spiegazioni?

[Buddace]

Diciamo che grososmodo dipende dal pacchetti dcc su cui viaggiano.

[Marco Fornaciari]

In pratica perchè la memoria è paginata: è un residuo del secolo scorso per tutti i processori a 4 e 8 bit tipo Intel.
La cosa è proseguita anche sui processori a 16 e 32 bit, in particolare nell'ambiente industriale, es. PLC.
Nei processori Intel di ultima generazione, in pratica quelli dopo il Pentium (I3, I5, I7,) non so esattamente come funziona: ho evitato di studiarlo per non incrementare il vocabolario degli improperi.
...
Molti problemi del DOS e di Windows dipendono appunto dal fatto che la memoria è paginata.
Piuttosto a sembrae illogico è il 192, ma di fatto 192 indica il banco di memoria 1, 193 il due, ecc.
Sempre ad esempio chi ha programmato PLC siemens serie Step 5 sa benissimo di cosa si tratta, oggi l'uso è passato da 255 a 32767, ma il concetto è lo stesso.

[Fidax]

Ohhhh okay! Adesso so il perchè, grzie mille!

[Buddace]

In pratica perchè la memoria è paginata: è un residuo del secolo scorso per tutti i processori a 4 e 8 bit tipo Intel.
La cosa è proseguita anche sui processori a 16 e 32 bit, in particolare nell'ambiente industriale, es. PLC.
Nei processori Intel di ultima generazione, in pratica quelli dopo il Pentium (I3, I5, I7,) non so esattamente come funziona: ho evitato di studiarlo per non incrementare il vocabolario degli improperi.
...
Molti problemi del DOS e di Windows dipendono appunto dal fatto che la memoria è paginata.
Piuttosto a sembrae illogico è il 192, ma di fatto 192 indica il banco di memoria 1, 193 il due, ecc.
Sempre ad esempio chi ha programmato PLC siemens serie Step 5 sa benissimo di cosa si tratta, oggi l'uso è passato da 255 a 32767, ma il concetto è lo stesso.

Dettagliata spgigazione...ma non riguarda questo caso

[Fidax]

E allora sono ancora confuso... Fosse stato un problema hardware potevo capirlo...

[Buddace]

E allora sono ancora confuso... Fosse stato un problema hardware potevo capirlo...

Il primo pacchetto dcc aveva solo 7 bit per l'indirizzo da qui 1-127. Poi hanno aggiunto un altro pacchetto per permettere maggiori indirizzi. Stessa cosa per gli step il primo era 14 step poi hanno aggiunto i 28 step spostando bit e facendo casino con le luci e infinine hanno aggiunto un nuovo pacchetto per 128.

[Fidax]

Ok, adesso inizia ad avere senso

[Zampa di Lepre]

... per fortuna c'è chi ricorda la storia del DCC ...

... a proposito, visto che vorrei ma "non posso", ... tra le emoticon mancano gli applausi o, almeno, il pollice su

[Marco Fornaciari]

Che il DCC sia nato male e poi alla fine sia un protocollo di comunicazione "raffazzonto" non c'è ombra di dubbio.
Così come il max numero scrivibile in un insieme di bit sia appunto limitato da numero dei bis stessi, è un dato oggettivo e imprescindibile.

Ma che si addebbiti al pacchetto del telegramma i di comunicazione il limite numerico è una giustificazione per lo meno "strana", per non dire altro.
Il ragionamento a senso se lato decoder non hai solo memoria temporanea specifica per ogni singola funzione, quindi il decoder è solo un esecutore che vuole aggiornato in continuo (quindi diventa "vero" che la loco è comandata dalla centralina e non dal decoder).
Ad onor del vero la storia del DCC dalle origini l'ho dimenticata è cancellata dalla mia memoria quando ho iniziato a leggere di questi modi di lavorare.

Ma andiamo oltre e speriamo che la benedetta commissione, se ancora esistente, decida di normare la comunicazione WiFi, auspicando che eliminino le storture attuali.

[Fidax]

Tu parli di comandare le loco tramite wifi?
Per gestire lo stesso numero di indirizzi del dcc (circa 10000) servirebbero un numero di access point immenso... Per non parlare di tutte sotto reti necessarie

[Marco Fornaciari]

Tu parli di comandare le loco tramite wifi?
Per gestire lo stesso numero di indirizzi del dcc (circa 10000) servirebbero un numero di access point immenso... Per non parlare di tutte sotto reti necessarie

Non esattamente, già con il TCP/IP V6 superi il problema anche se più complesso (devi conoscere tutta la codifica esadecimale), ma in realtà visto che la dimensione del telegramma non è un problema si possono utilizzare dei sottoindirizzi specifici: è già tutto fatto da decenni, basta aprire il rubinetto e non pretendere d'inventare l'acqua calda. Oppure come già avviene adesso in molti impieghi, una volta stabilito il collegamento con l'indirizzo IP, chi comanda è il MAC o il none dato all'apparecchiatura.
In ogni caso sulla stessa porta Ethernet si possono mettere più indirizzi di rete TCP/IP: lo faccio da anni senza nessun problema, in ogni caso esiste sempre il gatevay.
Senza entrare nei perchè e nei percome, per un profano è più semplice capire un indirizzamento IP, che altre menate del DCC.
Già all'epoca, ad esempio, potevano usare il protocollo universale Modbus, che da sempre è pure gratis; o in alternativa il CAN, che poi è utilizato nella comunicazione tra palmari e centralina da Lenz e dai suoi derivati.

Usare il WiFi ha un vantaggio enorme:
- apparecchiauture di comune uso e testate in miliardi di esemplari
- bassi costi
- semplice installazione
- biderizionalità della comuminacazione in tempo reale
- tensione continua o alternata a valore fisso ai binari
- quasi nessun problema di presa di corrente dalle ruote.

MTH, ad esempio ha un suo sistema biderezionale basato sul principio delle onde convogliate.

[Buddace]

- apparecchiauture di comune uso e testate in miliardi di esemplari
- bassi costi
- semplice installazione
- biderizionalità della comuminacazione in tempo reale
- tensione continua o alternata a valore fisso ai binari
- quasi nessun problema di presa di corrente dalle ruote.

Di fatto nessun vantaggio perchè la presa di corrente e comunque per le ruote, la bidirezionalità senza poter individuare la posizione del treno serve a molto poco .
Nel tempo sono stati presentati vari accrocchi wireless (incluso il bluetooth) per comandare i treno ma l'unico vantaggio oggettivo di detti sistemi era di poter coesistere su impianti analogico con loco analogici...visto che sono misconosciuti dalla massa si può intuire il successo che hanno avuto.
Il DCC risulta vincente per la "banalità" dell'hardware necessario per generarlo o della irrisoria potenza di calcolo necessaria sul banale microcontrollore per gestirlo.

[Buddace]

... per fortuna c'è chi ricorda la storia del DCC ...

... a proposito, visto che vorrei ma "non posso", ... tra le emoticon mancano gli applausi o, almeno, il pollice su

Bhe facendo un analisi dei pacchetti si vede abbastanza facilmente come sia cresciuto

[Fidax]

Piccola nota da marklinista: Il CAN è usato anche dalla marklin, lo chiama Marklin Bus ma è il CAN.

La mia osservazione nasceva da una semplice costazione: gli access point wifi hanno un numero massimo di dispositivi collegabili e tale numero può essere raggiunto in fretta in caso di treni full digital (ogni carrozza con decoder, già 10 treni da 9 carrozze più locomotore fanno 100 dispositivi), senza contare i vari decoder accessori, rilevatori di presenza, decoder sonori ambientali (vedasi i kit DCC workd).
Al tutto aggiungiamoci la questione inquinamento elettromagnetico e possibili interferenze.

Ad oggi un mio grande dubbio è se il DCC rimarrà ancora il principale protocollo: il diretto concorrente MFX ha alcuni vantaggi (indirizzo univoco senza interventi del'utente, funzioni fino alla F32, bidirezionalità con autoriconoscimento esattamente come il RailCom Plus) e sta venendo abbracciato dai grandi produttori di decoder: Zimo in primis, Uhlenbrock, Piko (che dovrebbere essere Uhlenbrock rimarchiato) e ovviamente ESU e Marklin (creatrici di tale protocollo).
Non credo manchi molto a quando le specifiche di tale protocollo vengano pubblicate anche per utenti che realizzano progetti Home made: marklin ha capito che un mondo chiuso non le conveniva, e tempo un anno dall'annuncio ecco subito ucire i decoder delle altre ditte con supporto a tale sistema.

Personalmente quello che trovo più limitante dei deocder odierni è il numero "basso" di aux per avere modelli il più possibili reali, sul progetto eurofima le aux sono 31.
Preferirei che esistesse un unico connettore che faccia passare rotaie, Motore, SUSI, e alimentazione (U+ e GND): 8 fili (7, se vogliamo metttere il sistema di alimentazione sulla scheda del rotabile, GND deve sempre essere in comune). Poi la scheda logica del rotabile gestirà tutto il resto.
Oggi la SUSI gestisce fino alla F68 (http://www.normen.railcommunity.de/RCN-600.pdf) proviamo solo a immaginare quante funzioni realistiche si potrebbero realizzare.