|
|
| PIC - Miértek, hogyanok haladóknak.. |
|
| Témaindító: G-Lex, idő: Jan 9, 2006 |
|
|
|
|
|
| CTS/RTS -el egyszerubb lenne, akkor akar egyetlen vonalon (PIC labon) egyszeru port billegtetessel meg tudod oldani az adatfolyam vezerlest. |
|
|
| Hát az a helyzet hogy én is ezen gondolkoztam , hogy timer2 vel megcsinálom szoftveresen. Csak közben időmérési feladatokat kéne csinálnom és elég nehéz úgy ha megszakítok . Bár lehet úgy kéne hogy timer0-t meg be üzemelem annak, megszakítás nélkül és akkor azzal mérhetem az időt folyamatosan megszakítás közben is. Majd megpróbálkozok vele. |
|
|
Köszi ( Hp41C is)
Úgy tűnik marad az RTS/CTS változat. FT232-vel átalakított USB-s kapcsolat "simán" működhet? Gondolok az FT232-ben levő nagy FIFO-ra. |
|
|
Sziasztok!
Érdeklődnék, hogy ehhez a kapcsoláshoz esetleg nincs valakinek olyan hex-e, amivel akármilyen távirányítóval működik? Mert az oldalon találhatóval csak Sony távval lehet kapcsolni, ami idáig jó volt, de TV-t cseréltünk... 
Egyébként nagyon jó kis kapcsolás, már kb két éve hibátlanul üzemel.
Előre is köszi, ha valaki tud segíteni;
E. |
|
|
| Igen, FT232-vel nem szokott tul sok gond lenni. Amugy a Microchip-nek is van ilyesmije, az MCP2200. Harmadik megoldas ha egy USB kepes 18F-el valositod meg amit szerettel volna es a Microchip USB frameworkkel egy CDC eszkozt valositasz meg ha belefer -- akkor ugye amit szeretnel ugyanabban a chipben lenne mint ez az USB-s soros kommunikacio... |
|
|
Igen, közben én is keresgéltem és az MCP2200 lesz valószinüleg. (az ára harmada mint az FT232, ráadásul kevesbbet fogyaszt)
Köszönöm a segítségeteket. |
|
|
Ha komolyan gondolod az RTS/CTS használatát, akkor vagy felejtsd el az MCP2200-at (Bővebben: Link), vagy kísérletezz vele, és próbáld megérteni a Microchip sajátos logikáját!
Bár az RTS ősidők óta azt jelenti, hogy Request to Send, az MCP2200 adatlapja szerint az "I am ready to receive" értelemben használja. Bővebben: Link (lásd: 1.3.4 pont) |
|
|
Nyilvan Microchippek a "modern" RTS/CTS-t implementaltak:
Idézet:
„A non-standard symmetric alternative, commonly called "RTS/CTS handshaking," was developed by various equipment manufacturers. In this scheme, CTS is no longer a response to RTS; instead, CTS indicates permission from the DCE for the DTE to send data to the DCE, and RTS indicates permission from the DTE for the DCE to send data to the DTE. RTS and CTS are controlled by the DTE and DCE respectively, each independent of the other. This was eventually codified in version RS-232-E (actually TIA-232-E by that time) by defining a new signal, "RTR (Ready to Receive)," which is CCITT V.24 circuit 133. TIA-232-E and the corresponding international standards were updated to show that circuit 133, when implemented, shares the same pin as RTS (Request to Send), and that when 133 is in use, RTS is assumed by the DCE to be ON at all times.[10]”
Bővebben: Link
A gond inkabb az lehet, hogy ez az egesz a firmware-ben van implementalva es igy a PC oldalon nincs lehetoseg a kommunikacioba torteno beleszolasba. Ki kellene probalni, hogy a bufferek mit engednek meg ill mi van ha a PIC tartosan nem akar adatokat fogadni... |
|
|
Köszönöm a linket, hasznos információ!
Idézet:
„A gond inkabb az lehet, hogy ez az egesz a firmware-ben van implementalva es igy a PC oldalon nincs lehetoseg a kommunikacioba torteno beleszolasba.” Nem olyan nagy baj,  mert a Windows usbser.sys meghajtója úgysem kezeli rendesen az RTS jelet.
Biztosan nem véletlen, hogy minden valamire való USB-soros protokol konverter saját meghajtót használ (CP2102, PL2303, FT232RL). |
|
|
Sajnos az angol szöveget csak részben értem. Nekem csak az kellene, hogy a PIC egy mondatot (max. 60 karakter) beolvasása után állítsa le az adatfolyamot, majd ha végrehajtotta (néhány perc is lehet), olvassa tovább.
Ezt az MCP2200-val lehet produkálni, ha jól értettem.!? |
|
|
| Ezt lehet, csak az a kérdés, hogy a PC-n futó alkalmazásnak ki mondja meg, hogy várjon? |
|
|
| Remélem, hogy ezt már az USB protokoll elintézi, vagy mégsem? |
|
|
| Szerintem nem. De mondtam, hogy kísérletezni kell... |
|
|
Sziasztok!
A következő gondom akadt egy PIC24HJ64GP502 (Microstick) típusú kontrollerrel: A hardveres UART1 egységet használom a PIC és PC közötti kommunikációra (PICKit 2 UART Tool). Átlagosnak mondható beállításokkal (9600 baud, 8N1) konfigurálom a kontrollert, mely a belső 7,3728 MHz-es oszcillátoráról működik (PLL nincs, a CPU és perifériák is Fosc/2- vel működnek). A vételhez engedélyezem a megszakítást, az adáshoz viszont nem. A PIC egyszerűen visszaküldi a vett adatokat, tehát egyelőre semmi ördöngősséget nem csinál. A kommunikáció kezdetekor, amikor a PC felől elküldök egy karaktert, a megszakítás megtörténik, viszont az kétszer is egymás után, pedig karaktert csak egyet küldök. Az első megszakításnál kiolvasva az U1RXREG regisztert 0x00- val tér vissza, a második megszakításnál (csak egy karakter volt elküldve) már a helyes értéket olvasom ki a vételi regiszterből. Ha a megszakítás rutinban vizsgálom, hogy az U1STA regiszter URXDA bitje 1-be billent-e, akkor csak a második megszakításnál olvasom ki az U1RXREG tartalmát, amelyben a helyes karakter van. Mindez csak a legelső vett karakternél van így, a többinél már normálisan működik.
Ez így nekem jó is lenne, hiszen úgy tűnik sikeresen megoldható a probléma. De...
A fő gond, hogy én DMA- val szeretném használni az UART-ot, ott pedig sajnos nincs lehetőség figyelni az URXDA bitet. Természetesen a DMA esetén is ugyanígy történik, az első karakter, amelyet a DMARAM-ban elhelyezkedő puffer tartalmaz a 0x00. A többi rendesen megérkezik és a későbbiekben is a helyes adatok szerepelnek a pufferben. Végülis oly módon meg tudtam oldani a dolgot, hogy az UART egység konfigurálásánál kezdetben engedélyezem a belső LOOPBACK-et, ezután elküldök a kontrollerrel egy "dummy" karaktert, visszaállítom a modult normál módba (loopback kikapcsol), majd ezután engedélyezem a DMA csatornát is. Ezzel a dolog működik is, minden adatátvitel megfelelően végbemegy. A probléma itt az, hogy a LOOPBACK csak a PIC RX-t választja le a kontroller lábáról, a TX-t nem, így
elküldésre kerül a dummy karakter is. Természetesen a későbbiekben a PC-n futó kliens le tudná ezt kezelni, tehát nem értelmezné a dummy karaktert, csak picit piszkálja a csőröm, hogy ez így eléggé "fapados". Ha esetleg valakinek lenne ötlete egy szebb, jobb megoldásra, az kérem ne tartsa magában!
Előre is köszönöm a hozzászólásokat és elnézést a regényért.
(Fejlesztői környezet: MPLAB X 6.0; Fordító: MPLAB C30 3.25) |
|
|
Hogy csinálod az inicializálást? Célszerű egy letiltással kezdeni, az esetleges hibabit beállások törlése érdekében.
// First, disable the UART, clearing all errors, terminating // any in-progress transmissions/receptions, etc. // In particular, this clears UTXEN. U1MODE = (0u << 15); // UARTEN = 0 to disable.
Ha jól látom, a PIC-kwik projektben gyakorlatilag csak az UARTEN bitet állítjuk vissza 1-re (feltéve, ha BRGH=0 megfelel).
A megszakításban először a hibabiteket ellenőrizzük (PERR, FERR, OERR), s csak akkor használjuk fel a kiolvasott karaktert, ha minden rendben volt. Az Errata szerint a hibainterrupt nem megbízható, gondolom ezért kell a hibabiteket külön vizsgálni.
DMA-val nem foglalkoztam, nem is tudom, hogy ott a fentihez hasonló hibavizsgálat hogyan oldható meg. |
|
|
| Letiltással kezdek én is, de csak utána inicializálok. Én nem ellenőrzöm a hibabiteket, ezt majd ki fogom próbálni. Így igaz, én is olvastam, hogy a hibákhoz tartozó megszakítás nem mindig megbízható. DMA esetén nem találtam utalást arra, hogy a hardver közvetlenül vizsgálná a hibabiteket. Azt tudnám elképzelni, hogy DMA mellett engedélyezem a vételi interruptot is és abban ellenőrzöm a hibabiteket, csak így megint ott tartok, ahol a part szakad. Pont azt szeretném elkerülni, hogy karakterenként megszakítás legyen. Mindenesetre köszönöm a válaszod, később még próbálkozom a dologgal. |
|
|
Üdv.!
Ha van egy PIC-es készülékem, ami RS232-n kommunikál a PC-vel, lehet olyat csinálni, hogy számítógép nélkül az adatokat egy webes felületre tölti fel, így bárhonnan elérhetem? Mert egy állandó üzemű számítógép elég energiaigényes. |
|
|
Szia!
Egy Ethernet illesztős pic és sok programfejlesztés... Vannak kész eszközök: RS232 - Ethernet illesztők. pl: Moxa, Lantronix, stb. |
|
|
Sziasztok,
Hogy lehet megoldani PIC18F14K22 és PIC24HJ64GP202 -nél hogy ne tudják kiolvasni (kilopni) a PIC-ből a programot?
Mit kell beállítani?
Azért kérdezem, mert nem szeretném lezárni úgy a PIC-ket, hogy utána ne lehessen újra programozni. |
|
|
| En hasznaltam ezt a panelt ,ill az elodjet. A MikroE ad hozza mintaalkalmazast is. Nekem 16F887 procival ment lokalis halozaton. A konyvespolcon talalhato 40-pin demo panelt csinaltam erre a projectre. A mukodes a potik leolvasasa, a kapcsolok lekerdezese, valamint a LED-ek vezerlese volt LAN-on keresztul. Az eredeti MikroC mintapeldat alakitottam at egy kicsit, es mukodott szepen. A projekt egy egyetemi demo-nak keszult. |
|
|
| A konfigurációs biteknél a kódvédelmet kell bekapcsolni. A kódvédelem utána csak a PIC törlésével szüntethető meg, de újraprogramozható, tehát nem kell aggódnod. |
|
|
Közben rájöttem és egy dugdosós próbapanelon kipróbáltam egy másik 14K22 PIC.kel.
__CONFIG _CONFIG5L, _CP0_ON_5L & _CP1_ON_5L
__CONFIG _CONFIG5H, _CPB_ON_5H & _CPD_ON_5H
__CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L
__CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
__CONFIG _CONFIG7L, _EBTR0_ON_7L & _EBTR1_ON_7L
__CONFIG _CONFIG7H, _EBTRB_ON_7H
köszi |
|
|
| Na a végén csak sikerült megoldani a problémát, most már rendesen működik DMA-val, meg anélkül is. Úgy tűnik nem minden esetben megfelelőek a gyári függvények (OpenUART1(), CloseUART1()). Mellékletbe felteszem a kódot, hátha egyszer más is hasznát veszi. A működés röviden: A DMA 0 csatorna ping-pong módban, folyamatosan működik, ez a két vételi pufferbe helyezgeti a vett karaktereket (5 karakter után megszakítás). A DMA 1 csatorna One-Shot módban működik, ez mindig az aktuális vételi puffer másolatát visszaküldi. A timer csak egy LED villogtatását végzi. |
» A fájlok letöltéséhez be kell jelentkezned! «
|
|
|
| Örülök, hogy működik! Az viszont nagyon nem tetszik, hogy a DMACS1bits.PPST0 bitet a főprogramban vizsgálod. Ennek a helye (a DMA buffer kiürítésével együtt) a DMA0 megszakítást kiszolgáló eljárásban volna. |
|
|
| Igen, a PPST0 bittel kapcsolatban teljesen igazad van, jelen alkalmazásban megfelelően működik, ha viszont a főprogram hosszabb ideig nem ér rá lekezelni, akkor már a másik puffer lesz kiválasztva. Nem terveztem, hogy sokáig így hagyom, csak elfelejtettem módosítani. A buffer másolással mondjuk már annyira nem értek egyet, de elképzelhető, hogy igazad van. Azért a főprogramban másolom át, mert nem akarok túl hosszú időtartamig a megszakításban maradni, az 5 karakter csak a próba kedvéért annyi, egyébként ennél több lesz. Véleményem szerint akkor lenne jelentős probléma, ha nem lenne idő lekezelni a főprogramban addig, amíg a másik puffer megtelik. De ha esetleg tévednék, akkor légy szíves mond el, hogy miért helytelen ez a megoldás! |
|
|
Idézet:
„Azért a főprogramban másolom át, mert nem akarok túl hosszú időtartamig a megszakításban maradni” Erre találták ki a több prioritási szintű megszakítást.
Idézet:
„akkor lenne jelentős probléma, ha nem lenne idő lekezelni a főprogramban addig, amíg a másik puffer megtelik.” De azt mikor és hogyan tudod ellenőrizni, hogy ez nem következik/következett be? |
|
|
| Persze, a többszintű megszakítás megoldást jelentene, ekkor jól gondolom, hogy a nested interruptot is engedélyezni kellene? Azt természetesen nem tudom ellenőrizni, hogy a puffer is felülíródott-e, de abban az esetben, ha csak egy puffer van és annak tartalma még nem lett feldolgozva, akkor teljesen mindegy, hogy mikor másolom be a DMA-tól származó adatokat, ha nem tudom feldolgozni, akkor mindegy, hogy a megszakításban másolom bele a karaktereket, vagy a főprogramban. Ezt csak azért említem, mert nem pusztán az lesz a feladat, hogy a beérkezett karaktereket visszaküldözgessem. Na mindegy, ezt majd később még megálmodom, mindenesetre köszönöm az észrevételeidet! |
|
|
Idézet:
„Persze, a többszintű megszakítás megoldást jelentene, ekkor jól gondolom, hogy a nested interruptot is engedélyezni kellene? ” Igen. |
|
|
| A kérdésed rendben van, de láttad a téma címét ? Itt leszel . |
|
|
Hírek.rss
