Write A Program To Demonstrate Aplicaton of Spi Protocol For On Board Serial Communication
Write A Program To Demonstrate Aplicaton of Spi Protocol For On Board Serial Communication
Below is an example program demonstrating how to use the SPI (Serial Peripheral Interface)
protocol for on-board serial communication.
Here one Arduino acts as the SPI master, and the other acts as the SPI slave. The master sends data,
and the slave receives it.
#include <SPI.h>
void setup() {
// Start the Serial communication for debugging
Serial.begin(9600);
// Initialize SPI as a master
SPI.begin();
// Set the Slave Select pin as an output
pinMode(10, OUTPUT);
// Make sure the slave select is disabled (high) initially
digitalWrite(10, HIGH);
}
void loop() {
// Send data to the slave via SPI
digitalWrite(10, LOW); // Enable the Slave
byte dataToSend = 42; // Arbitrary byte to send
byte receivedData = SPI.transfer(dataToSend); // Send and receive data
digitalWrite(10, HIGH); // Disable the Slave
// Print the sent and received data to the Serial Monitor
Serial.print("Sent: ");
Serial.print(dataToSend);
Serial.print(", Received: ");
Serial.println(receivedData);
delay(1000); // Wait for 1 second
}
#include <SPI.h>
volatile byte receivedData = 0;
void setup() {
// Start the Serial communication for debugging
Serial.begin(9600);
// Initialize SPI as a slave with a specific SPI ID (0 is common)
pinMode(MISO, OUTPUT); // Set MISO as output for sending data back
SPI.begin(); // Start the SPI bus
SPI.attachInterrupt(); // Enable SPI interrupt
}
void loop() {
// Check if data is received
if (receivedData != 0) {
// Print the received data
Serial.print("Received: ");
Serial.println(receivedData);
receivedData = 0; // Reset the received data
}
}
// This function is called when the SPI transfer is complete
ISR(SPI_STC_vect) {
receivedData = SPDR; // Read received data from SPI Data Register
}
Explanation:
o This device sends a byte (in this case, 42) to the slave using the SPI.transfer()
function.
o The master continuously sends data every 1 second and prints both the sent and
received data to the Serial Monitor for debugging.
2. Slave (Arduino 2):
o This device is in SPI slave mode, waiting for data from the master.
o The slave reads data from the SPI Data Register (SPDR) whenever a transfer occurs.
10. Elaborate Super-loop based approach for firmware development and give some
applications of the same
• It is adopted for applications that are not time critical and where the response time
is not so important (embedded systems where missing deadlines are acceptable).
• It is very similar to a conventional procedural programming where the code is
executed task by task. The task listed at the top of the program code is executed first
and the tasks just below the top are executed after completing the first task.
• This is a true procedural one. In a multiple task based system, each task is executed
in serial in this approach.
The firmware execution flow for this will be
1. Configure the common parameters and perform initialization for various hardware
components memory,registers, etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
5. :
6. :
7. Execute the last defined task
8. Jump back to the first task and follow the same flow.
void main ()
{
Confi gurations ();
Initialisations ();
while (1)
{
Task 1 ();
Task 2 ();
:
:
Task n ();
}
}
Since the tasks are running inside an infinite loop, the only way to come out of the loop is
either a hardware reset or an interrupt assertion. A hardware reset brings the program
execution back to the main loop. Whereas an interrupt request suspends the task execution
temporarily and performs the corresponding interrupt routine and on completion of the
interrupt routine it restarts the task execution from the point where it got interrupted.
Almost all tasks in embedded applications are non-ending and are repeated infi nitely
throughout the operation. From the above ‘C’ code you can see that the tasks 1 to n are
performed one after another and when the last task (nth task) is executed, the fi rmware
execution is again re-directed to Task 1 and it is repeated forever in the loop. This repetition
is achieved by using an infi nite loop. Here the while (1) { } loop. This approach is also referred
as ‘Super loop based Approach’.
The ‘Super loop based design’ doesn’t require an operating system, since there is no need for
scheduling which task is to be executed and assigning priority to each task. In a super loop
based design, the priorities are fixed and the order in which the tasks to be executed are also
fixed. Hence the code for performing these tasks will be residing in the code memory without
an operating system image.
• The major drawback of this approach is that any failure in any part of a single task may
affect the total system. If the program hangs up at some point while executing a task,
it may remain there forever and ultimately the product stops functioning.
• There are remedial measures for overcoming this. Use of Hardware and software
Watch Dog Timers (WDTs) helps in coming out from the loop when an unexpected
failure occurs or when the processor hangs up. This, in turn, may cause additional
hardware cost and firmware overheads.
• Another major drawback of the ‘Super loop’ design approach is the lack of real
timeliness. If the number of tasks to be executed within an application increases, the
time at which each task is repeated also increases. This brings the probability of
missing out some events.
• There are corrective measures for this also. The best advised option in use interrupts
for external events requiring real time attention.
• Advances in processor technology brings out low cost high speed
processors/controllers, use of such processors in super loop design greatly reduces
the time required to service different tasks and thereby are capable of providing a
nearly real time attention to external events.