PM Asembler and Melab U2 Programmer Problems with PIC16F1939


Closed Thread
Results 1 to 13 of 13

Hybrid View

  1. #1
    Join Date
    Jan 2009
    Posts
    78


    Did you find this post helpful? Yes | No

    Default

    I have the pic16F1939 on mine (ver 4.32)

    Name:  u2 ver 4.32.gif
Views: 866
Size:  39.1 KB

  2. #2
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    There is NO good reason to use PM as far as I know. Just stick to MPASM. You have much more great "hidden" features in...
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  3. #3
    Join Date
    Jan 2009
    Posts
    78


    Did you find this post helpful? Yes | No

    Default

    welcome back !

  4. #4
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    704


    Did you find this post helpful? Yes | No

    Default

    Bogdan,

    Tonight I will check to see what software version I have. I bought my U2 programmer about two years ago, so it is probably an old version. I need to research this issue a little bit more.

    Mister_e,

    It is very nice to see you back . I have a program >8000 words that I developed using PM. This program uses interrupts on a PIC16F727 to read values for a built-in capacitance touch sensor. However, if I use MPASM the sensors don't work properly. I suspect it has to do with different interrupt intervals if I use MPASM, but I haven't tested this yet. This is the reason why I use PM for my touch sensor projects.

    Robert
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  5. #5
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    Or it's working as design with MPASM, but have problem with PM, but... ya never know.

    Do yourself a big favor, isolate the problem, keep the ISR and a simple short and sweet main loop, see if the problem's still there.

    Usual Convention: Keep the ISR as short as possible.


    Get rid of PBP interrupt and use ASM one, or DT.

    Maybe not a bad idea to make sure you're using the latest MPASM version.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  6. #6
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    704


    Did you find this post helpful? Yes | No

    Default

    Bogdan,

    I have an old software version 4.23. In Melabs.com they have a free download for the latest Beta v4.32 software. I will install it and will post back with results.

    Mister_e,

    Yes, I know that I have to fix that problem with the interrupts to make the sensors work properly with MPASM. Now, I am using ON INTERRUPT GOTO ISR to handle the ISR. There are many lines of code that need to get done in the ISR routine. So, if I have many lines of PBP in the ISR routine, what method should I use?

    Should I go with something like this?
    Code:
    @myint                  ; create myint label
    .......
       @ retfie  FAST       ; Return with 'auto restore' of WREG, STATUS and BSR
    Or, should I do something like this with DTs interrupts?

    Code:
    INCLUDE "DT_INTS-14.bas"     ' Base Interrupt System
    INCLUDE "ReEnterPBP.bas"     ' Include if using PBP interrupts
    
    ASM
    INT_LIST  macro    ; IntSource,        Label,       Type, ResetFlag?
    			INT_Handler   TMR0_INT,  _MyInterrupt,   PBP,  yes
    	endm
    	INT_CREATE               ; Creates the interrupt processor
    ENDASM
    
    @ INT_ENABLE  TMR0_INT      ; enable Timer 0 interrupts
    
    .....
    
    MyInterrupt:                       
    .....
    @ INT_RETURN
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  7. #7
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    If you have PBP lines in your ISR, I'd say go for your second example.

    What kind of interrrupt it is? Remember that ON INTERRUPT will jump in your ISR ONLY after finishing a x current job. So if you have, say PAUSE 5000, in your main loop, it may take up to 5 secondes to jump in the ISR (assuming your main loop is actually doing the PAUSE). Maybe why your sensor doesn't work that good. Now why better on PM than MPASM, I don't know.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts