Project: SPI_MSTransfer

mjs513 · May 11, 2018

Ok tonton81. Hooked up the LC to T3.5 and checked wiring a bunch of times and while the master is firing I am not seeing anything come through on the slave. I am running the slave at 48MH, the master I tried at 120, 144 and 168MHz with 4/6Mhz SPI speed. I am on SPI0. I did change SPI=0 in the cpp file, or are we limited to SPI1 for F&F example?

Keep getting low memory warnings when using faster. Also am seeing startup problems - doesn't want to come on line.

Mike

tonton81 · May 11, 2018

the LC use specific pins not same as SPI0, use SPI1
oh ok you change to 0, dunno, still doing work on current version

tonton81 · May 11, 2018

You can try this on the LC slave:

Code:

[ATTACH]13775._xfImport[/ATTACH]

This uses pins 0,5,6,20
only use F&F overload 1 on master, dont use events or anything else

Fastest:

Code:

Sketch uses 25988 bytes (40%) of program storage space. Maximum is 63488 bytes.
Global variables use 6292 bytes (76%) of dynamic memory, leaving 1900 bytes for local variables. Maximum is 8192 bytes.

Smallest:

Code:

Sketch uses 17252 bytes (27%) of program storage space. Maximum is 63488 bytes.
Global variables use 4100 bytes (50%) of dynamic memory, leaving 4092 bytes for local variables. Maximum is 8192 bytes.

correction, sorry mike, i didnt add the "memory address" for SPI0 to it's begin(), sorry, that would be the reason it didnt work.
Look at the SPI1 in begin(), where it sets the memory address
copy that to SPI0 below it, and change the address to 0x40076000

EDIT:
just add this line for the SPI0

Code:

    spi_mst_spi_addr = 0x40076000; // SPI0 SLAVE

tonton81 · May 11, 2018

From the datasheet:

Data may be read from the SPI data registers any time after S[SPRF] is set and before
another transfer is finished. Failure to read the data out of the receive data buffer before a
new transfer ends causes a receive overrun condition, and the data from the new transfer
is lost. The new data is lost because the receive buffer still held the previous character
and was not ready to accept the new data. There is no indication for a receive overrun
condition, so the application system designer must ensure that previous data has been
read from the receive buffer before a new transfer is initiated.
In 8-bit mode, only the DL register is available. Reads of the DH register return all zeros.
Writes to the DH register are ignored.

Seeing as the send & receive register, like I mentioned earlier on, are one and the same, to me that looks like it's able to discard a new "entry" if its not popped out, lots of gotchas with this chip...

mjs513 · May 11, 2018

Tony
This may sound like a dumb question but why are you beginning SPI0 when sSPI_port=1 and vice versa. This gets set when SPI1 is true:

Code:

    SPI.setSCK(14); SPI.setMOSI(11); SPI.setMISO(12); SPI.begin();
    SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0)); // default speed
    Serial.println("SPI1 using pins: (MOSI)11\t(MISO)12\t(SCK)14");
    NVIC_SET_PRIORITY(IRQ_SPI0 , 0);

and when sSPI_port = 0

Code:

    SPI1.setSCK(20); SPI1.setMOSI(21); SPI1.setMISO(5); SPI1.setCS(6); SPI1.begin();
    SPI1.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0)); // default speed
#if defined(MST_USE_SERIAL2)
    Serial2.setTX(10); // reclaim pin for Serial2.
#endif
    NVIC_SET_PRIORITY(IRQ_SPI1 , 0);

Little confused on that one, because it seems I have to use SPI pins for SPI1 and SPI1 pins if I want to use SPI0?

Thanks
Mike
Update:
Did a compile at fastest

Sketch uses 55628 bytes (87%) of program storage space. Maximum is 63488 bytes.
Global variables use 7496 bytes (91%) of dynamic memory, leaving 696 bytes for local variables. Maximum is 8192 bytes.

Wondering now if I got a conterfit - bought this one on amazon. Oh I am using 1.8.5 with 1.4.2b4

tonton81 · May 11, 2018

no, if SPI is used as slave, its presetting SPI1 as master, and if SPI1 is slave, SPI is preset to master
i preinitialize the resources remember?

I cant define the opposite port resource without knowing which one would be set to slave, including setting proper pins to utilize the resources (ex, moving pin 10 to use Serial2)

