Supporting Lastest PICs

[Senacharim]

Hi!
My company is looking at updating both the software we use for PIC dev (to Swordfish, yay!) and the PICs we use, from 18F2620 to 18F26K22.

I notice the latter is not a recognized device in the IDE and must query as to what kind of timing can be expected from new parts being released to when they're supported in Swordfish.

Thanks in advance.

[CharlieM]

Hi Senacharim,

Before your company takes the plunge take a look at this thread.

http://www.sfcompiler.co.uk/forum/viewtopic.php?t=1266

It seems that Sf is at the end of its life.

[Jon Chandler]

Sadly, support for Swordfish has been nonexistent for a while. We're hoping for a glorious return of David but those hopes are fading.

The good news is that there is support for more recent parts. The include files are here:

http://www.sfcompiler.co.uk/wiki/upload ... Series.zip

[CharlieM]

Jon,

the 18F26K22 is not one of them.

[Senacharim]

Alrighty, thanks for the tip.

I notice the PIC configuration seems to be just a list of named constants which coincide with the Name && Address of control registers listed on the data sheet, as well as a few compiler defines for various features (ram, usb, et al).

In a pinch, I'm sure I could whip up such a thing for the latest PICs, as all of the requisite information is available.

Is there somewhere I might find instructions for doing so?

Or, better yet, is there any particular community effort for the maintenance of such that I might join?

[octal]

Hello Senacharim

include files for new chips were build based directly on *.dev files that comes from MPLab from Microchip. All compilers vendors make converters to these files to simply generate includes to their compilers. *.dev files contain all needed stuff (regs names and adr).

Regards

[Jerry Messina]

Because of the open nature of SF, adding support for new processors isn't that difficult.
I've done it for a few of them, and these are the basic steps I use, with the 18F26K22 as an example:

First, get a copy of MPASM that supports your processor. You can get this from the latest MPLAB download. When you install it, all you really need is MPASM and perhaps whatever programmer/debugger support you want. From the install directory (typ C:\Program Files\Microchip), look in the 'MPASM Suite' dir and locate the asm INC file for the processor you want (ie P18F26K22.INC). This file has pretty much everything you'll need. The rest of the info (ram, rom, etc) you can get from the device datasheet.

SF uses it's own copy of MPASM, and not the one in the mchip directory. Copy the file 'MPASM Suite\MPASMWIN.EXE', and place it in the <SF install>\bin dir. You may want to rename the existing one first so you can restore it. I keep bunch of different versions, for reasons I'll discuss later. Note: if you ever do an online update, it'll overwrite your new mpasmwin.exe if you let it.

SF needs two files to support a new device... an asm INC file (ie P18F26K22.INC) and a BAS file (18F26K22.BAS). These need to be located in the <SF install>\Includes dir. If you can find a similar device that SF already supports, you can use those files as a starting point.

Note that even though the asm INC files are the same name, they're different. The SF P18F26K22.INC file is a cut-down version of the MPASM one. From the MPASM file, you need the 'Register Definitions' section that has the SFR register addresses, and the SFR bit definitions. SF reformats these slightly, so a good text editor helps a greate deal. Otherwise, the only real changes you need to make is to add definitions for the '16-bit' registers. For example, the standard INC file defines FSR0L and FSR0H. In addition to these, SF wants a new one, FSR0LH. There are a number of these, and it varies chip to chip. Don't worry too much about catching the odd-ball ones... if you miss it you should get an error message like 'Symbol not previously defined(FSR0LH)' when you compile, and you know which one to add.

Now for the 18F26K22.BAS file...

