Przeszukaj forum

No cóż - trochę mi to czasu zajęło. Ale dziś mam zaszczyt przedstawić Księżniczkę i Krasnoluda. Z czystym sumieniem umieszczam to w dziale "roboty" - tym razem lalki mają przynajmniej częściową autonomię czyli jak najbardziej zasługują na miano robota. Ale może chronologicznie. W pewnym momencie stwierdziłem, że teatralne lalki (klasyczne czy z dodatkiem elektroniki) to trochę za mało, i postanowiłem zrobić jakąś postać w pełni zdalnie sterowaną i z możliwością wykonania jakiegoś mniej lub bardziej skomplikowanego programu. Wybrałem Piękną Księżniczkę i zacząłem robić założenia. Wyszło mi coś takiego: Konstrukcja głowy podobna jak w poprzednich lalkach (wypróbowana, sprawdzona). Jedno serwo do napędu oczu, dwa do pochylenia i obrotu głowy. Zrezygnowałem z pełnego ruchu głowy (tak jak w mlle Woni) ze względu na trudności zarówno w animacji, jak i wykonaniu mechanizmu w domowych warunkach, a efekt nie jest wart zachodu. Silniki krokowe do napędu Zasilanie z dwóch akumulatorów 18650. Implikowało to zastosowanie stepperów EasyDrive (napięcie zasilania) i niewielkich silników NEMA14 ESP32 jako procesor Bezprzewodowy pad (z Botlandu) do sterowania. Na początek poszło podwozie. Teoretycznie wszystko było jak trzeba: dwa koła napędowe osadzone w osi lalki po bokach i dwie kulki podporowe (z przodu i z tyłu). Taki układ powinien zapewnić stabilność... Jako że po zmontowaniu podwozie jeździło całkiem zacnie, zabrałem się za resztę. I tu pierwsza trudność: serwa HD-1370A teoretycznie powinny mieć na tyle duży moment, aby podnieść lekką rękę lalki. Nie wziąłem jednak pod uwagę bezwładności - próby skończyły się rozwaleniem zębatek w serwie i zastosowaniem trochę porządniejszych (z metalowymi trybami). Dalej było tylko gorzej. Szybkie podniesienie ręki kończyło się wpadnięciem serwa w oscylacje. Jako-tako opanowałem to, zmniejszając maksymalną dopuszczalną prędkość ruchu serwa. Kontroler (pad) okazał się absolutną pomyłką. Nie ma mowy o żadnej precyzji, w końcu użyłem go e trybie cyfrowym (czyli jak joysticka w C64). W związku z tym musiałem jakoś uprościć sterowanie; zrezygnowałem z bezpośredniego sterowania oczami, głowa wykonuje tylko podstawowe gesty (tak/nie oraz spojrzenia w ośmiu kierunkach). Do regulacji prędkości silników napędowych użyłem przycisków R1/R2 - nie jest to idealne rozwiązanie, ale pozwalające na względnie dokładną kontrolę ruchu lalki. No i to nieszczęsne podwozie - pomysł był dobry, ale wykonanie absolutnie do niczego. Nie wiem co mi się przyśniło żeby silniki napędowe umocować na sztywno do korpusu a resorowanie dać na kulkach podporowych; w rezultacie lalka kołysze się w trakcie ruszania, zatrzymywania czy zmiany prędkości. Na szczęście byłem zadowolony przynajmniej z głowy. A jako, że lalka może wykonywać różne, nawet dość długie sekwencje ruchów - efekt był całkiem niezły. Przy okazji okazało się, że dodatkowy sterownik (w założeniu miał służyć wyłącznie do wyzwalania kolejnych sekwencji) co prawda działa bardzo dobrze, ale jest absolutnie bezużyteczny, więc nawet nie dokończyłem fragmentu programu obsługi. Zresztą - program w tej postaci jaka jest nadaje się tylko do napisania od zera. Tak więc Księżniczka dostała sukienkę, perukę, rzęsy i makijaż i stanęła sobie na półce aby ładnie wyglądać. Na pewno zabiorę się za przeróbkę zarówno mechanizmu, jak i programu (poczynając od wywalenia w diabły tego nieszczęsnego pada), ale to raczej zadanie na przyszłość. Teraz postanowiłem podejść do sprawy nieco inaczej. Przede wszystkim - chciałem spróbować RPi Pico jako głównego kontrolera. Do tego chciałem podłączyć RPi Zero 2 W, do programowania Pico i do obsługi kamery (jednym z zadań lalki było patrzenie w twarz rozmówcy). Poza tym musiałem przemyśleć sprawę podwozia. Zastosowałem co prawda identyczne silniki i sterowniki jak w Księżniczce, ale tym razem całość zasilana jest z akumulatora Parkside V20 2Ah. Postanowiłem rozwiązać sprawę podwozia nieco inaczej. Teraz to kulki podporowe były połączone na stałe z korpusem, a silniki umieściłem na wahaczu. Dwie sprężyny dbają o prawidłowy kontakt kół z podłożem nawet przy jeździe po nierównej podłodze. I taka konstrukcja jeździ już prawie dobrze (dlaczego prawie - o tym na zakończenie). Ręce rozwiązałem w nieco inny sposób. Oprócz uniesienia ręki lalka ma możliwość skręcenia dłoni (dłoń jest przymocowana do osi, którą obraca małe serwo w przedramieniu), a otwieranie i zamykanie palców wziąłem z mlle Woni. Całość wygląda w ten sposób: Trochę inaczej rozwiązałem głowę. Tym razem zrezygnowałem z naturalistycznego wyglądu. Ponieważ pierwotnie miał być to Troll a nie Krasnolud - naturalne wydało mi się wydrukowanie twarzy i dłoni z szarego filamentu (w końcu trolle mają coś wspólnego ze skałami, a te są najczęściej szare). Trudności techniczne zmusiły mnie do zmiany podejścia (w porę stwierdziłem, że nie mam szans na prawidłowe odwzorowanie postaci trolla bez jakichś cilikonowych odlewów, na których się absolutnie nie znam), ale w końcu Krasnoludów jest wiele gatunków, a mój jest właśnie jaskiniowy i trudni się kamieniarstwem 🙂 Wracając do głowy: spróbowałem inaczej rozwiązać kwestię skłonu (przekładnia zębata). Dodatkowo zrezygnowałem z ruchu oczu na boki; w to miejsce wprowadziłem ruch pionowy (tak jak w "zamykających oczy" lalkach). Co prawda pozwala to na dodatkowy efekt (włączenie odpowiedniej funkcji powoduje, że Krasnolud może sobie mrugać w losowych odstępach czasu), ale ogólnie ruch oczu na bioki daje więcej możliwości animacyjnych. Ideałem byłoby umożliwienie ruchu zarówno w poziomie jak i w pione - ale to zarezerwowałem sobie do następnej konstrukcji. Pionowy ruch oczu zrealizowałem nietypowo - za pomocą paska zębatego. Zdjęcie jest trochę niewyraźne, ale wnętrze głowy wygląda w ten sposób: Niestety - musiałem z przyczyn absolutnie ode mnie niezależnych zrezygnować z kamery. Po prostu okazało się, że Zero 2 W jest absolutnie niedostępny, a zwykły Zero W nie jest w stanie w jakimś sensownym czasie znaleźć twarzy na obrazie z kamery. Próbowałem zrobić po prostu streaming - uznałem jednak, że to mało przydatna funkcja, a pracujący serwer bardzo skutecznie zagłuszał sygnał radiowy sterowania. W związku z tym wyrzuciłem kamerę, w jej miejsce włożyłem czujnik ToF i postanowiłem, że zrobię przy okazji program "spacer" (czyli typowe unikanie przeszkód). Więcej czasu poświęciłem sterownikowi. Co prawda wygląda on nieco prowizorycznie, ale bardzo dobrze spełnia swoja funkcję. Użyłem tym razem precyzyjnych joysticków (dzięki kol. @Sabre). Dzięki temu mogę bardzo precyzyjnie sterować ruchami robota - zarówno napędami, jak i głową. Niestety, znów natrafiłem na problem wpadanie ręki w oscylacje. Wydawało mi się, że zastosowanie mocnego serwa (użyte przeze mnie ma 5 kG*cm) poskutkuje wymuszeniem prawidłowego ruchu ręki. Niestety - nic z tego; przy szybszych ruchach ręce znów wpadały w oscylacje. I znów poradziłem sobie z tym problemem naokoło - spowalniając ruch serwa. Jak widać na filmie - w przeciwieństwie do Księżniczki ręce Krasnoluda poruszają się z większą precyzją. Zresztą kod sterownika zamieszczam tutaj - może nikt nie będzie chciał budować takiego samego, ale część rozwiązań może się przydać (działająca biblioteka nRF24 chociażby). geopilot.zip W międzyczasie (już gdy miałem całą konstrukcję mniej więcej złożoną) pojawił się całkiem używalny polski głos dla syntezatora RHVoice. Z bólem serca pożegnałem więc Milenę i Kedrigerna. Co prawda syntezator jest strasznie mulasty (samo wczytanie np. ukraińskiego głosu zajmuje mojemu Zero W kilkanaście sekund), ale kolejne kwestie wypowiadane są już z prawie niezauważalnym opóźnieniem. Dodatkowo mogłem wprowadzić drugi język (ukraiński - ważne, bo Krasnolud lubi czasem zawitać do przedszkola do którego uczęszczają również dzieci z Ukrainy). A tak wyglądają Księżniczka i Krasnolud w realu: Niestety - z przyczyn prawnych nie mogę zamieścić nagrań z przedszkola, ale sam byłem zdziwiony jak dzieci szybko orientują się w obsłudze dość skomplikowanego w sumie kontrolera. Przy okazji "spaceru"... okazało się, że wysoko umieszczony czujnik (tam, gdzie miała być kamera - czyli w kasku) nie łapie przeszkód znajdujących się blisko podłogi. Poradziłem sobie z tym zupełnie inaczej. Ponieważ robot w czasie spaceru porusza się symulując chód (uruchamiane są silniki naprzemiennie, a głowa i ręce kontrują obrót tułowia), całość jest synchronizowana żyroskopem (po osiągnięciu 8 stopni odchylenia od kierunku następuje przełączenie silników i obrót w drugą stronę) wystarczyło sprawdzić, czy robot rzeczywiście się obraca; jeśli tak - oznacza to napotkanie przeszkody której nie wykrył czujnik ToF. I jeszcze o popełnionych błędach i niedociągnięciach... Nie mówię tu o błędach w programie (w ostatniej chwili okazało się, że jest tam dość krytyczny błąd, nie mam dzisiaj już czasu sprawdzać ale robot musi być gotowy do spotkania z dziećmi od początku września). Z tego też powodu na razie nie zamieszczam kodu samego robota. Kulki podporowe są fajne, ale dla dość ciężkiego i robota poruszającego się po niespecjalnie równym podłożu nawet calowe kulki są za małe, aby robot potrafił np. wjechać na dywan. Na razie nie mam pomysłu na rozwiązanie tego problemu, ale liczę na Wasze podpowiedzi. Wydrukowane opony mają za małą przyczepność, i koła wpadają czasem w poślizg. Można to zobaczyć na filmie, kiedy robot w czasie spaceru próbuje cofnąć się od nieistniejącej przeszkody. Tu muszę poeksperymentować z oponami; w Księżniczce użyłem oryginalnych silikonowych opon zdjętych z tanich kół. Niestety - tu koła mają nieco większą średnicę. Będę musiał po prostu wypróbować kilka możliwości - na razie myślę o wydrukowaniu węższych kół i zrobieniu opon bez bieżnika z TPE zamiast TPU. Jeśli o czymś zapomniałem - jestem do dyspozycji 🙂

