Przeszukaj forum

Witam, Zaczynam czytać kursy Arduino i mam problem. Z uwagi na brak USB, nie potrafię zainstalować na moim tablecie Lenovo, programu Arduino IDE. Mam tylko WiFi i Bluetooth, gdy próbowałem skorzystać z pomocy wujka G, to tylko wskazywana była możliwość przesyłu danych przez WiFi, a nigdzie nie mogłem jeżeli ktoś zna na to jakiś sposób, to proszę o podpowiedź. Pozdrawiam

Cześć, Jestem nawy na forum i zupełnie zielony jeśli chodzi o programowanie. Jak w temacie potrzebuję wykonac przycisk na USB, który po naciśnięciu "zgłosi się" w ubuntu 22.04 oraz odtworzy mp3 z folderu Music. Znalazłem podobny projekt w linku poniżej: https://www.pjrc.com/teensy/td_digital.html Podłaczyłem jak poniżej: ale nie wiem jak go przeprogramować by po naciśnieciu przycisku urządzenie zgłosiło na ttyUSB i wyrzuciło komunikat "pishbutton" w Ubuntu i zagrało mp3 z folderu Music. Wyczytałem jeszcze że można to zrobić na adapterze USB/UATR, nie ma dla mnie większego znaczenia, który to będzie adapter ważne by zadziałało, jeśli zrobienie tego na UART bezie łatwiejsze to mogę go dokupić. Proszę o pomoc w przeprogramowaniu i napisaniu kodu pod Ubuntu.

Opis skrócony Trochę się nudziłem, a że niestety ceny HUB'ów USB są dość niemiłe (najtańsze kosztują 7-10zł per sztuka i produkują dużo śmieciowego plastiku), to postanowiłem złożyć coś swojego (głównie by przetestować jak magistrala zareaguje na mocny rozjazd impedancji ścieżek)... Założenie było też takie, że tego HUB'a można bez problemu zamontować np. w biurku czy stoliku, a nie tylko w obudowie 🙂 No i powstał taki potworek: Zasada działania Jest ona bardzo prosta - wykorzystałem gotowy chip HS8836A 😉 Koszt to 1.18$/szt dla zamówienia 100 sztuk. Niestety z AliExpress chińczyk przysłał mi HS8836 a nie HS8836A, więc powstał też drugi schemat na starszą wersję 🙂 Schematy (HS8836A) Wyszedł ciut duży, aczkolwiek wykorzystuje tylko dwie warstwy 🙂 [pliki projektu jeszcze nie są nigdzie wrzucone], bo niestety paczka z tą rewizją zatrzymała się w Niemczech... Schematy (HS8836) Ten został "skompresowany". Taka wersja bardziej przyjazna dla użytkownika... BOM (HS8836A) 1x złącze microUSB - w promocji były po 0.025$ 🙂 1x 4.7R, 2x 4.7uF, 1x 100nF, 1x 100kR - tutaj akurat to są dość standardowe wartości, więc liczę sumarycznie ok. 0.05$ 1x HS8836A - 1.18$ 4x złącze USB (żeńskie) - 0.028$/szt RAZEM: 1.29$ Nie uwzględnia dostawy HS8836A od producenta - 9$ za ePacket. BOM (HS8836) 1x złącze microUSB - promocja 0.025$ 2x 4.7uF, 1x 100nF, 1x 10k - 0.05$ 1x HS8836 - 0.32$ (przeliczone z zamówienia, wliczona dostawa) 4x złącze USB (żeńskie) - 0.028$/szt RAZEM: 0.423$ BOM C.D. Do obu cen należy doliczyć oczywiście koszty spoiwa czy płytki drukowanej. Płytka to najzwyklejsza dwuwarstwowa z JLCPCB - koszt ok. 0.5$ / szt Sumarycznie wychodzi więc około 6.88 PLN (HS8836A) lub 3.55 PLN (HS8836) Czego się nauczyłem? Wbrew pozorom USB jest bardzo odporne 🙂 Na dwuwarstwowej płytce z "pseudo-matched" impedance (szerokość ścieżek i dystans zrobione na oko) USB 2.0 działa bez większych problemów z pełnym transferem (testowane na dwóch pendrive). No i USB 2.0 ma sporą tolerancję dla nierównych długości ścieżek 😉 Dodatkowe notatki Załączone zdjęcie płytki pochodzi ze starego schematu, który miał jeszcze zaplanowany regulator 3.3V (na wszelki wypadek), ale obyło się bez niego 😉 (zawsze łatwiej czegoś nie lutować niż lutować na pająka) Z ważnych błędów projektu warto zaznaczyć umieszczenie portów USB na górze, przez co na stykach D+/D- powstaje duży stub, który może powodować spore zakłócenia elektromagnetyczne, ale w tym przypadku nie ma on większego znaczenia. Technicznie ścieżka powinna być umieszczona po tej samej stronie co lut. P.S. Dział Początkujący, bo jednak zaprojektowanie czegoś takiego jest dość banalne 🙂 Rozmiar komponentów 0805, bo jestem zbyt leniwy na mniejsze 🙂 I tak wiem, że moje lutowanie do standardów branżowych ma daleko, ale to prototyp, a nie produkt 🙂 (ważne, że nie ma zwarć, a że płytka klei się od topnika i jest za dużo cyny... kto by się przejmował, działa? działa, to po co drążyć temat...)

Witam, Posiadam dwa mikrokontrolery z rodziny STM32. Pierwszy na płytce Nucleo-64 STM32F103RB, drugi na płytce Waveshare CoreH7XXI STM32H743IIT6. Postawiłem sobie za cel zbudować przetwornik cyfrowo analogowy R2R w oparciu o mikrokontroler. Wiem, że można wykorzystać do tego FPGA, ale ja postanowiłem całość oprzeć o mikrokontroler - cele naukowe i rozwojowe. IDE z którego korzystam, to STM32CubeIde. Z racji tego, że nie mam na co dzień do czynienia z mikrokontrolerami, a traktuję to jako hobby, to z góry przepraszam, jeśli popełniam jakieś rażące błędy, lub posiadam braki w wiedzy, ale dopiero się uczę. Skonfigurowałem USB na płytce Nucleo, jako USB Device, przyłączyłem middleware USB_DEVICE, klasa Audio Device Class, ustawiłem parametr częstotliwości na 48000 sampli/s, RCC HSE ustawiony na Crystal/Ceramic Resonator. Zegary skonfigurowane na korzystanie z kwarcu i PLL, USB taktowane 48MHz. Wlutowałem kwarc 8MHz i dwa kondensatory 30pF (takie akurat miałem pod ręką), wlutowałem rezystor 1k5 (1448Ω) pomiędzy 3.3V a pin USB D+ skompilowałem projekt, wgrałem na płytkę. Zrobiłem sobie około 40cm przewód z taśmy 4 żyłowej z jednej strony zakończony wtykiem USB, z drugiej wtykami goldpin. Podłączyłem D+, D- i GND, zasilanie pobieram z USB od programatora (przy czym przestawiałem też zworkę na E5V i całość zachowuje się tak samo). Podłączam mikrokontroler pod USB - urządzenie znalezione, poprawnie zainstalowane, widnieje jako STM32 Audio Class https://imgur.com/nBjyhkV. Inicjalizacja urządzenia się powiodła, wszystko wygląda dobrze - https://imgur.com/1LDmdm7. Na oscyloskopie kwarc pokazuje stabilne 8.00MHz. I teraz się zaczynają schody. Uruchamiam audacity, częstotliwość projektu ustawiam na 48KHz (choć to bez znaczenia, na każdej jest ten sam problem), generuję falę prostokątną 1KHz, wybieram moje urządzenie i klikam play. Oto, co się dzieje w snifferze - https://imgur.com/JjXmSkf. Proszę zwrócić uwagę na czasy - pierwsze dwa pakiety URB_FUNCTION_SELECT_INTERFACE wykonują się bardzo szybko. PC wysyła do uC żądanie i otrzymuje odpowiedź w ciągu 2ms - to jest moment kliknięcia play. Następnie mamy pakiety transferu danych, których jest mało, ze względu na to, że bardzo szybko kliknąłem stop. I tutaj zaczyna się sedno problemu. Kliknięcie stop ponownie powoduje żądanie URB_FUNCTION_SELECT_INTERFACE, które od PC do uC idzie od razu, ale w drugą stronę całość się zamraża na równo 5 sekund (+czasami kilka-kilkanaście ms, co widać w różnicach czasowych). Kliknięcie play i ponownie 5 sekund zwłoki i później lecą dane. Stop - znów 5 sekund i tak w kółko. Odpięcie USB i ponowne jego podpięcie daje jednorazowy szybki play, a potem sytuacja się powtarza. Wygląda to tak, jakby mikrokontroler przez 5 sekund próbował coś robić (tylko co?) a potem przechodził do właściwej pracy. Dodatkowo nie jestem w stanie poprawnie debugować pracy USB na tym mikrokontrolerze. Debuger poprawnie zatrzymuje się na pierwszej linii kodu, następnie klikam resume, urządzenie się pojawia. Gdy natomiast klikam play w audacity, dostaję komunikat "Błąd otwierania urządzenia dźwiękowego". Pakiet URB_FUNCTION_SELECT_INTERFACE (odpowiedź od uC) zwraca status 0xc0000011 https://imgur.com/EzQhRPh. I teraz, żeby było ciekawiej, powtarzam dokładnie tą samą procedurę na płytce z STM32H743IIT6 i wszystko działa tak, jak powinno, play i stop działa zawsze i od razu. Dlaczego zatem nie użyję H7 do USB? Ponieważ chcę zrzucić operacje pobierania danych z komputera i wstępną obróbkę na jeden cpu, a odtwarzanie, precyzyjny timer 48KHz i kierowanie danych na GPIO na drugi procesor (tutaj też są cele naukowe i rozwojowe - chcę spróbować różnych podejść i zrobić to na dwóch procesorach, mogąc jednocześnie obserwować komunikację między nimi). Czy ktoś się spotkał z takim problemem? Być może jest to kwestia tego, że CubeMX coś źle generuje, ale niestety nie jestem jeszcze aż tak biegły, żeby ogarnąć całą bibliotekę USB i potrzebuję wsparcia od osób bardziej doświadczonych :) Pozdrawiam, Mateusz

Witam, z jakiego DIODA mogę skorzystać aby zabezpieczać układ z "Reverse Polarity" ? Chodzi o zabezpieczenie portu USB. Czy ten model jest kompatybilny ? https://lcsc.com/product-detail/Schottky-Barrier-Diodes-SBD_PANJIT-International-SS1040L_R1_00001_C305161.html

Potrzebuję sygnału zegarowego z tego układu https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF do taktowania mikrokontrolera. Czy mogę go pobrać z pinów XI XO, jeśli tak to z którego? XO? Druga część pytania - o przejściówkę BT - jak narysuję schemat 🙂 Update: na wyjściu XO jest sygnał sinus 12MHz o wartości 2.56Vpp chcę go doprowadzić do CLKI w AtTiny13

Niedawno przyszło do mnie arduino uno. Chciałem go podłączyć przez USB i był wykrywany tylko jako nie znane urządzenie i nie było widziane jako port com. Próbującppodłączyć pod inne usb oraz po zainstalowaniu sterowników w końcu pokazał się port com z arduino. pomimo że na usb nadal widział go jako nie znane urządzenie. Wykorzystując ten port udało mi się wgrać program. co 20 sekund na 1 sekundę zapala się dioda na 13 pinie. I program działa. Potem odłączyłem arduino i mając wcześniej przygotowany już uklad z dioda i opornikiem. Podłączyłem go do 5v i masy. dioda ładnie świeci. Jeszcze potem wgrałem program z szablonem i klasą i obliczaniem sum różnic i z widocznym wynikiem na monitorze portu. i go wgrałem wszystko działało. Potem znów odłączyłem arduino przygotowując pod 11 pin. Jednak po ponownym podłączenie arduino przestało być widoczne jako urządzenie. I komputer przestał na nie reagować inny również. A program z mruganiem co 20 sekund nadal działa i dioda do 5v też świeci. 🙂 co mogłem rozwalić? a na kolejnym komputerze zobaczyło mi bez problemów i wszystko się ładnie ładuje.... 🙂

Słowem wstępu Jak większość elektroników wie magistrala USB nie należy do tych przyjemnych w implementacji. Często coś nie działa, lub urządzenie nie jest enumerowane. Co można zrobić w takim przypadku? Diagnozowanie przy użyciu software'u Teoretycznie możemy korzystać z oprogramowania takiego jak Free USB Protocol Analyzer, aczkolwiek często nie wykrywa ono urządzeń - dla przykładu jednego z moich projektów CDC nie jest w stanie wykryć niezależnie od portu, do którego zostanie wpięty. Stąd trzeba było poszukać innych rozwiązań... Hardware USB Sniffer Jak nie możemy zdiagnozować USB za pomocą software, to może podsłuchamy transmisję między hostem a device'm? Dobrze, ale ile kosztuje taki sprzęt, bo już prawdopodobnie ktoś go stworzył? 4000-9000 PLN 😮 Teledyne LeCroy No cóż... może istnieją tańsze rozwiązania? BugBlat miniSniffer / ezSniffer Chwila szukania tańszych alternatyw i trafiamy na stronę, gdzie widzimy 59.99$ plus wysyłka... No to już bardziej racjonalna cena. Alternatywnie można też kupić we francuskim lab401 jeżeli nie chcemy długo czekać. No cóż... w przeliczeniu z wysyłką z Francji cena to jakieś 370 złotych... to już sensowna wartość za tak użyteczny sprzęt - zamawiamy. Po oczekiwaniu na paczkę Wreszcie dotarła paczka - w niej wyłącznie płytka miniSniffer (bez okablowania). W przypadku wysyłki ChronoPostem w Polsce paczkę dostarcza DPD. Obudowa była wykonana chwilę później. Jak widzimy na obrazku urządzenie posiada dwa porty z jednej strony i jeden z drugiej. Są one używane następująco: USB-C - połączenie urządzenia z komputerem służącym do analizy (z oprogramowaniem miniSniffer) USB-A - podłączenie urządzenia - device USB-micro-B - podłączenie do komputera-hosta Patrząc na płytkę jest ona wykonana bardzo dobrze, a sercem jest układ FPGA - LCMX02. Podłączenie Samo podłączenie urządzenia do komputera jest bardzo proste, wystarczy wpiąć wszystkie przewody na swoje miejsce i uruchomić oprogramowanie. Należy pamiętać, by kliknąć przycisk Capture i podłączyć device do hosta (przycisk Connect). Pozwala nam to też na diagnozowanie pakietów kontrolnych (zawsze możemy odłączyć programowo urządzenie, po czym rozpocząć sniffing i podłączyć urządzenie). I tutaj pokazuje się główna różnica między miniSniffer, a ezSniffer - pojemność pamięci. miniSniffer posiada pojemność 128kB, która jest dość mała, ezSniffer 256MB. Należy mieć to szczególnie na uwadze w przypadku diagnozowania urządzeń, które przesyłają ogromną ilość pakietów danych. Ekran software'u Sam software jest dość prosty i wizualnie podobny do tego od Teledyne LeCroy. Posiada podgląd transakcji i pakietów, stąd łatwo możemy sprawdzić jak wygląda komunikacja w poszczególnych transakcjach. Widzimy wszystkie niezbędne dane - typ pakietu, endpoint, adres, dane czy CRC. Do tego również mamy określoną ilość czasu jaka minęła od początku diagnostyki. Warto wiedzieć, że nie możemy ustawić sobie offsetu na czas, więc jest to dość problematyczne, gdyż trzeba sobie ręcznie przeliczać, ale wystarczy prosty kalkulator i da się to zrobić. Dosyć przydatną funkcją jest ukrywanie pakietów NAK oraz SOF, więc zostają wyłącznie te, które mają znaczenie w komunikacji (te pierwsze zawsze można aktywować gdy np. diagnozujemy czy to komunikacja USB powoduje spadek wydajności czy inne algorytmy wewnątrz urządzenia). Pakiety kontrolne Raspberry Pi Pico (biblioteka przykładów, device low-level) Podsumowanie Jeżeli ktoś projektuje proste urządzenia USB (FS, HS), to miniSniffer jest przydatnym narzędziem do testowania. Jeżeli przesyłamy duże ilości danych lepiej skusić się na zakup ezSniffer, gdyż posiada znacznie większy bufor pamięci. W cenie 370 PLN z dostawą (lab401) jest to bardzo opłacalny zakup biorąc pod uwagę, że markowe rozwiązania kosztują 10 razy drożej, a ich dodatkowe funkcje są zwykle zbędne. Dodatkowym atutem urządzenia jest API, które można pobrać i napisać własne oprogramowanie 🙂 Problemy Podczas testowania urządzenia zauważyłem następujące "problemy": Urządzenie nie podłącza automatycznie device do hosta - trzeba klikąć przycisk w oprogramowaniu Oprogramowanie na linuxie wymaga nieoficjalnych wxWidgets - nie mogłem ich znaleźć w repozytoriach AUR / ArchLinux'a, znalazłem je wyłącznie w repozytoriach Debiana. Program instalujący na linuxie jest dostosowany pod Debiana / Ubuntu, na innych dystrybucjach trzeba go instalować ręcznie. Porty z początku ciężko chodzą, ale potem się dostosowują 🙂 Czy warto zakupić urządzenie? Jeżeli planujesz eksperymentować z USB - jak najbardziej, no chyba, że masz dostęp do Teledyne LeCroy Mercury lub innego markowego rozwiązania np. na uczelni czy w pracy... Wtedy raczej bym skorzystał z tej drugiej opcji.

Witam wszystkich. Idą święta, więc wpadłem na pomysł przyozdobienia roweru programowalnymi lampkami migającymi w rytm kolęd. Założenia projektu: Tanio - z racji na ograniczony budżet na zabawę Praktycznie - im mniej dodatkowego sprzętu, tym lepiej Szybko - żeby realizacja projektu trwała max 2 tygodnie Co będzie potrzebne: Jednostka sterująca - na początku myślałem o Raspberry PI 2B (posiadam to urządzenie) i sterowaniu lampkami za pomocą gpio, jednak sama malinka zużywa dość dużo prądu (1.1 - 2.3 W) i nie wiem, jak znosi niskie temperatury. Drugi pomysł to telefon z Androidem i sterowanie za pomocą USB, ale tu raczej nie obejdzie się bez dodatkowego kontrolera, gdyż sam USB posiada piny +5V, D+, D- oraz GND, więc sterowanie odbywałoby się przy pomocy pakietów danych. Trzeci pomysł to Arduino lub jeszcze mniejszy mikrokontroler. Lampki - chcąc podejść do tego budżetowo, można puścić 3 zestawy lampek i sterować nimi on/off (8 kombinacji), trochę słabe. Chcę sterować każdą lampką osobno. Tu są 2 podejścia: albo każda lampka posiada wszystkie składowe RGB, albo każda jest konkretnego koloru. Zależy, jak to cenowo wyjdzie. Panel użytkownika (opcjonalnie) - jeśli użyję malinki, to można dokupić jakieś przyciski do przełączania trybów, zmiany programu, ewentualnie skomunikować ze smartfonem. Jeśli użyję telefonu z Androidem, no to aplikacja w Javie albo wynalazkach typu React Native. Problemy do rozwiązania: Czy taśmy RGB to dobry pomysł, czy raczej wyprowadzić każdą lampkę osobnym przewodem? Taśma RGB może popsuć efekt. Luźne lampki wyglądają bardziej choinkowo. Zauważcie, że w co najmniej 2 miejscach potrzebuję rozdzielić lampki (np. na sztycę i na tylne widełki). W przypadku lampek z osobnym przewodem nie stanowi to większego problemu, a co w przypadku taśm RGB lub łączonych lampek? Ile będzie takich punktów, to kwestia optymalizacji. Jak do tego podejść? Jednym ze sposobów jest kupienie kilku taśm RGB. A czy jest to możliwe, aby je po prostu podzielić bez prowadzenia dodatkowego przewodu? Jeśli zdecyduję się na smartfona + microUSB, to czego użyć jako kontroler? Są gotowe rozwiązania do sterowania diodami? Na myśl mi jeszcze przychodzą przerzutniki - gdyby sekwencja zapalania światełek była znana - a to będzie zależeć od pliku w formacie MIDI. Ewentualnie zastosowanie jakiejś formy pamięci przy każdej lampce. Tańsze (acz mniej estetyczne) już chyba będzie wyprowadzenie osobnego przewodu do każdej lampki. Zasilanie - czy +5V z microUSB 2.0 uciągnie całość? jak nie, to power bank z wyjściami 1A lub 2A. Czy Android umożliwia na dowolne sterowanie D+ i D- w USB, czy trzeba napisać sterownik? Propozycje rozwiązania: Raspberry PI 2B jako kontroler, program w JavaScript + moduł do obsługi gpio i plików midi (wszystko już jest), podpięcie taśmy LED do gpio lub osobnych diod do osobnych wejść GPIO Arduino lub inny mikrokontroler + program w... pewnie w C Telefon z Androidem jako kontroler + aplikacja + jakiś minikontroler + taśma/lampki/??? Trzecia opcja mi się najbardziej podoba. Na początek trzeba rozwiązać problem z lampkami, czego użyć, jak to połączyć i do tego dobrać odpowiednie rozwiązanie sprzętowe. Może coś mi podpowiecie. Projekt czysto hobbystyczny, żeby się czegoś nauczyć.

Hej, Zacznę od swojego backgroundu w temacie - skończyłem infę dobre kilka lat temu, ale tak naprawdę zgłębiam ten fascynujący świat elektroniki od stosunkowo niedawna. Jestem w trakcie wykonywania projektu - zdalnie sterowanej rolety wewnętrznej w kuchni. Celem nadrzędnym jest wykorzystanie jak najbardziej podstawowych elementów, by żona nie krzyczała, że zagracam jej kuchnię 😉 schemat poglądowy wygląda tak: Oraz filmik jak to wygląda na żywo: Filmik jest nagrany dla poprzedniej wersji, w aktualnej zastąpiłem szybkozłączki lutami oraz dołożyłem 2 kondensatory do układu, jak na schemacie. W kwestii zasilania rozciąłem walający się w domu kabel USB i połączyłem czerwony i czarny kabel, pozostałe tj. białe i zielone uciąłem (nie zabezpieczając ich w żaden sposób). Jako zasilacz użyłem zwykłą ładowarkę do telefonu bodajże Samsunga dającą 2A. Wszystko działało dobrze, zarówno w wersji z filmiku jak i z lutami i kondensatorami. Schody zaczęły się, gdy podłączam przedłużacz usb 5 metrowy (potrzebuję przeciągnąć do bo wtyczkę mam trochę dalej od okna). Właściwie, to próbowałem z dwoma przedłużaczami, również z "aktywnym" (https://allegro.pl/oferta/kabel-usb-5m-przedluzacz-aktywny-9272337651) . Próbowałem również 2 różne łatowarki, bez zmian. Rezultat jest identyczny - wygląda na to, że kontroler nodeMCU się resetuje (nie łączy się do sieci WiFi). Czy dodatkowa ilość kabla powoduje jakieś zakłócenia/spadki napięcia układu? Czy powinienem dorzucić jakiś jeszcze stabilizator do tego układu? Myślałem, że kondensator załatwi tę sprawę, ale nie daje on praktycznie różnicy. Pewnie popełniłem dużo błędów przy tym projekcie, więc jeśli macie jakieś sugestie to chętnie posłucham 🙂

Hej, męczę się z projektem, w którym potrzebuję podłączyć złącze Jack 3,5mm. I tutaj zaczynają się schodki. Złącze to ma kilka nóżek i kompletnie nie wiem jak to podłączyć. Datasheety też niewiele mi mówią, ponieważ nie umiem się w nich połapać. Pracuję w programie Altium Designer i jak na razie wygląda to tak: To złącze jest na wejściu i zbiera dźwięk (więc służy jako mikrofon). Sygnał później leci do wzmacniacza. Kolejne złącze służy do wyjścia (podepnę do tego jakieś głośniki). I jest tam sygnał, który wychodzi ze wzmacniacza i wygląda to tak . Kolejnym problemem, z który stanął na mojej drodze to podłączenie złącza USB. To złącze ma za zadanie niesymetrycznie zasilić wzmacniacz. Wygląda to tak: . Nie ma zielonego pojęcia czy jest to dobrze podłączone, jednak jest to jedyne co udało mi się ustalić od jakiś2 tygodni 😕 . Liczę na waszą pomoc, za którą z góry dziękuję!

W przypływie wolnego czasu chciałem przećwiczyć sobie obsługę USB w STM32 i przy okazji zrobić coś praktycznego do podłączenia do komputera. Ponieważ mam klawiaturę mechaniczną z przyciskami multimedialnymi ukrytymi pod mało praktyczną kombinacją z klawiszem FN (klawisz po prawej stronie - totalnie niepraktyczne w tym zastosowaniu) postanowiłem zrobić sobie dedykowany pilot do multimediów. Platforma STM32F103 bo mam mały zapas płytek BluePill. Jako sterowanie wybrałem joystick z enkoderem na wzór tych z systemów infotainment w samochodzie. Żeby doprecyzować joysticki ALPS RKJXT1F42001 zamówione jakiś czas temu na aliexpress i czekające na projekt jak ten. Kod na STM32 powstawał na bazie generowanego przez CubeIDE przy middleware USB_DEVICE z wybranym Human Interface Device Class (HID). W moim odczuciu generowany kod jest chyba bardziej demonstracją, ponieważ kod z definicjami deskryptorów jest stworzony dla myszy, i nie ma nigdzie znaczników USER_CODE_BEGIN/END. Próbowałem coś zadziałać z klasą Custom Human Interface Device ale mogłem znaleźć deskryptorów urządzenia, konfiguracji i interfejsu w kodzie, a deskryptor raportu HID był do napisania od zera, co jest raczej trudne przy pierwszym projekcie z USB. Zostałem przy przykładzie z myszką od ST, który sukcesywnie modyfikowałem, tworząc kopie zapasowe na wypadek potrzeby generowania kodu z Cube (przez brak znaczników USER_CODE wszystkie zmiany - głównie zmodyfikowany deskryptor raportu - byłyby nadpisane przez wygenerowany kod). Nie będę opisać tworzenia mojego deskryptora bo robiłem to raczej na czuja metodą prób i błędów. W skrócie chodzi o to, że deskryptor raportu HID informuje host(komputer) o możliwościach urządzenia oraz przypisuje funkcjonalności bajtom w raporcie HID - w moim przypadku każdy bit w drugim bajcie raportu niesie informacje o wciśnięciu przycisku z grupy consumer page (0x0C) (więcej o nich w dokumentacji USB HID - HID Usage Tables 1.12). Utworzenie deskryptora od zera jest raczej trudne dla początkującego ale w internecie jest sporo informacji - wielką pomocą był dla mnie raport z przykładowej implementacji (http://www2.ece.rochester.edu/~parihar/pres/Report_MultiMedia-KB.pdf) w którym o wiele lepiej wytłumaczono działanie USB, klas i deskryptorów, niż ja to jestem w stanie zrobić. Oprócz tego mój deskryptor raportu jest lekko zmodyfikowaną wersją tego spod linku. Deskryptory urządzenia, konfiguracji i interfejsu wykorzystałem w wersji wygenerowanej przez cube dla myszy - zmieniłem jedynie typ urządzenia na klawiaturę (0x01) w deskryptorze konfiguracji (Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c). Deskryptor raportu powstał na podstawie tego podlinkowanego. Mapowanie przycisków do bitów w raporcie jest tam zobrazowane na stronie 11. Dobry tutorial o deskryptorach raportów HID tutaj. Gotowy deskryptor raportu przedstawia się tak: 0x05, 0x0c, // USAGE_PAGE (Consumer Devices) 0x09, 0x01, // USAGE (Consumer Control) 0xa1, 0x01, // COLLECTION (Application) 0x85, 0x01, // REPORT_ID (1) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x10, // REPORT_COUNT (16) 0x09, 0xe2, // USAGE (Mute) 0x01 0x09, 0xe9, // USAGE (Volume Up) 0x02 0x09, 0xea, // USAGE (Volume Down) 0x03 0x09, 0xcd, // USAGE (Play/Pause) 0x04 0x09, 0xb7, // USAGE (Stop) 0x05 0x09, 0xb6, // USAGE (Scan Previous Track) 0x06 0x09, 0xb5, // USAGE (Scan Next Track) 0x07 0x0a, 0x8a, 0x01, // USAGE (Mail) 0x08 0x0a, 0x92, 0x01, // USAGE (Calculator) 0x09 0x0a, 0x21, 0x02, // USAGE (www search) 0x0a 0x0a, 0x23, 0x02, // USAGE (www home) 0x0b 0x0a, 0x2a, 0x02, // USAGE (www favorites) 0x0c 0x0a, 0x27, 0x02, // USAGE (www refresh) 0x0d 0x0a, 0x26, 0x02, // USAGE (www stop) 0x0e 0x0a, 0x25, 0x02, // USAGE (www forward) 0x0f 0x0a, 0x24, 0x02, // USAGE (www back) 0x10 0x81, 0x62, // INPUT (Data,Var,Abs,NPrf,Null) 0xc0 I definicje bitów dla przycisków oraz zmiennej przechowującej raport HID do wysłania #define HID_REPORT_SIZE 3 #define MEDIA_MUTE 0 #define MEDIA_VOLUP 1 #define MEDIA_VOLDOWN 2 #define MEDIA_PLAY_PAUSE 3 #define MEDIA_STOP 4 #define MEDIA_PREV 5 #define MEDIA_NEXT 6 /* USER CODE END PD */ /* Private variables ---------------------------------------------------------*/ TIM_HandleTypeDef htim1; /* USER CODE BEGIN PV */ extern USBD_HandleTypeDef hUsbDeviceFS; uint8_t HID_report[HID_REPORT_SIZE] = {0x01,0,0}; //empty hid report W celu zakomunikowania hostowi wciśnięcia przycisku wysyłamy raport HID z ustawionym bitem odpowiadającym wciśniętemu przyciskowi. Przykładowo dla przycisku VOL_UP ustawić należy drugi bit w drugim bajcie raportu. Ponieważ należy zasymulować wciśniecie i zwolnienie przycisku należy wysłać po chwili drugi raport z samymi zerami. Ważne jest też zachowanie co najmniej 10 ms odstępu między wysyłaniem raportów, by dać czas na przetworzenie informacji bibliotece USB na STMie oraz hostowi (komputerowi). Poniżej kod w funkcji main() obsługujący wysyłanie raportów o wciśnięciu przycisków HID_report[1]=0; //0 means none of the buttons pressed ////THIS CODE CAN SUPPORT ONLY 1 KEY AT A TIME, AND VERY SLOW REPEAT WITH LONG PRESS//// CheckButtonsState(); //check if any button is pressed and set appropriate bits in HID_report[1] if(HID_report[1]!=0){ USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); //send key-press and after 15 ms key-release reports HAL_Delay(400); HID_report[1]=0; USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); } Funkcja CheckButtonsState() ustawia na podstawie stanów logicznych na wejściach uC, bity w 2 bajcie tablicy uint8_t przechowującej raport HID. void CheckButtonsState(){ if(!HAL_GPIO_ReadPin(PUSH_GPIO_Port, PUSH_Pin)) { //push input is low when whichever button is pressed uint8_t isPushPressed=1; if(!HAL_GPIO_ReadPin(RIGHT_GPIO_Port, RIGHT_Pin)) {SetKeyPress(MEDIA_NEXT); isPushPressed=0; } if(!HAL_GPIO_ReadPin(LEFT_GPIO_Port, LEFT_Pin)) {SetKeyPress(MEDIA_PREV); isPushPressed=0; } if(!HAL_GPIO_ReadPin(UP_GPIO_Port, UP_Pin)) {SetKeyPress(MEDIA_MUTE); isPushPressed=0; } if(!HAL_GPIO_ReadPin(DOWN_GPIO_Port, DOWN_Pin)) {SetKeyPress(MEDIA_STOP); isPushPressed=0; } if(isPushPressed==1){SetKeyPress(MEDIA_PLAY_PAUSE);} } } void SetKeyPress(uint8_t key){ HID_report[1] |= 1<<key; } Zastosowany joystick ALPS jest tak skonstruowany, że wciśnięcie jakiegokolwiek przycisku zwiera także wyprowadzenie PUSH odpowiadające wciśnięciu joysticka. Z tego powodu funkcja jest napisana tak, że jeżeli na wejściu PUSH jest 1 to na każdym innym musi być 1 (styki otwarte). Jeżeli wciśnięty jest PUSH (logiczne 0) ale też 0 jest na pinie od innego przycisku, oznacza to że wciśnięto inny przycisk, a stan na wejściu PUSH jest ignorowany. Jeżeli 0 jest tylko na wejściu PUSH, oznacza to że joystick rzeczywiście został wciśnięty. Takie rozwiązanie prosi się aż o generowanie przerwania z wejścia PUSH i wykonywania kodu wtedy. Ponieważ jestem leniwy i miałem już gotowy kod do wysyłania raportów HID kiedy to odkryłem, zostałem przy pollingu stanu na wejściach. Delay po wysłaniu raportu rozwiązuje mi także problem z debouncingiem przycisków (obserwowałem wejścia na oscyloskopie i stwierdzam że styki w tym joysticku drżą jak złe 😁). Regulację głośności obsługuję przez timer 1 w trybie enkodera (przydał się kurs zaawansowanych timerów na STM32 z waszego bloga 😁). Przy zmianie wartości licznika timera wartość jest porównywana z zapisaną w poprzednim przejściu głównej pętli while(1). Jeżeli się zmieniła na mniejszą lub większą wysyłany jest raport HID z ustawionym bitem odpowiadającym klawiszowi VOLUP/VOLDOWN a zmienna lastEncoderCount jest in/dekrementowana. Dopóki obie wartości nie są równe raporty są wysyłane co przejście głównej pętli while. Wartość licznika jest dzielona przez 2 gdyż przy poprawnej pracy enkodera o tyle zmienia się po przeskoczeniu "o jeden ząbek". Czasem miałem sytuację że wartość licznika była nieparzysta (może błąd połączeń/drżenie styków) i algorytm w kółko podnosił/obniżał głośność o 1 bo wartości encoderCount i lastEncoderCount nigdy nie były równe. Dzielenie przez 2 gwarantuje parzystość wartości zmiennej ///TE ZMIENNE SA GLOBALNE/// uint16_t encoderCount=32766; //half of timers resolution (16bit) uint16_t lastEncoderCount=16383; //////////////////////////// //TEN KOD WYKONUJE SIE W PETLI WHILE FUNKCJI MAIN()// encoderCount=__HAL_TIM_GET_COUNTER(&htim1)/2; //get encoder absolute position if(encoderCount!=lastEncoderCount){ if(encoderCount<lastEncoderCount){SetKeyPress(MEDIA_VOLDOWN);lastEncoderCount-=1;} //set key press depending on encoder movement direction else{SetKeyPress(MEDIA_VOLUP);lastEncoderCount+=1;} USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); HID_report[1]=0; USBD_HID_SendReport(&hUsbDeviceFS, HID_report, HID_REPORT_SIZE); HAL_Delay(15); } Kompletne oprogramowanie STMa dostępne na github.com/wiciu15/STM32-USBHID-MultimediaPilot. Po zweryfikowaniu działania prototypu zaprojektowałem i wytrawiłem prostą płytkę w KiCADzie żeby się pozbyć luźnych kabelków. Urządzenie zasilane jest z USB na BluePillu, programuje je z wyprowadzeń SWD po drugiej stronie płytki za pomocą ST-Linka V2. Żeby urządzenie jakoś wyglądało zaprojektowałem i wydrukowałem obudowę oraz gałkę do joysticka. Od razu ostrzegam że na drukarce FDM ciężko jest osiągnąć taką precyzję żeby gniazdo w gałce ciasno siedziało na wałku joysticka - ja zaprojektowałem 0,1mm ciaśniej i przy montażu rozgrzałem plastik tak by się uplastycznił i dopasował do kształtu na końcu drążka joysticka. Nie jest to ciasne pasowanie ale wystarcza żeby sterować bez urywania gałki co drugie dotknięcie 😁. I wydrukowane: Wszystkie pliki z kodem, płytka i obudowa dostępne na github.com/wiciu15/STM32-USBHID-MultimediaPilot. Z racji że chciałbym dalej to rozwijać to zakupiłem moduł NRF51822 i będę próbował zrobić coś podobnego, ale na Bluetooth HID, i z zastosowaniem w aucie do sterowania tanim tabletem z emulatorem headunitu AndroidAuto (używam apki HeadUnit Reloaded która wspiera obsługę z klawiatury do sterowania API Androida Auto np. sterowanie jasny/ciemny tryb, multimedia, poruszanie się po interfejsie za pomocą enkodera - AA jest tak zaprojektowany bo piloty do systemów infotainment z reguły mają też enkodery). Jedyna moja obawa jest taka że pilocik będzie musiał działać cały czas ze stałej instalacji 12V, bo tablet z niewiadomych powodów po rozłączeniu z sparowanym urządzeniem BT wymaga ręcznego ponownego połączenia, więc po wyłączeniu i włączeniu pilocika czeka mnie wycieczka do ustawień tabletu by go z powrotem połączyć. Nie mam doświadczenia z programowaniem nRF więc zobaczymy jak mi pójdzie na raz z BT HID, przerwaniami, enkoderem i jeszcze minimalizacją poboru energii😁 Łatwiej by było dorobić drugie USB w tablecie i podłączyć taki pilot jak opisałem powyżej. Tu jest problem tej natury, że tablet który mam już zmodyfikowany i założony na bardzo mocną taśmę dwustronną (😁) nie chce działać na OTG z więcej niż jednym urządzeniem. Podłączałem do niego kilka HUBów USB, kupiłem nawet specjalną przejściówkę do OTG z paroma portami USB ale nic nie chce ruszyć. Póki co moduł z NRF81 dopiero przyszedł, będę teraz się oswajał z SDK do niego, może jakiś hello world 😛. Nie jestem jeszcze pewny czy będę w stanie go programować i debugować bo mam tylko ST-Linka na stanie w tej chwili 😞 Podobno korzystając z OpenOCD można ST-Linka z tym połączyć ale to musiałbym przy wolnej chwili zrobić próby. Jak nie ruszy to będę szukać jakiegoś JTAGa ale ceny mnie trochę odstraszają. Wszelkie sugestie, pochwały, krytyka i komentarze mile widziane 🙂

Witam serdecznie, robię coś "ala inteligentny dom" i brakowało mi gpio na malince. Podłączyłem mcp23017 i działa:) Działa jako wyjście:/ Jak zrobić żeby działało jako wyjście? A takie ważniejsze i chyba trudniejsze pytanie (jak dla mnie) to: Jak połączyć malinkę z arduino przez usb?? tak żeby arduino działało jako we/wy?? Nie liczę na gotowca, ale jakieś wskazówki. Nie jestem też jakimś tam hiper, biper, diker informatykiem. Skoro potrafiłem podłączyć mcp23017 i "ledami mrugać" to myślę że arduino podłączę jako we/wy do malinki;) Pozdrawiam serdecznie;) p.s. Zapomniałem dodać, że to wszystko obsługuję na domoticz.

