STM32 - [C] Odczyt danych szeregowych (nie UART)

Cześć

Próbuję połączyć enkoder absolutny Fanuca do STM32F373. Problemem jest dla mnie odbiór danych z enkodera, ze względu na to iż przesyła on dane szeregowo, asynchronicznie z prędkością 1 Mbps. Ramka zaczyna się od bitu startu, a następnie 76 bitów danych jednym ciągiem. Próbowałem użyć UART, ale bezskutecznie - UART wymaga co 8 lub 9 bitów bitu startu. Próba programowego odbioru danych póki co też mi nie wychodzi ze względu na brak możliwości uzyskania stabilnego czasowo wyzwalania co 1us, które próbowałem realizować i timerami i pętlami, ale wygląda na to że pomimo zastosowania zegara 64MHz bardzo trudno jest zdążyć zapisać dane, przejść pętlę FOR odliczającą bity i sprawdzić ponownie stan linii danych.

Macie może jakieś inne pomysły na realizację odczytu takich danych?

Pozdrawiam

Użyj SPI, wyzwalanego ręcznie lub przez przerwanie EXTI. Do pinu SCLK SPI podłącz wyjście timera na którym będziesz generował wymagany zegar 1MHz.

To się raczej nie uda przy braku transmisji zegara przez źródło danych. Ja bym popędził SPI na częstotliwości nieco powyżej 3 MHz, zrobił odbiór na DMA i programowo analizował odebrany strumień bitów. Wtedy nie trzeba generować zegar przez timer, co grozi błędną synchronizacją.

Ew. można pomyśleć o włączaniu timera generującego zegar dla SPI przez bit startu np. przez inny timer w trybie capture i DMA, a na szybszym uC (np. F4) może nawet w przerwaniu.

To jest Pulsecoder Fanuc αi128, wg informacji od producenta jest to enkoder absolutny, przy czym absolutna pozycja realizowana jest przez elektronikę, z rodzielczością 32000000/obr.

Jutro będę kombinował z SPI to dam znać co udało mi się uzyskać

Odbiór 77 bitów bez jakiejkolwiek synchronizacji ogólnie może być problemem niezależnie od metody przechwytywania danych. Jak dla mnie to trochę dziwny jest ten format transmisji. @korneliusz możesz wstawić tutaj jakąś dokumentację, chociaż część odpowiadającą za transmisję? Co w tych 76 bitach jest zawarte? Jest jakaś suma kontrolna?

Dokumentacji nie mam, próbuję go obsłużyć posługując się informacjami m.in. stąd: http://www.cnczone.com/forums/fanuc/127192-need-serial-pulse-coder-info.html

Na razie po wystawieniu impulsu 8us na oscyloskopie widać że enkoder zwraca 77bitów danych, które zmieniają się w zależności od położenia osi, na żadnym z pozostałych pinów wyjściowych enkodera nie pojawia się żaden sygnał zegarowy.

Poniżej cytat opisu ramki z forum CNCzone

Quote:

Bit # Function
0 1 encoder ID
1 0 encoder ID
2 1 encoder ID
3-7 ? 0 encoder ID ?
8 1 = encoder not indexed
. 0 = index located
9-17 0 possibly lowest order bits of higher res encoder
18-31 angular count for 1/4 turn (14 bits)
32-33 0
34-35 angular quadrant count
36 0
37-51 signed count of rotations (15 bits)
52 1
53 0
54-63 low-res position count (10 bits)
64-68 0
69-70 11 (two one's)
71-75 checksum

Znalazłem tą dyskusję. Z tego co widziałem to tam ktoś zaprzągł do tego FPGA, no ale to może być trochę na wyrost. Dobrze, że w tych danych jest suma kontrolna, pozwoli to na weryfikację odebranych danych. Jakby do tego tematu nie podchodzić to jest potrzebne precyzyjne źródło zegara 1.024Mhz pozwalające na idealne samplowanie w czasie. W najprostszej wersji trzeba wykryć start, odczekać pół bitu i rozpocząć samplowanie. Samplowanie z wyższymi częstotliwościami nie wiele tu da, bo analiza samplowanych danych ma dużą szansę wyłożyć się na ciągu takich samych bitów. Według mnie potrzebny jest tutaj sprzętowy mechanizm synchronizujący samplowanie, który będzie synchronizował do każdego zbocza w strumieniu danych. Nie wiem, może się mylę, może aż takie kroki nie są potrzebne, ale na pewno łatwo nie będzie. Osobiście próbowałbym to zrobić na innym uC( np LPC15xx ) w oparciu o SCT+SPI+DMA.

Może użyć DMA i Timera w trybie capture. Transmisje DMA wyzwalać synchronicznie drugim timerem.

Piotr Piechota wrote:

Może użyć DMA i Timera w trybie capture. Transmisje DMA wyzwalać synchronicznie drugim timerem.

Mógłbyś rozwinąć?

Co do stabilnego źródła zegarowego zamówiłem właśnie rezonator 16,384MHz, powinien on w przybliżeniu umożliwić próbkowanie z częstotliwością 1,024MHz, więc może wystarczy to i nie będę gubił synchronizacji. Poza tym nie będzie dla mnie problemem jeśli co któraś ramka będzie błędna, w swojej aplikacji spokojnie będę miał czas ponowić odczyt.