Ankieta: Jaki system operacyjnym preferujesz
Ankieta jest zamknięta.
Windows 60.78% 31 60.78%
Linux 31.37% 16 31.37%
MAC/OS 7.84% 4 7.84%
Inny 0% 0 0%
Razem 51 głosów 100%
*) odpowiedź wybrana przez Ciebie [Wyniki ankiety]

Odpowiedz 
 
Ocena wątku:
  • 1 Głosów - 5 Średnio
  • 1
  • 2
  • 3
  • 4
  • 5
Programowanie ARM, nauka, środowiska programistyczne IDE
SQ6DGT Offline
Robert
*

Liczba postów: 41
Dołączył: 22-05-2011
Post: #16
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Generalnie się zgadzam, faktycznie tak jest, że można napisać kod bardziej zwarty i szybki przy wykorzystaniu asemblera i bez bibliotek. Problem zaczyna się wtedy, kiedy kod staje się duży, skomplikowany, trzeba go utrzymywać i/lub dzielić się pracą nad nim z większą grupą. Wtedy zysk z niskopoziomowego pisania zostaje skonfrontowany ze stratą spowodowaną nieczytelnością kodu, brakiem określonej architektury (co jest częste przy niskopoziomowym pisaniu) i ogólną podatnością na błędy przy nawet małych modyfikacjach. Dawno temu jak pisałem pod C64 na Motorolę 6502 pisałem w czystym asemblerze, wykorzystanie choćby C wydawało mi się koszmarnym marnotrawstwem. Napisanie np. sortowania dynamicznie tworzonej mapy czy innych struktur danych, które są potrzebne przy bardziej skomplikowanych zagadnieniach, to było nie lada wyzwanie. Niemal szczyt możliwości. W językach wyższego poziomu, z bibliotekami, to rutyna.

To jest oczywiście moje zdanie, ale asembler jest ważny tylko tam gdzie jest absolutnie kluczowy i inaczej się nie da. Tak jest pewnie w algorytmach DSP na gołe STM32, choć i tu nie dam głowy czy nie są pisane w C. W 99% przypadków zwykłe C jest już wystarczająco niskopoziomowe.

Projekt powoli mi się rozrasta i zastanawiam się nad przepisaniem fragmentów np. mojej biblioteczki do komunikacji przez UART na C++. Po co ? Np. bardziej podobałoby mi się stworzenie np. obiektu do komunikacji w ten sposób:

Usart rs1 = new Usart(USART1, 115200, 8, 1, 200);

gdzie argumenty to nr. USART, prędkość, bity danych, bity stopu, timeout w ms. I potem:

if(rs1.error()) { .... } czy
if(rs1.success()) { ....}
if(rs1.hasData()) {
rs1.read(&buf, 200); gdzie 200 - maks długość, a dla sprawdzenia statusu operacji:
}

i dalej w tym stylu.

Mam to teraz w C gdzie każdorazowo zmieniam sobie definicje w nagłówku dla konkretnych danych. Tutaj byłoby ładnie zamknięte w obiekcie (albo strukturze), mógłbym stworzyć kilka takich obiektów dla wielu portów na raz, itd. Trzeba by napisać kod w konstruktorze, któryby poustawiał wszystko w MCU, podłączył zegar tam gdzie trzeba itd. Może nawet remap by się przydał, byłoby trochę kodu, czasem może nie potrzebnego. Ale jaka wygoda i mała podatność na błędy! W tym stylu widziałbym np. biblioteki do obsługi np. DDS-ów, SPI, I2C itd. Składałoby się z klocków a kod dbałby o to, żeby zegary były podane do odpowiednich modułów MCU itd. Wiem, że SPL/HAL idą w tym kierunku ale IMO są dalej pisane nieco kryptologicznie. Moje podejście jest takie, że biblioteka powinna być jak towar dla programisty: ładna, zgrabna i funkcjonalna, żeby kod był mały i prosty i chciało się programować :-)

Robert HF6ROB
(Ten post był ostatnio modyfikowany: 29-06-2016 11:01 przez SQ6DGT.)
29-06-2016 11:00
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
Odpowiedz 


Wiadomości w tym wątku
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ6DGT - 29-06-2016 11:00

Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości