Fórum témák
» Több friss téma |
Sziasztok!
Egy atmega128-at akarok a pc-vel összekötni egy ft232 segítségével. Terminál programban működik a dolog, tudom vezérelni az avr lábait, de szeretnék egy programot írni, hogy ne keljen terminál programot használni. Az a problémám, hogy nem tudom, hogy hol induljak el. C-ben szeretném megírni windowsra, de nem találok példaprogramot, vagy leírást.
szia!
Próbálj meg elindulni így: Bővebben: Link
Talán ez segít. Elég kimerítően írnak a témáról
 Itt. Én is innen vettem mindent .Annyi különbséggel, hogy át kellett írnom Delhibe.
Köszi. Ismerem. Magam részéről, nem használom...
Üdv!
Két db atmega8-ast szeretnék összekötni soros porton, egyik csak küld, a másik csak fogad 8 bites adatcsomagokat. Az adó része szépen működik, szépen küldözgeti az adatokat, hallom a pittyegést a piezohanszórón. A vevő viszont bármit csinálok továbbugrik a következő néhány soron: unsigned char USART_Receive() { while (!(UCSRA & (1< < RXC))); //fórummotor miatt raktam szóközöket... return UDR; } Akkor is, ha nincs semmi az RXD lábon. Folyamatosan ~2V-ot mértem itt. Megsült volna vagy a felhúzóellenállását kéne kikapcsolni? Rosszul konfiguráltam? Nem tudom. Másik atmega8-asommal is ugyanezt csinálja. Mellékeltem az adó ill vevő forráskódját. C-ben írtam, de leginkább ollóztam. Kezdő vagyok még, mindenféle építő kritikára kíváncsi vagyok. Az atmega8 adatlapján lévő kódok alapján próbáltam megírni a kommunikációt. Az egész célja egy távirányító készítése, 433Mhz-es rádiós modulokkal, ezért próbálok minél több hibakiiktatást alkalmazni. Egyelőre kábellel van összekötve az adó és vevő. Adó oldalon egy potméter->feszülségosztó értékeit olvassa le, besorolja kategóriákba, majd átküldi 3 biten a 2 bitnyi értékeket. Vevő oldalon értelmezi az értékeket és meghajtja a motort egy tranzisztor-mosfet kombón keresztül. Később 8 biten szeretném egyszerre elküldeni 2 motor értékét és egy "kioldó" parancsot. Ezek már mind működtek külön-külön, csak a kommunikációval akadtak problémáim. Előre is köszi a segítséget!
Meg van a megoldás, rendes hibamentes adatokat küld.
Nem tudom pontosan hogyan, meg miért, de ki kellett törölni az RXC-t indításnál. main függvénybe írtam: UCSRA &= ~ (1< Úgy néz ki ülnöm kellett rajta fél napot és be kellett ide írnom, hogy rájöjjek  >>
Nagyrészt angoltudásom hiánya miatt nem tudok rájönni, hogy hogyan kell használni ezeket
Üdv.
Abban tudna valaki segíteni hogy.. .Net VB Soros port működik a SerialPort objektummal szépen, viszont a portot kézzel kell beállítanom. (ComX) Na ezt szeretném, ha a nyitott portról ki tudnám olvasni a készülék tulajdonságait (azonosítóját, gyártó nevet, stb) ezzel megkeresve mely porton található a cucc. Köszönöm.
Üdv!
Ha automatikusan szeretnéd megtalálni a létező soros portokat, akkor ezen a példán keresztül könnyen megteheted.
Ez is jó, ötlet én nyitogatással mentem volna végig.
 Viszont nekem azonosítani kellene a portot melyiken van a készülékem. FT232-vel csatlakoztatva
Ha az FT232-ből akarod kiolvasni a VID-et és a PID-et, akkor ahhoz az FTDI-től letölthető dll-t kell használnod.
Ha a készülékből akarod kiolvasni, akkor azt neked kell tudnod, hogy hogyan működik...
FT232-ből akartam kiolvasni. Közben én is erre jutottam hogy küldök jeleket folyamatosan a PC felé, ott megnyitogatom a portokat és ha megvan a jel akkor felépítem a kapcsolatot.
Amit küldtél szuperül működik. Köszi.
Tiszteletem.
Az lenne a kérdésem, hogy van valamilyen egyszerű módszer arra, hogy leteszteljük az RS232-es portot? Szeretnék adatokat küldeni PC-ről, ehhez szeretném az alaplapi soros portot (DB-9 female csatlakozó). Összekötöttem a Rx-Tx, DSR-DTR, CTS-RTS vonalakat, és végig próbálgattam a COM portokat a realtherm segítségével. (Mint ahogyan itt is látható.) Egyik portról sem kaptam vissza semmit, viszont gyanús, hogy a COM0, COM1 portokat nem engedte megnyitni. Esetleg USB-RS232 átalakítóval kéne próbálkoznom?
Hello.
Én a Hterminal progit használom fejlesztés közben prort olvasásra és írásra. Egyből látod milyen használható port van a gépen. Van pár hasznos kis funkciója, és persze Ingyenes. HTerm
Közvetlen soros portot még nem használtam csak USB-vel FT232 + AVR de ott elég, ha csak az Rx Tx Valamint a tápokat összehozod.
Ennek így működnie kellett volna, ha van fizikai soros portod(és rá van dugva az alaplapra, ha nem az alaplapon lenne a csati!).
Ha nem tudod megnyitni, akkor ott valami foglalja, vagy valami probléma van a rendszerben. A Brayterminal-t is próbálhatod, vagy a belső terminál progit is.
Sziasztok!
Számítógép soros portján szeretnék küldeni 8 bites adatot paritás bittel, úgy hogy a paritás bitet kézzel én állítom be. A lényeg az, hogy cím detektálással szeretném fogadni az adatokat egy PIC-kel, csak sehogy sem akar működni. Tehát cím byte előtt 1-re állítom, adat byte előtt pedig 0-ra állítanám a paritás bitet. Tudtok valami szoftvert ajánlani amivel le tudnám monitorozni a PC portját, amivel megvizsgálhatnám, hogy milyen csomagot küld ki a gépem? Tehát látnám, hogy milyen paritás biteket küld ki ezáltal leellenőrizhetném a windows-os alkalmazásomat. Tegnap találtam egy fórumot ahol szintén ez a téma: http://forums.nrcommlib.com/index.php?topic=1360.0 Én valami olyasmit hámoztam ki belőle, hogy ezt nem lehet megvalósítani szoftverrel, vagyis nem lehet manuálisan átállítani a paritás biteket. Aki egy kicsit jobb angolból mint én az átolvashatná nekem azt a pár hozzászólást és megerősíthetne engem ebben a tényben. Én is VB-ben írom a programot és ugyanezekkel a parancsokkal próbálkozom mint a topic kérdezője, de nekem sem működik, pedig VB súgója szerint a paritás bit írható lenne. Előre is köszönöm!
Szia! Én is használom címjelzésre a 9. bitet, de PC-ről nekem se sikerült, igaz nem is nagyon erőltettem, mivel nem a PC, hanem egy PIC a master.
A gond az, hogy ha kiválasztod a VB-ben a paritás bitet, akkor automatikusan kiszámolja és beállítja az elküldéskor azt. Olyan dll-t kellene használnod, ami megkerüli az API-kat. http://www.geekhideout.com/iodll.shtml Remélem a 9. bitről is írnak, mert ilyen szemszögből nem keresgéltem még az infók között.
Tehát azt mondod, hogy pl. a system32 mappába kellene valamilyen dll-t berakni?
Amúgy te hogy oldottad meg a problémát PIC részről? Én jelenleg a következő kódot használom paritás nélkül, csak nem mindig működik rendesen, elég gyakran kell resetelni a PIC-et és újraindítani a szoftvert, hogy feléledjen a rendszer és rendesen olvassa be az adatokat a PC illetve a PIC. Valószínűleg ilyenkor rosszul indul a windows-os program és elsőnek pl. az adat byte-ot küldheti ki. Ezt a problémát szerettem volna javítani a cím detektálással, mert ugye az csak cím byte esetén hozna létre megszakítást.
Itt lényegében számolom a megszakítások számát és a 3-nál teszem csak be a változóba az adatot. Nem tudom máshogy, hogy lehetne elkülöníteni a byte-okat egymástól... A visszajelzésként visszaküldött byte-okat majd szeretném kivenni a kódból, csak tesztelés miatt raktam be. Amit még nem értek, hogy miért nem elég ha a PC-ről 5ms-onként küldöm a byte-okat egymás után 28800 baud-dal, pedig ekkora sebességnél 1 ms alatt majdnem 3 byte is át tud menni. A kábel késleltetne ilyen sokat? Te mennyi késleltetést használsz? Nekem most 15 ms-nál működik rendesen.
Nem valamilyen dll-t, hanem az io.dll-t és a köré való implementációt, amit linkeltem. Így a portokat direkt el tudod érni, azt írsz ki rá amit akarsz.
Megbízható kommunikációt csak hibakezeléssel lehet megoldani, ami figyeli az USART hibajeleket, az időtúllépéseket és a CRC-t is. Első körben a megszakításkor ezt ellenőrzöm:
Ezután a címet: Ha a cím stimmel, akkor elkezdem venni a további adatokat, miközben időtúllépést is figyelek, ha valami hiba miatt nem jön be a várt adatmennyiség.
A protokolt úgy kell felépíteni, hogy az első adatcsomag ismert hosszúságú legyen(pl. 10bájt), vagy figyelni kell az utolsó bájt utáni időt, és ha az meghalad 3,5 bájtnyi időt(MODBUS módszer), akkor ért be az adatcsomag. Ha beért, akkor CRC vizsgálat. Ha ez rendben akkor további feldolgozás. Egy másik szálon pl. a Timer1 low megszakításaiban figyelem a OERR és a FERR biteket, ha ilyen hiba van, lekezelem az adatlap szerint. Nem gond, ha low a megszakítás, mert az időtúllépés vizsgálata a high int-ben kilépteti a szálat az USART vételi hurokból, és ha a vétel a két hiba egyikétől adódott, akkor a low int is szóhoz jut. Nem annyira fontos hiba ez, hogy ne legyen rá pár mikroszek... A hozzászólás módosítva: Szept 10, 2012
Ok, majd átnéztem azt az oldalt és kiderítem, hogy jó lesz-e nekem az a dll.
Hmmm... CRC... Nem mondasz hülyeséget. De lényegében akkor te is késleltetve küldöd egymás utána a byte-okat, nem? Neked mennyi késleltetés elég? Az ötleteket meg köszönöm!
Nem. Nincs semmi késleltetés. Az utolsó bájtot lehet detektálni időméréssel, erről beszéltem, és akkor nem kell tudni előre az adatok számát. Olvass utána a MODBUS kommunikációnak. Neked RS232-n mennek az adatok, ha jól sejtem, de erről nem írtál semmit. Csak RS485 esetében kell időzítés a vonal irányának váltotatásakor, de itt erről nem volt szó.
Soros porton mennek az adatok egy max232-es IC felhasználásával, annyira nem tudom mi a különbség RS232 és RS485 stb. között, de hogy őszinte legyek nem is nagyon érintett még meg eddig a dolog, más területek jobban érdekelnek. Azzal tisztában vagyok én is, hogy vannak különböző busz típusok, tanultam is párat (pl. EIB, Profibus, CAN), de ezeket sem úgy, hogy gyakorlatban használni is tudjam. Nekem jelenleg csak arra kell a kommunikáció, hogy a PC-ről töltsek be a PIC-be pár változó értéket. Nem kell 26 eszközt vezérelnem ezért nem is nagyon törtem magam a buszok tanulmányozásával.
Én ezt a késleltetést úgy értem, hogy én például most 3 byte-ot akarok küldeni egy csomagban és minden byte után van egy 15ms-os holtidő. Késleltetés nélkül meg azért nem működik mert rögtön az első byte után jön a megszakítás és mielőtt beérkezne az utolsó is, addigra ő már fel is töltötte a változókat. A neten is ahogy olvasgattam másoknak is késleltetett küldést ajánlottak az ilyen esetekben. Máshogy én csak úgy tudom elképzelni a dolgot, hogy minden byte után ellenőrzésképp visszaküldöm, és ha egyezik akkor mehet a következő, de ez csak végső megoldás lenne. Vagy most hirtelen az az ötletem támadt, hogy egy 10 elemű karakter tömböt használnék buffer gyanánt és a main részben írogatnám a változókat. De ezen még agyalnom kell. Tehát a kérdés, hogy 1 megszakításban hogy lehet lekezelni egy 3-4 byte-os adatcsomagot, hogy szokták ezt csinálni? (most minden hibakezelés nélkül) Amúgy gondolkodtam ezen az io.dll-es dolgon is, és az lenne a kérdés még, hogy ezt a programom mappájában is lehetne tárolni vagy beleintegrálni a programba valahogy, mert olyan gépen is kellene működnie ahol nem biztos, hogy van rendszergazdai jogosultságom és akkor úgy már annyira nem is jó ötlet.
Az io.dll-hez rendszergazdai jog kell egyszer, mikor bemásolod és egyszer futtatod.
Én csak példának hoztam fel a MODBUS-t, mint egy lehetőség az ismeretlen hosszúságú adatok fogadására. Ismétlem, 3, vagy akár 133 bájt küldése közben sem szükséges időzítés(várakozás) a bájtok között. Szép is lenne, milyen sebesség jönne ki!? A csomagok vételének módja a PIC alkalmazástól függ. Ha van idő a teljes csomag vételére a többi teendőtől, akkor egy ciklusban lehet venni az adatokat a megszakításból nem kilépve. A vett adatokat minden esetben pufferbe kell tárolni, azonnali feldolgozás nem szokás megszakításban, kivéve a cím, mert azzal sok időt lehet spórolni. Ha nem RS485-öt használsz, akkor nincs értelme a címnek egyébként, sem a 9. bitnek, sem az io.dll-nek! Ha nincs idő kivárni a csomagot, akkor minden beérkező bájt megszakítást okozhat, ha engedélyezed, ekkor kell eltárolni a bájtokat egyenként, majd kilépni a megszakításból. Mindezt a csomag végéig ismételni. Két bájt beérkezése között sok program ciklusidő van, addig sok minden mást el lehet végezni. Ha előre ismered a csomag hosszát, vagy esetleg ismert a hossz jelző sorszáma(mondjuk a 3. bájt) akkor vétel közben is meg lehet állapítani azt, és egy indexel figyelni, hogy beérkezett-e mind. Ha igen, egy jelzővel lehet jelezni, hogy kész a vétel, fő hurokban lehet feldolgozni a pufferben lévő adatokat. Hibakezelés nékül, ha nem érkezik meg minden bájt, megakadhat a folyamat és az utána következő csomagot sem lehet venni az index elcsúszása miatt. Ezért kell legalább a timeoutra lekezelni a vételt. A hozzászólás módosítva: Szept 12, 2012
Akkor meg nem értem, hogy pl. a fenti program kódom miért nem működik már 1ms késleltetésnél sem. Pedig elvileg úgy kellene működni, hogy az 1. byte STOP bitje kiváltja a megszakítást (közben i++) és pár usec alatt beteszi az Address változóba és kilép a megszakításból, majd tovább számolgat és az előbbi történik a 2. byte-tal is kb. 1ms múlva és csak a 3 byte-tal megy el több idő, mert vissza is küldi a gépbe. De az a baj, hogy utána ha nem is következik több byte, akkor sem küldi vissza az infót! Tehát már 1db 3 byte-os csomaggal sem működik 10-15 ms késleltetés nélkül. Nem tudom, hogy akkor hol lehet a hiba. Még annyit megfogok tenni, hogy a változókba másolást átteszem a fő rutinba meg a Send-es függvényhívást is, de nem sok reményt fűzök hozzá így sem.
De azért is csináltam így, hogy több megszakítással végzem, mert ahogy írtad te is az én alkalmazásom nem engedi meg a túl nagy időkiesést, 1-2 ms már hibához vezethet. Azt, hogy érted, hogy nincs értelme a címnek? Milyen címre gondolsz? Én a cím byte alapján különböztetem meg egymástól az adatokat, hogy melyik változóba pakoljam őket. (Összesen 4 változónak kell értéket adnom)
Én évekkel ezelőtt úgy oldottam meg a több byte-os csomagküldést, hogy a byte-ok számát figyeltem. Amikor megérkezett mind (6 byte-os csomag volt), akkor dolgozta csak fel a csomagot, előtte szépen berakta egyenként a memóriába. Az első byte elindított egy időzítőt, amit minden byte ujraindított, csak a 6.-ik byte állított le. Ha az időzítő elérte a 0-át, akkor az azt jelentette hogy nem jött be a 6 byte, így amik addig jöttek azokat elvetette. Ez persze csak fix hosszúságú csomaggal működik, de nagyon stabilan megy a mai napig.
Akkor minek nevezzem?
Lényegében a regisztereket címzem meg vele. Tudtommal ilyen busz topológiáknál ha címről beszélnek, akkor elé szokták tenni, hogy milyen címről van szó (pl. tartomány, vonal, készülék stb.) De itt nem sok értelme lenne használnom ezeket, max. máskor úgy fogom mondani, hogy regiszter cím. (Csak aztán nehogy félreértsd, hogy a memóriabeli címre gondolok)Azért ennek a kis kódnak 400us alatt (kb. 1 byte beérkezése) le kellene futnia, de kitettem a belső switch-et a main-be és úgy sem javult a helyzet. Mintha jobb lenne, de ha gyorsan változik az adat, akkor már elveszti a fonalat. Még arra is gondoltam, hogy nem-e a timer1-es megszakításból nem tud kilépni időben (25ms-onként lép ebbe is számolgat magának), de próbaképp letiltottam és úgy sem működik rendesen. Na mindegy, majd még szórakozok vele, valamennyire működő képes és ez a lényeg, de most fontosabb dolog is lenne még a programmal, úgyhogy inkább azt csinálom, mindenesetre köszi a segítséget. |
Bejelentkezés
Hirdetés |
