Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Przenośna konsola z kolorowym TFT - DMA -wydzielone

jacynka84 30 Maj 2015 16:24 6732 124
  • #1 30 Maj 2015 16:24
    jacynka84
    Poziom 26  

    Może mi ktoś wyjaśnić jak to osiąga tak dobre odświeżanie? Na xmega i bascom 128x160x16bpp czyli połowa tego po SPI jest bardzo średnio. Widoczny tu efekt nie jest osiągalny. A xmega gania na 40Mhz, SPI na max. Czy C i bascom robi aż taką różnicę? Coś mi się nie chce w to wierzyć.

    0 29
  • #2 30 Maj 2015 17:06
    R-MIK
    Poziom 38  

    jacynka84 napisał:
    (...)Czy C i bascom robi aż taką różnicę? Coś mi się nie chce w to wierzyć.

    Często robi, dlatego w Bascom częściej stosuje się wstawki Assemlerowe niż w C.

    0
  • #3 30 Maj 2015 17:06
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    Na xmega i bascom 128x160x16bpp czyli połowa tego po SPI jest bardzo średnio.

    Policzmy:
    128x160x2= 40960 bajtów = 40kB. 40kB x 20fp = 800kBps. 800kBps x 8 = 6400kbps...
    To jest ledwo 6.25Mbps. Zegar SPI potrzebujesz niecałe 7MHz, zakładając ciągły transfer. Jeśli nie dajesz rady uzyskać takich transferów dysponując prockiem kilkadziesiąt MHz i DMA, to, krótko mówiąc, bida.

    Wciąz mowimy o przerysowywaniu całego ekranu 20 razy na sekundę. To się często mija z celem. Przerysowuje się tylko to, co się zmienia, w szczególności wtedy, gdy masz jednolite tło...

    0
  • #4 30 Maj 2015 17:31
    jacynka84
    Poziom 26  

    Niecałe 41kB/klatkę, czyli np 16fps to by wymagało ok 656kB/s, tak jak mówisz.
    A moja xmega nie jest w stanie wydusić chyba nawet 6fps.
    I ciekawostka, jak użyjemy zamiast print aby wysyłał po spi w xmega, bezpośrednio Spic_data = dana 'SPI na porcie C
    Bitwait Spic_status.7 , Set
    to jest zauważalnie szybciej. Nadal jednak to jest bardzo mało fps. Daltego jestem ciekawy jak to jest że to działa na 8Mhz, czyli SPI max 4Mhz (ja w xmega ustawiam max czyli pewnie ze 20Mhz) nie widać migotania, a u mnie widać wyraźnie klatkowanie.
    Aż wezmę Fmeter i może uda mi się zmierzyć częstotliwość zegara SPI.

    0
  • #5 30 Maj 2015 17:52
    R-MIK
    Poziom 38  

    jacynka84 napisał:
    Niecałe 41kB/klatkę, czyli np 16fps to by wymagało ok 656kB/s, tak jak mówisz.
    A moja xmega nie jest w stanie wydusić chyba nawet 6fps.

    Sma transmisja to nie wszystko, trzeba jeszcze zmienić treść bufora pamięci obrazu a to też zajmuje czas.

    0
  • #6 30 Maj 2015 18:03
    jacynka84
    Poziom 26  

    No więc zmierzyłem, licznik wykazał 440Khz po przyłożeniu do SCK SPI na PortC.7 w xmega...
    Prędkość odświeżania by się zgadzała właściwie idealnie.
    To jest najmniej 10x za mało. Czy jest możliwość że SPI się załącza inaczej niż chcę i nadal pokazywać rzekomo prawidłowy rejestr ustawień??

    R-MIK napisał:
    trzeba jeszcze zmienić treść bufora pamięci obrazu a to też zajmuje czas.

    To ja wiem ale to nadal o wiele za mało. Tym bardziej że do tego testu nie użyłem funkcji która cos liczy tylko wysyła same dane koloru wypełnienia obrazu, Call Lcd_clear(blue).
    To nie liczy niczego tylko bezpośrednio wysyła 40960 bajtów.

    0
  • #7 30 Maj 2015 18:11
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    To nie liczy niczego tylko bezpośrednio wysyła 40960 bajtów.

    To jest jeden z problemów takich funkcji. Gdzie użycie DMA? Wysyłając w pętli niedosyć że blokujesz sobie przepływ, to jeszcze zamiast ciągłego strumienia bitów masz przerwy co 8 bajtów (na szybkich prockach bywa bardzo upierdliwe, bo obsługa pętli i czekanie na flagę potrafi zająć pół z tego, co transmisja całego bajtu...)
    Wydaje mi się, że xmega potrafi znacznie więcej niz 440kHz. A funkcja powinna ustawić kolor w jakiejś globalnej zmiennej, uzbroić wyświetlacz, uzbroić DMA, i wysłać ten sam bajt 40960 razy bez ingerencji rdzenia w transmisję. Wtedy to ma sens.

    1
  • #8 30 Maj 2015 18:34
    jacynka84
    Poziom 26  

    Rozumiem, ale ATmega z projektu powyżej nie ma DMA, a radzi sobie 10x lepiej.
    A jesteś w stanie mi objaśnić jak to DMA poustawiać? I jak zastąpić w Bascom SPIx_DATA poleceniem uruchomienia DMA? Próbowałem kiedyś, ale oczywiście nie działało.
    Bo niewykluczone że same SPI działa szybko, ale przerwy między bajtami są zbyt długie.

    0
  • #9 30 Maj 2015 18:52
    R-MIK
    Poziom 38  

    Bez wstawki Assemblerowej pewnie się nie obędzie.

    0
  • #10 30 Maj 2015 19:14
    jacynka84
    Poziom 26  

    No to lipa. A co właściwie miałaby ona robić?

    Dodano po 16 [minuty]:

    Kod: basic4gl
    Zaloguj się, aby zobaczyć kod

    Tak wygląda funkcja zapełniająca/czyszcząca ekran.

    0
  • #11 30 Maj 2015 21:39
    nsvinc
    Poziom 35  

    Nie mam pojęcia jak działa bascom. Jak to ktoś kiedyś na elce stwierdził - "bascom dzielnie walczy z problemami nie występującymi w innych językach"...

    W C uzbrojenie DMA to zwyczajnie parę zapisów do SFRów procesora; żadnych wstawek asemblerowych nie ma potrzeby pisać, a często jest to wręcz nie wskazane.
    Jak modyfikować surowe SFRy pod bascomem - nie wiem. Ale pewnie jakoś się da.

    Co trzeba zrobić:
    [Nie wiem jak działa DMA w XMega] ale zakładam że ogólny sposób działania jest standardowy - pod kanał obsługujący request tx od SPI, wpisujesz adres zródłowy (de facto adres zmiennej), adres docelowy (adres SFRa danych od SPI), aktywujesz obsługę requesta od SPI, i odpalasz transfer... Wszystko będzie na bank opisane w manualu :)

    2
  • #12 30 Maj 2015 22:09
    leonow32

    Poziom 29  

    nsvinc napisał:
    [Nie wiem jak działa DMA w XMega] ale zakładam że ogólny sposób działania jest standardowy - pod kanał obsługujący request tx od SPI, wpisujesz adres zródłowy (de facto adres zmiennej), adres docelowy (adres SFRa danych od SPI), aktywujesz obsługę requesta od SPI, i odpalasz transfer... Wszystko będzie na bank opisane w manualu :)

    Działa bardzo prosto :) wystarczy wpisać adres źródłowy, docelowy, parę rejestrów skonfigurować i heja. Dokładniej to zostało opisane w moim kursie:
    http://www.leon-instruments.pl/2015/02/kurs-xmega-23-podstawy-dma.html

    1
  • #13 30 Maj 2015 22:59
    jacynka84
    Poziom 26  

    No ja wiem, czytałem w helpie jak się konfiguruje DMA i niby używa, ale nic to nie dało. Normalnie jak mam funkcję "data send", i zamiast tego wpiszę tę zmienną jako źródło, i adres docelowy jako SPIx_DATA, to NIC się nie dzieje. Zresztą dlaczego miałoby. Te dane mają być wysyłane w konkretnym momencie i konkretna ich ilość a nie na pałę na bierząco przez DMA. I to chyba sedno problemu.

    0
  • #14 31 Maj 2015 00:03
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    No ja wiem, czytałem w helpie jak się konfiguruje DMA i niby używa, ale nic to nie dało. Normalnie jak mam funkcję "data send", i zamiast tego wpiszę tę zmienną jako źródło, i adres docelowy jako SPIx_DATA, to NIC się nie dzieje. Zresztą dlaczego miałoby. Te dane mają być wysyłane w konkretnym momencie i konkretna ich ilość a nie na pałę na bierząco przez DMA.

    Przecież każde szanujące się DMA ma licznik pojedynczych transferów, i obstawiam, że w XMega nie jest inaczej! Odpalasz w swoim 'konkretnym momencie', i DMA bez obciążania rdzenia wykonuje 'konkretną ilość' transferów. Jak wykona, to się wyłączy... - więc syntezujesz problem, którego nie ma.

    Pamiętaj, że musisz tez skonfigurować SPI tak, żeby w ogóle chciało sygnalizować requesty do kontrolera DMA. Samo z siebie domyślnie nie będzie ich generować...

    Ogólnie robi się to tak, że najpierw wysyłasz 'rdzeniem' krótkie rozkazy typu właśnie set_window, potem przełączasz SPI w tryb DMA, uzbrajasz DMA, odpalasz DMA, [od tego momentu transfer dzieje się 'sam z siebie'], i w przerwaniu od DMA 'transfer complete' finalizujesz transakcję - przełączasz SPI w tryb 'normalny', opcjonalnie wysyłasz dodatkowe rozkazy lub zwyczajnie podnosisz linię CS diwajsa, do którego wysyłałeś dane.
    Nie ma w tym magii. Żadnej...

    1
  • #15 31 Maj 2015 13:16
    jacynka84
    Poziom 26  

    nsvinc napisał:
    musisz tez skonfigurować SPI tak, żeby w ogóle chciało sygnalizować requesty do kontrolera DMA.

    Nie ogarniam, przecież SPI sygnalizuje bitem jak skończy wysyłać bajt, a nie że go chce. To ja wysyłam bajt wtedy kiedy potrzebuję.
    Chodzi ci o to żeby SPI mówiło DMA że się zwolniło i może dać następny bajt a nie pchało wszystko naraz?
    I nie wiem co znaczy przełącz SPI w tryb DMA.
    Ponadto, mam w kodzie steru do lcd 2 miejsca z różnymi zmiennymi które uzywają SPI, czy to znaczy ze muszę użyć 2 kanałów DMA?

    0
  • #16 31 Maj 2015 14:57
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    Nie ogarniam, przecież SPI sygnalizuje bitem jak skończy wysyłać bajt

    No właśnie. I w krzemie ten 'bit' jest podłączony pod multiplekser requestów DMA. Więc jeśli DMA jest skonfigurowane tak, aby tym bitem wyzwalać przeniesienie wartości z pamięci do SFRa danych SPI, to za każdym razem gdy SPI skonczy wysyłać, to DMA nakarmi go nowym bajtem...

    jacynka84 napisał:
    I nie wiem co znaczy przełącz SPI w tryb DMA.

    Ja też nie wiem :) np. w STM32 trzeba włączyć w SFRach SPI tryb DMA (ustawić bit). W XMega może tego nie być lub być inaczej. Zajrzyj do manuala zamiast czytać helpa bascoma!

    jacynka84 napisał:
    Ponadto, mam w kodzie steru do lcd 2 miejsca z różnymi zmiennymi które uzywają SPI, czy to znaczy ze muszę użyć 2 kanałów DMA?

    Dwa kanały DMA na jedno SPI. Aby wysłać, musisz odbierać, nawet wtedy gdy to co odbierzesz, olewasz. Więc jeden kanał DMA obsługuje wysyłkę sensownych danych po SPI, drugi utylizuje to co odbierasz, do jakiejś lipnej zmiennej lub pod adresy "DMA garbage" (niektóre procki mają specjalną przestrzeń adresową służącą właśnie do utylizacji niepotrzebnych danych z DMA).

    0
  • #17 31 Maj 2015 18:09
    jacynka84
    Poziom 26  

    Dobrze wezmę pod uwagę że to ma też odebrać. Choć nie mam pojęcia jak i jak to wyegzekwować skoro nic nie nadaje do xmega.
    Tak czytam datasheety często bo daje to dużo lepszy wgląd w registry niż durne polecenia bascoma. Nie wiem jednak jak podłączyć przerwanie od SPI pod te DMA, jest coś jak eventsystem ale miesza mi się to wszystko już.

    0
  • #18 31 Maj 2015 20:23
    nsvinc
    Poziom 35  

    Może warto poczekać na kol. tmf albo kol. dondu którzy pracują z AVRami :] Ja niebardzo jestem w stanie pomóc w sprawach dotyczących krzemu AVRów. Moje podpowiedzi są oparte na doświadczeniu nabytemu podczas pracy z różnej maści ARMami, i niekoniecznie musi to być w 100% trafne; jednak sądzę, że kontroler DMA będzie w każdym procku działać mniej więcej tak samo (w sumie nie bardzo jest inne wyjście...)

    jacynka84 napisał:
    Tak czytam datasheety często bo daje to dużo lepszy wgląd w registry niż durne polecenia bascoma.

    Hm... Może jednak warto przesiąść się na C? (broń borze, nie chcę kolejnej flame war :)...) C jednak daje możliwość panowania w niemal 100% nad tym, co wykonuje rdzeń, i praktycznie 100% nad tym, co wykonują peryferia.
    Bez obrazy - ale piszą w bascomie, nie masz pojęcia co robi procek. Wydajesz mu tylko bardzo-wysokopoziomowy rozkaz i liczysz na to, że kompilator zamieni ten rozkaz na kawałek wydajnego kodu maszynowego. Błąd. Im wyższy poziom języka, tym mniej wydajny kod... Wysokopoziomowy kompilator musiałby zbyt wiele 'zgadywać' i 'domyślać się', aby zamienić dwie linijki wysokopoziomowego kodu na najoptymalniejszą wersję asemblera.

    0
  • #19 31 Maj 2015 21:47
    atom1477
    Poziom 43  

    nsvinc napisał:
    Jak modyfikować surowe SFRy pod bascomem - nie wiem. Ale pewnie jakoś się da.

    Zupełnie prosto.
    SFR = Wartość
    np.
    PORTB = 255
    Rzecz jednak w tym że klasyczni BASCOMowcy nie uznają takich rzeczy i używają tylko wysokopoziomowych funkcji BASCOMa.
    To coś jak Arduino albo biblioteki SPL do STMa. I się ludzie którzy tego używają rękami i nogami bronią przed zwykłymi zapisami do rejestrów. Tylko używają durnych funkcji jakichś. I się potem dziwią że program wolno działa i zajmuje 10kB zamiast 4B.
    Ale nie znaczy to że pod BASCOMem się czegoś nie da zrobić.
    Dlatego też w pewnym sensie w BASCOMie też się da napisać dobry kod.
    nsvinc napisał:
    C jednak daje możliwość panowania w niemal 100% nad tym, co wykonuje rdzeń, i praktycznie 100% nad tym, co wykonują peryferia.
    Bez obrazy - ale piszą w bascomie, nie masz pojęcia co robi procek. Wydajesz mu tylko bardzo-wysokopoziomowy rozkaz i liczysz na to, że kompilator zamieni ten rozkaz na kawałek wydajnego kodu maszynowego. Błąd. Im wyższy poziom języka, tym mniej wydajny kod... Wysokopoziomowy kompilator musiałby zbyt wiele 'zgadywać' i 'domyślać się', aby zamienić dwie linijki wysokopoziomowego kodu na najoptymalniejszą wersję asemblera.

    I dlatego też nie powiedział bym że C będzie lepsze. Będzie równie dobre (jeżeli chodzi o panowanie nad prockiem). Bo nikt nie zmusza do korzystania z tych wysokopoziomowych funkcji BASCOMa, tak samo jak nie zmusza do stosowania SPLa na STMie.
    C będzie jedynie wygodniejsze w użyciu niż BASCOM (dokładniej niż kompilator BASCOMa, sam język jest równie dobry).
    Ale to tylko tak przy okazji piszę żeby uświadomić :D
    Żeby nikt nie zarzucał że chcę rozpocząć wojnę który język będzie lepszy, to od razu wyjaśnienie:
    Robię coś dokładnie odwrotnego. Chcę pokazać że oba języki są sobie równe.

    0
  • #20 31 Maj 2015 21:53
    jacynka84
    Poziom 26  

    Składnia C sprawia że mam nieudane myśli samobójcze na myśl o nauce C. Nie wspomnę o popieprzonych toolchainach i ich konfiguracjach.

    A samo DMA sprawia mi jakieś problemy, próbuję uruchomić przykład z sampli, z tą różnicą że adresem docelowym m być DAC, i nie widać zmian (wynik zamiast mierzyć wyswietlam na lcd).
    Nie wiem jak się ustawia te przerwania i co dokładnie mają robić.

    0
  • #21 31 Maj 2015 21:58
    tmf
    Moderator Mikrokontrolery Projektowanie

    Kolega @nsvinc właściwie trafił ze swoimi wyjaśnieniami w 100%. Drobna różnica jest taka, że powiązanie DMA z SPI dokonuje się w rejestrach kontrolera DMA. Wybiera się, że triggerem dla transferu DMA ma być zdarzenie generowane przez SPI. Wtedy za każdym razem, gdy zwolni się miejsce w buforze SPI, wyzwalany jest transfer DMA (DMA musi pracować w trybie single shot). Dzięki temu uzyskamy ciągły strumień danych na SPI i maksymalną szybkość nadawania. To, że kol. @jacynka84 ma tylko 440 kHz na SPI nie wynika ze złej konfiguracji tego interfejsu, lecz z tego, że zegar SPI jest generowany tylko w czasie transferu. Można to zinterpretować tak, że SPI jest taktowany np. 16 MHz, a skoro zegar efektywnie wynosi tylko 440 kHz to znaczy, że interfejs wysyła bajt danych, a następnie bardzo długo czeka na kolejny bajt.
    Jeszcze jedna uwaga a propos DMA - jeśli po SPI tylko chcesz nadawać, to możesz zignorować odbierane bajty. Dlatego nie trzeba pod odbiór podpinać DMA, czyli jeden kanał wystarczy.
    Także podsumowując, odpowiednio napisany program umożliwia bezproblemowe osiągnięcie pokazanych efektów. Z DMA jest po prostu łatwiej, bez DMA trzeba staranniej pisać kod, przeplatając wysyłkę danych przez SPI z obliczeniami.

    Dodano po 3 [minuty]:

    jacynka84 napisał:
    Składnia C sprawia że mam nieudane myśli samobójcze na myśl o nauce C. Nie wspomnę o popieprzonych toolchainach i ich konfiguracjach.

    A samo DMA sprawia mi jakieś problemy, próbuję uruchomić przykład z sampli, z tą różnicą że adresem docelowym m być DAC, i nie widać zmian (wynik zamiast mierzyć wyswietlam na lcd).
    Nie wiem jak się ustawia te przerwania i co dokładnie mają robić.


    Jaka konfiguracja toolchaina? Instalujesz Atmel Studio i jedyną rzeczą, którą konfigurujesz to decyzja czy budujesz Debug, czy Release i ustawiasz F_CPU. IMHO składnia jest logiczniejsza, niż jakieś bascomowe zaklęcia, popróbuj trochę C, szybko się przekonasz, że jest lepiej.

    0
  • #22 31 Maj 2015 22:18
    nsvinc
    Poziom 35  

    atom1477 napisał:
    Ale nie znaczy to że pod BACOMem się czegoś nie da zrobić.
    Dlatego też w pewnym sensie w BASCOMie też się da napisać dobry kod.

    Nie stwierdziłem, że się nie da :) Widziałem kilkanaście lat temu w QBASIC'u dobre kody, i złe kody. Nie ważny jest język - ważny jest programista ;]

    atom1477 napisał:
    I dlatego też nie powiedział bym że C będzie lepsze. Będzie równie dobre (jeżeli chodzi o panowanie nad prockiem). Bo nikt nie zmusza do korzystania z tych wysokopoziomowych funkcji BASCOMa, tak samo jak nie zmusza do stosowania SPLa na STMie.

    Skoro tak, to tym bardziej obowiązuje powyższe stwierdzenie.
    Serio, bascoma dotykałem ostatni raz jakieś 9 lat temu i odkąd zacząłem pisać w C, już chyba nie znajdę drogi powrotnej :D Ale skoro sam bascom daje możliwość operacji na SFRach, to w gruncie rzeczy da się w nim napisać wszystko, i to tak, żeby kod był wydajny.

    Dodano po 15 [minuty]:

    tmf napisał:
    To, że kol. @jacynka84 ma tylko 440 kHz na SPI nie wynika ze złej konfiguracji tego interfejsu, lecz z tego, że zegar SPI jest generowany tylko w czasie transferu. Można to zinterpretować tak, że SPI jest taktowany np. 16 MHz, a skoro zegar efektywnie wynosi tylko 440 kHz to znaczy, że interfejs wysyła bajt danych, a następnie bardzo długo czeka na kolejny bajt.


    Trochę podejrzane, patrząc na przytoczony kod. Kol. jacynka84 nie wspomniał o jakichkolwiek przerwaniach, więc odrzucam możliwość długich ISRów zakłócających przepływ podanej pętli wysyłającej dane po SPI. Dziwne jest, że rdzen na obsługę pętli i zagnieżdzonej pętli czekającej na bit, marnuje aż tyle czasu.

    tmf napisał:
    Jeszcze jedna uwaga a propos DMA - jeśli po SPI tylko chcesz nadawać, to możesz zignorować odbierane bajty. Dlatego nie trzeba pod odbiór podpinać DMA, czyli jeden kanał wystarczy.

    Plus dla designerów krzemu - w STM32 i większości LPC, SPI odmawia wysyłki gdy bufor odbioru jest zapełniony. Dopiero w LPC8xx da się ignorować odbiór...

    tmf napisał:
    IMHO składnia jest logiczniejsza, niż jakieś bascomowe zaklęcia, popróbuj trochę C, szybko się przekonasz, że jest lepiej.

    Popieram absolutnie. Chociaż, jak wspomniał atom1477 i w bascomie można. Tylko zamiast uczyc się helpa do bascoma, trzeba nauczyć się manuala do procka. I rozmawiać bezpośrednio z prockiem, bez udziału złodziejskiego (pod względem wydajności) pośrednika...

    0
  • #23 31 Maj 2015 22:23
    jacynka84
    Poziom 26  

    tmf napisał:
    440 kHz to znaczy, że interfejs wysyła bajt danych, a następnie bardzo długo czeka na kolejny bajt.
    Też tak właśnie myślę, tylko czy wtedy DMA coś da? No bo Co tyle mu zajmuje, i to podczas pojedynczej pętli "For"? Jeśli tyle mu zajmuje uaktualnienie danych czy cokolwiek innego to czy Wtedy nie będzie tak że będę miał te odświeżanie ale tymi samymi danymi?

    0
  • #24 31 Maj 2015 22:32
    tmf
    Moderator Mikrokontrolery Projektowanie

    Procesor robi to co mu napiszesz... DMA umożliwi ci nieprzerwaną transmisję danych - jeśli tylko np. zmieniasz kolor na jednolity, to wysyłasz np. 24 bitowe ciągi, DMA zrobi to z maksymalną dostępną szybkością interfejsu SPI, czyli dla XMEGA 16 Mbps, czyli 2 MB/s. Czemu u ciebie wysyłka danych trwa tak długo nie wiem, nie znam bascoma. Przejrzyj wygenerowany kod asemblerowy to sprawa się wyjaśni - zobaczysz jak tłumaczona jest stworzona przez ciebie pętla. Niemniej jeśli na poważnie chcesz zająć się LCD TFT to porzuć bascoma, nie dlatego, że coś się nie da, ale ze względu na jego narzuty. Nawet jeśli wszystko osiągniesz SFRami, to porównaj na ile instrukcji tłumaczone są np. obliczenia w bascomie i w C. Kompilator c jest po prostu wydajniejszy. Oczywiście można robić wstawki asemblerowe, ale nie po to się pisze w języku wyższego poziomu, żeby 50% kodu było w asemblerze :)

    0
  • #25 31 Maj 2015 22:33
    atom1477
    Poziom 43  

    No właśnie ta pętla For tyle zajmuje. To jest jedna z wad kompilatora BASCOMa (a nie samego języka BASCOM). Nieoptymalizowany dostęp do zmiennej licznikowej. Pętla za każdym razem ładuje zmienną z RAMu (16-bitową) i ją sprawdza (porównuje do stałej też 16-bitowej). Potem zwiększa i zapisuje z powrotem do RAMu.
    W C pobrana była by raz i nie była by porównywana do stałej, lecz zmniejszana i porównywana do 0. Mniej transferów danych i mniej porównywania.
    Ale i w C trochę cykli by to musiało zająć. Zysk w stosunku do BASCOMa był by raczej symboliczny. Same operacje na zmiennych (pobranie z pamięci) zajmą z 16 cykli a to drugie tyle co zajmie transfer po SPI.
    Kiedyś sobie napisałem taki "optymalizator" BASCOMa. Czyli nazwijmy to prekompilator który kompilował wstępnie to co BASCOM kompiluje wyjątkowo źle. Wstawiał to do kodu jako wstawki assemblerowe i to potem kompilowałem już dalej normalnie oryginalnym kompilatorem BASCOMa. I dawało to znaczny wzrost szybkości i zmniejszenie ilości zajmowanej pamięci.
    Ale to kombinowanie na maxa.
    Tak więc jak pisałem, języki są sobie równe.
    Ale kompilatory już nie. I dlatego też bym polecał przejście na C.

    0
  • #26 31 Maj 2015 22:34
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    Też tak właśnie myślę, tylko czy wtedy DMA coś da?

    Musi coś dać - co w efekcie obecnie robi rdzen?
    -2) Rn=adres bazy tablicy
    -1) Rm=0
    0) wez bajt z Rn+Rm i wsadz do Rp
    1) zapis bajtu z Rp do SFRa
    2) odczyt SFRa do Rq
    3) test bitu w Rq
    4) jeśli bit zgaszony, idz do 2.
    5) zgas flage w SFRrze
    6) Rm=Rm+1
    7) jeśli Rm<wielkosc_tablicy idz do 0.

    DMA zaoszczędza ci tego typu operacji. Rdzeń będzie robił sobie cośtam, a o cały ten bajzel będzie się martwić logika DMA...

    PS. W rozpisie mogę się lekko mylić; podany control dotyczy architektury load-store, a o ile się nie mylę, to AVR do nich należy ;] I nie jest to też najoptymalniejsza wersja; chociażby Rn mógłby być inkrementowany bezposrednio, bez operacji typu Rp=[Rn+Rm]

    0
  • #27 31 Maj 2015 22:44
    jacynka84
    Poziom 26  

    Na razie musze zmusić DMA w ogóle do działania bo mam wrażenie że nie coś nie działa, zapewne przez brak jakiegoś przerwania.

    0
  • #28 31 Maj 2015 22:46
    nsvinc
    Poziom 35  

    jacynka84 napisał:
    zapewne przez brak jakiegoś przerwania.

    Do pracy DMA nie potrzebujesz przerwań. Podsystem przerwań jest zawsze oddzielny i niezależny od surowej pracy peryferiów... [przewaznie. stm32f1 potrafi odstawić numery, na szczęscie nie dotyczy to DMA...]

    0
  • #29 31 Maj 2015 22:47
    atom1477
    Poziom 43  

    DMA może działać bez przerwań. Pokaz kod na którym testujesz.

    0
  • #30 31 Maj 2015 22:48
    jacynka84
    Poziom 26  

    Wezmę w klasyczny w pętli sposób ładował coraz większą wartość do DAC i zobaczę miernikiem częstotliwości czy działa, potem to samo ale za pomocą samplowego DMA.
    Różne kody próbuję i na razie nic.

    0
TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo