- LiFePO4 Speicher Test         
Ergebnis 1 bis 4 von 4

Thema: SPI Verständnisfrage

  1. #1
    Neuer Benutzer Öfters hier Avatar von Ethernut
    Registriert seit
    24.10.2012
    Beiträge
    14

    SPI Verständnisfrage

    Anzeige

    E-Bike
    Hallo,

    ich habe ein Problem mit dem Verstehen des SPI Kommunkationszyklus. Ich habe zwei Unterschiedliche MSP430 µC. Beide im 3-Wire Modus. Der Slave schickt das was der Master sendet als Echo zurück und wenn der Master einen bestimmten char empfängt, den selber zuvor geschickt hat, sollte eine LED leuchten. Unten sind die beiden Codes:

    Master:
    Code:
    /* --COPYRIGHT--,BSD_EX
     * Copyright (c) 2012, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     *
     *******************************************************************************
     *
     *                       MSP430 CODE EXAMPLE DISCLAIMER
     *
     * MSP430 code examples are self-contained low-level programs that typically
     * demonstrate a single peripheral function or device feature in a highly
     * concise manner. For this the code may rely on the device's power-on default
     * register values and settings such as the clock configuration and care must
     * be taken when combining code from several examples to avoid potential side
     * effects. Also see www.ti.com/grace for a GUI- and www.ti.com/msp430ware
     * for an API functional library-approach to peripheral configuration.
     *
     * --/COPYRIGHT--*/
    //******************************************************************************
    //   MSP430xG46x Demo - USCI_A0, SPI 3-Wire Master Incremented Data
    //
    //   Description: SPI master talks to SPI slave using 3-wire mode. Incrementing
    //   data is sent by the master starting at 0x01. Received data is expected to
    //   be same as the previous transmission.  USCI RX ISR is used to handle
    //   communication with the CPU, normally in LPM0. If high, P5.1 indicates
    //   valid data reception.  Because all execution after LPM0 is in ISRs,
    //   initialization waits for DCO to stabilize against ACLK.
    //   ACLK = 32.768kHz, MCLK = SMCLK = DCO ~ 1048kHz.  BRCLK = SMCLK/2
    //
    //   Use with SPI Slave Data Echo code example.  If slave is in debug mode, P5.2
    //   slave reset signal conflicts with slave's JTAG; to work around, use IAR's
    //   "Release JTAG on Go" on slave device.  If breakpoints are set in
    //   slave RX ISR, master must stopped also to avoid overrunning slave
    //   RXBUF.
    //
    //                    MSP430FG4619
    //                 -----------------
    //             /|\|              XIN|-
    //              | |                 |  32kHz xtal
    //              --|RST          XOUT|-
    //                |                 |
    //                |             P7.1|-> Data Out (UCA0SIMO)
    //                |                 |
    //          LED <-|P5.1         P7.2|<- Data In (UCA0SOMI)
    //                |                 |
    //  Slave reset <-|P5.2         P7.3|-> Serial Clock Out (UCA0CLK)
    //
    //
    //   K. Quiring/ M. Mitchell
    //   Texas Instruments Inc.
    //   October 2006
    //   Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.41A
    //******************************************************************************
    #include <msp430.h>
    
    volatile char zeichen = 'A';
    
    char spi_transmit(char data);
    
    int main(void)
    {
    	volatile unsigned int i, j=0;
    
    	WDTCTL = WDTPW + WDTHOLD;                   // Stop watchdog timer
    	FLL_CTL0 |= XCAP14PF;                     // Configure load caps
    
    	// Wait for xtal to stabilize
    	do {
    		IFG1 &= ~OFIFG;                           // Clear OSCFault flag
    		for (i = 0x47FF; i > 0; i--)
    			;             // Time for flag to set
    	} while ((IFG1 & OFIFG));                   // OSCFault flag still set?
    
    	for (i = 2100; i > 0; i--)
    		;                      // Now with stable ACLK, wait for
    							   // DCO to stabilize.
    	P2DIR = 0xFF;
    	P5OUT = 0x04;                            // P5 setup for LED and slave reset
    	P5DIR |= 0x06;                            //
    	P7SEL |= 0x0E;                            // P7.3,2,1 option select
    	UCA0CTL0 |= UCMST + UCSYNC + UCCKPL + UCMSB;    //3-pin, 8-bit SPI master
    	UCA0CTL1 |= UCSSEL_2;                     // SMCLK
    	UCA0BR0 = 0x02;                           // /2
    	UCA0BR1 = 0;                              //
    	UCA0MCTL = 0;                             // No modulation
    	UCA0CTL1 &= ~UCSWRST;                   // **Initialize USCI state machine**
    	IE2 |= UCA0RXIE;                          // Enable USCI_A0 RX interrupt
    
    	P5OUT &= ~0x04;                         // Now with SPI signals initialized,
    	P5OUT |= 0x04;                            // reset slave
    
    	for (i = 50; i > 0; i--)
    		;                        // Wait for slave to initialize
    	P2OUT=0x00;
    
    	__bis_SR_register(GIE);					// enable interrupts
    
    	while(1)
    	{
    		spi_transmit('A');                     // Transmit first character
    		__delay_cycles(3000000);
    		spi_transmit('B');                     // Transmit first character
    		__delay_cycles(3000000);
    		spi_transmit('C');                     // Transmit first character
    		__delay_cycles(3000000);
    	}
    }
    
    #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
    #pragma vector=USCIAB0RX_VECTOR
    __interrupt void USCIA0RX_ISR(void)
    #elif defined(__GNUC__)
    void __attribute__ ((interrupt(USCIAB0RX_VECTOR))) USCIA0RX_ISR (void)
    #else
    #error Compiler not supported!
    #endif
    {
    	volatile unsigned int i;
    
    	if (UCA0RXBUF == 'B')                // Test for correct character RX'd
    	{
    		P2OUT |= 0x02;                          // If correct, light LED
    	}
    	for (i = 30; i > 0; i--)
    				;                        // Add time between transmissions to
    										 // make sure slave can keep up
    }
    
    char spi_transmit(char data)
    {
    	while (!(IFG2 & UCA0TXIFG));	// USART1 TX buffer ready?
    	UCA0TXBUF = data;            	// Send next value
    }
    Slave:
    Code:
    /* --COPYRIGHT--,BSD_EX
     * Copyright (c) 2012, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     *
     *******************************************************************************
     *
     *                       MSP430 CODE EXAMPLE DISCLAIMER
     *
     * MSP430 code examples are self-contained low-level programs that typically
     * demonstrate a single peripheral function or device feature in a highly
     * concise manner. For this the code may rely on the device's power-on default
     * register values and settings such as the clock configuration and care must
     * be taken when combining code from several examples to avoid potential side
     * effects. Also see www.ti.com/grace for a GUI- and www.ti.com/msp430ware
     * for an API functional library-approach to peripheral configuration.
     *
     * --/COPYRIGHT--*/
    //******************************************************************************
    //   MSP430F54x Demo - USCI_A0, SPI 3-Wire Slave Data Echo
    //
    //   Description: SPI slave talks to SPI master using 3-wire mode. Data received
    //   from master is echoed back.
    //   ACLK = 32.768kHz, MCLK = SMCLK = DCO ~ 1MHz
    //   Note: Ensure slave is powered up before master to prevent delays due to
    //   slave init.
    //
    //
    //                   MSP430FR5739
    //                 -----------------
    //            /|\ |                 |
    //             |  |                 |
    //            -+->|                 |
    //                |                 |
    //                |             P2.0|-> Data Out (UCA0SIMO)
    //                |                 |
    //                |             P2.1|<- Data In (UCA0SOMI)
    //                |                 |
    //                |             P1.5|-> Serial Clock Out (UCA0CLK)
    //
    //
    //   P. Thanigai
    //   Texas Instruments Inc.
    //   August 2010
    //   Built with CCS V4 and IAR Embedded Workbench Version: 5.10
    //******************************************************************************
    #include <msp430.h>
    
    int main(void)
    {
      WDTCTL = WDTPW+WDTHOLD;                   // Stop watchdog timer
      // Configure XT1
      PJSEL0 |= BIT4+BIT5;
    
      CSCTL0_H = 0xA5;
      CSCTL1 |= DCOFSEL0 + DCOFSEL1;             // Set max. DCO setting
      CSCTL2 = SELA_0 + SELS_3 + SELM_3;        // set ACLK = XT1; MCLK = DCO
      CSCTL3 = DIVA_0 + DIVS_3 + DIVM_3;        // set all dividers
      CSCTL4 |= XT1DRIVE_0;
      CSCTL4 &= ~XT1OFF;
      do
      {
        CSCTL5 &= ~XT1OFFG;
                                                // Clear XT1 fault flag
        SFRIFG1 &= ~OFIFG;
      }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag
      // Configure SPI pins
      P1SEL1 |= BIT5;
      P2SEL1 |= BIT0 + BIT1;
    
    
      UCA0CTLW0 |= UCSWRST;                     // **Put state machine in reset**
      UCA0CTLW0 |= UCSYNC+UCCKPL+UCMSB;         // 3-pin, 8-bit SPI slave
                                                // Clock polarity high, MSB
      UCA0CTLW0 |= UCSSEL_2;                    // ACLK
      UCA0BR0 = 0x02;                           // /2
      UCA0BR1 = 0;                              //
      UCA0MCTLW = 0;                            // No modulation
      UCA0CTLW0 &= ~UCSWRST;                    // **Initialize USCI state machine**
      UCA0IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt
    
      __bis_SR_register(LPM0_bits + GIE);       // Enter LPM0, enable interrupts
    
    
    
    }
    
    #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
    #pragma vector=USCI_A0_VECTOR
    __interrupt void USCI_A0_ISR(void)
    #elif defined(__GNUC__)
    void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)
    #else
    #error Compiler not supported!
    #endif
    {
      while (!(UCA0IFG&UCTXIFG));               // USCI_A0 TX buffer ready?
        UCA0TXBUF = UCA0RXBUF;                  // Echo received data
    }
    Ich weiß, dass das SPI Verfahren vollduplex ist, ich empfange also direkt etwas vom Slave, wenn ich gleichzeitig auch was schicke. Ich schicke kontonuirlich 'A', 'B', 'C' und wenn der Master 'B' empfängt sollte die orangene LED leuchten. Ich schicke also 'A', empfange irgendwas, das was zu allererst im Sendebuffer des Slave ist. Ich schicke 'B' und empfange 'A', und so weiter. Aber spätestens im zweiten Zyklus sollte ich, wenn ich 'C' schicken das vorangegangene 'B' empfangen, oder? Die LED leuchtet nie, wenn ich beide Boards flashe. Auch interessant, wenn ich das Masterboard von der Versorgung hole, powert sich über die Busleitungen des anderen Boards und da kann es manchmal passieren, dass die LED leuchtet???

    Muss beim SPI beide Boards mit derselben Versorgung betrieben werden wie das Masterboard?

    Danke für jede Anregung!

    lg Ethernut

  2. #2
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    73
    Beiträge
    11.077
    Hallo!

    Zitat Zitat von Ethernut Beitrag anzeigen
    Ich weiß, dass das SPI Verfahren vollduplex ist, ich empfange also direkt etwas vom Slave, wenn ich gleichzeitig auch was schicke.
    Nicht immer, weil es u.a. von deiner bisher unbekannter Hardware abhängig ist. Siehe bitte: https://de.wikipedia.org/wiki/Duplex...htentechnik%29 .
    MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!

  3. #3
    Neuer Benutzer Öfters hier Avatar von Ethernut
    Registriert seit
    24.10.2012
    Beiträge
    14
    Die Hardware ist nicht unbekannt. Beide µC sind in den Codesnipets beschrieben. Diese Beispiele habe ich aus den individuellen c files aus TI und beide funzen nicht. verstehe nicht was ich falsch mache. in beiden steht fast genau das gleiche...

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    899
    Zitat Zitat von Ethernut Beitrag anzeigen
    Hallo,
    Muss beim SPI beide Boards mit derselben Versorgung betrieben werden wie das Masterboard?
    Nein, aber Gnd muss verbunden sein.
    Und beide Boards sollten annähernd gleiches Ub verwenden, also 3,3V und 5V nicht ohne Nachdenken/ Pegelanpassen mischen.

Ähnliche Themen

  1. SPI - Verständnisfrage
    Von hae im Forum Microcontroller allgemeine Fragen/Andere Microcontroller
    Antworten: 1
    Letzter Beitrag: 29.03.2012, 11:44
  2. Verständnisfrage zu SUB deklarieren
    Von mat-sche im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 13.01.2009, 17:19
  3. SPI Verständnisfrage
    Von bertl100 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 9
    Letzter Beitrag: 07.09.2006, 17:54
  4. Verständnisfrage
    Von Shadow² im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 30.08.2006, 12:56
  5. PWM Verständnisfrage
    Von Amri im Forum AVR Hardwarethemen
    Antworten: 9
    Letzter Beitrag: 01.04.2005, 14:36

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Labornetzteil AliExpress