Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2594
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    189

Wszystko napisane przez Elvis

  1. Dowcip matematyczny Def. Pochodną imprezy nazywamy ilość alkoholu jaką możemy kupić za butelki sprzedane po imprezie. Tw. Imprezę nazywamy nietrywialną wtedy i tylko wtedy gdy jej druga pochodna jest niezerowa.
  2. Nie, będzie jeszcze jedna część o RS232 oraz o przetworniku ADC.
  3. Jak już wymieniamy ciekawe mikrokontrolerki, to polecam zobaczyć Cortex-M0. Co prawda są słabsze od Cortex-M3, ale za to są bardzo tanie. Mogą być ciekawą alternatywą dla AVR. Do wgrywania można wykorzystać RS-232, albo kupić płytkę ewaluacyjną z przejściówką USB<->UART: http://www.kamami.pl/index.php?productID=137779 Najciekawsze są ceny samych procesorów. Najtaniej znalazłem w Kamami: http://www.kamami.pl/index.php?ukey=product&productID=136170 Procesor z 24KB Flash, 8KB RAM, zegarem 50MHz w cenie 6,65 zł (brutto przy 30szt)... Producent dostarcza gotowe środowisko do programowania (bazujące na eclipse): http://ics.nxp.com/lpcxpresso/ Na koniec jeszcze jeden plus dla osób nie przekonanych do SMD. LPC1114 jest (albo raczej będzie) dostępny w obudowie 44PLCC - można ją włożyć w przewlekaną podstawkę. http://pl.farnell.com/nxp/lpc1114fa44-301/mcu-32bit-32kflash-cortex-m0-44plcc/dp/1786288
  4. W ustawieniach projektu trzeba odszukać opcję generowania dodatkowo pliku .hex. Ja mam wersję 1.x CrossStudio, tam było to w zakładce Linker, opcja "Additional Output Format"
  5. Zawsze możesz wykorzystać BT do komunikacji z palmtopem. Dajesz moduł btm-222 i masz komunikację jak po RS-232.
  6. Te procesorki mają niestety trochę niespodzianek. Trzeba jeszcze uważać na P0.14 i czytać erraty. Jak chodzi o podciąg, to nie polecam dawać małego rezystora. Wtedy przy wyłączonej diodzie będzie płynąć całkiem spory prąd. Może lepiej odwrócić logikę - diodą podłączyć katodą z procesorem, anodą (przez rezystor) z zasilaniem. Wtedy zerem będzie można zapalać diodę. Podciąg może być całkiem spory - np. 47k. Najlepiej byłoby dać tranzystor, który sterowałby diodą - przy najmniej procesor nie byłby obciążany prądem diody.
  7. Jak chodzi o P0.2 to niestety trzeba dokładnie czytać dokumentację - wyjścia I2C są open-colector. Też się kiedyś na to naciełem. Ale z pullupem działają poprawnie. Natomiast P0.30 działa poprawnie. Tylko jest jeszcze jedna sprawa. Na stronie 106 dokumentacji (UM10114.pdf) podane są domyślne ustawienia portów. I jak na złość P0.30 domyślnie jest jako ADC (AIN3 dokłądniej). Czyli trzeba dodać: PINSEL1 &= ~(_BV(28)|_BV(29)) albo: PINSEL1 = 0
  8. Dziwne, że nie działa kod: GPIO0_IOSET =_BV(2)|_BV(30); Natomiast aktualna wersja: GPIO0_IOSET = 0xffff;//_BV(2)|_BV(30); Nie ma prawa działać na P0.30 - powinno być: GPIO0_IOSET = 0xffffffff;//_BV(2)|_BV(30); [ Dodano: 16 Paź 10 09:21 ] Już wiem, czemu nie działa P0.2 W dokumentacji jest mała zmyłka, jak odsyłacz [1]. A w nim: Więc wyjście P0.2 wymaga pull-upa. Inaczej nie będzie działać.
  9. Aby sprawdzić, gdzie są przechowywane zmienne funkcje itd. najlepiej otworzyć plik z rozszerzeniem .map (znajduje się w katalogu z plikiem wynikowym). Przykładowo w program14.map znajdziemy fragment: Memory Configuration Name Origin Length Attributes ROM 0x00000000 0x0001e000 xr RAM 0x40000000 0x00004000 rw *default* 0x00000000 0xffffffff Tutaj zdefiniowana jest mapa pamięci naszego mikrokontrolera. Od adresu 0 mamy Flash, od 0x40000000 pamięć RAM. Dalej odnajdujemy adresy zmiennych, czy funkcji. Przykładowo stała: const unsigned int SIN_TABLE[] = { 0, 15, 31, 46, 61, 76, 90, 104, 117, 129, 141, 152, 161, 170, 178, 184, 190, 194, 197, 199, 200 }; Daje wynikowo: *(.rodata) .rodata 0x00000418 0x74 program14.o 0x00000438 SIN_TABLE 0x00000418 LED_PIN Więc jak widać const działa zgodnie z oczekiwaniami, stała umieszczana jest w pamięci Flash.
  10. Ja bym radził oprócz oceny "na oko" podłączyć miliamperomierz i sprawdzić ile mA pobiera podświetlenie. Na diodę powinno być 10-20mA. Więc wystarczy sprawdzić ile diod ma wyświetlacz, i można chociaż z grubsza prąd oszacować. Poza tym jak pisze Nawyk zacząć o rezystora, sprawdzić jak świeci i ile prądu bierze.
  11. Strasznie drogo w AVT... Poczekaj chwile, może Treker coś z Kamami załatwi. Jeśli nie, to może lepiej inną płytkę wybrać. Bo prawie 180 zł to nieporozumienie...
  12. Ja również bardzo dziękuję za oddane głosy. Gratuluję wszystkim laureatom.
  13. Poprzednia lekcja RS-232, c.d. - biblioteka standardowa W przypadku Bascom-a używanie RS-232 jest bajecznie proste. Polecenie „print” wysyła tekst, właściwie nic nie trzeba robić. W tej części spróbujemy uzyskać podobny efekt w języku C. Funkcja sprintf Najpierw przyjrzymy się funkcji „sprintf”. Należy ona do biblioteki standardowej C, więc jest dostępna na właściwie każdej platformie i kompilatorze. Aby ją wykorzystać wystarczy zaimportować plik stdio.h: #include <stdio.h> Funkcja sprintf jest bardzo podobna do znanej funkcji printf. Każdy kurs C zaczyna się wyświetleniem „Hello World” za pomocą printf. Sprintf jako pierwszy parametr przyjmuje bufor (tablicę znaków) i zamiast na ekran, wypisuje wynik do bufora. Obejrzyjmy kod: char buf[32]; sprintf(buf, "Hello world!\n"); Program nie wypisze nic na ekran. W jego wyniku zmieni się zawartość tablicy buf, ale nic nie będzie widać. Po co więc nam funkcja sprintf? Za jej pomocą możemy właściwie dowolnie formatować napisy, wykorzystywać formatowania w rodzaju %d, %f, \n itd. Następnie bufor możemy za pomocą naszej funkcji uart_send_string() wysłać przez RS-232. Zmieńmy nieco poprzedni program. Tym razem, gdy otrzymamy nieznane polecenie (znak), wypiszemy kod tego znaku. Fragment: default: uart1_send("Nieznane polecenie\r\n"); break; Zastąpimy następującym: default: sprintf(buf, "#%d - Nieznane polecenie\r\n", c); uart1_send(buf); break; Kompilujemy program i... czeka nas przykra niespodzianka. Dostajemy całe mnóstwo błędów: c:/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(freer.o): In function `_malloc_trim_r': mallocr.c:(.text+0x48): undefined reference to `_sbrk_r' mallocr.c:(.text+0x64): undefined reference to `_sbrk_r' mallocr.c:(.text+0x84): undefined reference to `_sbrk_r' c:/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(makebuf.o): In function `__smakebuf': makebuf.c:(.text+0x3c): undefined reference to `_fstat_r' makebuf.c:(.text+0x110): undefined reference to `isatty' c:/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(mallocr.o): In function `_malloc_r': mallocr.c:(.text+0x424): undefined reference to `_sbrk_r' mallocr.c:(.text+0x4cc): undefined reference to `_sbrk_r' c:/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib\libc.a(stdio.o): In function Okazuje się, że musimy sami zdefiniować brakujące funkcje. Najprościej będzie skopiować gotowy plik z funkcjami z przykładu w katalogu: C:\WinARM\examples\lpc2129_adc_stdio\syscalls.c Kopiujemy plik do naszego projektu, dodajemy go w oknie edytora. Niestety błędy podczas kompilacji pozostają bez zmian. Musimy dodać nowy plik do kompilacji, czyli poleceń w pliku Makefile. Odnajdujemy fragment: # List C source files here. (C dependencies are automatically generated.) # use file-extension c for "c-only"-files SRC = $(TARGET).c I do zmiennej SRC dodajmy nowy plik: SRC = $(TARGET).c syscalls.c Jest to bardzo ważny moment. Od tej chwili nasz program będzie się składał z dwóch plików źródłowych. Część kodu jest w program19.c, część w syscalls.c. Jest to bardzo częsty i użyteczny mechanizm. Nie musimy trzymać wszystkich funkcji w jednym, z czasem bardzo dużym pliku. Zamiast tego dzielimy projekt na mniejsze części, funkcje umieszczamy w różnych plikach. Bardzo ułatwia to orientowanie się w projekcie oraz pozwala na wykorzystywanie plików z innych projektów w nowych programach. Niestety problemy nadal występują. syscalls.c:15:18: error: uart.h: No such file or directory syscalls.c: In function '_read_r': syscalls.c:31: warning: implicit declaration of function 'uart0GetchW' syscalls.c:31: warning: nested extern declaration of 'uart0GetchW' syscalls.c:37: warning: implicit declaration of function 'uart0Putch' syscalls.c:37: warning: nested extern declaration of 'uart0Putch' Na początek po prostu pozbędziemy się problemów - zakomentujemy wszystkie linie, które sprawiają problemy. W języku C wystarczy na początku linii napisać // aby kompilator resztę traktował jako komentarz. Dzięki temu linie te zostaną pominięte podczas kompilacji, ale gdy będziemy chcieli do nich wrócić, wystarczy usunąć napis //. Kompilujemy program i wgrywamy do procesora. Poniżej wynik działania: W archiwum program19.zip znajdziemy kompletny kod przykładu. Wgrywanie zajmuje teraz dużo więcej czasu niż w poprzedniej wersji. Niestety dołączenie funkcji sprintf znacznie zwiększyło objętość programu. Zajmuje teraz aż 45KB! Czyli o ponad 40KB więcej niż poprzednio... Moduł obsługi UART-a Zanim przejdziemy dalej warto nieco uporządkować program. W pliku głównym poza samym programem napisaliśmy kod odpowiedzialny za komunikację przez UART1. Kod ten na pewno przyda się w kolejnych programach, jest dość długi i utrudnia analizę programu głównego. Przygotujemy własny moduł, czyli utworzymy dwa pliki: uart.h, uart.c Do pliku uart.c przeniesiemy funkcje związane z komunikacją, czyli: uart1_init, uart1_recv, uart1_send_byte, uart1_send. Plik nagłówkowy jest potrzebny kompilatorowi, aby w programie głównym rozpoznawane były nazwy naszych funkcji. Wpisujemy do niego nagłówki funkcji poprzedzone słowem kluczowym extern, które informuje kompilator, że treść funkcji zdefiniowana jest gdzie indziej (w pliku uart.c). Następnie w programie głównym dodajemy instrukcję włączającą nasz nowy moduł: #include "uart.h" Musimy jeszcze w pliku Makefile dodać informację o nowym pliku z programem: uart.c. Wykonujemy to podobnie jak poprzednio dla pliku syscalls.c. Kompilujemy nowy projekt i sprawdzamy działanie. Wielkość kodu, ani działanie programu nie ulega zmianie. Natomiast program jest nieco "czytelniejszy", a nasz nowy moduł uart będziemy mogli wykorzystywać w kolejnych programach. Archiwum Program20.zip zawiera omawiany przykład. Funkcja printf i scanf Teraz możemy przystąpić do prawdziwego ułatwienia pracy. W standardowych programach pisanych na PC do komunikacji z użytkownikiem można wykorzystać standardowe funkcje printf oraz scanf. Ich użycie jest bardzo proste i każdy kurs C szczegółowo je omawia. Nauczymy się wykorzystywać je na mikrokontrolerze. Otwieramy plik syscalls.c i sprawdzamy, które linie musieliśmy zakomentować, aby program się kompilował. Na początek: #include "uart.h" Tutaj jest łatwo - wystarczy usunąć komentarz, mamy moduł uart.h, więc wszystko powinno być dobrze. Następnie zobaczmy zakomentowane odwołania do funkcji uart0Putch. Jak można się domyślić, ta funkcja ma wysyłać znaki. Nasza wersja nazywa się uart1_send_byte. Wystarczy więc zmienić nazwę wywoływanej funkcji i oczywiście usunąć komentarze. Zobaczmy jeszcze funkcję uart0GetchW. Odpowiada ona za odczyt znaku. Nasza wersja nazywa się uart1_recv i niestety działa nieco inaczej - zamiast czekać na znak, zwraca 0 jeśli nic nie zostało odebrane. Musimy więc dodać pętlę, w której będziemy czekać, aż coś odbierzemy. do { c = uart1_recv(); } while (c==0); Czas teraz wrócić do programu głównego i wykorzystać nowo przygotowane funkcje. Nowy program ma na celu jedynie prezentację, jak łatwo teraz programować komunikację przez RS-232: while (1) { printf("Podaj prędkość robota: "); scanf("%d", &speed); printf("\n"); if (speed>150) speed = 0; if (speed<0) printf("Za mala wartosc\n"); else if (speed>100) printf("Za duza wartosc\n"); else printf("Predkosc wynosi %d%%\n", speed); } Okazało się, że kod w pliku syscalls.c wymagał nieco poprawek - wersja z przykładu nie działała w 100% poprawnie. W załączniku znajdziemy plik program21.zip z poprawioną i przetestowaną wersją. Wnioski Wykorzystanie funkcji printf do komunikacji jest bardzo wygodnym rozwiązaniem. Niestety w przypadku kompilatora gcc oraz biblioteki standardowej, cena jaką trzeba zapłacić za wygodę jest wysoka. Dla dużych programów 40kB nie stanowi problemu, natomiast jeśli nasz program jest mały, lepiej poszukać innego rozwiązania. Program21.zip Program20.zip Program19.zip
  14. Może warto zobaczyć ten dokument: http://www.atmel.com/dyn/resources/prod_documents/doc2553.pdf Atmel opisuje w nim różnice między atmega88 i atmega8. Na mój gust różnice są spore - inne adresy rejestrów, część ma pozmieniane nazwy. Poza tym inne jest napięcie referencyjne dla ADC. Trzeba więc pewnie program trochę pozmieniać.
  15. Timer + rs232 powinien wystarczyć. Przed wywołaniem funkcji uruchamiasz timer, po zakończeniu zatrzymujesz i wartość wysyłasz przez rs232.
  16. Ja czasy mierze w ten sposób, że na wolnym pinie zmieniam stan przed wywołaniem określonej procedury i po powrocie. Następnie na oscyloskopie oglądam przebieg.
  17. Miejsce 1: Nawyk Miejsce 2: Zuk Miejsce 3: Lassar Uzasadnienie: Pierwsze miejsce dla Nawyk-a, głównie za artykuł o serw-ach. Ładnie zebrane informacje, porządny artykuł. Na pewno plus za opis modułu MEMS. Chociaż jak chodzi o MEMS, to trochę za mało jak na mój gust... Drugie miejsce dla Zuk-a za artykuł o pomiarze stanu akumulatorów. Temat dla mnie interesujący w dziedzinie niekoniecznie związanej z robotyką. Ale na pewno ładnie i profesjonalnie opisany. Z trzecim miejscem miałem problem. Głosuję na Lassar-a za opis zawieszeń.
  18. Poprzednia lekcja Lekcja 9 - RS-232 Nastepna lekcja Na początek krótki wstęp Wszyscy pewnie znają interfejs RS-232. Charakterystyczne gniazdo DB-9 dawniej montowane było w każdym komputerze PC. Obecnie coraz częściej gniazdo zastępowane jest przez USB, na szczęście dostępne są przejściówki USB<->RS232. Wtyczka wyposażona jest w 9 linii, opis możemy znaleźć na wikipedii, poniżej dla przypomnienia najważniejsze linie: Numer pinu Oznaczenie Funkcja 2 - RxD - Odbiór danych 3 - TxD - Transmisja danych 5 - GND - Masa Te trzy linie wystarczą do naszych celów - wymiany informacji między mikrokontrolerem, a PC. Łącząc dwa urządzenia, musimy podłączyć je „na krzyż”, czyli linię RxD łączymy z TxD drugiego układu: Zasada jest prosta, chociaż łatwo się pomylić: to co jeden układ wysyła przez linię TxD, drugi musi odebrać, linią RxD. Takie połączenie dawno temu było popularne do łączenia dwóch komputerów PC. Komunikacja z mikrokontrolerem Najpierw ostrzeżenie: Nie wolno łączyć bezpośrednio mikrokontrolera z gniazdem RS-232 w PC. Dlaczego? Otóż RS-232 przesyła dane za pomocą napięć ±11V. Procesory nie tolerują takich napięć. Więc należy zapamiętać, że nie wolno podłączać bezpośrednio RS-232 do naszego układu. Procesory ARM tolerują napięcia od 0V do 3.3V, więc podłączenie 11V mogłoby nasz układ uszkodzić. Aby temu zapobiec potrzebujemy tzw. konwertera napięć. Jest to specjalny układ, który napięcie -11V zamieni na 3.3V, a +11V na 0V. Na rynku dostępnych jest wiele tego typu układów, chociażby popularny max232. Podłączamy więc układ następująco: W naszym przypadku płytka ZL1ARM jest już wyposażona w odpowiedni konwerter napięć. Warto jednak pamiętać o odpowiednim podłączeniu, gdy będziemy chcieli budować własne układy. Płytka ewaluacyjna wyposażona jest w dwa gniazda RS-232, oznaczone COM0 oraz COM1. Jeden układ MAX232 wystarcza do konwersji napięć dla obu gniazd, a nasz układ LPC2114 wyposażony jest w dwa sprzętowe interfejsy zgodne ze standardem RS-232. Interfejsy te nazywane są odpowiednio UART0 oraz UART1. Interfejs UART0 połączony jest z gniazdem COM0, natomiast UART1 z COM1. Dotychczas już wykorzystywaliśmy łącze COM0 (UART0) do programowania procesora. Dodatkowe układy umieszczone na płytce ewaluacyjnej pozwalają na łatwe programowanie (zapewniają reset oraz uruchomienie bootladera). Wrócimy do nich później. Ponieważ COM0 jest zajęty przez programator, na początek wykorzystamy COM1 do komunikacji z komputerem PC. Łączymy wyjście COM1 naszej płytki z wolnym portem COM komputera. Ja wykorzystam przejściówkę USB<->RS232 ponieważ mój laptop nie posiada gniazda RS-232. Prędkość transmisji i format danych Łącze RS-232 pozwala na przesyłanie danych z różnymi prędkościami oraz w różnej postaci danych. Zastosujemy popularny format, czyli: 8 bitów danych, 1 bit stopu, brak kontroli parzystości oraz transmisji. Prędkość możemy ustawić dość dowolnie, zaczniemy od 9600 kbps, możemy zmienić na 115200 kbps jeśli chcemy szybciej przesyłać dane. Wysyłanie danych Na początek zdefiniujemy stałą, ustalającą prędkość transmisji: #define BAUDRATE 9600 Aby zmienić prędkość transmisji wystarczy przypisać jej inną wartość. Do rejestrów będziemy musieli wpisać wartość równą prędkości zegara peryferiów (pclk) podzielonej przez prędkość transmisji pomnożoną przez 16. Jeśli to zawiłe, wystarczy napisać: #define BAUDRATEDIVISOR (15000000/(BAUDRATE*16)) Wartość pclk wynosząca 15000000 (15MHz) pojawiła się w części poświęconej zegarom. Teraz musimy wpisać wartości konfiguracyjne do odpowiednich rejestrów. Więcej informacji jak zwykle znajdziemy w dokumentacji procesora: void uart1_init(void) { PCB_PINSEL0 |= 0x00010000; PCB_PINSEL0 |= 0x00040000; UART1_FCR = 1; //Set baudrate UART1_LCR |= 0x80; // DLAB = 1; UART1_DLL = BAUDRATEDIVISOR & 0x00ff; UART1_DLM = (BAUDRATEDIVISOR >> 8) & 0x00ff; UART1_LCR &= ~0x80; // DLAB = 0; //Set mode UART1_LCR = 0x03; //8 bit word length, 1 stop bit, No parity } Rejestry PINSEL odpowiadają za funkcję pełnioną przez dane wyprowadzenie. Domyślnie (czyli po resecie procesora) linie pracują jako wejścia-wyjścia, za pomocą podanego przypisania linia P0.8 będzie działać jako nadawanie (TxD), a P0.9 jako odbieranie (RxD) danych przez UART1. Następne instrukcje ustawiają prędkość oraz tryb transmisji. Gdy UART jest już skonfigurowany możemy zacząć wysyłać przez niego dane. void uart1_send_byte(unsigned char byte) { while(!(UART1_LSR & 0x20)); UART1_THR = byte; } Funkcja czeka najpierw na koniec poprzedniej transmisji (o ile trwała), po czym zapisuje do bufora kolejny bajt. Za cało transmisję odpowiada sprzęt. Będziemy wysyłać napisy, więc przygotujemy jeszcze jedną funkcję: void uart1_send(const char *s) { while (*s) { uart1_send_byte(*s); s++; } } Pozwoli ona na wysłanie całego napisu. Teraz możemy uruchomić program program17.zip i zobaczyć rezultat. Na PC powinniśmy uzyskać komunikat „Hello world!”. Kod programu jest bardzo krótki: int main(void) { pll_init(); timer0_init(); uart1_init(); while (1) { uart1_send("Hello world!!!\r\n"); } } Warto przy okazji zwrócić uwagę na program obsługujący port RS-232. Nie wszystkie działają równie dobrze. Polecam putty, dostępny za darmo pod adresem: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Rezultat działania programu widać poniżej: Komunikacja dwukierunkowa Skoro umiemy już wysyłać dane, czas spróbować dane odbierać. Poniższa funkcja będzie odpowiedzialna za odczyt danych z UART1 (COM1): unsigned char uart1_recv(void) { if ((UART1_LSR & 0x01)==0) return 0; return UART1_RBR; } W pierwszej linii sprawdzamy, czy są jakieś odebrane dane. Procesor LPC2114 ma wbudowany bufor dla odbieranych i wysyłanych danych o pojemności 16 bajtów. Dzięki temu nawet bez obsługi przerwań nasz program może działać całkiem sprawnie. Jeśli bufor odbiorczy jest pusty zwracamy 0. Jest to informacja dla programu głównego, że chwilowo brak danych. W przeciwnym przypadku odczytujemy daną z bufora i zwracamy jako wynik funkcji. Przykładowy program będzie odczytywał komendy 'a', 'w', 'd' oraz wyświetlał komunikat o wybranym kierunku jazdy robota. Oczywiście poza wysyłaniem komunikatu, należałoby odpowiednio wysterować silniki. while (1) { c = uart1_recv(); switch (c) { case 'a': uart1_send("a - Jazda w lewo\r\n"); break; case 'w': uart1_send("w - Jazda w prawo\r\n"); break; case 'd': uart1_send("d -Jazda prosto\r\n"); break; case 0: break; default: uart1_send("Nieznane polecenie\r\n"); break; } } W pliku Program18.zip znajdziemy kompletny kod przykładu. Poniżej rezultat działania: Program18.zip Program17.zip
  19. Dla częstotliwości 868MHz antena, tzw. ćwierćfalówka powinna mieć długość ok. 8,5cm. Czyli trzeba przylutować przewód o właśnie takiej długości. Ciężko mi jest powiedzieć o jakim konkretnie przewodzie mówisz, ale postaraj się użyć w miarę solidny.
  20. Szkoda, że pisząc o liczbach losowych autor nic nie wspomniał o matematyce - rachunku prawdopodobieństwa i statystyce. Warto wspomnieć jakie cechy powinien mieć dobry generator liczb. Nie każde źródło liczb pozornie losowych spełnia wymogi generatora. Np. wciskanie jednego przycisku wcale nie jest tak bardzo losowe - ludzie mają dość przewidywalny refleks i rozkład prawdopodobieństwa wcale nie jest jednostajny. Nawet dodawanie liczb "modulo" należałoby podeprzeć pewną dawką matematyki. Wybór podstawy dla działań modulo ma znaczenie. Przykładowo wybranie naturalnej dla timera i informatyki liczby 256 jest bardzo złym pomysłem. Podstawa działań modulo powinna być liczbą pierwszą - tego autor nie wspomniał, ani tym bardziej nie napisał dlaczego.
  21. Płytka była projektowana pod CC1000, ale później znalazłem inne moduły. Stąd pozostałe były podpinane "na pająka". Dokładniej na kynar-ek. Podłączenia są zdefiniowane w kodzie źródłowym: #define PORT_SEL PORTB #define PORT_SDI PORTD #define PORT_SCK PORTD #define PORT_SDO PORTB #define RFXX_SCK 6 #define RFXX_SDO 0 #define RFXX_SDI 7 #define RFXX_SEL 1 Nie wykorzystywałem sprzętowego SPI, więc nie było większej różnicy pod które piny I/O podłączyć. Wszystko i tak jest robione programowo.
  22. Gdy hamujesz silniki wzrasta płynący przez nie prąd. Często powoduje to obniżenie napięcia na procesorze i w efekcie jego reset albo zawieszenie. Musiałbyś wysłać schemat robota, ciężko coś doradzać bez tego.
  23. Prawdopodobnie problemem jest zasilanie. Dodaj kondensatory, powinno pomóc.
  24. Polecenia do BTM muszą się kończyć znakiem końca linii (CR), w C wystarczy wysłać \r. Bascoma nie znam, ale może jest coś jak Println, czy printline? [ Dodano: 27 Sie 10 01:57 ] może zadziała: Print "ATN?" ; Chr(13) ;
  25. Wniosek taki, że masz źle ustawioną częstotliwość pracy procesora. Działa 8x wolniej niż zakładasz. Czyli nie jak masz w kodzie 8Mhz, ale 1Mhz $crystal = 8000000 Spróbuj na początek zmienić kod na: $crystal = 1000000 A najlepiej ustaw odpowiednio fuse-bity.
×
×
  • Utwórz nowe...