Re: Programowy reset AT89C2051



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Stanislaw Sidor" <sts_at_nospam_qq.elcompzu.com.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 10:59:05 +0200


On the news Olgierd Cybulski <dechamp_at_nospam_poczta.wp.pl> wrote:

Użytkownik Stanislaw :

Mam u siebie '32-ki Intela, ktore spokojnie to maja gdzies.
Przerwania od zegara wchodza jedna na drugie, gdy przerwanie to ma
programowo
ustawiony wysoki priorytet (PT0).

Zauwaz, ze mowilismy o kontrolerach AT89c2051.
Nie wiem, co to za 32-ki, ale nie wydaje mi sie, zeby to mialo
cos wspolnego z rodzina MCS-51. No chyba, ze "pewne podobienstwa".

Matko jedyna !!!
Przeciez '32 to po prostu '52 ('51 z RAM 256B) bez PROMu wewnatrz.

(STS)


Poprzedni Następny
Wiadomość
Spis treści
From: "Olgierd Cybulski" <dechamp_at_nospam_poczta.wp.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 11:40:18 +0200



Stanislaw Sidor <sts_at_nospam_qq.elcompzu.com.pl> w artykule news:8m8ntg$t13$1_at_nospam_news.onet.pl pisze...

Mam u siebie '32-ki Intela, ktore spokojnie to maja gdzies.
Przerwania od zegara wchodza jedna na drugie, gdy przerwanie to ma
programowo ustawiony wysoki priorytet (PT0).

Zauwaz, ze mowilismy o kontrolerach AT89c2051.
Nie wiem, co to za 32-ki, ale nie wydaje mi sie, zeby to mialo
cos wspolnego z rodzina MCS-51. No chyba, ze "pewne podobienstwa".

Matko jedyna !!!
Przeciez '32 to po prostu '52 ('51 z RAM 256B) bez PROMu wewnatrz.

A, to przepraszam, nie używałem, więc nie skojarzyłem.
Co się zaś tyczy meritum sprawy - trudno jest mi uwierzyć w to,
co piszesz. Stawiałbym raczej na jakiś nietrywialny błąd w kodzie.
Niby dlaczego Intel miałby złamać kompatybilność z wlasnym standardem ?
A może znów się nie rozumiemy ? Napisałbyś dokładniej, co rozumiesz
przez wchodzenie przerwań jedne na drugie. Czy chodzi o to, że
przy PT0=1 przerwanie timera T0 wchodzi "samo na siebie" ? Nie wierzę...

OC





Poprzedni Następny
Wiadomość
Spis treści
From: "Stanislaw Sidor" <sts_at_nospam_qq.elcompzu.com.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 12:51:45 +0200


On the news Olgierd Cybulski <dechamp_at_nospam_poczta.wp.pl> wrote:

Czy chodzi o to, że
przy PT0=1 przerwanie timera T0 wchodzi "samo na siebie" ? Nie wierzę...

W samej rzeczy :)
Wyczajenie tego faktu z miesiac mi kiedys zajelo, bo chodzacy program wywalal
sie srednio raz na tydzien przy bardzo niekorzystnym ukladzie zagospodarowania
stosu i nakladkowaniu przerwan (testowy kod ujawnil zjawisko o ktorym pisze).

Od tej pory zawsze(kiedy istnieje takie niebezpieczenstwo) robie wlasny
znacznik a przy wejsciu do przerwania opuszczam je jesli jest on ustawiony,
minimalizujac nakladkowanie.
Robie tak "na wszelki wypadek", choc byc moze byla to wadliwa seria procesorow
lub jakas "normalna inaczej".
Spotykalem tez procesory, ktore nie potrafily prawidlowo wykonac instrukcji
CPL P1.0 i CPL P1.1, Bog raczy wiedziec dlaczego.

(STS)


Poprzedni Następny
Wiadomość
Spis treści
From: "/\\_MS_/\\" <m__s_at_nospam_go2.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 13:15:08 +0200


W samej rzeczy :)
Wyczajenie tego faktu z miesiac mi kiedys zajelo, bo chodzacy program
wywalal
sie srednio raz na tydzien przy bardzo niekorzystnym ukladzie
zagospodarowania
stosu i nakladkowaniu przerwan (testowy kod ujawnil zjawisko o ktorym
pisze).
Jesli masz gdzies ten testowy kod
to poprosilbym
Uzywalem roznych klonow '51 i nigdy czegos
takiego nie widzialem
Czy robiles proby na kilku egzemplarzach ?

