Chris,

Your comments are the direction we need to move towards.

I would like to just hack out what I can to make it build and load so I can test chip interface. Will be looking at doing this.

I want to get to the point that when I take something out that green bar moves to the left. This bar is red when you exceed available memory and probably yellow just before you do. I worry the bar is based on inputs and not actual linker results.

I agree constants want help much but if there are any tables of fixed data that can be helpful. The other thing to do is code with numbers and not use variables. Again, not much savings but just a coding style.

The heap space and swap is set for 0x800 each. I tried making this 0x100 each and did not see a change in the Green bar. This seems like a problem.

Bob

From: Chris Thompson via pacsat-dev pacsat-dev@amsat.org Sent: Tuesday, January 16, 2024 10:39 AM To: Bob Stricklin bstrick@n5brg.com Cc: Pacsat Dev pacsat-dev@amsat.org Subject: [pacsat-dev] Re: Memory Problem on PacSatSW

I expect the code could be drastically optimized to reduce memory usage. It's fairly complex and I opted for simple static memory allocation. But there is plenty of duplication. Each task makes a copy of the received packet in an RTOS queue and likely in a temp buffer as well. In theory we could collapse all of that into one shared queue/buffer.

In the short term you can reduce the heap size as Burns said. You could also remove some of the tasks temporarily as they each have a stack. The stack sizes can also probably be trimmed back in some cases as no optimization has been done.

Most of the Globals are in MRAM but get mirrored in RAM. We could stop doing that but I doubt it is a lot of space.

Finally we keep an index of the directory in the heap which does increase its size. We could remove that and only iterate over MRAM but that requires some redesign as it needs to be sorted by upload time.

73 Chris the

On Mon, Jan 15, 2024, 16:01 Bob Stricklin via pacsat-dev <pacsat-dev@amsat.orgmailto:pacsat-dev@amsat.org> wrote: Looks like we have an issue with memory usage in RAM.

If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used.

I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build.

Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code.

I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study.

Bob

[cid:image001.png@01DA47C3.B189E4D0]

-----------------------------------------------------------

pacsat-dev mailing list -- pacsat-dev@amsat.orgmailto:pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.orgmailto:pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org