Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Mivel az órajel a működési referencia, ha jobban belegondolsz, ez lehetetlen is lenne. Nincs, ami az órajelet még tovább ossza, további időegységeket létrehozva ezzel.
Konkrétan ezt a típust nem ismerem és az adatlapot hirtelen megnézve valóban szűkszavú...
Én 16-os PIC-el használtam PWM-et, ott a periódusidő adott százalékáig adott 1-et, majd nullát, szerintem nem változtattak rajta ( így sajnos tényleg nehezebb szűrni!). Steve
Nem erre gondolok természetesen. Hanem hogyha mondjuk 4MHz-en megy a PIC, akkor osztás nélkül egy 16 bites számláló nulláról a túlcsordulásáig 0,016384 másodperc telik el. De az egyszerűség kedvéért legyen kereken 1 másodperc. Tehát azt kérdeztem, hogy jól olvastam-e a könyvet amiben azt írták, hogy a PIC nem negyed másodpercig ad ki H szintet aztán háromnegyed másodpercig L szintet (az előbbi példánál maradva), hanem egy órajelig H szintet, majd három órajelig L szintet.
Attila szerintem arra gondolt hogy a tmr2 8 bitje kiegészül még 2 bittel. Ami így úgy néz ki mintha 4x gyorsabban pörögne. Ja, és így lesz 10 bit, tehát nem 16.
Idézet: „Mint írtam, nem túl sok használható irodalmat találtam a PWM modulról.” A PIC Midrange Reference Manual eleg jol leirja szerintem, es hozza erdemes az adatlapot is elolvasni! Idézet: „ha mondjuk 25%-ra állítom be a kitöltési tényezőt, akkor nem az egész periódusidő negyedéig ((162*órajel)/4) ad ki H szintet aztán háromnegyed periódus-ideig L szintet, hanem kiad egy órajelnyi H szintet és három órajelnyi L szintet azért, hogy könnyebb legyen szűrni. Igaz ez?” Igy nem ahogy leirod, de tulajdonkeppen meg lehet csinalni, ha a periodus regisztert beallitod 4-re, es a kitoltest 1-re -- meg sohasem probaltam, ez csak az elmelet... De ekkor 2 bites lesz a max felbontasod -- ha ez elegendo akkor am legyen  Viszont alap koncepcio, hogy a periodus ido sohasem valtozik, csak a kitoltesi tenyezo... Tehat ugyanazzal a frekvenciaval dolgozol mindvegig ami jo, mert tudsz ra alul atereszto szurot tervezni.
Ezt olvastam:
Idézet: „Fontos! A 256-os ciklus átlaga lesz kitöltési tényezőnek megfelelő, és nem az első n értéknél magas, a többinél alacsony (például 50%-os kitöltési tényezőnél egymás után egy 1-es és egy 0-s érték következik váltakozva). Ez a váltakozás analóg feszültség előállításánál előnyös, mert könnyebb szűrni.” (Kónya-féle könyv második kiadása, 158. oldal.)
Hát ez igy elég fura lenne, michrochipes doksiban én ilyet nem találtam. Nem valami soft pwm megoldásról szól ez ?
Szia Attila86 íme egy segítő link:Bővebben:pwm-calculatorÜdv nyemi.
Hú, ez kicsit zavaros fogalmazás (ismerem egyébként személyesen a tanárt, aki írta, valóban néha kicsit zavaros, vagy az is előfordulhat, hogy a könyv írásakor nem minden egyes mp-ben volt a helyzet magaslatán, de hát ugye ő is embörgyerök).
 Szóval ez nem egészen így van. Ha belegondolsz, ilyen nem is lehetne, vagy ha lenne, azt másképp hívnák. A PWM azért PWM, mert adott időben egy adott frekvenciához tartozó impulzus szélességét modifikáljuk, azaz változtatjuk. Semmi értelme nem lenne ezt további ciklusokra bontani (akár 256 vagy 128, stb.), hiszen akkor már köze nincs az általunk beállítani kívánt PWM-frekvenciához, létrejönne egy "belső" periódusidő, a 0-k és 1-ek váltakozásával.
