Mikrokontrolery ATMEL dla początkujących: Książki, zestawy i zasoby do automatyki domowej

Mon Mar 09, 2009 9:46 pm   

T.M.F. pisze:


'51 używam bardzo rzadko, najchętniej wcale bym nie używał, ale najpierw
bardzo poproszę o AVR-a z porównywalnym ADC jak w MSC1210 TI albo serii
ADUC Analoga.. ;-)

--
Pozdr.
Michał

Mon Mar 09, 2009 9:50 pm   

Michał Baszyński pisze:


Ale idac tym tropem - pokaz mi '51 ktora ma drivery do LCD, interfejs do
SDRAM, wbudowane DMA, albo sprzetowe RSA?

Mon Mar 09, 2009 9:52 pm   

T.M.F. pisze:


Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne. W
starych AVR możesz odblokować wszystkie, albo żadne.


Aha, spróbuj to zrobić w przypadku UARTa.

Mon Mar 09, 2009 9:55 pm   

T.M.F. pisze:


ADUC 816?
albo AVR-a z USB z trybem High-Speed ?
Nie ma jednej rodziny uC, która byłaby dobra do wszystkiego i uważam, że
uC powinien być dobrany do konkretnych potrzeb.

--
Pozdr.
Michał

Mon Mar 09, 2009 9:59 pm   

Michał Baszyński pisze:

AVR z USB HS sa dostepne.
Masz '51 z wireless?:)


To z pewnoscia. Tyle, ze trudno wskazac do czego dobre sa '51

Mon Mar 09, 2009 10:09 pm   

Nimitz wrote:

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.

Mon Mar 09, 2009 10:09 pm   

Zbych pisze:

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.


A dlaczego nie?

Mon Mar 09, 2009 10:16 pm   

T.M.F. pisze:

Wszystkie AVRy poza xmega mają tak samo.

Uprzedzajac - to i tak bedzie szybsze niz '51, a

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

Mon Mar 09, 2009 10:27 pm   

Nimitz pisze:

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

Mon Mar 09, 2009 10:30 pm   

Sebastian Biały pisze:

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

pzdr
mk

Mon Mar 09, 2009 10:39 pm   

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?



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.

Mon Mar 09, 2009 10:46 pm   

T.M.F. pisze:

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.

Mon Mar 09, 2009 10:52 pm   

mk wrote:

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
:/ ).

Mon Mar 09, 2009 11:35 pm   

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?

Tue Mar 10, 2009 12:00 am   

T.M.F. pisze:


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.



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.