Generator sygnałów z zadawaniem parametrów z komputera

Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Mikrokontrolery ARM
Generator sygnałów z zadawaniem parametrów z komputera
Jakub Janeczko ([email protected])
Prowadzący przedmiot: dr inż. Mariusz Suchenek
Semestr 2016L
1 Wstęp
Tematem projektu jest generator sygnałów z możliwością zadawania parametrów z urzyciem
komputera. W poprzednim semestrze (2015Z) projekt o tym samym temacie był realizowany przez
Macieja Rzepińskiego. Aby nie powielać tej samej pracy postanowiłem zmodyfikować istniejący
projekt i rozwinąć go w kierunku generatora DDS (direct digital synthesis).
Celem mojego projektu jest zrealizowanie dwukanałowego generator DDS programowalnego
dynamicznie przez sieć (poprzez Ethernet).
2 Ogólna zasada działania
Na urządzeniu będzie uruchomiony serwer, który po podłączeniu kabla rozpoczyna nasłuchiwanie na z
góry ustalonym porcie. Po nawiązaniu połączenia urządzenie będzie oczekiwać na konfigurację pracy.
Konfiguracja będzie zawierać:
•
numer kanału do konfiguracji
•
częstotliwość próbkowania (częstotliwość zmiany na kolejną próbkę)
•
tablica próbek
•
sumę kontrolną/hash przesłanych danych
Pierwszą czynnością po odebraniu konfiguracji będzie weryfikacja jej integralności poprzez
sprawdzenie sumy kontrlolnej/hash-u. Następnie należy skonfigurować DAC i kontroler DMA i
rozpocząć generację próbek.
Próbki będą kopionowane z pamięci RAM do przetwornika DAC przy użyciu kontrolera DMA aby
odciążyć procesor. Aby efektywniek wykorzystać szynę APB1, do której podłączony jest konwerter
DAC możliwe będzie urzycie trybu dual DAC (jedna operacja kopiowania dla dwóch kanałów
jednocześnie).
Do realizacji projektu zamierzam urzyć zestawu STM32F4DISCOVERY z procesorem
STM32F407VGT6, ponieważ posiada on dwukanałowy konwerter cyfrowo-analogowy (DAC) oraz
zestawu STM32F4DIS-BB do komunikacji poprzez Ethernet.
3 Opis
Jako punkt początkowy użyłem przykładu tcp_echo serwera dostarczonego przez ST. Echo serwer
został przerobiony tak aby odbierać konfiguracyjną ramkę konfiguracyjną oraz została dodana obsługa
konwersji C/A. Do budowy projektu używam środowiska EWARM. Próby z użyciem kompilatora
GCC nie zakończyły się na razie powodzeniem.
Oprogramowanie sentyzatora można podzielić na dwie funkcjonalne części: serwer (dds_server.c) i
aplikacja (dds.c). Zadaniem serwera jest odebranie kompletnej ramki konfiguracyjnej i przekazanie jej
do części aplikacyjnej. Serwer może znajdować się w trzech satnach:
1. DS_IDLE – bezczynny, żaden klient nie jest połączony z serwerem.
2. DS_HEADER – oczekiwanie na nagłówek ramki. Serwer przechodzi do tego stanu gdy klient
połączy się z nim. Najistotniejszą daną dla serwera jest wielkość całej ramki danych, która jest
zawarta w nagłówku, dzięki niej będzie mógł sprawdzić czy ma wystarczającą ilośc pamięci na
przechowanie wszystkich danych. Po pobraniu nagłówka serwer przechodzi w stan
DS_RECEIVING.
3. DS_RECEIVING – serwer odbiera pozostałe dane. Gdy odbierze co najmniej tyle danych ile
zostało podane w nagłówku, przekazuje je do części alikacyjnej.
Część aplikacyjna zawiera funkcje:
1. DDS_Init – do inicjalizacji wszystkich peryferiów potrzebnych do realizacji DDS.
2. DDS_Start – która konfiguruje odpowiednie peryferia na podstawie kompletnej ramki danych i
rozpoczyna konweresje C/A.
3. DDS_Stop – zatrzymanie konwersji.
Urządzenie (aplikacja) może działać w trzech trybach
1. niezależnym (independent) – każdy z kanałów jest wyzwalany odzielnym timerem, używane są
różne kanały DMA
2. pojedynczy wyzwalacz (single trigger) – każdy z kanaów wyzwalany jest z tego samego timera,
różne kanały DMA.
3. podwójny (dual) – dwa kanały są wyzwalane z tego samego timera, muszą mieć taką samą ilość
próbek, używany jest jeden kanal DMA oraz dane dostarczone muszą być w formacie
podwójnym (na zmiane).
Urądzenie sygnalizuje swój stan także poprzez diody LED
1. niebieska – świeci się podczas aktywnego połączenia TCP (da się zobaczeć).
2. zielona – dioda konwersji C/A, gaśnie i zapala się naprzemiennie, zmienia swój stan gdy
wszyskie próbki zostały przekonwertowane i rozpoczyna się konwersja od początku.
3. czerwona – błąd protokołu dds_serwera
4. pomarańczowa – błąd (niepoprawność) danych dostarczonych do aplikacji
Ramka danych - nagłówek
Nazwa
Typ
Opis
magic
char[4]
4 chary tworzące napis „MARM”. Sygnaizacja
początku ramki
checksum
uint32_t
Skrót/suma kontrolna danych. Ma nacelu
upewnienie się, że klient wysyła poprawne dane
tworzące ramkę konfiguracyjną. Nie trzeba
sprawdzać czy nastąpiło przekłamanie w
procesie transmisji – to weryfikowane jest na
poziomie protokołu.
size
uint32_t
Wielkość całej ramki danych
mode
uint8_t
Tryb działania, jeden z independent, sigle trigger
i dual
ch
dds_chconfig[2] Konfiguracja kanałów
data
void[0]
Początek danych zawierających próbki
Ramka danych – dds_chconfig – konfiguracja kanału
Nazwa
Typ
Opis
enabled
uint8_t
1 – kanał włączony, 0 - wyłączony
data_format uint8_t
Format danych, jeden z DDS_FORMAT_8bit,
DDS_FORMAT_12bit_LEFT,
DDS_FORMAT_12bit_RIGHT
data_offset uint32_t
Przesunięcie początka danych dla kanału,
liczone od dds_header->data
data_size
uint32_t
Rozmiar wszystkich próbek dla danego kanału
period
uint32_t
Period timera
prescaler
uint16_t
Prescaler timera
Odpowiedzi zwracane przez serwer
Nazwa
Opis
OK
Ok
Invalid header
Niepoprawny nagłówek, nie rozpoczyna się od „MARM”
Invalid checksum
Niepoprawna suma kontrolna
Invalid data
Niepoprawny format danych
Invalid configuration Nieprawidłowa konfoguracja
No enough memory Brak pamięci
timeout
Po 30 sekundach oczekiwania na dane, serwer rozłączy
się automatycznie
W trybie single trigger ustawienia timera dla drugiego kanału są ignorowane. W trybie dual, cały
deskryptor drugiego kanału jest ignorowany.
DDS klent
Częścią projektu jest także aplikacja kliencka (napisana w Pythonie) uruchamiana na komputerze,
której zadaniem jest stworzenie poprawnej ramki konfiguracyjne i wysłanie do serwera DDS (na porcie
1234).
4 Implementacja
Projekt został wstępnie zaimplementowany, brakuje opcji liczenia sumy kontrolnej, weryfikacji
poprawności formatu danych (próbek) i konfiguracji. Aktualny stan projektu przedstawia się
następująco. Serwer działa poprawnie odbiera i przekazuje dane (zweryfikowane za pomocą debuggera
EWARM), widać zapaljącą się na chwile diodę niebieską. Natomiast konwersja C/A nie rusza.
Najprawdopodobniej niepoprawnie skonfigurowane timery i/lub DMA.
Niestety brakuje czasu na dopracowanie projektu, dlatego wysyłam projekt w takim stanie.
Kod projektu znajduje się tutaj: https://github.com/yay6/dds_marm
5 Możliwe modyfikacje
Dodatkowe funkcje jakie mogą być dodane do projektu to:
1. dodawanie próbek pośrednich między zapisanymi w RAM-ie np. poprzez liniową
aproksymacje. Dzięki temu można zmniejszyć tablice próbek dla niektórych przebiegów.
2. Użycie karty SD do przechowywania próbek lub/i do zapamiętyania stanu między odłączeniami
zasilania.
6 Schemat połączeń
STM32F407VGT6
LAN8720
PB11
TXEN
PB12
TXD0
PB13
TXD1
PC4
RXD0/MODE0
PC5
RXD1/MODE1
PA7
CRS_DV/MODE2
PA2
MDIO
PC1
MDC
PA1
NINT/REFCLKO
PE2
NRST
STM32F407VGT6
PA4/DAC_OUT1
Wyjście – kanał 1
PA5/DAC_OUT2
Wyjście – kanał 2
PA0
Synchronizacja