Skocz do zawartości
Zaloguj się, aby obserwować  
dambo

Biblioteka do łatwego sterowania I/O Arduino

Pomocna odpowiedź

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ć.

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

@dambobrzytwa Ockhama przestała obowiązywać?

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

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ś.

Udostępnij ten post


Link to post
Share on other sites
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 😉

Udostępnij ten post


Link to post
Share on other sites

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.

Udostępnij ten post


Link to post
Share on other sites

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.

 

 

Udostępnij ten post


Link to post
Share on other sites
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

Udostępnij ten post


Link to post
Share on other sites

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.

Udostępnij ten post


Link to post
Share on other sites

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ś.

Udostępnij ten post


Link to post
Share on other sites

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 🙂

Udostępnij ten post


Link to post
Share on other sites
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ę.

Udostępnij ten post


Link to post
Share on other sites

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...

Udostępnij ten post


Link to post
Share on other sites

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.

Udostępnij ten post


Link to post
Share on other sites

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).

 

Udostępnij ten post


Link to post
Share on other sites
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ć.

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Gość
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

Zaloguj się, aby obserwować  

×
×
  • Utwórz nowe...