Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Helló!
Ezt szeretném leírni C18-ban, csak nem tudom, pontosan hogyan kell: #if AppConfig.pingip.Val = 0.0.0.0 ICMPSendPing(AppConfig.MyGateway.Val); #else ICMPSendPing(AppConfig.pingip.Val); #endif Valaki segítene?
A C18 tulajdonkepp ANSI C szintaktikaval es tulajdonsagokkal rendelkezik, tehat C nyelven kell csak ezt megfogalmaznod. Az IP cimeket tipikusan 32 bites szamkent (long) szoktak leirni, de nem tudom Te hogyan tarolod pillanatnyilag. Ha long-ban van akkor csak egy sima C szerinti osszehasonlitas... A fuggveny hivas igy ahogy leirtad fog menni, feltetelezve, hogy a struktura definicio helyes.
Jogos megállapítás, félreérthetően írtam, szóval alaphelyzetben programozás után az eeprom adatok FF-et tartalmaznak , és a kódom úgy néz ki hogy egy bizonyos kalibrálás után ezt az adatot átírja akármire. 0x00tól 0xFE -ig bármire , és az if fv-el csak azt nézem hogy még mindig 0xFF -et tartalmaz vagy sem. Igazából ez volt a problémám hogy miután megtörtént a kalibrálás és újraindult a főprogram akkor is FF-nek olvasta azt a szektort és így újra csinált egy mem_def hívást, amivel elvesztettem a kalibrálási beállításaim. Viszont írtam azt is hogy más módon megoldottam ezt a vizsgálatot szóval a problémám lényegében semmisnek vehető csak hogy tanuljak is valamit gondoltam rákérdezek hogy hibás lehetett e az a kis kódrészlet, ugyanis sehol máshol nem hívom a mem_def fv-t. Azért köszönöm a segítségeket
Amugy az eeprom fv-eim ilyenek : void ee_iras(unsigned char data,unsigned char address) { EEDATA = data; EEADR = address; // start write sequence as described in datasheet, page 91 EECON1bits.EEPGD = 0; EECON1bits.CFGS = 0; EECON1bits.WREN = 1; // enable writes to data EEPROM INTCONbits.GIE = 0; // disable interrupts EECON2 = 0x55; EECON2 = 0x0AA; EECON1bits.WR = 1; // start writing while(EECON1bits.WR){ _asm nop _endasm;} if(EECON1bits.WRERR) EECON1bits.WREN = 0; INTCONbits.GIE = 1; // enable interrupts } char ee_olv(unsigned char address) { char data; EEADR = address; EECON1bits.CFGS = 0; EECON1bits.EEPGD = 0; EECON1bits.RD = 1; data = EEDATA; return(data); } Adatlap szerintiek és működnek is szóval nem gondoltam hogy abban lenne a hiba. a mem_def pedig csak beír bizonyos címekre alapértékeket.
Szia!
- A WREN bitet nem csak akkor kellene törölni, ha hibára fut az eeprom írása... - Tiszteségesebb lenne a GIE - GIEH, PEIE - GIEL bitek értékét a 0-ba állítás előtt elmenteni, az írás végén a mentett értékeket visszaállítani. Előfordulhat, hogy az említett bitek közül valamelyik már 0-ra van állítva (valamilyen más okból), amikor az eeprom írását hívja a program. A feltöltött megoldás hibás működésre vezet, mivel a kilépéskor visszaállítja a megszakítás engedélyezését, pedig a tiltásra a hivó rutinnak még szüksége lenne. - Ha prioritásos megszakításkezelést használsz, a GIEH és a GIEL biteket is 0 -ra kell állítani az írás előtti szekvencia megkezdése előtt.
Bocs,
Azt elfelejtettem említeni, hogy a 7. bitet átállítom egyesre, és visszaolvasva eggyesen is marad, csak nem kezdd el az IC számolni...
A HLVD modulnál a HLVDCON regiszter IRVST nevű bitje mire való?
Az adatlap szerint azt jelzi, hogy a belső referencia beállt-e már. A HLDEN bit bebillentése után eltart egy ideig, amíg a bekapcsolt áramkör stabilizálódik. Ezalatt az IRVST bit nulla, és a HLDEN egység nem generál interruptot.
Köszönöm a választ!
Elvileg megírtam hogy a tápfesz megszűnésekor keletkezzen megszakítás és abban elmentek négy bájtot az EEPROM-ba. Vagyis el szeretnék menteni, de nem mentődik. :no: A probléma az, hogy ezt nem igazán tudom debuggolni hogy mi a hiba, történik-e megszakítás és ha igen akkor ott tényleg az történik-e amit szeretnék. Nincs rá valami ötletetek hogy hogyan lehetne ezt kideríteni?
Nincs elég idő elmenteni. Tegyél nagyobb kondit, vagy akkut, elemet...
Itt van az én félig hardveres megoldásom:
Bővebben: Link Hátha ihletet ad a hibakereséshez.
Az, hogy tortenik-e megszakitas meg tudod nezni - kell egy masik aramkor (pl PIC-kel) ami erzekeli, hogy egy jel magasra valt, utana szamolja az eltelt idot, amig egy masik magasra nem valt, majd nezi ezek mikor valtanak alacsonyra. Namost az eredeti PIC-ed az elso jelet akkor teszik magasra mikor megszakitas bekovetkezik, a masodikat mikor vegeztel az eeprom irassal... Eltelt idobol kovetkeztetni lehet sokmindenre -- egyaltalan megtortenik-e... Mikor vegkepp kifigyott a kondibol az aram akkor alacsonyra valtanak a vezetekek, tehat azt is merheted utana meg mennyi ido maradt hatra (mekkora tartalekod van).
Magat az EEPROM irast es egyeb dolgokat normal tap mellett teszteld le normalis uton-modon ahogy eddig is szoktad. Azt a teszteleskor azonban vedd figyelembe, hogy az eeprom irasnak vannak elektronikai kovetelmenyei. Bizonyos tapfesz alatt nem tudod megcsinalni, noha a PIC meg megy. Ha nincsen DC-DC stepup convertered akkor az idozitest is ugy kell terezni, hogy az irasi folyamat meg ennek a kuszob szintnek az elerese elott meg kell tortennie. Ezt a szintet a masik PIC-kel szinten tudod figyeltetni a comparator segitsegevel es merni az idot... Kulso aramori elemeket aramkimaradas eseten erdemes lekapcsolni, hogy azok ne szippanthassak le a kondit. A masik, hogy azon is erdemes elfizolni, hogy nem erdemesebb-e egy gombelemet bele tenni, es csupan altatni a PIC-et (es lekapcsolni a kulso aramkori elemeket) mikor aramimaradas van. Igy 1-2 evet is ki tud huzni a PIC-ed...
Szia!
Túl sokat nem árultál el az áramkörről, így igazán érdemben nehéz segíteni. A Brown Out Reset mekkora feszültségküszöbre van állítva? Esetleg nem lehet, hogy előbb szólal meg a BOR, mint a Low Voltage Detection?
A Microchip 18f4550-be való bootloaderét szeretném használni. Addig működik a dolog, hogy a gép felismeri a picet (a windows7 saját HID drivert tesz fel, a microchipét nem szereti), a PC oldali szoftver a próba.hex-et beégeti, kijelenti hogy a verify is rendben van. Nyomok egy resetet a pic-nek ("hardveresen", a próbapanelen -tehát kilépek a bootloader módból), de a beégetett program nem fut. A program egy sima ledvillogtatás; új config biteket a beégetendő kódban nem állítottam be, és a meglévők átírását nem engedélyeztem. 48MHz órajelet állítottam be, tudtommal ez adott.
Hol lehet a hiba? Ha egyszer kiírja, hogy bégette azt amit kértem, gondolom nem a driver a gond, hanem a programom beállításai.
Szerintem a bootloader rendben van, hiszen a gépet felismeri, sőt még a proba.hex-et is feltölti.
Szerintem a proba.hex-el van a hiba. Azt tudni kell, hogy a configok a bootloaderben vannak eltárolva. Esetleg a proba.hex nem jó linker scriptel lett fordítva és nem jó memória címtől indul a program.
A Brown Out Reset nem tudom mire van állítva, igazából azt se tudom mi az (de mindjárt utánaolvasok). A HLVD modult viszont így állítottam be:
A megszakítás kezelése pedig így néz ki:
Megmértem debuggerben, 16ms kell a megszakítás-vektorra ugrástól az utolsó bájt elmentéséig. Azzal hogy a HLVDCON regiszter HLVDL3:HLVDL0 bitjeit 1110-ra állítottam be, elvileg tipikusan 4,59V-nál kell a HLVD modulnak megszakítást generálnia. A PIC pedig ha jól olvastam 4,2V-ig hajlandó működni. Tehát a 16ms alatt maximum 0,39V-ot csökkenhet a tápfeszültség. A PIC-en 100µF-os kondi van, a terhelés pedig nem tudom mennyi, de a 4x20-as LCD háttárvilágításának áramához a többi elenyésző. Lehet be kellene tennem egy schottky diófát a PIC tápja elé. Idézet: Az alkalmazás eredményes futtatásához gondoskodni kell róla, hogy az első 4096 bájt üresen maradjon, s a RESET és az interrupt vektorok az 0x1000, 0x1008, 0x1018 címekre kerüljenek.„A Microchip 18f4550-be való bootloaderét szeretném használni.” Az egyszerű LED villogtató program nem használ interruptot, pl. így írhatod:
Arról is gondoskodni kel, hogy olyan linker scriptet (.lkr állomány) használj, ami az első 4096 bájtot védettnek nyilvánítja. Egyébént nagyon ajánlom a PICCOLO projekt szoftver segédletében közzétett bootloader és linker script használatát. A bootloader abban különbözik a gyáritól, hogy optimalizáltam a CONFIG bitek beállítását (pl. Brown Out Reset engedélyezése). Amíg a gyárit használtam, előfordult, hogy a PIC "elfelejtette" a bootloadert... A linker script és a piccolo_all.h állományok pedig megoldják a RESET és az interrupt vektorok, valamint az alkalmazói program elhelyezésének gondjait.
Nem lehetne ezt a 300 ezer db-os csillagos elválasztást mellőzni, már 500-adszorra tolja szét a topikot ez a jelenség.
Bocsi, erre nem is gondoltam. :hide:
Elég problémás a dolog szerintem. 10 mA-es terhelést feltételezve "worst case" becslésem szerint 4 ms elteltével már 4,2V alatt van a táp 100 µF mellett. Próbaképpen tegyél be 1000 µF-t, így kb. 40 ms idő lesz az írásra. Egyébként 4 ms alatt csak valószínű, hogy megír egy byte- ot, de inkább 5 ms-t szokás ráhagyni. Egyébként ennél a megoldásnál (közvetlenül Vcc-t mérve) egy sokkal jobb lehetőség, ha a fesz stab IC előtti puffer kondenzátor feszültségét mérjük meg. Feszültség osztó + Zener (biztonság kedvéért) + parallel kondi (Zener feléledési ideje miatt) és a már leosztott feszültséget mérjük a HLVDIN bemenet segítségével (Hasonlóan oldottam már meg táp kimaradás figyelését, bár az 8051 alapú kontroller volt, nem PIC). Ez azért előnyösebb, mert már akkor tudunk a feszültség kimaradásról, amikor a stabilizátor még bőven leadja névleges feszültségét. Ezt persze nem kötelező megfogadni, csak egy lehetőség. A másik, amit még szokás intézni ilyen esetben, hogy a nagyobb fogyasztású, a működés szempontjából nem létfontosságú egységek (pl. LCD) tápját lekapcsoljuk.
Mivel hardverileg is problémás a dolog, ezért a kódodat nem nagyon elemeztem. Brown Out Reset: Egy olyan reset lehetősége a mikrovezérlőnek, hogy ha a beállított küszöb alatt van a vezérlő tápfeszültsége, akkor resetben tartja a mikrokontrollert. Alapesetben ez 2 V körül van megadva, ha nem babráltad, akkor ez az alapértelmezett.
A CCS fordítónak ez nem tetszik, gondolom a gyári C18-ra van. A CCS fórumán van pár .lkr meg .h, ami megoldást ígért (pl ez), de azokkal sem működött. Bár így, hogy egy komplett leírás épül a C18 fordítóra, többre megyek vele ha az USB tiszteletére felkerül az is a gépre...
Helló. Egy PIC az adatot csak a megadott Rx lábon tudja fogadni nem? Van egy PIC-em, amin az Rx láb, nem működik..
Tudja másikon is, csak akkor szoftverből kell megoldani a dolgot. A hardveres soros port az csak az RX lábon tud fogadni.
Sziasztok,nemrég megépítettem a Topi által tervezett JDM programozót(Nulláról a robotokig) és bele akartam égetni az elektronikus dobókocka kódját a PIC12F629-be,de amikor beégettem volna mindig hibát írt ki amikor leellenőrizte a dolgokat,majd ezután kivettem az ellenőrzést az írás után és sikerült beégetni,de amikor elindítottam volna nem csinált semmit.
Tehát most abban szeretném a segítségeteket kérni ,hogy nem tudom mi lehet a hiba. Ami szerintem OK: -az IC,mert miután beégettem a dolgot,visszatudtam olvasni -szerintem a programozó is,mert kitudtam olvasni az adatot az IC-ből meg bele is írni Kérlek segítsetek! (programozáshoz az ICprogot használtam) Idézet: Természetesen C18-hoz való, amit írtam. Érdemes azt használni. „A CCS fordítónak ez nem tetszik, gondolom a gyári C18-ra van.”
Sziasztok. Most ismerkedem, ismerkednék a pic rejtelmeivel. Van egy pic16f87xx fedőnevű próbapanelem lcd-vel, mindennel, és 18f452-vel a foglalatban. A cd-n található 18f-hez való próbafájlokat (.asm) beviszem az mp-labba, és fordításkor mindent hibának ír ki. Kivéve a kommentbe rakott sorokat A bootloader rajta a picen. Miért van? Köszi a segítséget. Itt egy .asm ha segít.
Szia!
A programban van egy sor, ami a BEALLIT.INC állományt keresi...
Abban kellene lennie a kontroller típus megadásának...
Azt is hozzáadtam, és a p18f452-t is. Rámentem a projekt/make-re, és build failed egy rakás hibaüzenettel minden sorra hivatkozva. Most próbálkozom a panellel, és a pic-el. Azt mondták egy dologra vigyázzak, hogy benne legyen az, hogy org space 0x200. Hogy a bootloader megmaradjon.
Idézet: Az nem ér semmit! Include-dal kell becsatolni és az elérési útvonalakat beállítani/megadni.„Azt is hozzáadtam, és a p18f452-t is.” Nem lehetne elsőnek valamivel kevesebbet markolni? |
Bejelentkezés
Hirdetés |