1 Attachment(s)
18F26K80 Code Optimisation.
Attached is a complex man in the middle program I have written to control my Honda hybrid car via MCP2515 CAN bus modules and a PIC18F26K80 at 64mhz.
It works well in the car presently but I'm keen to see if I have missed any obvious pbpro speed tricks. :confused:
I would be grateful for any comments or observations from the gurus on here. :)
I did try and get the pic to run at 80mhz with an external 20mhz resonator and 4xPLL but it just would not run/work.
There was a separate thread for the overclocking attempt. Maybe a bad pic or bad resonator etc at my end.
I'm thinking about adding a timer program loop counter so I can see what effect ideas people have have on the basic loop time.
Thanks in advance for any speedup or space saving ideas.
Re: 18F26K80 Code Optimisation.
Hi,
After browsing thru this for 30 minutes or so I would say you've done a pretty damn good job. I was going to suggest running the SPI clock faster but it's already at 8MHz with the MCP2515 maxing out at 10.
There are a lot of WHILE ! SSP1IF :WEND statements waiting for the SPI peripheral. At 8MHz there's not THAT many instructions wasted but I suppose you could possibly pull the part of the display update routine where you're sending the VideoBuffer out of the mainloop, make a subroutine out of that and GOSUB that before entering the WHILE ! SSP1IF :WEND. Checking if a screen update is in progress, if the TXREG is free and, if so, put a byte there is perhaps something it can do while the SPI peripheral clocks out 8 bits. It MIGHT slow down the SPI thruput slightly but I think it should increase the overall speed - you'll have to try it. At least it'll DO something other than twiddling its thumbs waiting for the SPI peripheral.
How often is the screen updated?
It looks like you're updating the full VideoBuffer array every time it's time for a screen update. I'm not sure but I can imagine that massive ARRAYWRITE might take some time.
Perhaps you can have one VideoBuffer for Screen 0 and one for Screen 1 and update the entries when the values are received or changed instead of making that full snapshot every time?
BTW, what sort of display is this?
The checksum routine...
Code:
CheckSum = (CAN0RXBUF[CAN0RXPOINT + 5] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 5] & %00001111) + (CAN0RXBUF[CAN0RXPOINT + 6] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 6] & %00001111)_
+ (CAN0RXBUF[CAN0RXPOINT + 7] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 7]& %00001111) + (CAN0RXBUF[CAN0RXPOINT + 8] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 8] & %00001111) + (CAN0RXBUF[CAN0RXPOINT + 9] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 9] & %00001111)_
+ (CAN0RXBUF[CAN0RXPOINT + 10] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 10] & %00001111) + (CAN0RXBUF[CAN0RXPOINT + 11] >> 4) + (CAN0RXBUF[CAN0RXPOINT + 11] & %00001111) 'Add packet bytes 0-6 inclusive
I don't know if it'll be faster but I think the following will do the same thing:
Code:
Checksum = 0
For i = (CAN0RXPOINT + 5) to (CAN0RXPOINT + 11)
Checksum = Checksum + ( (CAN0RXBUF[i] >> 4) + (CAN0RXBUF[i] & %00001111) )
NEXT
And you can make that loop faster by precalculating the start and end values, like
Code:
StartValue = CAN0RXPOINT + 5
EndValue = CAN0RXPOINT + 11
FOR i = StartValue TO EndValue
Checksum = Checksum + ( (CAN0RXBUF[i] >> 4) + (CAN0RXBUF[i] & %00001111) )
NEXT
I don't know if something happened with the format of the file when you uploaded but as I was going thru it I had to indent a lot of code in IF/ELSE/ENDIF blocks in order to figure out what belonged to what.
Anyway, I think you've done an excellent job. If you really want to know where the possible bottlenecks are you'll have to start measure it.
/Henrik.
Re: 18F26K80 Code Optimisation.
Henrik. I appreciate the reply and will study it.
I don't like indented 'if then's' so don't do it as a rule.
I was trying to max out the MCP2515 by overclocking the pic to 80mhz (20mhx x 4PLL) which would have given me a 10mhz SPI clock..
But i could not get that to work. i need to look at it again on a breadboard..
I need to try a crystal instead of a resonator maybe.
The display is the old Batsocks Tellymate TTL serial to composite video chip that runs at 57,000bps input.
http://www.batsocks.co.uk/products/Other/TellyMate.htm
Thanks Peter
Re: 18F26K80 Code Optimisation.
My other thread about running the PIC at 80mhz is here.. (I failed to get it working)
https://www.picbasic.co.uk/forum/sho...heck-and-4xPLL.
Re: 18F26K80 Code Optimisation.
Do you NEED it to run faster? Are you at or close to the limit or do you just want to see what can be done?
I would not bother with overclocking the PIC, running it 25% above its specification, which I said in the other thread. Perhaps you couldn't make it work because it simply does not work.
Besides, I don't think PBP has a valid DEFINE OSC for 80MHz so all software timing etc will be wrong, which I now see Alain also said in the other thread. That can of course be compensated for but nah...
Here's what I'd do.
Start wrapping subroutines and small sections of code with LATB.0=1 / LATB.0=0 (or whatever pin is available) and put a scope probe on that pin.
Measure the sections and figure out where most of the time is spent. Then look at that section in more details.
Shaving off a couple of instructioncycles here and there on code that runs 5 times per second doesn't pay off. Shaving off the same number of cycles in code that runs thousands of times per second does. I'd probably start with the display update code as outlined in my previous reply. Which I now realise is completely the oposite of what I just said but if there's anywhere you can save a LOT of cycles it might be there.
/Henrik.
Re: 18F26K80 Code Optimisation.
Try using a clock osc chip instead of a crystall or resonator.
That's what I used (an external 20Mhz osc) and it worked for me.
Of course, that doesn't mean it'll work for all chips.
If you want to increase the speed switch to a chip that has the CAN controller builtin.
That avoids all the SPI transfers to the external controller.
Why use the 2515 at all when the K80 has CAN?
Re: 18F26K80 Code Optimisation.
Quote:
Originally Posted by
tumbleweed
If you want to increase the speed switch to a chip that has the CAN controller builtin.
That avoids all the SPI transfers to the external controller.
Why use the 2515 at all when the K80 has CAN?
Because I'm talking on three separate CAN buses.
The K80 only has one internal CAN module.
Re: 18F26K80 Code Optimisation.
Quote:
Originally Posted by
HenrikOlsson
Do you NEED it to run faster? Are you at or close to the limit or do you just want to see what can be done?
I wanted to see if it could run at 80mhz and if it did that would give me some free time with no code optimising.
I understand the define osc would need tweaking.
If I could get it going at 80mhz I was going to do define osc 40mhz and just double up on pauses and other commands that use that define etc
