MPLAB-X Plugin...

Discuss the Integrated Development Environment (IDE)

Moderators: David Barker, Jerry Messina

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

MPLAB-X Plugin...

Post by David Barker » Sat Jan 24, 2015 11:08 am

I've been playing around with MPLAB-X for a few days now and it appears to be a very usable IDE now, especially when compared to MPLAB. Unfortunately, installing a new compiler under MPLAB-X is not as easy (by a long way) as it was under MPLAB, but offers considerable advantages. You basically have to write a plugin for MPLAB-X using the MPLAB-X SDK.

http://www.opensource4pic.org/content/c ... -x-ide-230

If the above is not available, you can try here
http://www.firewing.info/downloads/sdk/

There is an example project and documentation in the above download that shows how to create a compiler plugin for MPLAB-X, so you would not be starting completely from scratch.

Is there anyone who could help out in this respect? If you can, or know anyone else who can, then please do get in touch...

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Sat Jan 24, 2015 1:18 pm

That's probably a good idea since MPLAB8 is a dead-end w.r.t supporting new devices. MPLAB-X does seem to be getting better, so maybe they'll have more of it straightened out before it's MPLAB-XI.

I'll gladly help however I can, but my java skills are pretty limited. Right now I'm having a problem even connecting to the opensource4pic site.

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: MPLAB-X Plugin...

Post by David Barker » Sat Jan 24, 2015 3:51 pm

Bah! It was available this morning! I've added an alternative link to the original post...

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Tue Jan 27, 2015 2:53 pm

The official link is available again :)

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Tue Jan 27, 2015 9:01 pm

Hello,
well, I have started the integration of Swordfish BASIC compiler under MPLabX.
I wrote initial plugin module, with needed XML files to let the makefile-writer to generate the needed makefile for MPLabX to compile SF projects. Integration in MPLabX help engine is also functionnal and all needed support written.

First results:
1- Sworfish BASIC compiler is showing as a toolchain in the Embedded tab of Tools::Option menu of MPLabX :)
2- when you create a new project or select an existing project, and select one of the processors supported by Swordfish BASIC (I took the list of supported processors from SF website), you'll see the Sworfish BASIC toolchain listed and selectable among the other Microchip toolchains (demo versions of XC8 and C18 installed in the case of my PC).

See screenshots at the end of this post.

The missing things I'm aware of:
1- I have to complete and correct the writer-rules in order to produce a correct makefile. I have to figure out how to ask SF compiler to compile the "main" file that needs to have the same name as the project with ".bas" extension. This will make it possible to ask for compile, build or debug without having to select, each time, the main file of the project. It's a bit difficult to fiddle with predefined variables and some stupid aspects of the mplab xml schema (desribed in the mplab XML Schema User's Guide document in sdk doc - long doc to read indeed).
2- I have to create a plugin module to associate and completely register the *.bas files with a text editor. Later, when the toochain will be fully integrated, I'll add a plugin that extends the text editor to support SF syntax highlighting (code completion will need to write an incremental parser).

here are first screenshots.
Attachments
toolsoptionstoolchain.png
toolsoptionstoolchain.png (71.17 KiB) Viewed 26787 times
projectproperties.png
projectproperties.png (57.06 KiB) Viewed 26799 times
projectwizard.png
projectwizard.png (116.58 KiB) Viewed 26799 times
Last edited by octal on Wed Jan 28, 2015 12:03 am, edited 1 time in total.

User avatar
Coccoliso
Posts: 152
Joined: Mon Feb 17, 2014 10:34 am

Re: MPLAB-X Plugin...

Post by Coccoliso » Tue Jan 27, 2015 10:33 pm

Excellent great result! :wink:

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Wed Jan 28, 2015 9:45 am

Great job so far.

I haven't even been able to finish reading the documentation yet, much less make sense out of it! It's good to have somebody around who knows what they're doing.

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Wed Jan 28, 2015 9:28 pm

Hi Jerry, Coccoliso
thank you for you encouraging messages.
@Jerry
I have had the chance to work a lot some years ago on Eclipe Rich Client Platform (RCP) and Eclipse Plugins API. The main project I tried to do was to create a development environment for PIC asm programming. You can see flash demo here http://www.pocketmt.com/downloads/demoflash.zip

Netbeans is a bit similar, and I can confirm that the most obscur part is not the Netbeans API, but the MPLabX API provides by Microchip. Most of the infrastructure is NOT documente, unless you consider javadoc listing of classes and their methods as a doc :roll: .

Today:
I have added the *.bas "files type" integration to the infrastructure, and I associated it with SF projects/modules. I also added the wizards needed to generate such files when using the "new file" dialog from MPLabX (see screenshot).
Now fighting with the makefile handler.
Attachments
newfilewizard.png
newfilewizard.png (69.06 KiB) Viewed 26768 times

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Wed Jan 28, 2015 10:47 pm

ICD feature in Swordfish BASIC

Well, I have a little problem and want to have your opinion (and ideas) about that.

Actually, MPLabX handles compilation of a "project" into DEBUG or PRODUCTIONrelease.
- DEBUG release is intended to generate a cof (and hex) file that have all needed information to debug a program using the simulator or the ICD3/PICKit3/RealIce hardware tags. This release also activates automatically the DEBUG bit in processor CONFIG.
- PRODUCTION release simply generates a HEX file without the debug bit set.

When you build a project to be used with a hardware tag, MPLabX automatically generates a DEBUG version of your project before flashing it.

Actually, selecting which config to generates is done simply in MPLabX using the buttons (or menus) in the toolbar.

Image

In Swordfish BASIC, generating a DEBUG version to be used with a hardware tag (ICD3 for example), is not done by asking only for a COF file to be generated. It's done at source level by setting the correct config bit, and by reserving the needed memory for ICD to work (modifying "maxram" variable), something like that:

Code: Select all

#variable _maxram = _maxram - $C    // constrain RAM
#variable _maxrom = _maxrom - $1C0  // constrain ROM
Config DEBUG = ON                   // DEBUG fuse ON
For more details, see article at page http://www.sfcompiler.co.uk/wiki/pmwiki ... r.MPLABICD

The problem:
Users of SF under MPLabX would want to do the same as with any compiler. i.e. by simply clicking on the concerned button, have the compiler to select the correct config (Debug / Production). This can be done easily, but if users will want to have debug working, they need to do modifications to their source codes to preserve the maxram.
Do you think it's better to keep the responsability of such thing to end user? or is it better that SF compiler be modified to handle the needed ram modifications and config bit setting automatically for user? this second choice, of course, mean a lot of work, as there are a lot of variant of PIC18Fxx and the way they preserve ram for ICD is different.

Do you have ideas on that? any suggestion is welcome.

Regards

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Thu Jan 29, 2015 10:18 am

That article's a little out of date. I'm not sure if MPLABX handles it in quite the same way as MPLAB does, but the MPLAB IDE handles setting the DEBUG config setting automatically for you, so you never specify that in your source code.

MPLAB only lets you select one tool at a time, so when you have the Debugger tool selected it sets DEBUG on, and if you have a Programmer selected it turns it off before it actually programs the device.

Here's how I handle it. Since there's no linker in SF, I have a debugger module and a #option to control it's usage.
In the main program module I put the following:

Code: Select all

#option MPLAB_ICD = false
include "mplabicd.bas"
The #option MPLAB_ICD defaults to false in mplabicd.bas, and if so it doesn't do anything. Setting the option = true reserves the req'd resources.

module mplabicd.bas:

Code: Select all

//
//------------------------------------------------------------------------------
// Name    : mplabicd.bas
// Author  : Jerry Messina
// Date    : 10/4/2014
// Version : 1.3
// Notes   :
//   MPLAB ICD settings
// ver 1.1
//  - correct entries for 18F13K22, 18F14K22, 18F13K50, 18F14K50
// ver 1.2
//  - add new K50 and 18FxxJ94 family
//  - device list from MPLAB 8.92
// ver 1.3
//  - correct WDTEN list (devices were missing)
//------------------------------------------------------------------------------
//
module mplabicd

//
// to use ICD, set '#option MPLAB_ICD = true' in the main program module
// before you include this file
//

// set default (ICD not used)
#option MPLAB_ICD = false

#if IsOption(MPLAB_ICD) and (MPLAB_ICD = true)

//
// By default, high priority interrupts use the hardware shadow registers for
// context saving the WREG, STATUS, and BSR registers, and low priority interrupts
// save them using software. The hardware shadow registers can get corrupted when
// placing a breakpoint inside an ISR.
// You can force the compiler to perform software context saving in software for both
// high and low interrupts rather than using hardware shadow registers by using the
// ISR_SHADOW option:
//      #option ISR_SHADOW = false
// This disables all hardware shadow register context saving and lets you use
// breakpoints in an ISR
// NOTE: since this changes the way isr's work, it is up to the user to set this option
//
'#option ISR_SHADOW = false
#if IsOption(ISR_SHADOW) and (ISR_SHADOW = false)
  #warning "disabling hardware shadow registers"
