Skocz do zawartości

MR1979

Użytkownicy
  • Zawartość

    18
  • Rejestracja

  • Ostatnio

Reputacja

26 Bardzo dobra

O MR1979

  • Ranga
    2/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Gdynia

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Kolejny update z frontu. Walczyłem głównie z dźwiękiem. I tak, za radą kolegów powyżej przerobiłem następujące wersje: 1. Modulacja PWM + filtr dolnoprzepustowy. + Od strony oprogramowania wszystko ładnie dało się zrobić. Była tablica z wartościami dla funkcji SIN. Zrobiłem 2 kanały z wykorzystaniem jednego timera (wg instrukcji marek1707 znalezionym na tym forum w innym wątku). - Zastosowanie najprostszego filtru RC nie dało najlepszych rezultatów. Jakość dźwięku była taka sobie. Sygnał na oscyloskopie był daleki od tego co oczekiwałem. - Miksowanie 2 lub więcej kanałów dość mocno obciąża procesor (bo częstotliwość PWM musi być kilka razy większa od przewidywanej max częstotliwości dźwięku). Gdyby mój układ nie miał nic innego do roboty poza graniem muzyki to poszedłbym w tym kierunku. 2. Symulacja złącza I2S wg instrukcji z ST AN5086 (łatwo znaleźć w google). Czyli linia SCK z SPI jest jednocześnie triggerem dla timera który steruje linią WS (kanał lewy/prawy). - Tak symulowany I2S podłączyłem na próbę do prostego wzmacniacza audio MAX98357A. Tu niestety poległem i nie udało mi się zmusić układu do działania. Uzyskałem sygnał SPI zgodny z oczekiwaniami (przynajmniej tak wyglądało na oscyloskopie), ale wzmacniacz milczał. Podejrzewam że powodem są duże wymagania co do bitrate na wejściu. Bo nie wysyłałem danych ze standardowymi prędkościami audio jakie stosuje się w I2S. Jest też duża szansa że mój sygnał wyjściowy nie do końca był zgodny z wymaganiami I2S. W końcu zrezygnowałem z "zaawansowanego" dźwięku. Czas jednak nie był zmarnowany bo dużo się nauczyłem i nabytą wiedzę wykorzystam w kolejnych projektach. Ostatecznie zdecydowałem się na zwykły sygnał prostokątny z jednym tranzystorem w roli klucza. Do tego napisałem prostą bibliotekę do odgrywania melodyjek, oraz prostych efektów audio. Całość wykorzystuje jeden Timer. Piszę teraz w Pythonie konwerter plików midi na tablice array które będę mógł użyć w moim projekcie. Zobaczymy co z tego wyjdzie. Z innych rzeczy to dodałem sterowanie podświetleniem wyświetlacza. Ale to już drobnostka. Projekt płytki prawie skończony. Jeszcze pozostała kosmetyka. Na razie wygląda to tak: Pozdrawiam, Marek
  2. Witam, Nie mam pojęcia jaki jest jednostkowy koszt. To hobby więc ekonomia projektu nie była dla mnie priorytetem. Najdroższym elementem była oczywiście PCB. Resztę cen możesz sprawdzić na farnell albo podobnej hurtowni online. Projekt płytki w załączniku (format KiCad). Jakbyś robił własną PCB to najtrudniejsza jest część pod przetwornicę DC/DC. Pozdrawiam. psu.zip
  3. WItam, Tak. Domyślnie ta funkcjonalność działa wyłącznie przez aktywację dwóch przycisków jednocześnie. Dlatego w moim projekcie połączyłem na stałe wejścia PB i SR pod jeden przycisk. Czyli wciskając przycisk PWR modułu ustawiam niski stan jednocześnie na PB i SR układu STM6601. Ponieważ opóźnienie awaryjnego wyłączenia układu ustawiłem kondensatorem Csrd na 10s, więc taka konfiguracja nie ma wpływu na podstawową funkcjonalność przycisku PWR. Pozdrawiam, Marek
  4. Mały update z frontu 1. Jest już integracja modułu zasilania z konsolką oraz oprogramowanie przycisku power: Przy wyłączonym zasilaniu: - krótkie naciśnięcie przycisku power - konsolka uruchomi się na chwilę i po chwili wyłączy - dłuższe naciśnięcie przycisku power - wyświetli ekran powitalny (wtedy można zwolnić przycisk zasilania), a następnie uruchomi się gra Przy włączonym zasilaniu: - krótkie naciśnięcie przycisku power - spowoduje przerwanie gry i powrót do menu głównego - dłuższe naciśnięcie przycisku power wyświetli ekran zamykania systemu - gdy zwolnimy przycisk przed upływem 3 sekund - konsolka powróci do głównego programu - gdy przyciśniemy przycisk powyżej 3 sekund - nastąpi wyłączenie urządzenia z poziomu oprogramowania - przyciśnięcie przycisku >10s - w razie gdyby urządzenie się zawiesiło - nastąpi wyłączenie awaryjne z poziomu modułu zasilania. Przydatna funkcja, gdy bateria nie ma możliwości odłączenia baterii bez rozkręcania obudowy 2. Jest już podłączona klawiatura 3. Aktualnie myślę nad układem audio. Ponieważ mój STM32F103 nie ma ani I2S (nie mogę podłączyć MAX98357A), ani DAC na pokładzie, więc pozostaje mi tylko PWM i proste odgrywanie melodii zapisanej w postaci nut. Zastosuję PWM do tego i najprostszy możliwy wzmacniacz na jednym tranzystorze (znaleziony w sieci). Zamienię tylko 47uF na 10uF na wejściu. Co prawda wtedy będzie tłumić bardziej przy niskich częstotliwościach, ale dla głośniczka po 2PLN nie powinno to mieć znaczenia. Zmienię też tranzystor na coś podobnego tylko SMD. Jak ktoś podsunie mi pomysł na coś lepszego do audio to będę wdzięczny 4. Schemat się rysuje już w KiCad. Jak tylko dogram audio, zabieram się za PCB. A poniżej sekwencja włączenia i wyłączenia konsolki:
  5. Fajny projekt Jak już będziesz miał filmik z kotem to dodaj do wątku
  6. Witam! To mój pierwszy wpis w dziale DIY. Projektem jest (a właściwie dopiero będzie) mini konsolka do gier na STM32F1. Robię ten projekt dla mojego 3-letniego synka. Docelowo będę mu wgrywać na nią różne napisane przeze mnie gry, ale na początek zacznę od klasyki, czyli gra w węża Robiłem już podobny projekt przy okazji kursu SMT32 na Forbocie, więc szybko powinienem napisać niezbędny kod. Tym razem ma to być gotowe urządzenie które bez problemu będzie mógł obsłużyć 3-latek. Założenia projektu: 1. Mikrokontroler STM32F1 2. Ekran TFT kolorowy 240x320 3. Zasilanie bateryjne LiPo z ładowaniem przez gniazdo USB (więcej szczegółów w moim wątku w dziale Zasilanie - szczególnie ostatni mój post) 4. Obudowa w całości drukowana w 3D 5. Żadnych gotowych modułów. Własny projekt PCB i własny montaż. 6. Klawiatura: Krzyżyk, przycisk A, przycisk B oraz przycisk POWER, jak w starych Game - Boy'ach 7. Dzwięk: Nad tym jeszcze nie myślałem, brak I2S oraz DACa na mojej płytce Nucleo trochę utrudnia sprawę. Może będzie coś na Timerach i PWM. Zobaczymy. Teraz po kolei. Pierwsze co musiałem zrobić to ogarnąć wyświetlanie na TFT. Zakupiłem trochę w ciemno kilka wyświetlaczy 2,8" na ILI9341. Mój brak doświadczenia z TFT natychmiast się zemścił. Po odbiorze przesyłki okazało się że obsługa SPI wcale nie jest oczywista i jestem skazany na 16-bitową magistralę. Nie znalazłem nigdzie driverów na STM32 do sterowania tym kontrolerem przy takim połączeniu, ale znalazłem kilka projektów na GitHub'ie gdzie było sterowanie przez magistralę 8-bitową. Postanowiłem więc na podstawie tych projektów napisać własne drivery i procedury wyświetlania podstawowych kształtów. W trakcie prac nad optymalizacją wyświetlania okazało się że jednak 16-bitowa magistrala to doskonały pomysł i jest 4-krotnie szybsza od 8-bitowej. Dlaczego? Już tłumaczę: Gdy używa się 8-bitowej szyny danych to wysłanie piksela wygląda następująco (już po ustawieniu adresu): - Ustawiamy pierwsze 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 - Ustawiamy kolejne 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 4 kroki. Gdy używamy 16-bitowej magistrali - wygląda to następująco: - Ustawiamy 16 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 2 kroki. Ale przecież pisałem że jest 4 razy szybciej, a tu wychodzi że 2 razy No więc łatwo można zauważyć, że przy 16 bitach raz ustawiony kolor na linii danych możemy zostawić do czasu aż będziemy musieli użyć innego koloru. Więc jeżeli mamy kilkaset pikseli do wypełnienia jednym kolorem to raz go ustawiamy, a później już tylko WR strobe tak długo jak potrzebujemy Czyli realnie wykonujemy tylko jeden krok. Zaimplementowałem to w moich driverach i rezultaty były doskonałe. Na tyle dobre że odpadła mi konieczność posiadania pamięci pod bufor klatki. Wszystko wyświetla się błyskawicznie: Aktualnie mogę wyświetlać do 8Mpix/s, co teoretycznie pozwala odświeżyć ekran 240x320 ponad 100 razy na sekundę na STM32F1 taktowanym 64MHz. Czyli mogę jeszcze podnieść tą częstotliwość do 72 MHz i jeszcze zwiększyć transfery. Niestety chwilowo mam odcięty programator od płytki Nucleo i muszę kożystać z wewnetrznego oscylatora który pozwala rozkręcić mikroprocesor do 64MHz. Kolejnym problemem z którym musiałem się zmierzyć to mała ilość flash na grafiki do gier. Jak łatwo policzyć jedna pełnoekranowa grafika to 153600 bajty, a mam tylko 128k do dyspozycji. A jeszcze musi się zmieścić program. Rozwiązaniem problemu jest kompresja. Tu znów musiałem od zera napisać program do kompresji grafiki który spełniałby moje wymagania. Kompresor został napisany w Pythonie. A szybki dekoder zaimplementowany w C w driverach na STM32. Pisałem program praktycznie od zera wg mojego pomysłu. Otóż dzieli on grafikę na bloki o jednolitych kolorach, a ich metadane zapisuje w binarnym pliku wyjściowym, albo w pliku C. Bloki są następujące: pozioma linia, pionowa linia, prostokąt. Pojedynczy piksel to pozioma linia o długości 1. Kompresja odbywa się przez rozkład grafiki na takie bloki, a następnie zapisaniu ich parametrów do pliku wyjściowego. Procedurę dekompresji zaimplementowałem w driverach do wyświetlacza, a każdy blok łatwo można wysłać bezpośrednio do pamięci ekranu, gdzie obraz zostaje odtworzony. Kolejną funkcją którą zaimplementowałem w kompresorze jest możliwość kodowania różnicy pomiędzy dwoma grafikami. Tzn jeżeli robię animację to program kompresuje tylko piksele które różnią dwie klatki. Poniżej proces odtwarzania obrazka na wyświetlaczu w zwolnionym tempie: Skoro miałem już ograne wyświetlanie grafiki, przyszedł czas na prototypowanie konsoli i pisanie samego kodu gry Aktualnie moje stanowisko pracy wygląda następująco: Sama gra jest na etapie tworzenia grafiki. Na razie mam animacje na intro: To tyle na dzisiaj. Wraz z postępami będę aktualizował ten wątek. Pozdrawiam, Marek
  7. Projekt skończony. Powstał z tego fajny moduł do prototypownia urządzeń zasilanych baterią LiPo. Ostatecznie moduł bazuje na następujących układach: 1. MCP73871-2CC - zintegrowana ładowarka LiPo + power path 2. STM6601-CQ2BDM6F - układ nadzorujący, komunikacja z uC, obsługa przycisku [POWER] 3. TPS63001 - konwenter DC/DC typu buck/boost z wyjściem 3,3V do 1,2A. Projekt został zaprojektowany od kart katalogowych, tzn nie użyłem ani jednego gotowego modułu. Główne funkcje: 1. Bezpieczne ładowanie praktycznie dowolnej baterii LiPo 3,7V (pełna konfiguracja parametrów przez wymianę dwóch rezystorów oraz ustawienie zworek na płytce) 2. Pełna obsługa przycisku [POWER] jak w telefonach komórkowych: - Krótkie wciśnięcie gdy układ jest wyłączony - uruchomienie zasilania. Wtedy uC musi potwierdzić że wszystko OK ustawiając stan wysoki na linii HOLD. - Krótkie wciśnięcie gdy układ jest włączony - sygnał wysłany do uC. Oprogramowanie może zapisać swój stan, a następnie bezpiecznie wyłączyć zasilanie przez ustawienie stanu niskiego na linii HOLD. - Długie wciśnięcie (powyżej 10s) - awaryjne wyłączenie zasilania - np gdy uC przestanie odpowiadać. 3. Zabezpieczenia zintegrowane w zastosowanych układach: - Przeciwzwarciowe (TPS6301) - Gdy napięcie baterii spadnie poniżej 3,3V nie można uruchomić urządzenia przyciskiem [POWER]. Jednak jeżeli urządzenie już działa to będzie ono zasilane do momentu gdy napięcie w baterii spadnie do poziomu 3,1V [STM6601] - Gdy napięcie na baterii spadnie do poziomu 3,1V - nastąpi awaryjne wyłączenie urządzenia [STM6601] - Dodatkowo na baterii zwykle jest zintegrowany układ zabezpieczający odcinający zasilanie na poziomie 3V - Zabezpieczenie przed przeciążeniem gniazda USB. Całkowity prąd pobierany z gniazda zasilania można skonfigurować na poziomie 100mA, 500mA lub wyłączyć to ograniczenie. Zasilany układ ma zawsze priorytet i jeżeli pobór prądu będzie zbyt duży to układ ładujący automatycznie obniży prąd ładowania baterii, tak żeby całkowity pobór prądu nie przekroczył ustawionego limitu [MCP73871] - Możliwość podłączenia czujnika temperatury w celu monitorowania baterii podczas ładowania [MCP73871] - Zabezpieczenie przed zwarciem w obwodzie baterii [MCP73871] Poniżej zdjęcia z poszczególnych etapów prac na modułem: 1. Prototypowanie i testy. Zacząłem od zamówienia przejściówek QFN, DFN na DIP (nie były nigdzie dostępne potrzebne mi rodzaje więc musiałem zrobić projekt PCB i zamówić). Zamówiona została też specjalna płytka na której wykonałem kompletny przetwornik DC/DC. Ze względu na wymóg jak najkrótszych połączeń między elementami przetwornika - nie można było go złożyć na płytce stykowej. 2. Projektowanie PCB 3. Zamówione płytki drukowane i montaż Montaż nie nastręczał problemów. Najtrudniej było przylutować gniazdo USB Montowałem i testowałem układ w następującej kolejności: konwerter DC/DC -> układ nadzorujący -> układ ładowania. 4. Gotowy moduł: Pozdrawiam, Marek
  8. A tyle da się wycisnąć z STM32F103 przy odpowiedniej optymalizacji drivera. Podłączyłem TFT bazujący na ILI9341 16-bitową magistralą. Z pomiarów wynika że udało się osiągnąć szybkość 5.5Mpix/s (pomiar oscyloskopem na lini WR). Mikrokontroler pracował na 64MHz, więc zostało jeszcze kilka MHz w zapasie. Jeszcze muszę dodać wyświetlanie tekstu. Pozdr! EDIT: Faktycznie po ustawieniu optymalizacji na -O3, prędkość zapisu wzrosła do 8Mpix/s. Możemy w ten sposób wypełnić ekran jednolitym kolorem ponad 100 razy na sekundę.
  9. Wyrazistość obrazu nie zależy od siły podświetlania. Poeksperymentuj z kontrastem. Poszukaj linijki: lcd_cmd(0x80 | 0x2f); //Ustawienie kontrastu i zmień 0x2f na inna wartość, np: lcd_cmd(0x80 | 0x3f); //Ustawienia kontrastu Pozdrawiam, Marek
  10. @atMegaTona Chcę wszystko zaprojektować i zbudować sam. W celach edukacyjnych. Nie chcę kupować gotowych modułów. STM6600 lub coś podobnego chcę dodać w późniejszym etapie bo wydaje mi się ciekawym układem i daje między innymi następujące możliwości: + Włączenie układu jednym przyciskiem (krótkie wciśnięcie) + Wysłanie przerwania do mikrokontrolera gdy krótko wciśniemy przycisk POWER (np w celu zapisania danych do EEPROM przed wyłączeniem) + Możliwość wywołania hard reset długim przytrzymaniem przycisku POWER (przydatne gdy układ się zawiesi a urządzenie jest zabudowane i nie ma łatwej możliwości odłączenia baterii) + Automatyczne wyłączenie układu gdy poziom baterii spadnie poniżej dozwolonego + Możliwość kontroli stanu zasilania przez mikrokontroler + Możliwość wywołania wyłączenia zasilania układu z poziomu mikrokontrolera Tak więc możliwości są duże i chciałbym się tym układem pobawić. Na razie w celach edukacyjnych.
  11. Jeszcze wracając do pierwszego postu. Rozważam dwie opcje: 1. Przetwornica DC/DC połączona równolegle z ładowaniem oraz baterią: + Łatwiejsza konstrukcja - Wciąż nie jestem pewien czy takie połączenie jest prawidłowe (jak zachowa się logika układu ładującego gdy będzie ładował baterię i zasilał przetwornicę jednocześnie ?) 2. Przetwornica odłączana MOSFETem w momencie podłączenia zasilania USB: + W momencie podłączenia zasilania przetwornica i ładowarka działają niezależnie (jestem pewien że logika ładowarki będzie działać prawidłowo) - Prąd zasilania przetwornicy oraz ładowarki sumują się więc istnieje ryzyko przeciążenia portu USB. Może jakiś bardziej doświadczony kolega skomentuje?
  12. @Gieneq Możliwe że nie wyraziłem moich zamiarów jasno. Pisząc moduł miałem na myśli część układu zasilania który chcę zbudować. Nie chcę kupować gotowych modułów zasilania. Wracając do projektu.... Przeglądałem ofertę w sieci i wstępnie wybrałem następujące układy ([+] zalety [-] wady): 1. Charger IC - TP4056 + Dostępny w ilościach detalicznych + Łatwa w montażu obudowa SOP-8 + Wymaga niewielu dodatkowych elementów do działania + Można płynnie zmieniać prąd ładowania zależnie od potrzeb nawet do 1A + Możliwość kontroli temp baterii (opcjonalnie) + Niska cena - Nie wiem jak z jakością tego układu, mało znany chiński producent 2. DC/DC Converter - LTC3440EMS + Dostępny w ilościach detalicznych + Łatwa w montażu obudowa MSOP-10 + Wymaga niewielu dodatkowych elementów do działania + Napięcie wejściowe 2,5 - 5,5V + Napięcie wyjściowe 2,5 - 5,5V (można dowolnie zmieniać zależnie od potrzeb) + Prąd wyjściowy do 600mA + Możliwość kontroli układu przez wejście ~SHDN (shut down) 3. Power button controller - Tu wciąż szukam układu. Na razie znalazłem dwa: STM6600 + dostępny w ilościach detalicznych + wiele ciekawych opcji w połączeniu z mikrokontrolerem - bez Hot Air raczej nie przylutuję - nigdzie w sklepach nie znalazłem przejściówki TDFN12 -> DIP do prototypowania (może ktoś widział? ma na sprzedaż?) - wysoka cena MAX16054 + Łatwa do lutowania obudowa SOT23 - w ilościach detalicznych praktycznie niedostępny w Polsce - dużo mniejsze możliwości niż STM6600 - wysoka cena (wyższa nawet niż STM6600)
  13. Witam! Planuję zaprojektować zasilanie 3,3V do przyszłych budowanych układów. Wymagania: - Max prąd na wyjściu 250mA - Bateria Li-Po 3,7V - Ładowanie przez USB - Możliwie mały - czyli układy SMD - Możliwy do ręcznego polutowania bez Hot Air - Max prąd pobierany z USB - 500mA. (Wiem, że prawidłowo układ powinien pobierać 100mA a później dokonać identyfikacji portu USB i przełączyć się na 500mA, ale na początek nie chcę komplikować układu). Zamierzam skorzystać z jedno-układowych modułów ładowania z USB oraz przetwornicy DC/DC (step up/down). Nigdy nie budowałem ładowarki USB i zasilania z baterią w jednym urządzeniu, dlatego na początek chciałbym potwierdzić ogólny układ blokowy (w załączniku). Czy rzeczywiście wystarczy równolegle połączyć moduł ładowarki, baterię i przetwornicę? Czy tak podłączony układ ładujący będzie działać prawidłowo w czasie gdy jednocześnie będziemy zasilać odbiornik? Myślałem jeszcze nad drugą opcją, żeby na czas podłączenia zasilania USB, przetwornicę odciąć od baterii (np tranzystorem MOSFET) i zasilać bezpośrednio. Tylko jak wtedy ograniczyć max prąd pobierany z USB.
  14. Dzięki! Jak tylko wymyślę jak sterować głośnikiem (obsługa DAC) to dodam loop z Dr Dre - "The Next Episode" do zwycięskiej planszy Przy kodowaniu PCM 8bit/8kHz dla 5s wyjdzie jakieś dodatkowe 40kB.
  15. Mając wyświetlacz od starej dobrej Nokii musiałem napisać grę w węże Poniżej rezultat:
×
×
  • Utwórz nowe...