Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją 26.12.2019 we wszystkich miejscach

  1. 2 punkty
    Jak łatwo było przewidzieć zabrałem się za WS2812B stanowczo zbyt późno - miało być piękne oświetlenie choinki, a są standardowe lampki, czyli jak zwykle. Właściwie to w tym roku jest nawet gorzej niż w poprzednie Święta, bo wtedy zrobiłem sterowanie używając ESP32 i przez WiFi można było przesyłać dane do wyświetlenia. Niestety gdzieś mi się ten program zagubił, a nowego nie napisałem, więc żeby w przyszłym roku nie zaczynać przygody z WS2812 znowu od początku, dopiszę jeszcze trochę moich przemyśleń odnośnie tych diodek. Na początek starałem się pokazać, że Arduino UNO w zupełności wystarcza do sterowania oświetleniem choinki - przynajmniej do czasu, aż będziemy chcieli bardziej rozbudować program i dodać do niego więcej funkcji niż tylko sterowanie ws2812b. Teraz spróbuję użyć jednego z typowych modułów peryferyjnych, czyli UART-a do sterowania WS2812B. Przy okazji zmieniam mikrokontroler na stm32l476 - jest do tego kilka powodów. Po pierwsze znacznie lepiej znam stm32 niż atmegę, więc jak dla mnie jest łatwiej. Po drugie Arduino i atmega328p ma raptem 2KB pamięci RAM. To pewnie wystarczyłoby do sterowania lotem na księżyc, ale w dzisiejszych czasach programy są zasobożerne, a sama biblioteka Adafruit_Neopixel zużywa po 3 bajty na każdą diodę w łańcuchu - więc jak dodamy rozbudowane sterowanie i wymagania biblioteki, może zacząć brakować pamięci. Użycie UART-a też nie ułatwia oszczędzania pamięci, bo jeden bit jest reprezentowany za pomocą trzech, więc ilość danych rośnie, albo konieczne jest kolejne komplikowanie kodu. W każdym razie wybrałem STM32L476 bo mam go aktualnie "na tapecie", mikrokontroler posiada 128KB pamięci RAM, spory wybór peryferiów, DMA oraz możliwość inwersji wyjścia Tx z UART, co będzie za chwilę przydatne. Jednak sterowanie, które opisuję można równie dobrze zastosować do innych mikrokontrolerów, nawet do Arduino. O samym UART-cie nie będę za wiele pisał, był już omawiany przy okazji kursu STM32F1 (https://forbot.pl/blog/kurs-stm32-f1-hal-komunikacja-z-komputerem-uart-id22896) oraz STM32F4 (https://forbot.pl/blog/kurs-stm32-f4-7-komunikacja-przez-uart-id13472) Na początek szybkie utworzenie projektu w STM32CubeIDE, konfiguracja zegara oraz UART1. Zaczynam od standardowych ustawień czyli prędkość 115200, 8 bitów danych itd. Taka konfiguracja jest bardzo łatwa do przetestowania, można też upewnić się, że wszystkie niuanse odnośnie komunikacji przez uart działają tak jak myślimy. Ponieważ dane są przesyłane w kolejności od najniższego bitu, wyślę wartość 0x0f, czyli najpierw powinny być cztery bity o wartości "1", a następnie cztery "0". Analizator poprawnie odczytuje przesłane dane, na diagramie widać bit startu, cztery bity "1", a następnie zera. Mniej to widać, ale na końcu jest bit stopu. Wszystko działa, jak powinno, ale do sterowania WS2812B potrzebny jest taki przebieg: Czyli najpierw stan wysoki przez czas zależny od wartości bitu, a później stan niski. UART domyślnie działa zupełnie odwrotnie - start ma wartość "0", a stop "1". Można sobie z tym poradzić sprzętowo dodając negację wysyłanego sygnału, ale w przypadku stm32l476 wystarczy zmienić ustawienia modułu: Teraz wysyłane dane muszą być zanegowane, więc zamiast 0x0f wysyłam 0xf0. Efekt jest dużo bliższy oczekiwaniom ws2812: Trzeba jeszcze poprawić czasy, można też trochę zoptymalizować sterowanie. Wysyłając wartość 0xf0 uzyskałem sygnał o odpowiednim kształcie, ale "marnuję" cały bajt na wysłanie jednego bitu. Okazuje się, że w jednej ramce UART-a bez problemu zmieścimy aż trzy bity. Ponieważ zanegowaliśmy wyjście bit startu jest automatycznie dodawany i ma wartości "1". Następnie transmitujemy (również zanegowany) bit danych, a na koniec bit zerowy. Na końcu ramki jest bit stopu, który podobnie jak start jest dodawany sprzętowo. To oznacza, że potrzebujemy wysłać raptem 7 bitów - używając UART najczęściej przesyłamy 8-bitowe dane, ale bez problemu można zmienić ustawienia na 7 bitów. Zostaje jeszcze korekta czasu transmisji. Jak pamiętamy przesłanie całego bitu do ws2812b zajmuje 1,25 us, co odpowiada 800 b/s. Ponieważ UART musi wysyłać 3 bity na jeden odbierany przez ws2812b, więc i prędkość musimy zwiększyć trzykrotnie. Daje nam to wartość 2,4Mb/s, która często pojawia się w poradnikach internetowych. Teraz już tylko zmiana ustawień CubeMX Konfiguracja peryferiów jest już gotowa, teraz trzeba napisać program. UART wysyła 7-bitowe dane, które i tak będziemy przechowywać jako 8-bitowe bajty. Ponieważ wysyłamy 3 bity na każdą ramkę UART, więc możliwych jest 8 wartości. Jako dane wejściowe przyjmujemy wartość 0-7, którą możemy zapisać binarnie jako b2b1b0. Wynik to 8-bitowa liczba, ale najwyższy bit nie ma znaczenia (więc niech będzie zerem). Pamiętając o tym, że UART wysyła dane zaczynając od najniższego bitu możemy przygotować następującą tabelkę: Teraz możemy napisać funkcję, która zakoduje nam dane w sposób oczekiwany przez UART. Jako wejście dostajemy 24-bity czyli jasność dla składowej czerwonej, zielonej i błękitnej. W wyniku otrzymamy 8 bajtów, bo tyle wymaga nasz sposób kodowania. Program może wyglądać następująco: static const uint8_t ws_code[] = { ~0x24, ~0x64, ~0x2c, ~0x6c, ~0x25, ~0x65, ~0x2d, ~0x6d }; void ws_encode(uint8_t r, uint8_t g, uint8_t b, uint8_t *buf) { uint32_t value = (g << 16) | (r << 8) | b; for (int i = 0; i < 8; i++) { uint32_t tmp = (value >> 21) & 0x7; *buf++ = ws_code[tmp]; value <<= 3; } } To już właściwie wszystko - resztę robi za nas biblioteka HAL. Jedno co musimy zrobić to zadeklarować bufor, w którym będziemy mieli po 8 bajtów na każdą diodę ws2812b: #define PIXELS 1*144 static uint8_t ws2812b_buf[PIXELS * 8]; Następnie wypełniamy bufor używając wcześniej napisanej funkcji ws_encode (oczywiście warto ją dostosować i zoptymalizować w zależności od potrzeb). Na koniec musimy wysłać zawartość naszego bufora przez UART. Na początek możemy użyć: HAL_UART_Transmit(&huart1, ws2812b_buf, sizeof(ws2812b_buf), HAL_MAX_DELAY); Jednak ta metoda niewiele nam da w porównaniu z "machaniem pinami" używanym wcześniej. Okazuje się, że obsługa przerwań i tym razem może mieć wpływ na komunikację. W rzeczywistości ten kod działa, ale opóźnienia wywołane przerwaniami mogą zakłócić transmisję. Aby tego uniknąć należy wyłączać przerwania, to jak wiemy nic dobrego. Inną możliwością jest wykorzystanie DMA do przesyłania danych. Ponieważ używamy standardowego modułu UART, wystarczy że użyjemy: HAL_UART_Transmit_DMA(&huart1, ws2812b_buf, sizeof(ws2812b_buf)); Na zakończenie jeszcze uwaga odnośnie użycia pamięci - zaprezentowane podejście jest bardzo proste, ale też mocno "naiwne". Dla długich pasków zużywamy mnóstwo pamięci, a wcale nie jest to konieczne. Mając DMA można obsługiwać przerwanie po przesłaniu połowy danych i wypełniać wówczas bufor danymi. Dzięki temu zaoszczędzimy mnóstwo RAM-u. Ale ta i inne optymalizacje to temat na kolejny wpis. Tym razem chciałem tylko zaprezentować jak łatwe jest użycie UART-a do sterowania WS2812B i jak można przygotować dane w formacie oczekiwanym przez ten moduł. .
  2. 2 punkty
    Cześć, od jakiegoś czasu studiuję bardzo dobrą książkę doktora Pong P. Chu (Cleveland State University) pt: "FPGA PROTOTYPING BY VHDL EXAMPLES Xilinx SpartanTM-3 Version". jest to chyba najlepsza z książek jakie dotychczas czytałem (dotyczących teorii i praktycznych przykładów implementacji różnych układów z użyciem języka VHDL). Książka jest dostępna do pobrania (format pdf) za darmo z tej strony: https://misp.mui.ac.ir/sites/misp.mui.ac.ir/files/ebooksclub.org__FPGA_Prototyping_by_VHDL_Examples__Xilinx_Spartan_3_Version.pdf A na tej stronie są dostępne przykłady kodu w języku VHDL do wszystkich rozdziałów: https://academic.csuohio.edu/chu_p/rtl/fpga_vhdl.html Wracając do tematu tego postu - w rozdziałach 12 i 13 jest dokładnie opisana teoria budowy sterownika VGA opartego na układzie FPGA. Opisane są także sposoby tworzenia prostych animacji bitmapowych (rozdział 12). W rozdziale 13 opisano dokładnie jak można na takim sterowniku VGA wyświetlać dane alfanumeryczne. Podsumowaniem rozdziału jest kod w języku VHDL z implementacją gry Pong (dla jednego użytkownika). Gra używa zarówno prostych animacji bitmapowych jak i wyświetlania znaków alfanumerycznych (np. wyników) i cały jej kod jest dokładnie wytłumaczony. Postanowiłem zamieścić kod projektu tej gry (z książki) z małymi modyfikacjami umożliwiającymi uruchomienie go na płytce FPGA (z kursu Forbot'a) Elbert V.2. Do kodu został dodany generator zegara (IP core Xilinx) 50 MHz i plik ucf dla Elbert;'a. Tak się prezentuje gra Pong w wersji z książki (przepraszam za słabą jakość zdjęć): A tutaj kod projektu działąjący na płytce Elbert v.2. (Xilinx ISE 14.7): PongText01.zip Kod zamieszczam głównie dla jego walorów edukacyjnych - nie widziałem jeszcze lepiej omówionej implementacji sterownika VGA dla układów FPGA. Projekt zajmuje około 33% procent układu Spartan3 zastosowanego w Elbercie. Bazując na tym kodzie można tworzyć własne wersje sterowników VGA z obsługą grafik bitmapowych (sprite) i wyświetlaniem danych alfanumerycznych. Pozdrawiam
  3. 1 punkt
    W pierwszych eksperymentach z WS2812B używałem Arduino UNO. Tak jak napisałem wcześniej, było to proste, łatwe i przyjemne. Właściwie wystarczyło podłączyć układ, dodać bibliotekę i wszystko działało - chociaż oczywiście z ograniczeniami. Opisując sterowanie za pomocą UART chciałem wykorzystać inny mikrokontroler. Możliwe że nie było to konieczne i pewnie znacznie więcej można "wycisnąć" z atmegi 328p, ale jak napisałem wcześniej zmiana układu ma swoje plusy, a nawet jeśli nie ma, to była okazją do przetestowania innych rozwiązań Dawniej standardem zasilania mikrokontrolerów było napięcie 5V. Atmega328p z racji wieku, ma tę niewątpliwą zaletę, że zarówno do zasilania rdzenia, jak i peryferiów jest używane właśnie takie napięcie. Można więc podłączyć pasek WS2812B zasilany z 5V i wszystko powinno działać. Natomiast, gdy używamy mikrokontrolerów pracujących z logiką 3.3V, mogą pojawić się problemy. W dokumentacji WS2812B znajdziemy następującą informację: Jak widzimy napięcie do 0,3 Vin będzie traktowane jako stan niski, natomiast powyżej 0,7 Vin jako wysoki. Z pierwszym parametrem raczej nie będziemy mieli problemów, ale z drugim może być już trudniej. Jeśli zasilamy pasek LED z napięcia 5V, to 0,7 * 5V = 3,5V, czyli więcej niż mikrokontroler może zaoferować. Przy okazji warto zwrócić uwagę, że problem z którym się musimy zmierzyć nie dotyczy tylko WS2812B. To ogólny problem sterowania układu pracującego w 5V-logice przy użyciu 3.3V mikrokontrolera. Na szczęście znajdziemy wiele możliwych rozwiązań naszego problemu, będziemy mogli więc wybrać taki, który najbardziej nam pasuje. Rozwiązanie 1: czyli zignorowanie problemu Właściwie nie powinienem o tym pisać, bo to jest złe, niedobre i niepoprawne, ale zawsze można spróbować po prostu podłączyć mikrokontroler zasilany z 3.3V do paska pracującego z 5V. Okazuje się, że to na ogół działa. Pin sterujący jest wejściem WS2812B, więc nie pojawia się na nim 5V. Dzięki temu nie ma ryzyka uszkodzenia mikrokontrolera. Natomiast układ może nie działać (a nawet nie powinien o ile wierzymy dokumentacji), ale jak napisałem wszystkie diody które testowałem działały bez problemu. Jest to więc niepoprawne, ale często działające rozwiązanie. Rozwiązanie 2: obniżenie napięcia zasilania WS2812B Okazuje się, że napięcie 5V chociaż typowe wcale nie jest minimalnym do pracy ws2812B. Jeśli mamy zasilacz z regulowanym napięciem wyjściowym możemy zamiast 5V użyć nieco niższego napięcia. Dzięki temu zmniejszymy straty mocy, a sam pasek będzie świecił równie jasno (opinie są podzielone, ale z moich testów wynika że zejście nawet do 4V nie ma wpływu na jasność świecenia). W każdym razie już przy 4,7V będziemy "na styk" z dokumentacją, ale już przy 4,5V wszystko powinno działać poprawnie i z niezbędnym zapasem. Kolega @ethanak zaproponował bardzo ciekawe rozwiązanie "hybrydowe". Można wykorzystać jeden moduł WS2812B, który zasilimy z niższego napięcia do wysterowania kolejnych. Do obniżenia używając nawet jednej lub kilku diod prostowniczych. W przypadku paska led takie rozwiązanie wydaje się nieco kłopotliwe, ale większość pasków można rozcinać - więc wystarczy odciąć jedną diodę i wykorzystać jako sterownik. Bardzo sprytne rozwiązanie Rozwiązanie 3: dedykowany układ scalony To chyba moje ulubione rozwiązanie. Może niezbyt tanie i proste, ale za to skuteczne i teoretycznie bezawaryjne. Po prostu musimy wybrać odpowiedni układ scalony, który wykona za nas całą pracę. Dostępnych jest mnóstwo opcji, są dedykowane układy tzw. https://en.wikipedia.org/wiki/Level_shifter. Przykład takiego układu znajdziemy np. analizując schemat płytki Maximator (http://maximator-fpga.org/), która wyposażona jest w układ FPGA pracujący w logice 3.3V. Dostępne są gotowe moduły z podobnymi układami, np. https://botland.com.pl/pl/rozszerzenia-gpio-nakladki-hat-do-raspberry-pi/4290-konwerter-poziomow-logicznych-txb0104-dwukierunkowy-4-kanalowy-sparkfun.html Jeśli ktoś uważa, że cena jest nieakceptowalna, może poszukać tańszych odpowiedników np. na aliexpress. Ceny podobnych modułów zaczynają się od 4zł z przesyłką. Prawdopodobnie tańszym rozwiązaniem będzie wybranie odpowiedniego układu z rodziny 74. Przykładowo SN74LV1T34 (http://www.ti.com/product/SN74LV1T34) - jeśli znacie inne, np. tańsze, łatwiej dostępne układy, piszcie w komentarzach - ten model znalazłem na szybko za pomocą google, wcale nie twierdzę że to najlepszy układ na świecie. Rozwiązanie 4: wyjście open-drain lub open-collector To rozwiązanie jest pozornie proste. Jeśli nasz mikrokontroler toleruje napięcia 5V oraz ma możliwość przełączenia wyjścia w tryb open-drain, wystarczy podłączyć rezystor podciągający do 5V i teoretycznie wszystko działa. Pierwszy problem to tolerancja 5V. Nie wszystkie układy mają taką możliwość, więc np. jeśli chcemy z ESP32 wysterować diody WS2812B nie możemy bezpośrednio podłączyć rezystora pull-up. Możemy to łatwo obejść dodając tranzystor, ale to już nie jest tak proste jak wcześniejsza opcja. Drugi, dużo poważniejszy problem to ograniczenia takiego sterowania. Jak pewnie wszyscy wiedzą, sygnały nie zmieniają się natychmiast, nawet "idealny" prostokąt ma swoje czasy narastania. Jeśli użyjemy układu open-drain, to zmiana ze stanu niskiego na wysoki będzie trwała dość długo - jest to wręcz książkowy układ R-C (https://pl.wikipedia.org/wiki/Układ_RC), więc stała czasowa t=R * C. W nocie katalogowej WS2812B znajdziemy informację o pojemności wejściowej wynoszącej 15pF. Do tego musimy doliczyć pojemności wprowadzane przez PCB lub/i przewody. Podstawmy kilka wartości R do wzoru: Jak widzimy przy typowej wartości rezystora podciągającego, czyli 47k stała czasowa wynosi 705ns - to oznacza że po tym czasie na wyjściu będziemy mieli napięcie ok. 63% docelowego (czyli mniej niż wymagane 0,7Vin). W przypadku 10k jest nieco lepiej, ale 95% docelowej wartości otrzymamy po czasie 3 * t, czyli większym niż szerokość impulsu, który staramy się uzyskać. Dopiero bardzo małe rezystory podciągające, jak 4k7, czy 1k dają w miarę rozsądne czasy. Jednak ich użycie oznacza dość spore prądy wpływające do mikrokontrolera. Wykonałem kilka pomiarów, żeby przetestować takie sterowanie w praktyce. Testy Pierwsze dwa rozwiązania działały na wszystkich posiadanych przeze mnie diodach. Ponieważ do zasilania używam zasilacza laboratoryjnego, więc zmniejszenie napięcia z 5V do 4,5V było bardzo łatwe. Jak napisałem wcześniej, nie powoduje to widocznej zmiany jasności świecenia. Trzecie rozwiązanie testowałem używając płytki Maximator. Jak można się spodziewać wszystko działa wówczas bardzo dobrze, a FPGA pozwala na sterowanie WS2812B bez "sztuczek" z UART, SPI, czy innymi modułami. Ostatnie rozwiązanie postanowiłem sprawdzić podłączając oscyloskop. Na początek dla porównania pierwsza opcja, czyli sterowanie WS2812B bezpośrednio z 3.3V: Tutaj przydałby się lepszy oscyloskop, ale jak się nie ma co się lubi... W każdym razie widać silne dzwonienie sygnału. Warto przetestować polecane często w internecie wpięcie rezystora szeregowego w linię sterującą. Po podłączeniu 82 Ohm oscylogram wygląda następująco: Użycie 220 Ohm sprawia daje jeszcze ładniejszy rezultat: Nie jestem niestety ekspertem od elektroniki analogowej, ale mam nadzieję, że ktoś - może @marek1707 ładniej opisze dlaczego warto (albo nie) dodawać rezystor szeregowo. W każdym razie wyraźnie widać różnicę. Jednak celem testu miało być co innego - zmieniam więc wyjście mikrokontrolera na open-drain, podłączam zasilanie 5V do paska WS2812B oraz rezystor podciągający 33k (z 47k było jeszcze gorzej, a później gdzieś sobie poszedł): Diody oczywiście nie działają z takim rezystorem. Zmieniam więc na 10k: Układ nadal nie działa, ale jest postęp. Czas podpiąć 4k7: Wykres nadal fatalny, prąd 1mA wpływa do biednego mikrokontrolera, natomiast co ciekawe układ działa. Na koniec jeszcze pull-up 1k: Tutaj jak widzimy jest już prawie dobrze. Czasy narastania nadal są kiepskie, prąd wynosi aż 5mA - ale chociaż działa. Podsumowanie Sposobów na rozwiązanie problemu podłączenia WS2812B jest na pewno więcej. Opisałem kilka, które znam oraz które pojawiały się ostatnio na forum. Jeśli macie jakieś uwagi, pomysły na lepsze rozwiązania, piszcie proszę w komentarzach. Tylko bardzo proszę o merytoryczną dyskusję, a nie przekonywanie się nawzajem że moja racja jest najmojsza... Każdy problem można rozwiązać na wiele sposobów, a dzieląc się wiedzą wszyscy tylko zyskujemy.
  4. 1 punkt
    super kurs ciekawe zadania samemu do zrobienia
  5. 1 punkt
    Witam wszystkich, mam na imię Maciej i właśnie rozpoczynam przygodę z Arduino dzięki kursowi, który dostałem od św. Mikołaja
  6. 1 punkt
    Będzie bo WS2812 nie mają źródeł prądowych. Zauważalne zmniejszenie jasności jest już przy 4,5V a przy 4,1 bardzo duże. Dlaczego? W katalogu napisano, że LED ma być zasilany napięciem 5V +/1 10% a 3,5V to już odchyłka 30% więc 3 razy większa niż dopuszczalna.
  7. 1 punkt
    Witam na forum a jaką masz taśmę LED RGB, ile diod? Bo są takie z programowalnymi diodami, mają one 3 pola do lutowania na krańcach taśmy. Są też takie prostsze z 4 polami, gdzie sterujesz poprostu całością. Choć prostsze to ciężej się steruje, są do tego dedykowane moduły ale o tym później. Na pewno nie myśl że zasilisz to z USB podpiętego do ESP. Potrzeba dodatkowy zasilacz.
  8. 1 punkt
    Pierwsza leda zasilana z obniżonego napięcia (np. przez diodę prostowniczą). Dobre jak masz oddzielne ledy, a nie pasek :(
  9. 1 punkt
    Uwaga - od tej chwili kończy się część inżynierska, a zaczyna "czarna magia" Testując własny program oraz szukając informacji w internecie znalazłem dość ciekawy wpis: https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ Autor przebadał działanie ws2812 i podzielił się dość interesującymi przemyśleniami. Z jego doświadczeń wyszło, że bardzo ważny jest czas stanu wysokiego podczas transmisji bitu 0, natomiast pozostałe czasy mogą być przekroczone bez szkody dla działania układu. Postanowiłem jego badania przetestować - i muszę powiedzieć, że nie wyszło mi tak optymistycznie, ale nadal ciekawie. Na początek dodajmy do naszego pierwszego programu opóźnienie przy wysyłaniu bitu "0": static inline void send_bit_zero(void) { PORTD |= _BV(6); _NOP(); delayMicroseconds(10); PORTD &= ~_BV(6); for (uint8_t i = 0; i < 4; i++) _NOP(); } Taka zmiana zupełnie psuje komunikację. Diody świecą z pełną jasnością, zupełnie nie o to chodziło. Ale już wstawienie opóźnienia podczas stanu niskiego działa poprawnie: static inline void send_bit_zero(void) { PORTD |= _BV(6); _NOP(); PORTD &= ~_BV(6); for (uint8_t i = 0; i < 4; i++) _NOP(); delayMicroseconds(10); } W przypadku transmisji bitu o wartości "1" można dodać opóźnienie w dowolnym momencie i nadal komunikacja będzie działała. Testowałem różne opóźnienia i do 30us wszystkie diody ws2812b jakie posiadam działały bez problemu. Wstawianie sztucznych opóźnień jest ciekawe, jednak niewiele w tym sensu. Można natomiast zdobyte doświadczenie wykorzystać inaczej - jak widzieliśmy wcześniej obsługa przerwania dla millis() zajmuje mniej niż 7us. Skoro nawet 30us opóźnienie nie psuje komunikacji, to może dałoby się włączyć przerwania od czasu do czasu? To właśnie zrobił autor bloga, do którego link wstawiałem wcześniej. Postanowiłem przetestować następujący program: #define LED_PIN 6 void setup() { DDRD |= _BV(6); } static inline void send_bit_zero(void) { cli(); // wylacz przerwania PORTD |= _BV(6); _NOP(); PORTD &= ~_BV(6); sei(); // wlacz przerwania 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() { for (int i = 0; i < 24; i++) { send(0x01); send(0); send(0); } delay(10); } Tym razem przerwania wyłączane na raptem 0.4us, używając analizatora możemy "zobaczyć" przerwy w komunikacji: Ale o dziwo diody działają bez najmniejszych problemów. Od razu zaznaczam - to nie jest poprawne, inżynierskie podejście. Jeśli planujecie produkcję seryjną urządzeń, albo pracujecie w sektorze safety-critical to proszę nawet tego nie czytajcie. Ale jeśli chcecie mieć tylko oświetlenie na choinkę i wszystko działa poprawnie, to jest to co najmniej ciekawostka Co więcej można nieco zmienić bibliotekę Adafruit_Neopixel. W pliku Adafruit_NeoPixel.cpp, linii 222 znajdziemy wywołanie noInterrupts(). Po usunięciu tej linii zobaczymy błędy w komunikacji z modułami ws2812b. Możemy jednak dodać wyłączanie przerwań tylko na czas stanu wysokiego (to ten fragment w asemblerze) - i będziemy mieli wówczas w pełni działający port szeregowy, millis() oraz przykłady dołączone do Adafruit_Neopixel. Tak jak napisałem wcześniej - takie sterowanie nie jest zgodne z dokumentacją producenta. "U mnie działa", ale to tylko ciekawostka. Natomiast jeśli chcemy mieć poprawne sterowanie ws2812b oraz możliwość obsługi przerwań musimy zmienić platformę sprzętową. Arduino UNO nie ma niestety odpowiednich modułów peryferyjnych. Jednak jak wielokrotnie wspominałem - do przygotowania lampek na choinkę na pewno wystarczy.
  10. 1 punkt
    A skąd to wiesz? Bo ja uważam, że najlepsza jest taka która wprost pasuje do postaci zasilania jakie potrzebujesz. Praktycznie niczego nie napędzisz z 1.5V więc żeby zrobić 3.3 lub 5V będziesz musiał użyć przetwornic podwyższających a te są z definicji gorsze (mniej sprawne za te same pieniądze) niż obniżające. Bardzo dobrze, że 9V mieści się do pudełka i takiej użyj. Pomiając fakt, że ogniwa AA mają mniejszą ilość energii (objętość jest kluczowa jeśli chemia jest podobna) niż 6F22. A tak w ogóle to odpowiedź na pytanie o czas pracy nietrywialnych systemów jest - jak się zapewne domyślasz - trudna z jednego bardzo ważnego powodu: pobór prądu nie jest stały. Zacznij od tego, że źródło ma pewien zasób energii liczony w Wh. Z drugiej strony masz (w najprostszym przypadku) układzik pobierający np. 10mA na napięciu 3.3V. To przekłada się na moc 33mW, czyli że to coś będzie zużywać 0.033Wh w godzinę. Jeżeli dobra bateria alkaliczna 9V ma w sobie powiedzmy 5Wh (mają gdzieś tak od 4 do 5.5Wh) to z prostego rachunku Twoje urządzenie będzie na niej pracować ok. 150h. To jest najprostszy rachunek, nie uwzględniający mnóstwa czynników jak chociażby: Sprawność przetwornicy (lub innego bloku) zasilającego system. Trzeba przecież te 9V zamienić na coś użytecznego, a czasem na kilka napięć i to zawsze kosztuje od kilku do kilkudziesięciu % strat. Dlatego tak ważne jest dopasowanie baterii do wymagań systemu i sam wybór bloku zasilania. Sposób poboru prądu - nie zawsze urządzenia pobierają ciągle tyle samo. Baterie lubią małe i stałe pobory i zwykle mają pewną granicę powyżej której wyraźnie "przysiadają". Akurat bateria 9V ma bardzo małą obciążalność. Poziom napięcia do którego można baterię "wyssać". Producenci podają wyniki swoich pomiarów dla konkretnych warunków rozładowania tj. wielkość prądu, sposób użycia (np. ile godzin dziennie) oraz końcowe napięcie. Jeżeli Twój system bedzie odmawiał pracy przy wyższym napięciu niż przewidział producent, to nie wyczerpiesz całej pojemności baterii. Przykładowo jeśli baterię 9V mierzyli do 4.8V (to standard) a Ty masz 5V procesor a na dodatek jego przetwornica DCDC potrzebuje na wejściu min. 6V, to urządzenie zdechnie właśnie przy 6V, mimo że w baterii zostanie jeszcze teoretycznie z 10-15% energii. Temperatura pracy. Baterie dobrze działają w temperaturach pokojowych i okolicach, powiedzmy 0..+50°C. W minusach gwałtownie rośnie im rezystancja i spada pojemność a wysoko w cieple wybuchają lub wylewają. Także jeśli urządzenie ma znosić ciężkie warunki klimatyczne to przewymiarowanie baterii np. 3-krotne nie jest niczym niezwykłym. A specjalne baterie/akumulatory dobrze radzące sobie w takich ekstremach są wielokrotnie droższe. Do prostych obliczeń możesz wziąć pobór procesora przy danym napięciu i prędkości zegara (to bardzo ważny parametr dla układów cyfrowych) oraz koniecznie musisz się zastanowić jak będziesz używał tej karty, bo to ona będzie głównym pożeraczem prądu. Podczas zapisu może wciągać nawet 10-20 razy więcej mocy niż procesor Arduino. Czujniki zwykle potrzebują niedużo, chyba że są jakieś bardzo aktywne typu ultradźwięki, bariery opto, pomiar stężeń gazów metodami optycznymi (NDIR) lub cieplnymi. Jeśli ograniczysz się tylko do temperatury i wilgotności to na razie w ogóle możesz to pominąć w budżecie prądu. Podsumowując: dobra wiadomość jest taka, że do obliczeń wystarczy znać średni pobór mocy i pojemność źródła. Zła, że na średni pobór mocy ma wpływ właściwie każdy element systemu począwszy od bloku zasilania przez procesor i całą resztę sprzętu a skończywszy na oprogramowaniu, które może procesor zatrzymywać, rozpędzać, usypiać i to samo robić z pozostałymi blokami. W zasadzie nie mając gotowego kodu w którym na cyzelowanie/minimalizację poborów energii nie zużyłeś 30% całego czasu pisania, to nie jesteś w stanie precyzyjnie odpowiedzieć na zadane w temacie pytanie. A z gruba to wiadomo, nie znając dokładnie tego co chcesz zrobić i co to ma robić, można pomylić się pewnie i 100 razy. Może więc napisz coś więcej? Czy jakaś interakcja z użytkownikiem? Jakieś LEDy? Czy urządzenie w pełni autonomiczne? Jak często i co ma robić?
  11. 1 punkt
    "..żaden w momencie kiedy jest nowa ciekawa propozycja czy pytanie się nie kwapi do odpowiedzi" "Ciekawość" propozycji mierzyłbym właśnie liczbą odpowiedzi. Czy brak masowego odzewu nie daje Ci do myślenia? I podpowiadam, że nie chodzi tu o to, że "niema nikogo kto by posiadał stosowną wiedzę" Znalazłeś poradnik, przeczytałeś i czujesz, że wcale nie jesteś od tego mądrzejszy. MirekCz bardzo ładnie ten tekst podsumował. Znajdziesz coś innego, artykuł w sieci, książkę, przeczytasz i będzie to samo. Chcesz wiedzieć dlaczego? To posłuchaj. Zaprojektowałem pewnie kilkaset jesli nie więcej płytek, wiele z nich wielowarstwowych. Do prościutkich układzików z mikrokontrolerkiem, do sterowań przemysłowych, do systemów pomiarowych, DSP, telekomunikacyjnych, do przetwornic, zasilaczy, wzmacniaczy programowanych, filtrów, zabawek modelarskich i mnóstwa innego elektronicznego chłamu i wiesz co? Nadal twierdzę, że nic nie umiem. Zaczynam się powoli przychylać do stwierdzenia, że projektowanie płytek jest jak malowanie obrazów. Oczywiście z inżynierskiego punktu widzenia to śmieszne. "Przecież mamy reguły, wzory, zalecenia!" - podniesie się zaraz krzyk a ja śmiem twierdzić, że w dziedzinie sztuki istnieje podobna liczba reguł i zaleceń. A jak to jest, że jedne obrazy to arcydzieła dające naprawdę masę fajnych, estetycznych przeżyć a obok innych przejdziesz nie zwracając uwagi? Płytka jest tylko jednym z etapów procesu powstawania gotowego urządzenia. I tak jak na etapie schematu, żeby go dobrze zrobić musisz uwzględnić wiele czynników - nie tylko "elektronicznych" tak i podczas rysowania płytki istnieje wiele sprzecznych zaleceń. Przy kilku podzespołach, pamiętając o tych regułach możesz stworzyć optymalny układ połączeń ale w miarę wzrostu stopnia skomplikowania liczba stopni swobody staje się tak wielka, że z powodzeniem możemy mówić o sztuce projektowania PCB. Jeśli masz dobre wyczucie, szybko trafisz na lokalne optimum rozmieszczenia elementów i połączenia będą dobre. Jeśli masz mniej szczęścia, zrobisz płytkę w 95% i uznasz, że dalsza praca nie ma sensu. Trzeba wtedy wrócić prawie do początku. Ktoś trafi na inny lokalny dołek i zrobi inaczej ale czy "gorzej"? Czy słyszysz o czym ja mówię? O wyczuciu, szczęściu itp. To nie jest terminologia inżynierska, prawda? Chcesz się porwać na poradnik? A co ma w nim być? Nauka obsługi jakiegoś programu CAD? Chyba nie. To może zbiór reguł? Czyich? Moich? Moich kolegów z firmy? MirkaCz? Grabo? Twoich? Zaręczam Ci, że do każdej płytki jaką zobaczę, jestem w stanie się przyczepić i wytknąć rzeczy, które zrobiłbym inaczej. I nie wykluczam tu moich projektów. Jako początkujący w tej działce - tak wnioskuję z Twojego podpisu, możesz dostać kilka ogólnych reguł ale są to bardziej reguły "elektroniczne" niż "płytkowe". Nie wspominam już o estetyce rozmieszczenia elementów, choć z wiąże się z tym również serwisowalność, niezawodność środowiskowa itp - bo ta (estetyka) jest elementem zupełnie niewymiernym. Chodzi mi raczej o "czucie" projektu. Sam piszesz, że doświadczenie z przetwornicami dużo Cię nauczyło o prowadzeniu mas. I jak teraz chcesz tak ogólne stwierdzenie zapisać w poradniku? Żeby przemyśleć prowadzenie mas, kierunki prądów, wydzielać obwody silno- i słaboprądowe, słowem: żeby rozumieć swój układ? Proponuję Ci: napisz rozdział o prowadzeniu mas z którego będziesz zadowolony i wrzuć go tutaj. Jeśli skończysz przed Bożym Narodzeniem, czapki z głów. "błagam nie piszcie w innych tematach na temat tych pól " Będę pisał, bo dużo łatwiej rozmawia mi się o konkretnym przypadku (płytki, obrazu, kawałka muzyki) niż o "ogólnej teorii wszystkiego". Moja wiedzę i doświadczenie mogę wtedy zaprząc do rozważenia za i przeciw oraz - co ważne - do posłuchania moich wewnętrznych, osobistych wrażeń. Po przefiltrowaniu tego przez zdrowy rozsądek mogę to ubrać w słowa, wysłać na Forum i być może komuś pomóc. Odpowiedź w sprawie polygonów dostałeś: "Jest to raczej dobry krok na koniec projektowania a nie coś co się robi na początku " Oczywiście założenia co do przyszłego położenia dużych polygonów powinny powstawać już na etapie rozmieszczania elementów, a wcześniej również na etapie wyboru technologii. Na płytkach 4-6- i więcej-warstwowych raczej ich się nie wylewa (choc nie jest ścisłą regułą). Tam warstwy zasilania są "polygonami" z definicji a czasem warto poświęcić warstwę czy dwie na specjalny "bezprądowy" ekran np. między szybkimi, mikropaskowymi ścieżkami cyfrowymi a pewnymi szczególnymi analogowymi.
Tablica liderów jest ustawiona na Warszawa/GMT+01:00
×
×
  • Utwórz nowe...