• Witaj na Forum Arduino Polska! Zapraszamy do rejestracji!
  • Znajdziesz tutaj wiele informacji na temat hardware / software.
Witaj! Logowanie Rejestracja


Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Deklarowanie/inicjalizacja pinów Wemos w Arduino IDE?
#11
Widzę że znowu wyrzucili @semi z elektrody to wrócił tutaj trolować.
Używanie int ma pewien sens. W języku C powinien to być typ najwydajniej obsługiwany przez daną architekturę - i najczęściej tak jest, chociaż małe AVR są niestety wyjątkiem. Z drugiej strony dla początkujacego to absolutnie bez różnicy, czy zmarnuje jeden bajt, czy dwa pamięci - to tylko nauka i początki, nie można od razu wymagać za wiele. A zastosowanie int jest po prostu najprostsze.
 
Odpowiedź
#12
@elvis czy nie lepiej od razu zwrócić na to uwagę, że zżera to niepotrzebnie pamięć i do tego jest nieeleganckie. Czy deklaracja #define Pin 11 nie jest lepsza od int Pin = 11;. Widać od razu co jest zmienną a co deklaracją pinu.
Co Ty na to?
 
Odpowiedź
#13
Użycie #define jest lepsze i faktycznie przykłady ze zmiennymi nie są dobrym pomysłem - ale już zmienianie typu int na uint8_t jest bez sensu.
Natomiast co do elegancji, to można byłoby długo dyskutować. W końcu cała idea "sztucznej" numeracji pinów w Arduino jest i zawsze będzie mniej efektywna niż używanie prawdziwych portów i pinów - więc to jest coś-za-coś. Mamy numerację niezależną od sprzętu, ładną i wygodną, ale płacimy za to zużyciem pamięci, zarówno flash, jak i ram.
 
Odpowiedź
#14
Edit: zanim mi ktoś zarzuci, że piszę nieprawdę - wycofuję że #define jest lepsze.
Ogólnie nic nie jest ani absolutnie lepsze, ani absolutnie gorsze. Dla osób przyzwyczajonych od C będzie to lepsze (stąd mój poprzeni post), ale już w C++ jest to gorsze i niezalecane rozwiązanie.
Faktycznie zamiast zmiennej int należałoby użyć coś innego, ale niekoniecznie #define - nawet jeśli to daje optymalny kod wynikowy. Ogólnie używanie makr nie jest zalecane i wyłącza kontrolę typów. Więc jak napisałem wcześniej wycofuję to co za szybko napisałem - #define nie jest "lepsze", ale faktycznie mniej pamięci marnuje niż int.
 
Odpowiedź
#15
(08-01-2020, 14:29)elvis napisał(a): to wrócił tutaj trolować.
Trolujesz to Ty nazywając trolowaniem wskazówki jak lepiej pisać kod co sam przyznałeś. Widzę, że nadal zazdrość nie przeszła?
Trolowałeś w sprawie WS2812 na Forbocie, pisząc zwyczajne bzdury, wprowadzając w błąd. Kto jest więc trolem?
Trudne zagadnienia w przystępny sposób - praktyczny kurs Arduino w Elektronice dla Wszystkich https://elportal.pl/.
 
Odpowiedź
#16
Wiem, że to znowu nie na temat, ale mógłbyś wskazać gdzie są te bzdury odnośnie WS2812? Chętnie poprawię jeśli coś źle napisałem.
 
Odpowiedź
#17
Panowie prosiłem w innym temacie, aby nie zaśmiecać wątków wzajemnymi uprzedzeniami. Tak dobrze już szło, było rzeczowo bez prywatnych wycieczek. Pokory trzeba, pokory i jeszcze raz pokory i wydaje mi się, że im więcej wiedzy i umiejętności tym więcej jej trzeba.
 
Odpowiedź
#18
(08-01-2020, 14:54)elvis napisał(a): Ogólnie używanie makr nie jest zalecane i wyłącza kontrolę typów.

Dyrektywa #define pozwala zdefiniować stałą, funkcję, słowo kluczowe, oraz makro.
#define measurePin 0, nie jest makrem tylko definicją stałej.
Jeśli się boisz braku kontroli typów w tym przypadku (choć gwarantuję, że nie masz się czego obawiać), to po każdym wystąpieniu zdefiniowanego wyrażenia odwołuj definicję. Oczywiście definiuj ją na nowo przed każdym następnym wystąpieniem.
Jak się poczyta trochę bibliotek Arduino, to można zauważyć, że w/w metoda jest powszechnie stosowana.
Jeśli masz problem z kodem lub sprzętem, zadaj pytanie na forum. Nie odpowiadam na PW, jeśli nie dotyczą one spraw forum lub innych tematów prywatnych.

[Obrazek: SsIndaG.jpg]
 
Odpowiedź
#19
Ja nie mam problemów z używaniem #define i często używam. Jednak ostatnio w C++ jest to bardzo niemile widziane - stąd była moja uwaga, że nie jest to najlepsze rozwiązanie. Wszystko zależy co i po co chcemy zrobić. W każdym razie brak typu jest jedną z głównych wad definicji.
Pisząc makro miałem na myśli dyrektywę dla preprocesora - w kodzie, który zobaczy kompilator nie będzie już śladu po D0, czy A0 - będzie to po prostu 1, czy inna wartość. Dlatego niektóre błędy mogą być łatwo przeoczone.
W przypadku C++ pewnie lepszym rozwiązaniem byłoby użyć constexpr, chociaż programiści "wysokopoziomowi" na pewno stwierdzą że nawet const jest lepsze.
Moim zdaniem nie istnieje jedno, jedynie słuszne rozwiązanie. Więc pisanie, że coś jest lepsze jest mocno ryzykowne - dla jednego lepsze jest niższe zużycie pamięci, dla kogoś innego statyczna kontrola typów.
 
Odpowiedź
#20
Zmienna zamiast #define to jeszcze dostęp do wskaźnika.
Arduino wie, że raz masz na myśli pin D0, raz pin A0 również wtedy, gdy dana funkcja jest przeznaczona np. do czynności związanych z pinem analogowym. Można zrobić analogRead(0) i będzie dotyczyło to pinu A0. digitalWrite zadziała dla pinu cyfrowego, chyba że wyraźnie napisze się A0.
W ESP jest jednak nieco inaczej, pin D0 to wcale nie jest pin GPIO0  i wpisanie raz digitalWrite(0), a drugi digitalWrite(D0) zadziała dla różnych pinów. Dla każdej płytki mogą być inne definicje co jest D0, D1, itd. Np. dla NodeMCU w pliku pins_arduino.h jest między innymi:
static const uint8_t D0  = 16;
static const uint8_t D1  = 5;
static const uint8_t D2  = 4;
static const uint8_t D3  = 0;
static const uint8_t D4  = 2;
static const uint8_t D5  = 14;
static const uint8_t D6  = 12;
static const uint8_t D7  = 13;
static const uint8_t D8  = 15;
static const uint8_t D9  = 3;
static const uint8_t D10  = 1;
Dla Wemos Mini jest raczej to samo, ale przeglądając różne pliki wewnątrz pakietu ESP można sprawdzić jakie są różnice. W ESP32 zrezygnowano raczej z oznaczeń Dcośtam i należy się odwoływać do numeracji GPIO.
Miło być decenianym https://buycoffee.to/kaczakat
 
Odpowiedź
  


Skocz do:


Przeglądający: 1 gości