Jestem na etapie projektowania płytki pod sterownik MagicLED. Na razie złożyłem pierwszy prototyp na stykówce i wszystko działa.
Kolejnym etapem projektu będzie dodanie obsługi pilota IR. I tu pytanie: jak się za to zabrać? W trakcie wysyłania sekwencji do paska LED wyłączam przerwania. Przycisk na pilocie mogę wcisnąć w dowolnym momencie, nawet wtedy, gdy procek mam "zablokowany" transmisją do WS2812.
Czy w przypadku podłączenia pinu z odbiornika IR do pinu Rx UARTa w buforze UARTa będę miał dane mimo wyłączonych przerwań? Flaga przerwania UART będzie ustawiona?
A może jest inny sposób, którego nie widzę na razie?
Nie chcę gotowca, potrzebuję tylko naprowadzenia.

Kolejnym etapem będzie dodanie VUSB, żeby konfigurację robić przez USB, więc o to też będę pytał. Albo przeczytam w OB, jak będzie wcześniej. Ale najpierw ogarnę pilota (albo i nie)

A jak sobie to kolega wyobraża? niestety jak przerwania wyłączone to i UART może nie zdążyć


Pracuję nad tym ale to jeszcze troszkę potrwa


No w OB na pewno będzie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jeśli diod jest mało (poniżej 30-40) można bez specjalnych zabiegów zmieścić się z odświeżaniem diod i obsługą IR. Jeśli jest więcej, ale odświeżanie jest stosunkowo rzadkie można się pogodzić z przypadłością, że czasem pilot "nie załapie". Mowa oczywiście o obsłudze LEDów przez typowe machanie pinem. Jeśli LEDów jest więcej/odświeżanie częste oczywistym rozwiązaniem jest sprzętowe sterowanie LEDami (UART lub SPI). Alternatywnym rozwiązaniem jest okresowe dopuszczenie przerwań IR w procedurze generującej przebieg dla diod. Wygenerowany przebieg narusza specyfikację WS2812 więc dla takich czy innych partii diod procedura może nie działać.
W metodzie "machanie pinem" nie ma możliwości jednoczesnego odświeżania diod i komunikacji przez VUSB. Można zrobić tak, żeby aktywować VUSB i jednocześnie deaktywować odświeżanie WS2812 przy podłączeniu kabla USB, a przy odłączeniu na odwrót.

IR a UART to całkiem inne protokoły (przynajmniej jeśli mowa o "zwykłych" AVR)

_________________
Think for yourself and question authority.

Nie wiem jak działa MagicLED więc poniższy pomysł może być nietrafiony lub wręcz głupi
Nie myślałeś żeby ISR UART tylko i wyłącznie odczytywało kod otrzymany z pilota do bufora ? Potem przed odświeżeniem LED (w pętli main) możesz sobie pobrać ostatnie dane z bufora i tyle bez straty danych, ewentualnie z opóźnieniem o 1 wykonanie maina. Jeśli z czasem na wykonanie operacji krucho to może coś da się do LUT wrzucić, np. kod z pilota i odpowiadające mu ustawienie wyprowadzeń?

PS.
Też czekam na OB, w planie jest własny JTAG

Dziękuję za tak duży odzew. Postaram się wszystkim odpowiedzieć.
Że w buforze UDR będę miał ostatni odebrany kod z pilota? Myślałem, że dane są sprzętowo zapisywane, ale nie jest wywoływana funkcja obsługi przerwania.
Trochę? Dłużej niż pół roku?
Dlatego z USB czekam na OB. A chciałem wcześniej ogarnąć IR

Diod mam być docelowo 150 (taki pasek mam), więc raczej się nie wyrobi.
Taki sposób rozważałem. Temat założyłem, bo myślałem, że macie jakieś sprytne sposoby.
W atmedze? W jaki sposób?
To rozwiązanie odpada, ponieważ USB na razie nie komentuję, Mirek obiecał, że w OB będzie taki projekt, więc wtedy spróbuję.
O zwykłych, zwykłych. Uparłem się zrobić to na małym procku. Z UARTem zaszalałem, zapomniałem o przebiegu dla 0 i 1 w protokole dla WS2812.

