Zbych pisze:
> 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.

A po co mam zapamietywac jej stan? Skoro je blokuje to znaczy, ze
wczesniej musialo byc odblokowane, jesli z danego przerwania nie
korzystam to po co mialbym je blokowac? Taka potrzeba istnieje tylko
kiedy mam wiecej niz 1-poziomowa obsluge przerwan, zreszta to co
najwyzej 1 takt zegara.
Czasu odtworzenia nie musze liczyc, bo krytyczny jest moment do
odblokowania przerwan. Co sie dzieje potem w procedurze obslugi
przerwania dla innych przerwan jest bez znaczenia. Wiec tego nie licze.
A nawet liczac to porownaj czas RETI dla AVR i '51.

> 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.

No ile? Nawet odblokowywujac kilka zrodel przerwan obsluga zajmie mniej
niz jednego dla '51.
Widze, ze sprytnie usunales moje info, ze na '51 to zajmuje 36-108 cykli
zegara!!! Dla kazdego przyjetego przerwania! W porownaniu do tego moje
nawet 12 cykli na przerwanie nic nie znaczy.

> Po to, żeby tak nie cudować wymyślono priorytety.

Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to zalatwia
klasa napisana w C++, ktora jest skladnikiem HAL w moim projekcie.
BTW, ten sam program po zmianie paru klas realizujacych abstrakcje od
sprzetu kompiluje na PC i o dziwo... dziala.

>> 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.

Jak mi sie zapetli? Jesli odblokuje przerwanie Rx lub Tx UARTa to
znaczy, ze chce je obsluzyc. Zostanie ono natychmiast zgloszone, a
procedura obslugi musi na poczatku je skasowac, albo poprzez
zablokowanie flagi, albo poprzez odebranie znaku. W czym problem? Nic mi
sie nie zapetli bo przerwania sa przy zgloszeniu blokowane.

do góry

>> Takie porównania nie mają najmniejszego sensu!!!. Co za różnica jaki
>> kwarc
>> się podczepi, nie ma pomiędzy nimi w zasadzie różnicy - kwarce kosztują
>> tyle samo i
>> tyle samo miejsca zajmują. Podczepiasz taki jaki potrzebujesz.
>
> Owszem. Problem powstaje tylko jesli juz nie mozna podczepic wiekszego
> kwarcu, a mocy ciagle brakuje. No i obwod na 40MHz to nie to samo co obwod
> na 10MHz.

Obwód zegara jest prawie identyczny tylko cyferki na obudowie inne....ale to
obojętne

> Znasz jakas '51, ktora ma 20-30MIPSow? Jak jest taktowana 90-360MHz?

z 51' to znam uPSD 10MIPsów z 40MHz....

ale też znam inny mały nowoczesny kontroler 90MIPS z kwarca 8MHz :) i co ty
na to? OK -
ten ma wewnątrz PLL i programem ustawiasz to co się podoba (ARM).

Powiedzmy więc że jeśli z 51 nie mogę wyciągnąć potrzebnej mocy to jej tam
nie wsadzę
a wsadzam inny kontroler i już załatwione - kto powiedział że muszę
ograniczać się tylko do jednego?
- a w zasadzie ostatnio to już ograniczyłem się tylko do jednego ale ani 51
ani AVR tylko do ARM - nawet
jak prawie nic nie robi :).


>> Co za różnica co za procek stosujecie - układ ma działać!
>
> Dokladnie. A zwazywszy na ilosc i jakosc narzedzi szybciej zadziala na AVR
> niz na '51.

NIE to nie tak, mi szybciej zadziała na 51 bo znam 51 a tobie na AVR bo
znasz AVR
a innej osobie to nawet jak rok nad nimi spędzi to i tak żaden nie zadziała
bo się na
kontrolerkach nie zna :)

do góry

> Obwód zegara jest prawie identyczny tylko cyferki na obudowie inne....ale to
> obojętne

Ale jak to wplywa np. na podlaczona zewnetrzna pamiec? Albo na zuzycie
energii?

