RebellionArts wrote:Sam pracuje teraz nad urządzeniem, które wykorzystywać będzie kod do sterowania, i oczywiście piszę go w Atmel studio, wiem jaki prosty jest C bo przesiadałem się z BASCOM i mnie wryło dosłownie. No ale nie jest dział DIY działem innowacyjnych technologii. Zrozumcie to.
Takie przekrzykiwanie się o wyższości jednego języka nad drugim to w zdecydowanej większości domena mało doświadczonych programistów, którzy nie pisali rzeczy o dużej złożoności. O ile istnieją poważne różnice w stosowaniu C/C++ w zastosowaniach biznesowych - bo brak programowania obiektowego w dzisiejszych czasach praktycznie dyskwalifikuje takie strukturalne C. Co nie znaczy, że się nie da - bo da się wszystko. Jeśli ktoś umie tylko strukturalnie to lepiej niech pisze dobrze w tym co umie, niż robi byle jaką obiektówkę tylko dlatego bo inni mówią, że to lepsze. Nie można też wszystkich języków wrzucić do jednego "wora" bo to także duży błąd, natomiast jak ktoś 20 lat pisze w JAVA to nie ma sensu przekonywać go do C#, C++, Delphi, Pythona czy innych równie zaawansowanych języków bo we wszystkich zrobimy to samo. Różnice mogą jedynie wynikać z np:
- konieczność kompilacji do kodu natywnego ( co w Java jest oficjalnie nie do zrobienia );
- braku jakiś specjalistycznych bibliotek ;
- ceny środowiska ...
Z programowaniem uC a szczególnie AVR lub innych 8-bit'owców, używanie języków niższego poziomu (ASM, C) moim zdaniem jest wskazane i podyktowane malutką ilością RAM oraz pamięci programu. Napisanie programu używając obiektów, dziedziczenia, dużych uniwersalnych bibliotek może być zwyczajnie niemożliwe. Z drugiej strony sama wielkość pamięci programu nie pozwala na napisanie czegoś "dużego". Tym samym języki strukturalne doskonale sprawdzają się na tym polu i ciężko to negować.
Jednak gdy weźmiemy już takiego STM32 co ma 0,5Mb FLASH i 128KB RAM i mamy zamiar zapełnić całość sensownym programem ( a nie samymi danymi ) to w dzisiejszych czasach aż szkoda nie robić tego obiektowo przy użyciu np.: C++.
Nie zapominajmy, że użycie wybranego języka programowania jest jedynie narzędziem w osiąganiu celu a nie celem samym w sobie.
Jeśli końcowy projekt spełnia początkowe założenia to znaczy, że autor dokonał prawidłowego wyboru.
Oczywiście dokonałem kilku optymalizacji oraz zrezygnowałem z obsługi przerwania, które w tamtej postaci i tak nie działało zgodnie z moim zamierzeniem.
.