Wyświetlacze OLED cz. 8 - dodajemy obsługę kolejnych kontrolerów i nie tylko

Po raz kolejny dałem się nabrać na to,że to nowy odcinek. Proszę, nie rób tak.

simw wrote:

Po raz kolejny dałem się nabrać na to,że to nowy odcinek. Proszę, nie rób tak.

Ale to jest nowy odcinek - tylko na elektrodzie jest to z opóźnieniem w stosunku do publikacji na YT. Sorki, jeśli to wywołuje zamieszanie, ale jeśli np. subskrybujesz to widzisz, czy to nowy czy nie. Poza tym każdy oznaczam numerem, żeby nie było nieporozumień.

Wszystko fajnie, ale jak usłyszałem że WŁONCZASZ coś tam... odpadłem.

Hej. Chciałbym się spytać czemu wybierasz robienie wszystkiego od podstaw ? Można by było użyć wyświetlacza telefonu albo komputera/laptopa i mniejsze koszty urządzenia. Bo każdy coś ma i nie trzeba nowego wyświetlacza.

398216 Usunięty wrote:

Wszystko fajnie, ale jak usłyszałem że WŁONCZASZ coś tam... odpadłem.

To prawda, muszę się poprawić. Skutek uboczny robienia filmów - poprawa wymowy

kamil3211 wrote:

Hej. Chciałbym się spytać czemu wybierasz robienie wszystkiego od podstaw ? Można by było użyć wyświetlacza telefonu albo komputera/laptopa i mniejsze koszty urządzenia. Bo każdy coś ma i nie trzeba nowego wyświetlacza.

Bo taki OLED kosztuje kilkanaście złotych i wolę mieć coś do czego mam specyfikację, niż rozkminiać enigmatyczne układy.
Zresztą wyświetlacz ze współczesnego smartfona lub matryca z laptopa to nie ta liga. To zupełnie inny sterownik, inna potrzebna do sterowania moc obliczeniowa, interfejs np. LVDS, MDDI lub inne wynalazki, do których często nie ma dostępnej dokumentacji, chyba, że jesteś dużą firmą i podpiszesz NDA.
Z kolei wyświetlacze ze starego sprzętu często odstają jakością obrazu. Np. taki LCD ze starej Nokii vs. współczesny mały OLED to nawet nie ma co porównywać - przepaść jakościowa.

Mi raczej chodziło o zrobienie aplikacji gui. W czymś na dany system operacyjny. A nie rozbieranie na części dla wyświetlacza Oczywiście komunikuje się z jakimś mikrokontrolerem czy czym innym albo odrazu. Jak aplikacje gui na raspberry pi sterujące pinami gpio

kamil3211 wrote:

Mi raczej chodziło o zrobienie aplikacji gui. W czymś na dany system operacyjny.

Ale to znowu - zupełnie inna klasa zastosowań. Jeżeli chcesz sobie np. wyświetlać jakieś informacje na panelu PLC to nie za bardzo ma sens używać do tego dużego procka z OSem. Poza tym dla tego OS też trzeba napisać sterownik. Samo się nie zrobi. Generalnie - świat małych mikrokontrolerów i maszyn z OS to zupełnie inne obszary zastosowań.

Tomku mógłbyś dać linki do poprzednich twoich filmów, bo wyszukiwarka nie bardzo chce je znaleźć.

Janusz_kk wrote:

Tomku mógłbyś dać linki do poprzednich twoich filmów, bo wyszukiwarka nie bardzo chce je znaleźć.

Najprościej na YT kliknąć na mój profil i masz w zakładce filmy wszystko. Albo po prstu tak:
https://www.youtube.com/@tmfmikro/videos

tmf wrote:

To prawda, muszę się poprawić.

Nie chcę się wywyższać - i mi się zdarza czasem popełnić taki błąd - skutek uboczny przebywania wśród ... młodzieży wychowywanej bezstresowo. Mimo że minęło tyle lat to gdzieś w zakątku pamięci pozostało i odzywa się w najmniej odpowiednich momentach. Ale właśnie dzięki temu tak mnie to drażni u innych (u siebie też - o ile zdążę zauważyć).
A co do cyklu - gratulacje. Mimo, ze jestem totalnym laikiem jeśli o programowanie chodzi wydaje mi się że coś jednak zrozumiałem.

kamil3211 wrote:

Można by było użyć wyświetlacza telefonu albo komputera/laptopa i mniejsze koszty urządzenia. Bo każdy coś ma i nie trzeba nowego wyświetlacza.

Na poszukiwaniach danych technicznych takich wyświetlaczy stracisz mnóstwo czasu i zdrowia, zwłaszcza iż często są to dedykowane wyświetlacze pod konkretny sprzęt i dokumentacja jest praktycznie niedostępna dla amatora. Też mi zalega kilka różnych wyświetlaczy, od 4" do 12" z różnych nawigacji czy tabletów. Z powodu tego o czym wyżej napisałem, odpuściłem sobie ich uruchamianie.

398216 Usunięty wrote:

Mimo, ze jestem totalnym laikiem jeśli o programowanie chodzi wydaje mi się że coś jednak zrozumiałem.

Totalnym laikiem w programowaniu nie jestem, ale wolę rozwiązania typowo sprzętowe . A zwłaszcza w technice cyfrowej . Na "skopany" pod względem elektronicznym projekt czasem i najlepiej napisany program nie pomoże.

Tomek fajnie prezentuje uruchamianie wyświetlaczy, choć aby z tego skorzystać to trzeba już niestety mieć trochę wiedzy o programowaniu, a chociażby znać podstawy.

@ArturAVS mi chodziło o zrobienie aplikacji. Komentarze wyżej.

kamil3211 wrote:

mi chodziło o zrobienie aplikacji

A czy w/g ciebie łatwiej byłoby zrobić (napisać) aplikację dla wyświetlacza o nieznanych parametrach, czy takiego gdzie pełna dokumentacja jest dostępna?

Np aplikacja na windows komunikująca się przez usb uart z mikrokontrolerem albo po wifi jak jakiś esp w sieci lan. Tak jak robią to zwykli programiści. aplikacje graficzne. W np frameworku qt albo innym rapid application development software. Choć od tego odchodzą.

kamil3211 wrote:

Np aplikacja na windows komunikująca się przez usb uart z mikrokontrolerem albo po wifi jak jakiś esp w sieci lan. Tak jak robią to zwykli programiści. aplikacje graficzne. W np frameworku qt albo innym rapid application development software. Choć od tego odchodzą.

Możesz sprecyzować o co ci chodzi i o jakiej aplikacji piszesz? Bo twoje wypowiedzi są dosyć chaotyczne i zdawkowe. Więc sprecyzuj co dokładnie masz na myśli.
Mikrokontrolery to zupełnie inny obszar zastosowań i nikt przy zdrowych zmysłach nie będzie pakował Qt w aplikację sterującą np. pracą pompy.

Sterowanie pracą pompy. Załóżmy że robię to na esp8266.

Mogę się z esp komunikować albo bezprzewodowo wifi albo przewodowo uart. Ale najpierw żeby dało się po wifi trzeba jakoś ustawić ip maskę itd. Najprościej po uarcie to ustawić i zapisać w pamięci trwałej w celu komunikacji późniejszej po wifi. Albo cały czas po uart.
Czyli aplikacja działa w 2 trybach komunikacji (po uart i wifi (udp np)).
Da się jeszcze po http przez sieć gdzie esp jest httpserver pod spodem o tym napiszę.

Sterowanie może odbywać na trzy sposoby.
-Robię aplikację na windows, android która komunikuje się cały czas z urządzeniem. Ona wysyła mu polecenia na bieżąco. Jeśli urządzenie ma działać cały czas a użytkownik ustawia i już więcej nie zagląda do maszyny to pojawia się problem bo ten komputer musi działać. Czyli komputer to serwer. Ale może być tak że urządzenie nie musi cały czas działać tylko jak operator przy niej jest i na bieżącą ją ustawia to to najlepsze wyjście. Bo najmniej roboty z tych trzech. Najmniej kodu.
-Robię aplikację która wysyła po wybraniu ustawień dane konfiguracyjne do pompy i mogę wyłączyć aplikację.
- Esp jest httpServer i po prostu tak jak się łączy routerem przez przeglądarkę tak łączę się ze esp ale trzeba znać html i inne to jest według mnie najgorszy sposób. Bo te wcześniejsze bardzo łatwe są w rozbudowie i nic mnie nie ogranicza. A najprostszy to 1 sposób.

@kamil.321 To o czym piszesz ma się nijak do tematu artykułu. Nawiasem mówiąc bardzo rzeczowy i super. Jeżeli zaś chodzi Ci o graficzne interfejsy użytkownika GUI to istnieją na przykład TouchGFX czy na STM32 GUI library i pewnie jeszcze kilka innych.

Ja się tylko pytałem @tmf czemu wybrał akurat taką drogę do osiągnięcia jakiegoś celu. A sam zaprezentowałem inną alternatywę. Właśnie o to chodzi że to się nijak ma do artykułu jeśli chodzi o realizacjię. Ale efekt końcowy dla klienta to to samo. To tylko diody led świecące w różnych kolorach . Do tego się to sprowadza w obu przypadkach. Telefon też jest graficznym interfejsem użytkownika i jego chcę np użyć zamiast touchgfx za pomocą aplikacji.

Przecież to jest artykuł o hardwarze, a konkretnie o sterowniku SSD1306 i SH1107. O tym co trzeba i w jakiej kolejności wpisać do konkretnego rejestru aby uzyskać określony efekt.

kamil3211 wrote:

Ale najpierw żeby dało się po wifi trzeba jakoś ustawić ip maskę itd. Najprościej po uarcie to ustawić i zapisać w pamięci trwałej w celu komunikacji późniejszej po wifi. Albo cały czas po uart.

Chyba sam widzisz, że to bez sensu - budujesz urządzenie, komunikujące się po wifi, po to, żeby kablem wiązać je z np. PCtem, w celu konfiguracji? To teraz wyobraź sobie, że ten sterownik pompy jest zabudowany na szynie DIN i nie za bardzo chcesz biegać z komputerem, konwerterem USB/RS232 i w rozdzielnicy, w której masz 230V łączyć jakieś kable. Pozostaje napisać porządnie obsługę wifi, lub dodać proste menu i wyświetlacz, w celu manualnej konfiguracji. Zastosowanie wyświetlacza ma tę zaletę, że możesz sobie na urządzeniu podglądnąć stan, zmienić nastawy i nie potrzebujesz nic więcej.

kamil3211 wrote:

A sam zaprezentowałem inną alternatywę. Właśnie o to chodzi że to się nijak ma do artykułu jeśli chodzi o realizacjię. Ale efekt końcowy dla klienta to to samo.

Nie, to co zaprezentowałeś to nie jest alternatywa. Mówimy o pewnej klasie rozwiązań, gdzie trzeba lokalnie prezentować jakieś informacje lub zrobić interakcję z użytkownikiem. No chyba, że będziesz się upierał, żeby np. zamiast zegarka z budzikiem, odpalać PCta, w celu sprawdzenia godziny Da się, ale dla większości osób nie miałoby to sensu.

kamil3211 wrote:

Telefon też jest graficznym interfejsem użytkownika i jego chcę np użyć zamiast touchgfx za pomocą aplikacji.

To go użyj. Jednak nie wszędzie i nie zawsze użycie armaty ma sens, jeśli można użyć pistoletu.

tmf wrote:

Chyba sam widzisz, że to bez sensu - budujesz urządzenie, komunikujące się po wifi, po to, żeby kablem wiązać je z np. PCtem, w celu konfiguracji? To teraz wyobraź sobie, że ten sterownik pompy jest zabudowany na szynie DIN i nie za bardzo chcesz biegać z komputerem, konwerterem USB/RS232 i w rozdzielnicy, w której masz 230V łączyć jakieś kable. Pozostaje napisać porządnie obsługę wifi, lub dodać proste menu i wyświetlacz, w celu manualnej konfiguracji. Zastosowanie wyświetlacza ma tę zaletę, że możesz sobie na urządzeniu podglądnąć stan, zmienić nastawy i nie potrzebujesz nic więcej.

W razie czego mogę ustawić domyślne ip jak w routerach i switchach domyślne hasło do wifi (jedyna różnica w porównaniu z tymi urządzeniami to to że będę potrzebował drugiego routera albo drugi access point (chyba że nikomu nie przeszkadza użycie routera domowego i chwilowe go przekonfigurowanie) i zrobić sieć zamkniętą np 192.16.0.0 z jakimś komputerem gdzie adres pompy to 192.168.0.1 maska 255,255,0,0). Dać przycisk do resetowania do ustawień fabrycznych jak użytkownik coś źle sobie ustawi. Albo przed włożeniem maszyny skonfigurować wszystko.

tmf wrote:

To go użyj. Jednak nie wszędzie i nie zawsze użycie armaty ma sens, jeśli można użyć pistoletu.

zmniejszam w ten sposób koszt urządzenia i miejsca potencjalnych awarii. Bo każdy sobie poradzi z zepsutym monitorem a raczej ciężko będzie z dodatkowym wyświetlaczem w urządzeniu.
Ale są sytuacje że lepszy mały wyświetlacz jak w automatach z jedzeniem piece. Jak najbardziej.

I tak uważam że robisz kawał dobrej roboty.

kamil3211 wrote:

zmniejszam w ten sposób koszt urządzenia i miejsca potencjalnych awarii. Bo każdy sobie poradzi z zepsutym monitorem a raczej ciężko będzie z dodatkowym wyświetlaczem w urządzeniu.

Nie zmniejszasz. Wprowadzenie OSa, od razu wprowadza wiele ptencjalnych miejsc awarii, w dodatku określenie ryzyka będzie często poza możliwościami programisty, np. z braku dostępu do kodu OS lub jego złożoności. Innym aspektem jest bezpieczeństwo. Nierealnym jest oczekiwać, że programy są bez błędów. Im bardziej skomplikowany program, tym większe ryzyko błędu. Złożoność OS w stosunku do złożoności jakiegoś sterownika pompy jest nieporównywalna. W efekcie wprowadzenie OS od razu wprowadza duże ryzyko błędów. To z kolei implikuje np. aktualizacje. A więc konieczność ogarnięcia całej z tym związanej logistyki - od dystrybucji dla klienta po wgrywanie do urządzenia. W międzyczasie jeszcze testy kompatybilności i przekonanie użytkownika, że system trzeba aktualizować. Dla prostych urządzeń/problemów lepiej ten cały balast odrzucić.
Ponadto urządzenie będące w stanie uruchomić OS jest bez porównania bardziej skomplikowane niż urządzenie realizujące proste funkcje - np. sterowania pompami o któych mówiliśmy. A więc i ryzyko awarii hardware roście. Niezawodność prostego MCU wykonanego np. w technologii 0,8 mikrona jest zupełnie inna niż złożonego procka w technologii 10 nm.
Tak jak pisałem - mówimy o różnych klasach rozwiązań i potrzeb.

tmf wrote:

Nie zmniejszasz.

Dokładnie. Sam zauważyłem wzrost awarii bardziej rozbudowanych sterowników kotłów, gdzie producent "idąc z duchem czasu" zastosował mocniejszy kontroler i wyświetlacz TFT z graficznym interfejsem i różnymi wodotryskami. Trochę czasu współpracowałem z firmą której flagowy produkt (sterownik kotła) był uproszczony do niezbędnego minimum i praktycznie "niezniszczalny" jeśli był używany zgodnie ze specyfikacją. Interfejs użytkownika to podwójny wyświetlacz 7-seg + kilka diod funkcyjnych oraz trzy przyciski. Na jego bazie, dzięki zmianie oprogramowania (oraz front-panelu z opisem) powstało wiele typów sterowników (sterowniki do kotłów, chłodni, pomp czy też instalacji solarnych). Całość opierała się o ST7Flite.