Skocz do zawartości

kling

Użytkownicy
  • Zawartość

    232
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    4

Wszystko napisane przez kling

  1. Nie wydaje mi się, żebyś wykonał taki zestaw taniej: moduł radiowy ~20, procesor ~ 10, płytka ~ 10 to daje 40 złotych. Potrzebujesz do sterowania 2 takie zestawy to już jest minimum 80 złotych. Do tego jak nie masz doświadczenia w projektowaniu i programowaniu takich układów to zajmie Ci to sporo czasu. Jednak możliwości będą znacznie większe. Z drugiej strony możesz kupić prosty samochodzik zdalnie sterowany za około 50 PLN'ów i spróbować z wyciągnąć odbiornik. Jednak takie samochody mają tylko dwa kanały. Możesz też iść w stronę gotowych standardów (Bluetooth, ZigBee itp) ale to na pewno wyjdzie jeszcze drożej. A tu za stówkę masz zestaw plug and play;)
  2. RFM12B to zdecydowanie nie jest gotowy moduł zdalnego sterowania. Stworzenie zdalnego sterowania na tym module dla początkującego może być dosyć kłopotliwe. Polecam zainteresować się aparaturami modelarskimi (np: HobbyKing_HK6S_2_4Ghz). Osobiście nie ma z nimi żadnych doświadczeń, ale to chyba jest to co Cię interesuje.
  3. No ale przecież pamięci nie zerują krasnoludki;) Jakiś fragment kodu (c startup) musi o to zadbać Jeżeli chodzi o zmienne lokalne to tu masz racje;)
  4. No to w takim razie powinno być ok;) Standard języka C określa, że niezdefiniowane zmienne globalne oraz statyczne mają wartość początkową równą '0'. W związku z tym, przypisując kolejne adresy zmiennym globalnym kompilator musi mieć pewność, że w te konkretne miejsca w pamięci będą zawierały zera. O to między innymi dba c startup, wykonywany po resecie, a przed funkcją main;)
  5. Pomiędzy resetem a main() jest jeszcze kawałek kodu inicjalizujący środowisko C. Patrz: C Startup. Nie wiem jak dokładnie działa to w AVR'ach, skoro ich bootloader jest na końcu, trzeba byłoby zajrzeć do dokumentacji;) No ok, ale bootloader też ma swoje zmienne, które powinny zostać zaincjalizowane. Istotne wydaje się być czy wykonasz skok do funkcji main w bootloaderze czy do adresu pod którym będzie inicjalizacja środowiska dla booloadera.
  6. Jeżeli nie skoczysz pod adres wektora resetu, to nie zostanie wykonana inicjalizacja procka, a tym samym zerowanie i ustawianie zmiennych globalnych. Jeżeli obie aplikacje są napisane w takie sposób, że współdzielą pamięć RAM (a zapewne tak jest) to zwykły skok pod adres z funkcją main() bootloader'a może nie zadziałać. Dlatego właśnie wykonuje się resety procka lub skacze, ale pod adres 0x00000000 (adres resetu).
  7. Nie wiem czy AVR Studio ma możliwość download'u wcześniej skompilowanego programu. Jeżeli tak, to wystarczy podać mu ścieżkę do pliku *.hex utworzonego po wywołaniu Make'a. Jeżeli nie, to musisz użyć avrdude - w necie jest wiele step by step jak z niego korzystać Jeżeli chodzi o bootloader i RAM to widzę to tak: Zarówno w bootloaderze jaki i w aplikacji definiujemy sekcję w RAM'ie pod konkretny adresem, z flagą NOCLEAR. Spowoduje to, że w momencie resetu i wykonywania się startup'u proca sekcja ta nie będzie zerowana. Następnie tworzymy zmienna (flagę) właśnie w tej sekcji w bootloaderze jaki i w aplikacji. Będzie to współdzielony obszar przez oba programy, za pomocą którego będą mogły się komunikować między sobą. Teraz uruchamiając bootloader sprawdzamy najpierw czy w pamięci flash jest aplikacja (sposób dowolny, ja wykorzystuje magic numbery ). Jeżeli nie ma aplikacji, czekamy w bootloaderze aż ktoś ją nam wyśle;) Jeżeli jest aplikacja to sprawdzamy flagę we wspólnym obszarze RAM'u. Jeżeli jest ustawiona to czekamy na nową aplikację od operatora, jeżeli nie skaczemy do aplikacji. W aplikacji dostając rozkaz flash'owania ustawiamy flagę i wykonujemy software reset (np watchdog'iem). Po resecie uruchomi się bootloader i sprawdzi naszą flagę, która nie będzie wyzerowana w czasie resetu. Takie podejście oszczędza miejsce we flashu', które musiały by wykorzystać biblioteki do obsługi/emulacji eepromu. Mam nadzieję, że w miarę jasno opisałem koncepcję
  8. Wydaje mi się, że Makefile musiałby być napisany zgodnie z regułami AVR Studio. Przynajmniej eclipse nie łyka różnych makefilów.
  9. Jak to ma się 'nic' nie wywoływać? A kompilacja? "make all" wpisujesz w konsoli, bedąc w katalogu z plikiem Makefile. Pamietaj, zeby w zmiennej środowiskowej $PATH dodać Make'a. Swoją drogą, jak do tej pory Ty to kompilowałeś? @OldSkull Opiszę pomysł dzisiaj wieczorem;)
  10. Zapisywanie i odczyt flagi w EEPROM'ie nie wydaje się byc najszczęśliwszym pomysłem. Wymaga to wykorzystania bibliotek do obsługi EEPROM'u, co zwłaszcza w bootloaderze zajmuje cenne miejsce. Moim zdaniem lepiej stworzyć małą sekcję gdzieś w RAM'ie pod konkretnym adresem z flagą NOCLEAR. Wtedy obszar ten nie będzie zerowany pomiędzy resetami proca. Wtedy po podaniu zasilania, bootlader sprawdza czy aplikacja jest na miejscu, jeżeli tak to ją wywołuje. Jeżeli rozkaz flashowania przyjdzie w momencie działania aplikacji to ustawia ona tą flagę w RAM'ie i resetuje proca. Następnie bootloader sprawdza tę flagę i mimo obecności aplikacji rozpoczyna flashowanie. Co do drugiegp pytania - tak. Wywołując make z komendą flash najpierw program zostanie skompilowany a następnie wgrany do procesora.
  11. @wojttar w takim labiryncie kwestią sporną może być ścinanie zakrętów, jazda po przekątnej i tak dalej. plusem jest, koszt wykonania takiego labiryntu i możliwość testowania robota poza zawodami. Jednak myślę, że bliżej temu do FTL'a niż MM.
  12. Moim zdaniem dotychczasowe LFE to dosyć kiepski pomysł. Jedyną ciekawą przeszkodą jest cegła, ktorej poprawne ominiecie (nie na zasadzie timer'a) znacznie zwiększa koszty robota (czujnik odległosci, enkodery). Tak więc za rezygnacją z LFE podpisuję się jak najbardziej. Co do LF'a - macie rację, że można to zrobić i na standardowej konstrukcji uwzględniając zmiany w programie. Jednak czy osoba, która dopiero co dowiedziała się jak działa mostek H i zbudowała coś, co z trudnością pokonuje zwykłą trasę da sobie radę? Obawiam się, że może ją to zniechęcić. @baton I przynajmniej będzie można sprawdzić roboty w pełnowymiarowym labiryncie - mało kto ma w domu labirynt 16x16;d Żeby było sprawiedliwie i tak labirynt przed właściwymi przejazdami powinien się zmienić. Jeżeli chodzi o trudność wykonania, to opisany własnie Speedy zaprzecza temu;) Myślę, że trzeba sobie również odpowiedzieć na ważne pytanie: do kogo skierowane są te zawody. Można zrobić ukłon w stronę 'elit', dając coraz to trudniejsze konkurencje, ale mnie widowiskowe. Z drugiej strony, można starać się zrobić show, trafiając do większej rzeszy ludzi - popularyzować robotykę.
  13. Z MM jest jeszcze jeden problem. Z racji niewielkiej ilości konstrukcji i limitowanego czasu przejazdu niewiele się tam dzieje. Może warto udostępniać labirynt przez luźniejszą część zawodów, nawet klasyfikować jakoś czasy poszczególnych przejazdów (bez wpływu na ostateczny wynik konkurencji), po czym 'przemieszać' labirynt na eliminacje/finały. Może nieco spopularyzowało by to konkurencję? Podobny system był w Łodzi, gdzie dzieciaki przez większość czasu testowały swoje konstrukcje, dopiero na finał został zmieniony labirynt i jeden możliwy przejazd. Wtedy przy labiryncie było sporo ludzi przez większość zawodów.
  14. @sobal To tym bardziej nie rozumiem, dlaczego odcinać początkujących od prestiżowych konkursów. Nie sądzę, żeby popularność robotyki amatorskiej w Polsce była na tyle wysoka, żeby móc 'ograniczać' dostęp do prestiżowych zawodów komukolwiek.
  15. Fajnie, że podejmujecie inicjatywę tworzenia czegoś nowego. Oby jak najwięcej z tego się przyjęło;) Ale co z tradycyjnym FTL'em? Chcecie zupełnie z tego zrezygnować? Moim zdaniem właśnie od tej kategorii zaczyna większość osób, poznaje atmosferę panującą na zawodach i zyskuje chęć tworzenia kolejnych konstrukcji. Usunięcie tej konkurencji może znacznie utrudnić nowym ludziom dołączenie się do grona robomaniaków.
  16. Strasznie ogólnie opisujesz swój problem. Podaj więcej szczegółów (target, programator, system operacyjny) oraz pokaż kod, który nie działa i wtedy może uzyskasz pomoc. Nie wydaje mi się, że ktoś z kolegów potrafił wróżyć z fusuów;)
  17. Jakich błędów nie potrafisz obejść? Brak LPT nie jest problemem, za <50 PLN kupisz programator USB, który bez problemów śmiga na linuksie (Debian, Arch). Kurs, do którego podajesz link, bardzo dobrze wprowadza w świat programowania uC w C, sam od niego zaczynałem.
  18. Spacje i polskie znaki w ścieżkach dostępu. Kompilator i inne narzędzia średnio to lubią
  19. Jak masz taką strukturę katalogów, to spróbuj takiego zapisu: #include "../ADC/ADC.h" //lub #include "ADC/ADC.h"
  20. A gdzie masz ten plik ADC.h? nie widzę go w drzewie projektu.
  21. Zbadałem temat i warto zainteresować się asemblerem. Tam trochę lepiej opisane są tego typu tajniki programowania. Jednak temat pozostawiam otwarty, może ktoś podrzuci inne ciekawe podejście do tematu.
  22. Są zależne od języka. Od języka angielskiego Nie wydaje mi się, żeby żadna dobra książka z tej tematyki była solidnie przetłumaczona. Niestety nie znam żadnej wartościowej pozycji, ale myślę, że powinieneś poszukać/zapytać na angielskich forach. Niekoniecznie musi być po polsku. Zrobiłem trochę rozeznanie i widzę, że taką wiedzę zawierają książki o ... hakerstwie;) Jeżeli nikt nie ma lepszych propozycji, to na trochę zostaję hakierem;d Myślałem, ze dosyć wyraźnie zaznaczyłem, że nie chodzi mi o tradycyjne podejście do nauki programowania. Oczywiście książkę Pana Grębosza znam i cenię, jednak interesujące mnie tematy zostały tam potraktowane bardzo pobieżnie, a inne nawet w ogóle pominięte.
  23. Słuchajcie, szukam książki, gdzie poruszony jest temat programowania w trochę inny sposób niż zawsze. Chodzi mi o pozycję, gdzie znajdę wyjaśnienie różnicy między stosem a stertą, możliwości komunikacji między procesami, parę słów o wątkach itp. Nie wydaje mi się, aby w.w. zagadnienia były zależne od języka, ale jeśli się mylę, to zależy mi na powiązaniu z C/C++. Z góry dzięki za wskazanie jakichkolwiek wartościowych pozycji;)
  24. Podpisuje się pod tym co napisał OldSkull. Dodatkowo fajnym pomysłem, nie tylko dla robotyków, byłoby stworzenia czegoś podobnego do BusPirate. Może nieco mniej zaawansowane ale tańsze. I najlepiej na AVR, z otwartym źródłem, żeby łatwo można było dokonywać zmian.
×
×
  • Utwórz nowe...