Revolution indicator out of old rollerball mouse

I have one of those really old Microsoft two button non scroll wheel mice with a PS/2 connector and i just wanted to try and make a revolution measurer.
By coincidence this mouse comes with a PIC16CR58... but i am not sure whether i can use this with my velleman PIC coder.
It has a LED and a receiver thing mechanism for X and Y axis

Basically what i want is a device interfaced in a PIC then goes through the serial port into a computer, which then displays the revolution e.g 90°, 180° from when the device was powered on. I intend to use the second one to 'calibrate' the wheel so that if something passes through the second LED - receiver system it gets reset to 0°

I have no idea what voltage the LED and receiver things work at.
If i have left gaps in the description which i probably have please ask!
I think i will be alright with the computer program that will receive the serial info

Is this the type of mouse that has two slotted sprockets, each one with an interrupter around it?

You want to measure the rotation of the stock mouse ball, or turn it into a 2D ruler?

Useless Trivia: The "CR" PIC are ROM Masked, not even One Time Programmable like the "C" series, some of which also had a UV erase window. The F are Flash memory, and cover most of the development market. Once a design is finalized and a million are wanted, Microchip creates the "CR" processor that does only what the program was designed for, and the IC isn't "readable" for the best code protection.

according to microchip the 16f627 is the same as the 16f628, could it be that the type of PIC is compiled in the code and i need to modify that to 627. Only problem is that it is written in C and not assembly which i have compiling software for, i have CC5X free but i do not have the foggiest idea how to operate it

Yeah it is the one with two slotted sprockets, i basically want them to be Tachometers and detect where abouts it is in the rotation, but i will take into consideration all the diameters and numbers of slots in the computer program at the end, for now i am just focussing on constructing the original device

Code needs to be compiled target specific, this is chosen at compile time. Even with the 16F627, there are two versions, the second being the 16F627A. The original 16F627 had a silicon bug where reading TRISB would return PORTB rather than the input/output status (TRISB). This was fixed in the A revision.

Others have different requirements when looked at from a compiler, sometimes hardware not obviously used by source code is used after compiler/linker optimization. The only way to know for sure is to read the .asm listing, produced at compile time with the .hex file. Always rebuild if changing clock frequency or processor, it takes a few seconds, and saves a few headaches when things don't quite work.

The wheels are quadrature encoded, with two sense outputs per sprocket. They are often in the same unit, slightly offset.

This gives the ability to sense direction, treating one as the "clock", and the other pulse as "data".

Once you identify the lines that pulse when moved, attach a PIC programmed to display a count on an LCD, then move the mouse one inch/one rotation/etc, and check the counts. If that works, add code for direction sensing and decrementing counter, with two inputs. Once that is going, add the other two inputs for the 2nd axis and test. Finally calibrate both axis through tests and code changes to convert output to whatever units you'd like to measure.

If you do not know C, there are some examples for this in PICBasic on the net, it has a counter function built in, as well as an LCD display routine. The LCD display would be taken out and replaced with whatever output you wanted once initial calibration is done.

The "627A" also has a bit more memory, ICD compatibility, and a couple other features, which is why it gets a letter instead of a less obvious revision code.

The bug isn't Severe, most people treat the TRIS registers as "write only", and generally keep track of what are inputs and what are outputs.

Different compilers (and hardcore assembly coders) may not use TRISB only to determine input/output state. If a program only deals with portA, a compiler may use other ports as 'fast memory' registers to store some info during a function call, usually on uCs with very limited resources to start with. If 16 extra bits of memory is the difference between a cheaper uC being sufficient, or a more expensive one required, nearly all commercial products will wring every last bit (literally) out of a uC.

Unorthodox memory and math methods were what made a "Good Game" on a 6502 processor, and almost "define hacking". Saving data in memory mapped ports that weren't used, video ram that isn't frequently visible, tape drive memory buffers, etc.

Pretty much all Microcontrollers have bugs of one sort or another, Microchip, Intel, AVR, etc. Make sure to download the errata sheet, and app notes for your exact controller. If the bug was serious, you wouldn't get one in mail order. Seriously flawed chips always find a use (for a low enough price, only one working port is ok!). The once common 486sx comes to mind, Which were 486DX Processors that had the MPU/Math CoProcessor fail testing before packaging. It was then disabled and sold as an integer processor. One could buy a 487 "Co-Processor", but they were actually purchasing a fully functional 486, and a processor in the second socket disabled the first. The 386sx was born of a similar fate years earlier, due to memory addressing failures when run at 16Mhz instead of 12Mhz.

Relabeled ICs have been around as long as ICs have been around. The expense to create a wafer is to great to simply throw it out. Once in a while I need a small, 1 gate inverter, too bad they don't bother packaging those like a transistor.

The 18F2520 Is in it's 4th revision, and is extremely popular in hobby and commercial areas despite the silicon errors, which were as minor as the 627.

I have one of those really old Microsoft two button non scroll wheel mice with a PS/2 connector and i just wanted to try and make a revolution measurer.
By coincidence this mouse comes with a PIC16CR58... but i am not sure whether i can use this with my velleman PIC coder.
It has a LED and a receiver thing mechanism for X and Y axis

Basically what i want is a device interfaced in a PIC then goes through the serial port into a computer, which then displays the revolution e.g 90°, 180° from when the device was powered on. I intend to use the second one to 'calibrate' the wheel so that if something passes through the second LED - receiver system it gets reset to 0°

I have no idea what voltage the LED and receiver things work at.
If i have left gaps in the description which i probably have please ask!
I think i will be alright with the computer program that will receive the serial info

Vane

Click to expand...

There's a linux "toy" called "Mouse Pedometer" which seems to do all you'd want in software. It's actually pretty accurate too, i've used it for measuring off drawings and such.