>> Znasz jakas '51, ktora ma 20-30MIPSow? Jak jest taktowana 90-360MHz?
>
> z 51' to znam uPSD 10MIPsów z 40MHz....

To ciagle 3x mniej.

> ale też znam inny mały nowoczesny kontroler 90MIPS z kwarca 8MHz :) i co ty
> na to? OK -
> ten ma wewnątrz PLL i programem ustawiasz to co się podoba (ARM).

A znasz ARMa w obudowie SO08? Albo SO16? ARMa w wersji zuzywajacej
pojedyncze mikrowaty?

> Powiedzmy więc że jeśli z 51 nie mogę wyciągnąć potrzebnej mocy to jej tam
> nie wsadzę
> a wsadzam inny kontroler i już załatwione - kto powiedział że muszę
> ograniczać się tylko do jednego?

Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin,
jesli korzystasz z komercyjnych narzedzi to tez musisz za wszystko
placic 2x, dwie rozne elektroniki, przy komercyjnych narzedziach
praktycznie nieprzenoszalny kod, czyli piszesz wszystko 2x. Mozna i tak.

> - a w zasadzie ostatnio to już ograniczyłem się tylko do jednego ale ani 51
> ani AVR tylko do ARM - nawet
> jak prawie nic nie robi :).

Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
najmniejsza wystepujaca obudowa jest TQFP64?

>>> Co za różnica co za procek stosujecie - układ ma działać!
>> Dokladnie. A zwazywszy na ilosc i jakosc narzedzi szybciej zadziala na AVR
>> niz na '51.
>
> NIE to nie tak, mi szybciej zadziała na 51 bo znam 51 a tobie na AVR bo
> znasz AVR
> a innej osobie to nawet jak rok nad nimi spędzi to i tak żaden nie zadziała
> bo się na
> kontrolerkach nie zna :)

Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++
z libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
przeniose np. na ARMa.
Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki
naglowkowe chociazby tylko ze standardowymi definicjami rejestrow?

do góry

On Mon, 09 Mar 2009 20:15:58 +0100, T.M.F. wrote:
>Owszem. Problem powstaje tylko jesli juz nie mozna podczepic wiekszego
>kwarcu, a mocy ciagle brakuje. No i obwod na 40MHz to nie to samo co
>obwod na 10MHz. Znasz jakas '51, ktora ma 20-30MIPSow?

O ile pamietam to byly takie.

>Jak jest taktowana 90-360MHz?

Nie, zrezygnowali z tego x12.

J.

do góry

T.M.F. pisze:

> A po co mam zapamietywac jej stan?

Bo przerwanie, które właśnie wpuściłeś w połowie obsługi innego
przerwania z powrotem ci tą flagę odblokuje.

> A nawet liczac to porownaj czas RETI dla AVR i '51.
> No ile? Nawet odblokowywujac kilka zrodel przerwan obsluga zajmie mniej
> niz jednego dla '51.
> Widze, ze sprytnie usunales moje info, ze na '51 to zajmuje 36-108 cykli
> zegara!!! Dla kazdego przyjetego przerwania! W porownaniu do tego moje
> nawet 12 cykli na przerwanie nic nie znaczy.

A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?

> Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
> ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to zalatwia
> klasa napisana w C++, ktora jest skladnikiem HAL w moim projekcie.

A co to ma do rzeczy jeśli chodzi o czas wykonania albo o konieczność
napisania tego?

> zablokowanie flagi, albo poprzez odebranie znaku. W czym problem? Nic mi
> sie nie zapetli bo przerwania sa przy zgloszeniu blokowane.

Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym uartem
musisz zrobić zanim odblokujesz przerwania.

do góry

>> A po co mam zapamietywac jej stan?
>
> Bo przerwanie, które właśnie wpuściłeś w połowie obsługi innego
> przerwania z powrotem ci tą flagę odblokuje.

Znowu manipulujesz. Napisalem, ze przy jednopoziomowej obsludze jest to
niepotrzebne. Przy wielopoziomowej jest to konieczne, ale tez nie
wszystkie flagi, bo moge zastosowac np. dodatowa flage, ktora wskazuje
na koniecznosc zapisania i modyfikacji innych flag. Co wiecej niektore
AVRy maja do takich celow specjalny rejestr dostepny przez sbi/cbi. W
efekcie moj prolog do przerwania ulegnie nawet skroceniu.

