Tytuł może i straszy lub brzmi jak bełkot, i być może nie wszyscy znają temat. Niech się ten fakt od dziś zmieni … W Bascom nosave jest parametrem w deklarowanej procedurze obsługi przerwania, dotyczy zarówno Bascom AVR jak i 8051. Co z tego wynika i po co to? Hymmm dobre pytanie.

Generalnie, przeglądając informacje zawarte w opisie deklaracji procedury obsługi przerwania, podane w powyższym odnośniku dowiemy się, iż istnieje możliwość nadzorowania obsługi stosu w momencie wystąpienia dowolnego przerwania ISR. Na fakt ten szczególną uwagę zwrócił BARTek. a co z tego wyszło dowiemy się za chwilę

W Bascom nosave

jako parametr, bezwzględnie wyłącza zapisywanie rejestrów na stosie w chwili przejścia do obsługi przerwania, jak i również po zakończeniu jego obsługi blokuje ich odtwarzanie. Sytuacja tak może doprowadzić do utraty danych i błędnego funkcjonowania programu. To po co to wymyślono? A no po to aby te operacje wykonać samodzielnie … jak kto potrafi 😛 Jaki jest tego sens?

Otóż każdorazowo kompilator czynność przechowania wartości rejestrów na czas obsługi przerwania, wykonuje za nas, umieszczając w kodzie stosowne komendy. Robi to automatycznie kopiując wartości prawie wszystkich z występujących w µC rejestrów … zabiera to sporo czasu nawet dla µC AVR skonstruowanych w architekturze RISC. Jak jeszcze się przypomni, że robi to dwa razy … raz na „dzień dobry” a kolejny na „do widzenia” … każdemu przerwaniu obsługiwanemu w systemie …

I właśnie na te czynności zwrócił uwagę BARTek i chwała mu za to, bo owocem tego jest doskonałe narzędzie, które opracował, i które za każdego odwali brudną robotę, umożliwiając sielankową pracę ze swoim kodem w jakże poważnym tonie. Wszakże do czynienia będziemy mieć z asemblerem. 😉
Ale znaczny przyrost w uzyskanej wydajności wykonywanego kodu obsługi przerwania to nie wszystko. Zaznaczyć też w tym momencie warto, że teraz wręcz możliwe będzie wykonanie i opracowanie skomplikowanego kodu, którego w niektórych przypadkach nie było by się w stanie ukończyć, ze względu na czas wykonywania występujących przerwań itp.
Kolejną niebywałą zaletą jest optymalizacja kodu i redukcja jego objętości, niejako przy okazji, przez wykluczenie zbędnie wykonywanych operacji za każdym razem w trakcie wystąpienia przerwania.

Na ten fakt tym razem ja zwróciłem szczególną uwagę. Kiedyś przy opracowaniu pewnego sterownika na µC Attiny2313 poświęciłem mnóstwo czasu by „upchnąć” zamierzoną funkcjonalność w jego pamięci flash. Oczywiście była to owocna lekcja i nie żałuję poświęconych chwil, nie mniej w chwili obecnej stosując wytyczne z nowego narzędzia BARTka dostałem ekstra 80 bajtów wolnej przestrzeni na kod … Sterownik używa tylko jednego przerwania a co by było gdyby wykorzystywał ich więcej? 😆

 Więc są to dwie bardzo poważne zalety używania parametru Bascom nosave w swoim kodzie, który od tej pory każdy będzie mógł stosować z sielankową beztroską i zgłębiania „czarnej magii” asebmlera AVR, oraz poznawania od podszewki co się dzieje w trakcie obsługi przerwania. Oczywiście wiedza taka na pewno zaowocowała by każdemu w trakcie budowy swoich urządzeń, ale czy każdemu jest niezbędna? Niech każdy oceni to samodzielnie.
A niewspółmierne zalety tej funkcjonalności stosować może każdy bez względu na stopień zaawansowania i swoich umiejętności, dzięki programowi opracowanemu przez BARTka, o wdzięcznej nazwie NoSave Tool.