Mniej więcej tak, tylko bez przerwania - zakłóci mi transmisję z diodami. Chciałem wykorzystać bufor UDR, ale to na 99,99% nie wyjdzie.
Wysłanie danych mam w pętli głównej, mniej więcej raz na sekundę.
Czasu pomiędzy kolejnymi wysłanymi danymi mam sporo, problem mam z tym, żeby kod z pilota odczytać w czasie wysyłania danych do LED.
Ale że jak?

LookUp Table (LUT), tablicowanie wyniku lub częściowego wyniku operacji na LED.
Czyli np. odbierasz po IR kod 0x55, w tablicy pod tym adresem (albo adresem z offsetem) masz dokładnie to, co chcesz wysłać na LEDy.


Dlaczego bufor UART miał by nie działać, wykorzystujesz go do jeszcze czegoś w tym czasie? Zawsze możesz w miejscu gdzie przerwanie nie może nastąpić wyłączyć przerwania, wtedy przerwanie nastąpi zaraz po ponownym włączeniu przerwań i zapobiegnie przepełnieniu bufora, o ile zdąży (przynajmniej w PIC tak jest).
Napisz jaki to procek i z jaką prędkością chodzi w MIPS (miliony instrukcji na sekundę), to może jednak da się zmajstrować takie przerwanie żeby nie zakłóciło komunikacji z LED.

Kiedyś też walczyłem z tym problem do podświetlanego stolika który miał być sterowany przez pilota i przez BT. Diód mam ok 260 szt. Specjalnie do tego projektu zainteresowałem się atxmega które to posiada DMA a procesor ma sporo czasu na komunikacje z użytkownikiem i inne zadania.

No właśnie. Do tego zadania na procesorze ATmega potrzeba "kunsztu", ale nie tylko "rzemieślnictwa". Z tego powodu osobiście bym tego nie robił, do zadania potrzeba dobrze rozgarniętego programisty lub właściwego sprzętu. Trzeba wiedzieć, że V-USB działa w pollingu, gdzie polling ten wymaga ścisłego okna czasowego oraz polling ten jest napisany w asemblerze, co dodatkowo może utrudnić sprawę, nie mówiąc już o WS2812B, który również bez przerwań raczej położy ten projekt. Stawiam osobiście tezę, ale mogę się mylić, że dla 260 diod (z sensowny odświeżaniem ok 30 fps) to tego nie da się na "słabej" ATmedze wykonać.
Jeśli chodzi o mnie to bardzo tani STM32F042F6Px wykonuje podstawową pracę USB+WS2812 właściwie bez użycia procesora, dodane IR i jeszcze wielu zadań nie będzie kłopotem (i nie chodzi tu o mityczne "32 bit") tylko własnie o "sprzęt". W przygotowaniu mam opis właśnie takiego projektu, który będzie wyśmienitą bazą do wykonania wielu lampek choinkowych sterowanych "czymkolwiek". Jeśli, ktoś ma problem z wyborem sprzętu, to niech jeszcze trochę poczeka
Wiem, że piszę trochę nie w temacie, wybaczcie , ale gdyby temat brzmiał "jak to zrobić najlepiej, żeby się nie narobić" to rozwiązanie jest takie jak opisałem.

Ja myślałem, że tobie chodzi o odbieranie przez uart z buforowaniem. Oczywiście, że sam UART posiada sprzętowy bufor, który potrafi zapamiętać (hmm nie pamiętam teraz dokładnie) ale chyba nawet 2 odebrane bajty - ale to zależy jakiego kodowania użyjesz bo tych bajtów musiałoby być odebranych zwykle kilka a nie tylko jeden. Trzeba poćwiczyć - jakiś program prosty testowy sobie napisać do takiego odbierania. Czyli nastawić uart na nasłuch, zablokować przerwania, kliknąć pilotem, odblokować przerwania i żeby wysłał np do terminala w HEX to co odebrał i będziesz miał.

------------------------ [ Dodano po: 24 minutach ]


eeeeh Zelaota - to tak jakoś b.dziwnie brzmi a szczególnie to zestawienie programisty z właściwym sprzętem, to tak jakby właściwy sprzęt miał coś zrobić sam za programistę Hmmm tylko czy to miałoby być logicznym dowodem na poparcie tezy o tym, że programista jest rozgarnięty ? Coś mi tu nie pasuje Moim zdaniem to wszystko zależy po prostu czasem od dobrego pomysłu i pewnego uporu w rozwiązywaniu problemów, aczkolwiek wiadomo że "głową muru nie przebijesz" i nie zawsze warto "kopać się z koniem" ... jeśli coś jest rzeczywiście poza zasięgiem 8-bitowca to nie ma co się szczypać i sięgać po lepszy sprzęt.


To oczywista oczywistość i nawet nie ma co marzyć ... ale kolega autor widać zdaje sobie z tego sprawę bo napisał, że chce V-USB użyć tylko do celów konfiguracyjnych a więc wtedy diody LED mogą nie świecić albo może - nie wyświetlać animacji. (Jeśli dobrze go zrozumiałem?) Wtedy nie będzie nawet NAJMNIEJSZYCH problemów.


A ja stawiam tezę, że hmmm może z pewnym "trickiem" da się to zrobić nawet dla 500 diod albo i ich większej ilości I to nawet nie teza tylko bardzo długo mnie ten temat męczył swego czasu jak zrobiłem sterownik do kuchni na ok 280 diod ... no i naturalnie jak chciałem go sterować komenadami AT przez UART to niestety nie zawsze udawało się sterownikowi odebrać komendę AT w całości. Zadanie to było dużo trudniejsze niż odebranie kodu z pilota z podczerwieni bo jest on stosunkowo krótki w porównaniu do niektórych komend AT składających się z kilkunastu albo nawet kilkudziesięciu bajtów!

Podsumowując, dzisiaj już nie ma tego problemu w sterowniku pomimo, że nadal robi DOKŁDANIE to co robił jeśli chodzi o wyświetlanie na pasku Madżik LEDów ... tylko tak jak pisałem wyżej - to na razie kompletnie nie nadaje się do jakiejś publikacji czy omówienia - muszę mocno uporządkować kod, jak przyjdzie czas, jeszcze to zoptymalizować i przede wszystkim ! zrobić tak, żeby mogło to działać tak nie tylko z komendami AT czyli przez UART ale właśnie żeby podobny sposób zastosować dla obsługi pilotów i wielu wielu innych tego typu źródeł odbierania danych. Jak zobaczyłem efekt pierwszy raz zadziałania tego pomysłu to byłem mocno zdziwiony bo też już w zasadzie byłem na etapie poddania się i klepania ręką w matę jak podczas zawodów zapaśniczych myśląc o przejściu na ARM. No ale niestety - znowu się udało ze zwykłym kocim 8-bitowcem bez "sterydów sprzętowych" ... a prace nad rozwojem tego projektu przerwał ORANGEBOOK ... dlatego będzie trzeba troszkę poczekać.

Bo tak jak piszesz, taki STM z USB i DMA jeśli chodzi o możliwości to nawet nie ma co mówić albo porównywać do biednej ATmegi Dla STM'a jak się to oprogramuje to będzie znaczyło tyle co puścić zdrowego bąka jak chodzi o wysłanie danych na paski madżik LED.


No! jak Cię znam i projekty jakie wychodzą spod twojej ręki, to będzie na pewno gratka dla wszystkich, którzy bawią się prockami !

