• Witaj na Forum Arduino Polska! Zapraszamy do rejestracji!
  • Znajdziesz tutaj wiele informacji na temat hardware / software.
Witaj! Logowanie Rejestracja


Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Arduino - proces budowy i obsługa różnych rodzin uC
#1
Witam wszystkich,

Bardzo długo starłem się unikać Arduino jako środowiska programistycznego
(na ogół piszę wszystko w "czystym C" przy wykorzystaniu Eclipse'a i Atmel'owskiego toolchaina) jednak obecnie staram się zrealizować projekt, który częściowo został rozwiązany w Arduino.

Zastanawia mnie jak wyglądają w Arduino kolejne etapy tworzenia skompilowanego pliku od kodu źródłowego,
a szczególnie to jak została zrealizowania kompilacja kodu źródłowego (który de facto jest nieco zmodyfikowanym C++) na różne platformy (np. Arduino Uno - czyli Atmelowska Atmega 328P, a z drugiej strony - np. ESP8266 albo STM32)
Czy byłby mi w stanie ktoś wypunktować kolejne operacje, które za to odpowiadają?
 
Przypuszczam, że wygląda to mniej więcej tak:
1. Wybieramy płytkę co determinuje wykorzystywany w kompilacji toolchain
(swoją drogą, ciekawi mnie też jakie toolchainy zostały wybrane do poszczególnych rodzin)
2. Odpala się główny "rdzeń" arduino który dokonuje translacji z Arduino do ustandaryzowanego C++ (zapewne tym rdzeniem jest po prostu nieco bardziej rozbudowany preprocesor) 
3. Po preprocesorze do gry wchodzi toolchain czy też sam kompilator pod konkretną rodzinę,
4. Kompilator na podstawie wcześniej powiązanego z płytką pliku make tworzy już gotowy, skompilowany plik Hex 
5. Skompilowany plik wykonywalny wrzucany jest w program bootloadera i wgrywany na docelowe urządzenie.

Bardzo bym prosił o ewentualne poprawienie mnie, czy też głębsze uściślenia bądź chociaż linki do stron gdzie mogę znaleźć takie informacje. 

Dla ciekawskich: Próbuję stworzyć uniwersalny pakiet bibliotek w języku C we własnym standardzie nazewnictwa wektorów, rejestrów, pinów itp które mają się charakteryzować wysokim stopniem "portowalności" między różnymi mikroprocesorami. Obecnie mam prawie gotowy wzór dla Atmegi16, zatem cała rodzina Atmega powinna pójść dość sprawnie (Atmegi nie różnią się między sobą jakoś diametralnie pod względem wykonywania programu).
W obrębie jednej rodziny mogę praktycznie całą "robotę" ów portingu zrzucić na preprocesor, jednak migracje między rodzinami stanowią osobny problem.

Jeśli ktoś z Was byłby również chętny do pomocy przy tej inicjatywie to zapraszam do kontaktu Smile
Brzmi to może nieco skomplikowanie i groźnie, ale tworzenie plików HAL jest stosunkowo łatwe, niestety nieco pracochłonne ze względu na mnogość rozmaitych mikroprocesorów, dlatego też mile widziana jest wszelka pomoc! Wink
 
Odpowiedź
  


Skocz do:


Przeglądający: 1 gości