Menu

10f200 setting gp2 as output

Help
2017-02-09
2017-02-10
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-09

    Hi, pretty new on PIC programming.
    Just tried to create a walking LED with 3 outputs on this low end PIC
    GP2 is shared with TOCS so I have to disable TOCS output in this pin.
    I cannot find how to override the TOCS precedence. I know I have to clear bit five on the option register but cannot find out how to do this in code.
    I tried :

    asm MOVLW b'11011111'
    asm OPTION
    

    but that won't work.
    I'm using the internal osc and no fancy stuff. Even use sequential output code.
    Here is the code so far:

      ; ----- Configuration
      #chip 10f200, 4
    
      ; ----- Constants
      #define LED0 GPIO.0
      #define LED1 GPIO.1
      #define LED2 GPIO.2
    
      asm MOVLW b'11011111'
      asm OPTION
    
      ; ----- Define Hardware settings
      dir LED0 out
      dir LED1 out
      dir LED2 out
    
       ; ----- Variables
        ' No Variables specified in this example. All byte variables are defined upon use.
    
      ; ----- Main body of program commences here.
    
      Do
        LED0 = FnNotBit( LED0 )  ' LED != LED
        wait 100 ms
        LED1 = FnNotBit( LED1 )  ' LED != LED
        wait 100 ms
        LED2 = FnNotBit( LED2 )  ' LED != LED
        wait 100 ms
      Loop
    
      end
    

    thank for helping me out :)

     
  • kent_twt4

    kent_twt4 - 2017-02-09

    Program works fine in 95.008, so newer uploads should be O.K., which version do you have? Wiring, led orientation, or other problem here?

    GCB is happy to set the option register for you in the default INITSYS sub, so no real need to set OPTION unless there are other reasons. Default OPTION register setting is b'11000111', which handles the TOCK pin.

     
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-10

    I have the latest windows version (0.96.00) installed in a virtual box using the Synwrite IDE
    I have GCB installed under linux too. Will try to compile there and report back
    Wiring or LED orientation cannot be the case. Iḿ using a breakout LED board with integrated resitors. Just one wire to GND and a wire to the output LED
    so IC pin 5 -> Led Board 0, IC pin 4 -> LED board 1 and IC pin 3 -> LED board 2
    LED 0 and 1 are flashing, LED 2 lights up on half power. On my scope there is a 50% duty cycle pulse from the clock

    Compiling & linking in Linux gives me the same results. Latest gcbasic version (0.96 for linux) on Linux Mint. I hooked up the datalogger. As you can see there is a 1 Mhz pulse on GPIO2

     

    Last edit: Ruud de Vreugd 2017-02-10
  • kent_twt4

    kent_twt4 - 2017-02-10

    Seeing equal power between LED1 and LED2, LED0 not checked because different led. I thought that LED2 was also down on power, but when looked at directly (due to narrow emitter angle) from above they are the same brightness. You have checked milliamps?

     
    • Ruud de Vreugd

      Ruud de Vreugd - 2017-02-10

      see previous post with screenshot

       
  • kent_twt4

    kent_twt4 - 2017-02-10

    O.K. so still TOCK out, can you post your assembly file.

     
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-10

    sure, this is the assembly file from the linux compiler:

    ;Program compiled by Great Cow BASIC (0.96.<<>> 2016-12-14)
    ;Need help? See the GCBASIC forums at http://sourceforge.net/projects/gcbasic/forums,
    ;check the documentation or email w_cholmondeley at users dot sourceforge dot net.
    
    ;********************************************************************************
    
    ;Set up the assembler options (Chip type, clock source, other bits and pieces)
     LIST p=10F200, r=DEC
    #include <P10F200.inc>
     __CONFIG _MCLRE_OFF & _WDTE_OFF & _OSC_INTRC
    
    ;********************************************************************************
    
    ;Set aside memory locations for variables
    BITIN   EQU 20
    DELAYTEMP   EQU 16
    DELAYTEMP2  EQU 17
    OPTION_REG  EQU 21
    SYSBITVAR0  EQU 22
    SYSWAITTEMPMS   EQU 18
    SYSWAITTEMPMS_H EQU 19
    TRISIO  EQU 23
    
    ;********************************************************************************
    
    ;Vectors
    ;Start of program memory page 0
        ORG 0
    BASPROGRAMSTART
    ;Call initialisation routines
        call    INITSYS
    
    ;Start of the main program
    ;#define LED0 GPIO.0
    ;#define LED1 GPIO.1
    ;#define LED2 GPIO.2
    ;dir LED0 out
        bcf TRISIO,0
        movf    TRISIO,W
        tris    GPIO
    ;dir LED1 out
        bcf TRISIO,1
        movf    TRISIO,W
        tris    GPIO
    ;dir LED2 out
        bcf TRISIO,2
        movf    TRISIO,W
        tris    GPIO
    ;Do
    SysDoLoop_S1
    ;LED0 = FnNotBit( LED0 )  ' LED != LED
        clrf    BITIN
        btfsc   GPIO,0
        incf    BITIN,F
        call    FN_FNNOTBIT
        bcf GPIO,0
        btfsc   SYSBITVAR0,3
        bsf GPIO,0
    ;wait 100 ms
        movlw   100
        movwf   SysWaitTempMS
        clrf    SysWaitTempMS_H
        call    Delay_MS
    ;LED1 = FnNotBit( LED1 )  ' LED != LED
        clrf    BITIN
        btfsc   GPIO,1
        incf    BITIN,F
        call    FN_FNNOTBIT
        bcf GPIO,1
        btfsc   SYSBITVAR0,3
        bsf GPIO,1
    ;wait 100 ms
        movlw   100
        movwf   SysWaitTempMS
        clrf    SysWaitTempMS_H
        call    Delay_MS
    ;LED2 = FnNotBit( LED2 )  ' LED != LED
        clrf    BITIN
        btfsc   GPIO,2
        incf    BITIN,F
        call    FN_FNNOTBIT
        bcf GPIO,2
        btfsc   SYSBITVAR0,3
        bsf GPIO,2
    ;wait 100 ms
        movlw   100
        movwf   SysWaitTempMS
        clrf    SysWaitTempMS_H
        call    Delay_MS
    ;Loop
        goto    SysDoLoop_S1
    SysDoLoop_E1
    ;end
        goto    BASPROGRAMEND
    BASPROGRAMEND
        sleep
        goto    BASPROGRAMEND
    
    ;********************************************************************************
    
    Delay_MS
        incf    SysWaitTempMS_H, F
    DMS_START
        movlw   142
        movwf   DELAYTEMP2
    DMS_OUTER
        movlw   1
        movwf   DELAYTEMP
    DMS_INNER
        decfsz  DELAYTEMP, F
        goto    DMS_INNER
        decfsz  DELAYTEMP2, F
        goto    DMS_OUTER
        decfsz  SysWaitTempMS, F
        goto    DMS_START
        decfsz  SysWaitTempMS_H, F
        goto    DMS_START
        retlw   0
    
    ;********************************************************************************
    
    FN_FNNOTBIT
    ;If BitIn then
        movf    BITIN,F
        btfsc   STATUS,Z
        goto    ELSE7_1
    ;FnNOTBit = 0
        bcf SYSBITVAR0,3
    ;Else
        goto    ENDIF7
    ELSE7_1
    ;FnNOTBit = 1
        bsf SYSBITVAR0,3
    ;End If
    ENDIF7
        retlw   0
    
    ;********************************************************************************
    
    INITSYS
    ;movwf OSCCAL
        movwf   OSCCAL
    ;movlw b'11000111'
        movlw   199
    ;option
        option
    ;option_reg = b'11000111'
        movlw   199
        movwf   OPTION_REG
    ;GPIO = 0
        clrf    GPIO
        movlw   255
        movwf   TRISIO
        retlw   0
    
    ;********************************************************************************
    
     END
    

    in initsys option is set correct as you can see ???

     
  • kent_twt4

    kent_twt4 - 2017-02-10

    OK then, need help from Anobium (Evan) here. OSCCAL doesn't really need to be set in INITSYS, cut and paste issue? And in doing so, it is not being set correctly OSCCAL = b'11000111' so bit0 is setting the INTOSC/4 to output on GP2.

    EDIT: I know 95.008 works properly, or you can rewrite OSCCAL with bit0 = 0 in main to overwrite INITSYS till a fix is in.

     

    Last edit: kent_twt4 2017-02-10
  • Anobium

    Anobium - 2017-02-10

    Thanks... see http://gcbasic.sourceforge.net/help/compilerinsights.html as a start. This will explain the changes we made to support these chips.

    I need look into the issue. Back later.

     
    • Anobium

      Anobium - 2017-02-10

      I need to discuss with the dev team.

      @Kent is correct. We are incorrectly setting OSCCAL. This is not a typo but an error when we extended the code to support some differing chip types.

      Meanwhile... try this. I did simplfy the code. :-)

      ; ----- Configuration
        #chip 10f200, 4
      
        OSCCAL.0 = 0
      
        ; ----- Constants
        #define LED0 GPIO.0
        #define LED1 GPIO.1
        #define LED2 GPIO.2
      
        ; ----- Define Hardware settings
        dir LED0 out
        dir LED1 out
        dir LED2 out
      
         ; ----- Variables
          ' No Variables specified in this example. All byte variables are defined upon use.
      
        ; ----- Main body of program commences here.
      
        Do
          LED0 = !LED0
          wait 100 ms
          LED1 = !LED1
          wait 100 ms
          LED2 = !LED2
          wait 100 ms
        Loop
      
        end
      
       
  • jackjames

    jackjames - 2017-02-10

    The link is not working.

     
    • Anobium

      Anobium - 2017-02-10

      http://gcbasic.sourceforge.net/help/_compiler_insights.html

      Try this - but, on relfection... this is just fyi. Does not resolve. We are having a discussion in the DEV forum to resolve. The issue is not a cut and paste issue but a constraint we may not have applied - I the brains of the Dev team!!

       
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-10

    Sorry for not responding earlier, had to catch some sleep :)

    Update:
    A installed 0.95 and that worked without a problem, just to be sure, although I had to change the FnNotBit part because that is an unknown function in 0.95

    Back to the latest release, simplified and optimised the code to this

      '''@author  R. de Vreugd
      '''@licence GPL
      '''@version 1.02a
      '''@date    10.02.2017
      '''********************************************************************************
    
      ; ----- Configuration
      #chip 10f200, 4
    
      OSCCAL.0 = 0 ; work around?
    
      ; ----- Constants
      #define LED0 GPIO.0
      #define LED1 GPIO.1
      #define LED2 GPIO.2
    
      ; ----- Define Hardware settings
      dir LED0 out
      dir LED1 out
      dir LED2 out
    
       ; ----- Variables
        ' No Variables specified in this example. All byte variables are defined upon use.
    
      ; ----- Quick Command Reference:
      'See header for details
    
      ; ----- Main body of program commences here.
    
      Do
        LED0 = !LED0  ' LED != LED
        pause
        LED1 = !LED1  ' LED != LED
        pause
        LED2 = !LED2  ' LED != LED
        pause
      Loop
    
      end
    
      ; ----- Support methods.  Subroutines and Functions
    sub pause
      wait 100 ms
    end sub
    

    note the OSCCAL.0 = 0 as a workaround (thanks Anobium)
    That workaround did the trick, see the attached screenshot of my logger

    Ruud

     
    • Anobium

      Anobium - 2017-02-10

      Can you try the code using 0.96.00? We will only fix 0.96.00 and later releases?

       
      • Ruud de Vreugd

        Ruud de Vreugd - 2017-02-10

        The previous post is the 0.96 version. To be sure I tried the code in an older version without the OSCCAL.0 = 0 and that worked.
        The code and output you see in te previous post is used and compiled with the latest IDE version in Windows (0.96) and the linux (ubuntu.MINT) version.
        On these versions the clock pulse on the output pin is NOT disabled. You have to use the workaround you posted some messages ago using OSCCAL.0 = 0
        Then the result is as expected.

        off topic: Just entered the amazing wold of PIC programming. Used MPLAB X both in assembler and X8C but was not thrilled. I must say I really do like GCB and I am very surprised about these community responses. Think I will stick with GCB for a long time :) Keep it up guys!

         
  • Anobium

    Anobium - 2017-02-10

    @Ruud de Vreugd. Nothing looks incorrect.

    What are you using to program the chip? we believe that you have knocked out the calibration. We need to know what you are using to program.

    Why does 0.95 and not 0.96. 0,95 ran the chip uncalibrated... not good. 0.96 has the correct call to setup the chip at the calibrated clock speed. So, we believe (at the moment), the code is valid.

    Let us know. We are all waiting to here!!

     
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-10

    For this project I used an K150 programmer. Removing the chip from the breadboard, program it en replace it. If you like I could try a pickit 2 as that is in my toolbox too. A pickit 3 is on it's way.
    To be sure:
    Version 0.96 with K150 no OSCCAL.0=0 --> clock on output
    Version 0.96 with K150 with OSCCAL.0=0 --> correct running LEDs
    Version 0.95 with K150 no OSCCAL.0=0 -> correct running LEDs

    PicKit 2, I hav eto try, but I am out for a few hours, will do when I get back

     
  • Anobium

    Anobium - 2017-02-10

    AHA! the K150 has knocked out the calibration. The PK2 and PK3 will sort this with our build of the software. Please installed the software included in your GCB for the pk2 and/or the pk3.

    Anyway, you need to restore the calibration and all 'should' be ok. My OSCCAL value is 0CFF on my 10F202.

    I am sure others can tell you how to re-calibate but if it does not fix it.. use the OSCCAL=0 and press on!

     
  • kent_twt4

    kent_twt4 - 2017-02-10

    My 10f200 OSCCAL=0C24. From what I can tell, the 10f200,202,204,206,220,222 has the FOSC4 bit in OSCCAL.0 Other baseline chips like 12f508,509 have no FOSC4/OSCCAL.0 bit.

    The Pk2 has the OSCCAL auto calibrate function under the tools header of the GUI. Pk3 can do this too under the MPLAB IPE.

     
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-10

    Ok gents her I am again.
    Think I have to disappoint you :(
    An update of my new actions:
    Stashed the K150 and hooked up the PK2 first stand alone, so remove the chip from the breadboard. Create a hex file with GCB (0.96) and write the hex with the PK2 util
    Did that with osccal.0=0 in the code and again commented out.
    Second I did exactly the same but now in circuit powered by the PK2
    My OSCCAL calibration is 0CFF and is preserved on write.
    So there is no need to restore calibration.
    Here are the results:


    off circuit, osccal.0 set in code -> working correct
    off circuit, osccal.0 removed -> clockpulse on output pin 2
    in circuit, OSCCAL.0 set in code -> working correct
    in circuit, OSCCAL.0 removed -> clockpulse on output pin 2

    Sorry we are back to square one. The programmer is ruled out result are the same for the K150 and the PK2 and ther is nothing wrong with my calibration. Tried again with a brand new spare 10f200 with same results.

    *BTW: this is not a simple experiment. In the end I want to create a small battery operated device that pulses a IR led (GP0), read the pulses back on GP3 and if interupted opens the shutter of a camera (GP1) and activates a flash (GP2). *

    EDIT: if you check the datlogger output a few messages ago you can see that the clock pulse is 1.083 us. Well within limits of the specs from the internal osc and the values in the datasheet (in theory the pulswidth should be 1us)

     

    Last edit: Ruud de Vreugd 2017-02-10
  • kent_twt4

    kent_twt4 - 2017-02-11

    Use OSCCAL auto regenerate in Pk2 and tell us the results, in circuit is the way to go.

    This seems very odd that OSCCAL is 0CFF, that is the default? number that pops up when first opening Pk2 and selecting the device, or changing to a different device, but not after programming or reading the device.

     
  • William Roth

    William Roth - 2017-02-11

    An OSCCAL value of 0x0CFF seems odd. The 0C is the MOVLW instruction an is of no concern. However the FF indicates that the chip calibration is set to near center frequency with bit 0 on. FF is the default and is unlikely to be the best calibration value.

    If we write this value of FF to the OSCCAL register via the routine in system.h then bit 0 will be on. A calibration value of 0CFE seems more appropriate.

    I would try the automatic calibration feature in the Pick2 GUI and see what value it selects. If the utility is "smart" it will write an even value where bit 0 is off, If it is not "smart" it could write an odd value where bit 0 is ON. In this case it could be modified by manually setting the calibration value.

    The other option is to mask out bit 0 in source code. As this will not affect the OSC calibration.

    A better check of accurate calibration is to do a "wait 10 ms" and measure with a scope as as the error will accumulate. over time and be more visible. Microsecond measurements are not accurate.

    1.083 us X 10000 = 10.83 ms and we can do better than that with the correct calibration value. In fact 10.83 ms is what I get when I delete the calibation data on a 12F510. With the autogenerated value from PK2 GUI it improves to 10. 07 ms

    EDIT:
    The OSC on these chips is supposed to be factory calibrated to +- %1. So if we assume that 1.083us is an accurate measurement we are out of specification by 8%. It should be between .99us and 1.01 us.

     

    Last edit: William Roth 2017-02-11
  • Ruud de Vreugd

    Ruud de Vreugd - 2017-02-11

    OK guys,
    I guess you are right. I used the auto calibration of the PK2. The selected value came out on 0C16 (even value). From that moment on everything works as it should be. I do not have to set the OSCCAL manualy. So it really was a bad calibration value. Is that caused by the K150??
    Set the wait time at 10ms to measure the values wit the datalogger like William sugested.
    Measured value 10.035ms. Some siple math gives me a clockpulse of 1.0035us

    I love this community. I had never ever found this on my own.
    thanks

     

    Last edit: Ruud de Vreugd 2017-02-11
  • William Roth

    William Roth - 2017-02-11

    Looks like we have a resolution. All pins working as expected and an accurate OSC.

    Yes, IMO it was most likely the K150 Programmer that erased the calibration data, .

    And BTW ....... Welcome to Great Cow Basic !

     
  • Anobium

    Anobium - 2017-02-11

    Just to correct my info of the earlier post my OSCCAL on the 10F202 on test here is 0x0C0E which does give me a 10,00ms width for a 'wait 10 ms'

    Result.

    Oh.... Welcome to Great Cow BASIC. Enjoy.

     

    Last edit: Anobium 2017-02-11

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.