[ veselinovic @ 17.08.2019. 23:04 ] @
Imam jedan master i nepoznat broj slejvova ( manje od 10) na 485 basu.
Korisnik sam daje tekstualno ime slejvu tipa Pera, Zika, xxxx.
Konfiguracija je takva da je komunikacija jednostrana, tj master salje komandu pojedinom slejvu.
Ovaj ce naravno odgovoriti i potvrditi da je OK primio.
Problematika je kako napraviti proceduru raspoznavanja slejvova.
Moja ideja je da master posalje komandu predstavite se.
Svaki slejv ceka random1 ms i odgovara.
Ako je kolizija na liniji onda ceka radnom 2 milisec pa ponovi.

Valja li ova ideja, i ima li neka druga logcnija procedura?
[ Living Light @ 17.08.2019. 23:10 ] @
Odgovor na tvoje pitanje, trenutno NE ZNAM,
ali ću u ponedeljak u firmi da pitam,

-Kako ONI to rešavaju sa više od 75 "slejvova".
[ ZAS011 @ 18.08.2019. 00:45 ] @
Koji protokol se koristi za komunikaciju?
Pera, Žika, Mika, Laza, ... se u normalnom svetu ne koriste za identifikaciju. To su samo simbolički nazivi koje korisnik u nekom SCADA sistemu daje slejvovima koji imaju isključivo numeričke adrese (kao mnenonici u assembleru, lakše se razume od 10010010, 01101001, ...
Pogledaj malko opis MODBUS protokola. Slejvovi imaju adrese od 1 do 254
Master pošalje poruku slejvu koji bi na istu trebalo da odgovori ponavljanjem primljene poruke + podatak koji je od njega tražen, i, naravno CRC.
MODBUS se intenzivno koristi kod PLC-ova.
BTW RS-485 je samo hardverski lejer (balansirana linija sa definisanim naponskim nivoima).
MAX485, SN75176 su predviđeni da drajvuju do 32 slejva, ima čipića koji mogu i više, ne mogu trenutno da se setim koji

Nisam siguran, Mikroelektronikini kompajleri su imali, čini mi se, mogućnost broacast-a, gde svi slejvovi reaguju na primljenu poruku, tu bi moglo da se igra sa osluškivanjem povratnih informacija od slejvova, npr, slejv sa adresom 1 odgovori odmah, sa adresom 2 posle 2ms, sa adresom 3 posle 4ms ... i na osnovu tajminga odgovora doći do podatka o aktivnim slejvovima. Znači, očekivanje odgovora u tačnim vremenskim intervalima.
[ veselinovic @ 18.08.2019. 06:47 ] @
Zoki,
jasna je prica gdje ima administrator koji zna broj slejvova, i koji ce na neki nacin ( dip prekidacima, softverski,.. kakko god) adresirati pojedini slejv.
Medjutim, ja ne znam unaprijed broj slejv uredjaja.
I nema administratora koji umije dati brojeve slejvu.
Cak sta vise, naknadno ( poslije pustanja u rad) korisnik moze dodati neki slejv.
Dakle, situacija je takva.
Brzina uopste nije kriticna.
Recimo da je Ok ako par bajtova poruke stigne u roku od desetak sekundi.

PS znam MODBAS i jos par industrijskih protokola, ali ovo nisam nasao nigdje u literaturi.
Znam i da Pera, Zika,... nisu imena prilagodjena procesoru, ali su itekako prilagodjena covjeku.
Korisnik ce u slejv upisati ime koje ga jasno asocira na slejv, a master kasnije - kad ih prebroji i identifikuje moze svakom od njih dati broj.
Npr, u kolima ti pise - pregorela sijalica desna pozicija nazad. i to je OK za tebe. Komp u kolima je vodi kao neki broj. I sad zamisli da pise S132, E12.
[ ZAS011 @ 18.08.2019. 10:20 ] @
NIsam zalazio u problematiku vozila, mada se i tamo slejvovi "imenuju" brojevima, prema utvrđenom dogovoru među proizvođačima.

Ako moraš da identifikuješ nepoznate slejvove, MORAŠ da znaš koji se komunikacioni protokol koristi da bi istima mogao da se obratiš.
Ako pišeš softver za slejvove, k'o što sam ti ranije napisao, time slot za svaki slejv čime bi se izbegla, koliko-toliko kolizija.
Npr.

M: Slejvovi Predstavite Se (Broadcast poruka na koju svi slejvovi moraju da odgovore)
TimeSlot1: Pera
TimeSlot2:
TimeSlot3: Žika
TimeSlot4: Mika
TimeSlot5:
.
.
.
.
TimeSlot254: Laza

Recimo da ti je TimeSlot u trajanju od 20ms ukupno vreme za "prozivku" bi bilo 5080ms

Ovo je samo primer.
[ mikikg @ 18.08.2019. 11:55 ] @
Obicno na Broadcast poruke sa mastera slejvovi ne odgovaraju, tako se direktno ulazi u problem ako bi oni tada poceli da odgovaraju, jednostavno cute i kuliraju i zapamate to sto im je master poslao.

Ako ne mozes da reprogramiras slejovove onda ce biti veselo, kako da se napravi onda ovo sto je ZAS predlozio sa TIME*ID? :)

Po meni jedino logicno resenje je "prozivka" sa nekom status komandom, "jel' tu ID1?", "jel' tu ID2?" ... Ko se javi taj je prisutan na casu, ostalima se pise neopravdano jer je prozivka samo kod starta masine :)

BTW: Majstor koji kaci novu periferiju na MODBUS jednostavno MORA da ima informaciju koji su ID-evi slobodni/zauzeti kako bi taj nov podesio na unikatnu adresu. To se da resiti u okviru neke procedure za inicializaciju masine gde operater ima uvid u spisak trenutno zauzetih adresa.

[Ovu poruku je menjao mikikg dana 18.08.2019. u 13:22 GMT+1]
[ bogdan.kecman @ 18.08.2019. 12:26 ] @
ako pravis svoj protokol time*id nije losa ideja ali kad vec definises
da je svaki slave sa numeric ID-om koji ide od 0 do X (255 obicno) onda
sa mastera kazes

for (i = 0; i < MAX_ID; i++) prozovi_slave(i);

gde ti je prozovi_slave(i) nesto tipa

if (status = sendmsg(i, MSG_STATUS, TIMEOUT) == STATUS_OK) slaves = true;

tako da umesto da slave racuna koliko da ceka i kada da se javi i slusa
broadcast, slave slusa samo svoj id, i kad ga ko sta pita on odgovori,
samo dodas da ume da odgovori i na MSG_STATUS sa "TU SAM"
[ veselinovic @ 18.08.2019. 13:37 ] @
Nisam dobro objasnio.
Imam n slejvova koji inicijalno nemaju svo ID.
Master nema pojma koliko slejvova ima na mrezi.
Korisnik u slejvove upise neko njemu logicno ime, a nije dovoljno strucan da upise i broj.
Dakle u pocetku imam n slejvova sa imenima pera, zika, ....
Master ce na pocetku da da komandu predstavi se.
Svaki slejv ce se predstaviti recimo sa ID 100, i u poruci reci svoje ime.
Master ce poredati slejvove po imenima i svakom dati ID.
Na dalje je sve OK. Svaki slejv ima ID, master moze jednoznacno povezati ime i ID.
Problem je kako izbjeci koliziju.
Posto ce slejvovi imati ds1820 Scepa je predlozio da uzmem dio 48-bitnog serijskog broja DS-a napravim vrijeme kasnjenja.
Ja imam ideju da uzmem ASCII reprezent prva tri slova imena i napravim neku tezinsku funkciju.
Npr kasnjenje zike = 65025*ASCII (Z)+255*ASCII(I)+ASCII(K).
Ako bih prosto sabrao ASCII onda bi ZIKA i KIZA imali isto kasnjenje.
Ima jos jedna ideja.
Slejv izmjeri temperaturu i ono iza decimalne tacke pomnozim sa nekim koeficijentom, npr 100ms.
Eto, jos se razmislja.
[ goran_68 @ 18.08.2019. 18:37 ] @
Svi nodovi teba da imaju jedinstvenu mac adresu. To obezeđuješ ti u firmveru. Novi nod se mreži predstavlja mac adresom šaljući zahtev za dodelom imena (simboličko ime, ID ili šta već..). U zahtevu slejv može da naznači koje bi ime želeo (uneo ga korisnik u slejv). Master proverava u svojoj listi simboličkih imena da li je novo ime slobodno i dodeljuje ga slejvu ako jeste. AKo ime nije slobodno sve ispočetka.
[ ZAS011 @ 18.08.2019. 19:45 ] @
Gorane, zamisli da imaš glupog korisnika koji je kupio sistem od 5 slejviva sa 1 masterom.
Joca nema blagog pojma kako će glupi korisnik da nayove svoje slejvove (simbolička imena) i svih 5 komada NEMAJU uprogramiran ID (pazi, nije MAC pošto je na RS-485 liniji, najprobližniji je MODBUS protokol).
Jedino što NIJE zajedničko tim slejvovima je jedinstveni serijski broj koji se nalazi u temperaturnom senzoru. Matematičkim igrarijama je moguće iygenerisati zadršku od, recimo, X*100ms (ako zadamo da je jedan TimeSlot 100ms).
Svaki slejv, čim se javi, dobije od mastera ID, prvi slobodan, upiše u svoj EEPROM i setuje fleg da se na Broadcast više ne javlja i tako redom.
Pre povezivanja slejvova u sistem, glupi korisnik je na neki način u slejv upisao samo simboličko ime, ID stoji ili 0x00 ili 0xFF (yavisno od stanja bitova prayne memorijske lokacije u EEPROM-u
Kada se master "upozna" sa svim prisutnim slejvovima, ostaje samo da se na neki način poveže sa nekom aplikacijom bilo na mobilnom telefonu ili na računaru (SCADA) gde će aplikacija iz slejvova pokupiti simbolička imena i prikayati ih na odgovarajući način glupom korisniku.

Primer hotela sa "n" soba (Joca ne može da ode na teren i da programira svaki slejv ponaosob)
Code:
Simboličko Ime           ID
Soba 101                  4
Soba 102                  2
Soba 103                  1
Soba 104                  5
Soba 105                  3


ID dodeljeni po redosledu odayiva slejvova prilikom prve prozivke.

Glupi korisnik nadozida još jedan sprat sa 5 soba, u jednom momentu Master (što bi trebalo da radi ciklično) započne prozivku i prijavi mu se novih 5 slejvova (prethodnih 5 ćute pošto su prošli tu proceduru) i pridodeli svakom novajliji ID prema redosledu prijavljivanja:
Code:
Simboličko Ime           ID
Soba 201                  6
Soba 202                  7
Soba 203                  10
Soba 204                  8
Soba 205                  9


Aplikacija, na čemu god da se nalazi, će od Mastera dobiti ukupan broj slejvova i prikazati i novajlije, bilo tabelarno ili grafički.

Štos je samo izgenerisati iz serijskog broja senzora jedinstveni broj koji će predstavljati vreme ya odgovor na "prozivku" (TimeSlot)
Predpostavljam da se u 100ms može mnogo toga obaviti, čak i sa malom brzinom komunikacije.

To je neko moje viđenje.

PS ako ima negde Y umesto Z, jbg glupi XP (drugi prastari računar) ne ume da im zameni mesta :D Pigvinček sa time nema problema ;)
[ veselinovic @ 18.08.2019. 20:51 ] @
Zoki je to objasnio bolje od mene.
Fol je pronaci algoritam vremenskog kasnjenja kod zahtijeva PREDSTAVI SE.
Iako, realno nece biti vise od 10 slejvova, pa cak i ako bude kolizija sve ce se zavrsiti za par sekundi sa random funkcijom.
Vrijeme uopste nije kritican faktor u toj prici.
Jedini zabun moze biti da neuki korisnik da isto ime za dva ili vise slejvova.
Tada master moze upozoriti i dati predefinisano ime npr soba101-1, soba101-2..., a on ce ih razlikovati po serijskom broju senzora.
[ goran_68 @ 18.08.2019. 21:51 ] @
Po meni je suvišan taj periodični broadcast od strane mastera. Novi slejv se prijavljuje na mrežu zahtevom da mu se dodeli ID. Master ima jedinstven ID kome se slejv obraća kad traži sopstveni ID. Kad želi da zna koji su mu slejvovi još uvek u mreži Master "pinguje" svakog ponaosob i nema opet broadcast-a. Moguće je da nešto previđam ali mi se čini da bi ovako radilo.
[ bogdan.kecman @ 18.08.2019. 22:11 ] @
ne valja ta rabota "glupi korisnik koji upisuje ime slave-a" .. napises
glupom korisniku da svakom slave-u umesto imena mora stavi broj od 1 do
10 i da svaki mora ima razlicit broj inace sprava nece radi kako treba
... jer ces ovako imati korisnike koji upisuju imena cirilicom, emojiima
i slicne budalastine ..

