Jako że dopiero teraz udało mi się poprawnie wstawić nowy temat przepraszam wszystkich za kłpoty

Witam
Zaczynam poznawać język C z "Niebieskiej Biblii" trwa to już trochę
i właśnie dzięki tej książce (między innymi) dostałem procesor w prezencie,
Ponieważ był to AtTiny15 po odpaleniu Eclipsa nastąpił "zonk", Eclips
nie wspomaga tego procka .
Następnie przyszła por na AS i tu też niespodzianka AS też nie wspomaga tej kostki,
znaczy wspomaga ale tylko w ASM.

Mój błąd może najpierw powinienem doczytać (słabiutki angielsi)
,że ten procek nie ma w ogóle pamięci RAM (oczywiście poza rejestrami - jakby nie patrzeć rejestry to też RAM ) więc
wpadłem na pomysł spróbuje przerobić program Mirka z C na asembler.

Jako że AS w ogóle mi nie podszedł znalazłem taki symulator o nazwie VMlab
po poznaniu nawet ciekawy (bez reklamy ).

Wziąłem program pilota RC5 (bo wydawał się "krótki" ) i cóż pomyślałem co ja
robię C nie znam a asembler to tylko trochę na C-64 i to słabo ale tutaj
wielki pokłon Mirkowi jego rady w książce pozwoliły mi to zrobić.

Co prawda na razie to działa tylko w symulatorze (VMlab ma taki oscyloskop programowy)
a wiadomo w realu to cuda mogą z tego wyjść .

Wstawiam to co mi się udało zrobić, nie jest to przetestowany program w procku,
(niestety mam inne obowiązki a to jest moje hobby na które ciężko znajduje czas)
jak tylko znajdę czas to będę dalej działał w tym temacie.



plik definicje.inc


Plik defPinow.inc


Plik timery.inc


Plik przerwania.inc


Plik przerwINT0.inc


Plik opuznienie.inc


Plik klawisze.inc


Plik daneRC5.inc


Plik czekajtim.inc


Jeśli ktoś rzuci na to okiem to
wszelkie opinie i krytyka mile widziane.
Na swoją obronę napisze ,że jestem bardzo początkujący


Dodano po 30 minutach

Podzieliłem ten kod na tyle kawałków aby testować wszystko mniejszymi kawałkami
choć może to utrudnić analizę komuś innemu .
Może jakoś się przekonam do AS w wersji 4

Hej ,
Jeśli to pierwszy raz x.asm, tylko pogratulować ,
Jednak , nie zniechęcałbym się od razu do AtmelStudio , jeśli masz problemy z AS5, czy AS 6.x to
zawsze masz jeszcze AtmelStudio 4.18 - ma zdecydowanie mniejsze wymagania.
Bo AS, to też pewny symulator , to oryginalny kod maszynowy-składnia i rozkazy,
nie zawsze tak jest przy innych , czasem wygodniejszych narzędziach, dotyczy także eclipse..
W asemblerze regułą jest ( przynajmniej moim zdaniem ) , puścić sobie symulator , tak niechcący
zobaczysz wpływ użytego rozkazu na zużycie pamięci flash , na ilość cykli potrzebnych do wykonania..
jest to super szkoła by zacząć dobierać świadomie typy rozkazów, i konstrukcje logiczne zadań do wykonania.
Jeśli chciałbyś uwagi , do twojego kodu - bynajmniej nie krytyka , spróbuj przełączać całe porty zamiast
pojedyncze piny, niekoniecznie musisz dzielić zadania na tak elementarne bloczki , "branch" to aż
64 pojedyncze rozkazy , często jest to zupełnie wystarczające by zapisać program "liniowo"
, przynajmniej dla mnie jest to bardziej czytelne( łatwiejsze do interpretacji po latach ).
Twoja wersja zapisu jest bardzo poprawna logicznie i strukturalnie , jest natomiast nieco "droższa"
czasowo i objętością flash z powodu użycia niekoniecznej, większej ilości rozkazów rjmp.

ps. nie wiem dlaczego ale w tej chwili Twój post znikł ?
na początku popełniłeś nieostrożność próbujesz wpisać do 8-mio bitowego rejestru częstotliwość oscylatora - nie wiem jak tę częstotliwość zdefiniowałeś,
ale do rejestru AVR wpiszesz zawsze tylko 8 bitów - spodziewaj się złych czasów opóźnień .
ps2. już sprawdziłem , Twoja częstotliwość jest w MHz , zatem jest OK

Właśnie nie do końca zrozumiałem pdf-a jeśli chodzi o
o OSCCAL .


