Microchip mnie dziś zaatakował reklamowo czymś takim :
Sławek
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...
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?
*Nie* mam potrzeby pisania dla dsp. Dlatego sprzętowy stos denerwuje mnie niezmiernie w *normalnych* aplikacjach. Bo np. cholernie utrudnia preemptive multitasking. Nie wiem czy w ogóle sa jakieś rozsądne implementacje tego na PICe.
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
30kB flash i 1kB RAMu. Słaba jest niestety dokumentacja samego stosu. Spece z microchipa natrzepali za to prezentacji jak zrobić sobie serwer http i własne dynamiczne stronki.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.
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.