Re: defektní PIC16F18015

Pondělí Duben 1 19:13:59 CEST 2024

Tak to jsem z toho jelen. Vzal jsem nový procesor a chová se stejně.
V příloze je obrázek z analyzátoru.
pochopitelně když program krokuji, tak se chová normálně. Nic takového, 
že by přerušení skočilo někam jinam a běžel kus jiného programu.

Dne 01.04.2024 v 17:22 Jindrich Fucik napsal(a):
> To není můj případ, start přerušení trvá tuším 3 instrukční cykly, 
> procesor jede 8MHz, takže 1,5μs nebo tak něco. Program je velmi 
> primitivní, je napsaný v assembleru, abych vyloučil nějakou botu z jazyka.
> Nakopíruji sem podstatnou část programu. Nepodstatná nastavuje config: 
> vypnutý watchdog, interní oscilátor 8MHz a tak.
> 
> Program nedělá nic, než že v mainu bliká jedním výstupem a v přerušení 
> druhým. přerušení je od časovače (v příkladu Timer 0, ale stejně se 
> chová i Timer 2) a je nastaveno na 60 μs.
> 
> Na analyzátoru je pak velice zřetelné, že proběhne 25 bliknutí RA1, pak 
> je těch 350μs mezera a pak jedno bliknutí RA0 a pak hned zase 25x RA1 
> (jasně, ten kód není optimální, je to poslední troska, než jsem to 
> zabalil). Podstatné je, že ta díra je větší, než vlastní běh, takže je 
> to velmi zřetelné a nemá cenu zjišťovat, jestli je něco ± jednotky 
> instrukčních cyklů. Zábavné je, že stejný čas dostanu i při přepnutí 
> rychlosti procesoru na 4MHz (tedy díra je asi 350μs, běh se 2x prodlouží).
> 
> -------
> 
> ; Timer0 management        ; used for software serial Tx time ticks - 60 
> micro sec per tick
> T0CON1_INI    equ 0x51    ; T0CS FOSC/4; T0CKPS 1:2; T0ASYNC 
> not_synchronised;
> T0CON0_INI    equ 0x80    ; T0OUTPS 1:1; T0EN enabled; T016BIT 8-bit;
> TMR0H_INI    equ 0x3B    ; in 8 bit mode the TMR0H is compared same as 
> timer2 0x3B = 59 = LN baud rate
> 
> PIE0_INI    equ 0x20    ; Enable TMR0 interrupt.
> PIE1_INI    equ 0x00    ; none used
> PIE2_INI    equ 0x00    ; none used
> PIE3_INI    equ 0x00    ; none used
> PIE4_INI    equ 0x00    ; none used
> 
> INTC_INI    equ 0xC0    ; GIE enable, PIE enable
> 
> 
> PSECT resetVec,class=CODE,delta=2,abs
> resetVec:
> PowerUp:
> 
>      clrf    INTCON            ; Disable all interrupts
>      clrf    PCLATH            ; Tables on page 0
>      ;clrf    STATUS            ; reset flags
>      goto    START
> 
> PSECT isrVec,class=CODE,delta=2
> isr:
> Interrupt:
> 
>      movlb    0            ; BANK 0
>      bsf LATA,0
>      nop
>      bcf LATA,0
>      nop
>      bsf LATA,0
>      BANKSEL        PIR4    ; BANK 14
>      bcf TMR0IF    ; clear timer overflow
>      retfie
> 
> START:
> (...tady je miliarda přiřazení *_INI do správných registrů ...)
> 
>      movlw    INTC_INI            ; GIE enable, PEIE enable
>      movwf    INTCON
> 
>      movlb    0            ; BANK 0
> 
> testloop:
>      bsf LATA,1
>      nop
>      bcf LATA,1
>      goto testloop
> 
> 
> Dne 01.04.2024 v 13:46 Miroslav Draxal napsal(a):
>> Dobrý den,
>> Pozor na to, PICi si při přerušení ukládají registry soft, ne hw. 
>> Kolikrát ta obsluha toho uložení registrů je docela časově náročná.
>> Standardně se ukládá
>> STATUS
>> WREG
>> BSR
>> Pokud se někde v používájí FSRx registry, a v přerušení Se používají 
>> také, potom se i ty ukládají
>> FSR1
>> FSR1H
>> FSR2
>> FSR2H
>>
>> A můžou se ukládat i další. Při ukončení přerušení se zase registry 
>> obnovují. Tudíž je tam nějaká režie a prodleva, než se přerušení 
>> dostane na příslušnou obsluhu. Takže pokud by docházelo k velmi 
>> častému přerušení, může se i občas nějaké ztratit.
>>
>> A ještě jedna věc, na kterou se zapomíná.
>> Novější procesory umí ukládat STATUS, WREG, BSR v režimu FAST. Nebudu 
>> vypisovat podrobnosti, nakoukněte do *-.pdf konkrétního PICu, jestli 
>> umí. Ovšem pozor, pokud odlaďujete program třeba s ICDx, potom tyto 
>> FAST rutiny využívá ICDx. Pokud pak natvrdo pustíte program v samotném 
>> PICu, tyto rutiny většinou potom používá přerušení s vysokou 
>> prioritou. Takže časování je následně o něco rychlejší než při ladění 
>> HW prostředky.
>>
>> Nahoďte při jaké příležitosti se seká, jestli je to při periodickém 
>> přerušení (např. od TMRx), nebo něčeho externího. Třeba nás něco napadne.
>>
>> Míra
>>
>> -----Original Message-----
>> From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of 
>> Jindrich Fucik
>> Sent: Monday, April 1, 2024 12:09 PM
>> To: HW-news
>> Subject: defektní PIC16F18015
>>
>> Ahoj,
>>
>> občas si tu někdo hraje s těmito typy procesorů. Narazil jsem na jeden
>> defektní kus. Bohužel to byl ten, kterej jsem si odvezl na velikonoce a
>> nemám tu náhradu.
>> Projevuje se tak, že při vyvolání přerušení se procesor na cca 350 μs
>> zasekne. jak to tak bývá, tak mi trvalo dva dny zjistit, co se děje a
>> proč se nemohu dopočítat času nějaké události.
>>
>> Tak třeba se někomu tato informace bude hodit. Nebo možná někdo ví o
>> něčem, co jsem špatně nastavil a může mi to říci.
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
A non-text attachment was scrubbed...
Name: zaznam_kodu.png
Type: image/png
Size: 10992 bytes
Desc: [žádný popis není k dispozici]
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20240401/8d54d761/attachment-0001.png>