Fluidics refactor

[Prattbuw]

Refactor to support new fluidics system for the delphi behavioral apparatus.

[Poofjunior]

Let's use inline constexpr size_t instead where possible.

[Poofjunior]

We can get rid of these (in most cases) if we use this pattern inside of a read_any handler function:

// Convert address to output channel with pointer arithmetic.
const RegSpec& specs = HarpCore::reg_address_to_spec(address);
size_t channel = ((uint16_t*)specs.base_ptr - app_regs.analog_output_port_state);

It's not pretty, but it works.

The idea is that we already have the base_ptr, which is the array base address, so with pointer arithmetic, we can access everything else, since the data is contiguous. You just have to cast the pointer to the appropriate array element type.

(You probably want to use a static_cast instead of a c-style cast.)

Also: this function (HarpCore::reg_address_to_spec) might be specs not spec in the old core. Just FYI!

[Poofjunior]

You can use either sizeof(array)/sizeof(element) or std::size here in the delphi_controller.cpp.

See this example in the quac board (though I should've used std::size).

[Poofjunior]

I recommend a convention where you name functions that are callback functions as either: something_callback or something_cb or something_handler just to tip off future-you (and others!).

[Poofjunior]

I recommend refactoring this to a read_any_*/write_any_* handler function style, so you don't have to copy the function body thrice.

[Poofjunior]

I recommend a read_any_*/write_any_* pattern for the cam_0 and cam_1 functionality.

[Poofjunior]

Same comment here.

[Poofjunior]

Per our in person discussion, here's another way to implement this.

We can setup a class to memory map a continuously updated result that other entities can scoop up on their own time.

Here's an example of streaming 5 (4 + 1 internal) ADC values (4 pins + internal temp) to a fixed location in memory that gets constantly refreshed as fast as the adc can stream it.

The consideration you need to deal with is that you need to read it in one cycle and work off a copy. (The Treadmill does this.) If you can't do this, you need to push the data to a queue or possibly use std::atomic.

Refactoring in this way lets you make one flow detector instance per adc pin rather than having to think of them conceptually as a group.

[Poofjunior]

Per chatting and possibly moving this to core1, here are 2 examples.

• cuttlfish core1 loop
• quac board

If your interface is multicore safe, then you don't need to deal with passing settings back and forth between cores (a la the quac board), and your core1 loop becomes very simple. If not ( a la the cuttlefish), then you need to use queues or mutex locks to make sure the shared resources are multicore-safe.