Forum: Mikrocontroller und Digitale Elektronik Semihosting für ARM verwenden


von brechbunkt (Gast)


Lesenswert?

Hallo,

ich verwende einen CortexM3 und dort soll es durch "Semihosting" möglich 
sein mit über den Debugger mit dem PC kommunizieren zu können. Worum es 
überhaupt geht ist ganz gut auf der Seite von ARM beschrieben:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Bgbjjgij.html

Software:
Entsprechende lib für den Processor (STM32) liegt bereits der IDE 
(CooCox) bei.

Hardware:
Hardwareseitig ist auch die Leitung SWO verbunden, über die die Signale 
anscheinend gesendet werden.

Was ich allerdings nirgends finden kann ist, wie ich es überhaupt 
verwenden kann. Hat jemand Semihosting schon mal verwendet und könnte 
ein paar Tipps geben?

Danke.

von gerhard (Gast)


Lesenswert?

hallo,
der erste absatz der von dir zitierten arm-seite beschreibt doch den 
sinn von semihosting. was verstehst du daran nicht?

gruss
gerhard

von brechbunkt (Gast)


Lesenswert?

Danke für die Antwort.

Was der Sinn von Semihosting ist habe ich schon verstanden. Mir ist nur 
nicht klar was/wie ich machen muss um es nutzen zu können.

Wenn ich die existierende Library nutze und einfach vom uC aus einen 
test-string senden möchte, bleibt der Debugger in dieser Zeiler "hängen" 
und springt nicht weiter:
1
SH_DoCommand:
2
  BKPT 0xAB   /* Wait ICE or HardFault */

Am PC tut sich allerdings nichts.

von Ralf (Gast)


Lesenswert?

In den CodeRed-IDEs stellt man den Typ der Bibliothek ein und in 
Abhängigkeit davon erscheint dann bei nem printf, etc. eben was auf der 
IDE-internen Konsole.
Kannst du in Coocox den Libtyp beeinflussen?

Ralf

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

brechbunkt schrieb:
> Hardwareseitig ist auch die Leitung SWO verbunden, über die die Signale
> anscheinend gesendet werden.

Semihosting hat nichts mit SWO zu tun, sondern wird lediglich über 
JTAG/SWD abgewickelt. Die reine Ausgabe von Zeichen über SWO (ITM Kanal 
0) benötigt kein Semihosting. Dieser Mechanismus wird für komplexere 
Dinge verwendet, wie u.a. File I/O und String Funktionen auf Systemen 
die kein SWO haben.

von Moritz M. (moritz_m35)


Lesenswert?

Hallo,

du musst in der CoIDE in den Dubugger Einstellungen Semihosting 
einschalten und die entsprechene Lib über die Repoitory einbinden. Dann 
werden solche Funktionen wie putch, printf oder so bereitgestellt (Weiß 
grad nicht genau wie die heißen). In der CoIDE gibt es ein Fenster wo 
die Daten angezeigt werden und wo man Daten senden kann.

Moritz

von brechbunkt (Gast)


Lesenswert?

Super, danke euch für die vielen Tipps. Der Hinweis vom Moritz war es, 
warum es bei mir nicht ging. Ich hatte einfach übersehen, dass ich da 
noch ein Häkchen setzen muss:

Moritz M. schrieb:
> ...du musst in der CoIDE in den Dubugger Einstellungen Semihosting
> einschalten...

von brechbunkt (Gast)


Lesenswert?

Während dem Debuggen kann ich jetzt meine Textausgaben sehen. Sobald ich 
ohne Debugger neu-starte, "hängt" sich die Software allerdings wieder ab 
dem ersten Zeichen auf. Der Code läuft nun also nur noch im 
Debugger-Modus.

Ist das normal so? Wenn ja, könnte ich das einfach mit einem 
compiler-switch bzw. einem define umgehen. Ich bin mir nur nicht sicher 
ob das tatsächlich so von ARM gedacht sein sollte.

von W.S. (Gast)


Lesenswert?

brechbunkt schrieb:
> Was ich allerdings nirgends finden kann ist, wie ich es überhaupt
> verwenden kann. Hat jemand Semihosting schon mal verwendet und könnte
> ein paar Tipps geben?

