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

STM32F4 - Używanie funkcji API znacznie wydłuża czas wykonywania programu... ?

09 Sie 2012 10:59 2775 20
  • Poziom 13  
    Witam, problem i zarazem pytanie jak w temacie. Napisałem funkcję obsługi 1-wire z wykorzystaniem bibliotek API STM32 do komunikacji z czujnikiem temperatury DS1820. Funkcja wywoływana jest w przerwaniu od timera. Nie było z nią problemów gdy rdzeń STM-a pracował częstotliwością 168 MHz, przy niższych wstępowały błędy komunikacji. Podejrzewałem, że timer który został użyty do generowania precyzyjnie odmierzonych opóźnień, taktowany jest inną częstotliwością niż zakładam, ale po sprawdzeniu ustawień w pliku system_stm32f4xx.c i godzinach kombinowania doszedłem do wniosku, że winą może być zbyt długie wykonywanie funkcji obsługi 1-wire przy niższej częstotliwości taktowania rdzenia. Po zastąpieniu funkcji API operacjami bezpośrednio na rejestrach mikrokontrolera sytuacja uległa poprawie. Szacuje, na podstawie ustawień preskalera timera który generuje opóźnienia dla magistrali 1-wire, że czas wykonywania tej prostej funkcji skrócił się ok 35%. Czy ktoś ma jakiekolwiek doświadczenia w tym temacie?
    Ile cykli zajmuje wykonanie instrukcji takich jak while, for, if, przy parametrach podanych bezpośrednio? Ile cykli zajmuje wywołanie funkcji w programie? Jaki wpływ ma na to optymalizacja kodu przez kompilator?
    Więcej pytań nie pamiętam :-)
  • Computer Controls
  • Poziom 12  
    Dołączam się do tematu. Jak uruchamiałem komunikację 1-wire na STM32F103 bez użycia timerów (opóźnienia odmierzane pętlą FOR), również spotkałem się z problemami różnych czasów wykonania funkcji opóźniającej. Opóźnienia początkowo skalibrowałem za pomocą analizatora logicznego/oscyloskopu.
    Po użyciu nowszego kompilatora lub zmianie optymalizacji kodu, kalibracje musiałem przeprowadzać ponownie (bez kalibracji komunikacja z DS1820 nie była możliwa).
  • Poziom 27  
    No czego się spodziewasz od opóźnień generowanych za pomocą pętli for... i to jeszcze do onewire, gdzie te czasy są kluczowe.
  • Computer Controls
  • Poziom 13  
    @emk generowanie opóźnień programowo nie jest dobrym pomysłem, tym bardziej gdy precyzja jest wymagana tak jak w 1-wire. Co prawda jest pewien margines błędu, ale lepiej wykorzystać do tego timer. W STM-ach ich nie brakuje :-)
  • Specjalista - Mikrokontrolery
    dyzma_s napisał:
    Szacuje, na podstawie ustawień preskalera timera który generuje opóźnienia dla magistrali 1-wire, że czas wykonywania tej prostej funkcji skrócił się ok 35%

    No niemożliwe! Funkcje z biblioteki SPL nie są cudowne, najlepsze i niezastąpione?

    Hint - było.

    4\/3!!
  • Poziom 13  
    Zawiodłem się- nie ukrywam. Mimo tego nie zaprzestane z nich korzystać, bo np. przy konfiguracji peryferiów są bardzo przejrzyste. Po za tym trzeba zmienić podejście do programowania...
    Chciałbym wiedzieć z czego to wynika, czy tak duże opóźnienia powstają na skutek częstego wywoływania funkcji API STM32?
  • Specjalista - Mikrokontrolery
    Wynika to z tego, że te biblioteki są B-E-Z-N-A-D-Z-I-E-J-N-E, a wszyscy się nimi właśnie tak zachwycają, rękami i nogami bronią się przed ich porzuceniem, że po prostu firma ST odniosła na tym polu niebywały sukces.

    4\/3!!
  • Poziom 12  
    stanleysts napisał:
    No czego się spodziewasz od opóźnień generowanych za pomocą pętli for... i to jeszcze do onewire, gdzie te czasy są kluczowe.

    Akurat liczyłem się z faktem ponownej kalibracji opóźnienia po zmianie sposobu optymalizacji. Natomiast rzeczywiście byłem trochę zaskoczony, że nowsza wersja kompilatora również tego wymagała. Ale to świadczy o tym, że ktoś zauważył istnienie możliwości polepszenia nawet prostej pętli for.

    Dyzma_s, jak sam napisałeś użycie timerów też nie jest takie pewne. Użycie timera planuje..ale nie jest to dla mnie priorytetem skoro obecnie nie mam problemów z tą funkcjonalnością.
  • Specjalista - Mikrokontrolery
    emk napisał:
    Dyzma_s, jak sam napisałeś użycie timerów też nie jest takie pewne. Użycie timera planuje..ale nie jest to dla mnie priorytetem skoro obecnie nie mam problemów z tą funkcjonalnością.

    Bardzo błędny wniosek. "Nie takie pewne" to jest użycie funkcji z SPL, użycie timera akurat jest pewne w 100%, tylko trzeba nad nim panować, a nie zdawać się na łaskę funkcji napisanych na kolanie i zachwalanych jako najlepszy kod pod słońcem.

    4\/3!!
  • Poziom 13  
    Freddie Chopin ma rację, użycie timerów jest pewne, stabilne i nie zależy od kompilatora, ale trzeba nad nimi panować.
    Niektórzy piszą o bibliotekach SPL tak jakby krzywdę im zrobiła. Fakt krzywdą może być stracony czas poświęcony na szukanie przyczyny błędnego działania programu, która może leżeć właśnie w SPL, ale trzeba przyznać, że sam pomysł stworzenia jednolitego API dla programisty układów STM jest dobrym pomysłem. Cóż, wykonanie nie jest już tak dobre.
  • Poziom 27  
    Cytat:
    Chciałbym wiedzieć z czego to wynika, czy tak duże opóźnienia powstają na skutek częstego wywoływania funkcji API STM32?


    Przecież te funkcje wywołują się tak jak są zaimplementowane w kodzie więc trochę nie rozumiem toku myślenia, poza tym to dlatego działają wolniej bo są pisane nie optymalnie ale bardziej pod kątem przejrzystości (hm, ale czy aby napewno), w każdym razie taki był zamysł.

    Przykład: chcesz ustawić bit jakiś na porcie, normalnie patrzysz w datasheet i piszesz:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    ale jak chcesz już skorzystać z API, to wtedy znajdujesz funkcję:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    o wnętrzu:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Różni się czymś? No choćby tym, że trzeba wejść do funkcji etc a to kosztuje czas.
  • Poziom 12  
    Freddie Chopin napisał:
    Bardzo błędny wniosek. "Nie takie pewne" to jest użycie funkcji z SPL, użycie timera akurat jest pewne w 100%, tylko trzeba nad nim panować,

    Ja nie neguję zalet timerów :| Natomiast twierdzę, że w niektórych zastosowaniach można ich użycie obejść.

    Natomiast trzeba tutaj podkreślić, że funkcje konfiguracji timera oraz kod w obsłudze przerwania od timera, może być wykonywany w różnych ilościach cykli pracy zegara w zależności od użytego kompilatora (faktem jest, że użycie bibliotek STM na pewno spowoduje znacznie większe rozbieżności).
  • Poziom 13  
    "kosztuje czas" - dobre określenie. Kosztuje i to jak się okazuje niemało. W funkcji obsługi przerwania i w funkcjach precyzyjnie odmierzających odstępy czasowe może mieć i ma niebagatelne znaczenie. Szczególnie przy niskich częstotliwościach rdzenia mikrokontrolera, np 16 MHz. Wiem to z doświadczenia.
    @emk Rozbieżności spowodowane użyciem timera i jego obsługi będą znacznie mniejsze niż przy zaimplementowaniu opóźnienia całkowicie programowego przy kompilacji różnymi kompilatorami.
  • Poziom 27  
    Wszystko na uC przecież kosztuje czas a to, że każdy ogarnięty przy generacji "dokładnych" odstępów czasu korzysta wyłącznie z timerów to świadczy o tym, że są one najlepszym rozwiązaniem. Kod w obsłudze przerwania ma być poprostu taki, żeby te różnice były niezauważalne.
  • Poziom 20  
    A ja tak się zastanawiam po co męczyć się z timerami skoro usart w trybie halfduplex sie do 1wire nadaje idealnie?
  • Poziom 27  
    Bo jak się zrobi dobrą bibliotekę do ONEwire z odpowiednią warstwą abstrakcji to nie trzeba potem na różne procki jej za bardzo modyfikować :D
  • VIP Zasłużony dla elektroda
    kriss68 napisał:
    A ja tak się zastanawiam po co męczyć się z timerami skoro usart w trybie halfduplex sie do 1wire nadaje idealnie?
    Bo USART może być potrzebny w projekcie np. do Modbusa ? ;)
  • Specjalista - Mikrokontrolery
    Tak samo jak z timerami w STM32 z UARTami też nie ma problemu - zwykle są dwa jak nie trzy - w tych najmniejszych, bo w tych większych to jest np 5, a w STM32F4 jest 6. Ciężko znaleźć zastosowanie dla tych nadmiarowych, a UART jest na 1wire lepszy niż timery, bo cały bit jest załatwiony sprzętem jednorazowo, a z timerem trzeba to robić na kilka etapów (3?).

    4\/3!!
  • VIP Zasłużony dla elektroda
    Przyznam się, że w sumie myślałem o niskobudżetowych ARM Cortex-M3 z innej stajni - LPC13XX... ;)
  • Poziom 20  
    stanleysts napisał:
    Bo jak się zrobi dobrą bibliotekę do ONEwire z odpowiednią warstwą abstrakcji to nie trzeba potem na różne procki jej za bardzo modyfikować :D
    A co ma użyty interfejs do abstrakcji? Przecież różnić będą się tylko funkcje wysyłające/odbierające bity oraz konfiguracja sprzętu. A nie trzeba się martwić o timingi, opóźnienia i można oprzeć wszystko tylko o przerwania. Jeśli możemy tylko poświęcić usarta to jest to najlepsza opcja.
  • Poziom 13  
    Temat zamykam, wszystko "jasne".