My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
Szoftverterv  
Elgondolások a szoftveres megvalósítással kapcsolatban
Featured, Phase-Design
Updated May 8, 2010 by kirm...@gmail.com

A feladat által megkívánt megfontolások

  • Algoritmus
  • Hálózati protokol
  • Időzítés

Részletek

Algoritmus

Bizánci típusú hibák kiküszöbölésével nem foglalkozunk, az külön házi feladat

Az algoritmus magjának áttekintő leírása megtalálható a hivatalos jegyzetben. Ehhez a következő pontosításokat tesszük hozzá:

  • inicializálni kell a timert, a rádiót, ro(0)=0, delta(0)=0, h= <a kvarc pontatlansága>
  • drift becslése
    1. dT=(Ci-ro), ahol
      • dT az előző szinkronizáció óta eltelt idő
      • Ci az algoritmust futtató node lokális ideje
      • ro [görög ró] az előző szinkronizációs időpont
    2. dC=Cnew-Cold, ahol
      • dC az óramódosítás mértéke
      • Cold az algoritmust futtató node lokális ideje a módosítás előtt
      • Cnew az újonnan elfogadott idő
    3. deltanew = dC/dT a drift becslője
    4. ezen delta becslések rekurzív átlagolása delta=A*delta+(1-A)deltanew
  • A drift becsléssel kiegészített algoritmus folyamatábrája a 2. ábrán megtalálható.
  • Az órák számlálójának túlcsordulása nem okoz problémát az algoritmus implementálásában, ha azt unsigned típusként használjuk fel.

Hálózati protokoll

  • Bár csak 3 node-unk van, 15-re készülünk fel (+1 broadcast cím), mert annyi lehetséges azonosító van (lásd kiírás: azonosító választás a DIP kapcsolókkal) és fel kell készülni dinamikus hálózatátrendeződésre
  • Rádiós keret tartalma:

feladó azonosítója üzenet típus (szinkronizáció kérés,válasz) Cj Ej

  • Szinkronizációs kérés vételekor az esetleg fennálló aktív rádiós kapcsolatok passzíválódnak és ez utóbbi kérés kiszolgálása következik
  • A kérés vételének időpontjától minden használt és nem-használt azonosítóhoz egy time-slot rendelődik, amikor a kérésre reagálhat.
  • Ezen felül adva lesz egy ún. macrotick, amelyet 15 time-slotra osztanak fel az egyes azonosítók időzónái
  • Egy macrotick egy azonosítóhoz tartozik, amelyben ő kérhet szinkronizációt és a többiek ezt kötelesek kiszolgálni.
  • A macrotickek körcímzéssel az összes létező (15 db) azonosítón végighaladnak, így biztosan mindenki kér szinkronizációt egy bizonyos időn belül és elkerülhetők a rádiós ütközések.
  • A node bekapcsoláskor még nem tud semmit a környezetéről, ezért hallgatózik, vár max. 15 macroticket, hogy megtudja, vannak-e még rajta kívül más node-ok jelen. Ha vannak, akkor ezen az időn belül biztosan eljut hozzá egy szinkronizációs kérés, amivel ő maga be tud illeszkedni a hálózat laza időzítési (macrotick és time-slot) rendszerébe. Ha nem észlel ennyi idő alatt kérést, akkor addig a pillanatig ő az egyedüli node, elkezdhet kérést generálni.

Legyen pl. 0 a broadcast cím! Ekkor egy hiperciklus:

Macroticks 1 2 3 ... 15 1 ...
time slots 1 2 3 4 5...15 1 2 3 4 5...15 1 2 3 4 5...15 ... 1 2 3 4 5...15 1 2 3 4 5...15 ...

Időzítések

  • A belső időzítésekre egy timer egységet használunk (nem az ütemezőét), amivel a válaszadókban a kérés beérkezése és az adás megkezdése között eltelt időt, a lekérdezőkben a kérés rádiós teljesítése és a válaszok beérkezési idejeit tudjuk mérni
  • Az adófüggvény kezdete becsülhető úgy, hogy tudjuk a kerethosszat és az adatátviteli sebességet, azaz a függvény végrehajtási ideje becsülhető a vevőben, mert az api blokkoló
  • A timerrel az időmérés a számláló állásának feljegyzésével történik, nem nullázgatjuk
  • Az keret küldő függvény hívását kölcsönös kizárással kell védeni, hogy a vevő szál által küldött válaszok és a szinkronozó szál által küldött szinkronizációs kérdések ne keveredjenek össze. (lásd 1. ábra). A timer interrupt nem okoz nagy problémát a rádiós adás közepén sem (reméljük), ha elég gyors. (Lehetne egy külön rádiós adó-szál, hogy ne kelljen kizárás, de túl erőforrás-igényes és lassít, bonyolítja az időmérést.)

Egyebek

  • Soros porti monitorozás demonstráció és mérés végett

Implementáció

Két szálra szükség lesz, egyik a vevő, másik az adó. Mivel az API blokkolásos, a vevőnek kell alacsonyabb prioritásúnak lennie.

A szinkronizáció pontosságához célszerű az óra állását vagy a mért bizonytalanságot, vagy mindkettőt időnként elküldeni soros porton, vagy valamelyik lábon periodikus tüskéket kivinni. Utóbbit olyan helyre, ahol szkóppal csatlakozni tudunk rá. Az UART-os megoldás esetén a TX szál végére még kell egy printf parancs.

Ábrák

Normális felbontáshoz jelenítsd meg a képet!

Áttekintő folyamatábra

overview

Óraátállítás

újraszinkronozás

Powered by Google Project Hosting