Skocz do zawartości

kling

Users
  • Zawartość

    232
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    4

kling zajął 1. miejsce w rankingu.
Data osiągnięcia: 27 czerwca 2013.

Treści użytkownika kling zdobyły tego dnia najwięcej polubień!

O kling

  • Urodziny 02.02.1990

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Kraków / Łódź

Osiągnięcia użytkownika kling

Eksplorator

Eksplorator (8/19)

  • Za 100 postów
  • Za 5 postów
  • Za 25 postów
  • Młodszy Juror
  • Wschodząca gwiazda

Odznaki

19

Reputacja

  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. Wystarczy wywołać: make all
  11. 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.
  12. @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.
  13. 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ę.
  14. 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.
  15. @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.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.