support added for K40 devices
Moderators: David Barker, Jerry Messina
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
support added for K40 devices
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)
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)
Last edited by Jerry Messina on Wed Jan 11, 2017 11:51 am, edited 6 times in total.
Reason: update for 18LF devices; K40 eeprom;K40 pps errata
Reason: update for 18LF devices; K40 eeprom;K40 pps errata
Re: support added for K40 devices
That's nice work. thank you Jerry
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: support added for K40 devices
Thanks Jerry...
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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...
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...
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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)
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)
- Attachments
-
- uk-co-mecanique-swordfishbasictoolchain.zip
- (37.95 KiB) Downloaded 229 times
Re: support added for K40 devices
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
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
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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.There are a lot of "LF" versions missing
How do you do it now? Would adding the LF make it easier?
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.I wonder how many people are using last version of MPLabX (3.4) with the plugin
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.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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.
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 like
Code: Select all
program version: 1.3.0.0
mpasm path: D:\MPASM SUITES\MPASMX_568_IDE_X335_X340
resource file version: V1.31
number of devices: 414
device list:
18F1220
18F1230
18F1320
18F1330
18F13K22
.....
18LF8680
18LF8720
18LF8722
18LF8723
Re: support added for K40 devices
Thanks for all this Jerry, I can confirm that I have a 18F27K40 working nicely.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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.
I went ahead and moved/added the new files to the wiki (see post #1 for links). The ConfigGenerator now supports 18LF as well.
Re: support added for K40 devices
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
I'll check the converter and will try to dedicate some more time to the plugin.
Regards
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: support added for K40 devices
> you have been extremely generous with SF community.
I wholeheartedly second that!!
I wholeheartedly second that!!
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: support added for K40 devices
> ...dedicate some more time to the plugin
That would be fantastic!
That would be fantastic!
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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.
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.
- Attachments
-
- SystemConvert_v131.jpg (35.42 KiB) Viewed 7384 times
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: support added for K40 devices
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!!!
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.
Code: Select all
#const _eeprom_start = $310000 // EEPROM start address
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!!!
Last edited by Jerry Messina on Tue Jan 03, 2017 12:30 pm, edited 2 times in total.
Reason: updated first post with links for SystemConvert v1.32 that addresses this issue
Reason: updated first post with links for SystemConvert v1.32 that addresses this issue