-
Zawartość
2663 -
Rejestracja
-
Ostatnio
-
Wygrane dni
198
Wszystko napisane przez 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.
-
Problem z wysterowaniem LCD 2x16 - co zle ?
Elvis odpisał w temacie użytkownika razors • Mikrokontrolery
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 -
Problem z wysterowaniem LCD 2x16 - co zle ?
Elvis odpisał w temacie użytkownika razors • Mikrokontrolery
No właśnie - brakuje jeszcze pętli na końcu. dodaj while (1); przed ostatnim return -
Problem z wysterowaniem LCD 2x16 - co zle ?
Elvis odpisał w temacie użytkownika razors • Mikrokontrolery
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 -
[Kurs] Kurs programowania procesorów ARM (LPC21xx)
Elvis odpisał w temacie użytkownika Elvis • Artykuły użytkowników
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. -
[Kurs] Kurs programowania procesorów ARM (LPC21xx)
Elvis odpisał w temacie użytkownika Elvis • Artykuły użytkowników
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?
-
[Komunikacja] Radiowa transmisja danych, czyli robot zdalnie sterowany
Elvis odpisał w temacie użytkownika Elvis • Artykuły użytkowników
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
-
Gdy zaczynałeś przygodę z robotyką...
Elvis odpisał w temacie użytkownika Arek Banaś • Zupełnie zieloni
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