Message objects im ARM Cortex M3 (LM3S8971)

Maddin Gast #2136408
Lesenswert?
• ▲
▼ 
Ich versuche eine einfache Kommunikation per Can mit 2 Teilnehmern 
aufzubauen. Dabei stoße ich jedoch auf Schwierigkeiten beim Verständnis 
der Message-Objekte.

Laut Datenblatt sitzen im Ram 32 message objects, die ich einzeln 
initialisieren kann. Dies geschieht über 2 Message interfaces. 
Üblicherweise einer für TX und RX.

Nun ist es so, dass mittels einer handvoll Register für jedes Interface 
ein Objekt gebastelt wird und dieses dann anschließend in dem Ram 
gelangt in dem im CANIF1CRQ register eine message number hinterlegt 
wird... denke ich. Vorrausgesetzt TXRQST im CANIF1MCTL register ist 
gesetzt, wird dieses Objekt nun im Ram gespeichert. Aber auch sofort 
gesendet? Und was passiert mit dem Objekt nach dem Senden. Muss ich es 
komplett neu initialisieren?

Noch verrückter wirds beim Empfangen. Lege ich ein receive message 
object an, zum Beispiel ohne jegliche identifier-Filterung, dann wird 
dieses im Ram gespeichert? Und wie greift man nun mittels der message 
number auf empfangene objekt zu?

Der Zusammenhang zwischen Interface und Objekte ist mir ein Rätsel.... 
help please
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Maddin Gast #2141436
Lesenswert?
• ▲
▼ 
Ok erste Frage war anscheinend nicht zu beantworten. Ihr bekommt noch 
einen Versuch ;)

Bei den Cortex M3 muss man laut IAR Workbench Doku den Interrupt Handler 
von Hand in die Vector-Tabelle eintragen. Es gibt auch ein Beispiel. In 
einem Projekt wird folgende ISR definiert:
1
__irq __arm void IRQ_Handler()

2
{

3
...

4
}


In der im Projekt enthaltenen cStartupCM3.s befindet sich folgender 
Eintrag:
1
        ;; Device specific interrupts

2
        DCD     UART_Handler


Nun stellt sich mir die Frage wie der Compiler eine Verbindung zwischen 
dem IRQ_Handler und dem UART_Hanlder herstellt. Weder die Namen sind 
gleich, noch irgendetwas anderes verrät, dass hier in den IRQ_Handler 
gesprungen werden soll. Ich vermisse die MSP430 typische einfache 
Verwendung von
1
__interrupt void Timer_B (void)

Timer_B war in *.h definiert und Programmierer und Compiler wussten 
wohin gesprungen wird. .... Ich stehe auf dem Schlauch.

Gruß


Maddin
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin T. Moderator Persönliche Seite #2141833
Lesenswert?
• ▲
▼ 
Maddin schrieb:
>
>
1
> __irq __arm void IRQ_Handler()

2
> ...

3
>

Das scheint nicht aus einem Beispiel für Controller mit Thumb2. Soweit 
erinnert erzwingt __arm beim EWARM die Generierung von ARM-code.

>
> In der im Projekt enthaltenen cStartupCM3.s befindet sich folgender
> Eintrag:
>
1
>         ;; Device specific interrupts

2
>         DCD     UART_Handler

3
>

>
> Nun stellt sich mir die Frage wie der Compiler eine Verbindung zwischen
> dem IRQ_Handler und dem UART_Hanlder herstellt.
Der Controller schaut in der Tabelle nach der Adresse der ISR und führt 
diese aus. Compiler hat damit nicht viel zu tun, eher der Linker, der am 
per DCD reservierten Platz die Adresse des Symbols ("Funktionspointer") 
einträgt.

> Weder die Namen sind
> gleich, noch irgendetwas anderes verrät, dass hier in den IRQ_Handler
> gesprungen werden soll.
Falls es nicht aus diversen Beispielen zusammengewürfelte 
Codeausschnitte sind, ist mglw. noch irgendwo ein Alias definiert.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Maddin Gast #2142089
Lesenswert?
• ▲
▼ 
Martin Thomas schrieb:
> Compiler hat damit nicht viel zu tun, eher der Linker, der am
> per DCD reservierten Platz die Adresse des Symbols ("Funktionspointer")
> einträgt.

Oh ich habe etwas unterschlagen. Der Code sieht eigentlich so aus:
1
#if __CORE__ == __ARM7M__

2
/* Defines an interrupt handler for the ARMv7m (Cortex-M) UART interrupt. */

3
void UART_Handler()

4
#else

5
/* Defines an interrupt handler for the ARMv4 (ARM7) IRQ. */

6
__irq __arm void IRQ_Handler()

7
#endif

8
{

9
...

10
}


Ich habe fälschlicherweise angenommen bei Cortex M3 handelt es sich 
nicht um einen ARM7M. Ok Dann ist auch meine Fehlermeldung beim 
Kompilieren von __arm verständlich.

Bei dem UART_HANDLER handelt es sich ja um einen Hardwareinteruptvektor 
richtig? Nun frage ich mich was mache ich um zum Beispiel eine ISR für 
den TimerX zur Verfügung zu stellen... Ich muss die Vektortabelle 
erweitern... Da ich jedoch kein #define für UART_Handler finde, verwirrt 
mich dies nur. UART_Handler ist schließlich eine Name der sicherlich nur 
in diesem Projekt definiert ist.

Dann stellt sich mir die Frage, wie ich dem Compiler/Linker nun 
überhaupt mitteile das in meiner *.s Datei die Vektortabelle steht bzw. 
ergänzt wird...

Gruß

Maddin
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren