Fórum témák
» Több friss téma |
Köszi mendkettőtöknek a választ!
Én mindig úgy csináltam, hogy a memóriában csináltam egy akkora tömböt amibe pont belefér a teljes kijelző tartalma (nevezzük frame buffernek) és a programban csak ebbe a tömbbe írogattam a megjelenítendő szövegeket. A háttérben pedig megszakításból 1-2ms-ként mindig frissítettem 1db karaktert. Így nem kellett busy flag-ot figyelnem, és villogtatni is lehet bármelyik karaktert (akár az összeset is).
Szeretnék egy kis segítséget kérni.
Hogy kapcsolom be a belső felhúzó ellenállást 16f676-nál? Mikroe C-ben próbálok programozni.
A WPUA regiszterben van erre lehetőség, de csak a PORTA 0,1,2,4,5 lábain. A C-hez nem értek, de gondol ha a 0,1 lábakon kell bekapcsolni valami ilyesmi lehet: WPUA = 0x03
OPTION_REG.RAPU = 0;
ha az elso nem mukodik, akkor a masodik: OPTION.RAPU=0 ja, igen; és ezen kívül WPUA megfelelő bitjeit 1-be kell rakni A hozzászólás módosítva: Máj 20, 2019
Ezek szerint a C porton nincs sőt az A porton is csak 0,1,2,4,5 ha jól értem.
De az egész lehetőséget engedélyezni kell az OPTION REG-ben
Ha az OPTION_REG.RAPU = 0; akkor van engedélyezve? Vagy ha =1;?
A hozzászólás módosítva: Máj 20, 2019
Igen, de ilyenkor érdemes beleolvasni a datasheetbe.
Idézet: „ RAPU: PORTA Pull-up Enable bit 1 = PORTA pull-ups are disabled 0 = PORTA pull-ups are enabled by individual PORT latch values ” http://ww1.microchip.com/downloads/en/devicedoc/40039f.pdf A hozzászólás módosítva: Máj 20, 2019
Persze, hogy olvasom, kinézem már a szemem, de RAPU-t nem találok sehol,
csak ennyit: "Note 1: Global RAPU must be enabled for individual pull-ups to be enabled" 2: The weak pull-up device is automatically disabled if the pin is in Output mode (TRISA = 0).
Sikerült, köszönöm.
16F676 OPTION_REG = 0b00000000; //a 7-es bit ha 0 akkor van felh.ell. WPUA = 0b00110111; // csak az A porton van hátha valaki hasonló cipőben...
Ezt úgy érted, hogy a 2x16 harakternek, vagy a teljes DDRAM méretének megfelelő tömböt?
Köszi a választ! 
A 2x16-os esetén 2x16+1 (azaz 33 byte) méretű tömböt. A +1 byte csak azért, mert ha könyvtári függvényt használok a karaktertömb előállításakor előfordulhat, hogy az utolsó karakter után még egy lezáró #0-t is mögé rak. Az pedig ugye nem szerencsés, ha ezzel más változót felülír. A 2x16 karakteres esetén 32+2 = 34 megszakítás alatt lehet a teljes tömb tartalmát átvinni a kijelzőbe (a +2 a sor eleji DDRAM címzés miatt kell). Ha könyvtári függvényeket is használunk a kiírandó szöveg előállításához, érdemes a #0 kódú karaktereket szóközzel helyettesíteni a kijelző írása során, mert az itoa és társai függvények fognak #0 kódú karaktereket belerakni a "frame bufferbe".
Köszi a választ!
Idézet: „A 2x16 karakteres esetén 32+2 = 34 megszakítás alatt lehet a teljes tömb tartalmát átvinni a kijelzőbe (a +2 a sor eleji DDRAM címzés miatt kell).” HD44780 @ 250kHz: DDRAM írás 37us + 4 us a cím frissítése. 32 karakter kivitele 32* 41 us = 1312 us = 1.312 ms. Ehhez még jön kétszer a cím beállítása azaz 40us. Az átvitel 1.352 ms -ig tart. Ha ezt megszakítási szinten végezné a kontroller, rengeteg dologról lemaradna. Meg kell vizsgálni, hogy a feladat megengedi az ilyen hosszan tartó megszakítás kiszolgálást. Kettős pufferelést kellene csinálni, azaz az egyiket a program módosítja, a másikat egy timer megszakítás karakterenként (40 .. 50 us -enként 1 karakter) másolná át a kijelzőre. Így lehetősége lenne adatokat megjeleníteni 740 byte/sec (7396) sebességnél nagyobb sebességű UART kapcsolatról is. A hozzászólás módosítva: Máj 21, 2019
Ha 1ms timer megszakítást használok, akkor 34ms alatt viszi át a teljes kijelzőtartalmat (mivel megszakításonként csak egyetlen parancsot vagy karaktert írok a kijelzőre így semmilyen us nagyságrendű várakoztatásra nincs szükség). Ez nagyjából 30fps-t jelent. Ennél többnek szerintem semmi értelme nincs mert a kijelző maga elég lomha. Ha már úgy is ott az 1ms megszakítás, fel lehet azt még használni egyéb tevékenységre is, pl. számláló léptetésre a ms vagy sec nagyságrendű időzítésekhez.
Ekkor még kellene egy állapotjelző, hogy a puffert a megszakítás olvassa vagy a főprogram módosítja.
A driveremben úgy csináltam meg, hogy olyan üzemmódot is be lehet állítani (#define-vel 5 féle üzemmód közül lehet választani). Ekkor a frame buffer feltöltése után szólni kell a drivernek, hogy új tartalom van->frissítsd a tartalmat. Viszont úgy nem lehet villogó karaktereket kirakni, csak ha folyamatosan frissítjük a kijelző tartalmát. Mindegyik üzemmódnak vannak előnyei és persze hátrányai is, a feladattól függ, melyiket érdemes használni.
Üdv. Mennyi a PIC18F46K22 SPI modul max. beolvasási sebessége? Nekem 20MHz kellene ennyit tud-e? Nem találok erről semmit az adatlapon.
Köszönöm.
60MHz max. órajel eleve kizárja.
Master módban max. Fosc/4 Slave módban Idézet: „external clock must meet the minimum high and low times as specified in the electrical specifications”
Master mód kell, ezek szerint 64MHz a max. órajel PLL -el, tehát 16MHz lehetne? Az is jó lenne.
Az az elméleti maximum.
Nem tudom milyen feladatra akarod használni; én nem nagyon hiszek ezekben a maxon járatásokban. Ez ugyan egy HW blokk, de a kiszolgáló rutinoknak is le kell futniuk valamikor. Persze kellő hozzáértéssel és odafigyeléssel nyilván ki lehet használni a proci maximumait, de ez értelemszerűen többlet munkát jelent a megvalósítás során.
LTC1864 A/D -hez, minél gyorsabb mintavételezési freki kell kb. 10 mintavételezésig, utána van idő. Ez 16 bites, 2 lépcső egy beolvasás, gondolom a 8 bites buffer egy kiolvasása után mehet a másik 8 bit. Csak szórakozás, elbíbelődgetek vele.
Köszi.
Sziasztok!
PIC16f628a vezérlővel szeretnék UART-on adatokat olvasni, de nem sikerül ha azt akarom kiolvasni, hogy van e a válaszban ok szó. Random kiírja , hogy rendben meg szétfagy ahogy küldök adatot neki.
A hozzászólás módosítva: Máj 22, 2019
Idézet: „char *tmp[255]; //Ezt a változót hozom létre az olvasott adatoknak” Error [1250] main.c; 2. could not find space (510 bytes) for variable _tmp Ez a sor nem egy 255 elemű karakterre mutatókat tartalmazó tömböt hoz létre?
Ez a sor valóban létrehozná a változót. Van-e egyáltalán annyi RAM ebben a kontrollerben, amennyi ehhez a feladathoz kellene? Nincs. Ld adatlap 224 bytes of RAM. Ráadásul a RAM -o lapozva kezeli a hagyományos 16F család, így egy lapon max 80 byte kezelhető. A Common külön kezeli a fordító (XC1.33). A hozzászólás módosítva: Máj 22, 2019
Idézet: „UART1_Read_Text(tmp, "ok", 10); // Kiírjuk a tmp változóba” Nem látok bele az UART rutinjaidba, de ez az egy sor kétlem, hogy rendben lenne A beérkezett bájtokat pufferelni kell és az "OK" stringet a pufferben kell keresni. Persze ilyenkor felvetődik, hogy mikor töröld a puffert, vagy körforgóra hagyjad - de akkor hogyan keresel egy körforgó pufferben, stb. Nem írnám meg a kódot helyetted, de kiindulásnak valami ilyesmi:
Igazad van, bocsi , elírtam. Az ott így néz ki:
Húha , ez a teljes kód:
Minden adatra azt írja, hogy RENDBEN. A library azt írja, hogy az "strstr" pont akkor ad 0 értéket vissza, ha nincs benne az a karakterlánc amit keresek. A hozzászólás módosítva: Máj 22, 2019
|
Bejelentkezés
Hirdetés |
