Nauka C - co radzicie ?

Witamy w krainie preprocesora ;)

Jezyk C, zreszta jak wiekszosc innych jezykow wyskiego poziomu, nie wprowadza doatkowych rozszezen ze wzgledu na archtekture. Tak wiec C jest "takie same" na DSP czy x86

DSP TI nie posiada przestrzeni I/O czyli dostep do rejestru wyglada tak samo : #define MY_REG_ADDR (0x12345678)

lub opakowanie w funkcje/metode.

Biorac to pod uwage oraz "przemyslenia" zponizszych postow dziwi mnie brak konkluzji pt. Kod nalezy pisac w sposob w miare prosty i czytelny bo :

1. Autor nie jest jedynym jego uzytkownikiem
2. Pamiec autora jest zawodna itp.

cepu69 schrieb:

Konkluzja chyba oczywista i kawanaławizmu nie potrzeba. A jak potrzeba, to się pod tym podpisuję wszystkimi członkami. Bywają coprawda istoty programistyczne, które myślą, że jak program napiszesz czytelnie i dobrze skomentujesz, to po pierwsze będzie wolniej działał, a po drugie siedzisz jako programista na zaminowanym stołku. A to może się akurat obrócić przeciwko takiemu. Taki przypadek: mieliśmy w robocie studenta piszącego pracę dyplomową. Pisał porządne programy, znaczy działały, był szybki etc. Zrobił wszystko na czasie, obronił się na bdb. Po dyplomie nie mogliśmy go przyjąć, bo akurat było cienko z możliwością zapłacenia mu normalnej pensji, więc odszedł i chciał się zwerbować do innej firmy. Pech chciał, że szef nowej firmy to kumpel naszego szefa. No i się zdzwonili, a szef słyszał jak fakuję nad programem studenta. Podszedł, popytał, obejrzał i dał cynk kumplowi. No i były student nie dostał fajnej pracy, choć według aplikacji i CV był na pierwszym miejscu. Szukali jednak ludzi, którzy potrafią pracować w zespole i nic się nie wali jak w trakcie projektu ktoś pójdzie na chorobowe czy urlop.

Waldek

Jako literaturê konieczn± do przeczytania to Kernighan & Ritchie, przeczytanie i przerobienie prostych przyk³adów z tej knigi np: w dosowym borlandzie. Bez tego ani na dsp, ani avr, ani arm, ani windows API, ani linux ani cokolwiek innego. Ksi±¿ka jest ogólna i opisuje standard Ansii C. Nie ma chyba pozycji opisuj±cej programowanie DSP w jêzyku C. Jest zapewne tylko opis biblioteki udostêpnionej przez producenta konkretnego DSP. Tzn. jak wywo³aæ dan± funkcjê w jêzyku C, jak odwo³aæ siê do portu w jêzyku C itd.. Te nawiasy {} nie ró¿ni± siê niczym od begin i end. Poza tym zgodnie ze standardem ansii C nie ma mo¿liwo¶ci definiowania zmiennych gdzie siê chce tylko na pocz±tku programu lub pocz±tku funkcji, inaczej kompilator powinien zg³osiæ b³±d. Pozdrawiam Pawe³

cepu69 pisze:

Raczej nie wszystkie TI DSP. Na przykład takie TMS320VC5416 (które mocno eksploatujemy w niektórych firmowych sprzętach) mają wydzieloną przestrzeń I/O, oddzielną od pamięci danych i oddzielną pamięć programu. Trzeba nieco więcej naspawać w kodzie aby zrobić dostęp I/O.

Ale i tak przecież nikt zdrowo myślący nie będzie w C pisał przetwarzania sygnałów, FFT czy innego Viterbiego. Od tego są funkcje asemblerowe. A język C w przypadku procków DSP dobrze się sprawdza jako "klej" łączący różne kawałki kodu.

pawel pisze:

Zmienne można definiować na początku każdego bloku {}, na przykład:

if (a > 3) { int x; printf ("a = %d", a); x = a + 8;

itd. Co wg mnie nie robi zamieszania w kodzie, a właśnie odciąża główny blok zmiennych deklarowany na początku funkcji.

In the darkest hour on Fri, 05 Jun 2009 22:15:19 +0200, Adam Dybkowski snipped-for-privacy@45wp.pl screamed:

Zawsze można od czasu do czasu tak:

if (a > 3) { printf("a = "%d", a); { int x = a + 8; printf("x = %d", x); } }

Ale po co, skoro mamy od jakiegoś czasu C99...

Artur M. Piwko pisze:

To też bywa czasem czytelniejsze choć nie wygląda już tak "naturalnie". ;)

Powiedz to kompilatorowi dla texasowych DSP'ków, nie mającemu nic wspólnego z gcc.

BTW: W ogóle pisząc dla takich procków, natywnie 16-bitowych (gdzie nawet typ "char" jest 16-bitowy oraz sizeof(int)=1) trzeba od razu myśleć nieco inaczej, niż w aplikacjach dla ARMa czy AVRa. Portowanie normalnie pisanych bibliotek na DSPki 16-bitowe wiąże się z niemałym zamieszaniem. Tak to już jest gdy się używa np. TMS320VC5416 i kompilator C sprzed chyba 10 lat.

In the darkest hour on Sat, 06 Jun 2009 23:18:00 +0200, Adam Dybkowski snipped-for-privacy@45wp.pl screamed:

Kilka razy zastosowałem, chociaż wygląda brzydko. A musiałem być wtedy zgodny z ANSI C.

No tu już trzeba krajać jak materiału staje... ;>

Ciekawe.

Ja bawilem sie na troche innym "poziomie" stad to podejscie. Rodzinna C6000 ma "normalna" 32 bitowa przestrzen adresowa i w ramach ciekawostek dropsa np. mimo wlaczonego cache'a danych 1-poziomu nie trzeba bylo flushwac buforow, na ktorych pracowalo DMA (tak na marginesie tam wszystkie operacje I/O wykonywanem byly przez DMA)

Tak, ale jest to juz wyzsza szkola jazdy. Na poczatek calkowicie wystarczy C szczegolnie, ze TI dostarcza konfigurowalny z poziomu IDE system opweracyjny czasu rzeczywistego i wyprodukowanie wlasnej aplikacji typu "Hello World" jest proste.

Natomiast programowanie w asemblerze procesora sygnalowego nalezy zostawic na pozniej, szczegolnie gdy w gre wchodzi zrownoleglanie instrukcji ( C6000 ma dwie jednostki wykonawcze i moze wykonac chyba do 8 instrukcji jednoczesnie).

Co do pisania w C przetwarzania sygnalow TI dostrcza o ile mnie pamiec nie myli zestaw makr "przyspieszajacych" kod typu rozwijanie petli.