to sa random je standardni protokol na mrezi, pogledaj kako radi 10base2
mreza, ti slusas dal je na mrezi tisina, kad je tisina krenes, ako se
preklopis sa nekim drugim ucutite oboica i cekate neko random vreme i
onda probate opet.. ali u ovom tvom slucaju, kazes dodaj id i to je to
... ili stavi 8 jumpera i neka jumperima setuju id ili ...
[ mikikg @ 18.08.2019. 22:20 ] @
Ja sam odavno za Modbas uveo da ima 32bitnu adresu, 32bitnu komandu i 32bitni podatak sa 32bitnim HW CRC :)
Od Seriskog broja sa DS se dobije CRC32 i to bi trebalo da bude unikatno na mrezi ako se ne varam i to se iskoristi kao adresa :)

Nesto ovako, ovo mi je od predhodne verzije protokola, radi i to odlicno sa sve diagnostikom oko noise i frame errors i tako dalje.
[ mikikg @ 18.08.2019. 23:08 ] @
Inace indentifikacija moze da se resi sa jednim jumperom ili tasterom + led diodica.

Pogledajte malo detaljnije Modbus specifikaciju, imaju tacno pravila kakvi podaci trebaju da se loguju zbog diagnostike, koje LED diodice i kojih boja treba da ima na modulu da bi bio po specifikaciji, sve su vrlo korisna pravila koja mogu da se prihvate za nasu "custom" specifikaciju.

Po preporukama mora da postoji input element i otput element za diagnostiku, minimum jedna LED+jumper jer mora da se potvrdi da je to validan uredjaj koji se indentifikuje na mrezu u tom trenutku kada je poslata broadcast poruka za indentifikaciju.

Dakle korisnik uzme nov uredjaj koji prikaci na mrezu i pritisne taster, sa PLC mastera se salje broadcast poruka gde se javi samo onaj kome je pritisnut taster i odgovori sa adresom koja je vezana za unikatan seriski broj koji stoji u DS integralcu (taj je sa 48bit UID, imaju do 256bit inace), master to skonta i posalje komandu da blinke LED da korisnik zna da je to proslo i to je to.

Mora da se ispostuje neka procedura, ne moze da kaci ko sta kad hoce, imaju vrlo prosta pravila i to je to.
[ scoolptor @ 18.08.2019. 23:21 ] @
Goran, ako se slejv obraca, onda nije slejv, vec master, a mreza je multi master.

Covek trazi recept za gibanicu sa sirom, a dobija recepte za princes krofne, burek sa sampinjonima, i specijalitete kuce koje je kuvar izmislio kada je radio u proslom restoranu.

[ scoolptor @ 18.08.2019. 23:35 ] @
Veselinovic, napisacu ti sutra svoj predlog, na poslu. Ne mogu sad da kucam na telefonu.
[ mikikg @ 19.08.2019. 00:03 ] @
Ime koje korisnik upisuje je totalno nebitno, to je za njegovu informaciju i da kazemo da je to na visem sloju transporta ili aplikacije, ne moze od njega da se ocekuje da upisuje "uniqe" imena, sto bi to radio uopste, sam transport na mrezi trebalo bi da bude resen sa unikatnim adresama koje kao sto spomenuh mozemo da dobijemo iz DS + CRC32 tj 32 bitna "staticna" adresa pa se onda kroz UI (kad se vec spominje da korisnik nesto unosi, gde unosi, kako, LCD2x16, touch ili nema nista ili moze da ima "jedan taster i LED" ??) inicializuje procedura za indentifikaciju i prijavljaivanje na mrezu.
[ ZAS011 @ 19.08.2019. 01:26 ] @
Gorane, klinac (slejv) ima da ćuti dok mu se stariji (master) ne obrati (inače može da dobije vaspitnopopravnu :D ).
Ako bi se samoinicijativno "prijavljivao" u bilo kom slučaju (pritisak na taster ili u nekom random vremenu) ne bi bio slejv već master i sistem bi bio multimaster.
[ mikikg @ 19.08.2019. 01:39 ] @
Ovde ima vrlo lepo sve opisano u specifikaciji za implelemntaciju Modbus-a kako treba postaviti stvari i sta je preporucljivo da se odradi:

