Oryginalność mikrokontrolerów AVR z Chin

[Sabre]

marek1707, tylko, że dla mnie to nie jest babol. Dlaczego nie dopuszczacie do siebie myśli, że coś z tym mikrokontrolerem jest nie tak? I ten błąd powstaje właśnie przez mój, nie do końca zgodny ze sztuką kod. Ten sam program z przerwaniem wywoływanym przez przycisk działa w mikrokontrolerze z TME sterującym 99 diodami i przez kilka tygodni wiszenia lampek na choince i moim synku, który siedział i wciskał przycisk po kilkanaście razy na raz, nigdy nie doszło do sytuacji, w której mikrokontroler przestał reagować na przerwania. Oczywiście pomijam już w tym momencie kwestię sprzętowej kasacji drgań. Przycisk ma kondensator 10nF równolegle i przez 10kΩ jest podciągany do plusa a do pinu mikrokontrolera jest podłączony przez rezystor 100Ω.

[deshipu]

To sprawdzaj ten indeks w najbardziej wewnetrznej petli.

[nse]

Wychodź z podprogramu jak się zmieni indeks, a w pętli głównej wchodź do następnego.

[ Dodano: 16-06-2016, 12:12 ]

Btw, pamiętaj o "volatile" (czy co tam Bascom ma) na tej zmiennej!

Bascom jest wydajny i dla początkujących przygodę z mikrokontrolerami, w starszych wersjach bascoma wiele błędów korygował kompilator im nowsze wersje tym bardziej wymagające świadomości programisty

[Sabre]

@Sabre

Obsługa przerwania ma w tle programu odebrać daną z pilota, a program w pętli głównej ma zadecydować co z tą daną zrobić i jakie zmiany ona wprowadziła, po obsłużeniu tego zezwalasz

na odebranie kolejnej danej z pilota, wtedy pętla główna programu będzie jedynie przerywana na czas odebrania danej co statystycznie trwa ok 10 - 100ms zależy od pilota, takiego sporadycznego zakłócenia w pracy programu nie zauważysz.

Nad takimi problemami siedziałem kilka lat temu i nie miałem z kim o tych problemach pogadać

Napiszę to samo co wyżej, bo widzę, że nie czytasz tego co piszę a tylko się wymądrzasz.

Po obsłużeniu przerwania program wróci w miejsce z którego wyskoczył. Przy sekwencjach zmian koloru, które mam zdefiniowane typu płynąca tęcza kolorów na 100 diodach (no 99 bo jedną spaliłem przez odwrotne przylutowanie kabli zasilających) niemożliwe jest, aby wyskoczyć z tego kodu w tak krótkim czasie jak zapewnia mi aktualna konstrukcja kodu, nawet jeśli jest ona nie do końca zgodna ze sztuką. Taka sekwencja wykonuje się co najmniej kilka sekund, i nawet dopisanie w kilku miejscach kodu warunków na wyskoczenie z niego nie przyspieszy działania do poziomu obecnego. A tylko zanieczyszczę kod masą warunków.

[Elvis]

Sabre, gdybyś znalazł wolną chwilę spróbuj proszę resetowania stosu. Takie rozwiązanie powinno działać bez modyfikacji całej reszty programu.

Oczywiście w pełni zgodzę się, że najczęściej z przerwania wraca się do miejsca jego wystąpienia, ale nie zawsze tak się robi. A skoro napisałeś taki nietypowy program, to dlaczego go nie poprawić?

[nse]

Napiszę to samo co wyżej, bo widzę, że nie czytasz tego co piszę a tylko się wymądrzasz.

Widzę że mama szacunku nie nauczyła, dalej radź sobie sam.

Dziękuję nic tu po mnie

[Sabre]

Napiszę to samo co wyżej, bo widzę, że nie czytasz tego co piszę a tylko się wymądrzasz.

Widzę że mama szacunku nie nauczyła, dalej radź sobie sam.

Dziękuję nic tu po mnie

No wybacz kolego, ale jako jedyny nie napisałeś ani nie zaproponowałeś niczego sensownego a tylko głupie komentarze pod moim adresem.

Nie byłoby tego tematu gdyby podkreślę ponownie ten sam kod, działał tak samo na 3 mikrokontrolerach, z czego 2 pochodzą z Chin a jeden ze sklepu od nas.

