CMSIS — część 4 — Debugowanie —

CMSIS — część 4 — Debugowanie —
Razem głosów: 17 co stanowi: 96.47% całości.

 

imgres

Heh… miałem już nic nie pisać w tym cyklu , ale jakoś tak zapomniałem że obiecałem napisać coś o debugowaniu w CMSIS …  zatem cóż się słowo rzekło trzeba się brać za pisanie o mechanizmie ITM, który zaiste jest ciekawe  …

Tak więc by wykonać debug w pewnym zakresie oczywiście korzystając z funkcji CMSIS  wystarczy np program z poprzedniej  części i dodajemy do  niego  komunikaty wyjściowe debugu  poprzez wywołanie puts(). Naszym zadaniem jest też przekierować dane wyjściowe „śledzenia” do naszego mechanizmu ITM (dla przypomnienia – Instrumentation Trace Macrocell)  — pamiętacie, że CMSIS zastrzega kanał 0 do tego celu ?? — używając do tego celu  funkcji CMSIS  ITM_SensChar().  Mechanizm zwany Retargeting  pozwala  wywoływać na niejako nasze własne żądanie wykonywanie funkcji systemu.

Fputc jest standardową funkcją języka C , która ostatecznie będzie się nazywać puts() w naszej obsłudze przerwania SysTick , a jej realizacja będzie wykorzystywać funkcje ITM_SendChar(), Wynik takiego retargetowania  może być łatwo monitorowany przez uVision czy inne środowisko :) Co zresztą widać na zrzucie poniżej.

Przechwytywanie W środowisku IAR EWARM  z kolei nie jest konieczne ręczne retargetowanie  tej funkcji ,  Wystarczy w oknie Opcji w ramach zakładki  General Options w sekcji Library
Configuration wystarczy włączyć SWO i Semihoosting :)  Co widać niżej:

Przechwytywanie

 


 

— PODSUMOWANIE 

Oczywiście w każdym środowisku jest nieco inaczej tu chciałem pokazać w tym cyklu jak znacznie ułatwia się programowanie z CMSIS, na przekór trochę zwolennikom rycia po rejestrach … bo przecież nic tym nie udowadniają, że jest lepiej, a standardy są postrzegane jako zło konieczne,  tymczasem chodzi głównie o zmniejszenie krzywej uczenia dla programistów aplikacji, zapewnienie spójnych ram oprogramowania,  zapewnienie spójności dokumentacji i łatwe wdrążanie kodu niezależnie od dostawcy kompilatora czy różnic w krzemie samego mikrokontrolera. Wiem, wiem że wielu na mnie naskoczy bo niema to jak bycie hardkorem i rycie dłutem w krzemie :)

Osoby te chyba nie chcą zrozumieć że konsekwentne wdrażanie i stosowanie CMSIS przez różnych producentów krzemu i oprogramowania middleware przez ich partnerów upraszcza znacznie proces weryfikacji i certyfikacji, a z kolei to zmniejsza przyszłe ryzyko projektu.  Dostosowanie wspólnych technik programowania poprzez CMSIS upraszcza utrzymanie długoterminowości sprzętu, ze względu na łatwiejszy do zrozumienia kod źródłowy i jego łatwą przenośność w obrębie wszystkich MCU  opartych o Cortex-M.

Producenci procesorów czy jak wolicie sprzedawcy krzemu mogą się skoncentrować na wartościach dodanych do mikrokontrolera fjuczerów w ramach rozwoju sprzętu zamiast tracić czas na oprogramowanie które znacznie podnosi koszty, a oszczędności te  zarówno finansowe jak i przede wszystkim czasowe mają korzystny wpływ na rozwój produktów dostępnych na rynku.

Zatem czy warto …. sami sobie odpowiedzcie …

Tymczasem to już naprawdę w tej formie na temat CMSIS wszystko.

 

Podziel się na:
  • Print
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Blogplay