Fórum témák
» Több friss téma |
(E)usart esetén az RB7 - RB5 és RB5 - RB7 a helyes összekötés.
Nem tudom! Az adatlap ezt írja:
In order to configure pins RB6/SCK/SCL and RB7/TX/CK as the Universal Synchronous Asynchronous Receiver Transmitter: ? SPEN (RCSTA<7>) bit must be set (= 1), ? TRISB<6> bit must be set (= 1), and ? TRISB<7> bit must be set (= 1).
Köszönöm!
Következőket ollóztam a projektből és egészítettem ki egy függvénnyel, amiben megnézem az adott bit állapotát és számolom az impulzusokat.
#if defined(USE_INTERRUPT) #pragma interrupt hi_isr void hi_isr() { if (PIR1bits.TMR2IF){ jbit=1; } PIR1bits.TMR2IF = 0; if(delay) delay--; USBDeviceTasks(); } #pragma interruptlow lo_isr void lo_isr() { dummy=PORTB; INTCONbits.RBIF=0; cFlag = 1; impulzusok(); } #endif //USE_INTERRUPT unsigned int impulzusok (void){ if (cFlag) { delay_ms(20); cFlag = 0; b2all=(b2all++); if (be3==0){ b3all=(b3all+2); } } } a számlálás jól működik. Üdv.
Megszakításvektroban beállítod cFlag változót, utána meghívod az mpulzusok függvényt, ami megnézi hogy 1 -e. Ennek így nemsok értelme van szerintem. A delay_ms megszakításban használata bizonyos körökben halálos bűn
 . Ez az egész függvény? Nem szól a fordító hogy uint típusú a függvény de nincs visszatérése?
Heló!
2x16-os LCD kijelzőre szeretnék egy float típusú számot kiírni, de a FloatToStr funkcióval 6 tizedesjegy jelenik meg, nekem csak 2 kellene. Sprintf-et nem tudok használni. Van valami más lehetőség a szám formázására? Előre is kösz!
Nem tudom, hol olvastad. Nálam a 12.1.1.1 szekcióban ilyeneket írnak:
Idézet: „The EUSART transmitter is enabled for asynchronous operations by configuring the following three control bits: * TXEN = 1 * SYNC = 0 * SPEN = 1 All other EUSART control bits are assumed to be in their default state. Note 1: When the SPEN bit is set the RX/DT I/O pin is automatically configured as an input, regardless of the state of the corresponding TRIS bit and whether or not the EUSART receiver is enabled.”
Megírtam ez a két kis programocskát azonban nem működik. Az első pic-en egy kapcsoló állásától fügően küldeném az üzenetet, a második pedig egy kétfényű ledet változtatna, az üzenetnek megfelelően.
Szerintetek mi lehet a hiba? *A progit a tab hiba miatt kivettem, ennyit tehettem .
Első ránézésre:
1. nincs analógról digitálisra állítva RX/TX láb 2. nincs az átviteli sebesség beállítva 3. TX nincs kimenetnek állítva 4. nincs figyelve hogy érkezett-e adat (csak akkor kerül érvényes adat RCREG-be)
1. alapértelmezetten digitális
2. az alapértelmezett beállítás az nem az ami a belső oszcillátorhoz jó? 3. jogos
2. állíts be valami alacsonyabb sebességet, pl. 9600bps-t. Nemtudom, mi az alapértelmezett érték, de ezeket mindig be kell állítani.
5. nincs figyelve az, hogy a TXREG kiürült-e. Így egymásra küldöd az adatokat, ami miatt lesz egy hibajelzés és leáll a küldés (ha jól emlékszem). A kódodból a behúzásokat csak az oldal szedte ki, vagy tényleg nem használsz behúzásokat? Utóbbi esetben használj. Idézet: „Csak szólok, hogy te is a karakterenkénti megszakítást javasoltad. Tehát a helyes válasz: nincs.” Miert, ez most melyik PIC amiben nincs az asynchron kuldesnek megszakitasa?
5. Hogyan lehet megoldani ezt a problémát.
Íme a javított de még mindig nem működő programok (használok behúzást csak kiszedi az oldal):
5. -> PIR1 regiszterben figyeled a TXIF bitet.
A vételhez a CREN bitet is be kell kapcsolni! Olvasd az adatlapot!
A tabulátort nem szereti az oldal, cseréld szóközökre.
A cFlag változó figyelése az első próbálkozásból maradt, amikor a főciklusban figyeltettem a bemenet változását (persze az ciklus sok teendője miatt lassúnak bizonyult) azért is próbálkoztam függvénnyel.
Arra persze nem gondoltam hogy annak hívása tulajdonképpen a megszakítás része és nem szabad a pergésmentesítés miatti késleltetést itt alkalmazni. Arra viszont szükség van, a hardveres pergésmentesítésen kívül van esetleg más egyéb szoftveres megoldás? Most nézegetem a PICOLLO projekt számlálók/időzítők fejezetét és itt látom a pergésmentesítés mintavételezéssel részt, talán megoldás lehet a problémámra. Jól gondolom? A fordító egyébként nem szólt hogy a függvénynek nincs visszatérési értéke (eredetileg úgy csináltam) lefordult és működött is a számlálás, csak mint kiderült a rossz helyen alkalmazott késleltetés miatt az USB adatforgalomba némi zavar keletkezett.
Sziasztok!
Bocs, ha rossz topikba írok, 8000 közül nehéz kiválasztani az egyetlen tökéleteset. A kérdésem az volna, hogy ezen a párhuzamos portos égetőn el lehet-e hagyni a D3 és a D4 közül az egyiket. Más LPT-s égetőket megvizslatva, számomra feleslegesnek tűnik. Mivel ez lesz az első égetőm, inkább kérdezek hülyeséget, mint csinálok. Idézet: Igen. „a pergésmentesítés mintavételezéssel részt, talán megoldás lehet a problémámra.”
Attol fugg hogy a kezeloprogram mit hasznal.
Mi az a "besik" ??
 Basic nyelv van. Vannak programok amik visszaforditanak HEX forrast ASM-re ugy hivjak hogy disassembler. De basic-re vagy mas magasabb szintu nyelvre meg nem lattam.
