NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak skutecznie nauczyć się C do DSP, korzystając z TI? Polecana literatura i zasoby.
RoMan Mandziejewicz
Guest
Guest
Fri Jun 05, 2009 10:51 am
Hello Waldemar,
Friday, June 5, 2009, 11:15:42 AM, you wrote:
[...]
Quote:
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ł.
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ł.
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ą :)
--
Best regards,
RoMan mailto:roman@pik-net.pl
Spam: http://www.allegro.pl/sklep/7416823_squadack
Sebastian Biały
Guest
Guest
Fri Jun 05, 2009 11:14 am
Waldemar Krzok wrote:
Quote:
#define begin {
#define end }
#define or ||
i tak dalej
#define end }
#define or ||
i tak dalej
O bosze, duch bajtka i jego kursu C z lat 80 wracają ! Zombie atakują !
Błagam, tylko bez takich rad ...
MoonWolf
Guest
Guest
Fri Jun 05, 2009 11:31 am
Sebastian Biały denied rebel lies:
Quote:
Waldemar Krzok wrote:
#define begin {
#define end }
#define or ||
i tak dalej
O bosze, duch bajtka i jego kursu C z lat 80 wracają ! Zombie atakują
!
#define begin {
#define end }
#define or ||
i tak dalej
O bosze, duch bajtka i jego kursu C z lat 80 wracają ! Zombie atakują
!
#define majster main
Quote:
Błagam, tylko bez takich rad ...
MSPANC
--
<:> Roger, MoonWolf Out <:>|That's only a statue
(:
(:|
(
JID:moonwolf@jabberpl.org(| http://karakkhaz.prv.plRafal
Guest
Guest
Fri Jun 05, 2009 1:26 pm
Waldemar Krzok pisze:
Quote:
MH wrote:
#define begin {
#define end }
#define or ||
i tak dalej
#define begin {
#define end }
#define or ||
i tak dalej
#define TRUE FALSE
//Happy debugging suckers
z dzisiejszego wydania joemonstera:)
Pozdrawiam
Rafał
Sebastian Biały
Guest
Guest
Fri Jun 05, 2009 1:46 pm
MoonWolf wrote:
Quote:
#define majster main
Dokladnie :/
Jeszcze widziałem w jednej książce do gimnazjum język C przetłumaczony
na pl (tak, z ą,ę ...).
Uprasza się humanistów i programatorów w pascalu o zajmowanie się swoja
działką :/
Waldemar Krzok
Guest
Guest
Fri Jun 05, 2009 2:16 pm
Rafal schrieb:
Quote:
Waldemar Krzok pisze:
MH wrote:
#define begin {
#define end }
#define or ||
i tak dalej :-)
#define TRUE FALSE
//Happy debugging suckers
z dzisiejszego wydania joemonstera:)
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
cepu69
Guest
Guest
Fri Jun 05, 2009 4:33 pm
MH wrote:
Quote:
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
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
Quote:
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
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
Quote:
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
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.
Quote:
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
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.
Waldemar Krzok
Guest
Guest
Fri Jun 05, 2009 5:01 pm
cepu69 schrieb:
Quote:
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
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
pawel
Guest
Guest
Fri Jun 05, 2009 5:17 pm
Quote:
Jaką literaturę polecacie , ew. coś w sieci do nauki od podstaw.
Witam.
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ł
Adam Dybkowski
Guest
Guest
Fri Jun 05, 2009 9:13 pm
cepu69 pisze:
Quote:
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.
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.
Adam Dybkowski
Guest
Guest
Fri Jun 05, 2009 9:15 pm
pawel pisze:
Quote:
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.
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.
Artur M. Piwko
Guest
Guest
Sat Jun 06, 2009 10:26 am
In the darkest hour on Fri, 05 Jun 2009 22:15:19 +0200,
Adam Dybkowski <adybkows12@45wp.pl> screamed:
Quote:
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.
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
Adam Dybkowski
Guest
Guest
Sat Jun 06, 2009 10:18 pm
Artur M. Piwko pisze:
Quote:
Zmienne można definiować na początku każdego bloku {}, na przykład:
[...]
[...]
Quote:
Zawsze można od czasu do czasu tak:
if (a > 3)
{
printf("a = "%d", a);
{
int x = a + 8;
printf("x = %d", x);
}
}
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". ;)
Quote:
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.
Artur M. Piwko
Guest
Guest
Sun Jun 07, 2009 7:31 am
In the darkest hour on Sat, 06 Jun 2009 23:18:00 +0200,
Adam Dybkowski <adybkows12@45wp.pl> screamed:
Quote:
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". ;)
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.
Quote:
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.
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... ;>
Quote:
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.
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.
cepu69
Guest
Guest
Mon Jun 08, 2009 11:41 am
Adam Dybkowski wrote:
Quote:
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.
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)
Quote:
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
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.
elektroda NewsGroups Forum Index - Elektronika Polska - Jak skutecznie nauczyć się C do DSP, korzystając z TI? Polecana literatura i zasoby.