Przeszukaj forum

Witam Staram się podłączyć wyświetlacz na sterowniku SSD1306 do mikrokontrolera STM32F401RE. Posiadam dokładnie ten model wyświetlacza https://kamami.pl/wyswietlacze-oled-graficzne/560775-wyswietlacz-oled-waveshare-096-cala-a.html Chcę połączyć się z nim poprzez i2c i móc wyświetlać na nim tekst czy też figury. Mój kod wygląda aktualnie tak: /* Includes ------------------------------------------------------------------*/ #include "main.h" /* Private includes ----------------------------------------------------------*/ /* USER CODE BEGIN Includes */ #include "ssd1306.h" #include "test.h" #include "fonts.h" /* USER CODE END PV */ /* Private function prototypes -----------------------------------------------*/ void SystemClock_Config(void); static void MX_GPIO_Init(void); static void MX_I2C1_Init(void); /* USER CODE BEGIN PFP */ int main(void) { /* USER CODE BEGIN 1 */ /* USER CODE END 1 */ /* MCU Configuration--------------------------------------------------------*/ /* Reset of all peripherals, Initializes the Flash interface and the Systick. */ HAL_Init(); /* USER CODE BEGIN Init */ /* USER CODE END Init */ /* Configure the system clock */ SystemClock_Config(); /* USER CODE BEGIN SysInit */ /* USER CODE END SysInit */ /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_I2C1_Init(); /* USER CODE BEGIN 2 */ SSD1306_Init(); /* USER CODE END 2 */ /* Infinite loop */ /* USER CODE BEGIN WHILE */ while (1) { /* USER CODE END WHILE */ SSD1306_Clear(); SSD1306_GotoXY(5, 0); // coordinates x, y SSD1306_Puts("Hello", &Font_11x18, 1); // print Hello SSD1306_GotoXY(0, 24); // coordinates x, y SSD1306_Puts("ssd1306 OLED", &Font_7x10, 1); SSD1306_GotoXY(0, 40); // coordinates x, y SSD1306_Puts("display!", &Font_11x18, 1); SSD1306_UpdateScreen(); // update screen HAL_Delay(10000); /* USER CODE BEGIN 3 */ } /* USER CODE END 3 */ } Bazuje on głównie na poradnikach znalezionych w internecie. Nie jest zbyt skomplikowany, a jednak wyświetlacz w ogóle nie reaguje. Może ktoś ma pomysł co z tym zrobić lub doświadczenie w podobnym przypadku?

robię sobie taki zegarek do motocykla mam już zegar i temperaturę i chciałbym żeby gdy podnóżka się rozkłada była wyświetlona litera "p" a kiedy będzie włączony luz był "N" wszystko na jednym wyświetlaczu ssd1306 OLED 0,96 cala jak mówiłem godzina i temperatura działa lecz gdy włączę switcha z podnóżkom wyświetla się P lecz co chwile miga bo wyświetlacz musi się odświerzyć do zegarka i tu moje pytanie jak zrobić to na jednym wyświetlaczu żeby godzina była ok i żeby litera P nie migała dodam też że tan sam program zastosuje też do luzu czyli N jak już tu piszę to mam też pytanie bo jako że mamy przestawiany czas to 2 razy w roku trzeba zmienić godzinę i chciałem też zrobić 1 albo 2 switche do przesuwania godziny i minuty lecz o ile mogę zczytać myRTC to nie mogę do niego dodać liczby i tu moje pytanie czy da się to jakoś prosto zrobić i też następne pytanko jak zastąpić na tej wyświetlanej godzinie żeby zamiast 0 było O bo na wyświetlaczu zero jest przekreślone i słabo to wygląda poniżej kod #include <SPI.h> #include <OneWire.h> #include <Adafruit_GFX.h> #include <Adafruit_SSD1306.h> #include <virtuabotixRTC.h> //Libraries needed #include <DallasTemperature.h> Adafruit_SSD1306 display(4); OneWire oneWire(2); virtuabotixRTC myRTC(5, 6, 7); DallasTemperature sensors(&oneWire); //-------------------------------------------- void setup() { Serial.begin(9600); display.begin(SSD1306_SWITCHCAPVCC,0x3C); sensors.begin(); //myRTC.setDS1302Time(00, 30,9, 00, 18, 5, 2021); display.clearDisplay(); pinMode(3,INPUT_PULLUP); } //-------------------------------------------- void loop() { int temperatura = (sensors.getTempCByIndex(0)); sensors.requestTemperatures(); myRTC.updateTime(); display.setTextSize(2.7); display.setTextColor(WHITE); display.setCursor(10,4); if (myRTC.hours <10) { display.print ("0"); } display.print(myRTC.hours); display.print(":"); if (myRTC.minutes <10) { display.print ("0"); } display.print(myRTC.minutes); display.setTextSize(1.7); display.setCursor(20,23); display.print(temperatura); display.drawRect (33, 23, 4, 3,WHITE); display.setCursor(32,23); display.print(" C"); display.display(); if (digitalRead(3) == LOW){ display.setTextSize(2); display.setCursor(75,18); display.print("P"); display.display(); } delay(500); display.clearDisplay(); }

