Struct CrcDriver

pub struct CrcDriver<'a, C: Crc<'a>> { /* private fields */ }

Struct that holds the state of the Crc driver and implements the Driver trait for use by processes through the system call interface.

Implementations

impl<'a, C: Crc<'a>> CrcDriver<'a, C>

pub fn new( crc: &'a C, crc_buffer: &'static mut [u8], grant: Grant<App, UpcallCount<1>, AllowRoCount<{ ro_allow::COUNT }>, AllowRwCount<0>>, ) -> CrcDriver<'a, C>

Create a Crc driver

The argument crc_unit must implement the abstract Crc hardware interface. The argument apps should be an empty kernel Grant, and will be used to track application requests.

Example

capsules::crc::Crc::new(&sam4l::crccu::CrcCU, board_kernel.create_grant(&grant_cap));

Trait Implementations

impl<'a, C: Crc<'a>> Client for CrcDriver<'a, C>

fn input_done( &self, result: Result<(), ErrorCode>, buffer: SubSliceMut<'static, u8>, )

Called when the current data chunk has been processed by the CRC engine. Further data may be supplied when this callback is received.

fn crc_done(&self, result: Result<CrcOutput, ErrorCode>)

Called when the CRC computation is finished.

impl<'a, C: Crc<'a>> SyscallDriver for CrcDriver<'a, C>

Processes can use the Crc system call driver to compute Crc redundancy checks over process memory.

At a high level, the client first provides a callback for the result of computations through the subscribe system call and allows the driver access to the buffer over-which to compute. Then, it initiates a Crc computation using the command system call. See function-specific comments for details.

fn command( &self, command_num: usize, algorithm_id: usize, length: usize, process_id: ProcessId, ) -> CommandReturn

The allow syscall for this driver supports the single allow_num zero, which is used to provide a buffer over which to compute a Crc computation. The command system call for this driver return meta-data about the driver and kicks off Crc computations returned through callbacks.

Command Numbers

• 0: Returns non-zero to indicate the driver is present.

• 1: Requests that a Crc be computed over the buffer previously provided by allow. If none was provided, this command will return INVAL.

  This command’s driver-specific argument indicates what Crc algorithm to perform, as listed below. If an invalid algorithm specifier is provided, this command will return INVAL.

  If a callback was not previously registered with subscribe, this command will return INVAL.

  If a computation has already been requested by this application but the callback has not yet been invoked to receive the result, this command will return BUSY.

  When Ok(()) is returned, this means the request has been queued and the callback will be invoked when the Crc computation is complete.

Algorithm

The Crc algorithms supported by this driver are listed below. In the values used to identify polynomials, more-significant bits correspond to higher-order terms, and the most significant bit is omitted because it always equals one. All algorithms listed here consume each input byte from most-significant bit to least-significant.

• 0: Crc-32 This algorithm is used in Ethernet and many other applications. It uses polynomial 0x04C11DB7 and it bit-reverses and then bit-inverts the output.

• 1: Crc-32C This algorithm uses polynomial 0x1EDC6F41 (due to Castagnoli) and it bit-reverses and then bit-inverts the output. It may be equivalent to various Crc functions using the same name.

• 2: Crc-16CCITT This algorithm uses polynomial 0x1021 and does no post-processing on the output value. The sixteen-bit Crc result is placed in the low-order bits of the returned result value. That is, result values will always be of the form 0x0000xxxx for this algorithm. It can be performed purely in hardware on the SAM4L.

fn allocate_grant(&self, processid: ProcessId) -> Result<(), Error>

Request to allocate a capsule’s grant for a specific process.

fn allow_userspace_readable( &self, app: ProcessId, which: usize, slice: ReadWriteProcessBuffer, ) -> Result<ReadWriteProcessBuffer, (ReadWriteProcessBuffer, ErrorCode)>

System call for a process to pass a buffer (a UserspaceReadableProcessBuffer) to the kernel that the kernel can either read or write. The kernel calls this method only after it checks that the entire buffer is within memory the process can both read and write.