[HWnews] OT - komunikacni protokol

[Pavel]

Ano, neni to primo receno ve specifikaci (pokud to tam kolega na posledni
chvili nedoplnil) ale mate pravdu melo by tam byt nejake doporuceni. Na
rozdil o CAN Busu kde je v norme specifikovano vse od urovni a tvaru signalu
po protokol i reseni koliznich stavu a u ktereho je prakticky dano, ze vzdy
to budou 2 draty, my toto nemame dano, resime skutecne jen otazku protokolu.
Nemame danu fyzickou vrstvu a nikde neni dano ze muze byt jen jedna v celem
retezci, da se rici ze nikde ani neni dano ze to musi byt prenos seriovy.
Zatim jsme prenosy Spinelem zkouseli na urovni jen TTL dale RS485(422),
RS232, USB, Ethernetu, GPRS, pokusne i WiFi a ruzne kombinace. To jsou
technologie dnes, zitra budou stejne ale nevime ktere budou za rok, nemuzeme
si ted uzavrit cestu proto je Spinel otevreny a jeho vyvoj samozrejme
pokracuje. Proto Vasi pripominku ted jiz neberu jako rypani (at uz jste si
chtel rypnout do sveho byvaleho kolegy Pavla Pouchy nebo vseobecne :-} ) ale
urcite se zamyslime nad nejakym doporucenim, ktere pripadne uvedeme ve
specifikaci.

Pokud jde o praxi, tak obecne je to reseno tak, ze master vysle dotaz a ceka
na odpoved a teprve po jejim obdrzenim muze vyslat dalsi dotaz komukoliv.
Casy odpovedi nejsou blize specifikovane ale v praxi jsou okamzite, pripadne
v radu ms u slozitejsich instrukci a pripadne desitek ms u konfiguracnich
instrukci nebo instrukci spolupracujicich s dalsim HW. Podle konkretniho
pozadavku aplikace muze toto byt presne specifikavano, jinak plati vyse
uvedene jako doporuceni vysle z praxe. V pripade aplikace kdy je pozadovan
prenos po RS484 (Half Duplex vseobecne) a tedy prepinani smeru komunikace je
treba implementovat minimalni prodlevu mezi poslednim prijatym byte a prvnim
odeslanym, tato prodleva je bezne cca 2ms ale uz jedno zarizeni ma dle
pozadavku prodlevu zkracenu. Minimalni doba mezi byte zpravy je dana
technickymi moznostmi a maximalni je specifikavana jako 1 az 5s pro rucni
komunikaci z terminalu. I tento timeout ovsem muze byt podle konkretnich
pozadavku zmenen obema smery, takze opet se jedna pouze o doporuceni. Pokud
bude pozadavek na "buseni jak hluchej do vrat" budeme jej muset realizovat,
neni to technicky nemozne ale nepripada mi to korektni. Pokud jde o
zajisteni zprav proti ruseni, maji binarni formaty kontrolni checksum.

V soucasnosti je pripravovan format Spinelu vhodny pro multimaster ale neni
dokoncen natoz vyzkousen, podrobnosti tedy nesdeluji.

Pavel


-----Original Message-----
From: hw-list-bounces@mailman.nethouse.cz
[mailto:hw-list-bounces@mailman.nethouse.cz]On Behalf Of Danhard
Sent: Friday, April 16, 2004 8:10 PM
To: [HWnews]
Subject: Re: [HWnews] OT - komunikacni protokol


No pokud si nereknu, ze to zarizeni ma odpoved hned, ale treba az za 5
minut, tak na tu jeho odpoved budu muset cekat a komunikace ponekud vazne
:o)
Naopak kdyz odpovim okamzite, tak to musi take master dobre zpracovat.
Naopak kdyz to tam bude master busit jako hluchej do vrat, a nebude delat
pri asynchronnim prenosu mezery mezi zpravami, tak treba diky ruseni se
prenos rozpadne a prijimace se nebudou moc chytnout, takze nejake zpravy
vypadnou.
Ja vim, ze jsou to veci, ktere vetsinou vyplynou nejak automaticky, jen me
zajimalo jestli jste to u fyzicke vrstvy Vasich zarizeni nejak
specifikovali.

Danhard

> Muzete trosku vice specifikovat co myslite tim "Pokud nebudou definovane
> odezvy na RS485, taksi jaksi nedovedu predstavit implementaci systemu
> prikaz-odpoved." ?

> Pavel Tatar


_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
HW-list@mailman.nethouse.cz
http://nethouse.cz/mailman/listinfo/hw-list