Project: SPI_MSTransfer

Just an idea of the code difference:

Old code events:
Code:
    if ( _slave_handler == nullptr ) {
      if ( teensy_handler_queue.size() > 0 ) teensy_handler_queue.pop_front();
      return 0;
    }
    if ( teensy_handler_queue.size() > 0 ) {
      auto _deque = move(teensy_handler_queue.front());
      teensy_handler_queue.pop_front();
      uint16_t checksum = 0, _deque_pos = 0, _buf[_deque[3]];
      for ( uint16_t i = 0; i < _deque[1] - 1; i++ ) checksum ^= _deque[i];
      memmove (&_buf[0], &_deque[5], _deque[3] * 2 );
      if ( _slave_handler != nullptr ) {
        AsyncMST info;
        if ( checksum != _deque[_deque[1] - 1] ) info.error = 1;
        info.packetID = _deque[4];
        _slave_handler(_buf, _deque[3], info);
        return 0;
      }
    }
New code events()
Code:
    if ( mtsca.size() > 0 ) {
      uint16_t checksum = 0, buf_pos = 0, len = mtsca.front()[3], buf[len]; AsyncMST info;
      for ( uint16_t i = 0; i < mtsca.front()[1] - 1; i++ ) checksum ^= mtsca.front()[i];
      ( checksum == mtsca.front()[mtsca.front()[1]-1] ) ? info.error = 0 : info.error = 1;
      info.packetID = mtsca.front()[4];
      len = mtsca.front()[3];
      memmove (&buf[0], &mtsca.front()[5], mtsca.front()[3] * 2 );
      mtsca.pop_front();
      if ( _slave_handler != nullptr ) _slave_handler(buf, len, info);
    }

alot cleaner than the STL methods!

even the F&F has only 1 memmove to do now
Code:
      _slave_pointer->SPI_MSTransfer::mtsca.push_back(data,len);

no more shuffling entries anymore :)

I also noticed I left the FASTRUN entries in place, gonna reflash master & slave to not use it and report back

EDIT: works without FASTRUN :)
EDIT2: no errors mean all consecutive entries are intact without loss! at 20ms intervals the 64 queued arrays are being recycled over, and over, and over, and over, in a incremental pattern! :)

EDIT3, also forgot to mention, events() are in main loop for both master & slave. So looking good so far

EDIT4, added master println statement to print when toggling led on slave console:

Code:
  if ( !(millis() % 1000) )  {
    teensy_gpio.println("Toggled Led");
    teensy_gpio.pinToggle(LED_BUILTIN); Serial.print("^LT"); delay(1);
    }

Slave output:

Code:
  0.000000,    0.0487,    0.0487,2792940.000000,2792997.250000,48748.0000,  220.7918,  220.7940,  220.7963,48752.0000,48753.0000,48754.0000
  0.000000,    0.0488,    0.0488,2793627.500000,2793684.750000,48760.0000,  220.8189,  220.8212,  220.8235,48764.0000,48765.0000,48766.0000
  0.000000,    0.0488,    0.0488,2794315.000000,2794372.250000,48772.0000,  220.8461,  220.8484,  220.8506,48776.0000,48777.0000,48778.0000
  0.000000,    0.0488,    0.0488,2795002.500000,2795059.750000,48784.0000,  220.8733,  220.8755,  220.8778,48788.0000,48789.0000,48790.0000
  0.000000,    0.0488,    0.0488,2795690.000000,2795747.500000,48796.0000,  220.9004,  220.9027,  220.9050,48800.0000,48801.0000,48802.0000
  0.000000,    0.0488,    0.0488,2796377.750000,2796435.000000,48808.0000,  220.9276,  220.9299,  220.9321,48812.0000,48813.0000,48814.0000
  0.000000,    0.0488,    0.0488,2797065.250000,2797122.500000,48820.0000,  220.9547,  220.9570,  220.9593,48824.0000,48825.0000,48826.0000
Toggled Led
  0.000000,    0.0488,    0.0488,2797752.750000,2797810.000000,48832.0000,  220.9819,  220.9842,  220.9864,48836.0000,48837.0000,48838.0000
  0.000000,    0.0488,    0.0488,2798440.250000,2798497.500000,48844.0000,  221.0090,  221.0113,  221.0136,48848.0000,48849.0000,48850.0000
  0.000000,    0.0489,    0.0489,2799127.750000,2799185.250000,48856.0000,  221.0362,  221.0385,  221.0407,48860.0000,48861.0000,48862.0000
  0.000000,    0.0489,    0.0489,2799815.500000,2799872.750000,48868.0000,  221.0633,  221.0656,  221.0679,48872.0000,48873.0000,48874.0000
  0.000000,    0.0489,    0.0489,2800503.000000,2800560.250000,48880.0000,  221.0905,  221.0927,  221.0950,48884.0000,48885.0000,48886.0000
  0.000000,    0.0489,    0.0489,2801190.500000,2801247.750000,48892.0000,  221.1176,  221.1199,  221.1221,48896.0000,48897.0000,48898.0000
  0.000000,    0.0489,    0.0489,2801878.000000,2801935.250000,48904.0000,  221.1447,  221.1470,  221.1493,48908.0000,48909.0000,48910.0000
  0.000000,    0.0489,    0.0489,2802565.500000,2802623.000000,48916.0000,  221.1719,  221.1741,  221.1764,48920.0000,48921.0000,48922.0000
 
