asembler a arduino

Witam Wszystkich

Czy są jakieś podobieństwa w programowaniu mikro kontrolera arduino a atmega16 w asemblerze?
Jeżeli potrzebuje zaprogramować w środowisku AVR opierając się na architekturze Atmelsowskiej Atmega16 jakąś sekwencje diod .
Jeżeli jestem w stanie (potrafię) to zaprogramować w arduino . Czy są między arduino a platformą avr atmel atmega16 jakieś cechy wspólne w programowaniu, które mogą mi pomóc szybko ogarnąć problem. Czy jest to zupełnie inne podejście wymagające użycia innego paradygmatu.

W arduino siedzi procesor avr. Mozesz olac cala biblioteke arduino i pisac jakbys mial sam procesor

Ale dlaczego assembler?

Assembler to o wiele przestrzelone.
Prawdopodobnie szukasz czegoś pośredniego, np C++ z Atmel Studio 7

W ekosystemie Arduino charakterystyka sprzętu jest "zamglona", w AS będziesz miał pełną kontrolę.

W arduino powiedzmy sobie radzę, potrzebuję teraz jakby w symulatorze avr studio bazując na asemblerze mikrokontrolera atmega atmel zaprogramować u uruchomić zadany system zmiennej sekwencji diod. Jeżeli chcę to zrobić w samym (jeszcze nie wiem jak to działa) symulatorze avr studio. Czy wiedza z arduino mi powinna pomóc czy jest to zupełnie inne podejście?

Po to stworzono C, żeby był przenośny na poziomie kodu źródłowego, ale jak chcesz asembler to nikt ci tego nie zabroni. Co do Arduino to może być problem np. z brakiem bootloadera w innym typie μC i jeżeli twój kod przypadkiem korzysta z "arduinowskich" funkcji to mogą pojawić się problemy.

Rdzeń AVR oba mają wspólne, w związku z tym instrukcje takie same. Paradygmat asemblera to pisanie bezpośrednio po rejestrach, których rozkład po krótkim spojrzeniu w pdfa mają chyba identyczny. Pinów jest więcej, dlatego tu pewnie wystąpią różnice. Trzeba by się wgłębić w dokumentacje czy występują jakieś różnice w poszczególnych rejestrach.

W zasadzie zapalenie diody to tu i tu wpisanie LOW/HIGH na odpowiedni bit. Roznica jest taka, ze w arduino masz jakies digitalWrite(pin, state) a w low-level-api PORT |= _BV(PIN).
Inna sprawa, ze w arduino masz bez zadnego wysilku np. PWM a w low-level-api musisz sam sobie wszystkie bity, wspolczynniki wypelnienia itd. ustawic

modulop napisał(a):

W arduino powiedzmy sobie radzę, potrzebuję teraz jakby w symulatorze avr studio bazując na asemblerze mikrokontrolera atmega atmel zaprogramować u uruchomić zadany system zmiennej sekwencji diod. Jeżeli chcę to zrobić w samym (jeszcze nie wiem jak to działa) symulatorze avr studio. Czy wiedza z arduino mi powinna pomóc czy jest to zupełnie inne podejście?

Bez bootloader arduino wgranego do μC nie będzie możliwości wgrywania programu poprzez USB. Na płytce istniej 6-pinowe złącze ISP, do którego podłącza się programatory, które mogą go programować i nawet wgrywać inne bootloadery. Różnice będą wynikać z braku wielu funkcji, które sporo upraszczają programowanie μC, ale bez obaw nie są to jakieś zaawansowane rzeczy.

Co do symulatora, plik binarny programu będzie korzystać z funkcji, które już siedzą na stałe w μC i nie wiem jak symulator sobie z tym poradzi. Skompilowany sketch arduino jest niekompletny i bazuje częściowo na tym co już w siedzi we Flashu. Sketch nie ma funkcji main, ona jest bibliotece arduino. Programując w AVRStudio masz kompletny program, z którym symulator na pewnie nie będzie miał problemu.

Asemblery miały większy sens w zupełnie innych czasach, inny stosunek kosztu wydajności/pracy programisty, ale co o wiele ważniejsze:
Ówczesne **procesory **miały niewiele (kilka) rejestrów, każdy nieco różniący się w funkcjach, idealne środowisko dla utalentowanego programisty asemblerowego, a kiepskie dla kompilatora
Obecnie mają kilkanaście/kilkadziesiąt jednakowych rejestrów. Nie do ogarnięcia dla człowieka, za to ideał dla kompilatora. Nikt nie opanuje bez błędów "aha, to które rejestry już mam zajęte i czym, a które wolne". A kodowanie na jeden/trzy rejestry będzie miał fatalną wydajność, gorszą od innych języków.

O stosunku kosztu hardwaru / programisty dzisiaj nie muszę mówić.

Co do symulatora, plik binarny programu będzie korzystać z funkcji, które już siedzą na stałe w μC i nie wiem jak symulator sobie z tym poradzi. Skompilowany sketch arduino jest niekompletny i bazuje częściowo na tym co już w siedzi we Flashu. Sketch nie ma funkcji main, ona jest bibliotece arduino. Programując w AVRStudio masz kompletny program, z którym symulator na pewnie nie będzie miał problemu.

Jesteś pewien? Bo doświadczenie uczy (a i logika wskazuje), że jakkolwiek Arduino jako biblioteka/framework załatwia wiele na poziomie kompilacji/linkowania (stąd np. brak maina, który leci "pod spodem") to na poziomie sprzętu to raczej tylko bootloader gadający z IDE, ładowanie jakiejś biblioteki standardowej do flasha z reguły nie jest praktykowane.
A z mojego doświadczenia z AVR: symulator działa ok. Aczkolwiek siłą rzeczy UARTu, SPI czy I2C nie przetestujesz. Zrobisz to już pod Proteusem...ale chyba nie warto go kupować jeśli na tym nie zarabiasz.
A, I jeszcze jedno: klasyczne Arduino to AVR, ale są też wersje oparte o ARMa. I tu już assembler będzie inny. Niby oczywiste, ale "najsampierw" to sprawdź co w zasadzie posiadasz.

alagner napisał(a):

Co do symulatora, plik binarny programu będzie korzystać z funkcji, które już siedzą na stałe w μC i nie wiem jak symulator sobie z tym poradzi. Skompilowany sketch arduino jest niekompletny i bazuje częściowo na tym co już w siedzi we Flashu. Sketch nie ma funkcji main, ona jest bibliotece arduino. Programując w AVRStudio masz kompletny program, z którym symulator na pewnie nie będzie miał problemu.

Jesteś pewien? Bo doświadczenie uczy (a i logika wskazuje), że jakkolwiek Arduino jako biblioteka/framework załatwia wiele na poziomie kompilacji/linkowania (stąd np. brak maina, który leci "pod spodem") to na poziomie sprzętu to raczej tylko bootloader gadający z IDE, ładowanie jakiejś biblioteki standardowej do flasha z reguły nie jest praktykowane.

Dzięki za sprostowanie. Zdaje się że palnąłem głupotę powtarzając dawno przeczytane rzeczy w Internecie i nie sprawdzając je dokładniej. Choć pewnie technicznie możliwe, co przy dużych programach pozwalałoby robić szybszy upgrade, no ale łatwiej by było tego nie robić.