Re: Lots of things working--I'm pretty much done for now
Great progress Burns. All sounds good.
The RX uses the interrupt, so that will need to be setup for all 4. To test it you need to send it a packet I suppose...
The TX should have an interrupt configured but we don't use it so far. But we need it to support packets longer than 255 bytes. That is important if we want to add FEC bytes.
On the branches we should create a launchpad one from main before we merge blinky into main. And or add a release Tag for launchpad. Then, as long as we don't change the HCG stuff in the launchpad branch (or other incompatible things), we should probably be able to merge changes from launchpad branch back into blinky. If that is ever required.
73 Chris
On Fri, Feb 9, 2024, 17:31 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev@amsat.org> wrote:
I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I think that this has essentially everything that I planned to do (although see the end).
- I2c temp sensors working
- SPI access to AX5043 working. (Oh, I have not tested interrupts. I
don't know with the current setup how to make one. Tell me if it does not work and how to do something that SHOULD cause it to interrupt, and I will fix it.) 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my board and it does not have 3, but they all work on Bob's so I assume that is all ok. 4) All tasks are started. What they do is not my baliwick! 5) MRAM init routines are working. Depending on what you do, these will figure out how many address bytes are required (always 3 for blinky, always 2 for Launchpad, so that could be hard-coded). They will also figure out the MRAM size as well as the number of MRAM chips, and set up the chips so that the partitions do what they should. (II can't test odd configurations but 1 MRAM works and 4 works.)
New info: When starting on a brand new processor (and I'd recommend it on the current ones that we have been using), I don't think it will crash unless none of the MRAMs work. But the first thing you should do is to issue the command "init new proc". This will init a lot of MRAM stuff, including the default AX5043 frequencies for two of the 5043s (one Rx and one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq nnn" to raise and lower them. Save them with "save freq". Rebooting or "preflight init" will not change them.
If you do "get mram sr" to look at the status registers, that is an easy way to tell which MRAMs are present. The status register for those not present will read 0xff. The first one present will read 0x32. Others will just read 2. "get mram size" will also give useful info.
Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes
What I have left to do:
Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. Make a place to store them in MRAM, set default values, etc.
Check for even more stuff that can be removed. I think there are a number of unused commands which may have no code, but will still show up in help, for example.
Debug 5043 interrupts if there is a problem. Actually is it the case that only Tx uses interrupts and not Rx? If Rx, there is more to do to make all 4 of them work.
In the meantime, though, Chris and Jim, I think you can play with this as soon as you get a blink. One thing to note: Be sure to keep blinky and launchpad on separate branches. Especially the HalCoGen stuff is much different but also anything that knows how many MRAMs and how many 5043s there are. Those won't merge easily if at all.
I'll try to do at least the rx freq stuff tomorrow. I totally forgot about that until a few minutes ago.
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
Ok, it makes sense it would be Rx. If there is just a way to poke a register to cause an interrupt, that is really all I need. I really don't want to (or know how to) debug lots of other stuff like ensuring that the Rx set up correctly if it is at all possible.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Feb 9, 2024 at 5:46 PM Chris Thompson chrisethompson@gmail.com wrote:
Great progress Burns. All sounds good.
The RX uses the interrupt, so that will need to be setup for all 4. To test it you need to send it a packet I suppose...
The TX should have an interrupt configured but we don't use it so far. But we need it to support packets longer than 255 bytes. That is important if we want to add FEC bytes.
On the branches we should create a launchpad one from main before we merge blinky into main. And or add a release Tag for launchpad. Then, as long as we don't change the HCG stuff in the launchpad branch (or other incompatible things), we should probably be able to merge changes from launchpad branch back into blinky. If that is ever required.
73 Chris
On Fri, Feb 9, 2024, 17:31 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev@amsat.org> wrote:
I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I think that this has essentially everything that I planned to do (although see the end).
- I2c temp sensors working
- SPI access to AX5043 working. (Oh, I have not tested interrupts. I
don't know with the current setup how to make one. Tell me if it does not work and how to do something that SHOULD cause it to interrupt, and I will fix it.) 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my board and it does not have 3, but they all work on Bob's so I assume that is all ok. 4) All tasks are started. What they do is not my baliwick! 5) MRAM init routines are working. Depending on what you do, these will figure out how many address bytes are required (always 3 for blinky, always 2 for Launchpad, so that could be hard-coded). They will also figure out the MRAM size as well as the number of MRAM chips, and set up the chips so that the partitions do what they should. (II can't test odd configurations but 1 MRAM works and 4 works.)
New info: When starting on a brand new processor (and I'd recommend it on the current ones that we have been using), I don't think it will crash unless none of the MRAMs work. But the first thing you should do is to issue the command "init new proc". This will init a lot of MRAM stuff, including the default AX5043 frequencies for two of the 5043s (one Rx and one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq nnn" to raise and lower them. Save them with "save freq". Rebooting or "preflight init" will not change them.
If you do "get mram sr" to look at the status registers, that is an easy way to tell which MRAMs are present. The status register for those not present will read 0xff. The first one present will read 0x32. Others will just read 2. "get mram size" will also give useful info.
Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes
What I have left to do:
Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. Make a place to store them in MRAM, set default values, etc.
Check for even more stuff that can be removed. I think there are a number of unused commands which may have no code, but will still show up in help, for example.
Debug 5043 interrupts if there is a problem. Actually is it the case that only Tx uses interrupts and not Rx? If Rx, there is more to do to make all 4 of them work.
In the meantime, though, Chris and Jim, I think you can play with this as soon as you get a blink. One thing to note: Be sure to keep blinky and launchpad on separate branches. Especially the HalCoGen stuff is much different but also anything that knows how many MRAMs and how many 5043s there are. Those won't merge easily if at all.
I'll try to do at least the rx freq stuff tomorrow. I totally forgot about that until a few minutes ago.
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
As requested:
The GPIOs to turn on and off the SSPA and the AX5043s is set up. (Bob, I think you meant MIBSPI5SOMI_0 (Pin 99), not NCS. The console commands are
set pa on set pa off set ax on set ax off
In addition, all 5 AX5043s are set up to be able to interrupt. All interrupts from the Receive AX5043s send a message to the Rx task. The Tx 5043 sends a message to the Tx task. (If that is not correct it is set up in main.c with GPIOInit.
None of the above is tested other than that the commands above don't crash, and that "get gpios" displays the interrupt GPIOs.
This is upstream now as version X0.1s. I still want to fix the frequency adjustments so each Rx and be tuned individually. When I am done, I'll change to X0.2. I'm not going to do any merging, Chris.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Feb 9, 2024 at 5:50 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Ok, it makes sense it would be Rx. If there is just a way to poke a register to cause an interrupt, that is really all I need. I really don't want to (or know how to) debug lots of other stuff like ensuring that the Rx set up correctly if it is at all possible.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Feb 9, 2024 at 5:46 PM Chris Thompson chrisethompson@gmail.com wrote:
Great progress Burns. All sounds good.
The RX uses the interrupt, so that will need to be setup for all 4. To test it you need to send it a packet I suppose...
The TX should have an interrupt configured but we don't use it so far. But we need it to support packets longer than 255 bytes. That is important if we want to add FEC bytes.
On the branches we should create a launchpad one from main before we merge blinky into main. And or add a release Tag for launchpad. Then, as long as we don't change the HCG stuff in the launchpad branch (or other incompatible things), we should probably be able to merge changes from launchpad branch back into blinky. If that is ever required.
73 Chris
On Fri, Feb 9, 2024, 17:31 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev@amsat.org> wrote:
I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I think that this has essentially everything that I planned to do (although see the end).
- I2c temp sensors working
- SPI access to AX5043 working. (Oh, I have not tested interrupts. I
don't know with the current setup how to make one. Tell me if it does not work and how to do something that SHOULD cause it to interrupt, and I will fix it.) 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my board and it does not have 3, but they all work on Bob's so I assume that is all ok. 4) All tasks are started. What they do is not my baliwick! 5) MRAM init routines are working. Depending on what you do, these will figure out how many address bytes are required (always 3 for blinky, always 2 for Launchpad, so that could be hard-coded). They will also figure out the MRAM size as well as the number of MRAM chips, and set up the chips so that the partitions do what they should. (II can't test odd configurations but 1 MRAM works and 4 works.)
New info: When starting on a brand new processor (and I'd recommend it on the current ones that we have been using), I don't think it will crash unless none of the MRAMs work. But the first thing you should do is to issue the command "init new proc". This will init a lot of MRAM stuff, including the default AX5043 frequencies for two of the 5043s (one Rx and one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq nnn" to raise and lower them. Save them with "save freq". Rebooting or "preflight init" will not change them.
If you do "get mram sr" to look at the status registers, that is an easy way to tell which MRAMs are present. The status register for those not present will read 0xff. The first one present will read 0x32. Others will just read 2. "get mram size" will also give useful info.
Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes
What I have left to do:
Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. Make a place to store them in MRAM, set default values, etc.
Check for even more stuff that can be removed. I think there are a number of unused commands which may have no code, but will still show up in help, for example.
Debug 5043 interrupts if there is a problem. Actually is it the case that only Tx uses interrupts and not Rx? If Rx, there is more to do to make all 4 of them work.
In the meantime, though, Chris and Jim, I think you can play with this as soon as you get a blink. One thing to note: Be sure to keep blinky and launchpad on separate branches. Especially the HalCoGen stuff is much different but also anything that knows how many MRAMs and how many 5043s there are. Those won't merge easily if at all.
I'll try to do at least the rx freq stuff tomorrow. I totally forgot about that until a few minutes ago.
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
participants (2)
-
Burns Fisher (AMSAT) -
Chris Thompson