Project: SPI_MSTransfer

[tonton81]

nope, they as is, darnit, IDE seems cache cross-compiling
this is a pain lol

 

[defragster]

Are you using two of the same # Teensy? I have two instances of the IDE - run from .exe - not file open - each one to a different teensy and no issues?

 

[tonton81]

yup, always different instances, yesturday had an extra instance with esp, now i think i have memory out problems as im getting discolored windows, might need reboot soon

 

[defragster]

I just recompiled and uploaded to S::T_3.1 and M::T_3.6 - still nothing but RETRY...ABORT

 

[tonton81]

yup, replicated, let me debug, its prolly something stupid, data looks fine testing manually

I see whats going on
the bytes are working but dword types are not, its late though so ill try again tomorrow mst needs dwords to work

Output:

----------------------
[COLOR="#FF8C00"]Queue Size: 3, Index order: 0 1 0 
First Entry: 13 14 15 16 17 18 (6 entries.)
Last Entry: 13 14 15 16 17 18 (6 entries.)

Queue list: 
0) 13 14 15 16 17 18 (6 entries.)
1) 6 7 8 9 10 11 (6 entries.)
2) 13 14 15 16 17 18 (6 entries.)[/COLOR]

[COLOR="#0000CD"]Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 48 49 50 51 52 53 (6 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 55 77 88 (9 entries.)
2) 48 49 50 51 52 53 (6 entries.)[/COLOR]

blue == uint8_t Type
orange = uint16_t Type
The index order is not correct, and neither is the placement of the 3rd array

test code:

[COLOR="#FF8C00"]  Circular_Buffer<uint16_t, 10, 10> ba;
  uint16_t bb[] = { 0, 1, 2, 3, 4, 5 };
  uint16_t bc[] = { 6, 7, 8, 9, 10, 11, 12 };
  uint16_t bd[] = { 13, 14, 15, 16, 17, 18, 29, 20 };
  ba.push_back(bb, sizeof(bb) / 2);
  ba.push_back(bc, sizeof(bc) / 2);
  ba.push_back(bd, sizeof(bd) / 2);
  ba.list();[/COLOR]

[COLOR="#0000CD"]  Circular_Buffer<uint8_t, 8, 10> t;
  uint8_t bufy[6] = { 0, 1, 2, 3, 4, 5 };
  uint8_t bufy1[9] = { 6, 7, 8, 9, 10, 11, 55, 77, 88 };
  uint8_t bufy8[6] = { 48, 49, 50, 51, 52, 53 };
  t.push_back(bufy, 6); // 0
  t.push_back(bufy1, 9); // 6
  t.push_back(bufy8, 6);
  t.list();[/COLOR]

EDIT, silly me, 10 is not a power of 2!

Result:

----------------------
[COLOR="#FF8C00"]Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 13 14 15 16 17 18 29 20 (8 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 12 (7 entries.)
2) 13 14 15 16 17 18 29 20 (8 entries.)[/COLOR]

[COLOR="#0000CD"]Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 48 49 50 51 52 53 (6 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 55 77 88 (9 entries.)
2) 48 49 50 51 52 53 (6 entries.)[/COLOR]

seems good to me

 

[defragster]

Something odd on my end . . . restored examples and lib from github copy and it is 'not working' just the same ????

 

[tonton81]

Something odd on my end . . . restored examples and lib from github copy and it is 'not working' just the same ????

try reflashing MST with the github circular_buffer, both master and slave, i dont see a problem with the circular problem of new version so ill need to figure out what exactly is going on

 

[tonton81]

Even this works:

  ba.list();
  uint16_t bp[8];
  ba.pop_back(bp,8);
  for ( uint8_t i = 0; i < 8; i++ ) {
    Serial.print(bp[i]); Serial.print(" ");
  } Serial.println();

Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 13 14 15 16 17 18 29 20 (8 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 12 (7 entries.)
2) 13 14 15 16 17 18 29 20 (8 entries.)

[COLOR="#FF0000"]13 14 15 16 17 18 29 20 [/COLOR]

if push and pop work, dont know whats up with MST, im lost right now due to tiredness

aha!

  ba.push_back(bb, sizeof(bb) / 2);
  ba.push_back(bc, sizeof(bc) / 2);
  ba.push_back(bd, sizeof(bd) / 2);
  ba.list();
  uint16_t bp[8];
  ba.pop_front(bp,6);

pop front has a different bug:

----------------------
Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 13 14 15 16 17 18 29 20 (8 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 12 (7 entries.)
2) 13 14 15 16 17 18 29 20 (8 entries.)

6 0 1 2 3 4 29 20

gotta fix that

silly bug, needed an offset
red == added:

    memmove(&buffer[0],&_cabuf[_cbuf[(head)&(_size-1)]][COLOR="#FF0000"][1][/COLOR],length*sizeof(T)); // update CA buffer

correct output:

Queue Size: 3, Index order: 0 1 2 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 13 14 15 16 17 18 29 20 (8 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 12 (7 entries.)
2) 13 14 15 16 17 18 29 20 (8 entries.)

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

