They say direct port manipulation is a way to set multiple pins at the same time.
Example:
PORTC |= B11111111;
What is the chance that pins will not get set absolutely at the same time? I mean - is it possible for another controller at some microscopic point in time during that operation to see not all pins high?
If existent and if multiplied by repetition millions3 of times, could this microscopic time be a potential for errors?
This is usually a concern with CPLDs or FPGAs which process signals in parallel. However, with sequential processing of an MCU, the port outputs would have already settled by the next clock cycle. When using these signals to communicate with another device, there is usually an output enable, or chip select, or other handshaking line etc. to let the master or slave device know when data is ready.
What is the chance that pins will not get set absolutely at the same time?
Times will always be a slightly different.
However we are only talking about a few nano second differences.
Rise and fall times may be different between pins, fractions of a nano second.
I have clock+data line that get set in a single command.
I'm concerned about the chance of receiving clock before the data pin has finished transition. Receiving end is 16MHz Mega, sending - 8MHz Attiny.
There is ALWAYS skew between signals, even when "set" at the same time. At the very least, physical factors (PCB trace length, capacitance, loading, etc. can skew signals by quite a bit. This is exactly why any reasonable protocol will specify setup and/or hold times between data and clock signals, to ensure the data is ALWAYS settled by the time it is sampled. If you change all at once, you have absolutely no idea the order in which they will settle, unless you've very carefully designed every single bit of the signal path, and know precisely how the signals are all routed, and loaded.
Set the data, wait a short time, then set the clock. But, at 16MHz, you won't be doing that in software. One thing you can do is put a controlled delay the clock signal, by passing it through an extra gate, to make sure it arrives at the destination LAST.
Due to capacitance in the lines, there might be a nanosecond or picosecond of difference while the processor drives the output pins.
However what you normally do is set the pins to a wanted state, and then assert a clock pin. Since this is definitely done after the data pins are stable there should never be any issue. In fact you must have a clock, right? You don't just test the pins and look for changes?
If you look at datsheets with timing diagrams they always show exaggerated rise and fall times for the signals and show that READs must be delayed a little compared to WRITEs to ensure that the data is valid.