Hi! I’m designing a DUE-based project which will read a 14-bit rotary encoder via SSI interface. Googling reveals examples using SPI instructions (e.g. “SPI.begin();”, SPI.transfer(0x00);” and “SPI.setDataMode(SPI_MODE2);”).
Q1: What’s a good place for a relative novice like myself to learn more about these SPI instructions?
Q2: The few examples I’ve been able to find so far appear to primarily focus the Arduino’s attention on supporting the SPI interface… leaving 20 microsecond periods in its main loop to handle all other microcontroller functions. Would it be wise to incorporate a second Arduino microcontroller (e.g. a Nano or a Feather) to focus exclusively on the SPI/SSI interface and interrupt the DUE when the next data word is ready to read?
Q1: Where can I find out more about these apparent SPI instructions I’ve seen in some encoder software interface examples?
Q2: Would it be a good idea to add a second microcontroller dedicated exclusively to supporting the encoder’s (partial) SSI interface to reduce the DUE’s interrupt rate?
I have never coded for an SPI absolute encoder so I can't provide help there if indeed you have one.
Q2: Would it be a good idea to add a second microcontroller dedicated exclusively to supporting the encoder’s (partial) SSI interface to reduce the DUE’s interrupt rate?
What is your application, and how frequently do you need to read the encoder? What else is the Due going to be doing.
I would think that with direct port instructions for reading and writing the clock and data pins you can be significantly faster than using digitalWrite() and digitalRead() on the Due.
In my experience, using two processors instead of one with the added complexity of communication and synchronization, typically creates more problems than it solves and should be a last resort.
Thanks for sharing your thoughts. I’ll definitely consider your advice toward avoiding a dual-processor implementation. The link below (courtesy of @Majenko) describes using SPI libraries to support (partially implemented) SSI encoder applications. I’m curious about how these SPI functions are used.
It "somewhat" looks like SSI is like SPI, but "read only." To access the 16bits of data from your encode, you'd use SPI.transfer(), "sending" 0s are saving the two bytes of returned data.
Aside from the Arduino library documentation, your best source of documentation on SPI is probably the AVR datasheet.
That doesn't seem accurate. The arduino SPI interface is "blocking", so that when you use it to transfer data, it will sit there until that transfer is complete. THAT is likely to take about 20us per byte at the default clock rate (500kHz, IIRC?), but those pauses are only during the SPI.transfer() calls, with the main loop running all the rest of the time...
(There are some "degenerate" applications, like spoofing a video display, where the SPI output is the main function of the program, since the serial data is needed continuously. But those aren't "typical.")
(OTTH, It doesn't look like there is any sort of output from the encoder to indicate that the position has changed, so you probably need to read it pretty continuously if you're expecting real-time-ish responses to rotation.)
A second microcontroller could do a nice job of continuously scanning the encoder and only reporting actual changes to the master controller (rather like a mouse...)
