SPI interface - Interrupt or Polling

Thread Starter


Joined Jan 18, 2008
I am trying to use a Mitutoyo Digimatic dial indicator as a threading dial to automatically stop a lathe at a user-defined set point. When threading into the headstock, one must be prepared to withdraw the cutter and stop the lathe in a coordinated manner as the end of the thread is reached, that is, if one wants to produce a thread that tapers to end on a shoulder, not a thread ending in a groove. Anyone who has done that knows how easily it is to get mesmerized by the process and mess up.

Digimatic code is similar to standard SPI code. There are four wires plus ground. Data are read on the rising edge of the clock. The device sends 13 hexadecimal digits, i.e., 52 bits of data.

Since I don't need to read and store all of the data nor control the indicator from the MCU, I had planned only to key on a particular value for the set point. For example, a value of all zeros would indicate the set point. Rather than do that, however, I have tentatively decided to stop on a change in sign. In this particular example, if the stop point is set to be zero, values leading up to that point will be negative. At the stop point, data will change to positive. The sign in Digimatic code is the 5th hexadecimal digit, which is read from LSB to MSB. A "0" is positive and an "8" is negative. Thus, in theory, all I will need to do is look at bit 20 and wait for it to change from high to low, i.e., 0001 (d'8) to 0000 (d'0).

I want to keep the code as simple as possible. I have not completely ruled out hardware SPI, such as with the PIC 16F88, but since I do not need bi-directional communication, that seems like overkill. Moreover, I am a real novice at coding.


1) Does the approach of "monitoring" just that one bit make sense? Is error detection needed, e.g., two consecutive "positive" readings?
2) Would you recommend using an interrupt or polling, based on the CLK from the indicator?
3) What is the disadvantage to using polling?

Thanks. John


Joined Jun 7, 2009
Just thinking out loud;

SPI is a hardware protocol. Data flow is not specified.

If your running a cutter into a shoulder, I would likely want to count clock pulses, rather than parsing a data block looking for a specific bit or byte.

This implies leading the tool through it's profile, rather than following it with some action. Your cut will either radius out or enter an undercut to transition away from the root profile. Stopping (or even slowing) is likely undersireable.

'Polling' is a supervisory function where the controller dedicates time slices to querying the device. 'Interrupting' allows the controller to engage in other activities, until a device requests it's attention. If there was a 'disadvantage' to polling, it would be that the controller must dedicate the time to 'polling'.

I motion profiling, you would generally want a logic controller 'completely' dedicated to the motion. A second logic device can handle the other functions.

Thread Starter


Joined Jan 18, 2008
Thanks for the response (GetDeviceInfo). I should have mentioned that the lathe is just a hobby lathe (Prazi SD300) without half-nuts. It is best if the lead screw is engaged throughout the whole threading process; otherwise, you waste a lot of time finding the right start. The lathe has to be stopped. I converted it to variable speed DC quite awhile ago, and it stops almost instantly when switched off while threading.

As for the interface, here is some more detail on the Digimatic interface. You need to scroll to page 22 ( http://www.mitutoyo.com/pdf/1715.pdf ).

If your running a cutter into a shoulder, I would likely want to count clock pulses, rather than parsing a data block looking for a specific bit or byte.
I did not plan to receive the entire 52 bit data block and then parse out the sign. I was planning to simply count clock cycles or data bits after the handshake and look at the 20th. Is that what you meant? I like your suggestion to poll the CLK pin, not the data pin, to find the 20th bit. That clears up some of my fuzzy thinking on the subject.

The controller will be dedicated to this one function. To further refine the question, I plan to use a very small loop for the poll. Thus, I expect the uncertainty of knowing when the clock/pin goes high to be fairly small. With an interrupt, the uncertainty would be potentially less, but would that really matter in this application?


Thread Starter


Joined Jan 18, 2008
Thanks for the input. Are you suggesting to read the data for a position and then set limits based on that position?

In the sign method, the lathe would stop at the first change. That might lead to some false stops, which is better than not stopping.

I have no idea how noisy the data are from these devices. The displays do not bounce around much, but they may be well buffered.


John Luciani

Joined Apr 3, 2007
If the Mitutoyo is going to be the master device on the SPI bus and continuously
send data then I am not sure how you would get polling to work. I think you would
have to use interrupts.

Can the Mitutoyo be a slave on the SPI bus? If so then polling would work and it
would be easier to code. Each time through your program loop you would shift 26
bytes from the Mitutoyo. Once the value gets beyond your limit you would stop.

Unless your system is moving very fast for the PIC you have chosen then storing
the data in RAM is not going to cost you much processing time (especially if
the PIC is doing this one task). Comparing a sign bit and comparing two integers
will both be very quick operations. Having the data could be useful if you ever
want to do more advanced control.

I am curious as to which of the Mitutoyo devices you are using and how much
it costs.

(* jcl *)

Thread Starter


Joined Jan 18, 2008
Hi John,

Thanks for the advice. I wrote some code last night, but as I got into the subject more this morning, it became more complicated.

In brief, it does not appear that all Digimatic interfaces are the same!

I was under the impression that the handshake began with the Digimatic sending an active low "ready" (presumably pin 4 at the device and on the plug). That was based on Don Lancaster's Tech Musings (#145, 2000) and is certainly the case for some devices, but not all.

My device is an ID-C Indicator, series 543-252B. It was only $50 NIB on ebay. I could not find much on the Mitutoyo site, but the box insert - in very tiny print - shows that Pin4 (Ready) is not used and is NC. The protocol is for REQ (Pin 5) to be held low by the MCU until the clock starts, then read the data. I think I can deal with that.

What worries me is the statement:
Data output may be disabled if an output request (REQ) is received while the spindle is in motion or...
In my application, the spindle of the gauge will be in motion, but slow. So, I will still give it a try. Otherwise, it is a very nice gauge for other purposes, and I will just have to find another that will work in this application.

While on this subject, I understand that input to the gauge needs to be open collector , i.e., the PIC drives the base of an NPN; the collector connects to the Digimatic pin, emitter is grounded.

I am confused, though, about interfacing output from the gauge to the PIC. Lancaster (and others) just show pull-up resistors (e.g, 20K) to 5V going to the PIC. Mitutoyo shows a more complex scheme with a CMOS inverter and a 1.55 V /1M ohm pull-up on its input. The gauge is presumably tolerant to 7V (Mitutoyo). Do you have any experience using either interface?



Joined May 7, 2007
If the Mitutoyo is going to be the master device on the SPI bus
Although this is "SPI-like" it is not SPI. It is a custom interface.

Mitutoyo shows a more complex scheme with a CMOS inverter and a 1.55 V /1M ohm pull-up on its input.
This scheme is to drive other logic (TTL/DTL). You can just use a pull-up if you are going directly in a PIC I/O pin.

Thread Starter


Joined Jan 18, 2008
Just thought I would give a short update:

It works.

Ended up using CMOS inverters to clean up the clock and data and get sharp transitions. The data set bounces around quite a bit relative to the request signal. The request line from the PIC (GP2) uses a low-side mosfet instead of an open-collector NPN to sink the dial indicator REQ pin. Either would probably work. As soon as the Clock from the indicator starts, it simply counts clock ticks to 20, then adds a little delay (200 uS). If the data bit is then high, the indicator is reading positive; if the data bit is low, the indicator is reading negative.

I have it set now so when the indicator passes zero, an LED/switch is activated.

I will post another follow up in the Projects Collection Forum, once I have tested it more thoroughly and am satisfied with it.

Thanks to everyone for the help.