Elvis

Obsługa klawiatury matrycowej nie jest wcale taka skomplikowana. Można ją spokojnie obsłużyć bezpośrednio przez mikrokontroler, o ile oczywiście wystarczy wolnych pinów. Radzę tylko na wyjściach procesora zamiast rezystorów dać diody. Inaczej mogą być problemy przy naciśnięciu dwóch przycisków jednocześnie.

Cała zabawa polega na tym, żeby samemu zbudować robota. Jeśli podchodzisz do sprawy jak wynika z twoich postów, po prostu zamów robota w firmie. Zleć wykonanie obudowy, mechaniki, elektroniki i najlepiej oprogramowania. 20 tys. może być mało, ale jak poszukasz, ktoś za ciebie projekt wykona. Tylko czy o to chodzi?

Turgon, ty coś chyba oczekujesz, że wszyscy na forum powiedzą ci jak zrobić robota, a ty tylko za niego zapłacisz, a później pojedziesz na zawody. Jakoś dziwnie w 5min udało mi się wygooglować sklep Maxona: https://shop.maxonmotor.com/ishop/app Pewnie inne można równie łatwo odszukać. Tylko trzeba chcieć, a nie co chwila wołać pomocy.

Zamień podłączenia pinów 2 i 3 gniazda RS_232.

Jak chodzi o łatwe rozwiązania, to na pewno nie polecam RFM12. Jest on dość skomplikowany do obsługi, poza tym ma infterfejs SPI, więc bezpośrednie podłączenie do RS232 w PC odpada. Najprościej jest kupić moduły mobot-a: http://www.mobot.pl/index.php?site=products&type=853&details=7770 oraz http://www.mobot.pl/index.php?site=products&type=853&details=7771. Pierwszy moduł podłączamy bezpośrednio do PC, przez zwykłe USB. W systemie moduł działa jako port COM, więc można użyć nawet hyperterminala do obsługi. Po stronie AVR podłączamy drugi moduł. Ma on wyjścia TTL więc możemy podłączyć bezpośrednio do mikrokontrolera. Nie potrzeba MAX232, ani skomplikowanego oprogramowania.

Co do akumulatorów na płycie głównej to będę bronił rafalz_32. Obecnie rzadko się to spotyka, ale dawno dawno temu często były montowane. Na 100% widziałem akumulator w płycie 486... Później już się nie przyglądałem. Jak chodzi o prąd to po pierwsze od niego zależy jasność świecenia diody. Więc jeśli damy np. 5mA to może świecić, ale bardzo słabo. Są jeszcze diody niskoprądowe. Na szybko znalazłem http://www.semics.pl/oferta/publiczny/optoelementy/diody_led_niskopradowe_info.pdf Jest tam dioda, której do świecenia wystarczy 2mA. A ogólnie to chłopaki, dajcie sobie na wstrzymanie i przestańcie się kłócić. Bo nie warto.

Spróbuj podłączyć serwo do wyjścia PWM. Będziesz miał większą stabilność sygnału. Przeglądałem trochę informacji w necie i wygląda na to, że TG9 ma sterowanie jak każde inne serwo...

Czyli piny wejścia-wyjścia są ustawiane na logiczne jedynki, gdy na RST podamy stan wysoki. Na schemacie masz 12MHz kwarc, jeden cykl maszynowy to 12 cykli oscylatora, czyli cykl maszynowy trwa 1us. Czyli na pinie reset stan wysoki musi trwać co najmniej 2us, aby wywołać reset procesora. Racja, przyzwyczajenie z AVR

Tak, C9 i R12 tworzą układ całkujący. Jeśli podłączałeś układ przed R12, czyli tam gdzie jest dioda, mogły być zmienne odczyty.

Jak dla mnie to zmiany odczytów są za duże jak na niedokładności wywołane skokami napięcia referencyjnego. Z drugiej strony widać, że przeważnie Uzm Mam wrażenie, że sonar daje na wyjściu sygnał zmienny, więc konieczne byłoby dodanie układu całkującego (chyba że już dodałeś). Proponowałbym wykonać test z dużą częstotliwością pomiarów z ADC (taka symulacja oscyloskopu) i sprawdzić jak ten sygnał wygląda. Z tego co podałeś wygląda jakby miał okres 6s, ale to chyba aliasing, moim zdaniem powinno być coś koło 40kHz.

A jak często wykonywałeś odczyty? Chodzi mi o to, jak często występują te zakłócenia.

Masz błąd w procedurze obsługi przerwania: count+=1; if(count==0) P1_0=1; // jedynka do serwa if(count==wartosc) P1_0=0; // Po wartosc * 500 us zero do serwa if((count==400)){ // Odliczaj do 20ms count = 0; } Problem jest taki, ze nie wykonuje się instrukcja dla count==0. Gdy count==400, wtedy wykonuje się trzeci if, w nim ustawiasz count=0. Po następnym przerwaniu jest count=0, ale pierwsza instrukcja zmienia na count=1. I w efekcie warunek if (count==0) nie jest spełniony.

Prawdopodobnie coś nie tak z programem. Może masz źle ustawione czasy/zegar. Możesz spróbować napisać programik, który co 1s zapala/gasi diodę i sprawdzić czy będzie to dokładnie 1s. Albo lepiej dodać taką funkcje (mrugania diodą) do obecnego programu.

Moduły mają raster 2mm, typowe goldpiny 2,54. Możesz zamówić listwy z rozstawem 2mm, np. w TME: http://www.tme.eu/html/PL/gniazda-do-druku-proste-raster-2-mm/ramka_637_PL_pelny.html

Jak chodzi o wybór płytki ewaluacyjnej: 1) http://www.propox.com/products/t_144.html 2) http://www.propox.com/products/t_145.html 1 jest tańsza, a atmega8 to całkiem spory procesor na początek. Natomiast płytka 2 ma jedną przewagę - obsługuje JTAG - więc jeśli będziesz się uczyć możesz debugować program (wykonywać linia po linii, podglądać wartości zmiennych, zawartości rejestrów). Dla początkującego proponowałbym taki zestaw: * Płytka 2 * programator obsługujący JTAG * AVRStudio + WinAVR jako kompilator Ja na podobnym etapie zaczynałem zabawę z AVR i polecam na początek.

Ja bym radził zacząć od komunikacji po kablu. Dopiero jak wszystko zadziała zmienił na radio. Nie znam modułu mobota, ale: 1) może wymagać inicjalizacji, np. ustawienia prędkości, częstotliwości itd 2) nie wiem czy zawiera sprzętową kontrolę transmisji - jeśli nie, to mogą być spore zakłócenia i problem wykrycia początku transmisji [ Dodano: 16 Gru 09 04:49 ] Używasz modułu MOBOT-RCRv2? W dokumentacji jest konfiguracja uarta:interfejs wyjsciowy: UART TTL57600bps, bity danych: 8, parzystosc: brak, bit stopu: 1

powinno być: PORTB |= _BV(3); //stan wysoki na PB3 (4A) ... PORTB &= ~_BV(3); //Stan niski na PB4 (4A) ogólnie |= daje stan wysoki, a &=~ niski. [ Dodano: 13 Gru 09 10:58 ] czyli: void przod() { PORTB |= _BV(3); //stan wysoki na PB3 (4A) PORTB |= _BV(0);//stan wysoki na PB0 (1A) PORTB &= ~_BV(4); //Stan niski na PB4 (3A) PORTB &= ~_BV(5); //stan niski na PB5 (2A) PORTB |= _BV(1); //kanały pwm (maksymalne wypełnienie) PORTB |= _BV(2); }

PORTB &= ~_BV(3); //stan wysoki na PB3 (4A) Komentarz nie zgadza się z kodem - program ustawia stan niski, nie wysoki. Podobnie jest z kodem, który miał dawać stan niski - daje wysoki. Może dlatego nie działa?

if(pomiar<512){ zamień na if(pomiar<128){ W zmiennej pomiar masz 8 wyższych bitów wyniku. A zmienna 8 bitowa nie może przekroczyć 255, więc warunek <512 jest zawsze spełniony.

W zestawie brakuje jednego - kompilatora. Nie wiem w czym będziesz programować, bo wiele książek o PIC-ach dotyczy programowanie w asemblerze. Jest to niewątpliwie cenna umiejętność, ale ciężko zaczynać od asemblera, to wyższa szkoła jazdy. Jeśli mam coś doradzać to nauki chyba lepiej wybrać AVR. Po pierwsze jest duży wybór języków programowania, chociażby Bascom, C, asembler. W internecie jest dużo przykładów i dokumentacji, sporo po polsku.

Kondensator przy reset można dać, ale mniejszy. 100nF wystarczy w zupełności. Przydaje się z dwóch powodów. Po pierwsze filtruje zakłócenia. Po drugie zapewnie odpowiednią długość impulsu resetującego.

Ja kiedyś miałem podobny problem. Rozjechały się schemat i pcb. Pomogło usunięcie wszystkich elementów, do których eagle miał zastrzeżenia, a następnie dodanie ich z powrotem. Od tego czasu nie używam autoroutera nawet na próbę - bo po jego użyciu wystąpił błąd.

Jakby co to ja też jestem za zawodami

Ja myślę, że dałoby się wyszukać problem do rozwiązania w C, niewykonalny w Bascomie. Tak jak można wymyślić program, który da się napisać w asemblerze, a nie da w C. Tyle, że to będzie tak nietypowy i specyficzny problem, że po co sobie głowę zawracać.

Ogólnie, to chyba im większy tym lepiej. W sterownikach widziałem kondensatory po 4700uF. Ale nawet z mniejszymi powinno działać. Pamiętaj też o kondensatorach za stabilizatorem 5V, inaczej procesor może się resetować.