Also! Lets debug the slave handler:
output:
the 12 dwords transfer is INTACT, why cant you sizeof the buffer (length2) ? because sizeof on a POINTER returns the size of the POINTER (4), and dividing by 2 gets you, well, 2. This is why when passing arrays to functions the length is specified by the USER sketch.
AFAICT, the library is doing it's job properly at both ends, a new demo will need to be exercised to fix the bad length. You might also gain performance without that 3x overhead traffic!
Code:
Serial.print("Length: "); Serial.println(length);
Serial.print("Length2: "); Serial.println(sizeof(buffer)/2);
for ( uint16_t i = 0; i < length; i++ ) {
Serial.print(buffer[i]); Serial.print(" ");
} Serial.println();
}
output:
Code:
Length: 12
Length2: 2
0 0 46080 16568 0 0 46336 16568 0 0 46592 16568
Length: 12
Length2: 2
0 0 49152 16568 0 0 49408 16568 0 0 49664 16568
Length: 12
Length2: 2
0 0 52224 16568 0 0 52480 16568 0 0 52736 16568
Length: 12
Length2: 2
0 0 55296 16568 0 0 55552 16568 0 0 55808 16568
Length: 12
Length2: 2
0 0 58368 16568 0 0 58624 16568 0 0 58880 16568
Length: 12
Length2: 2
0 0 61440 16568 0 0 61696 16568 0 0 61952 16568
Length: 12
Length2: 2
0 0 64512 16568 0 0 64768 16568 0 0 65024 16568
the 12 dwords transfer is INTACT, why cant you sizeof the buffer (length2) ? because sizeof on a POINTER returns the size of the POINTER (4), and dividing by 2 gets you, well, 2. This is why when passing arrays to functions the length is specified by the USER sketch.
AFAICT, the library is doing it's job properly at both ends, a new demo will need to be exercised to fix the bad length. You might also gain performance without that 3x overhead traffic!