As usual, I will not be at the 2nd Thursday meeting. Here is where I am:
-The OS is running (a timer is flashing the lights, not to mention all the drives mentioned below depend on interrupts and OS semaphores -The low level SPI bus software to read/write the AX5043s appears to be working, along with the very basic test commands -The I2c access to the thermometers appears to be working along with the test command to read them. -The SPI bus to read and write the MRAM may be working. Bob seems to have access to two of the four MRAMs on his board. However, with the same software, I can access none of the ones on my board. I'm pretty sure there is one broken trace where I can measure it (to an intentionally missing MRAM), but that does not explain the other 3. I'm also not sure about the test and setup code for the MRAM. Bob seems to have some problems with the two of his that are working. The two not working could be software or hardware. I can't tell from a distance, but will look further when I get a board that even two MRAMs work on.
Just to be clear on what I can and will do: I know it was mostly my doing that got the busses working and put in the test code, so I want to make that all happen, in particular checking out the MRAMs. I'm also reasonably good at finding crashes and OS problems, so I'll make sure that all works. I have also removed even more code that was useful only for Golf and there are probably some commands which do nothing which I can also remove. Please note that there is NOTHING in this code that is ITAR related despite it having come originally from Golf.
I have already added a number parameter to the routines that access the 5043 since there are more of them now. However, I really have to get back to Golf and Fox+ and there are a lot of things that are just not in my baliwick, largely having to do with the details of sending and receiving and using the higher level 5043 routines. I'm assuming that Jim and Chris will carry on once I get the hardware access working. For example, there are several commands that would probably be useful, but which I'm don't feel competent to work on. The ones that I think of are as follows (I may not have them exactly right):
test pll -- this sweeps the frequency setting for one of the receive (2m) 5043 to ensure that it can lock on. This fails when the wrong (or no) inductor is present. It should probably be fixed to do each individual Rx, and maybe the Tx (although 70cm does not need an inductor).
test rx -- This actually transmits on the receive frequency using the receive 5043. The purpose is to allow us to find the correct frequency setting for receive by watching what frequency it transmits on. (Putting the exact number into the 5043 never gave the exact frequency so this lets us tweak the receive frequency to be "exact".) I'm not sure if it is possible to do this with the blinky board, but if it is useful, that needs to be changed to be able to specify the specific Rx chip.
And of course the actual packet code which I don't plan to touch :-) 73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*