Choinka (3D) oparta o Xmega i diody RGB (WS2812B)

Witam,


Ponieważ w końcu udało mi się dokończyć projekt który zapoczątkowałem z lekka rok temu to zamieszczam .

Pokrótce celem było stworzenie choinki 3D opartej o Xmegę128A4U oraz diody RGB WS2812B. W zasadzie nie było tu jakiejś wielkiej filozofii bo cała robota sprowadziła się do projektu w KiCad i lutowania. Powstały dwie płytki PCB tak aby po zlutowaniu dały konstrukcję trójwymiarową która pozwala mi na projektowanie "choinkowych" efektów świetlnych i jest punktem wyjścia do konstrukcji na kolejny rok.


W projekcie nie ustrzegłem się błędu który musiałem na sztywno rozwiązać kawałkiem zielonego kynara. W każdym bądź razie w załączonych plikach Gerber błędy te zostały już usunięte.


W prawdzie choinki (z różnych względów) nie udało mi się odpalić na minione święta niemniej myślę że do przyszłego roku powinienem już bez poślizgu zbudować wersję 2.0 bo mam kilka pomysłów jak wprowadzić kilka usprawnień i trochę brakuje mi tego że obecnie drzewko nie wydaje dźwięku..


W kwestii programowego rozwiązania tu nie ma nic fascynującego z mojej strony, w zasadzie zrobiłem kopiuj wklej pomysłu TMF: https://www.elektroda.pl/rtvforum/topic3411874.html Działa to w zasadzie od strzału, choć przyznam że jedna rzecz nie daje mi spokoju mimo głowienia się chyba ze dwa dni w czym leży problem.. 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 kodu zamieszczonego przez TMF w cytowanym powyżej temacie 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 (?).


Płytka w akcji



Płytki w postaci w której spędziła święta



Schematy obu płytek i pliki gerber załączyłem do tematu.

Filmik z krótką prezentacją:
https://photos.app.goo.gl/mwnZptyhnruqrcm57

Projekt OK ale wykorzystanie Xmegi128A4U to jak wjechanie w ogródek koparką.

h3c4 wrote:

Projekt OK ale wykorzystanie Xmegi128A4U to jak wjechanie w ogródek koparką.

A jaką byś proponował ? Bo chętnie się czegoś nauczę poza "błyskotliwymi komentarzami"..

Wiem że zabolało, bo spodziewałeś się samych pochwał ; ) np. Attiny13

h3c4 wrote:

Wiem że za bolało bo spodziewałeś się samych pochwał ; ) np. Attiny13

Kolego, na Attiny13 to możesz sobie zrobić migacz na dwóch ledach. Autor spodziewał się raczej konstruktywnej krytyki, a nie gawędziarskich wpisów.
Projekt jest wykonany starannie i zasługuje na uznanie.

h3c4 wrote:

Wiem że za bolało bo spodziewałeś się samych pochwał ; ) np. Attiny13

Raczej merytorycznej dyskusji niż pochwał.. No ciekawa ta propozycja, ona jest na serio czy tylko aby cos odpisać ?

Attiny13 ma porywającą ilość pamięci do zapisania efektów świetlnych i chciałbym zobaczyć w jaki sposób sprzętowo obsłużyć na tym mikrokonrolerze komunikację z diodami WS2812B bez robienia jakiś programowych wygibasów, pomrugać diodami sobie tam można ale raczej nie takimi RGB..

chemik22 wrote:

h3c4 wrote:

Projekt OK ale wykorzystanie Xmegi128A4U to jak wjechanie w ogródek koparką.

A jaką byś proponował ? Bo chętnie się czegoś nauczę poza "błyskotliwymi komentarzami"..

Xmega16A4U lub 32A4U są połowę tańsze i podejrzewam, że też to "udźwigną". Widząc ten uc w opisie naprawdę liczyłem, że to będzie jakaś płytka rozwojowa, a nie gotowe urządzenie. Po za tym ok

khoam wrote:

h3c4 wrote:

Wiem że za bolało bo spodziewałeś się samych pochwał ; ) np. Attiny13

Kolego, na Attiny13 to możesz sobie zrobić migacz na dwóch ledach. Autor spodziewał się raczej konstruktywnej krytyki, a nie gawędziarskich wpisów.
Projekt jest wykonany starannie i zasługuje na uznanie.

<CIACH>


Link

Moderated By dondu:

3.1.9. Nie ironizuj i nie bądź złośliwy w stosunku do drugiej strony dyskusji. Uszanuj odmienne zdanie oraz inne opinie na forum.

A tak przy okazji, dlaczego miałby nie zastosować XMegi? To nie jest projekt komercyjny tylko hobbystyczny.

Co do ceny poszczególnych mikrokontrolerów to jako że elektronika zajmuje się czysto hobbystycznie to mówiąc szczerze w ogóle jej nie rozważałem.

