Maximizing speed and efficiency of MCU
Moderators: David Barker, Jerry Messina
Maximizing speed and efficiency of MCU
Dear all,
I have been trying my best to squeeze out maximum speed from my PIC. Now after I have done almost everything, short of porting to PIC24, I am thinking if I can have a last attempt.
Do you think there will be any big difference if I change my subroutines from running variables of type Long to Byte? One of my busiest and critical subroutine is running a couple of long variables.
I think there will be, since PIC18 architecture is based on 8 bits. I can split the variable to shorter types (byte). But it will need some working on my core algorithm. So I would like to have some opinion before I dive in to work it out.
Thanks.
Regards,
Liak
I have been trying my best to squeeze out maximum speed from my PIC. Now after I have done almost everything, short of porting to PIC24, I am thinking if I can have a last attempt.
Do you think there will be any big difference if I change my subroutines from running variables of type Long to Byte? One of my busiest and critical subroutine is running a couple of long variables.
I think there will be, since PIC18 architecture is based on 8 bits. I can split the variable to shorter types (byte). But it will need some working on my core algorithm. So I would like to have some opinion before I dive in to work it out.
Thanks.
Regards,
Liak
working with bytes and dividing/multiplying by powers of 2 is most efficient, and as already mentioned no floats.
If you have a variable that is calculating a value in code see if you can use a constant if possible.
If you have a loop which counts larger than a byte have two byte loops, one inside the other.
try not to call routines outside the one you are in if other information needs changing.
If you are using swordfish modules see if you can strip down the code and streamline it for your own specific use, this could also save your code jumping to a subroutine.
Thats all that comes to mind right now!
If you have a variable that is calculating a value in code see if you can use a constant if possible.
If you have a loop which counts larger than a byte have two byte loops, one inside the other.
try not to call routines outside the one you are in if other information needs changing.
If you are using swordfish modules see if you can strip down the code and streamline it for your own specific use, this could also save your code jumping to a subroutine.
Thats all that comes to mind right now!
Dear Doj and John,
Thanks for the suggestions and feedback.
Indeed, I am already using multiplications and divisions with power of 2 that's the fastest I know (made a lot of difference, but still I need some more speed).
I have also converted all my loops to repeat..until from For...next. Somehow the for...next loop is significantly slower compared to the rest.
But I am not sure if we compare repeat...until against while...wend. I haven't looked into the ASM code generated by SF compiler (iliterate in ASM anyway ).
By the way, I am not sure which of the lines below is faster:
* inc(Counter)
vs
* Counter = Counter + 1
My vote is for the later.
If so, I will do the last thing. --> convert all my working variables into type byte.
Lastly, I would suggest we put a wiki on tips to optimize code execution in SF. That would be great.
Regards,
Liak
Thanks for the suggestions and feedback.
Indeed, I am already using multiplications and divisions with power of 2 that's the fastest I know (made a lot of difference, but still I need some more speed).
I have also converted all my loops to repeat..until from For...next. Somehow the for...next loop is significantly slower compared to the rest.
But I am not sure if we compare repeat...until against while...wend. I haven't looked into the ASM code generated by SF compiler (iliterate in ASM anyway ).
By the way, I am not sure which of the lines below is faster:
* inc(Counter)
vs
* Counter = Counter + 1
My vote is for the later.
If so, I will do the last thing. --> convert all my working variables into type byte.
Lastly, I would suggest we put a wiki on tips to optimize code execution in SF. That would be great.
Regards,
Liak
Liak, looks your application is speed sensitive and math intensive. I would recommend taking the plunge into the PIC24/dsPIC33. I use three variants/dialects of BASIC - as I said earlier, my favorite is SF. However, when needed, I will use something else.
Take a look at mikroBASIC for dsPIC. Download their demo and run your math routines in the simulator. It will give an accurate picture of how fast they run in terms of instruction cycles and microseconds. I think you will be in for a very pleasant surprise.
Take a look at mikroBASIC for dsPIC. Download their demo and run your math routines in the simulator. It will give an accurate picture of how fast they run in terms of instruction cycles and microseconds. I think you will be in for a very pleasant surprise.
Dear rmteo,
Thanks for the suggestion. Already I am in the process of evaluating and learning the particular version you mentioned. Just that, it will take some time (quite some time) before I get used to the new IDE and language environment. Still hoping David will be able to release his version in very near future.
Regards,
Liak.
Thanks for the suggestion. Already I am in the process of evaluating and learning the particular version you mentioned. Just that, it will take some time (quite some time) before I get used to the new IDE and language environment. Still hoping David will be able to release his version in very near future.
Regards,
Liak.
Don't forget to also download the 400+ page manual from here:
http://www.mikroe.com/en/compilers/mikrobasic/dspic/
I spoke to David a year ago regarding SF for 24-bit core PICs. I realize that it is a major undertaking and that whatever time he needs to do it, I am willing to wait.
In the meantime, using the mE compiler and switching between SF and it has not proven to be a problem. If you do run into issues, you can post your questions here:
http://www.mikroe.com/forum/viewforum.php?f=22
http://www.mikroe.com/en/compilers/mikrobasic/dspic/
I spoke to David a year ago regarding SF for 24-bit core PICs. I realize that it is a major undertaking and that whatever time he needs to do it, I am willing to wait.
In the meantime, using the mE compiler and switching between SF and it has not proven to be a problem. If you do run into issues, you can post your questions here:
http://www.mikroe.com/forum/viewforum.php?f=22
Or you could try overclocking the PIC It has worked for me.
Take a look at this post:
http://www.sfcompiler.co.uk/forum/viewtopic.php?t=707
Take a look at this post:
http://www.sfcompiler.co.uk/forum/viewtopic.php?t=707
This may be an interesting starter project. It demonstrates some of the unique features of the PIC24 - peripheral pin mapping, 32-bit timers, vectored interrupts, etc. It can be implemented on the smallest PIC24 (PIC24FJ24GA002, 16K Flash, 4K RAM, available as a 28-pin DIP).
2-Channel, 50MHz Frequency Counter with LCD
http://www.mikroe.com/forum/viewtopic.php?t=16520
2-Channel, 50MHz Frequency Counter with LCD
http://www.mikroe.com/forum/viewtopic.php?t=16520
Dear Jason and rmteo,
Sorry for late reply. Thought thread was closed.
Interesting topic, Jason, that you have brought up. I didn't know there was a thread on "overclocking". Will look in other forums for further experiences by others on same topic.
But I guess it will have to be tested on PIC by PIC basis, other hardware settings and luck too, will have to play a role. Makes me thinking... and naughty , what if...
Thanks again rmteo for the link. I am still in the process of learning the PIC24 dialect.
Thanks.
Regards,
Liak
Sorry for late reply. Thought thread was closed.
Interesting topic, Jason, that you have brought up. I didn't know there was a thread on "overclocking". Will look in other forums for further experiences by others on same topic.
But I guess it will have to be tested on PIC by PIC basis, other hardware settings and luck too, will have to play a role. Makes me thinking... and naughty , what if...
Thanks again rmteo for the link. I am still in the process of learning the PIC24 dialect.
Thanks.
Regards,
Liak
Dear Doj and John,
Finally completed making all modifications in my variable type handling. I have changed all variables to type byte wherever I can. And you were right, the algorithm is much much more robust now. It is running nearly 40% faster!!! Nothing else is changed except the way data is represented.
Btw, rmteo, PIC18 and SF are too precious for me to leave for now. I will wait patiently for SF PIC24, and meanwhile I will do with the modifications I made.
Amazing.
Regards,
Liak
Finally completed making all modifications in my variable type handling. I have changed all variables to type byte wherever I can. And you were right, the algorithm is much much more robust now. It is running nearly 40% faster!!! Nothing else is changed except the way data is represented.
Btw, rmteo, PIC18 and SF are too precious for me to leave for now. I will wait patiently for SF PIC24, and meanwhile I will do with the modifications I made.
Amazing.
Regards,
Liak
Hi Liak,
We also thought we would have to change to the 24F due to interrupt constraints and speed issues. However, the more we worked with SF and become more experienced at it, the more we were able to optimize our code and make it work in the 18F.
SF also has many features not present in the Hi-Tech C compiler we also use such as open source libraries, GLCD, HID, and other tools, automatic backup and other plug-ins. SF also has very good external chip libraries (like timers and EEPROM) and, of course, very simple yet powerful basic code to generate very efficient assembler. Running as a finite state machine with substates also simplified our code. We are on our second product version and still have plenty of 18F resources left. We just haven't had a compelling reason to go to the 24F yet...although we're sure customer demand will pull us there eventually.
Cheers,
-Tom
We also thought we would have to change to the 24F due to interrupt constraints and speed issues. However, the more we worked with SF and become more experienced at it, the more we were able to optimize our code and make it work in the 18F.
SF also has many features not present in the Hi-Tech C compiler we also use such as open source libraries, GLCD, HID, and other tools, automatic backup and other plug-ins. SF also has very good external chip libraries (like timers and EEPROM) and, of course, very simple yet powerful basic code to generate very efficient assembler. Running as a finite state machine with substates also simplified our code. We are on our second product version and still have plenty of 18F resources left. We just haven't had a compelling reason to go to the 24F yet...although we're sure customer demand will pull us there eventually.
Cheers,
-Tom