Jak dostosować funkcję printf w AVR-GCC do zapisu danych w zewnętrznej pamięci?

Witam

Wie może ktoś jak zmienić działanie funkcji printf tak aby działała tak
jak sobie ktoś zamarzy (chodzi o miejsce gdzie wysyłane są dane) bo ja
chce zapisywać je tą funkcją w zewnętrznej pamięci, a nie wysyłać na UART.
Na początku wydawało mi się to proste bo już coś takiego robiłem tyle że
na kompilatorze rainsonance w którym można nadpisywać funkcje i
wystarczyło napisać funkcje putchar w taki oto sposób:

int putchar(const int c)
{
send2mem(c); // ta funkcja wysyłała by wskazany bajt do pamięci
return (0);
}

Jednak niestety z tego co widzę w AVC-GCC nie da się nadpisywać funkcji ;(
także nie zabardzo wiem jak się do tego zabrać.

BT wrote:

Witam

Wie może ktoś jak zmienić działanie funkcji printf tak aby działała tak
jak sobie ktoś zamarzy (chodzi o miejsce gdzie wysyłane są dane) bo ja
chce zapisywać je tą funkcją w zewnętrznej pamięci, a nie wysyłać na

Na początku wydawało mi się to proste bo już coś takiego robiłem tyle że
na kompilatorze rainsonance w którym można nadpisywać funkcje i
wystarczyło napisać funkcje putchar w taki oto sposób:

int putchar(const int c)
{
send2mem(c); // ta funkcja wysyłała by wskazany bajt do pamięci
return (0);
}

Jednak niestety z tego co widzę w AVC-GCC nie da się nadpisywać funkcji

także nie zabardzo wiem jak się do tego zabrać.

chyba kombinujesz jak koń pod górę. Od tego jest sprintf. Dajesz jako
pierwszy parametr adres pamięci i już masz co trzeba.

Wie może ktoś jak zmienić działanie funkcji printf tak aby działała tak jak
sobie ktoś zamarzy (chodzi o miejsce gdzie wysyłane są dane) bo ja chce
zapisywać je tą funkcją w zewnętrznej pamięci, a nie wysyłać na UART

Aby stosować printf w avr-gcc, musisz najpierw wywołać funkcję fdevopen,
której podajesz m.in. adres funkcji wypisującej jeden znak (poczytaj
helpa do avr libc). Stąd już krótka droga do robienia z tym znakiem, co
tylko ci się zamarzy, np. wysłania go w kosmos drogą radiową. ;) Albo
zapisania w zewnętrznej pamięci.

Ale to chyba nie jest najlepszy pomysł na programowanie np. zewn. Flasha
albo karty MMC - printf przekaże do twojej funkcji każdy znak
oddzielnie, a najczęściej znacznie lepiej jest zapisywać pamięć od razu
całymi blokami.

Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/

Aby stosować printf w avr-gcc, musisz najpierw wywołać funkcję fdevopen,
której podajesz m.in. adres funkcji wypisującej jeden znak (poczytaj
helpa do avr libc). Stąd już krótka droga do robienia z tym znakiem, co
tylko ci się zamarzy, np. wysłania go w kosmos drogą radiową. ;) Albo
zapisania w zewnętrznej pamięci.

Dzięki obczaiłem o co chodzi poprostu zrobili to na wskaźniku do funkcji.
Inna sprawa to to że jest to nikompatybilme z językiem ANSI C

On Mon, 7 Jun 2004 20:47:39 +0200, BT wrote:

Aby stosować printf w avr-gcc, musisz najpierw wywołać funkcję

której podajesz m.in. adres funkcji wypisującej jeden znak (poczytaj
helpa do avr libc). Stąd już krótka droga do robienia z tym znakiem, co
tylko ci się zamarzy, np. wysłania go w kosmos drogą radiową. ;) Albo
zapisania w zewnętrznej pamięci.

Dzięki obczaiłem o co chodzi poprostu zrobili to na wskaźniku do funkcji.
Inna sprawa to to że jest to nikompatybilme z językiem ANSI C

Mozna spytac o standard jaki wymaga ansi C ?