You need to create/modify the 'System header' section that describes the device resources. The important ones here are the memory layout. There's no real documentation on this section, but if you compare a few, you can see what's required. This info can be gotten from the device datasheet. Add in the SFR definitions, and the register bit definitions, and you're almost done. The only thing remaining is the configuration fuses, which you can get from the original MPASM INC file. The INC file usually has two sets of these, the old __CONFIG directive style, and the newer CONFIG style definitions that are in the file as comments. The SF 'public config' statement relates to the newer CONFIG style, and you can get the SF settings directly from the INC file comments. Unlike the old __CONFIG directive where you can define each individual bit, support for the CONFIG definitions is built into MPASM, and can't be changed (at least not that I've found). That's one of the reasons you need a version of MPASM that supports your device. While the newer CONFIG style is simpler and a lot less error-prone, MPASM only exposes certain settings, which can be an issue (see the thread on the missing DEBUG bit http://www.sfcompiler.co.uk/forum/viewtopic.php?t=1282).

You should now have the ability to add 'device=18F26K22' to your main bas file. One thing to watch out for, and that's the SF libraries. There's a good chance that the new device you're adding isn't 100% compatible with some of the existing library code, and you'll have to make some changes. For example, the uart lib has a function to set the baud rate that assumes that the two registers making up the 16-bit BRG register are contiguous in memory, and on some chips they're not.

If you want to debug under MPLAB, you'll have to check and see what debugger supports your device. Sadly, the pickit2 is becoming less and less supported, so you may have to switch to the pickit3/ICD3. There's a way of adding support to the pickit2 standalone programming app using a device file editor, but this doesn't help with MPLAB.

Some notes on MPASM:
Beginning with MPASM V5.3x, mchip started changing the way MPASM works. MPASM now really wants to work with relocatable code (where you use a linker), but SF produces a single non-relocatable absolute file. This still works fine, but V5.3x is MUCH slower to assemble a file compared to previous versions (like 5.11 or 5.22). You might not notice this on small projects, but for larger projects the slowdown is significant. I have a rather large program that takes ~30 seconds to compile using v5.22. That same program takes over 2:30 using mpasm 5.36! Also, they changed the command-line switches, so the default operation is a bit different. Normally, with SF and mpasm <5.3, when you compile you get a sequence of status windows as it goes through the 'compiling'->mpasm->'optimizing'->mpasm phases. With MPASM > 5.3x, you no longer get the status box displayed as it assembles, so it can seem like nothing's going on. Mchip finally added this feature back in, but it requires a new command-line switch not currently supported by SF. This is pretty annoying, and when I get a chance I think I'll write a little app to fix this behaviour.

Jerry

[Francis]

Superb Jerry. Thank you.

[Senacharim]

Indeed, superb. Thank you.
: )

[Jerry Messina]

thanks.

A few other notes/tips/things to watch out for...

I mentioned that you need to create 'xxxxLH' definitions for the 16-bit registers in the SF asm INC file.
The easiest way to find out which ones you need is to use the mplab .DEV file for the device, which is found in the '<mchip install>\MPLAB IDE\Device' dir (the one Octal was talking about).
If you search through the 'Special Function Registers' section for 'size=2', these are the ones you need to add.

PIC18F26K22.dev

Code: Select all

sfr (key=FSR0 addr=0xfe9 size=2 flags=j)
    bit (names='- - - - FSR0' width='1 1 1 1 12')
sfr (key=FSR0L addr=0xfe9 size=1 access='rw rw rw rw rw rw rw rw')
    reset (por='xxxxxxxx' mclr='uuuuuuuu')
    bit (names='FSR0L' width='8')
    stimulus (scl=rwb pcfiles=rw regfiles=w)
sfr (key=FSR0H addr=0xfea size=1 access='u u u u rw rw rw rw')
    reset (por='----0000' mclr='----uuuu')
    bit (names='- - - - FSR0H' width='1 1 1 1 4')
    stimulus (scl=rwb pcfiles=rw regfiles=w)

You need to add a 'xxxxLH' definition using the addr of the 'H' register, like

Code: Select all

FSR0L            EQU 0x0FE9
FSR0LH           EQU 0x0FEA
FSR0H            EQU 0x0FEA

#variable _maxrom
On most parts, the configuration words are located in a separate area from the 'normal' program flash. However, on some parts (such as the 'J' series) this isn't the case, and the config words are at the end of the program memory space, and you need to reserve that.

For example, the 18F46J50 is a 64K part, so you'd be inclined to say

Code: Select all

	#variable _maxrom = $010000 		// 64 KB of program ROM

but the config words are located at $FFF8-FFFF, so you need

Code: Select all

	#variable _maxrom = $00FFF8         // 63 KB of program ROM

#variable _maxram
This can get a little tricky sometimes. SF can only deal with allocating ram in one contiguous block. On some parts, the peripherals (like USB, Ethernet, and CAN) use parts of the data space as buffers/registers, and if you use the peripheral you need to reserve that space (otherwise, if you don't, you can sometimes use it as more general purpose ram). Some brain-dead parts put this 'reserved' block smack dab in the middle of the ram space (like the 18F46J50 USB BDT), while others have it disjointed from the regular ram space (like the 18F13K50) so you can't use it normally. In any case, you can't necessarily pay attention to the 'this device has 4K of data ram' that the datasheet says. While it may be true, SF probably can't use it all. You need to look at the Data Memory Organization section of the device datasheet and set the '#variable _maxram' to the highest address of contiguous ram below that special area.

Then use statements like

Code: Select all

	dim usb_bdt(256) as byte absolute $0B00

to locate the reserved areas. This makes the remaining ram space unavailable to SF unless you manage it yourself like

Code: Select all

	dim my_buffer(256) as byte absolute $0C00
	dim my_data as byte absolute $0D00

and so on. Or, you could look for a different device. Microchip is all over the map with how they handle this stuff, and it's never the same chip to chip it seems.

PS - watch out if you use any of the beta 'K' series files... there's a lot of mistakes/things that don't match up to the current documentation in them. RKP did a lot of work here...search for some of his posts.

[Jerry Messina]

I posted a program to 'fix' the mpasm 5.3x status box issue over on http://digital-diy.com/forum/viewtopic.php?f=12&t=593

Jerry

[David Barker]

This may help some people:

http://www.sfcompiler.co.uk/wiki/pmwiki ... temConvert

It's a little piece of software to automatically generate include files for Swordfish. Note that it is supplied 'as is'. However, if it works for you it should provide a good starting point.