Elvis

Jak chodzi o czujniki, to moim zdaniem optyczne od myszki odpadają. Muszą być bardzo blisko podłoża, żeby poprawnie działały. W przypadku poduszkowca to raczej nierealne. Poza tym podłoże musi być idealnie płaskie - a po co poduszkowiec, żeby po stole latać. Może warto pomyśleć o czujnikach ultradźwiękowych? Są dobre na większe odległości.

Raczej nie spaliłeś, tylko źle ci doradzili. Optotriak będzie działał tylko z prądem przemiennym. Triak uruchamiany jest prądem bramki, niestety do wyłączenia konieczne jest wyłączenie zasilania. W przypadku prądu przemiennego triak wyłączany jest przy przejściu przez zero. Jeśli podłączyłeś do prądu stałego, to raz włączony będzie przewodzić, aż do wyłączenia zasilania.

Uruchomiłem program na płytce olimex-a z atmega128 (http://olimex.com/dev/pdf/AVR/AVR-MT-128-SCH-REV-A.pdf). Konieczne były drobne zmiany, ale działa: // PROGRAM OBSLUGUJACY WYSWIETLACZ LCD (2X16 ZNAKOW) // // Atmega16, 4Mhz, // ///////////////////////////////////////////////////// //-------------------------------------------------- // Biblioteki: #include <avr/io.h> #include <inttypes.h> #define F_CPU 4000000 #include <util/delay.h> //-------------------------------------------------- // Makra upraszczajace dostep do portow: #define

No właśnie - brakuje jeszcze pętli na końcu. dodaj while (1); przed ostatnim return

LCD_sendHalf((LCDC_FUNC | LCDC_FUNC8b)<<LCD_D4); LCD_sendHalf((LCDC_FUNC | LCDC_FUNC8b)<<LCD_D4); LCD_sendHalf((LCDC_FUNC | LCDC_FUNC4b)<<LCD_D4); Niepotrzebne są < #define LCDC_FUNC 0x20 #define LCDC_FUNC8b 0x10 #define LCDC_FUNC4b 0

Takie aktywne czekanie ma kilka poważnych wad. Po pierwsze jest mało dokładne. Jeśli w trakcie wystąpi przerwanie, to czas będzie inny. Dla 1-wire może to mieć znaczenie, więc trzeba wyłączać przerwania czekając, co z kolei może powodować problemy procedur działających na przerwaniach. Dodatkowy problem to pobór prądu. Procesory ARM potrafią sporo pobrać. W końcu 60MHz to sporo. Więc czekanie w pętli to marnowanie czasu i prądu. Najlepiej jest uruchomić timer i uśpić procesor. Wtedy mamy dokładność działania, brak opóźnień przerwań i oszczędność prądu.

Jak chodzi o biblioteki to niestety na arm jest trudniej. Nigdy nie używałem, ale znalazłem bibliotekę ArmLib - http://hubbard.engr.scu.edu/embedded/arm/armlib/index.html , w niej jest trochę funkcji, które wydają się ciekawe. Najprościej opóźnienie zrobić na pętli - oscyloskopem wyregulować i chodzi. Niestety dokładność jest wtedy bardzo słaba. Jeśli opóźnienia maja być dokładnie mierzone pozostaje użyć timer. LPC21xx ma 2 timery. Można wykorzystać jeden do tworzenia opóźnień, albo wprowadzić globalny licznik czasu i za jego pomocą tworzyć opóźnienia. Jest jeszcze jedna możliwość, uru

Sorki, jeśli źle zrozumiałem. Nie chodziło mi o piekarnik, tylko o piec do montażu elementów smd.

SeerKaza, to ty gadasz głupoty. Obudowy TQFP64 (SMD, raster 0.5mm) da się lutować zwykłą lutownicą. Ja nie próbowałem, ale widziałem jak inni lutują - więc da się. Natomiast BGA raczej nie da się zlutować w domowych warunkach. Gorące powietrze nie podgrzeje wszystkich padów równomiernie. Poza tym konieczna byłaby kontrola temperatury. O ile wiem konieczny jest piec. [ Dodano: 29 Mar 10 09:25 ] Jednak ludzie wszystko domowymi metodami zrobią: http://www.elektroda.pl/rtvforum/topic73518.html Ale i tak łatwiej poradzić sobie z LQFP. Tak, czy inaczej jest to dużo wyższa szkoła jazdy niż A

Właśnie błędy konkretnych procesorów mi chodziło, nie o cały rdzeń. Ale to w każdym procesorze się zdarza. Jak chodzi o stm32lib to jest rzeczywiście super łatwo programować, niestety kosztem wydajności. Chciałem sprawdzić, czy na prawdę I/O mają prędkość 50MHz. Przy stm32lib prędkość max to ok. 2-3MHz. Dopiero bezpośredni zapis do rejestrów + maksymalna optymalizacja dało 50MHz. Ale i tak biblioteka bardzo przyjemna.

Bardzo polecam cortex-m3. Co prawda nie są pozbawione błędów, ale wiele rozwiązań jest udoskonalonych w porównaniu z ARM7. Testowałem STM32 oraz NXP (LPC176x) i osobiście wolę NXP - głównie ze względu na doświadczenie w programowaniu LPC2148. Natomiast dużym plusem STM32 jest standardowa biblioteka oferowana przez producenta. Jak chodzi o kompilatory, to coraz lepiej radzi sobie z nowymi procesorami gcc. Polecam środowisko Rowley (CorssStudio) - bardzo łatwo rozpocząć przygodę z nowymi procesorami. Natomiast jak chodzi o darmowe narzędzia, to CortexM3 mają standardową bibliotekę obsługi do

To ja głosuję, że winny jest brak diód w mostku. Kiedyś testowałem silnik krokowy w podobnym układzie - indukowało się ponad 100V... Ale najlepiej sprawdzić podłączając diody, jak zacznie działać, to będzie odpowiedź.

Ja bym proponował jeszcze raz sprawdzić, czy to nie problem z zasilaniem. Spróbuj odłączyć silniki i ręcznie "pochodzić" chwilę robotem. Jeśli nie będzie się resetował, to może jednak skoki zasilania - kondensatory powinny pomóc. Jak nadal będzie problem, to proponuję bardzo skrócić program - najpierw zrobić jazdę bez czujników - np. 2sek prosto, 2 sek w prawo 2 sek w lewo. Póżniej dodać obsługę 1 czujnika i zobaczyć czy działa. Dalej kolejno dodawać następne czujniki - jak się popsuje to będzie wiadomo gdzie szukać błędu.

Strasznie kombinujesz. Na pewno nie byłoby łatwo. Gdybyś po prostu podłączył tranzystor pnp do wyjścia procesora, to niezależnie od stanu linii procesora tranzystor by przewodził. Musiałbyś mieć wyjście open-colector oraz rezystor podciągający. Z open-colector można sobie jeszcze poradzić (sztuczka jak przy i2c, zamiast wystawiania 1, zmiana kierunku działania portu), ale pull-up nie wiem, czy nie byłby szkodliwy dla procesora. Ja polecam wersję: bipolarny npn, polowy z kanałem P.

co do bipolarnych to tak, ale BUZ11 jest ma kanał N więc nie polecam.

Na mój gust to przepełniasz stos. Funkcja Jedz wywołuje np. Prosto, następnie prosto wywołuje Jedz. Zamiast Call używaj Goto (tak przynajmniej jest w Basic-u, bo Bascom-a nigdy nie używałem). Jeśli używasz Call, to na końcu procedury musi być z niej powrót (pewnie przez Return).

Moim zdaniem polecony IRLZ44 nie najlepiej się nadaje. Nie wiem jaki schemat chcesz zastosować, ale najlepszym rozwiązaniem jest zaproponowane przez madman07-a. Czyli tranzystor npn, którym wysterujesz MOSFET. Wtedy nie jest potrzebny model "L". IRLZ44 się nie nadaje, bo potrzebny będzie MOSFET z kanałem P, a nie N. Takie rozwiązanie sprawdzałem na 12V, działa bardzo dobrze. Jeśli zastosujesz MOSFET z kanałem N, to obie części układu nie będą miały wspólnej masy. Może to być akceptowalne, i wtedy IRLZ44 nie stanowi problemu.

A jaki prąd płynie przez to 24V? Bo jeśli przewidujesz większy pobór prądu oraz rzadkie przełączanie, to może zwykły przekaźnik?

Ponieważ sporo osób pyta o kody źródłowe, załączam kody dla RFM12 oraz HM-T868S. RFM12B_T.zip RFM12B_R.zip HM_FSK.zip

Nie chciało mi się wierzyć, że enum nie działa. I słusznie, pobrałem kompilator arduino i sprawdziłem. Działa dokładnie jak w C. Nie lubię wklejać kodów na forum, ale tym razem zrobię wyjątek: #include <LiquidCrystal.h> //biblioteka do obslugi LCD enum { KIERUNEK_STOP, KIERUNEK_PROSTO, KIERUNEK_W_LEWO, KIERUNEK_OW_LEWO, KIERUNEK_W_PRAWO, KIERUNEK_OW_PRAWO }; LiquidCrystal lcd(12, 11, 5, 4, 3, 2); //LCD podpięty pod te piny int irLPin = 0; // Analog PIN 0; Left IR int irCPin = 1; // Analog PIN 1; Center IR int irRPin = 2; // Analog PIN 2; Right IR in

To nieprawda. ASCII jest 7-bitowe, jeśli nie wierzysz sprawdź na wikipedii. Co prawda używa się 8 bitowego kodowania, ale to już nie jest ascii. Kody >127 nie należą do standardu.

W C++ można pominąć enum przed deklaracją zmiennej, więc kod był w C++ poprawny. Niestety w C trzeba powtarzać enum przed typem zmiennej.

Nie podłączaj nigdy bezpośrednio - zawsze przez rezystor 100-470ohm.

Jeśli już to: enum NKierunkek kierunek = KIEUNEK_PROSTO; Ale sprawdzałem pod gcc i keil enum {X1, X2 }; i kompilowało bez problemu.

Jest jak najbardziej poprawna. Ma tylko taką wadę, że za rok ciężko sobie przypomnieć co znaczy "kierunek = 2". Jeśli enum nie działa można wykorzystać instrukcję #define, czyli #define KIERUNEK_PROSTO 1 #define KIERUNEK_STOP 2 #define KIERUNEK_PRAWO 3 #define KIERUNEK_LEWO 4