• AVR Freaks

Hot!Porting MPASM assembly to XC8

Page: 12 > Showing page 1 of 2
Author
danish.ali
Super Member
  • Total Posts : 1721
  • Reward points : 0
  • Joined: 2004/11/16 02:02:02
  • Location: Surrey, UK
  • Status: offline
2020/03/11 06:34:22 (permalink)
0

Porting MPASM assembly to XC8

I have some legacy products that I wrote in mpasm for PIC16F506 (I originally used PIC16C54 so it goes back a long way).
 
I see that MPASM will not be updated to run on 64-bit platforms. Some time soon I would like to upgrade my Mac to the current OS, which no longer supports 32-bit code.
 
As I understand it, the recommendation is to use XC8 assembly instead. Is there any guidance on how to make the necessary changes? Ideally I would generate the same hex and checksum, so I can know that my code is right. But longer term I would be able to make changes and reassemble. So I would be doing naked assembly rather than calling selected assembly routines from within a C environment.
 
I have tried a few things that don't seem to correspond with the XC8 manual. For example conditional assembly seems to generate code for both the if and else portions.
 
Is there an example I might look at?
 
#1

27 Replies Related Threads

    danish.ali
    Super Member
    • Total Posts : 1721
    • Reward points : 0
    • Joined: 2004/11/16 02:02:02
    • Location: Surrey, UK
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/11 07:22:42 (permalink)
    0
    Correction: I see now that IF statements are always examined, so EQUs and syntax errors will be spotted even in the inactive sections.
    #2
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/11 08:17:20 (permalink)
    0
    danish.ali
    I see that MPASM will not be updated to run on 64-bit platforms. 
     
    As I understand it, the recommendation is to use XC8 assembly instead.

    Where did you see that from? 
     
    I have yet to see anyone used purely the XC8 assembler ASPIC, which is not very well documented (I've never looked for the ASPIC User's Guide, if there is one). From what I know, its syntax is different and less powerful than MPASM. ;)
     
    Edit: The ASPIC User's Manual/Guide returned from a Google search is NOT for the Microchip PIC. LOL!
     
     
    post edited by 1and0 - 2020/03/11 08:22:25
    #3
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/11 08:55:45 (permalink)
    0
    Jeff (mad_c) from XC8 Team posted a test program here:  https://www.microchip.com/forums/m890788.aspx but the compiler will also generate a runtime startup code and it's part of the C environment.
     
    post edited by 1and0 - 2020/03/11 09:00:29
    #4
    danish.ali
    Super Member
    • Total Posts : 1721
    • Reward points : 0
    • Joined: 2004/11/16 02:02:02
    • Location: Surrey, UK
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/11 13:27:43 (permalink)
    5 (1)
    1and0
    danish.ali
    I see that MPASM will not be updated to run on 64-bit platforms. 
     
    As I understand it, the recommendation is to use XC8 assembly instead.

    Where did you see that from? 
     
     

    When I launch MPLAB IDE 5.35, I get a warning for a project that only uses MPASM:
    Output - Configuration Loading Error
    MPASM is not supported on 64 bit Operating Systems. Please consider migrating your project "Mk8B_MPLabX" configuration "default" to XC8 Assembler or continue to use a previously released IDE.
     - Danish
    #5
    danish.ali
    Super Member
    • Total Posts : 1721
    • Reward points : 0
    • Joined: 2004/11/16 02:02:02
    • Location: Surrey, UK
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/12 02:08:11 (permalink)
    5 (1)
    I'm slowly making progress. I can get the whole thing to build as far as producing a credible disassembly listing that looks similar to the original code.I have defined a few macros that help (see below).
    But having checked Project Properties:Conf:XC8 Global Options:XC8 Linker:Runtime:Do not link startup module in, it seems that nothing gets loaded into memory the checksum is for blank memory! (Attached file build.png is a screenshot showing that there is filled memory, but the dashboard shows nothing used)
    How do I say "do load this file"?
    ; macros.inc
    ; for XC8 assembler for PIC16F506
    FALSE equ 0
    TRUE equ not FALSE
    skpnc macro
    btfsc CARRY
    endm
    skpc macro
    btfss CARRY
    endm
    skpz macro
    btfss ZERO
    endm
    skpnz macro
    btfsc ZERO
    endm
    ;----- CONFIG Options --------------------------------------------------
    _OSC_LP EQU 0x0FF8; LP oscillator and 18 ms DRT
    _LP_OSC EQU 0x0FF8; LP oscillator and 18 ms DRT
    _OSC_XT EQU 0x0FF9; XT oscillator and 18 ms DRT
    _XT_OSC EQU 0x0FF9; XT oscillator and 18 ms DRT
    _OSC_HS EQU 0x0FFA; HS oscillator and 18 ms DRT
    _HS_OSC EQU 0x0FFA; HS oscillator and 18 ms DRT
    _OSC_EC EQU 0x0FFB; EC Osc With RB4 and 1.125 ms DRT
    _EC_OSC EQU 0x0FFB; EC Osc With RB4 and 1.125 ms DRT
    _OSC_IntRC_RB4EN EQU 0x0FFC; INTRC With RB4 and 1.125 ms DRT
    _IntRC_OSC_RB4EN EQU 0x0FFC; INTRC With RB4 and 1.125 ms DRT
    _OSC_IntRC_CLKOUTEN EQU 0x0FFD; INTRC With CLKOUT and 1.125 ms DRT
    _IntRC_OSC_CLKOUTEN EQU 0x0FFD; INTRC With CLKOUT and 1.125 ms DRT
    _OSC_ExtRC_RB4EN EQU 0x0FFE; EXTRC With RB4 and 1.125 ms DRT
    _ExtRC_OSC_RB4EN EQU 0x0FFE; EXTRC With RB4 and 1.125 ms DRT
    _OSC_ExtRC_CLKOUTEN EQU 0x0FFF; EXTRC With CLKOUT and 1.125 ms DRT
    _ExtRC_OSC_CLKOUTEN EQU 0x0FFF; EXTRC With CLKOUT and 1.125 ms DRT
    _WDT_OFF EQU 0x0FF7; WDT disabled
    _WDT_ON EQU 0x0FFF; WDT enabled_CP_ON EQU 0x0FEF; Code protection on
    _CP_OFF EQU 0x0FFF; Code protection off
    _MCLRE_OFF EQU 0x0FDF; RB3/MCLR pin functions as RB3, MCLR tied internally to VDD
    _MCLRE_ON EQU 0x0FFF; RB3/MCLR pin functions as MCLR
    _IOSCFS_OFF EQU 0x0FBF; 4 MHz INTOSC Speed
    _IOSCFS_ON EQU 0x0FFF; 8 MHz INTOSC Speed
    __CONFIG macro value
    psect config
    org 0x0
    dw value
    endm

     
    post edited by danish.ali - 2020/03/12 02:09:44

    Attached Image(s)

    #6
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/12 03:15:34 (permalink)
    0
    danish.ali
     
    When I launch MPLAB IDE 5.35, I get a warning for a project that only uses MPASM:
    Output - Configuration Loading Error
    MPASM is not supported on 64 bit Operating Systems. Please consider migrating your project "Mk8B_MPLabX" configuration "default" to XC8 Assembler or continue to use a previously released IDE.

    I have never seen that warning before, and I'm running Windows 10 64-bit Operating System on x64-based processor for years.
     
    #7
    BMD
    Super Member
    • Total Posts : 445
    • Reward points : 0
    • Joined: 2003/12/02 21:42:52
    • Location: UK
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/15 00:55:02 (permalink)
    0
    Hi,
    Yes, since I downloaded 5.35 I have been getting that message too.
    So far I have ignored it, and haven't encountered any problems. But I guess at some point things will fall over and I'll have to follow the instruction.
    I was perturbed by a comment earlier that XC8 Assembly was inferior to mpasm, is this true?

    Regards

    Brandon
    #8
    mpgmike
    Super Member
    • Total Posts : 449
    • Reward points : 0
    • Joined: 2014/01/23 17:27:06
    • Location: NJ
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/15 04:34:59 (permalink)
    0
    BMD
    I was perturbed by a comment earlier that XC8 Assembly was inferior to mpasm, is this true?

    I guess it might be like asking is a monkey superior to a fish?  Both have strengths.  I find that for most things I default to XC8, but occasionally use ASM for speed or memory reasons.

    I don't need the world to know my name, but I want to live a life so all my great-grandchildren proudly remember me.
    #9
    NorthGuy
    Super Member
    • Total Posts : 6228
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/15 05:52:07 (permalink)
    5 (1)
    If your OS is Windows, I don't think they'd drop 32-bit support any time soon. If you build .NET applications, the default for extraneous library is still 32-bit.
     
    If your OS is Linux, installing 32-bit support is not a problem.
     
    But, of course, there is ARM, and then RISC-V on the horizon. Nobody knows.
    #10
    LdB_ECM
    Super Member
    • Total Posts : 406
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/16 04:39:33 (permalink)
    0
    The microsoft lifecycles are already locked in
    https://support.microsoft.com/en-au/help/13853/windows-lifecycle-fact-sheet
     
    Windows7 support stopped in January this year, Windows 8.1 stops in 2023 and after that there is no longer any 32bit windows beyond that. Many of the early 32bit versions of Windows 10 also ends this year.
     
    The 64bit Windows will still shim emulation of 32 bit for some time after but it will be hit and miss in exactly the same way as Win95 and Windows XP support slowly died away. 
     
    Microchip is simply stating the obvious  they will not be able to support 32bit going forward on windows and it is completely outside there control. Whether MPLAB will be able to continue to be used going forward is simply outside there control it depends how much Microsoft bother to shim the emulation.
     
    #11
    ric
    Super Member
    • Total Posts : 28004
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/16 05:05:36 (permalink)
    5 (4)
    None of that explains why Microchip can't just do a 64 bit build of MPASM.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/16 07:31:09 (permalink)
    5 (1)
    ric
    None of that explains why Microchip can't just do a 64 bit build of MPASM.

    That's what I was thinking, too.  In fact, they should replace both ASPIC and ASPIC18 with MPASM going forward!!!
     
     
    post edited by 1and0 - 2020/03/16 07:33:43
    #13
    LdB_ECM
    Super Member
    • Total Posts : 406
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/16 09:21:34 (permalink)
    0
    They could but they have told you they aren't  :-)
     
    Personally they would be better off just migrating XC-8 over to gcc like XC-16, XC-32 and then you can just use gcc assembler and a simple debugger stub like the majority do. The question is how many of the old tiny device do you really want to support.
     
    You can use any IDE you want and any debugger hardware you like.
    post edited by LdB_ECM - 2020/03/16 09:25:54
    #14
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/17 01:24:15 (permalink)
    5 (4)
    LdB_ECM
    They could but they have told you they aren't  :-)

    That would be an ENORMOUS blunder on so many levels if they do that; it'll be another gross and stupid mistake to add to the misery. Discontinuing MPASM will mean Microchip will have to update *ALL* the assembly source code in thousands of PIC10/12/16/18 MCU datasheets, application notes, technical briefs, code templates, and so on; which IMO is a massive task than building a 64-bit MPASM assembler.
     
     
     

    Attached Image(s)

    #15
    Jerry Messina
    Super Member
    • Total Posts : 539
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/17 06:37:55 (permalink)
    0
    That would be an ENORMOUS blunder on so many levels if they do that

    Couldn't agree more...
     
     
    #16
    Mark1024
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2019/11/07 08:52:58
    • Location: 0
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/19 12:28:54 (permalink)
    0
    I second that, I've been writing PIC programs since the n-channel days in the early 80's, when General Instruments were in charge and have a huge legacy of programs, a few of which still need occasional modifications.  I tried using C when it first became available but spent more time fighting the compiler bugs than I did writing code.  The only reason I'm trying MPLAB X rather than my trustworthy MPLAB V8.92 is that I've got a project that needs an NCO which isn't available on any of the older parts it supports.
    #17
    danish.ali
    Super Member
    • Total Posts : 1721
    • Reward points : 0
    • Joined: 2004/11/16 02:02:02
    • Location: Surrey, UK
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/23 07:59:24 (permalink)
    5 (1)
    I've now got things to build and even get the same checksum. But it was a battle, and I don't find the XC8-ASPIC assembly code nearly as easy as MPASM.
    A lot of the problems are down to a lack of documentation. In the end I took a copy of the startup.s generated for C code and hacked that.
    But it also seems badly thought through:
    • If blocks merely turning off the generation of code, not the declaration of symbols (so you can't use an if-block to choose what value a symbol has or even if it is present).
    • Only bitwise operators | & - not the "logical" ones || &&
    • The equality-test operator returns 1. So not (a eq b) will always be non-zero!
    #18
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/24 12:39:00 (permalink)
    0
    Stupid forum won't let me post the following posts together in one post. :(
     
    Here are the ASPIC Operators:
     

    Attached Image(s)

    #19
    1and0
    Access is Denied
    • Total Posts : 10999
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Porting MPASM assembly to XC8 2020/03/24 12:42:29 (permalink)
    0
    Here are the MPASM Operators:

     
     
     

    Attached Image(s)

    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2020 APG vNext Commercial Version 4.5