CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Faster pin input detection

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
2xhp



Joined: 14 Jan 2019
Posts: 39

View user's profile Send private message

Faster pin input detection
PostPosted: Thu Jan 07, 2021 10:36 am     Reply with quote

Hi,

I'm trying to use a 12F615 to detect and act fast on a pulse. The MCU is set up to use the internal oscillator at 8 MHz. I'm assuming that the fastest theoretical response time would be 0.5 us (1/8,000,000) * 4. All the test code does is look at an input pin. If it changes to high, it outputs high on another pin.

I get between 2 and 5 us from input rising edge to output rising edge as measured using an oscilloscope with a separate probe channel looking at both input and output. The input waveform is being generated by a signal generator. Frequency of the input is about 340 Hz and the pulse width is about 20 us. I'm wondering why the response time is so long. If I was seeing in the 1 us range, I don't think I'd be surprised. But 2-5 us is a lot more than I expected to see. I also expected it would be fairly consistent, but it jumps around from the low to the high range quite a bit.

Any ideas? Here's the test program:

Code:

#include <12f615.h>

#fuses IOSC8,NOWDT,NOMCLR,NOBROWNOUT,NOPUT,INTRC_IO, NOPROTECT

#use delay(clock=8000000)

#use fast_io(ALL)

void main() {
   
   set_tris_a(0b00001100);
   // A0: PGD, not used otherwise (output low)
   // A1: PGC, not used otherwise (output low)
   // A2: Pulse input
   // A3: MCLR
   // A4: unused, output low
   // A5: Pulse output

   output_low(PIN_A0);
   output_low(PIN_A1);
   output_low(PIN_A4);
   output_low(PIN_A5);

   setup_wdt(WDT_144MS); // WDT on in software

   while(1) {

      if(input(PIN_A2)) output_high(PIN_A5);
      else output_low(PIN_A5);

      restart_wdt();
   }
}


Compiler version is 5.083.

Thanks in advance.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 11:00 am     Reply with quote

1st get RID of the WDT code......,recompile and test...see what happens.
There is no need for the WDT.

2nd, dump the listing and post it here...
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 11:22 am     Reply with quote

Agreed, remove the watchdog for now.

If all you're looking for is to monitor one pin and set a reaction on another pin, consider CLC (configurable logic cell). I realize that your problem is probably more involved, and that you're initially gauging response time as part of a larger issue, but if speed is critical and the task is simple, you can't beat standard gates.
2xhp



Joined: 14 Jan 2019
Posts: 39

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 11:42 am     Reply with quote

temtronic wrote:
1st get RID of the WDT code......,recompile and test...see what happens.
There is no need for the WDT.

2nd, dump the listing and post it here...


First, thank for the response.

I had previously tested with the WDT removed with no discernible difference. I put it back in as I will need this functionality in the final program (so wanted to see best-case performance with this included).

I revised the program to remove the WDT again though and verified no change. Here is the list file:


    CCS PCM C Compiler, Version 5.083, xxxxx 07-Jan-21 10:37

    Filename: C:\temp\test.lst

    ROM used: 31 words (3%)
    Largest free fragment is 993
    RAM used: 4 (6%) at main() level
    4 (6%) worst case
    Stack used: 0 locations
    Stack size: 8

    *
    0000: MOVLW 00
    0001: MOVWF 0A
    0002: GOTO 004
    0003: NOP
    .................... #include <12f615.h>
    .................... //////////// Standard Header file for the PIC12F615 device ////////////////
    .................... ///////////////////////////////////////////////////////////////////////////
    .................... //// (C) Copyright 1996, 2014 Custom Computer Services ////
    .................... //// This source code may only be used by licensed users of the CCS C ////
    .................... //// compiler. This source code may only be distributed to other ////
    .................... //// licensed users of the CCS C compiler. No other use, reproduction ////
    .................... //// or distribution is permitted without written permission. ////
    .................... //// Derivative programs created using this software in object code ////
    .................... //// form are not restricted in any way. ////
    .................... ///////////////////////////////////////////////////////////////////////////
    .................... #device PIC12F615
    ....................
    .................... #list
    ....................
    ....................
    .................... #fuses IOSC8,NOWDT,NOMCLR,NOBROWNOUT,NOPUT,INTRC_IO, NOPROTECT
    ....................
    .................... #use delay(clock=8000000)
    ....................
    .................... #use fast_io(ALL)
    ....................
    .................... void main() {
    0004: MOVF 03,W
    0005: ANDLW 1F
    0006: MOVWF 03
    0007: BCF 1F.6
    0008: BSF 03.5
    0009: BCF 1F.0
    000A: BCF 1F.1
    000B: BCF 1F.2
    000C: BCF 1F.3
    000D: BCF 03.5
    000E: CLRF 1A
    000F: CLRF 1C
    ....................
    .................... set_tris_a(0b00001100);
    0010: MOVLW 0C
    0011: BSF 03.5
    0012: MOVWF 05
    .................... // A0: PGD, not used otherwise (output low)
    .................... // A1: PGC, not used otherwise (output low)
    .................... // A2: Pulse input
    .................... // A3: MCLR
    .................... // A4: unused, output low
    .................... // A5: Pulse output
    ....................
    .................... output_low(PIN_A0);
    0013: BCF 03.5
    0014: BCF 05.0
    .................... output_low(PIN_A1);
    0015: BCF 05.1
    .................... output_low(PIN_A4);
    0016: BCF 05.4
    .................... output_low(PIN_A5);
    0017: BCF 05.5
    ....................
    .................... while(1) {
    ....................
    .................... if(input(PIN_A2)) output_high(PIN_A5);
    0018: BTFSS 05.2
    0019: GOTO 01C
    001A: BSF 05.5
    001B: GOTO 01D
    .................... else output_low(PIN_A5);
    001C: BCF 05.5
    001D: GOTO 018
    .................... }
    .................... }
    001E: SLEEP

    Configuration Fuses:
    Word 1: 3CD4 INTRC_IO NOWDT NOPUT NOMCLR NOPROTECT IOSC8 NOBROWNOUT
