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*