Wgrywanie wsadu do FPGA Lattice ice40 przez SPI z STM32 #2

Plik wsadowy .bin można też zamienić lokalnie na tablicę C w pliku nagłówkowym .h za pomocą aplikacji:

https://github.com/AntumDeluge/bin2header/releases/tag/v0.3.1

Odpowiednio ustawiając skrypty poprzedzające kompilację, możemy automatycznie dokonywać konwersji. Oczywiście to tylko przykład, wsad mikrokontroler może odbierać dynamicznie z innego źródła, np. USB. Jedynym ograniczeniem jest wtedy pamięć RAM, która musi zbuforować ciąg danych.

Skompensowana funkcja dokonująca programowania:

/*
* SPI has to be configured in range (1..25MHz)SCK Freq, 8-bit, MSB-first.
* CRESET_B, SS, - GPIO OUTPUT
* CDONE - GPIO INPUT 
* Returns: 0-programming failed; 1-programming successful
*/
uint8_t flash_fpga(SPI_HandleTypeDef *hspi, const uint8_t *bitstream){

uint8_t retval = 0;
const uint8_t zeroes[] = {0,0,0,0,0,0,0,0,0,0,0,0,0};
HAL_GPIO_WritePin(CRESET_B_GPIO_Port, CRESET_B_Pin, GPIO_PIN_RESET);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
HAL_Delay(1);
HAL_GPIO_WritePin(CRESET_B_GPIO_Port, CRESET_B_Pin, GPIO_PIN_SET);
HAL_Delay(2);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);
if(HAL_SPI_Transmit(hspi,(uint8_t *) zeroes, 1, HAL_MAX_DELAY) != HAL_OK) return 0;
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
if(HAL_SPI_Transmit(hspi,(uint8_t *) bitstream, sizeof(fpga_bin), HAL_MAX_DELAY) != HAL_OK) return 0;
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);
if(HAL_SPI_Transmit(hspi,(uint8_t *) zeroes, 13, HAL_MAX_DELAY) != HAL_OK) return 0;
retval = HAL_GPIO_ReadPin(CDONE_GPIO_Port, CDONE_Pin);
if(HAL_SPI_Transmit(hspi,(uint8_t *) zeroes, 7, HAL_MAX_DELAY) != HAL_OK) return 0;
return retval;
}

 

Toolchain FPGA

Pliki wsadowe można otrzymać również z darmowego toolchaina pod Linux. Ja sprawdziłem na maszynie wirtualnej z Lubuntu 22.

https://mcmayer.net/first-steps-with-the-icestorm-toolchain/

W tej linii dostosowałem swój układ FPGA:

arachne-pnr -d 384 -P qn32 -o build/blinky.asc -p blinky.pcf build/blinky.blif  


Mój plik Makefile:

all: build/blinky.bin
cp build/blinky.bin /media/sf_share/fpga.bin
python3 /media/sf_share/bin2header.py /media/sf_share/fpga.bin

build/blinky.bin: build/blinky.asc
icepack $< $@

build/blinky.asc: blinky.pcf build/blinky.blif
arachne-pnr -d 384 -P qn32 -o $@ -p $^

build/blinky.blif: blinky.v
yosys -p "synth_ice40 -top top -blif $@" $^

prog: build/blinky.bin
iceprog build/blinky.bin

