Tablica liderów

Witam! Chciałbym zaprezentować Wam lodówkę, którą sam zrobiłem. Elementy z których zbudowałem lodówkę: Sklejka 6mm styropian 30mm Zestaw radiatorów Wentylatory Ogniwo Peltiera 5A Przekaźnik Arduino UNO Czujnik temperatury DS18B20 2 przełączniki Gniazdo DC 5,5x2,5mm Zasilana jest zasilaczem 12V 7A. Tak duży prąd potrzebny jest do zasilania 5A ogniwa Peltiera , 2 wentylatorów i LED'ów. Nie był potrzebny aż tak mocny, ale tylko taki miałem pod ręką. Do zasilania "zabezpieczenia" używam 2A ładowarki. niestety za późno zorientowałem się, że będzie potrzebne, przez co nie podpiąłem bezpośrednio do zasilacza. Niestety, kupując zasilacz o tak wysokim natężeniu prądu nie przewidziałem, że nie posiadam odpowiedniego kabla zasilającego. W domu znalazłem tylko taki, który da MAX 2,5A. Obudowa jest wykonana ze sklejki o grubości 6mm pomalowanej czarną matową farbą do drewna. Wyłożona jest styropianem o grubości 3cm a drzwiczki zrobione są z 4mm pleksy. Po między pleksą a styropianem jest uszczelka, która choć częściowo zapobiega uciekaniu zimna. Lodówka posiada magnesy dzięki którym drzwiczki są przyciśnięte do uszczelki. W środku zamontowałem LED'y w dwóch kolorach: białym zimnym i niebieskim. Niebieski zapala się gdy drzwiczki są zamknięte a biały, gdy są są otwarte. Z tyłu obudowy są dwa przełączniki. Jeden służy do włączania LED'ów a drugi włącza wentylatory i ogniwo Peltiera. Do chłodzenia lodówki użyłem modułu wentylatora z radiatorami przeznaczonego do ogniwa Peltiera. Niestety od zimnej strony ogniwa, mniejszy radiator nie ma wentylatora, więc musiałem go dokupić. Jego wymiary to 40mm x 40mm x10mm Obok przycisków jest otwór przez który wlatuje powietrze. Radiator z tyłu obudowy bardzo się grzał przez co musiałem wymyślić coś dzięki czemu temperatura była by stabilizowana i ograniczana. Wpadłem na pomysł aby przy temperaturze 45°C ogniwo było odłączone na 100 sekund(wentylatory wciąż pracują). W tym czasie wentylator chłodzi radiator. Do odłączenia zasilania ogniwa użyłem przekaźnika, Arduino UNO i czujnika temperatury DS18B20+. Chciałem użyć Nano, ale jak na złość wszystkie były uszkodzone. Do Arduino wgrałem odpowiedni program i podłączyłem wszystko na płytce stykowej. Dodatkowo temperaturę można sprawdzać na komputerze komunikując się z płytką przez interfejs UART. #include <OneWire.h> #include <DallasTemperature.h> OneWire oneWire(A3); //Podłączenie do A3 DallasTemperature sensors(&oneWire); //Przekazania informacji do biblioteki #define przekaznik 7 void setup(void) { pinMode(przekaznik, OUTPUT); Serial.begin(9600); sensors.begin(); //Inicjalizacja czujnikow } void loop(void) { sensors.requestTemperatures(); //Pobranie temperatury czujnika Serial.print("Temperatura radiatora to: "); Serial.println(sensors.getTempCByIndex(0)); delay(1000); if(sensors.getTempCByIndex(0) >45){//Jesli temperatura radiatira jest wyzsza niz 45 stopni digitalWrite(przekaznik, HIGH); delay(100000); digitalWrite(przekaznik,LOW); } } Niestety, na ten moment nie posiadam termometru, którym mógł bym sprawdzić różnicę temperatury. Ale po około 30 min pracy napój w puszce lekko się schłodził. Może nie jest bardzo wydajna ale mi wystarcza.

Napiszę na wstępie IPhone ma swoich zwolenników i przeciwników, bardzo proszę by ten temat nie stał się polem dyskusji "Dlaczego Apple to zło a Android jest super". Posiadam Iphone i mam swoje przemyślenia ale nigdzie ich nie ujawnię by nie rozpętać burzy . A teraz przechodzimy do sedna Aplikacji do zarządzania smarthomem na system android jest mnóstwo, ale co jest dostępne dla użytkowników iOS? Apple udostępniło protokół HAP (HomeKit Accessory Protocol) aby móc połączyć urządzenia trzecich firm do aplikacji dom. Można samemu stworzyć odpowiedni kod który połączy nasze esp z aplikacją ale można wykorzystać tak zwany mostek który to zrobi za nas. Mostek komunikuje się z naszymi urządzeniami na esp za pomocą protokołu HTTP oraz z urządzeniam firmy Apple za pomocą HAP. Połączenie to jest od początku do końca szyfrowane. Ja przedstawię instalację, krótką konfigurację mostku oraz coś jeszcze Zapewne znacie sterownik rolety lub sterownik oświetlenia wykonany przeze mnie na popularnym module ESP8266. Postanowiłem lekko zmienić w nich oprogramowanie żeby były zgodne z homebridge. Ale nie będę opisywał tutaj zmian jakie dokonałem tylko sposób instalacji tak zwanego mostku na Raspberry PI Zero W. Wybrałem model z końcówką W po to żeby nie być ograniczonym kablem Ethernet. Dodatkowo dokupiłem sobie radiator i wiatraczek. Zapewne zastanawiacie się po co mi sam wentylator bez uchwytu, ale o tym w dalszej części . Aby uruchomić malinkę potrzebujemy karty micro sd (ja wybrałem wersje 32 gb), dobrej klasy gdyż to z niej będzie uruchamiany system więc im wolniejsza karta tym wolniej będzie się ładował system. Najnowszą wersję oprogramowania pobieramy ze strony Raspberry Pi dodatkowo potrzebujemy program Etcher aby nagrać system na kartę pamięci. Po wszystkim wkładamy kartę do malinki i podłączamy zasilanie. O tym jak skonfigurować możliwość połączenia ssh możecie przeczytać tutaj. Gdy mamy skonfigurowane ssh logujemy się na naszą malinkę. ssh pi@192.168.0.3 i podajemy hasło użytkownika pi (pamiętajcie że to jest adres ip raspberry pi u mnie Wy będziecie mieli inny , aby połączyć się z systemu windows potrzebny jest program putty). Teraz warto najpierw zaaktualizować system sudo apt-get update sudo apt-get upgrade Następnie możemy zająć się instalacją homebridge Sudo apt-get install curl curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash - sudo apt-get install -y nodejs sudo apt-get install libavahi-compat-libdnssd-dev sudo npm install -g --unsafe-perm homebridge Homebridge powinien nam wystartować i powinniśmy dostać kod QR wraz z pinem używamy ich do połączenia. Teraz możemy zająć się instalacją pakietów. Możemy je znaleźć na tej stronie. Na przykład plugin do sterowania żarówką znajduje się pod tym linkiem. Przedstawiona jest również komenda za pomocą której należy zainstalować pakiet sudo npm install -g homebridge-http-lightbulb Dodatkowo jest opisana konfiguracja pliku config.json który znajduje się w katalogu ~/.homebridge/ Dzięki przykładowej konfiguracji widzimy jakie zapytania powinien realizować nasz sterownik. Dla żarówki są to Status Turn on Turn off Po skonfigurowaniu pliku config.json należy zresetować homebridge. Ja używam komendy sudo systemctl restart homebridge Za każdym razem kiedy wyłączymy malinkę i ją uruchomimy homebridge sam wystartuje. Zaraz po instalacji homebridge zainstalowałem plugin, który wystawia stronę dzięki której mamy dostęp do pliku config.json bez potrzeby używania terminala. Dodatkowo możemy dokonać aktualizacji oprogramowania, zresetować system czy zobaczyć aktualne wykorzystanie procesora. Źródło https://www.npmjs.com/package/homebridge-config-ui-x Możemy również skonfigurować sobie podgląd logów. Źródło https://www.npmjs.com/package/homebridge-config-ui-x Dodatkowo jest tam wyszukiwarka pakietów NPN do instalacji. Źródło https://www.npmjs.com/package/homebridge-config-ui-x A teraz czas na sposób montażu wentylatora Z racji tego że w końcu zakupiłem sobie wymarzoną Anetkę to zaprojektowałem obudowę do RPI zero. Dodatkowo nie chciałem podpinać wtyku usb gdyż zajmuje ono dużo miejsca pod długości oraz łatwo bym mógł uszkodzić gniazdo. Sprawdziłem że pod gniazdem na RPI są dwa pady jeden z nich to minus a drugi to plus przylutowałem w to miejsce dwa kabelki które następnie poprowadziłem do wtyku dc. Następnie zrobiłem sobie kabelek usb typ A na wtyk dc i takim kabelkiem zasilam malinkę. Jeśli macie jakieś problemy z instalacją albo pytania to piszcie śmiało będę starał się pomagać Aha i jeśli dodacie nowe urządzenie to wystarczy, że zrestartujecie homebridge i pojawi się ono w aplikacji dom w iOs.