MST uses pop_front, so for sure this THREW IT OFF
hey its blinking now
one sec for new upload

 

[tonton81]

View attachment cb-bugfix.zip

please see if this works for you

i reflashed both master and slave and its perfect now
the pop_front offset was definately a bug causing the issue

this is what i get for integrating array length indexing support without taking breaks

now using teensyduino 1.42b3, and reuploaded both master and slave with the new bugfix and its still running smooth
as soon as its confirmed, we'll replace the github version, as the array system there is not really functional

You may see the differences between github (left) and new version (right)
https://www.diffchecker.com/7k6L2hES

pop_back(), list() were added
arrays are now indexed properly
library knows the actual size of all your arrays (excluding the buffer limits)

57680.00, #, #, #, #, #, #, #, #, #, #, #,184703,8676 [954 ,10
57692.00, #, #, #, #, #, #, #, #, #, #, #,184704,8676 [954 ,10
57704.00, #, #, #, #, #, #, #, #, #, #, #,184705,8676 [954 ,10
57716.00, #, #, #, #, #, #, #, #, #, #, #,184706,8676 [954 ,10
57728.000000,    0.0577,    0.0577,3307742.500000,3307799.750000,57733.0000,  240.2790,  240.2811,  240.2832,57737.0000,57738.0000,57739.0000
57740.00, #, #, #, #, #, #, #, #, #, #, #,184707,8676 [954 ,10
57752.00, #, #, #, #, #, #, #, #, #, #, #,184708,8676 [954 ,10
57764.00, #, #, #, #, #, #, #, #, #, #, #,184709,8676 [954 ,10
57776.00, #, #, #, #, #, #, #, #, #, #, #,184710,8676 [954 ,10
57788.00, #, #, #, #, #, #, #, #, #, #, #,184711,8676 [954 ,10
57800.00, #, #, #, #, #, #, #, #, #, #, #,184712,8676 [954 ,10
57812.00, #, #, #, #, #, #, #, #, #, #, #,184713,8676 [954 ,10
57824.00, #, #, #, #, #, #, #, #, #, #, #,184714,8676 [954 ,10
57836.00, #, #, #, #, #, #, #, #, #, #, #,184715,8676 [954 ,10
57848.00, #, #, #, #, #, #, #, #, #, #, #,184716,8676 [954 ,10
57860.00, #, #, #, #, #, #, #, #, #, #, #,184717,8676 [954 ,10
57872.00, #, #, #, #, #, #, #, #, #, #, #,184718,8676 [954 ,10

 

[defragster]

GOOD FIX !!!!!

Rebooted and cleaned my system - had a dupe MST in libraries that suddenly caused trouble. Pulled github copy added with cb-bugfix and it is blinking frantically.

Saw this: 21396.00, #, #, #, #, #, #, #, #, #, #, #,2030598,5 [951 ,10
with : F&F (OT=16) OT_CALC==100 micros() _time==56

<edit>: This time is UP to 56 from 51?

Both were compiled from new - not sure why those exact errors - one started first - but that shouldn't show in both?

Restarted Slave then master ... No errors in 225,000 at 30 MHz!


Rebuild Master to 3 MHz with 1000 F&F's - this is where I saw Errors and had to drop to 500 F&F's It is now working 1 ms F&F w/#55 and 10 pinToggles!

MASTER________________________________
F&F (OT=0) OT_CALC==1000 micros() _time==336
F&F (OT=0) OT_CALC==1000 micros() _time==336

SLAVE________________________________
32.00, #, #, #, #, #, #, #, #, #, #, #,272632,0 [953 ,10
44.000000, 0.0000, 0.0000,2692.901367,2750.197266, 49.0000, 7.0711, 7.1414, 7.2111, 53.0000, 54.0000, 55.0000
56.00, #, #, #, #, #, #, #, #, #, #, #,272633,0 [953 ,10

EDIT : Above hit 400,000 with NO ERRORS.

I dropped MASTER SPI to 2 MHz :: F&F takes 530 uS and the Slave is keeping up No Errors!

54224.00, #, #, #, #, #, #, #, #, #, #, #,103954,0 [950 ,10
54236.000000, 0.0542, 0.0542,3107665.500000,3107723.000000,54241.0000, 232.8991, 232.9013, 232.9034,54245.0000,54246.0000,54247.0000
54248.00, #, #, #, #, #, #, #, #, #, #, #,103955,0 [950 ,10

 

[tonton81]

umn, i guess the major CBA update was a success?

 

[defragster]

umn, i guess the major CBA update was a success?

From my testing YES - from this post it was the 3 MHz SPI in my test pair with 1000 msgs that lost some of the F&F's - and as tested that was fine at 3 and even slower 2 MHz now.

 

[tonton81]

awesome, ill override the repo copy in a few hours

 

[tonton81]

F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
^LTF&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==50
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==52
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51
F&F (OT=0) OT_CALC==100  micros() _time==51

45592.000000,    0.0456,    0.0456,2612401.000000,2612458.250000,45597.0000,  213.5369,  213.5392,  213.5416,45601.0000,45602.0000,45603.0000
45604.00, #, #, #, #, #, #, #, #, #, #, #,41330917,152865 [951 ,10
45616.00, #, #, #, #, #, #, #, #, #, #, #,41330918,152865 [951 ,10
45628.00, #, #, #, #, #, #, #, #, #, #, #,41330919,152865 [951 ,10
45640.00, #, #, #, #, #, #, #, #, #, #, #,41330920,152865 [951 ,10
45652.00, #, #, #, #, #, #, #, #, #, #, #,41330921,152865 [951 ,10
45664.00, #, #, #, #, #, #, #, #, #, #, #,41330922,152865 [951 ,10
45676.00, #, #, #, #, #, #, #, #, #, #, #,41330923,152865 [951 ,10
45688.00, #, #, #, #, #, #, #, #, #, #, #,41330924,152865 [951 ,10
45700.00, #, #, #, #, #, #, #, #, #, #, #,41330925,152865 [951 ,10
45712.00, #, #, #, #, #, #, #, #, #, #, #,41330926,152865 [951 ,10
45724.00, #, #, #, #, #, #, #, #, #, #, #,41330927,152865 [951 ,10
45736.00, #, #, #, #, #, #, #, #, #, #, #,41330928,152865 [951 ,10
45748.00, #, #, #, #, #, #, #, #, #, #, #,41330929,152865 [951 ,10
45760.00, #, #, #, #, #, #, #, #, #, #, #,41330930,152865 [951 ,10
45772.00, #, #, #, #, #, #, #, #, #, #, #,41330931,152865 [951 ,10
45784.00, #, #, #, #, #, #, #, #, #, #, #,41330932,152865 [951 ,10
45796.00, #, #, #, #, #, #, #, #, #, #, #,41330933,152865 [951 ,10
45808.00, #, #, #, #, #, #, #, #, #, #, #,41330934,152865 [951 ,10
45820.00, #, #, #, #, #, #, #, #, #, #, #,41330935,152865 [951 ,10
45832.00, #, #, #, #, #, #, #, #, #, #, #,41330936,152865 [951 ,10
45844.00, #, #, #, #, #, #, #, #, #, #, #,41330937,152865 [951 ,10
45856.00, #, #, #, #, #, #, #, #, #, #, #,41330938,152865 [951 ,10
45868.00, #, #, #, #, #, #, #, #, #, #, #,41330939,152865 [951 ,10
45880.00, #, #, #, #, #, #, #, #, #, #, #,41330940,152865 [951 ,10
45892.000000,    0.0459,    0.0459,2629589.750000,2629647.000000,45897.0000,  214.2382,  214.2405,  214.2429,45901.0000,45902.0000,45903.0000
45904.00, #, #, #, #, #, #, #, #, #, #, #,41330941,152865 [951 ,10
45916.00, #, #, #, #, #, #, #, #, #, #, #,41330942,152865 [951 ,10
45928.00, #, #, #, #, #, #, #, #, #, #, #,41330943,152865 [951 ,10
45940.00, #, #, #, #, #, #, #, #, #, #, #,41330944,152865 [951 ,10
45952.00, #, #, #, #, #, #, #, #, #, #, #,41330945,152865 [951 ,10
45964.00, #, #, #, #, #, #, #, #, #, #, #,41330946,152865 [951 ,10
45976.00, #, #, #, #, #, #, #, #, #, #, #,41330947,152865 [951 ,10
45988.00, #, #, #, #, #, #, #, #, #, #, #,41330948,152865 [951 ,10
46000.00, #, #, #, #, #, #, #, #, #, #, #,41330949,152865 [951 ,10
46012.00, #, #, #, #, #, #, #, #, #, #, #,41330950,152865 [951 ,10
46024.00, #, #, #, #, #, #, #, #, #, #, #,41330951,152865 [951 ,10
46036.00, #, #, #, #, #, #, #, #, #, #, #,41330952,152865 [951 ,10
46048.00, #, #, #, #, #, #, #, #, #, #, #,41330953,152865 [951 ,10
46060.00, #, #, #, #, #, #, #, #, #, #, #,41330954,152865 [951 ,10
46072.00, #, #, #, #, #, #, #, #, #, #, #,41330955,152865 [951 ,10
46084.00, #, #, #, #, #, #, #, #, #, #, #,41330956,152865 [951 ,10
46096.00, #, #, #, #, #, #, #, #, #, #, #,41330957,152865 [951 ,10
46108.00, #, #, #, #, #, #, #, #, #, #, #,41330958,152865 [951 ,10
46120.00, #, #, #, #, #, #, #, #, #, #, #,41330959,152865 [951 ,10
46132.00, #, #, #, #, #, #, #, #, #, #, #,41330960,152865 [951 ,10
46144.00, #, #, #, #, #, #, #, #, #, #, #,41330961,152865 [951 ,10
46156.00, #, #, #, #, #, #, #, #, #, #, #,41330962,152865 [951 ,10
46168.00, #, #, #, #, #, #, #, #, #, #, #,41330963,152865 [951 ,10
46180.00, #, #, #, #, #, #, #, #, #, #, #,41330964,152865 [951 ,10
46192.000000,    0.0462,    0.0462,2646778.500000,2646835.750000,46197.0000,  214.9372,  214.9395,  214.9418,46201.0000,46202.0000,46203.0000
46204.00, #, #, #, #, #, #, #, #, #, #, #,41330965,152865 [951 ,10
46216.00, #, #, #, #, #, #, #, #, #, #, #,41330966,152865 [951 ,10
46228.00, #, #, #, #, #, #, #, #, #, #, #,41330967,152865 [951 ,10
46240.00, #, #, #, #, #, #, #, #, #, #, #,41330968,152865 [951 ,10
46252.00, #, #, #, #, #, #, #, #, #, #, #,41330969,152865 [951 ,10
46264.00, #, #, #, #, #, #, #, #, #, #, #,41330970,152865 [951 ,10
46276.00, #, #, #, #, #, #, #, #, #, #, #,41330971,152865 [951 ,10
46288.00, #, #, #, #, #, #, #, #, #, #, #,41330972,152865 [951 ,10
46300.00, #, #, #, #, #, #, #, #, #, #, #,41330973,152865 [951 ,10
46312.00, #, #, #, #, #, #, #, #, #, #, #,41330974,152865 [951 ,10
46324.00, #, #, #, #, #, #, #, #, #, #, #,41330975,152865 [951 ,10
46336.00, #, #, #, #, #, #, #, #, #, #, #,41330976,152865 [951 ,10
46348.00, #, #, #, #, #, #, #, #, #, #, #,41330977,152865 [951 ,10
46360.00, #, #, #, #, #, #, #, #, #, #, #,41330978,152865 [951 ,10
46372.00, #, #, #, #, #, #, #, #, #, #, #,41330979,152865 [951 ,10
46384.00, #, #, #, #, #, #, #, #, #, #, #,41330980,152865 [951 ,10
46396.00, #, #, #, #, #, #, #, #, #, #, #,41330981,152865 [951 ,10
46408.00, #, #, #, #, #, #, #, #, #, #, #,41330982,152865 [951 ,10
46420.00, #, #, #, #, #, #, #, #, #, #, #,41330983,152865 [951 ,10
46432.00, #, #, #, #, #, #, #, #, #, #, #,41330984,152865 [951 ,10
46444.00, #, #, #, #, #, #, #, #, #, #, #,41330985,152865 [951 ,10
46456.00, #, #, #, #, #, #, #, #, #, #, #,41330986,152865 [951 ,10
46468.00, #, #, #, #, #, #, #, #, #, #, #,41330987,152865 [951 ,10
46480.00, #, #, #, #, #, #, #, #, #, #, #,41330988,152865 [951 ,10
46492.000000,    0.0465,    0.0465,2663967.000000,2664024.500000,46497.0000,  215.6339,  215.6363,  215.6386,46501.0000,46502.0000,46503.0000
46504.00, #, #, #, #, #, #, #, #, #, #, #,41330989,152865 [951 ,10
46516.00, #, #, #, #, #, #, #, #, #, #, #,41330990,152865 [951 ,10
46528.00, #, #, #, #, #, #, #, #, #, #, #,41330991,152865 [951 ,10
46540.00, #, #, #, #, #, #, #, #, #, #, #,41330992,152865 [951 ,10
46552.00, #, #, #, #, #, #, #, #, #, #, #,41330993,152865 [951 ,10
46564.00, #, #, #, #, #, #, #, #, #, #, #,41330994,152865 [951 ,10
46576.00, #, #, #, #, #, #, #, #, #, #, #,41330995,152865 [951 ,10
46588.00, #, #, #, #, #, #, #, #, #, #, #,41330996,152865 [951 ,10
46600.00, #, #, #, #, #, #, #, #, #, #, #,41330997,152865 [951 ,10
46612.00, #, #, #, #, #, #, #, #, #, #, #,41330998,152865 [951 ,10
46624.00, #, #, #, #, #, #, #, #, #, #, #,41330999,152865 [951 ,10
46636.00, #, #, #, #, #, #, #, #, #, #, #,41331000,152865 [951 ,10
46648.00, #, #, #, #, #, #, #, #, #, #, #,41331001,152865 [951 ,10
46660.00, #, #, #, #, #, #, #, #, #, #, #,41331002,152865 [951 ,10
46672.00, #, #, #, #, #, #, #, #, #, #, #,41331003,152865 [951 ,10
46684.00, #, #, #, #, #, #, #, #, #, #, #,41331004,152865 [951 ,10
46696.00, #, #, #, #, #, #, #, #, #, #, #,41331005,152865 [951 ,10
46708.00, #, #, #, #, #, #, #, #, #, #, #,41331006,152865 [951 ,10
46720.00, #, #, #, #, #, #, #, #, #, #, #,41331007,152865 [951 ,10
46732.00, #, #, #, #, #, #, #, #, #, #, #,41331008,152865 [951 ,10
46744.00, #, #, #, #, #, #, #, #, #, #, #,41331009,152865 [951 ,10
46756.00, #, #, #, #, #, #, #, #, #, #, #,41331010,152865 [951 ,10
46768.00, #, #, #, #, #, #, #, #, #, #, #,41331011,152865 [951 ,10
46780.00, #, #, #, #, #, #, #, #, #, #, #,41331012,152865 [951 ,10
46792.000000,    0.0468,    0.0468,2681155.750000,2681213.250000,46797.0000,  216.3285,  216.3308,  216.3331,46801.0000,46802.0000,46803.0000
46804.00, #, #, #, #, #, #, #, #, #, #, #,41331013,152865 [951 ,10
46816.00, #, #, #, #, #, #, #, #, #, #, #,41331014,152865 [951 ,10
46828.00, #, #, #, #, #, #, #, #, #, #, #,41331015,152865 [951 ,10
46840.00, #, #, #, #, #, #, #, #, #, #, #,41331016,152865 [951 ,10
46852.00, #, #, #, #, #, #, #, #, #, #, #,41331017,152865 [951 ,10
46864.00, #, #, #, #, #, #, #, #, #, #, #,41331018,152865 [951 ,10
46876.00, #, #, #, #, #, #, #, #, #, #, #,41331019,152865 [951 ,10
46888.00, #, #, #, #, #, #, #, #, #, #, #,41331020,152865 [951 ,10
46900.00, #, #, #, #, #, #, #, #, #, #, #,41331021,152865 [951 ,10
46912.00, #, #, #, #, #, #, #, #, #, #, #,41331022,152865 [951 ,10
46924.00, #, #, #, #, #, #, #, #, #, #, #,41331023,152865 [951 ,10
46936.00, #, #, #, #, #, #, #, #, #, #, #,41331024,152865 [951 ,10
46948.00, #, #, #, #, #, #, #, #, #, #, #,41331025,152865 [951 ,10
46960.00, #, #, #, #, #, #, #, #, #, #, #,41331026,152865 [951 ,10
46972.00, #, #, #, #, #, #, #, #, #, #, #,41331027,152865 [951 ,10
46984.00, #, #, #, #, #, #, #, #, #, #, #,41331028,152865 [951 ,10
46996.00, #, #, #, #, #, #, #, #, #, #, #,41331029,152865 [951 ,10
47008.00, #, #, #, #, #, #, #, #, #, #, #,41331030,152865 [951 ,10
47020.00, #, #, #, #, #, #, #, #, #, #, #,41331031,152865 [951 ,10
47032.00, #, #, #, #, #, #, #, #, #, #, #,41331032,152865 [951 ,10
47044.00, #, #, #, #, #, #, #, #, #, #, #,41331033,152865 [951 ,10
47056.00, #, #, #, #, #, #, #, #, #, #, #,41331034,152865 [951 ,10
47068.00, #, #, #, #, #, #, #, #, #, #, #,41331035,152865 [951 ,10
47080.00, #, #, #, #, #, #, #, #, #, #, #,41331036,152865 [951 ,10
47092.000000,    0.0471,    0.0471,2698344.500000,2698402.000000,47097.0000,  217.0207,  217.0230,  217.0253,47101.0000,47102.0000,47103.0000
47104.00, #, #, #, #, #, #, #, #, #, #, #,41331037,152865 [951 ,10
47116.00, #, #, #, #, #, #, #, #, #, #, #,41331038,152865 [951 ,10
47128.00, #, #, #, #, #, #, #, #, #, #, #,41331039,152865 [951 ,10
47140.00, #, #, #, #, #, #, #, #, #, #, #,41331040,152865 [951 ,10
47152.00, #, #, #, #, #, #, #, #, #, #, #,41331041,152865 [951 ,10
47164.00, #, #, #, #, #, #, #, #, #, #, #,41331042,152865 [951 ,10
47176.00, #, #, #, #, #, #, #, #, #, #, #,41331043,152865 [951 ,10
47188.00, #, #, #, #, #, #, #, #, #, #, #,41331044,152865 [951 ,10
47200.00, #, #, #, #, #, #, #, #, #, #, #,41331045,152865 [951 ,10
47212.00, #, #, #, #, #, #, #, #, #, #, #,41331046,152865 [951 ,10
47224.00, #, #, #, #, #, #, #, #, #, #, #,41331047,152865 [951 ,10
47236.00, #, #, #, #, #, #, #, #, #, #, #,41331048,152865 [951 ,10
47248.00, #, #, #, #, #, #, #, #, #, #, #,41331049,152865 [951 ,10
47260.00, #, #, #, #, #, #, #, #, #, #, #,41331050,152865 [951 ,10
47272.00, #, #, #, #, #, #, #, #, #, #, #,41331051,152865 [951 ,10
47284.00, #, #, #, #, #, #, #, #, #, #, #,41331052,152865 [951 ,10
47296.00, #, #, #, #, #, #, #, #, #, #, #,41331053,152865 [951 ,10
47308.00, #, #, #, #, #, #, #, #, #, #, #,41331054,152865 [951 ,10
47320.00, #, #, #, #, #, #, #, #, #, #, #,41331055,152865 [951 ,10
47332.00, #, #, #, #, #, #, #, #, #, #, #,41331056,152865 [951 ,10
47344.00, #, #, #, #, #, #, #, #, #, #, #,41331057,152865 [951 ,10
47356.00, #, #, #, #, #, #, #, #, #, #, #,41331058,152865 [951 ,10
47368.00, #, #, #, #, #, #, #, #, #, #, #,41331059,152865 [951 ,10
47380.00, #, #, #, #, #, #, #, #, #, #, #,41331060,152865 [951 ,10
47392.000000,    0.0474,    0.0474,2715533.250000,2715590.500000,47397.0000,  217.7108,  217.7131,  217.7154,47401.0000,47402.0000,47403.0000
47404.00, #, #, #, #, #, #, #, #, #, #, #,41331061,152865 [951 ,10
47416.00, #, #, #, #, #, #, #, #, #, #, #,41331062,152865 [951 ,10
47428.00, #, #, #, #, #, #, #, #, #, #, #,41331063,152865 [951 ,10
47440.00, #, #, #, #, #, #, #, #, #, #, #,41331064,152865 [951 ,10
47452.00, #, #, #, #, #, #, #, #, #, #, #,41331065,152865 [951 ,10
47464.00, #, #, #, #, #, #, #, #, #, #, #,41331066,152865 [951 ,10
47476.00, #, #, #, #, #, #, #, #, #, #, #,41331067,152865 [951 ,10
47488.00, #, #, #, #, #, #, #, #, #, #, #,41331068,152865 [951 ,10
47500.00, #, #, #, #, #, #, #, #, #, #, #,41331069,152865 [951 ,10
47512.00, #, #, #, #, #, #, #, #, #, #, #,41331070,152865 [951 ,10
47524.00, #, #, #, #, #, #, #, #, #, #, #,41331071,152865 [951 ,10

