Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Nekem van FT232-m. Az hogy az FT-nek mennyi az órajele teljesen tökmindegy. A PIC, és a PC-nek kell egyezni. Én világ életeemben 9600-8N1 beállítással használtam. Igaz még csak teszt jelleggel és ennek is egy éve. Akkor a PIC annyit csinált hogy ami adatot kapott azt küldte is vissza én meg néztem a Hyper Terminálon. Igaz ez pl egy 10kbyte os txt file is volt. nem volt vele látható gond.
Még egy dolgot tudsz megnézni a rendszereszközöknél a virtuálsi soros port tulajdonságai között van egy olyan hogy Flow Control. Én nem emlékszem hogy hogy használtam de lehet hogy Xon/Xoff üzemben. A szinkron hiba természetesen velejárója az RS232-nek, a microchipes adatlapok is mutatják hogy pl 20MHz kvarc mellett 9600 baudon mondjuk 0,5% a hiba. Ezt ki kell küszöbölni. Alkalmazz hibajavítást, pl a paritás bit is erre van. Én esetleg ajánlom hogy nézz utánna a nem csak hiba detektálós hanem hiba javítós kódoknak. Huffman kód pl. Szóval lehet rajta "javítani"... 
Értem és köszi!
És nem kell semmi plussz a programozásához? Tehát elvileg simán a USART-on menni kellene neki? Valami AT parancsra vagy bármi másra nincs szükség? A terminál progin próbáltam már, hogy Xon/Xoff-ra állítottam, de úgy sem volt jó.  Erre gondoltál, ugye?
Szvsz nincs semmi gond az aszinkron sebességekkel, nem kell azon hibajavítani. Minden egyes startbitnél újraszinkronizálódik az adatcsere, így elég durva eltérésnek (értsd: több százalék) kell ahhoz lennie a vételi és adási oldali bitsebességekben, hogy emiatt sérüljön az adat. Nekem még a PIC-ek belső oszcillátorával sem volt sohasem soros porti gondom. Egyébként pont azért jó a hardveres UART-okat használni, mert azok a biten belül többször is mintát vesznek az adatvonalból, így a zaj ellen is elég jól védettek.
Az FT-nél meg nem igazán a chip-pel kell foglalkozni, hanem a PC oldali szoftverben kell jól beállítani a sebességet. Nekem nem volt még ilyesmivel bajom, pl. ha Hyperterminal-ban megváltoztatom a baud rate-et, akkor azt szépen követi az FT által használt sebesség.
Amikor ilyen kínlódás van, akkor talán édemes lenne a PIC oldalára valami kiherélt tesztprogit írni.
Soros porti kommunikácihoz (8N1 formátumot használva) én olyat szoktam, hogy egy végtelen ciklusban (55h kódú) "U" karaktereket küldök ki. Ez elvileg egy folyamatos, 50%-os négyszögjelet kellene, hogy adjon a kimeneten. Egy frekimérővel rámérve rögtön visszaszámolható, hogy tényleg olyan sebességgel sorjáznak-e ki a bitek, amit elvárunk a programba kódolt beállítások alapján. 9600bps esetén 4800Hz-et kellene mérni a műszerrel, és körülbelül 50%-os kitöltési tényezőt.
Köszi a részletes magyarázatot. A TMR0 emelésével (200) egész jó kis szoftver PWM sikeredett, csak a proci annyira le van fogalalva, hogy mégegy ilyen felbontású PWM-el már nem birkózik meg, az meg szinte lehetetlen hogy a szoftveres PWM-et összehangoljam a hardveressel, mertugye az eredeti ötlet szerint a PIC-nek két motort kellene meghajtania ami egy jármű két kereke és azt hiszem valamelyik irányba erősen félrehúzna, mert olyan pontosan nem tudnám 'lemásolni' a hardveres PWM működését, szóval váltok inkább egy komolyabb tudású PIC-re.
 Egyébként nem tudtok egy olyan 20lábú PIC-et amiben már van két hardveres PWM csatorna?
A legfontosabbat most látom. USB-d rosszul van bekötve. USB dugó 4. lába GND.
FTDI232R Adatlap 27. oldal Egyébként a beszélgetésünkkor nem mondtam. Nem kell az RS485-öt leoperálnod a panelről. Az FT TX-RX lábait vezesd ki légvezetékkel és kösd rá kereszbe a PIC-re: De az USB dugó az nagyon gáz. Idézet: „Paraméterezett makrókat használva még hatékonyabb is lehetsz mint eccerűen csak azzal hogy egy két Port lábat nevén nevezel. Ezen ne fájdítsd a fejed...” Nem értek egyet, ezt már említettem. Azzal igen, hogy nem nagy gond a #DEFINE hiánya(bár ezt se állítom teljes nyugalommal), de azzal nem, hogy a macro hatékony! Memóriapazarló megoldás, én szinte soha nem használom, még is megoldottam eddig mindent.
Ha megfigyelted a PICC18 vagy 30 beállítás ablakát akkor a leggyorsabb kód mindig hosszabb mint a legrövidebb, ami meg lassabb az elsőnél.
Amikor olyan PIC-van hogy 256k, 512k memória akkor engem nem nagyon zavar hogy mennyi memóriát használok. Főleg hogy C-ben egyébként is hosszabbak a programok, tehát az legtöbb ember itt már eleve elbukta a program hossza című kérdést. Ettől függetlenül elismerem hogy rengeteg megoldás létezik, és minden megoldás jó ami működésre bírja az adott eszközt.
Hali!
Mellékelem a nyák rajzot. Az USB-t kábellel vezettem ki, így azzal most nincs baj. Szégyellem magam, de elnéztem egy vezetéket és az volt az egyik baj. Így most amit a PIC küld, szépen megjelenik a PC-n. Viszont amit a PC-ről próbálok küldeni abszolút nem jelenik meg a PIC-en, sőt még megszakítást sem generál.
Ugye megmondtam...
Muti a programot, megnézem. AD konverter: 3.072mV a referencia. 400mV amit a multiméter mér az ellenálláson. Konverzió eredménye: h1B9 *3 = h540 h540 /4 = h150 = d336mV mindezt azért mert a 3.072 az a 4.096 nak a 3/4-e. Tehát 400mV helyett mér 336 körül. Ez elég erős hiba. Most már referencia feszültségben is az adatlapon belül vagyok. Na Vajon most mi lehet? Meghalt az AD konverterem? Közbe rájöttem. Elmászott 250mV-al a kőbaltás referencia feszültség forrásom...
Pont így gondoltam. Egy rövidke szimulációt csináltam az MPLAB-ben. Nekem kikapcsolta az USART modult és sleepbe is ment.
Lehet, hogy látni kellene a programodat... Idézet: „Közbe rájöttem. Elmászott 250mV-al a kőbaltás referencia feszültség forrásom...” A Microchip fesz ref aramkoreit probalgattad mar? Egesz jok vannak bennuk nehany uA fogyasztasokkal ha jol emlekszem.
Hali!
Mellékelem a teszt kódot, amivel próbálkozok! Kérlek nézzetek bele egy pillanatra, hogy az adatok vétele a USART-on miért nem működhet? Nem is ugrik bele a megszakításba, pedig korábban egy másik kis projekten így csináltam. Ui.: Próbáltam megszakítás nélkül is, de úgy sem jött semmi... Köszi szépen! Idézet: „kőbaltás referencia feszültség forrásom...” Kőbaltás és referencia. E két fogalom igencsak külön világ nem? Nézd meg a chipcad-nél a A/D és D/A konverterek, feszültségreferenciákkal kapcsolatos áramköröket(microchip)! pl. a MCP1525T-I/TT egy 2,5V-os, atomstabil forrás. Ne ragaszkodj a kettő hatványaihoz, mert csak a 1541-es tud 4,096V-ot, az meg neked már sok(ugye 3,6V a max.). Ellenállással osztani nem szabad, mert elrontod a stabilitást. Akkor inkább számolj szoftverből!
Nekem akkor is 3.072V kell, mert szorzom az eredmény hárommal, majd jobbra léptetem kettővel (/4).
Egyébként a microchip fórumán is volt aki panaszkodott erre a 3V, és mé nem 3.072V-re... MInden esetben szívesen matekolok, de most nem mert ez az AD konverzió gyakorlatilag a biztosítékot helyettesíti. Tehtát olyan gyors akarok lenne amennyire csak lehet.
Az hogy kőbaltás az annyit jelent hogy a ua741 IC pozitív bemenete egy 3.6V-os Zener feszültséget fogad a negetív ága meg egy visszacsatolás potival kiegészítve. Olyan eccerű mint a lejtő és lehet hogy ez a baja... Na mondjuk a 741 nem éppen a precizitásáról ismert.
Na ugye kiderül, hogy mire is jó egy 30F2020! Mert milyen jó lenne egy 2Msps-es AD, ha ilyen jellegű felhasználás a cél!? A 24HJ nem feltétlenül erre való, ide egy SMPS-re fejlesztett felépítés kellene.
A másik pedig az, hogy ha biztosítéknak kell, akkor felesleges tologatni, szorozgatni az AD regiszterében kapott értéket, egyszerűen össze kell hasonlítani a megfelelővel!
t: szerk. optokapu 2 témába szereplö pic-et programozva
belehet-e szerezni valahol? mi a tipusa ? rajzával együt. nem tudok programozni, de szeretném ezt a kapcsolást megcsinálni! elöre is köszönöm:
Többször elolvastam a kérdésed, de egy szót sem értek mit akarsz? Értelmetlen, magyartalan mondatok, minden kisbetű és rövid...
Ha elvárod, hogy más időt fordítson arra, hogy a kérdésedre értelmes választ adjon, akkor annyit megtehetnél, hogy időt fordítasz arra, hogy érthetően fogalmazz! Ez itt egy szakmai fórum, csak értelmes embereket látunk szívesen. Az írás a lélek tükre!
Had panaszkodjak még az ASM30 miatt!
Milyen jó is ez a megoldás MPASM-ban!:
Most azt hiszitek, elfogadja ezt az ASM30 fordító?
Természetesen nem. Gratulálok a microchip-nek a visszafejlődéshez! Látszik, hogy minden erejükkel a C-t támogatják! Nem vall profi nézetre! Én nagyon haragszom rájuk!
En ezt a BAT file-t hasznalom, a kept tegnap vagy mikor mellekeltem mar, hogy hol allitottam be azt, hogy ezt hasznalja az MPLAB... Ez meghivja a GNU CPP-t, szoval lehet szepen hasznalni a #define, #if #else #ifndef #include stb-ket...
Na jó, azért ez is egy jó megoldás:
De ettől még nem engeszteltek ki!
Elnézést, nem értettem ,és most is csak sejtem mit hol kell beállítani. Rámozdulok a dologra!
Köszönöm!
Meg valami: MCC18\bin konyvtaraban van egy CPP18.EXE nevu valami, az a Microchip-ek C preprocesszora, azt is lehet hasznalni a GNU helyett. Azonkivul az MCC18\cpp konyvtarban van egy forras is a preprocesszorrol, szoval lehet meg azt is nezegetni az hogy mukodik
De nem erdemes ujra forditani szvsz.
Hehe, nem rossz 5let, es mit szolsz egy ilyenhez:
Ertekeket, hogy jol szamol-e nem csekkoltam le persze...
Nem rossz! Tökéletesen számol.
Viszont a preproc megoldásoddal kapcsolatosan lenne kérdésem. Honnan van neked a D:\MinGW\bin\cpp.exe állomány? Én nem találok ilyet, csak a Hi-Tech C könyvtáraiban, az meg valószínű nem lesz jó!
Még is csak van egy kis szépséghiba, hogy az editor nem tudja normálisan kerekíteni a számot. pl. a valós eredmény 381,65 amire az editor 381-et számol és helyettesít be, 382 helyett.
Erre nincs valami ötleted? A preprochoz még annyit, hogy nekem a dsPIC-es C30 van telepítve most még csak.
Nekem fel van teve a MinGW fejlesztoi kornyezet
Ez vegulis egy GCC windows-ra meg jonehany unix-os segedprogram amit unix fejlesztok szoktak hasznalni es ami nelkul elni nem birok De picit lejjebb irtam, hogy az MCC18 konyvtarban is van egy C preproci, arra is lecserelheted a MinGW-set. Ezzel csak az a baj, hogy nekem nem sikerult mukodesre birni egyenlore - meg kellene nezni az MCC30-at is, mert az ha minden igaz GCC alapu?
A sima MPASM-nak nincs külön preproc-a? Olyan fájlom vannak, hogy :
mp2cod.exe mp2hex.exe mplib.exe mplink.exe Ezekből talán a cod lehetne a előfordító? A többit sejtem mit csinálnak... |
Bejelentkezés
Hirdetés |
