3

When communicating over SPI, one byte is sent at a time. Is there a library (C or C++) that allows for sending strings? Essentially it would be a protocol library handling the start and the end of a message, as well as integrity checking. (I'm using an Arduino.)

migrated from electronics.stackexchange.com Mar 18 '14 at 16:24

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • 2
    You could use SPI just as you would use let's say a UART: just send the characters of the string, and terminate with whatever character you reserve for deliminating strings, for instance \n or \0. – Wouter van Ooijen Mar 17 '14 at 14:02
  • I have never used uart and have no experience with microcontrollers. But doesn't uart have integrity checking, in contrast to SPI? – Friend of Kim Mar 17 '14 at 14:11
  • It can have a parity bit for each byte, which is a very weak form of per-byte integrity checking. Almost nobody uses it. – Wouter van Ooijen Mar 17 '14 at 14:25
  • I believe uart uses that. I would make a library myself to do integrity checking etc. But I thought this was already common to use and easily available. – Friend of Kim Mar 17 '14 at 14:41
  • 2
    SPI is an inter-chip protocol, mainly used on a single PCB. The common assumption is that it just works, like the communication between a processor and its ROM just works. Hence adding integrity checking at that level is not commonly done. And it is both very easy and depends on what you want to transmit, so it does not lend itself to being turned into a library. – Wouter van Ooijen Mar 17 '14 at 14:47
6

Each spi peripheral has its own protocol in the sense of commands and addresses if any and data. Spi simply makes a common ground for chip select vs clocks and clocks vs data and separate miso and mosi data lines.

So a general purpose library doesnt make sense.

Also spi certainly is not limited to a byte, many peripherals and many spi controllers allow for long sequences of data, you are also not strictly limited to multiples of 8 bits either although that is the norm.

Your arduino spi master may have its limitations but that has nothing to do with spi in general.

Integrity testing is not part of the spi protocol, you get what you get. Ideally all of the parts are soldered down on the same board or through known connectors and the margins have been designed in. You would need to do something outside the spi protocol, for example if it is a spi flash then after you read a chunk of data you can do a checksum and compare it with a checksum you have embedded in the data (or crc). If it is a spi ethernet part you may choose to leave the frame checksums in the frames and re-validate each frame yourself. If you create your own peripheral (hardware design or cpld or fpga) then certainly you can add a crc or checksum to every transfer if you wish.

  • So far, I saw only one SPI peripheral, which does CRC for SPI transactions. SD cards. A/D, D/A, I/O expanders, RTC and so on don't do CRC or checksum or any other form of integrity checking on the SPI communication. – Nick Alexeev Mar 18 '14 at 3:11
  • At the same time a general purpose SPI library does make a modicum of sense. I wrote a more a less generic class, which keeps track and takes care of CS# pin, SPI mode, SPI clock divider. It still does only 1-byte read/write. Would a multi-byte (buffer) read/write make sense? May be... In some situations... – Nick Alexeev Mar 18 '14 at 15:56
  • @NickAlexeev There are plenty of SPI peripherals which either send CRC together with the data (example), or also require the master to send CRC of commands. Of course, many lasy library implementations simply ignore the CRC in the first case. – Dmitry Grigoryev Feb 6 '18 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.