Shared / configurable memory pool for Recorders

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Shared / configurable memory pool for Recorders

1,110 Views
FabrizioDaRos
Contributor I

Hi,

I have 3 recorders configured in my application, one on the main loop and the other 2 hooked to base tick generator under interrupt.

Now, when recorders are configured I need to figure out how much memory I need to provide each, through "FMSTR_REC_BUFF" and "FMSTR_RecorderCreate()"

That's a bit limiting. I was thinking to a shared space, let's say 2KB just to have a number in mind. This memory pool is given to all recorders and a default segment is assigned to each, not overlapping.

Let's say 3 recorder, the memory pool is divided into 512+512+1K. This setup is the same as we get with current solution.

But I would like to pass to recorder, not only their addr/size, but also the pool addr/size. The recorder segment falls inside the pool.

On PC-size I would like to be able to re-assign segments. Let's say I need to enlarge the 2nd from 512 to 1K. The following recorder can be collapsed (automatically for example) to 512 to get the new setup of 512+1K+512. Or the tool can ask the user to assign al of them according to available space.

That's the concept. To summarize

  • assign a shared memory pool to all recorders
  • pre-configure a segment from the pool to each of them (so we get same setup as now)
  • Let PC-side freemaster change segmentation to increase/decrease recorders buffer according to user selection

This feature boosts a lot the system flexibility with small FW impact (we need one addr/size couple more on recorders and of course messages to re-configure them)

Re-configuring a recorder memory pool causes its data to be discarded, of course (at least as first approx).

What do you think? Is that possible?

 

Thanks a tons for this great tool!
Fabrizio

 

0 Kudos
Reply
1 Reply

1,104 Views
MichalH
NXP Apps Support
NXP Apps Support

Dear Fabrizio,

I don't think we would go for such a complex change. If I understand your scenario well, you need three different recorders (each sampled in different point in time), but you do not want to waste a memory for each.

If you can make sure the recorders would never run simultaneously, I have two different proposals how to handle this situation:

Scenario A:

  1. Have just one recorder configured in the application and add one global variable named e.g. "selected_recorder". 
  2. Replace FMSTR_Recorder(0), (1) and (2) with conditional calls like:
    if(selected_recorder == 0)
        FMSTR_Recorder(0)

  3. The other sample places would test values 1 and 2, but would also call FMSTR_Recorder(0)
  4. You can add the selected_recorder variable to FreeMASTER Watch and control the behavior easily.

 

Scenario B:

  1. Use FMSTR_RecorderCreate to create all 3 recorders using the same address and size of the buffer.
  2. The FreeMASTER does full re-initialization of the recorder when you click a it in the FreeMASTER, so unless you would use two recorders simultaneously, you are safe.

 

Regards,
Michal

0 Kudos
Reply