Ich versuche, vernünftige Teile aus einem Buspiraten herauszuholen, der an ein Launchpad-Board angeschlossen ist (Verwenden des Sparkfun-Kabels: Orange geht zu P1.6, Gelb zu P1.5. Dies sollte korrekt sein, es sei denn, ich habe MOSI und MISO verwechselt ...). Ich habe CS nicht angeschlossen, da ich nur den Buspiraten benutze, um etwas zu überwachen.
Der Buspirat ist für SPI, 125 kHz, Taktpolarität Leerlauf niedrig, Ausgangstaktflanke Aktiv bis Leerlauf, Eingangsprobenphasenmitte, / CS eingerichtet, Ausgang ist normal.
Auf dem Launchpad habe ich einen MSP430G2231 ohne externen Kristall. Mit Code Composer Studio habe ich Folgendes:
#include "msp430g2231.h"
volatile unsigned char value=0;
#pragma vector=USI_VECTOR
__interrupt void universal_serial_interface(void)
{
value+=1;
USISRL=value;
USICNT=8;
}
void main(void){
WDTCTL = WDTPW + WDTHOLD;
BCSCTL1 = CALBC1_1MHZ; // Set range
DCOCTL = CALDCO_1MHZ;
BCSCTL2 &= ~(DIVS_3);
USICTL0 |= USIPE7 + USIPE6 + USIPE5 + USIMST + USIOE;
USICTL1 |= USIIE;
USICKCTL = USIDIV_3 + USISSEL_2;
USICTL0 &= ~USISWRST;
USISRL=value;
USICNT = 8;
__bis_SR_register(LPM0_bits+ GIE);
}
Das meiste davon wird aus den verschiedenen Proben zusammengeschustert. Nach langem Lesen des Datenblattes scheint der USI-Takt auf 125 kHz eingestellt zu sein (SMCLK von 1 MHz, geteilt durch 8), obwohl ich keinen Spielraum habe, dies zu messen.
Beim Laufen bekomme ich im Wesentlichen Müll aus dem Buspiraten. P setzte einen Haltepunkt in die erste Zeile des USI-Interrupt-Vektors und ließ ihn dreimal durchlaufen, also hätte ich 0, 1, 2 vom Buspiraten bekommen sollen
0x00(0x00)0x00(0x00)][0x40(0x00)]
Und wenn ich es frei laufen lasse, bekomme ich einfach solche Sachen:
[0xFF(0x00)][0x3F(0x00)][0x7F(0x00)][0xBF(0x00)][0xC0(0x00)0x00(0x00)][0x40(0x00)0x80(0x00)]
Was immer noch nicht so aussieht, wie ich es erwarte.
Ich habe den größten Teil des Abends damit verbracht, die Bedienungsanleitung für den Chip durchzugehen, und bin immer noch ratlos.
Während ich dies schrieb, stellte ich fest, dass ich den Buspiraten als Logikanalysator (mit LogicSniffer) verwenden kann, und richtete ihn dafür ein. Und modifizierte das Programm, um 0x55 zu schreiben USISRL
, und änderte das USIDIV
zu USIDIV_4
, um die Dinge ein bisschen langsamer zu machen, und hier sind die Ergebnisse:
Das Taktsignal sieht gut aus, LogicSniffer berichtet, dass es ungefähr 285 kHz ist ... und MOSI ist ... etwas Besonderes. Ich würde ein schönes Wechselmuster erwarten, da ich 0x55 schreibe, und das ist alles andere als.
Hat jemand irgendwelche Gedanken darüber, was ich falsch machen könnte? Chip defekt? Etwas anderes?
EDIT: Ok, wenig Idiotie von meiner Seite. Ich habe den Wert, der im Interrupt in SPI geschrieben wird, nicht geändert. Dies führt zu dem erwarteten Muster:
Wenn ich jedoch wieder versuche, ein inkrementierendes Byte zu schreiben, bekomme ich Müll:
Also habe ich immer noch ein Problem, nur nicht so groß wie ich dachte ...
EDIT 2: Dank der folgenden Kommentare habe ich das Erdungskabel vom Bus Pirate-Kabel, das zuvor nicht angeschlossen war, mit der Erdung meines Netzteils (Sparkfuns Steckbrett-Netzteil) verbunden. Zuvor befand sich der nächstgelegene gemeinsame Boden wieder im USB-Hub, an dem ich all diese Geräte aufhänge.
Dadurch wurden die Störungen bei MOSI beim Ausführen des Zählerprogramms beseitigt, und LogicSniffer kann die Bytes nun selbstständig korrekt dekodieren:
Der Buspirat im Überwachungsmodus meldet immer noch merkwürdige Ergebnisse:
[0x00(0x00)][0x04(0x00)][0x06(0x00)][0x10(0x00)][0x10(0x00)][0x10(0x00)][0x12(0x00)][0x18(0x00)]
Es scheint besser in der Lage zu sein, die Enden der Schreibvorgänge zu erkennen (ich gehe davon aus, dass dies durch die eckigen Klammern begrenzt ist), aber die Daten, die dekodiert werden, sind immer noch deaktiviert. Ich bin jetzt nicht ganz so besorgt, da die Wellenform besser aussieht, aber es wäre trotzdem schön zu wissen, warum der Buspirat verwirrt wird.
while(1);
oder ein Äquivalent am Ende von main (), um zu verhindern, dass es beendet wird und zufällige Dinge tut.