Forum: Mikrocontroller und Digitale Elektronik MSP430 Serial Port kopieren per P1/P2 Interrupt?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ralf S. (tuberkulum)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein etwas ungewöhnliches Szenario: Ich möchte zwei uC (MSP430 + 
DSP335) an der gleichen seriellen Schnittstelle eines Modems anschließen 
(nur Rx|Tx|RTS, nur 9600bd). Der DSP wird nur bei Bedarf vom MSP 
eingeschaltet, der MSP benötigt in diesem Fall das Modem nicht. Ich 
möchte keine weitere HW zwischen den beiden uC verwenden, die ggf. die 
beiden Tx-Treiber vom MSP/DSP trennen könnten.

Meine Idee dazu: Der MSP gibt den logischen Signalpegel den er am RX vom 
Modem sieht als Output an einem GPIO unmittelbar wieder aus (für den 
DSP)! Das könnte er mit sehr wenig Aufwand tun, indem er zwei P1/P2 
Interrupts nutzt, die auf Signal-Flanken reagieren: Zwei P1-Pins sind 
mit dem Modem-RX-Pin elektr. verbunden, die eine P1-ISR reagiert bei 
neg. Flanke, die andere P1-ISR bei pos. Flanke, beide kopieren den 
aktuellen RX-Signal-Pegel (0/1) auf den Output-Pin für den DSP. Das 
ganze dann für den Rückweg vom DSP => Modem-Tx ebenso. Es sind also 
insgesamt vier P1-GPIOs und 2 sehr kleine ISRs involviert. Man könnte 
das ganze als eine Art 'UART-Routing über GPIOs' bezeichnen.

Meine Hoffnung dabei ist, dass die MSP-Systemlast dadurch geringer ist 
als bei einem 'MSP-UART-Byte-Copy-Mode' (Modem <-> MSP-USCA0 <-> 
MSP-USCA1 <-> DSP) mit vier involvierten UART-ISRs.

Außerdem sollten bei einem MSP-Systemtakt von 16 MHz (<1µs/Instr.) und 
9600 bd (~100 µs/bit) die 'per Hand' getoggelten Bits für den DSP noch 
ausreichend genau sein (konstante MSP-IRQ-Latenz). Das Modem-RTS sollte 
kein Problem darstellen, da das Protokoll 'Master-Request / 
Slave-Response' (MSP und DSP sind Slaves) basiert ist.

Ist das machbar? Oder machen ich einen Gedankenfehler?

von Gerald K. (geku)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man dafür sorgt, dass die Unterschiede der Interruptbehandlungszeit 
zwischen L/H und H/L für die Ansteuerung des Ausgangspins kleiner als 3% 
bzw 3µs bei 9600Baud bleiben, sollte es funktionieren. Notfalls mit NOPs 
in der Interruptroutine abgleichen.

https://www.mikrocontroller.net/articles/Baudratenquarz

Achtung : bei Volldupex kommen sich zwei Interruptroutinen ins Gehege.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Ralf S. schrieb:
> Der DSP wird nur bei Bedarf vom MSP
> eingeschaltet, der MSP benötigt in diesem Fall das Modem nicht.

Warum dann so kompliziert?
Beide hängen einfach parallel am Modem. Gibt der MSP den DSP frei, 
disabled er einfach seine UART und der DSP enabled sie.

von Ralf S. (tuberkulum)


Bewertung
0 lesenswert
nicht lesenswert
Danke für das Feedback!

Im nachhinein fiel mir auf, dass die IRQ-Prio beim MSP ja nicht 
einstellbar ist (HW gegeben). Demnach habe ich ein Jitter durch andere 
potentiell gerade aktive IRQs - selbst wenn ich niederpriore IRQs mit 
GPIE in der ISR erlaube (IRQ-Nesting). Hmm...

Peter D. schrieb:
> Warum dann so kompliziert?
> Beide hängen einfach parallel am Modem. Gibt der MSP den DSP frei,
> disabled er einfach seine UART und der DSP enabled sie.
Das mag der DSP nicht so: "No voltage larger than a diode drop (0.7 V) 
above VDDIO should be applied to any digital pin (for analog pins, this 
value is 0.7 V above VDDA) before powering up the device."
(https://www.ti.com/document-viewer/TMS320F28335/datasheet/power-sequencing-power-seq-section#Power_Seq_section)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Ralf S. schrieb:
> Das mag der DSP nicht so:

Ich würde ihm auch nicht den Saft klauen, sondern ihn entweder in Reset 
halten oder in Sleep schicken.
VCC zu schalten könnte häßliche Spannungseinbrüche verursachen durch die 
Stützkondensatoren des DSPs und der MSP könnte sich verklemmen.

von Ralf S. (tuberkulum)


Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, werde ich an den Hardwerker weitergeben. 
Background: Das ist ein Stromspars-Szenario, der MSP schaltet das 
Schaltnetzteil für den DSP komplett aus, wenn er nicht gebraucht wird. 
Die Stromfresser auf der DSP Seite ist nicht der DSP selbst, sondern 
seine Peripherie dahinter.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Ralf S. schrieb:
> Das ist ein Stromspars-Szenario

Achso, das Gerät ist für Batteriebetrieb. Ist nicht so schön, wenn 
wichtige Informationen tröpfenweise kommen.

von Ralf S. (tuberkulum)


Bewertung
0 lesenswert
nicht lesenswert
> Ist nicht so schön, wenn wichtige Informationen tröpfenweise kommen.
Tut mir leid, wenn das in meinem obersten Beitrag nicht ausreichend 
erklärt war. "Der DSP wird nur bei Bedarf vom MSP eingeschaltet", das 
ist (leider) für mich Fakt und wollte ich auch nicht weiter ausbreiten 
(nur so viel: begrenzte Energieaufnahme des Gesamtsystems, kein 
Batteriebetrieb).

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt Trenn-ICs, die nur durchschalten, wenn VCC anliegt.
Das Routen in SW geht nur zuverlässig, wenn der MSP nichts anderes mehr 
macht (keine Interrupts usw.). Dann am besten per Polling, das spart die 
zusätzliche Zeit für Prolog und Epilog des Handlers, d.h. der Jitter ist 
deutlich geringer.

Ralf S. schrieb:
> Die Stromfresser auf der DSP Seite ist nicht der DSP selbst, sondern
> seine Peripherie dahinter.

Wär mal interessant, wieviel Watt das sind für die Peripherie. Man 
sollte Sachen nicht unnötig kompliziert machen.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Man könnte einen der neuen AVRs benutzen, z.B. den ATmega3208. Die haben 
ein Stück programmierbare Logik intern, d.h. Du kannst IO-Pins mit 
Peripherie logisch verknüpfen ganz ohne jede CPU-Last.
Und recht stromsparend sind sie außerdem.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.