W arduino przeglądałem jak działają funkcje "pod spodem" i funkcja "digitalWrite" na którą zawsze wszyscy narzekają, że jest wolna jak porównują arduino i natywne C w środku zawsze przed ustawieniem pinu deaktywuje przerwania i potem je uruchamia.
Pierwszy raz się spotkałem z tym i musiałem się zastanowić nad celem tego - przyzwyczaiłem się do makr ustawiających piny jak w BB gdzie nigdy nie dodawało się tego, jednak po przemyśleniu wydaje mi się, że powinny one też być "otoczone" cli() i sei(). Zabezpiecza to przed tym gdy podczas wystawiania danych na port odczytamy coś z portu, a w czasie tego wejdziemy w przerwanie, które też coś ustawia na danym porcie i w efekcie możemy nadpisać tamtą wartość - dobrze to rozumiem?
Szansa na wystąpienie tego wydaje się bardzo mała, ale chyba nigdy bym nie wykrył, że takie coś wystąpiło w moim programie.
Mógłby ktoś się wypowiedzieć na ten temat?

Arduino jak zauważyłem posiada wiele uproszczeń i rzeczy zdawało by się idiotoodpornych. Jeśli jednak programista wie co robi to te dziwne zabiegi są całkowicie zbędne.

_________________
http://www.sylwekkuna.com

Ten problem może wystąpić wszędzie, gdzie z tego samego portu korzystają rzeczy w mainie i w przerwaniach - czyli już w rozdziale o multipleksowaniu w BB.
Zgadzam się, że jest to forma idiotoodporności - tylko dalej kwestia czy jest to zbędne, czy nie. Jak robimy uniwersalnie bibliotekę to powinniśmy się zabezpieczyć przed takimi rzeczami - tak mi się wydaje, bo jak pisałem - powodzenia potem z debugowaniem tego w układzie.

Tak jak będziesz robił andruino II ostatnia krew - to wtedy możesz dodać w przeciwnym wypadku myśl i pisz program tak jak tego wymaga projekt

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

a coś merytorycznego też można prosić? Czyli to nie jest żaden problem i się tym nie przejmować? Jeśli tak wystarczyło to tak napisać...

Mirek odpowiedział prawidłowo

I tyle w temacie
Jeśli wiesz co robisz i przestrzegasz zasad dobrego programowania to żadne zabiegi z main nie będą wpływały na przerwania i odwrotnie.

_________________
http://www.sylwekkuna.com

chyba nie warto o nic pytać - liczyłem na jakieś wyjaśnienie tego problemu/dyskusję - pytam "jak robić żeby było dobrze i dlaczego tak" i dostałem odpowiedź "myśl i rób tak, żeby było dobrze" z jakimś "arduino ostatnia krew" na dodatek - może za bardzo weekend wleciał i się nie dogadamy o tej porze

Ale co tu tłumaczyć ? rozpatrywać dlaczego tak andruino sobie wymyśliło ? No to ci wyjaśnię - andruino musi przemyśleć różne nawet najbardziej durne ruchy "programisty" ... dlatego zabezpiecza się na 1000000 sposobów robiąc przy tym miliard nadmiarowych operacji. Mało kto zajmując się andruino nawet zdaje sobie sprawę dobrze co to są przerwania. Więc czego ty oczekujesz ? Jaki jest efekt takich nadmiarowych operacji ? ... dość prosty - mega spowolnienie różnych operacji i duża nadmiarowość generowanego kodu wynikowego we Flash. Podobnie jest w Bascom ... Twórcy tych ala języków programowania muszą wziąć na siebie jak wspominałem tzw idiotoodporność a i tak im się to nie udaje do końca bo im mniej taki programista zadaje sobie trudu żeby nauczyć się czegoś na temat procka i jego działania "od środka" tym więcej ten programista popełnia błędów. Ale spokojnie są też zalety tych języków:

