Tips for optimising bank switching?

Coding and general discussion relating to the compiler

Moderators: David Barker, Jerry Messina

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Mon Nov 02, 2015 3:05 pm

I do wonder if Microchip have either lost some good people or have simply grown too fast. The stuff about the bugs in the PIC32s is very worrying. I also wonder why nothing seems to be happening with the PIC18s - the last chip to be announced was the K40 series but it's over a year since they were listed as a 'future product' and there is no sign of them actually appearing.

ARM is actually another option for us. My colleague uses Keil to develop for the LPC2294 which is used in a couple of our products, although it seems like quite an old chip. I personally really like the Microchip peripherals and have heard some horror stories as to how difficult ARMs can be to do simple things with, but we do have the tools and experience. I'm going to have to learn at least the basics at some point to support these products as he is only a few years away from retirement and even if all current products were moved over to PIC before then the old products would still need support.

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

Re: Tips for optimising bank switching?

Post by Jerry Messina » Mon Nov 02, 2015 3:14 pm

The main problem with PIC24 series is that the silicon errata datasheets seems to never shorten even with the new versions of silicon releases
That's a problem with a number of their chips. I'm always surprised when they actually DO fix anything when they rev the silicon. They don't seem to do a very good job of qualifying things before release, and it seems you're sort of left with "well, that's how this chip turned out".

When I'm looking at using a different chip, I usually go straight for the errata before I even read the datasheet!
I also wonder why nothing seems to be happening with the PIC18s
Me too. Preliminary support for the K40 appeared in one of the recent XC8 updates, but they seem to be focusing more on adding things to the PIC16 line for some reason. Maybe with the cost of many of the PIC24's they see that as a better alternative?

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Mon Nov 02, 2015 3:21 pm

(Getting OT here, my apologies!)

I wonder if there is some limitation with the PIC18 core, maybe size? I'm surprised there are no 14 pin or even 8 pin variants - after all, they do smaller pin version of the PIC24 than they do of the PIC18. I don't know if the 16F1 core fixes any issues which makes it comparable with the PIC18 but the only reason I can think to put so much effort in to it rather than making the PIC18 core the 'standard' 8-bit one would be to do with manufacture costs.

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

Re: Tips for optimising bank switching?

Post by octal » Mon Nov 02, 2015 4:49 pm

SHughes_Fusion wrote: ARM is actually another option for us. My colleague uses Keil to develop for the LPC2294 which is used in a couple of our products, although it seems like quite an old chip. I personally really like the Microchip peripherals and have heard some horror stories as to how difficult ARMs can be to do simple things with, but we do have the tools and experience.
LPC2294 is an old chip and an old architecture. Check the Cortex-M chips. They have better and newer architecture (cortex m0 are the most energy conservative and lowest cost). Now with the CMSIS library, configuring pins is really easy. To configure pins you need to set more properties because you have far more capabilities. You can set pins PullUp, PullDown, HighZ, input, output, ... with all those possibilities being combined (output in pulldown mode and limited to 2Mhz for example). This is why you need a bit more code to configure devices in ARM chips, but this is always the price of flexibility in programmable devices.

As for PIC18, I also saw that microchip didn't released new PIC18 chips. I would be very happy to see CLC and OP-AMP combined all together in a single PIC18F chip (like on PIC16Fxx).
Also I don't understand why do they not release 8 pin chips in PIC18 architecture. I need to keep using HITECH C for (old) 8 pin devices.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Tue Nov 03, 2015 9:11 am

Thinking about it, Microchip's advantage in the 32 bit field is their peripherals. If they aren't going to develop their own core then they might be better off offering a few core options.

I can see more ARM developers moving to Microchip if they offered an ARM core PIC32 than if they have to learn to program the MIPS core.

Would love to know more about the plans for the PIC18 though. I posted something on the Microchip forum about a year ago asking this and the only response I got was along the lines of 'there are hundreds of types, of course it isn't dead'...

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

Re: Tips for optimising bank switching?

Post by octal » Tue Nov 03, 2015 9:33 am

I used PIC18 quite a lot and I really like Microchip peripherals. They always offer a nice set of peripherals (even most complicated ones like USB and Ethernet) in a single small chips. My hope was always to see same chips without the banking thing and with a bit more RAM. My hope was exhausted when I discovered PIC24 and dsPIC chips. If you want cleaner and more powerful chips than PIC18 with same set of peripherals and priced almost the same, move to PIC24.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Tue Nov 03, 2015 11:47 am

Back OT - I think I have found an issue with Bank Switching.

I'd tried re-ordering the includes in another program to minimise the MOVLB commands. This introduced an issue where one of the LEDs was flickering. Put the includes back to the original order and the code size goes up by 200-odd bytes but the flickering goes away....

The LEDs are multiplexed in software so I wonder if there is some bank switching being missed out and the settings are being read from the wrong place?

I'll try and investigate more...

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

Re: Tips for optimising bank switching?

Post by Jerry Messina » Tue Nov 03, 2015 12:18 pm

Something else to watch out for when you re-order modules... make sure that if you have routines with the same name in multiple modules (ie 'WriteByte') that you use the 'Module.WriteByte()' syntax so you get the correct routine called.

Not saying there isn't a banking problem...

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Tue Nov 03, 2015 12:23 pm

Good point, Jerry, I'll check but generally I do make a point of calling module.function just to be sure.

I can say for sure it isn't the actual LED multiplexing as that compiles the same for both versions - with the exception of some line labels differing.

The serial comms looks a lot different so that might be my favourite at the moment.

One thing I have noticed - If statements can result in some very impenetrable code! Take the following as an example:

Code: Select all

?I001457_F000_000321_P000270 ; L#MK IF LEDON OR LED2.FLASHING = FALSE THEN
    BCF STATUS,3,0
    MOVLB 9
    BTFSC M2218_U01,2
    BSF STATUS,3,0
    MOVLB 0
    BOV TRUE_1517
    BCF STATUS,3,0
    MOVLB 9
    BTFSC M2214_U01,2
    BSF STATUS,3,0
    MOVLB 0
    BOV ENDIF_1516
TRUE_1517
I'd never think of using the Overflow bit and BOV. Mind you, it looks to me as if there are quite a few 'pre-emptive' MOVLBs in there - unless you need to be in Bank 0 to test the STATUS register?

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

Re: Tips for optimising bank switching?

Post by Jerry Messina » Tue Nov 03, 2015 2:25 pm

unless you need to be in Bank 0 to test the STATUS register?
No, I think the extra 'MOVLB 0' instructions came from a bugfix a few versions ago.

IIRC, when you have a statement like 'if (condition1 or condition2 or condition3)' things can get REALLY hairy if the 'conditions' are a mix of variables in different banks, frame variables in bank 0, etc. The compiler normally tries to track the current banksel setting, but the resulting tree of tests and branches were confusing it. The 'MOVLB 0' forces the compiler to set the bank tracking to a known value.

If you see a lot of bank switching going on, sometimes one of the optimizations you can do is to take advantage of the fact that local frame variables are typically located in bank 0, and make a temp copy of your variable into a local and use that...

Code: Select all

dim b as byte 	// module static ends up in bank X

sub test()
	dim btemp as byte     // local frame var is likely in bank 0
	
	btemp = b                 // copy banked var to frame variable (hopefully) in bank 0
	if (btemp = xxxx)       // work with the local instead of the banked variable
	....
end sub
Keep in mind this doesn't always work out, and usually only helps if you access 'b' a lot in the sub, but it can really reduce the code size.
There's nothing that guarantees the local will be in bank 0, so if you really need the optimization you should use some other method to ensure it always works since things can/will change as you change the code.

It's not the kind of thing I'd start out doing (since you can just as easily end up with MORE code), but if you're at the end and you're trying to squeak out every byte/clock cycle it can help.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Tue Nov 03, 2015 2:56 pm

I did try using a local boolean but it didn't seem to help - added about 4 extra instructions. That said, I didn't use it in all the places I could so it may help overall.

To be honest, I'm not so bothered about saving code here, more trying to work out why one of the LED flickers when there is UART traffic. I'm not sure 'fixing' it by rearranging the includes is good enough for me as I'd prefer to understand why it happens in the first place incase a future update breaks it again.

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

Re: Tips for optimising bank switching?

Post by Jerry Messina » Tue Nov 03, 2015 2:59 pm

I'm not sure 'fixing' it by rearranging the includes is good enough for me
Certainly wouldn't be for me either.

If you need help trying to isolate the differences, drop me a PM.

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: Tips for optimising bank switching?

Post by SHughes_Fusion » Wed Nov 04, 2015 9:16 am

Problem solved! It was include order - and me being lazy / a bit of a numpty.

I've got two versions of hardware for this project so I've added a 'Versions.bas' file which sets various things up based on which version is specified in a #define at the top of the main.

When I was changing the order I was including the comms.bas file before the versions.bas file so it was using the default pin settings - and by sheer coincidence, the RTS pin default is the same as the LED pin that was flickering.

Lesson is make sure you know what is important to include first and include it first even if doing so adds bank switching to later includes!

Post Reply