Od kilku dni przeglądam SDK Raspberry Pi Pico. W pliku nagłówkowym o nazwie "address_mapped.h", który znajduje się w katalogu (ścieżka względna): "...\pico-sdk-master\src\rp2_common\hardware_base\include\hardware", natrafiłem na wiersz kodu, którego nie mogę rozgryźć. Oto on: *(io_rw_32 *) hw_set_alias_untyped((volatile void *) addr) = mask; Plik "address_mapped.h" jest dostępny pod adresem: https://raspberrypi.github.io/pico-sdk-doxygen/address__mapped_8h_source.html. Przytoczony wiersz pochodzi z funkcji: "hw_set_bits". Jej kod to: __force_inline static void hw_set_bits(io_rw_32 *addr, uint32_t mask) { *(io_rw_32 *) hw_set_alias_untyped((volatile void *) addr) = mask; } W tym wierszu występuje "funkcja" o nazwie "hw_set_alias_untyped", która w rzeczywistości jest makrem (jest umieszczone w tym samym pliku). Pytanie jest następujące: do czego jest przypisywana wartość argumentu "mask"? Po lewej stronie występuje makro "hw_set_alias_untyped", które zostanie zastąpione przez: "((uintptr_t)(addr))". Po jego podstawieniu i rozwinięciu powstanie wyrażenie (o ile nie popełniłem błędu): *(io_rw_32 *) ((uintptr_t)(volatile void *) addr) = mask; Argument "addr" jest adresem rejestru RP2040, odwzorowanego w pamięci. Ten adres ("addr") jest rzutowany na wskaźnik amorficzny ("volatile void *") a następnie na wskaźnik "uintptr_t" (znów: o ile nie popełniłem błędu). Żeby analiza była łatwiejsza można to uprościć do: wynik_makra = ((uintptr_t)(volatile void *) addr) // uproszczenie, które mam na myśli *(io_rw_32 *) wynik_makra = mask; // wynikowe wyrażenie po uproszczeniu Czy wynik makra to jakaś zmienna anonimowa (bez nazwy)? Czy lewa część wyrażenia, to dereferencja wskaźnika typu "io_rw_32", którego zawartość jest wyliczana z tego wyrażenia? Czy oznacza to, że zawartość argumentu "mask" jest przypisywana do "tego czegoś", co powstaje po dereferencji? Czy ktoś potrafi to wyjaśnić? Bo ja chyba jednak błędnie wytłumaczyłem sobie ten wiersz kodu.

