Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Lehet nem varsz eleget az AD feltoltodesehez, az szokott ilyen hibakat eredmenyezni...
Túl sok ideje van a mérésre, a katalógus ajánlása 8 vagy 16-os osztás 4 MHz-en. Meg ráadásul lehet, hogy nem várod meg a mérés végét sem, az adatlap 64. oldalán találsz mintapéldát arra hogy kell az AD konverziót indítani és kiolvasni.
Idézet: „A Pic 4Mhz belső oszcillátorról megy, az A/D pedig 1:64-es osztással, tehát a lehető legtöbb ideje van a mérésre...” 1. Ezen a frekvencián az FOSC/8 osztást kellene használni (Tad = 2.0 us konverziós időegység). 2. Fontos, hogy a Tacq adatgyűjtési idő elegendően hosszú legyen, hogy az ADC mintavevő/tartó áramkörének kondenzátora fel tudjon töltődni. Ehhez az ADCON0 regiszter írása (konfigurálás vagy csatornaválasztás) és a GO/#DONE bit beállítása közé minimum 5 us késleltetést kell tenni, de inkább többet... Itt igaz a minél hosszabb, annál jobb kitétel, nem pedig a konverziós időnél. Konverziónál a szükséges minimum közelében célszerű maradni.
Köszönöm mindenkinek. Valóban a minimális idő számítását átugrottam az adatlapban, mert túl bonyolultnak tűnt, és nem tudtam, hogy várni kell az indítás előtt.
Kipróbálom
A fejlettebb (vagy legalábbis bonyolultabb) PIC mikrovezérlőknél van lehetőség automatikus késleltetés beállítására. Itt azonban nincs ilyen, tehát a programnak kell gondoskodnia a várakozásról. Ezt az adatlap mintapéldája is jelzi a
sorral.
Szerintem az ellenállás osztód is nagyon nagy értékű ellenállásból van, azt is érdemes legalább a 20-adára levenni.
Szia!
Idézet: „Egy fettel (BS170) megoldható hogy csak a mérés idejére kapcsolódjon rá az osztó az akkumulátorra.” Én mégis kettőt ajánlanék: egy P-fet kapcsolná a tápot az osztóra, ennek a gate-ját (ami a tápra van húzva) egy N-fet földre. A két fet egy SO8 tokban is kapható... Okok: - Ha az N-fet a földet kapcsolja, az osztón a feszültség a pic tápfeszültsége fölé emelkedhet, a pic belső védő diódái kinyithatnak. - Ha az N-fet a tápot kapcsolná az osztóra, akkor a gate feszültségének min. 4V-tal magasabbnak kellene lennie a Source feszültségénél. Egy 20-22V-os segéd feszültséget kellene előállítani valahogy...
Igen, csak 4 bites, el is felejtettem. A vezetékeket megnéztem többször, jó helyre mennek, a vezetékekkel sincs baj, de még mindig ugyanazokat az ábrákat rajzolja ki, legtöbbször azt írja ki hogy: '11'╟ néha meg azt hogy ooo meg még egy fura karakter. Itt vannak a programok, de szerintem ezekben nincs hiba.
Szia!
A 16F690 esetén a PORTC sajnos analóg funkciókkal is rendelkezik, az ANSEL és ANSELH regisztereket törölni kell a digitális ki-/bemenet használatához.
PIC18F-hez soros porton kommunikáló bootloader sokféle van, ezek közül melyiket használja/ajánlja valaki?
Hirtelenjében ezeket találtam: AN851 AN1310 Colt bootloader ds30 bootloader Tiny bootloader Felületes vizsgálat alapján eddig az AN1310 és a Tiny tűnik szimpatikusnak. A ds30 letöltőjéhez pilótavizsga kell, nem tudnám jó szívvel ajánlani. Követelmények: egyszerű legyen a kezelése, ne a felhasználótól kérdezze, hogy milyen mikrovezérlőt kell programoznia, s legyen terminál funkciója is (a programletöltés után tudjon kommunikálni az alkalmazással).
És CCS-nél hogy tudnám törölni a regisztereket? Sajnos/szerencsére ez nem assembly. Eddig még nem találtam semmit erről, de tovább keresem.
Én írtam magamnak anno egy olyan bootloadert, ami soros porton keresztül tud kódot fogadni, méghozzá közvetlenül a hex-et. Emiatt nem kell hozzá semmilyen hókuszpókusz a PC oldalra, egy jó soros terminálprogram megteszi. Az alkalmazás meg ugyanúgy használhat soros portot a kommunikációra, mint a bootloader, így a terminálprogram ott is használható.
Itt található a bootloader, de már nagyon régen nem foglalkoztam vele.
Ez nagyon izgalmasan hangzik! Készítenél egy skiccet ha szépen megkérlek?
Azóta se találtam semmit, hogy hogy lehetne kikapcsolni az analóg módot CCS C-ben, flex_lcd.c vel se működik, ugyanazt írja ki. Ha más karaktereket küldök ki akkor változik az amit kiír az lcdre de soha nem az amit küldök. abc-t írtam 'bb lett belőle, cab-ot írtam b'b lett belőle. az utolsó karakter mindig egy ╟
Gondolom, a setup_adc_ports() függvénnyel. Vagy az ANSEL és ANSELH regiszter direkt írásával.
Egy olyan példát találtam, ahol AN0 engedélyezve marad, de a C port felszabadításához talán ez is jó lesz:
Mellesleg a CCS C helpjét érdemes forgatni, mert viszonylag könnyen megtalálható benne minden hasznos információ.
Beraktam a device adc sort és a 2 setup adc sort mindkét félét, de nem segített mindig ugyanazt írja, multival megmértem az alkatrészek lábán, hogy nem-e szakadtak a kábelek, de mindegyik jó. Kiszedtem a tris c sort is, akkor is rossz.
 Kösz, hogy próbáltok segíteni holnap teljesen újraépítem, meg újraírom talán megjavul.
Tegyél LED-eket (ellenállásokkal) azokra a PORTC lábakra, amik az LCD-re vannak kötve, és próbáld meg egyenként megvillogtatni őket a programodból. Ha mindegyiket sikerül villogtatni, és mindegyik azon a portlábon villog, ahova az szeretted volna kötni, akkor nem a port beállításával lesz a gond, hanem valahol máshol: vagy a hardveres összekötésnél (az LCD modul tápfeszére is tegyél 100nF körüli kerámiát, akár magára a modulra, ahol a vezetékek belemennek), vagy a programban.
Egyébként ilyenkor szoktuk elkezdeni szidni a C-t, mert nem biztos, hogy az történik ASM szinten, mint amire a C kód alapján számítana az ember. Mellesleg halvány emlékeim szerint a CCS-ben vannak olyan direktívák, amik a portok kezelésének a lefordított ASM kódba kerülő módját befolyásolják (fast_io, direct_io és ilyesmik rémlenek). Ezeket is át kellene nézni, mert van olyan mód (és ez az alapértelmezett?), amikor minden egyes portpiszkálás esetén adatirányt állít az adott porton és ki tudja, még milyen, esetleg zavaró dolgok kerülnek be a kódba. Az ilyenek során esetleg előálló tüskék a kimeneteken okozhatnak olyan jelenségeket is, amit épp az áramkörödben tapasztalsz. A help-ben el kellene olvasni ezeket, meg azt is, hogy a használni kívánt LCD rutinoknak nincs-e valami ilyen jellegű előfeltétele (esetleg még olyan is lehet, hogy az adatbitek és a vezérlőbitek ne egy porton legyenek, pont az említett viselkedések miatt). Ha nagyon nem megy a dolog, de LED-ekkel kipróbálva látszólag minden bit a helyén van, akkor nem marad más, mint a C-ből lefordított ASM kódban kell körülnézni, hogy mi hiúsíthatja meg a helyes kommunikációt az LCD-vel. Szerk.: a LEDvillogtatást is érdemes úgy csinálni, hogy a portláb állapotát visszaolvasva és megnegálva kiírni, nem pedig fix 1-be és 0-ba állító utasításokat betenni. Így ugyanis kibukik, ha valami miatt (pl. túl nagy külső terhelés, vagy analóg funkció aktív a kérdéses lábon) nem tudja visszaolvasni a láb állapotát a progi.
Szia!
Nem olyan bonyolult...
Átraktam az lcd lábait másik portokra így:
B4-B7 - B7,C7,C6,C3 RS B5 RW föld E B6 Ezek közt is van analóg bemenet de így működik. Így most már azt írja ki amit kellene, de minden írás után tesz egy ╟ karaktert a következő pozícióba. Ha van olyan parancs ami lekéri a string hosszát akkor fel lehet tölteni a többi részt szóközzel, viszont így elpazarolnék egy csomó helyet a memóriában, meg prociidőt.
Egyértelmű, hogy a konfigurációval van probléma, és még a programmal is. Ez az átka, mikor valaki ollózik és nem tudja hogy működik az a rész, amit használ...
De a lényeg, hogy lassan de haladsz. Érdemes lenne jobban elmerülni a kódban...
Szia!
Kérlek, olvasd át az LCD kezelését... Látnod kellene, hogy a parancsok, karakterek írása után a program a BUSY flag-et ki szeretné olvasni az LCD-ből, azonban a R/W láb földön van, ezért az olvasás nem sikerül (írás lesz belőle)... Kellene keresni olyan LCD rutint, ami nem a BUSY flag figyelésével működik, hanem várakozással...
Pedig, csak annyit változtattam, hogy átkábeleztem meg flex_lcd.c ben átírtam az új lábkiosztást. Úgy is működik, ha kikommentezem az adc kikapcsolós részt. Tényleg át kellene néznem, hogy mit is csinál ez a flex lcd, a főprogit értem.
Hp41C: Bocs, azt elfelejtettem mondani, hogy a flex_lcd.c-t használom, nem az alap lcd.c-t és ebben nem kell használni az RW lábat, elég kikommentezni egy sort, én is így tettem. Ha ezt írtam be: lcd_putc("alma"); akkor megjelent az a fura karakter, ha meg ezt: printf(lcd_putc,"alma"); akkor nem, érdekes. Idézet: Ez mennyiben tekinthető rendeltetésszerű használatnak? Az lcd_putc() szerintem nem nullával terminált sztringek kiírására készült. „Ha ezt írtam be: lcd_putc("alma"); akkor megjelent az a fura karakter” Idézet: Ezt írja a komment az lcd.c-ben, szerintem ez rendeltetésszerű használatnak tekinthető. „lcd_putc(c) Will display c on the next position of the LCD.”
Szia!
Valószínűleg nem. Ugyanis karakterlánc esetén a kezdőcímet adják át, egy karakteres változó esetén az értékét. Ha ez igaz, akkor a megjelent karakter az "alma" szöveg kezdőcímének egy részéből képződik...
Az lcd_putc() deklarációjában a paraméter char típusú, az általad átadott adat típusa pedig const rom char* (nem tudom, hogy CCS-ben is így hívják-e, lényegében a ROM-ban elhelyezett, nullával terminált karakterfüzérre mutató pointer).
Egy sztringet szerintem így kellene kiírni:
|
Bejelentkezés
Hirdetés |
Köszi, ki fogom próbálni. 
