Witam.

Chciałbym zaprezentować swoją bibliotekę do obsługi USART'a.
Jest to mój pierwszy "projekt" na taką skale, więc prosił bym o trochę wyrozumiałośći.

Powodem popełnienia tej biblioteki jest to iż wiele z ogólnodostępnych bibliotek dedykowanych C++, jest doskonałym przykładem jak NIE NALEŻY tworzyć bibliotek w C++.

Zamysł był taki aby biblioteka ta:

-była prosta w użyciu
-obsługiwała najpopularniejsze mikrokontrolerki AVR
-możliwie jak najbardziej zoptymalizowana
-obsługiwała 2 uarty UPDATE: teraz 4
-umożliwiała transmisje binarną (szybka implementacja pewnych protokołów np. xmodem)
-dawała użytkownikowi wybór czego chce używać a czego nie, bez grzebania w kodzie


dla prostego przykładu



uzyskujemy

Oczywiście rzeczywiste 'Data Memory Usage' jest większe o bufory i kilka zmiennych pomocniczych.

Ze zdefiniowaną flagą NO_USART_RX uzyskujemy wolny pin rx oraz


Jak widać rozmiarowo biblioteka ta jest porównywalna z analogicznymi tworami w C, nawet pomimo narzutu obiektowości.
Oczywiście dobrze napisana biblioteka C raz będzie większa albo mniejsza zależnie od użycia jak i "jakości" tej biblioteki.


Funkcje udostępniane przez nią są już dosyć znane i chyba nie trzeba tłumaczyć jak działają





Spotkałem się już z wieloma przeróżnymi sposobami na operowanie w przerwaniach na składowych klasy, każda kolejna jeszcze bardziej zagmatwana od poprzedniej. (oczywiście z wiadomym skutkiem dla zasobów)



Zastosowałem również raczej rzadko spotykaną optymalizacje operacji na zmiennych 'volatile'.
Mianowicie kompilator zakłada że zmienna taka będzie się zmieniać co każdy cykl zegarowy, więc co każde kolejne wywołanie pobiera jej wartość z pamięci. My natomiast wiemy że jest to konieczne jedynie ze względu na metodykę działania przerwań które nie mają dostępu do zmiennych trzymanych w rejestrze i zrzucanych na stos po wejściu w nie. Natomiast wewnątrz funkcji/przerwań ciągłe wczytywanie tej samej wartości z pamięci nie jest ani trochę oszczędne, a tak się właśnie dzieje z 'volatile'.



Dzięki temu udało mi się zrzucić kilkadziesiąt bajtów z kodu wynikowego zbliżając sie do tego co można uzyskać w C.
Oczywiście biblioteki C również można odchudzić tą metodą i bez użycia drugiego uarta będą znów mniejsze niż ich obiektowe odpowiedniki.

EDIT: Aktualny kod dostępny jest na githubie
https://github.com/jnk0le/Easy-AVR-USART-Class-Library

Dla miłośników C już jest dostępna odpowiednia wersja tej biblioteki
https://github.com/jnk0le/Easy-AVR-USART-C-Library

wszelkie uwagi i pomysły odnośnie tego co można dodać/poprawić mile widziane.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

Bardzo ciekawy projekt , ale ...



proponuje nabrać nieco pokory i wrzucać wszystkiego do jednego worka .....
nie każdemu pasuje c++ i nie każdemu C czy arduino , wersji jest tyle ilu programistów , kogoś mógł kolega obrazić

w konkretnym przykładzie tez widzę parę miejsc które się zemścić mogą, ale nie to jest wątkiem naczelnym postu i niechaj inni się
wypowiadają.

Z życzeniami wiary w "obiektowość" w Cpp z pełnym wsparciem dla paradygmatu funkcyjnego ... (to miał byc sarkazm)

oby tak dalej

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

No racja, jest wiele bibliotek które są zrobione prawidłowo bez specjalnych fajerwerków.
Chodziło mi o biblioteki które są jawnie naładowane absolutnie bezużytecznym kodem, albo wzięte biblioteki C ze zmienionym uart0_puts(char *str) na const char* str i


A co do arduino, widziałem kod, najbardziej mnie urzekły zahardcodowane tablice z UBBR


Nieczytelny kod, rozwalone tabulatory (bo wszędzie są inaczej traktowane), czy te moje "optymalizacje" które potrzebują konkretnych testów ?


Niestety implementacja pewnych elementów obiektowości ciągnie za sobą masę zasobów których na AVR'ach nie ma zbyt wiele.
Ta moja "obiektowość" jest widziana po stronie użytkownika który ma obiekt USART i na nim operuje.



Wszelka krytyka jak najbardziej mile widziana, chciałbym się na przyszłość dowiedzieć co powinienem robić, czego nie, a czego należy unikać jak ognia itd.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

Gdyż wyszło by dokładnie to samo tylko że w jeszcze mniej czytelny i mniej zrozumiały sposób.

No i szablony miały z założenia wyeliminować wielokrotnie powtarzające się te same funkcje dla typu int, double, float, czy zdefiniowanych przez użytkownika. Uproszcza to klepanie kodu, ale w pliku wynikowym już będą oddzielne funkcje dla każdego typu.
Na pc masz nieograniczone zasoby (że aż nikt nie zdaje sobie sprawy jak wygląda implementacja new(std::nothrow)) to na avr'kach nie można sobie pozwolić na rozrost kodu wynikowego.


Zapomniałem przedstawić konstruktorów i zaczyna się to na mnie mścić


do zmiany ustawień "in runtime", można użyć dodatkowej metody jak zaproponowałeś

A jaki jest sens "blokującego" uarta w bibliotece na buforach ? (takie to się widuje w kodzie początkujących, którzy dopiero co zaczęli naukę programowania avr'ów) Szczególnie gdy raz użyty kod nie jest "hardcodowany" ponownie dla użytku drugiego uarta.



Makra też na to pozwalają, a używam ich głównie do kompilacji warunkowej i "uniwersalizacji" rejestrów pomiędzy różnymi atmegami.



Poszerzenie kompetencji polega tu głównie na dodaniu funkcji odbierania/wysyłania do klasy i tyle.
A cała zabawa z dziedziczeniem czy funkcjami wirtualnymi a) może wpłynąć na rozmiar kodu wynikowego b) nic nie zmieni w tak małym przykładzie. Na PC gdzie same metody nieraz mogą mieć po 2k lini oraz występuje masa zależności jest to jak najbardziej uzasadnione.


Biblioteka przygotowana jest do pracy ze stringami zgodnymi z ogólnymi zasadami C, ale nic nie stoi na przeszkodzie aby dopisać sobie funkcje do obsługi takich stringów tak jak do odczytu zrobiłem




EDIT: Z tego co się dowiedziałem to niestety trzeba "na zewnątrz" przygotowywać dane z eepromu do wysłania uartem. No i odczyt epromu wewnątrz klasy uarta byłoby tym o co cały czas mi wytykasz


Jedyne zastosowanie tego rozwiązania to zewnętrzny sram, ale nie wiem czy takie rozwiązanie korzysta z jakiegoś interfejsu, czy jest "doadresowane" do głównej pamięci więc ciężko mi to ocenić.

No i kwestia zasobów, czy takie dziedziczenie lub trzymanie bufora w oddzielnym obiekcie nie będzie miało wpływy na rozmiar kodu ?

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

@mokrowski
1. A jakie obliczenia mogą wykonać szablony, których nie wykonają makra, i co w moim kodzie można obliczyć jeszcze poza BAUD_CALC ? Mi się od zawsze wydawało że obliczenia w trakcie kompilacji wykonuje kompilator ustawiony na inną flagę niż -O0 niezależnie od tego czy są jakieś szablony czy jest to bezpośrednio w kodzie.
2. W zasadzie mogło by oszczędzić paru makr, ale nie bardzo wiem jak to uzyskać w obecnym kodzie.
3. A którą implementacje masz na myśli ?

Nie jestem pewien czy obecne biblioteki standardowe libc++, MSVCRT itd. posiadają tą "funkcjonalność" bo wszystko jest zaszyte w skompilowanych dll'kach i nie bardzo można to sprawdzić .

4. wyjątkowa racja
5. Problem jest taki że takie ATiny co mają wyjątkowo mało ramu raczej nie posiadają drugiego uarta
W zasadzie transmisje blokującą można uzyskać przez ustawienie buforu na 1 bajt (kod obsługi bufora jest współdzielony więc nie ma "puchnięcia" na drugim uarcie). Niestety w obecnym kodzie obsługa takich różniących sie buforów nie obędzie się bez doładowania biblioteki kodem do obsługi tychże.
(jakieś warunki w konstruktorze, potrzebne są zmienne dla rozmiaru bufora/maski, może nawet jakieś dodatkowe metody pracy na tymże buforze, No i jak by wyglądało "dobieranie" się do takiego bufora w przerwaniu )
7. Biblioteka ta w zamyśle miała służyć do operacji znakowych jakimi są właśnie putstr() putint() itd. (tak jak w wielu innych bibliotekach), których jest tylko 7 (+2 makra) z czego używanych będzie najwyżej 4. Dla tak małej ilości funkcji, praktycznie tego samego zastosowania (operacje znakowe) jakoś niewielki jest sens rozdzielania klasy na podklasy z 'przeklejonymi' kilkoma funkcjami.

