Ich nutze einen MSP430F2012 und möchte neben den freien Pins auch einen der beiden Spy By Wire Pins für die Applikation nutzen. (Mir fehlt sonst genau ein Pin...) Laut Beschreibung sollte dies ja möglich sein. Allerdings habe ich das noch nicht wirklich verstanden. Bleibt die Programmierbarkeit und das Debugging über den Test und RST Pin denn erhalten, wenn man einen davon auch anders nutzt? Wie ist das möglich? Könnte man damit zum Beispiel einen Taster auswerten (Über den NMI) und die Programmierbarkeit "in-circuit" würde trotzdem erhalten bleiben? Handelt man sich dadurch auch Nachteile ein? Ich weiss dass wir das Thema Spy By Wire schon einige male im Forum hatten. Konnte aber trotzdem keine einfache Erklärung hierzu finden. Und auch die slau138k.pdf mit Ihren Schemas hat mich nicht wirklich weiter gebracht. Kennt vielleicht jemand ein einfaches Tutorial dazu? Grüsse Ste.
Der TEST-Pin ist nicht als I/O-Pin nutzbar. Er dient ausschließlich zur Programmierung und zum Debuggen, wird zur BSL-Entrysequenz gebraucht und ist Eingang der Fuse-Blow-Spannung. Den RST/NMI-Pin könnte man sicher als Input-Pin (z.B. Taster) benutzen, wenn die externe Beschaltung des Pins gemäß der SLAU138K, Fig3-2 erhalten bleibt, der Taster also z.B. ein Schließer-Typ ist. Programmieren sollte dann noch möglich sein, aber ob man den NMI dann auch debuggen kann, bezweifle ich!
Hallo Stefan Vielen Dank für die rasche und präzise Antwort. Aus der Nutzung des Test Pins wird also nichts. Das mit dem RST Pin werde ich auf jeden Fall am Wochenende ausprobieren. Dass ein Debugging des NMI (also während die Taste gedrückt ist) wohl nicht geht, ist ein guter Hinweis. Macht Sinn, wenn man mal drüber nachdenkt. ;)
Ich habe es bisher immer vermieden, mich mit den JTAG-Pins "anzulegen" und bin deshalb sehr dankbar über die SBW-Funktionalität, die mir ganze 4 I/O-Pins zurück gegeben hat! :-) Zum Debuggen: Der RST/NMI-Pin wird ja für das SBW-Interface zum Debuggen benutzt, weswegen die eigentliche Programm-Funktionalität (also hier ein Taster) natürlich während des Debug-Modus nicht gegeben ist. Falls Du IAR verwendest, könntest Du versuchen, die Option "Release JTAG on go" zu aktivieren. Ob das bei SBW auch funktioniert, weiss ich nicht... sollte aber den RST/NMI-Pin wieder freigeben. Breakpoints sind dann aber nicht mehr aktiv, Du musst den µC "von Hand" anhalten, um zu schauen, wo das Programm gerade steht. Ausserdem nehme ich mal an Du weißt, dass Du im WDTCTL-Register den Pin von Reset- auf NMI-Funktion umstellen musst? Ansonsten produzierst Du mit dem Taster lediglich saubere Resets!
Vielen Dank für eure Infos. Ja, man produziert mit dem Taster saubere Resets. ;) Natürlich muss man den Pin erst umkonfigurieren. Danke. Der Debugger verhält sich übrigens genau gleich, wie wenn man während dem Debuggen den "Stecker zieht". Dass man nicht debuggen kann stört mich eigentlich nicht. Denn dieser Nachteil ist nur während der Entwicklung eine Einschränkung. Aber das ganze hat einen anderen hässlichen Schönheitsfehler. Während der RST Pin low ist, werden keine Resets mehr ausgeführt. Auch nicht von anderen Quellen (Watchdog...) Das System kann sich also aufhängen. Irgendwie ist mir das ziemlich unsympatisch. Es scheint auch nicht wirklich einen Weg zu geben, die Resets trotzdem sauber abzufangen und durchzuführen. Ausserdem triggert der NMI jeweils die Flanke. Ich habe noch nicht herausgefunden, wie ich denn entscheide, ob der Taster gedrückt oder losgelassen wurde. Mehr Infos zum Thema habe ich übrigens hier gefunden: http://www.embeddedrelated.com/groups/msp430/show/36620.php Offenbar bin ich nicht der einzige, der sich einen Pin mehr wünscht. ;)
>Während der RST Pin low ist, werden keine Resets mehr ausgeführt. Auch >nicht von anderen Quellen (Watchdog...) Das System kann sich also >aufhängen. Das ist prinzipiell richtig. Aber die Wahrscheinlichkeit, dass ein Taster gerade zu dem Zeitpunkt gedrückt wird, wenn ein Reset (PUC) ausgeführt wird, scheint mir doch sehr gering (... wenn auch nicht unmöglich, natürlich!) >Ausserdem triggert der NMI jeweils die Flanke. Ich habe noch nicht >herausgefunden, wie ich denn entscheide, ob der Taster gedrückt oder >losgelassen wurde. Bei einem Taster interessiert ja für gewöhnlich die Flanke beim Drücken. Man könnte bestimmt irgendwie per Hardware entprellen und entsprechende Flanken/Pulse erzeugen... aber ob sich das wirklich lohnt? Wahrscheinlich ist es einfacher/sinvoller auf einen µC mit mehr I/O's umzusteigen. Ich kenne jetzt Dein Design nicht, aber vielleicht kannst Du ja auch andere Ports multiplexen, verodern oder per Tastatur-Matrix einlesen, oder so was?!
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.