Yesterday 19:19
Forum: Proton Plus Compiler v3
Starter: rcurl
Views: 0
Replies: 10
Yesterday 15:59
Forum: Proton Plus Compiler v3
Starter: evoortman
Views: 0
Replies: 7
Yesterday 15:45
Forum: Proton Plus Compiler v3
Starter: xldaedalus
Views: 0
Replies: 28
Yesterday 10:03
Forum: Proton Plus Compiler v3
Starter: palamont
Views: 0
Replies: 1
+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Num_Byte on 18F26K42149 days old

  1. #1
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Num_Byte on 18F26K42

    I'm using a macro that was created by the generator

    Code:
      Dump Macro  P1
      #if (Prm_Count > 1)
          #error "Dump - Too many parameters"
      #else
          #if (Prm_Count < 1)
              #error "Dump - Too few parameters"
          #else
              #if(Prm_1 != Num8)
                  #error "Dump - DumpNum(Param1) Must be a decimal number"
              #endif
                Num_Byte P1, D_DumpID
          D_WaitFlag = 0                                ' silly billy
              GoSub D_Dump
          #endif
      #endif
      Endm

    and is used
    Code:
      '
      ' code
      '
      Dump n        ' where n is an 8 bit integer
      '
      ' code
      '
    This is works on all tested devices except 18F26K42 which always returns 0. Loath to raise anomaly report as I know 18F26K42 is a work in progress.

    I'm guessing the problem is Num_Byte, anyone have a solution or work around?

    I also appear to have a problem with Eread on this device.
    George

  2. #2
    Senior Member AlbertoFS's Avatar
    Join Date
    Apr 2005
    Posts
    655
    Thumbs Up
    Received: 122
    Given: 2
    Total Downloaded
    3.33 GB

    1 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Hi George,
    I have compiled your macro with the PDS version 3.6.1.4 and I do not see anything strange in the compiled asm code.
    I have tried to put their variables in Bank0 and I have left them in Bank1. The change of Banks works well.

    Macro:
    Code:
    F1_000048 equ $ ; IN [MACRO1.BAS] DUMP 230
    variable max_params=10,DUMP_RETURN=0,prm_count=1
        movlw 230
        movff WREG,D_DumpID
        movlb 0X01
        bcf _B#VR1,0,1
        movlb 0
        rcall D_Dump
    I do not see anything curious about Eread either.
    Eread:
    Code:
    F1_000050 equ $ ; IN [MACRO1.BAS] D_DUMPID = EREAD 0
        movlb 0X39
        clrf NVMADRLH,1
        clrf NVMADRL,1
        rcall __eeread_w_
        movlb 0X01
        movwf D_DumpID,1
    
    __eeread_
        movwf NVMADRL
    __eeread_w_
        clrf NVMCON1
        bsf NVMCON1,PP_RD
        movf NVMDAT,W
        infsnz NVMADRL,F,0
        incf NVMADRLH,F,0
        bsf NVMCON1,PP_NVMREG1
        return
    But I do not see these 2 lines in the beginning of the program asm.
    Clrf NVMCON1
    Bsf NVMCON1, PP_NVMREG1
    I do not know if it will have an effect.
    I have noticed a mixture of parameters in decimal and in Microchip hex. But this does not affect the operation.

    Regards
    Alberto

    P.S. I have obtained the same asm code with PIC18F26K22.
    Try with preprocessor macro, the result is a little bit different.
    $define Dump2(pValue) '
    D_DumpID = pValue '
    D_WaitFlag = 0 '
    GoSub D_Dump
    Last edited by AlbertoFS; 26th May 2018 at 16:29.
    [U]73's de Alberto ea3agv[/U]

  3. #3
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Thanks for the info and your efforts. I'll try your suggestions and get back to you.

    Edit. I tried your macro but it won't compile

    error [line251]Value expected!
    error [line251]unrecognised,illegal or unresolved character found ' 12 ' repeated for each usage

    Do I need to Dim pValue?
    Last edited by towlerg; 26th May 2018 at 17:58.
    George

  4. #4
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Num_Byte on 18F26K42

    I must be looking in the wrong place because my expanded macro looks nothing like the one you posted.
    Code:
    F2_001754 equ $ ; IN [SNAPSHOT.INC] DUMPW MACRO  P1
    DumpW    macro P1,.,.,.,.,.,.,.,.,.
     local prm_empty=0,bit=1,byte=2,word=3,dword=4,float=5,label=6,char=7,string=9
     local num8=8,num16=16,num32=32,snum8=10,snum16=15,snum32=31,fnum=33,byte_array_ptr=22,word_array_ptr=23,dword_array_ptr=24
     local sbyte=11,sword=12,sdword=13,sbyte_array_ptr=25,sword_array_ptr=26,sdword_array_ptr=27
     if (prm_count > 1)
        error "(IN ASM) DumpW - TOO MANY PARAMETERS"
     else
     if (prm_count < 1)
        error "(IN ASM) DumpW - TOO FEW PARAMETERS"
     else
     if (prm_1 != num8)
        error "(IN ASM) DumpW - DUMPNUM(PARAM1) MUST BE A DECIMAL NUMBER"
     endif
        num_byte P1, D_DumpID
    ram_bank = 0
        bsf _B#VR1,3,0
        f@call D_Dump
     endif
     endif
        endm
    I've included the source files in case that helps. Thanks again for all your efforts.
    Attached Files Attached Files
    George

  5. #5
    Senior Member AlbertoFS's Avatar
    Join Date
    Apr 2005
    Posts
    655
    Thumbs Up
    Received: 122
    Given: 2
    Total Downloaded
    3.33 GB

    1 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Hi George,
    I have copied a macro from your program to a new very short test program. As I had announced in post#2, it works perfectly.
    I have been able to see in your file that the 2 macros are not compiled for a reason I can understand. (For xxK22 and same for xxK40)
    I have reviewed the preprocessor guidelines several times. Only I have found an errata in lines 89 to 95. You would have to verify.

    On the other hand, in my opinion, it is better to avoid using asm macros in your main code.
    Wreg_Byte D_WregBack
    Better replace it with:
    D_WregBack = WREG
    You have also written some codes in assembler. It could give Banks problems.
    I corrected some errata.

    You use the same version of PDS 3.6.14. I do not understand the problem.
    There would be an option! A non-visible character has been entered in the basic code causing a compilation failure. A similar thing happened to me once.
    You try to divide your program into small parts in a new file, always including the macros. Let's see if he finds the line that fails. You have to delete it and write it manually (no copy / paste).
    It is possible that it is a problem with the processor, you try to review everything.

    I will try to find more tomorrow.

    Anyway, changing the macro asm to the macro of the preprocessor as I have modified it in your program, works perfectly. By testing your program, it could be that you find the routine that fails.
    It is a very difficult case.
    Regards
    Alberto
    SnapShotInc_new.zip
    [U]73's de Alberto ea3agv[/U]

  6. #6
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Alberto, wow you realy go the extra mile. The reason that I was getting compile errors was because I used your macro incorrectly, I didn't put the parameter in brackets.

    I need to change my PC app (the part that parses out the Dumpid, its value, line number and source program name) before I can say if you've solved my problem. Thats a job for tommorrow.

    BTW I have tested my original code with k22 and it seems to work ok.
    George

  7. #7
    Senior Member AlbertoFS's Avatar
    Join Date
    Apr 2005
    Posts
    655
    Thumbs Up
    Received: 122
    Given: 2
    Total Downloaded
    3.33 GB

    1 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Hi George,
    I have modified their ASM macros so that you have brackets to be the same as other macros written by the processor.

    EUREKA ...
    I found the problem !!!!
    Change the [Declare Optimiser_Level = 0] for [Declare Optimiser_Level = 2] and all asm macros work.
    You would have to verify it with the core 14.
    This is new information for Les.

    Regards
    Alberto
    [U]73's de Alberto ea3agv[/U]

  8. #8
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Num_Byte on 18F26K42

    Well thats certainly strange. I must check what changes in the asm.

    From my end, I did some testing and without the above change, every device I tested worked equally well with either type of macro except 18F26K42 which returns 0 for assembler macro and hangs the process for preprocessor.

    Did test with Optimiser = 2 but sadly it still hangs.

    I realy appreciate your efforts.

    George

    Edit. Sorry finger trouble. With your preprocessor macro and device 18F27K42 my application works and the parameter is passed correctly. I thought I was an ok programmer but you're something else mate.

    The original macro, with optimizer = 2 and 18F27K42 works but still always passes 0 as macro parameter.

    I wish I understood macro's but I seem to have a mental block, pity there isn't a generator for them like the asembler one.

    Obviously I'm going to use the preprocessor macro from now on so my immeadiate problem is solved but the mystery of optimiser=2 remains.
    Last edited by towlerg; 27th May 2018 at 12:11.
    George

  9. #9
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,800
    Thumbs Up
    Received: 159
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Num_Byte on 18F26K42

    It's interesting to compare (as you have done) the assembler macro optimiser=2 with your preprocessor macro. They are kinda similar. It as if the optimiser is trying to replace the assembler macro with a processor one.
    George

  10. #10
    Fanatical Contributor Les's Avatar
    Join Date
    Feb 2002
    Posts
    3,003
    Thumbs Up
    Received: 306
    Given: 109
    Total Downloaded
    1.50 GB

    2 Not allowed!

    Default Re: Num_Byte on 18F26K42

    The problem lies in the new Movffl mnemonic, and the requirement for it, on the 18FXXK42 devices.

    This is now required because all the SFRs are in RAM above address 4096. However, it has some quirks that are not , exactly, published clearly.

    It does not recognise the Access RAM at the top of memory, and neither does the original Movff mnemonic, that all the other 18F devices do, so it still sees these above address 4096. When in reality, they are in the first RAM bank to the underlying core of the device, which is why the user access RAM stops at address $5F. It also requires 3 bytes, instead of 2.

    This is what has caused some of the more resent anomalies, and something I have been going through with a fine tooth comb. A lot of the compiler's routines use Bra $ - X, where X is the amount of code to jump back to. This stops a multitude of labels in code, and in macros, you cannot have the same label more than once. I have had to go through all the code in detail and look for somewhere that will be a Movffl on a 18FXXK42 chip, and make labels etc... This also applies to the compiler's macros in the seperate files. If anyone has made macros using the Movff mnemonic to access any SFR, and on a K42 device, this will need to be made into a Movffl mnemonic.

    That's where the _movffl define comes in, within a .def file of a devie that needs the Movffl mnemonic. If it is there, a Movffl is required instead of a Movff. if an SFR is one of its parameters, or a variable above the address 4096. For example:

    $ifdef _movffl
    Movffl Reg1, Reg2
    $else
    Movff reg1, Reg2
    $endif


    I'm creating another full installer that has all the modified macros and routines etc, but it will not be ready until tomorrow. Sorry for all the problems, but those bloody K42 devices are such a pain in the backside for very little reason. The underlying core of the new 18F devices should have handled all the differences invisibly.
    Last edited by Les; 27th May 2018 at 18:12.
    For more example programs for Proton and Proton24 or updates, please visit: Proton WIKI or Proton Files

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Similar Threads

  1. 18F26K42 status
    By towlerg in forum Proton Plus Compiler v3
    Replies: 4
    Last Post: 19th April 2018, 16:04

Members who have read this thread since 16th October 2018, 21:27 : 0

Actions :  (Set Date)  (Clear Date)

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

Tags for this Thread

Posting Permissions

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