If you don't have error checking in that system it is going to bite you in the ass. Data integrity checking is very important when communicating.
Again, it depends. STM32 SPI has an integrated CRC8/CRC16 generation and checking which works through DMA as well, and will give interrupt on detected corruption. So in this case, this is made quite easy. So yes, I'd recommend having error checking in communication whenever possible, too.
This being said, I'm not a big fan of such blanket statements.
Everything is communication. And 99.999% of your communication does not have any kind of integrity checks.
Do you have integrity check in your CPUs memory bus? Or ALU?
Do you have integrity check for memory? And yes, this is
actually very relevant. Memory corruption is widely studied and a well known phenomenon. Still, we often just choose to accept the results, and not invest in error correcting RAM.
I have thousands of traces on my PCB. Some analog, some digital GPIO, some SPI, some I2C... All carry "communication", and all are important. Do I add some kind of "integrity checking" to each of them? Is this realistic?
By adding gazillions of checks everywhere, you can drop the unprotected area of 99.999% to maybe 99.99%. When done right, you concentrate on the biggest contributors of errors.
Or, you can pretend your own CPU-to-CPU SPI link is the only magical place where electrical errors could happen.
I don't have any integrity check when reading many types of sensors, some SPI, some I2C, some parallel bus, simply because none of the sensors implement any kind of error checking functionality - even though it's "communication", and even though the integrity is "important", and even though they are fairly well designed products from the big, trusted manufacturers. Why don't they implement error checking possibility?
I guess the usage pattern seems to be that data corruption in the physical link level is so rare that many other sources of errors dominate anyway, by orders of magnitude.
Should my own SPI link, then, have a checksum? Yes, it's probably a good additional safety measure. This being said, a realistic case of one bit corrupting once per 10 years of operation is automatically fixed by the next transaction. This, of course, only works because the design is tolerant for having wrong values that exist for short time, so this doesn't work without thinking.
Adding a checksum to the SPI link would only protect from electrical corruption on said line - even then it would require extra code to handle retransmissions, etc. How well do you test this code? Given that corruption in SPI link is extremely rare and unlikely, you'll never see that part of code executing in real life. And if you
depend on having the right data at the right time, always, adding the checksum and error correction logic is starting to get nontrivial.
Which gets us to sanity checking inputs, and designing things to be robust even with wrong data, whenever possible. It's most important to focus here - much more likely than having a SPI corrupted bit, is that I have just made a stupid mistake somewhere, supplying wrong parameters, overindexing something, etc. Error checking one of the most reliable pieces of hardware I have on board is not going to help on that.
Then, at the end, we need to admit that no system is perfect, and try to focus on actual "worst offenders" first. Understanding that a short SPI link between a few MCUs on a PCB, correctly electrically designed, is practically error-free (comparable to all those signals
inside MCU's, also considered error-free by everyone without a second thought!), enables us to concentrate on the actual challenges, which do not get any easier when we have a multi-MCU design.
The issue with perfectionism is that it typically overlooks many super important areas while focusing on almost unnecessary.
TLDR: It depends.