Jak chodzi o moduły SOM, to ogólnie jest tak jak napisał kolega @msalamon, ich zastosowanie to głównie profesjonalne, komercyjne projekty. Nie znaczy to oczywiście, że w projekcie amatorskim na takie moduły nie ma miejsca - mogą się przydać chociażby do nauki, w końcu kiedyś możemy chcieć nie tylko bawić się w programowanie, ale może i coś na tym zarabiać. W każdym razie podejście nie powinno być takie - mam moduł i myślę do czego go mogę zastosować. Lepiej jest podejść odwrotnie - mam do rozwiązania pewien problem, przykładowo muszę zaprojektować urządzenie, które będzie zapewniało określoną funkcjonalność. Dopiero wtedy można zastanawiać się jak taki problem rozwiązać. I tutaj jest wiele możliwości, a wybór rozwiązania zależy od mnóstwa czynników. Jeśli mikrokontroler jest wystarczający, to często jest najlepszym wyborem. Są jednak problemy, przy których mikrokontrolery nie dają sobie rady - i tutaj znowu jest wiele możliwości: można zaprojektować własną płytkę, użyć gotowego komputera przemysłowego, taniego SBC, albo modułu SOM. Nie ma jednej odpowiedzi które rozwiązanie jest najlepsze (bo gdyby było, już dawno pozostałe by zniknęły z rynku).

Dostałeś boot loop, który pojawia się generalnie w jednej z poniższych sytuacji: nie wykasowałeś flasha przed flashowaniem i zostały tam jakieś opcje konfiguracji niekompatybilne z tym, co wgrałeś, przy flashowaniu wybrałeś niewłaściwy rozmiar pamięci flash (albo autodetekcja się nie powiodła), przy flashowaniu wybrałeś niewłaściwy sposób połączenia pomięci flash do płytki (są 4 do wyboru, po prostu spróbuj każdy po kolei), niewystarczające zasilanie, ale w przypadku tej płytki powinno być ok. Patrząc na płytkę, jest jeszcze jedna możliwość: MicroPython normalnie nie obsługuje 16MB flasha — musi być specjalny build, żeby to działało. Spróbuj wymusić 4MB.

Naprawdę dobry artykuł! Wart przeczytania.

Cześć, zapewne większość czytelników, która już trochę się orientuje w architekturze układów FPGA wie, że te układy nie zawierają bloków dla obliczeń zmienno-przecinkowych. Wbudowane w strukturę FPGA układy mnożące lub bloki DSP służą do wydajnych działań z użyciem arytmetyki na liczbach stało-przecinkowych. Oczywiście można zaimplementować w układzie FPGA bloki służące do obliczeń na liczbach zmienno-przeciknkowych, lecz wiąże się to z dość sporym użyciem zasobów układu. Jakiś czas temu opisywałem na tym forum swoje zmagania z blokiem arytmetycznym wykonującym 4 podstawowe działania arytmetyczne na liczbach Double (64-bitowych) - patrz ten link: Blok działał poprawnie,, lecz zużywał bardzo dużo zasobów układu FPGA i był wolniejszy niż moduł FPU w procesorach STM32 F4xx. Stąd stwierdziłem iż liczb zmienno-przecinkowych nie warto używać w układach FPGA (lepiej działania na zmiennych typu float czy double zastąpić obliczeniami dla liczb stało-przecinkowych). Nie zawsze jednak jest to wygodne, dlatego postanowiłem sprawdzić blok FPU dla liczb float 32-bitowych. Skorzystałem z kodu zamieszczonego w portalu: opencores.org. Oto link do projektu: https://opencores.org/projects/fpuvhdl Utworzyłem projekt (ISE 14.7 Webpack) dla układy FPGA Spartan6 (XC6SLX9 in CSG324 package) dla płytki Mimas V2 (firmy Numato Labs). Oto link do tej płytki (jest także dostępna w Botlandzie) https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdram Powyższy moduł FPU wykonuje dwa działania arytmetyczne (dodawanie i mnożenie) na liczbach 32-bitowych float (odpowiednik 32-bitowego float z języka C). Po implementacji blok zajmuje sensowną ilość miejsca w układzie FPGA: Adder - około 481 LUT (Spartan6) Multiplier - około 137 LUT (Spartan6). Poniżej zamieszczam działający projekt dla ISE 14.7 Xilinx'a (Spasrtan6). W opcjach projektu łatwo można zmienić docelowy układ na Spartana3A z płytki Elbert V2. Bloku FPU z tego projektu zamierzam użyć do obliczeń w manipulatorze mechanicznym z enkoderami kwadraturowymi - patrz ten post z Forbot'a: FPU_Multiply_ADD_01.zip Pozdrawiam Dołączam też projekt w ISE 14.7 dla mnożenia macierzy 4-wymiarowych (Verilog), może komuś się przyda. Matrix4DimMultiplyVerilog.zip

Zgadzam się: Płytkę kupił złą, ma za mało GPIO ale nic dokładać do tej płytki nie chce, uczyć się nie chce (na komunię to robi? Już były!). Jak niby pomóc w takiej sytuacji? Kupić, zrobić, podarować, podziękować? Takie rzeczy to tylko w Erze (jak ktoś pamięta reklamę).

W razie gdybyś po tym fochu zajrzał jednak na Forum, to opiszę Ci sytuację z naszego punktu widzenia. Zrozumienie drugiej strony zwykle pomaga. Ja Ciebie rozumiem, zobaczyłeś coś fajnego i zapragnąłeś to mieć, motyw chrześniaka jest dla mnie drugorzędny. Porwałeś się z motyką na Słońce, sparzyłeś i poprosiłeś o pomoc pisząc rozbrajająco, że nie umiesz połączyć układu tak jak na filmie a nawet jeśli coś sklecisz, to go nie oprogramujesz. Jednocześnie rysujesz jakiś niekompletny obrazek z przełącznikami. My widzimy to tak: pojawił się gość, który nie umie połączyć kreskami obrazków z kropek. Bo jak rozumiem rozwiązanie pokazane na filmie odpowiada Ci w 100%, czy tak? Jeśli nie, to mnie popraw i wypunktuj wszystkie różnice jake chcesz wprowadzić do schematu. Bo przecież nikt z nas tego robić nie będzie. To Ty precyzyjnie musisz pokazać co chcesz robić, jakimi środkami i przekonać nas, że nowy projekt zamiast skopiowania gotowca jest jedynym wyjściem. To jest punkt wyjścia do dyskusji. Nie Ty pierwszy i nie Ty ostatni na Forum szukają pomocy w sytuacji która ich przerasta. Oczekujemy jednak,, że będziesz współpracował. Jeśli piszę o diodach, to musisz na to odpowiedzieć jak najszybciej, bo jak widzisz rozwiązań jest wiele i dyskusja zaczyna dryfować w jakieś ekstrema. Nie wiemy czy możesz kupować oporniki, diody czy warunek gołej płytki i przełączników jest nie do ruszenia. A jeśli na to nałożymy jeszcze konieczność pisania nowego programu lub choćby jego modyfikacji przy najmniejszej zmianie połączeń i weźmiemy poduwagę, że w tym temacie to już w ogóle jesteś zielony, to sam widzisz, że pachnie to zrobieniem tego za Ciebie. Gdybyś miał dwa miesiące, to byłaby szansa odesłania Ciędo kursów porgramowania i nawet gdybyś samodzielnie tego nie ugryzł, to przynajmniej rozmowa nie wyglądałaby jak ze ślepym o kolorach. No ale napisłeś, że czasu też Ci brakuje. To co, ktoś ma usiąść, narysować schemat plus rysunki montażowe i to jeszcze w kilku etapach tak byś widział jak to trzeba połączyć a potem napisać kod do tego unikalnego sprzętu? Jeśli widzisz to inaczej, opisz jak wyobrażasz sobie naszą pomoc. Ale nie w postaci pretensji czywylwania żalów tylko konkretnie. Jakich prac oczekujesz a co możesz zrobić sam. Dzieciaków, naiwniaków i spryciarzy rzeczywiście spuszczamy na drzewo więc pokaż, że nie należysz do żadnej z tych grup.

Mikrokontrolery z rodziny PIC32 należą do moich ulubionych układów. Większość konstruktorów już jakiś czas temu zdążyła się przerzucić na ARM-y (zwłaszcza rodzinę STM32), ja jednak z jakiegoś powodu ciągle lubię korzystać z produktów firmy Microchip. Niestety, o ile tanie płytki z STM-ami można bez problemu kupić za grosze, o tyle sytuacja w przypadku PIC-ów wygląda gorzej. Czasem pojawiają się zestawy deweloperskie, jednak ich cena jest dość wysoka. Dlatego właśnie preferuję samodzielne wykonywanie takich "pomocy dydaktycznych". Jakiś czas temu prezentowałem na forum projekt mojej płytki prototypowej z układem PIC32MX270F256B. To całkiem fajny, mały mikrokontroler, w sam raz nadający się do pierwszych eksperymentów albo pierwszych projektów. Ma jednak pewną wadę - relatywne małą liczbę wyprowadzeń. Z tego powodu po podłączeniu paru peryferiów na płytce zostało mi tylko kilka wolnych pinów, które mogłem wyprowadzić na złączę. Znalazł się wśród nich interfejs I2C oraz jedno przerwanie zewnętrze, więc teoretycznie istniała możliwość rozbudowy, jednak było to pewnym ograniczeniem. Jakiś czas temu pomyślałem więc o skonstruowaniu nowszej płytki, wyposażonej w nieco bardziej zaawansowany układ. Na warsztat wziąłem PIC32MX44F512H. Posiada on znacznie więcej pinów i pieryferiów, a także dwa razy więcej pamięci flash. Dzięki temu na płytce bez większego problemu mogłem zamontować więcej "dodatków". Posiada ona interfejs Ethernet, zbudowany w oparciu o popularny układ ENC28J60. Na tej samej magistrali SPI znajduje się także 2MB pamięć flash (SST25) oraz złącze karty microSD. Dostępne jest także złącze USB, umożliwiające podpięcie pendrive'a. Płytka posiada także trzy diody LED, cztery przyciski oraz sygnalizator akustyczny. Na dwóch złączach udało mi się wyprowadzić łącznie 24 piny GPIO, mam więc swobodny dostęp do właściwie wszystkich funkcji MCU. Czerwona złącze widoczne na zdjęciach to interfejs programatora, na zielonym jest natomiast wyprowadzony UART. Dwustronna płytka została wykonana metodą termotransferu, na tzw. "kopertę". Po raz kolejny mogę więc stwierdzić, że kompletną bzdurą jest stwierdzenie, że metoda ta nie nadaje się do wykonywania bardziej skomplikowanych obwodów drukowanych, z dużą liczną cienkich ścieżek, biegnących z niewielkich odstępach od siebie. Na płytce znajduje się sporo miniaturowych elementów SMD, w rozmiarze 0402. Cynowanie wykonane za pomocą stopu Lichtenberga.

Ale jesteś w stanie zrozumieć, że przy takich ograniczeniach to się może nie udać? Bo szansa na poprawne połączenie tego wszystkiego być może wcale nie zależy od naszej chęci ani umiejętności. Matryce zestyków to zagadki logiczne. Być może wydaje Ci się, że wystarczy połączyć przyciski we w miarę kwadratową siatkę i tyle, ale to tak nie działa. Wiesz dlaczego jedne klawiatury komputeroiwe nadają się np. do gier a inne kompletnie nie? I nie chodzi mi o jakość użytych podzespołów, ale o sposób ich połączenia. Otóż martyca działa na pewno dobrze, gdy naciskasz tylko jednej przycisk. Gdy chcesz zewrzeć dwa, też jeszcze będzie OK, ale już wciśnięcie trzech na raz może spowodować, że pewne miejsca (węzły) zostaną jakby zasłonięte przez zwarcia i prawidłowa identyfikacja ich stanu będzie niemożliwa. W przypadku przycisków typu "push" jest raczej mała szansa, że kierowca ciężarówki będzie ich wciskał na raz kilka, ale Ty wstawiłeś całe mnóstwo przełączników, które są na stałe zwieranymi stykami. I teraz, jeśli połączysz je na głupa np. tak aby druty były jak najłatwiejsze do polutowania, to będzie totalna porażka. Żaden najmądrzejszy program tego nie zeskanuje. Czasem na filmikach coś wydaje się proste, ale w rzeczywistości takie nie jest - to pułapka w jaką wpada wielu poczatkujących próbującyh kopiować rozwiązania choćby z YT. Pewne rzeczy nie skalują się wprost. Do separacji takich zestyków w matrycach służą diody. Jeżeli możesz ich kupić tyle ile masz styków, sprawa jest rozwiązana ale jeśli nie, czeka Cię zabawa w rozkładanie połączeń na schemacie i zastanawianie się czy w danej konfiguracji wszystkie przycski mogą zostać poprawnie wykryte. I czeka to Ciebie a nie żadnego z nas, bo to Twój projekt a problem nie ma natury elektronicznej tylko raczej zabawy logicznej. BTW: W przypadku użycia diodek schemat można narysować od ręki w ciągu 3 minut. To jak będzie? BTW2: Oczywiście to nie musi być matryca. Masz dużo pinów I/O więc może da się to jakoś opędzić np. opornikami i sygnałami analogowymi lub konstrukcją mieszaną. Na pewno enkodery obrotowe powinny mieć swoich 6 własnych pinów, bo szybkośc impulsów na ich wyjściach raczej nie umożliwia ich skanowania w matrycy. A ich przełączniki zwierają do wspólnego wyprowadzenia. Przełączniki dwustabilne, mimo trzech wyprowadzeń możesz traktowac jak pojedynczy zestyk, bo albo będzie zwarty albo rozwarty. Te 3-pozycyjne już muszą korzystać z 3 drutów.

Odczyt jest tak samo prosty jak zapis. Mikroprocesory generują specjalne wygnały, które pozwalają sterować operacjami odczytu i zapisu. W przypadku szyny intela są to sygnały !WR i !RD. Mikroprocesory z rodzin 6502 i 6800 co prawda nie generują ich bezpośrednio, ale można je w prosty sposób uzyskać za pomocą kilku bramek. Jest to wskazane, to większość powszechnie dostępnych pamięci EPROM i RAM została zaprojektowana z myślą o pracy na magistrali Intela. Jeśli chodzi o odczyt z/zapis do portu, to masz do wyboru dwie opcje: Wykorzystanie trójstanowego bufora zatrzaskowego, np. 74373 lub 74573. Możesz na nich zbudować zarówno port wyjściowy, jak i wejściowy. Tylko niestety, wyboru dokonujesz na etapie projektowania elektroniki i rozwiązanie działa tylko w jedną stronę, to znaczy nie będziesz w stanie odczytać wartości wpisanej wcześniej do portu wyjściowego. Musisz ją sobie trzymać w jakiejś pomocniczej zmiennej. Wykorzystanie specjalizowanego portu GPIO (np. 8255), który konfiguruje się podobnie do portów ze współczesnych mikrokontrolerów. W przypadku 6502 układy IO zajmują tą samą przestrzeń adresową, co pamięć. Systemy wzorowane na 8080/8085 (np. Z80 albo rodzina x86) miały osobną (mniejszą) przestrzeń adresową dla układów IO. Wyglądało to w ten sposób, że procesor posiadał dodatkowe linie !WR i !RD, ktore aktywowały się przy odczycie z/zapisie do peryferiów. W przypadku Z80 była to chyba jedna dodatkowa linia, którą trzeba było przepuścić przez dodatkową logikę aby stwierdzić, z czym procesor chce się w danej chwili dogadać.

Po prostu pip do pracy potrzebuje plików nagłówkowych bibliotek, a te są właśnie zawarte w pakietach dev (do normalnej pracy nie są one potrzebne). Polecenie apt-cache służy właśnie (między innymi) do wyszukiwania takich pakietów. Spróbuj najprostszego polecenia: apt-cache search glib - popatrz na wyniki, pewnie znajdziesz to co jest potrzebne. Niestety - jak co dzień mam do dyspozycji tylko telefon, a na tym ciężko coś znaleźć Jak sobie nie dasz rady pewnie ktoś pomoże, ja najwcześniej rano. Tak przy okazji - pakiety developerskie gliba są potrzebne praktycznie do wszystkiego poza gapieniem się w ekran, więc warto je mieć

Wchodzisz w terminal, i instalujesz (apt-get install) pakiet, który znajdujesz poleceniem apt-cache search.

Brakuje pakietu glib(cośtam)-dev a jak znam życie to pewnie jeszcze jakichś. Znajdziesz przez apt-cache search.

I co z tego? Plusik dla autora za tę nieodpartą (i całkowicie zrozumiałą) ciekawość wygrzebywania i wskrzeszania z czeluści historii lub zakamarków magazynów upadłych technologii. Ja mam bitwę czołgów w jeszcze gorszym pudełeczku, opartą też na AY-3-cośtam - wciąż działa Ech, kiedyś to robili scalaki... Wbudowałeś modulator RF do wejścia antenowego (do tego potrzebny stary telewizor z tunerem "analogowym" a ten na taki wygląda) czy wchodzisz sygnałem baseband przez euro lub chinch?

Wow, dałeś popis elokwencji i elektronicznego obycia zalewając biednego człowieka stekiem niezrozumiałych słów i oznaczeń. Naprawdę uważasz, że mu to w czymś pomoże? Przecież on ledwo sklecił ten swój układzik z 7805 i bateryjki 9V dodając od siebie diodkę LED, a wszystko na rysowanej jakimś lakierem do paznokci płyteczce. Piszesz o amperowych prądach, żyłowaniu sprawności, typach scalaków, ale to (bez urazy Kamil2 - każdy kiedyś zaczynał) nie ten poziom. Nie chcę wywoływać jakiejś wielkiej dyskusji, ale moim zdaniem to nie jest żadna pomoc tylko pompowanie własnego.. wizerunku? Zapomniał wół jak cielęciemj był? Gdybyś jeszcze wspomniał i wskazał jakieś gotowe moduły w konkrertnych sklepach nadające się wg. Ciebie do zbudowania lepszego zasilacza,, narysował jak je podłączyć to jakoś byś się uratował, ale ta lawa?. Szkoda gadać, ode mnie minus.

Próbował może ktoś korzystać z STM32CubeIDE? Zgodnie z tym opisem to jest All-in-one. Czyli może w końcu wszystko działa tak jak powinno?

Ja robię kopię w locie programem fsarchiver. Kopia wędruje prosto na laptopa przez sieć lokalną. Wczoraj przywracalem, przydała się:-)

Nie trzeba unikać jeśli wie się jak taki generator działa. W każdym dużym sofcie są błędy. Jak można spie... zepsuć tak prostą rzecz jak millis w Arduino? USB w Windows? Multitasking w Windows? Wystarczyło zobaczyć jaki kod został wygenerowany. Wiara w to, że kod na 100% będzie poprawny jest tak samo niedorzeczna, jak wiara w