Stawiam Pi-Hole na Raspberry Pi Zero W i postanowiłem w ramach ćwiczeń własnoręcznie stworzyć adapter USB w oparciu o dostępne na rynku rozwiązania. Znajdzie się ktoś, kto rzuci okiem, czy płytka jest zaprojektowana zgodnie ze sztuką? Poniżej załączam materiały, na których się opierałem podczas projektowania.

LiPol Charger v1.0 / v2.0 Szanowni czytelnicy forum 🙂 w tym krótkim artykule przedstawię Wam projekt ładowarki do akumulatorów litowo-polimerowych 2 celowych (7,4V). Prace nad projektem rozpoczęły się bardzo dawno temu, co można było śledzić w tym wątku. Dużą rolę w trakcie projektowania samego układu odegrał kolega @marek1707. Tak naprawdę ostateczna forma pierwszej wersji ładowarki została bardzo mocno zasugerowana przez niego 🙂 dzięki temu działa ona niezawodnie. Układy zostały zaprojektowane wedle następujących założeń: możliwość ładowania akumulatorów 2 celowych przy pomocy źródła zasilania o napięciu 5V i natężeniu prądu nie większym niż 1A (na tyle pozwalały zastosowane elementy elektroniczne) oraz ładowanie z wykorzystaniem 2 paneli słonecznych 6V/300mA, które aktualnie miałem pod ręką - stąd zastosowano układ przetwornicy typu boost, zastosowanie przewodowej lub bezprzewodowej komunikacji z komputerem PC, wykorzystanie diod LED do sygnalizacji stanów pracy ładowarki, (v2.0) wyświetlanie informacji na wyświetlaczu alfanumerycznym 2x16, (v2.0) dodanie przycisków do ręcznej interakcji użytkownika z urządzeniem, (v2.0) wbudowanie prototypu prostego balansera ogniw, (v2.0) wyprowadzenie padów do programowej kalibracji przetwornika ADC. LiPol charger v1.0 Wersja pierwsza ładowarki jest wersją niekombinowaną oraz dość niezawodną. Pełny cykl ładowania akumulatora obejmuje zarówno fazę CC (stałoprądową) oraz CV (stałonapięciową). Cykl ten świetnie obrazuje WYKRES, który podrzucił mi kolega @marek1707 i który zapamiętam do końca swojego życia 🙂 Zasadę działania przetwornicy boost wydaje mi się, że każdy elektronik powinien znać. Jeśli jednak czytelniku nie miałeś okazji zapoznać się z tym rodzajem przetwornic podsyłam ciekawe artykuły na ten temat: LINK, LINK. W skrócie - na wejściu przetwornica otrzymuje napięcie maksymalne 6V oraz prąd maksymalny 1A. Sygnał PWM generowany przez mikrokontroler ze stałą częstotliwością, a zmiennym wypełnieniem otwiera lub zamyka tranzystor kluczujący przetwornicę, który dzięki temu reguluje napięcie lub prąd wyjściowy przetwornicy w zależności od fazy algorytmu ładowania CC/CV. Zastosowano w tym celu najzwyklejszy regulator proporcjonalny. Mikrokontroler ma możliwość pomiaru potrzebnych parametrów tj. napięcia i prądy wejściowe/wyjściowe oraz napięcie międzyogniwowe. Napięcia są mierzone poprzez dzielniki napięciowe natomiast pomiar prądów odbywa się z wykorzystaniem układów bocznikowych. Komunikacja z komputerem odbywa się poprzez moduł Bluetooth (BTM222 lub HC-05) lub z wykorzystaniem przejściówki USB-UART. Dodatkowo domowymi metodami wykonałem shield umożliwiający podłączenie wyświetlacza alfanumerycznego 2x16. Ostatecznie wykorzystując źródło napięcia stałego 5V/1A udało się uzyskać przetwornicę o sprawności ok. 65%. Całkiem niezły wynik jak na prototyp. Straty mocy są związane ze stratami na diodzie, indukcyjności oraz NIE zastosowaniu kondensatorów typu Low ESR. Wszystkie te parametry można jeszcze trochę poprawić przez co możliwe jest zwiększenie sprawności samej przetwornicy. Wykorzystanie do ładowania paneli słonecznych zmusiło do zastosowania najprostszego algorytmu MPPT - śledzenia punktu maksymalnej mocy. Panele słoneczne połączone są równolegle przez co uzyskano większy prąd wejściowy na przetwornicę. W tym połączeniu maksymalny prąd wejściowy wynosi 600 mA dla posiadanych przeze mnie paneli 6V/300mA. Biorąc pod uwagę to, że w polskich warunkach z tych paneli jestem w stanie wyciągnąć maksymalnie 70-80% całkowitej sprawności przy bezchmurnej pogodzie prąd ładowania akumulatorów jest niewielki. Dlatego ten tryb ładowania sprawdza się raczej przy niewielkich akumulatorach. Ale najważniejsze, że się sprawdza 🙂 LiPol charger v2.0 Druga wersja ładowarki nie została jeszcze przetestowana!!! Natomiast wzbogaciłem ją o kilka praktycznych dodatków, których brakowało mi w poprzedniej wersji. Wersja v2.0 została wzbogacona o prototyp balansera złożonego z dwóch oporników dużej mocy oraz tranzystorów sterowanych z poziomu mikrokontrolera, który na podstawie pomiaru napięcia międzyogniwowego decyduje o tym, który obwód „strat mocy” załączyć. Jeśli któryś z tranzystorów zostaje otwarty, przez rezystor przepływa prąd, natomiast ładowanie danego ogniwa akumulatora jest pomijane. Dzięki temu możliwe jest wyrównanie poziomów napięć na obu ogniwach. Dodatkowo wyprowadzone zostały pady pomiarowe, które znacznie ułatwiają kalibrację odczytów z przetwornika ADC. Wbudowano również konwerter USB-UART na podstawie chipu FT230XQ, wyprowadzono również piny Rx i Tx w celu podłączenia np. modułu Bluetooth. W tym projekcie udało się znacząco zmniejszyć wymiary ładowarki. Kompletne schematy obu wersji ładowarki udostępniam w pdf’ach poniżej. LiPolCharger_v1_0.pdf LiPolCharger_v2_0.pdf Wykaz ważniejszych elementów wykorzystanych w układach ładowarek: mikrokontroler ATmega32 tranzystor kluczujący MOSFET-N STS12NF30L driver MOSFET MCP1402T cewka 220 uH wzmacniacze operacyjne LM358 wyświetlacz alfanumeryczny 2x16 konwerter USB-UART FT230XQ, tranzystory bipolarne NPN i PNP dowolne, pod warunkiem, że maksymalny prąd kolektor-emiter będzie większy niż 1A. Jeśli ktoś z czytelników będzie zainteresowany tematem owych ładowarek serdecznie zapraszam do zadawania pytań w komentarzach, a także ewentualnego krytykowania (oczywiście konstruktywnego) mojego projektu.

Witam. W mojej płytce arduino (nano) zepsuł się port usb. Jeśli podłącze płytkę do zewnętrznego zasilania, to wszystko działa, więc płytka jest sprawna. I tu moje pytanie: w jaki sposób mogę wgrać program na płytkę, nie korzystając z portu usb? Z góry dziękuje za pomoc 😄