www.elektronik.si

[Highlag]

Torej pri testiranju kontolerja obratov ventilatorja sem po 200h delovanja naletel na eno čudno zadevo, kateri zaenkrat še nisem prišel do dna.

Torej imam en poseben ventilator, ki sprejema komando za regulacijo obratov kar z enosmerno napetostjo. 10V = maksimalni obrati 1V = minimalni obrati.
Ker ne rabim ravno linearne regulacije obratov sem sestavil vezje, ki s pomočjo procesorja in LM317 regulatorja nastavlja željeno napetost.

Zadeva dela po pričakovanjih, le pri trajnostnem testu sem opazil, da kdaj pa kdaj -> tole je "radndom" ventilatorju obrati padejo za kako sekundo.

Zato sem vezje opremil z množico testnih točk, s pomočjo katerih sem v končni fazi ugotovil, da težava izvira ravno od vezja za regulacijo obratov. Dlje pa nisem uspel priti. Merjenje izhodov na procesorju mi ni dalo takšnih zaključkov, kot bi hotel. Pravzaprav mi v dveh dnevih testiranja ni uspelo izmeriti niti ene napake na izhodih procesorja, kar me sploh bega, ker sem napako pričakoval. Napaka bi namreč kazala na napako v programu.

Me pa v zvezi s tem vezjem zanima ravno če lahko način s katerim vklapljam posamezne izhode procesorja vpliva na delovanje priloženega vezja.

Koda:

BSF PORTB, 0
BSF PORTB, 1
BSF PORTB, 2
BCF PORTB, 4


Program se vrne na to mesto približno na vsako sekundo in nanovo nastavi vrednosti.

Kakšna napaka zaradi napajanja mislim, da ni, ker ostale stvari, ki jih procesor dela (prikaz delovanja z LED-diodami) deluje neprekinjeno.

Kakšna divja ideja?

[Silvo]

Uporabljaš prekinitve ? Uporablljaš WDT ? Lahko pripneš kodo?

[Highlag]

Prekinitev ne uporabljam, prav tako ne WDT-ja.

Tole imam za konfiguracijo:

__CONFIG _CP_ON & _WDT_OFF & _PWRTE_ON & _XT_OSC


Kode same nebi rad pripenjal, ker jo je preveliko (530vrstic + ) , razlaganje delovanja bi bilo verjetno tudi predolgo. Bom jutri zadevo ponovno poizkusil zagnati preko MP-labovega simulatorja, če bo kaj ven padlo.

Mogoče še tole. Prekinitev še ne razumem točno (nisem še poizkusil napisati programa pa se nisem poglabljal v detajle). Pa me zanima še tole. Procesor 16F84A ima na RA4 detekcijo zunanje prekinitve. Ta pin v sedanji verziji ni vezan nikamor, je pa definiran kot izhodni. Je možno da pobera iz kje kakšno stvar in vpliva na delovanje??

[Silvo]

Torej, če prekinitev nisi vključeval GIE bit INTCON registra je nizek (sicer je po resetu to prevzeta vrednost ) potem so vse prekinitve izključene.
Še popravek pin RA4/T0CKI je vhod za TMR0 z zunanjim virom clock-a. Zunanjo prekinitev pa lahko izvedeno na RB0/INT. Torej, če so prekinitve izključene potem se prekinitev na pinu RB0/INT ne more izvesti. Zakaj sem omenil prekiniev. Do neke napake, ki se pojavi vsakih "100 let" lahko pride zaradi tega, ker se pred prekinitvijo niso shranile vrednosti STATUS registra ter se po vrnitvi iz prekinitve niso vrnile.
Kratka softwerska razlaga:

[Highlag]

Hvala za popravek Se moram še veliko naučit.

Pa je možno, da nekako pride do interupta kljub temu, da so vsi PORTB biti definirani kot izhodni? Ali je to potrebno posebej definirati recimo z:

BSF STATUS, RP0
BCF INTCON, GIE

Ker prekinitve nimam nikjer eksplicitno izklopljene (razen pri pisanju v eeprom)

[Silvo]

[micabauc]

kaj pa temperaturna zaščita lm-a? Mogoče ti pa ta izklaplja?

[Silvo]

[Highlag]

Ja temperatura. Breme je 1Kohm upor + ventilator za katerega sem izmeril tok porabe 1,5mA. Upor sem moral dodati, da je regulator sploh delal pravilno. Regulator je mali 100mA v TO92 ohišju (mislim) In računsko ustreza.


V soboto sem še testiral program V MP-lab-u, kjer pa nisem našel napake. Oziroma se ni pokazala.

Danes sem ponovno izvajal meritve in kaj sem ugotovil? Do napake prihaja vsako uro. In moj procesor vsako uro shranjuje vrednost v svoj eeprom. Drugega kaj posebnega se v programu ne dogaja vsaj ne vsako uro. Zakaj bi se karkoli zgodilo ob vpisu v eeprom mi ni jasno. Mogoče sem spet kaj pozabil prebrat?
Se poraba drastično poveča? Napajalna napetost procesorja je ena izmed stvari, kateri sem na začetku testiranja posvetil največ pozornosti. in jo tudi izključil.

