Kilka informacji na temat mojej walki z 320x170:
od samego początku stało się jasne, że należy zmniejszyć głębię koloru z 16 do 8 bitów - w rp2350 brakowało RAM-u na tak dużego sprite'a w 16 bitach. Po dokonaniu kilku poprawek firmware ruszył bez artefaktów na wodospadzie, ale pojawił się nowy problem - po kilku minutach pojawiał się wyraźny jitter w dźwięku i na wykresie, obciążenie CPU spadało z ok. 70% do ok. 50% i audio/wodospad zatrzymywały się, choć menu nadal działało i poprzez np. zmianę poziomu redukcji szumów dawało się na chwilę uruchomić radio (najpewniej padała FFT). W skrajnych przypadkach obciążenie CPU spadało do 1% i następowało kompletne zawieszenie systemu.
Wskazówkę otrzymałem na YT od UD3SBV, który mocno "zremiksował" projekt Iana - należało jeszcze przetaktować CPU.
W tej chwili moja wersja pracuje z zegarem 304 320* zamiast 240 MHz, co dało CPU Load na poziomie <60% i całkowitą stabilność. Zegar SPI podniosłem z 20 MHz do 40MHz uzyskując znacznie lepszą płynność odświeżania LCD.
Problemem w rozbudowie firmware o nowe funkcje okazuje się nie brak pamięci flash, a RAM-u rp2350, w którym trzymane są rzeczy niezbędne dla FFT i DSP oraz bufor LCD. Aż korci, żeby przejść z buforowania całego obszaru wyświetlacza na buforowanie jedynie dynamicznie zmieniających się obszarów, a wszystkie statyczne elementy pisać bezpośrednio do jego RAM-u. Zdaje się, że można też zmniejszyć głębię koloru do 4 bitów, co wymagałoby dodatkowo zmapowania 16 kolorów z dostępnej palety. Obawiam się jednak, ze to zadanie mnie przerasta, bo ja grzebię w kodzie jak kura pazurem i patrzę, co wylezie na wierzch...
* 304 MHz dawało zakłócenia od SPI w pasmie 20m. 320 MHz przesunęło je poza pasma amatorskie.
od samego początku stało się jasne, że należy zmniejszyć głębię koloru z 16 do 8 bitów - w rp2350 brakowało RAM-u na tak dużego sprite'a w 16 bitach. Po dokonaniu kilku poprawek firmware ruszył bez artefaktów na wodospadzie, ale pojawił się nowy problem - po kilku minutach pojawiał się wyraźny jitter w dźwięku i na wykresie, obciążenie CPU spadało z ok. 70% do ok. 50% i audio/wodospad zatrzymywały się, choć menu nadal działało i poprzez np. zmianę poziomu redukcji szumów dawało się na chwilę uruchomić radio (najpewniej padała FFT). W skrajnych przypadkach obciążenie CPU spadało do 1% i następowało kompletne zawieszenie systemu.
Wskazówkę otrzymałem na YT od UD3SBV, który mocno "zremiksował" projekt Iana - należało jeszcze przetaktować CPU.
W tej chwili moja wersja pracuje z zegarem 304 320* zamiast 240 MHz, co dało CPU Load na poziomie <60% i całkowitą stabilność. Zegar SPI podniosłem z 20 MHz do 40MHz uzyskując znacznie lepszą płynność odświeżania LCD.
Problemem w rozbudowie firmware o nowe funkcje okazuje się nie brak pamięci flash, a RAM-u rp2350, w którym trzymane są rzeczy niezbędne dla FFT i DSP oraz bufor LCD. Aż korci, żeby przejść z buforowania całego obszaru wyświetlacza na buforowanie jedynie dynamicznie zmieniających się obszarów, a wszystkie statyczne elementy pisać bezpośrednio do jego RAM-u. Zdaje się, że można też zmniejszyć głębię koloru do 4 bitów, co wymagałoby dodatkowo zmapowania 16 kolorów z dostępnej palety. Obawiam się jednak, ze to zadanie mnie przerasta, bo ja grzebię w kodzie jak kura pazurem i patrzę, co wylezie na wierzch...
* 304 MHz dawało zakłócenia od SPI w pasmie 20m. 320 MHz przesunęło je poza pasma amatorskie.
Łukasz, Warszawa - FT991, TRX Brass (w budowie), Joker SDR (w głowie) i trochę chińszczyzny dla smaku.