microgeek.eu

Witam

Z racji tego, ze lubię pracować na różnych wyświetlaczach w zależności od potrzeb opracowałem sobie "uniwersalną" bibliotekę do wyświetlaczy. Na czym to polega - głównym założeniem jest praca na buforze w RAMie (skoro taki STM32F030F4P6 ma 4kB to czemu z tego nie skorzystać?). Moja biblioteka oferuje więc podstawowe funkcje do pisania po buforze, wklejania obrazków, dodam może potem jakieś rysowanie figur itp. Za pomocą #define w środku wybieramy LCD i następuje podmienienie funkcji inicjalizacyjnych oraz tych do wysyłania bufora danych. Dzięki temu kod jest w 100% zgodny z różnymi wyświetlaczami np ja go napisze na OLEDzie, a ktoś inny uruchomi na LCD z UC1701 zmieniając tylko jeden #define.

Przykładowy projekt (dla STM32F030F4P6) wraz z biblioteka jest wrzucony na githuba: https://github.com/dambo1993/universal_lcd_stm
Obecnie biblioteka wspiera:
- OLEDy z sterownikiem SSD1306
- LCD ze sterownikiem UC1701
W kodzie są fragmenty dotyczące ST7920 - tej biblioteki nie mogłem wstawić, bo nie jest moja.
W przyszłości dodam też LCD od nokii 5110 oraz robię mały projekcik na dwukolorowej matrycy LED 32x16 (dostępnej tanio na ebayu) - ona też będzie działać z tą biblioteką.

Jakby ktoś rzucił okiem i poradził/skrytykował to byłbym wdzięczny

Edit: dokumuntacja biblioteki: https://dambo1993.github.io/universal_l ... index.html

Tak na pierwszy rzut oka całość wygląda dość zgrabnie. Wiem, że pogodzenie skrajnie różnych wyświetlaczy w jednej bibliotece nie jest łatwe (zwłaszcza w C), a pisanie biblioteki oparte w głównej mierze na makrach jest mocno niezalecane z powodu braku jakiejkolwiek kontroli nad tymi makrami. Co bym zmienił... Na pewno zmieniłbym nazewnictwo funkcji, by uzyskać jakąś namiastkę standardu. Np.:


oraz


W przyszłości łatwiej będzie się dopisywało kod do już istniejącego. Poza tym kwestia polskich nazw... Osobiście jestem za angielskimi, bo wtedy będziesz miał szersze grono odbiorców (zwłaszcza wśród początkujących). Publikujesz kod na githubie, więc zasięg masz globalny. Aha, jedna rzecz mi się tam nie podobała...



Co prawda wiem, co robi ów kawałek kodu, ale staraj się tak nie pisać. Nie musisz w ten sposób udowadniać, że znasz się na swojej robocie Oczywiście jeśli cel był inny i ma na celu automatyzację jakiegoś procesu, chętnie poczuję się przez Ciebie oświecony.

Ok, a teraz propozycje:

Zamiast stada makr proponuję w inicie dopinać odpowiednie danemu wyświetlaczowi funkcje do statycznych wskaźników na funkcje.. Wtedy pozbędziesz się makr i uzyskasz całkowicie jednolitą strukturę funkcji. LCD_Update będzie wywoływało funkcje przez wskaźnik, a od jednego jedynego makra będzie zależało, która funkcja zostanie podłączona w inicie pod ten wskaźnik. Nie wiem, czy dość precyzyjnie się wyraziłem, ale w razie czego dopytaj.

Wniosek końcowy:

Bardzo mi się podoba!

To jest takie moje lenistwo trochę nauczyłem się podmieniać szybko te pliki z obrazkami, a kod zostawiać bez zmian dzięki temu

Antystatyczny pisze:Ok, a teraz propozycje:

Zamiast stada makr proponuję w inicie dopinać odpowiednie danemu wyświetlaczowi funkcje do statycznych wskaźników na funkcje.. Wtedy pozbędziesz się makr i uzyskasz całkowicie jednolitą strukturę funkcji. LCD_Update będzie wywoływało funkcje przez wskaźnik, a od jednego jedynego makra będzie zależało, która funkcja zostanie podłączona w inicie pod ten wskaźnik. Nie wiem, czy dość precyzyjnie się wyraziłem, ale w razie czego dopytaj.