clean:
rm build/*

.PHONY: prog clean

Timing

Czas programowania układu wynosi ok. 30 ms

Wgrywanie wsadu do FPGA Lattice ice40 przez SPI z STM32 #1

Opis

Układy FPGA firmy Lattice można skonfigurować poprzez interface SPI z poziomu podłączonego mikrokontrolera. Układ FPGA pracuje wtedy jako Slave, a mikrokontroler jako master magistrali. Wejście w ten tryb uzyskuje się przytrzymując linię SS w stanie niskim podczas wychodzenia z resetu kontrolera FPGA. Szczegóły opisuje dokument:

iCE40_Programming_Configuration_2022.pdf

Do układu wgrywamy wsad w postaci strumienia bajtów z pliku binarnego uzyskanego z procesu syntezy kodu VHDL/Verilog. Co ciekawe, plik binarny oprócz samej konfiguracji komórek programowalnych zawiera także metadane, które jednakże są ignorowane przez sam układ programowalny:

Zaznaczone bajty 0x7EAA997E są wzorcem synchronizacyjnym, po wykryciu którego układ zaczyna kolejne bajty interpretować jako użyteczne dane. Również na końcu ciągu znajduje się specjalna sekwencja 0x010600 sygnalizująca koniec strumienia (https://github.com/TiNredmc/OpeniCELink/blob/master/Core/Src/main.c).

Podobno można również zaprogramować FPGA na stałe, jednak datasheet nie ujawnia jak 🙁

Setup testowy

Kod

W STM32Cube został skonfigurowany interface SPI w trybie Master 2MHz MSB First na wybranych pinach + dodatkowe piny GPIO:

  • PA7 MOSI (SPI)
  • PA6 MISO (SPI)
  • PA11 SS (GPIO output)
  • PA12 CRESETB (GPIO output)
  • PA5 SCK (SPI)
  • PA4 CDONE (GPIO input)

Dodatkowo podczas dalszych prób wykorzystano kanał DMA do transferu strumienia danych.

Wsad z pliku .bin przekonwertowano jako tablicę bajtów w formacie języka C i umieszczono w kodzie programu. Do konwersji zostało użyte narzędzie https://notisrac.github.io/FileToCArray/

Co ciekawe, plik ma rozmiar 7413B, gdzie datasheet wpomina, że powinien mieć 7417B – skąd ta różnica 4 bajtów? Nie wiem, ale na razie działa 😉

 

Kluczowy kod (zakomentowane funkcje SPI niewykorzystujące DMA):

 const uint8_t zero = 0;
HAL_GPIO_WritePin(CRESET_B_GPIO_Port, CRESET_B_Pin, GPIO_PIN_RESET);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
HAL_Delay(1);
HAL_GPIO_WritePin(CRESET_B_GPIO_Port, CRESET_B_Pin, GPIO_PIN_SET);
HAL_Delay(2);
printf("FPGA in slave mode\r\n");
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);

//HAL_SPI_Transmit(&hspi1,(uint8_t *) &zero, 1, HAL_MAX_DELAY);
done = 0;
HAL_SPI_Transmit_DMA(&hspi1,(uint8_t *) &zero, 1);
while(done==0);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
//HAL_SPI_Transmit(&hspi1,(uint8_t *) not_gate_bitmap, sizeof(not_gate_bitmap), HAL_MAX_DELAY);
done = 0;
HAL_SPI_Transmit_DMA(&hspi1,(uint8_t *) not_gate_bitmap, sizeof(not_gate_bitmap));
while(done==0);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);

const uint8_t zeroes[] = {0,0,0,0,0,0,0,0,0,0,0,0,0};
//HAL_SPI_Transmit(&hspi1,(uint8_t *) zeroes, 13, HAL_MAX_DELAY);
done = 0;
HAL_SPI_Transmit_DMA(&hspi1,(uint8_t *) zeroes, 13);
while(done==0);
if(HAL_GPIO_ReadPin(CDONE_GPIO_Port, CDONE_Pin) == GPIO_PIN_SET){
printf("Programming succesful!\r\n");
}
else{
printf("Programming failed!\r\n");
}
//HAL_SPI_Transmit(&hspi1,(uint8_t *) zeroes, 7, HAL_MAX_DELAY);
done = 0;
HAL_SPI_Transmit_DMA(&hspi1,(uint8_t *) zeroes, 7);
while(done==0);
printf("Finished!\r\n");

Przebiegi

Można zauważyć podniesienie linii CRESETB przy opuszczonej linii SS, Sygnał SCK podczas transferu strumienia, podniesienie linii CDONE sygnalizującej przez układ FPGA poprawne skonfigurowanie, oraz dodatkowe stany na liniach wymagane przez dokumentację – chociaż nie wiem czy w praktyce niezbędne, skoro linia CDONE osiąga stan wysoki wcześniej.

WCH CH32V003 – RISC-V MCU – pierwsze kroki

Kupiłem:

1. Procek w obudowie so8 CH32V003J4M6 https://www.aliexpress.com/item/1005005143221495.html

2. Procek w obudowie so16 CH32V003A4M6

3. Programator WCH LinkE https://www.aliexpress.com/item/1005006295056343.html

Narzędzia:

1. https://www.wch.cn/downloads/WCH-LinkUtility_ZIP.html

2. https://www.wch.cn/products/WCH-Link.html

Pomocny opis: https://oshwlab.com/wagiminator/ch32v003j4m6-game-console


WCH-LinkUtility zagadał:

Trzeba było przestawić najpierw tryb z “ARM” na “RISC-V” wybierając z listy na dole “WCH-LinkRV”.


IDE

Trzeba zainstalować wersję “MounRiver_Studio_Setup”, nie “Community”.

Po instalacji ustawić generowanie plików hex oraz bin:


Jeżeli procesor zachowuje się jakby “zdechł”, “uceglił się”, należy wybrać:

Przykładowy “blink” na pinie PA2:

Pobór prądu: 1,8 mA @ 3,3V @ 8 MHz HSI. Brak obciążonych GPIO, pracujący TIM1 w trybie PWM na prescalerze=0. + prosty kod w pętli main.

Microstrip bandpass filter – wykonanie i pomiary

Serdeczne podziękowania dla mgr inż. Piotra Kwiatkowskiego, za wykonanie pomiarów na profesjonalnym analizatorze wektorowym.

Filtr projektowany na pasmo 434 MHz (420..470 MHz) wg kalkulatora jak niżej:

Płytkę zaprojektowałem w Eagle, rysując bez schematu struktury mikropaskowe. Płytka 4-warstwowa, na zwykłym laminacie FR-4. Wykonana w JLCPCB.

Wyniki pomiarów pierwszej wersji:

Jak widać, pasmo przepustowe w zakresie -3db trafiło na zakres 373..430 MHz przy szczycie na 402 MHz – czyli na sporo niższe częstotliwości, niż pierwotnie zakładane.

Pomiary analizatorem wektorowym:

Faza_S21
Faza_S21
Tlumienie_S21_2
Tlumienie_S21_2
Faza_S21_2
Faza_S21_2
S11
S11
S22
S22
Tlumienie_S21
Tlumienie_S21

Na podstawie powyższych wyników, przyjąłem “na oko” proporcjonalną poprawkę na częstotliwości. Wiadomo – krótsze elementy – wyższa częstotliwość.

Ponownie użyłem kalkulatora, ze zmodyfikowanymi parametrami:

Płytka wykonana jak poprzednio. Tym razem pasmo zmierzone analizatorem widma z generatorem śledzącym:

Pasmo nieco szersze niż zakładane, ale trafione w oczekiwany zakres: 406 .. 486 MHz ze środkiem w 446 MHz.

Jak widać, filtr niestety w paśmie przepustowym nadal celuje się względnie dużym tłumieniem na poziomie -6,5 dB. Nie wiem, czy wynika to z kiepskiego dopasowania, stratności w laminacie FR-4 czy ogólnie z nie najlepszej topologii.
Pomiary analizatorem wektorowym:

Faza_S21-1
Faza_S21-1
Faza_S21_2-1
Faza_S21_2-1
S11-1
S11-1
S22-1
S22-1
Tlumienie_S21-1
Tlumienie_S21-1
Tlumienie_S21_2-1
Tlumienie_S21_2-1

Budowa i pomiary transformatora izolacyjnego do pomiarów Bode

Podziękowania za wsparcie w realizacji oraz konsultacje dla inż. Michała Karasia – eksperta w zakresie badań obwodów i stabilności.

Inspiracja: https://electronicprojectsforfun.wordpress.com/injection-transformers/

Materiały:

  • 2x rdzenie VAC T60006-L2030-W514
  • Para skrętki pozyskana z kabla Ethernet BitLAN 2x23AWG (użyta długość poniżej 3m, z wyliczeń ok. 95mmb/zwój)

25 uzwojeń nawiniętych bifilarnie na 2 połączone rdzenie (sklejone dla wygody nawijania)

Zgrubne pomiary przy użyciu “testera tranzystorów” dały wyniki ok. 60 mH dla każdego z uzwojeń. Po zwarciu przeciwnego uzwojenia, miernik nie był w stanie określić indukcyjności, co sugeruje wysoki współczynnik sprzężenia (coupling factor), oceniam na powyżej 0,99.

Wyniki pomiaru charakterystyki w zakresie 10Hz – 25 MHz:

vac0.csv

Wykres przy użyciu Python+Matplotlib (pominięte ostatnie próbki które “leciały w kosmos”, dla czytelności skali):

vac0parsed.csv

python.zip

Dla ok. 6-7 MHz amplituda “ucieka” na +3dB, czyli tutaj można uznać koniec sensownego pasma transformatora.

Całe pasmo jest bardzo liniowe. Z jakiegoś powodu jednak Rigol jest upierdliwy w pomiarach – trwają bardzo długo, i nieraz trzeba je powtarzać, bo pojawiają się losowe zakłócenia.

Zdjęcie stanowiska pomiarowego:

Risetime oscyloskopów

Użyte źródło impulsów: Generator PSG-1 zaproponowany przez Jima Williamsa (Linera Technology): https://www.elektroda.pl/rtvforum/viewtopic.php?p=15023133#15023133

an47fa.pdf

Rigol MSO5074:

Rigol DHO914S (za pomiary i zgodę na publikację serdeczne podziękowania dla Pana Inż. Michała Karasia):

Dla porównania wyniki z oscyloskopu R&S RTP164B o paśmie 16GHz i 40GSa/s:

Wyniki w Postaci tabelarycznej:

Oscyloskop
Wynik
R&S RTP164B pasmo 16 GHz
207 ps
Rigol MSO5074 pasmo 350 MHz
700 ps
Rigol DHO914S pasmo 250 MHz
1180 ps

FFT a pozycje czasowe przebiegów

Wg teorii transformata Fouriera jest operacją odwracalną i bezstratną. To znaczy, że znając widmo sygnału jesteśmy w stanie odtworzyć dokładnie jego postać czasową.

Jednak widmo składa się również z części fazowej, niezależnie czy jest reprezentowane w postaci algebraicznej, zespolonej czy wykładniczej (w sumie to to samo co postać zespolona). Czy jednak samo widmo amplitudowe będzie się różnić, gdy składowe sygnału będą pojawiać się w różnych odstępach czasowych?

Chciałem sprawdzić empirycznie, jak to wygląda. Wygenerowałem 2 czyste przebiegi sinusoidalne, dla ustalenia uwagi 1 i 2 MHz.

W pierwszym przypadku obydwa sygnały pojawiają się w tym samym momencie. W drugim, pojawia się najpierw jeden, potem drugi.

Pozostałe parametry nie zmieniają się: czas próbkowania (trwania sygnału), amplitudy, fazy początkowe, czasy trwania każdego sygnału składowego.

Tak wygląda przygotowana przeze mnie symulacja w Qspice (duchowy następca LTspice):

Tak przebiegi czasowe opisane powyżej:

A tak FFT z tych przebiegów:

Jeżeli dobrze rozumiem, przebiegi prezentują jedynie część amplitudową widma. Jak widać, przebiegi są praktycznie identyczne.

Pomiary prądu pompy hydroforowej

Wykonałem pomiary oscyloskopowe poboru prądu przez silnik pompy hydroforowej, który posiadam w domu:

Znamionowa moc silnika 1f to 1,1 kW.

Pomiary wykonałem używając przekładnika prądowego 50A/1V SCT013 www.yhdc.com:

Na początek, w celu zweryfikowania wartości pomiaru, zmierzyłem pobór prądu gofrownicy o mocy 1200 W, jako czysto rezystancyjnego obciążenia:

Napięcie wyniosło ok. 100 mV RMS, co odpowiada ok. 5 A RMS. 1200W / 230 V = 5,2 A. Wpięty szeregowo (chiński) wskaźnik prądu pokazał 4,9V. Zakładam więc, że przekładnik wskazuje poprawnie z dokładnością 20 %. Na chwilę obecną nie mam jak wykonać wzorcowania.

Czyli przelicznik : 1 mV -> 50 mA

A teraz zasadnicze pomiary:

Rozruch silnika trwa około 300 ms, i Irms = 473 mV RMS / 1.41 * 50 = 16,8 A.

Daje to udar o mocy około 3860 VA.

W czasie zasadniczej pracy pompy pobór prądu wynosi 83 * 0.05 =4.15 A i odpowiada to ok 955 VA mocy przy napięciu 230 V rms.

Nie mierzyłem dokładnie wartości napięcia sieci, ale wskaźnik na testerze pokazywał ok 227 V, czyli bardzo zbliżona wartość do znamionowych 230 V.

Dla jasności, nie mierzyłem tutaj mocy rzeczywistej, a pozorną. Natomiast silnik wykonywał pracę pompując wodę, więc zakładam dosyć dobry współczynnik mocy (bliski 1.0). Nie ma to w sumie znaczenia, bo moc pozorna jest bardziej adekwatną wartością do doboru awaryjnego źródła zasilania.

Chcąc wykorzystać UPS na pewno jego moc pozorna musi być powyżej 1000 VA. Przydałoby się sprawdzić wykorzystanie układu soft-start. Bez niego UPS musiałby wytrzymywać udary na poziomie 4000 VA.