- Szoftveres sorosport néhány előnye
- korlátozások
- különbségek a beépített hardveres sorosport-hoz képest
- példaprogram
————————————————————————
Az ATMega328 és hasonló vezérlőkbe beépítettek egy hardveres USART egységet (vannak hasonló vezérlők, amikben több is van). A sorosport-i kapcsolat a legegyszerűbben kezelhető, ráadásul az Arduino alaplapokon még egy USART-USB illesztő chip-et is elhelyeztek. Így természetesen az Arduino és a PC között ezzel a legegyszerűbb kommunikálni. Semmi nem kell hozzá!
Mi történik akkor, ha nem csak egy, hanem több sorosport-ra is szükségünk lenne? Pl. van egy eszközünk, ami sorosport-on kommunikál az Arduino-val, ugyanakkor szeretnénk a PC soros monitorán is adatokat megjeleníteni pl. azért mert a fejletlen debug képességek miatt a programhibák megkereséséhez ez szinte nélkülözhetetlen. Erre találták ki a szoftveres soros portot. Alapból megkapjuk ezt a szoftver eszközt az Arduino IDE feltelepítésekor. Most ezzel az eszközzel szeretnék egy kicsit foglalkozni.
Első alkalommal azért kényszerültem a szoftveres sorosport használatára, mert hibát követtem el. NYÁK tervezésre adtam a fejem, és az ingyenes Altium CircuitMaker programmal elkövettem első nyomtatott áramkörömet, amit kínai testvéreink meglepően olcsón kb.2000Ft-ért le is gyártottak öt példányban. Szuperül sikerült, és kisebb hibáktól eltekintve jó is lett. Azonban egy komolyabb hiba is becsúszott túlzott magabiztosságam miatt. Történt, hogy megterveztem az áramkört és mivel annyira egyszerűnek tűnt, nem raktam össze próbapanelen, hanem rögtön megrendeltem ellenőrzés nélkül. Ezt már megbántam!
Sorosport-on kapta az áramkör az adatokat, és mivel hosszú vezeték kötötte össze az adatforrással, beterveztem egy optocsatolót. Csak épp azt felejtettem el, hogy az optocsatoló kimenete inverz. Így aztán minden bit ellentétesre változott a soros kapcsolatban. Hosszasan elemezgettem a problémát és ráleltem a megoldásra. A szoftveres sorosport képes arra, hogy megfordítsa a jelszinteket. Ez sajnálatos módon nem csak a vételre, hanem az adásra is vonatkozik, így nem működött volna a program illesztésekor nagyon hasznos sorosport-i írás a PC felé. De erre is lett megoldás.
Lássuk hát mi is kell a szoftveres sorosport-i megoldáshoz. Fontos tudni, hogy a szoftveres sorosport korlátozásokkal működik:
- A szoftveres sorosport megszakítás alapon működik. Csak azokon a kivezetéseken működhet, melyek képesek megszakításokat kezelni. Az ATMega328 és hasonló vezérlők legtöbb kivezetése képes erre, de nem mind. Pl. Az Arduino nano alaplap A7 és A8 kivezetése nem (Arduino Uno-n ez nincs is kivezetve). Az könyvtár leírásában erről többet is lehet olvasni.
- Több sorosport-ot is beüzemelhetünk a programunkban, azonban mindig ki kell jelölnünk, hogy melyik figyeli a saját RX kivezetését. A többi ez alatt nem érzékeli a saját RX kivezetése eseményeit.
- Beállítható, hogy az RX és TX kivezetést inverz módon kezelje a szoftveres sorosport-i program. Ez annyit jelent, hogy normál mód esetén a bemenet (és a kimenet) alap állapotban magas jelszinten van, és a stop bit alacsony jelszinttel jelzi az átvitel kezdetét. Inverz mód esetén azonban az RX és a TX is alap állapotban alacsony jelszinten van, és a start bit magas jelszinttel kezdi az átvitelt.
A függvények használatához nem kell semmit letölteni és telepíteni. Mindössze a programunkban el kell helyezni a következő sort:
#include <SoftwareSerial.h>
Ezt követően a fordító a program fordításakor a sor helyére beemeli a SoftwareSerial függvényosztály forráskódját. Természetesen a programban létre kell hozni a működéshez legalább egy programpéldányt a függvényosztályból. Ezt a következő sorral tehetjük meg:
SoftwareSerial mySerial = SoftwareSerial(Rx, Tx, Inverse);
Ahol a mySerial lesz a programpéldány neve, erre fogunk hivatkozni a metódusok hívásakor. Rx a sorosport bemenetének kijelölt kivezetés. Tx a kimenetnek kijelölt kivezetés, az Inverse pedig egy bool típusú változó. Ennek false értéke esetén normál módon működik a sorosport, míg true esetén invertált jelszintekkel dolgozik. Ez kellett nekem! Ha ezzel készen vagyunk, el kell indítani a szoftveres sorosport-ot. Írjuk a setup() részben a következőt:
mySerial.begin(boudrate);
Ahol a mySerial az objektumpéldányuk neve, a begin a sorosport indítását végző metódus neve. Ez beállja a port sebességet, ami a boudrate változó értéke. Pl. direktben beírhatjuk ennek a változónak a helyére 9600.
Ettől kedve készen áll a szoftveres sorosport a használatra. Mindent ugyanúgy kell használni, mintha a beépített hardveres sorosport-ot használnánk. mindössze a „Serial” helyett azt írjuk, hogy „mySerial”. Pl. ha szeretnénk kiírni a soros monitorunkra egy szöveget, akkor ennyit kell írni:
mySerial.println(„szöveg”);
Van azonban egy fontos teendő, mert ha több szoftveres sorosport-i objektumpéldányt is létrehoztunk, ki kell jelölnünk, hogy melyik legyen az aktív, ami éppen figyeli és várja a bejövő adatokat a neki kijelölt Rx kivezetésen. Ha több objektumpéldányunk is van, akkor azt a következő módon tehetjük meg:
mySerial.listen();
Lássunk most egy működő programpéldát. Az alábbi kód a fentebb említett problémára ad megoldást. Vagyis lecseréli a hardveres sorosport-ot egy szoftveres sorosport kezelő objektumra (readSerial), ami a hardveres sorosport számára kijelölt bemenetet használja (D0 kivezetés). Ennek az objektumpéldánynak Tx kimenetnek egy éppen nem használt tetszőleges kimenetet jelöltem ki, mert nem akartam adatot küldeni, csak fogadni. Az „Inverse” módot természetesen be kellett kapcsolnom, mert a vezérlő elé kötött optocsatoló sajnos invertálta a jelszinteket, amit a beépített hardveres sorosport nem tud kezelni. Létrehoztam egy másik objektumpéldányt is (writeSerial), amivel viszont a PC-n elindított soros monitorra tudok információt küldeni. Mivel a soros monitor sem képes „inverz” jelszintekkel működni, itt az inverz módot nem szabad bekapcsolni. És természetesen ez a szoftveres sorosport-i objektumpéldány a beépített hardveres sorosport kimenti kivezetésére akaszkodik rá (D1), mert azon ott csücsül az USART-USB illesztő, ami a kimenő adatokat az USB portra küldi a PC-n. A programban jó sok a komment, remélem érthető:
#include <SoftwareSerial.h>
//Arduino nano-nál figyelni, mert fordított sorrendben vannak a kivezetések, 1 és 0 a sorrend.
//Azért használok két SoftwareSerial objektumot, mert az egyik inverz logikára van állítva. Ennek oka
//hogy a nyákterven beraktam egy optocsatolót, ami jelet invertál, de elfelejtettem vissza invertálni
//így a beépített USART-ot nem tudom használni. A SoftwareSerial.h viszont képes inverz jelszinttel
//dolgozni, így minden működik a nyák módosítása nélkül, és a soros kimenet is használható marad,
//ha valamit ki akarok írni a képernyőre (debug).
//A readSerial példány az ATMEga328 USART RX kivezetésére akaszkodik, a TX kivezetés egy nem használt kivezetés kell legyen
//A writeSerial példány az ATMega328 USART TX kivezetést használja, és normál jelszintre van állítva.
//Így a soros USB illesztő az ide írt adatokat küldi az USB portra és lehet debugolni!
SoftwareSerial readSerial = SoftwareSerial(0, 2, true); //RX=0, TX=2, inverz logika, ezzel olvasok
SoftwareSerial writeSerial = SoftwareSerial(3, 1, false); //RX=3, TX=1, normál logika, ezzel írok ha debug-ot akarok a programban
//A program a sorosportról érkező adatokat figyeli és kiírja a soros monitorra az érkezett adatot.
int read_data=0; //ebbe olvasok a soros pufferből, ha jött valami
void setup() {
readSerial.begin(9600); //softveres sorosport vételi-példány indítása
writeSerial.begin(9600); //sorftveres sorosport adás-példány indítása
readSerial.listen(); //vétel példánynyt figyelésre állítom, mert softveres sorosportnál ki kell jelölni, melyik figyeli az érkező adatokat
writeSerial.println("indul..."); //hogy lássak is valamit a soros monitoron
}
void loop() {
if (readSerial.available() > 0) { //érkezett valami
read_data = readSerial.read(); //érkezett adat beolvasása
writeSerial.println(read_data); //érkezett adat kiírása a PC-n futó soros monitorra
}
}