Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC16F887 caliper interface via a small 16pin PIC?

Status
Not open for further replies.

dsc

Member
Hi all,

I'm adding some functionality to an existing PIC16F887 project to enable the uC to read values from a Mitutoyo caliper. The data format is rather easy to decypher as it's 13 BCD values sent out 'on top of' a clock signal and this data generation can be trigered with a PIC output (the caliper takes 5VDC signals, so one can throw a transistor in the loop and switch the signal from 5VDC to 0VDC to trigger the clock / data signal generation from the caliper). The current application running on the PIC16F887 isn't massively complicated, it services five push buttons, an LCD, generates short pulse signals to a stepper motor controller and also runs a 0.1sec timer when triggered with a button. The timer precision requirements are rather high, so this was implemented using internal chip timers and interrupts. The main loop of the program services the LCD and buttons and when the timer is triggered via one of the buttons, the INT is triggered every 100ms to increment the timer value and set an LCD update flag which then triggeres an LCD update in the main loop after the INT is serviced.

I'm trying to marry the existing functionality and the caliper servicing, but it seems that it won't be as easy as I first thought. The biggest issue I can see is trying to service the data read whilst also maintaining pushbutton servicing, LCD updates etc. Based on some test data gathered from the caliper it seems that a single data block (full 'transmission') lasts for around 70ms with 8ms spaces between the data. If I throw the data read code in the main loop of the program and consider interrupts triggering every 100ms (to update the app timer), I'm left with 20ms to service button presses which is a bit short. I've toyed with the idea if using a small 16pin PIC to service the caliper alone and then send the data to the main PIC using UART. Do you reckon this is a bit over the top, or a not such a bad idea overall?

Rgds,
T.
 
Why do you have to read the caliper continuously or in the same interval with servicing the buttons? I don't understand the problem with a 20-ms window for reading the buttons out of 100 ms. If someone presses a button for 90 ms, then the press will be captured. I probably can't press and release a button any faster than that.
John
 
Unless debouncing is implemented with in line delays (maybe between 15 and 35 ms ) there should be enough time.
 
Debouncing, this is done as an inc / dec function, a pressed state increases an internal counter and a de-pressed state decreases it, if a 'confirmed' level is reached the button is marked as pressed and whatever function assigned to it is serviced. This of course works well if there's not much else happenning in the main program loop, currently there's only five buttons connected being checked and an LCD update function. If I throw in the 80ms sample loop in the main program loop the buttons will be slower to react with the code as is, but I should be able to adjust the 'confirmed' level values (most of the debouncing will be done whilst the DATA line is being sampled). I'd much rather have the DATA sampling done based on interrupts, but with the timer INTs already enabled, there's going to be clashes and prioritising which would take a lot of work arounds.

The only problem I see here is sampling the incoming data, which effectively means doing a long loop waiting for the CLK signal to change and reading the DATA bits. This would mean 80ms just sitting there reading the data as it has to be done in one go, unlike the button servicing which can be split across several main program loops.I'd like to read the data from the calipers at least once every 100ms, so that when the timer value on the LCD is updated, the calipers reading can be updated as well (there's other reasons for a quick update as well - the reading shouldn't be allowed below a certain level, so if I sample the caliper slowly this functionality won't work). Of course the data stream takes roughly 80ms, so there's no way to read it more than once in a single 100ms window.


T.
 
Quick update, I've now managed to get the caliper reading function working, the problem is that it takes more than 100ms to read the entire stream of data and of course there's no way to pause this (you trigger the Request line and it takes roughly 50ms for the caliper to reply with a stream of data - this in turn takes almost 70ms, so altogether this is 120ms). This means that if I trigger interrupts every 100ms, those two functions will clash badly and I won't be able to read anything meaningful from the caliper.

Any ideas on how to solve this without a separate PIC to just ready the caliper and send the data to the main one via SPI or I2C?

T.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top