Nem az elektron nem ismeri a fizikát.
Mindig az emberben van a hiba.
Sajnos a CCS is az utasításaink szerint dolgozik, nem pedig a kívánságaink szerint.

Egyébként bizonyos körülmények esetén csak figyelmeztetés mellett engedi programozni a PIC-et az MPLAB.
Még ablakot is dob. Lehet, hogy letiltottad mert idegesített.
Pl. ha belső oszcillátor van kiválasztva és az MCLR le van tiltva, akkor csak saját felelősségedre engedi a programozást, mert nem vállalnak felelősséget arra, hogy minden sikerül.
Ilyenekre azért figyelni kell.

Próbálkozz valami másik platformmal vagy másik MCU gyártóval Azzal is lehet ám szenvedni igen sokat. Bárki bármit is mond.

Már többször írtam itt, hogy én már kipróbáltam több platformot és a CCS-nél kötöttem ki, mert elég barátságos és már elviselhető szintre szorították le a bugosságát. Lehet vele dolgozni.

Az MpLab 8.xx -ben a Configuration / Configuration bits ablakban van egy kiválasztási lehetőség: Configuration Bits set in code. Ha itt nincs pipa, akkor ebben az ablakban beállított értékekkel generálja a hex állományt.

Miért nem ismeri az MpLab a "Use vpp first programming entry" módszert?
Miért nem ismeri az MpLab a "Low voltage programming" módszert?
stb.
Pedig már elég sok év telet el azóta, hogy áttértek a 32 bites verzióra...
A PICKit2 saját programja biztosítja ezeket a lehetőségeket.

Megpróbáltam úgy is a config biteket hogy ne a forrás generálja hanem az itt kiválasztott tulajdonságok legyenek de akkor is hibásan generálja le a kódot....

Ezt szerintem az MPLAB-os fickók sem tudják.

Még az is lehet, hogy az MPLAB-ban nem az a processzor van kiválasztva, amit te szerettél volna, mert velem már megesett néhányszor. Szénné szívattam magam.
Az előző project által kiválasztott PIC volt az aktív.

Nézd meg fordítás után (ha hiba nélkül lefordult) az MPLAB: Configure > Configuration Bits menüjében mit akar beprogramozni a PIC-be.

Megnéztem jó pic van kiválasztva a pic típus. Érdekes fordítás után menüben átíródnak rosszra a beállítások. A Configuration bits set in code négyzetet nem pipálom be majd beállítom menükben a biteket fordítás után akkor is átíródnak a menü beállítások. Valamit a CCSC mahináll bele......

Még az is lehet, hogy Debug üzemmódban van Release helyett az MPLAB.
Sőt! Szinte biztos, mert ezt látom a programban:

#device ICD=TRUE

Ismét az emberi figyelmetlenségem.... Az áramköröm csinált még érdekességet elkezdett furán viselkedni lebegett egy bemenet hol magasra hol alacsonyra ugrott, ha a power up timert kikapcsolom minden stabil és jó lesz. Azt gondolom, hogy a zajos táp okozza a hibát. Szerintetek is lehet ez?

Bármi lehet, de nálam a PUT még soha nem okozott ilyesmit. Nem lehet, hogy az MCLR felhúzója szakadt vagy nem érintkezik?

A nyákot elbénáztam elég sok lett.... átírtam a programot hogy nincs mclr ellenállás belsőt használ.

Megint bebizonyosodott, hogy az elektronok tudják a fizikát.

16F628A MCLR lábát mindenképpen be kell kötni valahová, mert kikapcsolt MCLR mellett ugyan lefele húzással resetelni nem fog, de ha felfele mászik el a láb potenciálja valami okból, akkor belép programozás üzemmódba, ami szintén resetelésként fog megjelenni.

Köszönöm szépen lehet ettől instabil....

A CCS compilernér be lehet-e állítani valahol, hogy a hex fájl végére ne tegye be a megjegyzés sorokat ( PIC típusa, CRC, Dátum, idő)?

A másik kérdés, LCD kijelzőnél, hogyan lehet ékezetes karaktereket megjeleníteni?

Potyo köszönöm ez okozta az instabilitást, betettem egy ellenállást máris stabil lett. Még egyszer köszönöm szépen.

Ez engem érdekelne, hogyan gondolod ezt a mindenképpen való bekötést, amikor ki van kapcsolva a MCLR. Mert ilyenkor PORTA5 néven funkcionál a láb. Programozásba +9V MCLR feszültség környékén lép be a PIC. Ha belül össze van kötve a tápfesszel az MCLR láb, akkor ezen a tápfeszen szerintem meghal a PIC. Vagy valamit rosszul értelmeztem?

Rosszul. Belül nincs az MCLR összekötve a tápfeszültséggel, legalábbis nem egy szál drótként, mint azt sokan gondolják. A letiltott MCLR csak azt jelenti, hogy a kontrollert resetelő áramköri rész egyik bemenete le van választva a lábról, és fixen tápfeszültségre van kötve. De ettől még egy másik rész, nevezetesen a flash felprogramozásáért felelős rész továbbra is összekötve marad a lábbal, hiszen kikapcsolt MCLR mellett is újra lehet programozni a kontrollert. Ezért nem szabad a lábat szabadon hagyni, mert akkor antennaként összeszed mindenféle zajt a környezetből, panelen szivárgást a táp felől, stb., aminek hatására felmehet a potenciálja 9V fölé, majd le, és ez is úgy néz ki, mintha resetelne. Nem kell itt nagy áramokra gondolni, CMOS áramkörről lévén szó, szinte bármilyen alacsony áram is már gondot tud okozni, amit pl. ottmaradt forrasztószer, rászálló por is már elő tud idézni.

Mindenképpen be kell kötni, azt jelenti, hogy nem szabad lebegni hagyni. Ha digitális bemenetként használjuk, az már azt jelenti, hogy be van kötve, nem tud a potenciálja elmászni.

Vannak kivételek, pl. 12F683, amiben van az MCLR lábon belső felhúzó, ezen nyugodtan lebegni lehet hagyni az MCRL lábat, de CSAK akkor, ha az MCLR nincs kikapcsolva! Ugyanis ha az MCLR-t kikapcsoljuk, akkor azzal a felhúzót is kikapcsoljuk, és így ugyanott vagyunk, mint az első bekezdésben.

Ebben lehet valami, mert az MCLR lábon nincs felső clamp dióda a Vdd sínhez. Így nyugodtan be lehet nyomni az égető feszt(is). Logikus.
Megint tanultam valamit.

Pontos 10ms-os időzítést szeretnék csinálni timer1-el...


Ha jól számoltam akkor ennek elvileg pont annyinak kéne lennie, 8Mhz-es órajelnél.
A szimulátorral nézve viszont 45572-nél jön létre a megszakítás 10ms-onként.
Hol a hiba? A szimulátroban, vagy én nem vettem valamit figyelembe?

Amire a set_timer1(45536) sorra kerül a vezérlés, a timer1 már nem 0 -t tartalmaz. Az írás ezt az értéket nem veszi figyelembe.

Nekiugrottam másképp ...

Sajnos ez sem jó ... itt is több mint 10ms az idő!
Mi hát a korrekt megoldás?

Szia!
Ne beállítsd a számlálót, hanem annyit adj hozzá az aktuális számlálóállapothoz ( így figyelembe veszi a közben eltelt időt is!) !

Így gondoltad?


Sajnos még így is van eltérés. Gondolom azért mert a számolás közben is telik az idő.


És a Timer_2-es megoldásnál hol a hiba? Annak pontosnak kéne lennie! Vagy nem?

Van ám beépített demo is a programban:

A TIMER2-nek nincs 5-ös utóosztója.
Nem dobott hibát a fordító?

A simulatorban be van állítva a 8MHz órajel?
Mert alapértelmezés szerint 20MHz.

A setup... sort a Pic Wizard -al hoztam létre, azt másoltam be az MPLAB-ba és ott néztem a simulátorral... breakpoint létrehozása... stopwatch... és a stopper mutatja hogy nem annyi mint amennyinek lennie kéne.
A PIC egy 16F887-es, annál simán hagyja hogy ezt beállítsam!
Fordításkor nem kaptam hibaüzenetet.
Az eltérés mindössze néhány század ms.
A szinulátorban is jó frekvencia van beállítva.

vicsys hozzászólásához:
Én 4-es CCS-t használok, az nem ismeri a #use timer(...), sem a get_tick-et ...
Gondolom ez az 5-ben lehet ... (Arról meg azt olvastam valahol, hogy valami printf után gondok vannak a megszakításokkal, azért maradtam inkább a 4-nél)

Érdekes eszerint a program szerint van. Bővebben: Link. Akkor most ez a kalkulátor nem felel meg a valóságnak?