Rafal schrieb:
> Waldemar Krzok pisze:
>> MH wrote:
>>
>> #define begin {
>> #define end }
>> #define or ||
>> i tak dalej :-)
>
> #define TRUE FALSE
> //Happy debugging suckers
>
> z dzisiejszego wydania joemonstera:)


#define 0 7
#define 1 0
#define 4 2


jeszcze lepsze

Waldek

do góry

MH wrote:
>> 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 :-)
>
> Nie wiedziałem. To już trochę mnie zachęca ...
Witamy w krainie preprocesora ;)

>> Ja sie uczylem "u zrodel", czyli Kernighan & Ritchie, zreszta mialem na
>> to w sumie 4 godziny, wraz z napisaniem i przetestowaniem programu. Da
>> sie.
>
> 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?
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

> Przykładowo , chcę wysłać bajt danych do portu o określonym adresie. Czy
> są na to funkcje biblioteczne , czy muszę robić wstawki assemblerowe?
DSP TI nie posiada przestrzeni I/O czyli dostep do rejestru wyglada tak
samo :
#define MY_REG_ADDR (0x12345678)

*(* MY_REG_ADDR) = 0x12345678;

lub opakowanie w funkcje/metode.

>> 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.
>>
> Jak zaglądam po 2-3 miesiącach do programów napisanych przez siebie , też
> zastanawiam się o co temu idiocie chodziło !!
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.

do góry

cepu69 schrieb:

>>> 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.
>>>
>> Jak zaglądam po 2-3 miesiącach do programów napisanych przez siebie , też
>> zastanawiam się o co temu idiocie chodziło !!
> 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

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

do góry

> Jaką literaturę polecacie , ew. coś w sieci do nauki od podstaw.
Witam.

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ł

do góry

cepu69 pisze:

>> Przykładowo , chcę wysłać bajt danych do portu o określonym adresie. Czy
>> są na to funkcje biblioteczne , czy muszę robić wstawki assemblerowe?
> DSP TI nie posiada przestrzeni I/O czyli dostep do rejestru wyglada tak
> samo :
> #define MY_REG_ADDR (0x12345678)
>
> *(* MY_REG_ADDR) = 0x12345678;
>
> lub opakowanie w funkcje/metode.

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

pawel pisze:

> 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.

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

In the darkest hour on Fri, 05 Jun 2009 22:15:19 +0200,
Adam Dybkowski <a...@4...pl> screamed:
>> 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.
>
> 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.

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 : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:238B ]
[ 11:25:11 user up 12095 days, 23:20, 1 user, load average: 0.13, 0.38, 0.45 ]

If at first you don't succeed... So much for skydiving. -- Henry Youngman

do góry

Artur M. Piwko pisze:

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

> Zawsze można od czasu do czasu tak:
>
> if (a > 3)
> {
> printf("a = "%d", a);
> {
> int x = a + 8;
> printf("x = %d", x);
> }
> }

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

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

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

In the darkest hour on Sat, 06 Jun 2009 23:18:00 +0200,
Adam Dybkowski <a...@4...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);
>> }
>> }
>
> To też bywa czasem czytelniejsze choć nie wygląda już tak "naturalnie". ;)
>

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

>> Ale po co, skoro mamy od jakiegoś czasu C99...
>
> Powiedz to kompilatorowi dla texasowych DSP'ków, nie mającemu nic
> wspólnego z gcc.

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

> 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.

Ciekawe.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:223B ]
[ 08:28:41 user up 12096 days, 20:23, 1 user, load average: 0.24, 0.50, 0.35 ]

Don't comment or patch bad code; rewrite it.

do góry

Adam Dybkowski wrote:
> cepu69 pisze:
>
>>> Przykładowo , chcę wysłać bajt danych do portu o określonym adresie. Czy
>>> są na to funkcje biblioteczne , czy muszę robić wstawki assemblerowe?
>> DSP TI nie posiada przestrzeni I/O czyli dostep do rejestru wyglada tak
>> samo :
>> #define MY_REG_ADDR (0x12345678)
>>
>> *(* MY_REG_ADDR) = 0x12345678;
>>
>> lub opakowanie w funkcje/metode.
>
> 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.
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)

> 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.
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.

do góry