measuring time between two pulses

"it interfaces to hyperterminal"

Unfortunately, Hypoterminal can often be more of a hindrance than a help! :-(

"what happens? nothing."

Do your mean your system doesn't communicate with Hypoterminal at all, or just that the time bit isn't working?
If the former, it could be just a Hypoterminal problem!

thanks!

reading it again..nothing happens?? I meant the program doesnt work.

it only took several hours to figure out how to make hyperterm work.

Im having trouble with 2 things: interrupt routine, and calculating the timer.

the interrupt routine, a jmp at the 000Bh to my routine, never happens.

now what Im trying to do is use a 32bit variable to count timer ticks; problem? my Keil c51 eval compiler chokes when I try anything with my variables

long x = 0; //this is ok
long y;

int main void {

x = 1; //chokes, *** FATAL ERROR L210: I/O ERROR ON INPUT FILE:
EXCEPTION 0021H: PATH OR FILE NOT FOUND
FILE: C:\KEIL\C51\LIB\C51FPS.LIB

until now, Ive been coding this x51 project in assembly/machine. presently microsoft visual basic.net is easier to use, but it wont translate (will it?)

Ive got Intel AppBuilder to help with constructing asm, but am new to compiling C for the x51 target so I could be overlooking something simple.

thanks

The compiler is tryin to link to the floating pint library, which is not supplied in the evaluation version. I don't see why this is happening, as you only appear to be using integer variables.

It is easier to get code working without interrupts to start with. I would suggest you try just outputting a message when signal 1 goes low, then a different message when signal 2 goes low. When this is working, then try to time the period between the two transitions.


When programming embedded systems, it is usual for your main procedure to be declared as

void main(void)

"I meant the program doesnt work."

That could still mean anything from "the program does nothing at all." to "the program doesn't quite do what I expected"

*** FATAL ERROR L210: I/O ERROR ON INPUT FILE:

Hi Brad,

How accurate does your timer need to be, for example will +/- 1ms be accurate enough?

You could set timer 0 to be a 1ms timer and do roughly the following:-
Please note that it is 'incomplete code' in that you will have to put in #defines etc for your project.

long timer_tick = 0;

void main(void)
{
TL0 = TIMER_RELOAD_VALUE & 0xFF; /1ms reload value */
TH0 = TIMER_RELOAD_VALUE >> 8;
while (p1.0); /*Loop till pin goes low*/
TR0 = 1; /turn counter on
ET0 = 1; /* enable timer irq */
/* do we need to wait for pin to go high?, if so add 'while (!p1.0);' */
while (p1.1); /*loop till pin goes low */
TRO = 0; /* turn off timer 0 */
/* we now have timer_tick available in ms to process as we please */
/* if you need higher resolution then you could see what 16bit value is in timer0 to resolve it down to microseconds! */
}

static void timertick(void) interrupt 1
{
TL0 = TIMER_RELOAD_VALUE & 0xFF; /reload 1ms timer */
TH0 = TIMER_RELOAD_VALUE >> 8;
timer_tick++;
}


Hope this Helps,
Mark

thanks everyone, for those great replies.

the project Im trying to finish may be useful to everyone, so here it is:

problem: cars on my street go too fast. the city council will not take action, the local police cant patrol here very often; there are new apartments/condos with lots of families and children who play and cross the street; for the past 50+ years these were vacant lots, now they are crowded. I need to track the speed of cars.

solution:
using 2 laser beams (one beam split thru polarizing cube) feeding high speed photodiodes on the opposite end of the street, Im hoping to construct a device which will measure the speed of passing vehicles.

I plan to then use more of these on certain problem streets and place this information on a website updated often with the time of day, speed of the vehicle, and as a bonus, the measured wheelbase of the vehicle, since the front/rear tires pass thru the lights, that measurement will also appear.

its rare if 2 cars in opposite directions pass at the same time, if so the measurement may be lost;

once the 24 hour info is logged, Ill figure out peak speeding times and begin to video tape, to show the city council that cars just do not drive safely;

the problem with the long variable was indeed that its a trial version. being able to use C appears to be out of the question.

status: I did get the circuit to wait for the first bit to go low (simulating a car passing the first beam), it prints a message, then waits for the next bit to go low, it prints the TH1, TL1, and R7 which I need because the 16 bit timer overflows a zillion times/second; well its a 11.0592 ? Mc oscillator

**one problem I had was in using assembly, I wanted to move an immediate value to a register, MOV R7, 0xF4 ; should move the hex value F4 to the register? no. I finally figured out that its MOV R7, #0xFF

that pound sign seems to mean something to the compiler.


ok, so it almost works, my ultra simple monitor system can move bytes, but they are displayed as ASCII chars. so numbers show up as a random ascii char. converting hex to ascii??

Im not finding a "compare" instruction in the mcs51 core.

how to convert a byte into 2 ascii chars for their hex value?

move the char to the ACC, mask 0F->R1, then mask F0->R2, shift right 4 bits.

knowing the result will only be 30-39 and 41-46 ? for 0-9, A-F I only need align whats there with one of 16 choices. thats as far as I got

making the laser beam part, I was thinking to make a small box and cover it with some kind of concrete, with screws to get inside as needed, it would have the laser(s) and battery; the receive part? dont know yet, maybe serial cable. it would be nice to do it wireless.

well thats the goal, thanks again for the help

wanted to move an immediate value to a register, MOV R7, 0xF4 ; should move the hex value F4 to the register? no. I finally figured out that its MOV R7, #0xFF

that pound sign seems to mean something to the compiler.

Well, yes. Not to be flippant, but it means "immediate mode". MOV R7, 0F4H is the syntax for direct addressing. That is, move the contents of address 0F4H to R7. MOV R7, #0F4H is immediate addressing; move the value 0F4H to R7. Two different opcodes, AF or 7F, followed by F4.

The compare operations are combined with jumps. Take a look at the branching section of the instruction set manual, e.g. CJNE.

If those instructions don't suit your needs, perhaps it would be useful to note that a compare (on almost any processor) is really just a subtraction operation that doesn't keep the result, performed only for the side offect of setting the "zero" flag for later testing by a branch. Since the 8051 is accumulator-based, you can just ignore the result in the accumulator after a subtraction. (Of course, the number one thing you're likely to do after a compare is "branch if equal/not equal", which is CJNE.)

As for the ASCII output, I'd suggest a 16-entry lookup table for the characters, for simplicity. You could test for the boundary, as you note. You just want to take the input byte value a nibble at a time. Something like:

output(ascii[input & 0x0f]);
input >> 4;
output(ascii[input & 0x0f]);

Since you're using assembly, the SWAP instruction might come in handy. You'll probably want to use an indirect addressing mode for the table lookup.

The local camera store sells radar guns for a few hundred dollars. That and a videocam (which you will need anyway) might be a better way to go.

I'd like to know how you will protect this device when you're not looking after it. Are those kids angels ?

Also, my city has portable radar speed signs which are used in the same situation you have. I believe they also have double corded recorders for logging speeds and counts ...