ghost1313

Mam pytanie odnoście wejścia CLOCK. Nie tylko w kontekście tego układu, ale ogólnie. Chciałbym się upewnić czy dobrze je rozumiem. Rozumiem, że jest na nie podawany sygnał prostokątny, gdzie w równych odstępach czasowych pojawia się zbocze narastające. I teraz, jeśli chcemy wysłać z jednego układu do drugiego informację binarną np. 1101, to aby układ wiedział, gdzie jedna jedynka się kończy a zaczyna druga, każdy bit tej informacji jest odczytywany w momencie wystąpienia zbocza narastającego i interpretowany zgodnie z logiką: 0 = stan niski 1 = stan wysoki Proszę o potwierdzenie czy dobrze to rozumiem? Pytam, bo z takim wejściem spotykam się bardzo często przy różnego rodzaju układach czy magistralach i chciałbym dokładnie wiedzieć jak działa.

Witam, ostatnio postanowiłem zbudować własne Arduino. W pierwszej kolejności wykorzystałem do tego mikrokontroler Atmega8. Wyczytałem iż najpierw należy wgrać bootloader za pomocą programatora USBAsp, a następnie, używając konwertera USB->TTL wgrywać programy (Reset wciskałem manualnie) i komunikować się z portem szeregowym. Wszystko fajnie działało, ale 4kB pamięci flash to za mało na wgranie wielu szkiców, nawet tych z menu przykłady. Przerzuciłem się więc na mikrokontroler Atmega328 i tutaj w pierwszej kolejności wgrałem bootloader używając programatora. Co mnie jednak zaskoczyło to fakt, iż programowanie tego układu musi wyglądać inaczej niż poprzedniego. Po pierwsze, nie działa mi wgrywanie programów za pomocą konwertera, muszę używać opcji Wgraj używając programatora. W przypadku Atmegi8 ta opcja nie pozwalała wgrywać programów Arduino (chyba po prostu nadpisywała bootloader). Tutaj wszystko działało, ale oczywiście brak konwertera powodował brak możliwości komunikacji z portem szeregowym. Finalnie więc muszę mieć podłączone obie rzeczy, aby móc wgrywać programy i rozmawiać z portem szeregowym. Podsumowując pytania są następujące: 1) Dlaczego opcja Wgraj używając programatora zachowuje się inaczej w przypadku obu układów? 2) Czy da się jakoś wgrywać programy Arduino do mikrokontrolera Atmega328 używając tylko konwertera USB->TTL (zakładam że da się, bo w końcu płytka Arduino UNO chyba tak to robi)?

Ustawiłem fuse bity na FF(low) C9(high), podłączyłem kondensatory ceramiczne 22pF do oscylatora i przekompilowałem program. Dioda nie działa. Sprawdziłem dla 1MHz i przy takich ustawieniach nadal działa. Niemniej, kiedy wspomniałeś o bootloaderze przypomniało mi się, że wgrywałem na ten mikrokontroler bootloader Arduino. Chciałem spróbować wgrać na niego szkic Arduino, ale obecnie czekam na zamówiony konwerter USB->TTL. Może to fakt wgrania tego bootloadera powoduje tu jakieś problemy?

Właśnie sprawdziłem to jeszcze raz i teraz układ działa dla 8MHz. Wczoraj jednak zdecydowanie nie działał, ale wieczorem jeszcze się z tym bawiłem, więc musiałem coś przypadkowo naprawić. Układ nie działa jednak z zewnętrznym kwarcem 16MHz. Fuse bity są ustawione na FF(low) CA(high), testowałem też dla FF(low) DA(high). Dla tych drugich dioda miga, ale w czasie świecenia jakby migocze, nie świeci stabilnie i czasem się wyłącza na dłuższą chwilę, generalnie działa, ale chaotycznie, niezgodnie z kodem programu. Dla tych pierwszych nie działa wcale. Co prawda, podłączyłem kwarc bez kondensatorów, ale przy tak prostym programie podobno nie powinno to mieć żadnego znaczenia. Dla 8MHz mam ustawienie E4(low) DA(high) i układ działa. Bity ustawiam tylko i wyłącznie poprzez zakładkę Fusy uproszczone programu mkAVR Calculator.

Nie, w tym celu używam programu mkAVR Calculator.

Witam, dzisiaj, po całym dniu walki, udało mi się podłączyć mikrokontroler ATMEGA8A-PU i wgrać na niego pierwszy, migający diodą, program. Użyłem do tego następującej sekwencji poleceń: avr-gcc -mmcu=atmega8 -DF_CPU=8000000 dioda.c -o dioda avr-objcopy -O ihex dioda dioda.hex avrdude -c usbasp -p m8 -U flash:w:dioda.hex Wszystko działa jeśli oscylator jest skonfigurowany do pracy z częstotliwością 1MHz lub 2MHz. Jednak jeśli przestawię oscylator na 4MHz lub 8MHz dioda gaśnie i nic się nie dzieje. Oczywiście dostosowuję odpowiednio parametr DF_CPU. Co zrobić, aby układ działał również na wyższym taktowaniu zegara?

Witam, dzisiaj spróbowałem zbudować swojego pierwszego robota. Całe przedsięwzięcie skończyło się uszkodzeniem Arduino. Problem polega na tym, że nie do końca rozumiem dlaczego tak się stało. Generalnie robot bazował na Arduino UNO i płytce rozszerzającej Motor Shield 2.3. Do niej podłączone były dwa silniki, serwomechanizm i ultradźwiękowy czujnik odległości. Robot był w trakcie programowania (wszystko było już zmontowane). Na płytce rozszerzającej znajdowała się zworka decydująca o tym, czy zasilanie jest doprowadzane z zewnętrznego źródła, czy z mikrokontrolera. Nie wgłębiając się na razie w dalsze szczegóły, odłączyłem tę zworkę w czasie pracy urządzenia (było wtedy zasilane przez przewód USB) i chyba wtedy doszło do uszkodzenia. Jeśli faktycznie mogło to być powodem zniszczenia płytki, to prosiłbym o potwierdzenie i wyjaśnienie dlaczego tak się stało. Jeśli nie, to dostarczę więcej danych. Zależy mi na zrozumieniu swojego błędu i uniknięciu go w przyszłości. EDIT: Właśnie odłączyłem Arduino od reszty projektu i sprawdziłem, czy wtedy działa. Okazało się, że tak. Problem musi więc być w sterowniku silników lub jakimś innym miejscu. Gdy płytka jest podłączona do robota, nie da się na nią wgrać programu, a cała konstrukcja wariuje. EDIT2: Odłączyłem i podłączyłem wszystko jeszcze raz i robot znowu działa. Przyznam, że teraz już kompletnie zgłupiałem i nie mam pojęcia o co tu chodzi.

Witam, postanowiłem dzisiaj wymontować ze starego laptopa kamerę i podłączyć ją do komputera PC za pomocą przewodu USB. Zrobiłem to według znalezionego w internecie schematu: Wszystko zadziałało, jednak chciałbym zapytać, czy te dwie diody prostownicze są tutaj naprawdę konieczne. Rozumiem, że mają sprawić, aby prąd płynął tylko w dobrym kierunku, ale nie rozumiem dlaczego miałby próbować płynąć w drugą stronę. Moje drugie pytanie dotyczy tego, czy mogę tu zastosować diody 1N4148, zamiast tych podanych na schemacie?

Myślę, że przy okazji omawiania tego tematu, warto by coś wspomnieć o prostych obwodach szeregowo-równoległych. Na przykład, aby policzyć prąd jaki płynie przez układ (mierzony tuż przy dodatnim styku źródła zasilania) należy podzielić napięcie źródła zasilania przez opór całego układu (wszystkich elementów stawiających opór razem). Inną ważną informacją jest fakt, że aby policzyć spadek napięcia na rezystorach połączonych równolegle, należy najpierw policzyć ich opór zastępczy i pomnożyć go przez odpowiedni prąd. Zapewne jest to oczywiste dla bardziej zaawansowanych osób, jednak wydaje mi się, że te początkujące nie zawsze od razu to widzą (mówię tu oczywiście o sobie, choć może jestem jakiś wyjątkowo toporny ;)). W każdym razie mnie, jako osobie bardzo początkującej brakowało w tym kursie informacji o praktycznym zastosowaniu prawa Ohma do liczenia parametrów występujących w prostych obwodach szeregowo-równoległych. Może to dziwne, bo choć teraz wydaje mi się oczywiste, że w zasadzie dowolną konfigurację oporników połączonych szeregowo i równolegle da się uprościć do jednego, to jednak nie uświadomiłem sobie tego czytając ten kurs.

Jeśli mogę coś doradzić, fajnie by było, aby do zestawów dodawać krótkie, a nie długie przewody połączeniowe, takie jakie są w zestawie do kursu techniki cyfrowej. Te długie są w mojej opinii niepraktyczne i niewygodne przy układach budowanych na płytkach stykowych. Wprowadzają zamęt, plątaninę kabli i powodują, że budowane układy są kompletnie nieczytelne, a co za tym idzie, również ich zdjęcia, gdybyśmy na przykład chcieli pokazać taki układ na forum, w celu uzyskania pomocy. Generalnie ciężko doszukać się tu jakiejkolwiek przewagi przewodów długich nad krótkimi.

Bardzo ciekawy artykuł. Myślę, że skoro jest nadajnik, to ciekawym pomysłem byłoby pokazanie, jak można zbudować do niego odbiornik (na Raspberry Pi oczywiście).

Podłączyłem przycisk oraz diodę dokładnie tak, jak było to pokazane w artykule. Następnie stworzyłem następujący kod: #!/bin/bash gpio -g mode 12 out gpio -g mode 21 up gpio -g write 12 0 while true do gpio -g wfi 21 falling gpio -g toggle 12 done który w założeniu ma zmieniać stan diody po naciśnięciu przycisku. Zaobserwowałem, że podczas jednego naciśnięcia, od czasu do czasu, dioda zmienia swój stan dwa razy. Dlaczego? Czy problem jest spowodowany jakimiś zakłóceniami natury elektronicznej, czy to kod nie jest napisany poprawnie?

Witam, jako że jestem bardzo początkujący, jeśli chodzi o sprawy związane z elektroniką, mam pytanie dotyczące tego, jak bardzo potrzebna jest obudowa chroniąca Raspberry Pi i jak duże jest ryzyko jego uszkodzenia, jeśli komputerek będzie sobie po prostu leżał na biurku (oczywiście podłączony do zasilania) bez jakiejkolwiek ochrony. Pytam, ponieważ jestem aktualnie studentem informatyki, i na zajęciach czasami używamy FPGA czy STM32 bez żadnej osłony i nic wielkiego im się z tego powodu nie dzieje. Z tego co wiem jest tak, że niektóre płytki są bardziej wrażliwe, a inne mniej i chciałbym wiedzieć jak Rasbberry Pi wygląda w tym kontekście. Interesuje mnie też jak to wygląda, jeśli chodzi o dotykanie płytki palcami, w momencie gdy jest ona podłączona do zasilania.

Generalnie bardzo przydatny, ciekawy artykuł, jednak w części o uruchomieniu usługi TOR są poważne błędy merytoryczne. Systemctl to polecenie służące do kontroli demona systemd. Jest to pierwszy uruchamiany w systemie proces i jego zadanie polega na załadowaniu wszystkich pozostałych programów i usług, składających się na przestrzeń użytkownika, a także na wykonaniu innych procedur inicjalizujących. Demon ten zastąpił stary, już nieużywany w nowych dystrybucjach systemu Linux program initd. Poniższe polecenie służy do dodania podanej w argumencie usługi do listy usług uruchamianych w momencie startu systemu. Dzięki temu, po ponownym uruchomieniu, usługa zostanie automatycznie załadowana: systemctl enable <nazwa_usługi> Następne polecenie pozwala wystartować usługę w danej chwili. Dzięki temu nie trzeba wykonywać restartu systemu po wydaniu polecenia systemctl enable. Oczywiście efekt działania polecenia start jest tymczasowy, i po restarcie urządzenia usługa będzie z powrotem nieaktywna, jeśli nie znajduje się na liście usług, które mają być automatycznie uruchomione: systemctl start <nazwa_usługi> Warto również znać następujące polecenie: systemctl status <nazwa_usługi> Wyświetli ono aktualny stan usługi i pozwoli zweryfikować to, o czym napisałem powyżej. Często program apt automatycznie wykona dla nas polecenia systemctl enable i systemctl start, dlatego warto zacząć od wydania tego polecenia, aby nie powtarzać tej procedury. Jeśli chcemy zmusić usługę do ponownego odczytania pliku konfiguracyjnego wydajemy polecenie: systemctl reload <nazwa_usługi> A jeśli to nie przyniesie efektu, to uruchamiamy usługę ponownie poleceniem: systemctl restart <nazwa_usługi> Więcej przykładów możemy uzyskać wydając polecenie: curl cheat.sh/systemctl Nawiasem mówiąc, w ten sposób można wyświetlić sobie ściągę dla wielu innych poleceń. Jest to mało znany, ale bardzo przydatny trik ;). Plik /etc/rc.local nie ma tu żadnego znaczenia, jest to skrypt starego demona initd. Prawdopodobnie nadal można go używać, ponieważ systemd jest kompatybilny wstecz z procesem initd, ale w tym przypadku nie znajduje to większego zastosowania, a już na pewno nie należy tam wpisywać komend systemctl!