Zycie zmusza mnie do nauczenia się C pod kątem zastosowania w DSP. Chyba wybiorę TI. Nieźle daję sobie radę w Pascalu i Assemblerze. Ale jak patrzę się na źródła w C , to dostaję wysypki. {} , zamiast begin/end , a++ zamiast a:=a+1 , symbole logiczne nie całkiem logiczne , to się cholernie źle czyta. Do tego możliwość zdefiniowania zmiennej byle gdzie , to zaproszenie do zrobienia z programu totalnego burdelu.
No dobra , pomarudziłem trochę , ale czy mi się to podoba czy nie, muszę się tego nauczyć . Takie są tools'y uruchomieniowe i już..
Jaką literaturę polecacie , ew. coś w sieci do nauki od podstaw.
mozesz, ale nie musisz. Burdel mozna zrobic z programu w Pascalu, jak sie chce. A jak ci sie nie podoba, to zrob sobie cos takiego (na poczatku): #define begin { #define end } #define or || i tak dalej :-) oprocz tego nikt ci nie kaze pisac a++, mozesz sobie dalej pisac a=a+1, ale lepiej w tym przypadku pisac a+=1
Kolega tez tak zaczal, ale po tygodniu przestal, bo sie przyzwyczail. Zreszta w ANSI-C zmiennych nie mozesz deklarowac byle gdzie, ino na poczatku funkcji.
Ja sie uczylem "u zrodel", czyli Kernighan & Ritchie, zreszta mialem na to w sumie 4 godziny, wraz z napisaniem i przetestowaniem programu. Da sie.
A w Pascalu przy intensywnym uzywaniu unions i wskaznikow mozesz napisac program (dzialajacy gdzieniegdzie) dlugosci kilkunastu linijek gdzie postronny za cholere nie zalapie o co biega.
Być może zupełnie irracjonalnie się uprzedziłem do samej notacji.. Nie mniej jednak , powiedz mi czy C pod kątem zastosowania w DSP bardzo różni się od C jakiego używa się do pisania jakichś tam aplikacji pod peceta? Przykładowo , chcę wysłać bajt danych do portu o określonym adresie. Czy są na to funkcje biblioteczne , czy muszę robić wstawki assemblerowe?
Jak zaglądam po 2-3 miesiącach do programów napisanych przez siebie , też zastanawiam się o co temu idiocie chodziło !!
To oznacza, że nie ma tam za grosz dokumentacji programu. Moje programy pisane 20 lat temu muszę odszyfrowywać na nowo, te pisane 5 lat temu często poprawiam z marszu. K.
Jak ktoś ma podstawy zrobione w Pascal-u, to po przesiadce na C, jest najczęściej dobrym programistą. Język C daje większe możliwości oraz większą możliwość zrobienia bałaganu. Dobrą praktyką na początku uczenia się programowania w C, jest włączanie opcji kompatybilności z ANSI C.
Swoim studentom polecałem: Jerzy Grębosz "Symfonia C++".
Trzeba też pamiętać, że programowanie w Windows dorzuca funkcje/elementy (np. API) niebecne w uC czy DSP. Jeżeli uczysz się pod kątem programowania DSP, to tam uczyłbym się programować. Ewentualnie pod Windows program konsolowy lub jakieś stare środowisko Borlanda z uwagi na znakomitą dokumentację języka C (help). K.
To zależy od dostawcy oprogramowania. Najczęściej porty używane przez peryferia są już zdefiniowane w plikach nagłówkowych dostarczanych przez producenta kompilatora lub uC. A jak chcesz dołożyć własne porty to musisz wykorzystać różne sztuczki w zależności od tego czy adres leży w przestrzeni pamięci (tu wystarczy "przekonać" kompilator, że ten adres obok jest wskaźnikiem na np. bajt) czy IO (trzeba będzie użyć wstawki asemblerowej, albo gotowej funkcji bibliotecznej) .
Wiem o co pyta autor wątku. To studentów elektroniki uczyłem programowania. Tom pierwszy wspomnianej ksiązki opisuje język C. Nie będę twierdzi, że jest najlepsza itp. Jest łatwa w odbiorze, ma bardzo dużo dobrze skomentowanych przykładów i jest łatwo dostępna.
Oprócz tego, współczesne kompilatory uC czy DSP, mają mozliwość programowania w C++. K.
jak ktoś kiedyś napisał: dokumentacja programów jest dla mięczaków i każdy program, który jest udokumentowany trzeba napisać od nowa. ;-) Jednak staram się dokumentować, przynajmniej tak, żebym się sam w tym pozbierał. A pracując w firmie produkującej biblioteki działające na wielu platformach nauczyłem się pisać programy w standarcie. U nas był lint na początku testowania, nie na końcu.
A co do programowania w makaroniarskim kodzie to miałem grupkę studentów wychowaną na ATARI, C64 i Spectrum-Basicu (uczyłem wprowadzenia do programowania w Pascalu w latach 1983-1987). Produkowali niesamowite kody, czytać się nie dało, choćby z powodu formatu. No to dałem im zadanie na kartkówkę na ćwiczeniach: programik, jakieś 40 linii kodu, ale sformatowane w blok (wszystkie spacje zlikwidowane), same wielkie litery, zmienne nazywały się A001 do Acośtam i na dokładkę w programie sam program był zmieniany (znaczy opcode podmieniałem przez zagrywkę z union). Studenci mieli 60 minut na zanalizowanie programu i prezentację wyniku (bez komputera). Program w sumie nie robił nic ciekawego, wyliczał wartość wielomianu, ale tylko jednemu studentowi z 20 udało się toto rozszyfrować.
Z kolei na zajęciach z systemów operacyjnych mieliśmy analizę kernela starej wersji unixa (w C). Pięknie skomentowany (made in Berkeley). Ale komentaż jednej funkcji powalał: "we do not expect that you'll understand this". Funkcyjka może 20 linijek, która załączała sceduler, multitasking i wracała zupełnie nie tam, gdzie człowiek myślał. ;-)
w DSP musisz czasem trochę inaczej myśleć, bo nie zawsze kompilatorowi uda się zoptymalizować pipelining. Sam nie programowałem DSP zbyt intensywnie (znaczy raz tylko poprawiałem program napisany przez kolegę na TMS320C40), ale jak sobie przypominam, to trzeba czasami uważać na równoległe przetwarzanie danych, by nie pracować na danych, których jeszcze nie ma. Ponieważ w C jest (też w ANSI) operator procesów równoległych (rozdzielenie operacji przecinkiem, a nie średnikiem) możesz mieć z tym problemy na dzieńdobry. Ale jak pisałeś programy na DSP w assemblerze, to problemów nie widzę. Zresztą przez mojego profesora C był traktowany jako assembler wyższego poziomu, podobnie jak FORTRAN. Do portów masz na ogół funkcje biblioteczne, również do synchronizacji procesów, wstawki assemblerowe są w C w 99.9% zbędne. Ewentualnie można zrealizować funkcje bezpośrednio w assemblerze i dolinkować do reszty pisanej w C.
Mam kawałek kodu, który napisałem na początku 1999 roku. Ma niewiele więcej linijek. I na jego analizę poświęciłem kiedyś kilka dni, bo za czorta nie pamiętałem, jak to działało i dlaczego dla tylko dwóch poziomów wywołania zastosowałem rekurencję. Prosta procedurka generująca SGML dla Pogromu Płatnika - na podstawie danych z baz.
Dzisiaj się już cieszę, że od dwóch lat nie jestem programistą :)
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.