Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją od 27.09.2020 we wszystkich miejscach

  1. 11 punktów
    To będzie zbiór kilku projektów, które zrobiłem przez ostatnie kilka lat, związanych z klawiaturami. Zorientowałem się, że nie pisałem o tym tutaj jeszcze nigdy (poza krótką wzmianką w "nad czym teraz pracujesz"), a temat jest bardzo głęboki i potencjalnie ciekawy dla wszystkich użytkowników komputerów, szczególnie gdy spędzają przy nich dużo czasu. Z góry ostrzegam o dwóch sprawach: po pierwsze, klawiatury mechaniczne (a tylko takie moim zdaniem jest sens samemu budować) są dość drogą zabawą, ze względu na wysoki koszt mechanicznych przełączników no i ich dość dużą liczbę w takim projekcie. Owszem, w minimalnych klawiaturach możemy się obyć 40-klawiszami, ale i tak wychodzi to drogo. Na pewno nie ma co liczyć na zrobienie klawiatury taniej niż sklepowa, chyba, że przerabiamy klawiaturę znalezioną na złomowisku (co tak naprawdę jest doskonałym pomysłem, bo drzewiej klawiatury były znacznie wyższej jakości niż dziś). Po drugie, osobiście skupiać się będę na klawiaturach do pracy, czyli do pisania dużych ilości tekstu. Nie interesują mnie klawiatury zaprojektowane do jak najszybszego wykonywania combosów albo oddawania jak największej liczby strzałów, czy też najskuteczniejszego oślepiania użytkownika migającymi animacjami we wszystkich kolorach tęczy. To są osobne nisze, które nieco się pokrywają, ale mają odmienne wymagania niż moje. No więc zacznijmy może od najbardziej oczywistego pytania: po co robić własną klawiaturę, skoro te ze sklepu będą tańsze, w ładnej obudowie i od razu działające. Normalnie w takim przypadku odpowiedź brzmi "żeby się nauczyć i wiedzieć jak działa", ale akurat w tym przypadku mamy znacznie lepsze powody: ergonomia, wybór i jakość. Zacznijmy od ergonomii. Każdy, kto czytał o alternatywnych układach klawiatury, takich jak Dvorak czy Colemak, na pewno wie, że tradycyjny układ QWERTY nie został jakoś specjalnie zaprojektowany dla optymalności. Krążą nawet legendy, jakoby niektóre klawisze zostały poprzestawiane specjalnie, żeby maszynistki spowolnić, bo w przeciwnym razie mechanizm maszyny nie nadążał i zacinał się. Legendy te są nieprawdziwe. Owszem, poprzestawiano klawisze, ale nie w celu spowolnienia, tylko w celu oddalenia od siebie młoteczków tych liter, które często występują obok siebie, żeby właśnie zmniejszyć szansę zacięcia. Ale nie miało to na celu spowolnienia piszących i nie da się takiego efektu zauważyć. Drugą legendą jest większa "prędkość" pisania na nowych, zoptymalizowanych układach — niestety ten efekt jest zauważalny wyłącznie w badaniach przeprowadzonych przez proponentów tych układów i jak dotychczas nie udało się go powtórzyć w niezależnych badaniach. Zatem standardowy układ klawiatury jest jednak optymalny? Niekoniecznie, szczególnie gdy będzie nam wolno zrobić więcej niż tylko pozamieniać klawisze miejscami. Klawiatura w tej formie, którą znamy, powstała niemalże 150 lat temu, gdy ustandaryzowały się maszyny do pisania i od tamtego czasu prawie się nie zmieniła, poza dodaniem kilku klawiszy tu i ówdzie, no i oczywiście zmianach w technice produkcji. Na pewno zauważyliście, na przykład, że klawisze nie są ustawione w równych kolumnach, tylko w każdym rzędzie przesunięte są o ¼ albo ½ szerokości. Dlaczego tak? Bo w maszynach do pisania klawisze zamontowane były na metalowych dźwigniach i trzeba było na te dźwignie mieć miejsce. Inna rzecz, że nie wszystkie klawisze są tej samej wielkości. Oczywiście częściowo związanie jest to ze wspomnianym już ich poprzesuwaniem, żeby całość jednak mieściła się w prostokącie, ale częściowo związanie jest to z tym, że taka maszyna do pisania jest w zasadzie napędzana siłą ludzkich mięśni, i o ile taki zwykły młoteczek z literką da się poruszyć jednym palcem (choć kto próbował kiedyś mechanicznej maszyny ten wie, że żeby się dobrze odbiło, a jeszcze w kilku kopiach przez kalkę, to nieraz trzeba nieźle w taki klawisz przyłożyć), o tyle klawisz "shift" na przykład podnosi praktycznie cały mechanizm do góry, a do tego trzeba go przytrzymać — łatwiej to zrobić gdy klawisz jest większy. Podobnie inne "specjalne" klawisze są zazwyczaj traktowane specjalnie, do tego stopnia, że "enter" oryginalnie nawet nie był klawiszem, tylko dźwignią umieszczoną przy wałku. Wszystkie te kompletnie nieistotne dziś detale zachowały się w tradycyjnym układzie i utrudniają nam życie. Budując własną klawiaturę możemy je zignorować i zaprojektować ją od początku dobrze. Drugi powód to wybór. Oczywiście można dzisiaj znaleźć w sklepach szeroki wybór klawiatur w różnych kolorach, z touchpadem, z migającymi światełkami, bezprzewodowych, do tabletów, z kucykami, etc. Ale nawet jeśli sięgniemy po te z wyższej półki, to nie mamy za bardzo wyboru w kwestiach, które się liczą dla wygody pracy. Klawiatury niskoprofilowe wyglądają jak skopiowane z kalkulatorków, klawiatury mechaniczne są tak wysokie, że można dostać lęku wysokości patrząc między klawisze, producenci często wykazują się fantazją przestawiając niektóre klawisze albo zastępując klawisze funkcyjne klawiszami do zmiany głośności albo uruchamiania kalkulatorka. Pewien producent urządzeń domowych udających komputery nawet stwierdził, że klawisz Esc w zasadzie nikomu do niczego nie jest potrzebny (lata wcześniej usunęli klawisze Ins i Del i też było dobrze). Zatem w praktyce wybór rozsądnych klawiatur do pracy jest zatrważająco mały. Nie pomaga przy tym fakt, że producenci wprowadzając nowe udziwnione produkty lubią usuwać z oferty te dobre i sprawdzone, więc jeśli zepsuje się wam dobra klawiatura, której używaliście przez lata, to zapomnijcie o kupieniu takiej samej. No i wreszcie jakość. Trochę to dziwne, że coś, co możemy zbudować domowym sumptem będzie mieć wyższą jakość niż zaprojektowane przez profesjonalistów i wyprodukowane w fabrykach towary, ale tak jest — głównie dlatego, że większość ludzi kupując komputer nie myśli o jakości klawiatury, tylko o tym, żeby jakaś była, i być może, jeśli to do gier, to żeby migała. Istnieje kilka firm specjalizujących się w rzeczywiście dobrych klawiaturach, ale ponieważ nie sprzedają ich dużo, a celują głównie w profesjonalistów, to ich ceny są naprawdę wygórowane. Jeśli chcemy coś dobrej jakości, ale tańsze od używanego samochodu, to pozostaje nam polować na klawiatury gamerowe, którym przypadkiem trafiły się akurat lepsze części. Wymaga to cierpliwości i dobrego oka. No albo uda się nam zdobyć "starą" klawiaturę, która okaże się dla nas skarbem. Alpen Clack Moja przygoda z klawiaturami rozpoczęła się właśnie od takiego przypadku — dostałem "ze złomu" starą klawiaturę, która przeleżała u mnie kilka lat, aż któregoś dnia postanowiłem przerobić ją na klawiaturę USB (oryginalnie była oczywiście PS/2, i to ze starą, dużą wtyczką DIN). Słyszałem co prawda o rozwiązaniach polegających na zrobieniu adaptera, a stwierdziłem, że będę ambitny i wymienię w niej całą elektronikę. W tym samym czasie zaczęły też pojawiać się klawiatury bez numpada (tak zwane "tenkeyless") i spodobał mi się pomysł zostawienia więcej miejsca na myszkę, szczególnie, że komputera nauczyłem się używać na klonie IBM XT, który nie miał osobnych strzałek, więc NumLock musiał być zawsze wyłączony by był dostęp do strzałek, więc nigdy nie nauczyłem się używać numpada. Z usuniętych klawiszy postanowiłem zrobić brakujące klawisze "super". Klawiatura przed operacją wyglądała tak: Wtedy o tym nie widziałem, ale okazało się, że trafił mi się nie mała rarytas: klawiatura z mechanicznymi przełącznikami firmy ALPS. Dzisiaj takie są bardzo poszukiwane. Ale nie wiedząc o tym z zadowoleniem zabrałem się za jej masakrowanie. Trzeba było ją rozmontować, wylutować wszystkie przełączniki, umyć klawisze no i obciąć ten nieszczęsny numpad: Oraz wyciąć dziury na dodatkowe klawisze: Następnie powtykałem wszystkie przełączniki na miejsca, przylutowałem do nich wylutowane z płytki klawiatury diody, i połączyłem wszystko mniej więcej w matrycę, podłączając do nóżek płytki prototypowej Pro Micro. Niestety nóżek nie starczyło, więc musiałem też wylutować z Pro Micro jedną z diod świecących i użyć jej jako dodatkowej nóżki. Tutaj wypada się zatrzymać na chwilkę, żeby wyjaśnić po co te diody i jakim cudem da się podłączyć niemalże 100 przełączników do mikrokontrolera, który ma tylko jakieś 20 nóżek. Odpowiedzią jest wspomniana wcześniej matryca. Przełączników nie podłączamy tak jak się to zazwyczaj robi, pomiędzy nóżkę a masę, tylko pomiędzy dwie nóżki. A dokładniej, pomiędzy nóżki podłączone do kolumn, a nóżki podłączone do rzędów. No i teraz ustawiamy masę tylko na jednym z rzędów (lub kolumn), pozostałe zostawiając w trybie wejścia, a na kolumnach (lub rzędach, odpowiednio) ustawiamy rezystory podciągające i odczytujemy wartości. W ten sposób sczytamy stan klawiszy z jednego rzędu (lub kolumny) i operację powtarzamy dla innego. Robimy to bardzo szybko, więc opóźnienie jest niezauważalne dla człowieka. Ale po co te diody? No bo niestety może się zdarzyć, że wciśnięte zostaną dwa (lub więcej) klawisze, wówczas rząd na którym ustawiliśmy masę będzie połączony przez przełącznik jednego z tych klawiszy z kolumną, a ta z kolei będzie połączona z innym rzędem przez przełącznik innego wciśniętego klawisza — w rezultacie masę będziemy mieć na dwóch (lub więcej) rzędach jednocześnie i nie będziemy mieć sposobu na zgadnięcie które dokładnie klawisze są wciśnięte. Tanie klawiatury radzą sobie z tym prosto: po prostu uznają, że wciśnięte są wszystkie, przez co uzyskujemy zaskakujący wynik: tak zwany "ghosting". My chcemy porządną klawiaturę, więc na każdym przełączniku jest dioda zapobiegająca połączeniu rzędów. Dalej poszło już z górki: użyłem gotowego oprogramowania z projektu TMK (https://github.com/tmk/tmk_keyboard), więc jedyne, co trzeba było napisać, to dwie funkcje: jedna do ustawiania odpowiedniego rzędu i jedna do sczytywania jego stanu. Skopiowałem i przerobiłem po prostu przykłady. Do tego definicją który klawisz ma wysyłać jaki kod (lub modyfikator) i gotowe. Na koniec dołożyłem ładny kabel USB w otulinie z plecionki i dorobiłem obudowę z arkuszy tworzywa sztucznego: Troszkę ta obudowa wyszła niechlujnie, ale klawiatura działa i jest nawet wygodna — byłem z projektu zadowolony. Tylko pojawił się jeden mały problem: pracując nad tym projektem odkryłem bardzo dużo narzędzi i informacji o robieniu klawiatur. W tym między innymi oprogramowanie do projektowania własnych układów klawiszy i do generowania z nich plików do wycięcia laserem własnej obudowy. Znalazłem też gdzie można kupić mechaniczne przełączniki i same klawisze okazyjnie, postanowiłem więc zbudować kolejną klawiaturę od zera. Alpen Clack 2 Stanąłem przed kilkoma ważnymi wyborami. Po pierwsze, chciałem standardowy układ amerykański (ANSI), ale bez numpada (tenkeyless). Użyłem zatem jednego z presetów na http://www.keyboard-layout-editor.com/ i usunąłem numpad. Przy okazji przesunąłem nieco też klawisze funkcyjne i zrobiłem tam miejsce na dodatkowy klawisz. Następnie skopiowałem json-a z definicją klawiatury i wkleiłem do http://builder.swillkb.com/ aby wygenerować pliki do wycięcia laserem. Lokalny FabLab wyciął mi je bez problemu. Wybór przełączników miałem ograniczony budżetem, ale zdecydowałem się na brązowe Gaterony. Czemu brązowe i czym się one różnią od niebieskich albo czerwonych? Albo innych jeszcze kolorów? Długo by tłumaczyć, ale w dużym skrócie różne "kolory" przełączników mają różnie ustawione mechaniczne elementy tak, aby dawać odpowiednie wrażenie przy ich wciskaniu. Niebieskie przełączniki to te najbardziej znane z klawiatur mechanicznych, wydają przy wciśnięciu charakterystyczne głośnie kliknięcie, które odczuwane jest też w bardzo satysfakcjonujący sposób dotykiem. Czerwone przełączniki natomiast nazywane są "liniowymi" bo nie wydają odgłosu ani nie mają żadnego dotykowego powiadomienia o tym, że się włączyły. Przełączniki brązowe są pewnym kompromisem — wyczuć można w nich przełączenie, ale nie hałasują tak głośno, jak niebieskie. Nie mając doświadczenia postanowiłem pójść na ten kompromis. Klawisze wybrałem z tego co akurat było w danym momencie dostępne za rozsądne pieniądze i w ładnym kolorze. Nie widziałem wtedy jeszcze nic o profilach, różnych wysokościach klawiszy i różnych sposobach ich wykonania. Oprócz tego kupić trzeba było też tak zwane "stabilizatory", czyli kawałki drutu i plastikowe uchwyty do nich, które montuje się pod wszystkimi dłuższymi klawiszami po to, aby wciskały się zawsze całe naraz, bez względu na to w którym miejscu je naciśniemy. Jako mózgu użyłem tym razem płytki Pololu A-Star 32U4 Mini ULV — bo ma ten sam mikrokontroler ATmega32u4 co Pro Micro, ale z wyprowadzonymi wszystkimi nóżkami. Spodobała mi się tez biała płytka PCB, która w tamtych czasach była jeszcze rzadkością, Diody musiałem kupić tym razem własne, podszedłem też nieco bardziej profesjonalnie do połączeń: Przezroczysta obudowa w końcu trochę zobowiązuje. Oprogramowanie w zasadzie jest takie samo, musiałem tylko zmodyfikować definicje który klawisz jest który. Gotowa klawiatura wygląda tak: Niestety, pomimo faktu, że jest to dobra klawiatura, jakoś nie nauczyłem się jej używać. Znacznie później uświadomiłem sobie dlaczego, kiedy wypróbowałem kilka innych mechanicznych klawiatur: standardowe mechaniczne klawiatury, z pełnowymiarowymi przełącznikami są dla mnie za wysokie. Zazwyczaj rozwiązuje się ten problem stosując podkładki pod nadgarstki, ale dla mnie to nigdy nie działało, tym bardziej, że droga klawisza jest dla mnie zbyt wielka, nawet po dodaniu do nich "uszczelek" aby ją zmniejszyć. Wciskając klawisz mam wrażenie, że za chwilę wpadnę do środka klawiatury. Kiedy sobie to uświadomiłem, dałem sobie spokój z klawiaturami mechanicznymi ma ładnych kilka lat. 5plit Któregoś dnia dowiedziałem się, że w moim mieście odbywa się spotkanie miłośników klawiatur. Postanowiłem na nie pójść nie tyle z miłości do klawiatur, co z chęci pochwalenia się moimi dwoma projektami. Okazało się, że spotkanie było bardzo ciekawe i dowiedziałem się na nim o wielu rzeczach, między innymi o planowanych przez firmę Kailh przełącznikach o niskim profilu, zwanych "czekoladowymi" (choc switches). Sprawdzałem od tego czasu stronę tej firmy regularnie, niestety najmniejsze zamówienie jakie można było zrobić to 800 sztuk, więc pozostawały poza moim zasięgiem. Zastanawiałem się czy nie złożyć się może w kilka osób, ale jakoś nigdy z tego nic nie wyszło i o sprawie zapomniałem. Rok później spotkanie odbyło się ponownie i tym razem pojechałem bardziej żeby pooglądać ciekawe klawiatury i dowiedzieć się nowinek. No i dowiedziałem się, że Kailh sprzedaje swoje przełączniki na sztuki na Aliexpressie, razem z pasującymi klawiszami, a do tego kupiłem od jednego z uczestników płytki do dwuczęściowej klawiatury jego projektu używającej tych przełączników: Klawiatura nazywa się 5plit is jest minimalistyczna, ale jak tylko jej spróbowałem, to wiedziałem, że to są przełączniki, na które czekałem całe życie. Po zmontowaniu jej własnej wersji i zabawie z różnymi układami klawiszy odkryłem też uroki minimalistycznych klawiatur z "warstwami" — czyli różnymi funkcjami poszczególnych klawiszy przełączanymi za pomocą dodatkowego klawisza. Niestety na tym etapie nie potrafiłem jeszcze pisać poprawie wszystkimi palcami, głównie używając trzech palców u każdej ręki i czasem wciskając klawisze z lewej strony klawiatury prawą ręką, więc taka dwuczęściowa klawiatura nie była dla mnie łatwa w użyciu. Starałem się na niej ćwiczyć, ale do codziennego korzystania z komputera preferowałem jednak klawiaturę kupną (udało mi się w końcu znaleźć kupną klawiaturę używającą tych samych przełączników i jest to najlepsza kupna klawiatura jaką kiedykolwiek miałem, choć nadal jest dość wysoka). Flounder Na tym etapie postanowiłem, że skoro w sklepach nie ma takich płaskich klawiatur jak ja bym chciał, to sam sobie taką zrobię. Postanowiłem, że posunę się tak daleko jak to tylko możliwe używając nawet niższych przełączników niż te w 5plit — wpuszczanych w płytkę drukowaną. Chciałem też, żeby klawiatura miała tradycyjny układ, ale była minimalistyczna, więc tym razem zdecydowałem się na układ 65%. Zamówiłem na Aliekspresie przełączniki i zestaw klawiszy i zabrałem się do projektowania płytki. Tak naprawdę to ten projekt stał się możliwy tylko dlatego, że mniej więcej w tym czasie płytki drukowane większe niż 10x10cm stały się dostępne cenowo dla hobbysty, choć nadal była to inwestycja. Zaprojektowanie płytki wymagało trochę pracy, bo trzeba było zrobić wycięcia na każdy klawisz, a następnie poprowadzić ścieżki pomiędzy nimi. Udało mi się to z tylko dwoma małymi błędami, które poprawiłem drucikami. Pożegnałem się także z wysłużoną Atmegą32u4 i użyłem SAMD21, który stał się na tym etapie moim ulubionym mikrokontrolerem. Dodanie do CircuitPythona obsługi USB pozwoliło mi napisać kod kontrolujący klawiaturę w tym języku, co też było miłą odmianą. Z fizycznych problemów najgorsze okazały się stabilizatory. Kailh oferuje specjalne stabilizatory dla tych klawiszy, ale montowane są one po drugiej stronie PCB, co w moim przypadku jest niedopuszczalne, bo płytka ma leżeć płasko na stole. W ostateczności zbudowałem własne stabilizatory ze spinaczy do papieru: Generalnie rzecz biorąc projekt okazał się przełomowy, bo nauczyłem się na nim bardzo dużo. Niestety, ostateczny jego wynik, czyli sama klawiatura, okazała się nieużywalna z trzech powodów. Po pierwsze, postanowiłem ją zrobić tak małą jak się da, więc popełniłem kardynalny błąd eksperymentując z odstępami klawiszy i zamiast użyć standardowego 1U (czyli 0.75" albo 19.05mm) upchnąłem je tak gęsto, jak na to pozwoliła wielkość klawiszy. Okazuje się, że to źle współpracuje z ludzką pamięcią mięśniową i po prostu nie trafiam w klawisze. Po drugie, przełączniki wpuszczane w płytkę okazują się być znacznie gorszej jakości niż zwykłe choc switches i po prostu nie są tak przyjemne. Po trzecie, nie udało mi się zrobić tak, żeby płytka była całkowicie płaska z tyłu, a przy tej wielkości niestety lekko się ona wygina. Można zatem powiedzieć, że operacja się udała, ale pacjent zmarł. Klawiatura jest i wygląda i działa dobrze, ale nie da się jej używać. Dorsch 40k i 48k Minął rok. Spotkanie klawiaturowe nie odbyło się z powodu plagi, ale naszła mnie ochota ponownego eksperymentowania z klawiaturami. Zniechęcony flądrą postanowiłem jednak ograniczyć ryzyko i zrobić małą klawiaturę — mając mniejszą płytkę i mało przełączników będzie tańsza. Pogodziłem się już z używaniem kupnej klawiatury na co dzień i to miał być bardziej eksperyment. Chciałem mianowicie zobaczyć jak wygodna będzie klawiatura z zaledwie 40-ma klawiszami, ale używająca niektórych klawiszy w podwójnych rolach. Pomysł był taki, żeby na przykład przy naciśnięciu i puszczeniu klawisza wysyłać Esc, ale przy przytrzymaniu i naciśnięciu jednocześnie innego klawisza traktować to jak Ctrl... Klawiaturę nazwałem Dorsch kontynuując nazewnictwo płasko-rybne. Zacząłem oczywiście od zaprojektowania układu klawiszy. Zmienił się on potem kilka razy w miarę jak używałem klawiatury, więc zamieszczę tutaj wersję ostateczną: Dolne legendy mówią jak klawisz działa gdy się go przytrzyma, górne co gdy się go wciśnie normalnie, a te po prawej co jak z klawiszem Fn. Zamówiłem 40 przełączników i zestaw klawiszy, zaprojektowałem i zamówiłem płytkę — ponownie użyłem SAMD21. Wszystko przyszło po dwóch tygodniach, więc zmontowałem i zacząłem testować: Pierwsze zdziwienie: tego się nawet da używać! Ręce trochę uciekają do backspace-a w złym miejscu i do esc, ale po jednym dniu udało się pokonać odruchy. Drugie zdziwienie — ja piszę poprawnie wszystkimi palcami! Jak to, przecież nigdy się tego nie mogłem nauczyć! Czyżby fakt, że klawisze są w prostych kolumnach i nie ma gdzie przesuwać rąk to spowodował? Po używaniu tej klawiatury jako głównej przez tydzień stwierdziłem, że jest bliska ideału, ale jednak to jeszcze nie to. W międzyczasie ktoś na Twitterze zauważył, że taka klawiatura, ale z efektami świetlnymi programowalnymi w CircuitPythonie byłaby fajna. Zaprojektowałem i zamówiłem zatem jeszcze dwie płytki (i jeszcze jeden zestaw przełączników): Pierwsza to to samo, tylko z LED-ami RGB pod każdym klawiszem. W zasadzie nuda, tylko strasznie ciężko było polutować APA102 w opakowaniach QFN, dużo poprawiania zanim wszystkie zaświeciły. Biblioteki do animacji Adafruit ma gotowe, więc nawet mi się po zmontowaniu nie chciało tego programować. Jest ten sam kod co na oryginalnej klawiaturze, z której zresztą przełożyłem przełączniki. Druga natomiast to jest to, na czym piszę ten artykuł. Z ilości tekstu możecie się zapewne domyślić, że bardzo mi pasuje. Dwie dodatkowe kolumny pozwoliły umieścić backspace, tab, enter i esc na ich prawowitych miejscach, a drugi klawisz przełączający warstwy zapewnia dużo wygodniejszy dostęp do symboli. Stabilizator pod spacją sobie odpuściłem, choć może kiedyś zrobię jakiś ze spinacza znowu i przylutuję go na górze płytki tym razem, ale klawisz jest na tyle mały, że nie jest to konieczne. Turbot Pomyślelibyście, że po tym wszystkim będę wreszcie zaspokojony klawiaturowo. Ale okazuje się, że sukces zachęca do dalszego działania i eksperymentów. Nie chcąc chwilowo wydawać więcej pieniędzy na kolejne przełączniki postanowiłem, że skoro flądra nie działa jak należy, to szkoda trochę żeby tak leżała — wylutuję z niej te nieszczęsne przełączniki i spróbuję zbudować coś ciekawszego. Usiadłem do tego na poważnie, konsultując się na klawiaturowych forach z ludźmi z doświadczeniem i popełniłem taki projekt: Tym razem mamy do czynienia z klawiaturą w pełni ergonomiczną, złamaną na środku, ale nadal z 65% klawiszy, bez warstw (no, chyba, że do F1-F12). Klawisze w kolumnach, kolumny poprzesuwane zgodnie z długością i zasięgiem palców. Zrobiłem do tego płytkę: Tym razem od razu zakładam stabilizatory ze spinaczy, ale na górze płytki, więc dół ma być płaski. Odstępy między klawiszami takie jak mają być. Płytka powinna przyjść za tydzień, to napiszę co wyszło...
  2. 10 punktów
    Jako fan klawiatur z makrami chciałbym podzielić się z Wami kolejnym projektem. Zaczęło się od małej klawiatury, o której wpis powstał na blogu, a tu już 3 klawiatura (w tym 2 na ESP32). Główną motywacją jest upraszczanie rozbudowanych skrótów klawiszowych, zastąpienie skrótów fikuśnym układem klawiszy oraz automatyzacja powtarzalnych czynności (niewykrywalny bot w grach?). Klawiatura ESP32 V1 Pierwsze podejście do klawiatury na ESP32 było dość udane. Dość... bo klawiatura była niezbyt praktyczna, acz jak na samoróbkę bardzo ładnie wykonana. Brakowało jej jedynie wieczka z czymś do klikania. Składając całość z kawałków HIPSu stwierdziłem, że wieczko to taki banał że wydrukuję w 3D... i tak wydrukowałem że niebyło jak tego przymocować. W końcu zniechęciłem się i projekt poszedł do szuflady. Upakowanie całkiem udane, zwłaszcza że nie ma tu dedykowanej płytki. Co więcej da się to rozebrać i ani grama hot glue! Klawiatura ESP32 V2 Do kolejnego projektu zabrałem się nieco lepiej. Założenia są takie: przyciski mechaniczne i zwykłe, różne rozmieszczenia (żeby czymś się wyróżniały), przyciski mają być duże, nie jak w pierwszej wersji, wzór dla "gejmerów", żeby był WSAD i co tam gejmer potrzebuje do klikania, wyświetlacz i menu do zmiany trybów, zasilanie USB C / akumulator. Wyświetlacz jest o tyle ważna, że używam różne programy (Corel, przeglądarka, Eagle, Fusion 360, TexWorks) i fajnie by było mieć coś do każdego, idealnie byłoby gdyby przy zmianie trybów coś działo się z przyciskami ale ostatecznie skończy się na wypaleniu w drewnie jakiś ślaczków jako wzorki przycisków. To jednak musi poczekać, najpierw elektronika i program. I tak powstał projekt płytki w programie Eagle, częściowo bazując na inżynierii odwrotna ESP32 dev module. Układ zasilania Myślę że za wyjątkiem walorów estetycznych jakiekolwiek powyżej widać, lepiej będzie obejrzeć schemat. Zacznijmy od zasilania, które pochodzi z 2 źródeł: USB C używanego do programowania i ładowania, akumulatora litowo polimerowego. Tu blok dotyczący USB: Złącze USB C oporządzone zgodnie ze sztuką, do tego transile żeby nie groziły przepięcia (to raczej wodotrysk ale niech będzie) i tu pierwsza gafa... zamieniłem D + z D- co odkryłem dopiero, gdy polutowana płytka nie chciała pogadać z komputerem. Wiec pierwsze 2 poprawki zagościły na płytce. Po prawej stronie widnieje typowy układ z dev modułów CP2101 zmontowany w konfiguracji zasilania z zewnętrznego źródła 3,3V. Więcej na ten temat można znaleźć we wpisie na temat układu CP2101/2, który dodałem jakiś czas temu. Z ciekawszych sygnałów mamy tu RX/TX służące do programowania, oraz DTR i RTS służące do wyzwalania programowania. Mamy tu też sygnał USB_5V (jest to nieco zbite 5V pochodzące z USB, które służy do aktywowania układu komunikacyjnego. Jest to potrzebne gdyż 3,3V będzie trafiać na układ cały czas, a ma on działać tylko przy podłączeniu po kablu (przy zasilaniu z akumulatora układ powinien być wyłączony). Widnieje tu też bardzo ważny sygnał, a zarazem zasilanie - VBUS. Jest to istotny sygnał przy przełączaniu źródła zasilania widoczny w kolejnym bloku: Tu widać diodę sygnalizującą zasilanie z USB (przy zasilaniu z baterii, gdzie VBUS wisi w powietrzu nie świeci). Widać też moduł ładowarki podpięty do VBUS. Chyba najciekawszą częścią elektroniczną jest fragment, w którym następuje przełączenie źródła zasilania. Jest to jeden z tematów często poruszanych przez początkujących walczących z Arduino UNO, które ma 2 opcje zasilania. W tym przypadku sposób sterowania jest prostszy: Przy podłączeniu zasilania przez USB na VBUS jest około 5V, trafia to na bramkę tranzystora Q1 odcinając akumulator, prąd dostarczany jest przez diodę shottkyego D1. Tu nie do końca pomyślałem, bo dioda BAT60J ma dość małą moc, raptem 310 mW, więc przy spadku napięcia około 0,3V to 100 mA to dość mało. Ale z drugiej strony pobór prądu nie powinien być tu zbyt wysoki. Gdy odetnie się zasilanie z USB to bramka ściągana jest do masy i podawane jest zasilanie z baterii. Tu widać drobną rozbieżność w wydajności źródeł zasilania, tranzystor AO4459 jest w stanie udźwignąć 3W. Dobierałem go jednak głównie po to by dało się go łatwo wysterować z niskich napięć i napięcie progowe VGSth przy znikomym prądzie drenu to jedynie 1,9V. Dalej prąd trafia na rezystor pomiarowy żeby móc pomierzyć pobór prądu. Wynik jest mierzony przez komparator w układzie różnicowym. Prąd trafia też na regulator napięć MCP170. Dygresja o regulatorach Jakiś czas temu miałem możliwość przetestować sporo regulatorów LDO 3,3V i 5V. Przyznam że do tamtego momentu obierałem 3 drogi: jak chce 5V to LM7805, jak chce 3,3V to LM1117, jak coś innego to pewnie przetwornica impulsowa. Zaś temat regulatora w zasilaniu bateryjnym wiał grozą. A tu okazuje się, że niekoniecznie... Przeanalizowałem kilka modeli patrząc na parametry: napięcia zasilania, maksymalny prąd wyjściowy, prąd w stanie spoczynku (Quiescent Current). I gdy wziąłem układ LDO LM1117, który często widnieje na płytkach ESP to szło się złapać za głowę... Układ ten ma koszmarnie wielki prąd spoczynkowy! Wieje grozą... wielkie miliampery! Oczywiście zależy co chcemy zbudować, ale do zasilania bateryjnego nie polecam... Regulator MCP170 Tak więc moja perełka czyli układ MCP170 posiada takie cudne parametry: 2 uA prądu spoczynkowego to już coś dodając do tego bardzo oszczędne tryby pracy ESP32 to można śmiało uznać to za coś co nada się do zasilania z akumulatora. Oczywiście taki układ musi mieć wadę, no i jest - max prąd raptem 250 mA, ale... po co większy? No może do tego bloku: ale postaram się nie robić z klawiatury lampy dyskotekowej. Ktoś zapyta po co te LEDy? A to się później przyda jak będę robił obudowę mam nadzieję, że się przyda, bo obudowa jest na razie tylko w wyobraźni. Jest tu zatem wąskie gardło dla tranzystora Q1 i wyzwanie dla diody D1, która nie jest w stanie przepuścić prądu 250mA. Więc albo ją wymienię na coś większego albo będę dbał o to żeby nie przekroczyć prądu 100mA. Wydaje mi się, że podmianka jest lepszym pomysłem, bo może to byc jakakolwiek dioda, nawet 0,7 krzemowa, gdyż zapas napięcia jest dość duży. LDO wymaga zapasu jedynie 625 mA przy max poborze prądu 250 mA więc spokojnie 5V da radę wyciągnąć na 3,3V. Matryca przycisków Dalej to co w klawiaturze najważniejsze - matryca! Układ zwyczajny, tylko jest drobny mix przycisków. Część to bezgłośne przyciski Cherry, inne to zwykłe duże i małe Omrony. Układ sterowania I ostatni bloczek - widać tu wszystkie sygnały wyciagnięte z ESP32 (wszystkie dostępne piny są przewidziane do użycia. Jest tu listwa 4 pinów dla małego OLEDa 128x32 px, który ma służyć do informowania o wybranym układzie makr/programie: Widać tu też typowy układ 2 tranzystorów i przycisków służących do sterowania przebiegiem programowania. Taki układ znajdziemy na płytkach dev module i jest on domyślnie ustawiony podczas wgrywania przy użyciu esptool.py. Wątpliwości może budzić te coś z komparatorem... co to w ogóle jest? Historia zaczyna się od próby znalezienia układu z 1 komparatorem... wiecie że ciężko taki znaleźć? Za to z 2 jest pełno. Ale zostawić taki komparator to szkoda więc postanowiłem zaprojektować dość eksperymentalnie jakiś generator. Nie mam z nimi doświadczenia ale wygląda jakby miał działać. Ale jakby nie działał to otoczyłem go zworkami żeby odciąć en eksperyment i użyć zwykłego LEDa w formie wskaźnika. Do czego będzie to jeszcze się zobaczy, najpewniej będzie wskazywał stan parowania BT. Ciekawe jaki jest pobór prądu... o tym nie pomyślałem. Płytka PCB i montaż Kilkanaście dni czekania i otrzymałem śliczne płytki: Kilka testów i jak zawsze jestem w szoku gdy coś idealnie pasuje jak te przyciski Cherry i Omrony... żeby wszystko tak pasowało jak te przyciski: Tu się Pan Chińczyk się nie popisał (albo Pan projektant-płytkarz) bo na płytce została wyfrezowana miedź pod nóżki złącza, ale już nie laminat. Nie wiem czy nie mieli tak cienkich frezów, ale złącze to wylutowałem z modułu ładowarki do akumulatora i tam jakoś to wyfrezowali i przylutowali. No mniejsza, działa to najważniejsze. Testy Jak myślicie czy projekt ruszył po zlutowaniu? Oczywiście że nie! polutowanie układu CP2101 to niemałe wyzwanie ale w końcu udało się. Programowanie jednak nie powiodło się - komputer wykrywa coś ale nie rozpoznaje. I tu wyszedł mój błąd - zamienione linie D+ i D-. Szybka poprawka i komputer już coś rozpoznaje, ale... nie da się zaprogramować Kilka testów i ustaliłem, że ESP32 działa! Ale CP2101 nie reaguje na test echa ze zwartymi RX i TX... to nie dobrze. Na plus to że USB C działa i tu nic nie mieszam. Czyli chyba jednak upaliłem ten konwerter... Na tym koniec tej części. Stanąłem teraz przed małym murem (nazwijmy płotkiem) - bo ESP32 da się zaprogramować ale z osobnego układu CP2101 na płytce konwertera i teraz pytanie czy usmażyłem układ podczas lutowania? Chyba tak... Plany W najbliższym czasie mam zamiar przelutować układ CP2101 na nowy wyglądający na bardziej markowy (obecny pochodzi z wylutu i nie ma żadnego nadruku). Jeżeli wszystko będzie się ładnie programować to ruszam z klawiszami i obudową. Tu moja wizja jest następująca - sklejka, naturalne drewno i odlewana żywica w miejscu LEDów. W podobnym stylu robiłem jeden projekt, wiec jest szansa na coś ładnego ale tu nie obiecuję cudów na kiju, jak będzie coś nowego to o tym opowiem. Nie wiem jednak jak zrobić krzyżykowe mocowania klawiszy. Mam w głowie pomysł na przyciski - drewniane kołki z miedzianymi obręczami... ale czy nie będą za ciężkie? Potestuję i opiszę niebawem A i wypadałoby jakoś to nazwać... z wymyślaniem nazw zawsze jest problem, bo jak ma się kojarzyć? Ale to może wyjdzie w międzyczasie. Ostatecznie jak przybędzie kabelków i poprawek będzie śmiało można nazwać "MAKaROn". Stan na dzień 16.10.2020 Poprawki w układzie komunikacyjnym Zgodnie z zapowiedzią przelutowałem układ CP2102, tu miałem wątpliwość czynie wpakuję się znowu w maliny. Płytki ESPx są wyposażone w taki układ tylko wygląda jak od Chińczyka pracującego od godziny 16... brak nadruku. Dlatego dla pewności wziąłem układ który działał rewelacyjnie przy testach i po przelutowaniu tak pozostało. Wszystko ładnie się programuje, ESP32 wchodzi w reset zgodnie z założeniami. I też słuszny wniosek - opalarka z regulowaną temperaturą niekoniecznie nadaje się do lutowania, jakikolwiek Hot Air jest lepszym pomysłem.
  3. 8 punktów
    Witam wszystkich! Około rok temu, w oczekiwaniu na coroczny konkurs techniczny organizowany w mojej szkole postanowiłem wykonać robotyczne ramię sterowanie kontrolerem w formie rękawicy. Ramię miało powtarzać ruchy dłoni oraz nadgarstka w czasie rzeczywistym. Głównym celem było stworzenie działającego prototypu dzięki któremu zwiększę swoją wiedzę w dziedzinie elektroniki, robotyki oraz programowania. Ramię Projektowanie Zabrałem się więc za projekt. Na samym początku rysowałem oraz testowałem różne konstrukcje przekazania momentu do odpowiednich stawów aż zdecydowałem się na linki w pancerzach. W mojej opinii jest to najlepsze rozwiązanie w konstrukcjach amatorskich z ograniczonym budżetem. Serwomechanizmy TowerPro SG90 wymieszane ze swoimi klonami, plecionka wędkarska 0.23mm, oraz wężyki silikonowe 3mm/1mm powinny załatwić sprawę. Powrót określonej części palca realizowany za pomocą gumek recepturek . Przeszedłem więc do programu fusion 360 i tak prezentują się efekty mojej pracy. Składanie Po otrzymaniu przesyłki z serwami od naszych wschodnich kolegów przystąpiłem do drukowania poszczególnych części projektu. Wszystkie elementy drukowałem na delikatnie zmodyfikowanym enderze 3 z PLA ora PETG. Serwa zostały przykręcone oraz przyklejone na klej cyjanoakrylowy. następnie przystąpiłem do przedziewania wężyków silikonowych i podklejania linek do odpowiedniej części dłoni. Szybko okazało się że wężyk, który zamówiłem kompletnie nie nadaje się do takiego zastosowania ze względu na duże tarcie oraz małą sztywność powodującą ściskanie się wężyka zamiast zginania palca w odpowiedzi na ciągnięcie linki przez serwo. Dlatego aby konstrukcja działała chociaż trochę lepiej owinąłem wszystkie wężyki koszulkami termokurczliwymi co w większości pozwoliło pozbyć się problemu ściskania. Jednakże dodało to dodatkowy milimetr średnicy każdemu z nich. Coś za coś. Zostało tylko dodać gumki i cała konstrukcja mechaniczna skończona. Kontroler Jako czujniki zgięcia zastosowałem potencjometry. Początkowo miały to być zwyczajne montażowe jednak niezliczone wady tego rozwiązania ujawniły się natychmiast po złożeniu pierwszego prototypu. W poszukiwaniu innej opcji trafiłem w Internecie na podobną konstrukcję również wykorzystującą potencjometry jednakże z otworem umożliwiającym przedzianie przez nie wału. Zakupiłem więc wystarczającą ilość sztuk i podczas oczekiwania na przesyłkę zaprojektowałem naprędce projekt drugiej rękawicy który okazał się finalnym. Dodatkowo do podłączenia potencjometrów użyłem wyjątkowo giętkich przewodów odpornych na wielokrotne zginanie( skrętka nie poradziła sobie w tej roli). Elektronika Mózgiem całego układu jest atmega 8 , otoczona elementami pasywnymi niezbędnymi do jej właściwego działania oraz do właściwego działania przetwornika ADC. Płytkę zaprojektowałem w programie Eagle, a wykonałem na zrobionym samodzielnie ploterze wykorzystując czarny pisak permanentny laminat zamiast kartki. Po kąpieli w wytrawiaczu płytka była gotowa do montażu. Oczywiście nie obyło się bez błędów wynikających z mojego małego doświadczenia oraz zwyczajnej nieuwagi. Drugim niezwykle ważnym układem był multiplekser 16 kanałowy wykonany z trzech multiplekserów 8 kanałowych. Takie rozwiązanie było zdecydowanie tańsze oraz niemiałem żadnych problemów z dostępnością części. Ponownie odpaliłem Eagle-a i w ruch ruszył mój ploter. Pierwsza płytka wykonana na elementach SMD okazała się całkowitą porażką natomiast druga na THT wyszła dokładnie tak jak powinna. Starałem się aby w całej części elektronicznej projektu jak najmniej elementów było lutowane "na stałe". Dlatego używałem złączek IDC, ARC oraz oczywiście goldpinów. Dzięki temu całość uzyskała budowę modułową niezwykle ułatwiającą przenoszenie oraz wszelakie naprawy. Program Program został napisany w języku C na mikrokontrolery AVR w środowisku Eclipse. Gdyby nie książka: " Mikrokontrolery AVR - podstawy programowania" Pana Mirosława Kardasia nie sądzę aby udało by mi się nauczyć się programować AVR-y oraz napisać mój program w tak krótkim czasie. Program jest niezwykle prosty. Co 20 ms czyli z częstotliwością odświeżania właściwą dla serw SG90 przestawiane są multipleksery za pomocą odpowiednich bitów, a wartość odczytana z potencjometru przez przetwornik ADC jest zamieniana funkcją map()( przekopiowaną z biblioteki arduino) na wartości odpowiadające odpowiedniemu wypełnieniu sygnału PWM. Dzieje się to ze względu na właściwość użytych przeze mnie serwomechanizmów. Przy odpowiedniej wartości wypełnienia PWM przyjmują one odpowiednią pozycję( w moim przypadku 0 stopni to około 1ms wypełnienia natomiast 180 stopni to około 2ms wypełnienia). Następnie 16 programowo generowanych kanałów PWM przyjmuje przekonwertowane dane i wysyła je złączem IDC na serwomechanizmy. Lista części: Serwomechanizmy SG90(klony + oryginalne) - ok. 80zł Plecionka, wężyk + rurka termokurczliwa- ok. 60zł Potencjometry APC ( z otworem ) - ok.20 zł Atmega 8 , złączki, elementy pasywne- ok.30zł Multipleksery CD4051BE - ok.6 zł Koszty druku( filament + prąd)- ok.40zł Wady: Konstrukcja zawiera ich bardzo wiele : mała sztywność całego układu złe wężyki ( zbyt wiotkie oraz zbyt grube) nieoryginalne serwa mające ogromne problemy właściwie ze wszystkim nieprzemyślana konstrukcja dłoni (zbyt wiele kleju zbyt mało połączeń rozłącznych) gumki zamiast sprężyn jako powrót po ściśnięciu brak prawidłowej filtracji zasilania!!! niedziałający nadgarstek(spowodowany przez: brak pinów na mikrokontrolerze, brak czasu , za słabe serwa , zbyt mało miejsca na prawidłowe działanie, nieprzemyślana budowa itp. Podsumowanie Jestem niezwykle zadowolony z całokształtu mojej pracy. Mimo wielu błędów( a raczej dzięki nim) nauczyłem się bardzo bardzo wiele. Od programowania, projektowania, trochę mechaniki oraz wiele więcej. Jeśli mógłbym doradzić coś osobą początkującym takim jak ja chcącym wykonać podobną konstrukcję to: proszę was kupcie oryginalne serwa! Mimo ich 3 razy większego kosztu działają nieporównywalnie lepiej do chińskich odpowiedników a ich właściwości także są o wiele lepsze. Na swoim przykładzie przekonałem się że niema czegoś takiego jak za trudny projekt jest tylko za mało czasu i pieniędzy. Wszystkiego da się nauczyć w trakcie pracy jednakże będzie to skutkować błędami tak jak w moim przypadku. Bogatszy w doświadczenie zacząłem już tworzyć drugi projekt ręki , która to min. będzie realizowała ruch palców w bok. Pozdrawiam wszystkich serdecznie i dziękuję za uwagę!
  4. 6 punktów
    Sprzęt Lubię stary sprzęt, nie tylko komputerowy. Zdobyłem starą tarczę telefoniczną, wyczyściłem styki i uformowałem różne elementy które się pogięły, a następnie postanowiłem zrobić z tego klawiaturę. Przykleiłem na spodzie tarczy Seeeduino Xiao (taśmą dwustronną), wylutowałem oryginalny sznur i dodałem trzy przewody, starając się zresztą użyć tych samych kolorów, które były tam oryginalnie, chociaż wątpię czy jest na to jakiś ustalony standard. Sprzęt nie był wygodny do trzymania i łatwo było przypadkowo palcem zablokować mechanizm, więc złożyłem małe pudełko ze sklejki. (Na wszelki wypadek wyjaśnię jak się używa takiej tarczy. Żeby wybrać jakąś cyfrę, wkłada się palec w odpowiednią dziurę w tarczy, a następnie obraca tarczę w kierunku ruchu wskazówek zegara aż do momentu gdy palec zatrzyma się na tej metalowej blaszce. Tarcza, puszczona, wraca do położenia początkowego, w międzyczasie wykręcając numer w trybie pulsowym, czyli rozwierając i zwierając przewody, którymi telefon połączony jest z centralą.) Oprogramowanie Ustaliłem eksperymentalnie (z pomocą mojej pokazywaczki Hantek, która do tego celu była w sam raz) jakie sygnały nadaje tarcza. Otóż normalnie pin czerwony nie jest zwarty z żółtym, ale jeśli tarcza jest przynajmniej trochę obrócona, to się zwierają. Natomiast pin zielony jest normalnie zwarty z czerwonym, natomiast w czasie gdy tarcza się cofa, to to coś na wierzchu tej mniejszej zębatki rozwiera je i zwiera. Tych "pulsów" jest mianowicie tyle, z jakiej cyfry tarcza wraca (10 dla cyfry 0). Odczytanie wybranej na tarczy cyfry jest więc dość proste, na przykład tak: void setup() { pinMode(PIN_YELLOW,INPUT_PULLUP); pinMode(PIN_GREEN,INPUT_PULLUP); pinMode(PIN_RED,OUTPUT); digitalWrite(PIN_RED,LOW); } void dialledDigit(int d){ // Cyfra wybrana } void loop() { if(digitalRead(PIN_YELLOW)==LOW){ int p=0; byte prevG=LOW; delay(20); while(digitalRead(PIN_YELLOW)==LOW){ byte g=digitalRead(PIN_GREEN); if(g>prevG) p++; prevG=g; digitalWrite(LED_BUILTIN,!g); delay(10); } digitalWrite(LED_BUILTIN,HIGH); if(p) dialledDigit(p%10); } delay(5); } Najprostsze co można dalej zrobić, to użyć funkcji z Keyboard.h i wysyłać wybrane cyfry, ale taka klawiatura potrafi wpisywać tylko cyfry, a to trochę mało. Dlatego doimplementowałem tryb ASCII, który działa tak, że wybiera się kolejne cyfry kodu ASCII znaku, który chce się wpisać. Czyli żeby napisać 'A' (=65), trzeba wybrać 6 a potem 5. Większość kodów dwucyfrowych łatwo odróżnić od trzycyfrowych - wiadomo, że 65 nie jest początkiem trzycyfrowej liczby, bo maksymalna wartość kodu to 255. Natomiast kody poniżej 26 trzeba poprzedzić zerem. To jednak nadal za mało, bo chciałem również móc przytrzymywać klawisze, na przykład do tego, żeby pisać polskie litery z prawym altem, a także do innych operacji na przykład na tekście. Dlatego dodałem jeszcze następujące funkcje: Kod poprzedzony przez 00 oznacza, że klawisz należy przytrzymać. Gdy później wybrany zostanie dowolny kod bez 00, to ten klawisz zostanie puszczony. Kod poprzedzony przez 0000 oznacza, że klawisz należy przytrzymać, i trzymać tak długo, aż ponownie zostanie wybrany jego kod. Tryby zmienia się generując większą niż 10 liczbę pulsów. Żeby to osiągnąć, należy naciągnąć tarczę, potem pozwolić jej się cofnąć, ale tylko częściowo, i naciągnąć ponownie. W ten sposób liczba pulsów w czasie, gdy pin czerwony jest zwarty z żółtym, może być dowolnie duża. Efekt (oglądać z włączonymi napisami!): Łatwiej mi było nagrać klawiaturę podłączoną do telefonu niż do komputera, działa oczywiście tak samo. Można też oczywiście użyć tarczy do... wybierania numeru, wystarczy uruchomić aplikację telefonu Możliwe zastosowania projektu No cóż... Jak się można domyślić, ta klawiatura nie jest specjalnie ergonomiczna i nie ma prawdziwego zastosowania. Natomiast można by było wykorzystać taką tarczę jako część większego projektu, na przykład zamka szyfrowego.
  5. 5 punktów
    Od dłuższego czasu chciałem stworzyć działającego robota Micromouse, a jednocześnie chciałem nauczyć się obsługiwać inne mikrokontrolery niż Arduino. Idealna okazja spełnienia obu tych rzeczy nadeszła gdy wszedłem w posiadanie płytki STM32F429I-DISC1. Tak o to rozpocząłem projekt o zaskakującej nazwie "Micromouse Robot". KONSTRUKCJA ROBOTA Komponenty, które postanowiłem wykorzystać w robocie to: Mikrokontroler STM32F429I-DISC1 Czujniki odległości (odbiciowe) skonstruowane z pary: dioda IR SFH4550 i fototranzystor SFH-313FA Silniki DC FIT0450 wraz z enkoderami magnetycznymi SJ01 Sterownik silników L298N Moduł bluetooth HC-06 Koła DFRobot Na samym początku zaplanowałem ogólny schemat robota: Na podstawie schematu ogólnego stworzyłem schemat elektroniczny przy użyciu programu KiCad: Następnie przyszedł czas na zlutowanie potrzebnych układów, w pierwszej kolejności był to moduł z czujnikami - zdecydowałem się na prostopadłe rozstawienie czujników, dwie pary wykrywające przeszkody po bokach oraz dwie pary wykrywające ścianę na wprost dzięki czemu możliwe będzie wykorzystanie ich odczytów do korekcji orientacji robota (oba przednie czujniki powinny odczytywać tą samą odległość od ściany). Dodatkowo zlutowałem pomocniczy układ z przełącznikiem i stabilizatorem step-down (gdyż zasilanie, którego użyłem dochodziło do 8V przy pełnym naładowaniu, a płytka potrzebowała 5V). Dzięki niemu miałem łatwy dostęp do pinów 5V lub 8V w zależności od potrzeby: W celu sprawdzenia działania stworzonego modułu czujników wykonałem testy przy użyciu programu STMStudio, które pozwoliło na łatwą wizualizację odczytów mikrokontrolera. Przeprowadzone testy potwierdziły poprawne działanie każdego z 4 czujników (niższa wartość oznacza przewodzenie fototranzystora w diodzie odbiorczej, tym samym sygnalizując, odbiór światła wysłanego przez diodę IR i odbitego od białej ściany - w skrócie, wykrycie przeszkody przez dany czujnik): Niestety w tym momencie okazało się, że pomieszczenie wszystkich elementów wraz z utrzymaniem sensownych rozmiarów robota będzie niemożliwe, dlatego po wykonaniu wielu pomiarów powstał model 3D przyszłej konstrukcji, na którego podstawie stworzona została rzeczywista konstrukcja stworzona z wyciętej płyty ebonitowej oraz drucianych podpór: Jak widać dzięki wymyślnej konstrukcji udało się pomieścić wszystkie elementy. Nadszedł czas na programowanie. OPROGRAMOWANIE ROBOTA Ze względu, że użyta płytka należała do rodziny STM32 to do pomocy w programowaniu użyłem środowiska STM32CubeIDE. Ponieważ jak już pisałem, była to moja pierwsza styczność z płytką inną niż Arduino, to bardzo pomocny okazał się Kurs STM32 F4 ze strony Forbota. Końcowo wykorzystałem: 4 piny ADC w celu odczytywania wartości z czujników odległości, 2 piny PWM w trybie countera w celu odczytywania wartości z enkoderów silników, 4 piny PWM do sterowania silnikami, oraz 2 piny USART w celu komunikacji z modułem bluetooth. Schemat blokowy przyszłego programu robota wygląda następująco: W tym momencie głównym zadaniem stało się zaimplementowanie najważniejszych funkcji, czyli: przeszukania labiryntu, znalezienia najkrótszej ścieżki i jej przejechania. Również w tym przypadku Forbot nie zawiódł i poratował mnie artykułem Roboty MicroMouse – 5 metod przeszukiwania labiryntu. To właśnie on skłonił mnie do wykorzystania metody propagacji fali. Wzorując się na przykładach z artykułu udało mi się stworzyć własną wersję algorytmu. W międzyczasie stworzyłem funkcje odpowiedzialne za ruch robota w przestrzeni. Odpowiednie przechowywanie aktualnej pozycji (x, y) oraz orientacji robota (północ, południe, zachód, wschód) pozwoliło na proste zaimplementowanie funkcji typu jedz(kierunek), która pozwalała na nawigację po labiryncie jak gdybyśmy patrzyli na niego z góry i zadawali, w którym kierunku ma przemieścić się robot. Dzięki temu możliwe stało się stworzenie symulacji, która pozwalałaby na przetestowanie działania zaimplementowanego algorytmu i funkcji ruchu. Tak też zrobiłem: Jak widać funkcje ruchu pozwalają na przemieszczanie się po poszczególnych polach labiryntu, natomiast algorytm bez problemu znajduje najkrótszą ścieżkę do celu. Przyszedł czas na rzeczywiste testy. W tym celu używając wyciętych kartonów oraz białych kartek A4 złożyłem własny labirynt (na zdjęciu jeszcze bez kartek), niestety ze względu na ograniczoną przestrzeń składał się on tylko z 4x4 pól, jednak nie był to zbyt duży problem, gdyż algorytm zdołał już udowodnić symulacyjnie, że działa także dla pełnowymiarowego labiryntu. Kolejnym wyzwaniem było zaprogramowanie ruchu robota po labiryncie. Z pomocą przyszły enkodery silników oraz czujniki na podstawie których napisałem proste regulatory PD. Pierwszy z nich używając enkoderów gwarantuje, że dystans pokonany przez oba silniki jest stały, natomiast drugi używający czujników zapewnia równy odstęp robota od wszystkich ścian labiryntu. Ich połączenie zapewnia sprawne przemieszczanie się robota po kolejnych polach labiryntu. PODSUMOWANIE Ostatecznemu wynikowi daleko do idealnych. Robot jest dosyć powolny i czasami gubi trasę - myślę, że jest to spowodowane w pewnym stopni jego wagą i wielkością użytych silników, co w połączeniu skutkuje brakiem możliwości wykonywania małych i precyzyjnych ruchów. Dodatkowo brakuje tu wielu usprawnień funkcji ruchu, np. nie zatrzymywanie się na każdym polu jeśli jedziemy prosto kilka razy z rządu. Pomimo to myślę, że robot wcale nie wypada tak źle jak na pierwszy tak duży projekt, przecież jednak jeździ i ma się dobrze. Dodatkowo ilości nowej wiedzy którą zdobyłem podczas jego tworzenia nie da się zastąpić. Ogólnie jestem zadowolony z efektu oraz całego projektu, jednak także świadomy jego niedoskonałości i możliwości poprawy w miarę zdobycia nowej wiedzy. Efekt końcowy (przeszukiwanie labiryntu oraz przejazd najkrótszą ścieżką przyspieszone prawie 5-krotnie) można obejrzeć na filmiku:
  6. 4 punkty
    Chciałem podzielić się z wami jak powstała moja mała instalacja fotowoltaiczna oraz przedstawić system monitorowania. Ale od początku, aby móc zasilać wszystkie urządzenia w mojej domowej serwerowni konieczna była modyfikacja zasilania tak aby wszystkie sprzęty były zasilane z jednego źródła. Postanowiłem postawić na instalację 24V z przetwornicami stepdown do 12V. Dlaczego 24V a nie 12V? mniejsze prądy pakiet 7s ogniw 18650 w pełni pokrywa się z zakresem napięć akumulatorów kwasowych/żelowych więc można wykorzystać standardowy/tani kontroler do paneli PV możliwość zbudowania taniej baterii z ogniw 18650 niektóre urządzenia w mojej serwerowni były przystosowane już do napięcia 24V teraz kilka suchych danych: ilość paneli PV 3 szt. moc paneli 3x180Wp szacowana pojemność baterii 100Ah pobór mocy urządzeń dzień 80W, w nocy 100W - spowodowane tym że działa tam również monitoring więc podczerwień w kamerach pobiera w nocy 20W czyli jakieś 0,8A więcej. Instalacja w lato uruchamia się około godziny 8 ładuje baterie i na bieżąco zużywa energię z słońca, po zachodzie słońca całość pracuje do godziny 7-8 następnego dnia. Czyli w pogodne dni letnie 24h mogę pracować z energii słonecznej. Gdy akumulatory rozładują się do napięcia 21.2V sterownik odcina zasilanie, a wszystkie urządzenia zaczynają pracować z zasilacza, na którym mam ustawione napięcie 20V. Przełączanie jeśli tak to można nazwać zrealizowane jest na 2 diodach. Przedstawię ilość urządzeń które zasilam bo jest tego dość sporo: Switch DES-3028 Mikrotik 750GR3 Mikrotik 750R2 AP Tp-link 1043ND AP Ubnt Bullet M2 5 szt ESP8266 - przeznaczenie różne od sterownika pieca do sterowania bramą wjazdową Raspberry Pi NAS Zyxel NSA310 rejestrator Dahua 8 kamer Stacja meteo na Arduino Nano Nazbierało się tego dość sporo. Jak już wspomniałem energię gromadzę w 4 pakietach z ogniw 18650. Dwa z nich to pakiety 7s7p, jeden 7s14p oraz jeden 6s6p. Dlaczego tak, niestety przy samych pakietach 7s zdarzało się że przy głębokim rozładowaniu BMSy odłączały pakiety. Niestety mój sterownik z automatycznym wyborem napięcia akumulatorów następnego dnia włączał się z ustawieniami 12V. Aby temu zapobiec zbudowałem pakiet 6s, gdzie zakres pracy takiego pakietu to od 16.8V od 25.2V. Teraz wszyscy złapią się za głowę i powiedzą to co ten słynny kot na memie (Andrzej to .... ) Spokojnie tak wiem 7s to zakres od 19.6V do 29.4V. BMS w pakiecie 6s bardzo dobrze pilnuje aby nie przeładować ogniw, powyżej maksymalnego napięcia pakiet jest odłączany i w tym momencie ładowane są tylko pakiety 7s. Przewidziałem również prowizoryczny “system gaśniczy”, składający się z kuli gaśniczej, która podczas kontaktu z ogniem rozpyla 1.3 kg proszku. Wszystko zamknięte jest w szafie rack 5U, więc w razie pożaru kula powinna sobie poradzić. Opis jak są zbudowane moje baterie znajdziecie w osobnym poście bo ta historia jest również ciekawa, link tutaj. Jeszcze fotka z montażu skrzyni, jak widać baterie siedzą w dodatkowej skrzynce z grubej blachy. Do monitorowania ilości wytworzonego prądu oraz napięć na akumulatorach wykorzystuję EPS8266 oraz 3 szt. ACS712 podłączone do ADS1115, wszystkie dane zbieram w systemie Domoticz czyli: napięcie na pakietach prąd pakietów prąd wytworzony prąd zużyty licznik produkcji licznik zużycia A przy pomocy Grafany prezentuje je tak: Ważny szczegół, połączenia między ACS712 a ADS1115 warto polutować, bo inaczej mogą występować dziwne wahania prądów. Monitoruje dodatkowo temperaturę pakietów oraz szafy. Temperatura pakietów nie przekracza 30st podczas końcowego etapu ładowania/rozładowywania, a w samej szafie maksymalnie odnotowałem 25st. Jak widać zastosowałem też bezpieczniki 10A na pakiety 7s, 4A na pakiet 6s oraz 16A na panele PV. Cała elektronika zamontowana jest na listwie din a do sterownika dołożyłem z tyłu radiator oraz wentylator który załączany jest termistorem przy 50st. Teraz zapewne omówię najciekawszą sprawę jaka jest opłacalność. Zwrot z inwestycji w same panele, sterownik, bezpieczniki powinien zwrócić się po 24 miesiącach. (tak to wyliczyłem nie pamiętam jak ale chcę w to wierzyć ;) ) Nie liczę tu ceny ogniw bo pochodzą z odzysku i czasu jaki poświęciłem na budowę. Jest jeszcze jeden ważny aspekt, zmniejszyło mi się obciążenie UPSa więc w razie zaniku zasilania cały pozostały sprzęt w domu popracuje dłużej. Oprócz tej mini instalacji PV mam też instalacje z inwerterem 5.5kW, więc tą instalacje traktuję jako ciekawostkę. Jeszcze bym zapomniał, jeśli znajdą się zainteresowani kodem źródłowym to chętnie udostępnię, tylko jak zawsze muszę znaleźć czas aby go posprzątać i porobić komentarze
  7. 4 punkty
    Pisałem już o mojej małej instalacji PV lecz budowę samych pakietów ogniw opiszę w osobo, ponieważ jest to temat ciekawy, a moje doświadczenia myślę że przydają się kolejnym osobom. Całość podzieliłem na kilka etapów: 1. Testowanie ogniw Ogniwa które wykorzystuję w moich projektach pochodzą z starych baterii laptopowych. Ciekawostka! stare baterie można podzielić na: Całkiem niezdatne do użytku. 1/3 ogniw w baterii jest uszkodzona. Wszystkie ogniwa są w doskonałej kondycji bo uszkodzeniu uległa elektronika. Cały proces dzielę kilka etapów. pierwszy polega na naładowaniu wszystkich zdobytych ogniw. Następnie leżakują one sobie przez tydzień. Kolejny krok to pomiary napięć, jeśli jakieś ogniwo w ciągu tygodnia rozładuje się poniżej 4V, nie nadaje się ono do użytku. Resztę ogniw wkładam do ładowarki i mierzę ich pojemności. Ładowanie oraz testy należy wykonywać z prądem minimum 700mA, do tego celu przyda się taka ładowarka do ogniw, jeśli któreś z ogniw będzie się bardzo grzać podczas ładowania, też eliminuje je to do dalszej pracy. Zmierzone pojemności ogniw zapisuję na nich. 2. Uchwyt Do wykonania uchwytu można wykorzystać gotowe uchwyty do 18650 które łączymy ze sobą, lub jeśli posiadacie drukarkę 3D wydrukować, projektów na thingiverse jest mnóstwo ja używam tego https://www.thingiverse.com/thing:666162 Niestety nie zawsze wszystko wychodzi podczas druku, ale nie ma co się zniechęcać, warto grzać stół cały czas tak aby boki wydruku się nie odklejały bo może wyjść makaron 3. Projektowanie pakietu W tym punkcie przydatna jest strona https://www.repackr.com/ wpisujemy na niej wszystkie pojemności ogniw które posiadamy następnie wybieramy pakiet 7s7p i strona oblicza nam które ogniwa mamy ze sobą połączyć. 4. Lutowanie Po ułożeniu ogniw w uchwytach przechodzimy do lutowania, tutaj przyda się odpowiednio duży grot, tak aby punktowo zagrzać miejsce i nie męczyć całego ogniwa. Ja łącze ogniwa drucikami z skrętki komputerowej kat 5E (powinny zadziałać jak bezpiecznik gdyby któreś z ogniw spowodowałoby zwarcie), a te druciki lutuję do żyły o przekroju 2,5mm. 5. Podłączamy BMS Niestety BMS'y 7s nie należą do najtańszych, ja używam takich o prądzie maksymalnym 20A, przetestowałem do tej porty 2 rozdaje i obydwa sprawują się tak samo. 6. Testy Dla testu przed zalepieniem pakietu taśmą kaptonową rozładowuje go obciążeniem 5A, i sprawdzam czy któreś z ogniw jednak się nie grzeje, narazie niestety robię to metodą dotykową, tutaj przydałaby się jakaś kamera termowizyjna. Podczas rozładowywania podłączam też miernik napięcia do pakietów pozwala mi on obserwować czy wszystkie serie ogniw rozładowywują się jednakowo. 7. Na koniec zalepiamy pakiet taśmą kaptonową tak aby nie spowodował zwarcia, można też użyć odpowiednio dużej koszulki termokurczliwej. Takiego rodzaju ogniw używam w: w mini instalacji PV (kilka pakietów pakietów 7s7p i 6s6p) jako podtrzymanie alarmu (pakiet 3s6p) do awaryjnego otwierania bramy wjazdowej (7s4p) - tutaj ciekawostka pakiet działa już 3 lata bez serwisowania, gdzie aku żelowe padły po pierwszym roku użytkowania. jako zasilanie do mojej kamery foto-pułapki (3s4p)
  8. 4 punkty
    Cześć, jakiś czas temu opisywałem na forum moją próbę podłączenia prostej kamery CMOS o rozdzielczości VGA do zestawu FPGA Artix-7 (OV7670). Tutaj jest link: Chociaż kamera miała rozdzielczość tylko VGA (640x480 16-bit kolor) to do utworzenia frame-buffor'a (bufor jednej ramki obrazu) potrzebny był relatywnie "duży" układ FPGA (w tym przypadku chip FPGA: XC7A100T-2FGG677i). Było to spowodowane faktem iż projekt tworzył bufor obrazu w wewnętrznej pamięci "Block RAM" zawartej w chipie FPGA. Niestety zestawy FPGA z takimi "dużymi" chipami FPGA są dużo droższe. Dużo zestawów FPGA (tanich) ma obecnie "na pokładzie" jakiś układ scalony z zewnętrzną pamięcią RAM, jednak przeważnie jest to pamięć DDR RAM (dynamiczna pamięć RAM), która ma dużo wyższe czasy dostępu i wymaga cykli odświeżania. Sterowniki takich pamięci są mocno skomplikowane, dlatego pomyślałem aby utworzyć frame-buffer (bufor obrazu) w statycznej pamięci SRAM, ponieważ sterownik do takiej pamięci jest dużo prostszy (płytka z zewnętrznym scalakiem podłączona do zestawu FPGA). Docelowo chciałbym użyć pamięci SRAM o organizacji 2Mega x 16-bit i czasie dostępu 10 ns o symbolu IS61WV204816BLL-10TLI -patrz link: https://www.digikey.pl/products/en/integrated-circuits-ics/memory/774?k=&pkeyword=&sv=0&pv142=188516&pv142=188519&pv2042=74127&pv2042=87441&pv2042=103394&pv2042=143502&pv2042=159094&pv2192=u10ns&pv2192=u12ns&pv2192=u15ns&pv2192=u20ns&pv2192=u25ns&pv1291=165794&pv1291=165833&pv1291=165834&pv1291=226104&pv1291=240848&pv1291=242592&pv1291=68821&pv1291=69617&sf=1&FV=961|390622%2C961|407300%2C-8|774&quantity=&ColumnSort=0&page=1&stock=1&datasheet=1&pageSize=25 Taka pamięć pozwala utworzyć bufor obrazu o rozdzielczości 1600x1200 i 16-nasto bitowym kolorze (z przeplotem). Umożliwia to podłączenie takiego sensora CMOS (OV2640) - patrz link: https://www.banggood.com/XD-95-OV2640-Camera-Module-200W-Pixel-STM32F4-Driver-Support-JPEG-Output-p-1403106.html?rmmds=myorder&cur_warehouse=CN Jednak taka duża kostka pamięci z przesyłką kosztuje około 100 PLN, dlatego zdecydowałem, że pierwszą próbę podłączenia zewnętrznej pamięci SRAM do zestawu FPGA przeprowadzę z dużo mniejszą kostką pamięci SRAM o organizacji 256Kx16-bit. Mo wybór padł na układ scalony SRAM o symbolu: CY7C1041CV33-10ZSXI ponieważ mam dwie takie kostki "w szufladzie" (kupione kilka lat temu).Tutaj jest link do data-shit'a pamięci CY7C1041CV33: https://datasheet.octopart.com/CY7C1041DV33-10ZSXI-Cypress-Semiconductor-datasheet-17703221.pdf Co prawda te kostki na dzień dzisiejszy są już "obsolete", ale ciągle są w sprzedaży ich nowsze wersje o symbolu:727-CY7C1041G10ZSXIT (takie same wyprowadzenia i bardzo zbliżone parametry) - kosztują aktualnie około 25 PLN za jeden scalak. Tutaj link do tego produktu: https://pl.mouser.com/ProductDetail/Cypress-Semiconductor/CY7C1041G-10ZSXIT?qs=%2Fha2pyFaduh0yemDg4h8iPRcd6uZg6jBuQMJjKFwlztWmTNJRjtfFg%3D%3D , a tututaj data-sheet: https://pl.mouser.com/datasheet/2/100/cypress_semiconductor_cypr-s-a0005492749-1-1734674.pdf Bufor obrazu na pamięci SRAM CY7C1041CV33-10ZSXI pozwalał by na wyświetlanie obrazu o rozdzielczości 640x480 16-bit kolor (z przeplotem). Postanowiłem więc narysować schemat ideowy takiej płytki zewnętrznej PCB z buforem obrazu. Oto ten schemat: Schematic_CY7C1041_SRAM-Cpy_2020-10-17_17-58-53.pdf W ciągu kilku najbliższych dni zamierzam zaprojektować płytkę drukowaną i dokonać jej podłączenia do zestawu FPGA. Znalazłem nawet kod sterownika pamięci SRAM CY7C1041CV33-10ZSXI napisany w języku VHDL udostepniony przez firmę "Cypress" (producenta pamięci), ale zawiera on nie-syntetyzowalne konstrukcje (bardziej wygląda na kod do symulacji takiego sterownika). Kod ten na pewno będzie pomocny w napisaniu sterownika tej pamięci. Tutaj link do tego kodu: https://www.cypress.com/documentation/models/cy7c1041dv33-vhdl Przykładowe sterowniki pamięci SRAM są dobrze opisane w darmowej książce pt. "FPGA Prototyping by VHDL Examples: Xilinx Spartan™‐3 Version" napisanej przez doktora Pong P. Chu. Tutaj link do tej książki: https://misp.mui.ac.ir/sites/misp.mui.ac.ir/files/ebooksclub.org__FPGA_Prototyping_by_VHDL_Examples__Xilinx_Spartan_3_Version.pdf Jak będę miał jakieś rezultaty, będę pisał w tym wątku. Zapomniałbym pod tym linkiem jest całkiem fajny artykuł dot. pamięci SRAM w połączeniu z FPGA: https://www.hackster.io/salvador-canas/a-practical-introduction-to-sram-memories-using-an-fpga-i-3f3992 Pozdrawiam
  9. 4 punkty
    'C:\Users\PRZEMY~1\AppData\Local\Temp\arduino_build_946990\core\core.a'; reason: Permission denied Masz polskie literki w nazwie użytkownika i to dezorientuje Arduino pod Windowsem.
  10. 4 punkty
    Cześć @badbit Problemem jest to, że podajesz obiektowi QSerialPort (device) niepoprawny numer portu, podajesz: COM5 Arduino Uno a trzeba: COM5 Na początku tego nie zauważyłem (ale o tym zaraz) i specjalnie uruchomiłem u mnie Twój kod (tylko nie chciało mi się robić całego programu, więc spreparowałem tyle ile mogłem) i podałem z palca "COMx" (za x odpowiedni numer) - wszystko ok bez błędów. Jak podałem inny numer niż ma płytka przypisany przez system, to dostałem takie same błędy: QSerialPort::NoError QSerialPort::DeviceNotFoundError Problematyczna linia kodu to: QString portName = ui->comboBoxDevices->currentText().split("\t").first(); Robisz split gdzie jako delimiter bierzesz "\t" tylko... nie masz tego taba w tym co splitujesz, więc split zwraca to co się mu przekazało czyli: COM5 Arduino Uno Wystarczy zamienić delimiter z "\t" na " " (spację), czyli: QString portName = ui->comboBoxDevices->currentText().split(" ").first(); // albo QString portName = ui->comboBoxDevices->currentText().split(' ').first(); Gdybyśmy ten kod napisali lepiej - czyli podział na mniejsze metody i napisali testy jednostkowe to wykrylibyśmy to na samym początku.
  11. 4 punkty
    Mały update dla Dorsch 40k — miałem dziś luźniejszy dzień, więc naprawiłem te 6 LEDów, które miały inne kolory (uszkodzona jedna dioda) i zaprogramowałem prosty efekt przy naciskaniu klawisza: Taka zabawka.
  12. 4 punkty
    I od przyzwyczajeń. Ja np. jako pianista opanowałem klawiaturę chromatyczną w akordeonie (tzw. "guzikówka") w ciągu paru godzin (tzn. nie to że zagrałem jak jaki wiertołaz, ale wiedziałem gdzie jest jaka nuta i palce już się same układały). Natomiast do dziś nie potrafię zagrać na zwykłym akordeonie (inny rozmiar klawiszy).
  13. 4 punkty
    Cześć, chciałbym opisać w tym poście implementację wyżej opisywanej gry "Breakout" (Arkanoid) na zestawie FPGA "Sipeed Tang Nano" z układem FPGA chińskiej firmy "Gowin Semiconductors Corp.". Płytka ta jest dostępna w sklepie "Botland.com.pl" za niecałe 40 PLN. Tutaj link do zestawu: https://botland.com.pl/pl/moduly-i-zestawy-fpga/15813-sipeed-tang-nano-plytka-rozwojowa-fpga-gw1n-1.html Piszę o tym dlatego ponieważ dla wielu osób zakup zestawu FPGA nawet za kwotę 178 PLN (tyle na dzień dzisiejszy kosztuje zestaw Elbert v.2) może być problemem "nie do przeskoczenia" (szczególnie dotyczy to młodych osób, które jeszcze nie pracują). Chciałem pokazać, że tani zestaw FPGA "Sipedd Tang Nano" ma możliwości pozwalające użyć go w ciekawych projektach. Więc do rzeczy: najpierw kilka przydatnych linków: 1) Link do "pinout'u" i tutoriali: https://tangnano.sipeed.com/en/ 2) Link do "GitHub'a": https://github.com/andrsmllr/tang_nano_devbrd 3) Tutaj link do bloga kolegi Rafała Bartoszaka opisujący "pierwsze uruchomienie" płytki "Sipeed Tang Nano": https://rafal-bartoszak.blogspot.com/2020/09/tang-nano-pierwsze-uruchomienie.html 4) Tutaj link także do "szybkiego startu" z tą płytką (bardziej szczegółowy - z niego pozyskałem informacje dot. plików "user constraint files"): https://bananatronics.org/first-steps-with-the-tang-nano-fpga-development-board/ Tak gra "Breakout" wygląda na monitorze VGA podłączonym za pomocą kabla VGA do płytki "Tang Nano" (DAC VGA zbudowany z 12 rezystorów na płytce prototypowej - patrz posty powyżej): A tak wygląda zestaw FPGA "Tang Nano" na płytce prototypowej (widać sterownik VGA na dodatkowej zielonej płytce) podłączony do monitora VGA: Jak już pisałem wcześniej dla płytki FPGA "Tang Nano" jest środowisko do syntezy "Gowin EDA". Ja używam wersji "1.9.3.031 Beta" dla Windows 10 (o licencję poprosiłem firmę Gowin i ją otrzymałem, ale w archiwach w sieci dot. płytki "Tang Nano" jest gdzieś do pobrania plik licencji): Odnośnie samego projektu FPGA: w stosunku do wersji dla Xilinxa (Elbert V.2) trzeba było zmienić: 1) IPCore pętli PLL z formatu Xilnxa na format IPCore Gowin (zegar płytki ma 24 MHz) 2) Plik "user constraints" - "breakout.cst" ma mocno odmienny format od takich plików dla narzędzi firmy Xilinx Główny moduł projektu "breakout.v" wygląda teraz następująco: module breakout( input clk24, //24MHz crystal external input rota, input rotb, input de, output red, output green, output blue, output hsync, output vsync ); wire clk50; wire clkInBuf, clkOut; reg clk25; // Instantiate the module PLL-Clock Gowin_rPLL Clock24MHz( .clkout(clk50), //output clkout .clkin(clk24) //input clkin ); always @(posedge clk50) begin clk25 <= ~clk25; end wire [9:0] xpos; wire [9:0] ypos; signal_generator signal_generator_inst(clk25, hsync, vsync, xpos, ypos); game game_inst(clk25, xpos, ypos, ~rota, ~rotb, ~de, red, green, blue); endmodule Inne pliki źródłowe projektu (Verilog) zostają bez zmian. Do stworzenia pliku "user constraints" "breakout.cst" (mapowanie fizycznych pinów zestawu FPGA) korzystałem częściowo z pomocy narzędzia "FloorPlaner" (Menu: Tools->Floorplaner) - patrz lik: Na początku wyjścia sterownika VGA miałem na pinach trzydzieści klilka (patrz pinaout), ale te piny miały domyślnie przypisane inne działanie a ja nie umiałem w IDE tego wyłączyć. Tutaj ktoś opisał identyczny problem, jaki ja napotkałem: https://en.bbs.sipeed.com/t/topic/1801funkcji Nie udało mi się wyłączyć tych domyślnych funkcji pinów, więc przeniosłem te piny na niższe numery i jest OK. Docelowo "breakout.cst" wygląda tak: /Copyright (C)2014-2020 Gowin Semiconductor Corporation. //All rights reserved. //File Title: Physical Constraints file //GOWIN Version: V1.9.3.01Beta //Part Number: GW1N-LV1QN48C6/I5 //Created Time: Thu 10 01 15:28:00 2020 IO_LOC "clk24" 35; IO_PORT "clk24" IO_TYPE=LVCMOS33 PULL_MODE=NONE; IO_LOC "rota" 14; IO_PORT "rota" IO_TYPE=LVCMOS33; IO_LOC "rotb" 15; IO_PORT "rotb" IO_TYPE=LVCMOS33; IO_LOC "de" 20; IO_PORT "de" IO_TYPE=LVCMOS33; IO_LOC "red" 24; IO_PORT "red" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=12; IO_LOC "green" 21; IO_PORT "green" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=12; IO_LOC "blue" 19; IO_PORT "blue" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=12; IO_LOC "hsync" 22; IO_PORT "hsync" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=12; IO_LOC "vsync" 23; IO_PORT "vsync" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=12; Środowisko do syntezy "Gowin EDA" jest bardzo proste i szybkie (synteza zajmuje bardzo mało czasu). Projekt po syntezie zajmuje mało zasobów fizycznych FPGA: 1) 678 LUTs 2) 177 rejestrów 3) 1 pętla PLL (zegar) Zrzut ekranu: Programowanie zestawu FPGA odbywa się ze środowiska "Gowin EDA" poprzez kabel USB C (nie trzeba zewnętrznego programatora JTAG). Patrz zrzut ekranu: Poniżej zamieszczam pełny projekt gry dla "Gowin EDA" (zestaw "Sipeed Tang Nano"):pełen projekt FPGATang_Breakout.zip Jak widać pełen projekt po spakowaniu ma zaledwie 76 KB - jest to znacznie mniej niż dla projektu gry dla "ISE 14.7" Xilinx'a (829 KB). Zapomniałem dodać: do sterowania paletką użyte są dwa przyciski (dolna część zestawu FPGA Tang Nano). Pozdrawiam
  14. 4 punkty
    No więc płytka do Turbota przyszła i wygląda dobrze: Trafiła mi się bardziej pomarańczowa soldermaska, co mi się podoba. Przy żółtych płytkach to zawsze trochę loteria jest. W każdym razie zacząłem od elektroniki, żeby w razie czego było łatwiej poprawiać drucikami: Po wgraniu CircuitPythona i sprawdzeniu, że wszystko działa, wlutowałem przełączniki i wstawiłem klawisze i gotowe. Brakuje czterech klawiszy, bo ta klawiatura ma ich więcej niż poprzednia, a dodatkowe jeszcze nie doszły, co nie powinno być przeszkodą w przetestowaniu jak taki układ działa. Nie robiłem już stabilizatorów, bo po zaprogramowaniu klawiatury i testach okazało się, że ma jeden poważny feler. Obawiam się, że te przełączniki są przeklęte. Ogólnie rzecz biorąc, układ jest dobry. Do wszystkich klawiszy sięga się z minimalnym ruchem ręki, nie ma żadnych problemów z nie trafianiem. Gdybym miał coś poprawić, to zbliżył bym klawisze trochę poziomo — zacząłem od standardowych odstępów 0.75" i pochyliłem kolumny, co je nieco zwiększyło w niektórych miejscach. Gdybym je trochę zbliżył, niektóre by były dalej a inne bliżej, ale średnio byłyby bliżej standardu. W każdym razie jest to drobiazg, układ klawiatury działa. Co nie działa, to przełączniki. Tak jak ze zwykłymi choc switches nigdy nie miałem problemu, tak te są straszne. Mają dwa główne problemy: po pierwsze, naciśnięcie klawisza choć trochę nie na środku powoduje, że się haczą. Wrażenie jest jak przy tanich membranowych klawiaturach. Po drugie, i to jest bardziej istotne, kliknięcie jest bardzo mocno oddalone od kontaktu. O co mi chodzi? Otóż tego typu przełączniki mają w środku dwa osobne mechanizmy: Po lewej stronie jest tak zwany "click bar", czyli mechanizm służący do generowania tego satysfakcjonującego kliknięcia (albo tylko zmiany oporu, w zależności od rodzaju klawisza). Po prawej mamy właściwe styki. W nocie katalogowej naszego przełącznika możemy znaleźć następujący wykres pokazujący zależność wymaganej siły nacisku od drogi klawisza: Zaznaczone mamy tam trzy istotne punkty: "pressure point" to moment, w którym słyszymy kliknięcie, "operating point" to kiedy styki się zwierają, a "reset point" to kiedy się rozwierają. Niestety albo ja dostałem wybrakowane egzemplarze, albo je jakimś cudem zepsułem, bo w moich przełącznikach "operating point" znajduje się na samym końcu drogi klawisza, przy maksymalnym jego wciśnięciu. W praktyce oznacza to, że piszemy sobie z zadowoleniem na klawiaturze, słyszymy kliknięcia, a pojawia się jedna literka na dziesięć. Niezwykle irytujące. Nie wiem czy mogę coś na to poradzić, chyba wypada się pogodzić z faktem, że pieniądze na te przełączniki wydane są wyrzucone w błoto i dalsze inwestowanie w ten projekt nie ma sensu. Ktoś na forum klawiaturowym zasugerował, że mógłbym z przełączników pousuwać te mechanizmy klikające, miałbym wtedy liniową klawiaturę, ale boję się, że nadal dość mocno trzeba by wciskać klawisze. Na razie projekt odkładam na półkę i zajmę się mniejszą ergonomiczną klawiaturą z innymi przełącznikami, o której napiszę osobno.
  15. 3 punkty
    Dzień dobry serdecznie wszystkim! Zachęcony na wykopie przez Forbota zdecydowałem się podzielić swoim projektem, który bazowo miał służyć tylko mi jako On Board Computer do mojego starego BMW E36. Projekt jednak się rozwinął i obecnie jest pełnoprawnym urządzeniem/development boardem bazującym na ESP32. O urządzeniu dokładniej można poczytać na stronie Logger.Sorek.uk - na tej stronie będą też pojawiać się nowości w firmware/hardware gdyż jego development wciąż trwa! Z czego jest zbudowany? Ekran 2.8" TFT ILIi9341 (bardzo podobny do tego) z dotykiem i 65k kolorami (z opcją na założenie dowolnego innego ekranu), Port OBDII, CAN i K-line (ISO 9141), Obsługa kart SD do 32GB, 4 analogowe 0-5V inputy (np. do czujnika sony szerokopasmowej AFR), USB-C, i dlatego iż używam ESP32 mamy też: Bluetooth, Wifi oraz 2 porty serial - jeden do komunikacji z K-line drugi do USB (3 można używać bez ekranu). Warto nadmienić, że dzięki zastosowaniu chipu FTDI oraz demuxera seriala, urządzenie można używać (po przełączeniu pinu w programie urządzenia) bezpośrednio USB <-> K-line dzięki temu jest 100% kompatybilność z programami diagnostycznymi do samochodów i programatorami ECU. Co daje nam k-line? Prędkość przesyłu OBDII typu ELM327 jest bardzo niska. Przy k-line przy bazowej prędkości 9600 możemy osiągnąć 8-20 Hz (w porównaniu do 0.2-1 Hz w wypadku ELMa) a jeśli mamy odpowiednie ECU np. nowsze MS42/MS43 (które możemy znaleźć w takich autach jak BMW E46, E38 czy E39) nawet dochodzącą do 33 Hz! Do daje niesamowitą rozdzielczość. Natomiast komendy typu "telegram" pozwalają wybrać nam jakie elementy chcemy loggować czy retransmitować po CAN. Urządzenie jest w pełni konfigurowalne i firmware z którym go sprzedaje posiada takie funkcje jak konfigurowalne definicje, retransmisje CAN, logi do karty SD, autosleep, autolog na triggerze (np. gdy obroty silnika lub przepustnica przekroczy odpowiednią wartość), oraz Gui które stworzyłem na bazie bibliotek tft_eSPI oraz lvgl. Do urządzenia stworzyłem bibliotekę DS2.h która współpracuje z Arduino. Dzięki temu programowanie na urządzenie jest proste. Przykłady w bibliotece stworzyłem tak, by każdy mógł się połapać o co chodzi i część przykładów ma wgrany OTA update prosto z karty SD. Wystarczy wrzucić plik update.bin na kartę SD, odpalić urządzenie i można wrócić do oryginalnej wersji Firmware - które to wersje również wypuszczam dla wszystkich kupujących urządzenie. Oczywiście przy własnym programowaniu urządzenia możliwości są nieskończone! Jak obecnie wygląda i działa urządzenie można zobaczyć poniżej: Projekt płytki wraz ze stabilizatorami 5V i 3.3V stworzyłem wraz z pomocą bardziej doświadczonych kolegów. Wcześniej urządzenie działało na Arduino i wyglądało zupełnie inaczej! Cena urządzenia to obecnie £100 lub £130 z obudową. W cenie wliczony jest support - powiem tylko że sporo nocy spędziłem na pomoc klientom z Australii i USA by pomóc w integracji Firmware z urządzeniami typu RaceCapture lub JB4! Przykłady zastosowania jako CAN sniffer/transmitter po serialu: Zapraszam do komentarzy!
  16. 3 punkty
    Procek spokojnie się wyrobi i będzie miał jeszcze czas na to, żeby pospać (o ile do rysowania wykresów zmusisz klienta, a nie serwer - czyli przeglądarkę). Pytanie: czy taka ilość zapisów nie zarżnie karty - MySQL (jak zresztą wszystkie systemy baz danych) lubią sobie popisać po dysku... Mi przy podobnej ilości zapisów karta wytrzymała jakieś pół roku...
  17. 3 punkty
    Wg google Twój dysk jest 2,5 calowy czyli od 0.7 do 3 watów + RPi 3b+ od 1.9-2.1 wata czyli czy zestaw będzie ciągną 3-5 watów. Przy założeniu że będzie pracował 24/7/360 to daje 8760 godzin (8760 x 3) / 1000 = 26,28 kW rocznie (8760 x 5) / 1000 = 43.8 kW rocznie i teraz zależy w dużej mierze gdzie mieszkasz - załóżmy że w warszawie i masz dostawcę prądu innogy który sprzedaje po 0,70zł za kWh 26,28 x 0,70 = 18,39 43.8 x 0,70 = 30.66 Czyli całkowity koszt będzie w granicach 20-30zł rok przy założeniu że żyjesz w stolicy, ale sam musisz sprawdzić ostatnią fakturę za prąd i cenę kWh u swojego dostawcy.
  18. 3 punkty
    @KHX dokładnie tak jak pisze @wn2001 (i jak wspomniane jest we wpisie). To jest ciekawa płytka, ale głównie dla deweloperów. Szczególnie, że np. niektóre konfiguracje są dostępne dopiero dla zamówień od 200 szt. Jeśli chcesz zacząć przygodę z RPi to wybierz Raspberry Pi 4 model B - to jedyna sensowna wersja do nauki, jeśli dopiero planujesz start
  19. 3 punkty
    @KHX Jesteś pewien? To jest moduł dla deweloperów i osób, które chciałyby możliwości RPi wykorzystać we własnym urządzeniu, w seryjnej produkcji... Do zastosowań hobbystycznych "zwykłe" RPi jest nieporównywalnie lepsze (i w końcowym rozrachunku tańsze)...
  20. 3 punkty
    W związku z akcją "Opisz elektroniczne DIY i odbierz 50 zł rabatu do Botland" uruchamiam temat, w którym należy zgłaszać swoje projekty. W postach proszę wstawiać linki do swoich projektów oraz ewentualną informację, że to pierwszy z kilku Waszych projektów i chcecie otrzymać połączony rabat na koniec. Jeśli przy danym poście pojawi się moja reakcja (serce) tzn., że projekt jest zaakceptowany i bierze udział w tej akcji rabatowej. Szczegóły na temat akcji »
  21. 3 punkty
    @astony Sketch ---> Export compiled binary lub Ctrl+Alt+S.
  22. 3 punkty
    Nie napisałeś do czego to w ogóle ma być, bo możesz celować w 0.1°C (bezwzględnej dokładności) w jakichś eksperymentach chemicznych czy biologicznych a w innym przypadku nawet +/-2°C jest wystarczające. A jeśli robisz coś naprawdę "prostego", to żadne z tych równań się nie przyda, bo nawet znając współczynniki tego czy innego równania musisz zmierzyć offset tej konkretnej sztuki termistora więc tak czy tak musisz zbudować układ i mieć wzorzec. A jeśli już masz system pomiarowy, to kalibrujesz go do tego wzorca w jednym-dwóch-trzech punktach, dopasowujesz odcinek lub dwa prostej i tyle. Oczywiście, jeśli jest to jednostkowe wykonanie to możesz bawić się w wielopunktowe kalibracje i/lub w liczenie na Arduino logarytmów czy równań wykładniczych, ale to strzelanie do wróbla z armaty. A nawet najładniejsze wzory bez choćby jednorazowego potwierdzenia (i zapamiętania współczynników np. w EPROMie) ze wzorcem są nic nie warte. Jeśli nie dysponujesz możliwością kalibracji z interesującą Cię dokładnością, to od razu kupujesz czujnik droższy, ale porzynajmniej z gwarantowaną przez producenta wielkością błędu mieszczącą się z założeniach. Przykładowo bardzo wygodny i tani MCP9700 bazuje na technologii bandgap (must-to-know jeśli bawisz się pomiarami temperatur itp), oddaje napięcie analogowe +10mV/°C, które możesz zmierzyć swoim ADC bez żadnych elementów dodatkowych i ma błąd +/-2°C w całkiem sporym zakresie. Jeśli skalibrujesz go choćby w jednym punkcie (woda z lodem, 0°C), spokojnie dostajesz lepiej niż +/-1°C. W najprostszym przypadku jeden taki czujnik zabiera jedno wejście analogowe, ale w Arduino masz ich co najmniej kilka więc nie jest to wielki koszt. W zasadzie największym kłopotem z czujnikami temperatury jest raczej wybór interfejsu. Od najprostszego, czyli termistora - gdzie musisz jednak coś co procesora dospawać (a jeśli chcesz być przecyzyjny to może jakieś źródło prądowe), poprzez diody krzemowe (stałe -2mV/°C), termopary, czujniki z wyjściem analogowym (MCP9700, LM35 itp) do czujników oddających gotowy wynik w postaci cyfrowej przez 1-wire (kultowe DS1820), SPI (AD7314) czy I2C (MCP9800). Do wyboru do koloru. Linear (obecnie Analog Dev.) robił kiedyś taką wielokanałową maszynerię z gwarantowaną dokładnością +/-0.1°C działającą z termoparami lub termistorami 2-, 3- i 4-przewodowymi, ze współczynnikami kalibracyjnymi (no, musisz je podać) itp, ale to spory układ był. LTC2984 czy jakoś tak. Generalnie warto zajrzeć co jest produkowane, bo asortyment hobbystycznych poradników do Arduino zamyka się niestety w dwóch-trzech typach elementów powielanych setki razy w kolejnych "odkrywczych" projektach. Są nawet gotowe termostaty, TMP01 czy AD22105 od AD - żeby daleko nie szukać. https://www.tme.eu/pl/details/ad22105arz/przetworniki-temperatury/analog-devices/
  23. 3 punkty
    do zarządzania gitem można też skorzystać z https://www.sourcetreeapp.com/ , posiada prosty interfejs i jest darmowe Załóżmy, że masz już sklonowane repozytorium. Robisz zmiany w kodzie. Gdy zmiany są gotowe możesz poprzez konsolę zcommitować, a następnie zpushować kod. Możesz też użyć interfejsu wbudowanego w IDE, jeżeli ma taką opcje (a większość popularnych ma). Dobrą praktyką jest też pracować nad nowymi zmianami na innej gałęzi, i dopiero potem po weryfikacji (tzw. code review) przez innych programistów, mergujesz swoją gałąź do głównej.
  24. 3 punkty
    ArduinoDroid to jednak nie jest Arduino IDE. Ten projekt wygląda bardzo interesująco, ale trzeba pamiętać, że to tylko ulepiona przez kogoś aplikacja - nie ma wsparcia społeczności Arduino, ani samej firmy. Nie jest to może koniecznie złe, ale na pewno nie będzie działało tak od razu i bez problemów. Próbowałem zainstalować ArduinoDroida jakiś czas temu i wtedy było to moim zdaniem zupełnie nieużywalne narzędzie. Poza tym do pełnej funkcjonalności może wymagać praw root-a na tablecie, a wszelkie problemy sporej wiedzy o systemie Anrdoid. Według mnie to rozwiązanie absolutnie nie pasujące do początkującego użytkownika. Jeśli miałbym coś doradzać, to znacznie łatwiej rozpocząć przygodę z Arduino kupując używanego laptopa i instalując na nim "prawdzie" Arduino IDE. Można też użyć Raspberry, ale to już może być nieco trudniejsze. Natomiast jeśli jednak autor wątku jest na tyle odważny, żeby iść w ArduinoDroid-a, to proponuję po prostu kupić moduł z ESP8266 i programować po WiFi. W sieci są do tego tutoriale, nie ma problemu z kabelkami, czy interfejsem USB, a jeśli coś pójdzie bardzo źle to spali się ESP8266 a nie tablet.
  25. 3 punkty
    Cześć @mikowal91, bezpośrednio nie jestem w stanie Ci pomóc, "bawiłem" się jedynie nieco przykładami z PyImageSearch też na RPi, ale pisany w Pythonie Rozumiem, że kod zaprezentowany powyżej działa bez problemu i ładnie zaznacza kontury? Jeśli tak, to musisz jedynie wykorzystać te dwie wymienione funkcje, udało znaleźć mi się fragment z obliczaniem powierzchni pola tutaj: https://stackoverflow.com/questions/11631533/calculate-the-area-of-an-object-with-opencv, natomiast tutaj fragmenty kodu dla obu z tych funkcji (ale nie tylko) zarówno C++, ale też Python: https://docs.opencv.org/2.4/modules/imgproc/doc/structural_analysis_and_shape_descriptors.html
  26. 3 punkty
    Pozdrawiam Wszystkich Nawiedzonych (dla miłośników skrótów PWN), mam na imię Janusz i 66 lat, od kilku lat z powodu choroby i późniejszego wypadku jestem sparaliżowany, ale mam sprawne lewe oko i prawą rękę (lewa ręka nie ma precyzji i siły). Do poruszania się używam wózka alektrycznego oraz handbika łączonego ze zwykłym wózkiem inwalidzkim. Po awarii jednego wózka elektrycznego, kupowałem najczęściej używany drugi i dalej mogłem się przemieszczać (na nowy ze względów stosowania zaporowych cen nie było mnie stać). Filozofia ta doprowadziła, że jestem szczęśliwym posiadaczem 1 sprawnego (chwilowo) i 5 (słownie pięciu) niesprawnych różnego typu wózków elektrycznych. Jako inżynier mechanik zamierzałem zrobić z tym jakiś porządek i spróbować je naprawić, ale żeby było ciekawej, to najpierw kupiłem na aukcji, wspomagany elektrycznie uszkodzony handbike Speedy Duo i zabrałem się za jego naprawę. Po 3 miesiącach miałem już go sprawnego i na płaskiej drodze "gnałem" nawet 12 km/h, problemem okazały się nawet stosunkowo łagodne podjazdy, na których przednie koło napędowe traciło przyczepność i kręciło się w miejscu. Postanowiłem, że w moim zwykłym wózku inwalidzkim, jako wspomaganie, zastosuję 24" koła z któregoś uszkodzonego elektryka. Okazało się to niemożliwe, bo wszystkie elektryki miały niesprawne sterowniki i/lub kontrolery. Nie będąc elektrykiem ani tym bardziej elektronikiem, szukałem pomocy na Elektrodzie, niestety bez skutku, po prostu tam, jak tylko przeczytali, że chodzi o naprawę sterownika do wózka inwalidzkiego, to zaczynali wymieniać wszystkie obowiązujące przepisy i normy. Moja znajomość języków programowania, 40 lat temu zakończyła się na ALGOL1204 (co to jest, to mogą powiedzieć Wam, rodzice bądź dziadkowie, ale podstawą, jak nazwa wskazuje, były algorytmy i logika a komputer to Odra1204). Po tym bardzo długim wstępie, napiszę wreszcie " I tu pojawił się Forbot z jego kursami internetowymi i forum, gdzie mam nadzieję znaleźć pomoc w rozwiązaniu moich problemów". Chcę wykorzystać Arduino i sterowanie IR lub WiFi tak jak przy napędzie robotów, ale dopuszczam sterowanie przewodowe. Dzięki Forbotowi przypomniałem już sobie podstawy elektroniki, z lutowaniem sobie radzę bardzo słabo (jednooczność to brak oceny odległości), ale się nie poddaję i próbuję dalej. 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 oraz Bluetooth, jeżeli ktoś zna na to jakiś sposób, to proszę o podpowiedź. Pozdrawiam
  27. 3 punkty
    Jeśli Python i przetwarzanie obrazu to warto się zainteresować OpenCV i serwisem https://www.pyimagesearch.com/
  28. 3 punkty
    1. Żeby mieć rezystor do masy, to musi być "pull down" a nie "pull up". Niestety UNO nie ma takiej funkcjonalności wbudowanej, więc musiałbyś użyć zewnętrznego rezystora, zamiast polegać na wbudowanym. 2. Na każdy, który jest w trybie wejścia, bo jak podasz na wyjściowy, który akurat jest ustawiony na 0, to możesz coś upalić. TX i RX też możesz używać, ale nie będziesz mógł wtedy używać seriala. 3. Nie, inaczej już by to zrobili. Na szczęście AVR jest dość prymitywny i całkiem nieźle znosi znęcanie się nad nim.
  29. 3 punkty
    @kludo Świetnie, że skrypt działa , nawiązując do pytania - tak, oczywiście, zerknij tutaj: https://www.arduino.cc/reference/en/language/variables/data-types/string/functions/toint/ Na początek spróbuj napisać bardzo prosty programn, który wyświetli na SerialPorcie wartość zwracaną przez funkcję dla jakiegoś ciągu nie-liczbowego, np. "aa" czy "a1" - nie pamiętam, czy było to -1, a teraz nie mogę sprawdzić. Z pewnością funkcja nie zwróci nic sensownego, więc wówczas wystarczyć będzie jeden prosty if i mamy zabezpieczenie
  30. 3 punkty
    Wystarczy, że odczepisz tylko czarny kabelek od płytki i wszystko powinno już śmigać. Potencjometr masz w tej chwili podpięty tak: Te prostokąty symbolizują rezystory, które dzielisz przekręcając potencjometr. Gdy przekręcasz go w lewo wszystko działa, diody święcą mocniej, bo zmniejszasz opór tego symbolicznego rezystora po lewej, prawda? Gdy kręcisz nim w prawo zmniejszasz opór rezystora między plusem a minusem, co może prowadzić do sytuacji, że w pewnym momencie tego oporu albo nie będzie wcale (powstaje zwarcie), albo będzie on tak mały, że przepuści zbyt duży prąd, którego potencjometr nie będzie w stanie przyjąć (w obu przypadkach element się spala): Żeby rozwiązać problem wystarczy odpiąć minus od potencjometru i albo zostawić tą jedną nóżkę nie podłączoną nigdzie, albo przenieść plusa na prawo i zewrzeć go z środkową nóżką w ten sposób :
  31. 3 punkty
    Jest jeszcze jedno proste rozwiązanie. Można dać jeden tranzystor, który będzie odcinał zasilanie od wszystkiego poza PIRem. Jak pojawi się ruch to zasilanie mikrokontrolera zostanie załączone i może sobie nawet 50mA brać. Jak już program zrobi co ma zrobić, wyłączy zasilanie i po sprawie. Wtedy można użyć zwykłego Arduino, bez kombinowania usypiania itd.
  32. 3 punkty
    Witam, dziękuję za pomoc @Gieneq ! Krótko opiszę jak poradziłem sobie z problemem. Mój układ zasilam 6 bateriami (ok. 9V), nastepnie pin Vout dostarczam do dwoch połączonych równolegle regulatorów napięcia 5V. Wyprowadzenie z regulatora dostarczam do RPI do pinu 2 na RPI (5v Power). Następnie z innego wyprowadzenia 5v Power z RPI dostarczam napiecie 5V do pinu5V na shieldzie oraz spinam masy. Układ może działać także w drugą stronę, gdy chcę na czas testów dać odpocząć bateriom i zasilać RPI po kablu. Pozdrawiam, Konrad
  33. 3 punkty
    Hmm, jest to cos w rodzaju "karty graficznej" dla procesorów zbyt słabych aby grafikę obsługiwały samodzielnie. Procesor zajmuje się tylko załadowaniem po SPI danych do odpowiednich rejestrów i pamięci obrazu w Spartanie. Spartana można tu porównać do układu ULA w ZX Spectrum, jeśli ktoś to pamięta, tyle tylko jakbyśmy dołożyli jeszcze ULI do środka RAM video i obsługę VGA. Dokładny opis ze źródłami do Arduino i opisem rejestrów jest na stronie autora Jamesa Bowmana https://excamera.com/sphinx/gameduino/. Procesor odciążony wyświetlaniem grafiki może się zajmować np obsługą czujników i klawiatury(peryferiów) i wyświetlając leniwie info na ekranie monitora. Rodzaj procesora nie ma tu znaczenia, aby obsługiwał SPI... Na youtube jest bodajże filmik pokazujący jak Gameduino jest sterowane bezpośrednio ze złącza ZX Spectrum programikiem napisanym w Basic, jeśli mnie pamięć nie myli... a może był to Commodore C64 nie pamiętam...rewelacyjna zabawka dla amatorów programistów/projektantów układów, w przykładach np retro games typu asteroids czy frogger dużo zabawy, a przy okazji można się paru rzeczy nauczyć...
  34. 3 punkty
    Testy: programowanie Arduino Mega i Uno z IDE
  35. 3 punkty
    @Emerid, do tego dokumentacja Nucleo się przyda: (30. strona) https://www.st.com/resource/en/user_manual/dm00105823-stm32-nucleo-64-boards-mb1136-stmicroelectronics.pdf Też tego nie mogłem znaleźć jak zaczynałem
  36. 3 punkty
    Cześć, udało mi się uruchomić projekt gry "Breakout" (opisany powyżej) na bardzo taniej płytce FPGA za 40 PLN - "Sipeed Tang Nano". Patrz linki: https://botland.com.pl/pl/moduly-i-zestawy-fpga/15813-sipeed-tang-nano-plytka-rozwojowa-fpga-gw1n-1.html?search_query=FPGA&results=20 https://www.seeedstudio.com/Sipeed-Tang-Nano-FPGA-board-powered-by-GW1N-1-FPGA-p-4304.html Jest to całkiem fajnie zaprojektowany zestaw FPGA oparty na układzie FPGA "GW1N-1-LV" chińskiej firmy "Gowin Semiconductor Corp.". Ten zestaw FPGA ma ilość zasobów logicznych bardzo zbliżoną do łytki "Elbert V.2": 1152 LUT4 oraz 864 przerzutników. Nie ma co prawda sprzętowych układów mnożących (jak Spartan3 z Elberta), ale w zamian za to ma w układzie FPGA 72 kb pamięci SRAM i 96 kb pamięci flash oraz pamięć PSRAM: 64 Mb. Posiada też 40-to pinowe złącze do wyświetlacza RGB LED - jest do niego dedykowany (5 cali) taki wyświetlacz firmy Sipeed: https://www.seeedstudio.com/5-Inch-Display-for-Sipeed-Tang-Nanno-p-4301.html Software do syntezy i symulacji układu w FPGA jest też produkcji firmy "GOWIN" nazywa się "Gowin EDA"- patrz link: https://www.gowinsemi.com/en/support/home/ Środowisko jest bardzo proste - chwilami przypomina "ISE" Xilinx'a i działa szybko. Projekt udało się przenieść bardzo szybko, trzeba było tylko zmienić IPCore z modułem zegara PLL ze standardu Xilinx'a na standard Gowin IPCore oraz zmienić plik "user constraints" na format tego producenta FPGA. Ponieważ płytka nie ma wyjścia VGA użyłem wersji z kilkoma rezystorami opisanej w tym poście: Projekt działa poprawnie (nie widać różnic w stosunku do wersji na Elbercie). Jak będę miał chwilę czasu to opisze wersję projektu na płytkę ""Sipeed Tang Nano". Pozdrawiam
  37. 3 punkty
    Witam ponownie. W tak zwanym między czasie (brr jak to brzmi), sporo się działo a to kaleczny remoncik, a to choróbsko, ale udało się uszczknąć trochę czasu i oto moje malinowe ciasteczko dorobiło się ubranka. Ubranko oczywiście do poprawy (inaczej nie był bym sobą), ale póki trwa eksperyment to niech tak zostanie. Jak widać na fotkach dwa wentyle i w środku w stres testach max temp. to 40 st. no i cisza. Jak na razie to hula SAMBA, serwer DLNA i Motion testowany do przyszłego monitoringu. Jeszcze czekam na filtr od Pana Chińczyka, a w zasadzie to łuny utknął gdzieś w Polszy i jedzie kulawym wołem i do tego tyłem. Nie działa automatyczne usuwanie starych nagrań z monitoringu i Automatyczny start DLNA, o dziwo restart działa i aktualizuje bazę. Jak to posprzątam to zamieszczę kod może komuś się przyda. Na dziś podaję rysunki obudowy do np. wycinarki laserowej, a nóż ktoś się skusi . PS. Dostęp do Google Drive się robi, a w zasadzie się zrobił tylko niekompletny, za cholerę nie montuje się z automatu. Cierpliwości, tylko cierpliwości. 01-Raspberry Pi dół- do wycięcia-02.pdf 02-Raspberry Pi filtr_zew - do wycięcia-02.pdf 03-Raspberry Pi filtr_wew - do wycięcia-02.pdf 04-Raspberry Pi wentylator - do wycięcia-02.pdf 05-Raspberry Pi bok Karta - do wycięcia-02.pdf 06-Raspberry Pi przód - do wycięcia-02.pdf 07-Raspberry Pi bok złącza - do wycięcia-02.pdf 08-Raspberry Pi góra - do wycięcia-02.pdf
  38. 2 punkty
    Niedługo mam zamiar napisać kolejny opis projektu, który tym razem skupi się właśnie na wykorzystaniu tego wyświetlacza (+ jeszcze bonus ). Podlinkuje tutaj gdy będzie gotowy.
  39. 2 punkty
    Klatka Faradaya to obszar odizolowany od zewnętrznych pól elektrycznych. Do środka mogą wnikać pola magnetyczne oraz fale mechaniczne. Fale elektromagnetyczne (radiowe) zatem do wnętrza się nie dostają (ani wygenerowane wewnątrz nie wychodzą na zewnątrz) bo brakuje im składowej elektrycznej, ale już pole magnetyczne np. od przewodów 50Hz w ścianach przez folię aluminiową spokojnie przechodzi. To samo z dźwiękiem - falą mechaniczną. Oczywiście można sobie wyobrazić klatkę zrobioną z grubej gąbki obitej blachą z miękkiej (magnetycznie) stali. Coś takiego rzeczywiście nie przepuści ani składowej E ani H ani fali akustycznej. O ile nie wypompujesz z wnętrza powietrza - które to jest ośrodkiem rozchodzenia się dźwięku - to spokojnie możesz tam rozmawiać a jeśli Ty coś słyszysz, to mikrofon dyktafonu także to wyłapie. Mam nadzieję, że filmiki tego rodzaju nie są jedynym źródłem Twojej wiedzy o fizyce, bo to zakres kursu na poziomie gimnazjum, o ile się nie mylę.
  40. 2 punkty
    Nie da się znać na wszystkim. Ja z kolei nie wiem co to jest AWS (nie licząc partii politycznej) czy "oprogramowanie klienckie", ale mogę za to ocenić Twoje wysiłki na polu zasilania. Przede wszystkim wychodzisz od zapotrzebowania Twojego odbiornika na energię, liczonego w [Wh] a nie jako czysty prąd w [mA] bo to pierwsze daje całościowy obraz. Czym innym jest dostarczenie 100mA przy 3.3V a czym innym 100mA przy 12V. Zastanawiasz się w jaki sposób najwygodniej (dla całego systemu zasilania) tę energię dostarczyć. Czasem musisz zrobić stabilne 5V a czasem wystarczy cokolwiek od np. 4 do 12V. Pierwsze rozwiązanie wymusza jakąś formę stabilizacji napięcia a drugie daje większą swobodę. Pamiętaj, że każda forma konwersji postaci mocy to koszt (finansowy) i strata (energetyczna). Przykładowo jeśli możesz do odbiornika podłączyć akumulator o zakresie napięć pracy powiedzmy od 6V (rozładowany) do 8.4V (naładowany) to jest to znacznie lepsze rozwiązanie niż dłubanie z tego napięcia sztywnych 5V czego nikt naprawdę nie potrzebuje. Ogniwa słoneczne są bardzo kapryśnym źródłem - to nie bateria dająca w miarę stałe napięcie tylko raczej źródło prądowe z ograniczeniem napięcia. Możesz coś takiego podpiąć do "zwykłej" przetwornicy, stabilizatora lub nawet w pewnych przypadkach wprost do akumulatora, ale straty energii już na samym wejściu będą ogromne. Jak już wymyślisz sobie optymalną konfigurację systemu to szacujesz sprawność całego łańcucha i wychodząc od wyjścia liczysz zapotrzebowanie na energię widziane od strony wejścia - czyli wreszcie dostajesz konieczną moc ogniwa słonecznego. Przykładowo: Zaglądam do danych ESP32 (czyli np. na kurs Forbota ) i tam czytam, że zasilanie to 4.8-12VDC. Układ nie pojedzie więc wprost z jednego LiPola (2.8--4.2V), ale z dwóch szeregowo już tak. Jeśli nie ma innych ograniczeń (np. moduły wymagające sztywnych 5V lub nie wytrzymujące więcej jak np. 6V) to przyjmuję to za pierwsze założenie. Brak konwersji między akumulatorem a ESP32 to pierwszy sukces. Płytka i tak ma własną przetwornicę pokładową i nie musimy jej robić dobrze dodatkową stabilizacją. Teraz szacuję (albo mierzę - zależy czy system jest już gotowy i może pracować w docelowym trybie) pobór energii. Niech zatem wyjdzie średnio (w długim okresie czasu - np. za dzień) powiedzmy 30mA przy 5V, co daje 3.6Wh dziennie i ponad 1300Wh rocznie. Znając wieloletnie statystyki nasłonecznienia w Polsce wiemy, że z 1W ogniwa dostajemy ok. 900Wh w roku . Rzecz jasna nie jest to rozłożone równomiernie, bo w lecie będzie dobowo więcej a zimą nawet 50% mniej choćby z powodu mniejszej długości dnia nie licząc słabszej pogody. Zauważ, że to bardzo kiepska wiadomość: z 1W ogniwa dostaniesz w ciągu dnia średnio zaledwie 2.4Wh energii. Wydawałoby się, że np. 10 godzinny dzień powienien dać nam 10Wh.. Powyższy współczynnik zakłada nieruchomy panel patrzący w stronę Słońca na południe, zatem obracanie da rezultat może nawet i 100% lepszy, ale kosztuje energię i komplikuje konstrukcję. Gdybyś zatem umiał w idealny sposób spożytkować całą energię z ogniwa słonecznego na ładowanie idealnego akumulatora, to potrzebujesz zaledwie ok. 1.5W ogniwo. Niestety: ani akumulator nie ma 100% sprawności ani też nie da się bezpośrednio (bez strat) ładować go ze słońca. Dlatego nawet gdybyś zrealizował najlepszy możliwy scenariusz, to masz: ogniwo słoneczne -> ładowarka LiPol 2S z MPPT (80%) -> akumulator (80%) -> ESP32 i z początkowych 1.5W musisz wstawić prawie 2.5W panel. Podkreślam MPPT - koniecznie dowiedz się co to znaczy, bo przy okazji zrozumiesz wiele o pracy ogniw słonecznych. A teraz rozwiązanie "od czapy", czyli: ogniwo słoneczne -> power bank (strata na niedopasowaniu do panelu jakieś 50%, samo ładowanie 80%) -> akumulator (80%) -> ponowna konwersja na 5V (80%) -> ESP32, no i robi się panel prawie 6W. Pomijam fakt, że wejście USB power banku jest przygotowane na czyste 5V/500mA (min) i że być może w ogóle z panelem nie zadziała, bo będzie go zaduszać (zwierać) próbami pobrania wieszego prądu niż aktualnie może wypuścić panel. Cóż, tak działają źródła prądowe - napięcie spada do zera BTW: Szacunek 900Wh/rok jest pesymistyczny (realistyczny?), ale jeśli masz szczęście mieszkać w południwo-wschodniej Polsce, to możesz liczyć nawet na ponad 1000:
  41. 2 punkty
    Obecnie student 3 roku AiR, wydział Mechaniczny Politechniki Śląskiej. Mój program należy brać z dystansem,bo rocznik niżej ma już zupełnie inną podstawe programową. 1 rok to głównie matematyka,mechanika i przedmioty które bardziej mi pasują na inżynierie materiałową jak Zasady doboru materiałów inżynierskich. Jeśli chodzi o bardziej kierunkowe przedmioty to praktycznie sucha teoria, chociaż mieliśmy zajęcia gdzie bawiliśmy się robotami fanuca. Do tego obowiązkowe rzeczy do odhaczenia jak filozofia. 2 rok- więcej matmy oraz zamiast mechaniki mamy wytrzymałość materiałów. Do tego C++, SQL,jakieś sieci neuronowe i metody numeryczne. No i pełno rysunku technicznego (w tym PKM, co przy zdalnym nauczaniu i totalnym olaniu nas przez prowadzących skończyło się dla wielu tragicznie). Generalnie od IV semestru całe te studia to jest jeden wielki pic na wode. Zdecydowana większość prowadzących miała nas gdzieś,a zajęcia wyglądały na zasadzie wrzucenia prezentacji i listy zadań do wykonania. Po każdym roku miałem mieć 2 tygodnie praktyki produkcyjnej. Ale dopóki było to względnie związane z kierunkiem, uznawali. Teraz, na V semestrze dopiero zaczynają się ciekawsze dla mnie przedmioty (spawalnictwo, przedmioty związane z maszynami do obróbki) ale jako że plan zmienia się z tygodnia na tydzień,to nie wiem jak one będą wyglądały. W szczególności,że wydział ponownie jest zamknięty i wszystkie zajęcia mam zdalnie. A i tak najlepsze co wyciągłem ze studiów, to certyfikowane szkolenie z programowania PLC Siemensa. No i chciałem wyhaczyć uprawnienia spawalnicze,ale zamknęli mi wydział i nie wiadomo jak to będzie teraz wyglądać.
  42. 2 punkty
    Cześć! Nazywam się Wiki. Forbot jest moim pierwszym spotkaniem z elektroniką, ale technologią z punktu widzenia "teoretycznego" interesuję się już od jakiegoś czasu. Czas na praktykę! Nie dziwcie się, jeżeli będę zadawać na początku matołkowate pytania - przywykłam do pisania wierszy, a nie kodów Po kursie elektroniki dla początkujących, chciałabym zbudować swojego pierwszego Światłoluba. Nazwałabym go chyba Światowid. Pozdro!
  43. 2 punkty
    Daruj sobie tego typu teksty bo jeszcze ktoś w to uwierzy. Czyli jakieś dwadzieścia lat temu, tak?
  44. 2 punkty
    Były samoloty, czas na samochód na uwięzi, a raczej pocisk
  45. 2 punkty
    sprintf na pewno pomoże, jest to funkcja mająca duże możliwości konwersji różnych typów danych oraz formatowania tekstu, jednak jej użycie spowoduje spore zwiększenie rozmiaru kodu wynikowego (czyli zajętości FLASH), co w mniejszych mikrokontrolerach AVR może nie być bez znaczenia. Ponadto użycie tej funkcji może początkującemu programiście sprawić problem. Jeśli chodzi tylko o prostą konwersję liczby całkowitej do ciągu znaków, osobiście proponowałbym funkcję itoa oferowaną przez avr-libc (plik nagłówkowy <stdlib.h>). Przykład użycia: #include <avr/io.h> #include <stdlib.h> // zmienna przechowująca konwertowaną liczbę // jako ciąg znaków do wyświetlenia char str[7]; // przykładowa funkcja wyświetlająca ciąg znaków // (nie wiem jak nazywa się Twoja) void lcd_wyswietl_string(char* s) { // tutaj kod funkcji } int main(void) { int liczba = 173; // można najpierw konwertować // ostatni argument (10) oznacza, że chodzi nam o system dziesiętny itoa(liczba, str, 10); // później wyświetlić lcd_wyswietl_string(str); // można też od razu przekazać wskaźnik na ciąg znaków // do funkcji wyświetlającej lcd_wyswietl_string( itoa(liczba, str, 10) ); while (1) { } } Typ int w avr-libc jest 16-bitowy, dlatego do konwertowania liczb większych od 32767 lub mniejszych od -32768 wymaga użycia funkcji ltoa.
  46. 2 punkty
    @Maticz w tym ćwiczeniu powinieneś mierzyć napięcie między masą, a wejściem komparatora. Pomiar między potencjometrem a rezystorem nie będzie pomocny (tzn. będzie, ale trudniej o wyciągnięcie wniosku). Jak zmierzysz napięcie we wskazanym przeze mnie miejscu to powinno być łatwiej. Rezystor, który działa tutaj jak sprzężenie zwrotne wpływa na zachowanie diody "w punkcie", gdzie się ona przełącza. Bez rezystora, gdy kręci się potencjometrem to jest takie miejsce, w którym dioda szybko mryga lub świeci niepełną mocą. Z dodatkowym rezystorem nie powinno być takiego miejsca - zawsze dioda będzie "idealnie" wyłączona lub "włączona" - bez takich dziwnych stanów pośrednich Wykonując to ćwiczenie musisz obserwować jak dioda zachowuje się w momencie zmiany stanu wyjścia komparatora.
  47. 2 punkty
    Fajny projekt i całkiem schludny, doceniam też że przyznajesz się że nie wszystko jest idealne Wszystko co trzyma się na tylko na kablach to bardzo zły pomysł - popraw koniecznie przy najbliższej okazji i jakoś ten kondensator przymocuj. Co do trzymania ładunku po wyłączeniu zasilania dodaj opornik 220 - 330k równolegle (wystarczy 0.25W) do tego kondensatora C1 i problem zostanie rozwiązany, Wysokie napięcie trzymane przez kondensator jest bardzo niebezpieczne jak się zapomnisz. No, to czekam na projekty na lampach - chętnie sam się zainspiruję.
  48. 2 punkty
    Cześć, jest taka możliwość, ale w mocniejszym zestawie z STM32MP157C - zobacz link: https://kamami.pl/stm32/574375-stm32mp157a-dk1-zestaw-startowy-z-mikroprocesorem-stm32mp157a.html https://kamami.pl/zestawy-uruchomieniowe-stm32/574376-stm32mp157c-dk2-zestaw-startowy-z-mikroprocesorem-stm32mp157c.html Pozdrawiam
  49. 2 punkty
    To chyba najdziwniejsza rzecz związana z modelami, jaką widziałem. Oni ścigają się na liczbę okrążeń? To zatrzymanie to dolanie paliwa? Po wyścigach haftują godzinę w krzakach? Tyle pytań!
  50. 2 punkty
    @kulfi27 Okej w takim razie, jeśli problemem było użycie metody QObject::connect() z Qt4, która używa makr SIGNAL i SLOT: connect(this->device, SIGNAL(readyRead()), this, SLOT(readFromPort())); na connect z Qt5, connect(this->device, &QSerialPort::readyRead, this, &MainWindow::readFromPort); To sugeruje, że Qt nie mogło rozwiązać tego połączenia w czasie wykonywania programu. connect() z Qt4 jest rozwiązywany w czasie programu, natomiast connect() z Qt5 w czasie kompilacji. Ciężko powiedzieć dlaczego nie działa starsza wersja, ale to tylko znak, że należy używać tej z Qt5. Niestety wtedy kiedy pisałem kurs używałem connect() z Qt4 @kulfi27 Z ciekawości czy przy connect() z Qt4 po uruchomieniu programu w konsoli nie były drukowane jakieś ostrzeżenia? Jak się connect() z Qt4 nie powiedzie to jest drukowana informacja. Program do tego while'a wchodzi wtedy kiedy odczytany ciąg znaków zawiera znak końca linii, z przykładu z dokumentacji np: taką może mieć implementację metoda canReadLine(): bool CustomDevice::canReadLine() const { return buffer.contains('\n') || QIODevice::canReadLine(); } Czy dane, które wysyłałeś z uC zawierały znak końca linii? Jeśli nie to masz odpowiedź dlaczego nie wchodziło do while'a. Za to odpowiada mechanizm Sygnałów i Slotów Qt. To nie connect() sprawdza czy w buforze odbiorczym są jakieś dane, connect() się wykonuje i zwraca sterowanie od razu - więc jak by mógł to robić? To co robi connect() to rejestruje dane połączenie w mechanizmie sygnałów i slotów. Wtedy w tej pętli zdarzeń: int main(int argc, char *argv[]) { //... return a.exec(); // <- która startuje tutaj } Jeśli device wyemituje sygnał readyRead() to mechanizm sygnałów i slotów (nie connect()) wywoła w efekcie metodę readFromPort() klasy MainWindow. @erulission akurat mnie ubiegł A jak to działa dokładnie, możesz sprawdzić tutaj.
Tablica liderów jest ustawiona na Warszawa/GMT+01:00
×
×
  • Utwórz nowe...