Warto kupić ? C dla PIC

formatting link
Zastanawiam się nad przejściem na C dla PIC czy z tej książki będę w stanie się nauczyć? Wcześniej programowałem tylko w asemblerze na różne mikrokontrolery i PC+pascal. Ale widzę że C zaczyna dominować. A za godzinkę wybieram się do księgarni i nie wiem czy warto?

Reply to
xymax
Loading thread data ...

Witam,

Dla których modeli PIC bo poniżej PIC18 to chyba mija się z celem. I co dokładnie można rozumieć, że "C zaczyna dominować". Jeśli póki co programowałeś w asemblerze i projekty spełniały założenia to nie ma co się na siłę pchać w C. Chyba, żeby traktować to jako eksperyment czy też doświadczenie. Ciągle jednak asembler dla średnich i małych PICów jest chyba najlepszym rozwiązaniem. Te procki są tak prymitywne (co jest akurat zaletą!), że nawet te kilka "wybryków" jakie mają nie przeszkadza w programowaniu ich (można się szybko przyzwyczaić i nawet polubić - np. adresowanie tablic w pamięci programu poprzez zmiany PC i retlw, fajne!)

Pozdrawiam,

Radek

Reply to
Radek

xymax napisał(a):

Nie wiem czy zaczyna dominować. Na pewno jest bardzo atrakcyjny dla osób, które programują w C i boją się sprzętu. Czyli dotyczy osób z zacięciem informatycznym a nie inżynierskim. I - jak kolega już napisał, programowanie w C nie ma sensu dla małych (najciekawsze aplikacje) i średnich kontrolerów - strata czasu oraz pamięci i wydajnosci procesora. Jeśli będziesz używać makr w asemblerze, uzyskasz ten sam efekt co w C a nie stracisz na nieprzewidywalnosci kodu po crosskompilatorze.

Reply to
A.Grodecki

Witam,

Tu można by polemizować czy rzeczywiście C jest od tego sprzętu taki daleki (ze wskaźnikami i operatorami bitowymi)? W końcu trzeba zauważyć, że to nie nie tylko sam język robi tą "izolację" a także biblioteki, które są z nim dostępne. A raczej wątpie czy w tych kilka KB flash dla instrukcji da się upchać upchnąć cokolwiek dającego porównywalne możliwości chociażby do "stdio.h".

Właściwe moje doświadczenie z PIC ogranicza się póki co tylko do symulatora misim. Napisałem w nim realizację pewnej funkcji, którą wcześniej wykonałem na bramkach cmos. Na początku było trochę dziwnie tego PICa programować ale... po dwóch dniach piszę już w jego asemblerze w miarę płynnie.

I muszę przyznać, że architektura PIC w swojej pokraczności w niczym nie przeszkadza. Bo jest tak prosta, że wystarczy jedna strona z opisem instrukcji PICa aby mieć wgląd na to jak działa, co trzeba teraz zrobić, jak optymalnie podejść do napisania danej procedury, etc.

Chcę także napisać, że solidnie napisany kod w asemblerze nie musi być nieprzejrzysty. Sam napisałem kilka programów w Pythonie, których miałem później problem zrozumieć. Dobry styl programowania to rzecz niezależna od języka.

Chyba zrobię sobie jakiegoś NOPPPa i poużywam PICa bardziej praktycznie.

:)

A w zasadzie to najciekawsze jest kombinacja µC + PLD. Np. -

formatting link
(bardzo intrygujące imho)

Pozdrawiam,

Radek

Reply to
Radek

Radek napisał(a):

Nie bez powodu Microchip oferuje niektóre procesory jako "optymalizowane dla C" czytaj "mające sens z C" :) Dlaczego firma promuje C? Bo to sie dobrze sprzedaje. Tylko i wyłącznie. Tak samo jak dobrze sprzedają się nowości, w efekcie czego Microchip zaczyna wypuszczać nieprzetestowane porządnie padliny. Takie czasy, wszystko schodzi na psy - sprzęt i ludzie. Filozofia Microsoftu wygrywa... Nie wiem co jest w sdtio.h, ale na pewno więcej niż normalnie potrzeba i zajmuje więcej miejsca niż powinno zajmować to, co jest dokładnie potrzebne. No i wiele procesorów ma dużo mniej niż kilka kB pamieci programu ;)