http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

Moze da se ispostuje njihov protokol ali i ne mora niko nas ne primorava, korisno je videti postavku kako je osmisljena.
[ ZAS011 @ 19.08.2019. 01:48 ] @
Miki, iz prvog linkovanog dokumenta:
Citat:
A master-slave type system has one node (the master node) that issues explicit commands to one of the "slave" nodes and processes responses. Slave nodes will not typically transmit data without a request from the master node, and do not communicate with other slaves.

[ sdurut @ 19.08.2019. 06:51 ] @
Pogledaj u ovom dokumentu na strani 55 kako je rešena prozivka nepoznatog broja slejvova na strujnog petlji. Veoma jednostavno rešenja sa vremenskim slotovima. Ove module sam koristio i takođe ovaj protokol. Inače ovo je standardni X.28 komunikacioni protokol. Ne treba izmišljati toplu vodu. Ovo provereno radi.

ACG Reader module manual PDF
[ scoolptor @ 19.08.2019. 11:03 ] @
Veselinovicu, ukratko.

Sta treba da se uradi?

1. Master treba da na pocetku komunikacije izvrsi enumeraciju svih slave-ova
2. Dalje u toku komunikacije, master treba povremeno da izvrsi enumeraciju novih slave-ova, koji su naknadno dodati u sistem.

Kako se razlikuju slave-ovi?
1. Imaju ASCII ime, za koje nije garantovano da je jedinstveno
2. Imaju 48 bitni broj S_ID koji je jedinstven

Sta ce mater raditi kada identifikuje slave?
1. dodelice mu jedinstveni broj M_ID (recimo jedinstveni broj u opsegu 1..255), koji ce u masterovoj listi slave-ova biti povezan sa jedinstvenim identifkacionim brojem slave-a S_ID.

M_ID S_ID
1 0x442738
2 0x44274c
3 0x4429a7
...

Kako slave zna kada mu se master obraca?
1. dok nije identikovan, prati broadcast poruke, i poruke sa svojim jedinstvenim identifikacionim brojem S_ID (za dodeljivanje M_ID).
2. kada je identifkovan pa na dalje, prati poruke sa M_ID-om dodeljenim od strane mastera

Ako zelimo da koristimo vremenske slotove, treba da razmislimo koliko cemo vremenskih slotova da upotrebimo. Veliki broj slotova ce osakatiti komunikaciju.
Posto je jednoznacni identifikator S_ID duzine 48 bita, trebali bi da upotrebimo ogroman broj slotova (2^48), da bi se izbegle kolizije.

Ako vec ne mozemo da izbegnemo kolizije, treba da razmislimo kako se moze implementirati detekcija istih.

1. Detekcija kolizije od strane slave-a za vreme slanja, i prekid istog verovatno ne dolazi u obzir, posto mikrokontroleri i RS485 drajveri, nisu dizajnirani za ovu funkciju. Eventualno se moze pratiti stanje busa, pre pocetka slanja odgovora.

2. Preostaje detekcija od strane master-a, npr. primenom EDC-a, kao sto je CRC32, na osnovu koga moze sa odredjenom pouzdanoscu da odlici da li je odgovor koji je primljen od slave-a ispravan ili ne.

Zasto onda ne upotrebimo i vremenske slotove i detekciju kolizija?