przebiegi testowe przed i po zastosowaniu parametru nosave i optymalizacji kodu

Zanim przedstawię sposób używania tego sprytnego narzędzia omówię pokrótce uzysk wydajności wykonywania przerwania, na przykładzie przebiegu czasowego wykonanego przez BARTka w trakcie przeprowadzanych testów. Na zamieszczonym obrazku obserwujemy dwa zestawy przebiegów czasowych. Gdzie Channel 0, obrazuje wystąpienie przerwaniaw osi czasu, a Chanel 1, przedstawia przebieg w którym wyjście zmienia stan na przeciwny właśnie w tym przerwaniu. Teraz jasno widać zwłokę od wystąpienia przerwania do wykonania kodu zmieniającego stan wyjścia …. można powiedzieć „co ten m µC się tak guzdra” – co on robi? A no właśnie kopiuje rejestry na stos … Pamiętajmy, że po zakończeniu obsługi przerwania czeka go do wykonania ponowne kopiowanie rejestrów … tym razem by odtworzyć ich pierwotną wartość ze stosu. Wnioski niech każdy wyciągnie i skomentuje we własnym zakresie

I życie stanie się prostsze

Dla każdego kto będzie posługiwał się programem NoSave Tool. Zasadniczo obsługa tego skromnego narzędzia o wielkiej mocy sprowadza się do wczytania pliku projektu *.obj tworzonego podczas kompilacji kodu do postaci binarnej. Po tej czynności program odwala wilczą robotę analizując wystąpienie przerwań i wszystkie z tym związane pikantne szczegóły. Końcowym efektem działania jest wygenerowana gotowa wstawka w asemblerze do zaszczepienia w swoim kodzie. Program przetwarza informacje i wyłapuje, które rejestry należy utrwalić odkładając je na stos, by w trakcie obsługi przerwania  nie zostały nadpisane ich zawartości. Czego skutkiem jest krótka lista rejestrów, a nie wszystkie, do kopiowania. Stąd bierze się przyrost wydajności w wykonywaniu kodu, którego po prostu jest mniej, a z czego wynika oszczędność na objętości kodu.

Instrukcja w ekspresowym minimum

Programu nie trzeba instalować jest gotowy do pracy po wypakowaniu z archiwum. Po uruchomieniu wyłoni się podstawowe okienko. W części opisanej STATUS jesteśmy informowani o tym co program wykonał, dodatkowo program zachęca nas do wczytania stosownego pliku projektu 🙂 Jak kto ma ochotę, to może sobie na wstępie wczytać plik obj swojego projektu – co wcale nie jest ani konieczne ani potrzebne, a zaspokoi jedynie ciekawość 😛 Ja oczywiście poczyniłem taki krok i ujrzałem wtedy następującą treść: Zaowocowało to wyświetleniem dodatkowych informacji, z których chyba najistotniejszą jest przedstawiona sekcja QUICK INFO. Widać tam użyte w kodzie przerwanie i listę kopiowanych rejestrów …. jest tego trochę.
Dodatkowo program odgraża się by koniecznie dodać parametr Nosave. Oczywiście trzeba to uczynić w kodzie źródłowym, szczegóły podpowiada mini manual dostępny w małym przycisku zatytuowanym SEE.