No i kwestia zasobów - co z tego że oddzielę bufor od głównej klasy skoro rozwiązanie zachowujące obecny rozmiar kodu nie będzie się niczym różniło od obecnego. (czyli nadal mamy umieszczony w klasie bufor definiowany makrem)
Ale mimo wszystko zewnętrzny bufor który jest rzeczywiście reużywalny (a nie że jest po prostu 'wycięty' z jakiejś konkretnej klasy) dla i2c, usb, adc itd. to dosyć ciekawy pomysł i czekam z niecierpliwością na dalszy cykl poradników (może jakoś mnie nakierują na właściwą drogę)
A sama biblioteka na obecnym etapie najbardziej by zyskała na przepisaniu jej do C co by zrzuciło kolejne bajty narzutu.

EDIT:

Właśnie mi przypomniałeś dlaczego tak a nie inaczej napisałem: jest ich masa i 99% z nich nie spełnia twoich założeń, a jak by tego było mało, są one napisane do obsługi jednego uarta a próba implementacji drugiego skończyła by się ... na przepisaniu CAŁEJ biblioteki od nowa , czyli jawnie łamią zasadę reużywalności (bo hardcodowanie w C wyjdzie znacznie lepiej).

No i obawiam się że użycie zewnętrznych buforów wymaga dynamicznej alokacji.

EDIT2:
Mimo wszystko dzięki za wszelkie uwagi odnośnie "obiektowości" mojego kodu.
Prawdopodobnie z tym hardcorowym podejściem do optymalizacji przeniosę się do C, a tej bibliotece pozwolę trochę napuchnąć o obiektowość
Tak apropo, to ile flasha zajmuje twoja implementacja (lub celujesz że będzie zajmowała) dla zwykłego "hello worlda" i bardziej rozbudowanych przykładów ?

Teraz potrzebował bym jeszcze zebrać opinie o samym kodzie, jego 'jakości', komentarzach (za dużo, za mało, są miejsca niejasne, albo po prostu brakuje komentarzy z serii 'captain obvious' ) czy nawet sposobie (i brakach) w przedstawieniu tej biblioteki.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

Ostatnio troszkę popracowałem nad biblioteką, która obecnie znacznie się różni od wersji pierwotnej.

changelog:

-poprawione makra w tablicach uniwersalizujących, oraz dodanie paru atmeg do tychże
-funkcja putc() mogła wpaść w nieskończoną pętle po zapełnieniu buforu wysyłania (mimo że w początkowych testach działało dla 5x dłuższych stringów niż bufor i nagle nie działa ...)

-ogólna poprawa czytelności kodu
-redukcja kodu wynikowego o ok. 10 bajtów (i nie wiem właściwie jak )
-dodanie pełnej obsługi 4 interfejsów szeregowych (ATmega 640/1280/2560)
-oraz dodanie drobnej funkcjonalności (AvailableBytes, oraz planowane putfloat)

Obecnie zastanawiam się nad implementacją zewnętrznych buforów, aby nie uzależniać się od jednego możliwego rozmiaru bufora dla wszystkich nadajników/odbiorników.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib

Z szablonami jest ten problem że same w sobie są mało czytelne, sam musiałem kilka razy to "przelecieć" aby ogarnąć jak to mniej więcej dziala.
1. Tolerancja 2% lub dowolna inna - u mnie działa 57600 @8MHz co daje 4%, natomiast w pewnych sytuacjach nawet 0,2% to może być za dużo.
2. Automatyczne wybranie najbliższego "pasującego" UBBR - a co potem wpisać w putty ?
3. Co z ustawianiem bitu U2X dla kilku różnych seriali ? (bez tego to nie mam nawet co próbować implementować liczenia na szablonach)
4. Mam nadzieje że static_assert wywala błąd kompilacji, choć nic na to nie wskazuje (szablony i czytelność)

Zamiast sprawdzania siłowego kolejnych baudrate w swoich projektach, lepiej zapoznać się z tabelkami i mieć z głowy problem zapuszczania szablonowego skryptu na pc.

np. 1 wynik z gógla http://wormfood.net/avrbaudcalc.php?postbitrate=57600&postclock=8&u2xmode=1

EDIT: No i widzę że rozwiązanie w Cy wymaga globalnej definicji baudrate, co odpada z miejsca.

I co to za zwyczaj nie używania 'using namespace std;' ?


PS putfloat już dodane.

_________________
AVR-UART-lib
AVR-FAST-ENCODER
RFM7x-lib