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.
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.