2 dni? No to masz jeszcze troszkę za mało doświadczenia z tymi rdzeniami. Ale poczekaj, kiedy zaczniesz trafiać na kłopoty z zachowaniem programu (niektórych funkcji w niektórych procesorach), zobaczymy jak się z tego wygrzebiesz pisząc w C :)
Reply to
A.Grodecki

Witam,

Dlatego jeśli będę używał PICa to tego 14-bitowego. :)

Choć dsPIC ma kilka ciekawych funkcji jak multiplicator ale i tak dedykowane DSP będzie lepsze więc po co się w to pakują?

Tak samo z AVR... dorobili się nawet własnego 32 rdzenia tylko po co? Czy stary dobry (i sprawdzony - umiem jego asembler także) Arm jest aż tak gorszy?

Rozumiem, że ludzie mogą nie lubić asma i chcieliby coś w rodzaju basica. Przecież stare 8 bitowe komputery miały wbudowane jego interpratory w zasadzie standardowo. Może by to nie był głupi pomysł dodać z 8KB rom na właśnie BASIC bezpośrednio w samym chipie?

Właściwie te podstawowe modele od Microchipa czy Atmela są jak te stare

8 bitowce. Mają niestety o wiele mniej pamięci ale za to niektóre z nich o wiele więcej mipsów. To trochę dziwne czyż nie?

Duża wydajność przydaje się przy przetwarzaniu większej ilości danych ale aby móc to robić trzeba gdzieś je zmieścić. A tu nie ma gdzie więc do czego choćby te 20mipsów w układzie, którego pojemności pamięci jest bardzo mała?

Ale to nie ja piszę w "C"! :)

Czysty asembler i nic ponad to - jeśli PIC to tylko asm!

C to tylko od ARM w górę i to często z stawkami inline asembler.

PICa rozpatrywałem głównie z ciekawości jako zamiennik (uproszczenie) niektórych potrzebnych mi funkcji logicznych realizowanych wcześniej przez bramki cmos. I muszę napisać, że zaletą µC jest głównie elastyczność w przyporządkowaniu pinów I/O bo można je oprogramować tak jak się chce (z niedużymi wyjątkami). To jest dobre dla projektu płytki drukowanej oczywiście choć kosztem wchodzenia w software i o wiele większych opóźnień.

Docelowo planuje używać CPLD/FPGA ale zainteresowałem się "po drodze" µC bo czemu nie?

Imho kierunek, w którym idzie Microcip jak i Atmel będzie zgubny bo w końcu choćby taki Arm będzie równie tani więc po co marnować zasoby na jakieś własne wynalazki w tym kierunku? - µC powinien być "µ" tak jak tylko można - "klasyczne" PICe realizują to założenie bardzo dobrze. Wolałbym mieć lepszą tolerancję np. na napięcia zasilające/IO niż np. więcej mipsów bo sens tych układów nie leży w obróbce danych tylko upraszczaniu projektów.

Pozdrawiam,

Radek

Reply to
Radek

Użytkownik "xymax" napisał w wiadomości

No i kupiłem poczytałem trochę i C się z tej książki niestety nie nauczę :( Jest to moja druga książka z BTC i raczej nazwał bym ją powtórką z "Mikrokontrolery PIC 16H8x w praktyce". gdzie w przystępny sposób jest opisane programowanie.

Dziękuję wszystkim za odpowiedzi

Reply to
xymax

Radek napisal(a):

Odpowiedz - $$$. Atmel za ARMa musi placic royalties.

Reply to
Marcin E. Hamerla

A.Grodecki napisal(a):

E tam. W C pisze sie kilka razy szybciej i znacznie wygodniej. A i zasobow nie zzera dramatycznie wiecej.

Reply to
Marcin E. Hamerla

Marcin E. Hamerla napisał(a):

Już to wałkowaliśmy :)

Reply to
A.Grodecki

To nie tylko C - praktycznie kazdy jezyk "wyzszego poziomu" bardzo kiepsko sie implementuje na ubogiej architekturze 8-bitowej, za to calkiem niezle juz od poziomu 8086, a nawet Z80.

A to pozniejsi nabywcy kosci wybieraja te jezyki .. czemu sie zreszta nie ma co dziwic.

W zastosowaniach embeded w zasadzie nie powinienes w ogole uzywac stdio.

J.

Reply to
J.F.

Radek napisał(a):

o są właśnie te "średnie" :)

Prostych układów używa się z tego samego powodu, dla którego nie strzela się z armaty do muchy na ścianie.

Pomijając kwestie cenowe ostatecznego produktu, żaden interpreter nie daje optymalnego kodu. Basic, C, bez różnicy. Każdy program po translacji będzie niedoróbą - większy i WOLNIEJSZY.

To zależy od częstotliwości taktowania głównie. Ale - masz podejście pecetowca. Mipsy to nie wszystko. Kiedy potrzebne są mipsy to się szuka rozwiązań w tym kierunku. Popatrz jakie one mają peryferia! Żadne jednoukładowce wcześniej nie miały zwykle nic poza co najwyżej ADC i USART.

Wcale nie wiekszej ilości. Różnie bywa.

Zamiast bramek nie wkłada się uC, tylko PLD, chyba że zadowolisz sie dużo niższym poziomem pewności.

Sens wszystkich układów scalonych w tym się zamyka. I dlatego bardziej ważne są peryferia niż mipsy. A co przyniesie przyszłość - pokaże czas. Moim zdaniem zaczną powoli dominować dsPice i im podobne, czyli 2 w jednym.

Reply to
A.Grodecki

Użytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisał w wiadomości news:e0hmj3$1lp$ snipped-for-privacy@atlantis.news.tpi.pl...

Zdecydowanie się nie zgadzam. Nie wiem, czy w ogóle pisałeś w C pod PIC, skoro piszesz takie rzeczy, ale zważ, że:

1) Ta superprosta architektura PIC-a wymaga wykonywania wielu upierdliwych czynności, jak choćby pilnowanie banków pamięci. 2) C pod PIC-e to jednak nie to samo co C pod PC-ta. To pewien podzbiór funkcji, z bardzo ograniczonymi bibliotekami oraz z funkcjami specyficznymi dla danego hardware - i jest bardzo wydajny. Program nie jest może tak piękny jak pod PC-ta, albo nawet '51, ale trzeba mieć na względzie, jaki się ma procesor. 3) Żeby zachować jakieś podobieństwo do "prawdziwego" C producent przewidział obsługę struktur, wskaźników, zaimplementował printf() itd, ale to jest kwestia użytkownika, czy chce z tego skorzystać, czy nie. Wystarczy wiedzieć, jak prymitywna jest obsługa adresowania pośredniego, by wyciągnąć odpowiednie wnioski co do konstrukcji programu. Wystarczy wiedzieć, że nie ma sprzętowego mnożenia, żeby nie nadużywać go w programie. Itd. Jeśli ktoś jest na to ślepy, bo uważa, że C jest daleko od sprzętu i generalnie go nie obchodzi, jak procek to wykona, to może mieć pretensje tylko do siebie.

entrop3r

Reply to
entroper

Raczej osób które cenią swój czas.

Reply to
point

Witam,

Czy to jest wielki problem raz do czasu zrobić BCF/BSF dla rejestru STATUS?

Nie widzę tu więcej upierdliwych rzeczy niż było jeszcze np. w 80286 z rejestrami segmentowymi. Zawsze można także skorzystać z makr asemblera.

Pozdrawiam,

Radek

Reply to
Radek

Witam,

Nie o to chodzi, że kod ma być zawsze optymalny tylko czego oczekują klienci. Rozglądałem się trochę po różnych forach dotyczących µC i sam się zdziwiłem jak wielu używa takich rzeczy jak np. bascom. Widać, że jest zapotrzebowanie na takie narzędzia pomimo wszystkich ich wad.

Pisałem, że mi się to właśnie podoba przecież! :)

I dlatego nie mogę się doczekać tych Xilinxów, które niedawno zamówiłem. Jednak jakoś nie widziałem CPLD w obudowie DIP14 kiedy µC tak. A stare GALe ciągną niestety zbyt wiele prądu więc µC jest względnie atrakcyjne tutaj. Przynajmniej dla mojego małego projektu pod każdym niemal względem wybrałbym µC zamiast CPLD.(a skończyło się na przystosowaniu demultipleksera cmos)

No właśnie - i fakt, że można (prawie) dowolnie oprogramować każdy pin jest bardzo użyteczne. Nie musiałbym się tak natrudzić z trasowaniem ścieżek jak to robiłem z bramkami cmos. Ale wolałbym PLD zastosować oczywiście tylko, że te które udało mi się znaleźć w odpowiadającym mi opakowaniach (DIP14) żarłyby o wiele zbyt dużo prądu.

Pozdrawiam,

Radek

Reply to
Radek

zagodze sie z tym wiele lat pisalem w ASM pod AVR i 8051, balem sie C jak ognia, mimo ze na PC pisalem rozne rzeczy. Niedawno musialem zrobic na szybko projekt na AT90PWM3, znaczne czesci kodu dostarczal producent w postaci biblitek w C. Bylem zaskoczony, gdy uklad precyzyjnego falownika, z obsluga LCD,klawiaturki, UART, tablica sinusa z

512 wpisami (cwiartka,wartosci 16bit) udalo sie upchnac w niewiele ponad 3kB kodu. Zajelo 4 popoludnia razem z poznawaniem srodowiska WinAVR i znajdowaniem buga w programie obslugujacym programator (pisalem na pme). A silniczek pieknie kreci sie w zakresie 0.3 obr/min....20.000obr/min. Czas CPU(8MHz) zuzywam w 19%, liczenie i ladowanie PWM co 1ms. Watpie czy przesiade sie calkowicie na ASM, chyba ze bede musial. Przy smiesznych cenach procesorow, po prostu biore szybszy/pojemniejszy procek, a zmiana kosztuje tyle, co kilkanascie minut mojej pracy. Np ARM Atmela z 64KB pamieci kosztuje 19zl+VAT z (propox),. Nad optymalizacja w ASM bede sie zastanawial gdy bede musial cos wyprodukowac w tysiacu egzemplarzy. weim ze dyskusja byla walkowana wiele razy, chcialem sie podzielic moimi swiezymi spostrzezeniami Pozdrawiam
Reply to
Greg

Użytkownik "Radek" snipped-for-privacy@mitsoft.com.pl> napisał w wiadomości news:e0ja76$e44$ snipped-for-privacy@atlantis.news.tpi.pl...

rejestru STATUS?

o ile samą komendę wystarczy wstawić "od czasu do czasu", to pilnować banków trzeba ciągle.

Znalazłoby się. Chociażby rekomendowane sposoby dostępu do peryferii (czytaj: niedopatrzenia w hardware). Dobry kompilator C można własnie traktować jak bazę przydatnych procedur :)

pozdrawiam entrop3r

Reply to
entroper

A na co komu ta mityczna "wydajność procesora"? Procesor jest po to, by realizować postawione przed nim zadania. Jeśli ich nie spełnia, to znaczy, że albo został niewłaściwie do nich dobrany, albo że zaprogramowano go w niewłaściwy sposób. W pierwszym przypadku winna jest osoba odpowiedzialna za sprawy sprzętowe, w drugim programista i tam należy szukać przyczyn problemu. A jeśli spełnia, to co i -- przede wszystkim -- PO CO chcesz poprawiać?

Powyższe jest zupełnie niezależne od języka programowania i procesora. A jeśli w jakichś zastosowaniach istotnie asembler faktycznie okazuje się niezbędny (co ma miejsce nawet na dużych maszynach), to pisz w asemblerze tylko to, co rzeczywiście musi być w nim napisane. Po to właśnie ludzkość wymyśliła wstawki asemblerowe i external linkage.

:-)

Jakiej nieprzewidywalności?

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

Radek napisał(a):

No właśnie wynika to z popularyzacji chodzenia na łatwiznę kosztem jakości. Każdy chce mieć efekty a uczyć się mało albo wcale... NIe tylko w elektronice.

Reply to
A.Grodecki

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.