No i okazałem się niepotrzebny - świetnie! Jedna uwaga: musisz przypisać wartość początkową do zmiennej klawisz, bo w tej chwili siedzą tam po prostu jakieś śmiecie które przypadkowo mogą przyjąć wartość wciśniętego klawisza i całe zabezpieczenie nadajnika pada. Czyli: char klawisz = 0; Dodatkowo, dzisiaj doskonale wiesz, że "4" to 15m, a za tydzień się będziesz zastanawiał. Narzuca się tu od razu konstrukcja enum, czyli: enum { BAND_UNKNOWN=-1, BAND_160, BAND_80, BAND_40, BAND_20, BAND_15, BAND_10 }; a w programie używać zamiast tajemniczych cyferek po prostu zdefiniowanych przez enum stałych, czyli przykładowo: if (odczytanaWartosc0 <= 100) { currentMode = BAND_160; Aha, i nie musisz sprawdzać czy odczytanaWartosc0 jest większa lub równa zero - bo zawsze jest. Na razie powinno wystarczyć - zobaczymy co będzie później (podejrzewam że to nie jest cały program tylko jego początkowe stadium - w końcu jakieś przekaźniki pewnie będziesz chciał podłączyć). po edycji Właśnie zdałem sobie sprawę z tego, co mnie gryzło w Twoim programie. Mianowicie najpierw sprawdzasz jaka jest pozycja przełącznika, potem coś tam wypisujesz na ekranie a potem dopiero jeśli pozycja była inna niż poprzednia czyścisz ekran. W tej chwili nie widzisz tego efektu bo cały czas nadpisujesz tekst na wyświetlaczu ale później może przeszkadzać. Proponowałbym rozbić to na dwa etapy: Odczyt przełącznika: odczytanaWartosc0 = analogRead(A0); if (odczytanaWartosc0 < 100) currentMode = BAND_160; else if ... /* i tak dalej*/ if (previousMode != currentMode) { lcd.clear(); /* tu jest miejsce na jakieś dodatkowe czynności związane ze zmianą pasma */ previousMode = currentMode; } I teraz dopiero znając już currentMode można dużo ładniej napisać obsługę bieżącego pasma: switch(currentMode) { case BAND_160: /* kod dla 160m */ break; case BAND_80: /* kod dla 80m */ break; /* i tak dalej */ } Przy czym np. wypisywanie bieżącego pasma oraz treści niezmiennych proponowałbym zrobić raz, od razu po zmianie pasma.

@Gieneq potrzymam Cię w ciekawości do końca przyszłego tygodnia bo odbieram płytki pod nowe urządzenia i opisze je tutaj na forbocie (wraz z kodem). Napisze również krok po kroku jak to wyglada ze strony esp i jak wyglada dodanie do homebridge także dam Ci znać jak opisze

Robisz to źle Nie ma tu żadmego przejścia z ifa do ifa. Ten if pokazuje aktualne pasmo a nie zmianę - czyli kod będzie wywoływany za każdym obrotem loop. Musisz zapamiętać jakie pasmo było ustawione, a dopiero jeśli aktualne jest inne oznacza to zmianę. Spróbuj zdeklarować sobie jakąś globalną zmienną, niech trzyma sobie jakie pasmo jest wybrane (samo się narzuca 160, 80, 40 i zero na początku jako "nie wiem"). W kodzie za ifem sprawdzaj, czy aktualne pasmo jest takie samo jak poprzednie; jeśli nie - czyścisz wyświetlacz ew. robisz tam jakieś firdymałki związane z wyświetlaniem aktualnego pasma, i ustawiasz ową zmienną. Nie napiszę teraz kodu bo na telefonie mi to słabo wychodzi, ale powinieneś już załapać o co chodzi.

Co do artykułu. Jeśli przestaniesz zasilać ogniwo peltiera to ciepło z jednej strony szybko zostanie przerzucone na drugą także to niezbyt eleganckie rozpraszanie ciepła, żeby utrzymać temperaturę wewnątrz. Lepiej liniowo zmniejszać napięcie zasilające a co za tym idzie pobierany prąd, żeby transfer ciepła był tylko w jedną stronę. Poza tym nadal się zastanawiam skąd ludzie tutaj wiedzą na podstawie samego ogniwa jaka bądzie temperatura. Jeśli dostatecznie dobrze zaizolujesz lodówkę to możesz nawet otrzymać ujemne temperatury. Pytanie oczywiście jak długo chcesz czekać. Tu gość używa słabszego ogniwa: i jakoś udaje mu się uzsyakć po stronie chłodnej ujemną temperaturę.

To tylko pozornie fajne rozwiązanie, moim zdaniem nadające się dobrze wyłącznie do zastosowań analogowych typu stabilizator napięcia czy wzmacniacz audio. Tam tranzystor i tak pracuje w obszarze liniowym więc napięcie nasycenia Ucesat Cię nie obchodzi, bo układ i tak raczej w ten stan nie wchodzi. W przypadku klucza PWM, Darlington jest nomen-omen wykluczony, bo jego 2.5V spadek a dla większych prądów nawet i 4V praktycznie dyskwalifikuje tę konfigurację - klucz zamienia się w piecyk. Tak więc zanim coś pochopnie rzucisz, zastanów się dwa razy, bo akurat w Darlingtonie duże wzmocnienie nie jest za darmo - polaryzacja bazy tego dużego bierze się z jego własnego napięcia kolektora więc ono nie może być zbyt małe i lądujesz w piekle z 4V spadku na kluczu. Myślałeś kiedyś o tym w ten sposób? To już układ z małym buforem pnp byłby o niebo lepszy a wciąż bipolarny - jeżeli to lubisz.

I drugi z dwóch, opisywany już wcześniej:

@Julek akurat składam coś podobnego (tylko większego, na mocniejszych ogniwach). Jak sprawdzasz temperaturę ogniwa, masz obok zamocowany DS18B20? Dużo lepsze rezultaty chłodzenia są jeżeli do strony ciepłej dasz miedziany radiator, spory wpływ ma też rodzaj pasty pomiędzy. Mi się udało zredukować temperaturę strony zimnej o jakieś 5-10°C zmieniając radiator z aluminiowego na miedziany i pastę na srebrną. Ale spoko projekt Szacun że złożyłeś, ja od pół roku się bawię i końca nie widać

Teoretycznie to powinno działać... ale czy program wie, że DS działa na zasilaniu pasożytniczym? Nie chce mi się teraz tego szukać, ale chodzi o dłuższe podanie jedynki na linię DATA aby naładować wewnętrzny kondensator DS-a.

A słyszałeś o tym, że prąd płyniie w zamkniętych oczkach? I tyle samo prądu płynie w kabelku do czujnika jak i od czujnika? I że ta suma z definicji wynosi zero? To jak chcesz w ogóle wyczuwać pole magnetyczne od jednego, dwu- lub trzyżyłowego przewodu czujnikowego skoro on pola magnetycznego nie generuje? Poza tym cęgi to zakładasz na jeden przewód z Amperami prądów. Tutaj musiałbyś wypruć jedną żyłę i mieć czułość na mikroampery (czujnik indukcyjny) lub może miliamper (hallotron) co w otoczeniu komputera, silnika elektrycznego czy nawet spalinowego z jego całą elektryką jest niewykonalne tą metodą. Z resztą gdyby czujnik był zrobiony rozsądnie, to powinien wisieć na kablu ekranowanym. Pozamiatane. Pytanie w stylu "Ile człowiek może zjeść pączków?" albo "jaki jest najszybszy samochód?". Tak samo niekreślone i tak samo.. niech będzie, że tylko naiwne.

Tak czułem, że to jednak jakieś proste sterowanie dwustanowe. W takim zastosowaniu możesz oczekiwać całkiem sporego prądu wyjściowego, bo to jest przypadek w którym przez tranzystor albo nic nie płynie (i wtedy moc strat jest zerowa) albo płynie dużo, ale za to napięcie jest niskie (i wtedy iloczyn - czyli moc strat - jest niewielki). Problem jest jednak taki, że ten tranzystor wymaga sporego prądu do sterowania bazy. Nawet jeśli oczekiwałbyś kilku Amperów w kolektorze, co nie jest dla BD911 jakimś wyczynem, to do bazy musisz wtedy wpuścić kilkadziesiąt (a najlepiej ze 100) miliamperów prądu. Tyle nie wyciągniesz z portu biednej ATmegi więc będziesz potrzebował kolejnego tranzystora (coś małego pnp typu BC337) żeby wzmocnić prąd z pinu procesora na tyle, by zdołał dobrze wysterować klocka BD911. Wszystka da się zrobić, zaraz możemy tu razem narysować schemat, ale układ trochę jednak się komplikuje. Jeżeli jeszcze nie kupiłeś tego BD911, to pomyśl o innych tranzystorach, np. jakichś MOSFETach - te nie potrzebują prądu a przy małych częstotliwościach to i specjalne drivery bramek nie są poitrzebne - podłączasz wprost do pinu procka i masz 10A na wyjściu.

Tak, to normalne. Większość mierników ma za niskie napięcie na teście diod, aby mierzyć spadek napięcia na LEDach. Miernik musi mieć tą funkcję wyszczególnioną

Da się miernik zasilić z tego samego napięcia co i moduł zasilacza regulowanego. Jest mały problem, zasilanie ponad 16V "zabije" 78L05 w mierniku. Możesz dać jakiś gotowy moduł stabilizatora impulsowego step-down. Przy okazji, wyciągnięcie 3A na AVT1731 przy Uwe=30..40V a Uwy=kilka V nie będzie możliwe. Przykładowo Uwe=35V, Uwy=2V, I=3A. P=(Uwe-Uwy*I) =99W. Tyle LM338 nie da rady. Jak pamiętam 50W (sprawdź w nocie katalogowej) z odpowiednim radiatorem i małą rezystancją pomiędzy stabilizatorem i radiatorem. Trzeba dać trafo z odczepem (odczepami) i zmniejszać napięcie na wejściu modułu gdy używasz niskich napięć wyjściowych. Sam LM337, może pracować do 5A (pewnie w TO-3) wtedy max prąd 5A da się osiągnąć dla różnicy Uwe-Uwy równej 10W więc dla Uwy=3,3V max Uwe 10,3V. Poczytaj w nocie, bo moc max dla TO-220, która jest w AVT1731 i TO-3 jest różna.

Film.rarProtel Schematic.pdf Wczoraj rozpocząłem prace nad termometrem. Niewielka część już działa konkretnie wyświetlacz na WS2812 co widać na filmie. Diagnostyka po UART działa. USB można by odpalić ale nie planuję. Do zrobienia został odczyt DS18B20, to banał, bo już kiedyś robiłem więc CTRL+C, CTRL+V. OLED'a też robiłem więc prosta sprawa.DTH11 na razie nie planuję używać ale też go kiedyś robiłem. Podobnie odbiornik IR, robiłem ale nie będę obsługiwał, ESP-01 ma miejsce na PCB ale na razie nie będzie używany. Poza obsługą peryferii zostanie jeszcze odczyt zadajników kodu i potencjometru po czym poskładać program w całość. Jak to będzie działać? Odczytana temperatur będzie wyświetlana na OLED i WS2812. Skala będzie zmieniał kolor od niebieskiego, przez zielony, żółty do czerwonego. Temperaturę reprezentowaną przez dolną diodę ustawia się zadajnikiem TEMP_L, temperaturę ostatniej, górnej diody, zadajnikiem TEMP_H. Jak zadajnikiem o 16 pozycjach objąć zakres do np 150 stopni? Prosto, wartość 1 to 5 stopni, 2, to 10 stopni, itd do 150 stopni. Można by zrobić rozdzielczość 3 a nie 5 stopni, co obejmie zakres do 50 stopni. Jeszcze nie wiem jak będzie, może rozdzielczość ustawiania przez UART i zapamiętana w emulowanym EEPROM? Termometr ma służyć do pomiaru temperatur dodatnich, jak będę miał potrzebę pomiaru ujemnych, to skala będzie "rosnąć" od góry, od niebieskiego do białego. Na PCB jest przycisk, nim będzie można wybierać, z którego termometru wynik jest prezentowany na wyświetlaczu bo przewiduję ich kilka. Potencjometrem będzie można regulować jasność LED. Mam w rezerwie sporo wejść, może dodam fotorezystor, który umożliwi automatyczną regulację jasności. Sprzęt. STM32F072, 1-Wire zabezpieczony jak należy układem DS9503. Do zasilania przewiduję zewnętrzny zasilacz w wtykiem mini USB. Stabilizator SPX1117-3.3 więc da sobie radę nawet z ESP-01. Konwersja poziomów dla WS2812 zrobiona na rezystorze. W razie potrzeby, przy długich połączeniach pomiędzy PCB a WS2812, można skorzystać z pomocy 74HCT2G00. PCB dopasowana do obudowy HAMMOND 1591CFL Kolejny raz producent PCB zapewnił mi "rozrywkę" polegającą na szukaniu błędu jaki popełnił.

Ja z przykrością muszę się zgodzić z kolegą @grg0 - jeśli to faktycznie sterownik PWM (autor nie podał co to za moduł, z tego rysunku szumnie nazwanego "schematem" wynika że raczej tak), raczej bym tego nie użył do zasilania czegokolwiek.

Jeśli coś jest niejasne w opisie (tak jak wyżej podał @grg0) to zachęcam do zadawania pytań - niech autor DIY się tłumaczy. To, że projekt został zakwalifikowany do akcji jeszcze nie przesądza, że otrzyma rabat (i jaki). Jeśli pojawią się uwagi co do konkretnych rozwiązań, których autor nie będzie umiał racjonalnie wytłumaczyć, to oczywiście nie będziemy nagradzać błędnie wykonanych projektów. Liczę na to, że kulturalne omawianie projektów będzie dobre dla każdej ze stron. Jedni będą mogli wykazać się wiedzą i zasugerować co warto zmienić, a inni przy okazji czegoś się nauczą. Wychodzę z założenia, że nikt nie opisuje specjalnie błędnie wykonanych projektów - problemy mogą jedynie wynikać z niewiedzy autora. Czasami coś na pierwszy rzut oka działa, ale doświadczony elektroniki będzie umiał wytknąć, że to dzieło przypadku, bo projekt jest źle wykonany - kulturalne wytknięcie błędów będzie dobre dla wszystkich

@konstytucja zaproponowana przez Ciebie zmiana została wprowadzona do kursu. Oczywiście - prąd w danej gałęzi jest wszędzie taki sam. Możesz go zmierzyć "przed" lub "za" rezystorem - nie ma to żadnego znaczenia. Wynik zawsze powinien być taki sam (pomijając ewentualne błędy pomiarowe). Trochę źle na to patrzysz. Sonda miernika została przyłożona do jednego z wyprowadzeń diody dlatego, że jest ono podłączone do Vcc (dodatniej szyny zasilania). W praktyce mierzymy więc prąd między dodatnią szyną zasilania, a rezystorem. Nóżka diody posłużyła jedynie jako "wygodne" miejsce, w którym sondą miernika można dotknąć do Vcc. Równie dobrze mógłbyś przyłożyć czerwoną sondę do baterii lub specjalnie podłączonego przewodu. Dioda nie wpływa w żaden sposób na ten pomiar.

W załączeniu odręczny schemat kinematyki ramienia i macierze dla poszczególnych przekształceń. Jak się gdzieś nie pomyliłem Policzyłem też macierz transformacji... Fragment - macierz translacji wygląda tak : X: (((((c1 * c2 - s1 * s2) * c3) * c4 + ((c1 * c2 - s1 * s2) * s3) * s4) * c5 + (((c1 * s2 + s1 * c2) * -1) * -1) * s5) * s6 + ((((c1 * c2 + -s1 * s2) * c3) * -s4 + ((c1 * c2 + -s1 * s2) * s3) * c4)) * -c6) * H + (((((c1 * c2 + -s1 * s2) * c3) * c4 + ((c1 * c2 + -s1 * s2) * s3) * s4) * s5 + (((c1 * s2 + -s1 * -c2) * -1) * -1) * -c5) * G + ((((c1 * c2 + -s1 * s2) * c3) * -s4 + ((c1 * c2 + -s1 * s2) * s3) * c4) * F + (((c1 * s2 + -s1 * -c2) * -1) * E + ((c1 * c2 + -s1 * s2) * C * c3 + (c1 * s2 + -s1 * -c2) * D)))) Y: (((((s1 * c2 + c1 * s2) * c3) * c4 + ((s1 * c2 + c1 * s2) * s3) * s4) * c5 + (((s1 * s2 + c1 * -c2) * -1) * -1) * s5) * s6 + ((((s1 * c2 + c1 * s2) * c3) * -s4 + ((s1 * c2 + c1 * s2) * s3) * c4)) * -c6) * H + (((((s1 * c2 + c1 * s2) * c3) * c4 + ((s1 * c2 + c1 * s2) * s3) * s4) * s5 + (((s1 * s2 + c1 * -c2) * -1) * -1) * -c5) * G + ((((s1 * c2 + c1 * s2) * c3) * -s4 + ((s1 * c2 + c1 * s2) * s3) * c4) * F + (((s1 * s2 + c1 * -c2) * -1) * E + ((s1 * c2 + c1 * s2) * C * c3 + (s1 * s2 + c1 * -c2) * D)))) Z: (((s3 * c4 - c3 * s4) * c5) * s6 + ((- s3 * s4 - c3 * c4)) * -c6) * H + (((s3 * c4 - c3 * s4) * s5) * G + ((s3 * -s4 - c3 * c4) * F + ((C * s3 + (B + A))))) gdzie: c1 = cos teta1, s1 = sin teta1, itd. Na razie to tylko wynik mieszania wierszy i kolumn z mnożenia macierzy teraz trzeba by to po upraszczać, ale najpierw sprawdzę czy wzory zadziałają dla dwóch/trzech znanych pozycji. Macierzy obrotu (orientacji końcówki) na razie nie zamieszczam bo szkoda miejsca...

Na wstępie zaznaczam: ani kody nie są mistrzostwem świata, ani ta cała elektronika nie jest najwyższego lotu. Dla mnie ważne było przedstawienie działającego i przydatnego urządzenia, jeśli ktoś będzie chciał zrobić lepiej - przynajmniej będzie miał jakąś podstawę. Również estetyka może być dla kogoś wątpliwa - ale pamiętajmy o jednym: o gustach się nie dyskutuje. Nie zwracajcie uwagi na stan stolarki - mieszkanie jest do remontu. Dlatego też wszystkie elementy dekoracyjne przyklejone są po prostu taśmą - i tak trzeba będzie to rozebrać a po remoncie złożyć z powrotem. A więc... Zaczęło się od narzekań mojej pięknej pani, że odkurzacz się psuje a w ogóle to takie odkurzanie to straszna robota i ona ma dość. Ponieważ jestem bardzo podobnego zdania (jeśli chodzi o straszną robotę) staliśmy się właścicielami urządzenia o nazwie Roomba 805. Odkurzaczyk okazał się bardzo fajny. Bez zbędnych bajerów (nie potrzebujemy sterowania jakąś wymyślną aplikacją z komórki ani pilota żeby go włączyć jak się stoi metr od niego), jeździ, odkurza, karmi się sam i tyle. Niestety, z uwagi na układ mieszkania dwie wirtualne ściany dołączone w komplecie do odkurzacza to dla nas trochę za mało, trzy to minimum a najlepiej cztery. I co się okazało... cena takiego czegoś to 1/4 ceny odkurzacza! Akurat parę dni wcześniej na Forum byłą dyskusja o miganiu ledami. Jako że zadanie wirtualnej ściany sprowadza się praktycznie do migania - stwierdziłem że dwie i pół stówy na takie migadło to nieco za dużo. Zacząłem szukać jakichś gotowców - oczywiście najpierw znalazłem coś na Arduino, potem całą resztę na PIC-ach. Ponieważ moim zdaniem zastosowanie Arduino (nawet Pro Mini) do migania ledą to przerost formy nad treścią, a na PIC-ach to ja się ostatnio znałem w zeszłym tysiącleciu, postanowiłem zrobić coś od zera. W szufladzie leżały sobie dwie sztuki ATtiny13 (nadmiar ze starszego projektu) - więc postanowiłem je wykorzystać. Na początku jednak trzeba było określić, jak ta nieszczęsna dioda IR ma migać. W tym celu zacząłem czytać, czytać, czytać... i okazało się, że co autor to inne zdanie, co komentarz to "mi nie działa". W jednym przynajmniej wszyscy byli zgodni: dioda pracuje na 38 kHz. I tyle. No cóż... właściwie mogłem zacząć od czego innego. Znalazłem w rupieciach TSOP31236, co prawda jest on na 36 a nie na 38 kHz ale szybkie zerknięcie do datasheeta upewniło mnie, że powinien jako-tako działać (przynajmniej z bliska) na 38. Podłączyłem go do analizatora stanów, włączyłem oryginalną ścianę... no i okazało się, że to całe "miganie" sprowadza się do trzech impulsów po 0.5 msec co 8 msec, a potem przerwy gdzieś w okolicach 130 msec (przerwy były różne, od 100 do 150 msec, czyli najprawdopodobniej niekrytyczne). No cóż, teraz wypadałoby sprawdzić efekty moich ciężkich poszukiwań. Nabazgrany na kolanie kod skompilowałem w Arduino IDE, leda IR podłączona przez opornik 100Ω do PB0, czerwona przez 2kΩ do PB1, przytwierdzone gumką do koszyka na baterie... #ifndef F_CPU #define F_CPU 9600000UL #endif #include <avr/io.h> #include <util/delay.h> #define pon do { \ TCCR0A |= (1<<WGM01) | (1<<COM0A0);\ TCCR0B |= (1<<CS00); \ } while(0) #define poff do { \ TCCR0A &= ~((1<<WGM01) | (1<<COM0A0)); \ TCCR0B &= ~(1<<CS00); \ PORTB &= ~(1 << PB0);\ } while (0) int main(void) { char i,n; DDRB |= (1 << PB0) | (1 << PB1); PORTB |= (1 << PB1); OCR0A = 125; for (n=0;; n = (n+1) & 31) { if (!n) PORTB |= (1 << PB1); for (i=0; i<3; i++) { pon; _delay_us(500); poff; _delay_us(7500); } if (!n) PORTB &= ~(1 << PB1); PORTB &= ~(1 << PB0); _delay_ms(132); } } Odkurzacz bardzo grzecznie zareagował, wycofał się z terenu pilnowanego przez moje migadło i ruszył w swoją stronę. W tym momencie już byłem pewny, że urządzenie będzie działać i mogę się bawić w wersję finalną. Przede wszystkim pomyślałem, że warto trochę pooszczędzać baterie. Poczytałem sobie nieco o usypianiu i oszczędnościach, wyszło mi coś takiego, że ATtiny działa przez ok. 17 milisekund a następnie idzie sobie spać. Całkiem nieźle, ale brakowało mi jednej rzeczy, której nie ma w oryginalnej ścianie: wskaźnika poziomu baterii. Niestety - ATtiny13 nie potrafi zmierzyć napięcia zasilania. Wypróbowałem kilka różnych sposobów (w tym jeden, który nawet nieźle działał - potencjometr podłączony do jednego z wyjść ATtiny i porównanie przez komparator z wewnętrznym napięciem wzorcowym), tyle że w pewnym momencie uświadomiłem sobie, że "ściana" będzie na stałe zamocowana w krytycznych miejscach i zasilanie mogę wziąć skądś obok - na pewno nie z baterii (urządzenie ma być stuprocentowo bezobsługowe). Tak więc wszystkie pomiary zostawiłem sobie na przyszłość (jeśli będę robił wersję na baterie) i wziąłem się do roboty. Najważniejsze było niewpuszczenie odkurzacza do kuchni (możliwa mokra podłoga i pałętanie się pod nogami człowiekowi co może nieść coś gorącego) oraz zakaz wstępu za szafkę z telewizorem (trochę kabli tam niestety leży, podłączone jest w sumie siedem urządzeń z których trzy wiszą na ścianie). Ponieważ szafka stoi zaraz obok wejścia do kuchni, postanowiłem zrobić tylko jedno urządzenie, do którego podłączę dwie ledy IR, a zasilanie 5V wezmę po prostu z USB telewizora, dodając dodatkowo akumulatorek na wypadek, gdyby elektrowni akurat odbiło wyłączyć mi prąd kiedy odkurzacz sprząta. Ponieważ musiałem zasilić dwie diody IR (a myślałem jeszcze o trzeciej, chociaż zostawiłem to sobie na później), diody nie są podłączone bezpośrednio do wyjścia ATtiny, ale przez tranzystor (użyłem tu 2N2222 tylko dlatego, że jako pierwszy wpadł mi do ręki). Urządzenie wyszło całkiem zgrabnie: Schemat połączeń: Trzypinowe łącza zastosowałem dlatego, aby nie trzeba było zastanawiać się którą stroną włożyć wtyczkę. Jednocześnie nawet w przypadku pomylenia wtyczki od diody kontrolnej z IR od razu widać, że kontrolka świeci nie tak jak powinna. Kod się niewiele bardziej skomplikował: #ifndef F_CPU #define F_CPU 9600000UL #endif #include <avr/sleep.h> #include <avr/wdt.h> #include <avr/io.h> #include <util/delay.h> ISR(WDT_vect) {} #define pon do { \ TCCR0A |= (1<<WGM01) | (1<<COM0A0);\ TCCR0B |= (1<<CS00); \ } while(0) #define poff do { \ TCCR0A &= ~((1<<WGM01) | (1<<COM0A0)); \ TCCR0B &= ~(1<<CS00); \ PORTB &= ~(1 << PB0);\ } while (0) int main(void) { char i, n; DDRB |= (1 << PB0) | (1 << PB1); PORTB |= (1 << PB1); OCR0A = 125; // watchdog MCUSR &= ~(1<<WDRF); WDTCR |= (1 << WDCE) | (1 << WDE); WDTCR = 1 | (1 << WDCE); WDTCR |= (1 << WDTIE); sei(); for (n=0;; n= (n + 1) & 7) { if (!n) PORTB |= (1 << PB1); for (i=0; i<3; i++) { pon; _delay_us(500); poff; if (i<2) _delay_us(7500); } if (!n) PORTB &= ~(1 << PB1); for (i=0; i<5; i++) { set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_mode(); } } } Pozostało mi tylko umieszczenie diod. O ile przy szafce byłoby to proste (w sumie tę diodę nie bardzo widać czyli można by zrobić dowolne, najprostsze mocowanie), o tyle przy framudze nie chciałem, aby wystawała tam jakaś elektronika. Poradziłem sobie w prosty sposób: ponieważ zawsze mi się podobały różne bajki o krasnoludkach, Pożyczalskich i innych stworach zamieszkujących dom - dioda IR została ukryta w drzwiach do domku Zgredka, dioda kontrolna to alarm przy drzwiach, a wjazdu za szafkę pilnuje Nessie Urządzenie się sprawdza, prąd pobiera jakiś znikomy (zdechły prawie całkowicie akumulatorek wydłubany ze starego laptopa, naładowany na tyle żeby sprawdzić że działa, wytrzymał prawie miesiąc - dopiero potem podłączyłem ładowarkę do USB), alarm przy drzwiach Zgredka wesoło sobie mruga, więc teraz przyszła pora na urządzenie numer dwa. Tu niestety miałem większy problem. Z uwagi na dość dziwaczny układ mieszkania (troje drzwi w wąskim korytarzyku) jak bym nie umieścił diody broniącej drzwi do łazienki, zawsze coś się odbijało od białej stolarki (framugi, trzecie drzwi) i odkurzacz bał się wjechać przez właściwe drzwi. Wymyśliłem sobie, że zrobię jakąś barierę foto która będzie włączać diodę IR tylko wtedy, kiedy robot spróbuje wjechać do łazienki (tam mu nie wolno), ale wychodziło mi to jakieś straszliwie skomplikowane. I tu znowu czytanie Forum mi pomogło - ktoś w pewnym wątku zaproponował diodę laserową. Postanowiłem spróbować - akurat i tak coś w Botlandzie kupowałem, tak że diodę wziąłem przy okazji z myślą, że jeśli to mi nie wyjdzie, wykorzystam do jakiegoś inngo projektu. Okazało się to strzałem w dziesiątkę. Co prawda zaprojektowanie mocowania diody (z koniecznością regulacji, bo kąty w 80-letniej stolarce są proste tylko z nazwy) przysporzyło mi nieco roboty i nie wyszło dokładnie jak chciałem, ale spełnia swoje zadanie. Tu już program się skomplikował. Założenia były następujące: Jeśli fototranzystor jest zwarty (na czas regulacji), dioda laserowa świeci cały czas aby umożliwić wycelowanie promienia; Jeśli drzwi do łazienki są zamknięte (kontaktron), nie ma potrzeby uruchamiania led; nic nie świeci, nic nie miga, ATtiny sprawdza sobie tylko raz na jakiś czas czy otworzyłem drzwi; Jeśli drzwi są otwarte, dioda laserowa włącza się na co chwilę i sprawdzane jest, czy robot nie próbuje wleźć tam gdzie nie trzeba. Dioda kontrola błyska sobie co kilka sekund; Jeśli wykryta zostaje obecność robota, włącza się dioda IR, i wyłącza się dopiero chwilę po odjeździe robota. Dioda kontrolna błyska szybciej. Tutaj też zastosowałem dwie diody IR (po obu stronach framugi), ale tym razem połączyłem je po prostu szeregowo. Tak więc kod znów nieco urósł: #ifndef F_CPU #define F_CPU 9600000UL #endif #include <avr/sleep.h> #include <avr/wdt.h> #include <avr/io.h> #include <util/delay.h> #include <avr/interrupt.h> #define PIN_IRED PB0 #define PIN_CONTROL PB1 #define PIN_PHOTO PB2 #define PIN_LASER PB4 #define PIN_DOOR PB3 #define setPin(a) do {PORTB |= (1 << (a));} while(0) #define unsetPin(a) do {PORTB &= ~(1 << (a));} while(0) ISR(WDT_vect) {} #define pon do { \ TCCR0A |= (1<<WGM01) | (1<<COM0A0);\ TCCR0B |= (1<<CS00); \ } while(0) #define poff do { \ TCCR0A &= ~((1<<WGM01) | (1<<COM0A0)); \ TCCR0B &= ~(1<<CS00); \ unsetPin(PIN_IRED);\ } while (0) int adc_read (void) { ADMUX = (1 << MUX0) | (1 << ADLAR); ADCSRA |= (1 << ADSC) ; while (ADCSRA & (1 << ADSC)); return ADCH; } #define LASER_DELAY 500 #define MIN_PHOTO 20 #define CALIBRATE 2 #define SHADE 1 #define DECAY 3 uint8_t readPhoto(void) { int8_t i, pom;uint8_t na, nb; ADCSRA |= ( 1<<ADEN); for (i=pom=0;i<3;i++) { if (i) _delay_us(LASER_DELAY); na = adc_read(); if (!i && na < 5) { ADCSRA &= ~( 1<<ADEN); return CALIBRATE; } setPin(PIN_LASER); _delay_us(LASER_DELAY); nb=adc_read(); unsetPin(PIN_LASER); if (na > MIN_PHOTO && na - MIN_PHOTO > nb) pom++; } ADCSRA &= ~( 1<<ADEN); return (pom > 1) ? 0 : SHADE; } int main(void) { int8_t ndark, res, i; uint8_t ledctl; DDRB |= (1 << PIN_IRED) | (1 << PIN_LASER) | (1 << PIN_CONTROL); PORTB |= (1 << PIN_CONTROL) | (1 << PIN_DOOR); OCR0A = 125; // watchdog MCUSR &= ~(1<<WDRF); WDTCR |= (1 << WDCE) | (1 << WDE); WDTCR = 1 | (1 << WDCE); WDTCR |= (1 << WDTIE); // ADC ADCSRA = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0); sei(); for (ndark = ledctl = 0;;) { if (ndark > 0) { ndark --; res = DECAY; } else { if (!(PINB & (1 << PIN_DOOR))) { for (i = 10; i >= 0; i--) { set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_mode(); } ledctl = 0; continue; } res = readPhoto(); if (res == CALIBRATE) { ndark = 0; setPin(PIN_LASER); for (;;) { _delay_ms(100); res = readPhoto(); if (res != CALIBRATE) break; } unsetPin(PIN_LASER); _delay_ms(100); continue; } } if (res) { if (res != DECAY) ndark = 20; if (!ledctl) setPin(PIN_CONTROL); ledctl = (ledctl + 1) & 3; for (i=0; i<3; i++) { pon; _delay_us(500); poff; if (i<2) _delay_us(7500); } unsetPin(PIN_CONTROL); for (i=0; i<5; i++) { set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_mode(); } } else { if (!ledctl) { setPin(PIN_CONTROL); _delay_ms(10); unsetPin(PIN_CONTROL); } for (i=0; i<3; i++) { set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_mode(); } ledctl = (ledctl + 1) & 31; } } } Schemat połączeń wygląda mniej więcej tak (odtwarzam z pamięci): Kilka uwag: Użyłem gotowego modułu z diodą laserową, który ma już potrzebny rezystor (stąd brak na schemacie). Fototranzystor TEPT 4400 został użyty przede wszystkim dlatego, że go miałem. Prawdopodobnie nadałby się dowolny reagujący na kolor światła diody. Mój błąd - rezystor R3 podłączony jest cały czas do VCC zamiast np. być zasilany razem z diodą laserową (oszczędność energii). Jak już wspomniałem - urządzenie jest zasilane z sieci, czyli nie jest to krytyczne, ale w razie gdyby komuś chciało się coś takiego zrobić można pomyśleć o podłączeniu tego rezystora razem z diodą i odpowiednim przerobieniu funkcji readPhoto(). Na początku bałem się jednak, że nie będę mógł odróżnić zwarcia fototranzystora od jego oświetlenia - dlatego tak już zostało. I znowu kwestia umieszczenia tego wszystkiego na framudze drzwi w ten sposób, aby nic (ani szalejący odkurzacz, ani jakieś przypadkowe potrącenie) nie ruszyło diody. Ponieważ miałem już domek Zgredka - dorobiłem mu saunę i wygódkę. Przy okazji wyskoczył bardzo ciekawy efekt uboczny - światło diody laserowej prześwieca przez pomarańczowy "murek" sauny i tworzy wrażenie płonącego w saunie pieca Urządzenie numer dwa zasilane jest oddzielnie ze zwykłej starej ładowarki od e-papierosa. Planuję wspólne zasilanie obu urządzeń - ale aby podciągnąć tam kabel muszę wbić się po drodze pod dwa progi (i tak do wymiany) - czyli czekam na remont...

Witam! Zgłaszam projekt do akcji rabatowej.

Czy w zdaniu "Jeżeli do bazy przyłożymy nieduże napięcie (względem emitera), to elektrony z niego zaczną się przemieszczać w kierunku bazy." chodzi o to, że elektrony zaczną się przemieszczać z emitera do bazy? Jeśli tak, to wg mnie zdanie powinno poprawnie brzmieć: "Jeżeli do bazy przyłożymy nieduże napięcie (względem emitera), to elektrony z emitera zaczną się przemieszczać w kierunku bazy."

@OPszon Potwierdzam wypowiedzi Kolegów - w 78xx GND zawsze jest na środku, dobrą praktyką jest dodanie kondensatorów działających jak "zbiornik energii", zabezpieczającej przed chwilowymi spadkami, LM7805 nie może działać dla Uwe=5V, ponieważ musi mieć o minimum 2 V większe napięcie wejściowe, czyli 7V Polecam ten artykuł (jak i cały kurs, dużo powinien wyjaśnić): https://forbot.pl/blog/kurs-elektroniki-stabilizatory-napiecia-id4353 Ponadto polecam odizolować blok zasilania (czyli stabilizator) od zasilanego układu, w jego miejsce wstawić woltomierz - i wówczas sprawdzić, czy daje prawidłowe 5V, dopiero później wstawić to, co chcesz rzeczywiście zasilać Pozdrawiam

Bo procesory w nich nie są projektowane z myślą o SBC. SoC siedzący w RPi, przynajmniej w tych starszych to był układ zaprojektowany z myślą o dekoderach DVBT stąd jego architektura, jest to defacto GPU który ma moduł w postaci CPU.

Pierwszy z dwóch projektów:

Witam, Zgłaszam projekt DIY do akcji rabatowej

Coś dla leniwych - automatyczne otwieranie puszek

Dokładnie tak. Konstrukcja typu a<b<c powstała właśnie z Iconowego GDE, chodziło o to, aby w Pythonie było to dopuszczalne. Różnica jest taka, że wyrażenie a<b albo zwraca prawą stronę, albo pada. Jeśli padnie - to dalej nic się nie robi. Jeśli nie - sprawdzamy, czy prawdziwe jest wyrażenie b < c (bo b jest wynikiem działania a<b). W Pythonie powstała jakaś dziwaczna konstrukcja... Trochę szacunku i poznania języków które były przed Pythonem na pewno by Ci nie zaszkodziło. Proponuję zacząć od Snobol4 (bo to był prekursor dzisiejszych języków przeznaczonych do operacjach na tekstach, z regexpami włącznie).