if you look above them, the other resources (Serial/Wire(if defined)) are also pre-set

mjs513 · May 11, 2018

Understood now. As usual getting myself confused.

Anyway, just out of curiosity do you need to set SPI.setCS(2); to SPI.setSCK(14); SPI.setMOSI(11); SPI.setMISO(12); SPI.begin(); or are you going to leave it up the user to add it to his code?

EDIT:
Getting confused on connections now I think. Changed to make sSPI_port = 1 so I am using SPI1 for the slave. Correct.

CS master: 15 => CS slave 6
MOSIO master: 11 => 5
MISO master: 12 => 0
CLK master:14 => 20

Reason why I am asking is because I still can't get anything

tonton81 · May 11, 2018

yes thats good

Heres an observation that I see while debugging:

Code:

1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
2 3 4 5 6 7 8 9 10 37481 65535 0 0 1744 8192 255 0 3 0 32896 128 8139 0 1744 8192 6040 8192 120 0 6000 8192 0 0 1 1 0 0 128 0 255 0 3 0 32896 128 1229 0 128 0 14395 0 128 0 
1 3 4 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3 
1 2 3

This seems to be pretty consistant (in terms of exact error) (im debugging at 50ms F&F loops), to me this looks like the first byte may have been dropped in the LC "intermittantly"

I've played with the interrupts, disable them while in the ISR, trying different things, however, results so far are identical.

tonton81 · May 11, 2018

To rule out first byte loss (i think) i highered the F&F trigger from 50ms to 200ms

At 200ms F&F loops, I noticed this:

Code:

1 2 3 
1 2 3 
1 2 [COLOR="#FF0000"]4 [/COLOR]
1 2 3 
1 2 3 
1 2 3

The above I only printing first 3 of the 10 dwords, to rule out Serial overloading. Somehow 3 was discarded and filled with next dataword 4...

Something, somewhere, on LC is dropping data, this isn't an issue caused by MST

tonton81 · May 11, 2018

Anyway, just out of curiosity do you need to set SPI.setCS(2); to SPI.setSCK(14); SPI.setMOSI(11); SPI.setMISO(12); SPI.begin(); or are you going to leave it up the user to add it to his code?

if a user does SPI.begin() without setting the pins first, they would loose access to UART2, unless they call Serial2.begin() after SPI.begin();, the led would also be assigned to the port as well

mjs513 · May 11, 2018

Ok. bout ready to give up - have tried pretty much everything now. Still can't get any out on the LC. I am at 6mhz SPI, master at 168 (T3.5) and slave at 48. Redid the wiring again just in case. Later will try a couple of 10k resistor on cs and MISO just in case. All I am getting on the master is:

Code:

F&F (OT=0) OT_CALC==300  micros() _time==181

but nothing showing up on the slave. I don't have events or led on the slave - I have events on the master and LEDs commented out.

Sorry I can't be of more help at this point.

tonton81 · May 11, 2018

oh your running original f&f code? im testing small transfer16 f&f’s values 0->10, dont forget the buffers are set to 4,100, so the 196dword on original code should never work...

mjs513 · May 11, 2018

Kind of sort of. I know very articulate - sending 12 doubles. But finally got something coming across on the LC but I have to include slave.events() to make it work. Thought that wasn't working? Going to lower it to 10 and just make it 0-9 for now.

tonton81 · May 11, 2018

oh! i meant no master events(), slave needs it always for callback listening! sorry

post 1501 has the slave sample

mjs513 · May 11, 2018

Yep - actually using that example with a slight modification in the setup. Nothing to do with MST though

defragster · May 11, 2018

tonton81 said:
To rule out first byte loss (i think) i highered the F&F trigger from 50ms to 200ms

At 200ms F&F loops, I noticed this:

Code:

1 2 3 1 2 3 1 2 [COLOR="#FF0000"]4 [/COLOR] 1 2 3 1 2 3 1 2 3

The above I only printing first 3 of the 10 dwords, to rule out Serial overloading. Somehow 3 was discarded and filled with next dataword 4...

Something, somewhere, on LC is dropping data, this isn't an issue caused by MST

One of the things I did in that SLAVE DEBUG HACK (?) - was print the first value - then just a dot ( some filler ) when the next value was as expected - just skipped that fat load of output when the data was indexing right.

USB speed is 12 MHZ { net throughput is roughly 8 Mbits } - so printing 1 byte for each transfer should not hurt anything. Only problem is when a huge output from ERROR occurs and that shlows things down and can cascade more errors.

I tested that in prior posts as noted - with best USB3 port speed the T_3.6 was only 17% faster than the T_LC - so the T_LC USB is not much slower.

mjs513 · May 11, 2018

Ok got everything working now. Running the T3.5 at 168Mhz, LC at 48mhz and 8mhz spi. 10 Doubles sent in F&F packet format to slave every 25ms. Getting OTs periodically but heres a sample:

Code:

F&F (OT=8) OT_CALC==300  micros() _time==160
F&F (OT=8) OT_CALC==300  micros() _time==161
F&F (OT=8) OT_CALC==300  micros() _time==161
F&F (OT=8) OT_CALC==300  micros() _time==161
F&F (OT=8) OT_CALC==300  micros() _time==161

Not seeing any strange misses on the LC side:

Code:

0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00  8.00  9.00  
0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00  8.00  9.00  
0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00  8.00  9.00  
0.00  1.00  2.00  3.00  4.00  5.00  6.00  7.00  8.00  9.00

always the same.

UPDATE: I changed the slave to look a little more like the old slave so here is something else to ponder;

