Alright, so here is my problem.

I've been working on this chronograph which uses a photogate system to measure the speed of an object that flies through the two gates.
I've gotten most of the final program for that taken care of. However, because it is the first of it's type I made a very short program which would allow testing of all of the various inputs and outputs.

I know that there are many problems already, but I just figure that I would go down the list.

all three of the 7-segment display's and their drivers are working properly


here's the problem I'm trying to figure out right now...I can't get any of the inputs to function properly, specifically any of PORTE. the circuitry with the three switches does what it is supose to do, leading me to believe that it is a programming issue.

Attached is the circuit diagram and the current program

If anyone does notice a problem with the circuitry please tell me as I still can make minor changes, but I already have a PCB made. (the circuit is currently on a breadboard for testing)

Any ideas on what the problem could be?

Attached Thumbnails

 

Attached Files

PICCHR2T.asm (5.1 KB, 9 views)

 

do you switch off the A/D?
i think 16f877 has A/D on PORTA.

also have you considered a multiplexed LED display?

 

what is A/D?

Though there is a problem with the two inputs on PORTA, I don't think that it is the PIC in that case. I'm trying to at least get the inputs on PORTE to function before I move on to the main optocouplers.


Also, the first design had the three segments run off of one pin on a smaller PIC, but that would only allow the display of numbers.

EDIT----just looked at the datasheet. all of the A/D control bits are automatically set to be disabled during start up if you leave them alone

 

Take a look at this if you haven't you don't have porta or porte set to digital i looked at your code

__________________
Burt
http://mybe80be.com
http://stores.shop.ebay.com/mybe80be__W0QQ_armrsZ1

 

At power up all analogue capable pins are set to analogue and will not function as digital inputs. You need to write 0x06 to ADCON1 to make them all digital.

Mike.

 

Mike you beat me to it I just downloaded the data sheet to see what PORTE needed to be set to. Not
with a pic It just like Mike said It also works better if you set your (tris) first then (clrf) the port

__________________
Burt
http://mybe80be.com
http://stores.shop.ebay.com/mybe80be__W0QQ_armrsZ1

 

COOL!

thankyouguys for the help, I'm inserting the segment of code

MOVLW B'00000110'
MOVWF ADCON1

into the "INIT" label (in the proper bank) as well as clearing the ports after the tris have been set for each port.


one quick question though,

Will setting the ADCON1 register affect RA1 and RA0 as they are being used as outputs?

 

don't think so

 

nope you want it all digital that it dos it turns off adc so you can use the porta as output or input pins

__________________
Burt
http://mybe80be.com
http://stores.shop.ebay.com/mybe80be__W0QQ_armrsZ1

 

Note that ADCON1 is in bank 1.

Mike.

 

and.......IT WORKED!!!!

thankyou again guys for all of your help

it all worked as it should, except for one of the gates, but I'm pretty sure it's just a short or this ancient 4072 has a problem. (made in 1986, and the casing looks kinda iffy)

if it is something else I put up another question in this thread.

 

Hah, there wasn't a short nor was there a problem with the OR gates. I forgot to set all of the 100ohm trimpots to about halfway. There was one on the assumed failing gate that didn't have enough resistance to keep the OR gate from tripping

So luckily, I don't have to remove any of the traces from that already made PCB

here's a few pics of the board and its enclosure/custom photogate housing

 

well, the board has been soldered, tested, and worked perfectly, gate's and all.
It has been cased and is pretty much ready to go save for a few actuators for the input buttons and the lid needs a few more holes.

I've been working on the final firmware for the device, except I can't seem to figure out where these glitches are coming from.

sometimes it's pretty dang accurate, and sometimes its pretty far off.

I know it is pretty much impossible to put this on the internet and have it magically fixed, but is there any segment of code that doesn't quite look right to anyone that could be causing a problem?

To store the required numbers, it uses set registers representing numeral places that within the code will never hold anything greater than 10 in decimal. when they reach 10, they are cleared and the next register up is incremented.

the code follows this algorithm in order to get a velocity from the gate system:


x= measured time
xp=x/100

q=# of times x is added onto itself

xp is added to itself q number of imes until the result is equal to or greater than 1

q is then divided by 100 to give the final answer

all of this divides 1/x

Attached Files

CHRONO_FINAL.asm (23.6 KB, 10 views)

 

I haven't looked at your asm, but from your algorithm there are 2 potential problems;

1. the xp sequential addition should never exceed 1, it should stop as close to 1 as possble but still be <1 or =1.

2. What is the smallest expected value of x? You are damaging accuracy by doing the x/100 operation and then even worse later when you do q/100. To fix that you should leave x undamaged, and add x to itself until it reaches a high decimal number (up in the millions is best) so you have a value of q that has a higher resolution. If you pick the high number based on your processor speed and snesor distance you will get a q value that is directly in feet per second or metres per second.

To debug the hardware and the sensor firmware you can just mod the firmware to display x on the display, ie just display the elapsed time directly (value in the PIC timer). You can then check your hardware is not jittery, likewise they way you are reading the timer etc. When that is going good you can add in the math part to convert elapsed timer ticks into FPS etc.

 

I can see why xp*q should be ≤ 1 I'll try to change that. The easiest way I can see this being possible is to insert a code after it has finished incrementing q. It will test the contents of zplace (xp added onto itself in the program). It will test every place except for zplace_1. If the rest of the places hold any number, q will be decremented by 1

The x/100 was to try and allow much slower speeds to be measured. Say for example the gates record a time of 7 seconds. It would then be divided by 100 giving .07 (in the pic, the numbers would just be shifted)
.07 would then be added onto itself until the result would be ≥ 1( which will soon change to ≤1)
When x added onto itself (zplace in the program) would get to 1.05 (soon to be .98, q would equal 15 (soon to be 14. From there, q would be divided by 100 to give .15 (soon to be 1.4, where 1/7=.142857...