MBTRX by VK7IAN

[SP9FKP]

Nawinąłem filtry dolnoprzepustowe. Kondensatory wg dokumentacji, sprawdzone (trochę bez sensu bo z taśmy) na zgodność z tolerancją, trzymają fason. Cewki na rdzeniach T37-6 wg opisu i również sprawdzone za pomocą NanoVNA. Na zakresie 40/30m o jeden zwój mniej, nie mam pojęcia dlaczego tak. Do pomiaru musiałem wylutować kondensator C46. Wyniki poniżej tak jak wyszło, bez dobierania.

[SP5LU]

   
Pierwsze uruchomienie makiety z TFT na ST7789 320x170 (jak w Jokerze) - nawet coś widać

[SP9FKP]

Gratuluję Łukasz, mam nadzieję na dalszy ciąg. Mam sygnały od kolegów o różnym stopniu zaawansowania produkcji PCB. Zapewne niebawem będą w kraju i staną się dostępne.

[SP5LU]

Jeśli znajdzie się jakaś wolna płytka, to ja bardzo chętnie się podłączę.

W międzyczasie spróbowałem wykorzystać całą powierzchnię wyświetlacza. Dla programisty może byłoby to łatwe... Początkowo udawało się nieznacznie powiększyć x i y, ale po przekroczeniu pewnych wartości wyświetlacz nie uruchamiał się. Okazało się, że firmware wykorzystuje funkcję sprite do budowania całego obrazu zamiast wyłącznie ruchomych i często modyfikowanych obszarów. Bufor obrazu wykorzystuje oczywiście pamięć RAM procesora - przy wyświetlaczu 240x135 jest to 32400 pikseli, przy 320x170 to już 54400 px, więc prawie 2 razy więcej... Rozwiązaniem było znalezienie informacji, że domyślnie biblioteka tft-espi domyślnie pracuje w 16 bitach głębi koloru, więc w pierwszym przypadku rezerwuje 64.8kB, a w drugim usiłuje zarezerwować 108.8kB - i to już jest za dużo. Kompilacja przechodzi bez błędów, ale nie działa... ech Arduino Arduino...

Po jawnym zadeklarowaniu głębi ośmiobitowej 

Kod:

  tft.displayOn();
 
  lcd.setColorDepth(8);
 
  lcd.createSprite(LCD_WIDTH, LCD_HEIGHT);

działa cały wyświetlacz.

Sukces jest jednak tylko częściowy - przy kompilacji z zalecanym przez autora poziomem optymalizacji -O3 na ekranie pojawiają się ruchome artefakty. 
   
Przełączenie na poziom standardowy -Os poprawia sytuację, ale nadal nie jest dobrze. 
   
Obawiam się, że nie starczy mi samozaparcia i skończy się na wyświetlaczu 240x135, a szkoda, bo bardzo lubię ten 320x170.

Edit - jak widać przy zabawach z rozdzielczością wyszło, że autor niespecjalnie dba o spójność kodu - niektóre elementy (spektrum i wodospad) dostosowały się wraz z opisami do deklaracji 

Kod:

#define LCD_WIDTH         320

 
(co jest tam wyświetlane, to inna sprawa), a współrzędne innych są hardkodowane. Pocieszające jest to, że dało się zwiększyć wysokość wodospadu i to działa.

Kod:

#define WATERFALL_ROWS 96
// 61 for 240x135

[SP9FKP]

Koledzy, kto odstąpi Łukaszowi płytkę? Warto zainwestować w jego zapał!
Wydawało mi się, że dam radę wlutować dławiki 1812 w miejsce 1206 ale przy tak gęstym upakowaniu poległem. Niestety, zdobycie odpowiednich wartości w tym rozmiarze (1206) okazało się dla mnie trudniejsze niż się spodziewałem. W sumie jakoś zmordowałem a oto wyniki pomiarów.  I tak jak ostatnio, tak jak wyszły bez dobierania.
       
       
       
       

Jak widać, nie są to optymalne wyniki, trudno zgadnąć czy to wyniki rozrzutu parametrów czy błąd w projekcie. Na pewno wymaga to poprawy. Nie mniej kolejny krok do pełnego uruchomienia.

[SP5LU]

Zajrzyj do dokumentu Joker_13 - tam jest opisany chyba podobny problem z filtrami.

***

Prawdziwi twardziele nie czytają ostrzeżeń kompilatora ))
Jeśli się puszcza pętlę, która ma zrobić 320 obrotów na ośmiobitowym liczniku, a do tego sztywno deklaruje za krótką tablicę (dla 4*240px wystarczały 1024 elementy, dla 4x320px już nie), to efekty są jakie są.

Teraz już jest wyraźnie lepiej, ale bez działającego Rx'a nie mogę weryfikować dalszych poprawek - więc na razie odpuszczam temat.