Czy, kiedy i dlaczego warto operować na rejestrach?

[ethanak]

59 minut temu, pmochocki napisał:

To pytanie dość proste - chyba... Operujemy kiedy trzeba

Tylko właśnie chodzi o te "kiedy trzeba".

Jak dla mnie operowanie na rejestrach (a więc i umiejętność) konieczne jest, gdy biblioteka wyższego poziomu do obsługi danego mikrokontrolera nie zawiera koniecznych funkcji.

Przykład z życia: chciałem za pomocą Arduino Nano odczytać sygnał cyfrowy ok. 1V. Piny cyfrowe na to nie reagują (za niski poziom), ADC nie wyrabiał się w czasie z odczytem dwóch linii.

Mogłem albo użyć konwertera poziomów, albo przestawić preskaler ADC. To drugie wydało mi się prostsze i tańsze 🙂

Tyle że dalej w kodzie mam analogRead - nie widziałem sensu ani powtarzania w kodzie tego co jest w bibliotece, ani tym bardziej pisania choćby jednej linijki kodu więcej: wolałem skupić się na interpretowaniu danych.

 

 

 

[Elvis]

Użycie bibilioteki nie zawsze jest możliwe, albo raczej nie każdej. Problemem może być licencja, albo ograniczenia wynikające z norm lub innych wymagań prawnych. Przykładowo biblioteki Arduino raczej nie nadają się do użycia w przypadku systemów krytycznych dla bezpieczeństwa.

[ethanak]

4 minuty temu, Elvis napisał:

Przykładowo biblioteki Arduino raczej nie nadają się do użycia w przypadku systemów krytycznych dla bezpieczeństwa.

Generalizujesz. Gdybyś użył określenia "w większości przypadków" mógłbym się zgodzić. Ale w tej sytuacji na Tobie spoczywa udowodnienie, że digitalWriteFast nie nadaje się do systemów krytycznych.

 

[Elvis]

9 minut temu, ethanak napisał:

digitalWriteFast nie nadaje się do systemów krytycznych

To akurat bardzo proste - czy ta biblioteka spełnia wymagania normy EN62304? Jeśli nie to jest tzw. SOUP (soup software of unknown provenance). Trzeba więc przeprowadzić analizę ryzyka z założeniem że digitalWriteFast zawiera wszelkie, najgorsze możliwe błędy np. przepełnia stos, skacze po pamięci, albo po prostu nie działa. Jeśli takie zachowanie stwarza potencjalne ryzyko to nie można jej użyć. W przypadku innych norm jest chyba podobnie, ale podaję przykład medycznej, bo z nią trochę miałem do czynienia.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

1 minutę temu, Elvis napisał:

czy ta biblioteka spełnia wymagania normy EN62304?

Nie mam zielonego pojęcia. To Ty stwierdziłeś że się nie nadaje.

BTW digitalWriteFast kompilowany jest na jedną (dokładnie: jedną) instrukcję asemblera (bset lub bclr).

[H1M4W4R1]

13 minut temu, Elvis napisał:

W przypadku innych norm jest chyba podobnie, ale podaję przykład medycznej, bo z nią trochę miałem do czynienia.

Zacznijmy od tego, że sprzętu medycznego i wysokiego ryzyka nie programuje się w C/C++ tylko w Rust, którego kompilator jest bardzo rygorystyczny pod względem wszelkich potencjalnych błędów. Jeżeli firma każe pisać w C-family to jest już zamach na ludzkie życie...

Ogólna zasada SOUP bazuje na czystym rozsądku: jeżeli dana technologia może stworzyć zagrożenie dla życia / zdrowia należy ją przeanalizować pod względem każdego możliwego kompletu błędów. Potem te błędy należy zlikwidować, zabezpieczyć albo zrezygnować z użycia technologii. Chińczycy tego nie respektują (miałem okazję rozbierać kilkanaście urządzeń chińskich) i wiele z nich zawiera kardynalne wręcz błędy od braku uziemienia, urządzenie potrafi puścić sobie 230V na obudowę, a nawet gdzieś widziałem backfeed'a HV >1kV na zasilacz.

Z tego też powodu urządzenia przemysłowe (tokarki, frezarki etc.) posiadają wyłącznik elektromagnetyczny i grzybek bezpieczeństwa. Wyłącznik zabezpiecza przed zanikiem prądu (urządzenie samo się nie włączy w losowym momencie), a grzybek przed głupotą użytkownika (używanie tokarki w rękawiczkach).

[Elvis]

12 minut temu, H1M4W4R1 napisał:

sprzętu medycznego i wysokiego ryzyka nie programuje się w C/C++ tylko w Rust

Może tak kiedyś będzie, ale na razie jest C, ewentualnie C++. Zmiana pewnie nie nastąpi szybko, w sumie nie wiadomo czy kiedykolwiek będzie miała miejsce. 

[kaworu]

Dnia 14.12.2022 o 17:13, H1M4W4R1 napisał:

Zacznijmy od tego, że sprzętu medycznego i wysokiego ryzyka nie programuje się w C/C++ tylko w Rust, którego kompilator jest bardzo rygorystyczny pod względem wszelkich potencjalnych błędów. Jeżeli firma każe pisać w C-family to jest już zamach na ludzkie życie...

Mhm, ile mamy certyfikowanych kompilatorów rusta, powiedzmy zgodnych z IEC 61508?