Instruction cycle measurement

[Christopher4187]

Why not flip an output each time the PIC processes a message and measure the frequency of that of that output. Then you'll see how many messages per second the PIC is actually processing.

It's the VB code. I put a counter and a timestamp for each cycle through the mainloop. The results vary but the VB code is only able to poll the PIC every 10-30mS or so, and the counter jumps ~20 cycles. So in one second I can be missing a ton of packets. The VB poll looks like this:
Time (HH:MM:SS:MS) Counter(X)
11:07:25.92 / 58
11:07:25.94 / 70
11:07:25.95 / 88
11:07:25.97 / 100
11:07:25.98 / 115
11:07:26.00 / 130
11:07:26.02 / 146
11:07:26.03 / 160

When I datalog it's worse

12:48:54.84 / 252
12:48:54.88 / 30
12:48:54.91 / 64
12:48:54.94 / 90
12:48:54.97 / 126
12:48:55.00 / 156
12:48:55.03 / 186
12:48:55.06 / 216

Now I have to look at the VB code and figure that out.........

[HenrikOlsson]

Hi,
Windows isn't known for being good at high resolution timing, atleast not with the "standard" tools. Why not do one of two things:
1) Just stream the data from the PIC to the PC. The serial port control in VB buffers the data behind the scenes.
2) If you do need to have the PC poll the PIC then buffer the data in a circular buffer with enough size and send it off in bursts.

/Henrik.

[Christopher4187]

Hi,
Windows isn't known for being good at high resolution timing, atleast not with the "standard" tools. Why not do one of two things:
1) Just stream the data from the PIC to the PC. The serial port control in VB buffers the data behind the scenes.
2) If you do need to have the PC poll the PIC then buffer the data in a circular buffer with enough size and send it off in bursts.

/Henrik.

It's above my level of knowledge. But, I'm willing to learn. It's actually a USB VB program but I'm guessing the same ideas apply. I'll play around with it and see what I can do. Thanks for the help.

[Christopher4187]

After some searching, it appears as though there's no way to get below a 1mS timer with VB6. The problem, as you mentioned, is windows.

Now how to solve it?

I can miss up to 30 packets per revolution of code (mainloop -> Goto mainloop) so what is the easiest way to get every single piece of data? My preference would be for the PIC to store the data and then when the PC gets around to it, that packet will be sent.

[HenrikOlsson]

Hi,
USB, OK, never played with that myself. But anyway, are you sending one single measurment from the PIC to the PC each time the PIC is polled? If you reliably can get a poll rate of say 20Hz and you need 500 measurments per second you need a buffer in the PIC of atleast 500/20=25 measurements (bytes or words?) but I'd probably add some margin to that.

Now, depending on how the rest of the code is set up, ie. if interrupts are used etc using the local buffer can be more or less complicated. Assuming that no interrupts are used to put data INTO the buffer all your main program has to do keep track of where in the buffer to put the next byte using a pointer variable

BufferSize CON 25
LocalBuffer VAR BYTE[BufferSize]
Ptr VAR BYTE
Ptr = 0

Each time you get a new measurment to put in the buffer you do something like

LocalBuffer[Ptr] = NewMeasurment
Ptr = Ptr + 1
If Ptr = BufferSize THEN GOTO BufferOverFlow   ' Buffer not emptied in time.....

The routine that sends the data to the PC when polled then just have to send any data that's in the buffer. I'm using HSEROUT here since I don't know how you're doing it with USB

If Ptr > 0   'Only do this of there's any new data in the buffer
  For i = 0 to (Ptr - 1)
    HSEROUT [LocalBuffer[i], 10,13]
  NEXT
  Ptr = 0    ' Reset pointer
ENDIF

Something like that, perhaps.

If you're not using interrupts then obviosuly the PIC can't read data and put into the buffer at the same time that it's sending data but I don't know exactly how that works when using USB. If you're using interrupts to fill the buffer, ie. the routine that sends data to the PC can be interrupted by the routine putting data into the buffer you'll need to resort to a circular buffer.

/Henrik.