Elektroda.pl
Elektroda.pl
X
BotlandBotland
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

tmf 28 Gru 2017 15:00 10449 57
  • #31
    Sareph
    Poziom 22  
    tmf napisał:
    To nie jest problemem, można dać zwykłe diody RGB i do nich sterownik WS2811.
    No ja bym się spierał. Matryca 8x8 na 3mm diodach, ma ~1024mm2. Sam obszar 64 obudów SOP-8 to 1920mm2. Także nie uwzględniając połączeń, to już wychodzi 2x większe PCB niż sama matryca.
  • BotlandBotland
  • #32
    krisRaba
    Poziom 30  
    Jak już kombinować, to wrzucić MCU, które obsłuży komplet ;-) Choć 8x8x3 wyprowadzeń plus interfejs... Hmm ;-) BGA? ;-)
  • #33
    Sareph
    Poziom 22  
    Hmm, wypadku matrycy 8x8 RGB (ze wspólną elektrodą dla rzędów/kolumn) wystarczą 33 wyjścia sterujące, 24 (8 * 3) kanały PWM i 8 sterowników wspólnej elektrody. Dało by się upchnąć w jakimś TQFP albo QFN. ;)

    Dopisek: Czyli w sumie TLC5947 (12 bit na kanał) + jakieś P-mosfety... pytanie zatem, jakiś zintegrowany high-side z 8 wyjściami, w małej obudowie? ;) Co prawda nie będzie samodzielne, ale zawsze można zrobić wersje 16x16 + jakiś tani mały uC do sterowania takim panelem.
  • BotlandBotland
  • #34
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #35
    tmf
    Moderator Mikrokontrolery Projektowanie
    @Piotrus_999 W wygodny sposób można sterować czterema - podłączasz 4 kanały DMA, które transmitują wcześniej przygotowane dane. Ponieważ to rozwiązanie używa 2 timerów na kanał, więc cztery niezależne taśmy są też granicą z tego powodu. Łącznie daje to przy odświeżaniu 50 Hz możliwość sterowania 2666 diod. Ponieważ dla nich będziesz potrzebował 7998 bajtów na dane RGB, więc w XMEGA128A1U wystarczy nawet pamięci na double buffer. Jeśli zdecydujesz się na prosty układ zewnętrzny - multiplexer 2 na 1, to można sterować do 8 taśm równolegle, tylko wtedy potrzebna jest XMEGA 384, która ma 32 kB RAM - żeby starczyło na podwójne buforowanie. Chociaż można się obyć bez niego, wystarczy przetwarzać dane w buforze po ich wysłaniu, a nie przed - myk znany z wyświetlaczy TFT.
    Zapewne zapytasz, czy moc obliczeniowa wystarczy - bawiłem się efektem, w którym dla każdego kanału musiłem wykonać 3 mnożenia float i dzielenie oraz mnożenie razy sinus i cosinus (tu wartości miałem stablicowane, bo przy rozdzielczości bitowej WSów nie ma potrzeby na superdokładność) + korekcja gamma - ciągle limitem był czas transmisji danych przez wolny interfejs WS2812B do taśmy, a nie szybkość obliczeniowa procesora.
  • #36
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #37
    krisRaba
    Poziom 30  
    Jeśli można, to wrzucę mały temat poboczny ;)
    Czy XMEGA już wyzbyły się problemów wieku dziecięcego i osiągnęły taki poziom, w którym można myśleć o nich w poważnych zastosowaniach?
    Kiedyś byłem ich dużym zwolennikiem, bo mają mnóstwo ciekawych rozwiązań, użyłem ich nawet z powodzeniem w kilku mniejszych projektach, ale miałem też projekt, w którym bardzo się na nich sparzyłem :-/ Pomijając kosmicznie długą wtedy erratę (MCU jeszcze bez USB), to znalazłem jeszcze kwiatka nieopisanego w erracie, z którym dość długo walczyłem nim przyjąłem, że to po prostu nie działa jak w datasheecie. Błędy w dokumentacji będącej (wtedy) wiecznie w wersji Preliminary już pomijam, np. że na danych pinach jest I2C, którego tam nie było ;)
    Znajomy z kolei mówił, że dziwne rzeczy działy się podczas pracy w pełnym zakresie temperatur... ale że nie mówił co dokładnie, to traktuję bardziej jako legendę o smokach ;)
    Przerzuciłem się na ARMy i czasem tylko się zastanawiam, czy przy dostępności M0, M3, M4 i wyżej jest sens się jeszcze czasem uśmiechnąć do XMEGI i czy w zamian nie kopnie mnie w zadek przy najbliższej okazji ;)
  • #38
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #40
    krisRaba
    Poziom 30  
    Piotrus_999 napisał:
    Jezli wolisz płacić więcej za mniej to czemu nie :). Ja np. kupiłem ostatnio w Arrow 100szt F303C za £1.7 szt brutto czyli za 8zł. Cena była co prawda okazyjna ale normalnie są po 2.2 do 2.5/szt. Znajdź mi tak wyposażoną i szybką xmegę w tej cenie :)
    To też fakt, a że ostatnio trochę robiłem na F303, to miło wiedzieć, że finalnie mogą być w takich cenach ;)
    Dodano po 2 [minuty]:
    Marek_Ertew napisał:
    @krisRaba, Xmegi z USB (np. ATXMEGA128A4U lub A1U) są tańsze i lepsze od pierwszej serii. Mi te uC nigdy nie sprawiły przykrych niespodzianek. Jedynie gotowe przykłady (u mnie bootloader) wymagały gimnastyki żeby skompilować w nowszym sofcie.

    Wydaje mi się, że to co zastosowałem we wspomnianych mniejszych projektach też było A4U. Natomiast porażka była chyba na jakimś 128A3? Musiałbym sprawdzić.
    Tylko wtedy bałem się jeszcze ARMów, hahaha...
    Dodano po 11 [minuty]:
    Ciekawe, bo sprawdziłem i kwiatki były w ATXMEGA128A3U-AU :-/ A one niby w erracie mają tylko AWEXa... Może jeszcze wcześniejsza wersja projektu była na XMEGA poprzedniego typu i stąd pamiętam dłuuugą erratę? ;)
    A bez problemów obyło się z ATXMEGA32A4U-AU
    Ale dobra, mniejsza z tym, bo nie chcę hijack'ować tematu :)
  • #41
    Justyniunia
    Poziom 33  
    R-MIK napisał:
    Ciekawe kiedy pojawią się wyświetlacze 7-seg WS2812? Matryce 5x7 już widziałem.

    Ja czekam na gotowe Power LED 3x1W, albo 3x3W, chyba że już są.
  • #42
    Marek_Ertew
    Poziom 16  
    Istnieją, tylko nie wiem jakich słów kluczowych użyć żeby pokazały się w wyszukiwarce na Ali...

    Moduł łącznie 1W:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    Moduł z LEDem 1W * RGB (łącznie 3W):
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    Ech, serwer elektrody wie lepiej :/
    Nie mogę obrazków zamknąć w tagi [ img ], a proponowane "Załaduj poprawnie obrazek" kończy się pustą stroną.

    Moderowany przez tmf:

    Wstawiłem obrazki, bez najmniejszych problemów. Klikasz na dodaj obrazek i robisz Ctrl+C i Ctrl+V. Tylko trzeba poczekać na jego załadowanie.

  • #43
    tmf
    Moderator Mikrokontrolery Projektowanie
    krisRaba napisał:
    Czy XMEGA już wyzbyły się problemów wieku dziecięcego i osiągnęły taki poziom, w którym można myśleć o nich w poważnych zastosowaniach?


    O ile pierwsze miały jakieśtam problemy, to w kolejnych rewizjach je usunęli (aczkolwiek errata nigdy nie była długa). Atmel ma tą przyjemną cechę, że wypuszcza kolejne rewizje procków w których poprawia znalezione błędy, w przeciwieństwie do wielu innych producentów, którzy je powielają i wmawiają, że tak musi być:) Z pewnością tańsza i w sumie lepsza wersja, to wersja U z USB. Tu nie natknąłem się na żadne problemy i w dziesiątkach projektów działają one doskonale. Wypisz jakie konkretnie problemy miałeś to łatwiej będzie coś więcej powiedzieć.
    krisRaba napisał:
    Przerzuciłem się na ARMy i czasem tylko się zastanawiam, czy przy dostępności M0, M3, M4 i wyżej jest sens się jeszcze czasem uśmiechnąć do XMEGI i czy w zamian nie kopnie mnie w zadek przy najbliższej okazji ;)

    To zależy. XMEGi mają kilka przyjemnych cech, w dużej mierze taką XMEGA z rdzeniem ARM jest rodzina Atmelowskich SAMD, z rdzeniem CM0+, ale za to mają z XMEGI event system, bardzo przyjemne DMA z deskryptorami, USB itd. Z nieprzyjemnych rzeczy to typowe ARMowskie wynalazki - multiplexer funkcji pinu, w efekcie jak pin jest np. wejściem przerwania, to już nie może być np. wyjściem SCK interfejsu SPI oraz kosmicznie przerośnięty system dystrybucji zegarów, nie wiadomo po co. Ale poza tym to dosyć fajne procki.
    W sumie ciekawie wyglądają zaproponowane w tym wątku PSOC5 i PSOC6 - rdzeń ARM + układy UDB, czyli cele CPLD w które można władować potrzebne peryferia. Brzmi ciekawie, muszę się kiedyś tym pobawić.
  • #45
    krisRaba
    Poziom 30  
    tmf napisał:
    O ile pierwsze miały jakieśtam problemy, to w kolejnych rewizjach je usunęli (aczkolwiek errata nigdy nie była długa). Atmel ma tą przyjemną cechę, że wypuszcza kolejne rewizje procków w których poprawia znalezione błędy, w przeciwieństwie do wielu innych producentów, którzy je powielają i wmawiają, że tak musi być:) Z pewnością tańsza i w sumie lepsza wersja, to wersja U z USB. Tu nie natknąłem się na żadne problemy i w dziesiątkach projektów działają one doskonale. Wypisz jakie konkretnie problemy miałeś to łatwiej będzie coś więcej powiedzieć.

    Jak przez mgłę pamiętam, że było coś związane z PRR oraz z RTC, ale co dokładnie, to niestety już nie wiem, bo to strasznie dawno było (5 lat?). W dokumentacji był też błąd, że na którychś pinach jest I2C, a go tam nie było. Pamiętam, że w jednym dokumencie w 3 miejscach było co innego napisane na ten temat ;) Że go tam nie ma zacząłem podejrzewać, gdy w Atmel Studio nie rozpoznawał (nie kolorował) mi symbolu tego dodatkowego I2C, no i tabelka z funkcjami alternatywnymi pinów jako jedyna twierdziła słusznie, że go tam nie ma...
    Tamten projekt przeskoczył na STM32L, więc problemu się pozybyłem.. zyskując kilka innych, hahaha :D
    Chyba nie ma sensu do tego wracać i przypominać sobie. Bardziej mi to huczy w głowie jako zawiedzione nadzieje :-P No i trochę wstydu się najadłem, bo forsowałem to rozwiązanie do projektu, po czym musiałem się tłumaczyć, że dodatkowy czas, dodatkowe PCB itp... ;)
    Natomiast te małe A4U faktycznie dobrze wspominam. Ogólnie XMEGA była dla mnie o tyle sympatyczna, że strasznie łatwo było mi przejść na to ze znanych mi AVR mega czy tiny, środowisko wygodne, nie wymagało przyswojenia wiedzy, która na tamtym etapie mnie nie interesowała... instalujesz środowisko i wszystko działa, co było mega kontrastem w stosunku do stawiania środowiska na Eclipse z CodeSourery, OpenOCD, external toolsami itp :P Teraz jest trochę łatwiej w tym względzie, choćby z SW4STM32...

    tmf napisał:
    To zależy. XMEGi mają kilka przyjemnych cech, w dużej mierze taką XMEGA z rdzeniem ARM jest rodzina Atmelowskich SAMD, z rdzeniem CM0+, ale za to mają z XMEGI event system, bardzo przyjemne DMA z deskryptorami, USB itd. Z nieprzyjemnych rzeczy to typowe ARMowskie wynalazki - multiplexer funkcji pinu, w efekcie jak pin jest np. wejściem przerwania, to już nie może być np. wyjściem SCK interfejsu SPI oraz kosmicznie przerośnięty system dystrybucji zegarów, nie wiadomo po co. Ale poza tym to dosyć fajne procki.

    To fakt, jak pierwszy raz trafiłem na "wynalazek", że mam przerwanie od USARTa i muszę sobie posprawdzać, co dokładnie je wywołało (flagi przerwań) oraz czy takie przerwanie jest włączone (maski), to był szok w porównaniu z indywidualnymi przerwaniami znanymi z AVR ;) No i kilka innych "ciekawych wynalazków" ;)
    Ale z drugiej strony jak kiedyś robiłem coś na PIC16F97J60, to ja dziękuję jak podstawowych funkcji można nie mieć :P Stąd "wszystko-mający" ARM to błogosławieństwo ;)
  • #46
    leonow32

    Poziom 30  
    Sareph napisał:
    Ciekawe te dotstary, tylko krótki szereg... ale odkryłem, że WS2812 występują w takiej formie (5mm):

    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    I tak w sumie, jakby można je było dostać jako 3mm, to jak dla mnie byłby ideał. Bo zostaje tylko maskownice wydrukować na drukarce 3D (albo wyciąć laserem) i byłaby kompaktowa matryca w dowolnie konfigurowalnym rozmiarze.

    Takie diody występują i są są dostępne bez żadnych problemów. Są w obudowie przewlekanej 5mm matowej, aby ładnie mieszały się kolory

    https://extronic.pl/optoelektronika/74987-led-rgb-ws2812d-cyfrowy.html
  • #47
    Sareph
    Poziom 22  
    leonow32 napisał:
    Takie diody występują i są są dostępne bez żadnych problemów. Są w obudowie przewlekanej 5mm matowej, aby ładnie mieszały się kolory
    No, ale... to już sam zauważyłem. Tylko że ja bym pragnął wersji 3mm. Ale zdaje się w ogóle nie ma nawet zwykłych diod RGB w takich obudowach.
  • #48
    karol75
    Poziom 16  
    tmf napisał:
    @Piotrus_999 W wygodny sposób można sterować czterema - podłączasz 4 kanały DMA


    Jako sam panel (nie sprzętowo tylko klasycznie ) do 32 linii
    Ja robiłem 16 linii * 64 diody (atxmega128a1U): wczywanie z karty sd(spi) generowanie płynących tekstów itd. musiałem wstawiać opóźnienia aby w ogóle coś zobaczyć na panelu, było za szybkie nawet przy wysyłaniu 512 diod w lini.
    Dało by się szybciej przy odpowiednim mieszaniu pamięcią (adresowanie całego portu, a nie jednego bitu) )ale generowanie obrazów trwało koszmarnie długo.
  • #50
    karol75
    Poziom 16  
    Ja miałem przygotowany obszar pamięci (16 linii po 64*3bajty) w którym sobie rysowałem, Ładowałem do niego grafiki itd. Po przygotowaniu obrazu ten obszar był wysyłany do diod wiersz po wierszu 16 razy.
  • #51
    tmf
    Moderator Mikrokontrolery Projektowanie
    @karol75 To bardzo dobre rozwiązanie, jeśli nie tworzysz jakiś większych efektów na bieżąco, Jeśli obliczasz efekt dla wielu diod to niestety robi się spore zapotrzebowanie na RAM. Dlatego zaprezentowałem pomysł na realizację sprzętową transmisji - reprezentacja danych dla WSów zajmuje 3x mniej miejsca w RAM, dzięki temu nawet mały procek może policzyć efety dla wielu diod.
    Tak przy okazji - można użyć pamięci DataFLASH na predefiniowane ciągi bitów, najlepiej z interfejsem równoległym. Wtedy, procesor tylko wysyła zegar, a na liniach D0-D7 pojawiają się bezpośrednio ciągi danych dla WSów. Wsad można przygotować na PC.
  • #52
    karol75
    Poziom 16  
    ^^^
    Oczywiście to prawda, ale ja mogłem także robić efekt przezroczystości itd.
    Z zapisanymi danymi na karcie SD jest tego typu problem że 2GB zapełnia się bardzo szybko.
    Jeżeli jeden obrazek ma
    512 diod *3 *16 = 24 576 bajtów

    2GB =2147483648 / 24576 bajtów daje 87381 obrazów /24 k/s daje godzinę obrazów.
    To dużo i mało zależy jak do tego podejść.
    1GB to połowa.
  • #53
    chemik22
    Poziom 14  
    Kilka dni temu zamieściłem swój mały projekt z wykorzystaniem diod rgb i xmega ( https://www.elektroda.pl/rtvforum/topic3538891.html#17698570 ) i mam pewien problem który trochę nie daje mi spać...

    Kod który znajduje się w pierwszym poście @TMF z tego wątku działa to w zasadzie od strzału, choć przyznam że jednej rzeczy nie rozumiem.

    Mianowicie chodzi o kodowanie koloru diody WS2812B. Według noty katalogowej odbywa się to następująco:
    -nadanie wartość "0" powoduje że składowa danego koloru nie świeci
    -nadanie wartości "255" daje pełną moc świecenia danej składowej koloru diody.

    Natomiast korzystając z pomysłu @TMF mam efekt zupełnie odwrotny. Dla samego projektowania efektów świetlnych itd. nie ma znaczenia, niemniej przyznam że jest to dziwne i chętnie dowiedziałbym się dlaczego.. być może gdzieś popełniłem błąd (?)
  • #54
    krisRaba
    Poziom 30  
    Należałoby prześledzić w jaki sposób da się w tym układzie zamienić generowanie 0 na 1 i 1 na 0. To może być jakiś niuans w rodzaju reagowania na inne zbocze itp. Np. jeśli event system "gasi" nie ten timer co trzeba itd.
    Jeśli masz oscyloskop lub analizator stanów logicznych, to możesz podejrzeć, czy wpisanie 0x00 do UART/MasterSPI generuje faktycznie 0 na wyjściu.

    Wrzucasz cały kod bez zmian i to do takiego samego MCU, czy robisz jakąś konfigurację sam?
  • #55
    chemik22
    Poziom 14  
    Konfiguracja była na zasadzie kopiuj wklej. No jeszcze to prześledzę i muszę odpalić to na tym samym MCU co było w poście @TMF, bo to co próbowałem było na nieco innej xmedze (niby układ na porcie ten sam ale kto wie). Tak coś czuję że to jakiś problem z SPI, kombinowałem ze zmianą różnych ustawień ale nic nie pomogło, co najwyżej nie działało.. Miałem problem z dostępem do oscyloskopu ale w weekend powinno się udać to trochę po testuję
  • #56
    tmf
    Moderator Mikrokontrolery Projektowanie
    Powiem szczerze, że nie pamiętam niuansów, ale może jest tak jak piszesz, że kod dokonuje inwersji bitów. Nie jest to żadnym problemem, bo czy dioda jest włączona w pełni dla 255 czy dla 0 jest bez znaczenia, wystarczy odwrócić wszystkie zapisy. Można też w programie odwrócić kodowanie - zanegować TxD i dokonać odpwiednich korekcji timerów.
  • #57
    chemik22
    Poziom 14  
    No tak dokładnie tak, jak piszesz dla samego działania z tymi diodami, to żadnego problemu nie sprawia tylko po prostu taka ciekawość czy to ja gdzieś popełniłem błąd, czy po prostu jest tak i tak ma być.. W weekend prześledzę, co się dzieje na tych pinach z oscyloskopem, to może coś mi się rozjaśni..
  • #58
    tmf
    Moderator Mikrokontrolery Projektowanie
    @chemik22 Przypuszczam, że tak po prostu jest. Ten projekt powstawał w kilka godzin przed Świętami i zapewne nie chciało mi się tego za bardzo dopieszczać, a że nie miało dla mnie znaczenia, czy będzie inwersja, czy nie, tak to już zostało. Stąd pewnie pole do ulepszeń :)