• AVR Freaks

Hot!Efficient way of reducing 'Program Memory'?

Author
Poley
Starting Member
  • Total Posts : 59
  • Reward points : 0
  • Joined: 2020/06/16 08:39:05
  • Location: 0
  • Status: offline
2020/12/08 03:07:01 (permalink)
0

Efficient way of reducing 'Program Memory'?

Hi, my model is currently sitting at 89% program memory used using optimization level 3.
 
If I add anything else into the model (Takes it to 90%) it makes my program run really slow/constantly restarting, I am assuming it is due to the pic being overloaded and tripping.
 
Is there any useful tips I could start with to bring this down? I have tried -s optimization but for some reason this optimizes out some stateflows causing them to not run properly on the hardware ( Does 1 step then doesn't move on )
 
Thanks!
#1
Lubin
Moderator
  • Total Posts : 470
  • Reward points : 5
  • Joined: 2007/03/31 07:38:15
  • Location: Bayonne, France
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 04:20:48 (permalink)
0
Hi Poley,
 
There are blocks allowing to check MCU load in real time (CPU load, task state) and thus checking that no overload (real time violation) occurs.  Please check this post for MCU load: https://www.microchip.com/forums/FindPost/1120678
 
For program memory, you might try unchecking "inline invariant parameters" Simulink option if checked. However, it will use RAM instead of program memory.
Do you have lots of data stored, maybe lookup table ? Are you using double or floating point calculation you might replace with fixed point ?
 
Floating point would impact program memory as well as execution time.
Simulink is great at fixed point algorithm design and PICs are great at running theses.
 
Last, you might check the Code Replacement option which is good for both memory and execution speed for some fixed-point calculations.
 
Lubin
#2
Mysil
Super Member
  • Total Posts : 4123
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 04:48:45 (permalink)
4.5 (2)
Hi,
The simplest way, is to select a device with sufficient hardware memory.
 
All the other possible actions involve hard work and changes in the program,
and require knowledge of the actual program, the structure of code, algorithms used, and requirements to the product. 
 
The most obvious changes, may be the most work.
Avoid floating point calculations, where integer computations may be able to  do the work.
Select data types that match the range of values that will actually occur.
Make printed messages and other output shorter or more condensed.
 
Use fractional math calculations instead of floating point computations,
if it make sense for the application domain.
 
Tidy up duplications and repetitions, if any.
 
    Mysil
 
#3
Poley
Starting Member
  • Total Posts : 59
  • Reward points : 0
  • Joined: 2020/06/16 08:39:05
  • Location: 0
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 05:03:17 (permalink)
0
Hi Lubin
 
Thank you for the reply. I have set up MCU load (Red) and MCU Overload (Blue) and this is the result, does this show an overload?
 
I Will look at converting my floating points into fixed point and see if that helps, will need to do some reading as only used floating before. I don't however have Fixed-Point Designer if that matters
 
I have also attached the program and data memory for this build using -O1 to reduce size and increase speed. So it's not at a high percent with the same behaviour.
 
What else can I use for code replacement library? Thanks!
 
post edited by Poley - 2020/12/08 06:05:44

Attached Image(s)

#4
crosland
Super Member
  • Total Posts : 2176
  • Reward points : 0
  • Joined: 2005/05/10 10:55:05
  • Location: Warks, UK
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 07:31:20 (permalink)
4 (1)
If adding code causes the uC to constantly restart then you have a bug in your code. Is the watchdog enabled? Are you patting it often enough, including in the new code?
 
Which PIC? Which compiler? Is your stack deep enough?
 
If changing optimization changes behaviour then you have a bug in your code, e.g., missing 'volatile' qualifiers.
#5
Poley
Starting Member
  • Total Posts : 59
  • Reward points : 0
  • Joined: 2020/06/16 08:39:05
  • Location: 0
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 08:29:34 (permalink)
0
crosland
If adding code causes the uC to constantly restart then you have a bug in your code. Is the watchdog enabled? Are you patting it often enough, including in the new code?
 
Which PIC? Which compiler? Is your stack deep enough?
 
If changing optimization changes behaviour then you have a bug in your code, e.g., missing 'volatile' qualifiers.


Hi thanks for the help!
 
Watchdog is enabled and I have not made any changes to it in Simulink so am unsure what it defaults to with the block set.
 
I am using a dsPIC33EV256GM106 with XC16 compiler. I am not sure how to check stack size in Simulink? can't find an option for it, only heap size (are they the same thing?) - Update, adding 512 to heap shows that max stack is 3172  but unsure how to change stack
 
Looks like it resets at 6s everytime
post edited by Poley - 2020/12/08 08:35:22
#6
ric
Super Member
  • Total Posts : 29919
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Efficient way of reducing 'Program Memory'? 2020/12/08 19:56:16 (permalink)
4 (1)
Poley
Watchdog is enabled and I have not made any changes to it in Simulink so am unsure what it defaults to with the block set.

Try disabling the Watchdog.
If that fixes the problem, then it's a bug in your WDT handling.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#7
Lubin
Moderator
  • Total Posts : 470
  • Reward points : 5
  • Joined: 2007/03/31 07:38:15
  • Location: Bayonne, France
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/09 03:40:34 (permalink)
3 (1)
Hi Poley,
 
on the scope graph with MCU Load and Overload. Both shows that you do have an overload.
The MCU load pin is off during its MCU idle time. Here there are no Idle time.
the MCU overload pin get set on first overload detected. User might set it back to 0 in one simulink task (thread) if you want to detect another overload.
 
 
Then the graph seems to show an MCU reset wheen pins are in high impedance.
 
The MPLAB Blocks do not implement Watch Dog or Dead Man timer mechanisms. The code should be all disabled by default.
Still, I noticed that on this chip the fuse FWDTEN is set to enable Watch Dog when SWDTEN bit is set. (ON_SWDTEN option). I would prefere to set this fuse to OFF.
As the SWDTEN bit is 0 at power-on and not set, not sure the Watch dog it the cause of the reset.
You might change the FWDTEN fuse setting in the code once to validate this assumption.
 
I tend to think that the general overload is the root cause.
The Scheduler is protected against overload. However there might be limitation if the overload is continuous.
Rapid Control Prototyping tools like dSPACE, speedgoat or other just stop bu default on first overload detection.
 
Last, note that other chip supporting natively single and double floating point number are also supported in Simulink, some of them share blocks like UART, I2C and SPI which allows to port easily a software from dsPIC, to PIC32 or some SAMx devices.
#8
Poley
Starting Member
  • Total Posts : 59
  • Reward points : 0
  • Joined: 2020/06/16 08:39:05
  • Location: 0
  • Status: offline
Re: Efficient way of reducing 'Program Memory'? 2020/12/16 09:58:37 (permalink)
0
Hi Lubin
 
Thank you for helpful reply.
 
It was indeed an overload issue. I used Simulink Profiler and found that some of my 'for-each' subsystems were being called a crazy amount of times. Once changing the logic for this the model runs without issues on my target hardware. Also slowed the sampling rate of calculation blocks.
 
I think I need the Watchdog to be enabled for it to force a reset if the device crashes. 
 
Thanks!
 
#9
ric
Super Member
  • Total Posts : 29919
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Efficient way of reducing 'Program Memory'? 2020/12/16 12:04:32 (permalink)
4 (1)
Poley
I think I need the Watchdog to be enabled for it to force a reset if the device crashes.

It's not that simple.
YOU have to find a way to keep tickling the Watchdog when it has NOT crashed.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#10
Murton Pike Systems
Super Member
  • Total Posts : 225
  • Reward points : 0
  • Joined: 2020/09/10 02:13:01
  • Location: 0
  • Status: online
Re: Efficient way of reducing 'Program Memory'? 2020/12/16 15:11:31 (permalink)
0
I had to move up to next level of memory in a PIC as I had run out.
I was quite shocked to find it was half the price !
Must have been a more popular version.
 
#11
Jump to:
© 2021 APG vNext Commercial Version 4.5