In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.

When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.

Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.

To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.

Chris

On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:

Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are. In other words, I don't think that multiple chips are a big problem.

FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.

73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software

On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.

Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?

73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software

On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers <wa4cwi@bellsouth.net> wrote:
We need to address Pacsat memory considerations.

The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.

With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.

Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.

Thanks

Jim McCullers
WA4CWI
-----------------------------------------------
pacsat-dev mailing list -- 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.org
Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

-----------------------------------------------
pacsat-dev mailing list -- 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.org
Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org