Re: Zbiór narzędzi dla C++ i darmowy system operac

Przypuszczam, ze tak, ale JTAG nie jest ci potrzebny, chyba, ze w

> jakiejs sytuacji ratunkowej. Na plytce masz normalny OS, wiec twoje > programy to tylko aplikacje.

No nie wiem. Jakos nie moge sobie wyobrazic aby wszystko "debugowac printfami"...

Reply to
Krzysztof
Loading thread data ...

A ja JTAGa:) Zauwaz, ze predkosc jego dizalania jest koszmarna, wiec jak mialby na tym dzialac OS. Poniewaz masz zwyklego linuxa wiec swoja aplikacje mozesz debugowac na PC. Chyba ze piszesz cos zupelnie low-level, ale wtedy spora czesc mozesz przesledzic w AVR Studio, lub wykorzystac JTAGa.

Reply to
T.M.F.

Po zo takie kombinacje ? Jak na plytce jest linux i ethernet to wystarczy wrzucic monitor GDB na plytke, podlaczyc sie po sieci i debugowac za pomoca GDB (eclipse, insight, ddd lub inne)

Swoja droga, autor watku wspominal o czyms malym z RTOS-em. A tu juz propozycje linuxa na AVR32 lub ARM padaja :) Ja bym proponowal AVR + FreeRTOS + avrgcc na poczatek. RTOS jest darmowy i calkiem przyzwoity, jest troche przykladow na stronie. Do tego jako platforme jakis ATmega64/128 + debugger - moze byc AVR Dragon z Atmel-a - fabrycznie ma ograniczenie bodajze do 32kB pamieci Flash, ale na forum

formatting link
widzialem opis jak to obejsc.

Ewentualnie, jak ktos wspominal juz, ARM7 z dowolej firmy + arm-gcc + eclipse + openoscd + jtag na usb (usbkey np.) Predkosc ladowania JTAG-iem przyzwoita, wygoda pracy niepoorownywalnie wieksza niz z prinf-em:), choc sa sytuacje, w ktorych printf pomaga bardziej niz JTAG.

Pozdr AK

Reply to
AK

AK pisze:

printf pomaga bardziej niż JTAG zawsze gdy nie możesz ot tak po prostu zatrzymać procesu a trzeba podglądać co się po drodze dzieje. Większość przypadków to urządzenia real-time, np. telefon komórkowy podczas rozmowy. Gdy zatrzymasz procesor - od razu wywala się synchronizacja portu przesyłającego dźwięk do modułu GSM. Właściwie to JTAGiem można sobie prześledzić jakieś bardziej niskopoziomowe mechanizmy (krok po kroku działanie schedulera czy semaforów w systemie), ale do śledzenia co się dzieje z aplikacją, która nie może być zatrzymana - przydatny nie jest zupełnie. Ja wolę zdebugować co się da na pececie (tzn. kod w C przeznaczony dla ARMa - tyle ile się da - odpalić np. w MSVC++) a resztę dopieścić printf'ami na właściwym urządzeniu. Inaczej po prostu czasem się nie da (ew. zamiast printf'ów można by wymyślić inne mechanizmy w sposób nieblokujący zrzucające kawałki pamięci urządzenia do peceta).

Reply to
Adam Dybkowski

Mozna, ale mam uraz do GDB. Uruchomienie tego zakrawa o magie.

Nie wspominal o czyms malym z RTOSem, tylko o czyms z wbudowanym OSem. Ale nie to jest istotne, za plytke z AVR zaplaci tyle co za NGW100, ktory ma nieporownywalnie wieksze mozliwosci niz AVR. Prawde mowiac za cene zabawek z AVR mozna kupic devboard ze spartanem majacym 1M bramek, do ktorego mozna wrzucic core AVR (za free z opencore), lub nawet jakiegos opensparca i miec za ta kase zabawke do powaznych rzeczy z embedded linux jak i prostych z AVR. A gratisowo fajna plytke do nauki np. VHDL, albo testowania pomyslow opardych o "dyskretne" uklady cyfrowe.

Reply to
T.M.F.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.