Struct evegfx::EVE

pub struct EVE<M: Model, I: Interface> { /* fields omitted */ }

The main type for this crate, providing a high-level API to an EVE chip in terms of a low-level, platform-specific interface.

In order to interact with a real EVE chip you'll need to first select an implementation of Interface which you'll access the chip through. This will typically be an adapter to the API hardware for your platform. You can pass that interface object, along with a selected model, to this type's constructor.

After instantiating an EVE object, the first step would typically be to initialize it using its various initialization functions.

Since there are no real interface implementations in this create, the following example just supposes there's already an interface in scope as the variable name ei:

use evegfx::EVE;
let eve = EVE::new(evegfx::BT815, ei);

Implementations

impl<M: Model, I: Interface> EVE<M, I>

pub fn new(m: M, ei: I) -> Self

Construct a new EVE object for the given EVE model, communicating via the given interface.

Models are represented by empty struct types in this crate, such as BT815 for the BT815 and BT816 models. The different models all have a broadly-compatible API but later generations have additional functionality.

pub fn take_interface(self) -> I

Consumes the EVE object and returns its underlying interface.

pub fn borrow_interface<'a>(&'a mut self) -> &'a mut I

pub fn take_low_level(self) -> LowLevel<M, I>

Consume the EVE object and returns an instance of LowLevel that uses the same interface.

pub fn borrow_low_level<'a>(&'a mut self) -> &'a mut LowLevel<M, I>

pub fn start_system_clock(
    &mut self,
    source: ClockSource,
    video: &VideoTimings
) -> Result<(), Error<I>>

Sends commands to the device to configure and then activate the system clock.

If this function succeeds then the system clock will be activated and the device will have begun (but not necessarily completed) its boot process. You could use the poll_for_boot method as an easy way to wait for the device to become ready, albeit via busy-waiting.

The typical next steps are to first call configure_video_pins in order to configure the physical characteristics of the Parallel RGB interface, and then to call start_video to configure the video mode and activate the pixel clock.

pub fn poll_for_boot(&mut self, poll_limit: u32) -> Result<bool, Error<I>>

Busy-waits while polling the EVE ID for its ID register. Once it returns the expected value that indicates that the boot process is complete and this function will return.

If the connected device isn't an EVE, or if the chip isn't connected correctly, or if it's failing boot in some other way then this function will poll forever.

pub fn configure_video_pins(
    &mut self,
    mode: &RGBElectricalMode
) -> Result<(), Error<I>>

pub fn start_video(&mut self, c: &VideoTimings) -> Result<(), Error<I>>

Configures registers to achieve a particular graphics mode wLowLevel given timings.

You should typically call start_system_clock first, using the same timing value, in order to activate the system clock. Calling start_video afterwards will then activate the graphics engine with a pixel clock derived from the system clock.

If you call start_video with a different timings value than you most recently passed to start_system_clock then this is likely to produce an invalid video signal.

If this function succeeds then the display will be active before it returns, assuming that the chip itself was already activated.

pub fn new_display_list<F: FnOnce(&mut JustBuilder<'_, LowLevel<M, I>>) -> Result<(), Error<I>>>(
    &mut self,
    f: F
) -> Result<(), Error<I>>

pub fn coprocessor<W: Waiter<M, I>>(
    self,
    waiter: W
) -> Result<Coprocessor<M, I, W>, M, I, W>

Consumes the main EVE object and returns an interface to the coprocessor component of the chip, using the given waiter to pause when the command buffer becomes too full.

The typical way to use an EVE device is to initialize it via direct register writes and then do all of the main application activities via the coprocessor, which exposes all of the system's capabilities either directly or indirectly.

pub fn coprocessor_polling(
    self
) -> Result<Coprocessor<M, I, PollingWaiter<M, I>>, M, I, PollingWaiter<M, I>>

A wrapper around coprocessor which automatically provides a busy-polling waiter. This can be a good choice particularly if your application typically generates coprocessor commands slow enough that the buffer will rarely fill, and thus busy waiting will not be typical.

However, this will use more CPU and cause more SPI traffic than an interrupt-based waiter for applications that frequently need to wait for command processing, such as those which attempt to synchronize with the display refresh rate and thus could often end up waiting for the scanout to "catch up".