Logo-amall

Implement a minimal Luos single core prototype.

Last active 5 years ago

12 replies

12 views

  • PI

    This PR aims at implementing a prototype of a single core Luos example. We will use the electric dog project for this.
    For this first draft we will limit ourself to the simplest case. All modules will live in the same Core (we will handle multi-core examples later). Thus, no message to handle communication between cores is needed right now.
    A simple proto-app will be written (as the electric dog behaviour) to show how to use module both as sensor and effector. A simple app will also be written as a demonstrator
    We should implement:

    a module Trait as guideline for writing new modules
    a connection with @csagonero Hal crate
    documentation for the module and core
    basic integration and unit tests (tracked in #11)

    The luos core is rather empty at the moment. It actually only enforce for an alias method on the Module trait and provides an empty register method. It will mainly be useful as integration test for future versions.

  • PI

    I've written a first very simple draft to show how this single core case could be implemented. The main entry point is in the example file.
    A few improvement/fix planned:

    It still missing the alias in the module.
    Maybe the core could automatically update all local modules? I'm not sure this is a good idea as you could want to update module at different frequency.
    I've also used a faked Hal for the moment with simple digitalread and digitalwrite functions. It should be replaced with @csagonero HAL.

  • NI

    In this case why is the update necessary? I mean in your mind is this something optional or all modules need to have this "update" function?

  • PI

    Typically the update method is where you should update your internal state from the hardware. You can check this as an example: https://github.com/pollen/luos/blob/button-led-demo/src/module/button.rs#L44
    I'm not quite sure yet if this should be mandatory or not. At the moment, all modules must implement it.

  • MA

    How could you handle the app behavior with callback ?
    More like a trigger on the "fire_button" input (maybe with interrupts) rather than a constant loop, that execute a specified function. You would no longer need to handle the state update.
    Yet I have no idea if it is way more complex to implement or just different.

  • JG

    To follow on @matthieu-lapeyre comments, I guess this can be solved by adding a callback subscription mechanism in the core. With a publisher/subscriber tools usable by each modules that needs to, and a 'check' mechanism in the core.update() that detect and trigger those events.

  • NI

    button doesn't always need callbacks, I think both of these mechanism need to be managed (interrupt and polling). We just have to give the choice to the developper and the user.
    For me the update function can be usefull for complexe modules who need regular (but not real time) computation. We don't have modules who need it for now I think.
    In the button case access to the state of the button is as long as read a variable.

  • PI

    First, the update and callback are really two different things.

    The update is where you put the code to handle the module "hardware" update (e.g. read the analog pin for my distance sensor and update the distance variable).

    The callback is a function that will be called on the app side when some event is triggered on the module side.

    I guess the confusion comes from the fact that at the moment I put both the module loop and the app loop together. I'll update the example with a comment to clarify this.
    Second, @matthieu-lapeyre I've not really put too much thought into the callback yet. I imagine having something like this at some point (I've added an issue #9 to track this):
    let button = Button::new(…);
    let led = Led::new(…);

    button.whenpressed(|| {led.on()}); button.whenreleased(|| {led.off()});

  • PI

    I've removed the update method from the Module trait as it seems it bring more confusion than it solves problem. At least for the moment, it was useless.
    We will see in future versions if we need it back and how we could do it better.

  • PI

    @jgrizou @matthieu-lapeyre @nicolas-rabault On my side, it's ready to be merged. If you can check!

  • JG

    It is good for me, should I click some place to validate?

  • PI

    Sorry you were not one of the reviewer. I've just added you.

Last active 5 years ago

12 replies

12 views