Ich versteh nicht, was du daran nicht verstehst. Die ARM-Leute 
empfehlen, einfach für die betreffenden Funktionen einen SVC zu 
definieren. Dieser führt dann in eine Art Betriebssystem auf dem uC, wo 
sie dann entweder direkt und voll ausgeführt werden oder (=Semihosting) 
über irgend einen Kommunikationskanal auf einen PC geleitet wird, wo sie 
dann dort ausgeführt wird. Klingt kompliziert, ist es aber nicht.

Guck dir mal in der Codesammlung die Lernbetty an (mußt ein bissel nach 
unten paddeln). Dort kannst du sehen, wie die SVC (Supervisorcalls) 
realisiert sind. Beim Keil geht das direkt und so wie gedacht, bloß die 
GCC-Benutzer gehen leer aus, denn der GCC kann keine SVC's, da ist mal 
wieder Gebastel angesagt.

Beispiel:
Man will einen String auf dem Bildschirm ausgeben. Funktion dazu ist
int CgStr_at (int x, int y, char* P, word FontMode);

Bei der Lernbetty sieht das dann so aus:
__swi(19) int CgStr_at (int x, int y, char* P, word FontMode);

Anstelle eines Calls baut der Compiler einen Software-Interrupt mit der 
Nummer 19 in den Code ein. Dadurch landet die Ausführung in der 
BettyBase und wird dort so ausgeführt, daß der Text auf dem lokalen 
Bildschirm ausgegeben wird.

Beim Semihosting würde in der BettyBase ein Handler stehen, der die 
Argumente (X, Y, Text und Font+Farbe) z.B. über eine serielle Verbindung 
zum PC schickt, wo ein anderer Handler, der diese Nachricht versteht, 
selbige auf dem Bildschirm des PC (oder einem Fenster auf dem BS) 
ausgibt.

Nun alles klaro?

W.S.

von Peter (Gast)


Lesenswert?

Hallo Leute,
Bin schonmal gabzganz froh eure ubterhaltunUnterhaltung gefunden zu 
haben.
WeisWeiß jemand ob ich furfür printf in der coide auch swo 
venutzbenutzen kann? Benutze das gerne und viel in iar.
Hab ein stm32f4discovery dessen st-link debuggerDebugger ja einen swo 
trace eingangEingang hat.

Vielen Dank und Gruß

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

brechbunkt schrieb:
> Ist das normal so?

Ich denke schon, jedenfalls ist das bei mir auch so und woher soll die 
CPU wissen, ob ein Debugger angeschlossen ist?

brechbunkt schrieb:
> Wenn ja, könnte ich das einfach mit einem
> compiler-switch bzw. einem define umgehen.

So mache ich das im Moment auch. Falls also jemand einen Trick kennt, 
würde mir das auch helfen.

Peter schrieb:
> WeisWeiß jemand ob ich furfür printf in der coide auch swo
> venutzbenutzen kann?

Kaum zu lesen, die Frage. Ja, kann man. In der printf.c - so wie im 
Kommentar beschrieben - die Funktion "SH_SendChar()" aus der 
semihosting.c ergänzen:
1
void PrintChar(char c)
2
{
3
  /* Send a char like: 
4
     while(Transfer not completed);
5
     Transmit a char;
6
  */  
7
  SH_SendChar(c); // !!! hier ergänzen !!!
8
}

In der ARM-Doku steht:

> Using Multi-ICE standard semihosting with systems that include
> time-sensitive interrupt-driven software is not recommended. The
> processor must be halted while a semihosting operation is performed,
> and so interrupts will be missed. Use DCC semihosting or ARM
> RealMonitor to debug these systems.

Bei mir flackert das LED-Display, weil DMA1_Channel4_IRQHandler() nicht 
aufgerufen wird, wenn ich printf(…) benutze.

Hat schon mal jemand dieses "Debug Communications Channel Semihosting" 
mit CoIDE oder Em::Blocks benutzt? Wie würde das damit gehen?

> für neue Fragen einen neuen Beitrag erstellen.

War das jetzt eine neue Frage?

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.