Alternatywne klawiatury to rzadko poruszany temat - mimo różnego rodzaju układów, dzielenia na bloki klawiatura pozostaje typową pecetową klawiaturą różniącą się od standardowej w praktyce tylko ułożeniem klawiszy. Tymczasem jedną z ciekawszych jest tzw. klawiatura akordowa. Ma ona mniej klawiszy niż normalna, mimo to poprzez użycie kombinacji klawiszy można na niej napisać to samo, co na standardowej. Jako ciekawostkę mogę podać, że najstarszym do dziś używanym z niewielkimi modyfikacjami urządzeniem wyposażonym w klawiaturę akordową jest wynaleziona w końcu XIX wieku mechaniczna brajlowska maszyna do pisania. Zainteresowanych tematem odsyłam do obszernego artykułu w Wikipedii - niestety w wersji angielskojęzycznej, bo w polskiej wersji jest tylko krótka notka, nawet bez podstawowych linków. Dodam tylko, że historycznie podejmowano różne próby stworzenia w różnych celach takiej klawiatury, jednak najpopularniejszy jest układ siedmiu klawiszy (przynajmniej jeden model - BAT keyboard - jest wciąż produkowany), tak więc postanowiłem zrobić swoją wersję właśnie na tym układzie. Oczywiście - istnieją gotowe programy, zarówno dla klawiatury łączonej przez USB (różne rodzaje ATmeg/PIC-ów z software'owym USB czy Arduino Pro Micro) jak i BLE (Adafruit Feather). Po zapoznaniu się z tymi rozwiązaniami stwierdziłem, że chcąc wprowadzić te możliwości o których myślałem potrzeba byłoby zbyt wielu zmian w programach, tak więc zdecydowałem się na napisanie czegoś swojego. Jako "serce" urządzenia wybrałem RPi Pico (najważniejszy powód był taki, że leżał sobie w szufladzie). Myślałem jeszcze o jakimś Lolin 32 Lite (leżał sobie obok Pico w tej samej szufladzie) z uwagi na wbudowaną ładowarkę, ale po przemyśleniu postanowiłem pozostać przy USB i zasilaniu z hosta - mam niemiłe doświadczenia z akumulatorami rozładowującymi się nie wtedy kiedy trzeba... Na początku przemyślałem sobie mechaniczną budowę. Ułożenie klawiszy w oglądanych modelach wydało mi się niezbyt fortunne. Ułożenie ręki na takiej klawiaturze jest zupełnie inne niż na tradycyjnej, tak więc położenie klawiszy musi być dopasowane do ręki użytkownika. Po przeprowadzonych kilki próbach "na sucho" wyszło na to, że najlepszym rozwiązaniem będzie układ, gdzie dłoń opiera się o powierzchnię biurka, a klawisze umieszczone są tam, gdzie trafiają luźne palce. Po wykonaniu pomiarów okazało się, że układ który mi najbardziej pasuje jest zupełnie inny. Co prawda pozostaje podstawowy układ (trzy klawisze dla kciuka i po jednym dla pozostałych palców), ale rozmieszczenie klawiszy w obu blokach było nieco inne, a wzajemny układ obu bloków to już całkowicie inna sprawa). Pierwsza wersja powstała na dwóch oddzielnych kawałkach płytki uniwersalnej przykręconych do kawałka płyty spienionego PCW, co pozwalało na dokładne wzajemne dopasowanie obu bloków. Do tego użyłem aż pięciu LED pokazujących stan klawiatury. Jako klawisze wybrałem Cherry ML1A-11NW - nie wiem czy dobrze, ale działają. Natomiast założenia programowe były następujące: Podobnie jak w innych klawiaturach sygnał o wciśnięciu klawisza jest generowany po puszczeniu wszystkich klawiszy akordu, ale z możliwością pozostawienia wciśniętego jednego z klawiszy kciuka. Po pierwsze ułatwia to użycie klawiatury, gdy używamy jednego z bloków znakowe/numeryczne/kursor, a w przypadku klawiszy kursora ważne jest, aby klawiatura pamiętała wciśnięty Shift, Alt czy Ctrl. Programowo klawiatura podzielona jest na trzy bloki: Podstawowy (literowy) (26 podstawowych liter, spacja, enter, dodatkowo makra dla "dż" i "dź" które wymagałyby wciśnięcia zbyt wielu klawiszy), klawisz CENTRAL zmienia po prostu bank, przy czym dla ułatwienia spółgłoski bezdźwięczne i odpowiadające im dźwięczne są na tym samym miejscu (np. "s" to dwa pierwsze klawisze, "z" to te same dwa pierwsze klawisze ale z wciśniętym CENTRAL). Blok kursorów i klawiszy specjalnych (w tym funkcyjnych) Blok znaków interpunkcyjnych przełączany na numeryczny, przy czym w trybie numerycznym musi być dodatkowy dostęp do kropki (zapis ułamków dziesiętnych), dwukropka (zapis godzin) i klawisza TAB. Po wstępnych próbach znów okazało się, że zwykłe klawisze nie nadają się do tej klawiatury. O ile dla palców klawisze powinny zapewniać po prostu pewne ułożenie palca uniemożliwiające przesunięcie (w tym przypadku typowy kształt jako-tako się sprawdza)), o tyle klawisze kciuka są wciskane bokiem palca i tradycyjny kształt jest po prostu niewygodny. Dlatego zaprojektowałem zupełnie inny kształt klawisza - plik STL w załączeniu.kciuk.zip Układ połączeń klawiatury jest bardzo prosty, całość składa się z: RPi Pico (bez wlutowanych pinów) Siedmiu klawiszy podłączonych bezpośrednio do GPIO Pięciu diod połączonych przez rezystory 1.2k (takie miałem) do GPIO. Dla porządku zamieszczam schemat I tu jedna uwaga: ponieważ wszystkie diody sterowane są sygnałem PWM, w programie przewidziałem możliwość korekty jasności każdej z nich, tak więc można wybrać dowolne rezystory (w pierwszej wersji było to 1.5k, dioda nie ma oświetlać pomieszczenia tylko sygnalizować stan urządzenia). Wygląd gotowego urządzenia pokazałem już wyżej, teraz tylko dwa zdjęcia z procesu składania: I od razu kilka słów wyjaśnienia: Użyłem płytek z wersji próbnej z bardzo prozaicznego powodu: musiałem kupić Pico (i kilka innych drobiazgów) a nie znalazłem sklepu który sprzedawałby wszystko co trzeba. Zamawianie płytki za 5 PLN plus płacenia za paczkomat uznałem za zły pomysł. Również wytrawianie własnej płytki (nawet nie bardzo mam w czym wytrawić) uznałem za niewygodne rozwiązanie - zrobienie kilku połączeń kynarem było dużo szybsze, szczególnie że miałem już coś działającego. "Krzywa" płytka z diodami i brak jednej śrubki to nie wynik niedbalstwa; po prostu w tym miejscu przechodzi jedna ze śrub mocujących górną część obudowy. Widoczna "dziura" przed klawiszami kciuka to też nie wynik braku materiału. Po prostu obudowa musiałaby być obniżona w tym miejscu z uwagi na położenie palca, a po pierwsze trudno określić konieczne obniżenie bez prób, po drugie takie coś fatalnie się drukuje. Poza tym wieczko po zamknięciu i tak zakrywa to miejsce... a w ogóle to nie jest do oglądania i podziwiania tylko do pisania. Poza tym jak już wspominałem, cała klawiatura musi być dostosowana do ręki użytkownika, tak więc publikowanie jakichś STL-i czy projektów PCB na nic by się nie przydało. A prawidłowe ułożenie palców powinno wyglądać tak: (przepraszam za fatalne ujęcie, ale nie bardzo miałem jak zrobić fotkę bez statywu). I kilka słów o technice pisania. Pełna mapa klawiatury jest w pliku sciaga.txt w załączniku. Użyte nazwy klawiszy to kolejno (od najdalszego kciuka): FAR CENTRAL NEAR A E I O. Muszę jednak jeszcze wspomnieć o kilku drobiazgach. Przyciski kciuka jeśli wciskane są samodzielnie (bez klawiszy palców) działają jak modyfikatory, Rozróżniane są krótkie i długie wciśnięcia - np. krótkie wciśnięcie CENTER to shift, dłuższe to capslock. Stan danego modyfikatora sygnalizują odpowiednie diody. Jeśli po puszczeniu klawisza w ciągu 5 sekund nie nastąpi żadna reakcja użytkownika, modyfikator jest kasowany. Kasowany jest również po odebraniu następnego znaku, z następującymi wyjątkamu: - klawisze ruchu kursora zapamiętują stan Alt, Shift i Ctrl dopóki nie zostanie puszczony przycisk NEAR alo nie zostanie wprowadzony znak inny niż ruch kursora. Zapamiętanie stanu odbywa się w samej klawiaturze, czyli np. wciśnięcie kolejno "Shift, Right, Right" spowoduje wysłanie do hosta sekwencji: SHIFT Pressed RIGHT Pressed ALL Released SHIFT Pressed RIGHT Pressed ALL Released - Klawisze makr "Alt-Tab" i "Shift-Alt-Tab" zapamiętują modyfikator Alt w nieco inny sposób: ponieważ w trakcie zmiany okien klawiszami TAB i SHIFT/TAB klawisz Alt musi pozostawać wciśnięty, sekwencja np. "Alt-Tab Alt-Tab" jest przesyłana jako: ALT presssed TAB pressed TAB released TAB pressed TAB released ALT released Jest to co prawda techniczny szczegół, ale warto o nim pamiętać. Klawisz Super jest rzadko wykorzystywany, więc normalnie jest zablokowany aby nie mylił się z Ctrl. W każdej chwili można go odblokować odpowiednią kombinacją klawiszy (NEAR-AEIO NEAR-AIO). W trybie klawiatury - jak już wspominałem - znak interpretowany jest dopiero po puszczeniu wszystkich klawiszy AEIO. Umożliwia to spokojne wciskanie klawiszy akordu po kolei. W trybie myszy jest jednak inaczej. Teoretycznie klawisze powinny reagować od razu powodując przesłanie informacji o ruchu do hosta. Istnieją jednak kombinacje klawiszy nie związane z ruchem myszy (np. obrót kółka czy wciśnięcie/puszczenie modyfikatora). Dlatego pierwszy komunikat po wciśnięciu jest lekko opóźniony, dając czas na wciśnięcie dwóch lub trzech klawiszy. Czas (50 msec) jest na tyle krótki, aby nie utrudniał poruszania myszą, a jednocześnie umożliwiał operowanie takimi kombinacjami, należy jednak liczyć się z tym, że może wystąpić przesunięcie wskaźnika o piksel. Klawiatura jest przystosowana do obsługi prawą ręką, ale nic nie stoi na przeszkodzie aby zrobić lustrzaną wersję dla lewej ręki. Należy jedynie odkomentować w pliku keyboard.c linijkę: #define LEFTHAND co spowoduje właściwe ułożenie klawiszy kursora, nawiasów oraz myszy. I jeszcze o możliwych modyfikacjach. Klawiatura w tej postaci nie nadaje się dla niewidomych - niektóre kombinacje klawiszy (np. Insert-Space) są nieosiągalne. Na chwilę obecną widzę trzy rozwiązania: - dodanie dodatkowego klawisza (może być niewygodne) - zmiana programu w ten sposób, że akord "Insert" reaguje z opóźnieniem, a wciśnięcie jakiegoś akordu przed upłynięciem czasu opóźnienia powpoduje wysłanie np. sekwencji: INSERT Pressed, COŚTAM Pressed, ALL Released. - rezygnacja z makr "dż" i "dź" i wprowadzenie w to miejsce dodatkowych poleceń dla screenreadera. Tak zmodyfikowana klawiatura może być użyteczna przy jednoczesnym pisaniu i posługiwaniu się linijką brajlowską. Ponieważ klawiatura może być dołączona równolegle z normalną nic nie szkodzi aby używać obu zamiennie. Moim zdaniem taką klawiaturę należałoby wyposażyć również w jakiś sygnał akustyczny zastępujący wskaźnik diodowy, ale to już zależałoby od samego zainteresowanego. Ponieważ klawiatura nie wymaga trzymania ręki nad nią - może być użyta przez osoby o ograniczonej zdolności ruchu. Jeśli np. palce są sprawne, a niedowład dotyczy wyłącznie możliwości uniesienia ręki w takim przypadku nie trzeba żadnych zmian. Można również rozdzielić klawiaturę tak, aby palce jednej ręki obsługiwały modyfikatory, a drugiej klawisze palców. Oczywiście taka klawiatura może być również bez żadnych zmian użyta przez osoby posługujące się tylko jedną ręką. I to by było na tyle. Zamieszczam jeszcze pełną mapę klawiatury (w bloku "Pozostałe" trzecią i czwartą pozycję makr uzyskuje się poprzez włączenia AltGr): aeio | CENTRAL | ------+-------------+ x--- | A U | -x-- | E Y | xx-- | S Z | --x- | I J | x-x- | C X | -xx- | N M | xxx- | P B | ---x | O H | x--x | F W | -x-x | L R | xx-x | K G | --xx | T D | x-xx | V Q | -xxx | Dż Dź | xxxx | Space Enter | ------+-------------+ === MODYFIKATORY === Klawisz | Short | Long --------+-------+---------- FAR | AltGr | Alt CENTRAL | Shift | CapsLock NEAR | Ctrl | Super --------+-------+---------- === POZOSTAŁE KLAWISZE === aeio | FAR | FAR/NUM | NEAR Fn | ------+-----------+-------+----------+-------+-----------------+ x--- | . > | x--- | 1 ! | x--- | left F1 | -x-- | , < | -x-- | 2 @ | -x-- | up F2 | xx-- | [ { | xx-- | 3 # | xx-- | pgup F3 | --x- | ; : | --x- | 4 $ | --x- | right F4 | x-x- | ( % ^ \ | x-x- | 5 % | x-x- | a-tab F5 | -xx- | / ? | -xx- | 6 ^ | -xx- | bs/del F6 | xxx- | @ & | § | xxx- | 7 & | xxx- | home F7 | ---x | ' " | ---x | 8 * | ---x | down F8 | x--x | ! $ # € | x--x | 9 ( | x--x | esc F9 | -x-x | ) * = + | -x-x | 0 ) | -x-x | s-a-tab F10 | xx-x | - _ | xx-x | - _ | xx-x | insert F11 | --xx | ] } | --xx | = + | --xx | pgdown F12 | x-xx | ` ~ | x-xx | \ | | x-xx | menu/prt Super| -xxx | tab | -xxx | tab . : | -xxx | end Mouse| xxxx | NUM | xxxx | NUM | xxxx | Fn FnOff| ——————+———————————+———————+——————————+———————+—————————————————+ ==== MYSZ ==== aeio | ------+------------ x--- | Left -x-- | Up xx-- | LeftUp --x- | Right x-x- | ScrollUp -xx- | RightUp xxx- | Keyboard: Show Cursor ---x | Down x--x | LeftDown -x-x | ScrollDown xx-x | Keyboard: Alt Key --xx | RightDown x-xx | Keyboard: Ctrl Key -xxx | Keyboard: Shift Key xxxx | Mouse Off ——————+------------ === MOUSE BUTTON EMULATION == FAR = LMB CENTRAL = MMB NEAR = RMB === LED === Keyboard mode: No | Light | Blink | Dark ---+----------+--------+----------- 1 | CapsLock | Power | 2 | Numeric | | 3 | AltGr | Alt |Keep alt 4 | Ctrl | Super |Keep ctrl 5 | Shift | Fn |Keep shift ---+----------+--------+----------- Mouse mode: 1/2 Blink - mouse mode active 3 - Alt pressed 4 - Ctrl pressed 5 - Shift pressed Do tego w załączniku pełny kod programu.PicoChorder.tgz Oczywiście odpowiadam na wszystkie pytania i sugestie (nawet pozornie głupie - w końcu nie jestem wszechwiedzący i coś co pozornie może nie mieć sensu może okazać się ciekawym rozwiązaniem).

Poniższe pytanie zostało wydzielone z tematu: https://forbot.pl/forum/topic/19365-premiera-raspberry-pi-pico-za-4-z-nowym-ukladem-rp2040/ ______ @Pyth0n Dzięki za odpowiedź, ciekawa sprawa swoją drogą, teoretycznie to jest jeden standard ARM SWD. Kombinuje cały czas z płytką i spotkałem się dzisiaj z ciekawym jak dla mnie problemem. W kolejce fifo między rdzeniami można przekazywać tylko int'y, w examplu multicore_runner przekazano funkcje za pomocą multicore_fifo_push_blocking((uintptr_t) &factorial); i int32_t (*func)() = (int32_t(*)()) multicore_fifo_pop_blocking(); Walczę z tym jak przekazać w jakiś sposób arraya charów (char[]) w podobny sposób, lecz póki co bez skutku, co podejrzewam wynika z mojej niewielkiej wiedzy o C. Macie może jakieś pomysły na przekazywanie w taki sposób takiego arraya? Lub może jakieś inne sposoby na to?

Czy ktoś próbował już użyć STLink/V2 do programowania płytki poprzez SWD? Ciekawi mnie czy jest to możliwe i czy debugger działa w pełni

Co to takiego te PIO nad którymi się tak zachwycacie?

Do czego są dwa kanały i2C hardwareowe? Jakie to przynosi korzyści ? Chciałbym podłączyć 4 identyczne czujniki, które mają możliwość wyboru 2 adresów. Softwareowo jest to nie możliwe? Czujników chciałbym obsłużyć aż 16 przez raspberry pi 4 za pomocą bluetooth 2.0. Ile potrzebuje płytek RP2040? Ile takich połączeń jednocześnie RP4 może obsługiwać?

Mikrokontroler posiada 4 kanały ADC, wyprowadzone są 3 i tak sprawdziłem w plikach do czego prowadzi sygnał ADC3. Widzę dopisek ale niezbyt rozumiem ja kto działa. Ktoś bardziej doświadczony ma pomysł?