Last edited:
Ok. Got it set up and running at 168/168 CPU, 30M bus. Tried 120/120 and 168/120 (Master/slave did not transfer - has to be the spi bus). Only up to 9K so will let it continue. By the way this is on T3.5 to T3.5. I got the 3.2 tied up right now. :)

Edit1: running 20/20ms loops. The master led toggle not working but still sending data - or maybe it is and its just on permanently.... The data still going and Slave toggle flashing nicely. Up to 22K. Think I will go take another nap.
 
awesome! I'm adding EEPROM support to SPI_MST now. Soon you will be able to access the EEPROM:

eeprom.read(location);
eeprom.write(location, value);
eeprom.update(location,value);
eeprom.length();
 
:) ok, you asked for it - when are you going to do a datalogger to the sd card :) Really I am only joking so don't get any ideas :)
 
Well yeah if you want to use the slave's SD slot, why not, we'll need ideas on implementation tho, my first attempt was making SPIFFS work on teensy lol :)
 
Tony you are unbelievable that you took me serious. Any still going strong even though its 20/20ms loops for the send - no collisions or hangs. You know, usually when I say that it crashes a few minutes later :) But so far no errors or OTs. Look like you broke the code :)
 
Making this its own post - l stopped watching it for a minute and it decided to give out on me, slave hung here:
26104.00, #, #, #, #, #, #, #, #, #, #, #,111403,0

Don't believe its the library at this point.
 
I Just added eeprom support, github files updated

Just added *.setRX(uint8_t pin) and *.setTX(uint8_t pin, bool opendrain=false) to the library
This can allow you to remotely swap the RX & TX pins of any of the Serial1 -> Serial6 ports

edit: added 2 more UART methods

virtual bool attachRts(uint8_t pin);
virtual bool attachCts(uint8_t pin);


The additions have been added on the repo files
 
Last edited:
Ok. Some bad news.

I just tried to compile the slave for the T3.2 and it will not fit. Guess have to make the buffers smaller or create a test for the board in the SPT_MSTransfer library. The exact error is:
Code:
c:/local programs/arduino-1.8.5-142b2/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_456508/slave.ino.elf section `.bss' will not fit in region `RAM'

c:/local programs/arduino-1.8.5-142b2/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 9040 bytes

Mike
 
edit the buffers change 250 to 100 if your using less than 100, also the main buffer can be reduced as well

also, once you got a good configuration we could use as default, we'll update the library
 
in the H
#define DATA_BUFFER_MAX 1024
static Circular_Buffer<uint16_t, 64, 250> mtsca;
static Circular_Buffer<uint16_t, 64, 250> stmca;

in the C
Circular_Buffer<uint16_t, 64, 250> SPI_MSTransfer::mtsca;
Circular_Buffer<uint16_t, 64, 250> SPI_MSTransfer::stmca;

you may also reduce the 64 entry circular array to 32 for testing as well (always use power of 2)
 
Added analog support:

Code:
    virtual void            analogReadResolution(unsigned int bits);
    virtual uint32_t        analogWriteResolution(uint32_t bits);
    virtual int             analogRead(uint8_t pin);
    virtual void            analogWrite(uint8_t pin, int val);
 
I stopped adding methods for now since its 7:30PM

Mike, I admit, my buffers may be exageratted, but I was going for real tests I guess, after you reduced them to logical values either repost what you recommend for the circular array and spi buffer so we can use those as defaults

Also, remote I2C and SPI support will come later on, for now I added eeprom and analog support, so thats good for now while we run stability tests :)

EDIT: BTW, at 30 MHZ SPI, i have T3.6M and T3.5S slamming each other at 5ms rates! OT = 0! https://www.youtube.com/watch?v=ba2278nPlLI

Also, that "blip" on the slave is "Toggled Led" scrolling by every time the led toggles, the master is actually "printing it"

slaveSerial.println("Toggled Led"); :)

just remember if the circular system is able to fill faster than your processing, obviously you'll get an error (in your own code handling) as the next data was "offset", thats a given. however, the data will not be corrupt, thats a plus! usually you'd fix slow processing, or, raise the queue system, which is why i chose 64 as default, less chances to loop around to head position while they play cat and mouse :)

perhaps its also a good idea when the master connects to the slave, it sends a clear signal from setup, which clears the queue system so the head & tail will be as far as possible on the slave before sending data to it
 
Last edited:
Will do - going to download the latest changes first :) I really am thinking it something with the T3.5 master. Have you ever tried the T3.5 as the Master and the T3.6 as the slave? To be honest I keep forgetting if Tim is using the T3.6/T3.1 combo or the T3.5/T3.1 combo. Going to play some more. Will keep you posted.

Mike
 
Indeed I only have T3.6 and T3.5 setup here, I don't want to change things around on the breadboard as I have the ESP wired up and don't wanna touch the setup hehehe it's in a dormant state, but i dont wanna loose the wiring setup
i did buy quite a few teensy 3.5's and t3.6's, although, i dont have the solder gun available or time to do that, but i have a nice collection of teensies, including 3.2's, i bought a few of those without realizing teensy 3.5/3.6 was out, so they all been in their bags for quite a few months now

I'm testing out 20ms 2-way transfers now at 30MHz

I changed all the buffer sizes to 250 (including spi buffer) and changed the circular arrays to use 32 slots (32,250)
Since theres 2 circular array queues of 32,250, that gives 250*64+250 FIFO == 16250 dwords == 32500 bytes? ill let it run
 
Last edited:
Yeah, the same here, I have 5 T3.5s in different setups and a bunch of T3.6's unsoldered. Have to solder one up for testing. Believe it or not I only have a couple of T3.2's. Think I have to pick up a couple more one of these days.

EDIT: Running the test now on the T3.5/T3.1 combo. Just changed the number of rows from 64 to 32.
 
My setup just for the SPI_MST is T_3.6&T_3.1 - running OLD code (30 MHz SPI) now for many days at 2 ms F&F with only one (OT) error since startup. On the GPS_IMU board is it a T_3.6&T_3.5.

Been distracted thinking I'm editing a house floor plan to move into, and today I woke up to play in the driveway with a trackhoe to move around a bunch of 3-4' pieces of two 100' maple trees the PUD cut down 16 months back. And keeping the woodstove running.

You should have called your CB queues : MISO and MOSI :)
 
that would be funny, but if your serious, just confirm :)
although MISO MOSI are taken, we still need to abbreviate them, unless its okay within their scope :D

but the circular array system is working well!

2ms eh? thanks for heads up, i dropped the stm to 1000 intervals and mts to 0 intervals
looks like its holding (so far)

:D
 
I'll confirm I thought it would be funny - but seriously not necessary as stm and mts read as well or better for the ca's.
 
As noted FASTRUN only seems a good idea on T_3.6 with 8K cache - everything else it seems can't do that. With smaller code base of Circular_Buffer the T_3.6 cache may naturally hold it versus who know what was pulled in with the STL.

Wondering if the Slave might benefit from knowing when messages like .pinToggle are handled internally? Without requiring an explicit extra message. A short Circular buffer overwritten if not emptied?

Very odd that slower SPI doesn't work slower but more reliably? Based on Paul's reference note that Slave has to run no faster than F_BUS/4 it is impressive to see a 96 MHz T_3.1 keeping up with 30 MHz SPI? It should run at 1 MHz for reliable use at longer distance.

Another good test might be dropping NVIC priority from 0 to at or under USB level?
 
Ok, guys. Just a quick update before packing it in. Right now with the T3.5 @144Mhz and SPI at 36Mhz, and the T3.1 at 120Mhz, its been going for the over 2.5hours and up to 512k transfers with no errors on the slave and one OT on the master (at startup). This is using 20ms loop on the master with a 40ms loop on the slave.

To make it fit the buffers were reduced from 64 to 32 as well. Think this works.

Now to figure out what's with the T3.5/T3.5 combo. That is the project for tomorrow. Going to let the present config keep running.

EDIT: ok. I stopped the test at 560k no errors. Changed the loops to 5ms on master and slave - lets see what happens.
 
Last edited:
great! mikes getting progress :)

tim, pintoggle handled internally? I played with NVIC before, even set it at 113 (just after USBSerial), i did read a post once where paul said theres no priorities used between 1-32 either, and we’re using 0 for highest, i didnt see any differences, i did post a link quite a few posts back which was a post from another thread where the spi clock was not “exactly” within its margin rate for certain cpu speeds, which may explain why some clock rates could mismatch and cause unreliability, sort of simillar to error rates of uarts
 
yup, still doesnt explain why it wont accept a simple 1mhz, i think its teasing us hehehehe
“you have a teensy, use its potential! dont put me in a crippled state!”

btw, we just surpassed 10k views
 
Hehehe! Need to have a celebration. Think you have a winner on your hands. :)

BTW. Almost forgot - with the circular buffers it would not have worked as shown before.

EDIT: After 40mins and 430K transfers showing 1 error and no OT's
 
Back
Top