At89S8253 jaki darmowy kompilator C?

[kayron]

Kurcze dziwnie się dyskutuje. Z jednej strony podajesz mnóstwo faktów, z którymi trudno się nie zgodzić, po czym strzelasz nagle tekstem który spada z sufitu jak zeszłotygodniowy klops np.

Jak wyślesz te 12-bit? SPI są 8-bit czasem 16-bit, no chyba, że użyjesz ARM ale to nie każdy ma tryby co 4-bit w tym 12-bit ale wyświetlacz przyjmuje dane 16 lub 24 bit.
Jak więc chcesz wysyłać 12-bit? Jeśli chodzi o tryb 4096 kolorów to tego w tych wyświetlaczach nie widziałem, są tryby 16, 18, 24-bit, 12 i 8 bit to rzadkość.

Hm.. kurcze? Nie wiem ? Może tak jak to sugeruje DTRka sterownika wyświetlacza i tak jak to robi reszta świata? ST7735 który też często siedzi w tych wyświetlaczach 128x128. No chyba że Chińskie wersje są z tego wykastrowane?

Co do dema na wyświetlaczu 128x128, trudno całościowo się wypowiedzieć nie znając kodu. Ale pierwsze co się rzuca w oczy to efekt przypominający użycie procedury czyszczenia ekranu, przed wysłaniem kolejnej klatki. Jeżeli tak jest, bo tego nie wiem na 100%, to jest to pierwszy karygodny błąd, przy tworzeniu animacji.

[es2]

Kurcze dziwnie się dyskutuje. Z jednej strony podajesz mnóstwo faktów, z którymi trudno się nie zgodzić, po czym strzelasz nagle tekstem który spada z sufitu jak zeszłotygodniowy klops np.

Bierzesz za wzór jeden sterownik i jesteś przekonany, ze każdy ma 12-bit. Napisałem wyraźnie "12 i 8 bit to rzadkość.". Zapoznaj się z kilkudziesięcioma sterownikami i potwierdzisz, że 12-bit to rzadkość a 8 to unikat (znam tylko jeden).

Co do dema na wyświetlaczu 128x128, trudno całościowo się wypowiedzieć nie znając kodu. Ale pierwsze co się rzuca w oczy to efekt przypominający użycie procedury czyszczenia ekranu, przed wysłaniem kolejnej klatki. Jeżeli tak jest, bo tego nie wiem na 100%, to jest to pierwszy karygodny błąd, przy tworzeniu animacji.

Jest tam kasowanie i nie uważam tego za błąd. W moich (i nie tylko) rozwiązaniach "kasowanie" występuje przed każdą klatką. Napisałem "kasowanie" bo wysyłając cały bufor zawsze wypełniam na nowo całą pamięć ekranu. Wypełniając bufor, ZAWSZE, tak jak to się robi w FT8xx, kasuje ekran, ale to bardzo szybka operacja bo pracuję na szybkiej RAM CPU a nie RAM wyświetlacza gdzie wąskim gardłem jest interfejs komunikacyjny.
To co chcesz zrobić jest o tyle bez sensu, że całą moc CPU przeznaczysz na wysyłanie danych. Aby mieć czas na tworzenie kolejnej klatki musisz zmniejszyć częstotliwość odświeżania ekranu. Będziesz się pocił, męczył a ja bez problemu obsłużę kilka wyświetlaczy a CPU i tak będzie się nudził i będę go usypiał.
Akcelerator, do którego linki dałem, równocześnie wysyła dane do wyświetlacza, odbiera dane po SPI i śpi! Dlatego śpi, bo zarówno wysyłanie danych jak i odbiór jest realizowany przez DMA. Na AVR czegoś takiego nie da się zrobić z kilku powodów. Na Xmega da się ale cena poraża, dużo lepszy ARM jest dużo tańszy!
To co chcesz zrobić to sztuka dla sztuki jak dema na C-64, Atari, Spectrum itp. Co z tego, ze można uzyskać "bajery" jeśli CPU zużywa 100% mocy a dostawienie w jakimś mniejsu jednego rozkazu spowoduje, że wszystko się "wysypie"?
Ja takich problemów nie mam, nie muszę liczyć cykli, robić wstawek ASM aby CPU wyrabiało się w czasie a co ważne mikrokontrolery są tańsze niż te, na których musiałbym się męczyć. Dzięki takiemu podejściu projekt tworzę szybciej przez co jest tańszy a dodatkowo komponenty są tańsze. Same korzyści dla klienta.

Zobacz to Co prawda STM32F401RBT6 kosztuje ok 15zł ale na 89S8253 tego nie zrobisz. Gdybyś dodał RAM za ok 20zł i przeznaczył 100% mocy CPU osiągnąłbyś taki efekt ale czy wystarczyło bi pinów uC? Dwa porty 8-bit + 2 GPIO a może i 4 (RD, WR, A16, A17) zmarnujesz na magistralę. Czy program zmieści się w 12kB? Wątpię, aktualnie soft zajmuje blisko 50k a będzie więcej, bo dojdzie logo kilkadziesiąt kB. Musisz więc doinwestowac w kartę SD lub dodatkowy FLASH. Zakładam się o co chcesz, że nie uzyskasz, wydając w sumie 3-4 razy więcej niż na F401, takiego odświeżania jak na ARM mimo, że ARM głównie śpi.
Pewnie zapytasz po co 3 wyświetlacze? Będą 4. Jeden program a użytkownik podłącza taki wyświetlacz jaki mu pasuje. Łatwiej logistycznie zapanować nad jednym programem i czteroma. Na "dzień dobry" produkujesz seryjnie, zamawiasz rolkę zaprogramowanych uC. Nie będzie błędu w montażu, gdzie PCB jest dla kolorowego TFT a program np dla alfanumerycznego. Co najważniejsze, program napisałem szybciej niż na 8051a uC jest 2 razy tańszy niż rozwiązanie na 8051.

