[oscarX]

Jak wspomniałem w innym poście, rozpocząłem zabawę z prockami STM32. Po jakiś prostych próbach z miganiem LEdami, chciałem zrobić coś bardziej złożonego. Postanowiłem zbudować "symulator" komputerka ZX Spectrum. Kupiłem płytkę  - klon BlackPill - z prockiem STM32F401 (64kB RAM). Jako ekran planuje wykorzystać wyświetlacz LCD 320x240 na kontrolerze ILI9341. Wyświetlacz wypróbowałem podłaczając do FTDI232 i sterując z PC, potem podłączyłem do GPIO malinki i też działał. Przygotowałem projekt na STM pod arduino - jest biblioteka do tego wyświetlacza, jest emulator Z80, w zasadzie wystarczy. Projekt skonfigurowany do używania USB jako seriala - pod podłączeniu do kompa pojawia się port szeregowy. Próba szybkości wykazała, że można przesyłać 500kB/s tym "serialem". Wszystko działało na prostych, próbnych, fragmentarycznych projektach. Ale jak zebralem wszystko do kupy dostałem kod wynikowy wielkości 80kB (zawiera kopię oryginalnego ROMu ZX Spectrum). I pomimo, że kod na razie nic takiego nie robi mam kłopoty z USB - pod podłączeniu do kompa często nie zgłasza się "serial", komputer zgłasza jakieś błedy USB. Podejrzewam, że ten procek jest jakoś oszukany, jak to chińczycy potrafią, realnie ma mniej pamięci flash i RAM niż wynikałoby z typu.
Czy można jakoś sprawdzić typ (pewnie jakiś rejestr ID - ale to też może być oszukane) oraz wielkość pamięci - najlepiej poprzez testy. Identyczne problemy mam na płytce z STMF411 - która powinna mieć 512KB flash i 128kB RAM. Może USB działa trochę źle jak procek jest znacznie obciążony? Bo zwykle bootowanie po USB (jak się przytrzyma klawisz w trakcie zerowania - układ po USB zgłasza się inaczej) działa - a wtedy aplikacja użytkownika nie działa.

[kaczakat]

Jak sam składasz wsad to różnie może być, podróba też jest możliwa. Może jest jakiś gotowiec do wgrania, potwierdzony, że działa na oryginalnych prockach. Może nawet nie ten projekt ZX, ale jakiś bardziej rozbudowany, który wymaga więcej flash i ram. Może kup w renomowanym sklepie, TME czy Farnell, które biorą chipy i płytki prototypowe z autoryzowanych źródeł. Mam mnóstwo płytek z Ali, ale tylko migam ledami, więc nic niepokojącego nie zauważyłem.
Natomiast dziwne zachowanie USB i owszem, ale dla RP PICO W i też na prostym programiku, płytka pewna z Farnell, jest to dystrybutor Raspberry, w W10 działa jak bozia przykazała, a w W7 gdzie miałem problemy z driverami i trochę mieszałem, na dwóch komputerach nie działa coś innego.
A podróba to jest na pewno, przecież nie dałoby się sprzedać czegoś za 1.5$ (blue pill) gdzie u producenta procek jest droższy, tylko że czasami wsadzali chip 32kb ze zmienioną sygnaturą (czy 64 zamiast 128), bo przecież programator wykrywa prawidłowo model jak sprzedany, naniesione nowe oznaczenie i cyk 2$ więcej - ale dalej taniej niż takie same procki STM w hurcie.
https://sklep.msalamon.pl/produkt/plytka...2f103c8t6/ tu piszą o takich problemach z USB.

[oscarX]

Swoje moduły kupowałem od msalomona, co prawda na allegro ale od tego sprzedawcy.
Mam taki pomysł - utworze prosty projekt z dużą tablicą const (wtedy zostaje we FLASH) zainicjowaną zawartością pliku (bin2c) i oblicze jej jakąś sume kontrolną np. MD5 i porównam z oryginałem obliczonym na PC. A potem podobnie z tablicą bez const - czyli skopiowaną do RAM. Na razie kod na ponad 90% pojemności flash działa. Na razie jadę na bluepill - on ma fizyczny serial, bez USB. Potem blackpill - z większą tablicą) - po prostu większy plik do zamiany na tablicę.

[kaczakat]

