avr-gcc - dane w flash

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.
Reply to
Sebastian Biały
Loading thread data ...

Sebastian Biały pisze:

Do flasha programu? Taki jak w oficjalnym manualu:

formatting link

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.

Reply to
Zbych

Sebastian Biały pisze:

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.

Reply to
Adam Dybkowski

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.

No wiem, ze idzie powoli...

Reply to
Sebastian Biały

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

Reply to
Sebastian Biały

Sebastian Biały pisze:

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

Reply to
Adam Dybkowski

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

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 w dsp zadko się pisze w C.

Reply to
Sebastian Biały

Sebastian Biały pisze:

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

Reply to
Adam Dybkowski

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.

Reply to
T.M.F.

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

Reply to
identyfikator: 20040501

identyfikator: 20040501 pisze:

O C na AVRach był kurs chyba w EP.

No ale w końcu nic wielkiego i tak się nie wyczyta - C jak C, wszędzie takie samo. "AVR"owatość polega tylko na obsłudze urządzeń I/O i zagraniach niestandardowych jak właśnie omawiany wcześniej dostęp do pamięci programu.

A i tak do większości peryferiów albo samemu sterowniki trzeba sobie napisać, albo szukać gotowców w Sieci. Albo od razu przejść na rozwinięty system operacyjny z masą gotowych sterowników np. Nut/OS, który w gruncie rzeczy polecam. Łatwiejsza jest potem ew. przesiadka na ARMa (na którego Nut/OS także jest, z tym samym API).

Reply to
Adam Dybkowski

dzięki faktycznie był

jeśli można zapytać, najbardziej szukam informacji jak łączyć program w C z assemblerem - nie przy użyciu INLINE... wiem, że procedury asm trzeba umieszczać w pliku *.s który trzeba później w jakiś szczególny sposób kompilować... tylko jak? no i jak deklarować zmienne w procedurach asm, jak wywoływać procedury asm z c, no i najważniejsze jak tworzyć procedury obsługi przerwania w asm? jeśli Ktoś mógłby coś napisać to będę zobowiązany.

Reply to
identyfikator: 20040501

Fri, 07 Aug 2009 21:09:04 +0200 Sebastian Biały snipped-for-privacy@poczta.onet.pl>

napisał:

Zawsze możesz zrobic w jednym pliku źródłowym dwie wersje kodu wybierane przez #ifdef / #ifndef Moim zdaniem, gdy pisze się na mikrokontrolery, to trzeba sie pogodzić z tym że niektóre rzeczy muszą być "architekturo-specyficzne".

Reply to
__Maciek

identyfikator: 20040501 pisze:

Kompiluje się tak samo jak plik c. Gcc po rozszerzeniu (albo jeśli znajdzie opcję -x) rozpoznaje typ pliku i wywołuje kompilację/asemblację/linkowanie. Trzeba tylko pamiętać, że porty gcc na niektóre architektury automatycznie dostawiają pokreślenie przed nazwami procedur w c i trzeba w plikach asm rozpoczynać nazwy procedur od podkreślenia.

Reply to
Zbych

dzięki! mógłbyś napisać jakiś edukacyjny programik typu zapisz do zmiennej w procedurze asemblerowej, wywoływanej z C? P.S. przypomniało mi się, te pliki

*.s obowiązują w AVRstudio...
Reply to
identyfikator: 20040501

identyfikator: 20040501 pisze:

plik main.c:

#include <avr/io.h>

uint8_t zmienna;

uint8_t procedura_w_asemblerze(uint8_t arg);

void main( void ){

PORTC = procedura_w_asemblerze(PORTB); PORTB = zmienna; }

-------------------------------------------------- plik utils.S:

.global procedura_w_asemblerze .global zmienna

.section .text

procedura_w_asemblerze:

; modyfikacja zmiennej globalnej lds r25, zmienna inc r25 sts zmienna, r25

;obróbka parametrów i zwrócenie wyniku inc r24 ret

Zanim zaczniesz pisać procedury w asemblerze koniecznie musisz doczytać, w jakich rejestrach przekazuje się parametry, zawartość jakich rejestrów możesz zniszczyć, a które koniecznie musisz zwrócić nienaruszone:

formatting link
Do kompilacji używam standardowego makefile'a, więc pliki asemblerowe wystarczy dopisać w linii "ASRC =" (pamiętając o dużym S w rozszerzeniu).

Reply to
Zbych

dzięki!!! a gdzie można poczytać o dytektywach asemblera jak wyżej?

Reply to
identyfikator: 20040501

identyfikator: 20040501 pisze:

W manualu do gasa (gnu assembler) - na stronie gcc.

Reply to
Zbych

a jeszcze pierdółka... jak w avrstudio pisząc program w C: a. wygenerować plik wynikowy z przetłumaczonym i skompilowanym z C kodem assemblera? b. jak uruchomić symulację/debugowanie z pułapkami dla plików w C?

Reply to
identyfikator: 20040501

symulację debuggerem, bez procesora oczywiście...

Reply to
identyfikator: 20040501

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.