2xhp



Joined: 14 Jan 2019
Posts: 39

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 11:46 am     Reply with quote

newguy wrote:
Agreed, remove the watchdog for now.

If all you're looking for is to monitor one pin and set a reaction on another pin, consider CLC (configurable logic cell). I realize that your problem is probably more involved, and that you're initially gauging response time as part of a larger issue, but if speed is critical and the task is simple, you can't beat standard gates.


Hi newguy. You are correct, there is more to come in the program that can't be realized (at least not easily) with logic gates.

I do have a newer PIC arriving any minute (PIC12F1571) that ends up being quite a bit cheaper and can run with an internal oscillator of 32 MHz. I'll test it with the same basic program and see what difference I find. I can't imagine it being worse!
gaugeguy



Joined: 05 Apr 2011
Posts: 288

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 12:36 pm     Reply with quote

Looking at the assembly it is going to be anywhere from 3 to 8 clock cycles delay in response. At 8MHz that would be 1.5us to 4us. Seems to match your testing fairly close.
2xhp



Joined: 14 Jan 2019
Posts: 39

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 12:54 pm     Reply with quote

gaugeguy wrote:
Looking at the assembly it is going to be anywhere from 3 to 8 clock cycles delay in response. At 8MHz that would be 1.5us to 4us. Seems to match your testing fairly close.


I see now looking at the list file and the number of cycles per instruction how you get the 3 cycles. That would be upon detecting a high input. But I'm not seeing the 1.5 us on every rising edge - I see 1.5 to 4 us seemingly random (again - on the detection of a high input). Any ideas what could be causing that randomness?

Thank you.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 1:20 pm     Reply with quote

The randomness or jitter can be the signal generator ( is it a super stable 50/50 square wave ??)
or
simply WHEN a 'high'( or 'low) is detected.

Say the high pulse width is 10us. You don't have any 'sychronizing' with WHEN you sample. it could be .25us into the high, 2us, 4.99 us,9.99us etc.
Ideally you want to sample on the rising and falling edges.
I don't know if that PIC has 'edge detection' (IOC) capability.
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 3:15 pm     Reply with quote

temtronic wrote:
The randomness or jitter can be the signal generator ( is it a super stable 50/50 square wave ??)
or
simply WHEN a 'high'( or 'low) is detected.

Say the high pulse width is 10us. You don't have any 'sychronizing' with WHEN you sample. it could be .25us into the high, 2us, 4.99 us,9.99us etc.
Ideally you want to sample on the rising and falling edges.
I don't know if that PIC has 'edge detection' (IOC) capability.


IOC won't bring the reaction time down, especially if you actually code it as an interrupt driven event. The fastest possible reaction will be 3 clock cycles, worst 8 as gaugeguy has posted. The reaction, as Jay has said, depends on when the pulse arrives relative to which line the program is currently executing. Assuming that the assembly for the new faster processor is the same, and the new process runs 4x faster, that means the reaction time will be 1/4 of what you're currently observing. If that isn't fast enough, you could try a PIC that is capable of running at 64MHz. If that still isn't enough, then a GAL or small FPGA will probably be your next best option.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group