Swordfish

Microchip recently released the 18FxxK40 family of devices.

I've updated various files/programs to add support:
SystemConvert V1.32
ConfigGenerator V1.31
SetDigitalIO V2.2
PPS module V1.41
These devices require mpasmx from MPLABX to compile (see the SystemConvert wiki page for instructions)

That's nice work. thank you Jerry

Thanks Jerry...

No problem.

The K40 brings in some of the newer Core Independent Peripherals from the 16F1xxxx like a Zero-Cross Detector, DSM and PPS.
The ADC has some neat features like built-in averaging and low-pass filtering.

I think it's also the first 28-pin chip with 128K of flash that runs @ 5V (there were a few J series devices, but they're 3V3).

One thing to note - if you use ICD debugging then you're stuck with MPLABX. Come to think of it, you're probably stuck with it anyway (or the X IPE) just to get the thing programmed.
I'll have to get some samples and play around...

For anyone wanting to try this in mplabx you'll have to modify octal's mplabx swordfish plug-in.

Here's an updated version of the plugin that changes the list of supported devices to be in line with the
251 devices files generated with SystemConvert v1.22 and mpasmx 5.68 (the converted device files are in the zip file
at the bottom of the SystemConvert wiki page)

Instructions to update the plugin are in the readme.txt (you have to install the plugin first)

Thank you Jerry, this is very helpful.
I'll take time to update the whole plugin and add full list of PIC chips. There are a lot of "LF" versions missing, and if you use MPLabX (like I do) with realIce or ICD3 you won't be able to do hardware debug (or flash) via MPLabX if your circuit uses an LF chip.

btw. I wonder how many people are using last version of MPLabX (3.4) with the plugin

There are a lot of "LF" versions missing

Yes, I removed all of them from the list since the compiler doesn't really support compiling for an "LF" and doesn't really care. I could always change that if you like... perhaps add an "LF" checkbox to the SystemConvert utility (??). That way it could generate all the files and you wouldn't have to switch/modify anything.

How do you do it now? Would adding the LF make it easier?

I wonder how many people are using last version of MPLabX (3.4) with the plugin

I don't know about how many, but I only use it as a last resort when the chip isn't supported by MPLAB 8.92. For me, MPLABX has some serious issues talking with the devtools. It's not reliable for me at all, and I've tried all the versions of MPLABX, multiple PK3's, ICD3's, and RealIce units on four different computers and various OS's.

Microchip haven't been able to replicate it, but from reading the forum over there it happens to a number of other people as well. Maybe one day they'll get it fixed, but I'm not holding my breath.

Well, changing the convert utility to add 18LF devices was so trivial I went ahead and did it (see wiki page in post #1).

There's a new 'Include 18LF' checkbox... just check it before pressing 'Get Candidates' and it'll generate both 18F and 18LF files. That part works fine, and you can now use 'device = 18LFxxxx' and SF compiles ok.
BUT BEWARE... there are a number of system library files that check for specific devices and those will require modifying to match the LF devices.

octal - a useful feature is the log file. When you create the files the program generates a '_devices.txt' log in the NewIncludeBASIC folder.
It has the names of all the files created, and looks something likeThis list can be used to find out what versions of MPASM(x) support what devices. That's what I used when I patched the MPLABX plugin.

Thanks for all this Jerry, I can confirm that I have a 18F27K40 working nicely.

Glad to hear it. I keep meaning to get some samples and try it out...

I went ahead and moved/added the new files to the wiki (see post #1 for links). The ConfigGenerator now supports 18LF as well.

Thank you very much for this update Jerry, you have been extremely generous with SF community.
I'll check the converter and will try to dedicate some more time to the plugin.

Regards

> you have been extremely generous with SF community.

I wholeheartedly second that!!

> ...dedicate some more time to the plugin

That would be fantastic!

With the release of MPLABX 3.50/MPASMX 5.71, I made a minor change to the SystemConvert utility.

There's new checkbox that lets you generate an XML-based logfile instead of the plain .txt format.
This makes it a bit easier to hack the files of octal's MPLABX plugin to add new devices.

MPASMX 5.71 includes a few files for the upcoming 18FxxK42 family which have a number of new features, including 8K of RAM,
multi-vector interrupts, and a bunch of new peripherals. No real datasheets yet... just a bunch of product briefs so it'll
be interesting to see how this all works out.

Hopefully they'll appear faster than the K40 family took.

grrr...

It seems there's an issue with the K40 device files and EEPROM support.

In the past EEPROM data was specified in the hex file starting at location $F00000, which is way outside the normal program address range. It's specified in all the programming documents for the chips this way, and it's been like this for all PIC18 devices.

Accessing EEPROM (NVM) in the K40 devices is slightly different than before, so in typical Microchip fashion it appears that they have moved the start address of EEPROM data in the hex file for the K40 (and K42) to $310000. This doesn't match the programming documents, but it appears all the mplabx tools generate/look for it there, including xc8, mplabx and the x ipe.

Luckily, Swordfish can cope with this... there's a setting in the device file for the EEPROM start address so all you have to do is change it to match. Unfortunately, this information doesn't seem to be anywhere in the mpasm 8bit_device.info file database that I've been using to generate the device files from. It seems to come from the individual mpasmx device linker *.lkr files. So, I'll either have to hard-code it into the systemconvert app or start looking at the linker files too. That's a bit of a shame since I had been able to simplify the app to just using a single file for all the info (David's original version looked at a few different files, some of which are no longer available in mplabx/mpasmx).

I may just hard-code it in. With my luck If I change it then Microchip will probably change the .lkr files too!
For the time being, just change the device .bas file as shown above.

Oh, and Happy New Year!!!