Biblioteka do łatwego sterowania I/O Arduino

[dambo]

Poniższe posty zostały wydzielone z tego tematu: 

-------------------------------------

Dnia 14.08.2019 o 10:16, ethanak napisał:

To zrób w programie coś w stylu:

#define LED 6
 ...
 
  pinMode(LED, OUTPUT);
  digitalWrite(LED, 1);

 

 

Z tym można pójść jeszcze o krok dalej/czytelniej - jest taka biblioteka - https://github.com/dambo1993/Output

I wtedy przykład użycia wygląda:

#include <Output.hpp>

Output led(LED_BUILTIN);

void setup() 
{
	led.init();
}

void loop() 
{
	led.toggle();
	delay(1000);
}

czy tam led.on()/led.off().

 

Ale projekcik pokazuje jak można fajne rzeczy z połączeniem mechaniki itp z bardzo krótkim kodem robić.

[ethanak]

@dambobrzytwa Ockhama przestała obowiązywać?

[dambo]

Czemu? Idąc tym tropem "bytem nadmiarowym" jest to, że w DigitalWrite podajesz stany HIGH, LOW całkiem niepotrzebnie i musisz sobie zerknąć na schemat podłączenia, żeby zobaczyć jaka jest logika - tu już wjeżdzamy na grunt tego, że wszystko można zrobić na milion sposobów i przekonywanie się, że jakiś jest "jedyny słuszny" - komuś to przypasuje to będzie używał, inni nie i też ok - zawsze jest kompromis coś kosztem czegoś.

[ethanak]

1 godzinę temu, dambo napisał:

i musisz sobie zerknąć na schemat podłączenia, żeby zobaczyć jaka jest logika -

A jak w przypadku Twojego dziwoląga? Nie patrząc na schemat i nie wiedząc w jaki sposób realizowana jest metoda on czy off powiesz jak jest podłączona? Poza tym nie chodziło mi o zastąpienie znanej konstrukcji z digitalWrite jakąś nieznaną - a użycie nazwy do autodokumentacji. Ty tu nic nie zmieniłeś, a jedynie skomplikowałeś całość wprowadzając zupełnie niepotrzebną bibliotekę. A programy baaardzo nie lubią być za skomplikowane 😉

