Jump to content
Sign in to follow this  
JBr

Mplab And Xinst

Recommended Posts

Here's probably a dumb question. Does BoostC++ expect extended mode instructions to be enabled in the device config? Also, I notice that libc's mul_*() routines use hardware multiply on PIC18 - while hw mul is a PIC18 extension if I understand correctly it's available regardless of whether extended instructions (XINST) is enabled in the device config?

 

I guess this was really two dumb questions... :)

Share this post


Link to post
Share on other sites

JBr,

 

Does BoostC++ expect extended mode instructions to be enabled in the device config?
No they need to be disabled
Also, I notice that libc's mul_*() routines use hardware multiply on PIC18 - while hw mul is a PIC18 extension if I understand correctly it's available regardless of whether extended instructions (XINST) is enabled in the device config?
Hardware multiply is available in all PIC18's, it's not part of the extended instruction set.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Here's another question raised by using MPLAB 8.43... Whenever I build it always does a clean followed by a complete rebuild. I'm also unable to use settings presets (like Debug and Release) - the pulldown is disabled. Is this normal for third-party tools in MPLAB? I'd use the BoostSource IDE except I need ICD2 debugger integration. I suppose I could create plugins for the simulator for the LCD and peripherals, but that's clearly orthogonal to the task at hand.

Share this post


Link to post
Share on other sites
Here's another question raised by using MPLAB 8.43... Whenever I build it always does a clean followed by a complete rebuild. I'm also unable to use settings presets (like Debug and Release) - the pulldown is disabled. Is this normal for third-party tools in MPLAB? I'd use the BoostSource IDE except I need ICD2 debugger integration. I suppose I could create plugins for the simulator for the LCD and peripherals, but that's clearly orthogonal to the task at hand.
The configuration settings for Debug and Release versions is a new problem that started with MPLAB v.8 and it doesn't stop there. There are other problems that began with that version such as project source file locations. If some are in subdirs then MPLAB or SourceBoost won't find them in some cases. I've tried to find out if this is a sourceboost error or MPLAB but nobody can tell me. All I know is it used to work in MPLAB v.7.xx and I wish somebody would fix it.

 

As far as rebuilding the whole project every time, that is a major PITA but again nobody has ever answered my inquiry as to who needs to put this on their bug/enhancement list. My guess is that MC changed their specs/requirements for integrated tools but either didn't tell the tool providors or SB hasn't gotten around to updating yet. Only a guess.

 

I'm also using ICD2.

Share this post


Link to post
Share on other sites

Many thanks for the info! Maybe SB is saving their bullets for v7 since it appears to be around the corner. Mostly I work with ARM and MIPS, hence these beginner questions. This particular project was for a demo at CES where a PIC connects to the serial console of a Linux/MIPS-based blu-ray player; I was creating a demo of our middleware product on that platform and getting it launched required attaching to the console and typing commands. No way of auto launching it without rebuilding a complete system (root cramfs), which is outlandishly complex due to secure boot and BD certificates having to match the 'dev' chips - instead I set a PIC to monitor the console, driving the demo and acting as a watchdog. This way I could put it in hands of marketing and sales people since all they'd have to do is push the power button to start it up. :blink: It all fit neatly inside the BD player case. SB C++ is a nice tool and C++ is great for code reuse. Wish it had namespaces though.

Share this post


Link to post
Share on other sites
JBr,

 

Does BoostC++ expect extended mode instructions to be enabled in the device config?
No they need to be disabled

 

Regards

Dave

 

Why do the extended instructions need to be disabled? From what I can tell from the data sheet they are encoded as 0xe8??,0xe9??, 0xea??,0xeb?? and 0x0014 and the standard instructions do not use these opcodes. It seems to me if BoostC does not generate code for the extended opcodes then it does not matter if the processor is enabled or not for them. Am I missing something?

 

If disabling the extended instructions is how it has to be, I'm ok with it. I was just curious if there was a hardware reason.

 

While we are on the subject of config settings, it seems that if I enable MCLR to be input portE[3] in the config register and drive the pin with a 1 in the simulator, the simulator always returns 0. I think the same goes for the extra portA bits if I configure the internal clock. Are the extra ports pins not supported and might they one day?

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...