Best approach to implement hardware-specific APIs?

[9a3eedi]

Hello,

I am pretty new to cFS, and I've gone throguh the tutorials. What's the general approach in cFS when it comes to working with hardware modules? Say I had an i2c module that I would like a cFS app to interface with. cFS does not provide i2c APIs from what I can tell, so should we:

1. interface with i2c directly via the OS or the BSP, bypassing CFS?
2. Implement a custom API and make it part of PSP or OSAL?
3. Use an existing framework in cFE/cFS that I'm not aware of?

Doing option 1 is the most straightforward way, but it would break the whole abstraction aspect of using cFS in the first place. Option 2 is possible, but then that API would probably be mission specific unless it gets included upstream, so it's not too abstract in the end.

I'm using i2c as an example but this could apply to any interface really, like SPI, RS-422, Spacewire, etc.

[jphickey]

Hi! This is the intent of the "iodriver" API. That is - it is a generic PSP API for device access, similar to ioctl(). Device actions are enumerated so they can be extended without actually adding new function calls, and also allows for transparently changing underlying devices with others that have more (or less) functionality. There are several general classes of device defined and an i2c bus (raw access) would be the datagram type. You can also implement a device access module for whatever is connected via i2c, such as an ADC or DAC.

Currently there is just one example of a device driver, which reads the CPU load on linux and is used by HS app for reporting the current system load.

[andy27182]

Hi,
I'm trying to use cfs to drive an LED device on the Raspberry Pi. I just saw this discussion. It seems that the PSP only provides a system call interface similar to ioctl. I think a complete example include a hardware driver registered on OS and an application uses PSP iodriver Interface to manage the hardware.
How could the application communicate with driver? Uses system call or method provided by PSP? I am still trying to complete the case and whether it is possible to provide a sample that uses cfs to drive an io device.

[9a3eedi]

I've been reading the iodriver code and examples provided in the PSP. In particular, the "sysmon" example is implemented for both Linux and RTEMS. In general, it makes sense. However, what is not clear to me is how it adds to portability.

If an app requires the "sysmon" functionality, then with the way it is designed, it is still dependent on a specific platform, because of the way the enumeration of the PSP modules work (as far as I can understand), and command codes for each module are defined with different macros. I could not find an example of an app that uses this functionality however, so perhaps I'm understanding it incorrectly. If it's not portable, I might as well just make a platform-specific non-portable app that provides the same functionality and avoids the PSP all together, which reduces the amount of effort.

For example, say I had an app that talks to an I2C device. There would need to be an I2C PSP module for the platform I have (for example, an ARM board), and the app would need to include it.
Say now that I would like to port that app to a new platform, for example a SPARC board. In theory, I should write a new I2C PSP module specific to that new platform that provides the interface to the I2C chip, and the app should just work, right? However, the app I wrote is dependent on the ARM PSP module, and I couldn't get it to work with the SPARC PSP module without rewriting the app. So how is it portable?

Also, what's not clear to me is to what extent things should be iodriver, and to what extent they should be apps. In the case of the I2C device, I would need 2 drivers: one to handle the I2C communication, and one to handle the actual interface with the device via I2C. So should those be PSP modules? Or should the I2C driver be a PSP module but the device interface be an app? or perhaps both of those should be apps?

[dmccomas]

This cFS Raspberry Pi LED Control project uses a cFS library to communicate with the GPIO and a cFS app to perform the LED control.

[andy27182]

Thanks, it's very helpful. pi_iolib can be used as a standard IO library in projects. gpio_demo is a typical cfs application and uses pi_iolib.
The current example is enough for me, but I still have some questions.

I noticed that iolib is essentially a linux library rather than a cfs library, using /dev/mem, which is a physical address mapping method provided by the linux operating system.

• Q1: Does it destroy the layered architecture of cfs, allowing applications directly accessing the api of the OS.

  Suppose:
  I guess using libs that calling the native API of the OS is an extension of the cfs framework and has greater flexibility. This type of lib is more similar to psp or bsp, But when i work on the psp or bsp, i found that the bsp or psp is based on the OS API as much as possible instead of directly operate physical address.
  The lib related to the platform can avoid the application directly call OS API. I am thinking of modifying the api names in iolib to CF_IOLIB_* which is consistent with the architecture API form.

• Q2:if cfs is applied to other rtos for peripheral control, is it the best practice to use a app+lib combination, (the lib is based on the host OS type).
• Q3: How to perform data operations through IO interrupts?

[dmccomas]

I don’t think the RPI example violates the architectural layering, it just results in a non-portable lib/app as show in the figure below.
Here are some architectural design thoughts.

1. If you want to abstract a class of devices across projects, then consider defining standardized software bus messages. How these messages are created and published is project specific.
2. Create a dedicated device app. If this app is the only device data consumer, then it could process the data. The Raspberry Pi GPIO_DEMO app is an example. If there are multiple data consumers or you want to decouple the data processing, device control, etc. from the interface then the device app could publish the data on the software bus and receive device commands from the software bus.
3. The device interface level is much more platform specific, and it depends on your hardware, board support package and operating system. The Raspberry Pi example uses a library because the GPIO is memory mapped. Joe mentioned ioctl(). Something else to think about at this level is control flow. A device app can use a higher priority child task to perform low level interface functionality.
4. Control flow also needs to be considered at the system level. If multiple activities need to be synchronized, then the scheduler app can be used to send time-based messages to coordinate activities. In addition, you could design your hardware to send a 1 Hz timing pulse to multiple devices.

[andy27182]

Thank you for your reply, I seem not fully understand your description, I'm trying to do a iosample, the following is some understanding from me based on your reply, not sure if it is correct.

Step 1. Develop a device-specific application and Define a class of device messages on the soft bus
Step 2. Use a specific lib library or iodriver to realize device operations, including data and control flow.

I read the code of the iodriver part, but I haven't fully understood the design ideas of this part yet. I found the linux_sysmon used iodriver so I read it too.
I guess the original intention of the design is to provide a iodriver abstract interface and the real operation is defined in iodriver_xx_io, but At present, the code in iodriver_xx_io.h is too short, and there is no operations with the actual device, and in the process of gdb, the code in the function CFE_PSP_IODriver_Command is not really executed, so the understanding of this part is not yet deep.

Step 3. When the application layer considers the control flow, use sch_app to send time-based messages to the custom device-specific application

The system's time-based message seems to have a maximum of 4Hz. Can this clock be higher frequence?
Regarding the hardware interrupt problem in the previous question, I am now solving it in the device driver, that is, I developed a character device driver /dev/sampleio first, register the interrupt function when the device is opened, and copy data between the kernel space and user space. The application layer lib has not been developed yet. My plan is using a lib app to operate /dev/sampleio for data reading and writing, and a device-specific application to process soft bus msg. Considering to add the iodriver part in the future.