Skocz do zawartości

atlantis86

Użytkownicy
  • Zawartość

    127
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    10

atlantis86 zajął 1. miejsce w rankingu.
Data osiągnięcia: 13 listopada 2020.

Treści użytkownika atlantis86 zdobyły tego dnia najwięcej polubień!

Reputacja

201 Mistrz

O atlantis86

  • Ranga
    5/10
  • Urodziny 11.01.1986

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Kraków
  • Języki programowania
    C/C++, Python, ASM
  • Zainteresowania
    Amatorska elektronika, programowanie, historia techniki

Ostatnio na profilu byli

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

  1. Ok, już chyba wiem w czym rzecz. Spojrzałem na dokumentację i faktycznie masz rację - Arduino Core dla ESP8266 nadal korzysta z SDK NONOS. Rzuciłem też okiem na port libmad dla ESP8266. Kod wykorzystuje low-level API, w które nawet jeszcze nie zacząłem się wgryzać. Wygląda na to, że za jego pomocą faktycznie można stworzyć kod sekwencyjny, ale kosztem napisania od podstaw swoich własnych funkcji odpowiedzialnych za pobieranie i zwracanie danych. Najwyraźniej właśnie to zrobili twórcy biblioteki Arduino, która poza oryginalnymi plikami libmad posiada też sporo nowego kodu. Może faktyc
  2. O tym też myślałem, ale na razie szukam bardziej uniwersalnego rozwiązania. Zakładam, że w przyszłości będę chciał wykorzystać tę samą bibliotekę także na innych układach, z jednym rdzeniem (PIC32, STM32). Właśnie nie bardzo mogę. To znaczy mogę, ale kosztem użycia bardzo brzydkiego kodu. W swoich dotychczasowych projektach stosuję rozwiązanie, które wygląda następująco: int main (void) { while(1) { uart_rx_hndle(); network_handle(); log_data_to_file(); } return 0; } Każda z takich funkcji wygląda następująco: void func_handle (void) { static uint32_
  3. Szukałem ostatnio jakiegoś sposobu programowego dekodowania MP3 na mikrokontrolerze (w tym przypadku konkretnie Raspberry Pi Pico). Parę dni temu na forum polecono mi bibliotekę libmad. Udało mi się ją bez większego programu skompilować i przystąpiłem do jej uruchamiania. Działanie biblioteki opiera się na callbackach - przystępując do dekodowania audio trzeba zdefiniować kilka funkcji, które będą wywoływane w określonych sytuacjach (odczyt porcji danych, zgłoszenie błędu, zapis zdekodowanych danych do bufora DAC ). Każda funkcja zwraca wartość determinującą dalsze postępowanie - najważni
  4. Hmm... W sumie racja. Nie wiem czemu nie pomyślałem o najprostszej opcji.
  5. Libmad. Moja pomyłka. Czyli po prostu powinienem np. użyć funkcji map() celem przepisania wartości 24bitowych na zakres 0-255? Też jestem ciekaw. Na razie jeszcze nie bawiłem się z PIO, w obecnie powstającym projekcie nie potrzebuję wysokiej jakości audio.
  6. Ok, na razie udało mi się uruchomić na Pico odtwarzanie dźwięku PCM z plików WAV (PWM i timer) oraz skompilować LibMAN. W wolnej chwili zabiorę się za próbę uruchomienia odtwarzania MP3. W międzyczasie chciałem zapytać, czy ktoś się orientuje jak wygląda kwestia formatu wyjściowego LibMAN. Z opisu biblioteki wygląda, że produkuje ona dane PCM 24bit. Ponieważ u mnie pracuje bardzo prosty 8 bitowy "DAC" na PWM, dałoby się ją jakoś skonfigurować, żeby na wyjściu produkowała takie dane? Czy muszę je ręcznie konwertować?
  7. Ok, po wlutowaniu VS1003 okazało się, że wszystko działa. Czyli najwyraźniej winę ponosiła przyczyna opisana powyżej.
  8. To może jeszcze przy okazji zapytam: istnieje jakaś prosta w implementacji biblioteka do dekodowania MP3, którą też mógłbym przetestować na RPi Pico?
  9. Jeśli byłaby taka możliwość, to tak. AVI to format kontenera do przechowywania strumieni multimedialnych, MJPEG to format bardzo lekkiego kodeka wideo w którym każda klatka jest obrazkiem JPEG. Gdyby udało mi się dobrać do tych danych z poziomu mikrokontrolera, ułatwiłoby mi to bardzo mocno przygotowywanie treści, bo są to formaty obsługiwane przez popularne programy do kompresji wideo.
  10. Ok, pierwsze testy biblioteki PicoJPEG są bardzo obiecujące. Na RaspberryPi Pico pojedynczy plik 64x32 w skali szarości dekoduje się w jakieś 8-9 ms. W rzeczywistości będzie trochę więcej, bo kod nie uwzględnia jeszcze przepisywania zdekodowanych danych do bufora na bitmapę, ale tutaj różnica będzie minimalna. Ponieważ zadowoli mnie kilkanaście klatek na sekundę, pozostaje naprawdę sporo czasu na pozostałe zadania - nawet jeśli uwzględni się wyłuskiwanie ramek JPEG z pliku AVI zakodowanego MJPEG czy jakieś dekodowanie audio. A mam przecież jeszcze drugi rdzeń i PIO do pomocy. Swoją dro
  11. Ok, na razie udało mi się znaleźć coś takiego. Kompiluje się bez problemu pod RPi Pico, bez konieczności wprowadzania żadnych zmian do kodu. Zobaczymy czy i jak działa. https://github.com/richgel999/picojpeg
  12. Na te biblioteki już trafiłem przeglądając wyniki wyrzucone przez Google'a. Tę pierwszą można też chyba wyklikać w STM32CubeMX. Czy są gdzieś dostępne materiały wyjaśniające jak dodać bibliotekę do projektu pod mikrokontroler? Bo z tego co widzę, to paczki do ściągnięcia ze stron projektu są przystosowane raczej do kompilacji na PC. Jest może coś "embedded friendly", podobnego np. do "FatFS-a"? Raspberry PI Pico chyba wcale aż tak bardzo nie wyprzedza innych układów, które biorę pod uwagę: PIC32MX795F512L to jednak ciągle całkiem wydajny układ MIPS, taktowany 80 MHz.
  13. Szukam jakiejś biblioteki, która pozwoliłaby na w miarę szybkie dekodowanie plików JPEG, a jednocześnie była prosta w implementacji. Preferuję coś napisanego w czystym C, w oderwaniu od warstwy sprzętowej (a więc bez wstawek asemblerowych czy odwołań do rejestrów konkretnego układu), dzięki czemu mógłbym taki kod w miarę prosto przenosić np. pomiędzy PIC32, STM32, ESP32 czy RPi Pico. Na chwilę obecną dekodowane pliki będą bardzo lekkie - kilkadziesiąt na kilkadziesiąt pikseli, w skali szarości. Ponieważ jednak planuję eksperymentować z odtwarzaniem wideo skompresowanego MJPEG byłoby dobrz
  14. Niewykluczone, że znalazłem możliwą przyczynę, chociaż ciągle nie wiem co mogło za nią odpowiadać... Ponieważ podczas prób delikatnie uszkodziłem płytkę, postanowiłem wytrawić i złożyć ją ponownie. Przy tej okazji przeniosłem na nowe PCB wszystkie elementy za wyjątkiem VS1003. Efekt uruchomienia układu był taki, że tym razem rejestry zostały odczytane jako 0xFFFF, bo nie miało ich co ściągnąć do masy (jak widać na obrazku wrzuconym wcześniej, po ustawieniu pinu CS na stan nisku, VS1003 sprowadzał linię MISO do masy). Na tym etapie postanowiłem upewnić się co do działania linii CS, DC
  15. Ok, nie miałem dzisiaj za bardzo czasu na podpinanie analizatora logicznego, ale na szybko zrobiłem dwa inne testy - zastosowałem zaproponowaną przez Ciebie konfigurację SPI w poprzednich wersjach płytki, z mikrokontrolerami PIC24 i PIC32. Efekty wyglądają następująco: Płytka z PIC32. Było CPOL=0, CPHA=1 (w mikrokontrolerach PIC te bity mają nieco inne nazwy, ale wolę stosować jednolite nazewnictwo, żeby nie robić zamieszania). W takiej konfiguracji układ działał w 100%, to znaczy mogłem zarówno odczytać zawartość rejestrów, jak i odtwarzać muzykę. Teraz ustawiłem CPOL=0 i CPHA=0. Nic
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.