Köszi, próbálkozom. Nem egyszerű, de még mindíg könnyebb mint a hardveresen.
Üdv.
Bocsánat, hogy megint begányolom a programjaim, de még mindig nem működnek. Az RA4-es lábra egy ledet tettem kontrol gyanánt. A vevőnél ez a led egyáltalán, ki sem gyullad.
Az adatlapot olvasva sem sikerült megoldanom.
A vételi oldalon meg kell írni a hibakezelést. Le kell kezelni a ráfutási hibát (is), amit csak a vevő kikapcsolásával lehet törölni. Egy karakter esetén előbb a státus kell kiolvasni, aztán a vételi regisztert. Ez utóbbi a státust is frissíti... Hibás vétel esetén a vételi regisztert is ki kell olvasni.
Kiolvasás alatt törlést értesz? Nincs valahol egy minta program erre?
Szia!
Ki kell olvasni a RCSTA -t az értékét el kell menteni egy változóba, annak alapján kell eldönteni, hogy jó-e a vett karakter vagy történt valami hiba. Ha ráfutás hiba történt, ki kell kapcsolni a modult (SEN=0), majd visszakapcsolni (SEN=1). Mindenképen ki kell olvasni a RCREG regisztert, ha hibás volt a vétel, a karaktert nem szabad feldolgozni...
Az adó működik?
Nem ismerem ezt a fordítót (hitech ?) de #define-val vannak az sfr regiszterek definiálva vagy extern változóként? Nem kell használni a memóriacím.bit módszert (pl. TRISB7 helyett TRISBbits.TRISB7) ? Ha define-val vannak megadva akkor ugye simán lefordítja ezt is, csak épp a bitszám megadást memóriacímként értelmezi a fordító. Még egy ötlet: próbáld meg a sebességet nagyon lassúra venni (hogy látni lehessen a villogást) és egy ledet rakni a TX lábra is.
Sziasztok, bocsi, hogy közbeszólok, de nekem is vannak valami emlékeim Hi-Tech C -vel kapcsolatban:
- úgy emlékszem, hogy kell a htc.h is: #include < htc.h > - meg kell adni az órajelet is: #define _XTAL_FREQ 4000000, itt pl. 4MHz - a _config-nál nekem is sokszor akadt gondom, itt egy példa: __CONFIG(LVPDIS & WDTDIS & INTCLK & UNPROTECT & INTIO & BORDIS);, az INTCLK és INTIO azt harározza meg, hogy belső órajelről fut és a clk lábakat lehet használni I/O-nak. - a TRISx -et már nem emlékszem, hogy lehet használni pl. TRISB7 megadással, de úgy lehet, hogy TRISB = ..., ebben nem kell úgy mint C18-ban (TRISBbits.TRISB7), a portoknál lehet használni pl. RB7-et, vagy PORTB = ... (lehet hexában pl. 0x01, vagy binárisan 0b00000001, vagy csak simán decimálisan). A config-ot be lehet állítani valahol a menüben is de akkor a fordításnál nem elég csak simán compilálni, hanem exportálni kell (File -> export). Kb ennyi jutott eszembe most, mert már majdnem egy éve a mikroC-t használom, abban van help és minen függvényre/parancsra példa program részlet is van
Ti milyen nyelven programozzátok a pic-jeiteket?
Assemblyben - mert minden a én kezemben van...
|
Bejelentkezés
Hirdetés |