[kayron]

Oddaję koledze honor. Faktycznie 89S8253 nie poradzi sobie sensownie z wyświetlaczem 160x128pix, zabije go zwyczajnie kosmicznie długi cykl maszynowy, może by dał rady pociągnąć kolorowy wyświetlacz z Nokii 3510 (chyba bo nie pamiętam modelu z kursu C na AVR w EDW). który miał 96x64 pix i posiadał tryb 8bit kolor. Ala tam też by nie było szału. Tak naprawdę dla 51 MAX jest chyba monochromatyczny wyświetlacz 128x64 pix. Nawet jak rozpisałem sobie wysyłanie danych w ASM to czas wysyłania jednego kolorowego ekranu był kosmiczny i wynosił prawie 30ms ?!! Dane pobierane z zewnętrznego RAMu. Gdzie w praktyce tak naprawdę aby o czymś myśleć, nie możemy odświeżać ekranu dłużej niż 12ms.
Trochę inaczej sprawa wygląda dla Ultra High Speed 51, czyli DS89C430/450, tam wydajność jest zbliżona do AVRów, nawet ciut większa bo MCU można taktować do 33MHz. Natomiast Zong jest taki że nie ma na pokładzie sprzętowego SPI, i trzeba by kombinować. Tu może by się wyrobił kolorowy wyświetlacz 96x64 PIx, (SPI symulowany na USART, lub na bezczelnego coś na zewnętrznym rejestrze przesównym dopięty do magistrali RAM) ,w jakimś sensownym czasie, ale szalu by nie było.
Choć to zrobione na PICu, mi zaimponowalo .
https://www.youtube.com/watch?v=OlgqC8HLBTA

[es2]

Oddaję koledze honor. Faktycznie 89S8253 nie poradzi sobie sensownie z wyświetlaczem 160x128pix, zabije go zwyczajnie kosmicznie długi cykl maszynowy,

Nie napiszę "A nie mówiłem"

Tak naprawdę dla 51 MAX jest chyba monochromatyczny wyświetlacz 128x64 pix.

I to z kombinacjami, bo na bufor 128x64 potrzeba 1kB RAM.

Nawet jak rozpisałem sobie wysyłanie danych w ASM to czas wysyłania jednego kolorowego ekranu był kosmiczny i wynosił prawie 30ms

Dobry wynik, ale CPU nie robi nic tylko wysyła dane do wyświetlacza.

Dane pobierane z zewnętrznego RAMu. Gdzie w praktyce tak naprawdę aby o czymś myśleć, nie możemy odświeżać ekranu dłużej niż 12ms.

W ograniczonym zakresie ok, ale policz ile kosztuje 8051+RAM a ile ARM, który zrobi to, jak to się mówi "Z palecm w d....".

Trochę inaczej sprawa wygląda dla Ultra High Speed 51, czyli DS89C430/450, tam wydajność jest zbliżona do AVRów, nawet ciut większa bo MCU można taktować do 33MHz. Natomiast Zong jest taki że nie ma na pokładzie sprzętowego SPI, i trzeba by kombinować. Tu może by się wyrobił kolorowy wyświetlacz 96x64 PIx, (SPI symulowany na USART, lub na bezczelnego coś na zewnętrznym rejestrze przesównym dopięty do magistrali RAM) ,w jakimś sensownym czasie, ale szalu by nie było.

Widziałem patent z zewnętrzym, akurat w GAL, w wsyświetlaczach Paltronics, ale mowa o zeszłym tysiącleciu. Teraz pewnie robia na ARM albo AVR.

Choć to zrobione na PICu, mi zaimponowalo .
https://www.youtube.com/watch?v=OlgqC8HLBTA

Nic nadzwyczajnego, nie ma kasowania ekranu tylko kasowane sa wcześniej narysowane punkty. Taki numer przejdzie gdy tło nie jest animowane jak tu: https://www.youtube.com/watch?v=YuAheEd ... dex=9&t=0s
Generalnie, kolorowy wyświetlacz wymaga w pierwszej kolejności RAm na bufor. Bufor może być mniejszy, bo można uzyc koloru 8 czy 4-bit. Wskazane DMA. Jak DMA to najlepiej bufor wielkości takiej jak w wyświetlaczu ale niekoniecznie. Można miec bufor np 4-bit, przekodowac np ramkę 1kB na 16-bit, wysłac przez DMA, DMA wywołuje przerwanie i operacje powtarzamy az wysłana zostanie cała zawartość ekranu. Czasem tak robie ale najczęsciej wybieram uC z wymagana ilościa RAM na bufor wyświetlacza.