Szia!
Az egy szoftveres megoldás volt ( nekem egyébként nagyon tetszett!)! Steve
PWM betuszo amugy Pulse Width Modulation, azaz Impulzus Szelesseg Modulacio. Magyaran az impulzus szelessege ami valtozik nem pedig a frekvenciaja, amplitudoja vagy fazisa...
Egy olyan kérdésem lenne, hogy ha fopen() függvénnyel megnyitok egy nem szöveges dokumentumot. pl. egy wav fájlt, vagy egy mp3-t, akkor képes abból is olvasni adatot??
Az fopen() és fgetc() függvényeket nem érdekli a fájl adatformátuma. (Odaírhattad volna, hogy C30-ról van szó!)
MCC18-ban tudtommal nincs fopen(), ettől eltekintve ugyanaz...
ok
Más: Van egy karakter tömböm, erre egy mutatóval mutatok. Ezt szeretném (debug módban) a SIM Uart1-re kiiratni. Ilyenkor a tömb elemére ugye pointerrel hivatkozom, de ezt a printf -nek hogy kell beadni?? Tehát, hogy a "kimeneten" pl. az a jelenjen meg. char szo[] = {'a', 'b', 'c'}; char egy[]; char *p; p=&szo[0]; egy[0]=*p; printf("%s", *p); Idézet: „printf("%s", *p);” A %s formátumhoz szerintem egy nullával lezárt sztringet vár. A katarakterhez %c passzol.
Egy jó ötletre lenne szüségem:
Soros porton veszek egy bájtot, és annak az értékétől függően kell egy fájlmegnyitást végző függvények kéne átadjak egy fájlnevet. Tehát, ha a kód 0x01, akkor "elso.mp3". Arra gondoltam h switch -case szerkezettel oldom meg. switch(bajt) { case 0x01 : *p = tomb1[]; break; ... } Ez járható út? Vagy van ilyen problémára jobb megoldás?
A lenyeget mar icserny leirta, bar azt hiszem egyszerubb lenne WriteUSART() vagy putcUSART() fuggvenyt hasznalni ebben az esetben.
Amugy nem vagyok abban biztos, hogy az "egy" deklaracioja jo. Nem adtad meg a tomb meretet ugyanis. Masik, hogy a "p=&szo[0];" -t egyszerubb leirni ugy, hogy "p=szo;", bar lenyegi elteres nincsen.
Ebből következik a válasz.
Azt már nem PWM-nek hívjuk. Idézet: „Soros porton veszek egy bájtot, és annak az értékétől függően kell egy fájlmegnyitást végző függvények kéne átadjak egy fájlnevet. Tehát, ha a kód 0x01, akkor "elso.mp3".” Eltarolhatod a cimeket egy tombben, es akkor egyszeruen csak ki kell olvasni az indexnek megfelelo erteket:
Ehhez annyit tennék hozzá, hogy ROM területen lenne érdemes elhelyezni a konstansokat, tehát így:
Próbálni én sem próbáltam
Remélem jól értelmezem, első nekifutásra kicsitt magas volt
Szóval, van egy *filenevtomb[] nevezetű mutató tömb, ami most négy elemből áll. Mind a négy mutató egy egy sztringre mutat, ami a ROM-ba van letárolva. Az fntomb_max a mutató tömb max elemeit tartalmazza. Az index segitségével hivatkozhatók az egyes mutatatók által mútatott sztringre. Ha az index kisebb mint a tömb elemszám, akkor a p -be megkapom a szirnget. Ha az index nagyobb, akkor meg valami hiba kezelés. Amit nem tiszta: p = *filenevtomb[ index ]; p-t unsigned chat típusra deklaráltam. Az indexnek értéket adva, a p-be nem jelent meg. Ez így lehet, hogy hülyeség. Ezt nem értem. Ha pl. p-nek 0x05-t adok át, akkor azt ugye felveszi. De mi a helyzet ha sztring van??
Igen, jól érted.
Így add meg a p-t:
A p egy mutató lesz, amit át kell adnod a printf-nek, fopen-nek. Bár így utólag belegondolva nembiztos, hogy pl. a printf szeretni fogja a rom-ra mutató pointert, és lehet, hogy mégis rom nélkül kell csinálni. Ki kell próbálni.
Müködik, köszönöm.
A printf-s csak kiváncsiságból kellett A többit kis átalakitás után már feltudom használni. Idézet: „Bár így utólag belegondolva nembiztos, hogy pl. a printf szeretni fogja a rom-ra mutató pointert, és lehet, hogy mégis rom nélkül kell csinálni. Ki kell próbálni.” Ha jol emlekszem nagy %S -t kell neki megadni -- benne kell legyen a doksiban. Idézet: „Ha jol emlekszem nagy %S -t kell neki megadni” Igen jól emlékszel! A rom char* típusú mutatóhoz %S kell. A far rom char* típusú mutatóhoz meg %HS kell - a dokumentáció szerint (fprintf-nél kell keresni...).
Azt szeretném megtudni, hogy az adatmemóriában maximum hány regiszterhez (bájthoz) tudok hozzáférni ugyan abban a bankban úgy, hogy a regiszterek közvetlen egymás után vannak (nincs köztük semmiféle speciális, kitüntett regiszter). Az adatlap erről szóló, mellékelt lapja nem egyértelmű nekem. A BANK 0, 1, 2, 3, 4, 5-nél GPR van írva. Nem tudom még hogy mit jelent, ezért hagyjuk.
 A 6. BANK-tól a 14.-ig viszont nincs használatban. Akkor innen akármelyik BANK-ot felhasználhatom az elejétől a végéig? Nincsenek közte speciális regiszterek, mint a programmemóriában?Azt olvastam mindenhol, hogy a közepes teljesítményű PIC-ek adatmemóriája 2 vagy 4 lapra (BANK) van felosztva. De a 18f4520 adatlapján (mellékelt kép) 16db BANK van! Akkor hogy van ez? Azt is olvastam, hogy egy BANK 512 bájtot foglal magába. Igaz ez? Indirekt címzéssel szeretnék egy halom számot (A/D konverzió eredményeit) egymás után szépen bepakolni a memóriába. Végső soron azt szeretném megtudni, hogy hány bájtnyi számot tudok 'elmenteni'. |
Bejelentkezés
Hirdetés |
