Uchylne programovani dekoderu

[belgarat]

Cau,

jezdice z/do prace na autopilota, mozek bloumajici, premyslel jsem nad tim jak by se dalo vymyslet "nastaveni dekoderu", ktery treba obsluhuje vlakovou cestu, tudiz reknem obsluhuje 1..n vyhybek. Viz Sidluv dekoder/stavedlo. S tim rozdilem, ze Stavedlo je stavene na max 8 prvku na jeden pokyn, coz budto nemusi dostacovat (delsi cesta), nebo zabira misto (kratke cesty). POZOR - v zadnem pripade nerikam, ze stavedlo je spatne nebo nedostatecne. Maximum na radek nam da pekne matici, kterou muzeme at uz MM nebo JMRI pekne vyplnit. Dalsi typicke zarizeni, ktere pouziva v nastaveni "vycet", "cestu" a pod, je napr Zhlavik. Kapacita RAM ktera zustane typicky nevyuzita je velka, matice je ridka.

Teda "potiz" kterou bych zde chtel predlozit je "jak do dekoderu zapsat informaci s promenlivym poctem prvku (kroku)". Predlozim nastin, a rad bych slysel zda to muze byt funkcni, pouzitelne (pro rucni nastaveni). Vim, ze je mozne zvolit "rozumne velke" maximum, tuto dobrou radu uz znam, patram po jinem zpusobu. Jeden takovy OBDOBNY (ne stejny) mechanismus ma napr ZIMO pro programovani svych loko dekoderu: nezavisi jen na tom, jaka hodnota do jakeho CV se zapise, ale i v jakem poradi se zapise. Rikaji tomu "pseudo-programming".

