Zmiana Arduino IDE na Atmel Studio

[Anonim]

Używanie wskaźników na funkcje jako składników struktur ma tę zaletę, że zostaje zachowana kompatybilność z już napisanym softem. Wywołaniom w procedurze sterującej lub w innych bibliotekach jest wszystko jedno czy wciągają obiekt klasy czy struktury a odwołania do składników są dokładnie takie same w obu przypadkach więc ewentualne przeróbki sprowadzają się do kosmetyki (głównie kropki na strzałki jeśli potrzeba) a jednocześnie można sporo zaoszczędzić wykorzystując C zamiast C++. Przy odrobinie finezji można dzięki tej metodzie wykorzystać w sporym zakresie możliwości jakie daje programowanie obiektowo orientowane a nawet polimorfizm w pewnym sensie (taka sama nazwa pola, przypisany adres innej funkcji) co w znacznym stopniu ułatwia budowanie systemów wieloprocesorowych. Nieco problematyczne jest natomiast pilnowanie wszystkiego manualnie na etapie pisania kodu. Później wszystko działa dokładnie jak w C++ tylko wyraźnie szybciej i zazwyczaj mniej zasobożernie.

Brzmi być może zbyt poważnie biorąc pod uwagę fakt, że taki "system wieloprocesorowy" to powiedzmy 3 sztuki arduino pro mini 😜 ale jaka za to frajda 🙂

Dodam jeszcze tylko, że zazwyczaj takie "metody" zawierają proste procedury więc z powodzeniem mogą być napisane w asm co daje jeszcze większe oszczędności w stosunku do C a już na pewno do C++ więc finalnie odnosi się wrażenie, że proste arduino pro mini może pomieścić wielokroć więcej niż to samo pisane za pomocą frameworka arduino w C++.

[InspektorGadzet]

18 minut temu, atMegaTona napisał:

zawierają proste procedury więc z powodzeniem mogą być napisane w asm co daje jeszcze większe oszczędności w stosunku do C

Z tym się nie zgodzę. Owszem, 50 lat temu tak było, teraz C potrafi kod bardzo dobrze zoptymalizować, że wielu programistów jest w szoku, ze tak można. Najczęściej nie da się lepiej napisać w ASM niż w C. AVR-GCC jest wyjątkiem (pewnie nie tylko GCC) i tylko w pewnych specyficznych sytuacjach. Kilka razy (na kilkaset) sięgnąłem po ASM w AVR. GCC niepotrzebnie (czasem) wywala na stos coś co nie jest używane (R0, R1, RAMPZ) ale w ilu przypadkach jest to problemem?

[Anonim]

Takich przykładów można przytaczać całą masę. Nie chodzi o to, że to jest problem, chciałem zwrócić uwagę na to, że to się często opłaca przy prostych metodach tak samo jak w przypadku krótkich procedur obsługi przerwań. Tworząc bardziej skomplikowany projekt każdy sam oceni kiedy i co się opłaca a kiedy nie jak w wielu innych przypadkach np. czy warto wykorzystać dynamiczną alokację pamięci aby oszczędzać zasoby kosztem szybkości działania czy nie warto ale na pewno warto mieć na uwadze taką możliwość.

Dochodzi tu jeszcze jeden czynnik jeśli nie ważniejszy to równie ważny jak optymalne wykorzystanie zasobów i ograniczanie wydatków a mianowicie fakt, że niektórzy po prostu kochają 8bitowe mikrokontrolery i nawet kiedy jest łatwiej i bardziej się opłaca stosować STM32 i tak wolą bawić się z AVR czerpiąc z tego satysfakcję. Nie ma sensu nikogo na siłę nawracać.

[ethanak]

11 minut temu, atMegaTona napisał:

Nie ma sensu nikogo na siłę nawracać.

I na tym proponuję zakończyć ową niewątpliwie ciekawą dyskusję nad wyższością Świąt Wielkiej Nocy nad Świętami Bożego Narodzenia 🙂

BTW @InspektorGadzet sprawdź sobie co dokładnie oznacza "pytanie retoryczne" i jak się na takowe odpowiada.

Edytowano Lipiec 16, 2019 przez ethanak

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Bonkers]

Dziękuje wszystkim za tak ogromną reakcje na moją pytanie . Nie spodziewałem się, że wywiąże się z tego tak ciekawa dyskusja 😀.

8 godzin temu, Matthew11 napisał:

Jak ktoś jest zainteresowany to zdecydowanie polecam pisać w Visual Studio Code z dodatkiem PlatformIO (nie tylko w przypadku Teensy, ale ogólnie wszystkiego co jest zgodne z Arduino). 

Przy okazji bardzo ciekawe środowisko, bardziej rozbudowane niż Arduino IDE, może trochę mniej niż AS, ale daje rade. Poza tym bez debuggera, programatora to bardziej się opłaca z niego korzystać niż z AS.

Postanowiłem, że póki co nadal będę pisał programy w C++ na Arduino, równocześnie ucząc się podstaw C na AVRy pisząc jakieś proste programy, do obsługi led'ów, wyświetlaczy, przycisków itd. Nadal uważam, że pisanie w C ma więcej plusów niż C++ jeśli chodzi o mikrokontrolery i przykłady, które przytaczaliście. Może nawet zacznę pisać w ASM, bo z tego co wiem to przypomina to język STL do PLCków, z którymi też mam aktualnie do czynienia.

W przyszłości jak już ogarnę C na AVR, zabiorę się za ARM, STM, bo rzeczywiście jeśli chodzi o takie hobbystyczne sprawy to AVRy wystarczają, ale jak się już chce poważne rzeczy robić to trzeba ogarnąć resztę.

 

[InspektorGadzet]

13 minut temu, Bonkers napisał:

zacznę pisać w ASM, bo z tego co wiem to przypomina to język STL do PLCków,

STL to język drabinkowy nie ma nic wspólnego z ASM.

50 minut temu, atMegaTona napisał:

niektórzy po prostu kochają 8bitowe mikrokontrolery i nawet kiedy jest łatwiej i bardziej się opłaca stosować STM32 i tak wolą bawić się z AVR czerpiąc z tego satysfakcję

Tyle, że wielu rzeczy na AVR nie da się zrobić i na nic zda się tu miłość. Nie da i koniec, chyba, że dodasz FPGA a AVR będzie niewielkim i na 90% cały projekt da się zrealizować tylko na FPGA, AVR staje się zbędny.

50 minut temu, atMegaTona napisał:

Nie chodzi o to, że to jest problem, chciałem zwrócić uwagę na to, że to się często opłaca przy prostych metodach tak samo jak w przypadku krótkich procedur obsługi przerwań

Na ARM nie będziesz musiał używać ASM. Tak jak w AVR mi się to kilka razy zdarzyło tak w ARM nigdy. ARM ma wielopoziomowy system przerwań, ja ową wielopoziomowość w pewnym stopniu realizowałem programowo i w przypadku przerwań odbiorczych od UART, trzeba wtedy czasem sięgać do ASM. W AVR czasem wywalałem niepotrzebne push i pop R0, R1 w przerwaniu, w ARM problemu nie ma, bo odkładanie są sprzętowo wszystkie rejestry i nie masz na to wpływu. trzeba wiedzieć, że odkładanie i zdejmowanie jest  inteligentne i gdy nie trzeba tego robić to nie ma tej operacji.

Edytowano Lipiec 16, 2019 przez InspektorGadzet

[Anonim]

Wszystko zależy od wielu różnych zależności a każdy wybiera to co mu aktualnie pasuje lub czego potrzebuje lub, co najsmutniejsze, na co go stać... Jeśli ktoś "kocha" 8bitowce to zapewne doskonale wie co na nich zrobić można a czego nie. Nie rozumiem natomiast czemu ma służyć to rozciąganie tematu. Pochwaliłeś się, że jakąś wiedzę masz i albo się nią chełpisz i napawasz dla samego siebie albo szukasz pracy lub żony... Nie obraź się ale nie STMów temat dotyczył a ty nie dość, że zrobiłeś offtop to jeszcze napompowałeś go samouwielbieniem. Nikt nie kwestionuje Twojej wiedzy ale postaraj się trzymać ją pod kontrolą. ;)

[InspektorGadzet]

2 godziny temu, atMegaTona napisał:

Jeśli ktoś "kocha" 8bitowce to zapewne doskonale wie co na nich zrobić można a czego nie.

Wielu nie wie i przelicza się. Efekt to np pierwsza wersja urządzenia z TFT 320x240 a druga, gdy delikwent zobaczył, ze AVR jest za cienki, a dokładniej ma za mało RAM, z alfanumerycznym LCD.

 

2 godziny temu, atMegaTona napisał:

co najsmutniejsze, na co go stać..

No właśnie, ARM są tańsze od AVR, debugery także.

 

2 godziny temu, atMegaTona napisał:

albo szukasz pracy lub żony

Żon mam już dosyć a jedna swoja to o dwie kobiety za dużo. Lepsza praca? Nie powiem, skusiłbym się, lubię co 10 lat zmienić otoczenie.

 

Co do offtop, szukasz wydajniejszych rozwiązań niż Arduino i próbujesz to robić przez zmianę softu, wstawki ASM. Nie tędy droga do większej wydajności. Możesz się z tym nie zgadzać ale tak jest. W ofertach pracy dawno nie widziałem AVR, przeważnie ARM i Linux.

Edytowano Lipiec 16, 2019 przez InspektorGadzet

[ethanak]

No to wróćmy do początku 🙂

Przede wszystkim: w Arduino IDE można równie dobrze pisać w C, zarówno wstawki jak i całe programy (pusty plik .ino i reszta w C, tyle że bibliotek Arduino nie wykorzystasz). Builder się zorientuje i włączy odpowiednią wersję kompilatora.

AS może jest wspaniałe ale ma jedną wadę: na moim Linuksie nie pójdzie, a specjalnie dla niego nie będę Windowsa instalować (wszystkie pozostałe windowsowe programy których potrzebuję bardzo grzecznie działają przez Wine).

Arduino IDE ma owszem kilka wad - jedną z nich jest straszliwy "edytor" (cudzysłów użyty intencjonalnie), ale na szczęście daje możliwość pracy z Twoim Ulubionym Edytorem (ja używam Geany). Czasem przeszkadza również to, że przy pisaniu programów na ESP i użyciu OTA nie mam jak użyć monitora serial - ale ów monitor to również nie jest dzieło sztuki i CuteCom bardzo dobrze go zastępuje.

Jeśli ktoś nie chce w ogóle widzieć na oczy interfejsu Arduino IDE - może użyć arduino-buildera i avrdude czy to z linii poleceń, czy z jakiegoś skryptu (choćby podpiętego pod menu edytora).

Wszelkie wynalazki które nie używają arduinowego buildera są w mniejszym lub większym stopniu (ale nie w 100%) kompatybilne z Arduino IDE, a brak kompatybilności wychodzi z reguły wtedy kiedy coś jest potrzebne.

Co do assemblera... ostatni raz kiedy musiałem go użyć to były lata 90-te i Amiga 500 (dostępne wtedy kompilatory dość słabo sobie radziły z optymalizacją a ja się musiałem zmieścić w czasie aby przeliczyć i wysłać dane do Lightmastera w przerwaniu VBLANK) oraz również w tym samym okresie zabawy z PIC 16F84 (bo tu nie miałem wyboru języka programowania). Owszem, warto go znać ale nie jest to warunek konieczny do programowania.

 

[Elvis]

Ja tylko wspomnę, że ARM to nie tylko Cortex-M więc to co zostało wcześniej napisane nie jest prawdą - w przypadku Cortex-M ogólnie się zgadza, ale już na Cortex-A nie. Natomiast znajomość asemblera bardzo się przydaje, chociażby podczas debugowania. Poza tym  w Cortex-A jest potrzebna przy obsłudze przerwań, ale nawet na Cortex-M kod wykonywany przed wejściem do main jest napisany w asemblerze. Natomiast poleganie na tym co ST dostarcza nie zawsze wystarcza.

[ethanak]

25 minut temu, Elvis napisał:

znajomość asemblera bardzo się przydaje, chociażby podczas debugowania

Żeby wszystko było jasne: zgadzam się z tym, chciałem tylko powiedzieć że nie trzeba od razu uczyć się asemblera aby zacząć programować AVR-y w C.

[InspektorGadzet]

1 godzinę temu, Elvis napisał:

ale nawet na Cortex-M kod wykonywany przed wejściem do main jest napisany w asemblerze.

Jak się ktoś zaprze może napisać w C. Pytanie po co?

 

1 godzinę temu, Elvis napisał:

Natomiast znajomość asemblera bardzo się przydaje, chociażby podczas debugowania.

Najpierw trzeba używać debugera czego 98% osób na tym forum nie robi. Jak już się używa, to do ASM sięga się niezwykle rzadko. Nie pamiętam kiedy ostatnio na ARM przy debugowaniu, sięgałem do ASM. Co innego w AVR ale tam nie podczas debugowania tylko podczas robienia wstawek ASM.

Edytowano Lipiec 17, 2019 przez InspektorGadzet

[Elvis]

Skoro piszesz tylko banalne programiki sterujące diodami to nic dziwnego, że asember nie jest ci potrzebny. Ale skąd masz dane że 98% osób na tym forum nie używa debuggera to chyba napiszesz, bo przecież nie wymyśliłeś tych danych i głupot nie piszesz, prawda?

[InspektorGadzet]

1 minutę temu, Elvis napisał:

Skoro piszesz tylko banalne programiki sterujące diodami

Cóż, nawet ledem nie potrafię zamigać, co widać w projekcie, który pokazałem na tym forum.

 

1 minutę temu, Elvis napisał:

Ale skąd masz dane że 98% osób na tym forum nie używa debuggera

Z CBOS.

[Elvis]

4 minuty temu, InspektorGadzet napisał:

Z CBOS.

Czyli jednak piszesz głupoty, bo nie masz nic innego do roboty. W sumie to przykre.