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 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.
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.
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).
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.
Ż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.
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.
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...
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).
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.
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".
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.
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
;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).
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?
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.