Izmeril sem, da se ob "motnji" vsaj izhod RB1, ki je bil v tistem trenutku 1 postavi na 0 zakaj mi ni jasno. Izhodi se namreč nastavijo v programu le na enem mestu.

Tako da jutri pričenem najprej z testiranjem, le da bo PIC shranjeval vrednost vsakih 15 minut. Nadaljeval bom z Picem, ki sploh ne shranjuje v eeprom. To mi bo menda dalo nedvoumno informacijo ali je vpis v eeprom kriv ali ne.

[Highlag]

Ne tem vezju bom izgleda diplomiral.

Torej preizkusil sem dva vezja in 3 PIC-e.

Torej najprej sem zmanjšal čas vpisovanja v eeprom na 15 minut in seveda se je motnja pojavila na 15 minut. Moram sicer preverit če sem slučajno pri progamiranju tretjega PIC-a kaj zamočil, samo trenutno kaže, da tudi če rutino za vpis v EEprom vržem ven se motnja še vedno pojavi.

Jutri bom upam imel več časa za testiranje na strojni opremi, ker mi MPLAB program poganja že od včeraj popoldne brez napake. Ali slučajno obstaja še kakšen način kako ujet spremembo na portu v MPLAB-u? Sedaj vidim, če se zgodi sprememba s tem, ko simulacijo animiram. Če se vrednost registra spremeni se le ta obarva rdeče in je spremembe lahko odkriti.

Nadalje imam vprašanje o bremenih priključenih na PIC-a. PORTB je pri meni izhodni. Na vse nogice PORTB imam priključene tranzistorje na bazo preko 1K upora.
Tranzistorji so BC547B, emitorji vezani na maso (0V) delujejo kot stikala. (vključujejo LED diode in podobno).

So 1K omski upori premajhni?

[Silvo]

Brez, da ne vidim kodo ti ne morem pomagat. V koliko si ugotovil, da nastane težava pri vpisu v eeprom išči napako tam okrog. Preveri, če slučajno na rutino ne hodiš z GOTO potem pa se želiš vrniti z RETURN Če sumiš, da se vpis konča po nepravi poti program tik pred zakključkom zazankaj boš videl, če pride sploh do tam. Na simulatorju je sploh težko odkriti napako kot sem jo napisal zgoraj. Skok na neko rutino z GOTO rutina pa je zaključena z RETURN misleč, da se boš vrnil od tam kjer si prišel z GOTO v resnici pa te RETURN pošlje nekam... žal prevajalnik take "cvetke" prežveči.

[Silvo]

Na hitro sem preletel poslano kodo. En očitni "hrošček", ki bi lahko povzročal nevšečnost tiči na 365 vrstici kjer izvedeš vpis v EEPROM

[Highlag]

Ja priznam tole napako!

Če se prav spomnil sem na tem mestu tisto čakanje spustil zanalašč, ker sem si mislil, da sledi 1s pavza. Samo verjetno zadeva ni enaka kot čakanje na setiranje enega bita registra? Pa še sem program skoči vsakih 255 ur.

Vsekakor pa bom zadevo popravil.

[Silvo]

Program sem le bežno pregledal. Tisto mi je padlo v oči. Si bom čez vikend vzel več časa. Taka "napaka" lahko povzroči napačen vpis v eeprom, če sledi vpis drug za drugim.
Glede samega programa. Res si ga precej razvlekel z GOTO skoki. Cel probram bi postal preglednejši, če bi določeno kodo , ki se ponavljaja strnil v proceduro ter jo klical z CALL. Tipičen primer za to je vpis v EEPROM

Koda iz tvojega progama:

[Highlag]

Kaj naj rečem Silvo. Zadel si žebljico na glavo.

Rutino za vpisovanje v EEprom sem popravil po tvojem nasvetu in po detaljnem pregledu Microchip-ove dokumentacije.

Sicer sem bil prepričan, da sem program stestiral tudi tako, da sem rutino za pisanje v EEprom vrgel ven iz programa, a očitno mi tega vendarle nisem storil. Očitno me je zmedlo preveliko število poizkusov in programiranih a premalo označenih PIC-ev, ki sem jih očitno zamešal med sabo. (Da ne omenjam motenj z strani sodelavcev)

Danes je minil že drugi dan testov. Prilagam slikico iz inštrumenta. Imam 2 pica (tokrat jasno označena!) Staro verzijo(spodaj) in Novo verzijo(zgoraj). Obema sem spremenil časovno konstanto tako, da je potek primerljiv. Imam dva vezja, v kateri sem vgradil PIC-a. Inštrument jasno pokaže, da ima spodnji neke "motnje".

Pica sem med seboj tudi že zamenjal, da sem izključil morebiten vliv elekronike.
Sledi še test na normalni časovni bazi.

Je pa zanimivo, da motnje, kot je razvidno ne nastopajo ves čas ampak le nekaj časa.

Simulator v MPLAB-u teh napak ne pokaže.