>> A nawet liczac to porownaj czas RETI dla AVR i '51.
>> No ile? Nawet odblokowywujac kilka zrodel przerwan obsluga zajmie
>> mniej niz jednego dla '51.
>> Widze, ze sprytnie usunales moje info, ze na '51 to zajmuje 36-108
>> cykli zegara!!! Dla kazdego przyjetego przerwania! W porownaniu do
>> tego moje nawet 12 cykli na przerwanie nic nie znaczy.
>
> A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?

A o jakiej rodzinie rozmawiamy? Bo mam wrazenie, ze '51 vs. AVR.

>> Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
>> ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to
>> zalatwia klasa napisana w C++, ktora jest skladnikiem HAL w moim
>> projekcie.
>
> A co to ma do rzeczy jeśli chodzi o czas wykonania albo o konieczność
> napisania tego?

Napisac raz i zapomniec.

>> zablokowanie flagi, albo poprzez odebranie znaku. W czym problem? Nic
>> mi sie nie zapetli bo przerwania sa przy zgloszeniu blokowane.
>
> Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
> samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym uartem
> musisz zrobić zanim odblokujesz przerwania.

Skup sie. Podalem ci przyklad jak to zrealizowac gdzie odblokowanie
przerwania nastepuje dopiero w 5/6 instrukcji. Czyli szybciej niz '51
zdazy w ogole zauwazyc, ze przerwanie wystapilo.
I co musze zrobic z UARTem? Jesli odblokuje jego przerwanie to zostanie
ono zgloszone, skoro je odblokowalem to znaczy, ze jego priorytet jest
dla mnie wystarczajacy, zeby go przyjac. Jedyna roznica bedzie taka, ze
w samej procedurze obslugi przerwania UART (i tylko w tej) musze przed
odblokowaniem zlikwidowac przyczyne, czyli np. odebrac znak.


--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

do góry

T.M.F. pisze:
>>> A po co mam zapamietywac jej stan?
>>
>> Bo przerwanie, które właśnie wpuściłeś w połowie obsługi innego
>> przerwania z powrotem ci tą flagę odblokuje.
>
> Znowu manipulujesz. Napisalem, ze przy jednopoziomowej obsludze jest to
> niepotrzebne. Przy wielopoziomowej jest to konieczne

Przecież rozmawiamy o emulacji priorytetów przerwań, czyli z automatu
można założyć, że są sytuacje gdy jedne przerwania przerywają drugie, a
nawet trzecie. Zresztą problem nie pojawia się tylko wtedy gdy kilka
przerwań wchodzi na siebie. Czasem trzeba wyłączyć przerwanie na czas
rekonfiguracji peryferiów, czasem potrzebna jest sekcja krytyczna z
wyłączonym konkretnym przerwaniem (a nie wszystkimi). Zakładanie z góry,
że flaga przerwania jest zawsze ustawiona, to proszenie się o kłopoty.

>> A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?
>
> A o jakiej rodzinie rozmawiamy? Bo mam wrazenie, ze '51 vs. AVR.

Nie, próbowałeś udowodnić, że priorytety przerwań nie są potrzebne, bo
je sobie możesz wyrzeźbić w sofcie.

>>> Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
>>> ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to
>>> zalatwia klasa napisana w C++, ktora jest skladnikiem HAL w moim
>>> projekcie.
>>
>> A co to ma do rzeczy jeśli chodzi o czas wykonania albo o konieczność
>> napisania tego?
>
> Napisac raz i zapomniec.

Czy ma to wpływ na czas wykonania przez procesor?

>> Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
>> samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym
>> uartem musisz zrobić zanim odblokujesz przerwania.

> w samej procedurze obslugi przerwania UART (i tylko w tej) musze przed
> odblokowaniem zlikwidowac przyczyne, czyli np. odebrac znak.

No nareszcie za którymś razem zrozumiałeś. Czyli jednak nie możesz
odblokować przerwań na samym początku, tak jak to wcześniej proponowałeś.

do góry

> Przecież rozmawiamy o emulacji priorytetów przerwań, czyli z automatu
> można założyć, że są sytuacje gdy jedne przerwania przerywają drugie, a
> nawet trzecie. Zresztą problem nie pojawia się tylko wtedy gdy kilka
> przerwań wchodzi na siebie. Czasem trzeba wyłączyć przerwanie na czas
> rekonfiguracji peryferiów, czasem potrzebna jest sekcja krytyczna z
> wyłączonym konkretnym przerwaniem (a nie wszystkimi). Zakładanie z góry,
> że flaga przerwania jest zawsze ustawiona, to proszenie się o kłopoty.

To sa konkretne sytuacje, ktore nie musza zachodzic w projekcie. Ja np.
jeszcze nigdy nie potrzebowalem kontroli priorytetu przerwania. Zapewne
nawet jesli by taka potrzeba zaszla to jednopoziomowa moglaby mi
wystarczyc, najprawdopodobniej potrzebowalbym co najwyzej jedno
nadrzedne, nieblokowane przerwanie.

>>> A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?
>>
>> A o jakiej rodzinie rozmawiamy? Bo mam wrazenie, ze '51 vs. AVR.
>
> Nie, próbowałeś udowodnić, że priorytety przerwań nie są potrzebne, bo
> je sobie możesz wyrzeźbić w sofcie.

No i to udowodnilem. Czyzbys uwazal, ze nie moge ich sobie softwarowo
zrobic? Pytanie retoryczne, bo musialbys obalic uniwersalnosc maszyny
Turinga, Nobel gwarantowany.

>> Napisac raz i zapomniec.
>
> Czy ma to wpływ na czas wykonania przez procesor?

A czy twierdzilem, ze nie ma? Narzekales jaki to straszny problem dodac
pare instrukcji assemblera.

>>> Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
>>> samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym
>>> uartem musisz zrobić zanim odblokujesz przerwania.
>
>> w samej procedurze obslugi przerwania UART (i tylko w tej) musze przed
>> odblokowaniem zlikwidowac przyczyne, czyli np. odebrac znak.
>
> No nareszcie za którymś razem zrozumiałeś. Czyli jednak nie możesz
> odblokować przerwań na samym początku, tak jak to wcześniej proponowałeś.


Juz 5 postow wyzej pokazalem w przykladzie, ze odblokowywuje przerwania
dopiero w ktorejstam instrukcji. Jeszcze tego nie dostrzegles?
Dla przypomnienia - chodzi o to, ze tak zachwalales kontroler przerwan w
'51. Pokazalem, ze w czasie krotszym niz '51 jest w stanie zareagowac na
przerwanie moge sobie to zrobic jesli potrzebuje programowo. Czyli o
dowolnym stopniu uniwersalnosci. Wiec w czym '51 ma byc lepsze?

do góry

T.M.F. pisze:

> Dla przypomnienia - chodzi o to, ze tak zachwalales kontroler przerwan w
> '51.

Pokaż mi posta w którym to zrobiłem.

do góry

J.F. pisze:
> On Mon, 09 Mar 2009 20:15:58 +0100, T.M.F. wrote:
>> Owszem. Problem powstaje tylko jesli juz nie mozna podczepic wiekszego
>> kwarcu, a mocy ciagle brakuje. No i obwod na 40MHz to nie to samo co
>> obwod na 10MHz. Znasz jakas '51, ktora ma 20-30MIPSow?
>
> O ile pamietam to byly takie.
>
>> Jak jest taktowana 90-360MHz?
>
> Nie, zrezygnowali z tego x12.
>
> J.
>
Rodzina Silabs(dawniej Cygnal) na przykład - około 1 MIPS/MHz moc
obliczeniowa do 100 MIPS. Od maleństw do TQFP100:
https://www.silabs.com/products/mcu/mixed-signalmcu/
Pages/C8051F12x3x.aspx

Pozdrawiam
--
Arek Świerc

do góry