Więc aby cokolwiek wskórać i osiągnąć opisywany od samego początku rezultat koniecznie należy w deklaracji procedur obsługi przerwań (tworzonego projektu) dodać parametr Nosave.  Tak wstępnie przygotowany kod poddajemy kompilacji. Oczywiście kompilator musi być tak przygotowany i skonfigurowany by zechciał łaskawie utworzyć plik wyjściowy  o rozszerzeniu obj. To właśnie ten plik jest poddawany szczegółowej analizie przez nasze nowe narzędzie.
Po takich przygotowaniach należy obowiązkowo wczytać ten wynikowy plik do programu NoSave Tool. Gdy wykonamy tą czynność, klikając przycisk OPEN OBJECT FILE, a program przeanalizuje sobie i wyłuska co tam potrzebuje, wyświetli nam informację o użytym / użytych przerwaniach i przedstawi kolejne rejestry, których zawartość jest niezbędna do zachowania na stosie, dla prawidłowego funkcjonowania tworzonego programu. Jak widać na moim przykładzie standardowo kopiowane były wszystkie rejestry, a do życia programu niezbędne jest kopiowanie tylko pięciu z pośród nich!!
I co dalej?
Kolejnym krokiem do zbliżającego się sukcesu jest posłużenie się przyciskiem z nazwą przerwania (u dołu okienka). Uruchomiona funkcja przedstawi wstawkę kodu w języku Asembler do zaimplementowania w obsłudze naszego przerwania. W moim przypadku nowe okienko wygląda następująco Dla naszej i swojej wygody (lub na odwrót) BARTek przygotował funkcję kopiującą niezbędny kod do schowka. Przycisk COPY TO CLIPBOARD AND CLOSE. Teraz należy wkleić go (naszą wstawkę) do swojego projektu.

Przedstawię jeszcze dwa obrazki z raportem kompilacji, które to raporty utworzyły się po normalnej standardowej kompilacji w pierwszym przypadku bez użycia parametru Nosave, a kolejny z użycie tego parametru i owocu działania nowego narzędzia …

Podczas rozmowy z autorem przedstawionego wynalazku wypytywałem zawzięcie o przypadki szczególne, i zachowanie programu. Oto jaką otrzymałem odpowiedź:

BART ::ja patrzyłem najpierw na rozkodowane do ASM kody i patrzyłem gdzie on ładuje SREG i zawsze do R24, wiec to jakby zawsze z automatu,

NoSave sprawdza co zostało naprawdę użyte wiec z tym nie ma problemu, on patrzy co kompilator użył,
… a potem program patrzy na jakich operuje rejestrach,
… tam są ciekawostki bo wiadomo ze rejestr może być użyty wielokrotnie,
…ale NoSave kolekcjonuje wszystkie, sprawdza żeby się nie powtarzały, układa w kolejności

Program jest nowym dzieckiem BARTka więc na bieżąco będą pewno zachodziły w nim zmiany. I treść przedstawianych ekranów może być różna, od tej, którą być może będziesz posiadał drogi czytelniku w „swojej” wersji narzędzia.
Jak się stać posiadaczem tego wynalazku?
Sugeruję posłużyć się przyciskiem na witrynie autora w dolnej części jego prezentacji dotyczącej NoSave Tool. 😛  I przekazać dowolne środki na energię życiową czerpaną z piwa … o przepraszam miało być … z paliwa 🙂 Oczywiście ja tak uczyniłem.

A.D. 2017-09-09 na dziś dzień doczekaliśmy się wersji programu oznaczonej 1.10, więc to dobry znak. Narzędzie nie zostało porzucone i pewno można będzie liczyć na więcej. No i fajnie.

Prawdziwym powodem kontynuacji tego wpisu będzie kolejna korzyść odkryta przeze mnie w minionych dniach. Od pewnego czasu grzebię przy obsłudze transmisji ze sprzętowego bloku USART generowanej przez urządzenie zewnętrzne. Zdarzenie oprogramowałem z użyciem Bytematch, będącym parametrem składni konfiguracji Config Serialin.

W takim wypadku zalecane jest

When using the BYTEMATCH option, you must preserve the registers you alter. If you do not know which one, use PUSHALL and POPALL.

zabezpieczenie zawartości używanych rejestrów na czas obsługi zdarzenia. W przypadku gdy programista nie wie, które z nich będą użyte kolejne wskazanie radzi zrzucić wszystkie rejestry … dla świętego spokoju i poprawnego działania programu. Oczywiście kosztem wydajności funkcjonowania. I tutaj znowu pomocny staje się NoSave Tool. Wskaże, które rejestry należy odłożyć i tym samym zadba o wydajność pracy powstającego kodu.