Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

ATMEGA 644A – RS485 buszos adatgyűjtő áramkör

A következő posztban szeretnék bemutatni egy olyan témát, ami a műszaki praxis során sokszor előfordul, azonban számtalan apró buktatója van és általában az eredménytermék nem tudja azt, amit az alkotók és a megrendelők elvárnak tőle.

Az én gyakorlatomba is pont ilyen okból került be ez a feladat: Adott volt egy meglévő adatgyűjtő rendszer, ami maximum 30 eszközből néhány bitnyi információt gyűjtött, és képes volt néhány bitnyi adatot – működtető kimenetekként – eljuttatni az adatgyűjtés helyére.

A példaként beszállított alkalmazás több hibával, döcögősen üzemelt és a vizsgálatom után megszületett az újratervezést támogató döntés.

A tervezés során fél duplex kommunikációs protokoll mellett döntöttem, az igények kiszolgálására ez is elégségesnek bizonyult. Döntésem hátterében a duplex kommunikáció ellen a kétszeres hardver igény – és így kétszeres meghibásodási lehetőség – szólt.

A kommunikáció megvalósítására az áramhurkos RS485-ös összeköttetést tartottam a legalkalmasabbnak, mert alkalmas sodrott érpáros vezetéken akár 5MB/s átvitelt 100m+ távolságra is biztosítja.

Ennek tipikus topológiáját a következő ábra mutatja:

SN75176 tipikus alkalmazása
RS485 busz struktúra 32 kapcsolódó eszközhöz.

Az így összekapcsolt mikrokontrollerek (SLAVE-eszközök) egy buszon kapcsolódnak az adatgyűjtő számítógéppel soros porton kapcsolódó busz illesztést és vezérlést végző MASTER eszközhöz.

Ez gyárthatósági és praktikussági okokból azonos hardvert jelent különböző betöltött programokkal.

Az RS485 busz gyártói ajánlat szerinti PCB kialakítására egy példát találunk a gyártó adatlapjában, ami nem sok segítséget, éppen csak iránymutatást ad.

SN75176 tipikus PCB ajánlás

A lényeg azonban így is látható : rövid, vastag vezetékekkel kell az áramkört a busz vezetékhez kötni. A műszaki gyakorlatban sodrott érpáros kábeleket legolcsóbban CAT5E+minősítésű nyolceres “internet” kábelként lehet beszerezni. Ilyen kábeleket praktikusan RJ-45 csatlakozóval mutatkozott célszerűnek szerelni.

Az áramkör tervezésnek szinte egyik kulcsmozzanatához értünk: Az érsorrend kiválasztásnál úgy kell eljárjunk, hogy a kapható kábelek esetén az “A” és “B” vezetékek egy pászmába kerüljenek.

Bus kapcsolat RJ-45 csatlakozón keresztül

(a gyakorlat azt mutatja, ez nem mindíg és nem mindenkinek sikerül)

Jelen példánkban a 4 -5 vezetékek és 3 – 6 vezetékek egy pászmába esnek. A szokásos színjelölés mellett zöld – zöld/fehér és kék – kék/fehér erek. A párhuzamosítást redundancia miatt végzem. A próbagyártás és tesztelés során az összeköttetés minőségi paramétereit lényegesen javította az ilyen párhuzamosság.

Adatgyűjtő készülék PCB SMD beültetés előtt.
ATMEGA644A mikrokontrollerrel készült RS485 buszos adatgyűjtő készülék

A kép jobb oldalán látható a busz csatlakozó foglalata. Ide jó minőségű árnyékolt kivitelű aljzat kerül beültetésre, az áramköri lemezhez forrasztott árnyékolással. A vezetékek topológiáját úgy alakítottam ki, hogy az alkatrész oldalon a csatlakozót árnyékoló fém ne okozzon zárlatot a használat (mozgatás, során a fém ház súrlódhat az alatta lévő fóliával) során.

A két csatlakozó közt található a buszmeghajtó illesztő áramkör, csatlakozása rövid, vastag vezetékkel biztosított.

Félgyártmány forrasztási oldal
ATMEGA644A mikrokontrollerrel készült RS485 buszos adatgyűjtő készülék

Az illesztő áramkör két darab RJ-45 típusú csatlakozóval kapcsolódik a buszhoz: így a kábelek könnyen előre gyárthatóak csatlakoztatásuk gyors telepítést tesz lehetővé.

Az áramkör tervezésénél másik nagyon fontos probléma volt a cél rendszerek digitális földjeinek különböző potenciálja. Ezek elválasztását opto-csatolók biztosítják. A tápenergia ellátás egy közös vezetéken keresztül történik, egy kis kapcsolóüzemű tápegység használatával: így elérhető hogy a tápfeszültség esés a teljes vezetékhosszon alacsony legyen, és az energiaszállítás jó hatásfokon történjen.

