Nimitz wrote:
> Nie zapominajmy, że 8051 to konstrukcja lat 70, ale ciągle trzyma się
> świetnie.

O przepraszam, nic sie nie trzyma. U mnie 51 wyleciala z hukiem z 15 lat
temu po pierwszym projekcie gdzie glownym problemem byl procek.

I bardzo jestem zadowolony, ze to byl lot w jedna strone ;-)
Nie wiem po co ludzie odgrzewaja taki stary kotlet, ale dobrze ze to nie
moj problem ;-)

--
Jerry1111

PS: po namysle: chyba tylko 13 lat temu.

do góry

Zbych pisze:
> T.M.F. pisze:
>
>> A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?
>
> Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne. W
> starych AVR możesz odblokować wszystkie, albo żadne.

W tych najprostszych, typu AT90S2313 tak, ale one juz sa obsolete. W
innych mozesz blokowac przerwania, ktore w danej chwili nie powinny
przerywac. Uprzedzajac - to i tak bedzie szybsze niz '51, a
uniwersalnosc jest nieporownywalnie wieksza.

>> Zawsze moge w pierwszej instrukcji odblokowac przerwania
>
> Aha, spróbuj to zrobić w przypadku UARTa.

A dlaczego nie?

do góry

T.M.F. pisze:
> Zbych pisze:
>> T.M.F. pisze:
>>
>>> A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?
>>
>> Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne. W
>> starych AVR możesz odblokować wszystkie, albo żadne.
>
> W tych najprostszych, typu AT90S2313 tak, ale one juz sa obsolete. W
> innych mozesz blokowac przerwania, ktore w danej chwili nie powinny
> przerywac.

Wszystkie AVRy poza xmega mają tak samo.

Uprzedzajac - to i tak bedzie szybsze niz '51, a
> uniwersalnosc jest nieporownywalnie wieksza.
>
>>> Zawsze moge w pierwszej instrukcji odblokowac przerwania
>>
>> Aha, spróbuj to zrobić w przypadku UARTa.
>
> A dlaczego nie?

Przeczytaj w dokumentacji kiedy są gaszone flagi żądania przerwania od
UARTa.

do góry

Nimitz pisze:
>
> Użytkownik "T.M.F." :
>> Zartujesz? AVR moge taktowac zegarem 20MHz, minimalny czas trawania
>> impulsu dla tego wariantu to 100ns, zadna '51 nie odczyta portu z taka
>> rozdzielczoscia. A XMega maja juz taktowanie 32MHz/32 MIPSy.
>
> Wszyscy wiemy, że zwykły 8051 dzieli zegar przez 12, więc jakie to ma
> znaczenie dla programisty? Porównuj 8051 12MHz z AVR 1MHz. Owszem, w
> konsekwencji możemy uzyskać znacznie szybszy AVR, ale do rzetelnego
> porównania muszą być zachowane podobne warunki.

Podobnym warunkiem jest taka sama częstotliwość zegara.To nie wina
RISCów że wykonują się w jednym cyklu a nie w 12.


--
Pozdrawiam
MD

do góry

Sebastian Biały pisze:
> W jednym z
> programów na '51 widziałem takie coś:
>
> // do not remove this line!
> int foo = 0;
>
> Usunąłem i oczywiście kompilator wyprodukował niedziałajacy kod.
> Komercyjny kompilator. Nowej wersji nie ma po co kupować.

Opisany przykład nie jest dowodem na błędne zachowanie danego kompilatora.

pzdr
mk

do góry

>>>> A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?
>>>
>>> Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne.
>>> W starych AVR możesz odblokować wszystkie, albo żadne.
>>
>> W tych najprostszych, typu AT90S2313 tak, ale one juz sa obsolete. W
>> innych mozesz blokowac przerwania, ktore w danej chwili nie powinny
>> przerywac.
>
> Wszystkie AVRy poza xmega mają tak samo.

Znaczy jak? Bo moge w kazdej chwili zablokowac pojedyncze typy przerwan
poprzez blokowanie flag na nie zezwalajacych. Flagi zgloszenia
poszczegolnych przerwan moge rowniez programowo zerowac.
Wiec w czym jest problem?


> Uprzedzajac - to i tak bedzie szybsze niz '51, a
>> uniwersalnosc jest nieporownywalnie wieksza.
>>
>>>> Zawsze moge w pierwszej instrukcji odblokowac przerwania
>>>
>>> Aha, spróbuj to zrobić w przypadku UARTa.
>>
>> A dlaczego nie?
>
> Przeczytaj w dokumentacji kiedy są gaszone flagi żądania przerwania od
> UARTa.

A konkretnie ktore flagi? Chodzi ci o to, ze np. UDRE bedzie ci na okolo
przerywac?

When interrupt-driven data transmission is used, the Data
Register empty Interrupt routine must either write new data to UDR in
order to clear UDRE or disable the Data Register empty Interrupt,
otherwise a new interrupt will occur once the interrupt routine terminates.

Przerwanie pzy odbiorze tez moge blokowac flaga RXCIE.

Ew. prosze jasniej.

do góry

