logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Przejście z AVR na ARM AT91SAM7S256 - wybór oprogramowania i narzędzi

marenc 11 Kwi 2007 21:09 2096 14
REKLAMA
  • #1 3778174
    marenc
    Poziom 24  
    Posty: 881
    Pomógł: 37
    Ocena: 5
    Witam, czas wziąć się za coś na czasie, a mianowicie ARM. Mikrokontrolery AVR mam prawie w 100% opanowane, więc pora wziąć się za USB i Ethernet(na początek wystarczy USB).

    Jako pierwszy układ wybrałem AT91SAM7S256 ze względu na cenę, przywiązanie do firmy Atmel, możliwość ładowania programu bez jakiegoś specjalnego sprzętu typu JTAG oraz możliwość zaimplementowania systemu dla mikrokontrolerów.

    Kiedyś przymierzałem się do softu IAR, ale jest przynajmniej dla mnie mało przyjazne ze względu na nieznajomość rejestrów. Proszę o pomoc w wyborze najbardziej przyjaznego i dającego spore możliwości softu dla tego mikrokontrolera.

    Pytanie już kiedyś się pojawiło, ale teraz konkretnie nawiążę ... mikrokontrolery AVR znam dokładnie rejestry(prawie na pamięć), ale czy jest sens uczenia się znów całej architektury ARM'ów? Podobno system operacyjny jest czymś w stylu "nie wiesz jak działa, ale wiesz jak sprawić by działało jak chcesz", więc postanowiłem pisać programy dla ARM'ów na systemie operacyjnym. Proszę o pomoc wyboru systemu dla tego mikrokontrolera oraz pomoc przy jego uruchomieniu(prosty program w styli migającego LED'a).
  • REKLAMA
  • #2 3778304
    gufiak
    Poziom 21  
    Posty: 444
    Pomógł: 15
    Ocena: 2
    Cytat:
    więc pora wziąć się za USB i Ethernet(na początek wystarczy USB).
    No nie wiem czy to drugie nie będzie prostsze. Poza tym na USB atmel udostępnia gotowe źródła, więc to tylko zostaje zaadoptować do swojego kodu.
    Co do środowiska, to popatrz, potestuj. Każdy ma inny gust i każdemu co innego się podoba. A wybór jest szeroki: IAR, Keil, CrossWorks, WinAvr......
    Cytat:
    ale czy jest sens uczenia się znów całej architektury ARM'ów?
    Architektury? Napewno się przyda, szczególnie jeśli chcesz wiedzieć co robisz i nie zamierzasz korzystać z OS'ów. Jeśli zaś chodzi o rejestry specjalne, to raczej nie wyobrażam sobie wyuczenia się ich na pamięć (chyba, że po kilku latach pisania programów na tą samą rodzinę ARM'ów). Oczywiście te najczęściej wykorzystywane raczej szybko zapadną w pamięć, ale nie widzę sensu wkuwania ich na pamięć. Warto się tylko orientować co jest do dyspozycji i gdzie tego szukać. No i oczywiście obowiązkowo przeczytać dokumentację (600 stron, ale stosunkowo szybko to się czyta).
    Cytat:
    Proszę o pomoc wyboru systemu dla tego mikrokontrolera oraz pomoc przy jego uruchomieniu(prosty program w styli migającego LED'a).
    Proponowałbym jednak na początku zrezygnować z OS'ów, tym bardziej, że miganie diodami w przypadku OS'a to strzelanie z armaty do muchy. Warto na początku przejrzeć przykładowe programy, których nie brakuje w internecie. A co do OS'a, to jest spory wybór, ale polecam FreeRTOS'a. Możesz też pobawić się w zaimplementowanie linuksa. Co kto woli...
  • #3 3778496
    adamusx
    Poziom 27  
    Posty: 977
    Pomógł: 94
    Ocena: 28
    Zgadzam sie z przedmowca. Nie ma sensu sie uczyc rejestrow na pamiec, z biegiem czasu te czesto uzywane wchodza w glowe. Chyba malo prawdopodobne by zapamietac wszystkie. Dla przykladu podam, ze w porownaniu do AVRa gdzie do sterowania pinami sa tylko 3 rejestry, tak w ARMie jest ich kilkanascie :) Oczywiscie najczesciej korzysta sie z kilku podstawowych.
    Cytat:
    Kiedyś przymierzałem się do softu IAR, ale jest przynajmniej dla mnie mało przyjazne ze względu na nieznajomość rejestrów.


    Hmm wydaje mi sie ze z Keilem czy CrossWorkiem bedzie podobnie. Ja osobiscie od poczatku zabralem sie za darmowe srodowisko ( WinARm + edytor DevCpp)
    Na poczatku jest troche trudnosci, ale po ich opanowaniu nauka idzie z gorki :)
  • REKLAMA
  • #4 3779193
    marenc
    Poziom 24  
    Posty: 881
    Pomógł: 37
    Ocena: 5
    Co do OS'a to chodzi mi o to, żeby się nauczyć obsługiwać jednego, a nie uczyć się architektury by pisać własne programy od podstaw. Miganie LED'em miało być czymś w rodzaju sprawdzenia, czy poprawnie zaimplementowałem system. Dokumentacje doczytuje na bierząco wedle potrzeb.

    O freeRTOS'ie słyszałem już sporo. Z kąd mogę go pobrać i jak go dodać do projektu? Są jakieś przykłady(bo kursów pewnie nie ma)?
  • REKLAMA
  • #5 3779710
    gufiak
    Poziom 21  
    Posty: 444
    Pomógł: 15
    Ocena: 2
    Nie no... A słyszałeś o google?
  • #6 3779799
    fantom
    Poziom 31  
    Posty: 1649
    Pomógł: 108
    Ocena: 41
    adamusx napisał:
    Zgadzam sie z przedmowca. Nie ma sensu sie uczyc rejestrow na pamiec, z biegiem czasu te czesto uzywane wchodza w glowe. Chyba malo prawdopodobne by zapamietac wszystkie. Dla przykladu podam, ze w porownaniu do AVRa gdzie do sterowania pinami sa tylko 3 rejestry, tak w ARMie jest ich kilkanascie :) Oczywiscie najczesciej korzysta sie z kilku podstawowych.
    Cytat:
    Kiedyś przymierzałem się do softu IAR, ale jest przynajmniej dla mnie mało przyjazne ze względu na nieznajomość rejestrów.


    Hmm wydaje mi sie ze z Keilem czy CrossWorkiem bedzie podobnie. Ja osobiscie od poczatku zabralem sie za darmowe srodowisko ( WinARm + edytor DevCpp)
    Na poczatku jest troche trudnosci, ale po ich opanowaniu nauka idzie z gorki :)


    Co maja wspolnego rejestry procesora ze sterowaniem portow ? Fakt, w AVR-rze sa magiczne sfr-y ale w ARM-ie czegos takiego nie ma. Wszystkie urzadzenia (w tym porty IO) sa zmapowane na pamiec i napewno nie potrzeba znac kilkunastu zeby obsluzyc port ;-).

    Dajcie sobie ludzie spokoj z OS-ami na to przyjdzie jeszcze czas.

    Czy uczyc sie architektury ? Tak, taki jeszcze raz tak. Jak chcesz cos wiecej zdzialac na tym polu to badz przygotowany na uczenie sie nowych architektur przynajmniej zeby wiedziec co jest grane ale oczywiscie nie uczyc na pamiec , dajcie spokoj. Zreszta jak znasz jedna to reszta pojdzie latwiej (nie mylic z latwo). Warto dodatkowo nauczyc sie jezyka programowania wyzszego poziomu, wowczas nie bedzie tyle problemow z pisaniem oprogramowania na nowe architektury.

    W odroznieniu od niektorych mowie to z wlasnego doswiadczenia a nie teoretyzuje.
  • REKLAMA
  • #7 3779983
    kleki
    Poziom 28  
    Posty: 1350
    Pomógł: 95
    Ocena: 142
    PIOA_SODR
    PIOA_CODR
    PIOA_OER
    PIOA_ODR
    PMC_PCER
    tych rejestrów potrzebowałem do mrugania LED-em... :-)
    Z doświadczenie - dosłownie kilka dni wstecz. :-)
  • #8 3780080
    gufiak
    Poziom 21  
    Posty: 444
    Pomógł: 15
    Ocena: 2
    Cytat:
    Co maja wspolnego rejestry procesora ze sterowaniem portow ? Fakt, w AVR-rze sa magiczne sfr-y ale w ARM-ie czegos takiego nie ma. Wszystkie urzadzenia (w tym porty IO) sa zmapowane na pamiec i napewno nie potrzeba znac kilkunastu zeby obsluzyc port
    Z kontekstu wynika, że to nie o rejestry procesora chodziło, lecz o rejestry specjalne (czy rejestry I/O, jak kto woli). Poza tym SFR'y konkretnie są w '51. W AVR'ach są rejestry I/O i również są zmapowane w pamięci (zresztą jak w większości procesorów). Więc pewne podobieństwo jest. Aczkolwiek w AVR'ach dostęp do rejestrów I/O jest możliwy na dwa sposoby (bezpośredni oraz przez pamięć), zaś w ARM'ach polega to tylko na odwołaniu się do konkretnego miejsca w pamięci.
    Co do reszty Twojej wypowiedzi - masz rację.
    Cytat:
    Dokumentacje doczytuje na bierząco wedle potrzeb.
    To nie jest dobry sposób. Dokumentację trzeba chociaż raz przeczytać zanim za cokolwiek się zabierzesz. Najwięcej problemów mają ludzie, którzy tak właśnie podchodzą do sprawy czytania dokumentacji. Naprawdę dobrze jest wiedzieć co się ma do dyspozycji i jakie niespodzianki mogą czyhać zanim zacznie się cokolwiek z tym procesorem robić.
  • #9 3780273
    TWl
    Poziom 21  
    Posty: 337
    Pomógł: 42
    Ocena: 133
    kleki napisał:

    PIOA_SODR
    PIOA_CODR
    PIOA_OER
    PIOA_ODR
    PMC_PCER
    tych rejestrów potrzebowałem do mrugania LED-em... :-)
    Z doświadczenie - dosłownie kilka dni wstecz. :-)

    To nie jest tak duzo, sprowadza sie to tak na prawde do trzech rejestrow - SODR/CODR zostaly wprowadzone by mozna bylo modyfikowac poszczegolne bity za pomoca mniejszej liczby instrukcji. Nie zostalo to wymyslone zeby utrudnic zycie. Rejestr PCER jest elementem systemu zarzadzania poborem energii przez peryferia. Gdyby wszystko domyslnie bylo w nim wlaczone, wiekszosc ludzi nie wiedzialaby ze taki rejestr wogole istnieje.

    PS. Prosze Kolege o nie straszenie ze ARMy maja tyyyyle rejestrow i sa taaakie strasznie skomplikowane w programowaniu. Wiekszosc problemow wynika tu albo z niedoczytania dokumentacji, albo z braku podstawowej wiedzy o programowaniu w C - np. jak uzywac wskaznikow (czyli zrozumienia dlaczego PIOA_SODR = costam jest zle, a *PIOA_SODR = costam - dobrze).
  • #10 3782186
    fantom
    Poziom 31  
    Posty: 1649
    Pomógł: 108
    Ocena: 41
    gufiak napisał:
    Z kontekstu wynika, że to nie o rejestry procesora chodziło, lecz o rejestry specjalne (czy rejestry I/O, jak kto woli). Poza tym SFR'y konkretnie są w '51. W AVR'ach są rejestry I/O i również są zmapowane w pamięci (zresztą jak w większości procesorów). Więc pewne podobieństwo jest. Aczkolwiek w AVR'ach dostęp do rejestrów I/O jest możliwy na dwa sposoby (bezpośredni oraz przez pamięć), zaś w ARM'ach polega to tylko na odwołaniu się do konkretnego miejsca w pamięci.

    Wedlug wszelkich znakow na niebie i ziemi sa one zwane sfr-ami przynajmniej przez avr-gcc
    Cytat:

    /* avr/sfr_defs.h - macros for accessing AVR special function registers */

    Co do reszty faktycznie masz racje. To juz bedzie ze dwa lata jak sie nie zajmuje avr-ami takze moglo mi sie zapomniec. Musze sie rowniez szczerze przyznac ze nigdy wczesniej nie zwrocilem uwagi ze same rejestry procesora sa rowniez zmapowane na pamiec. Chytrze - w zasadzie eliminuje to potrzebe uzywania wstawek asemblerowych (choc podejrzewam ze dostep z uzyciem bezposredniego adresowania pamieci pozera wiecej taktow)
  • #11 3782605
    kleki
    Poziom 28  
    Posty: 1350
    Pomógł: 95
    Ocena: 142
    Prosta sprawa, że nie jest to coś strasznego. Hehe, kolega TWI pewnie pierwsze co zrobił, to spojżał na moje posty i teraz "targa łacha" że nie śmigam w C/C++. :-)
    Miłe.

    Dla mnie ARM jest póki co trudny w czymkolwiek z prostego powodu - dopiero zaczynam. C/C++ też "gryzę" od podstaw, więc zaskoczeniem jest również instrukcja i++, czy 0x1 << 5.

    Jak się zatrybi, to z górki - nie mam racji?
    Dla początkującego na pewno nie jest to łatwe, ani naturalne.

    PS - można prosić o wyjaśnienie, dlaczego zapis z gwiazdką jest lepszy niż bez gwiazdki? Ciekawi mnie to jak diabli, tym bardziej że bez gwiazdki mi jak najbardziej zadziałało. Jest jakoś wygodniej, pewniej, czy jak? Co nam to daje?

    pzdr
  • #12 3782654
    fantom
    Poziom 31  
    Posty: 1649
    Pomógł: 108
    Ocena: 41
    Spokojnie panowie, wszystko zalezy od tego jak jest zdefiniowane makro PIOA_SODR w pliku naglowkowym. Jesli tak:
    
    #define PIOA_SODR (*(volatile int*)0xffff)
    

    to wowczas PIOA_SODR = 0x1111. Natomiast jesli tak:
    
    #define PIOA_SODR ((volatile int*)0xffff)
    

    to wowczas *PIOA_SODR = 0x1111.Ot i cala filozofia.
  • #13 3783148
    kleki
    Poziom 28  
    Posty: 1350
    Pomógł: 95
    Ocena: 142
    Chyba kapuję... - nagłówek decyduje, czy przez PIOA_SODR masz dostęp do rejestru, czy do jego adresu w pamięci(czyli wskaźnika)?

    To by mi nawet pasowało. :-) Wszystko układa się w logiczną całość. :-) A jeszcze taka sprawa, niemal na osobny temat - jest jakaś możliwość sterowania osławionym HD44780 w C? Nie masz może do tego jakiś .h i .c + ew. przykład użycia?

    pozdrawiam
  • #14 3783173
    fantom
    Poziom 31  
    Posty: 1649
    Pomógł: 108
    Ocena: 41
    kleki napisał:
    Chyba kapuję... - nagłówek decyduje, czy przez PIOA_SODR masz dostęp do rejestru, czy do jego adresu w pamięci(czyli wskaźnika)?

    Dokladnie
    Cytat:

    To by mi nawet pasowało. :-) Wszystko układa się w logiczną całość. :-) A jeszcze taka sprawa, niemal na osobny temat - jest jakaś możliwość sterowania osławionym HD44780 w C? Nie masz może do tego jakiś .h i .c + ew. przykłąd użycia?

    pozdrawiam

    Zawsze jest mozliwosc ale ta zalezy scisle od tak jak ten wyswietlacz podlaczysz. Gdzies tam na dysku zakurzone pewnie lezy ale mysle ze szybciej znajdziesz to na elektrodzie lub zrobisz samemu gdyz nie ma z tym jakis duzych problemow. Mozesz zaczac chocby tutaj
  • #15 3785090
    gufiak
    Poziom 21  
    Posty: 444
    Pomógł: 15
    Ocena: 2
    Cytat:
    Wedlug wszelkich znakow na niebie i ziemi sa one zwane sfr-ami przynajmniej przez avr-gcc
    W avr-gcc może i jest, ale w notach katalogowych te rejestry nazywane są rejestrami I/O, zaś w przypadku '51 rejestry te nazywane są SFR'ami. Niemniej jednak, to jest to samo i moim zdaniem nazwa SFR w przypadku AVR'ów nie jest błędna.
    Cytat:
    To juz bedzie ze dwa lata jak sie nie zajmuje avr-ami takze moglo mi sie zapomniec.
    Kurcze, u mnie to chyba z 5 lat będzie ;)