[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

[dambo]

Właśnie o to chodziło, że dzięki temu nie musisz na to patrzeć, bo masz napisane led.on(), a nie digitalWrite(LED_PIN, HIGH) - co po samym takim zapisie nie wiesz czy zapali coś, czy zgasi + w konstruktorze podaje się dodatkowy parametr w jeśli logika jest "odwrotna" i wtedy zawsze on to on i off to off - ze zmianą tylko w jednym miejscu.

Czy to jest użycie dodatkowej biblioteki - tak, oczywiście. Czy jest potrzebna, czy nie - to już zależy.

[ethanak]

Powiem Ci tak...

Swego czasu powstał Wiring,którego spadkobiercą jest Arduino i którego zadaniem było właśnie uproszczenie operacji wejścia-wyjścia. Zamiast bawić się w rejestry i bity, wystarczyło podać numer pinu mikrokontrolera i stan, jaki chcesz a nim osiągnąć. (lub co chcesz z niego odczytać) - et voilá!

Trzeba pamiętać, że Wiring/Arduino powstał dla elektroników, którzy raczej wiedzą jak się do mikrokontrolera diodę podłącza i żadne udziwnienia nie są im do tego potrzebne. Owszem, warto sobie w programie zaznaczyć która dioda jest podłączona do którego pinu... i tyle.

Spojrzałem sobie na tę "bibliotekę" i przyznam się, że tak koszmarnego kawałka kodu dawno nie widziałem. Gdybyś tam jeszcze przeliczył w konstruktorze numer pinu na parę port/bit - od biedy można by to było uznać za ciekawe rozwiązanie, szybsze od tradycyjnego digitalWrite. Ale opakowanie pinMode/digitalWrite w naskrobane na kolanie klasy i chwalenie się tym na forum (szczególnie w komentarzach do kodu pisanego przez początkującego) zakrawa na absurd i - przynajmniej jak dla mnie - jest objawem ciężkiego przypadku megalomanii.

Żeby nie być gołosłowny - przykład z Twojego kodu:

if(!_inverse)
	{
		digitalWrite(_pin, HIGH);
	}
	else
	{
		digitalWrite(_pin, LOW);
}

@Treker, do Ciebie należy decyzja, ale ja bym wydzielił posty od pierwszego napisanego przez @dambo do oddzielnego wątku ze stosownym tytułem, najlepiej dotyczącym pisania bibliotek na Arduino i jak to się robi porządnie.

 

 

[dambo]

1 godzinę temu, ethanak napisał:

Spojrzałem sobie na tę "bibliotekę" i przyznam się, że tak koszmarnego kawałka kodu dawno nie widziałem. Gdybyś tam jeszcze przeliczył w konstruktorze numer pinu na parę port/bit - od biedy można by to było uznać za ciekawe rozwiązanie, szybsze od tradycyjnego digitalWrite.

Przeliczył na port/bit i utracił w ten sposób warstwę abstrakcji nad pinami? I ponownie - w opisie na samej górze jest informacja, że jest to obudowanie digitalWrite. Nie miało być szybsze, tylko czytelniejsze (oczywiście możesz uznać to za mniej czytelne - spoko).

Znów wspomniałeś odnośnie tego zerkania w schemat, że elektronicy nie potrzebują itp - no a kilka postów wcześniej wytłumaczyłem dokładnie o co chodzi - masz w kodzie luzem linijkę:

digitalWrite(LED_PIN, HIGH);

czy zamiast LED_PIN może być RELAY_PIN czy cokolwiek - i jak po tej jednej linijce jesteś w stanie stwierdzić, czy ona coś uruchamia, czy deaktywuje? I można to dla czytelności okomentować przy każdym wywołaniu lub obudować w dodatkowe funkcje gdzie po ich nazwie będzie to jednoznaczne co to ma na celu i nie skakanie potem po pliku, żeby zobaczyć jaką tam logikę zastosowano przy dopisywaniu kolejnego digitalWrite() + ułatwia to zmianę w przypadku innego podłączenia itp. 

Miała to być warstwa abstrakcji - czyli wyciągnięcie ogólnej funkcjonalności (on/off), a ukrycie jak to się się robi (czyli bez potrzeby podawania ciągle pinu i stanu LOW/HIGH). A warstwy abstrakcji to w arduino coś normalnego.

Chyba wystarczająco opisałem jaki był zamiar tego itp + z twojej strony już się zaczynają argumenty ad personam, więc chyba na tym zakończę wątek.

Co do przeniesienia - oczywiście można to wydzielić/czy może też wszystko do kosza wylecieć za offtop

[grg0]

Z programowania to jestem zielony. Czy takich rzeczy nie załatwia się odpowiednimi deklaracjami stałych i zmiennych, przecież program powstaje pod konkretny schemat urządzenia. Wtedy można sobie zamiast HIGH pisać co się che, np. ZGASZONE, ON, OFF, PRZEKAZNIK_WL itp.

[dambo]

No dokładnie - sposobów masz kilkanaście/dziesiąt/set - możesz tak jak podałeś zrobić do tego wszystkiego makra per projekt i wtedy je per projekt to piszesz, lub też można to jakoś uniwersalniej zrobić i też potem łatwo to przenosić. Wszystko jest zawsze kompromisem coś kosztem czegoś.

[ethanak]

Dlaczego utracić kontrolę nad pinami? Jeśli podasz numer pinu w konstruktorze to już Cię mało obchodzi co tam w środku klasy siedzi. A obliczenie pary port/bit i tak jest w końcu potrzebne - po co więc liczyć to za każdym razem w digitalWrite, jeśli można to policzyć raz w konstruktorze? Popatrz na kod digitalWriteFast - tam masz wszystko policzone w czasie kompilacji, a żadnej kontroli nad pinami nie tracisz.

@grg0 dokładnie tak się powinno robić - o to właśnie chodziło twórcom Wiringa. Wyobraźmy sobie opisywany niedawno problem sterowania zwrotnic: Do jednego pinu podłączone są dwie ledy (czerwona i zielona) i zawsze zapalona jest jedna z nich. Można sobie zrobić definicje typu "czerwona to HIGH a zielona to LOW" i patrząc na program każdy będzie wiedział jak te ledy podłączyć. Jeśli zacznę operować on i off to nie będzie to miało żadnego odniesienia do rzeczywistości, a po maksymalnie tygodniu zapomnę co jest do czego podpięte (nie mówiąc o kimś kto widzi to pierwsxy raz). 

Już słyszę argument, że przecież można zrobić klasę bazującą na Output z metodami green i red... ale to też nie zmieni faktu słabej czytelności.

Jeśli argument o brzytwie Ockhama do kogoś nie dociera - proponuję rozszyfrowanie skrótu BUZI 🙂

[dambo]

1 godzinę temu, dambo napisał:

Przeliczył na port/bit i utracił w ten sposób warstwę abstrakcji nad pinami?

9 minut temu, ethanak napisał:

Dlaczego utracić kontrolę nad pinami? Jeśli podasz numer pinu w konstruktorze to już Cię mało obchodzi co tam w środku klasy siedzi. A obliczenie pary port/bit i tak jest w końcu potrzebne - po co więc liczyć to za każdym razem w digitalWrite, jeśli można to policzyć raz w konstruktorze? Popatrz na kod digitalWriteFast - tam masz wszystko policzone w czasie kompilacji, a żadnej kontroli nad pinami nie tracisz.

Ja o jednym - Ty o czymś innym - gdzie napisałem o utracie kontroli?

Dzięki wykorzystaniu digitalWrite w środku klasy mogę łatwo przeskakiwać pomiędzy platformami - czy to AVR, czy ESP/Nordic, bo digitalWrite zapewni mi nad tym abstrakcję.

[ethanak]

I dlatego digitalWrite to powinien być fallback dla nieznanych procesorów. Zajrzałeś do kodu funkcji o której wspominałem?

@Treker pliz przenieś to gdzieś, bo wprowadzamy (przepraszam, ja też) niepotrzebny bur^H^Hałagan w całkiem interesującym wątku...

[dambo]

Znowu odbijasz "piłeczkę w bok" - tak zajrzałem - i dokładnie tego się spodziewałem + widać ograniczenie w platformach do kilku - dlatego użyłem digitalWrite, dzięki któremu się tym nie muszę przejmować. Ponownie -> coś kosztem czegoś - a moim celem nie było przyspieszenie wystawienia stanu na pin używając arduino godzę się na takie zachowanie. A jeśli potrzebowałbym szybszej wersji - no to wtedy pod spodem w klasie mogę to podmienić z digitalWrite na wersję fast i cała reszta projektu pozostaje bez zmian.

[ethanak]

Nie podmienisz w klasie na digitalWriteFast, bo ten wymaga znajomości pinu już w czasie kompilacji. Ograniczenie działa dokładnie tak samo jak w bibliotekach Arduino dla AVR. Dla ESP masz zupełnie inne biblioteki ze swoją wersją digitalWrite (nie wymagającą przeliczenia port/pin).

 

[dambo]

3 minuty temu, ethanak napisał:

Nie podmienisz w klasie na digitalWriteFast, bo ten wymaga znajomości pinu już w czasie kompilacji. Ograniczenie działa dokładnie tak samo jak w bibliotekach Arduino dla AVR. Dla ESP masz zupełnie inne biblioteki ze swoją wersją digitalWrite (nie wymagającą przeliczenia port/pin).

 

Ok - faktycznie się zapędziłem tutaj - mój błąd - nie zrobi się tego w ten sposób jak napisałem wcześniej - chyba bardzo na to czekałeś.

Co do ESP - no dokładnie o tym piszę od kilku postów - że użycie to digitalWrite zapewnia mi abstrakcję nad tym, a twoje sugerowane przeliczenia port/pin ograniczyłyby platformy - dzięki digitalWrite nie muszę wiedzieć jak to jest przeliczane - znajduje się to w implementacji digitalWrite dla danej platformy jaką właśnie używam. I kolejny raz powtarzam - nie chciałem uzyskać większej prędkości działania (bo chyba po to wskazałeś na bibliotekę fast + no może trochę miejsca się też by tym zyskało - na tym też mi nie zależało), tylko na nie klepywaniu wszędzie digitalWritów z dwoma parametrami - tylko je ukryć.