atlantis86

Chyba nie do końca ten sam, bo jak widzisz ten z przytoczonego linku posiada zworki do ustawiania szerokości magistrali (8/16 bit). Nie posiada natomiast nieopisanej zworki J1, która występuje u mnie. Miałem więc cichą nadzieję, że być może ten konkretny model posiada opcję skonfigurowania w trybie SPI. Wiem, że z całą pewnością istnieją moduły wyświetlaczy mogące pracować w trzech trybach: SPI, 8 bit i 16 bit. Tak było w przypadku wyświetlacza, który został użyty w radiostacji McHF M0NKA, którą kiedyś składałem. Niestety, chyba nie tym razem... Wygląda na to, że masz rację. No cóż...

Potrzebuję pomocy, bo chyba lekko zawaliłem sprawę. Jakiś czas temu zabrałem się za umieszczenie moich starych projektów w obudowach. W końcu przyszedł czas na prosty odtwarzacz multimedialny/radio internetowe na RasPi0. Opis TUTAJ. Jak widać na zdjęciach, projekt oryginalnie posiadał mały wyświetlacz SPI, zamocowany bezpośrednio na płycie głównej, a całość miała trafić do obudowy projektowanej na wymiar i drukowanej 3D. teraz jednak stwierdziłem, że wrzucę go do metalowej obudowy. Ponieważ na przednim panelu miałem znacznie więcej miejsca doszedłem do wniosku, że dam mu większy wy

Ok, odpowiem samemu sobie na wypadek, gdyby komuś podobna informacja była potrzebna w przyszłości. Okazuje się, że uruchomienie wyświetlacza przez wpis |dtoverlay=" w /boot/config.txt wymaga obecności odpowiedniego pliky *.dtso w katalogu /boot/overlays. W moim przypadku potrzebny był plik rpi-display, do którego odwoływała się większość tutoriali. Niestety plik ten został przygotowany z myślą o konkretnym modelu nakładki na RasPi, która wykorzystywała konkretne piny oraz dodatkowo uruchamiała panel dotykowy, co u mnie prowadziło do konfliktów z innymi peryferiami. Na szczęście jak s

Postanowiłem ostatnio wrócić do starego, niedokończonego projektu na Raspberry Pi Zero. Po wyjęciu go z pudełka, podłączeniu do zasilania i zalogowaniu się przez SSH okazało się, że siedzi tam ciągle stary Raspbian Jessie. Podniosłem go najpierw do Stretcha, a następnie do Bustera. Niestety po tej drugiej aktualizacji przestał działać wyświetlacz na ILI934, podłączony do magistrali SPI. Jego konfiguracja była zawarta w pliku /etc/modprobe/fbtft.conf: options fbtft_device custom name=fb_ili9341 rotate=90 speed=16000000 fps=50 bgr=1 buswidth=8 cs=1 gpios=reset:23,dc:24,led:25 Niestet

Z tego gniazda nie skorzystasz za pomocą DroidRTTY. Ten program robi to, co najwyraźniej jest już realizowane wewnątrz radia - poddaje sygnał audio demodulacji FSK i interpretuje go, wyświetlając odpowiednie znaki na ekranie telefonu. Na gnieździe dalekopisu będziesz miał bardzo wolną (zapewne 50 bps) komunikację szeregową, zrealizowaną na pętli prądowej. Protokół to standardowy interfejs szeregowy, tylko zamiast poziomów napięć (jak w TTL czy RS232) masz dwie możliwe sytuacje: albo jest przerwa w obwodzie, albo płynie przez niego prąd 40 mA. Stanem domyślnym jest właśnie przepływ prądu. Gdy n

Ok, faktycznie pospieszyłem się z napisaniem tego posta. Zapomniałem wspomnieć, że: Na samym początku przetestowałem nie tyle wrzucony przeze mnie kod, co przykład GPIO IRQ z sieci i wtedy wszystko działało, więc płytkę uznałem za sprawną. Dzisiaj testując układ próbowałem wywoływania przerwania na obydwu zboczach i efekt był taki sam. Dopiero po chwili dotarło do mnie, że pierwszy test był wykonywany na samym RPiPico, a w drugim przypadku było ono włożone w płytkę, gdzie do pinu jest podłączony tranzystor, ściągający go do masy po otrzymaniu sygnału z innego obwodu. N

Temat mogłoby się wydawać banalny, ale siedzę nad tym i nie mogę zmusić pico do zgłaszania przerwania zewnętrznego. Opierając się na kodzie z tego przykładu napisałem coś następującego: #include <stdio.h> #include <stdint.h> #include "pico/stdlib.h" #include "../FatFS/ff.h" #include "../FatFS/diskio.h" #include "../PicoJPEG/picojpeg.h" #include "../PicoJPEG/jpeg_helpers.h" #include "../wave/wave.h" #include "hardware/pll.h" #include "hardware/gpio.h" #include "hardware/clocks.h" #include "hardware/structs/pll.h" #include "hardware/structs/clocks.h" #include "FreeRTOS.h" #i

