Finally got TWO MRAMs working together
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?
I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 8:50 AM Chris Thompson chrisethompson@gmail.com wrote:
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
I've been checking the "sleep" power situation. I put an ammeter in series with ground going to the breadboard which holds only the MRAM. Thus, it should include not only MRAM Vss/Vdd current but also current used via the bus lines. The supply voltage is about 3.25V (the output from the 3.3V line on the Launchpad. Here is what we see with two MR25H40 devices with the clock at 2MHz.
Quiescent Awake: 160 uA Writing 9.1-9.3mA (This includes sending a WREN (write enable) command for each write command) Reading 6.6-6.4mA MRAM0 asleep, MRAM1 quiescent: 81uA Both Asleep: 2uA
Summary:
Reading and writing takes on the order of 50 times as much power as quiescent (you can do the math with more precision) Quiescent takes relatively little power Sleep cuts the quiescent power for each MRAM from about 81uA to about 1uA.
So my current thoughts about using sleep:
PRO:
--Sure it cuts the power use by 98% when the MRAM is not in use.
CON:
--But the savings is 98% of a "small" amount: 160uA. --The savings is only when the MRAM is not in use. (If one is in use and one sleeping, the power reduction is trivial) --The spec says we must explicitly send a wake command and wait 400uS before we can use an MRAM that is currently asleep. This is a significant time without some additional software. --The software is a bit less simple than I had hoped; we would have to use a timer and only sleep after a TBD time had passed with no memory ops. If we sleep at each op, the MRAM is hundreds of times slower.
I make no recommendation because the group may decide that the larger number of "CONs" are not as important as the PRO.
I'll check higher clock speeds at some point, but remember that all the power savings above is from quiescent (no clock) to sleep, so I would not expect a difference only in the read/write power.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 1:04 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?
I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 8:50 AM Chris Thompson chrisethompson@gmail.com wrote:
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
Also, the multi-MRAM support is now merged into the main branch. I just realized that I should have asked Chris to test it with a single MRAM. My apologies, but I did want to get this code out to share. When there are many more people working on code, we must work out our branch expectations. 73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 5:07 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I've been checking the "sleep" power situation. I put an ammeter in series with ground going to the breadboard which holds only the MRAM. Thus, it should include not only MRAM Vss/Vdd current but also current used via the bus lines. The supply voltage is about 3.25V (the output from the 3.3V line on the Launchpad. Here is what we see with two MR25H40 devices with the clock at 2MHz.
Quiescent Awake: 160 uA Writing 9.1-9.3mA (This includes sending a WREN (write enable) command for each write command) Reading 6.6-6.4mA MRAM0 asleep, MRAM1 quiescent: 81uA Both Asleep: 2uA
Summary:
Reading and writing takes on the order of 50 times as much power as quiescent (you can do the math with more precision) Quiescent takes relatively little power Sleep cuts the quiescent power for each MRAM from about 81uA to about 1uA.
So my current thoughts about using sleep:
PRO:
--Sure it cuts the power use by 98% when the MRAM is not in use.
CON:
--But the savings is 98% of a "small" amount: 160uA. --The savings is only when the MRAM is not in use. (If one is in use and one sleeping, the power reduction is trivial) --The spec says we must explicitly send a wake command and wait 400uS before we can use an MRAM that is currently asleep. This is a significant time without some additional software. --The software is a bit less simple than I had hoped; we would have to use a timer and only sleep after a TBD time had passed with no memory ops. If we sleep at each op, the MRAM is hundreds of times slower.
I make no recommendation because the group may decide that the larger number of "CONs" are not as important as the PRO.
I'll check higher clock speeds at some point, but remember that all the power savings above is from quiescent (no clock) to sleep, so I would not expect a difference only in the read/write power.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 1:04 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?
I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 8:50 AM Chris Thompson chrisethompson@gmail.com wrote:
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
I will test this with my MRAM, but I am taking a break at the moment due to a relapse with my arm pain. Unfortunately I have not made further progress with the AX5043 chip either. Hopefully soon.
73 Chris
On Sun, Dec 11, 2022 at 5:23 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Also, the multi-MRAM support is now merged into the main branch. I just realized that I should have asked Chris to test it with a single MRAM. My apologies, but I did want to get this code out to share. When there are many more people working on code, we must work out our branch expectations. 73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 5:07 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I've been checking the "sleep" power situation. I put an ammeter in series with ground going to the breadboard which holds only the MRAM. Thus, it should include not only MRAM Vss/Vdd current but also current used via the bus lines. The supply voltage is about 3.25V (the output from the 3.3V line on the Launchpad. Here is what we see with two MR25H40 devices with the clock at 2MHz.
Quiescent Awake: 160 uA Writing 9.1-9.3mA (This includes sending a WREN (write enable) command for each write command) Reading 6.6-6.4mA MRAM0 asleep, MRAM1 quiescent: 81uA Both Asleep: 2uA
Summary:
Reading and writing takes on the order of 50 times as much power as quiescent (you can do the math with more precision) Quiescent takes relatively little power Sleep cuts the quiescent power for each MRAM from about 81uA to about 1uA.
So my current thoughts about using sleep:
PRO:
--Sure it cuts the power use by 98% when the MRAM is not in use.
CON:
--But the savings is 98% of a "small" amount: 160uA. --The savings is only when the MRAM is not in use. (If one is in use and one sleeping, the power reduction is trivial) --The spec says we must explicitly send a wake command and wait 400uS before we can use an MRAM that is currently asleep. This is a significant time without some additional software. --The software is a bit less simple than I had hoped; we would have to use a timer and only sleep after a TBD time had passed with no memory ops. If we sleep at each op, the MRAM is hundreds of times slower.
I make no recommendation because the group may decide that the larger number of "CONs" are not as important as the PRO.
I'll check higher clock speeds at some point, but remember that all the power savings above is from quiescent (no clock) to sleep, so I would not expect a difference only in the read/write power.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 1:04 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?
I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 8:50 AM Chris Thompson chrisethompson@gmail.com wrote:
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
Certainly take it easy, Chris! I actually tried it myself with 1 and had to do some updates, but it should be fine now.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Mon, Dec 12, 2022 at 2:54 PM Chris Thompson chrisethompson@gmail.com wrote:
I will test this with my MRAM, but I am taking a break at the moment due to a relapse with my arm pain. Unfortunately I have not made further progress with the AX5043 chip either. Hopefully soon.
73 Chris
On Sun, Dec 11, 2022 at 5:23 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Also, the multi-MRAM support is now merged into the main branch. I just realized that I should have asked Chris to test it with a single MRAM. My apologies, but I did want to get this code out to share. When there are many more people working on code, we must work out our branch expectations. 73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 5:07 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I've been checking the "sleep" power situation. I put an ammeter in series with ground going to the breadboard which holds only the MRAM. Thus, it should include not only MRAM Vss/Vdd current but also current used via the bus lines. The supply voltage is about 3.25V (the output from the 3.3V line on the Launchpad. Here is what we see with two MR25H40 devices with the clock at 2MHz.
Quiescent Awake: 160 uA Writing 9.1-9.3mA (This includes sending a WREN (write enable) command for each write command) Reading 6.6-6.4mA MRAM0 asleep, MRAM1 quiescent: 81uA Both Asleep: 2uA
Summary:
Reading and writing takes on the order of 50 times as much power as quiescent (you can do the math with more precision) Quiescent takes relatively little power Sleep cuts the quiescent power for each MRAM from about 81uA to about 1uA.
So my current thoughts about using sleep:
PRO:
--Sure it cuts the power use by 98% when the MRAM is not in use.
CON:
--But the savings is 98% of a "small" amount: 160uA. --The savings is only when the MRAM is not in use. (If one is in use and one sleeping, the power reduction is trivial) --The spec says we must explicitly send a wake command and wait 400uS before we can use an MRAM that is currently asleep. This is a significant time without some additional software. --The software is a bit less simple than I had hoped; we would have to use a timer and only sleep after a TBD time had passed with no memory ops. If we sleep at each op, the MRAM is hundreds of times slower.
I make no recommendation because the group may decide that the larger number of "CONs" are not as important as the PRO.
I'll check higher clock speeds at some point, but remember that all the power savings above is from quiescent (no clock) to sleep, so I would not expect a difference only in the read/write power.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 1:04 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?
I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Sun, Dec 11, 2022 at 8:50 AM Chris Thompson < chrisethompson@gmail.com> wrote:
Well done Burns!
Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.
73 Chris
On Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)
Pacsat>get mram size Size of MRAM0 is 512KB Size of MRAM1 is 512KB Pacsat> Pacsat> Pacsat> Pacsat>test mram 0KB written 64KB written 128KB written 192KB written 256KB written 320KB written 384KB written 448KB written 512KB written 576KB written 640KB written 704KB written 768KB written 832KB written 896KB written 960KB written 0KB read 64KB read 128KB read 192KB read 256KB read 320KB read 384KB read 448KB read 512KB read 576KB read 640KB read 704KB read 768KB read 832KB read 896KB read 960KB read
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
participants (2)
-
Burns Fisher (AMSAT) -
Chris Thompson