#endif

//
// ICD resources (device dependant)
// most devices require program memory space to hold a debug executive
// pretty much all devices require 12 bytes of ram at the top of memory, so we'll just
// set it as a default. devices that don't require any ram can set it to 0
//
#variable ICD_RAM = $0c

// device list from MPLAB 8.92 (240 devices)
// standard 18F devices (108 devices)
#if _device in (18F242, 18F248, 18F252, 18F258, 18F442, 18F448, 18F452, 18F458)
  #define ICD_ROM = $240
#elseif _device in (18F1220, 18F1230, 18F1320, 18F1330)
  #define ICD_ROM = $1c0
#elseif _device in (18F2220, 18F2221, 18F2320, 18F2321, 18F2331, 18F2410, 18F2420, 18F2423)
  #define ICD_ROM = $240
#elseif _device in (18F2431, 18F2439, 18F2450, 18F2455, 18F2458, 18F2480, 18F2510, 18F2520)
  #define ICD_ROM = $240
#elseif _device in (18F2523, 18F2539, 18F2550, 18F2553, 18F2580)
  #define ICD_ROM = $240
#elseif _device in (18F2515, 18F2525, 18F2585, 18F2610, 18F2620, 18F2680, 18F2682, 18F2685)
  #define ICD_ROM = $280
#elseif _device in (18F4220, 18F4221, 18F4320, 18F4321, 18F4331, 18F4410, 18F4420, 18F4423)
  #define ICD_ROM = $240
#elseif _device in (18F4431, 18F4439, 18F4450, 18F4455, 18F4458, 18F4480, 18F4510, 18F4520)
  #define ICD_ROM = $240
#elseif _device in (18F4523, 18F4539, 18F4550, 18F4553, 18F4580)
  #define ICD_ROM = $240
#elseif _device in (18F4515, 18F4525, 18F4585, 18F4610, 18F4620, 18F4680, 18F4682, 18F4685)
  #define ICD_ROM = $280
#elseif _device in (18F6310, 18F6390, 18F6393, 18F6410, 18F6490, 18F6493)
  #define ICD_ROM = $240
#elseif _device in (18F6520, 18F6525, 18F6527, 18F6585, 18F6620, 18F6621, 18F6622, 18F6627)
  #define ICD_ROM = $280
#elseif _device in (18F6628, 18F6680, 18F6720, 18F6722, 18F6723)
  #define ICD_ROM = $280
#elseif _device in (18F8310, 18F8390, 18F8393, 18F8410, 18F8490, 18F8493)
  #define ICD_ROM = $240
#elseif _device in (18F8520, 18F8525, 18F8527, 18F8585, 18F8620, 18F8621, 18F8622, 18F8627)
  #define ICD_ROM = $280
#elseif _device in (18F8628, 18F8680, 18F8720, 18F8722, 18F8723)
  #define ICD_ROM = $280

// J series devices (91 devices)
// these require no program memory, but some of them use ram
#elseif _device in (18F24J10, 18F25J10, 18F44J10, 18F45J10)
  #define ICD_ROM = 0
#elseif _device in (18F24J11, 18F24J50, 18F25J11, 18F25J50, 18F26J11, 18F26J13, 18F26J50, 18F26J53, 18F27J13, 18F27J53)
  #define ICD_ROM = 0
  #variable ICD_RAM = 0
#elseif _device in (18F44J11, 18F44J50, 18F45J11, 18F45J50, 18F46J11, 18F46J13, 18F46J50, 18F46J53, 18F47J13, 18F47J53)
  #define ICD_ROM = 0
  #variable ICD_RAM = 0
#elseif _device in (18F63J11, 18F63J90, 18F64J11, 18F64J90, 18F65J10, 18F65J11, 18F65J15, 18F65J50)
  #define ICD_ROM = 0
#elseif _device in (18F65J90, 18F66J10, 18F66J11, 18F66J15, 18F66J16, 18F66J50, 18F66J55, 18F66J60)
  #define ICD_ROM = 0
#elseif _device in (18F66J65, 18F67J10, 18F67J11, 18F67J50, 18F67J60)
  #define ICD_ROM = 0
#elseif _device in (18F66J90, 18F66J93, 18F67J90, 18F67J93)
  #define ICD_ROM = 0
  #variable ICD_RAM = 0
#elseif _device in (18F83J11, 18F83J90, 18F84J11, 18F84J90, 18F85J10, 18F85J11, 18F85J15, 18F85J50)
  #define ICD_ROM = 0