Just added 3 overload methods to follow other containers:
front() exists, so i also created peek_front() which calls front(), makes the intention clear when doing readable code
back() has the peek_back() method to peek at the data of the last queue item
clear() was added to the flush() method, since clear() is also used to clear array contents
Since we're dedicating a slot in the array bank for actual array length, I added a +1 for size for the _cabuf multimensional array, to compensate, because if a user creates 10 byte array, it really can support only 9.

T _cabuf[_size][multi[COLOR="#FF0000"]+1[/COLOR]];

with this added, user creates a 10 byte array will actually create 11 byte in background behind the scenes, so when he/she writes the 10 bytes, it fits perfect

added 3 more methods:

T capacity() { return _size; }
T length_back() { return _cabuf[(tail-1)&(_size-1)][0]; }
T length_front() { return _cabuf[_cbuf[(head)&(_size-1)]][0]; }

0) 0 1 2 3 4 5 (6 entries.)
1) 6 7 8 9 10 11 12 (7 entries.)
2) 13 14 15 16 17 18 29 20 (8 entries.)

Capacity: 16
Length Front: 6
Length Back: 8

16 is the total arrays in the multidimensional system, so free slots would be capacity() - size()
the lengths get actual lengths, not total system array length, so 6 instead of 10, and 8 instead of 10

Added vector's max_size() method, which is the max size of the current array
T max_size() { return multi; }

this is good if your writing arrays to the queue, to make sure they fit

if ( sizeof(buffer)/2 <= ca.max_size() ) { ca.push_back(buffer,sizeof(buffer)/2); }

added the replace method! compares minimum 3, maximum 5 buffer indexes for a match, before the buffer is replaced in queue system. This does NOT modify the head or tail positions:

  Circular_Buffer<uint8_t, 64, 10> k;
  uint8_t bufc[] = { 0, 1, 2, 3, 4, 5 };
  uint8_t bufc1[] = { 6, 7, 8, 9, 10, 11 };
  uint8_t bufc2[] = { 12, 13, 14, 15, 16, 17 };
  uint8_t bufc3[] = { 18, 19, 20, 21, 22, 23 };

  k.push_back(bufc, sizeof(bufc));
  k.push_back(bufc1, sizeof(bufc1));
  k.push_back(bufc2, sizeof(bufc2));
  k.push_back(bufc3, sizeof(bufc3));
  Serial.print("Q Size: "); Serial.println(k.size());
  //  t.match(bufa, 6, 0, 5, 2);
 [COLOR="#FF0000"] uint8_t bufme[] = { 6, 7, 8, 9, 88, 64, 33, 54, 88 };[/COLOR]
  k.list();
  [COLOR="#FF0000"]k.replace(bufme, sizeof(bufme), 1, 2, 3); <-- match buffer positions 1,2 and 3 between buffer & queue, replace if succeeded.[/COLOR] (7,8,9 values should match on both)
  k.list();