--
_ _
||\_/||
|| S || m__s_at_nospam_go2.pl









--
Wysoka jakość, niskie ceny - http://rubikon.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Olgierd Cybulski" <dechamp_at_nospam_poczta.wp.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 14:39:08 +0200



Stanislaw Sidor <sts_at_nospam_qq.elcompzu.com.pl> w artykule news:8m8ugn$2ob$1_at_nospam_news.onet.pl pisze...

Czy chodzi o to, że
przy PT0=1 przerwanie timera T0 wchodzi "samo na siebie" ? Nie wierzę...

W samej rzeczy :)
Wyczajenie tego faktu z miesiac mi kiedys zajelo, bo chodzacy program wywalal
sie srednio raz na tydzien przy bardzo niekorzystnym ukladzie zagospodarowania
stosu i nakladkowaniu przerwan (testowy kod ujawnil zjawisko o ktorym pisze).

A dlugi byl ten kod testowy ?
Moze przyslesz ?
Do ewidentnego potwierdzenia Twojej tezy wystarczyloby w zasadzie
parenascie linijek assemblera. Np. uruchomienie ponizszego programu
potwierdzi lub obali Twoje obawy - do testowania przyda sie oscyloskop
podpiety do P3.7 i do P1.1, jesli impulsy pojawia sie na P3.7 - racje
mam ja, jesli na P1.1 - racje masz Ty. Programik probuje zagniezdzic
przerwanie od T0 i wysyla kopie wskaznika stosu (SP) do portu P1, jesli
zagniezdzenie sie nie udaje, miga linia P3.7 . Napisalem go tak, zeby
dal sie uruchomic rowniez na malych Atmelkach.

ORG 00h
AJMP 100h

ORG 0Bh ;wejscie procedury obslugi przerwania timera T0
MOV A,SP ;umieszczenie w akumulatorze wskaznika stosu
MOV P1,A ;przepisanie wskaznika stosu do portu P1
;jesli wszystko jest OK, w P1 powinna byc wartosc SP=2
;jesli zas nastapilo n-krotne zagniezdzenie, to SP=2*n
SETB TF0 ;symulacja przerwania timera T0 (ustawienie znacznika)
NOP ; <- w tym momencie nastapi ewentualne zagniezdzenie
NOP
CPL P3.7 ; mrugniecie linia (jesli zagniezdzenie nie wystapi)
RETI

ORG 100h ;zadanie wartosci poczatkowych
MOV SP,#00h ;wyzerowanie wskaznika stosu
SETB PT0 ;ustawienie priorytetu przerwania timera T0
SETB ET0 ;odblokowanie przerwania timera T0
SETB EA ;odblokowanie systemu przerwan
SETB TF0 ;symulacja przerwania timera T0 (ustawienie znacznika)
loop:
AJMP loop ;nieskonczona petla


Moglem o czyms zapomniec przy czesci inicjujacej,
sama obsluga przerwania jest raczej dobrze napisana,
zauwaz, ze w ogole nie uzywam samego licznika T0, a
tylko symuluje jego przepelnienie ustawiajac znacznik
zgloszenia przerwania TF0.

Od tej pory zawsze(kiedy istnieje takie niebezpieczenstwo) robie wlasny
znacznik a przy wejsciu do przerwania opuszczam je jesli jest on ustawiony,
minimalizujac nakladkowanie.
Robie tak "na wszelki wypadek", choc byc moze byla to wadliwa seria procesorow
lub jakas "normalna inaczej".
Spotykalem tez procesory, ktore nie potrafily prawidlowo wykonac instrukcji
CPL P1.0 i CPL P1.1, Bog raczy wiedziec dlaczego.

A co to byly za procesory ?
W roznych mutacjach sa tam czesto podpiete jakies dodatki,
komparator analogowy, licznik T2 i nie wiem co jeszcze.
A moze masz wadliwy kompilator assemblera ? Sprawdzales
kod wynikowy ? Jest mozliwe, ze kompilator blokuje mozliwosc
bitowego adresowania P1.0 i P1.1 jesli sa one zdefiniowane
jako np. wejscia licznika T2 (nie wiem, to tylko moja
hipoteza probujaca wyjasnic to dziwactwo)

