Elektroda.pl
Elektroda.pl
X
Elektroda.pl
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATMega128 - Overclocking. Czy jest to bezpieczne?

29 Kwi 2015 17:27 1656 23

  • Poziom 18  
    Na forum nie znalazłem za dużo na ten temat. W necie też jedynie amatorskie próby zwieńczone stwierdzeniem "no jak widać działa, ale nie wiem, na ile to stabilne jest".

    Nie jestem zbyt chętny na użycie ARM-a. Układ ma za zadanie pobierać kilkanaście impulsów z zewnątrz (w tym 2 mogą mieć dosyć dużą częstotliwość, także będą na przerwaniach) oraz wyświetlać to na wyświetlaczu 320x240x16b (oczywiście wybrałem komunikację za pomocą szyny 16b, aby wycisnąć jak najwięcej). Im szybciej wyświetli tym lepiej. Pomyślałem, żeby dać dla pewności większe taktowanie. Myślałem o 30MHz.

    Pytania:
    1. czy nie zacznie pracować niestabilnie? (najważniejsze)
    2. czy użyć zwykły kwarc podłączając go pod xtal1, xtal2 czy musi być generator częstotliwości (nie wiem, jak to dokładnie się nazywa. Taki 4 nóżkowy, metalowy układzik)?
    3. czy podczas programowania nie wystąpią problemy z programatorem? Planuję operować za pośrednictwem JTAG (najmniej ważne)
  • PCBway
  • Poziom 39  
    Ad.1 O przetaktowaniu 16-MHz Atmegi na 30MHz raczej zapomnij. Nie będzie to działać, a jeśli będzie - to będą się sypać poszczególne moduły (np. wewnętrzny EEPROM)
    Ad.2 Bez znaczenia, może być to i to.
    Ad.3 Programowanie i tak jest "taktowane" swoim zegarem (z lini SCK).

    Użycie Atmegi128 w celu sterowania LCD 320x240 to pomyłka. Nie osiągniesz ani dobrej wydajności (chyba, że mówimy o rysowaniu linii itd..). Wszelkiego rodzaju animacje będą się ciąć.
    Już lepszym rozwiązaniem byłoby użycie ATXMEGA... 32MHz z możliwością przetaktowania. Jednak wg mnie - to również pomyłka.
    Najlepsze z tanich rozwiązań - to STM32F4xx:
    - Mają one wbudowany układ FSMC i potrafią traktować wyświetlacz, jako część swojej wewnętrznej pamięci,
    - Taktowanie do 168MHz (przetaktowane nawet do 200)
    - Możliwość podłączenia karty SD (skądś obrazki musisz ładować) przez interfejs 4-bitowy (znacząca poprawa prędkości z generowaniem filmików włącznie).
    - DMA itd... itp.

    Tutaj masz przykład działania: www.youtube.com/watch?v=0ETyFmAMFjY
    Przetestowane, działa elegancko.

    P.S.
    Jeśli już się upierasz przy Atmega - przejdź na ATXMEGA!
  • Poziom 24  
    mikmas napisał:
    Nie jestem zbyt chętny na użycie ARM-a.


    A co jest problemem? Są nawet ARM w obudowie DIP, np LPC1114 - jesli nie chcesz robić montażu powierzchniowego.
    A jesli znasz środowisko programistyczne, to AVR Studio przecież mozna użyć też dla 'atmelowskich' armów.

    Jak duża częstotliwość jest tych impulsów i jak szybko chcesz je wyświetlać aby to było jeszcze czytelne i zauważalne (mozna wyświetlić jakiś stan przez 1/60s tylko jeszcze człowiek musi to zauważyć).
  • Poziom 39  
    @SQLmaster
    Wszystko co mówisz to oczywiście prawda, z tym że użycie do celów sterowania LCD (320x240) zwykłych GPIO jest pomyłką (moim skromnym zdaniem).
    Są oczywiście takie moduły z LCD i np. z LPC1768, jednak to raczej zabawki, niż normalne funkcjonalne i szybkie rozwiązania.
  • PCBway
  • Moderator Mikrokontrolery Projektowanie
    Podobnie jak moim skromnym zdaniem jest pomyłką zmiana MCU, środowiska, posiadanych programatorów tylko po to, żeby zrealizować projekt, który wg autora da się zrealizować na nieco szybszym AVR.
    Oczywiście przetaktowanie ATMega128 na 30 MHz można między bajki włożyć, nawet jeśli odpali to nie wiadomo jak ze stabilnością. Ale XMEGA działa nominalnie na 32 MHz, w dodatku niewykluczone, że obsłuży pomiar sprzętowo, ale autor musiałby uchylić nieco tajemnicy i powiedzieć co chce osiągnąć.
    Co do sterowania LCD - IMHO wcale nie jest takie oczywiste, że użycie GPIO jest pomyłką. Jeśli popatrzymy na specyfikację większości kontrolerów LCD to okaże się, że są koszmarnie wolne, a szczególnie wolny jest odczyt. Czasami cykl odczytu sięga 450 ns! Oczywiście można użyć ARMa z wbudowaną możliwością kontroli matrycy TFT, tylko...:
    - jest to już mała subpopulacja ARMów,
    - są to ARMy w raczej mało przyjaznych dla amatora obudowach,
    - sterowanie matrycą obciąża magistralę procesora i ze 160 MHz MCU okazuje się, że 30 i przy większych matrycach więcej % mocy idzie na obsługę LCD.
    IMHO sensowniejszym rozwiązaniem jest użycie jakiegoś współczesnego kontrolera LCD z akceleratorem - np. RA8875 lub lepiej - FT801/813. Mamy zaawansowany akcelerator, który zostawia w tyle nawet wypaśne ARMy...
  • Poziom 24  
    tmf napisał:
    w dodatku niewykluczone, że obsłuży pomiar sprzętowo, ale autor musiałby uchylić nieco tajemnicy i powiedzieć co chce osiągnąć

    wtedy może się nawet okazać, że wystarczy nie przetaktowana atmega.
  • Poziom 1  
  • Moderator Mikrokontrolery Projektowanie
    Marku, ARM który ma interfejs do pamięci zewnętrznej + pamięć zewnętrzna video + LCD to IMHO o wiele bardziej złożony układ niż MCU + zewnętrzny kontroler LCD. W dodatku przy pierwszym rozwiązaniu musimy zrobić projekt płyki na te 160 MHz, co na dwóch warstwach jest praktycznie niemożliwe. Lutowanie BGA (a stosowne ARMy chyba tylko w takich są obudowach) w warunkach amatorskich jest trudne, a jak coś nie działa to bez RTG też trudno się obejść.
    Zewnętrzny kontroler LCD i odczyt - a jak zrobić np. alfablending bez odczytu VRAM? Oczywiście można zrobic shadow RAM dla video w pamięci procesora i na tym wszystko liczyć, po czym przesyłać do VRAM LCD, chociażby przez DMA. Ale nawet dla 320x240x24b potrzebujemy 230 tys. bajtów. Trudno znależć ARMa z taką ilością RAM, a jeśli już są to w obudowach zdecydowanie nie amatorskich. Na koniec nawet jak te wszystkie problemy dzielnie rozwiążemy, to okaże się, że wyprzedził nas gostek, który kupił np. FT801 za 20 zł, połączył po SPI z ATMega i uzyskał lepsze efekty niż my po naszych mękach.
  • Specjalista - Mikrokontrolery
    tmf: ile razy jeszcze będziesz sugerował, że do uC, który w środku ma 160 MHz, a na zewnątrz miewa 40 MHz potrzebna jest jakakolwiek szczególna płytka? Nie, nie jest. Zwykła 2-warstwowa płytka bez żadnych dopasowań jest w zupełności wystarczająca. Nawet przy podłączaniu SDRAM do STM32F4 nie ma potrzeby wyrównywania długiści linii danych - to jeszcze nie ten zakres częStotliwości- Mówimy o max, 40..50 MHz, a nie o 160, które jest wyłącznie wewnątrz układu.
  • Moderator Mikrokontrolery Projektowanie
    @BlueDraco A jakiż to niesamowity transfer uzyskasz przy taktowaniu interfejsu pamięci na poziomie 40 MHz? Dla porównania nawet w XMEGA EBI działa na 64 MHz, myślałem, że piszemy o jakimś istotnym przyśpieszeniu transferu, a nie zabawie dla zabawy. Z moich obliczeń wynika, że dla LCD 320x240 przy FR 50 Hz ponad 25%-50% przepustowości będzie wykorzystane na samo odświeżanie.
    Uważam, że nawet przy 40MHz i tylu sygnałach płytka musi być megaprzemyślana. Na dwuwarstwowej fizyczne połączenie 32 linii danych, 19 linii adresowych i sygnałów sterujących, w dodatku przeplecenie tego z interfejsem 24-bitowym do LCD nie jest zadaniem łatwym. Pokażesz mi jak to poroutujesz na 2-warstwowej płytce? Ale ok, niech będzie, że masz rację. Czy efekt będzie lepszy i tańszy niż kupno np. FT813? Idę o zakład, że nie, szczególnie przy owych 40 MHz.
    Jeszcze jedna sprawa - ilu kondensatorów odsprzęgających i ilu linii zasilania wymaga procek taktowany 160MHz + jakie są zalecenia co do ich rozmieszczenia i jak zamierzasz je zrealizować na 2-warstwowym laminacie? To nie jest złośliwe pytanie i nie odbieraj tego jako ataku - siedzę właśnie na takim układem i mam duży problem jak to zrobić, dlatego właśnie rozważam użycie specjalizowanego chipu. Chętnie bym zobaczył przykład takiej PCB.
  • Poziom 39  
    tmf napisał:
    W dodatku przy pierwszym rozwiązaniu musimy zrobić projekt płyki na te 160 MHz, co na dwóch warstwach jest praktycznie niemożliwe. Lutowanie BGA (a stosowne ARMy chyba tylko w takich są obudowach) w warunkach amatorskich jest trudne...
    STM32F407VGT6 (taki jak w STM32F4DISCOVERY) w obudowie LQFP100 wystarczy. Oczywiście - nie wytrawimy płytki metodą żelazkową, ale spokojnie zrobią nam ta płytkę w pierwszej lepszej fabryczce PCB.
    Potem wystarczy dobra lutownica (nawet nie Hot-Air) i dobry topnik - i sprawa załatwiona.

    tmf napisał:
    Ale nawet dla 320x240x24b potrzebujemy 230 tys. bajtów. Trudno znależć ARMa z taką ilością RAM
    Kolejny błąd. Wystarczy spojrzeć na przestrzeń adresową ARM-ów. Nie mówię o wbudowanej pamięci RAM - tylko o układach z FSMC.

    Polecam link z zaprezentowanego przeze mnie filmiku, gdzie dokładnie widać jak 'skomplikowane' jest owe STM32F4DISCOVERY i płytka przejściówka do LCD.
    Zrobiłem ten układ - zadziałał bez problemu. Nie widzę żadnych trudności w podłączeniu LCD bezpośrednio do STM32F407VGT6 czy nawet wyższych (STM32F429xxx).
  • Poziom 1  

  • Poziom 18  
    Już śpieszę z odpowiedziami, do czego to i czemu akurat nie army.

    Robię se zegary do motorka (nie chcę żadnych gotowych projektów, chcę sam zaprojektować i zbudować). Zacząłem od WG12864B (128x64x1) na atmega8. Wyświetlało normalnie, układ był prawie ukończony, jednak pomyślałem sobie, że użyję czegoś fajniejszego. W tym momencie projekt trafił do kosza i zacząłem robić od początku na w/w wyświetlaczu. Ma on (modelu nie wymieniam, bo 1. nie mam pod ręką, 2. może się zmienić, nie zakupiłem go jeszcze) interfejs SPI, 8b lub 16b. 16b to imho najlepszy wybór.

    Czemu nie ARM? Poniekąd odpowiedziałem wyżej. Na atmelach zjadłem zęby. I tak wystarczająco dużo nowinek chcę tu zastosować, żeby dodatkowo ryzykować kompletnie dla mnie obcym procesorem. Zwyczajnie niepotrzebne zwiększenie ryzyka. Dodatkowo trochę szkoda wrzucać układ mierzący impulsy z pulsarów do sterowania zwykłym budzikiem ;). Bynajmniej nie będę tam wyświetlać filmów w HD, aczkolwiek podczas jazdy dużo fragmentów obrazu będzie się dynamicznie zmieniać.

    Motorek też zasadniczo dupska nie urywa - max 13k obr. i Vmax 220km/h (z czytnika mam 4 impulsy na obrót koła) - te 2 źródła będą miały największe częstotliwości, ale spokojnie ogarnę to przerwaniami (w atmedze jest ich trochę, więc luz).

    Taktowanie jest mi potrzebne do wyciągnięcia max. bezpiecznej prędkości procka. Im więcej ~ tym więcej będę mógł dynamicznie zmieniać na wyświetlaczu
  • Poziom 1  

  • Poziom 18  
    Czyli mówisz, że zbytnio panikuję i 16MHz na atmega128 w zupełności wystarczy?

    Animacja to za dużo powiedziane - raczej nie planuję robić np. efektu padającego śniegu :D. Raczej bym chciał móc np. szybko zmienić kolor tła. Na "starym" wyświetlaczu jak wyrzucałem bieg (ustawiałem się na N) to robił się negatyw (ciężko mówić o negatywie w przypadku 1b "palety" kolorów :D). Jest to dosyć wygodne, dlatego też tutaj chciałbym szybko odmalować tło na jakiś nie drażniący, ale widoczny kolor. Dodatkowo przy prędkościach 140+ jak człek się nie schowa za szybką to telepie głową i ciężko odczytać prędkość, więc fajnie by było jakby od pewnych prędkości tło zmieniało się na np. lekko bordowy.

    Oczywiście to nie jest niezbędna funkcjonalność, ale zapełnienie ekranu w <250ms byłoby mile widziane. Dlatego też pytam o te 30MHz. Szkoda by było, jakbym się namęczył nad stworzeniem płytki smd z soldermaską i innymi bajerami, zlutowaniem tego etc. tylko po to, żeby zobaczyć, że wyświetlacz potrzebuje 10 sekund na zalanie całego obrazu.

    Język oczywiście c. Sądzę, że dosyć dobrze go znam, także pod względem optymalności samego kodu raczej najgorzej nie będzie.

    EDIT!
    Do jakiej prędkości mogę dobić max, aby wszystko działało?
  • Moderator Mikrokontrolery Projektowanie
    @mikmas Impulsy mierzysz sprzętowo na licznikach i nawet przy 1000x wyższej częstotliwości nie będzie problemu. Odświeżanie jak piszesz interesuje cię poniżej 250 ms - na ATMega128 łącząc LCD po SPI uzyskasz spokojnie <250 ms, na XMEGA po SPI udało mi się uzyskać refresh na poziomie 8 Hz (<125 ms), a przy wypełnianiu obszarów jednolitym tłem >14 Hz. Więc jeśli interesują cię tylko takie osiągi to nic nie musisz robić. Będzie OK.

    Dodano po 2 [minuty]:

    mickpr napisał:

    tmf napisał:
    Ale nawet dla 320x240x24b potrzebujemy 230 tys. bajtów. Trudno znależć ARMa z taką ilością RAM

    Kolejny błąd. Wystarczy spojrzeć na przestrzeń adresową ARM-ów. Nie mówię o wbudowanej pamięci RAM - tylko o układach z FSMC.


    Jaki błąd? Że LCD będzie wymagał 230 tys. bajtów i że tą pamięć musimy podłączyć jako zewnętrzną do ARMa? Przecież o tym pisałem.

  • Poziom 18  
    Czyli jeżeli sterując po SPI zejdę poniżej 1/4s, to przy 16b szynie będę mógł się spodziewać naprawdę dobrych osiągów?
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Marek_Skalski napisał:
    tmf napisał:
    Lutowanie BGA (a stosowne ARMy chyba tylko w takich są obudowach)

    Dementuję takie pogłoski. Przykładowa płytka STM32F429-DISCO. Ma prawdopodobnie wszystko co potrzebuje autor tego tematu, kosztuje śmieszne pieniądze. Na pokładzie 64Mbit SDRAM, więc wystarczy na wiele ekranów. Alpha blending + overlay (obraz statyczny + dynamiczny) robi sprzętowo. Sercem jest układ, który można kupić w każdym dobrym sklepie STM32F429ZI w obudowie TQFP144; żaden cud. Jest też w wersji QFP100, QFP176 i QFP208. Xmega z interfejsem EBI też jest w obudowie QFP100. Więc nie ma tutaj wielkiej różnicy.
    W Q3 (lub Q4) będą dostępne układy z interfejsem MPI DSI; jeszcze szybsze przesyłanie obrazu na wyświetlacze montowane typowo w smartfonach i odtwarzaczach mm.


    Marku, nie zapędziłeś się trochę? Piszemy o projekcie na ATMega128 w którym wg autora (co zresztą okazało się nieprawdą) zabrakło ciut mocy. Doszliśmy już do QFP208, 64 bitowej pamięci SDRAM... to ja przebijam ofertę - RaspberryPi w wersji z 1 GB DDR i quad-core ARM.
    Czy chcesz mnie przekonać, że ARM może szybciej? Szkoda twojego wysiłku - doskonale to wiem. Czy jest potrzebny w takich projektach - IMHO nie. Jeśli ktoś siedzi w ARM to robi taki projekt na ARM, jeśli ktoś do tej pory siedział w AVR to nie ma najmniejszej potrzeby przesiadki.

    Marek_Skalski napisał:
    Co do RAMu, to żadna Xmega nie ma na pokładzie 256kB RAM. Argument chybiony.


    Marku, mam wrażenie, że nie miałeś czasu przeczytać tego co napisałem. Nigdzie nie twierdziłem, że AVR ma >32 kB RAM (wystarczy spojrzeć do product selector na stronie Atmela). Pisałem, że jeśli wykorzystamy ARMa do bezpośredniego sterowania matrycą TFT to musimy zapewnić przynajmniej 230 kB RAM na bufor ramki, a tak napradę 2xtyle ze względu na double buffering. Czyli może prościej jest jednak wykorzystać dedykowany kontroler w cenie <1$ za sztukę mający wszystko (np. RA8875).

    Marek_Skalski napisał:
    Co do FT801, to niestety, ale autor tego tematu napisał, że szybkość ma znaczenie. Jeżeli FT801 nadaje się do tego zadania, to Mega128 też podoła. Transmisja po SPI i grafika to pojęcia wzajemnie sprzeczne. A użycie kanału alpha w takim przypadku, to już tylko żart.


    Tu się z tobą nie zgodzę. Pominę, że okazało się, że jednak szybkość nawet SPI i klasycznego LCD jednak wystarczy. Ale wróćmy do FT801. To nie jest kontroler typu framebuffer, do którego musisz ładować gotowe dane do VRAM, co wymaga sporego pasma. To akcelerator, który robi wszystko sprzętowo - a więc po SPI ładujesz polecenia. Np. wyświetlenie tekstu z antyaliasingiem, alfablendingiem, obróconego o zadany kąt to wysłanie polecenia określającego atrybuty (parę bajtów) + kodów ASCII znaków do wyświetlenia. Wyświetlenie obrazka to konieczność preloadowania danych graficznych, np. kilku kB JPEG + polecenie wyświetlenia tego w zadanym miejscu. Mogę się założyć, że wydajność tych operacji po SPI dla FT801 będzie wyższa niż dla wymienionych ARMów z wbudowanym kontrolerem. Ale jeśli to ciągle mało to weź FT813, który ma interfejs QSPI + sprzętowe dekodowanie video. Tu próbka możliwości (sterowany z 8 bitowego MCU):

    Link




    Marek_Skalski napisał:
    Co do płytek... większość płytek do Cortex'ów jest robiona jako 2 warstwowe: ST, NXP, WaveShare. Jeżeli są 4 warstwy, to na ogół ze względu na obudowy BGA lub czasami ograniczenia powierzchniowe. I żadnych cudów tu nie ma. Poza tym, płytka 4 czy 6 warstw, to dzisiaj rzecz łatwo dostępna. 4x droższa niż 2 warstwy, ale dostępna.


    Marku, koszt zrobienia płytki 2-warstwowej w firmie to 40-100 zł, do tego mamy darmowy soft do wyboru do koloru. Koszt płytki 4-warstwowej to 400-500 zł, a jeśli chodzi o możliwość jej zaprojektowania softem za free to jest problem. Czyli mamy kilkaset $ na soft jako bonus. Wiem, że się profesjonalnie zajmujesz elektroniką i po prostu masz dostęp do sprzętu, firm i co ważne - potrafisz takie płytki zaprojektować. Ale dla amatora wydanie np. 400 zł na płytkę, z dużą szansą, że jest błędnie zaprojektowana i trzeba ją zrobić ponownie to już nie takie łatwe do przełknięcia jest.
    I nie uwierzę, że zrobisz na 2 warstwach LQFP144 z 64-bitowym SDRAM + złącze do matrycy LCD. Taki ze mnie niewierny Tomasz, że żeby uwierzyć muszę zobaczyć.


    Marek_Skalski napisał:
    Prędkość magistrali: W Xmega dane są wypluwane jako 8-bitów... trzeba je składać używając zatrzasków, albo 3x write dla każdego piksela, albo programowe przestawianie bajtów. Tutaj jest pierwsze wąskie gardło.
    Drugie, to DMA w Xmega, które kradnie cykle CPU. Dlatego te 25-50% przepustowości ma znaczenie. Dla mnie to nie ma znaczenia ponieważ DMA ma swój mostek na magistrali i dane pobiera nie blokując rdzenia.
    A ogólnie, aby coś wyświetlić, to trzeba wcześniej przygotować dane i tutaj Xmega ze swoim powolnym, 8 bitowym rdzeniem, który nie potrafi przesunąć więcej niż 1 bit w operacji, niestety ginie. Proponuję poszukać wyników CoreMark dla Xmega i porównać je z wynikami Cortex-M. Nawet z tymi M0 :)


    Marku, nie przekonuj mnie, że ARM jest szybszy niż AVR. Nigdzie nie sugerowałem czegoś innego. Być może źle mnie zrozumiałeś. Chodziło mi o to, że jeśli to ARM ma generować sygnały dla matrycy LCD to musimy zapewnić pamięć na bufor. Musi to być pamięć zewnętrzna, bo wewnętrznej ARMy o których piszemy po prostu nie mają tyle ile potrzeba. Czyli komplikacja układu. Druga sprawa - DMA. OK, masz oddzielną magistralę, ale w takiej sytuacji tą pamięć dedykujesz tylko pod bufor ramki LCD. Niemniej procesor zajmuje się przetwarzaniem danych w tej pamięci więc też konkuruje z DMA. Nie jest to żaden problem oczywiście, lecz już wymusza taktowanie pamięci na jakimś tam poziomie. Do tego jeśli korzystamy z SDRAM to ze względu na budowę pamięci, przełączanie banków itd. taktowanie musi byc szybkie, bo w pojedynczych przypadkach dostęp do pamięci może trwać nawet kilkanaście taktów zegara - szybki jest tylko dostęp sekwencyjny burst. Czyli 40 MHz i LCD może okazać się niekompatybilne z SDRAM.

    Marek_Skalski napisał:
    Dlaczego 32 linie danych jak Xmega obsługuje tylko 8? Linii adresowych też tyle nie trzeba. Wystarczy użyć SDRAM. Przecież dane do wyświetlania i tak lecą synchronicznie.
    W moim przypadku potrzebuję 10 kondensatorów 100nF(0603) + 2x V_CAP (1411).
    Nie jest to trudne, ponieważ ścieżki mogę mieć na 5mils'ów.


    Dlatego 32 linie danych bo pisałem o ARM, nie o AVR. IMHO i tu się ze mną pewnie zgodzisz, kompletnie nie miałoby sensu budowanie układu kontrolera LCD na AVR z zewnętrzną pamięcią - chociażby dlatego, że AVR nie podołałby temu zadaniu, lub byłoby to na granicy możliwości tego procka.
    BTW, 5 milsów to już lepsze firmy płytkarskie tylko oferują.

    Dodano po 2 [minuty]:

    mikmas napisał:
    Czyli jeżeli sterując po SPI zejdę poniżej 1/4s, to przy 16b szynie będę mógł się spodziewać naprawdę dobrych osiągów?


    Przepustowość będzie większa, ale... Komunikacja z LCD to nie tylko transmisja bloków danych - trzeba je jeszcze przetworzyć. Dla przykłądu - dla XMEGA taktowanej 32 MHz, z SPI na 16 MHz, masz bajt wysyłany co 16 taktów. Czyli w 16 taktach musisz przygotować kolejny bajt i go wysłać do SPI. W przypadku interfejsu równoległego kolejny bajt (lub dwa) możesz wysyłać częściej - powiedzmy, że jeśli programowo manglujesz liniami sterującymi interfejsu to na ich wysłanie potrzebujesz 4-5 taktów. Niby nawet 4-krotnie szybciej niż po SPI, ale jednak kolejne bajty też trzeba przygotować i już to wszystko tak pięknie nie wygląda.
  • Moderator Mikrokontrolery Projektowanie
    mikmas napisał:
    ... podczas jazdy dużo fragmentów obrazu będzie się dynamicznie zmieniać.

    Nie bez przyczyny w samochodach rajdowych (i motocyklach pewnie także) jest tak mało bajerów, a zamiast tego proste, duże i czytelne cyfry i w jak najmniejszej ilości.

    Marek_Skalski napisał:
    A grafika/animacje, to chyba tylko na postoju, bo podczas jazdy to raczej będzie rozpraszać niż pomagać?

    I tego bym się trzymał, byśmy nie musieli kwiatów kupować, gdy autor zagapi się na swoje dzieło podczas jazdy.

  • Poziom 18  
    tmf napisał:

    Przepustowość będzie większa, ale... Komunikacja z LCD to nie tylko transmisja bloków danych - trzeba je jeszcze przetworzyć. Dla przykłądu - dla XMEGA taktowanej 32 MHz, z SPI na 16 MHz, masz bajt wysyłany co 16 taktów. Czyli w 16 taktach musisz przygotować kolejny bajt i go wysłać do SPI. W przypadku interfejsu równoległego kolejny bajt (lub dwa) możesz wysyłać częściej - powiedzmy, że jeśli programowo manglujesz liniami sterującymi interfejsu to na ich wysłanie potrzebujesz 4-5 taktów. Niby nawet 4-krotnie szybciej niż po SPI, ale jednak kolejne bajty też trzeba przygotować i już to wszystko tak pięknie nie wygląda.

    Tu muszę przyznać rację. Podczas gdy pakiet się wysyła mogę "w tle" przygotować następną papkę, jednak i tak będzie to wolniejsze (przygotowanie kolejnego "pocisku" w miejscach, gdzie nie trza niczego dekompresować czy coś nie zajmie więcej niż ~4 takty). Aczkolwiek nie myślałem wcześniej o SPI jako wykorzystaniu go jako równoległy "wątek", w czasie którego mogę robić coś innego. Fajny pomysł

    dondu napisał:
    Nie bez przyczyny w samochodach rajdowych (i motocyklach pewnie także) jest tak mało bajerów, a zamiast tego proste, duże i czytelne cyfry i w jak najmniejszej ilości.

    I tego bym się trzymał, byśmy nie musieli kwiatów kupować, gdy autor zagapi się
    dondu napisał:
    na swoje dzieło podczas jazdy.

    Przeczytaj jeszcze raz, do czego potrzebuję możliwość szybkiego wyświetlenia obrazu
  • Moderator Mikrokontrolery Projektowanie
    mikmas napisał:
    Przeczytaj jeszcze raz, do czego potrzebuję możliwość szybkiego wyświetlenia obrazu

    Czytałem i nawet zacytowałem istotny fragment, a do niego przeczytałem także ten:

    mikmas napisał:
    Motorek też zasadniczo dupska nie urywa - max 13k obr. i Vmax 220km/h

    Przy tych prędkościach nie patrzy się na wskaźniki, tylko jedzie skupionym i czuje sprzęt wszystkimi zmysłami.
  • Moderator Mikrokontrolery Projektowanie
    mikmas napisał:
    tmf napisał:

    Przepustowość będzie większa, ale... Komunikacja z LCD to nie tylko transmisja bloków danych - trzeba je jeszcze przetworzyć. Dla przykłądu - dla XMEGA taktowanej 32 MHz, z SPI na 16 MHz, masz bajt wysyłany co 16 taktów. Czyli w 16 taktach musisz przygotować kolejny bajt i go wysłać do SPI. W przypadku interfejsu równoległego kolejny bajt (lub dwa) możesz wysyłać częściej - powiedzmy, że jeśli programowo manglujesz liniami sterującymi interfejsu to na ich wysłanie potrzebujesz 4-5 taktów. Niby nawet 4-krotnie szybciej niż po SPI, ale jednak kolejne bajty też trzeba przygotować i już to wszystko tak pięknie nie wygląda.

    Tu muszę przyznać rację. Podczas gdy pakiet się wysyła mogę "w tle" przygotować następną papkę, jednak i tak będzie to wolniejsze (przygotowanie kolejnego "pocisku" w miejscach, gdzie nie trza niczego dekompresować czy coś nie zajmie więcej niż ~4 takty). Aczkolwiek nie myślałem wcześniej o SPI jako wykorzystaniu go jako równoległy "wątek", w czasie którego mogę robić coś innego. Fajny pomysł


    Tak, przeplatanie danych dla SPI obliczeniami jest uciążliwe, znacznie w tym pomaga procek z DMA (XMEGA, ARM). W aplikacji obrabiasz dane i wpisujesz je do bufora, skąd bez udziału CPU są przez DMA wysyłane do SPI.
    Natomiast jeśli chcesz uzyskać bez większego wysiłku efekty graficzne na miarę czasów, w których żyjemy, to zainwestuj w FT801.
  • Poziom 24  
    dondu napisał:
    mikmas napisał:
    Przeczytaj jeszcze raz, do czego potrzebuję możliwość szybkiego wyświetlenia obrazu

    Czytałem i nawet zacytowałem istotny fragment, a do niego przeczytałem także ten:

    mikmas napisał:
    Motorek też zasadniczo dupska nie urywa - max 13k obr. i Vmax 220km/h

    Przy tych prędkościach nie patrzy się na wskaźniki, tylko jedzie skupionym i czuje sprzęt wszystkimi zmysłami.


    A dodatkowo śmiało możemy założyć że motor nie przyspiesza od 0 do 200 km/h w 100ms. Tak samo nie hamuje do zera w 100ms, a więc rak naprawdę odświeżanie rzędu 2 fps wystarczy. A nawet moim zdaniem byłoby czytelniej niż zamazane wirujące cyfry odświeżane z 60fps.

  • Poziom 18  
    OK, dzięki wszystkim za pomoc. Nieoceniona wartość porad. Pewnie nie raz będę z nich korzystać. :)