Witam.

Jaki jest oficjalnie sposob na wciskanie danych do flash z poziomu C?
Mam tablice N elementow ktora powinna byc w ROM a nie RAM. Ba, moze
nawet ze wskazaniem dokladnie gdzie (np. z jakis przyczyn na granicy
256B). A slyszalem ze nowsze wersje gcc maja miec support dla
architektury harvard wiec chyba bedzie tam mozliwosc wskazania gdzie
wyladuja stale i w jakim rodzaju pamieci.

do góry

Sebastian Biały pisze:
> Witam.
>
> Jaki jest oficjalnie sposob na wciskanie danych do flash z poziomu C?

Do flasha programu? Taki jak w oficjalnym manualu:

http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html

> A slyszalem ze nowsze wersje gcc maja miec support dla
> architektury harvard wiec chyba bedzie tam mozliwosc wskazania gdzie
> wyladuja stale i w jakim rodzaju pamieci.

To tak jak z maturą Beger:

ma
.
.
.
.
.
.
.
.
.
mieć
.
.
.
.
.
.
.
.
.
.
.
na wiosnę.


W praktyce potrzebny jest jeszcze backend dla avrów, a na liście
dyskusyjnej deweloperów nawet nikt jeszcze nie wspomniał o planach
dodania czegoś takiego.



--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

do góry

Sebastian Biały pisze:

> Jaki jest oficjalnie sposob na wciskanie danych do flash z poziomu C?
> Mam tablice N elementow ktora powinna byc w ROM a nie RAM. Ba, moze
> nawet ze wskazaniem dokladnie gdzie (np. z jakis przyczyn na granicy
> 256B).

Standardowo używa się do tego dyrektyw z pliku pgmspace.h, na przykład:

static const prog_uchar crc_table[8] = {0x00, 0x5e, 0xbc, 0xe2, 0x61,
0x3f, 0xdd, 0x83};

A jeżeli potrzebujesz coś specjalnie umieścić w niestandardowym miejscu,
musisz to powiedzieć linkerowi a w kodzie źródłowym dać np:

const city_pos_t cities_tbl[] __attribute__ ((section (".text.cities"))) =
{
{50.056629181, 19.945249557, "Krakow"},
{51.776933670, 19.453847408, "Lodz"},
{52.412016392, 16.919288635, "Poznan"},
{52.217137814, 21.004979610, "Warszawa"},
{51.107861996, 17.021555901, "Wroclaw"}
};

W takim przypadku nie zapomnij linkerowi powiedzieć, co ma zrobić z
sekcją .text.cities; normalnie umieści ją obok innych sekcji .text.

Wszystkie stałe z pamięci programu trzeba odczytywać także w specjalny
sposób, patrz memcpy_P, pgm_read_byte itd. Jest to opisane w
dokumentacji do avr-libc.

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

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

do góry

Zbych wrote:
> Do flasha programu? Taki jak w oficjalnym manualu:
> http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html

Tak wiem, ale czy to nie jest rozszezenie tylko dla AVRów ? Zastanawiam
sie co bedzie jak gcc oficjalnie bedzie miec taki support, zebym nie
musial tegp progmema wywalac z setek miejsc zastepujac czyms nowym-lepszym.

> To tak jak z maturą Beger:

No wiem, ze idzie powoli...

do góry

Adam Dybkowski wrote:
> Wszystkie stałe z pamięci programu trzeba odczytywać także w specjalny
> sposób, patrz memcpy_P, pgm_read_byte itd. Jest to opisane w
> dokumentacji do avr-libc.

Wlasnie mam nadzieje, ze nowe gcc dadza rade to ukryc przed
uzytkownikiem, a ja tylko oznacze sobie co ma gdzie byc i juz.

do góry

Sebastian Biały pisze:

>> Do flasha programu? Taki jak w oficjalnym manualu:
>> http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html
>
> Tak wiem, ale czy to nie jest rozszezenie tylko dla AVRów ? Zastanawiam
> sie co bedzie jak gcc oficjalnie bedzie miec taki support, zebym nie
> musial tegp progmema wywalac z setek miejsc zastepujac czyms nowym-lepszym.

Tak, to jest tylko dla AVRów. Po przejściu na inny procesor zrobisz
sobie po prostu makro puste albo definiujące normalny typ (char zamiast
prog_char itp).

Na przykład w ARMach nie trzeba tak kombinować. Jeżeli coś jest stałą to
zostanie umieszczone w sekcji stałych (.rodata) czyli docelowo przez
linker w binariach obok kodu programu. I można się do tego normalnie
odwoływać bo jest tylko jedna wspólna przestrzeń adresowa (dla programu,
danych, I/O).

Ale za to na DSPkach to już pełna rozpusta, niektóre nawet mają kilka
oddzielnych pamięci danych (aby można było np. jednocześnie pobierać
współczynnik filtru z jednej pamięci a próbkę danych z drugiej; do tego
oddzielna przestrzeń na kodu programu).

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

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

do góry

Adam Dybkowski wrote:
> Tak, to jest tylko dla AVRów. Po przejściu na inny procesor zrobisz
> sobie po prostu makro puste albo definiujące normalny typ (char zamiast
> prog_char itp).

No wlasnie dlatego pytam poniekad o te nowe ficzery gcc, bo robienie
pustego makra jest niefajne.

> Na przykład w ARMach nie trzeba tak kombinować.

Tak, wiem. Ale to inny procesor kompletnie. Mnie interesuje czy w
avr-gcc sa jakies inne mozliwosci bardziej kompatybilne w przyszłości.
Jesli jest tylko progmem to trudno.

> Ale za to na DSPkach to już pełna rozpusta, niektóre nawet mają kilka
> oddzielnych pamięci danych (aby można było np. jednocześnie pobierać
> współczynnik filtru z jednej pamięci a próbkę danych z drugiej; do tego
> oddzielna przestrzeń na kodu programu).

Ale w dsp zadko się pisze w C.

do góry

Sebastian Biały pisze:

>> Ale za to na DSPkach to już pełna rozpusta, niektóre nawet mają kilka
>> oddzielnych pamięci danych (aby można było np. jednocześnie pobierać
>> współczynnik filtru z jednej pamięci a próbkę danych z drugiej; do tego
>> oddzielna przestrzeń na kodu programu).
>
> Ale w dsp zadko się pisze w C.

Żebyś się nie zdziwił. Nawet super-duper zoptymalizowane algorytmy DSP
napisane w asemblerze często trzeba opakować w coś bardziej ogólnego,
jakiś automat stanowy, może GUI (jeżeli nie używasz kilku procesorów ani
OMAP'a tylko wszystko robi sam DSP). No i wychodzi potem 75% kodu
wynikowego zrobionego z C a 25% z asemblera.

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

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

do góry

W dniu 07.08.2009 21:10, Sebastian Biały pisze:
> Adam Dybkowski wrote:
>> Wszystkie stałe z pamięci programu trzeba odczytywać także w specjalny
>> sposób, patrz memcpy_P, pgm_read_byte itd. Jest to opisane w
>> dokumentacji do avr-libc.
>
> Wlasnie mam nadzieje, ze nowe gcc dadza rade to ukryc przed
> uzytkownikiem, a ja tylko oznacze sobie co ma gdzie byc i juz.

Realnie wprowadzenie tego to kwestia moze 2 lat. Wiec jesli masz tyle
czasu to czekaj, a poki co zostaje pgmspace.
Developerzy winavr nawet nie za bardzo mysla o przejsciu na nowsza
wersje gcc, a co dopiero o wprowadzeniu tak radykalnych zmian. No i
odpowiednim dostosowaniu avr-libc.


--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

z okazji okazji zapytam (może nikt mnie nie pobije), pojawiły się w sieci
jakieś tutoriale na temat programowania w c avr i arm? mam kilka dostępnych
ogólnie książek o programowaniu w c avr, ale są tak słabe, że szkoda nawet
do nich zaglądać... P.S. a wiecie, że HELION cenzuruje komentarze? dopisałem
jeden niepochlebny o książce Daniluka o USB i... wykasowali...

do góry