Fórum témák
» Több friss téma |
Nincs fent a teljes programod, pedig HP41C kolléga kérte...!
Úgy látom, hogy a végtelen ciklusban a tömböket folyamatosan töltöd fel, majd kijelzed a tartalmukat. 1 LED fényerejét az határozza meg, hogy a LED 2 bekapcsolás közötti időnek hány százalékában működik ! Ha tehát pl. 1 ms-ig világít az 1.szint LED-je, majd működik a többi szint ( 4szint --> 4 ms-ig ) majd a töltés pl. 1 ms-ig, akkor a LED 1ms/6ms, kb. 1/6 fényerővel fog világítani! Ennek és az egyes részek futási idejének ismeretében gondold át a programod és ha jónak tartod és tapasztalod a szervezését, akkor hagyd úgy!
De felraktam linkeltem is... Vagy is a teljes kódrészlet amit használok.
Elindítod szimulátorban, és a stopperrel megméred melyik mennyi ideig fut.
Egy megoldási javaslat:
- Időzített, időhöz kötött feladatokat egy időzítő megszakítással kellene vezérelni. Ha a lehetőségek még mindig túl rövid időt adnak ki, egy számlálót kell még felhasználni. A megszakítási rutin minden lefutásakor csökkenti a számlálót. Megvizsgálja, hogy 0 -e. Ha nem nulla, visszatér. Ha 0, újrainicializálja és elvégzi az időzített feladatot. A feladat legyen olyan rövid, amilyen rövid csak lehet. - Annak érdekében, hogy a lehető legrövidebb idő alatt le lehessen futtatni a megszakítási rutint, alkalmazzon kettős pufferelést. A puffer tartalma legyen olyan formában, hogy egyből lehessen a PORT / LAT regiszterekbe másolni. - A második puffert ez alatt az idő alatt a fő program töltögeti. Ha kész, jelzi a megszakítási rutinnak, hogy elkészült az adat és egyben figyeli is, hogy a megszakítás már átvette-e. - Ha bekövetkezik a kívánt idő és kész az új adat (addigra kész kell lennie) puffert cserélnek. A megszakítási rutin a most előállított tartalmú pufferből viszi az adatokat a PORT -okra, a fő program pedig a régi puffer tartalmát írja át. Ekkor biztos lehetsz abban, hogy két frissítés között mindig ugyanannyi idő telik el. Nem kellene ennyit indexelni. pl.: LATA.RA1=l[i][4]; Meg kellene nézni, hogy mire fordul. Megint az assembly.... Előbb egy szorzással kiszámolja az l[i][0] címét, majd egy összeadással az l[i][4]. A 0 bit szerint minimum 4 utasítással beállítja a LATA 1. bitjét. Ha mutatót alkalmaznánk: Egy újabb ciklus elején kiszámoljuk a l[i][1] címét és eltároljuk egy mutató változóban, ezután a mutatóval címezzük a soron következő adatot. LATA.RA4=*mutato++; és máris a következőre léptetjük. Kimarad 24 darab szorzás. Ha tovább lépek és a tárolás már olyan formában van, hogy vihető a portra: LATA ^= (LATA ^ (*mutato++)) & (LATA_MASK); LATB ^= (LATB ^ (*mutato++)) & (LATB_MASK); stb. A fenti sorok csak azokat a biteket állítja át a mutató által címzett rekesz tartalma szerint, amelyeknél a LAT?_MASK megfelelő helyiértékén 1 áll. A hozzászólás módosítva: Máj 10, 2017
Sziasztok!
A PICKit 3 Programmer To Go funkciójával kapcsolatban kérnék segítséget. Nem tudok rájönni, hogyan tudnám használni. Lehetséges, ha a projekt nem MPLAB-ban készült? MPLAB IPE programban próbálkozom, beírom az image name-t, majd a Programmer to go-ra kattintok, de látszólag nem történik semmi.
Hu köszi. És az MPLAB-nak nincs korlátja, ugyebár? Mert sajnos Mikroc-ben a demo verzióban van egy 2kBos limit a programmemóriára.....
És te milyen c fordítót használsz?
Az XC8, XC16, XC32 -nek nincs korlátja, de háromféle licencelési lehetősége van:
PRO - Legjobb optimalizálás - drága, Standard - rosszabb optimalizálás - olcsóbb, Free - nincs optimalizálás (inkább szószátyár) - ingyenes.
Sziasztok,
Ismét egy technikai jellegű kérdéssel fordulok hozzátok A PIC16LF1825 adatlapjában szó van egy bizonyos "INLVLA: PORTA INPUT LEVEL CONTROL REGISTER" regiszterről. Nekem úgy néz ki a kapcsolás, az RA4 ÉS RA5-öt két schmitt trigger buffer kapcsolja. A buffereket két nyitott drainű komparátor kapcsolja (a kimenetén egy R-C kapcsolás ad még + hiszterézist.). Ha beállítom az INLVLA regisztert úgy, hogy RA4 és RA5 Shmitt trigger bemenetű legyen, akkor elvileg elhagyhatom a kapcsolásomban szereplő buffereket!? A hiszterézis is megfelelő lenne, mert az adatlap szerint az L szint = 0.2 x VCC H szint = 0.8 x VCC Valamint ha ezeket bekapcsolom, nem befolyásolja az IOC-t? Mert RA4 és RA5-re az is be van állítva.
Az Mplab az csak IDE,vagyis csak fejlesztő környezet. Ez alá lehet C fordítókat feltenni,ahogyan Hp41C is írja. De mint írtam,ha nem új PIC-ekkel dolgozol,akkor jó a régi C-s fordító is aminek van okosított verziója,így tud optimalizálni.
Idézet: „Nem kellene ennyit indexelni. pl.: LATA.RA1=l[i][4]; Meg kellene nézni, hogy mire fordul. Megint az assembly.... Előbb egy szorzással kiszámolja az l[i][0] címét, majd egy összeadással az l[i][4]. A 0 bit szerint minimum 4 utasítással beállítja a LATA 1. bitjét. Ha mutatót alkalmaznánk: Egy újabb ciklus elején kiszámoljuk a l[i][1] címét és eltároljuk egy mutató változóban, ezután a mutatóval címezzük a soron következő adatot. LATA.RA4=*mutato++; és máris a következőre léptetjük. Kimarad 24 darab szorzás.” Ezt nem nagyonértem zavaros. Máskép eltudod magyarázni?? Egy folyamat ábrát tudnál melékelni hozzá? Kösszi A hozzászólás módosítva: Máj 10, 2017
Az l[i][4] egy kétdimenziós tömb egy eleme. Valószínűleg a deklarációja char l[6][5] lehetett...
Egy gyufásdobozokból felépített tárolót képzelj el, 6 szinttel és szintenként 5 fiókkal. Sajnos a kontroller memóriája egydimenziós, így a fordító veszi a nagy kést és szétvágja a tárolót a szinteknél, majd a 1. szintet az 0. 4. eleméhez ragasztja. (Sajnos a C 0 -tól kezdve számol, létezik az l[0][0] eleme is.) A 2. szintet pedig a 1. szint 4. eleméhez ragasztja. stb. Kapott egy egybefüggő 1 szintes 30 rekeszes tárolót. Keressük a i -edik szint j -edik elemének címét. Az l[0][0] cím a tömb kezdőcíme. Ehhez hozzá kell adni i * (a szintenkénti rekeszek száma) -t és még hozzá kell adni j -t. Ezt minden l[i][j] alakú kifejezés kiértékelésekor meg kell tenni, ha az indexek változók. Ha mutatót (char *) használunk fel, azt a feldolgozás elején a kívánt szint kezdőcímére lehet állítani (l[i][0] címére), onnan már egymásutáni rekeszekben levő adatokat sorban ki lehet szedni, ha kiszedés után léptetjük a mutatót.
Vagy is a ha jól értem..
szint 0 : 0000 szint 1 : 0000 szint 2 : 0000 szint 3 : 0000 Egybefüggö "kétdimenziós" tömb: 0000|0000|0000|0000 És egy ilyen sor a kétdimnziós tömböm. Igen akkor Idézet: „Nem kellene ennyit indexelni. pl.: LATA.RA1=l[i][4];.....” Hogy lehetne ezt az indexelös dolgot C ben megvalósitani??
Nem olvasod el mit írnak?
Idézet: „Ha mutatót (char *) használunk fel,”
De hogy lehet valami mutató és nem mutató??????
Kernighan Ritchie C programozás
Rendfokozat: * őrvezető, ** tizedes, *** szakaszvezető, **** alhadnagy, ***** hadnagy, ****** százados, ******* őrnagy, ******** alezredes, ********* ezredes, stb A hozzászólás módosítva: Máj 10, 2017
Idézet: „Nem ártana olvasgatni valami C# könyvet...” c# ugy tudom nincs pointer
Sziasztok,
Proteus-al szoktatok szimulálni? Mennyire szokott korrekt lenni a PIC-ek szimulálásánál? MPLAB X-ben elvileg tökéletesen működik a programom, Proteusban meg nem igazán.. Pl az alvó állapotból ki sem akar lépni..
Valahogy igy kéne indexhelés helyet??? Az a problémám megoldodott hogy az 5 szinti led jobban villágit mint a többi. Már csak annyi a baj 1ms en halványabbak a ledek mint pl 5 ms nél A hozzászólás módosítva: Máj 10, 2017
int *pa;
char a[5][10]; pa =&a[1][1]; LATA.RA4= *(pa++); LATA.RA3= *(pa++); LATA.RA2= *(pa++); LATA.RA1= *(pa++); LATA.RA0= *(pa);
Miért nem a nulladikat használjuk kezdönek??
Igy kell érteni?? A hozzászólás módosítva: Máj 10, 2017
Te írtad:
Az utolsó sor az a[1][1] értékét viszi a LATA.RA4 -be.
Így nézzne ki a kódom.
Hogy hogy elötte van a ++?
szerk.:
Hát beraktam a kódomba de össze vissza villágit és egy két led. Miért? A hozzászólás módosítva: Máj 10, 2017
Kihagytad az őrmestereket, a zászlósokat, és a hadnagyok közül a főhadnagyot. Alhadnagy rangfokozat pedig nincsen. Részint már a fordító is pampogna, de egyébként is úgy eltévedne a programvezérlésed, hogy ihaj!
A hozzászólás módosítva: Máj 10, 2017
A 33. sorra már jó ellépkedett a mutatód a &l[i][0] címről. Minden ++pa vagy pa++ lépteti a mutatót!
|
Bejelentkezés
Hirdetés |