Ok, wygląda na to, że udało mi się osiągnąć pewien sukces i pchnąć projekt do przodu. Na chwilę obecną wygląda to tak, jakby pamięć SPI nie lubiła się z jedną konkretną kartą SD (Kingston). Nie dosyć, że występował wyżej opisany problem, to jeszcze parę razy zaobserwowałem wysypanie się systemu plików (w tym jednym konkretnym urządzeniu, w innym projekcie karta jak na razie zdaje się działać prawidłowo). Po zastosowaniu SanDisca problemy przestały się pojawiać. Okazuje się jednak, że przydatność 23LC1024 jako podręcznego bufora na próbki audio (zakodowane w MP3) jest mocno ograniczon

Czy tę bibliotekę da się w jakiś sposób dostosować do odtwarzania MOD-ów z pliku? W opisywanym przykładzie dane są ładowane z tablicy w pamięci flash. Niestety STM32 nie dysponują zazwyczaj pamięcią RAM, która pozwoliłaby na raz załadować całość pliku MOD, który może mieć i kilkaset kB. Da się jakoś karmić odtwarzacz danymi z pliku porcjami?

Ok, garść nowych informacji: Podłączyłem analizator stanów logicznych do linii CS karty SD oraz pamięci RAM. Nigdy nie występuje sytuacja, kiedy obydwie linie jednocześnie znajdowałyby się w stanie niskim. Po zakończeniu operacji na RAM-ie i ustawieniu jego linii w stan wysoki mijają jeszcze trochę ponad trzy ms, zanim w stan niski zostanie ustawiona linia CS karty SD (między tymi operacjami jest printf). To bardzo dużo czasu, żeby stany linii zdążyły się ustabilizować. Najwyraźniej eksperymentując z projektem coś zrobiłem, tylko nie wiem co... Może chodzi o ustawienie para

Kontynuuję uruchamianie projektu wykorzystującego mikrokontroler STM32F407. Z ważniejszych peryferiów został mi już tylko do uruchomienia kodek audio WM8731. Mój testowy kod do obsługi tego układu wygląda następująco: #include <stdlib.h> #include <stdio.h> #include <stdint.h> #include <math.h> #include "stm32f4xx_hal.h" #include "main.h" #define WM8731_ADDR (0x1A << 1) //#define WM8731_ADDR 0x1A extern I2C_HandleTypeDef hi2c1; extern I2S_HandleTypeDef hi2s3; #define AUDIO_BUFFER_SIZE 2200 static int16_t audio_data[2 * AUDIO_BUFFER_SIZE]; static v

Eksperymentowałem trochę z "czystym" FreeRTOS na Raspberry Pi Pico, nie napotykając na jakieś większe problemy. Teraz próbuję uruchomić jeden projekt na CMSIS v2 RTOS na STM32F407 (projekt "wyklikany" w STM32CubeMX) i co jakiś czas trafiam na jakiś problem. Wiele rzeczy nie działa tak, jak powinno działać. Wygląda na to, że jeszcze będę musiał trochę doczytać i douczyć się. Czy możecie polecić jakiś materiały, które tłumaczyłyby takie zagadnienia jak: Zarządzanie pamięcią i przydzielanie jej poszczególnym wątkom, obsługa zmiennych przy korzystaniu z RTOS. Korzystanie z

W pełni zgodziłbym się z tym, gdyby nie fakt, że na tym etapie nawet nie dodawałem żadnej obsługi przerwań w tym projekcie. Jak widać w sekcji ustawień NVIC w STM32CubeMX, włączone są tylko te domyślne. Puste są także ustawienia DMA. Plik stm32f1xx_it.c nie zawiera żadnego mojego kodu. Sterownik do RAM-u napisałem samodzielnie, wzorując się na bibliotece dla Arduino. Sterownik SD na SPI przeportowałem z kodu dla PIC32 (pochodzi z przykładu dołączonego do podręcznika autorstwa Lucio di Jasio). Oryginalnie nie było tam żadnych przerwań, a ja ich nie dodałem. Ok, w woln

To była moja pierwsza myśl. Niestety, STM32CubeMX z jakiegoś powodu nie pozwala na takie rozwiązanie. Jeśli wybiorę tryb asynchroniczny, to automatycznie rezerwowane są dwa piny. Nawet jeśli w ustawieniach wybiorę "transmit only". Jeśli spróbuję ręcznie zwolnić pin RX i przypisać mu inną funkcję, to automatycznie dezaktywuje się UART. Co więcej - jeśli wcześniej przypiszę pin RX to jakiegoś innego celu, to program w ogóle nie pozwala wybrać trybu asynchronicznego. Single wire to jedyny tryb, który pozwala mi korzystać tylko z linii TX...

Zrobiłem jeszcze kilka dodatkowych prób. Wychodzi na to, że: Podciągnięcie linii do plusa z pomocą rezystor 10k nie daje właściwie nic. Użycie funkcji HAL_HalfDuplex_EnableTransmitter(&huart1) tylko raz na początku programu i niewywoływanie funkcji HAL_HalfDuplex_EnableReceiver(&huart1) po zakończeniu transmisji tylko pogarsza sprawę - w terminalu pojawia się istna sieczka. Najbliższym do ideału rozwiązaniem jest wysłanie kilku bajtów o wartości 0 przed właściwym komunikatem. Wtedy każda linia zaczyna się od nieznnego znaku, ale ciąg dalszy jest ok. Niskopozi