----------------------
Q Size: 4
Queue Size: 4, Index order: 0 1 2 3 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 18 19 20 21 22 23 (6 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
[COLOR="#FF0000"]1) 6 7 8 9 10 11 (6 entries.)[/COLOR]
2) 12 13 14 15 16 17 (6 entries.)
3) 18 19 20 21 22 23 (6 entries.)

Queue Size: 4, Index order: 0 1 2 3 
First Entry: 0 1 2 3 4 5 (6 entries.)
Last Entry: 18 19 20 21 22 23 (6 entries.)

Queue list: 
0) 0 1 2 3 4 5 (6 entries.)
[COLOR="#FF0000"]1) 6 7 8 9 88 64 33 54 88 (9 entries.)[/COLOR]
2) 12 13 14 15 16 17 (6 entries.)
3) 18 19 20 21 22 23 (6 entries.)

 

[tonton81]

I just realized I should have done a second offset for uint8_t types, for uint16_t/uint32_t types its fine, but the length storage max for uint8_t is 255 bytes, so I require 2 fields to keep length of bigger uint8_t arrays! doh!

regards to this, i now shifted everything 2 positions over
library is working with MST and the offset length << 8 /<< 16 are calculated by the Type 8*sizeof(Type) when length is stored in the first 2 slots
Now uint8_t types can define arrays bigger than 255.

View attachment circular_buffer_update.zip

Also corrected printout for loops to use uint16_t types instead of uint8_t for large array printouts

example of how library writes length to storage:

// from tail:
    _cabuf[_cbuf[tail&(_size-1)]][0] = length >> 8*sizeof(T);
    _cabuf[_cbuf[tail&(_size-1)]][1] = length;
// from head
    _cabuf[_cbuf[head&(_size-1)]][0] = length >> 8*sizeof(T);
    _cabuf[_cbuf[head&(_size-1)]][1] = length;

and how the length is calculated:

((T)(_cabuf[_cbuf[(head)&(_size-1)]][0] << 8*sizeof(T)) | _cabuf[_cbuf[(head)&(_size-1)]][1])

 

[defragster]

Ran the old code a bit faster last night micros >=450 :: 64,825,614 F&F's ( now counts the #50's )

64 missed messages - the T_3.1 is running at 144 MHz. Still running at 30 MHz with T_3.6 back to 240 MHz. ~17 of those were in first million.

43496.00, #, #, #, #, #, #, #, #, #, #, #,64825608,64 [2200 ,10
43508.00, #, #, #, #, #, #, #, #, #, #, #,64825609,64 [2200 ,10
43520.00, #, #, #, #, #, #, #, #, #, #, #,64825610,64 [2200 ,10
43532.00, #, #, #, #, #, #, #, #, #, #, #,64825611,64 [2200 ,10
43544.000000, 0.0435, 0.0435,2495059.250000,2495116.500000,43549.0000, 208.6864, 208.6888, 208.6912,43553.0000,43554.0000,43555.0000
43556.00, #, #, #, #, #, #, #, #, #, #, #,64825612,64 [2200 ,10
43568.00, #, #, #, #, #, #, #, #, #, #, #,64825613,64 [2200 ,10
43580.00, #, #, #, #, #, #, #, #, #, #, #,64825614,64 [2200 ,10

F&F (OT=0) OT_CALC==100 micros() _time==47
F&F (OT=0) OT_CALC==100 micros() _time==48

The T_3.1 one try at 120 MHz was worse than 96 MHz - that was at the old 1000 F&F/sec?

 

[tonton81]

the old code?

 

[defragster]

Emphasis added

Ran the old code a bit faster last night micros >=450 :: 64,825,614 F&F's ( now counts the #50's )

the old code?

 

[tonton81]

hehehe
i been very busy with feature implementation
im working on a MST feature atm
I hope the 2 latest circular_buffers is running great for you

 

[defragster]

Switching over to the post #915 version now. Initial startup looks to be error free :: 44440.00, #, #, #, #, #, #, #, #, #, #, #,328612,0 [2200 ,10

Last run <OLD CODE> shows 84,554,655 SPI Transfers:

980.00, #, #, #, #, #, #, #, #, #, #, #,84554655,164 [2200 ,10
53992.000000, 0.0540, 0.0540,3093685.500000,3093742.750000,53997.0000, 232.3747, 232.3768, 232.3790,54001.0000,54002.0000,54003.0000
54004.00, #, #, #, #, #, #, #, #, #, #, #,84554656,164 [2200 ,10

I keep getting the ideas that the Errors occur when I stop 'Autoscroll' and page around in the T_Sermon window - but cannot prove it. Except the first 17 errors were partly when I captured the current output ( not posted ) then above post #916 it shows 64 errors then when I stopped 'Autoscroll' to capture that I looked and there were 164 errors - now 2.5 hours later after letting it run - it is still at 164. Untouched overnight it went from 17 to 64 when doing an extra 60 Million messages.

Just to disprove my theory it worked perfectly - or the CB update fixed some issue? I scrolled around and got to over 2.34 Million with no Error issues detected:

42964.00, #, #, #, #, #, #, #, #, #, #, #,2341742,0 [2200 ,10

M T_3.6 @240 and T_3.1 @144 using SPI 30 MHz - F&F time is 45 uS and the delay between then limited by >= 450 micros.