EDIT:

Sabre, gdybyś znalazł wolną chwilę spróbuj proszę resetowania stosu.

Sprawdzę to wieczorem w pierwszej kolejności, jak dosiądę się do płytki i całego kodu.

[jnk0le]

To już się robi tak zagmatwane że tylko .lss całości może rozwiązać wszelkie wątpliwości.

Z wrzuconego kodu Bit_send, bez wglądu w całość, ciężko również wywnioskować co właściwie ma robić lub jaki ma efekt wrzucanie rejestrów na stos bez żadnego kodu do ich zdejowania:

$asm

Bit_send:                                                   
  ldi r17, Ile_ledow                                   
  clr R18                                               
  clr r19
  ;****************************************
  LDI XL , LOW(LABEL3)                                 
  LDI XH , HIGH(LABEL3)
  PUSH  XL <-------------------
  Push  XH <------------------
  LDI XL , LOW(LABEL2)
  LDI XH , HIGH(LABEL2)
  PUSH  XL <-------------------
  Push  XH <------------------
  LDI XL , LOW(LABEL1)
  LDI XH , HIGH(LABEL1)
  PUSH  XL <-----------------
  Push  XH <-----------------
  IN R23, SPL  <--- SP jest ładowany już po wrzuceniu danych na stos                                            
  in R24, sph                                           
Led_loop_:
...

A wracając do tematu dyskusji; to jeśli przerwanie wywołuje podprogram który czeka w pętli nieskończonej na kolejne przerwanie, to nie tylko musisz zdejmować ze stosu adresy powrotu zarówno w przerwaniu jak i w podprogramie czy tablice alokowane na stosie(SP), ale również zrzucone rejestry na wejściu do przerwania.

Coś takiego to tylko w assemblerze się widuje gdzie ma się pełną kontrolę nad stosem a nie w BASCOM'ie.

Oczywiście pomijam możliwość zastosowania "chińskich jednostek", przez alternatywnego producenta, gdzie 2kB to w rzeczywistości 1 kB i objawia się to właśnie nachodzeniem stosu na zmienne.

[marek1707]

Piszę wolno więc przy tak burzliwej dyskusji moje posty szybko się dezaktualizują, ale:

Babol jest, bo każde przerwanie z którego nie wyjdziesz poprawnie przez return odkłada na stosie adres powrotu. Tak więc stos rośnie. A teraz próbujesz nas przekonać, że wszystko jest OK bo nie zauważyłeś problemów? Mogę zrozumieć taki punkt widzenia: nie widzisz nic złego w działaniu - to problem rozwiązany ale zauważ, że to tylko oznacza, że nie zauważasz kłopotów. To nie to samo. Jeśli procesor po którymś przyciśnięciu tak zniszczy RAM, że np. przejdzie przez własny wektor RESETu - sprawa załatwiona. Jeśli nikt z was nie tego nie zauważył, spoko, jesteście zadowoleni. Ale my staramy się dojść przyczyn Twoich problemów, bo naszym zdaniem je masz. Jeśli wg Twojej oceny tak nie jest bo efekty na to nie wskazują, rozchodzimy się każdy z jakimś tam samozadowoleniem. Ja widzę co robisz źle, Ty nie uznajesz tego za problem.

Pisałem o braku determinizmu działania takich rzeczy i to jest tu najważniejsze. To także odróżnia - w przypadkach niedookreślonych - jedną sztukę procesora od drugiego. Opadający wskaźnik stosu będzie robił to w przypadkowych momentach i niszczył przypadkowe (w sensie akurat wykonywanych przez program rzeczy) lokacje. Rejestry procesora to też RAM więc nawet jeśli jakaś pętla jest sterowana licznikiem zorganizowanym przez kompilator w rejestrze, jej licznik lub cokolwiek innego także mogą zostać zniszczone.

Rozwiązanie sugerowane przez Elvisa jest rozpaczliwe, ale w tej sytuacji powinno pomóc. Pod warunkiem, że nasza diagnoza i model błędu są poprawne...

Przemyśl to i wymyśl strukturę tego kodu tak, by wszelkie mechanizmy wykorzystywać zgodnie z ich naturą - to może być naprawdę fajne ćwiczenie. Jedyną rzeczą nieprzerywalną w tym urządzeniu jest funkcja wysyłania strumienia danych do diodek. Tego nie może przerwać nawet obsługa odbiornika IR i to powinna być sekcja krytyczna. Przy dużej liczbie diodek to może stanowić poważny problem bo niektóre kody IR mogą być nieodbierane. Trzeba się z tym pogodzić ale zauważ, że wysyłanie danych może być bardzo rzadkie - tylko wtedy gdy zmienia się stan łańcucha. To trochę ratuje, ale nie znika problemu zupełnie. Wszystko inne, łącznie z organizacją programu, liczeniem numeru efektu czy samą jego generacją może być przerywane. Nawet obsługa przycisku (debouncing) powinna być robiona w jakimś okresowym przerwaniu od timera a nie za pomocą kondensatorów - tak robi się w przedszkolu. Mając w systemie zdarzenie typu "wykryto wciśnięcie" możesz go obsłużyć kiedy chcesz. Zwłoka nawet kilkudziesięciu ms niczego nie zmienia i jest niezauważalna. A co procesor ma innego do roboty?

Jeżeli dopuścisz obsługę przerwań w czasie wysyłania strumienia do LED, trzeba będzie pogodzić się z faktem chwilowego uszkadzania zawartości łańcucha, ale tylko podczas manipulacji na pilocie a to i tak zmienia używany efekt.

Same efekty nie powinny być pisane jak jedna wielka pętla zajmująca procesorowi wiele sekund - to także błąd w założeniach. Gdybyś zrobił jakiś systemowy timer np odliczający tick=50 czy 100ms to miałbyś podstawę czasu. Bazując na takich interwałach możesz zaprojektować efekty, które zmieniają stan łańcucha co taki czas (to chyba wystarczająco często) jednocześnie umożliwiając procesorowi robienie wielu rzeczy na raz. Także zatrzymanie i zmianę efektu w dowolnej chwili, bo proces nadzorujący przycisk i zmiany wykonywany jest równolegle ze wszystkim innym. Trzeba tylko usiąść i zastanowić się jak te wszystkie rzeczy na raz pogodzić. Chociaż pewnie nie masz wykształcenia informatycznego i doświadczenia w pisaniu kodu wielo- i współbieżnego, to nie jest trudne a jak już raz przez to przejdziesz, Twoje programy będą od tej pory zupełnie inne. Sam się zdziwisz.

Hm, w sumie to nie wiem, czy warto dalej to o tym pisać. To kwestia podejścia do swojego hobby w ogóle a do programowania w szczególności. Moim zdaniem tu nie chodzi o "spryt" czy efekty końcowe a o dochodzenie do pewnego rodzaju mistrzostwa w samym procesie powstawania produktu. Jak w kenjutsu, rowerowaniu czy nawet.. elektronice. Nigdy nie jesteś najlepszy, zawsze jest coś w Tobie do poprawienia a gdy się zatrzymasz w rozwoju lub uznasz, że osiągnąłeś efekt - przegrałeś (choćby sam ze sobą). Rozumiem, że nie każdy tak to widzi.

[Elvis]

Trochę się czuję pokrzywdzony traktowaniem mojej propozycji rozwiązania problemu jako rozpaczliwej.

Po pierwsze to jedyna jak na razie metoda na sprawdzenie, że faktycznie problem leży w obsłudze stosu. Jeśli napiszemy cały program od nowa, może mieć inne błędy, albo program może działać chociaż problem nadal istnieje. Zmieniając tylko jeden element na raz mamy kontrolę nad testowanym problemem.

Druga sprawa to sam pomysł - w pierwszej chwili też pomyślałem że to paskudna metoda na obsługę przerwań. Z drugiej strony sam ostatnio siedzę w obsłudze przerwań, gdzie powrót wcale nie następuje to miejsca wywołania przerwania Nieco przypadkiem Sabre napisał własną namiastkę systemu operacyjnego - dlaczego tego nie docenić? Co prawda jest to uproszczona wersja, ale po poprawieniu obsługi stosu może całkiem fajnie działać.

[marek1707]

Hej, to nie miało być uwłaczające. Rozpaczliwa, bo nie naprawia błędu w założeniach a tylko łata dziurę dla tego jednego, konkretnego przypadku. Jest prosta i pewnie skuteczna - jeśli w ogóle rozumiemy o co tu chodzi..

Nie traktuję napisania zupełnie nowego kodu jako metody naprawy istniejącego, tylko jako próbę wymuszenia innego spojrzenia na problem w przyszłości. No i odróżniłbym przypadkowe działanie od celowego pisania mini-systemu operacyjnego. Następnym razem, gdy urządzenie będzie miało robić jeszcze kilka innych rzeczy Sabre - stosując dotychczasowe podejście - będzie bez szans. Posiadając umiejętność tworzenia kodu "udającego" prawdziwą pracę współbieżną wielu procesów na raz, problemem zaczyna być jedynie dostępna moc obliczeniowa i zasoby pamięciowe. Wystarczy zachować trochę programistycznej higieny i skomplikowane programy nagle stają się proste. Być może inną (lepszą? trudniejszą?) ) drogą rozwoju będzie rozpoczęcie używania jakiegoś RTOSa, ale coś z tym trzeba zrobić. Już tu widać, że nawet w tak prostym kodzie trzeba było łapać się prawą ręką za lewe ucho a i tak powstał.. hm, potworek. Szkoda na to czasu.

[nse]

@marek1707:

"Tego nie może przerwać nawet obsługa odbiornika IR i to powinna być sekcja krytyczna."

Na moment obsługi LED'ów wystarczy zablokować przerwania, pozostanie do rozwiązania weryfikacja poprawności odebranej ramki danych, na tyle ile jeszcze pamiętam to funkcje odbiorcze w bascomie maja flagę "err" do obsługi takich błędów.

Rozkazy z pilota są cyklicznie wysyłane, tak że nawet jak jakaś ramka będzie czytana od "połowy" to następną już się odczyta prawidłowo w całości. W tym produkcie nie ma znaczenia czy będą wyłapywane wszystkie ramki wysyłane z pilota

Ten kod można w całości napisać w Bascomie tylko wystarczy trochę pomyśleć

Debuger bascoma odlicza czas pomiędzy ustawionymi breakpointami, wszystko spokojnie można dopracować. Nie trzeba kolegom udowadniać jaki to się genialny kod napisało, błędy popełniamy wszyscy.

[Elvis]

Dlaczego od razu potworek. Jest to nieco inny kod niż można byłoby się spodziewać, ale jeśli się mu bliżej przyjrzeć ma swój urok.

Moim zdaniem procedurę każdego efektu można traktować jako kolejne zadanie, a procedura przerwania pełni rolę schedulera w tym systemie. Każdy "proces" zaczyna od początku, więc nie ma potrzeby zachowywania kontekstu. Jedyny problem to zarządzanie stosem, stąd moja propozycja żeby podczas przełączania zadań, resetować wskaźnik stosu.

W sumie gdyby dodać zachowywanie rejestrów każdego zadania i dać im oddzielne stosy mielibyśmy ciekawy kernel systemu. Tak też jest to namiastka systemu, chociaż mocno uproszczona.

[nse]

@Elvis: Twoje rozwiązanie jest genialne, tylko kolega "Sabre" nie ma pojęcia o assemblerze i źle reaguje na wskazywane błędy w napisanym przez siebie kodzie. Więc nie wiadomo czy analizujemy problem związany z procesorem, jego programem czy jego EGO. Przepraszam Koledzy ale ja zgłupiałem.

EDIT:

... hmm, tak głębiej myśląc ustawienie wskaźnika stosu na początek zniszczy i adresy powrotu z przerwania ?? , wtedy program zacznie pracować od resetu procesora ...

Tak sobie gdybam, mam nadzieje że kolega nie jest tak wrażliwy jak Sabere ??

Chyba że resetujemy wskaźnik pozostawiający ostatnio odłożony adres powrotu ??

[ Dodano: 16-06-2016, 14:08 ]

... tak tylko ustawienie wskaźnika stosu na początkowy adres powrotu, nie naprawi już uszkodzonej zawartości ramu ...

[Elvis]

nse, ustawienie wskaźnika stosu sprawi że będzie on pusty, albo chociaż po każdym przerwaniu/przełączeniu zadań będzie w tym samym stanie.

Adres powrotu z przerwania nie ma znaczenia, ponieważ program z przerwania nie wraca - nie używa instrukcji RETI, więc resetu też nie będzie.