hello all. I have to carry out a project entitled the study of synchronous serial interfaces. I know that given the theme I could use I2C and SPI. On the net I found as a project idea a scheme consisting of 2 Arduino boards uno one to be configured as master and one as slave, respectively an I2C module and a 16X2 lcd display to work something like Arduino master sends a message every second to slave via I2C. The slave receives this message and displays it on the LCD screen.I mention that I will carry out this project as a diploma thesis, so I would like ideas, suggestions, project schemes from you to help me make this project more complex. Thanks in advance.Would it be necessary to add some sensors in order to have somewhere to read data to process them through the serial interface? Can I also use SPI in the same project with Arduino and how could I do that?
Your post has been edited to change the font to a more reasonable size and to remove the emboldening cause by it being receded by the hash character
I think you could start from something like this one:
what would you suggest I add to this project to make it more complex but still not stray from its theme?
I see the project is about two arduinos communincating, and it seems is what you're asking for, so you need to add just the LCD and start writing your communication protocol...
Would it be necessary to add some sensors in order to have somewhere to read data to process them through the serial interface? Can I also use SPI in the same project with Arduino and how could I do that?
You are correct but they are not designed for off board communications. Here are some links that may help: CJMCU SC16IS752 I2C-SPI to Dual Channel UART Converter Module
and Arduino compatible coding 18: Synchronous serial communication using the I2C bus You might adding a very robust multi master setup like CAN.
If you want a bit of a challenge, I would try to use the UART in synchronous mode. If you go that way, you will be better of with a board where the only UART is not used for communication with the PC (e.g. Mega has three spare UARTs, Micro/Leonardo has one spare UART).
I have manged huge data networks using synchronous data communications. I have written several computer programs that used synchronous data communications and various protocols. What you are describing is NOT synchronous data serial interfaces.
You seem to be using normal, every day asynchronous data communications. There is NO Arduino capable of sending or receiving synchronous serial data. The USARTS do not have the capability of synchronizing themselves using an external data stream.
For me, synchronous means clocked. And as far as I know the AVR processors do support that; am I mistaken?
That works for sending, but NOT for receiving.
Addition: Been too many years! One thing the regular old USART does that the Arduino cannot do is fill in sync characters if the transmit buffer is not refilled in time. The receiving end watches for sync characters in the message test and removes them from the data stream.
Another addition: Synch data is only 8 bits per character, not the 10 bits for async data. Biggest reason for using it!
I think the idea of reading an SPI sensor with one Arduino and then sending the data to another over i2c to be displayed on an i2c lcd is a good one.
You might want to try reading an SSI absolute encoder as part of the project. SSI stands for synchronous serial interface.
Sorry to say I disagree. Given it seems to be some kinda homework or exam test (so we don't know how strict are the requirements), I2C is a synchronous serial interface, because it has master and slave roles, and a clock (SCL). Even Wikipedia confirms it is a "synchronous, multi-master/multi-slave (controller/target), single-ended, serial communication".
So IMHO implementing I2C communincation between two Arduinos looks like it complies with the original requirement.
You can disagree, but when both ends use a common clock, they are not two separate devices, in my thoughts.
A synchronous transmission is a transmission, where the transmitter sends both - clock and data, and the receiver doesn't have an own clock. When receiver and transmitter both have there own clock, these cannot be synchronous - they always will differ a little bit, what makes them asynchronous.
But there a two very different techniques of transmitting the clock. This can be done with an own clock line ( as with SPI or I2C). But it is also possible to transmit clock and data on the same transmission line (as with an USART Interface). The receiver has to retrieve the clock from the datastream.
Maybe that's what @Paul_KD7HB has in mind.
MY experience was both ends have their own clocks that are similar in frequency. The receiving end uses a phase locked loop of sorts to adjust it's clock so the two leading message bytes, sync characters, are read properly, The second character must be read properly or the message must be rejected. Once the clocking is set, all the rest of the message is properly read and decoded.
There is a method of data encoding that can be used to include synchronizing information, but it was so rare that I never encountered it. Was never used with standard data modems. Seemed to be a lab curiosity.
How do you connect them to an external clock? Look up the definitional of USART vs UART. Since the OP asked about synchronous communication, knowing the on chip UART is not capable of that I recommended an external device. By definitions synchronous communications needs a common or synced clock. Asynchronous does not need a synchronized clock but one within a reasonable tolerance of each other.
You have a valid point that the needed pins are not broken out on a Mega; I did not check that when I posted. However, each U(S)ART has an associated XCKn pin for clock and the datasheet specifically mentions synchronous operation.
Well, that's also only a means of retrieving the clock from the datastream, isn't it? 
Well, regardless of whether the clock is transmitted in the data stream and - however - extracted there, or whether the clock is transmitted via a separate line. Both are technically synchronous data transmissions.
And that's what the OP wanted to do.
Well, actually… it wasn’t obvious to me whether OP was supposed to be interested in clocked local protocols like I2C and SPI, or whether they were supposed to be looking at the higher level “synchronous communications protocols” like HDLC or BiSync.
I hope for their sake that it’s the former, since afaik there are no Arduinos that support the continuous clocking and bit stuffing required by the latter. But a bit-banged HDLC would be an “interesting” project (presumably at a pretty low speed…)