JustVince:
Regarding the header, see my first attachment it may be clearer.
That does help! I've never seen a shield connector with the extra pins like that. None of mine have it, and none of the pictures of Yun's that I've seen have it.
Is your board from Arduino.cc, Arduino.org, or somewhere else?
I did an image search, and I did find one picture that had the header you mention, on a clone board: TURQUOISE BOARD ARDUINO YUN COMPATIBLE- Based on the ATmega32u4 microcontroller and the Atheros AR93 Perhaps you have one of these clone boards, and not an official Arduino board? being a clone, I guess that's why those pins don't show up on the official schematics.
Incidentally, I do not understand why, while it is the same function (signal + enable) GP19 need to be exported unlike GP22?
I have no idea. I just know that GP22 was already exported on my units, and if I tried to export them again, I would get an error message. Perhaps it's because GP22 is dedicated as an output to control the level shifter chip output enable, so they figured it was safe to initialize it as an output. But GP19 is the data signal passing through the level shifter, and it could be used as either an input or an output. Since they don't know how it would be used, they don't initialize it ahead of time?
the link "Serial1" suffers from a jitter (between 210 and 270 kbps) which generates framing errors on the arduino side for a configuration of 250kbps with the distribution Lede 17.11.
That's rather disturbing! Seems to me that it would make all Bridge communications unstable on Rev 2 boards.
And I'm looking for C / C ++ or python code to make a fast and reliable MCU/MPU synchronization AND data communication via the SPI ...
Seems like it would be a matter of first turning on the output enables for the level shifter pins, and setting up the appropriate pins as inputs and outputs. On the '32U4 side, you should be able to use the SPI hardware interface, but on the Linux side you will need to bit-bang the interface, as it is not using SPI hardware on that end. It will take some research to see if there is an existing bit-bang driver you can use, or if you will have to do all of the bit twiddling yourself. If it's the latter, it's fortunate that SPI is a very easy protocol to manually bit-bang. I would make the Linux side the master, so that it has control of the clock, which will make the timing easier. Unfortunately, if you are looking for raw speed, bit-banging the interface is not the fastest way to go.