Chyby v MPLAB 8.02 - riesenie

Středa Srpen 13 10:28:09 CEST 2008

Vezmu to od konce:
Kapitola 18.2.1 Special Event Triggers are not implemented for ECCP3, CCP4 
or CCP5. Selecting the Special Event Trigger mode for these modules has the 
same effect as selecting the Compare with Software Interrupt mode 
(CCPxM3:CCPxM0 = 1010). No je to v PDFku pekne schovame - klasicka poznamka 
malym pismem.... Ja jsem ji nasel az po dlouhem hledani proc mi procesor 
dava 140ms a pritom v simulatoru MPLABU tam mam 100ms.

Timer 1 ma sice implementovane 16bit cteni, ale to jsem vypnul - T1CON bit 
7. Zajimave ze ¨v MPLABu 5.7 to funguje jak ma. Zpatky k verzi 8.02. Upravte 
program na:
 do {
  if ( 1 == TMR1IF ) {
   TMR1IF = 0;

//   TMR1ON = 0;
//   TMR1 = 32000;
//   TMR1ON = 1;

   ++PORTB;
  }
 } while (1);
Ted bude TMR1 krásne fungovat jak ma 0x0000 - 0xFFFF.

Znovu upravte program:
 do {
  if ( 1 == TMR1IF ) {
   TMR1IF = 0;

   TMR1ON = 0;
   TMR1 = 32000;
   TMR1ON = 1;

   ++PORTB;
  }
Ted bude delat TMR1 paseku - zobrazuje nesmyslne stavy.

Tak a naposledy:
 do {
  if ( 1 == TMR1IF ) {
   TMR1IF = 0;

//   TMR1ON = 0;
//   TMR1 = 32000;
//   TMR1ON = 1;

   ++PORTB;
  }
Timer kupodivu zase dela paseku i kdyz jsem resetnul "procesor" simulatoru.

AD prevodnik:
ADC-W0001: Tad time is less than 0.70us
ADC-W0008: No stimulus file attached to ADRESL for A/D.
Krystal jsem znova zkontroloval, je tam nastaveno 14.7456MHz. Zprava se 
vypise jen jednou po otevreni MPLABu. Nenapsal jste jestli souhlasite s mym 
vypoctem nebo ne.

Michal Gregor

----- Original Message ----- 
From: j s
To: HW-news
Sent: Wednesday, August 13, 2008 9:17 AM
Subject: Chyby v MPLAB 8.02 - riesenie

Takze, pozrel som sa na tie tri "chyby" v simulatore MPLAB-u. Namiesto
toho, aby som odpovedal strohou odpovedou "RTFM" a zacal Vas sekirovat
nutenim do studia bohatej zbierky dokumentov, ktore Microchip k svojim
nastrojom ponuka, ponizovat tym, ze je pomerne nevhodne prehlasovat
svoje chyby za chyby simulatora, vysvetlim Vam, co robite zle.

----------------------------------------------

Priklad 1 - "chyba" ohladom TMR1
Tu bude vysvetlenie najdlhsie. Ide o to, ze pokial TMR1 bezi, tak
sekvencne citanie registrov TMR1H a TMR1L by mohlo viest k nespravnym
vysledkom. Ak precitate TMR1L prave vo schvili ked preteka z 0xFFFF na
0x0000, tak dostanete v TMR1L hodnotu 0xFF, ak o niekolko instrukcii
neskor (lebo inak sa to neda) precitate TMR1H, mate hodnotu 0x00, teda
celkova hodnota TMR1 by bola chybna - 0x00FF namiesto 0xFFFF. To je
celkom prirodzene. Preto to Microchipaci urobili tak, ze TMR1H nie je
realny obraz TMR1, ale len bufferovana hodnota. TMR1L je realny obraz
dolneho bytu TMR1 a logika je taka, ze ked uzivatel precita TMR1L, v
presne tej istej chvili sa horny byte TMR1 nabufferuje do registra
TMR1H, takze ak si ho o niekolko instrukcii precita, tak ziska hodnotu
taku, ktora patri k TMR1L. Preto najprv citame TMR1L a potom TMR1H.
Pri zapise do timera je to naopak. Najprv zapiseme do buffera TMR1H,
potom zapiseme do TMR1L, cim sa zaroven zapise aj hodnota z buffera
TMR1H ako celistva 16-bitova hodnota.
A teraz, co z toho vyplyva. Ak si svoju simulaciu prejdete naozaj
pozorne, vsimnete si, ze hodnota timera1 sa nemi v hornom byte, ale
len v dolnom (TMR1L). Ta 256 krat pretecie z hodnoty 0xFF na 0x00 a
potom nastane prerusenie. Samozrejme vy ste si zrejme len dali
breakpoint na cas, ked je nastaveny TMR1IF flag a v tej chvili Vam
simulaor ukaze hodnotu taku, aka bola naposledy zapisana, nie skutocnu
hodnotu, pretoze TMR1H nebol PRECITANY, aby sa hodnota z timera1
nabufferovala do registra TMR1H. Takze bud to urobite tak, ze ich
hodnoty precitate takto

do {
if ( 1 == TM1IF ) {
TM1IF = 0;

TM1ON = 0;
testl = TMR1L;
testh = TMR1H;
TMR1H = 0x7D;
TMR1L = 0x00;
TM1ON = 1;

++PORTB;
}
} while (1);

a v premennych testl a testh su skutocne hodnoty timera1 v tej chvili,
ked sa cital TMR1L. Alebo, si dajte do Watch window virtualny register
(pre ucely simulacie) TMR1_Internal. Ten je obrazom skutocnej hodnoty
TMR1 a uvidite, ze pretecenie nastava pri hodnote 0xFFFF->0x0000.

----------------------------------------------

Priklad 2 - "chyba" okolo TMR3 a CCP4
Citujem:
"
// Dle PDFka CCP4 nenuluje časovače
// tak�e tady by měl mít TMR3 hodnotu 46085 (+/-)
// a pokračovat do hodnoty 0xFFFF
"
pricom

CCP4CON = 0x0B
T3CON = 0x71

Cize T3 je nastaveny ako zdroj pre CCP, CCP4 je v rezime  0x0B -> 1011
= Compare mode: trigger special event, reset timer, start A/D
conversion on CCPx match
V datasheete je jasne napisane, ze CCP4 v tomto rezime NULUJE citac.
Je to v datasheete PIC18F87J11 family, DS39778C, dostupneho na stranke
Microchipu, konkretne na strane 197. Neviem, z akeho "PDFka" mate
opacnu informaciu.

----------------------------------------------

Priklad 3 - chyba okolo Tad.

Ako mate nastavenu frekvenciu oscilatora v Debugger-Settings-Osc/Trace
- Processor frequency?
Ja ked si ju nastavim na 14,746MHz, ako predpokladate Vy, tak nevidim
nijaku hlasku o Tad, ked prejdem cez nastavenie AD. Samozrejme, ked je
frekvencia nastavena niekde mimo, tak simulator vidi nespravne
nastaveny Tad, a aj to reportuje - tak ako by aj na realnom kremiku by
Tad bol mimo pre takuto taktovaciu frekvenciu.

----------------------------------------------

Resume. Prosim, neurazte sa, ale su to pomerne dost zaciatocnicke
chyby. Pisem to bez snahy o Vase zosmiesnenie, ale ako realny fakt.
Kazdy raz zacinal, a prave v zaciatkoch je velmi vhodne, ak je clovek
pozorny a obozretny. Ak Vam nieco nefunguje, skuste sa najprv
zamysliet nad tym, co robite zle, bez toho aby ste s horucou hlavou
pisali zbytocne "kydanie" na Microchip a jeho support. Ja chapem, ze
pluvanie na Microchip je sucastou miestneho folkloru a clovek, ktory
nadava na PIC je potlapkavany komunitou po pleci, ale aj tu, ako vzdy
plati - dvakrat meraj a raz rez.

Amen ;-)
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list@list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list 