T.M.F. pisze:
>>>>> A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?
>>>>
>>>> Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne.
>>>> W starych AVR możesz odblokować wszystkie, albo żadne.
>>>
>>> W tych najprostszych, typu AT90S2313 tak, ale one juz sa obsolete. W
>>> innych mozesz blokowac przerwania, ktore w danej chwili nie powinny
>>> przerywac.
>>
>> Wszystkie AVRy poza xmega mają tak samo.
>
> Znaczy jak? Bo moge w kazdej chwili zablokowac pojedyncze typy przerwan
> poprzez blokowanie flag na nie zezwalajacych. Flagi zgloszenia
> poszczegolnych przerwan moge rowniez programowo zerowac.
> Wiec w czym jest problem?

W czasie jaki to zajmuje. Parę postów wcześniej próbowałeś udowodnić, że
priorytety są zbędne, bo możesz odblokować inne przerwania w pierwszej
instrukcji. Otóż nie zawsze możesz, bo albo peryferium na to nie pozwala
(vide UART), albo musisz softowo blokować przerwania, których nie chcesz
wpuścić. Wszystko to zajmuje czas.

do góry

mk wrote:
>> // do not remove this line!
>> int foo = 0;
>> Usunąłem i oczywiście kompilator wyprodukował niedziałajacy kod.
>> Komercyjny kompilator. Nowej wersji nie ma po co kupować.
> Opisany przykład nie jest dowodem na błędne zachowanie danego kompilatora.

Oczywiscie ze sam potrafie podać przykład w którym nieznaczaca
instrukcja zmieni zachowanie programu przy braku błedu kompilatora.
Tylko że mam na myśli hakowanie i brudne sztuczki. W procedurze która
podałem o ile pamietam chodziło o liczenie CRC i po usunięciu tego
czegoś CRC wychodziło zupełnie inne. Zero hakowania, zwykły bug. Na 100%
kompilator był uszkodzony. I nie ma w tym nic dziwnego gdyby nie fakt że
poprawionej wersji nie było (albo inaczej: nie było w ramach gwaracji,
bo gwarancji na kompilator nie było, pozostało kupowanie nowszych wersji
:/ ).

do góry

>> Znaczy jak? Bo moge w kazdej chwili zablokowac pojedyncze typy
>> przerwan poprzez blokowanie flag na nie zezwalajacych. Flagi
>> zgloszenia poszczegolnych przerwan moge rowniez programowo zerowac.
>> Wiec w czym jest problem?
>
> W czasie jaki to zajmuje. Parę postów wcześniej próbowałeś udowodnić, że
> priorytety są zbędne, bo możesz odblokować inne przerwania w pierwszej
> instrukcji. Otóż nie zawsze możesz, bo albo peryferium na to nie pozwala
> (vide UART), albo musisz softowo blokować przerwania, których nie chcesz
> wpuścić. Wszystko to zajmuje czas.

Chyba sobie zartujesz w tym momencie. Dla '51 samo wejscie w procedure
obslugi przerwania trwa 3-9 cykli maszynowych (czyli 36-108 cykli
zegara). AVR w tym czasie wykona procedure o zlozonosci powaznego
schedulera dla OSu.

Zreszta policzmy ile to kosztuje
Najgorszy mozliwy wariant, czyli rejestr kontrolny jest spoza zasiegu
sbi/cbi:
PUSH R16
LD R16,rejestr z flaga
ORI R16, blokowane przerwania
STS rejestr, R16
SEI

Zajelo to 5 taktow. Dodatkowo 6 taktow kosztuje wejscie w procedure
obslugi, razem 11 taktow. W tym czasie '51 nie zdazy nawet zauwazyc, ze
jest przerwanie (aktywny poziom musi trwac co najmniej 12 taktow). Wiec
o czym ty mowisz?
Oczywiscie mozesz zapytac co kiedy masz kilka flag do zablokowania? No
problem, na malych prockach wiekszosc miesci sie w jednym rejestrze.
Jesli nawet w roznych to ciagle mamy spory zapas czasowy w stosunku do '51.
BTW, o co ci chodzi z tym UARTem?

do góry

T.M.F. pisze:

> Zreszta policzmy ile to kosztuje
> Najgorszy mozliwy wariant, czyli rejestr kontrolny jest spoza zasiegu
> sbi/cbi:
> PUSH R16
> LD R16,rejestr z flaga
> ORI R16, blokowane przerwania
> STS rejestr, R16
> SEI
>
> Zajelo to 5 taktow.

Bo miałeś tylko jedną flagę, nie zapamiętałeś jej stanu i nie
odtworzyłeś jej stanu przed zakończeniem przerwania. Policz ile zajmie
takie coś czasu jak będziesz miał kilkanaście działających w systemie
przerwań i będziesz chciał mieć kilka o wyższym priorytecie.
Po to, żeby tak nie cudować wymyślono priorytety.


> BTW, o co ci chodzi z tym UARTem?

Tak ciężko przeczytać dokumentację? Nie można odblokować przerwań na
przed odbiorem/wysłaniem znaku, bo ci się przerwanie zapętli. Więc
odpada pomysł z odblokowywaniem przerwań, tuż po wejściu w przerwanie.

do góry