tstana / cubes-sw Goto Github PK

At least while the software is being used for CUBES, a command queue should be implemented. This is a means of making sure the user can issue commands to the FPGA while the FPGA is replying to another command.

Extensions to the Arduino-based OBC simulator should be implemented as independently as possible from the actual OBC simulator code. The latter resides in a separate repository and is generated (as of the time of writing of this issue) using a config file. The OBC simulator repository may change at a later date, at which point CUBES will need to regenerate the code for its OBC simulator. At that point, adding the extensions to the the newly-generated OBC simulator code may lead to headaches.

The process should be simplified by:

1. Moving extension code outside of code generated for the OBC simulator, e.g., in new files called extension.c and extension.h;
2. Modifying the main flie of the OBC simulator to contain calls to functions in extension.h;

All of these should be added to the obcsim/ folder of the repository.

More of a cosmetic change than anything else, but still nice to have for clarity.

The obcsim/ folder should be removed from this repository after #7 has been closed. The OBC simulator is something used along with the cubes-fw repository, so it makes more sense to have items related to the OBC simulator there.

My proposal is that we proceed as follows:

1. Implement extensions per #7
2. Test
3. Close #7
4. Move files related to extensions to the cubes-fw repository. NB: Check issue #5 in the cubes-fw repository for details on where they should be located
5. Remove obcsim/ from this repository

For now, the tree view for the FPGA registers is disabled, since the command doesn't work properly.

One of two actions is possible for the future:

• fix: the issue may be due to the gateware not properly answering to the command, or the software being too insensitive on the serial port to the wrong number of bytes being received;
• discard registers view: since the software may change to a SIPHRA control software rather than simply CubesControl, the registers view may be unnecessary and too hard to maintain. It may also not be very useful for debugging.

At the moment, I'm currently leaning towards the latter.

This issue is a dump of my ideas regarding the extension of the software for its usability in more advanced projects:

• create a SiphraDevice class which would hold the value of all the registers on the SIPHRA
• update the SiphraTreeWidgetItem class to use data from the new SiphraDevice class
• the SiphraTreeWidgetItem can be an MVC (Model-View Controller) type of class, with the SiphraDevice as its model and two different types of views:
  • one for the table view
  • another for the visual config view
• create a SiphraConfigDevice class which would implement the protocol communicating to the FPGA communicating to the SIPHRA. This class would replace the current CubesProtoUartPmod class.
• create an interface that one can implement with new device types later on; this interface would be a base class for implementing the MIST Space Protocol needed for CUBES, as well as whatever would be used for SPHiNX. This is the idea behind the currently unused ICubesProtocol class.

The histogramming function was at first implemented in a rush and was difficult to extend. This should be fixed by something along the following lines:

• Conceptualize a header for all histograms, including the old ones. The header would contain a type definition, maybe an integer that is incremented whenever a new histogram type is added, or later on when a user selects another histogram type (channel or all-channels) via a combo box. A first proposal for a header would be (but maybe something more intelligent would be good):

  H<int_type>

• Change the CubesControl software so that it adds the header type to the output histogram. This should be done in the on_actionExportHistogram_triggered() method. NB: There should be no need to cover previous histogram types for histogram exports at the time of writing of this issue.

• Change the on_actionImportHistogram_triggered() method to import old histogram types,

• Change old histogram files and check that they can be imported properly. Note that so far there have been two histogram types used, so one would need to either cover all of them, or drop them altogether. Perhaps the second option is the best, since the two types used so far were in used at a very incipient state of testing.