1. rzeczywiście gdy ktoś chce stworzyć ot tak - przypadkowo raz na rok albo raz na całe życie jakieś urządzonko - odtworzyć je z netu do swoich potrzeb - no to proszę bardzo - często mu się to udaje
2. jest to zawsze jakiś tam startw świat mikrokontrolerów
3. na takich językach - środowiskach - można na szybko sprawdzić czy coś działa jeśli w C na początku nie wychodzi - gdy się znajdzie jakiś przykładowy kod w andruino czy bascomie
4. akurat do andruino istnieje ogromna społeczność na świecie która tworzy pierdyliard różnych bibliotek - to nic że ogromna ich ilość działa wadliwie albo jest napisana tragicznie i działają mega wolno - ale zawsze coś tam da się odpalić


o to tobie chodziło ? O taką merytoryczną dyskusję ? o rozpatrywanie dlaczego warto zastosować pierdyliard zabezpieczeń zawsze i w każdym momencie ?

Powiem ci szczerze - że nie warto nawet nad takimi rzeczami się pochylać i dyskutować ... więcej zrobisz rozpoczynając własną naukę w C, własne próby, pisząc własne kody i nawet jak nie będzie zawsze wychodziło - to po to masz forum żeby dopytać a nie tam rozpoczynać jałowe dyskusje dlaczego coś tam ktoś wymyślił w andruino.

Poza tym - w prockach AVR wiele operacji dostępu do pinów portów jak chodzi o pojedyncze piny wykonać można w sposób atomowy o ile wiesz co to oznacza. Krótko mówiąc po to są w asemblrze AVR taki rozkazi jak sbi czy cbi żeby było to możliwe i kompilator C z tego korzysta garściami. W takich przypadkach stosowanie cli i sei przed i po jest po prostu czystym nonsensem. A w andruino jak mówiłem jest jeszcze pierdyliard innych nonsensów więc nie wymagaj żeby je wszystkie tutaj opisywać bo szkoda czasu. Lepiej się pouczyć C;) będzie on wtedy lepiej spożytkowany.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

O tych rozkazach nie wiedziałem - czyli te "podstawowe" ustawianie pinów przez makra zostanie zamienione na sbi i cbi, a stan portu nie będzie czytany i po problemie - w sumie to by była odpowiedź na moje pytanie w jednym zdaniu. Chociaż też nie "lepiej się pouczyć C" bo to trochę zjazd poziom niżej do assemblera.

Nie do końca tak jest. Instrukcje te mają swoje zalety, przez co są bardzo chętnie używane przez kompilator. Niemniej mają też pewne ograniczenia:

• zakres działania tych instrukcji - można je wykonać tylko na rejestrach o adresie mniejszym lub równym 0x1F (31)w przestrzeni adresowej I/O; na szczęście przypadki, gdy mikrokontroler ma rejestry I/O poza tym zakresem są rzadkie i dotyczą raczej mikrokontrolerów o dużej ilości portów/pinów I/O,
• mogą wykonywać operacje tylko na jednym bicie jednocześnie, więc w przypadku instrukcji operującej na kilku bitach np. PORTD |= 0b00101100; kompilator może uznać, że intencją programisty jest zmiana stanu wszystkich bitów w tym samym czasie (takcie zegara) i nie rozbije operacji na szereg instrukcji SBI, bo to wprowadziłoby pewne opóźnienie.

Oczywiście w większości przypadków wyłączanie przerwań będzie zbędne, jednak trzeba mieć na względzie przypadki szczególne.


Myślę, że dobrze to rozumiesz, ale problem dotyczy nie tylko portów I/O, ale także (a może nawet głównie) zmiennych w pamięci RAM współdzielonych przez przerwanie i pętlę główną programu (w niektórych przypadkach nawet tych ośmiobitowych). Tutaj akurat wyłączanie przerwań na czas modyfikacji takiej zmiennej w pętli głównej programu jest bardzo często (choć nie zawsze) niezbędne dla zapewnienia poprawności działania programu i głównie na tym problemie warto się skoncentrować. Mikrokontrolery AVR (przynajmniej tiny i mega), nie posiadają instrukcji ASM do bezpośredniego modyfikowania zawartości komórki pamięci RAM, więc zmienną należy wczytać do rejestrów, zmodyfikować i ponownie zapisać do RAM, co wymaga wykonania kilku(nastu) instrukcji ASM. Jeśli w tym czasie wystąpi przerwanie, które również modyfikuje tę samą zmienną...