O.C.




Poprzedni Następny
Wiadomość
Spis treści
From: "Stanislaw Sidor" <sts_at_nospam_qq.elcompzu.com.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 15:28:34 +0200


On the news Olgierd Cybulski <dechamp_at_nospam_poczta.wp.pl> wrote:

A dlugi byl ten kod testowy ?
Moze przyslesz ?

Zbyt prosty, aby przysylac :)

Do ewidentnego potwierdzenia Twojej tezy wystarczyloby w zasadzie
parenascie linijek assemblera. Np. uruchomienie ponizszego programu
potwierdzi lub obali Twoje obawy - do testowania przyda sie oscyloskop
podpiety do P3.7 i do P1.1, jesli impulsy pojawia sie na P3.7 - racje
mam ja, jesli na P1.1 - racje masz Ty.

Tu nie chodzi o to, kto ma racje, tylko sygnalizuje wszem odkryty problem, aby
nie dziwili sie jak cos dziwnie dziala.


Moze inny kod testowy.
1. Ustawic automatyczne przerwania od T0 z prawie maksymalna predkoscia.
2. Ustawic priorytet PT0
3. Wyzerowac wlasna flage
....
CLR MY_FLG1
...

Proc. przerwania:

ORG 0BH
JNB MY_FLG1,T0_OK
CPL P3.7 ;zamruga dioda gdy sie naloza
RETI

T0_OK:
PUSH PSW
PUSH ACC
SETB MY_FLG1
MOV A,#100 ;Tyle ile potrzeba, aby program przebywal w przerwaniu
; by przyszlo kolejne przerwanie - nakladkowe.
DJNZ A,$ ;Petli sie az milo
POP ACC
POP PSW
CLR MY_FLG1 ;Wlasny znacznik opuszczenia przerwania
RETI


A co to byly za procesory ?
Intela 80C32.

A moze masz wadliwy kompilator assemblera ? Sprawdzales
kod wynikowy ?

Kod jest O.K.

Jest mozliwe, ze kompilator blokuje mozliwosc
bitowego adresowania P1.0 i P1.1 jesli sa one zdefiniowane
jako np. wejscia licznika T2 (nie wiem, to tylko moja
hipoteza probujaca wyjasnic to dziwactwo)

Ja nie wyjasnialem, tylko zmienilem procesor bez ruszania kodu :)

(STS)


Poprzedni Następny
Wiadomość
Spis treści
From: "/\\_MS_/\\" <m__s_at_nospam_go2.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 16:48:09 +0200



Moze inny kod testowy.
1. Ustawic automatyczne przerwania od
T0 z prawie maksymalna predkoscia.
2. Ustawic priorytet PT0
3. Wyzerowac wlasna flage
....
CLR MY_FLG1
...

Proc. przerwania:

ORG 0BH
JNB MY_FLG1,T0_OK
CPL P3.7 ;zamruga dioda gdy sie
naloza
RETI

T0_OK:
PUSH PSW
PUSH ACC
SETB MY_FLG1
MOV A,#100 ;Tyle ile potrzeba, aby
program przebywal w przerwaniu
; by przyszlo kolejne
przerwanie - nakladkowe.
DJNZ A,$ ;Petli sie az milo
POP ACC
POP PSW
CLR MY_FLG1 ;Wlasny znacznik
opuszczenia przerwania
RETI


A co to byly za procesory ?
Intela 80C32.

A moze masz wadliwy kompilator
assemblera ? Sprawdzales
kod wynikowy ?

Kod jest O.K.


Piszecie straasznie rozbudowane programy
zeby sprawdzic tak prosta rzecz
Wystarczy zapuscic licznik w dowolnym
trybie
z wewn zegarem a w procedurze przerwania


cpl pX.X
sjmp $

ot i wszystko
Jesli na pinie pX.X jest prostokat
tzn proc zezwala na przyjmowane
przerwania
w trakcie obslugi tegoz przerwania
Jesli nie tzn po przyjeciu pierwszego
wykonuje caly czas to przerwanie tzn
sjmp$
W "normalnych" '51 aby sprawdzic
poprawnosc dzalania
"nieudokumentowanych"
przerzutnikow zwiazanych z priorytetem
wystarczy zakonczyc przerwanie rozkazem
RET a nie
RETI
Po czyms takim drugi raz tego przerwania
( i zadnego
nizszego) przyjac nie powinien.
_ _
||\_/||
|| S || m__s_at_nospam_go2.pl