Na pocetku komunikacije master salje komandu za enumeraciju, koja sadrzi n i s, koja znaci znaci da:

1. svaki slave koji do sada nije identifikovan od strane mastera (koji nema M_ID) treba da na osnovu s i S_ID pripremi hash vrednost duzine n bita
2. s je seed za izracunavanje hash-a
3. na raspolaganju ce biti 2^n slotova za odgovor
4. svaki slave koji do sada nije identifikovan od strane mastera (koji nema M_ID) treba da unutar vremenskog slota ciji je redni broj jednak izracunatoj hash vrednosti, posalje S_ID i EDC kod.

Ako master na pocetku konekcije posalje komandu za enumeraciju sa recimo n = 8, bice na raspolaganju 256 vremenskih slotova.
Nakon slanja komande za enumeraciju, master slusa odgovore, i pamti sve odgovore sa ispravnom kombinacijom S_ID i EDC.

Kada prodje vreme za sve vremenske slotove, master individualno kontaktira svaki od ovih slave-a putem zapamcenih S_ID-ova , i dodeljuje im jedinstveni M_ID. Ovde moze da se implementira dodatna kontrola.

Zatim master moze da ponovi proceduru par puta, pri tome menjajuci s, kako bi bilo moguce da se slave-ovi koji su prvi put imali istu hash vrednost raspare, i sledeci put okupiraju druge vremenske slotove.

Kada nakon slanja komande za enumeraciju, izostane odgovor za vreme trajanja svih vremenskih slotova, svi slave-ovi su identifikoavni.

Treba biti pametan i smisliti kako ce raditi hash funkcija koja za ulaz ima vrednost s, i S_ID, a za izlaz hash vrednost duzine n bita.

Dalje u komunikaciji, kada je ocekivani broj novih slave-ova u jedinici vremena mnogo manji nego na pocetku iste, master moze povremeno da zapocne proceduru enumeracije novih slave-ova sa n=2, n=4 itd, da bi se manje gusila komunikacija sa manjim brojem vremenskih slotova.

Ukoliko se neki slave resetuje, on ce se prilikom sledece enumeracije slave-ova ponovo javiti masteru, a master ce mu dodeliti isti M_ID (3), na osnovu S_ID-a (0x4429a7), koji ima u listi slave-ova.


[Ovu poruku je menjao scoolptor dana 19.08.2019. u 13:56 GMT+1]
[ veselinovic @ 19.08.2019. 20:10 ] @
Hvala svima na odgovorima.
Skulptore,
pazi sad ovamo:

Kako slave zna kada mu se master obraca?
1. dok nije identikovan, prati broadcast poruke, i poruke sa svojim jedinstvenim identifikacionim brojem S_ID (za dodeljivanje M_ID).


Problem je sto master inicijalno nema pojma o S_ID nijednog slejva. Kao ni podatak ima li i koliko slejvova.



Treba biti pametan i smisliti kako ce raditi hash funkcija koja za ulaz ima vrednost s, i S_ID, a za izlaz hash vrednost duzine n bita.

