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

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??

Musiałbyś pokazać kod, może z niego by się uzyskało odpowiedź.

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:



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ć ??

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!!

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:



gdzie delay() zdefiniowano:


//makrodefinicja

//--------

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:


Atmega i STM mają ustawiony zegar na 8MHz. Problem jest taki że dioda na STM miga dużo wolniej.

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 ...

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:



a dla STM:



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

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!!

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"

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.

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!!

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...

Bzdury piszecie, nie ma lepszego banchmarka niż miganie diodą.

Ja tam uznaję za benchmark ilość obiegów pętli głównej na sekundę, podawane transmisją szeregową...

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:



LCD_ILI9325.c (umieszczam tylko część istotną dla tego problemu)


LCD_ILI9325.h


konfiguracja.h - definicja wyprowadzeń:

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.

ARM dłubie bit po bicie, co niekoniecznie jest najmądrzejszym rozwiązaniem, bo zarówno odczyt jak i zapis do rejestrów układów peryferyjnych trwa zwykle ponad jeden cykl.

4\/3!!

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...

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.

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"

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!!

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

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

No i tak właśnie jest, ale nie dlatego że działa to po jednym bicie, tylko dlatego że dostęp do tego obszaru adresowego trwa więcej niż jeden cykl zegara.

4\/3!!

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