To tak tylko gwoli uzupełnienia. Jak wspomniał powyżej kolega Mirek, nie sposób przewidzieć tutaj wszystkich możliwych sytuacji oraz zależności i podać krótką, jednoznaczną odpowiedź.

Dziękuję bardzo kolego andrews za super rozjaśnienie! Czyli da się bez jakiś tekstów o "andruino druga krew" zwyczajnie wyjaśnić temat.

Zobacz rozwinięcie asemblerowe a zobaczysz, że ustawienie czy skasowanie pinu to JEDEN rozkaz. bezzsensowne jest zatem wyłączanie i to w zły sposób przerwań. Jedyny przypadek, kiedy miałoby to sens, to duże AVR gdzie porty są poza SFR, w obszarze, w którym inne AVR maja SRAM. W takiej sytuacji ustawianie czy kasowanie pinu to 3 rozkazy
POBIERZ
ZMODYFIKUJ (AND/OR)
ZAPISZ

Dlaczego napisałem, że źle są wyłaczane a właściwie włączane przerwania? Jeśli napiszemy kod
CLI
CUDA NA KIJU
digiotalWrite
KOLEJNE CUDA
SEI
to część kodu, mimo iż miała wykonać się z wyłączonymi przerwaniami, wykona się z włączonymi.

Do blokowanie przerwań należy używać ATOMIC_BLOCK konkretnie ATOMIC_BLOSK( ATOMIC_RESTORESTATE )
Zadziała to tak
zmienna = PSW
CLI
program w bloku
PSW = zmienna

Jeśli w kodzie jesteśmy pewni, że przerwania są włączone i wydaje się, że należy zrobić
CLI
POBIERZ
ZMODYFIKUJ (AND/OR)
ZAPISZ
SEI

ale można inaczej, tak dla zmyłki
CLI
POBIERZ
ZMODYFIKUJ (AND/OR)
SEI
ZAPISZ
Dlaczego? Kto wie?



Niby Arduino jest idioto odporne, mnie wygląda na to, że pisali je idioci. Jest napisane zwyczajnie po głupiemu. Bascom, niepozbawiony błędów, jest chyba bardziej przemyślany.

Co dlaczego?

Dlaczego sei jest przez zapisem portu? Przecież może się zdarzyć, że po sei nasąpi przerwanie, które zmodyfikuje zawartość portu. Po zakończeniu przerwania port zostanie ustawiony zawartością ustalona w programie głównym, więc to co zostało zrealizowane w przerwaniu, nie odniesie skutku, ściślej odniesie na krótką chwilę.
Logika podpowiada, że sei powinno być po zapisie do portu.

Nie sprawdzałem tego w andruino - ale jeśli jest tak jak piszesz - i sprawdziłeś to dokładnie - to jakaś masakra. Nie sądziłem że aż tak można spierniczyć sprawę ale też byłaby to kolejna cegiełka do tego dlaczego ludziom w tym andruino zawsze coś się sypie w tych programach.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Nie wiem dlaczego, powiedz

Ja wiem.

A to dlatego aby przerwanie mogło jeszcze zmodyfikować stan pinu/portu przed zapisem, jedna instrukcja mniej do wykonania.

Wyobraź sobie że wystawiasz sygnał dla defibrillatora I reanimujesz człowieka, pod palec ma podpięty czujnik pulsu i po oddanym strzale przywracania tętna, zabierasz się do kolejnego strzału, a gość wlasnie odzyskał tętno i czujnik zgłosił, że przywrócono akcje serca, jakby nie została zmodyfikowana twoja decyzja to człowiek dostałby jeszcze jednego strzała i mógłby tego nie przeżyć.

Od taka opowiastka przyszła mi do głowy względem pytania czemu zapis po sei()

Pozdrawiam