Podsumowanie tematu

✨ Dyskusja dotyczy przejścia z mikrokontrolerów AVR na ARM, konkretnie na układ AT91SAM7S256 firmy Atmel, z naciskiem na wybór odpowiedniego oprogramowania i narzędzi programistycznych. Użytkownicy podkreślają, że nauka architektury ARM jest wskazana, choć niekoniecznie zapamiętywanie wszystkich rejestrów na pamięć, gdyż najważniejsze rejestry wykorzystywane są częściej i z czasem stają się znane. W ARM rejestry specjalne (I/O) są zmapowane w pamięci, co różni się od AVR, gdzie dostęp do rejestrów I/O jest możliwy zarówno bezpośrednio, jak i przez pamięć. Wskazano, że dokumentacja jest kluczowa do zrozumienia działania mikrokontrolera. W kwestii środowisk programistycznych wymieniono IAR, Keil, CrossWorks oraz darmowe rozwiązania jak WinARM z edytorem DevCpp. Poruszono temat systemów operacyjnych czasu rzeczywistego, zwłaszcza freeRTOS, który jest polecany do nauki obsługi OS na ARM. Omówiono także techniczne aspekty dostępu do rejestrów, wyjaśniając różnice w definicjach makr i użyciu wskaźników w C. Na koniec pojawiła się prośba o przykładowe biblioteki do sterowania popularnym wyświetlaczem HD44780 w języku C, z sugestią poszukiwania gotowych rozwiązań lub samodzielnego napisania kodu.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA