ATmega88: Niezgodności w dokumentacji PDF a problemy z kodem USART?

Sun Dec 02, 2007 11:15 pm   

Witam
Podczas prac nad drobnym projektem na ATmega8 przekombinowałem na
fusebitach i przyblokowałem sobie SPI Myśle sobie "sr.. plies" z
tytułu kilku PLN nie będę kombinował programatora równoległego do
odblokowania jednej atmegi. Problem,że jak się okazało była to ostatnia
Atmega8 w obudowie DIP jaką miałem pod ręką. Ale znalazłem kupioną "na
zaś" ATmega88. Pinout ten sam, zasoby podobne a nawet trochę większe.
WinAVR, makefile ustawiony na atmega88, w źródłówkach poprawione nazwy
rejestrów USART-a (z UDR na UDR0, UCSRB na UCSR0B itd) kompilacja i...
błędy typu "niepoprawny argument" we wstawkach assemblerowych obsługi
USART-a. Patrzę w pdf-a i moje procedury wysyłki i odbioru bajtu są
toczka w toczkę takie same jak w przykładzie podanym w pdf-ie. Myślę
sobie "ki diabeł". Patrzę na rozpiskę adresów rejestrów (Register
Summary) i... przykład z pdf-a nie ma prawa działać. Rejestry USART-a
zostały przeniesione na wysokie adresy powyżej 0x3F czyli nie mają prawa
działać instrukcje in, out, sbis wykorzystane w przykładach. Z drugiej
strony czemu Atmel zrobił taki rozp... w rejestrach. W obszarze SFR kupa
adresów jest jako reserved.

Pozdrawiam
Grzegorz

Sun Dec 02, 2007 11:32 pm   

Użytkownik "Grzegorz Kurczyk" <grzegorz.usun.to@control.slupsk.pl> napisał w
wiadomości news:fivar6$6ct$1@atlantis.news.tpi.pl...

Tak z ciekawości ile % czasu procka zaoszczędziłeś pisząc kod obsługi USART
w ASM? Wiem, można oszacować ale może Ty już wiesz dokładnie .

Pozdrawiam Łukasz

Mon Dec 03, 2007 12:11 am   

Użytkownik Ukaniu napisał:

USART musi działać na 9600, 19200 czy nawet 115200bps ? Przy pełnej
prędkości masz tylko 20 taktów zegara na przygotowanie kolejnego
bajtu... czyli nie aż tak strasznie dużo.

Pozdrawiam
Grzegorz

Mon Dec 03, 2007 12:14 am   

hmmm... odpisałem, ale nie mój czytnik nie widzi mojego posta...

Mon Dec 03, 2007 12:16 am   

Użytkownik "Grzegorz Kurczyk" <grzegorz.usun.to@control.slupsk.pl> napisał w
wiadomości news:fiveb2$qql$1@nemesis.news.tpi.pl...

Ja nie wątpię w korzyści tak tylko się zastanawiam czy to istotnie
potrzebne.
Odpowiedź jest jedna - oczywiście tak. Jednak mało kiedy potrzeba nadawać
pełną parą non stop a dane zgromadzone w tablicy wypluć szybko to już nie
problem. Więc tak się zastanawiam sam czy kiedykolwiek bym potrzebował
opisać to w ASM i ile zyskam :-)

Pozdrawiam,
Łukasz

Mon Dec 03, 2007 12:20 am   

Użytkownik Adam Dybkowski napisał:

Tak czułem... ;-)

Wiem, wiem... to były procedury, które pisałem jakiś czas temu jak
jeszcze WinAVR był daleki od doskonałości. Zostały bo działały jak
trzeba. Chodziło mi o przykład. Z drugiej strony mam dosyć często
potrzebę pisania wstawek assemblerowych w krytycznych czasowo
fragmentach programu. Kompilator niektóre rzeczy tłumaczy dośc
pokrętnie. Oczywiście nie widzę sensu rzeźbienia w assemblerze obsługi
menu czy prostej klawiatury matrycowej.

P.S. Czyżby Atmel zastosował tę filozofię, że w przykładzie
assemblerowym można napisać bzdury, bo kto pisze w assemblerze ;-)

Pozdrawiam
Grzegorz

Mon Dec 03, 2007 12:41 am   

Grzegorz Kurczyk pisze:


Nie, myślę że to tylko ich przeoczenie w PDFie. Nie pierwsze zresztą. W
przykładowych funkcjach do obsługi USB w AT91SAM7S256 musieliśmy
poprawić AFAIR ze 2 krytyczne rzeczy (nie wychodzące przy kompilacji!)
aby przykład mógł działać.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Mon Dec 03, 2007 12:41 am   

Grzegorz Kurczyk pisze:



Wytłumacz sens pisania w asemblerze. Ja co tylko mogę piszę na AVRa w C
(o ile oczywiście nie chodzi o malucha w stylu AT90S1200). Poza znikomo
niższą wydajnością niż 100% ASM (a zwykle porównywalną), główną zaletą
jest dla mnie możliwość późniejszych przenosin oprogramowania na inny
procesor. Już nie raz robiliśmy takie rzeczy w firmie, skacząc od DSP'ka
TI aż po ARMa (a nawet pisząc wspólny kod kompilowalny na różne
procesory). Tylko trzeba pamiętać, aby nie używać na każdym kroku
explicite rozwiązań AVR-super-duper-specyficznych w stylu printf_P (PSTR
("abc")), tylko opakować to w wygodne makro lub funkcję inline.
Podstawowym działaniem jest w każdym razie unikanie gdzie tylko się da
asemblera. Oczywiście nie zawsze się da (np. początek funkcji obsługi
przerwań czy wyjątków na ARMa lub scheduler przełączający zadania), ale
to inna sprawa.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.