To nie jest jedyny przypadek. Przestrzeń adresowa IO posiada zakres od 0x00 do 0x3F z czego tylko zakres od 0x00 do 0x1F jest dostępny dla instrukcji SBI oraz CBI (tylko te instrukcje gwarantują atomowość operacji ustawienia/zerowania bitu rejestru). Pozostałe mogą korzystać tylko z instrukcji IN oraz OUT, czyli operacje już nie są atomowe, bo wymagają trzech instrukcji. My tu rozważamy akurat rejestry związane z portami IO, ale przecież problem może dotyczyć prawie każdego rejestru specjalnego przeznaczenia (SFR). Np. rejestr TCCR0A w ATmega644P jest pod adresem 0x24 (w przestrzeni IO), czyli jest jeszcze w zakresie, ale już nie jest dostępny dla instrukcji SBI i CBI, więc jeśli modyfikujemy bity tego rejestru zarówno w pętli głównej, jak i w przerwaniach (co wcale nie jest rzadkością), to mamy analogiczny problem , jak w przypadku portów.

Tak czy inaczej, sam fakt, że rejestr znajduje się w przestrzeni IO nie gwarantuje atomowości - musi być jeszcze w pierwszej połowie zakresu.


Prawdopodobnie dlatego, żeby skrócić czas wyłączenia przerwań (czyli czas reakcji na przerwanie) do minimum. Zgodnie z deklaracją producenta:
która gwarantuje, że instrukcja następująca bezpośrednio po instrukcji SEI (czyli w tym przypadku zapisanie zmodyfikowanej wartości z powrotem do portu) zostanie wykonana przed wejściem mikrokontrolera w procedurę obsługi przerwania (nawet jeśli to przerwanie już oczekuje na realizację).

W którymś tam katalogu arduino, albo w linku https://github.com/arduino/ArduinoCore- ... _digital.c, można znaleźć

widać, że nawet nie znali dobrze bibliotek kompilatora, bo ja bym użył ATOMIC_BLOCK.

------------------------ [ Dodano po: 1 minucie ]


Widzę, że dobrze znasz AVR. Rzekłbym dogłębnie.

------------------------ [ Dodano po: 12 minutach ]

Arduino, z konieczności, nie z własnej woli, zajmuje się sporadycznie od mniej niż roku. Ciągle coś mi nie działa, zaglądam w źródła i ... przerażenie w oczach. To co widzę, to w pijanym widzie by mi do głowy nie przyszło! Brak debugera dopełnia wszystkiego. Można się ratować wczytując kod Arduino do AS7 i .... debuger nie działa! Sprawdzam co mu jest? Ano wyłączony JTAG! Co za idiota wyłącza go przez FUSES gdy i tak startuje bootloader, który może programowo go wyłączyć?
Chyba wystąpię do pracodawcy o dodatek do pracy w szkodliwych warunkach jakim jest Arduino.
Nawet konstrukcja PCB jest do du....y. Płytka ma konwerter USB-UART na MEGA16U4 z kwarcem 16MHz a mega328 jest taktowana z ceramicznego 16MHz. Szok!

dobre

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Nie wiem gdzie pracujesz ale powinieneś pomyśleć o zmianie pracodawcy. W żadnej porządnej firmie nie spotkałem się osobiście żeby użytkowali Arduino, czy to HW czy ten ich śmieszny framework. I nie mówię tego żeby Ci dopiec ale jako poważną radę zawodową bo wiem jak patrzą na rozmowach kwalifikacyjnych na Ciebie "techniczni" jak im mówisz że masz doświadczenie w embedded a pracowałeś w Arduino. To jest zabawka dla dzieci i dla dorosłych którymn się nie chce i chcą sobie coś na szybko poskładać z marnym efektem.

Projekty robię na ARM (STM32) a te jak wiesz praktycznie nie są wspierane przez Arduino (np H743). Jeśli już coś jest (F1, F4) nie używają DMA itp tylko "machają pinem" jak w AVR. Z pewnością wiesz, że w ten sposób niewiele da się osiągnąć.
Czasem, aby szybko coś sprawdzić robię to na Arduino. Jak działa, to mam np gotowe, choć niedoskonałe funkcje ale w połączeniu z notą katalogową układu/modułu mogę szybko taki kod przenieść na ARM. Gdy coś działa na arduino kiepsko przyglądam się funkcjom a tam np SPI do wyświetlacza graficznego emulowane programowo Nie dość, że SPI na AVR jest wolne, bo max to jakieś FCPU / 4 to jeszcze SPI emulowane przez machanie pinem! na to może wpaść tylko programista na Arduino.

no chyba że tak, uspokoiłeś mnie

Czasem też zamiast grzebać się godzinami w notach wspomagam się libsami arduino bo czasem z kodu idzie szybciej zrozumieć jak dany układ obsłużyć niż z wypocin producenta układu w jego nocie. Nie mniej jednak, za długo w ten kod nie można patrzeć bo można się zarazić złymi nawykami

ProgramistaAVR czy to dobra odpowiedź? Śledzę ten wątek i uważam, że jest mega ważny i interesujący ale nie wiem czy wszystko dobrze rozumiem a bardzo bym chciał rozumieć

Zła.
Chodzi właśnie o coś dokładnie odwrotnego, aby ewentualne przerwanie nie mogło się wykonać. Przeważnie rozkazy wykonują się od razu. Gdyby tak było to sekwencja:
SEI
ZAPIS PORTU
byłaby ryzykowna, po po SEI mogłoby wykonać się przerwanie, które mogłoby zmodyfikować stan portu. Błąd byłby ciężki do znalezienia to rzadki ale w AVR, zaraz po SEI nie może wykonać się przerwanie, dopiero w kolejnym rozkazie co gwarantuje, ze przerwanie nie zmodyfikuje stanu portu przed jego zapisem. W praktyce zadział to jak sekwencjia
ZAPIS PORTU
SEI
w innych CPU ale nie pytaj jakich bo nie pamiętam wiele z dawnych CPU. Coś tam mi świta, że w Z-80 zaraz po DI (blokada przerwań) modło być wykonanie przerwanie (nie wiem czy we wszystkich trybach czy tylko w IM2 - wektoryzowane) a 6502 odblokowanie przerwań miało skutek natychmiastowy.

Kiedyś zabieg z wykonaniem rozkazu zaraz po odblokowaniu przerwań był używany w pracy krokowej. Na NMI wymuszało się L. CPU prawie cały czas był w przerwaniu. Wykonanie kroku to opuszczenie przerwania gdzie w po przywróceniu znacznika przerwania (W 6502 był on na stosie, w rejestrze stanu, umieszczany sprzętowo, w Z-80 osobny przerzutnik) musiał wykonać się jeden rozkaz po którym program ponownie skakał w przerwanie. Nie pamiętam czy przypadkiem nie taki mechanizm był w CA-80 ale naprawdę wiele lat minęło.

------------------------ [ Dodano po: 34 minutach ]

Od siebie jeszcze dodam, ze w ARM nie używam ATOMIC_BLOCK. Blokuję w NVIC tylko przerwania, które mogłyby przeszkadzać. W AVR takie rozwiązanie raczej się nie przyda. Przerwania są blokowane głównie po to, aby nie zakłócić jakiś krytycznych czasowo funkcji np generowania bitu dla WS2812. Przy czasie impulsu 400ns przerwanie trwające kilka us rozwali wszystko. Nawet wolna transmisja 1-Wire też będzie szwankować. W ARM z reguły to nie problem, bo jest dziesiątki jak nie setki razy szybszy od AVR (taki H743 może być taktowany nawet 480MHz a są i takie co 600MHz mają). W ARM przerwania się blokuje gdy np i w przerwaniu i w programie głównym modyfikuje się np rejestry UART. W takiej sytuacji wystarczy jednak zablokować przerwania od UART.

W AVR też może być podobna sytuacja np licznik wielo bajtowy w przerwaniu. Aby go odczytać w programie głównym trzeba zatrzymać przerwania ale zamiast wyłączać wszystkie wystarczy zablokować przerwanie od timera modyfikującego licznik.

