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


von Ralf S. (tuberkulum)


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)


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)


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)


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)


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)


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)


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)


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)


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)


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.

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.