Assembler AVR, skąd się uczyć?

Witajcie,

Jeśli zna ktoś na tym forum Assemblera AVR to skąd się uczyliście? Chciałbym się go nauczyć aby zbudować na AVR coś w rodzaju komputera, tzn. żeby nie programować Flasha w uC tylko na karcie pamięci mieć programy i możliwość ich pisania na tym uC. Wydałem ok. 150zł na początek z AVRami (ATmega16, lutownica i akcesoria, zestaw rezystorów i kondensatorów, pytka stykowa itp.). Napisałem miganie LED... w C i teraz to "poszło w kąt". Assemblera chcę się nauczyć żeby pisać mało zajmujące i szybkie programy i żeby dobrze poznać architekturę tego procesora.

PS. Chodzi mi bardziej o wyjaśnienie działania poszczególnych instrukcji niż samo pisanie programu.

Rozszerzone datasheety (masz tam opis każdej instrukcji oraz praktyczny opis architektury (SP, SREG, itp) ) + ta strona może być pomocna .
Szkopuł jest w tym że sam syntax assembly nie jest trudny, trudne jest ogarnąć jak to wszysko trybi czyli architekture danego procesora.
Programowanie AVR w asm to zupełnieee inna bajka niż x86, i zanim zrobisz to co planujesz to troche minie :- ) + kod napisany przez Ciebie będzie prawdopodobnie mniej wydajny niż kod kompilatora, no, chyba że użyjesz jakiś sztuczek jak np te tutaj.
To co próbujesz myśle że da się z powodzeniem wykonać w C w sposób np, opkody zapisujesz w EEPROM i potem jakoś sobie ładujesz run-time do pamięci + jmp w to miejsce. Do tego można dołożyć mechanizm context switch i masz eleganckie środowisko wielozadaniowe ;- )
Generalnie możesz przejrzeć kody istniejących RTOS-ów na AVR i zobaczyć czy na pewno chcesz bawić się w low-level (ciekawe ale raczej nie łatwe, i tutorialów typowo step-by-step w tych tematach raczej nie ma).

@bajos
W znakomitej większości przypadków nie będziesz lepszy niż optymalizator gcc, kilkukrotnie boleśnie się o tym przekonałem. Nic złego w znajomości ASMa, ale generalnie ekstremalnie rzadko rzadko się tego używa. A jeśli koniecznie chcesz - to masz dokumentację.

A w skrócie: w AVR działasz na rejestrach a pamięć jest tylko do odczytu/zapisu.
Masz kilka (o ile pamiętam 3) par rejestrów wskaźnikowych żeby wygodnie się po niej poruszać, ale równie dobrze możesz używać ich jako normalnych rejestrów. Połowa rejestrów roboczych ma nieco większe możliwości od pozostałych (głównie operacje na w. natychmiastowych). Dla większych AVR masz dodatkowe instrukcje zapisu/odczytu dalszych obszarów pamięci/peryferiali.

Co do mądrych słówek: load to wczytanie, store zapis, immediate to wartość natychmiastowa (czyli np. w wyr. x + 5 - to 5 jest immediate), branch skok, call - skok ze śladem. Do tego kilka typów adresowań. Patrz na zakresy skoków, zwłaszcza względnych bo mają one ograniczone możliwości inkrementacji program countera, z drugiej strony zwykły skok zajmuje więcej pamięci programu i wykonuje się chyba dłużej.

Do tego poczytaj o makrach avrasm typu ramend, hbyte, lbyte oraz jak ustawiać stos: to jest o tyle problematyczne, że dla różnych AVR dzieje się to automatycznie lub nie w różnych momentach. Dodatkowo zwróć uwagę na rodzielenie pamięći flash i RAM oraz jak są one adresowane.

@Proxima czeeekaj, o co Ci chodzi z opkodami w eeprom? W sensie - uruchamianie wstawek/funkcji asemblerowych z RAMu? W ARM tak, Cortex M4 ma CCM-RAM specjalnie do takich zabaw (m.in.), ale w AVR nie masz szans tego zrobić bo architektura na to nie pozwala.

alagner napisał(a):

W znakomitej większości przypadków nie będziesz lepszy niż optymalizator gcc, kilkukrotnie boleśnie się o tym przekonałem. Nic złego w znajomości ASMa, ale generalnie ekstremalnie rzadko rzadko się tego używa. A jeśli koniecznie chcesz - to masz dokumentację.

Na AVR (zwłaszcza tych małych i mikroskopijnych) problemem często nie jest prędkość (ta i tak jest słaba, a często nie ma po prostu znaczenia) tylko brak miejsca. W asmie masz tylko to co napiszesz. w C, a w C++ jeszcze bardziej, kompilator dorzuca śmieci, funkcje z biblioteki standardowej.. i szybko zaczyna to zajmować więcej niż mamy dostępnej pamięci.

@Azarien: wiem, ale przy umiejętnym stosowaniu staticów, inline i innych możliwości języka C naprawdę aż takiej różnicy nie ma. Dołóż do tego optymalizację Os. To już prędzej w ASM napisałbym ISRa, który totalnie nie używa stosu, za to ma szybko "machnąć" pinem procka. Miałem kilkukrotnie okazję szukać oszczędności C <-> ASM, i jeżeli w ogóle cokolwiek dawało się znaleźć to były to pojedyncze bajty, pod warunkiem oczywiście że kod napisany był dobrze.

EDIT: btw - po to jest itoa zamiast sprintfa itd. ;) Fakt, o tym trzeba wiedzieć, ale to też wliczam do "dobrze napisanego kodu"

Czym kompilujecie kod do hexa? Ja mam zainstalowane avra i avr-asm tylko, że obydwa sypią errorami. Kod to prosty:

.nolist
.include "src/m16def.inc"
.list

.device atmega16

.cseg
.org 0

ldi R16, (1<<PINB0)
out DDRB, R16
out PORTB, R16