Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2594
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    189

Posty napisane przez Elvis


  1. Komunikaty o błędach wskazują na zbyt małą ilość pamięci RAM dla sterty (heap) maszyny wirtualnej javy. To dość dziwne, ale na wszelki wypadek proponuję sprawdzić ustawienia JVM.

    Google powinien podpowiedzieć jak to zrobić, przykładowe linki:

    http://www.messiahpsychoanalyst.org/wikihow/index.php/How_to_Increase_Java_Memory_in_Windows

    https://stackoverflow.com/questions/17369522/set-default-heap-size-in-windows

    • Lubię! 1

  2. Specjalnie jeszcze raz przetestowałem - i u mnie też nie widać różnicy. Od 3,5V które deklaruje producent diody świecą z taką samą jasnością. Wcześniej wykonałem serię pomiarów i moim zdaniem od napięcia zależy prąd pobierany przez ws2812b kiedy są wyłączone, czyli im wyższe napięcie tym więcej prądu się marnuje. Natomiast różnica między "ciemnym" prądem, a pobieranym podczas świecenia jest niezależna od napięcia. Nie mam jak tego zmierzyć, ale moim zdaniem ta różnica to prąd faktycznie płynący przez diody świecące, więc ws2812b ma wyjścia prądowe, chociaż na wejściu pobiera prąd zależny od napięcia.

    ws2812b_pomiary10.thumb.png.c5330e6787539ff10b9ff0d12b197566.png

    W tych pomiarach, kolumna PWM=0 określa prąd (w miliamperach) jaki płynie gdy diody są wyłączone. Przy PWM=64 wypełnienie wynosi 25%, ale ciekawa jest ostatnia kolumna, czyli różnica między tymi prądami. Jak widać jest ona (w granicach błędu pomiaru) stała.

    • Lubię! 1

  3. Widzę, że pisząc cokolwiek w internecie trzeba niesamowicie uważać na słówka - faktycznie źle się wyraziłem, na pewno z Arduino i atmegii 328p da się jeszcze niejedno wycisnąć. Co do obsługi przerwań to nie byłbym pewien, czy to dobry kierunek - standardowe przerwanie od timera zajmuje ponad 6us, a transfer jednego bitu - 1,25us. Więc nawet mając 3 bity do przesłania (np. używając UART), zaczyna brakować czasu. Tak jak napisałem wcześniej - ws2812b są o wiele bardziej tolerancyjne na przerwy w komunikacji niż podaje specyfikacja, więc użycie przerwań i SPI, PWM lub UART pewnie zadziała, tyle że to nie będzie sterowanie zgodne z dokumentacją i to miałem na myśli pisząc o zmianie platformy.

    W tym co napisałem chciałem pokazać że za pomocą Arduino UNO można sterować nawet dość długim łańcuchem diod ws2812b. Nie jest to jedyne możliwe rozwiązanie i postaram się jeszcze opisać inne możliwości - dlatego wspomniałem o innych platformach, chociaż może niezbyt dobrze dobrałem słowa.


  4. Choinki jeszcze nie kupiłem, więc są ostatnie chwile na przygotowania 😉 Natomiast czy wrażenia artystyczne są takie ważne nie jestem pewien - w każdym razie oświetlenie choinki to dla mnie dobry pretekst do zajęcia się ws2812b, których trochę nazbierałem a jakoś ciągle brakowało czasu.


  5. Pisanie w języku C lub C++ programów, które mają działać z dokładnością do cykli procesora jest w sumie bez sensu, ale postanowiłem chociaż spróbować. Używając analizatora oraz dobierając mocno empirycznie wartości udało mi się przygotować taki kod na wysyłanie bitu zerowego:

    static inline void send_bit_zero(void)
    { 
      PORTD |= _BV(6);
      _NOP();
      PORTD &= ~_BV(6);
      for (uint8_t i = 0; i < 4; i++)
        _NOP();
    }

    Najważniejsze jest małe opóźnienie między ustawieniem stanu wysokiego na wyjściu, a powrotem do stanu niskiego - to raptem jeden _NOP().

    Aby wysłać bit o wartości "1" trzeba dodać większe opóźnienie:

    static inline void send_bit_one(void)
    { 
      PORTD |= _BV(6);
      for (uint8_t i = 0; i < 8;i++)
        _NOP();
      PORTD &= ~_BV(6);
    }

    Teraz już można napisać cały program. Jak wspominałem bity są wysyłane zaczynając od najbardziej znaczącego, kolejność kolorów to GRB

    #define LED_PIN         6 
    
    void setup()
    {
      DDRD |= _BV(6);
    }
    
    static inline void send_bit_zero(void)
    { 
      PORTD |= _BV(6);
      _NOP();
      PORTD &= ~_BV(6);
      for (uint8_t i = 0; i < 4; i++)
        _NOP();
    }
    
    static inline void send_bit_one(void)
    { 
      PORTD |= _BV(6);
      for (uint8_t i = 0; i < 8;i++)
        _NOP();
      PORTD &= ~_BV(6);
    }
    
    static inline void send(uint8_t value)
    {
      for (uint8_t i = 0; i < 8; i++ ) {
        if (value & 0x80)
          send_bit_one();
        else
          send_bit_zero();
        value <<= 1;
      }
    }
    
    void loop()
    {
      cli();
      for (int i = 0; i < 24; i++) {
        send(0x01);
        send(0);
        send(0);
      }
      sei();
    
      delay(10);
    }

    Gdy podłączymy analizator zobaczymy, że efekt jest dużo gorszy niż biblioteka Adafruit_Neopixel, ale co ważne działa poprawnie - testowałem nawet z 4 x 144 diodami.

    Tutaj wynik dla 24 diod:

    ws2812b_20.thumb.png.25788b15a9a8f5328e6c14f0392c4ad1.png

    Problemy pojawiają się po transmisji bajtu - powroty z funkcji, obsługa pętli itd zajmuje czas 😞 To niestety widać podczas transmisji:

    ws2812b_20b.thumb.png.307a42b79aada1c7ced35f0adab07471.pngws2812b_20c.thumb.png.6bfdc8bf75f2558f98ef0ca5832ab87b.png

    Jak widać napisanie dobrego programu do sterowania ws2812b nie jest łatwe - ten który przygotowałem działa, ale nie jestem z niego dumny. Chciałem natomiast przetestować moje rozumienie komunikacji z ws2812 i pokazać że to nie czarna magia. Po prostu trzeba dbać o dokładne czasy generowanych przebiegów. Co więcej sprzęt potrafi nam wybaczyć nawet więcej niż gwarantuje dokumentacja.

    • Lubię! 2

  6. Żeby lepiej zrozumieć sterowanie ws2812b postanowiłem spróbować napisać własną obsługę tych diod. Od razu chciałbym wyjaśnić, że nie mam aspiracji do napisania lepszej biblioteki niż Adafruit_Neopixel - kod tej biblioteki został wielokrotnie przetestowany, napisany w asemblerze i świetnie zoptymalizowany. Jest więc pod prawie każdym względem lepszy - tym czego mu brakuje to czytelność, ale nie można mieć o to chyba pretensji. Ja chciałbym tylko napisać prosty kod prototypowy, który pozwoli mi zrozumieć sterowanie ws2812b.

    Na początek samo sterowanie liniami GPIO - ws2812b wymaga raczej szybkiego sterowania, więc zanim zabiorę się do pracy trzeba upewnić się, że jest to wykonalne.

    Każdy, kto miał do czynienia z Arduino wie jak proste jest używanie funkcji digitalWrite() i sterowanie pinami. Zacznę więc od wręcz banalnego programu:

    #define LED_PIN         6 
    
    void setup()
    {
      pinMode(LED_PIN, OUTPUT);
    }
    
    void loop() {
      digitalWrite(LED_PIN, HIGH);
      digitalWrite(LED_PIN, LOW);
    }

    Podłaczam analizator i mogę zobaczyć co udało mi się uzyskać:

    ws2812b_18.thumb.png.d2621004697185c50e3fbd144c5a6f63.png

    Szerokość stanu wysokiego to 3,8 us, a do sterowania ws2812b konieczne są ~0,4us - więc digitalWrite() jest miłe i sympatyczne, ale zupełnie się nie nadaje.

    Na szczęście pod Arduino są dostępne też inne biblioteki. Spróbuję użyć FastGPIO (https://github.com/pololu/fastgpio-arduino)

    Nie znam tej biblioteki za bardzo, więc jeśli program jest niepoprawny to proszę śmiało pisać. W każdym razie udało mi się przygotować coś takiego:

    
    #include <FastGPIO.h>
    
    #define LED_PIN         6 
    
    void setup()
    {
      FastGPIO::Pin<LED_PIN>::setOutput(1);
    }
    
    void loop() {
      FastGPIO::Pin<LED_PIN>::setOutput(1);
      FastGPIO::Pin<LED_PIN>::setOutput(0);
      FastGPIO::Pin<LED_PIN>::setOutput(1);
      FastGPIO::Pin<LED_PIN>::setOutput(0);
    }

     

    Efekt działania programu wygląda następująco:

    ws2812b_18b.thumb.png.54b71f8194ac377d37b1a055725b93ef.png

    Jak widać impuls ma teraz szerokość 0,252us - to 15 razy lepiej niż przy użyciu digitalWrite !

    Poprzednio sterowanie wyjściem było tak powolne, że czas spędzony poza pętlą loop() nie miał praktycznie znaczenia. Używając szybszej biblioteki możemy jednak zobaczyć, że dwa impulsy są generowane z odstępem równym ich szerokości, ale kolejna przerwa jest trochę większa (ma 0,5us). Wywołanie funkcji loop() oraz pętli głównej trochę zajmuje, więc mierząc czasy trzeba o tym pamiętać.

    Na koniec spróbujmy zupełnie pominąć biblioteki Arduino i bezpośrednio odwołać się do rejestrów mikrokontrolera

    #define LED_PIN         6 
    
    void setup()
    {
      DDRD |= _BV(6);
    }
    
    void loop()
    {
      PORTD |= _BV(6);
      PORTD &= ~_BV(6);
      PORTD |= _BV(6);
      PORTD &= ~_BV(6);
    }

    Teraz wyniki są już prawie takie jak powinny:

    ws2812b_18c.thumb.png.5dbfa3c767294763b7cd026c9bc11ee4.png

    Arduino UNO jest taktowane zegarem o częstotliwości 16MHz, co oznacza że czas wykonywania instrukcji to 62,5ns (albo więcej). Skoro uzyskaliśmy szerokość impulsu 126ns to znaczy że zmiana stanu wyjścia wymaga dwóch cykli maszynowych. Nie jest źle, ale w asemblerze biblioteki Adafruit_Neopixel pewnie mogą osiągnąć więcej.

    W każdym razie ja postanowiłem zostać przy tej wersji - nadal jest to język C, ale jak widać wydajność starej szkoły bezpośredniego dostępu do rejestrów jest trudna do pobicia nawet przez C++.

    Przy okazji mała dygresja odnośnie przerwań - jak wspominałem wcześniej biblioteka Neopixel wyłącza obsługę przerwań na czas całej komunikacji z ws2812b. Mając prosty program testowy można ładnie zobaczyć dlaczego:

    ws2812b_19.thumb.png.ff935ba0d10ac30175f98ec776752639.png

    Jak widzimy obsługa przerwania zajmuje prawie 6,5us i wówczas program nie może "machać" pinem. Dlatego obsługując ws2812b autorzy biblioteki wyłączają przerwania - żeby w trakcie transmisji nie pojawiały się przerwy trwające kilka mikrosekund.

    • Lubię! 1

  7. Skoro zasilanie pasków ws2812b nie stanowi już problemu, czas poświęcić kilka chwil na sterowanie nimi. Jak już wcześniej wspominałem, użycie Arduino oraz biblioteka Adafruit_Neopixel (https://github.com/adafruit/Adafruit_NeoPixel) niesamowicie ułatwia zadanie - właściwie wystarczy podłączyć przewody, wgrać przykładowy program ewentualnie dostosowując liczbę sterowanych diod i gotowe.

    Oczywiście nie wszystko jest takie idealne, więc może warto dokładniej przyjrzeć się takiemu rozwiązaniu, poznać jego zalety i wady, a przede wszystkim poznać lepiej sposób sterowania ws2812b.

    Ma początek trochę dokumentacji. Okazuje się że do WS2812B znajdziemy kilka różnych datasheet-ów. Przykładowo:

    Na pierwszy rzut oka różnice nie są duże, ale w pewnych momentach istotne.

    Każdy moduł ws2812b składa się z układu sterującego oraz trzech diod świecących (czerwonej, zielonej i niebieskiej).

    ws2812b_14a.thumb.png.13108d7414c13911e61ae7a743d29f36.png

    Moduł nie dość że jest mały to posiada raptem 4 wyprowadzenia. Dwa służą do zasilania, a pozostałe to wejście i wyjście danych.

    Dzięki posiadaniu również wyjścia danych możliwe jest łatwe łączenie ws2812b w długie łańcuchy - wyjścia modułów są po prostu łączone z wejściami kolejnych.

    Oznacza to, że cała komunikacja z mikrokontrolerem ogranicza się do jednego sygnału, czyli wejścia pierwszego modułu w całym łańcuchu.

    W dokumentacji znajdziemy opis sterowania ws2812b, która opiera się na przesyłaniu trzech możliwych kodów: bitu o wartości 0, 1 oraz sygnału reset.

    ws2812b_14.thumb.png.8de4194f1fded434f909427f7b45ebbe.png

    Jak widać diagramy są raczej proste, pozostaje rozszyfrować ile wynoszą zaznaczone na nich czasy, czyli T0H, T0L, T1H, T1L oraz Treset.

    Okazuje się że każda dokumentacja podaje trochę inne wartości:

    ws2812b_15.thumb.png.05cfc638b44ae0be31ede5633351f710.pngws2812b_15b.thumb.png.ecd0311fb9c1b759c4ad70fc98f82cee.pngws2812b_15c.thumb.png.d5c207d6579b681f1b8a0c25256a8050.png

    Na szczęście różnice nie są ogromne, widzimy więc że dla bitu 0 mamy mieć przez ok. 0,4us stan wysoki, a następnie przez 0,8us stan niski. Dla bitu o wartości 1, najpierw przez 0,8us stan wysoki, a następnie przez 0,4us stan niski. W przypadku resetu, stan niski ma trwać co najmniej 50us - ale może być dowolnie długo.

    Teraz możemy zobaczyć jak wygląda sterowanie 24 diodami za pomocą Arduino oraz biblioteki Adafruit_NeoPixel. Kod programu jest banalnie prosty:

    #include <Adafruit_NeoPixel.h>
    
    #define NUMPIXELS   24
    #define PIN         6 
    
    Adafruit_NeoPixel pixels(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);
    
    void setup()
    {
    }
    
    void loop()
    {
      pixels.begin(); 
      pixels.clear(); 
      for (int i = 0; i < 24; i++)
        pixels.setPixelColor(i, pixels.Color(0x00, 0x01, 0x00));
      pixels.show();   
    }

    Jego działanie polega na bardzo słabym wysterowaniu wszystkich 24 diod - wartość 0x01 oznacza 1/256 wypełnienia PWM dla diody zielonej. Okazuje się że nawet tak małe wysterowanie zapewnia całkiem widoczne świecenie diody. Wartość wybrałem jednak z innego powodu, chodziło o łatwiejsze przeanalizowanie wyników odczytanych analizatorem.

    Na początek cała transmisja:

    ws2812b_16.thumb.png.79ade23957db8b21a884fd2551e72f16.png

    Jak widzimy po prawej stronie, zajmuje ona ok. 720us. Policzmy, mamy 24 diody, każda ma 3 składowe po 8 bitów dla każdej. Czyli 24 x 3 x 8 = 576 bitów danych. Transmisja każdego bitu ma według dokumentacji trwać 1,25us (+-0,6us), więc wychodzi nam idealnie to co zmierzyliśmy. Między transmisjami jest dużo wolnego czasu, kiedy na linii danych jest stan niski - dzięki temu układy ws2812b wykrywają reset transmisji i wiedzą kiedy rozpocząć przesyłanie nowych danych.

    Teraz możemy przyjrzeć się transmisji bitów

    ws2812b_17.thumb.png.09842882dd0fd8fbf1caf1f72d209f0a.png

    Ogólnie większość danych testowych to zera, przy pierwszym przesyłanym zerze widzimy czasy: stan wysoki, czyli T0H ma 312us, a stan niski to pozostałe 9,938us. Wartości jak widzimy odpowiadają dokumentacji.

    Teraz dwa słowa o kolejności danych: najpierw przesyłane jest 8 bitów dla diody zielonej pierwszego modułu ws2812b, następnie 8 bitów dla czerwonej, a na koniec dla niebieskiej. Jeśli mamy więcej niż jeden ws2812b w łańcuchu to bezpośrednio po danych dla pierwszego, przesyłane są dane dla drugiego i kolejnych. Kolejność barw jest więc trochę nietypowa to GRB.

    Dane dla każdej diody przesyłane są zaczynając od najbardziej znaczącego bitu.

    W ramach testów używany był kod:

    pixels.setPixelColor(i, pixels.Color(0x00, 0x01, 0x00));

    Biblioteka Neopixel używa zanacznie popularniejszej kolejności kolorów, czyli RGB, więc nasz przykład oznacza R=0, G=1, B=0. Skoro najpierw przesyłana jest składowa dla zielonej diody, powinniśmy zobaczyć pierwszy transmitowany bajt o wartości 1:

    ws2812b_17b.thumb.png.69530b8d004b18d9aa54057ca954a43e.png

    Zgodnie z oczekiwaniami, transmisja zaczyna się od najwyższego bitu, a my wysyłamy 7 bitów zerowych. Ósmy bit ma wartość "1" i widzimy jego czasy podświetlone na obrazku.

    Tym razem stan wysoki T1H trwał 0,814 us, a niski 0,432 us - czyli zgodnie z oczekiwaniami.

    Mając takie wyniki nie powinniśmy być zaskoczeni, że wszystko pięknie działa. Testowałem bibliotekę Neopixel używając do 432 diod ws2812b i nie było najmniejszych problemów. Pewnie można byłoby użyć więcej, ale pojawiają się pierwsze ograniczenia Arduino UNO - mała ilość pamięci RAM. Biblioteka Adafruit_Neopixel przechowuje kolory wszystkich diod w pamięci, więc dla każdej diody konieczne są 3 bajty. Oznacza to że 432 diody wymagały 1296 z dostępnych 2048. Trochę pamięci trzeba zostawić dla programu, więc przy tak prostym sterowaniu raczej nie można liczyć na więcej niż 500 diod - co i tak jest chyba niezłym wynikiem.

    Czy wszystko jest tak idealnie jak się wydaje? Okazuje się że niestety nie do końca. Po pierwsze nasz mikrokontroler ma mnóstwo pracy przy sterowaniu diodami ws2812b - wszystko wykonywane jest programowo, więc wymaga mnóstwo pracy. To nie jest jakaś ogromna wada, bo i tak nasze Arduino nie ma nic lepszego do roboty w Święta.

    Druga wada jest poważniejsza - dla 24 diodek transmisja trwała 720us, ale przy 432 będzie to już 12960 us, czyli prawie 13 ms. Okazuje się że biblioteka Adafruit_Neopixel aby zapewnić niezbędne przebiegi czasowe na cały czas transmisji wyłącza obsługę przerwań. Oznacza to że większość modułów używających przerwań jak np. port szeregowy, a nawet funkcja millis() może nie działać prawidłowo. Możemy sobie z tym poradzić, ale takie proste rozwiązanie nie będzie niestety działało z każdą biblioteką i kodem.

    Jeśli więc chcemy przygotować pięknie migający łańcuch diod na choinkę, możemy po prostu użyć Arduino i biblioteki Neopixel. Natomiast jeśli chcemy zrobić coś więcej, trzeba będzie poznać diody ws2812b nieco lepiej.

     

    • Lubię! 2

  8. Do testów jak poprzednio wykorzystuję krążek 24 diod oraz Arduino UNO. Ponieważ będę testował tylko pojedyncze diody, więc wróciłem do zasilania z USB, podłączam oscyloskop i na początek pomiar prądu, gdy diody nie świecą:

    TEK0009.thumb.JPG.b0441f612313dad40e9bd1d60ad96d63.JPG

    Niby nic ciekawego ale warto się upewnić, że nowa metoda daje te wyniki co poprzednio (wcześniej było 21,6mA, teraz 23,4mA - na większą dokładność i tak nie mam co liczyć).

    Kolejny prosty test to jedna dioda świecąca maksymalnie na biało, czyli PWM 100%:

    TEK0008.thumb.JPG.2df2cc3b36b56fcf9791bdc3ea4082d9.JPG

    Wcześniej wyszło mi 52,9mA, teraz 54,9mA - czyli zarówno przy zerowym, jak i pełnym wypełnieniu pomiary oscyloskopem pokrywają się z wynikami otrzymanymi multimetrem.

    Czas więc przejść do czegoś ciekawszego. Wypełnienie 50%, czyli PWM=128:

    TEK0006.thumb.JPG.b1a437ac9f6b093873779fffa76d7ac9.JPG

    Jak widać i w sumie można się było spodziewać, prąd płynący w obwodzie wcale nie jest stały. Widzimy też częstotliwość PWM, która wynosi ok. 1,2kHz. Co ciekawe każda dioda WS2812B ma nieco inną częstotliwość, podobną ale inną.

    Jeszcze dla upewnienia się, że wszystko działa PWM=25%, czyli to co chciałbym mieć na choince:

    TEK0005.thumb.JPG.989a6ec00ddf67d73524eab850d587a3.JPG

    Dotychczas była używana jedna dioda, ale co się stanie gdy wysterujemy dwie? Pierwszy pomiar jest nieco zaskakujący:

    TEK0010.thumb.JPG.833b605668f5ccb44a463650525f1e85.JPG

    Okazało się jednak że winne było uśrednianie używane wcześniej, po jego wyłączeniu lepiej widać co się dzieje:

    TEK0011.thumb.JPG.454954d7193991469d4664a2d35a871d.JPG

    Jednak częstotliwość PWM każdej diody jest nieco inna, więc przebiegi nakładają się na siebie w przeróżny sposób:

    TEK0012.thumb.JPG.7040cfb086106d5e7bdab96252b3f940.JPG

    Chyba już widać jak strasznie ws2812b zaśmiecają linie zasilania. Jeśli ktoś nie wierzy, poniżej wyniki dla 8 sztuk (zmieniona skala):

    TEK0013.thumb.JPG.378de23eda78fa53e5bb7bcd38d47244.JPGTEK0014.thumb.JPG.b3cb35716e3c5bb6f37dd86f806f5100.JPG

    To chyba wyjaśnia częste problemy z zasilaniem pasków WS2812B. Jak widać nawet przy wypełnieniu 25% i akceptowalnym prądzie średnim, wartości chwilowe mogą osiągać maksimum. Dlatego bardzo ważne jest filtrowanie oraz używanie zasilacza z odpowiednim zapasem mocy.

    Trochę mnie to wszystko zmartwiło muszę przyznać, bo okazuje się że prosty łańcuch lampek na choinkę może być nieco trudniejszy niż myślałem. Z drugiej strony już wiem dlaczego każdy odcinek LED ma własne zasilanie - nawet nie chcę myśleć jak wyglądałyby oscylogramy przy tych 23A, które mi wyszły z wcześniejszych obliczeń.

    Wydaje mi się, że o zasilaniu WS2812B wiem już wystarczająco dużo, teraz czas zabrać się za to co proste i przyjemne - czyli sterowanie.

    • Lubię! 1

  9. Nazbierałem już trochę wyników, czas je wykorzystać. Spróbowałem oszacować jakie prądy będą konieczne do zasilenia różnej liczby diodek na choince:

    ws2812b_pomiary11.thumb.png.9971ec1ad1b5953807a3964ee7271fa3.png

    5 metrowy pasek świecący na biało to ponad 23A - dla mnie trochę za dużo. Ale już zejście z pwm do 25% daje jakieś 6,4A - znacznie lepiej.

    Ale zanim zacznę cokolwiek podłączać postanowiłem porównać moje "wyniki teoretyczne" dla 24 diodek z pomiarami. Poniżej to co wyszło:

    ws2812b_pomiary13.thumb.png.7bbabb145c0d43278a53c5fa8da7297a.png

    Tak jak napisałem na wstępie, nie dysponuję sprzętem laboratoryjnym, ale wygląda na to że szacunki całkiem nieźle wyszły. Oczywiście błąd będzie na pewno większy dla większej liczby diod, ale widać że dla 24 sztuk wyszło w miarę dobrze.

    Niestety podczas wykonywania pomiarów spotkała mnie kolejna niespodzianka. Dla wypełnienia PWM powyżej 50% musiałem zmienić zakres w multimetrze... i otrzymałem zupełnie inne wyniki niż wcześniej. Nie pozostało nic innego jak wygrzebać z szafy stary oscyloskop i przyjrzeć się o wiele dokładniej zasilaniu WS2812B.

    • Lubię! 1

  10. I jeszcze w kwestii bezpieczeństwa IoT, już tutaj masz buffer overflow:

    data[30] = '\0';

    Reszty nawet nie komentuję, ale pamiętaj proszę że Internet to nie piaskownica, to co udostępniasz widzą wszyscy - zarówno dobrzy, jak i źli użytkownicy sieci...

    • Lubię! 1

  11. Ja też trochę eksperymentowałem, najpierw z MSP430, później LPC2138 - w sumie to ja nawet nie miałem czasu na testowanie RTC, ale na produkcji narzekali, że wskazania zegara różnią się o kilka godzin zanim urządzenie zostanie wysłane do klienta. Z tego co pamiętam kwarce używane do taktowania mikrokontrolerów mają o wiele wyższą dokładność niż używane w typowych modułach RTC, stąd było moje zaskoczenie dlaczego miałoby być inaczej. Ale niezależnie od wszystkiego, po pewnym czasie każdy, nawet drogi moduł wskazuje coś innego niż wzorzec czasu.

×
×
  • Utwórz nowe...