A mogę prosić o przykład dla takiego rozwiązania? Coś jak callbacki, ale statyczne przy kompilacji - w dobrym kierunku ide? Z tym, ze teraz poprzez #define wykluczam też pliki z includowania do nadrzędnej biblioteki, więc chyba musiałbym to też pod ten sposób odpowiednio przerobić?

Tak, w dobrym kierunku. Robisz sobie wskaźniki na funkcje. Oprę się na funkcji Update. Tworzysz void ( *LCD_Update)(void); a dopiero w inicie dopinasz do tego wskaźnika jedną z funkcj aktualizujących wyświetlacz. Którą? Ano tę, która odpowiada ustawieniu makra wybierającego wyświetlacz. Później w kodzie napiszesz LCD_Update(); i program skoczy od razu w odpowiednią funkcje aktualizującą. Jeśli masz więcej sprzętowych funkcji, dla każdej z nich ( o ile posiadają swój funkcjonalny odpowiednik przy innym wyświetlaczu) robisz osobny wskaźnik na funkcję.

ok, czyli dzięki temu makra z różnych funkcji znikną i zostaną tylko makra w inicie decydujące o tym, jakie funkcje przypisać, tak?

Tak, dokładnie. Będzie ładnie i przejrzyście, a w miarę rozrastania się biblioteki tylko init będzie coraz bardziej spuchnięty, bo to będzie jedyne miejsce, w którym będzie robił machlojki z przypisywaniem funkcji do wskaźnika

super! dzięki za poradę! dzięki temu będzie też mniej kodu do klepania i co ważne - tylko w jednym miejscu, więc jakby ktoś chciał dodać inny LCD - będzie miał łatwiej

Otóż to

Kolejne pytanko, mam teraz taki kod:


Trochę mi się nie podoba, że jest "podwojny" skok do funkcji - wywołuję funkcję odśwież, która wywołuje drugą funkcję odśwież. Można tego jakoś niknąć? Czy zmiana "lcdb_odswiez_ekran()" na inline będzie ok? - spowoduje to pominięcie tego pierwszego skoku do środku

Tym podwójnym skokiem w ogóle bym się nie przejmował (w kontekście korzystania z STM32), a wieczorem przedstawię Ci jeszcze inny sposób. Oczywiście każdy ma swoje wady...

czasem mam takie zapędy optymalizacyjne pewnie niepotrzebne :p

Zastanawiałem się nad inna wersją kodu, ale... Ostatecznie nie będę publikował, bo kod utraciłby swą hermetyczność, doszłyby nowe makra... Nie, lepiej nie. Mam za to inny pomysł. Zerknij na moje wskaźniki... Moja propozycja jest taka, by były one statyczne, wewnątrz pliku lcd.c. Inicjalizowałbyś je od razu, a nie w inicie. Dlaczego tak? Ano dlatego, bo one są betonowe... Chodzi o to, że po ich zadeklarowaniu i inicjalizacji nie będziesz już mógł zmienić ani adresu, ani wartości, na jaką on wskazuje (stąd nazwa betonowy). Zapoznaj się z tym i daj znać, czy to ogarniasz:

super - statyczność w tym przypadku jest spoko - nie planuje podmieniać tych callbacków. Dziś wleci kolejna wersja libki - pododawałem funkcję które często potrzebowałem i zazwyczaj pisałem z palca typu wyświetlenie liczby z wyrównaniem do prawej strony, żeby zajmowała zawsze tyle samo miejsca itp.

A nie myślisz czasem o użyciu zwyczajnego printf? Ta funkcja tak pięknie wszystko formatuje... W STM32 i tak jest od groma pamięci, więc w czym kłopot? Oczywiście trzeba by wskazać wyświetlacz jako stdout, a tego jeszcze nie robiłem w STM32. To tylko taka luźna myśl...

szczerze - nie bawiłem się tym nigdy :p faktycznie stosowanie printf jak na PC ułatwia sprawę. W atollicu są nawet includowane jakieś przerobione wersje bibliotek o nazwie tiny printf - muszę to sprawdzić na spokojnie

Pobaw się tym przede wszystkim przez uart. Potem będzie można pomyśleć o podłączeniu lcd do strumienia stdout. W przypadku avr i pic przekierowanie jest banalnie proste.

Update - poćwiczyłem trochę Doxygena i do tej biblioteki można zobaczyć namiastkę dokumentacji:

https://dambo1993.github.io/universal_l ... index.html