Microchip Microstick

Sławomir Szczyrba pisze:

I tak trzymaj ;) Microchip ma kilka fajnych bardzo niedrogich(!) narzędzi wydatnie wspomagających uruchamianie. Ostatnio przygotowując "wkład do kontenera na elektrośmieci" natknąłem się na domowej roboty sprzętowy zestaw uruchomieniowy dla 8052 składający się z wersji piggyback tego procesora oraz emulatora epromów na porcie równoległym. Oczywiście zero debuggingu, tylko analiza problemu i szybkie przeładowanie pamięci i tak w kółko, aż do skutku. I pomyślałem sobie, jak ja mogłem na tym cokolwiek zrobić, nie mając do dyspozycji możliwości pracy krokowej, pułapkowania, podglądu zasobów itp.

Dalej produkuje procesory ze sprzetowym stosem ;) ? Bo w dzisiejszych czasach to takie niefajne że żadne narzedzia tego nie rekompensują ;)

Sebastian Biały pisze:

Microchip robi i takie procesory jakie były 15 lat temu i takie zaprojektowane pod katem programowania w C.

Dlatego pytam, sprzetowy stos jest kluczowym problemem który mnie od tego wynalazku odrzucał w kierunku AVR. Może się coś zmieniło.

No i jeszcze brak gcc...

No i chyba, ale moze sie myle, w niektorych prockach byl jeszcze problem, ze pomimo ustawien zabezpieczen przed odczytaniem kodu i zrobieniem klona dalo sie jednak wyciaganc kod przez JTAG'a.

W dniu 2010-07-27 20:25 Sebastian Biały napisał(a):

Oj chyba nie pisałeś nigdy nic dla DSPków. Sprzętowy stos to bardzo często stosowany zabieg - oczywiście sensowne kompilatory C sobie z tym bezproblemowo radzą (przeznaczając jeden rejestr ogólnego przeznaczenia na wskaźnik stosu).

Yup. Coś się zmieniło w tej kwestii w ciągu ostatnich 10 lat? Czymże super skomplikowanym jest architektura i asembler PICów, że jeszcze nikt nie zrobił portu gcc?

Hmmm chyba nie o tym mówie kiedy mam na myśli sprzetowe stosy ;) nie wiem jak to teraz wygląda w PICach, wlasnie chciałbym się dowiedzieć, może warto się przeprosić.

Bo PIC jest mocno nienormalny w porównaniu z "reszta świata"?

Wystarczy wejść na stronę Microchipa żeby w ciągu 5 minut znaleźć odpowiedzi na Twoje pytania. Mnie programowanie uC w C zupełnie nie interesuje, więc nie powiem nic więcej na temat szczegółów.

Wystarczy wejść na stronę Microchipa żeby w ciągu 5 minut znaleźć odpowiedzi na Twoje pytania. Mnie programowanie uC w C zupełnie nie interesuje, więc nie powiem nic więcej na temat szczegółów.

Wystarczy wejść na stronę Microchipa żeby w ciągu 5 minut znaleźć odpowiedzi na Twoje pytania. Mnie programowanie uC w C zupełnie nie interesuje, więc nie powiem nic więcej na temat szczegółów.

Wystarczy wejść na stronę Microchipa żeby w ciągu 5 minut znaleźć odpowiedzi na Twoje pytania. Mnie programowanie uC w C zupełnie nie interesuje, więc nie powiem nic więcej na temat szczegółów.

Sebastian Biały pisze:

Wystarczy wejść na stronę Microchipa żeby w ciągu 5 minut znaleźć odpowiedzi na Twoje pytania. Mnie programowanie uC w C zupełnie nie interesuje, więc nie powiem nic więcej na temat szczegółów.

W dniu 2010-07-27 21:57 Andgro napisał(a):

Dobrze, że dobitnie 5 raz dałeś nam o tym znać.

Od paru miesięcy interesowalem się tematem na zasadzie "i jak tam?". Wiem, że pice 18 mają jakieś ficzery pozwalające uzyskac preemptive multitasking w sposób rozsądny. Jednak materiały reklamowe mają się średnio do rzeczywistości i dlatego interesuje mnie opinia kogoś żywego.

W tym rzecz właśnie. Podobnie jak marketoidalne bzdury ze stron producentów kontra nudne lektury po 2000 stron dokumentacji. Po prostu chce poznać opinie kogoś kto w tym robi, że "już czas zerknąc na PICe" bo staly się bardziej normalne.

Czas sie zastanowic czy dalej rzezbic w gownie czy skoczyc klase wyzej !

Adam Dybkowski pisze:

Ale zaraz potem skasowałem. Serwer TPSA twierdził, że odrzuca mój post, a okazało sie że jednak go puszczał.

Andgro przemówił ludzkim głosem:

Ostanio mam okazję pobawić się microchipowymi narzędziami do PIC18, ichnim stosem tcp/ip i muszę powiedzieć, że mam mieszane uczucia. To co cieszy to rzeczywiście niska cena PicKita (programator-debuger). Ale software jest już lekko denerwujący. MPLAB wygląda jakby zatrzymał się w rozwoju jakieś kilkanaście lat temu, wszystkie okna są luźne.

Kompilator microchipa C18 łyka tylko C89, o udogodnieniach z C99 można zapomnieć. Gadzina potrafi się pruć, że do funcji biorącej (void *) próbujemy przekazać (BYTE *), nie generuje warningów o nieużywanych zmiennych, choć je usuwa.

Debuger w zasadzie działa, ale bardzo często przy zmiennych lokalnych w funkcjach pokazywał mi "out of scope" i musiałem tworzyć zmienne globalne. PIC18 ma tylko 3 sprzętowe pułapki, 1 jest używana do pracy krokowej, więc do użytku zostają tylko dwie - jak na mój gust mało.

Co do samego stosu tcp/ip, to działa całkiem sprawnie i ma małe wymagania. Aplikacja z klientem DHCP i komunikacją po UDP zjada mi około

Sebastian Biały pisze:

Już byś dawno wiedział, gdybyś potrzebował. Ale wolisz czekać aż ktoś odrobi lekcje za Ciebie? Nie handluje PIC-ami wiec ja tego za Ciebie nie zrobię, bo nie mam motywacji. Mogę tylko powiedzieć, że hasło "zaprojektowane specjalnie dla tworzenia oprogramowania w języku C" widziałem na stronie Mchipa juz dawno. Nic więcej nie wiem, bo jak juz wspomniałem, nie jestem tym zainteresowany. W moich urządzenia uC pełnia rolę pomocnicza dla analogówki i często są to wymagające systemy czasu rzeczywistego, gdzie zrzucenie roboty na crosskompilator nie ma sensu o ile w ogóle jest możliwe. Albo tak proste programy na kilka ekranów, że pisze je jedną ręka mieszając drugą herbatę w szklance.

Zbych pisze:

Do programowania flasha masz przycisk na belce komend a pice 18 mają 3 pułapki sprzętowe. Nie wiem, może kompilator C jedna z nich sobie zabiera? Ja używam wszystkich 3. Do zaawansowanych aplikacji i takich które sie zwrócą w produkcji należy używać symulatora sprzętowego. Debugger za 500zł - nie oczekujmy cudów.