Code:

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> 10.00
0.00,1.00,2.00,3.00,4.00,5.00,6.00,7.00,8.00,9.00,8564,8564 [40 ,0

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> 10.00
0.00,1.00,2.00,3.00,4.00,5.00,6.00,7.00,8.00,9.00,8565,8565 [40 ,0

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> 10.00
0.00,1.00,2.00,3.00,4.00,5.00,6.00,7.00,8.00,9.00,8566,8566 [40 ,0

mjs513 · May 12, 2018

Morning all,
Took the time this morning to put back the LCmaster/Slave sketches I am using and all seems to be running with the exceptions that you do get a bunch of OT's occurring on a somewhat regular basis on the slave its reflected as bad lastvals (Yes is fixed the code so now sending id's 55 and 60):

Code:

4374.00, #, #, #, #, #, #, #, #, #,6705,9 [38 ,0
4384.00, #, #, #, #, #, #, #, #, #,6706,9 [38 ,0
4394.00, #, #, #, #, #, #, #, #, #,6707,9 [38 ,0

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> -10.00
4414.00,4415.00,4416.00,4417.00,4418.00,4419.00,4420.00,4421.00,4422.00,4423.00,6708,10 [37 ,0

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> -10.00
4434.00,4435.00,4436.00,4437.00,4438.00,4439.00,4440.00,4441.00,4442.00,4443.00,6709,11 [37 ,0
4454.00  4455.00  4456.00  4457.00  4458.00  4459.00  4460.00  4461.00  4462.00  4463.00  

Bad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> -10.00
4464.00,4465.00,4466.00,4467.00,4468.00,4469.00,4470.00,4471.00,4472.00,4473.00,6710,12 [37 ,0
4474.00, #, #, #, #, #, #, #, #, #,6711,12 [37 ,0
4484.00, #, #, #, #, #, #, #, #, #,6712,12 [37 ,0
4494.00, #, #, #, #, #, #, #, #, #,6713,12 [37 ,0
4504.00, #, #, #, #, #, #, #, #, #,6714,12 [37 ,0
4514.00, #, #, #, #, #, #, #, #, #,6715,12 [37 ,0
4524.00, #, #, #, #, #, #, #, #, #,6716,12 [37 ,0

Again this is run at 8Mhz SPI. Right now after about 47k got about 28 ots. Going to try at 6Mhz and see what happens

EDIT:
@6 Mhz had 10Ots at 54K on the slave
@4 Mhz had 0 Ots at 74k on the slave

Could the OTs and your results be caused by too small a CB?

mjs513 · May 12, 2018

Tony - Tim
For reference here are the sketches I am using for the master and the slave (look familiar):
Master:

Code:

#include <SPI.h>
#include <SPI_MSTransfer.h>
#include "A_ConfigDefines.h"

//#define SPI_SPEED 30500
#define SPI_SPEED 4000000
#define OT_CALC   100*(30000000/SPI_SPEED)

SPI_MSTransfer teensy_gpio = SPI_MSTransfer("Serial", SPI_MST_CS, &SPI_MST_BUS, SPI_SPEED ); // bad with default timeouts

void setup() {
  
  Serial.begin(115200);
  while (!Serial && millis() < 2000 ) {}
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  teensy_gpio.debug(Serial);

#ifdef SPI_MST_SCK
  SPI_MST_BUS.setSCK( SPI_MST_SCK );
#endif
  SPI_MST_BUS.begin();
  delay(5000);
}

uint32_t OverTime = 0;
void loop() {
  static uint32_t _timer = millis();
  //static uint32_t _timer1 = micros();
  //if ( !(millis() % 100) )  { teensy_gpio.pinToggle(LED_BUILTIN); Serial.print("^LT"); delay(1); }
  if ( millis() - _timer >= 25 ) {
    _timer = millis();
    //_timer1 = micros();
    uint32_t _time = micros();
    
    uint16_t *buf;
    double MST_PrintVals[10];
    buf = (uint16_t *)MST_PrintVals;
    int ii = 0;
    static uint16_t __count = 0;
    static uint16_t __countB = 0;
    for ( uint32_t i = 0; i < sizeof(MST_PrintVals) / sizeof( MST_PrintVals[0]  ); i++ ) MST_PrintVals[i] = __count++;

    Serial.print("F&F (OT=");
    Serial.print( OverTime );
    Serial.print(")");
    _time = micros();

    __countB++;
    if ( __countB % 25 )
      teensy_gpio.transfer16((uint16_t *)MST_PrintVals, sizeof(MST_PrintVals) / 2, 60, 1); // DEBUGHACK output
    else
      teensy_gpio.transfer16((uint16_t *)MST_PrintVals, sizeof(MST_PrintVals) / 2, 55, 1);

    _time = micros() - _time;
    Serial.print(" OT_CALC==");
    Serial.print(OT_CALC);
    Serial.print("  micros() _time==");
    Serial.println(_time);
    if ( _time > OT_CALC ) OverTime++;
  }
}

Slave:

Code:

#include <SPI_MSTransfer_Slave.h>

void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 5000 )
  { Serial.print( "Teensy NOT Online @ millis=" );
    Serial.println( millis() );
    delay(30);
  }
  Serial.print( "Teensy Online @ millis=" );
  Serial.println( millis() );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

  if ( ARM_DWT_CYCCNT == ARM_DWT_CYCCNT ) {
    Serial.print( "Cycle Counter Not Enabled :" );
    Serial.println( ARM_DWT_CYCCNT );
  }
  if ( ARM_DWT_CYCCNT == ARM_DWT_CYCCNT ) {
    // Enable CPU Cycle Count
    ARM_DEMCR |= ARM_DEMCR_TRCENA;
    ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;
  }
  if ( ARM_DWT_CYCCNT != ARM_DWT_CYCCNT ) {
    Serial.print( "Cycle Counter Enabled! :" );
    Serial.println( ARM_DWT_CYCCNT );
  }


  
  slave.begin( );
  slave.onTransfer(myCallback);
}

void loop() {
  slave.events();
}

static uint16_t last_packetID = 0;
elapsedMillis TogClk;
uint32_t TogCnt = 0;
uint32_t FaFCnt = 0;
void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {
  if ( 55 == info.packetID ) {
    if ( 40 != length ) {
      Serial.print("Bad Length: "); Serial.println(length); // If this shows then the SPI Passed array size is nor wrong
    }
    else if ( 0 != info.error ) {
      Serial.println("\nBad CRC: ");
    }
    else {
      double* MST_PrintVals;
      MST_PrintVals = (double *)buffer;
      
      for(int i = 0; i<10; i++){
        Serial.print(MST_PrintVals[i]); Serial.print("  ");
      }
      Serial.println();
    }
  }

  else if ( 60 == info.packetID ) {
    if ( 40 != length ) {
      Serial.print("Bad Length: "); Serial.println(length); // If this shows then the SPI Passed array size is nor wrong
    }
    else if ( 0 != info.error ) {
      Serial.println("\nBad CRC: ");
    }
    else {
      double* MST_PrintVals;
      MST_PrintVals = (double *)buffer;

      //for(int i = 0; i<10; i++){
      //  Serial.print(MST_PrintVals[i]); Serial.print("  ");
      //}
      //Serial.println();
      
// This provides a terse output with error checked based on MASTER output to the 12 DOUBLE value Array
      {
        static uint16_t TogLast = 0;
        static uint16_t TogHz =0;
        static uint16_t FaFHz =0;
        static double LastVal = 100000;
        static uint32_t ChkErr = 0;
        static uint32_t CBcount = 0;
        //if ( digitalReadFast( LED_BUILTIN) != TogLast ) { 
        //  TogLast = !TogLast; 
        //  TogCnt++; 
        //}
        if ( TogClk >=1000 ) {
          TogClk -= 1000;
          TogHz = TogCnt;
          TogCnt = 0;
          FaFHz = FaFCnt;
          FaFCnt = 0;
        }
        if ( last_packetID != info.packetID ) {
          LastVal += 10;
          if ( LastVal > 65536 && LastVal < 100000 ) LastVal -= 65536;
        }
        elapsedMillis LastCB;
        double DiffMiss = 0;
        uint32_t ErrSeen = 0;
        CBcount++;
        FaFCnt++;
        for ( uint32_t ii = 0; ii < 10; ii++ ) {
          LastVal++;
          if ( 65536 == LastVal ) LastVal = 0;
          if ( LastCB > 10 || 100001 == LastVal || 100013 == LastVal ) LastVal = MST_PrintVals[ii];
          if ( LastVal != MST_PrintVals[ii] ) {
            DiffMiss = LastVal - MST_PrintVals[ii];
            ChkErr++;
            Serial.print("\nBad LASTVAL TEST INCREMENT <<<<<<<<<<<<<<<<<<<< DIFF OF> ");
            Serial.println( DiffMiss );
            LastVal = MST_PrintVals[ii];
            ErrSeen++;
          }
          if ( 0 != ErrSeen || 1 > ii ) {
            Serial.print( MST_PrintVals[ii] );
            Serial.print(",");
          }
          else {
            Serial.print(" #,");
          }
        }
        Serial.print( CBcount );
        Serial.print(",");
        Serial.print( ChkErr );
        Serial.print(" [");
        Serial.print( FaFHz );
        Serial.print(" ,");
        Serial.print( TogHz );
        Serial.println();
        LastCB = 0;
      }
      
    }
  }
  else {
    Serial.print("PacketID: ");
    Serial.println(info.packetID);
  }
  last_packetID = info.packetID;
}

tonton81 · May 12, 2018

16 arrays of 50 doesnt change anything during testing, theres an issue in the LC's hardware (or core?)

If default NVIC is set (i dont know default priority), I can see random garbage entering the data/lost bytes intermittantly

If I set the slave's NVIC to 0 or 1, It seems to be running alot better, however, its very intermittant to get garbage still
I can only presume at this point there is another resource overtaking the priority (we're only using SPI & SerialUSB...) that may be causing a hiccup to the SPI databus
Really weird..

EDIT, pushing usbserial, uarts, wire, spare SPI to IRQ level 128 and leaving SPI1 slave at level 0, same issue.

tonton81 · May 12, 2018

VERY INTERESTING.
I modified a core function, can you guess which?

SPI.h

Code:

	uint16_t transfer16(uint16_t data) {
		port().SR = SPI_SR_TCF;
		port().PUSHR = data | SPI_PUSHR_CTAS(1);
		while (!(port().SR & SPI_SR_TCF)) ; // wait
                [COLOR="#FF0000"]delayMicroseconds(5);[/COLOR] 
		return port().POPR;
	}

Adding this line to the MASTER before it reads the POPR register seems to not give anymore blips from slave, running at 10mS F&F loops...
NOTE, 1uS does NOT work, but I get no more blips at 5uS before pulling!
I'm going to be testing this for now...

If this works well I might have to make a transfer16 just for the library, and not use the core version.

unfortunately, this brings the F&Fs to 150uS for 10 dwords+F&F overhead in tight 5ms loops... (at 8MHz SPI)

EDIT, even 1ms loops work with this patch!

I might need to redesign MST after, use a write only non return with the 5mS omitted, and a write & read method for capturing... I do believe the read corruption at master end is leading to those blips due to the POPR register not being filled properly.....

tonton81 · May 12, 2018

NOW..
as simple as this is, its working fine.

Code:

#elif defined(KINETISL) //////////////////////////////////////////////////////////////
      while ( !(GPIOD_PDIR & sSPI_port_gpioloop) ) { // wait here until MASTER confirms F&F receipt
        if ( SPI1_S & SPI_S_SPRF ) {
          if ( ( ((*(KINETISL_SPI_t *)spi_mst_spi_addr).DH) << 8 | ((*(KINETISL_SPI_t *)spi_mst_spi_addr).DL) ) == 0xD0D0 ) break;
          (*(KINETISL_SPI_t *)spi_mst_spi_addr).DH = 0xBA;
          (*(KINETISL_SPI_t *)spi_mst_spi_addr).DL = 0xBE;
        }
      }
#endif ///////////////////////////////////////////////////////////////////////////////

EDIT, without setting the DL/DH registers for CMD entry, we now have 134/135uS F&F's at 8MHz (CMD entry doesnt need to send anything really, it seems the LC takes ~ 20uS to set those entries lol...)

tonton81 · May 12, 2018

OK, I'm doing a test implementation for master (hardcoded for now to test)

Code:

uint16_t SPI_MSTransfer::_transfer16_write(uint16_t data) {
  SPI2_SR = SPI_SR_TCF;
  SPI2_PUSHR = data | SPI_PUSHR_CTAS(1);
  while (!(SPI2_SR & SPI_SR_TCF)) ; // wait
  return SPI2_POPR;
}
uint16_t SPI_MSTransfer::_transfer16_writeread(uint16_t data) {
  SPI2_SR = SPI_SR_TCF;
  SPI2_PUSHR = data | SPI_PUSHR_CTAS(1);
  while (!(SPI2_SR & SPI_SR_TCF)) ; // wait
  delayMicroseconds(5); 
  return SPI2_POPR;
}

these will be private methods of the library instead of using the core version. The first one doesnt do any reading, the second one reads with a 5uS delay (I will most likely have that defined out if an LC is used as a slave).

and the master F&F mod:

Code:

    if ( fire_and_forget == 1 ) {
      SPI_assert();
      for ( uint16_t i = 0; i < data[1]; i++ ) [COLOR="#FF0000"]_transfer16_write[/COLOR](data[i]);
      uint32_t timeout = millis();
      while ( [COLOR="#FF0000"]_transfer16_writeread[/COLOR](0xFFFF) != 0xBABE && millis() - timeout < 100 );
      [COLOR="#FF0000"]_transfer16_write[/COLOR](0xD0D0); // send confirmation
      SPI_deassert();
      return data[4]; // F&F, RETURN PACKETID
    }

Here are the F&F response times at 8MHZ in a 10ms loop:

Code:

mjs513 · May 12, 2018

After looking at SPI.h I would say it begin transaction ?

Looks a lot better. Can't wait to give it a go. Let me know when you are ready.

tonton81 · May 12, 2018

Heres something else very interesting, when I enable Led toggling with adaptive LC settings, I get intermittant pauses, I went from 8 mhz, to 4, to 2 and even 1, same issue. As soon as I selected 150KHz, its running led toggling without pauses!
500KHz and up have pauses and crashes with LED & F&F

400KHZ, 300KHZ, 150KHZ, 100KHZ are all working! what the heck ?

Looking at the KL25 chipset which is similar to the MKL26 LC, I've stumbled onto other forums, and spotted things like:

Code:

  SPI0_C1 = SPI_C1_SPE_MASK | SPI_C1_MSTR_MASK; // Enable SPI0 module, master mode //SETS SPI ENABLE AND SPI MASTER BITS  
  SPI0_BR = SPI_BR_SPPR(0x04) | SPI_BR_SPR(0x02) ; // BaudRate = BusClock / ((SPPR+1) * 2^(SPR+1)) = 20970000 / ((4+1) * 2^(2+1)) = [COLOR="#FF0000"]524.25 kHz  [/COLOR]
  //SPI0_BR = SPI_BR_SPPR(0x00) | SPI_BR_SPR(0x00) ; // BaudRate = BusClock / ((SPPR+1) * 2^(SPR+1)) = 20970000 / ((4+1) * 2^(2+1)) = 5240.25 kHz

Why on earth people wanna run these in KHz mode? Something is definately wrong somewhere

at 400KHz we're looking at 999uS for F&F and LED, hasnt paused or crashed yet!, going 500 or above will definately cause "issues"

Project: SPI_MSTransfer

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member