Ez különösen fontos, amikor 32 áramkör (teljes kiépítés) kerül telepítésre. A tápfeszültség ilyenkor 20..32 V teljes áramfelvétel 200mA. Így a tápenergia kábelezésre tökéletesen megfelelt a közönséges flexibilis hangszóróvezeték erenként 0.5 négyzetmilliméter keresztmetszettel.

A megépített és néhány száz példányban már telepített készülék 20 MHz órafrekvencián stabil üzemet biztosít 250kbit/sec átviteli sebességen.

Sokakban felmerülhet a busz lezáratlanság kérdése. A busz lezárását praktikusan az utolsó áramkör üresen maradó RJ-45 csatlakozójába egy aljzatba krimpelt ellenállással lehet elvégezni. A tapasztalat azt mutatja, hogy ez szükségtelen.

A bus MASTER készülék paneljén a kommunikációs vonal potenciálját fél tápfeszültség közelébe az R29 és R28 ellenállásokkal lehet elvégezni. A tapasztalat azt mutatja, hogy kompatibilitási okokból ez szükségtelen sőt elkerülendő!

Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

A Z80 processzor diszkrét bája

Őskövület a feledés szemétdombjáról – mondhatnánk azonban több szempontból is rendkívüli figyelmet érdemlő mikroprocesszort, valamint a benne rejlő lehetőségek alkalmazását és ennek programvédelmi megfontolásait szeretném ebben a posztban bemutatni.

Ki ne szeretett volna már olyan hardveres programvédelmet készíteni, ami egyrészről hatósági eljárás céljából a programot rögzíti kiolvasható módon (eprom) ugyanakkor a konkurencia reverse-enginering próbálkozásai ellen megvédi azt?!

Erre kínál egy kiváló lehetőséget ez a processzor, és ennek használati technikáját szeretném röviden bemutatni itt. Ahhoz, hogy megértsük miként működik ez a védelmi megoldás, tekintsük át a processzor és a perifériák közti kommunikációt memória írás és olvasás tekintetében.

Processzor - busz kapcsolat
A processzor memória kapcsolat időbeni felosztása.

Az ábrán látható a Z80 processzor memória hozzáférés időzítése. Vegyük észre, hogy a processzor megkülönbözteti az utasítás lehívási ciklust a többi memória hozzáféréstől, ami lehetőséget biztosít az adat és programkód memória elválasztására. Ezzel a lehetőséggel azonban védelmi szempontból is tudunk élni, mégpedig pont úgy, hogy az adat és kód hozzáféréseket egy memóriában tároljuk lehetőleg jó alaposan összekeverve. Az utasítások és adatok alkalmasan összekevert mintája a program egyedi “ujjlenyomata” is lehet, és mivel a tárgykód változás esetén relokálódik, mert a fordításkor az utasítások számára foglalt hely változik, nagyon egyedi is lehet. Alkalmas fordítóprogrammal és makrók használatával a kódba ékelt adatok mennyisége a kód méretének néhány százalékos mértékét meghaladó méretben a visszafejtést nagyon megnehezíti.

Utasítás beolvasási ciklus
A processzor utasítás beolvasási ciklusa (M1)

A fenti ábrán a processzor utasítás lehívási ciklusa van ábrázolva, és pirossal kiemelve amikor a buszról utasítás byte-ot olvas a processzor. Ha egy utasítás több byte-ból áll, akkor a T1-T4 ciklusok ismétlődnek addig , míg a teljes utasítás beolvasásra nem kerül.

Amikor a processzor az utasítást végrehajtva memória műveletet végez – olvasási vagy írási esetleg R-M-W ciklust, akkor az alábbi diagram szerint történik a memória hozzáférés:

Processzor memória olvasási és írási ciklusa
A processzor – memória kapcsolat időbeni megvalósulása.

Ugyan a diagramon az M1 vonal nincs ábrázolva, de ezen ciklusok alatt logikai “H” szinten áll, azaz inaktív.

A programunk védelmére ez biztosítja a gyakorlatilag csak nagyon nehezen megfejthető megoldást.

Tekintsük az alábbi kódszakaszt és annak memóriába fordított gépi kódját!

példa a kódba ágyazott adathozzáférésre
kódba ágyazott adat

Vegyük észre, hogy a befordított tárgykódban a szubrutin hívó utasítás utáni két byte-ot a szubrutin ADATKÉNT olvassa fel a memóriából, a környező utasítás byte-okat viszont KÓDKÉNT! A különbséget a hardveres működés során a fentiekben ismertetett M1 vonal aktivitása jelzi.

A példában a veremtárban a stackpointer mögött egy lokális változót hozok létre, hivatkozás az (IX -2) mutatóval történik azt kinullázom, majd ötig elszámolok vele a példa kedvéért. A rutin végrehajtása után felszabadítom a veremtárban foglalt helyet. A foglalt hely mérete 2 byte, ennek komplemensét adom az SP regiszter aktuális értékéhez, ami tulajdonképpen a kivonást jelenti.

A programvédelem hardver alapja, hogy az adatbusz tartalmát a címbusztól függően összekeverem, ha kellően bonyolult a függvény, akkor ez már jól védi a memória tartalmát visszafejtés ellen, de azért néhány kreatív ötlettel visszafejthető. (lásd xx posztot, ezt még nem írtam meg, de tervben van) A hab a tortán csak ezután jön! A kódoló függvénybe vegyük bele az M1 vonal értékét például egy XOR kapun keresztül!

Amennyiben saját fordítóprogramunk van (én ezt használok) és azt úgy írtuk meg, hogy a program által generált objektum kód tartalmazza, hogy mely byte-ok utasítások és melyek adatok, akkor a tárgykód készítésekor (eprom tartalom előállítása) ezeket különféleképpen kódolva jutunk el a csaknem visszafejthetetlen kódig. A példában a kódoláson felül az adatként értelmezett byte-okat negálni kell.

Ezt azzal lehet elérni, hogy a példában bemutatott módon kreatív makrók alkalmazásával például egy érték paraméter szerinti rutin felhívást (c# switch – case struktúra) valósítunk meg:

switch-case példa

A példában a .db és .dw utasításokkal definiált byte-ok adatként kerülnek tárolásra, (még a cimkék is!) míg a többi kódként.

Ez a visszafejtésnél azért okoz nehézséget, mert a kódot soronként kell elemezni, hogy egy szubrutinhívás után adat vagy programkód következik, esetleg indirekt szubrutinhívással még jobban nehézzé tehető a helyzet. Ekkor annak, aki a kódot meg akarja fejteni a visszafordítás során el kell dönteni egy eprom adatról, hogy az adatként vagy kódként kerül feldolgozásra, mert ettől függ a processzor – memória közé beékelt kódoló logika működése. További nehézséget jelent a bemutatott példában az adatstruktúra értelmezése, ugyanis byte-os konstansok, word-os konstansok, és word hosszúságú szimbólumok értéke is kerülnek egymás után tárolásra. Ennek a struktúrának az értelmezése a felhívott szubrutin dolga, amit itt terjedelmi okok miatt nem mutatok be, de a működése könnyen érthető: az első .w konstans megmutatja hány ága van a switch szerkezetnek, utána byte-os konstansokkal felsorolásra kerülnek a különböző esetek, majd az illető esetekre és az ELSE ág lefordított tárgykódjára mutató szimbolikus címek értékei következnek.

Ez a processzor számára “in-situ” körülmények közt természetesen megy, az eredmény az M1 vonalon, de ez a kódolt eprom vizsgálatakor byte-onként nem áll rendelkezésre a kíváncsi tekintetek számára! 🙂

Nos, dióhéjban ennyit szeretnék elmondani erről, nem veséztem ki teljes mértékig a témát, különös tekintettel az interrupt ciklusok és az M1 vonal működésének összefüggésére, de úgy vélem bemutattam egy technikailag szofisztikált programvédelmi megoldást, ami megalapozza ennek a processzornak a XXI. században történő használatát.

Kategóriák
Egyebek, gépház, házirend stb. Maga az iparos. Történetek a múltból és a jelenből. Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér Utazás, szabadidő és mindenféle érdekes dolog. Véleményem a világ dolgairól

Helló Világ!

Annak írok, aki itt jár. Ha tetszik ha nem, ennek a honlapnak a gazdája én vagyok. Nekem kell felelősséget viselni a törvények szerint.


Szabályok:
Az egészséges, építő, jobbító kritikát szívesen fogadom.


A kérdésekre, kérésekre, szívesen válaszolok, de ez a saját munkám terhére nem mehet.


Aki türelmetlen vagy zaklat, kitiltom.


Aki tiszteletlen azt kitiltom.

A számomra elfogadhatatlan, üzleti és/vagy magánérdekeimet sértő hozzászólásokat törlöm.

Ha valaki linkel engem, viszonossági alapon én is linkelem őt. Ez természetes, kedvenceimet a kedvencek menüben találhatják.


Ennyi.