No to nie spodziewał bym się tam oryginałów uC, skoro wiedzą, że mają takie źródło, że muszą testować, czy aby nie jest to totalny odpad. Co nie znaczy, że nie mogą działać prawidłowo.
Oryginalne płytki w miarę fajnych cenach to Nucleo, był taki okres, że na ali były droższe niż w sklepach UE, no i to było zrozumiałe, musieli je ściągnąć z oryginalnej fabryki i wysyłać na Zachód, gdzie w tym czasie sklepy w UE miały mocno promować alternatywę oryginalnych płytek Arduino na koszt producenta.
A co do blue pill, to one mają przecież USB, używałem taki core w Arduino, gdzie wybierałem maple mini, 120kB flash, wgrywałem bootloader generic_boot20_pc13.bin przez STlink i pierwszy SERIAL to był przez USB właśnie. Core się ściągało jako zwykły zip i wgrywało do katalogu /Arduino/hardware/, tam gdzie projekty.
W tym core bardziej popularnym miałem właśnie problem z USB, a ten obsługuje też Blackpill STM32F401CCU6
https://github.com/rogerclarkmelbourne/Arduino_STM32
Trudno mi powiedzieć, czy to ten core, takich "nieinstalowalnych" z managera kojarzę też kilka źródeł, ale jak masz inny to możesz sprawdzić, nie wiem tylko czy na czas testów nie trzeba odinstalować core STM wrzuconego z managera płytek.
Jeszcze ten link mam zapisany, ale nie mam go teraz wrzuconego do Arduino, bo nie mam katalogu STM32F3: https://github.com/stevstrong/Arduino_STM32, już nie pamiętam czemu, ale wybrałem od RogerClark.
Edit. jeszcze dorzucę, że jak ktoś miał problem z tym USB w STM32 to czasami była wina rezystorów, mała chińska rączka czasem sięgła do złego pudła, no ale to nie zależało od wielkości kodu i działało źle zawsze.

[oscarX]

Po kilku różnych sprawdzeniach wychodzi, że pamięc jest OK, ma zadeklarowaną pojemność. Wygląda że faktycznie problem jest techniczny z USB - jeden kabel trochę wchodzi luźno i jak go nieco przycisnę to działa. Z drugiej strony nie należy mocno dotykać pinów modułu, trzeba tak złapać by w miarę nie dotykać pinów - widocznie zakłócenia z eteru (który nie istnieje) przeszkadzają (A w BlackPillu trzeba przytrzymywać w trakcie resetu jeden guzik). Muszę zlutować jakąś płytkę montażową bo na razie idzie na pająka.
Na razie sama symulacja działa tylko strasznie wolno - ale to kwestia transmisji SPI do wyświetlacza, na razie idzie na GPIO poprzez fukcje digitalWrite. Muszę przejść na sprzętowe SPI i to najlepiej asynchroniczne - program startuje transfer i wraca do kodu. Bo sama symulacja Z80 jest wystarczająco szybka. No i jeszcze jakąś klawiaturke...

[kaczakat]

Dotykanie pinów to mogą być też zimne luty, wnosisz jakieś naprężenia do płytki, nie tylko zakłócenia elektrostatyczne. Czasami warto przejechać lutownicą, oni też już ponoć nie używają lutowia z ołowiem, a te są kruche.
Nie wiem czy SPI wyrobi, znalazłem podobny projekt, może Cię zainteresuje:
https://github.com/ukw100/STECCY/tree/main
On wykorzystuje interfejs równoległy, który jest raczej szybszy niż SPI, oczywiście jak to ciśniesz przez IO jako softowy SPI to jest jeszcze wolniej.
Jest gotowiec do wgrania na płytkę, ale konkretną i do wyboru 2 ekrany, widzę nawet że Salomon ma takie komponenty, albo można zaryzykować tutaj:
https://www.aliexpress.com/item/33013274704.html lub podobny zestaw https://pl.aliexpress.com/item/1005005806465228.html w okolicach 30$.
Choć ekran wygląda na oferowany u innych ILI9341 dedykowany do VET BLACK to jednak jego typ nie jest wypisany, trochę dziwne. Jednak w drugim linku jest mowa o ILI9341 w szczegółach.
Oczywiście są różne ILI9341 , te tylko z SPI są tańsze raczej, nie wiem jaki masz.
Kupiłem kiedyś taką płytkę STM32F407VET6 na Ali za 10$, ale na razie nie ogarniam AVR więc czeka w pudełku, a u tego samego dostawcy teraz jest za 21$ + wysyłka. Zresztą u Salomona też już ponad stówę.

[oscarX]

Teoretycznie jak liczyłem dla pełnego (50 razy/s) odświeżania ekranu potrzebne byłoby 60MHz na SPI. Ale można wyświetlać tylko np. co drugi, trzeci ekran.