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?
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
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.
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)
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.
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.
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.
> 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).
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.