Fórum témák
» Több friss téma |
A második változat nagy valószínűséggel nem lesz jó. Hova szántad a fogadási makrókat?
Most, hogy tisztán látszik, mit kellene kapnod, megkérdezném, hány bájtot küld a modul egy-egy távirányító gombnyomásra? Ha csak hárma, akkor elég a b2, b1 és b0.
Hát arra gondoltam hogy a ciklusba teszek egy RXINT megszakítást ami behívja az rx makrót, és oda gondoltam ezt berakni!
Hány bájtot?? Hát szerintem hármat, akár melyik gombot nyomom le mindig ugyan az az eredmény 00 10 és az utolsó karakter változik De akkor a program többi részét valahogy el kéne szeparáljam hogy ne legyen időveszteség a futásba, tehát amikor rxint behívja a makrót és lefogadja az első karaktert akkor ne kezdjen el még a program jobbra balra koborogni hanem tudjon visszafordulni fogadásra a második és harmadik bájtért! Ugye?
Kezeld úgy a dologt, mintha a bájltok egy Nextion kijelzőtől jönnének. A különbség cska annyi, hogy itt mindig fixen három bájtot kapsz. Ha addig más nem, szombaton töltök fel egy példát.
Hát az a a baj hogy alapvető gondjaim vannak a soros komunikációval... mert értem, de mégsem!
Én ugy képzelem hogy ha a TX ad ( mondjuk küld 3 bájtot) akkor azt rx oldalon úgy a legegyszerűbb fogadni, hogy egymás után háromszor fogadok 3 karaktert mondjuk 10ms várakozással! Hiszen ha hármat küld akkor azt egymás után küldi... vagy minden egyes bájt előtt bezárja a kommunikációt a tx és a második bájt előtt újra felépíti majd elküldi a második bájtot, aztán megint zár és megint nyit és küldi a harmadikat majd végül zár? Mert ha mindig megszakítja akkor értem hogy miért elég csak egy fogadás az RXINT-be... de ha egymás után, úgymond folyamatosan akkor nem értem hogy miért nem lehet egymás után lefogadni!
NA kicsit olvastam azóta megint!
ÉS találtam egy olyat ha Bájtot küld akkor elvileg mindig ott van az elején a start de legalább minimum a stop bit! Tehát igen elvileg lezárja és újra nyitja a a komunikációt! De akkor ezek szerint ha meg nem Cart hanem STRINGET küldök akkor nincs minden bájt végén stop bit?? ezért nem zárja le? De lényeg a lényegbe hogy akkor nekem itt egyesével bájtonként jön az adat tehát a második biztos nem jó... Próbálok egy példaprogit összerakni rá, de szerintem teszek bele egy időzítést hogy a kiírassál ne menjen az idő és csak minden másodpercben egyszer irjon ki az LCD-re. Igy vissza tud fordulni olvasásra, hogy ne legyen adatvesztés!
Az UART (és a többi) modul, mint a neve is mutatja, egy különálló modulként üzemel a chip-ben. A modulokat a belső adatbuszon maga a kontroller fogja össze, ez az adatlapon a belső felépítésből látszik. Így gondolj rá, talán érthetőbb lesz.
Ha bekapcsolod az RX megszakítást, akkor az ahhoz rendelt makró konkrétan akkor aktivizálódik, amikor egy bájt fogadása befelyeződött. Lassú kommunikáció és nagy sebességű kontroller esetén a fogadás közben is van bőven idő tevékenykedni, de ez kb. mindegy is, mert neked csak onnan érdekes a dolog, ha a bájt beérkezett. Természetesen nem kötelező megszakítást használni de ha csak simán fogadást állítasz be a Flowcode-ban, akkor amíg várakozik a kontroller a beérkezett adatra, addig vár, nem csinál semmit. Ha a megadott ideig (delay paraméter) nem érkezik adat, akkor hibára fut a bájt fogadás, 255-öt kapsz vissza. Ha három ilyen van egymás után és az első érvényességi ideje alatt nem érkezik adat, akkor előáálhat az az eset, amikor a második fogadási makró fogadja az első bájtot, a harmadik fogadási a második bájtot és a harmadik bájt megy a levesbe. Megszakítás használata esetén azonnal értesülsz róla, hogy adat érkezett. Ezt ideiglenesen elmented és majd foglalkozol vele akkor, amikor akarsz.
Felrakom képbe is meg programba is!
Az elején csak az lcd indítása van illetve egy tmr2 megszakítás amivel számoltatok! De valami biztos nem jó.. mert több gombra is ugyan azt az értéket kapom, ami elvileg lehetetlen
Azthiszem megvárom a segítséget, mert szerintem nagyon bent vagyok az erdőbe! Akár hogy csavarom, nem akar racionálisan működni, pedig már minden hülyeséget is össze irogattam benne!
Egyszerüen nem értem, hogy az egyes gomb lenyomására a terminál program kiirja hogy 00 10 03 adatot kap! Én fogadtatom a PIC be RS232 b0=ReceiverChar (0) b0 változó tipusa Byte megcsinálom minden egyes fogadás elött az értékek "eltolását" . Tehát az első byte lesz b2 be a második b1 be a harmadik b0 ba és megis 240 255 243 értéket kapok az lcd re, ha ki iratom a print Number b0 stb stb parancsal ( na jo lehet hogy a 240 és a 243 fel van cserélve) Utánna kettes gombra kidob valami mást a hármasra meg ugyan azt mint az egyesre! Ahol meg a harmadik byte nem szám hanem betű, na ott meg végképp elveszti a fonalat a PIC .... de én is! Már gondoltam mundenre kondik a betápon, kerámia a táplábaknál.... de semmi! Ugyhogy biztos hogy a programba irok valami egetverő hülyeséget ....  A hozzászólás módosítva: Ápr 5, 2018
A programban van néhány hiba.
1. Megszakítást elegendő egyszer engedélyezni a program elején ahogyan a TMR2-vel tetted. Az RX megszakítás hurokba tétele teljesen felesleges. 2. Az LCD frissítését jelen alkalmazásnál és általában is, célszerűbb akkor elvégezni ha azon valamilyen változás történik. Tehát nem kell állandóan újra íratni. 3. Gondold végig a "timer" változód állapotát az idő függvényében. Az idő nagy részében kevesebb mint 250, pontosabban 249x4ms ideig a hurokban nem hívódik meg az "lcd" makró, viszont 4ms-ig, amíg a "timer" értéke 250-251 között van állandóan meghívod a hurokban az LCD újra írását. Ez így egyébként sem jó, ha ezt az utat választod, akkor meg kell oldani hogy csupán egyszer hívódjon meg a makró egy időzítési periódus alatt. Bakman javaslatával ellentétben én úgy szoktam csinálni az RX megszakításban az adatok vételét, ha tudom hogy a bájtok folyamatosan jönnek és ismerem a számukat, akkor egymás után rakom az adott mennyiségű RS232 receive makrót. Megvallom a másik módszer még eszembe se jutott, egyszer azt is kipróbálom. Mellékeltem az én megoldásomat a feladatra.
Az időzítő javítását köszönöm..
Ezt a 3 Char fogadást én is próbáltam, és hozzá teszem nem működött, nagyon bíztam a Te verziódba... de sajnos az sem működik! Vagy már nem tudom.... mintha random működne.. de az a baj hogy ha meg terminal programmal nézem akkor meg szépen adja az adatot! Már kezdem azt hinni hogy a PIC nél nem stimmel valami!
Még Bakman próba progiját megvárom, délután ugysem vagyok itthon aztán ha nem sikerül azzal se akkor nem tudom!
Lehet hogy kéne valami ellenörző progit irjak amivel PC-ről küldök ki adatot és azt iratom ki, hogy megnézzem jó e a PIC.. mert ez már nonszensz.... NEm felejtek el valamit? valami szűrés vagy felhózó ellenállás vagy akármi?
Parancsolj, melléklet.
Most vettem csak észre hogy belső RC oszcillátort használsz. Aszinkron adatátvitelnél mindíg kvarcot használj mert számít a pontos időzítés.
Hát ma már lekapartam magamat! 68 féle progit memtettem el... de nem sikerül! De még a tiéd se megy Bakman....
Ugyhogy nemtudom! Lehet hogy a PIC UART portja halt csak meg? mert amugy más kimenete meg működik más programmal! Na mindegy reggel "elindulok a kályhától" PIC16f627 4 megás külső quarzal! Aztán meglátjuk. Előszőr PC ről sima string mondat fogadás majd kiirás, ha megy neki (meg nekem is  ) akkor Char fogadás, ha az is megy akkor ez a 3 nyomorult Char fogadása a modultol!
Hi Mesterek!
Olyan kérdésem lenne, hogy a stepper motornál unipolláris motor esetén milyen kapcsolást kell építeni? H hidat? Válaszokat előre is köszönöm
Öt vagy hat vezetékes unipoláris esetén elég négy tranzisztor/FET. Bővebben: Link.
Egy kis szájbarágós segítséget szeretnék kérni!
A mellékelt képen szereplő, soros porton kiküldött "string" ről lenne szó! A string hosszósága állandó! Jól számolom hogy 43 Byte hosszú a string? Tehát ha le akarom fogadni PIC-el akkor flowba az RXINT makrónak úgy kellene kinéznie ahogy a mellékelt képen van, hogy: Receiver RS232String nTimeout 100 ( ha lasabban jónne az adat) NumBytes 43 ( mivel elvileg 43 byte hosszú a string viszatérési érték data(43) (a 20 felülirva a neve melett a szerkesztőbe mivel 43 hosszú) Az elmúlt 2-3 nap katasztrofális UART komunikációja miatt mentem vissza teljesen az alapokhoz... mert nem akar sehogy működni az UART
Ok, köszi . Elnéztem, nem uni hanem bipoláris a motor. Azaz 4 vezetékes. Ez h hidas, igaz?
Csak hogy a soros kommunikácót értsd, minden portnyitáshoz tartozik minimálisan sebesség ( meghatározza az egy és nulla impulzus hosszát) hány bit ( egy adat hány bitet tartalmaz) és a stop bit hossza (1-1.5-2) adat.
Az átvitel egy start bittel indul majd jön attól függően hány bitet állítottál be, számú bit, a végén meg egy stop bit. utána ismét start adat,stop, addíg míg el nem fogy a küldenivaló. Minden küldésnél az adat egy "csőbe" kerül, ahonnét az elsőnek beírt távozik először, a kimeneten sorossá alakítva. A vevőnél ugyan ez a helyzet, a sorosan vett adat összegyűjtésre kerül ( a beállított bitszám függvényében) majd egy átmeneti tárolóba. Az így kapott adatot a programod két módon dolgozhatja fel. Egyesével kiolvassa az adatokat ( (talán a régi GET parancs) vagy kiolvashatja egyben az öszeset, ha egy lezáró karaktert érzékel az adatfolyamban (READLN jellemzően enter 0d vagy soremelés 0a , esetleg mindkettő karakter) A soros portnál buktató lehet még a jelszint Ez szabvány szerint +-12V (PC) de hogy bonyolultabb legyen az élet a mikrokontrollerek a 0-5 vagy 0-3.3V szinteket használnak. ( és hogy teljes legyen az öröm fordított logikával ( a +5v jelenti a -12V szintet) így a síma szintillesztés kevés. A hozzászólás módosítva: Ápr 10, 2018
Amugy gondolom ha egy ilyenen keresztül illesztem a PC hez a PIC et akkor az megold minden gondot...
Én is ilyet használok, szerintem működik rendesen. Az a baj, távolról nagyon nehéz bármire is tippelni, hol lehet a gond. Első lépésként stabil tápfeszóltség és stabil érintkezések kellenek.
Fogj egy kontrollert és írj rá egy egyszerű programot. Ha kap egy bájtot, adjon hozzá egyet és küldje vissza. A képen szereplő USB-UART konvertert hozzádtrótozod és teszteled. Küldesz neki pl. 10-et, 11-et kell visszakapj stb. Ne azonnal 43 bájtnyi mondatokkal teszteld.
Ez jó ötlet.. valami ilyennel próbálkozom akkor!
NEm is próbálkozom.. ezt kb 2 perc megírni! Na mindjárt jövök!
Szia!
7.3728 MHz-es külső kvarcot használsz? Mert ha nem akkor ne csodálkozz a hibás adatokon, főleg ha ilyen hosszú adatot akarsz egyszerre elküldeni. javasolnám a cikk tanulmányozását különösen a 61--es táblázatot.. Ezenkívül szerintem lekezelni is egyszerűbb egy rövid adatot, mint egy regényt szétboncolni.
Olvasok tanulmányozok... aztán jövök!
Szia!
Hát a leírás alapján több hibát is találtam saját verziomba! Az első hogy nem használok külső kvarcot! Biztam a 32 megás belsőbe! Mondjuk fél éve összekalapáltam egy progit itt, amikor barátkoztam az UART al. Akkor is kvarc nélkül ment! és fogadott mindent szépen... Mondjuk az meg nem garancia hogy most is megy! ( mert nem megy) Az USB <>UART converterem szerintem jó... A program viszont biztos hogy nem! Pl Byte típusú változóval nem tudok semmien műveletet jól vegezni! A másik esetben amikor string érkezik, akkor is inkább elöbb számmá kéne alakítanom, aztán utánna már talán tudnék valamit kezdeni! Ugyhogy rá kellene előbb keresnem és (megtanulnom) hogy flow on belül hogy tudom a különböző válltozók tipusát átalakitani, convertálni! Ami a sugóba van string címszó alatt az csak egy része, ott pl pont számmá convertalás nincsen... Ugyhogy még bőven van mit tanulnom olvasnom... Mondjuk azt még mindig nem tudom hogyha elküldök neki 1 egyest, azt lefogadom byte-ba és hozzáadok egyet akkor miért nem kapok vissza semmit! vagy csak össze visszaságot! Holnap előkotrok egy kvarcot aztán bel2erakom! Hátha javulni fognak a dolgok! Ha esetleg string/byte műveletekről van valakinek gyüjteménye vagy linkje azt szívesen venném!
Én soha nem használok kvarcot, az UART kommunikáció mindig jó 9600-as sebességnél. Nagyobb sebességnél valószínűleg már nem lenne jó a belső órajel.
Milyen konkrét problémád van a byte műveletekkel? A kontroller szemszögéből nézve édes mindegy, hogy látszólag mi érkezik, mindig bájtként látja az adatot. Ha kap egy "A" betűt, azt a kontroller 65-ként fogja értelmezni (tizes számrendszerben számolva). kokozo hozzászólásából azt lehet leszűrni, hogy a kontroller beállítása, konfigurációja hibás, ezért nem működik rendesen a program.
Sajnos péntekig csak elméleti síkon tudok vele foglalkozni.... de kattogok rajta mert nem jövök rá mi a hiba!
Ha tudom feltöltöm a programot de addig is leirom mert nem egy bonyolult! C koddal be van állítva az orajel! utánna engedélyezve az RxINT utánna egy ciklus amibe van egy "névleges port ki-be" RX INT makróba Van egy ReceiverRS232Char nTimeout 10 visszatérési érték adat adat típusa Byte utánna van egy számítás hogy: adat = adat + 1 Utánna van egy SendRS232Char Byte A PIC re a mellékelt USB<> UART illesztővel megy a PC, Termite programmal küldöm ki az adatot PC-ről Dugdosós panelba berakva a PIC. Adatküldéskor a converter felvillan hogy adatot kapott, de a PIC nem küld vissza semmit... hosszas pötyögés után ( kb a 10 átirás után) egyszer bejött az hogy bármit küldtem a PIC [00] választ adott. Ez már kb faék egyszerűségű program... ugyhogy vagy tényleg a chipconfig nem stimmel ( bár mindig ezt a "mintaprogit használom) vagy már nem is tudom mi lehet a gond! Az USB<>UART converter jó mert az IR modultol szépen tolja be a PC be az adatot!! Remélem pénteken feltudom tenni hogy ránézzetek a projektopciókra!
Nem csak C kódban kell beállítani az órajelet, a Flowcode-ban (Build menü -> project options) is meg kell adni azt helyesen.
Legegyszerűbben a LED villogtatós módszerrel tudod kideríteni, hogy jó-e az órajelbeállítás. ciklus ---- kimenet bekapcsol delay 500 ms kimenet kikapcsol delay 500 ms ciklus vége ---- Ha másodpercenként többet vagy kevesebbet villog, mint kellene, akkor nem jó. |
Bejelentkezés
Hirdetés |