Głównym założeniem tego projektu było stworzenie urządzenia wyświetlającego liczbę klatek na sekundę w grach komputerowych, jak i również innych informacji o obciążeniu komputera. Zdaje sobie sprawę, że projekty podobnego to tego pojawiały się już nie raz w sieci pod różnymi postaciami. W tym projekcie skupiłem się jednak na tym, aby całość zmieściła w małej kompaktowej obudowie, którą można w elegancki sposób zamontować pod monitorem. Możliwość wyświetlania FPS również jest tutaj czynnikiem wyróżniającą ten projekt na tle innych. Jest tak głównie dlatego że o ile informacje o wykorzystywanej ilości pamięci RAM, czy też obciążeniu procesora można dosyć łatwo pozyskać za pomocą różnych bibliotek w programie po stronie komputera, tak z klatkami na sekundę jest trochę trudniej. Użyte komponenty Sama budowa tego monitorka jest naprawdę prosta. Zostały w nim użyte właściwie tylko 3 komponenty: Arduino nano wyświetlacz OLED 128x32 przycisk dotykowy Pierwotnie zakładałem również użycie diody LED do sygnalizacji pewnych błędów, czy też wciśnięcia przycisku dotykowego. Uznałem jednak, że w tym przypadku nie miało by to większego sensu zważając na potrzebę minimalizacji. Można byłoby się zastanowić czemu wybór padł na arduino nano, a nie np. arduino pro micro. Arduino pro micro jest mniejsze, prawda? Zgadza się, dlatego też użyłem tego mikrokontrolera w pierwszej wersji tego wyświetlacza, który skończył dość marnie. Było tak dlatego, że przez przypadek chcąc poprawić przewód HDMI za monitorem, szarpnąłem niechcący za przewód idący do arduino. No i stało się, wyrwałem wtyk micro USB z płytki. Chcąc uniknąć ponownie takiej wpadki w następnej wersji użyłem mikrokontrolera, który kosztem ciut większej wielkości jest tańszy oraz posiada lepiej zamontowany na płytce wtyk USB mini. Jeśli chodzi o wyświetlacz to sprawa była prosta. Taki OLED 128x32 nie tylko rozmiarami idealnie pasuje do całego projektu, ale też po prostu prezentuje się ładnie i daje dużo możliwości. No i na koniec czujnik dotykowy. Dostępny w wielu rozmiarach, tani oraz przede wszystkim nie wymagający praktycznej żadnej siły do jego aktywacji. Ukryty w prawym boku obudowy dodaje estetyczności, nie zmniejszając przy tym komfortu użytkowania. Obudowa Obudowa została w całości wydrukowana na drukarce 3D. Sam model do druku zaprojektowałem w programie Fusion 360. Tak jak już pisałem, zależało mi na niewielkich rozmiarach. Dlatego cały model przeszedł przez wiele iteracji, a w każdej z nich starałem się zminimalizować jego wielkość. Zadbałem tutaj również o to, aby każdy z elementów w środku miał dopasowane pod siebie miejsce celem łatwego montażu. Po historii z wyrwaniem wejścia na płytce, finalnie dodałem jeszcze mały uchwyt na przewód mający minimalizować ryzyko ponownego uszkodzenia portu USB. Software Oprogramowanie po stronie komputera to prosty skrypt napisany w pythonie. Poza łączeniem się z arduino i przesyłaniem mu danych, musi te dane jeszcze skądś brać. I tutaj pojawił się mały problem, jeśli chodzi o pobranie ilości klatek w aktualnie włączonej grze. Nie da się od tak wyliczyć takiej wartości w programie, nie ma też na to gotowej funkcji. Z pomocą przyszedł popularny program o nazwie Msi AfterBurner. Nie wchodząc w szczegóły, program ten pozwala na monitorowanie zasobów komputera ( RAM, CPU, GPU itp.), jak i również uzyskanie potrzebnych nam FPS w aktualnie włączonej grze/programie. Teraz już tylko wystarczyło użyć wbudowanej w program funkcji do logowania tych danych do pliku, oraz odczytać je w pythonie i przesłać do arduino. Czy taki sposób jest wydajny? Cały proces wykorzystania pliku jako bufora do danych nie powinien w znaczący sposób obciążyć komputera, jednak lepszą opcją byłoby wykorzystywanie współdzielenia pamięci między dwoma programami. Aby to jednak osiągnąć potrzebna jest trochę większa wiedza z programowania w C++/C#, której niestety jeszcze nie posiadam. W przypadku arduino program po za odczytaniem danych oraz ich wyświetleniem, obsługuje również dotykowy przycisk. Pojedyncze dotknięcie przycisku zmienia wyświetlaną zawartość na 1 z 6 ekranów, zaś przytrzymanie przycisku powoduje zmianę ekranu co jedną sekundę. Dostępnymi ekranami są: klatki na sekundę, użycie CPU i GPU, temperatura CPU i GPU, użycie pamięci RAM i VRAM, prędkość wentylatora oraz ekran główny powodujący wygaszenie ekranu po paru sekundach. Dalsze plany W przyszłości planuje jeszcze większą minimalizacje wielkości obudowy, bo jest na tym polu jeszcze dużo do zrobienia. Mam zamiar również poduczyć się C++, aby móc wykorzystać współdzieloną pamięć między programami, rezygnując z odczytywać danych z pliku.

Witam, Tworzę projekt stacji pogodowej na ESP32, która wyświetla dane z czujnika temperatury na stronie WWW z użyciem phpMyAdmin. Tą część mam już za sobą i wszystko działa tak jak należy. Teraz postanowiłem dodać ekran OLED, aby móc odczytywać pomiary z czujnika(BME280), gdy ESP nie ma dostępu do Internetu (chodzi tylko o wyświetlanie ostatniego zmierzonego pomiaru). W jaki sposób się za to zabrać? Czy wystarczy zrobić warunek typu: while(WiFi.status() != WL_CONNECTED) { delay(500); ---- wyświetlanie na OLED pomiaru z czujnika----- } ----tutaj co się stanie jak się połączy z Internetem, czyli wysyłanie do bazy danych itd.---- Osobiście wydaje mi się to trochę zbyt proste, żeby było prawdziwe stąd moje pytanie do Was. Z góry dzięki za odpowiedzi 😄

Witam serdecznie, Problem pojawia się w Lib_confuig.h Informacja po najechaniu na błąd - Unresolved inclusion: "mxconstants.h", jak powininem ją zaimportować, nie ma o niej ani słowa w artykule : ( Ponadto informuje mnie że Res_Pin, CS_Pin..... undeclared w momencie w którym w tym samym pliku wpisuje te Macra i stm32 sam mi je proponuje , więc są przez niego widoczne w tym zakrasie. Za wszelką pomoc będę bardzo wdzięczny : ) PS uruchamiam go na Nucleo - F767ZI, PPS Mega kurs, bardzo dziękuję, wszystkie pozostałe elementy dokupiłem jak w zestawie, płytkę po prostu wypożyczył mi kolega do zabawy SPI_F7.rar

Dość długo zabierałem się za ten projekt, ale w końcu udało się go zrealizować. Powstał on, ponieważ potrzebowałem czegoś, co umożliwi mi szybki wgląd w aktualne obciążenie komputera, bez niepotrzebnego przełączania okienek. Rozwiązanie czysto programowe byłoby też w moim przypadku o tyle mniej praktyczne, że często korzystam z maszyn wirtualnych, a taki zewnętrzny monitor obciążenia pozwala mi na wyświetlanie statystyk wszystkiego jednocześnie. Poza wyświetlaniem informacji zależało mi także na graficznej reprezentacji obciążenia, dzięki czemu można nawet "kątem oka" zauważyć że pojawiło się jakieś duże obciążenie lub że kończy się pamięć RAM. Parę lat temu zbudowałem taki monitor na ekranie LCD 4x20, jednak z biegiem czasu i modernizacją sprzętu coraz ciężej było zmieścić na nim wszystkie informacje które bym chciał, dlatego stwierdziłem że czas na nową odsłonę 😄 Tym razem zamiast ekranu LCD postanowiłem użyć wyświetlaczy OLED. Z kolei do reprezentacji graficznej chciałem wykorzystać diody WS2812. Dość długo zastanawiałem się w jaki sposób je ułożyć i jak to najprościej zrobić. Ostatecznie diody zostały ułożone w dwóch półpierścieniach nad wyświetlaczami. Aby ułatwić sobie życie kupiłem pierścienie 16 diodowe i 24 diodowe i przeciąłem na na pół. Wadą takiego rozwiązania było to, że tylko na jednej połówce miałem do dyspozycji wygodne pola lutownicze z tyłu, a na drugiej musiałem wlutować kable bezpośrednio w pierwszą diodę. Na zdjęciu widać pierwsze przymiarki diod do wyświetlacza: Docelowo planowałem wykonać 4 takie zestawy oled + diody, co wiązało się z pewnym problemem. Wyświetlacze które posiadałem podłącza się przez I2C, a ponieważ miałem 4 identyczne, to wszystkie miały ten sam adres, niestety producent wyświetlaczy nie przewidział takiego scenariusza (niektóre wersje umożliwiają ustawienie ostatniego bitu, co umożliwia podpięcie 2 wyświetlaczy, moje akurat nie miały takiej opcji). Po zrobieniu researchu rozwiązanie tego problemu okazało się bardzo proste. Polega ono na selektywnym doprowadzaniu sygnału zegara do poszczególnych wyświetlaczy. Ja w tym celu wykorzystałem demultiplekser 74HC139. Takie rozwiązanie jest możliwe, ponieważ tylko master (w tym wypadku mikrokontroler) steruje linią zegara, dzięki temu możliwe jest zastosowanie demultipleksera. W przypadku gdyby slave'y też sterowały linią zegara rozwiązanie byłoby bardziej złożone (o ile w ogóle możliwe), bo demultipleksery działają tylko w jedną stronę 😄 Z tego powodu też nie można tego zrealizować na linii danych (nawet jeśli przesyłanie danych odbywa się tylko w jedną stronę, to linia SDA musi być "dwustronna" żeby możliwa była realizacja protokołu I2C). W przypadku diod WS2812 sprawa była prostsza, docelowo każdy półpierścień dostał własny pin procesora, dzięki czemu każdy z nich może być odświeżany niezależnie. Jako mikrokontroler wybrałem Atmegę4809, ponieważ potrzebowałem 4kB ramu na trzymanie klatek z każdego z 4 oledów (128*64*4 = 32kb = 4kB). Możliwa by była realizacja przy mniejszej ilości pamięci, np 2kB, poprzez trzymanie tylko jednej klatki, jednak wiązałoby się to z mniejszą wydajnością całego programu, ponieważ generowanie kolejnej klatki można by było rozpocząć dopiero po zakończeniu przesyłania poprzedniej. W przypadku gdy każdy wyświetlacz ma swój bufor, to w trakcie gdy na przykład dane są wysyłane do pierwszego wyświetlacza możliwe jest generowanie obrazu dla drugiego wyświetlacza itd. Wymaga to asynchronicznej implementacji I2C, co zrealizowałem poprzez kolejkę do której można dodawać wskaźniki na tablice danych które mają być po kolei wysłane i ich obsługa jest w pełni realizowana na poziomie przerwania. Samo generowanie klatek zrealizowane jest w ten sposób, że dla każdego wyświetlacza przygotowany jest szablon zawierający stałe części obrazu, a następnie renderowane są na nim wartości w określonych pozycjach x,y, co łącznie generuje pełną klatkę obrazu. Graficznie wygląda to tak (po lewej templatka, po prawej z wypełnionymi wartościami): Wszystkie przygotowane ekrany wyglądają następująco: Ekrany przygotowane są stricte pod moją konfigurację, oczywiście możliwe by było generowanie wszystkiego po stronie komputera i przesyłanie gotowych klatek, akurat ja wolałem podejście z renderowaniem po stronie uC, ale co kto lubi 😄 Układ został zrealizowany na płytce uniwersalnej, a szkielet i obudowa zostały wydrukowane na drukarce 3D. Projekt ma budowę modułową i działa poprawnie z każdą liczbą modułów między 1 a 4, na ten moment mam zrealizowane dwa, kolejne dwa czekają aż będę miał trochę więcej wolnego czasu. Ponieważ każdy moduł wykorzystuje 4 kable do przesyłania danych (2 do pierścieni i 2 do wyświetlacza), to do ich podłączania wykorzystałem skrętkę, akurat po pół skrętki na moduł. Na ten moment całość prezentuje się następująco, kable z boku są przygotowane dla następnych modułów. Urządzenie łączy się z komputerem poprzez konwerter USB↔UART. Po stronie komputera działa aplikacja napisana w javascripcie, która zbiera dane z komputera na którym działa, używając głównie biblioteki systeminformation. Dodatkowo, nasłuchuje na jednym z portów sieciowych, pod który mogą się podpinać maszyny wirtualne i przesyłać dane o swoim obciążeniu. Technicznie, zamiast maszyn wirtualnych możliwe by było podpinanie innych fizycznych urządzeń, opcji jest wiele, wszystko zależy od potrzeb. Wyświetlanie informacji z dwóch źródeł jednocześnie na pierścieniach realizowane jest poprzez kolory, host wykorzystuje zielony i czerwony, natomiast maszyna wirtualna niebieski.

Tradycyjna kostka do gry jest prosta w budowie, tania ale ma pewne wady. Potrafi potoczyć się w trudno dostępne miejsce. Kolejna wada jest hałas przez nią wytwarzany oraz fakt, że potrafi wpaść na planszę gry i przewrócić pionki. Wad tych pozbawiona jest kostka elektroniczna. W Internecie można znaleźć wiele konstrukcji, wszystkie jakie widziałem wyświetlają wynik losowania na diodach LED. Prezentowana konstrukcja posiada nowoczesny wyświetlacz OLED co pozwala na wyświetlanie różnorodnych grafik. Ponadto może zastąpić cztery kostki o praktycznie dowolnej liczbie liczbie ścian. Kostka została zbudowana na mikrokontrolerze STM32F103RBT8, który można znaleźć na płytkach STM32 NUCLEOSTM32-NUCLEO i innych dostępnych w Botlandzie . Można użyć taniej płytki "Blue pill". Prototyp został zamontowany na dedykowanej do tego PCB. Do wyświetlania grafiki służy kolorowy wyświetlacz OLED o rozdzielczości 96x64 np OLED 0,96". Grafika jest zapisana na karcie SD, dzięki czemu łatwo ją zmienić. Karta jest umieszczona w gnieździe podobnym do Gniazago karty SD z wyrzutnikiem tyle, że bez wyrzutnika. Na PCB przewidziano miejsce na pamięć DataFlash ale w prototypie nie jest ona używana. Jej przeznaczeniem była możliwość skopiowania grafiki z karty pamięci do DataFlash skąd mogą one bardzo szybko być wyświetlane na OLEDzie. Czas odczytu grafik z karty SD jest stosunkowo długi ale wystarczający do wyświetlania statycznych obrazów. Jeśli miałyby być wyświetlane grafiki (np. podczas losowania) to wykorzystanie DataFlasch będzie konieczne. Jak to działa? Naciśnięcie przycisku SET, wybudza mikrokontroler. Program sprawdza, czy reset spowodowany jest włączeniem zasilania czy wybudzeniem. Jeśli włączeniem zasilania wybiera kostkę numer 1 (na karcie SD można umieścić grafiki czterech kostek, każda do 250 ścian) ponadto inicjalizuje generator pseudolosu (ziarno). Jeżeli reset był wywołany wybudzeniem, ustawiana jest ostatnio używana kostka. W kolejnym kroku, przeszukiwane są pliki graficzne, na podstawie których, wiadomo ile ścian ma każda z czterech kostek. Po przeszukaniu plików pojawia się napis „Gotowy do gry” albo „SD Error” jeśli nie wykryto karty lub wymaganych plików graficznych. Przyciskami UP, DOWN, LEFT, RIGHT, można wybrać jedną z kostek, SET uruchamia losowanie. W czasie losowania, zależnie od tego czy znajduje się grafika reprezentująca wybraną kostkę (w prototypie „Orzeł czy reszka” i „Ruletka”) czy nie (w prototypie kostka 6 ścian, kostka 12 ścian), wyświetlana jest grafika lub migający ekran. Po zwolnieniu przycisku SET, po sekundzie, pojawia się wylosowana ściana kostki. Bezczynność przez dwie minuty spowoduje przejście kostki w stan uśpienia. Program został napisany w KEIL uV 5, zajmuje 31kB FLASH, 18kB RAM więc można go skompilować darmową wersją programu. Przy pisaniu softu, wspomagano się programem CubeMX. Program w dużej mierze korzysta z HAL tylko nieliczne fragmenty operują bezpośrednio na rejestrach mikrokontrolera. W pamięci mikrokontrolera stworzono bufor na dane wyświetlacza. Wszystkie operacje graficzne są wykonywane na nim, po czym wysyłana z wykorzystaniem DMA. Dzięki temu, transmisja zajmuje ok 12ms, w efekcie grafika na ekranie pojawia się niezauważalnie szybko. Zawartość karty SD stanową pliki graficzne w formacie BMP zapisane są w głównym katalogu. Nazwy plików kolejnych kostek zaczynają się od liter a, b, c, d. Cyfra za nazwą informuje o numerze ściany. Pierwsza kostka 6 ścian będzie wymagała plików: "a1.bmp" ... "a6.bmp". Ruletka to pliki:" b1.bmp" … "b37.bmp". Jeśli w czasie losowania ma pojawiać się grafika należy dodać plik z sufiksem 00, np.: "a00.bmp", "b00.bmp". Grafika w formacie BMP powinna mieć wymiary 94x64 piksele. Głębia kolorów 24-bit, bez kompresji. Grafika może mieć inne wymiary, jeśli będzie za duża, to zostanie obcięta, jeśli za mała, nie wypełni całego wyświetlacza. Do tworzenia /obróbki grafik w prototypie korzystano z Windows'owego Paint'a i programu IrfanView. W załączniku archiwum z programem i schemat. Kostka12.zip Protel Schematic.pdf