Skocz do zawartości

atlantis86

Użytkownicy
  • Zawartość

    151
  • 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

208 Mistrz

O atlantis86

  • Ranga
    5/10
  • Urodziny 11.01.1986

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Kraków
  • Programuję w
    C/C++, Python, ASM
  • Moje 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. 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
  2. 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
  3. 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
  4. 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
  5. 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?
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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...
  11. 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
  12. Problem polega właśnie na tym, że biblioteka do obsług RAM-u nie zmienia niczego w konfiguracji magistrali SPI. Jej parametry są konfigurowane w następujący sposób: Wstępnie, przez STM32CubeMX, do pracy z niską prędkością. Na początku procedury inicjującej SD jeszcze raz na wszelki wypadek ustawiam dzielnik częstotliwości SPI (inicjacja karty tego wymaga). Po zakończonej pomyślnie inicjacji SD ustawiam niski dzielnik, aby zwiększyć prędkość transmisji danych. Ta jednak mieści się jednak zarówno w specyfikacji karty SD, jak i RAM-u. Zresztą, próbowałem też manipulować t
  13. Projektując płytkę do jednego se swoich projektów na STM32F407 miałem dość napiętą sytuację z pinami. Aby oszczędzić jeden z nich stwierdziłem, że skonfiguruję sobie UART w trybie Single Wire (Half-Duplex), mogąc dzięki temu przeznaczyć pin RX do innych celów. UART tak czy inaczej jest mi potrzebny do debugowania i nie planowałem czegokolwiek n niego wysyłać. W STM32CubeMX skonfigurowałem USART1 w następujący sposób: Baud Rate: 115200 bps Word Lenght: 8 bits (including parity) Parity: None Stop bits: 1 Data Direction: Receive and Transmit (próbowałem też Transmit Only) Over Samp
  14. Uruchamiam właśnie urządzenie na mikrokontrolerze STM32F107RCT6. Jakiś czas temu uruchomiłem na mim obsługę karty SD za pośrednictwem magistrali SPI3. Wszystko działało idealnie - bez problemu zarówno odczytywałem, jak i zapisywałem dane. Dzisiaj wlutowałem w płytkę kolejny element - tym razem pamięć RAM 23LC1024, która jest podpięta do tej samej magistrali, ale rzecz jasna steruje nią osobny pin GPIO. Na szybko napisałem kilka funkcji do obsługi tej pamięci, wzorowanych na tej bibliotece dla Arduino. Pamięć sama również działa poprawnie. Problem zaczyna się, gdy próbuję w jednym projekcie uży
  15. W swoich projektach dość często wykorzystuję bufory kołowe/cykliczne. Do tej pory samo zastosowanie gwarantowało mi, że nigdy nie dojdzie do sytuacji, kiedy dane będą przychodziły szybciej niż niż zadanie w pętli głównej będzie w stanie je przetworzyć, bo szybkość na wejściu była narzucana przez prędkość UART-u albo częstotliwość próbkowania ADC. Teraz jednak mam do czynienia z sytuacją odwrotną - buduję odtwarzacz audio, w którym dane z pliku (lub połączenia TCP) są zapisywane do bufora, a następnie gdy zachodzi taka potrzeba program przesyła je do VS1003 przez SPI. FatFS albo stos TCP/IP móg
×
×
  • 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.