Jest też prosta metoda aby One Wire czy WS2812 na AVR obsłużyć w przerwaniu. Tak jak w przypadku One Wire są dwa rozwiązania czyli timer albo UART tak w przypadku WS2812 SPI lub UART. W necie można znaleźć przykłady a dla One Wire przez UART to nawet Maxim wydał odpowiednią notę katalogową. Szczegóły można tam przeczytać a w skrócie, to ustawia się UART na 9600 Zapisuje FF i sprawdza co wróciło (TX-RX jest zapętlone przez bufor OC). Jak FF to nie zgłosił się slave, jak inna wartość to było zgłoszenie. Komunikacja podobnie tyle, że na 115200. Wysłanie 1 to zapis FF, zera to zapis 0. Odczytanie bitu to zapis FF i odczyt, jak FF to slave zwraca 1, jak <> od FF to zwrócił 0.
Proste a działa na każdym mikrokontrolerze. Próbowałem na AVR, ARM wiem, że działa na porcie COM PC powinno na konwerterze USB-UART ale nie próbowałem. Można sobie zorganizować komunikację w tle (na przerwaniach). WS2812 zarówno na AVR jak i ARM próbowałem na SPI i UART. Działa na przerwaniach ale na AVR lepiej robić to na UART.

Dzięki za obszerne wyjaśnienie i rozwianie wątpliwości co do zagadki

Bardzo mnie ten temat zaciekawił, nawet przygotowałem sobie taki prosty kodzik, w którym co sekundę zmieniam stan pinu na PD7 oraz za każdym razem jak przyleci przerwanie INT zmieniam stan na PD0. Słowem przykład, jak kodu nie pisać

W tym kodzie delay może być przykładem jak nie pisać ale w demonstracji można jednego delay użyć.
Przykładem jak nie pisać jest całe Arduino. Na początek przerwanie T0

Przerwanie to jest obligatoryjne. Tak jak w przypadku UART, I2C itd nie musisz używać biblioteki, tak tu jesteś skazany na taki twór (raczej potwór).
W konsekwencji nie wykorzystać przerwania od przepełnienia T0. Jak to, że używane są sztuczki z przeskakiwaniem licznika aby odliczać w ciągu sekundy 1000 impulsów mogę zrozumieć (PWM można uruchomić na T0) tak braku możliwości modyfikacji tej funkcji lub chocby prostego skoku do funkcji

pojąc nie mogę.

Inny "kwiatek", obsługa wyświetlaczy w trybie równoległym na mega2560 przez "machanie pinem":

jakby mega2560 nie miała buss keepera. Jak dodać zatrzask na przerzutniku D np 74HC74 to oszczędzamy jeden pin AVR bo linia AD0 jest zarówno linią danych jak i A8 (przy okazji tracimy jedną na ALE więc bilans jest na 0). A8 łączymy z RS LCD i zależnie czy zapisujemy pod adres parzysty XRAM czy nieparzysty będzie to komenda lub dane dla LCD. Niby zysk z użycia XRAM jest niewielki bo 2 cykle* ale to 2 razy mniej a do wyświetlacza 480x320 trzeba zrobić ponad 150 tysięcy przesłań aby wypełnić cały wyświetlacz (i tak takiego bufora w RAm AVR nie da się zrobić ale może to być zewnętrzna RAM) co przy 16MHz (mega2560 max 16MHz) daje osczzędność czasu prawie 200ms!


* zapis machanie pinem:
ST X,Rx ; 2 cykle
CBI PORT,WR ; 1 cykl
SBI PORT,WR; 1 cykl
zapis sprzętowy (XRAM)
ST X,Rx ; 2 cykle

Cóż "machanie pinem" to dewiza Arduino tak samo jak delay.

Mała poprawka
zapis machanie pinem:
OUT PORT,Rx ; 1 cykl
CBI PORT,WR ; 1 cykl
SBI PORT,WR; 1 cykl

zapis sprzętowy (XRAM)
ST X,Rx ; 2 cykle

Oszczędność wynosi więc 33 a nie 50% ale chciałbym płacić 33% mniej za wszystkie towary.