STM32F0 wolniejszy niż PIC32MX - jak poprawić wydajność?

Portuję projekt z PIC'a (32MX) na STM'a (F0) i mam problem z wydajnością. Szybkość zegarów jest taka sama.
Mimo włączonej w kompilatorze maksymalnej optymalizacji program działa zauważalnie wolniej niż na PIC, gdzie był kompilowany w darmowej wersji XC32 (czyli z najsłabszą optymalizacją -o1). Mam przez to problemy z wyrobieniem się z obsługą zadań podczas przerwania timera.
Mam wrażenie, że STM kuleje w porównaniu z PIC w przypadku odczytu tablic stałych z flash.

Czy ktoś może zasugerować jakieś poprawki w konfiguracji samego procka (startup), które wpłyną na wydajność? Gdzie to ewentualnie zmieniać?

ZAWSZE wkleja się kod programu przy takich pytaniach.

excray napisał:

ZAWSZE wkleja się kod programu przy takich pytaniach.

Obawiam się, że tysięcy linijek i tak nikt nie będzie czytał.

Pytanie jest dość ogólne, czy ktoś wie, czy można wycisnąć z tego STM'a coś więcej poprzez zmiany w konfiguracji samego procesora?

To po co w ogóle wygenerowałeś ten temat? Nikt tutaj nie będzie wróżyć z fusów co źle zrobiłeś w swoim kodzie.

excray napisał:

To po co w ogóle wygenerowałeś ten temat? Nikt tutaj nie będzie wróżyć z fusów co źle zrobiłeś w swoim kodzie.

Nie chodzi o wróżenie z fusów tylko konkretną odpowiedź, jakie są możliwości konfiguracji rdzenia by podnieść wydajność.

Testowałem w przypadku różnych programów i jak narazie STM jest zawsze słabszy od PIC'a. Może po prostu te rdzenie są wolniejsze niż M4K, czy ktoś na forum porównywał osobiście wydajności STM32F0 vs PIC32MX?

Witam. Na PIC'a (32MX) to mi się nie chce patrzeć ale zerknij tu:
https://en.wikipedia.org/wiki/ARM_Cortex-M do tabelki ARM Cortex-M instruction variations.
Na poprawę szybkości działania programu to proponuję lepiej napisać program lub zmienić procka na wydajniejszego.
Zrób test : na obu prockach zmierz czas wykonania miliona dzieleń / mnożeń liczb stałoprzecinkowych / zmiennoprzecinkowych

stmx napisał:

Przy tej samej prędkosci zegara PIC-e maję wolniejszy FLASH - przy 48MHZ PIC-e 2WS a F0 1WS. Tak że będą czytać stałe z FLASH wolniej.

oba procki chodzą na 24MHz, ze względu na pobór prądu

Na prośbę moderatora:
PIC32MX150, STM32F030K6T6

Tu prosta maszyna stanów - funkcja, która wykonuje się wolniej o jakieś 30...40% niż na PIC.

Uprzedzam, sprawdziłem, że nie jest to wina SPI ani funkcji processPacket().

stmx napisał:

co ma prędkość procesora do programu, który pewnie większość czasu spędza w pollingu:

Nie przeczytałeś mojego postu. Pisałem, że to nie to. Nawet zrezygnowanie z wywołania funkcji hwSpi() nie powoduje, że STM staje się nagle szybszy od PIC'a. Zresztą w wersji na PIC też mam to SPI, w dodatku zaimplementowane software'owo i wszystko się wyrabia (!).

Jeśli jesteś w stanie cokolwiek pomóc to napisz czy mam jakieś możliwości konfiguracji samego procesora/rdzenia/kompilatora (gcc -Os) by przy tym samym zegarze procesor działał szybciej.

djfarad02 napisał:

by przy tym samym zegarze procesor działał szybciej.

Sprawdzałeś czy na pewno STM jest taktowany 24MHz a nie przypadkiem wewnętrznym 8MHz?

stmx napisał:

gdzie tu przerwania timera?

cała funkcja jest wywoływana w przerwaniu 50us

stmx napisał:

Po co tyle volatile?

Może faktycznie za dużo. Poza tym, ten kod na pewno nie jest optymalny, lecz nie w tym rzecz.

LChucki napisał:

Sprawdzałeś czy na pewno STM jest taktowany 24MHz a nie przypadkiem wewnętrznym 8MHz?

Na pewno 24, zgadzają się częstotliwości generowane przez timery.

Z ciekawości dzisiaj przeprowadzę próby w "bardziej sterylnych" warunkach, dla jakiegoś czytelniejszego, krótszego kodu. Podam wyniki (czas wykonania funkcji) PIC vs STM.

Ciekawe czy ktokolwiek ogarnia tą "machinę stanów" na 322 linijkach, przy czym niektóre są "zwinięte"... (;

djfarad02 napisał:

Czy ktoś może zasugerować jakieś poprawki w konfiguracji samego procka (startup), które wpłyną na wydajność? Gdzie to ewentualnie zmieniać?

A masz włączony prefetch buffer?

Freddie Chopin napisał:

Ciekawe czy ktokolwiek ogarnia tą "machinę stanów" na 322 linijkach, przy czym niektóre są "zwinięte"... (;

Hehe, mam świadomość, że ten kod nadaje się jedynie do przepisania od nowa

Sareph napisał:

A masz włączony prefetch buffer?

Stworzyłem nowy projekt w Atollic TrueSTUDIO i jedyne co ustawiałem w programie to zegar, gpio, przerwania itp. Czego mam użyć (biblioteka, konfiguracja projektu), żeby kontrolować ustawienia tego bufora?

djfarad02 napisał:

...

Po inicjalizacji HAL, dodaj sobie:

Sareph napisał:

Po inicjalizacji HAL, dodaj sobie:

FLASH->ACR |= FLASH_ACR_PRFTBE;

Dziękuję za wskazówkę, jak na razie niestety nie spowodowało to przyspieszenia programu, będę próbował dalej.

stmx napisał:

Dokumentu co sie nazywa reference manual. A optymalizowanie to sie zaczyna od algorytmu a nie opcji kompilatora, ktore sa "wisienka na torcie"

Mam prośbę - nie pisz takich oczywistości. Co takiego wnosi Twój post? Jeśli nie chcesz pomóc nie pisz nic, temat będzie czytelniejszy.

Dodano po 1 [godziny] 3 [minuty]:

Postanowiłem zrobić porównanie tych dwóch rdzeni wykonując na nich abstrakcyjny kod pokazany poniżej:

STM:


PIC:


Oscylogramy są z podstawami czasu 5us/dz oraz 50ns/dz.
Ukazują one przebieg na pinie sterowanym z funkcji gpioDrive

Tym razem zegar 48MHz, kompilatory gcc i XC32

STM optymalizacja -O1





STM optymalizacja -O3 Bardzo ciekawe jest, że mimo ogólnie lepszej wydajności machanie pinem jest wolniejsze niż na O1




STM optymalizacja -Os





PIC optymalizacja -O1 (mam darmową wersję XC32)




Jak widać PIC jest zdecydowanie szybszy przy optymalizacji -O1, przy innych poziomach optymalizacji nie mogłem sprawdzić z racji posiadania darmowej wersji kompilatora.
Samo machanie pinem PIC robi o wiele szybciej.

Optymalizacja -Os na STM powoduje, że chodzi on wolniej niż -O1 na PIC'u

Naprawdę nie wiem co chcesz porównywać... Ten kod który pokazałeś, a który ma czegoś dowodzić, jest po prostu przykładem "jak tego nie robić". Wystarczy wspomnieć tylko te wszystkie pętle opóźniające bez volatile, które każdy normalny kompilator wywali w kosmos przy dowolnym poziomie optymalizacji.

Jak chcesz układ który superszybko macha pinami, to weź FPGA. Jeśli STM32F0 jest dla Ciebie zbyt wolny, to weź jakiś szybszy, albo popraw algorytm tak aby prędkość rdzenia nie była dla niego taka istotna. Warto zawsze przypomnieć, że Commodore 64 miał ~1 MHz, więc jeśli Twój soft nie jest bardziej skomplikowany niż dowolna gierka sprzed 30 lat, to znaczy że coś jest nie tak z algorytmem.

Freddie Chopin napisał:

Wystarczy wspomnieć tylko te wszystkie pętle opóźniające bez volatile, które każdy normalny kompilator wywali w kosmos przy dowolnym poziomie optymalizacji.

Bardzo dziękuję za zwrócenie na to uwagi, poprawiłem i czas wykonania funkcji speedTest() wynosi:

optymalizacja O1
PIC 110us
STM 160us

Po wywaleniu opóźnień while (d--) sytuacja wygląda tak jak w poprzednim poście (co tylko potwierdza błąd, na który zwróciłeś mi uwagę). Znowu PIC o wiele szybciej wystawia stany na port.

Zresztą nie chodzi o machanie pinami tylko ogólną szybkość wykonywania programu - stm działa mi wolniej i bardzo chcę wiedzieć dlaczego tak jest. Czy aż taka różnica może wynikać z kompilatorów?

F0 to układ w założeniu energooszczędny, prosty i tani. PIC32 zapewne taki nie jest i już.

Kiedyś odpalałem coś na próbę na STM32F103 i był ten sam problem - mniejsza wydajność niż na PIC. Zaczynam podejrzewać, że ta architektura jest po prostu wolniejsza.

Cortex M0 ma jakieś 0.93DMIPS/MHz, PIC32 ma z tego co kojarzę 1.5DMIPS/MHz, M3 ma 1.25DMIPS/MHz - doprawdy nie wiem czemu ktoś oczekiwał czegoś innego?

tronics napisał:

Cortex M0 ma jakieś 0.93DMIPS/MHz, PIC32 ma z tego co kojarzę 1.5DMIPS/MHz, M3 ma 1.25DMIPS/MHz - doprawdy nie wiem czemu ktoś oczekiwał czegoś innego?

Dziękuję, to wiele wyjaśnia... Szkoda, bo tanie te STM'y.

djfarad02 napisał:

Dziękuję, to wiele wyjaśnia... Szkoda, bo tanie te STM'y.

Jak F0 czy F1 za wolne to weź F4 albo H7.

@Marek_Skalski, @LChucki miło, że wzięliście udział w dyskusji.
Widzę, że nie ma dla mnie ratunku albo jest tylko jeden - walka z optymalizacją kodu, może się uda. Mówię tak, ponieważ te lepsze rodziny STM są za drogie do tego projektu.