J

której podajesz m.in. adres funkcji wypisującej jeden znak (poczytaj
helpa do avr libc). Stąd już krótka droga do robienia z tym znakiem, co
tylko ci się zamarzy, np. wysłania go w kosmos drogą radiową. ;) Albo
zapisania w zewnętrznej pamięci.

Dzięki obczaiłem o co chodzi poprostu zrobili to na wskaźniku do funkcji.
Inna sprawa to to że jest to nikompatybilme z językiem ANSI C

Mozna spytac o standard jaki wymaga ansi C ?

J

Trochę nie rozumie twojego pytania, w każdym razie chodzi mi o to, że w ANSI
C nie ma w ogóle funkcji fdevopen ;) i lepiej chyba było by zrobić AVR-GCC
tak aby było w nim wszystko zrobione tak samo jak w ANSI C (wiadomo nie
wszystko się da przenieść na uC),ale zamiast robić jakieś dziwolągi w stylu
fdevopen, mogli by rozwiązać ten problem tak jak w innych kompilatorach.
Zresztą z tego co przeczytałem to twórcy AVR-GCC mają zamiar to zrobić.

w ANSI-C nie ma też printf. Wogóle funkcje nie są standaryzowane ANSI.
Ale w każdym kompilatorze jest printf ;-)

Waldemar Krzok wrote:

w ANSI-C nie ma też printf. Wogóle funkcje nie są standaryzowane ANSI.
Ale w każdym kompilatorze jest printf ;-)

dziwne. JanB pisał o tej funkcji w książce ,,Język C. Interpretacja
standardu'' już w latach 80-tych. nawet na okładce jest przykład.

http://www.infosys.utas.edu.au/info/documentation/C/CStdLib.html#fprintf

Trochę nie rozumie twojego pytania, w każdym razie chodzi mi o to, że w ANSI
C nie ma w ogóle funkcji fdevopen ;) i lepiej chyba było by zrobić AVR-GCC
tak aby było w nim wszystko zrobione tak samo jak w ANSI C (wiadomo nie
wszystko się da przenieść na uC),ale zamiast robić jakieś dziwolągi w stylu
fdevopen, mogli by rozwiązać ten problem tak jak w innych kompilatorach.

"J.F." <jfox_nospam_at_nospam_poczta.onet.pl> wrote in message

Dzięki obczaiłem o co chodzi poprostu zrobili to na wskaźniku do funkcji.
Inna sprawa to to że jest to nikompatybilme z językiem ANSI C

Mozna spytac o standard jaki wymaga ansi C ?

Trochę nie rozumie twojego pytania, w każdym razie chodzi mi o to, że w ANSI
C nie ma w ogóle funkcji fdevopen ;)

i lepiej chyba było by zrobić AVR-GCC
tak aby było w nim wszystko zrobione tak samo jak w ANSI C (wiadomo nie

wszystko się da przenieść na uC),ale zamiast robić jakieś dziwolągi w stylu
fdevopen, mogli by rozwiązać ten problem tak jak w innych kompilatorach.

Dzięki obczaiłem o co chodzi poprostu zrobili to na wskaźniku do

Inna sprawa to to że jest to nikompatybilme z językiem ANSI C

Mozna spytac o standard jaki wymaga ansi C ?

Trochę nie rozumie twojego pytania, w każdym razie chodzi mi o to, że w

C nie ma w ogóle funkcji fdevopen ;)

IMHO to w standardzie ANSI w ogole nie ma zadnych funkcji
zdefiniowanych, ale moze sie myle. No - stringi formatujace do printf
to byc moze standard obejmuje :-)

A biblioteke to raczej standaryzuje POSIX.

i lepiej chyba było by zrobić AVR-GCC
tak aby było w nim wszystko zrobione tak samo jak w ANSI C (wiadomo nie

Tzn jak ? fopen ?

wszystko się da przenieść na uC),ale zamiast robić jakieś dziwolągi w

fdevopen, mogli by rozwiązać ten problem tak jak w innych kompilatorach.

Drobny niuans - nie przypominam sobie zadnej funkcji w typowych C
[juz nawet nie wymagam zeby to bylo opisane w standardzie], ktora
umozliwialaby wstawienie wlasnej funkcji "drukujacej". Czyli
co byc nie wymyslil, to bedzie niekompatybilne :-)

Mozesz natomiast poslugiwac sie sprintf .. ale na maluchach
zdecydowanie odradzam - bufor w pamieci za duzo jej zuzywa :-)

Mozna tez przeprosic sie z funkcjami itoa, ftoa, ltoa ..

i lepiej chyba było by zrobić AVR-GCC
tak aby było w nim wszystko zrobione tak samo jak w ANSI C (wiadomo nie

Tzn jak ? fopen ?

Chodzi mi o nadpisywanie.

No ale wystarczyło by zrobić możliwość nadpisywania funkcji putchar i już po
nadpisaniu tej funkcji miałbyś możliwość wysyłania danych gdzie tylko chcesz
(tak jest właśnie w innych kompilatorach). Nie jestem pewien czy takie
rozwiązanie jest kompatybilne z C

Mozesz natomiast poslugiwac sie sprintf .. ale na maluchach
zdecydowanie odradzam - bufor w pamieci za duzo jej zuzywa :-)
Mozna tez przeprosic sie z funkcjami itoa, ftoa, ltoa ..

Narazie się martwie tym że po dadaniu math.h ;) mój program zajmuje już 4k

a jak narazie to właściwie nie robi nic poza odbieraniem sygnałów DTMF i
dzwonieniem pod dany nymer.

A z printf i tak ostatecznie zrezygnowałem bo ta
funkcja nie działa prawidłowo (czyli tak samo jak w języku C) wszystko jest
dobrze jeśli wpisuje się do niej stringi ale jak zacznie się podawać
parametry np. typu double itp. to zamiast zapisać ten prametr to wiesza cały
uC ;-)

Chodzi mi o nadpisywanie.

Nadpisywanie IMHO nigdy nie bylo zestandaryzowane w ANSI. I chyba
nigdy nie bylo wymogu zeby printf poslugiwal sie wewnetrznie putch.

A napisywanie to kwestia linkera i bibliotek - jesli zdefiniujesz
wlasna funkcje putch, to nie bedzie przeszukiwana biblioteka.
Ale dla printf zostanie sciagniety caly modul z biblioteki -
i kto wie czy nie zawiera takze putch, a wtedy linker zglosi
konflikt.

No ale wystarczyło by zrobić możliwość nadpisywania funkcji putchar i już

nadpisaniu tej funkcji miałbyś możliwość wysyłania danych gdzie tylko

(tak jest właśnie w innych kompilatorach). Nie jestem pewien czy takie
rozwiązanie jest kompatybilne z C

I ja tylko w kwestii tej kompatybilnosci. Ale to ty zaczales
"jak w ANSI C", a nie "jak w Keilu" :-)

Mozesz natomiast poslugiwac sie sprintf .. ale na maluchach
zdecydowanie odradzam - bufor w pamieci za duzo jej zuzywa :-)
Mozna tez przeprosic sie z funkcjami itoa, ftoa, ltoa ..

Narazie się martwie tym że po dadaniu math.h ;) mój program zajmuje już

No wiesz - jak sie chce uzywac printf ... to jest funkcja-kombajn,
robi wszystko i duza jest :-)

a jak narazie to właściwie nie robi nic poza odbieraniem sygnałów DTMF i
dzwonieniem pod dany nymer.

Samodzielnie wylawiasz DTMF z sygnalu ?
To sie zastanow nad programem, ale imho - na zmiennym przecinku bedzie
za wolne, na stalym .. nie potrzebne ci zadne bilbioteki.

A z printf i tak ostatecznie zrezygnowałem bo ta
funkcja nie działa prawidłowo (czyli tak samo jak w języku C) wszystko

dobrze jeśli wpisuje się do niej stringi ale jak zacznie się podawać
parametry np. typu double itp. to zamiast zapisać ten prametr to wiesza

uC ;-)

Nie bardzo rozumiem - chyba za latwo sie poddajesz, jakie C jest takie
jest, ale co ma to ma dzialac ..
na uC warto sie doczytac - z reguly sa dwie wersje printf - z obsluga
zmiennego przecinka i bez. Pierwsza dwa razy dluzsza :-)

Samodzielnie wylawiasz DTMF z sygnalu ?
To sie zastanow nad programem, ale imho - na zmiennym przecinku bedzie
za wolne, na stalym .. nie potrzebne ci zadne bilbioteki.

Tak wyławiam DTMF z sygnału. Nie wiem czy dobrze rozumie co do mnie piszesz
;) ale mam wrażenie że chcesz mi powiedzieć że obiczenia zmiennoprzecinkowe
zajmują dużo więcej czasu niż na liczbach całkowitych. Ja do wyławiania DTMF
używam algorytmu goertzla (zresztą podpowiedziano mi go na tej grupie ;). I
mniej więcej jestem zadowolony na Atmega8 z 16Mhz uzyskuje próbkowanie tak
no oko to jakieś 100ms (przy przeszukiwaniu 7 częstotliwości), najwięcej w
tym algorytmie czasu zajmują funkcje sin i cos.

No pewnie masz racje i jakoś to printf działa pewnie także z double.Ale
pewnie jak jeden parametr jest double a drugi int to już się rozłoży ;-).
Dokumentacja do AVR-GCC jest raczej na niskim poziomie i raczej nie chce się
za bardzo w niej zagłębiać ;)

I o tym wlasnie pisze :-)

- algorytm goertzla nie wymaga zadnych sin i cos. Wymaga kilku stalych
wspolczynnikow, ktore obliczyc sobie mozesz na kalkulatorze i wpisac
w program. I juz sie rozmiar progamu zmniejsza.

- 100ms .. ale ty masz probkowac co najmniej 3.5kHz [najwiekszy sygnal
1633Hz]. Doradzam wieksza czestotliwosc. Wiec masz gora 200us na
obrobke probki. To ci chyba troche czasu zabraknie :-)

- obliczenia proste i zakres w miare znany - mozesz to zrobic na
liczbach calkowitych [bedzie troche zabawy, bo 16 bit moze byc
za malo] - na oko ten procek ma szanse sie zmiescic, ale byc moze
trzeba sie bedzie z assemblerkiem przeprosic.

No pewnie masz racje i jakoś to printf działa pewnie także z double.Ale
pewnie jak jeden parametr jest double a drugi int to już się rozłoży ;-).
Dokumentacja do AVR-GCC jest raczej na niskim poziomie i raczej nie chce

za bardzo w niej zagłębiać ;)

Trzeba zajrzec do zrodla ... avr/include/stdio.h:

" Since the full implementation of all the mentioned features becomes
fairly large, three different flavours of vfprintf() can be
selected using linker options. [...]

If the full functionality including the floating point conversions
is required, the following options should be used:
\code
-Wl,-u,vfprintf -lprintf_flt -lm
\endcode

- 100ms .. ale ty masz probkowac co najmniej 3.5kHz

Nie zrozumiałeś całość obliczeń przy 7 częstotliwościach zajmuje 100ms. Cały
algorytm oczywiście jako dane wyjściowe pobiera sygnał pochodzący z
próbkowania 8khz. A później dokonuje na nich obliczeń które zajmują około
100ms. A napisałem że próbkowanie jest co 100ms bo miałem na myśli to że
mogę badać jaki kod DTMF jest na linii właśnie co 100ms. I teraz nie wiem
czy to wystarczy bo jeśli sygnał DTMF jednego przycisku będzie krótszy niż
100ms to może go nie wyłapać.

No w sumie to ja już przerobiłem to prawie że na wersje liczb całkowitych
mnożenie zmiennoprzecinkowe mam tylko przy sin bo z tej funkcji wychodzi mi
ułamek który reprezentuje radiany, ale jak widze i to łatwo uda się ominąć.

No ale wystarczyło by zrobić możliwość nadpisywania funkcji putchar i już po
nadpisaniu tej funkcji miałbyś możliwość wysyłania danych gdzie tylko chcesz