Assembly delays don't work in ISIS proteus

Discussion in 'General Electronics Chat' started by Richjtf, Apr 30, 2015.

  1. Richjtf

    Thread Starter New Member

    Oct 12, 2013
    Hey, i've tried several programs already on proteus and none of them have worked, as soon as it reaches the point where the delay is called it stays there, stock, and won't do anything else, i've ran programs that used to work but don't now. Whats going on?

    Code (Text):
    2. list p=16f84A
    3. include <>
    6. org 0
    8. TIME1 EQU 0Eh
    9. BSF 03h,5
    10. MOVLW B'00000'
    11. MOVWF 85h
    12. BCF 03h,5
    14. START
    15. MOVLW B'00001'
    16. MOVWF 05h
    17. CALL DELAY1
    18. MOVLW B'00010'
    19. MOVWF 05h
    20. GOTO START
    22. DELAY1
    23. MOVLW D'255'
    24. MOVWF TIME1
    25. DEC
    26. DECFSZ TIME1
    27. GOTO DEC
    28. RETURN
    30. END
  2. JohnInTX


    Jun 26, 2012
    Keep in mind that simulators take each PIC instruction and spend much more time 'executing' it on the host machine (your PC) than it would take on the actual chip. For most things this is OK but for delays, it can wind up taking a very long time to simulate.

    I rarely use counting delays but one way to make things better for you is to use a very short delay when simulating. You can organize the process by an assembler-time switch:

    Code (Text):
    1. ;--------------- CONFIGURATION  ----------------------------------------
    2. USE_SIM equ 1;  1=simulate, 0=on-chip selects delay time..
    5. ;  Your code:
    6. if USE_SIM == 1
    7.   movlw 2  ; just run delay twice
    8. else
    9.   movlw 255 ; on chip, use full delay
    10. endif
    11.   movwf TIME1 ; set timer with appropriate value
    13. ; then the rest of your delay code here
    The reason for making an assemble-time switch is that once you get it working, you can switch simply back and forth between simulation and code for the actual target chip in as many places as required without having to visit each place in the code whenever you switch modes. Collect all of the switches (and XTAL and CONFIG bit settings) in a separate CONFIG.INC file and include it in all of the .ASM files in the build. That way you can change values without screwing up the code flow. 'Real programmers' make heavy use of such things.

    BTW, your code will read better if you:
    1) put a ':' after each label i.e. DEC:
    2: explicitly specify the destination register i.e. ,W or ,F - don't rely on defaults
    3) I personally like lower case for the instructions - upper case for symbols and macros
    4) use indents - MPASM is flexible in this regard - Labels start in column 1 always, other code is indented.
    Code (Text):
    1. DEC:
    2.   decfsz TIME1,F
    3.   goto DEC
    Finally, don't forget that you can use MPSIM in MPLAB to simulate your code. Use a watch window to see what it does. If you watch the PORT registers, you can see the outputs happen as you step.

    Hello to Portugal and have fun.
    Last edited: May 1, 2015