------------------------ [ Dodano po: 25 minutach ]

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dziękuję za kolejne podpowiedzi.
Od razu zaznaczę (zapomniałem wcześniej), że projekt ma być na Atmega88 (bo takie mam pod ręką).
ATxmega, ARM, odpadają. Chcę użyć jak najprostszego procka.
USB ma być tylko do konfiguracji, zresztą zaznaczyłem, że to na przyszłość. I jestem prawie pewien, że na atmedze mi to zadziała.
No tak, ale nie z przygotowaniem danych do wysłania mam problem. W czasie pomiędzy wysyłaniem danych do LEDów mam tyle czasu, że mogę sobie tablicę wypełniać po jednym bicie, i tak zdążę. Problem mam z tym, że transmisji do LEDów nie mogę przerwać - wysłanie stanu niskiego/wysokiego to ok. 1200 ns, atmega taktowana kwarcem 11,0592 MHz nie obsłuży mi przerwania od pilota w tak krótkim czasie.
Z buforem od UARTa zamotałem się trochę, ale Mirek to już wyjaśnił:
To mnie naprostowało. W skrócie, nie wiem, dlaczego, wydawało mi się, że pilot nadaje na takim samym protokole jak LEDy. Pomroczność jasna
Do podświetlenia szafek kuchennych wystarczy mi 0,5 fps, żadnych animacji nie będzie.

Przypomnę, że temat dotyczył tylko pilota IR. O USB wspomniałem przypadkiem, że to plan na przyszłość. I doskonale zdaję sobie sprawę z tego, że podczas transmisji USB nie będę mógł realizować transmisji z LED.
Natomiast jeżeli ktoś wie, jak sprzętowo zrealizować transmisję z MagicLEDami w prostych AVR, to chętnie dowiem się, jak to zrobić.

Chętnie się zapoznam z projektem.
To i ja wiem, że tak się da. Ale chcę to zrobić bez sprzętowych ułatwień, żeby sprawdzić, czy jestem tylko rzemieślnikiem z programowania, czy może jednak stać mnie na odrobinę kunsztu.

Może jeszcze jedno zdanie, na wypadek, gdyby ktoś chciał się jeszcze wypowiedzieć.
Zapomnijcie o USB w opisanym przeze mnie projekcie. Założenia są takie:
1) procek ATmega88
2) pasek MagicLED (WS2812(B)) - 150 diod, może więcej
3) zmiana kolorów świecenia paska za pomocą pilota IR
4) częstotliwość odświeżania - ok. 1 Hz

A z innej beczki - czemu nie dasz szybszego kwarcu?

Moim zdaniem przy tak wolnej częstotliwości odświeżania to nie masz co się martwić, może czasem (choć rzadko) pewnie będziesz musiał jeszcze raz kliknąć klawisz pilota i to tyle.

Aha tylko dodaj do procka kwarca porządnego czyli 20 MHz i zrób obsługę podczerwieni na przerwaniu ICP z Greenbooka - bo to na prawdę dobrze opracowana metoda i b.szybka. Może nawet przy swoim odświeżaniu w ogóle nie zauważysz tego, że czasem jakaś pojedyncza ramka się nie przedostanie.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A jeszce innej beczki, czemu nie pójdziesz na skruty i nie dasz jednego uC do pilota i drugiego do LED.

_________________
de gustibus non est disputandum

Docelowo zapewne dam. Akurat 11,0592MHz miałem pod ręką (na zestawie ATB ). Chociaż przyznam, że myślałem raczej o 12 MHz, ponieważ mam kilka(naście) sztuk w fajnych obudowach SMD, a projekt ma powstać z "przydasiów"
Na takie działanie właśnie liczę.
Skorzystam. Ale jak znam życie, to dużo czasu minie, zanim to ogarnę - obowiązki nie pozwalają na hobby.
Do atmegi88? Microchip podaje 16 MHz max. Zresztą, chyba i tak spróbuję na 12MHz. A jak nie będzie chciało działać, to wtedy zmienię kwarc.
Myślałem o tym. Ale nie chcę rozbudowywać projektu. Jeśli da się na jednym procku, to chcę to zrobić na jednym

Przecież w GB masz gotową do działania bibliotekę i nic w zasadzie nie trzeba ogarniać, szczególnie jeśli masz pilota RC5. Po prostu