Left alone running a bit - no OT's but some misses on F&F's #57 after 5,742,452:

21204.00, #, #, #, #, #, #, #, #, #, #, #,5742452,57 [2200 ,10

Going to back down Master send - may just be overwhelming the T_3.1 between SPI in and USB out current status:
19612.00, #, #, #, #, #, #, #, #, #, #, #,16573608,129 [2200 ,10

With timer check >= 600 it is hitting 1650/sec F&F's:
54972.00, #, #, #, #, #, #, #, #, #, #, #,460526,0 [1650 ,10
a #3 errors - 1096.00, #, #, #, #, #, #, #, #, #, #, #,3832533,3 [1650 ,10 - dropping spaces before #:

 

[tonton81]

umn, Tim..... *** waves the white flag ***


How does sending F&F uint8_t arrays sound?
I'm achieving 22uS for sending an array of 24 uint8_t's which are packed into 16 bit and unpacked at slave for callback

PacketID: 10750
Length: 24
64 6D FF 1F 0 0 0 0 64 6D FF 1F 0 0 0 0 0 0 0 0 4 0 0 0

T: 22

it uses the same circular buffer, the proper header gets forwarded to proper callback. all quad callbacks use same method onTransfer but your callbacks arrays activate the proper pointer:
in my case both callbacks are active when both handlers are passed into onTransfer:

  slave.onTransfer(myCallback);
  slave.onTransfer(myCallback8);

.................

  void myCallback8(uint8_t *buffer, uint16_t length, AsyncMST info) {
  void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {

I still need to add slave to master 8bit transfer capability, but its running well!

    uint8_t buffer[24];
    uint32_t ___time = micros();
    teensy_gpio.transfer(buffer, sizeof(buffer), 10750, 1);
    Serial.print("T: "); Serial.println(micros() - ___time);

so now you'll have transfer && transfer16 to play with......

at 48 bytes im achieving 33/34uS !!!!!!!!!!!
at 48 bytes WITHOUT F&F im achieving 44uS !!

MASTER -> SLAVE transfer & transfer16 are functional, with and without F&F!

I need time to work on slave -> master....tomorrow

[ATTACH]13409._xfImport[/ATTACH]

this is how i did dynamic sized packing:

    bool odd_or_even = ( (length % 2) );
    for ( uint16_t i = 0; i < length; i += 2 ) {
      if ( odd_or_even ) {
        if ( i + 1 < length ) {
          data[data_pos] = ((uint16_t)(buffer[i] << 8) | buffer[i+1]); checksum ^= data[data_pos]; data_pos++;
        }
        else {
          data[data_pos] = buffer[i]; checksum ^= data[data_pos]; data_pos++;
        }
      }
      else {
          data[data_pos] = ((uint16_t)(buffer[i] << 8) | buffer[i+1]); checksum ^= data[data_pos]; data_pos++;
      }
    }

and the receiving unpacking:

        bool odd_or_even = ( (array[3] % 2) );
        uint8_t buf[array[3]];
        for ( uint16_t i = 0, j = 0; i < array[3]/2; i++ ) {
          buf[j] = array[5+i] >> 8;
          buf[j+1] = (uint8_t)array[5+i];
          j+=2;
        }
        if ( odd_or_even ) buf[sizeof(buf)-1] = array[array[1]-2];

 

[defragster]

Sounds about the same ? The current message is TEN 8 byte doubles and TWO uint32_t's put each in 8 bytes. I could pack and save 8 bytes - but transfer time of the 96 bytes - with SPI_MST overhead - so 100 easy bytes in F&F in 45 uS doesn't sound any different.

I didn't bother packing because I expect the output to change - with new or different display values over time. Once I saw they were 8 byte double not 4 byte float I just decided to use a simple 12 entry array of double and be done.

Using a more generic CB to push the data into and then pop it out of might be cleaner or more generic and more usable than a string of [12] assignments with exacting but arbitrary [ii++] on each end - but a Struct would resolve that as well, I just didn't feel like making one it seems.

Running very well with the reduce USB text: 63548.00,#,#,#,#,#,#,#,#,#,#,#,14244617,9 [1650 ,10

 

[tonton81]

okay, well i guess others can use the 8 bit version for their 8bit arrays hehe

 

[defragster]

Put a 1 uS wait on Master and sped it up - still some few fails : 40804.00,#,#,#,#,#,#,#,#,#,#,#,4512119,12 [2200 ,10

Pushed it to 5 uS wait with _delay_before_deassertion = 5

Now it is not catching any missed F&F's so far. No Ot's on Master - running at a slower 50 uS with the delay, and Slave shows this with ZERO errors after 7,180,976 messages - back at higher speed >= 460 micros yielding 2200 SPI messages/per sec + pinToggle's::

44192.00,#,#,#,#,#,#,#,#,#,#,#,7180976,0 [2200 ,10

BOTTOM LINE: I think putting/accepting the NULL Transfer on the end of each message will keep the CS line switching under control.

 

[tonton81]

accepting the NULL?