atlantis86

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

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

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

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

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

Dzięki za info. To się może przydać. Jeśli to faktycznie działa tak jak mówisz, to nie ma sensu nawet modyfikować plików, podmieniając tokeny na wartości. Korzystając z gotowych serwerów na PIC32 i ESP8266 NONOS SDK korzystałem z tokenów, bo były dostępne i pozwalały pewne rzeczy osiągnąć w bardzo wygodny sposób. Jednak równie dobrze ten sam efekt można osiągnąć modyfikując DOM po stronie przeglądarki, za pomocą skryptów JS i danych pobieranych za pomocą JSON-a. Mógłbym zacząć od napisania funkcji, które pobierałyby dane przez GET i wysyłały konfigurację przez POST. Na własny użytek wystarczy,

Swoją drogą, znasz może jakiś prosty i wygodny sposób na konfigurowanie urządzeń na ESP8266? Jak wspominałem, do tej pory korzystałem z "pełnego" serwer WWW, który obsługiwał pliki zapisywane w systemie plików w pamięci flash oraz tokeny, zamieniane na wartości zmiennych podczas wysyłania strony. Stworzyłem sobie w nim całkiem wygodną stronę konfiguracyjną - urządzenie startowało w trybie SoftAP, pozwalając na przeskanowanie WiFI, połączenie z określonym AP oraz skonfigurowanie kilku innych parametrów. Niestety - wspomniany serwer z GitHuba od dawna nie miał aktualizacji i prawie na pewno

A usunąłeś niepotrzebny kod z przykładowych funkcji? Bo trochę tego tam było: odczytywanie treści nagłówków, logowanie poszczególnych operacji na monitor (to narzędzie do debugowania) itp. Odchudziłem do maksimum funkcję obsługującą jeden URI i teraz nie robi ona właściwie nic poza zwróceniem odpowiedniego tekstu. Teraz czas załadowania kompletnej strony w Chrome spadł do około 18 ms. Nic nie stoi na przeszkodzie, żeby biblioteka TCP/IP udostępniała także funkcje do obsługi wyższych warstw. Tak było chociażby w przypadku biblioteki TCP/IP od Microchipa, która posiadała m.in. całkiem ro

Hmm... Zrobiłem test n jednym z przykładów dodanych do RTOS SDK. Czas załadowania prostej strony w stylu "Hello World" to jakieś 50ms. Nie jest idealnie, ale chyba też nie tragedia na prostym MCU. Może po prostu napisany przez Ciebie serwer był uproszczony dużo bardziej od tego, czego używa RTOS SDK? Tm chyba pod spodem siedzi serwer z lwIP? Pamiętam, że w czasach NONOS używałem bardziej zaawansowanego serwera, który pozwalał na załadowanie kompletnych stron do pamięci flash ESP8266 i użycia w plikach html/js/json tokenów, które były podmieniane na określone wartości podczas wysyłania strony

Parę lat temu zdarzało mi się tworzyć projekty na ESP8266, przy pomocy NONOS SDK od Espressif (nie przepadam za Arduino, które w przypadku ESP8266 tak naprawdę jest jedynie nakładką na to SDK). Niestety każda dłuższa przerwa oznaczała konieczność douczania się, bo producent wprowadzał zmiany, które wymagały dodawania kolejnych definicji i funkcji do własnego kodu, często w zależności od posiadanego modułu. Jakiś czas temu utknąłem na próbie przegryzienia się przez SDK w wersji 3.0 i prawdę mówiąc do tej chwili nie miałem motywacji, żeby się za to zabrać. Głównym powodem było to, że w międzycza