Witam,
Mam problem związany z USARTem w układzie STM32F303. Staram się uruchomić naprawdę prosty program, którego zadaniem jest wysyłanie co pewien czas na terminal jakiejkolwiek wartości (w tym wypadku wartości 11). Chce po prostu sprawdzić czy PC cokolwiek odbiera. No i jest problem gdyż nie pojawia się nic... Sprawdzałem połączenia fizyczne - używam konwertera USB-RS232 (napięcia w zakresie 0-3.3V) - TX->RX; RX->TX. To wydaje się być w porządku. Czy zapomniałem o jakiejś dodatkowej linii ?

Konfiguracja pinu TX i RX:


USART_SendData(); wysyła tylko pojedyncze znaki np.


Jak chcesz wysłać więcej to:


Zwiekszyłbym tego delay`a chociaż do 100 ms

ps19:

na arm sie nie znam ale jaka jest roznica
miedzy


a



moim zdaniem żadna

bo w obu przypadkach dostaniesz na terminalu znak A lub kod hex liczby jezeli nie jest znakiem asci

Witam ponownie,
Zdeklarowałem ponownie porty GPIO zgodnie z zalecaniami ps19, ale dalej cisza w terminalu...

Spróbuj zamigać jakąś diodą na porcie A, może w RCC_config jest błąd. Możliwe, że masz coś na PC źle skonfigurowane. Wrzuć kod z poprawkami.

Rozumiem, że zamigać diodą poprzez rozkaz z pc->stm32 ? RCC raczej jest dobrze ustawione (CooCox z którego korzystam na co dzień jest na tyle "mądrym" kompilatorem, że sprawdza dokładnie każdą linie którą pisze - również te związane z RCC). Jeśli chodzi o ustawienia komputera... hmm... przez chwile myślałem, że konwerter jest usiekany, jednak zwarłem TX z RX no i występuje efekt echa, czyli z nim (i prawdopodobnie z ustawienia pc) jest wszystko ok

Nie, zamigać diodą poprzez zmianę stanu na jakimś porcie A. W ten sposób ustalimy czy procek m.in odmierza czas i zegar w nim "tyka"

CooCox nie powie ci że zapomniałeś jakiejś linii odpowiedzialnej za konfigurację np. PLL. Sam używam CooCox`a

Wrzuć cały kod z poprawkami

Problem rozwiązany, wystarczyło dodać linie odpowiedzialne za konfigurację funkcji alternatywnych tzn:


P.S.
Mam małą zagwozdkę, a nie chce zaśmiecać forum nowymi tematami. Mianowicie, chciałbym za pomocą wspomnianego stm'a próbkować sygnał o zmiennej częstotliwości (4kHz-40kHz). No i teraz tak: teoria mówi, że minimalna fp powinna wynosić jakieś 80kHz (dla tego przypadku). Z praktyki jednak wiadomo, że lepsza by była większa wartość częstotliwości próbkowania.
Narazie mam w głowie następującą koncepcję: ustawiam przetwornik ADC na 12 bit (chce "wycisnąć" z STM'a ile natura dała ), ustawiam go w tryb pojedynczego pomiaru i wyzwalam timerem co np. 5us. Teraz: chciałbym próbki wysyłać przez usart do pc. W czasie rzeczywistym tego nie dokonam, ponieważ standard tego nie wytrzyma (tak przynajmniej mi się wydaje), więc próbki z ADC bd wysyłał do dwóch tablic (tab1 i tab2) za pomocą DMA. Na początku zapełnie tab1 próbkami - zrobie przerwanie, rozpoczne zapełnianie tab2 - próbki z tab1 chce wysyłać do pc i tak w koło macieju. No i teraz mam zgrzyt... bo przy takiej częstotliwości próbkowania to jest prawie pewne, że tablica się prędzej zapełni próbkami z adc (np. tab1), aniżeli druga (tab2) zdąży wysłać swoje wartości przez USART'A (jeszcze dodatkowo muszę każdą próke w postaci 16bitowej podzielić na pół; wiem: adc daje 12 bitową próbkę, ale będę ją musiał poszerzyć do wspomnianych 16).
Chciałem zatem zapytać czy jest jakieś inne rozwiązanie/metoda podejścia do tego problemu ? Wiem, że istnieją rozwiązania typu przystawka oscyloskopowa do komputera, ale zanim dogrzebie się w kodzie i domyśle "co autor ma na myśli" to już 100 razy zwątpie

Buforowanie sprawdza się tylko wtedy, gdy masz paczki danych, albo dane nie lecą cały czas, bo jak sam zauważyłeś, kiedyś musi być czas na opróżnianie bufora.
A tak na marginesie, sprawdzałeś UARTa w STMie , w/g dokumentacji można go pędzić do 10.5Mbit/s

Sprawdzałem, sprawdzałem ale wyniki dt. prędkości trochę mnie ....zszokowały. Załóżmy że baud rate ustawiłem w programie na poziomie 9600 (w terminalu również) - "próbki" sobie śmigają tak, że otrzymuje kilaset bajtów na sekunde - pasuje. Ale jak zwiększałem BR (nawet do 250000) to nie widziałem żadnej różnicy w ilości przesłanych informacji. Zmieniałem wartość w tej linii:


Troszkę mnie zdziwił fakt, że USART może wyciągnąć 10.5Mbit/s, ale faktycznie zgodnie z notą katalogową STM32F303 wartości są zbliżone (stosunkowo ):

Ja patrzałem w F407 .

Rozumiem:)
Wiesz może dlaczego zmiana tych prędkości nie jest widoczna w terminalu ? Jedyne co przychodzi mi do głowy to to, że gdzieś w bibliotece USARTa trzeba dokonać dodatkowej modyfikacji, ale to było by bez sensu od strony użytecznej (bo po co wtedy linia z deklaracją w której wpisuje się wartość BR - patrz: wcześniejszy mój post).

Rozumiem, że mimo zwiększania prędkości samego UARTa, dane nie przyspieszają?, spróbuj na początek wysyłać coś z bufora bez pobierania pomiarów, może gdzieś masz jakieś opóźnienie. Chwilowo nie jestem nic więcej w stanie podpowiedzieć, bo za chudy w kapeluszu jestem na to.

Wczoraj przeprowadzałem takie proste próby o których wspomniałeś - wysyłałem np. tylko 0xFF (dec: 255) lub 0x0A (dec: 10). Zmiany w BR dawały bardzo słabą poprawę ilości odbieranych bajtów w ciągu sekundy (rzędu kilku dziesięciu bajtów - zmiana BR = 9600-256000).

To ewidentnie coś źle masz skonfigurowane, nawet na mega8 po uarcie śmigało mi na 200 kb.

Nie wiem już co jest... pewnie trzeba będzie grzebać w rejestrach.... Na chwile obecną uzyskuje "zabójcze" prędkości:
44 bajty na sekunde - przy BR=9600
201 bajt/sekunde - BR=128000

P.S.
rezasurmar korzystasz z bibliotek ST czy sam napisałeś procedury obsługi ?

Nie chce zaśmiecać forum,a trochę mnie to nurtuje mianowicie załóżmy, ze chciałbym wyzwalać przetwornik A/C za pomocą timer'a. Do tego celu (z tego co zrozumiałem z not i idąc śladem intuicji) służy następująca linia:

gdzie x to numer zdarzenia. Moje pytanie jest następujące: jaki numer wybrać jeśli chce wyzwalać timerem 1,2, itd. ? W nocie katalogowej ( http://www.st.com/st-web-ui/static/acti ... 068049.pdf ) nie ma nic o tym, które zdarzenie jest przypisane któremu timerowi.
Pozdrawiam.

P.S.
Znalazłem (po przeszukaniu dwóch manuali) i zostawiam w razie czego dla potomnych: