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ć :-)
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