Best way to handle multiple derived driver components?

[phillip-marks]

Hi, I'm new to F after being interested in using it for quite a while. I'm working on a project that will use multiple cameras with different interfaces in various hardware deployments. I want to develop a single CameraManager that implements command handlers, compression, and writing data to a file, and then create multiple instances of the manager, each with its own driver. The drivers would then handle a given camera vendor's specific interface, such as GigE or a custom TCP stream. As extra credit, I'd like to have one of the vendors write and test their driver, but not expose them to any F prime framework code. I'm considering several approaches to this using F prime components, all of which assume that CameraManager is an active F prime component with command handling, telemetry ports, etc.

1. Create a CameraDriver base class that CameraManager uses to execute calls to open, configure, and capture frames from the camera. Then modify instances.fpp to insert code for each CameraManager instance to instantiate a derived driver class and pass it as a reference at CameraManager construction or during the configure phase
2. Make a CameraDriver passive component and create multiple component implementations with command and data ports that can be connected to a CameraManager instance in the topology. During a capture, the CameraManager would attempt to pop frames from a command port and receive frames on an input port. The driver would handle allocating and deallocating frames using a BufferManager.
3. Don't make a separate driver class; instead, create different manager implementations for each camera type.

I'm currently working on implementing option 2, and I'm able to instantiate a CameraManager and CameraDriver, and connect their ports.

[LeStarch]

I am a fan of option 2. Multiple camera manager instances, controlling instances of camera drivers that are unique. You can bring-in the spirit of option 1 by defining a generic set of ports using a component interface, then have multiple camera driver components that use that interface alongside anything specific they need.

Here is an example:

1. https://github.com/nasa/fprime/blob/devel/Drv/Interfaces/I2c.fpp
2. https://github.com/nasa/fprime/blob/devel/Drv/LinuxI2cDriver/LinuxI2cDriver.fpp

In item 1 we define a generic I2C interface that will be used by any I2C driver, and in item 2 we use it for a specific Linux I2C driver.

[phillip-marks]

Alright. I'll stick to option 2. One other question. I see that you're using an interface for item 1, which will help with defining the interface between the manager and the driver. This leads me to another question. The manager will need to send a few commands to the driver to set parameters like gain and exposure. I'm currently using a port for each command between the manager and driver, but I'd like to know if there is a better way that doesn't involve making full-on commands.