--
Wysoka jakość, niskie ceny - http://rubikon.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Stanislaw Sidor" <sts_at_nospam_qq.elcompzu.com.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 17:32:00 +0200


On the news /\ MS_\ <m__s_at_nospam_go2.pl> wrote:

Piszecie straasznie rozbudowane programy
zeby sprawdzic tak prosta rzecz

Pisze takie procedury, jakie moge przetestowac 'piorkiem' sonda TTL :)
Oscyloskop to w przypadkach ostatecznych wchodzi w rachube ...

Wystarczy zapuscic licznik w dowolnym
trybie

Nie w dowolnym, ale w 'auto reload' i z ustawionym PT0 (dla timer_0)

z wewn zegarem a w procedurze przerwania


cpl pX.X
sjmp $

ot i wszystko
Jesli na pinie pX.X jest prostokat
tzn proc zezwala na przyjmowane
przerwania
w trakcie obslugi tegoz przerwania
Jesli nie tzn po przyjeciu pierwszego
wykonuje caly czas to przerwanie tzn
sjmp$

Racja. Wygreles nagrode za kod minimalny (z oscyloskopem) ! ;)

W "normalnych" '51 aby sprawdzic
poprawnosc dzalania
"nieudokumentowanych"
przerzutnikow zwiazanych z priorytetem
wystarczy zakonczyc przerwanie rozkazem
RET a nie
RETI
Po czyms takim drugi raz tego przerwania
( i zadnego
nizszego) przyjac nie powinien.

Czy ja wiem ? Moze naloza sie dwie nieudokumentowane rzeczy ?

(STS)


Poprzedni Następny
Wiadomość
Spis treści
From: "/\\_MS_/\\" <m__s_at_nospam_go2.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 18:02:02 +0200


Nie w dowolnym, ale w 'auto reload' i z
ustawionym PT0 (dla timer_0)

Otoz w dowolnym bo co za roznica czy ja
cos wpisze
do licznika czy sam bedzie przekrecal te
8 , 13 czy 16 bitow
Po prostu fwy bedzie rozna.
A czemu musi byc PT0?

_ _
||\_/||
|| S || m__s_at_nospam_go2.pl




--
Przyznajemy się do niskich cen - http://rubikon.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Stanislaw Sidor <sts_at_nospam_qq.elcompzu.com.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 02 Aug 2000 18:04:22 +0200


/\\ MS_\\ wrote:

Nie w dowolnym, ale w 'auto reload' i z
ustawionym PT0 (dla timer_0)

Otoz w dowolnym bo co za roznica czy ja
cos wpisze
do licznika czy sam bedzie przekrecal te
8 , 13 czy 16 bitow
Po prostu fwy bedzie rozna.
A czemu musi byc PT0?

Pisze w jakich warunkach zjawisko zaobserwowalem i nic wiecej:
  • zegar T0

  • priorytet PT0

  • tryb auto-reload


(STS)

Poprzedni Następny
Wiadomość
Spis treści
From: "/\\_MS_/\\" <m__s_at_nospam_go2.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 2 Aug 2000 18:37:47 +0200


Pisze w jakich warunkach zjawisko
zaobserwowalem i nic wiecej:
- zegar T0
- priorytet PT0
- tryb auto-reload

Sorry , watek zrobil sie pokazny i
zapomnialem juz co bylo na poczatku
Faktycznie w tym przypadku
trzeba odtworzyc to co bylo
w orginale
_ _
||\_/||
|| S || m__s_at_nospam_go2.pl




--
Przyznajemy się do niskich cen - http://rubikon.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Juliusz" <jul_at_nospam_fom.pl>
Subject: Re: Programowy reset AT89C2051
Date: Wed, 02 Aug 2000 12:59:17 GMT


> Matko jedyna !!!
Przeciez '32 to po prostu '52 ('51 z RAM 256B) bez PROMu wewnatrz.

A, to przepraszam, nie używałem, więc nie skojarzyłem.


Tu nie ma co kojarzyc :-) Przeciez w kazdym PDF-ie stoi napisane, ce MCS32
czy 31 compatible core :-)

Juliusz