I jeszcze w temacie wyboru mikrokotrolera to swojego czasu zastanawiałem się jeszcze nad sprzętami o mniejszych możliwościach (bo początkowo takie "marnotrawstwo" trochę mnie bolało ) ale jak zacząłem liczyć ile może zajmować mi wsad programu z jakimś efektem świetlnym zapisanym w postaci tablicy to szybko się wyleczyłem z pomysłu na użycie czegoś z pamięcią poniżej 64KB, nie chciałem też dawać niewiadoma jakiej kobyły typu xmega256A3U (lub o zgrozo A1U) wiec stanęło na sprzęcie z 44 nogami..

No i fakt że ograniczyłem się na wstępie do xmega bo jakoś po prostu ją lubię.. a o gustach się nie dyskutuje podobno

Bardzo fajny projekt.

Kolego a_noob może xmega16A4U lub xmega32A4U by wystarczyła na początku. Ale co jeśli kolega wymyśli sobie jakieś bardziej skomplikowane efekty czy opcje kilku różnych efektów? W projekcie widzę 2 przyciski które mogą posłużyć do zmiany efektu. Wtedy może okazać się że jednak 16/32kB pamięci Flash to za mało. Ja zawszę wole przewymiarować uC i mieć luz.


Na dodatek nie wiem jak koledzy ale ja staram się mieć zawsze jakiś zapas popularnych i relatywnie niedrogich elementów. W przypadku uC trzymam w zapasie raczej jakieś modele z większa pamięcią. Myślę że nie jestem jedynym który taki zapas ma i jak potrzebuje to używa. Oczywiście można trzymać wersje 32A4U,64A4U,128A4U,256A4U. Tylko ile wtedy układów ma się dodatkowo i gdzie je trzymać. Ja wiem że taki uC nei zajmuje dużo miejsca. Ale zajmując się hobbystycznie elektroniką od ładnych kilku lat nazbierałem kilkaset (>500) typów układów scalonych z czego większość jest w ilości większej niż 1.

Dodano po 3 [minuty]:

Kolego h3c4 ja rozumiem że różne rzeczy mona zrobić na ATTiny13. Ale raczej wtedy nie ma się dużych możliwości rozbudowy. Podejrzewam że w tym przykładzie co pokazałeś, efekt generowany jest programowo a nie siedzi w pamięci Flash uC. Tutaj podejrzewam że autor chce mieć możliwość wgrania jakiś efektów jakie sobie wymarzy do pamięci uC. Nie wyobrażam sobie generowania bardziej złożonych efektów na uC co ma 1kB Flash i 64B RAM/EEPROM.

Dodano po 4 [minuty]:

Te ATTiny13 itp sa fajne jak układ ma robić tylko jedną ściśle określoną rzecz. Jak chce się coś więcej to szybko zaczyna czegoś brakować.

Zresztą nie krytykując nikogo ale czasem to to ATTiny się nei opłaca. Widziałem projekt gdzie użyto ATTiny13 w roli przetwornika A/D a dalej dane wysyłano do MAX7219. I niby wszystko fajnie. Ale ani to oszczędność miejsca MAX7219 jest sporym układem ani pieniędzy bo ten układ jest drogi. No chyba że ktoś z uporem godnej lepszej sprawy chce pokazywać ile z takiego ATTiny da się wycisnąć.

Xmega faktycznie lekki (no może trochę więcej niż lekki) overkill. ATmega32 lub 644 by raczej dała radę.
Swoją drogą to scalak ma moc i można było jakieś gadżety dodać, np. sterowanie przez RS232 z komputera efektami, zmiana koloru na "klaskacz", może nawet termometr (zmiana koloru zależna od DS18B20), generalnie sporo pomysłów tak jak sporo miejsca w pamięci flash

Swoją drogą to by się przydały płynne przejścia (interpolacja) jak w konsoletach DMX gdzie ustawiasz chaser i możesz mieć płynne przejścia między zaprogramowanymi stanami. Moim zdaniem brak tego trochę psuje efekt bo wygląda to jakoś tak sztucznie. Swoją drogą można nawet obsługę jakiejś formy DMX zrobić (wsadzić jeszcze bardziej kozacki scalak z WIFI i zrobić artnet node)

Kolego fotomh-s nie przesadzał bym z tym że xmega t overkill.

Jest wiele zalet xmeg które nawet w prostych projektach warto wykorzystać:

-uporządkowane i czesto intuicyjne nazwy rejestrów, we wszystkich uC w serii (a może i nawet innych też, nie używałem serii B,C,E). Niezwykle prosto przenieść kod z np xmegi128A3U na xmega64A4U. W przypadku regularnych AVR serii ATmega tak pięknie często nie było.

-brak konieczności użycia kwarcu nawet przy projektach wymagających stabilności (RS232,RS485 a nawet USB)