Cislo CV v popisu je nahodne zvolene; nezkoumal jsem moznou kolizi s necim jinym. Pro jednoduchost budou vsechny adresy prislusenstvi max 255. Zmena na delsi adresy je trivialni. Chci-li zapat (rekneme) cestu (sled vymen na ni), postupuji takto:
1/ zapisu do CV 200 cislo cesty, napr. 2 - definuji cestu cislo 2
2/ zapisu do CV 201 cislo 1. prestavniku na ceste
3/ zapisu do CV 201 cislo 2. prestavniku na ceste
4...n+1/ zapisu do CV 201 cislo 3..n prestavniku na ceste
5/ zapisu do CV 202: 0 (storno, zrusi se), 1 (ok, cesta #2 se definuje ci prepise)
6/ pokud do XXX sekund po poslednim zapisu do CV201 nenasleduje zapis do CV202, definice cesty se zrusi

Jak je to s opakovanim packetu centralou - muze byt dekoder schopen odlisit po sobe nasledujici (diskretni) zapisy do stejneho CV od pouheho opakovaneho packetu ?

Pokud je zde nekdo expert na JMRI nebo RocRail, zejmena psani jejich rozsireni, rad bych vedel zda by sel podobny styl zapisu do CV zabudovat aby se dal napr. do Decoder Pro zabudovat podobny hezky ovladaci panel, jako pro Stavedlo. Proc: protoze to umozni relativne pohodlne nastaveni i sloziteho dekoderu "obycejnemu" uzivateli - v GUI se da prevod na jednotliva CV a jejich posloupnost zcela schovat (snad).

Poznamka: netahat sem LocoNet, jedna se mi o dekoder, ktery sedi na DCC signalu. Zpusob komunikace PC <-> centrala nechci resit. Dekuji.

[fulda]

Ve stručnosti - je to hodně odvážné. Já bych se do toho nepouštěl.
Má to několik problémů. Centrála nemá přesně stanovený počet zápisů. Sice "většinou" udělá jeden zápis na jedno volání, ale není to pravidlo. V některých režimech dělá třeba tři.
Pozor také na to, co je a co není zápis. Je legální, aby centrála nezapsala celý bajt, ale jen některý jeho bit. To se používá celkem často.
Nehledě na to, že je legální, aby se kombinovaly metody zápisu (Servisní/PoM).

Takže já bych do toho nešel.

Ale existuje indexovaná oblast (sleduj popis CV31,CV32 a pak CV257-512).

[belgarat]

Fulda: dik, takove pekne vidle a ja si na ne nabehnu. Jasne ze nejde poznat "kdy zapis konci", kdyz se da CV menit postupnymi bitovymi manipulacemi.

Da se teda spolehnout aspon na to, ze kdyz dekoder dostane instrukce pro zapis (cteni) pro CV-x, tak predchazejici zapis do CV-y uz zcela skoncil ?

Ad indexovana CV: Pochopil jsem spravne, ze indexovane CV jsou 257-512, pricemz indexy 0-4095 jsou rezervovane ? Tzn. pokud bych (napriklad) pro definici cesty (s nejakou vetsi max delkou) pouzil napriklad CV300-319, s tim, ze index 4096 by znacil cestu 1, index 4097 cestu 2 ... tedy presneji cesty by byly definovane pomoci
* cesta #1: CV300.16.00, CV301.16.00, CV302.16.00 ...
* cesta #2: CV300.16.01, CV301.16.01, CV302.16.01 ...
atd
tak bych se vlezl do podminek standardu ?

prirozenejsi je samozrejme
* cesta #1: CV300.16.00, CV300.16.01, CV300.16.02 ...
* cesta #2: CV301.16.00, CV301.16.01, CV301.16.02 ...
ale nasel jsem zminku, ze neni nutne (v zavislosti na dekoderu ?) pokazde zapisovat indexy (stranku) a staci pouze zapisvat do jineho mastera - coz by vedlo na jednodussi zachazeni v tom prvnim uvedenem priklade.

(Edit: doplneno)

[sidlo]

Není to úplně odpověď na tvoji otázku.

S proměnlivou délkou proměnné pracuji např. při adresování návěstidla dekodéru UNI16ARD-NAV-MX. Dekodér může mít až 8 návěstidel a každé návěstidlo zabere 1 až 5 DCC adres. Po spuštění dekodéru se vypočtou rozsahy adres adres všech návěstidel a ty se uloží do tabulek. Když přijde příkaz DCC tak se z tabulky přečte ke kterému návěstidlu patří.

To celkem funguje, protože se obsah těch tabulek počítá po zapnutí dekodéru. Problém by byl v tvém případě. Ty chceš obsah těch tabulek mít v CV. Při pokusu prodloužit tabulku n budeš muset posunout všechna CV v tabulkách n+1 až do max_počet_tabulek. To bude dost vopruz.

[fulda]

Da se teda spolehnout aspon na to, ze kdyz dekoder dostane instrukce pro zapis (cteni) pro CV-x, tak predchazejici zapis do CV-y uz zcela skoncil ?

Ne. Narazíš na to často při přehazování krátké/dlouhé adresy. To si centrála "odskočí" změnit CV29 a mezi tím si matlá CV1, CV9, ....

Ad indexovana CV: Pochopil jsem spravne, ze indexovane CV jsou 257-512, pricemz indexy 0-4095 jsou rezervovane ? Tzn. pokud bych (napriklad) pro definici cesty (s nejakou vetsi max delkou) pouzil napriklad CV300-319, s tim, ze index 4096 by znacil cestu 1, index 4097 cestu 2 ... tedy presneji cesty by byly definovane pomoci
* cesta #1: CV300.16.00, CV301.16.00, CV302.16.00 ...
* cesta #2: CV300.16.01, CV301.16.01, CV302.16.01 ...
atd
tak bych se vlezl do podminek standardu ?

Ano, do požadavků standardu se vejdeš, ale platí co napsal sidlo. Zjednodušíš si tím vizualizaci, ale nepořešíš tin tu "řídkost matice".

Ještě drobná poznámka - moc nechápu ten zápis, kterej uvádíš. Normálně se to provádí takto:
zápis do CV31 = 16 (4096/256 - horní byte)
zápis do CV32 = 1 (1 =první cesta, 2=druhá cesta, ...)
zápis do CV 257 = první krok první cesty
zápis do CV 258 = druhý krok první cesty
zápis do CV 259 = třetí krok první cesty
...

[belgarat]

Zjednodušíš si tím vizualizaci, ale nepořešíš tin tu "řídkost matice".

No, v zasade vyresim. Nikdo nerika, ze musim tu matici ukladat do RAM / EEPROM v dekoderu (v mem pripade asi arduinu) tak, jak ji uzivatel zapise resp. vidi. Bude sice opruz transormovat "indexovana CV" na 'normalni' datove struktury a naopak, ale da se. Slibuju si od toho, ze napr. do JMRI by sel vyrobit vlastni JPanel s peknou prezentaci, ktery muze za scenou "nejak" dekoder nakrmit. Prozatim to stejne odlozim jako "napul dopeceny napad", resuscituju az u mne dojde na navestidla s rychlostni navestni soustavou a predvestenim. Indexovani mi vyresi velkou spotrebu cisel CV na vetsi matici.

Ještě drobná poznámka - moc nechápu ten zápis, kterej uvádíš. Normálně se to provádí takto:

Sorry. Jako prvni k tematu jsem nasel toto: https://dccwiki.com/Configuration_Varia ... _Variables kde je zavedeny urcity zpusob zapisu co pouziva QSI, mozna ne uplne standardni ale prvni co jsem nasel; viz take http://media.wix.com/ugd/0f7119_a2df90c ... 3ec6a9.pdf
v JMRI dokumentaci je o tom formatu zapisu takze zminka http://jmri.org/help/en/html/apps/Decod ... indexedcap