Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

STM32-problem z szybkością działania.

tadeek2 30 May 2012 16:51 5659 24
Computer Controls
  • #1
    tadeek2
    Level 11  
    Witam. Napisałem program na ATmega32 do obsługi wyświetlacza LCD. Ustawiłem częstotliwość układu na 8MHz. Wszystko działa. Teraz odpowiednio przerobiłem program i uruchomiłem go na STM32F100. Wyświetlacz działa wszystko jest wyświetlane ale dużo wolniej niż na Atmedze. Zastanawiam się dlaczego tak się dzieje.

    Wydaje mi się że zegar dobrze konfiguruje. Testowałem na migających diodach. Zmieniając częstotliwość zegara zmieniała się częstotliwość migania diodą. Natomiast obrazki na wyświetlaczu są wyświetlane dużo wolniej niż na Atmedze, nawet zwiększając zegar układu do maksymalnej częstotliwości: 24MHz.

    Czy ktoś wie jaka może być tego przyczyna??
  • Computer Controls
  • #2
    gaskoin
    Level 38  
    Musiałbyś pokazać kod, może z niego by się uzyskało odpowiedź.
  • #3
    tadeek2
    Level 11  
    Kod wydaje mi się nie istotny. Ponieważ mam też napisany program na obsługę innego wyświetlacza i jest ten sam problem.
    Jedyną istotną rzeczą w programie jest funkcja konfiguracji zegara:

    Code: c
    Log in, to see the code


    Słyszałem teorie że to JTAG może spowalniać układ i należy go wyłączyć.
    Co o tym sądzicie i jak można go ewentualnie wyłączyć ??
  • Computer Controls
  • #4
    Freddie Chopin
    MCUs specialist
    tadeek2 wrote:
    Kod wydaje mi się nie istotny.

    W takim razie myślę że można spokojnie założyć, że Twój problem też jest nieistotny.

    tadeek2 wrote:
    Słyszałem teorie że to JTAG może spowalniać układ i należy go wyłączyć.

    Bzdura.

    4\/3!!
  • #5
    tadeek2
    Level 11  
    Wydawało mi się że problemem jest jedynie kwestia złego konfigurowania układu.

    A jeśli chodzi o kod programu to uproszczę sprawę. Zrobiłem teraz następujący test:
    Na Atmedze i STM program wykonuje jedynie pętle while:

    Code: c
    Log in, to see the code


    gdzie delay() zdefiniowano:

    Code: c
    Log in, to see the code

    //makrodefinicja
    Code: c
    Log in, to see the code

    //--------

    konfiguracja pinu:
    GPIO_InitTypeDef GPIO_InitStructure;
    RCC_APB2PeriphClockCmd(LED_RCC , ENABLE);
    GPIO_InitStructure.GPIO_Pin = LED;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LED_GPIO, &GPIO_InitStructure);

    konfiguracja zegara:
    Code: c
    Log in, to see the code


    Atmega i STM mają ustawiony zegar na 8MHz. Problem jest taki że dioda na STM miga dużo wolniej.
  • #6
    gaskoin
    Level 38  
    tadeek2 wrote:

    RCC_PLLConfig(RCC_PLLSource_PREDIV1, RCC_PLLMul_4); // PREDIV1 dla HSE.


    Jeśli PREDIV1 (bo biblioteka jest z kosmosu) oznacza, że nie dzielisz zegara a PLLMul_4 oznacza, że mnożysz go razy 4 to znaczy, że PLL działa na 16 MHz () a nie jak założyłeś na 8. Poza tym dałeś preskaler na AHB, więc wszystko działa 2x wolniej.

    ----


    Zmieniłeś kod, więc już się nie ma co dziwić, czemu wszystko działa wolniej :) PLL na 8MHz a całe AHB na 4MHz. Nawet jak ustawisz sysclk na 24MHz to cała reszta działa na 12MHz. Pozatym, taki "benchmark" jest o kant tyłka ...
  • #7
    tadeek2
    Level 11  
    W końcu doszedłem do tego co było nie tak z tym testem na diodzie.

    pętla dla atmegi musi wyglądać tak:

    Code: c
    Log in, to see the code


    a dla STM:

    Code: c
    Log in, to see the code


    Atmega wykonuje operacje na zmiennych typu int 2x wolniej niż na char. Natomiast STM nie lubi działać na zmiennych typu char.
    W ten sposób uzyskuje na STM:
    8MHz dla RCC_SYSCLK_Div2 i RCC_PLLMul_2 pozostałe parametry bez zmian
    8MHz dla RCC_SYSCLK_Div8 i RCC_PLLMul_8 pozostałe parametry bez zmian
    16MHz dla RCC_SYSCLK_Div1 i RCC_PLLMul_2 pozostałe parametry bez zmian
    16MHz dla RCC_SYSCLK_Div4 i RCC_PLLMul_8 pozostałe parametry bez zmian

    czyli zegar dobrze konfiguruje a w programie mam coś nie tak. Jeszcze dziś umieszczę ten program tu
  • #8
    Freddie Chopin
    MCUs specialist
    tadeek2 wrote:
    Natomiast STM nie lubi działać na zmiennych typu char.

    Dla STM32 nie ma znaczenia czy zmienna ma 8-, 16- czy 32-bity...

    tadeek2 wrote:
    8MHz dla RCC_SYSCLK_Div2 i RCC_PLLMul_2 pozostałe parametry bez zmian

    Możesz zdradzić nam powód, który każe Ci ustawiać dzielnik dla najszybszej i najważniejszej magistrali w tym układzie na jakąkolwiek inną wartość niż 1? Nie dziw się, że coś działa wolno, skoro zwalniasz (niepotrzebnie) najistotniejszą magistralę... Pozatym Twoje rozumowanie jest całkowicie błędne, bo zegar AHB nie jest zegarem rdzenia.

    tadeek2 wrote:
    8MHz dla RCC_SYSCLK_Div8 i RCC_PLLMul_8 pozostałe parametry bez zmian

    Jeśli faktycznie pomnożyłeś częstotliwość kwarcu przez 8 bez dzielnika przed PLL, to ten układ nie powinien w ogóle działać dla takich parametrów, bo częstotliwość wyjściowa PLL musi być w zakresie 16-24MHz.

    4\/3!!
  • #9
    markosik20
    Level 33  
    tadeek2 wrote:

    pętla dla atmegi musi wyglądać tak:.......


    Mając tyle dostępnych timerów w STM32 robienie pętli opóźniającej w tak prymitywny sposób woła o "pomstę do nieba" :)
  • #10
    tadeek2
    Level 11  
    Też mi się wydawało że dla STM32 nie ma różnicy między zmienną 8 i 16 bitową ale dioda wyraźnie z mniejszą częstotliwością migała stąd takie konkluzje.


    W jaki sposób mam skonfigurować zegar żeby uzyskać prędkość działania STM32 podobną do np. atmega32 z ustawioną częstotliwością 8 albo 16MHz. No chyba że nie da się porównać tego tak łatwo i ustawienie na STM32 'RCC_SYSCLK_Div1 i RCC_PLLMul_2 pozostałe parametry bez zmian' wcale nie oznacza że układ(program) będzie działać z taką samą szybkością jak atmega32 z kwarcem 16MHz.
  • #11
    Freddie Chopin
    MCUs specialist
    tadeek2 wrote:
    W jaki sposób mam skonfigurować zegar żeby uzyskać prędkość działania STM32 podobną do np. atmega32 z ustawioną częstotliwością 8 albo 16MHz. No chyba że nie da się porównać tego tak łatwo i ustawienie na STM32 'RCC_SYSCLK_Div1 i RCC_PLLMul_2 pozostałe parametry bez zmian' wcale nie oznacza że układ(program) będzie działać z taką samą szybkością jak atmega32 z kwarcem 16MHz.

    Jak w traktorze i Ferrari będziesz miał 3000 obrotów na 3 biegu to jednak nie jadą tak samo szybko, no nie? Więc zacznij może od zdefiniowania, czy "tak samo szybko" ma działać układ czy program no i może przedewszystkim zacznij od tego co tak naprawdę chcesz sprawdzić... Bo STM32 jest szybszy od Atmegi spokojnie o rząd wielkości, ale nie dlatego, że jest 10x szybszy zegarem...

    4\/3!!
  • #12
    LordBlick
    VIP Meritorious for electroda.pl
    Taki przykład porównawczy - szpadlem macha się z reguły szybciej, niż koparka wykonuje cykl (wybranie - wysypanie) łyżką, mimo to koparka jest efektywniejsza...
    Takie teoretyzowanie na temat szybkości uważam za bezprzedmiotowe. Bez całego kodu, a czasem i schematu, to tylko gdybanie...
    Procedura obsługi LCD może być niedostosowana do architektury i stąd może wynikać problem. Złe nawyki programisty pozostaną złymi nawykami niezależnie od procesora. Piję tu głównie do używania takiego koszmarka jak delay() i to nie odnoszącego się do F_CPU plus ustawienia konfiguracyjne zegara. Timery proszę pana, timery...
  • #13
    gaskoin
    Level 38  
    Bzdury piszecie, nie ma lepszego banchmarka niż miganie diodą.
  • #15
    tadeek2
    Level 11  
    Poniżej program do obsługi wyświetlacza TFT:

    Interesuje mnie dlaczego funkcja LCD_Clear(WHITE) na STM32 działa wolniej niż na Atmedze32 z kwarcem 16MHz. Wydawało mi się że powinno czyścić ekran szybciej na STM32 a już na pewno nie wolniej.

    Tylko nie zwracajcie mi uwagi na temat pętli opóźniającej;) ponieważ i tak nie jest wykorzystywana w LCD_Clear.

    main:

    Code: c
    Log in, to see the code


    LCD_ILI9325.c (umieszczam tylko część istotną dla tego problemu)
    Code: c
    Log in, to see the code


    LCD_ILI9325.h
    Code: c
    Log in, to see the code


    konfiguracja.h - definicja wyprowadzeń:
    Code: c
    Log in, to see the code
  • #16
    LordBlick
    VIP Meritorious for electroda.pl
    Tak na prawdę w tym przypadku trzeba by przeanalizować pliki lss, aby porównać, czy np. przypadkiem wywołania dla linii danych wyświetlacza dla AVR nie są bardziej optymalizowane do wysłania całego bajtu jednym opkodem, a w ARM nie dłubie bit po bicie.
  • #18
    LordBlick
    VIP Meritorious for electroda.pl
    No jeśli tak jest, to podejrzewam, że ustawienie każdego bitu polega na pobraniu zawartości, przemaskowaniu i zapisaniu z powrotem razy każda linia...
  • #19
    tadeek2
    Level 11  
    Jeśli dobrze rozumie to nawet jeśli w programie ustawiałbym całą linie danych za jednym razem to i tak port STM32 jest ustawiany bit po bicie. Natomiast w AVR może być ustawiany 8 bitów jednocześnie?

    Wprowadzę wyżej wymienioną zmianę i zobaczymy co z tego wyjdzie.
  • #20
    markosik20
    Level 33  
    Już kiedyś na forum dyskutowano nt. szybkości bezpośredniej obsługi pinów w STM32 i AVR.... i z tego co pamiętam AVR pod tym względem potrzebował mniej cykli zegara. Druga sprawa jest taka że Twój kod w ogóle nie jest napisany pod kątem szybkości działania, nie wspominając już że pewnie w newralgicznych momentach korzystasz z tej "szybkiej i cudownej" biblioteki "stm32f10x_stdperiph_lib" :)
  • #21
    Freddie Chopin
    MCUs specialist
    tadeek2 wrote:
    Jeśli dobrze rozumie to nawet jeśli w programie ustawiałbym całą linie danych za jednym razem to i tak port STM32 jest ustawiany bit po bicie. Natomiast w AVR może być ustawiany 8 bitów jednocześnie?

    Że co?

    4\/3!!
  • #22
    gaskoin
    Level 38  
    Kolega pewnie zrozumiał, że przy takim zapisie:

    REJESTR = 0xe43432.

    ARM jedzie bit po bicie a AVR wstrzykuje całą wartość w ciągu pół taktu zegarowego ;)
  • #23
    tadeek2
    Level 11  
    Może trochę źle się wyraziłem ale zrozumiałem to tak że w STM32 instrukcja GPIOA->ODR = 0x44(czyli ustawienie na pinach odpowiednich stanów) może wykonywać się dłużej niż PORTB = 0x44 w AVR
  • #25
    tadeek2
    Level 11  
    Wnioski ogólne: ustawianie pinów GPIO w STM trwa dłużej niż w przypadku AVR stąd ogólne wrażenie że cały program wykonuje się wolniej.

    Temat zamknięty