Hallo,
ich möchte über SPI beim MSP mehrere Bytes an einen Funkchip senden. Mit
folgendem Code in C funktioniert das auch:
1
for(a=6;a>=0;a--)
2
{
3
TXBUF1=test[a];
4
while(!(IFG2&UTXIFG1));// USART1 TX frei?
5
}
bei test handelt es sich um ein array mit 7 bytes. Mit der
while-schleife warte ich bis der Buffer leer ist und lade dann das
nächste Byte.
Jetzt entsteht aber zwischen den jeweiligen Bytes eine Pause, da der MSP
ja erst die Daten wieder laden muß. Die 7 Bytes sollten aber ohne Pause
an den Funkchip gesendet werden.
Besteht da eine Möglichkeit...
Oder muß ich die Daten irgendwie über normale I/O Pins rausschicken?
Vielen Dank
@ThoBi (Gast)
>Jetzt entsteht aber zwischen den jeweiligen Bytes eine Pause, da der MSP>ja erst die Daten wieder laden muß.
Logisch, der MSP muss den Arrayzugriff machen und auch die
Schleifenvariable bearbeiten. Besser so.
1
chartmp;
2
3
for(a=6;a>=0;a--)
4
{
5
tmp=test[a];
6
while(!(IFG2&UTXIFG1));// USART1 TX frei?
7
TXBUF1=tmp;
8
}
9
while(!(IFG2&UTXIFG1));// Ende des letzten Bytes abwarten
ThoBi wrote:
> Hallo,>> ich möchte über SPI beim MSP mehrere Bytes an einen Funkchip senden.> Die 7 Bytes sollten aber ohne Pause> an den Funkchip gesendet werden.
Warum? Der Trick bei SPI ist doch, dass es egal ist, wann die Bytes
rausgehn, solange CS aktiv ist. Welcher Funk-Chip ist das genau? Steht
das wirklich im Datenblatt, dass keine Pause sein darf? Eine kleine
Pause bekommst du immer, der MSP muss erst das nächste Byte aus dem
Buffer in das Schieberegister laden.
Es entsteht keine Pause durch das Laden aus dem Array.
Die seriellen Schnittstellen (in Hardware) sind i.A. zweistufig
aufgebaut.
Die erste Stufe ist das Schieberegister (SR), dass die Bits auf die
Leitung "klingelt". Die zweite Stufe ist ein Datenregister (DR), welches
das zu sendende Byte (kann auch ein Word sein, oder bei SPI sogar krumme
Bitanzahlen). Auf dieses Datenregister hat der Programmierer Zugriff.
Also:
Wenn du das erste Byte ins DR schreibst, wird dieses sofort von der HW
ins SR kopiert und die HW beginnt dieses Byte seriell zu senden. Dein DR
ist in diesem Augenblick wieder leer (HW Flag) und kann mit dem zweiten
Byte beschrieben werden. Da jetzt aber das SR noch mit dem ersten Byte
"beschäftigt" ist, wird das DR als voll gemeldet (HW Flag).
Wenn das SR das letzte Bit vom ersten Byte gesendet hat wird das zweite
Byte aus dem DR ins SR kopiert und sofort das DR wieder als leer
gemeldet (HW Flag).
Der MSP hat also genau so viel Zeit um das nächste Byte ins DR zu
schreiben, wie das SR benötigt, um ein Byte zu senden.
Gruß
@ supachris
Sorry, das Problem leigt eher beim Empfänger, weil es sich bei den Daten
schon um die Nutzdaten ahndelt, welche gesendet werden sollen.
Wenn jetzt zwischen den einzelnen Bytes eine Pause ist, wird diese vom
Empfängermodul als Nullen interpretiert und mein gesmates Protokoll
kommt durcheinander.
Ich denke ich werde die einzlenen Bytes über einen normalen Port
rausschieben, wenn das einfacher geht
> Wenn jetzt zwischen den einzelnen Bytes eine Pause ist, wird diese vom> Empfängermodul als Nullen interpretiert und mein gesmates Protokoll> kommt durcheinander.
Dann taugt dein Empfänger nix, weil SPI ein synchrones Protokoll ist und
der Master durch den Takt bestimmt, wann der Slave die Signale zu
übernehmen hat. Wenn die Pause tatsächlich als Nullen interpretiert
wird, dann würd ich mal gucken, was die CLK-Leitungen in den Pausen
macht.
Ralf
Hm, versteh ich nicht so recht. Wenn es eine SPI Schnittstelle ist,
werden doch die Daten nur übernommen, wenn eine Taktflanke kommt. Kommt
keine Taktflanke (z.b. zwischen 2 Bytes) dann wird auch nix übernommen.
Wie sieht denn dein Aufbau aus? Eventuell klappt es, wenn der MSP430
schnell genug aus dem TXBUF0 nachlädt, da könnte es sein, dass der Takt
quasi durchgehend anliegt und die Daten direkt hintereinander kommen.
Aber da müsste man mal ins Datenblatt schauen.
Was verstehst du unter Nutzdaten? Willst du die SPI als asynchrone
Schnittstelle missbrauchen? Ich denke, das geht erst ma zu einem
FunkChip?
@ Gast (Gast)
>Es entsteht keine Pause durch das Laden aus dem Array.
Das weisst du doch gar nicht.
>Die seriellen Schnittstellen (in Hardware) sind i.A. zweistufig>aufgebaut.
Nicht notwendigerweise. Beim AVR ist SPI nur in Empfangsrichtung doppelt
gepuffert. Beim MSP430 weiss ich es nicht.
@ ThoBi (Gast)
>Sorry, das Problem leigt eher beim Empfänger, weil es sich bei den Daten>schon um die Nutzdaten ahndelt, welche gesendet werden sollen.>Wenn jetzt zwischen den einzelnen Bytes eine Pause ist, wird diese vom>Empfängermodul als Nullen interpretiert und mein gesmates Protokoll>kommt durcheinander.
Dann ist das aber kein wirkliches SPI. Das klingt eher nach UART oder
ähnlichem.
>Ich denke ich werde die einzlenen Bytes über einen normalen Port>rausschieben, wenn das einfacher geht
Dort ist das Problem eher noch grösser, denn du hast dann definitiv
KEINEN FIFO.
MFG
Falk
@Falk
>Nicht notwendigerweise. Beim AVR ist SPI nur in Empfangsrichtung doppelt>gepuffert. Beim MSP430 weiss ich es nicht.
Habe vor ca. 3 Jahren mal eine SPI auf einem MSP430 programmiert und
denke mich an die zweistufige HW zu erinnern (bin jetzt aber zu faul im
DS nachzusehen).
Gruß
Der MSP430 hat eine gepufferte USART, ist schon richtig. Aber das
Datenbyte aus dem Puffer in das Schieberegister zu transferieren, dauert
ja auch mindestens einen Takt.
@Christian R. (supachris)
>Der MSP430 hat eine gepufferte USART, ist schon richtig. Aber das>Datenbyte aus dem Puffer in das Schieberegister zu transferieren, dauert>ja auch mindestens einen Takt.
Jain, aber das kann lückenlos mit dem letzten Bit des vorhergehenden
Bytes passieren. Parallel Hardware kann das ;-)
MFg
Falk
... könnte das, aber wie meine Messung zeigt, kann der MSP430 das eben
nicht. Macht ja auch nix, wenn man die SPI als solche verwendet. Wenn
man natürlich irgendwelche "Sauerein" damit vorhat, dann nicht.
Thread beobachten
Seitenaufteilung abschalten