#elseif _device in (18F85J90, 18F86J10, 18F86J11, 18F86J15, 18F86J16, 18F86J50, 18F86J55, 18F86J60)
  #define ICD_ROM = 0
#elseif _device in (18F86J65, 18F87J10, 18F87J11, 18F87J50, 18F87J60)
  #define ICD_ROM = 0
#elseif _device in (18F86J72, 18F86J90, 18F86J93, 18F87J72, 18F87J90, 18F87J93)
  #define ICD_ROM = 0
  #variable ICD_RAM = 0
#elseif _device in (18F96J60, 18F96J65, 18F97J60)
  #define ICD_ROM = 0
#elseif _device in (18F65J94, 18F85J94, 18F95J94, 18F66J94, 18F86J94, 18F96J94, 18F67J94, 18F87J94, 18F97J94)
  #define ICD_ROM = 0
  #variable ICD_RAM = 0
#elseif _device in (18F66J99, 18F86J99, 18F96J99)
  #warning "support marked preliminary in 892"
  #define ICD_ROM = 0
  #variable ICD_RAM = 0


// K series devices (41 devices)
// many of these require no program memory or ram
#elseif _device in (18F13K22, 18F14K22, 18F13K50, 18F14K50)
  #define ICD_ROM = $200
  #variable ICD_RAM = 0
#elseif _device in (18F23K20, 18F24K20, 18F25K20, 18F43K20, 18F44K20, 18F45K20)
  #define ICD_ROM = $240
#elseif _device in (18F26K20, 18F46K20)
  #define ICD_ROM = $280
#elseif _device in (18F23K22, 18F24K22, 18F25K22, 18F26K22, 18F25K80, 18F26K80, 18F43K22, 18F44K22, 18F45K22, 18F46K22)
   #define ICD_ROM = 0
   #variable ICD_RAM = 0
#elseif _device in (18F45K80, 18F46K80, 18F65K22, 18F65K80, 18F65K90, 18F66K22, 18F66K80, 18F66K90, 18F67K22, 18F67K90)
   #define ICD_ROM = 0
   #variable ICD_RAM = 0
#elseif _device in (18F85K22, 18F85K90, 18F86K22, 18F86K90, 18F87K22, 18F87K90)
   #define ICD_ROM = 0
   #variable ICD_RAM = 0
#elseif _device in (18F24K50, 18F25K50, 18F45K50)
   #define ICD_ROM = 0
   #variable ICD_RAM = 0

#else
  #error "unsupported ICD device"
#endif

// constrain ROM and RAM so they are not used by SF
#variable _maxrom = _maxrom - ICD_ROM
#variable _maxram = _maxram - ICD_RAM

//
// wdt must be off for icd
//
// these 127 devices use WDTEN instead of WDT
#if _device in( _
18F13K22, 18F13K50, 18F14K22, 18F14K50, 18F2331,  18F23K20, 18F23K22, 18F2431, _
18F24J10, 18F24J11, 18F24J50, 18F24K20, 18F24K22, 18F24K50, 18F25J10, 18F25J11, _
18F25J50, 18F25K20, 18F25K22, 18F25K50, 18F25K80, 18F26J11, 18F26J13, 18F26J50, _
18F26J53, 18F26K20, 18F26K22, 18F26K80, 18F27J13, 18F27J53, 18F4331,  18F43K20, _
18F43K22, 18F4431,  18F44J10, 18F44J11, 18F44J50, 18F44K20, 18F44K22, 18F45J10, _
18F45J11, 18F45J50, 18F45K20, 18F45K22, 18F45K50, 18F45K80, 18F46J11, 18F46J13, _
18F46J50, 18F46J53, 18F46K20, 18F46K22, 18F46K80, 18F47J13, 18F47J53, 18F63J11, _
18F63J90, 18F64J11, 18F64J90, 18F65J10, 18F65J11, 18F65J15, 18F65J50, 18F65J90, _
18F65J94, 18F65K22, 18F65K80, 18F65K90, 18F66J10, 18F66J11, 18F66J15, 18F66J16, _
18F66J50, 18F66J55, 18F66J90, 18F66J93, 18F66J94, 18F66J99, 18F66K22, 18F66K80, _
18F66K90, 18F67J10, 18F67J11, 18F67J50, 18F67J90, 18F67J93, 18F67J94, 18F67K22, _
18F67K90, 18F83J11, 18F83J90, 18F84J11, 18F84J90, 18F85J10, 18F85J11, 18F85J15, _
18F85J50, 18F85J90, 18F85J94, 18F85K22, 18F85K90, 18F86J10, 18F86J11, 18F86J15, _
18F86J16, 18F86J50, 18F86J55, 18F86J72, 18F86J90, 18F86J93, 18F86J94, 18F86J99, _
18F86K22, 18F86K90, 18F87J10, 18F87J11, 18F87J50, 18F87J72, 18F87J90, 18F87J93, _
18F87J94, 18F87K22, 18F87K90, 18F95J94, 18F96J94, 18F96J99, 18F97J94 _
)
  config WDTEN = off
#else       // assume standard WDT
  config WDT = off
#endif     // _device

// enable debug (not required... this is controlled by mplab)
'config DEBUG = ON
#endif      // MPLAB_ICD = true

end module
Have the #option also lets you add special code when you're in debug mode vs a production build. That comes in very handy sometimes... there are times when you need to know which environment you're running under.

I don't know of any good way for the IDE to control all of this since you can't set an #option externally from the command line, so I think you'd have to actually edit the program file to change MPLAB_IDE option. If that's the case, I'd rather leave it up to the user to do manually.

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: MPLAB-X Plugin...

Post by David Barker » Thu Jan 29, 2015 10:34 am

Thanks octal and Jerry...

I'm quite prepared to make alterations to the Swordfish command line to support better MPLAB-X integration. With respect to ICD options. I've been talking about updating the Swordfish device files in another thread. This would appear to be an ideal candidate? For example, if every device file had something like

#variable ICD_ROM = <val>
#variable ICD_RAM = <val>

You could then add a command line switch (lets say -icd) which will automatically perform

#variable _maxrom = _maxrom - ICD_ROM
#variable _maxram = _maxram - ICD_RAM

If no command line was seen, you could do it in code as Jerry has already shown (but obviously the ICD_ROM and ICD_RAM define would not be needed as the device file holds these).

Alternatively, if the ICD_ROM and ICD_RAM could not be extracted from any microchip files when auto-generating the Swordfish device files, a command line switch of -icd would automatically link in a file file similar to the one shown by Jerry.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Thu Jan 29, 2015 10:57 am

I think you would want to have an individual control to enable/disable this as well... you need to be able to test for it in your source, like 'DEBUG' in the C environment.

Having the 'MPLAB_ICD' (or whatever) setting, you could have something like this in the device files

Code: Select all

#if (MPLAB_ICD)
#variable _maxrom = _maxrom - ICD_ROM
#variable _maxram = _maxram - ICD_RAM
config PWRTEN = off            // sometimes you need to do certain things for ICD
#endif
It would be nice to allow the user to have control over exactly what happens when -icd is used, and not have the compiler automatically do some fixed set of operations.

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: MPLAB-X Plugin...

Post by David Barker » Thu Jan 29, 2015 11:09 am

Swordfish currently supports "sys.import", like Firewing. I think this may be the way to go. You can test this now.

(1) create a folder in your main Swordfish library folder called "sys.import" (not sys.imports, leave the "s" off!)
(2) place your debug file into the "sys.import" folder
(3) restart Swordfish

This file will now be automatically linked into your code, without having an explicit "include". So you can now

(a) control using code, as before
(b) set via a command line option when using the command line compiler
(c) a will always override b

How does this sound?

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Thu Jan 29, 2015 11:30 am

If I follow, if I put the file in sys.import then it always gets included automatically. With my file, can I use the "#option MPLAB_ICD=false" to shut it off, or do I need to remove the file from sys.import?

How does 'b' work?

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: MPLAB-X Plugin...

Post by David Barker » Thu Jan 29, 2015 11:48 am

> If I follow, if I put the file in sys.import then it always gets included automatically.

Yes

> With my file, can I use the "#option MPLAB_ICD=false" to shut it off

#option MPLAB_ICD = false ' switch off
#option MPLAB_ICD = true ' switch on

if left out, it default to whatever is in your module (in your example, this is false)

> or do I need to remove the file from sys.import?

No, see above

> How does 'b' work?

It doesn't at the moment - I'm looking for ideas. For example, maybe get the compiler command line to process very simple define. For example,

-defMPLAB_ICD

then all you need in the debug file is

#ifdef MPLAB_ICD
...
#endif

Alternatively, lets say you have the debug file in "sys.import". To include support for ICD, just put

#define MPLAB_ICD

at the top of your program. Leave it out for a non-icd build. Or should the command line accept "#variables" rather than defines?

Post Reply