E ovo je kljucni problem koji postoji od ispocetka.
Nesto cu vec skontati.
[ bogdan.kecman @ 19.08.2019. 20:28 ] @
a vidi ti pokusavas da nabudzis kompleksan sistem a da ga koriste
pajseri :( ... i naravno da je nemoguce .. zato se ti ogradis procedurom
koja mora se ispostuje i bas te briga .. u tom slucaju ti imas mogucnost
da napravis "kako oces" jer mora se postuje ta procedura ...

npr, slave NEMA ID, ima eprom/flash gde moze da ga sacuva i originalno
ga nema

u slucaju da se slave podize "sa nekom forom" (kao sto mu setujes to ime
negde nekako) on ako ima slucajno ID on ga sam sebi obrise, ili svaki
put kad mu menjas to "ime" obrises mu ID ako ga slucajno ima..

"novi" slave se dodaje u chain SAMO PO JEDAN

i dalje ti je jasno .. master na svakih X ili na svaki restart, ili ...
posalje broadcast, i slave ako nema ID javlja se na broadcast i kaze
"eve me kume daj mi ID" i ovaj mu posalje novi id i eto registrovo se ...

ili umesto "nema id" slave po defaultu ima id "-1" (sve ostalo isto, sam
sebi postavi -1 kad mu menjas ime etc etc), master povremeno, posle
reseta, kad zelis, na dugme, posalje poruku na -1 i kaze, aj kume ako si
tu javi se, i onda ako se jave, super kume ti si sad ID xyz ..

u svakom slucaju onda master postavlja ID koji on oce za novog slave-a i
registracija radi lako, master zna koga ima, kad ga je dodao, slave zna
ko je i koji mu je id ..

ako neces tako onda opet kao standardan 10base2, znaci posaljes "ko je
sve novi" broadcast, i oni se svi jave, javljaju se tako sto "slusa dal
ima nesto na mrezi, ako nema javi se, ako kad krene da se javlja dobije
koliziju saceka random * 100ms pa opet slusa dal ima koga na mrezi, pa
ako nema krene da se javlja..."
[ scoolptor @ 19.08.2019. 21:10 ] @
Citat:

Problem je sto master inicijalno nema pojma o S_ID nijednog slejva. Kao ni podatak ima li i koliko slejvova.

S_ID ove nauci iz odovora u time slotovima gde nije doslo do kolizije.
Potom piziva svaki slave i dodeljuje mu M_ID.

Citat:

Treba biti pametan i smisliti kako ce raditi hash funkcija koja za ulaz ima vrednost s, i S_ID, a za izlaz hash vrednost duzine n bita.

E ovo je kljucni problem koji postoji od ispocetka.
Nesto cu vec skontati.


Nista lakse. Uzmes 6 bajtova S_IDa dodas sedmi s, izracunas CRC8 za ovu sekvencu bajtova, i uzmes n bitova, pocev od pozicije 0.

Sa jednim s npr. slaveovi 2 i 7 ce zauzimati isti time slot, pa ce doci do kolizije, a sa drugim nece, pa ce moci da se identifikuju.

[ scoolptor @ 19.08.2019. 21:27 ] @
Broadcast. Enumeracija: s=0, n=8
Svi slaveovi izracunaju hash u opsegu 0 .. 2^8-1=255 na gore opisan nacin.
6 slaveova imaju jedinstven hash, dok dve grupe po dva slavea imaju isti hash.
Svi slaveovi posalju svoj S_ID+CRC16 unutar svog slota ciji redni broj odgovara izracunatom hashu.
Slaveovi sa jedinstvenim hashom bivaju prepoxnati od strane mastera, koji salje lo jednu komandu dodele M_ID svakom slaveu sa identifikovanim S_IDom
Potom master ponavlja enumeraciju sa s=1, n=4
Preostali slaveovi pripremaju hashove u opsegu 0..15, i odgovaraju unutar svojih vremenskih slotova.
Sada prvi i cetvrti preostali slave ima jedinstven hash dok drugi i treci imaju isti hash.
Itd.
Nakon 2 nove iteracije enumeracije nema vise odgovora, i svi slaveovi zu identifikovani.

Periodicno se enumerisu novi slaveovi sa n=2 odnosno 4 vremenska slota.
Itd.
[ scoolptor @ 19.08.2019. 21:34 ] @
Ako dodje do reseta slavea on se javlja kao novi slave za vreme sledece enumeracije, a master ce mu dodeliti isti M_ID koji je imao ranije, jer pri dodeli M_IDa prvo proverava da li je S_ID u trenutnoj listi slaveova cije je S_IDove naucio za vreme prethodnih enumeracija.

Ako se resetuje master, ide sve od nule.
[ scoolptor @ 19.08.2019. 22:26 ] @
Poboljsanje, ako se uspe u inplementaciji detekcije kolizije slave-ovim MCUom, da slaveovi postanu tihi, tj. da ne pokusavaju ponovo da se oglase, do kraja vremena za time slotove, i nove broadcast komande za enumeraciju.
[ veselinovic @ 04.09.2019. 06:20 ] @
Na zalost nisam jos probao ideju,
iskrslo je nesto trece da se mora zavrsiti.
Mislim da imam kompletno sve u glavi, ostaje da se proba.
Javicu se ja sa rezultatima.