że jeśli jest zero to jest najmniejsza możliwa częstotliwość a jeśli zapiszę $FF to
największa, tylko jak zauważyłeś jest to rejestr ośmiobitowy więc nie wiem co i jak.

@jp_elek no i nie rozumiem zwrotu "branch"
jeśli chodzi o optymalizacje to jeszcze jestem zbyt zielony

Hej ,
Z tego co wyczytałem na szybko , odnośnie oscylatora RC , nominalnie jest wyskalowany na 1,6 MHz , rejestr OSCCAL służy do wprowadzania korekcji do pętli PLL aby
tę częstotliwość nieco podkręcić w górę - wiadomo iż stabilność tego oscylatora RC jest nie tak znów wielka , zatem wpisując coś większego od 0 do 0x00 podkręcisz tę częstotliwość
w górę - nie znalazłem na szybko jakiegoś bardziej precyzyjnego wzoru - pozostaje więc eksperyment - zwróć uwagę iż ostrzegają iż podkręcenie powyżej 1,75 MHz moeż spowodować
problemy z Timer'em 1 , zatem domyślnie zmiana OSCCAL w zakresie 0x01 do 0xFF nie wpływa radykalnie ,lecz łagodnie na zmianę częstotliwości RC
ad2. Branch ==> część instrukcji skoków to:
Skip Skip if Bit in Register is Set (C)leard -to najkrótszy skok o jeden rozkaz - nie ma znaczenia czy kod rozkazu jest 16 bitowy czy długi -rozkaz sam rozpoznaje wymaganą długość skoku( inkrementację licznika rozkazów),
Branch nieco dłuższy skoczek BRxx jest ich ponad tuzin , BRBS,BRBC,..... to takie skoki po najwyżej 64
potem RJMP ( relative JUmp) do 2048 rozkazów
a najdłuższy to JMP skok w dowolne miejsce programu .

Wielkie dzięki za rozjaśnienie tematu
czyli zamiast RJMP lepiej jest używać BRXX jeśli
chciałbym zoptymalizować kod ?.

Co do rejestru OSCCAL to dopiero przetestuje jak będę miał program
wgrany do procka ale na razie to muszę poczekać aż wrócę
do swojego "lochu" dostałem brutalny zakaz wstępu na czas nieokreślony
(do końca urlopu)

Nie tak z automatu ,
Skip i Branch to skoki warunkowe ,
a rjmp to skoki bezwarunkowe , zatem wedle potrzeb - nie z automatu.

ps. jeśli natomiast potrzebujesz długiego skoku warunkowego , to najprościej:
Branch if ... ( warunek do pominięcia kolejnego rozkazu)
Rjmp ( wykonaj ten skok jeśli poprzedni warunek nie jest spełniony)
Rjmp ( wykonaj ten skok jeśli warunek z pierwszej linii jest spełniony )

No i znowu jaśniej
dzięki

Attiny15 to naprawdę cienki bolek - na jakieś gotowe rozwiązanie problemu, które się zmieści w obrębie tak małej pamięci, może i OK, ale na eksperymentowanie dla początkujących to trochę jak rower na jednym kółku z miniaturowymi pedałami. Największym mankamentem jest ten brak pamięci SRAM, bo... no właśnie... w pamięci SRAM realizujesz sobie stos i operujesz na nim, najlepiej z rezerwą a nie na styk co do jednego bajtu, na tym polega komfort programowania. W tych małych szkrabach jest ponoć jakiś tam minimalny stos zrealizowany sprzętowo, ale w przypadku zaczynania pisania programów w asemblerze to tylko bardziej utrudnia niż pomaga, bo zawsze trzeba o tym małym stosie pamiętać, żeby nie przekroczyć jego „możliwości” - wystarczy wywołać kilka podprogramów w sobie i jesteś ugotowany. Ten mikrokontroler chyba nawet nie ma rozkazów PUSH i POP - ratowania i przywracania wartości rejestrów. Ja na pierwsze eksperymenty z 8-pinowym Attinem kupiłem sobie maksimum, jakie udało mi się kupić - Attiny85 - który ma 8 kilobajtów pamięci programu (tak naprawdę to 4 kilo kodu) i co ważniejsze - 512 bajtów SRAMu i tym samym możliwość realizacji normalnego stosu. Ktoś, kto programował trochę na C51/52, na pewno będzie wiedział co to jest mały stos, mało pamięci SRAM i jak niekiedy trzeba się nagimnastykować, żeby starczyło na wszystko i jak niewygodne jest pośrednie adresowanie za pomocą @r0. Z czegoś takiego będzie się śmiał ktoś, kto pisze program na 68000 i ma pod ręką kilka megabajtów RAMu.

Ale wracając do Atmela... Tak samo postąpiłem z 28-nóżkowymi i 40-nóżkowymi procesorami - od razu Atmega16 i Atmega32 a w przypadku 40DIP Atmega1284P, nie ma się co szczypać i mlaskać przy zamawianiu. Oszczędzanie na pamięci jest tylko złudnym zaoszczędzeniem, bo zaoszczędziłeś 2 zł a potem przy pisaniu programu robisz coraz większe oczy i zaczyna się łykanie śliny, bo koniec pamięci się zbliża wielkimi krokami i w pewnym momencie i tak będziesz zmuszony kupić sobie tego lepszego scalaka, jeżeli będzie ci na tym wszystkim zależało. Oczywiście jeśli chcemy zapalać tylko LEDa i patrzeć na niego jak ładnie mruga, gdy naciskamy na „jeden jedynie słuszny” klawisz w naszym układzie a potem to walniemy w kąt, to nie ma to większego znaczenia - nie trzeba stosu, nie trzeba RAMu, a 1 kilobajt pamięci Flash to nawet już grzech i za dużo.

Dodam może jeszcze, że oczywiście nie wykluczam sytuacji, kiedy się umyślnie wybiera procesor z mniejszymi zasobami, ale to wtenczas już jest bardzo przemyślana i dojrzała decyzja - np. mamy już dopracowany i skończony program albo bierzemy takiego scalaka, który ze względu na swoje właściwości i parametry jest nam potrzebny w układzie - one się między sobą różnią, choćby nawet czymś takim podstawowym i banalnym jak maksymalną częstotliwością taktowania albo poborem mocy.



To trochę dzieło artystyczne, tym bardziej że Attiny15 ma chyba rozkaz do zerowania rejestrów i nawet on tyle samo pamięci i taktów procesora zużywa - lepiej korzystać z mnemoników tak jak zostały one do tego przeznaczone, bo to ułatwia późniejszą analizę i poprawianie (często własnego) programu. Tak samo jak robienie samemu sobie komentarzy przy pisaniu programu, który być może za rok będziemy czytali i przy ich braku na nowo odkrywali i zastanawiali się o co nam w tym miejscu programu chodziło. W asemblerze jest taka jedna zasada: jeżeli napisałeś jakiś dobry fragment programu, opisz go sobie dobrze i nie kasuj go, bo z pewnością go za jakiś czas będziesz na nowo potrzebował. W ten sposób robimy przy okazji sukcesywnie swoje własne biblioteki i podprogramy, z których zawsze możemy w nowych projektach skorzystać, co z kolei zaoszczędzi nam wiele czasu, trudu i nerwów. Pisanie czegoś dwa razy, żeby się czegoś nauczyć, na pewno nie jest głupie, ale pisanie czegoś zawsze od nowa, bo tak postępować się „nauczyliśmy”, nie jest najlepszą opcją - na dlugą metę to zniechęci każdego zapaleńca. To samo zresztą jest z naszymi schematami i bibliotekami w EAGLEu albo jakimś ekwiwalentnym programie.

@Grzegorz zgadzam się z Tobą mój kod na pewno nie jest optymalny a
jeśli chodzi o wybór procka to miałem znikomy wpływ na to, po prostu
taki dostałem (mogłem go umieścić w koszu) ale chciałem jakoś go
wykorzystać i powstało takie "Cóś" .

(EOR rejestru samego ze sobą) do wyzerowania rejestru użyłem
tak dla testu i zadziałało więc zostawiłem ale zgadzam się ,że
nie jest to eleganckie rozwiązanie .

Jako, że to mój pierwszy post witam wszystkich.

Zaba, masz błędy przy końcu obsługi przerwania INT0, przy kasowaniu flagi przerwania INTF0. (choć w Twoim programie nie mają one negatywnych skutków).

Plik przerwINT0.inc

- Najpierw odtwarzasz rejestr SREG, a wykonujesz później jeszcze operacje które mogą zmienić jego zawartość.
Polecenie "ori" modyfikuje bity Z,N,V w SREG.

- Jeśli w odczytanej zawartości GIFR byłyby ustawione flagi innych przerwań, jeśli wykonasz "ori temp, (1<<INTF0) " i zapiszesz zmienioną wartość do GIFR je też skasujesz oprócz flagi INTF0.
Możesz zmienić na: