Fórum témák
» Több friss téma |
Közelebb is kapható. Sajnos csak sárgászöld színben hozzáférhető.
A hozzászólás módosítva: Okt 27, 2014
A piccolo projekt LCD vezérlés részében találsz 8bites 4bites példát az LCD-hez, fő különbség a lábszám ami a vezérléshez kell és a minimum várakozási idő 4bit 2x160µs 8bit 160µ(persze ez adott utasításnál nagyobb is lehet).
Ahogy látom ennek a háttérvilágítása 4.2V 200mA 5V-ra 4Ohm a minimum.
Hali!
Szerintem tipikusan 42usec a várakozási idő, parancsoknál, írás/olvasásnál 46usec. Kétsoros 162B van nekem, egy kis trükkel pedig 2usec re redukáltam le, mert sokalltam azt a felesleges 440 utasításnyi várakozási időt karakterenként.
Szia!
A Hitachi HD44780 adatlapban az írásra 37+4 usec van megadva, de most nem ez a lényeg, hanem az maximális idő, tehát annál lehet kevesebb. Viszont a 2 usec nem biztos hogy mindig elég lesz. Vagy olvasod a busy flaget? Mert ha igen, akkor nem szóltam. 
Köszi! Már rajzolom is a nyákot.... egyszer bizti kész lesz
Nem saját ram buffer van a főprogi ciklikusan (31msec) kirak 1 betűt és már rohan is tovább.
A saját buffer törlése is elenyésző idő semmilyen lcd parancsot nem kell kitenni. egyedül sorvégeken kell 46usec időt várni (be kell írni az uj sor címét)
Jaaa, azt hittem, hogy 2 usec telik el két karakter között.
 Hát igen, "nagyban" így is kell csinálni (illetve a legszebb megoldás a busy flag olvasása, de ki engedi meg magának azt a luxust..  ).De azért a ~40usec nem olyan sok idő. A 440 utasítás ennyi idő alatt 44MHz Fosc mellett darálódik le (ha el nem számoltam magam...). Mihez kell ekkora sebesség?
Nem kell ekkora sebesség, de 2 stepper motor vezérlés lcd kezelés lebegőpontos számolás , billentyűzet , komparátorok és külső megszakítás előtolás vezérlésének számítása ....
Elgonolkodtam, hogy amikor gyorsan kéne reagálni valamire és épp 16 karater kiírása van folyamatban miért is kell várni majd 1mS időt.feleslegesen. A program úgy van felépítve, hogy az egyes funkciók egy-egy jelzőbitre indulnak el. tehát a főprogram csak azt a rutint hívja meg ami "aktív" frissítésre vár. tehát a 10-15 feladat áttekintése pár usec az egyes rutinok sem hosszúak, de az lcd kilógott a sorból. Egyébként saját kíváncsiságom volt.
A mellékelt programmal van egy olyan gondom, hogy a CCP megszakításokból számított érték az LCD kijelzőn össze vissza ugrál. Próbáltam úgy is, hogy egy másik PIC-kel állítottam ellő egy kb 10 Hz-es négyszögjelet és az kötöttem a CCP bemenetre, de akkor is 000 és 021 ugrál nagyon gyorsan.
Számtalanszor átnéztem a programot, de nem találom a hibát. Próbáltam Mplab szimulátorban, de nem lettem okosabb. Próbáltam Proteusban is, de az meg semmit nem csinál. A hozzászólás módosítva: Okt 28, 2014
Már többször javítottam a programodban az alábbi részt:
Itt az a bökkenő, hogy a movf utasítás állítja a STATUS regiszter Z bitjét.
A swapf viszont nem változtat a nagy nehezen visszaállított STATUS értéken.
Ezzel csak a problémákat hozod magadnak. A 0x800 -on kezdődő rutinok már az 1. program lapra kerülnek, a híváskor / visszatéréskor a PCLATH regiszter is kezelni kellene, valamint a megszakítás kezelőben is foglalkozni kellene a PCLATH -val. Javaslom inkább az
használatát. A hozzászólás módosítva: Okt 28, 2014
Köszönöm! A swapf -et értem, javítom. Az org 0x800 csak maradvány, egy nagyobb programból vágtam ki ezt a részt. Ki is veszem belőle. Egyébként is ez a szövegkiíró rész csak az induláskor hajtódik végre.
Ezek közül valamelyik okozhatta a hibajelenséget?
Mindkettő katasztrofális eredményhez vezethet, de nem biztos, hogy ezek okozzák az összes problémát.
Srácok, ha használom az USB modult és bootloadert is, akkor nem tudom a PIC-ben lévő programot védeni?
Olvasás elleni védelemre gondolok elsősorban. 18F4550.. (gyári michrochip bootloader) Azért kérdezem mert minden, kivéve a táblázat védelme, be van kapcsolva még is simán ki tudom olvasni a programot USB-n keresztül..
Ha a Táblázatolvasást is próbáltam, de ha tiltom, akkor nem indul el a program.. Előre is köszi.. A hozzászólás módosítva: Okt 28, 2014
Ez egy jó ördögi kör:
Ha bekapcsolod a TBLRD kiolvasási védelmet, akkor nem tudja a boot loader eldönteni, hogy a program már be van töltve illetve nem tudja ellenőrizni a programozását. Ha ki van kapcsolva, akkor pedig az ellenőrzés miatt a kiolvasás is lehetséges. Úgy lehet védekezni, hogy a főprogram, ha újraprogramozást kér, törli saját magát (vagy egy részét). Ez a törlő rutinnak a boot loader részének kell lenni, a boot loader memória területén. Ezt a programrészletet kell akkor is hívni a boot loared kiszolgáló előtt, ha más módon aktivizálják a boot loader -t (csatlakoztatáskor gomb lenyomva). Így, ha le lehet indítani a fő programot, akkor a boot loader funkciói elérhetetlenek, ha nem, akkor már nincs mit kiolvasni.
Puff neki, akkor ennek annyi is..
A gyári bootloader alig fér bele még MPLAB-os optimalitással együtt is a megadott területére, nem hogy még plusz törlő rutint írni hozzá. Iszonyatosan ki van számolva a bootloader szóval ez nem megvalósítható. Főként azért is mert, ha ezt így megírom és véletlen a felhasználó véletlen rosszul, vagy nem megfelelően indítja a bootloadert, akkor azonnal beletöröl ezzel kinyírja saját magát. Főleg akkor, ha p. nincs meg neki a program hex fájlban... Szép lenne  Akkor a bootloadert ki húzom a listáról... Köszi..
A 18F2550 / 18F4550 -ben 8k-t véd a boot protect konfigurációs bit. A PICkit2 USB boot loader -e nem tesz ki 4k -t sem.
Ezért vannak a megszakítások...hogy ne mindent a főprogram végezzen...
Minden fontosabb dolgot a megszakításokban kell elintézni (vagy csak egy flag-et beállítani LCD esetén).
Nem jól állsz a dologhoz. A megszakítás lényege, hogy a főprogram dolgozhasson, ne fecsérelje az idejét olyan alantas dolgokra, mint egy periféria kiszolgálása. A megszakítás a lehető legkevesebb ideig tartson, a főprogram pedig csak akkor várjon egy eseményre, ha nagyon muszáj. A megszakítás pedig csak akkor indulhat el, ha minden erőforrás rendelkezésére áll.
A hozzászólás módosítva: Okt 28, 2014
Idézet: „A 18F2550 / 18F4550 -ben 8k-t véd a boot protect konfigurációs bit.” Az adatlap szerint CONFIG5H CPB bitje (Boot Block Code Protection bit) a 000000-0007FFh Boot block-ot védi. Ez szerintem nem 8k, hanem 2k, amibe csak az MCHPUSB bootloader fér bele. A HID bootloader viszon kétszer ekkora (a 4k-ba csak az -O1-nél magasabb szintű optimalizálással fér bele).
A Diolan már évekkel ezelőtt közzétett egy nyíltforrású USB HID bootloadert ami állítólag mindenféle védelmet biztosít (pl. a felhasználóknak kiadott firmware letöltése XTEA titkostással folyik, ami a visszafordítás ellen is véd). Ha érdekel, nézd meg itt: Diolan USB PIC bootloader
Már meg se haragudj, de tudom, hogy mit beszélek (nem kis programokat írtam eddig, többek között egy saját fejlesztésű 100MHz-es USB-s oszcilloszkópot is) és tudom, hogy miből áll egy megszakítás lekezelése (hogy a lehető legröbidebb kell legyen, stb.) ezért is írtam azt amit írtam, csak lehet kicsit férreérthetőre sikeredett mivel sihettem és nem volt időm regényeket írni. Ezért elnézést is kérek, és ezentúl nem szólok hozzá semmihez, csak gyorsan végiggörgetem a kommenteket...
Mivel az USB boot loader hosszabb, mint 2k, a CP0 területét is beleértettem a tartományba...
Egyébként a PICkit2 HID boot loader most hajszálra 3k, de lehetne még kivenni belőle...
Még nincs teljesen befejezve, és sajnos egyéb okok miatt félbemaradt a fejlesztés, de amint lesz időm megint vele foglalkozni meg fogom majd osztani veletek
Én is tudom, mit beszélek. Kicsivel több, mint negyven éves a programozó diplomám.
Nem vitattam érdemeidet, ha úgy érzed, sajnálom. Mindössze az általad leírtaktól némileg eltérő szemléletről tettem említést.
simpi: Rendben, az ADC egy MAX1198-as
 nedudgi: Értem, sajnálom, hogy kicsit túlreagáltam a dolgot, de nem szeretném tovább vitatni, mert ez már nagyon OFF
Köszönöm, igazából próbáltam egy pár másik nyílt forrású USB bootloadert, de azok meg nem akartak menni win7ttel.
Nézegetem az oldalt, de itt le lehet tölteni a bootloader forrást? Win programot megtaláltam, de a forrást nem és ahogyan látom 2009-es dolog és azokkal próbálkoztam előtte, de a win7-el nem ment.. Idézet: „CP0 területét is beleértettem a tartományba...” Igen, úgy stimmel. Idézet: Szerintem egy csomagban letöltődik minden. Én sohasem foglalkoztam vele, de gondolom, a kibontott ZIP-ben az fw mappa a firmware forráskódját rejti (ASM!), az fw_update pedig a PC program forráskódját. Kicsit igazítani kell rajta, mert "gyárilag" PIC18F4455-hez van konfigurálva. „Nézegetem az oldalt, de itt le lehet tölteni a bootloader forrást?”
Következő a feladat:
A PIC egyik lábán ki kell adjon egy kb. 8 KHz frekvenciájú 50% kitöltési tényezőjű négyszöjelet. Ehhez képest a másik lábán nyomógombokkal +- irányban változtatható késéssel szintén ugyanolyan négyszöget és a 3. lábán is. A 2. és a 3. lábon lévő négyszögek fáziskülönbsége a referenciához képest külön állítható kell legyen. Az sem baj, ha a fáziseltérések egy kijelzőn megjelennek. Hogyan a legegyszerűbb ezt megvalósítani ? |
Bejelentkezés
Hirdetés |
