Go Down

Topic: In Yun who is SPI Master ? (Read 245 times) previous topic - next topic

AgroMeInc

Hi,

In the Arduino Yun 1st generation who is SPI master ? The Carambola 2 or the AVR?

How about in Yun Generation 2 ?

TIA!
Alex

AgroMeInc

Looking at the schematic of the Yun G1 (https://www.arduino.cc/en/uploads/Main/arduino-Yun-schematic.pdf) it seems obvious that the Atheros is master.

Since the OE of the NTB0104 is pulled low I am assuming that it's only for programming the AVR.

My question now is, can I use the SPI pins on the AVR as master to control other SPI devices and go back to slave to program the AVR? What would be the best way to implement this?

 

pylon

Quote
Looking at the schematic of the Yun G1 (https://www.arduino.cc/en/uploads/Main/arduino-Yun-schematic.pdf) it seems obvious that the Atheros is master.
I don't think that this is obvious from the schematics.

Quote
Since the OE of the NTB0104 is pulled low I am assuming that it's only for programming the AVR.
That only shows that the Linux part is responsible to select the interface between the AVR and the NTB. Although programming the AVR be ICSP from the Linux part is possible by the hardware connection I'm not aware that it is used for the by any Arduino software.

Quote
My question now is, can I use the SPI pins on the AVR as master to control other SPI devices and go back to slave to program the AVR? What would be the best way to implement this?
Which of the two is SPI master and which slave is just a matter of the programming. As I'm not sure that the NTB supports SPI slave functionality I would expect the Linux part to be always master if SPI is activated. Standard bridge operations are done by the UART interface.

AgroMeInc

Quote
That only shows that the Linux part is responsible to select the interface between the AVR and the NTB. Although programming the AVR be ICSP from the Linux part is possible by the hardware connection I'm not aware that it is used for the by any Arduino software.
So when you program the AVR over the air it uses reset and bootloader via the UART just like any other Arduino? Are you certain of this?

Why did they hookup the SPI then? I was thinking that perhaps they always burn the complete flash, bootloader and all, or that there could be an option for this, since on the Luci Web interface you have the option to upload a sketch, you could perhaps load the one with the bootloader and write the whole thing. Else what is the purpose of the SPI connection between the Atheros chip and the ATmega ?

pylon

Quote
So when you program the AVR over the air it uses reset and bootloader via the UART just like any other Arduino? Are you certain of this?
No, I'm not. The over the air update might be a usage for the SPI bus as the caterina bootloader won't check the serial interface for uploads.

Quote
Else what is the purpose of the SPI connection between the Atheros chip and the ATmega ?
I always thought of it as just another possibility to communicate from the Linux side if you must use the hardware serial interface for other stuff.

AgroMeInc

One thing I can tell you for sure is that if anything else is connected to the SPI lines, it cannot program the AVR saying the AVR doesn't respond, so that's why I've been assuming that it uses SPI to program OTA.

I know this because I am using SPI as master from the AVR to control other peripherals (I take the lines from the ICSP connector) and I have had to add circuitry and logic to isolate the SPI lines when I need to program the AVR via OTA.

ShapeShifter

When a sketch is running, the AVR microcontroller and the Linux system talk to each other over the Serial1 port using the Bridge library. The SPI port is not used unless you have explicitly written code on both the AVR and Linux sides to enable it and use it.

When loading code over the USB port, the Arduino IDE builds a hex image of the sketch that does not include the serial bootloader. The AVR processor is then reset so that it enters the bootloader, and the sketch is downloaded to the AVR processor using the bootloader that is running on the AVR processor. In this way, the bootloader space remains unchanged, and only the portion of the program flash that holds the sketch is updated.

When loading code over the network, either through the Luci web interface, or directly from the IDE, things are a bit different. The IDE still builds a hex image of the sketch without the bootloader, and that hex image is transferred to the Linux system (either directly by the IDE, or manually through the Luci web pages.) The Linux system then combines the sketch's HEX image with the bootloader image, and then uses the SPI interface to load the entire program flash space including the bootloader and sketch. In this way, the Linux system acts like an ICSP loader pod. While this is happening, the Linux system is a SPI master, and the AVR microcontroller is a slave (although no sketch is running at this time, just as no bootloader is running.)

The SPI link between the Linux and AVR processors is normally deactivated so that the signals are isolated. When the Linux system is loading code, it asserts GPIO21, which enables the U5 level shifter chip. This connects the SS/MOSI/MISO/SCK lines on the AVR processor to GPIO26/GPIO27/GPIO8/GPIO11 on the Linux processor. The Linux processor then bit-bangs the SPI interface and loads the code. When done, the Linux processor de-asserts GPIO21, and the two systems are once again isolated.

If you have circuitry connected to the ICSP header on your Yun so that the sketch can use the SPI interface (as either master or slave) then you must take care that the circuit does not try to drive any of the SPI signals. The Linux processor must be free to drive the SS, MOSI, and SCK lines without interference, just as the AVR processor must be free to drive the MISO line without interference.

This is typically not an issue as long as the external SPI hardware is properly set up for a multi-device SPI interface. In other words, the slave device(s) never drives the lines unless it is selected, and when not selected, all lines are high impedance (inputs are normally high impedance, outputs will need to enter a tri-state condition.) The external hardware should only drive lines when its chip select input is active. Since the Linux processor drives the SS signal while loading code, you should not use the SS signal as the chip select signal for any SPI slave device, or it will be selected during the programming operation and interfere with loading code.

AgroMeInc

Wow, thank you so much for the detailed reply!! It explains a lot.

I had deduced that SPI was being used OTA but didn't realize that over the USB port it was more Arduino traditional via the AVR bootloader.

Also I always had doubt on which hex image to load via the luci Web pages. I have screwed up several times since I can't remember which of the two (with or without bootloader because they are both generated).

Maybe for Revision 2 there should be a note on the web loading page to help people from screwing it up.

BTW I just purchased a new Yun Rev 2 and can't wait to get my hands on it see how it's evolved. I think this is such a great product.

Thanks again!
Alex

Go Up