-nie zablokujesz tak łatwo xmegi jak atmegi poprzez złe ustawienie fusse-bit. Szczególnie popularne było blokowanie przy przejściu z oscylatora wewnętrznego na zewnętrzny kwarc. Sam tak kilka uC "ubiłem"

-linia programowania (PDI) nie jest współdzielona z portami uC, jak w przypadku interfejsu ISP w atmegach. Czasem były z tym problemu jak coś na tych liniach też wisiało a ktoś nie zastosował buforu itp.

W zasadzie wszystkie projekty jakie robię teraz to robię na xmega. Mimo że jeszcze kilka atmeg gdzieś leży. Ale jakoś przyjemniej mi się te uC programuje.

paluszasty wrote:

-brak konieczności użycia kwarcu nawet przy projektach wymagających stabilności (RS232,RS485 a nawet USB)

Ja na ATmegach nigdy nie musiałem kwarcu wpinać, mimo stosowania w systemie odpalającym UARTa i to w środowisku zakłóceń radiowych (proste moduły RF bez żadnych gadżetów podpięte pod UART, nie to co te nowe LORA itp.). Dodam tylko że system działał w różnych temperaturach.

paluszasty wrote:

-uporządkowane i czesto intuicyjne nazwy rejestrów, we wszystkich uC w serii (a może i nawet innych też, nie używałem serii B,C,E). Niezwykle prosto przenieść kod z np xmegi128A3U na xmega64A4U. W przypadku regularnych AVR serii ATmega tak pięknie często nie było.

Jak programujesz w ASSembly to może i ma znaczenie. W przypadku języków wysokiego poziomu nie ma problemów z przekompilowaniem na inny procek.

paluszasty wrote:

-nie zablokujesz tak łatwo xmegi jak atmegi poprzez złe ustawienie fusse-bit. Szczególnie popularne było blokowanie przy przejściu z oscylatora wewnętrznego na zewnętrzny kwarc. Sam tak kilka uC "ubiłem"

Ale ubijesz ją podpinając przypadkowo coś z poziomem 5V

Ja ostatnio zamówiłem płytkę z STM32, zobaczymy ile to warte, Xmega jakoś mi nie podchodzi właśnie z powodu braku tolerancji na poziomy TTL. STM ma znaczną część wejść 5V tolerant i kilka innych gadżetów. Do tego SRAMu jest od groma, sporo peryferjów, ZTCP to system przerwań o wiele lepszy, można by dalej wymieniać.

fotomh-s wrote:

Swoją drogą to scalak ma moc i można było jakieś gadżety dodać, np. sterowanie przez RS232 z komputera efektami, zmiana koloru na "klaskacz", może nawet termometr (zmiana koloru zależna od DS18B20), generalnie sporo pomysłów tak jak sporo miejsca w pamięci flash

I o to mi właśnie chodzi, tutaj ten scalak się marnuje. Jednak RS232 nie ma tu większego sensu bo uc jest w wersji z USB, do tego choinka również jest zasilana z microUSB, więc i złącze jest na płytce... tylko wykorzystane w takim samym stopniu jak uc

paluszasty wrote:

Kolego a_noob może xmega16A4U lub xmega32A4U by wystarczyła na początku. Ale co jeśli kolega wymyśli sobie jakieś bardziej skomplikowane efekty czy opcje kilku różnych efektów? W projekcie widzę 2 przyciski które mogą posłużyć do zmiany efektu. Wtedy może okazać się że jednak 16/32kB pamięci Flash to za mało. Ja zawszę wole przewymiarować uC i mieć luz.

Litości, tam są 32 diody. Zgodzę się z tym, że lepiej mieć zapas, niż miałoby zabraknąć ale... tam są trzydzieści dwie diody... jakie to mogą być skomplikowane efekty?

Jeśli ta cała dyskusja sprowadza się w głównej mierze do tego że zamiast xmega128a4u lepiej byłoby dać xmega16a4u bo w tym pierwszym pamięć się marnuje to nic nie przeszkadza aby na płytkę wlutować zamiast 128a4u tą 16a4u bo układ nóżek identyczny. Ja wlutowałem na maxa co było dostępne bo skoro robię jedną płytkę do zabawy to po co się ograniczać i później żałować..

Co do komunikacji po USB to z pewnością w nowej wersji na kolejne święta taka będzie.

a_noob wrote:

fotomh-s napisał:
Swoją drogą to scalak ma moc i można było jakieś gadżety dodać, np. sterowanie przez RS232 z komputera efektami, zmiana koloru na "klaskacz", może nawet termometr (zmiana koloru zależna od DS18B20), generalnie sporo pomysłów tak jak sporo miejsca w pamięci flash

Fajny pomysł z tym DS18B20 itd.

Płytki gdzie zlecałeś i jaki był ich koszt?

Zamówiłem z PCBWay albo Jlcpcb. już nie pamiętam gdzie było taniej, wyszło jakieś 100-150zł za łącznie 10 płytek czyli 5 kompletów choinek.