logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

AVR - UART xmega vs mega-róznice wady i zalety

zbynio_k 25 Lut 2016 19:45 2373 22
  • #1 15470894
    zbynio_k
    Poziom 10  
    Witam,
    ostatnio zajmuję się sterownikiem WS2812 dla LED RGB i znalazłem sposób na inną komunikację z tym sterownikiem a mianowicie przez UART AVR'a, niestety (pomijając teorię) trzeba "zanegować pin Tx" co w xmega da się zrobić

    //Zaneguj wyjście - domyślnie będzie w stanie niskim
    PORTC_PIN3CTRL=PORT_INVEN_bm;

    Czy dla mega istnieje coś podobnego ?
    Oczywiście można dać po prostu inwerter na wyjściu Tx ale to jest robienie na okrągło jeżeli istnieje możliwość programowego ustawienia megi
  • #2 15471016
    BlueDraco
    Specjalista - Mikrokontrolery
    Biorąc pod uwagę fakt, że za 10 zł można kupić płytkę z STM32F103C8, który popędzi WS2812 sprzętowym SPI z DMA, gra chyba nie jest warta świeczki.
  • #3 15471029
    tmf
    VIP Zasłużony dla elektroda
    @zbynio_k Zrób komunikację w oparciu o SPI. W ATMega nie zanegujesz pinu, gdyż ten procek nie dypsonuje taką funkcjonalnością. BTW, skoro masz kod dla XMEGA, to po co chcesz zastosować ATMega?
  • #4 15471089
    zbynio_k
    Poziom 10  
    Dzięki koledzy,
    1. BlueDraco > wlazłem w megi i nie chciałbym się przestawiać :cry:
    2. tmf > to Twój przykład z książki a XMegach i jak wyżej
    pomyślę jak zaadoptować SPI dla megi albo zwykły 7404 :D

    Tak myślałem, że się nie da ale szukałem potwierdzenia:)
  • #5 15471177
    Piotr Piechota
    Poziom 22  
    Przy zasilaniu taśmy z 5V dla XMega czy STM32 wypadało by dać jakiś bufor w celu podniesienia napięcia, żeby spełnić wymagania WS2812.
  • #6 15471221
    BlueDraco
    Specjalista - Mikrokontrolery
    Stary AVR po prostu się do tego nie nadaje. Nie wszystko da się dobrze zrobić na prehistorycznych mikrokontrolerach, a robienie na siłę, keidy można taniej i lepiej, jest niezbyt sensowne. Niedawno dyskutowaliśmy na ten temat tutaj z kol. TMF. ATmega nie obsłuży 260 tysięcy przerwań na sekundę potrzebnych do teransmisji na przerwaniach, a obsługa transmisji do WS2812 (z przerwaniami czy bez nich) uniemożliwia obsługę jakichkolwiek przerwań i wykonywanie w tym czasie jakichkolwiek innych czyności.

    PP: I na to są sposoby - można obniżyć napięcie zasilania WS2812 do 4.5 V albo podbić napięcie na wyjściu (tryb OD albo dioda Schottky i rezystor podciągający do +5).
  • #7 15471255
    Piotr Piechota
    Poziom 22  
    Obniżanie napięcia zasilania przy dłuższych zestawach to nie najlepszy pomysł. OD chyba lepszy - tylko rezystor podciągający nie może być zbyt duży.
  • #8 15471300
    BlueDraco
    Specjalista - Mikrokontrolery
    Akurat obniżenie napięcia zasilania WS2812 jest b. dobrym pomysłem, sugerowanym przez producenta, bo 5 V to za dużo - przy niższym napięciu mniej się grzeje. A tak z praktyki, to nie miałem nigdy problemu ze sterowaniem taśmy z STM32 bez żadnych dodatkowych środków. Oczywiście w warunkach niepokojowych wypadałoby zapewnić odpowiednie poziomy napięć na najgorszy przypadek.
  • #9 15471346
    Piotr Piechota
    Poziom 22  
    Też sterowałem taśmą z STM32 bezpośrednio i działało - ale to poza specyfikacją. Przy zasilaniu nawet 5V taśmy z 300 led'ami przy "silnym" wysterowaniu napięcie na drugim końcu spadało poniżej 3V i zmieniało się odwzorowanie kolorów - czasem tego 0.5V szkoda.
  • #10 15471450
    tmf
    VIP Zasłużony dla elektroda
    zbynio_k napisał:
    Dzięki koledzy,
    2. tmf > to Twój przykład z książki a XMegach i jak wyżej
    pomyślę jak zaadoptować SPI dla megi albo zwykły 7404 :D


    W przykładach do II wyd. "Język C..." masz obsługę WS na ATMega.
  • #11 15471882
    jnk0le
    Poziom 18  
    BlueDraco napisał:
    ... ATmega nie obsłuży 260 tysięcy przerwań na sekundę potrzebnych do transmisji na przerwaniach ...

    260k przerwań opróżniających bufor atmega bez problemu obsłuży - oczywiście nie może być to kod 'ala arduino.

    Przykładowo uart można zmieścić w 50 43 cyklach: https://github.com/jnk0le/Easy-AVR-USART-C-Library/blob/master/usart.c#L1976

    Dla 16MHz przerwania zajmą ok. 80 70% (70 56 dla 20MHz) czasu procesora, zakładając że przez cały czas będzie coś animowane na WS'ach (choć w tym przypadku lepiej użyć coś z DMA).
  • #12 15472153
    BlueDraco
    Specjalista - Mikrokontrolery
    Obsłuży przy 16 MHz i programowaniu w asemblerze lub wstawkach i NAKED. Czyli - jak się dobrze nagmnastykujemy, to może uda nam się uzyskać to samo, co na każdym Cortexie mamy bez asemblera, bez problemów i taniej, z dużym zapasem mocy obliczeniowej.

    Ponadto ATmega jeśli obsłuży te 260 k przerwań UART czy SPI, to nie może obsłużyć żadnego innego przerwania, więc p. ne zareaguje na transmisję szeregową ani timer.
  • #13 15472277
    kamyczek
    Poziom 38  
    BlueDraco napisał:
    Biorąc pod uwagę fakt, że za 10 zł można kupić płytkę z STM32F103C8, który popędzi WS2812 sprzętowym SPI z DMA, gra chyba nie jest warta świeczki.


    Biorąc pod uwagę ,że to dział AVR może wystawisz sobie ostrzeżenie , poza tym jaki sens widzisz w przesiadaniu się z AVR na st z powodu braku możliwości odwrócenia stanu portu na TX czy RX ? do tego wystarczy tranzystor , inwerter ttl , a dla bardziej kapryśnych programowy uart i to nawet w jedną stronę , bo nic nie przeszkadza temu żeby nadawać programowym a odbierać sprzętowym czy odwrotnie . Długość kodu jaka jest potrzebna do realizacji uarta mieści się nawet w attinny 4 ,10 , 13 itp za 2,5 pln jaki tu widzisz zysk w układzie za 10 pln. Czemu nie proponujesz DS PIC-a . Na starych poczciwych AVR-kach można budować bardzo złożone i wymagające projekty tylko czasem trzeba robić to z głową i nie korzystać z gotowych bibliotek i bezmyślnego doczepiania 100kB śmieci jak to robią niektórzy w C .
  • #14 15472324
    Piotr Piechota
    Poziom 22  
    Użycie programowego uarta w celu sterowania WS2812 - to taki żart? Kamyczku wiesz jak steruje się tymi LED'ami? Chodzi o dość precyzyjne generowanie dość szybkich impulsów. Używa się sprzętowych układów szeregowych troszkę na siłę je naginając do potrzeb (bo pasującego do WS w popularnych uC nie ma) więc programowa ich emulacja dla tego zastosowania to delikatnie mówiąc zły pomysł.
  • #15 15472333
    grko
    Poziom 33  
    Cytat:

    Czemu nie proponujesz DS PIC-a . Na starych poczciwych AVR-kach można budować bardzo złożone i wymagające projekty tylko czasem trzeba robić to z głową i nie korzystać z gotowych bibliotek i bezmyślnego doczepiania 100kB śmieci jak to robią niektórzy w C .


    Ostatnio robiłem sterowanie tymi diodkami na ATinty26. I w 2KB pamięci zmieściło się:
    - obsługa diodek przez GPIO
    - kilkanaście patternów dla matrycy diodek
    - prosta komunikacja po USI (na czas odbioru bajtu diody przestawały działać)

    Wszystko było napisane w C (+ kilka wstawk w asm).
  • #16 15472560
    kamyczek
    Poziom 38  
    Piotr Piechota napisał:
    Chodzi o dość precyzyjne generowanie dość szybkich impulsów


    W programowaniu nie ma określeni dość szybkie to nie literatura i poezja tu jest czysta matematyka 0,05us *7 =0,35us czyli najkrótszy potrzebny czas to 7 taktów zegara dla AVR z 20MHz zegarem czas bitu (1,05 do 1,4us) razy 24bit/led razy ilość diod plus 50us to czas odświeżania dla całego łańcucha . Tu nie ma co płakać ,tylko dobrze napisać program w asemblerze . Świetne ćwiczenie no to panowie może zrobimy zawody kto to zmieści w najmniejszym mikrokontrolerze i objętości kodu ;) Kto się pisze ?
  • #17 15472605
    grko
    Poziom 33  
    Cytat:

    Świetne ćwiczenie no to panowie może zrobimy zawody kto to zmieści w najmniejszym mikrokontrolerze i objętości kodu ;) Kto się pisze ?


    Jeszcze powinniśmy wziąć pod uwagę czas w jakim to się zrobi. W asm zajmie to o rząd wielkości dłużej.
  • #18 15472759
    Piotr Piechota
    Poziom 22  
    kamyczek napisał:
    (...) 0,05us *7 =0,35us czyli najkrótszy potrzebny czas to 7 taktów zegara dla AVR z 20MHz zegarem czas bitu (1,05 do 1,4us) razy 24bit/led razy ilość diod plus 50us to czas odświeżania dla całego łańcucha


    Sporo pracy dla małego AVR'ka zdziwiła mnie więc Twoja propozycja rozwiązania problemu programowym UART'em:
    kamyczek napisał:
    (...)a dla bardziej kapryśnych programowy uart i to nawet w jedną stronę, bo nic nie przeszkadza temu żeby nadawać programowym a odbierać sprzętowym czy odwrotnie . Długość kodu jaka jest potrzebna do realizacji uarta mieści się nawet w attinny 4 ,10 , 13 itp za 2,5 pln

    Choć myślę, że pisząc o programowym porcie szeregowym nie doczytałeś, że autorowi chodziło o sterowanie WS2812.
    Użycie procesora z DMA pozwala bardzo wydajnie obsłużyć "dziwny" protokół WS2812.
    W moich zabawach z tymi LED'ami użyłem STM32 i timera który przy pomocy DMA otrzymywał czasy kolejnych bitów zawartych w tablicy. Taki sposób nie obciąża głównego programu prawie wcale.

    Pozdrawiam
    PS
    konfiguracja timera i dma dla stm32f4 do sterowania ws2812
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Edit:
    filmik z zabaw z LED'ami:


  • #19 15473226
    piotrva
    VIP Zasłużony dla elektroda
    Ja dodam od siebie:
    1. Po licha negować pin w AVR - przecież ESP ma normalny UART - podpinałem ESP z AVR i działało beż żadnego negowania
    2. W dzisiejszych czasach taniej jest wziąć lepszy procesor niż zapłacić za kilka (naście/dziesiąt) godzin więcej pracy programisty. Poza tym wspomniane STM wygrywają z AVR także na polu cenowym
    3. W podobny sposób jak @Piotr Piechota sterowałem z stm32F103 około 1000 diodek WS2812B. Niestety w AVR trochę ramu na to braknie no i na czas komunikacji i wgrania danych dla 1000, czy nawet 100 diodek wszystko zgaśnie - u mnie w międzyczasie procek wczytuje dane z karty SD i jeszcze się nudzi ;)
    4. Owszem - fajnie jest wykorzystać zasoby danego modelu/układu na 110% i pokazuje to kunszt programistyczny, a czasem kombinowanie wynika z braku dostępu do innych układów czy braku czasu/chęci/możliwości poszerzenia swojej wiedzy o nowe układy.
  • #20 15473277
    tronics
    Poziom 38  
    @U.P. - prawda, ale czytając od początku wygląda na to, że autor liznął też AVR w formie xmega, które to ma DMA i 32MHz więc ani czasu, ani zasobów do obsługi nie braknie. Robi to w tym samym IDE z podobnym zestawem narzędzi. Nie musi poznawać zupełnie odmiennej rodziny (a tylko nieco inną). Też lubię STM32 ze względu na dostępność, cenę i możliwości, ale w tej sytuacji atxmega też spełni wszystkie wymagania :) A Atmedze można zostawić mryganie diodką, termometr na ds18b20 itp. jeśli ktoś rzeczywiście ma awersję do zasilania <5V, ale jeśli dobrze czujemy się w AVR to polecam Xmega, jeśli ogółem chcemy czegoś nowego to jak najbardziej ARM zamiast zamykać sobie drogę wchodząc w "odświeżynkę" 8bit.
  • #22 15475924
    maslak
    Poziom 14  
    Kiedyś do bezpośredniego sterowania z SPI wykonałem taki układ, wadą jest że wymaga aby SPI działało z częstotliwością około 400kHz co nie zawsze jest możliwe do uzyskania, ale jeżeli mamy taka możliwość to zyskujemy bezpośrednie wysyłanie bajtów kolorów.

    AVR - UART xmega vs mega-róznice wady i zalety
  • #23 15631482
    zbynio_k
    Poziom 10  
    Myślę, że temat można zamknąć
    pozdrawiam
REKLAMA