to taki krótki pseudo kod


Ja cię nie mogę zawsze się dziwię jak ludzie boją się szybkich kwarców podczas gdy szybsze taktowanie ZAWSZE ratuje nam przysłowiowy tyłek ... toż nie chodzi o to że będzie czy nie będzie działać. Chodzi o to, że przy tak wolnym taktowaniu typu 11 czy 12MHz i przy tak długim pasku - będziesz miał BAAARDZO MAŁO CZASU na inne operacje. To trzeba kiedyś zrozumieć - jak to działa. Poza tym jeśli nawet bym się aż tak bał dać 20MHz (chociaż nie wiem czego się bać) to i tak dałbym najwyższy możliwy - a ty się upierasz przy ślimakach 11-12MHz ... dlaczego ? Przy diodach MAGIC LED, szczególnie jest ważne właśnie to szybsze taktowanie.

A na koniec dwie sprawy:

1. kwarce 20MHz są wszędzie dostępne i kosztują grosze - kompletnie nie widzę sensu wymiany 11,052 MHz na 12 MHz to da tyle co nic.

2. przetaktowanie procka z 16 MHz do 20 MHz w ogóle nie jest grzechem i nic by się nie działo, najdziwniejsze jest jednak to, że kolega nie zajrzał nawet do noty PDF tych nowych procków w której stoi jak byk:



No, chyba że ty piszesz o ATmedze88 bez literki P na końcu to rzeczywiście ona jest wg noty do 16 MHz ale ileż ja procków nawet zwykłych atmeg32 biednych starych puszczałem na 20MHz ba ... a atmegi88P/168P/328P to spokojnie nawet 24MHz przetaktowuję bez NAJMNIEJSZYCH skutków ubocznych.

Sprawdź bo może masz jednak tą z P czyli ATmega88P a jeśli nie - to i tak daj 20 MHz mówię ci. I w ogóle zaopatrz się w kilka porządnych kwarców takich jak:

a) 18,432 MHz (przyjazny dla RS232) a za to już dużo dużo szybszy
b) 20 MHz

ja sobie nie wyobrażam życia bez takich kwarców pod ręką - już nie wspominając o kwarcach 16 MHz.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Bibliotekę wiem, że mam. Chodziło mi o czas na to, żeby siąść nad projektem.
Pilot jest z jakiegoś prostego sterownika do LEDów RGB. Odczytując kody przez analizator salae wychodzi mi na to, że to kodowanie NEC.
Nie boję się. Jak wspomniałem, mam mnóstwo kwarców 12 MHz w obudowie mniej więcej 5x2 mm. Chcę się zmieścić na płytce 45x25 mm. Więc szukam miejsca. A jestem typem człowieka, który kupi coś dopiero wtedy, kiedy nic z szuflady nie dopasuje
Wiem, że to żadne wytłumaczenie, ale mogę odświeżać rzadziej. To ma być podświetlenie szafki w kuchni, nie będzie żadnych animacji.
Właśnie takie procki mam. I znowu - są, więc chcę je wykorzystać.
20MHz chyba nie mam, pozostałe podane przez Ciebie mam. Ale w dużych obudowach.
Bo mam
Chyba jednak trzeba będzie zrobić zamówienie na nowe kwarce masz rację, Mirku, lepiej dać maksymalną możliwą szybkość.

Temat chyba można zamknąć, myślę, że wszystkie moje wątpliwości zostały rozwiane. Będę relacjonował rozwój projektu

Ja tylko dodam, że tu nie chodzi o to że jak dasz wolniejszy kwarc to np zmniejszysz odświeżanie - kompletnie nie w tym rzecz. Właśnie chodzi o to aby przy szybszym karcu o wiele szybciej wyrabiały się przerwania do komunikacji np uart, do osbługi podczerwieni itp - żeby zajmowały możliwie najmniej czasu, najmniej taktów.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

W tą stronę nie pomyślałem. Dam kwarc 16 MHz, powinien wystarczyć.
Jeszcze raz dziękuję za całą pomoc