Adding the Enhanced Mid-range PIC16F15213 through PIC16F15276 ?

[trastikata]

Hello Les,

just noticed that some Enhanced Mid-range 16F PICs, which would fit well in one of my projects, to my surprise are supported. Any chance of adding the PIC16F152xx (PIC16F15213 through PIC16F15276) with the next upgrade?

Regards

[tumbleweed]

Those devices are not supported in mpasm 5.87 (aka mpasmwin.exe), so unless/until the assembler is changed they won't be available.
 

[top204]

Those devices are not supported in mpasm 5.87 (aka mpasmwin.exe)

That is what i am currently working on for the new 18F devices and the new enhanced 14-bit core devices. However, the different assembler is absolutely dreadful! and creates none of the files that the compiler requires for its optimisers, and the .lst file seems like an afterthought and is an abomination, with so much missing!! So I am having to re-create the .lst file from the mess it creates so the optimisers will work and the COFF maker will work on them.

Change for the sake of change and no other reason whatsoever, because the new devices are "exactly" the same as the previous devices that were supported in Mpasm!!! I wish they would release the source for Mpasm or, at least, the format of the data file for the supported devices, so new devices could be added by users instead of being forced to use ther "dreadful" new assembler, which is actually the dreadful assembler used by the old High-Tech C compiler 20 years ago, that they bought for their devices. Back then it was dreadful as well. :-)

After quite a few months of work, I have the compiler working for the new devices, and creating HEX files, but I will not release it as an "upgrade" until I have the optimisers working fully as well.

[tumbleweed]

I agree, there are lots of people complaining about the PIC-ASs assembler (I added the extra letter they forgot).
They abandoned MPASM when they switched to all 64-bit tools since it was 32-bit only and they couldn't port it.

I have the modified info file for MPASM that works with the new PIC18 devices, but not for the PIC16.
The Swordfish compiler added support for these a while back, and it works with them (Q83/84, Q40/41, etc).

If I get a chance I'll see if I can figure out the PIC16, although if you already have stuff working with PIC-AS it's sort of a moot point.
 

[top204]

I added the newer Q83/84, Q40/41 devices to the Positron compilers a couple of years ago, and the new Q16 devices are the same as those, so there was no reason for changing the assembler. The swordfish compiler handles the original Q devices because I wrote the backend for it, so it uses the mechanisms that were in the earlier Proton compilers, and uses the .lst file for the optimiser, and once assembled, converts the .lst file into a nice and tidy assembler file with all the conditions removed. Just as Proton did and now Positron does. That's why I am having to re-construct the .lst file from the mess left over by the latest assembler, because it is so utterly dreadful and has so much missing, it may as well not be there! It even places address values instead of variable or SFR names in its assembler listing!! The whole point of the .lst file is to see the code once the assembler and its preprocessor have finished with it, so it can be used for debugging the code etc...

The Mpasm assembler is written in C++, so it could have easily been re-compiled using a 64-bit compiler to give it a header for 64-bit, and 64-bit means nothing because it is not using any 64-bit architecture inside it. It is just these idiots that do not live in the real world, that they get in as third-party, and have been told at uni "do this, do that, do as I do, regardless of what you think", that think it needs 64-bit!!! :-) But even then, they simply re-compiled an old assembler that is worse than Mpasm!!! It just does not make sense.

32-bit programs will happily run in 64-bit operating systems, as has been shown for the past 10 years or so.

[top204]

I have been looking further into the "8bit_device.info" file for the Mpasm assembler, and I have managed to add one of the 18F16Q devices to it. :-) But I do not quite understand the offset hex values in the "<PARTS_INDEX_TYPE>" sections. Any ideas?

[tumbleweed]

The <PARTS_INDEX_TYPE> entry identifies the device name and the .info file offset (in bytes) of the <PART_INFO_TYPE> for that device.
Each PARTS_INDEX_TYPE line must be 52 chars in length (50+CRLF), so they are padded with '###' chars

For example the line

Code Select Expand

<PARTS_INDEX_TYPE><18F16Q41><427d40>#############

means that you'll find the entry:

Code Select Expand

<PART_INFO_TYPE><a30c><PIC18F16Q41><18XVxx><6><1><ffff><40><ff><3ff><500-55f><460-4ff><0><9>
at file offset 0x427d40 (4357440 dec)

The .xml file is only used by MPLABX to identify which devices the mpasm build tool supports...
you only need to change the .info file to add support for the standalone mpasm to work.

[tumbleweed]

... and there's one other restriction I forgot to mention.

The mpasmx.exe program only supports a max of up to 16 CONFIG register entries. Even though the default .info file from 5.87 may include more, if you actually try to use them mpasm blows up.

This effects the 18FxxQ83 and Q84 parts, as they have 35 CONFIG registers. They were the last parts added by microchip, and obviously they never tested this.

The V1.60 .info resource file redefines these extra registers as a different type (<XCONFIGREG_INFO_TYPE>), and you have to come up with a way of supporting them since the new XCONFIGREG_INFO_TYPE is ignored by mpasm. At least it assembles now.

[top204]

I've gone through the scenario of altering teh mpasm assembler for the new devices and decided not too, for several reasons.

New devices may bring in new mnemonics, as has occured with some of the newer devices, such as movffl, subfsr, addfsr etc, and mpasm recognises them, but now that it is no longer updated, new mnemonics will not be recognised and so the compiler cannot create better assembler code.

Also, new memory areas are being created with the new devices and the mpasm assembler will not recognise them because it is no longer updated.

My method of using the new assembler is the better option because it is future proof.

Thanks for you input tumbleweed. I also read the microchip forum sometimes, because true assembler code writers really do not like the new assembler program, and I can't blame then. However, do not take what is said on that forum too literally! It is full of people who state to be experts, but definately are not, and some of the rubbish advice from it is dreadful. There are some really good programmers on there, but you have to sift them out. LOL

There may be a limit to the CONFIGs, but it is not 16. Take a look at the bottom of the compiler's newer 18F device .ppi files and you will see the default fuses, such as:

Code Select Expand

ifdef WATCHDOG_REQ
    CONFIG WDTE = ON            ; WDT Enabled; SWDTEN is ignored
else
    CONFIG WDTE = OFF           ; WDT Disabled; SWDTEN is ignored
endif
ifdef PLL_REQ
    CONFIG RSTOSC = EXTOSC_4PLL ; EXTOSC with 4x PLL, with EXTOSC operating per FEXTOSC Bits
else
    CONFIG RSTOSC = EXTOSC ; EXTOSC operating per FEXTOSC Bits (device manufacturing default)
endif
    CONFIG FEXTOSC = HS         ; HS (crystal oscillator) above 8 MHz; PFM set to high power
    CONFIG CLKOUTEN = OFF       ; CLKOUT function is disabled
    CONFIG PR1WAY = OFF         ; PRLOCK bit can be set and cleared repeatedly
    CONFIG CSWEN = ON           ; Writing to NOSC and NDIV is allowed
    CONFIG DEBUG = OFF          ; Background debugger disabled
    CONFIG FCMEN = OFF          ; Fail-Safe Clock Monitor disabled
    CONFIG MCLRE = EXTMCLR      ; If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR
    CONFIG PWRTS = PWRT_OFF     ; PWRT is disabled
ifdef __VCTR_ISR__REQ__         ; Use Vectored Interrupts?
    CONFIG MVECEN = ON          ; Yes. So Interrupt contoller uses vector table to prioritise interrupts
else
    CONFIG MVECEN = OFF         ; No. So Interrupt contoller does not use vector table to prioritise interrupts
endif
    CONFIG IVT1WAY = OFF        ; IVTLOCK bit can be cleared and set repeatedly
    CONFIG LPBOREN = OFF        ; ULPBOR disabled
    CONFIG BOREN = OFF          ; Brown-out Reset disabled
    CONFIG BORV = VBOR_2P45     ; Brown-out Reset Voltage (VBOR) set to 2.45V
    CONFIG ZCD = OFF            ; ZCD disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON
    CONFIG PPS1WAY = OFF        ; PPSLOCK bit can be set and cleared repeatedly (subject to the unlock sequence)
    CONFIG STVREN = OFF         ; Stack full/underflow will not cause Reset
    CONFIG XINST = OFF          ; Extended Instruction Set and Indexed Addressing Mode disabled
    CONFIG WDTCPS = WDTCPS_2    ; Divider ratio 1:128
    CONFIG WDTCWS = WDTCWS_0    ; Window delay = 87.5; no software control; keyed access required
    CONFIG WDTCCS = LFINTOSC    ; WDT reference clock is the 31.0 kHz LFINTOSC
    CONFIG BBSIZE = BBSIZE_1024 ; Boot Block size is 1024 words
    CONFIG BBEN = OFF           ; Boot block disabled
    CONFIG SAFEN = OFF          ; SAF disabled
    CONFIG WRTAPP = OFF         ; Application Block not write protected
    CONFIG WRTB = OFF           ; Configuration registers (300000-30000Bh) not write-protected
    CONFIG WRTC = OFF           ; Boot Block (000000-0007FFh) not write-protected
    CONFIG WRTD = OFF           ; Data EEPROM not write-protected
    CONFIG WRTSAF = OFF         ; SAF not Write Protected
    CONFIG LVP = OFF            ; HV on MCLR/VPP must be used for programming
    CONFIG CP = OFF             ; PFM and Data EEPROM code protection disabled
endif

With all the above configs from a PIC18F26Q43 device, it has never given an error, and the fuses are set appropriately according to a device programmer. The amount of configs supported is the last value of the device's data within the .info file.

[tumbleweed]

My method of using the new assembler is the better option because it is future proof.

At least until they change it again! But you're right, if you can get PIC-AS to work it's probably a better choice.

The memory layouts are described in the .info file so that's not so much of an issue as much as the possibility that they add new asm instructions. If/when they did that then mpasm couldn't handle it.

As far as the CONFIG statements, what I meant is that mpasm can only handle 16 config register locations, not 16 individual config statements. The config registers are the ones described by the <CONFIGREG_INFO_TYPE> statements that specify the location, default setting, and how many functions (ie individual CONFIG) in each register.

So far, this only comes into play for the 18FxxQ83/Q84.