Physical computing/Signalen en events: verschil tussen versies

Uit Lab
Naar navigatie springen Naar zoeken springen
Regel 63: Regel 63:
* https://thingflow-python.readthedocs.io/en/latest/
* https://thingflow-python.readthedocs.io/en/latest/
* https://github.com/mpi-sws-rse/thingflow-python
* https://github.com/mpi-sws-rse/thingflow-python
* https://micropython-iot-hackathon.readthedocs.io/en/latest/


Opmerking: de laatste activiteiten rond thingflow lijken van ca. 2 jaar geleden.
Opmerking: de laatste activiteiten rond thingflow lijken van ca. 2 jaar geleden.

Versie van 9 nov 2019 08:49

Physical computing
Arduino Basis
  1. Led-0: breadboard, LED, weerstand
  2. Blink-1
  3. Button-1
  4. Blink-freq: frequentie
  5. Blink-PWM: pulsbreedte-modulatie
  6. Analoge input

Een signaal heeft op elk moment een waarde. Voorbeelden van signalen:

  • het signaal dat aangeeft of een knop ingedrukt is of niet;
  • het signaal van een hart (electrocardiogram)
  • het signaal van een versnellingsopnemer (accellerometer)

<<figuur van een signaal>>

Een event heeft een waarde op één enkel (ondeelbaar) moment. Voorbeelden van events:

  • het indrukken van een knop (of: het loslaten van knop)
  • een hartslag
  • een stap
In het interface van een computer spelen events een grote rol: het indrukken van een toets, of van een muisknop; het aanraken van een touchscreen; zijn allemaal voorbeelden van input-events die door de interface-software afgehandeld worden.

Vaak kun je, met behulp van signaalverwerking, events detecteren (vinden) in een signaal. Bijvoorbeeld: in het signaal van de drukknop detecteer je het indrukken; in het hartsignaal (ECG) detecteer je de verschillende hartslagen; in het signaal van een versnellingsopnemer detecteer je de stappen.

Analoge en digitale signalen; bemonstering

Detecteren van events

Voor het detecteren van een event in een signaal hebben we, naast de huidige waarde van het signaal, een stukje van de signaal-historie nodig. In het eenvoudige geval van het indrukken van een drukknop hebben we aan de vorige waarde genoeg.

Afhandelen van events

De "normale" manier om een event af te handelen is door de bijbehorende handler-functie ("on event") uit te voeren. Dit is het model dat bijvoorbeeld bij grafische gebruikersinterfaces gebruikt wordt, zoals met JavaScript in de browser.

Events en automaten

Bij besturingstoepassingen maken we vaak gebruik van eindige automaten. De invoer- en uitvoertekens van een automaat komen dan overeen met invoer- en uitvoer-events.

Een eenvoudig voorbeeld is het aan- en uitschakelen van een LED met een drukknop. Bij elke druk op de knop schakelt de LED om: van uit naar aan en omgekeerd.

De automaat hiervoor heeft twee toestanden, 0 (LED uit) en 1 (LED aan). Er is 1 input-symbool: "push". Dit zorgt voor een overgang naar de andere toestand. Bij deze overgang hoort een output-symbol: van 0 naar 1: "led-on", van 1 naar 0: "led-off".

<<fig>>

Dit kunnen we op de volgende manier in een programma omzetten:

Events en messages (berichten)

Een andere manier om met events om te gaan is om deze om te zetten in messages (berichten). Deze berichten kunnen lokaal afgehandeld worden, of ze kunnen gecommuniceerd worden naar andere systemen, om daar af te handelen.

Een voordeel van messages is dat deze compleet asynchroon afgehandeld kunnen worden, zoals in het geval van NodeRed.

Een "blok" (node, thing?) voor het afhandelen van een message kan een (strikte) functie zijn, maar ook een automaat, met een eigen toestand. Een dergelijke automaat-blok kan meerdere event-streams als input hebben, of als output.

NodeRed

ThingFlow

Opmerking: de laatste activiteiten rond thingflow lijken van ca. 2 jaar geleden. Dat lijkt niet gunstig voor de continuïteit. Maar: de hele implementatie is niet erg groot, dit is relatief eenvoudig te onderhouden of aan te passen.

Thingflow voor de microbit? De implementatie is niet erg groot of ingewikkeld, het lijkt mij dat dit zou moeten werken.

Ik vind de naamgeving van ThingFlow in een aantal opzichten niet handig: (i) ik zou (in een IoT-omgeving) nodes voor de verwerking nooit "things" noemen; (ii) ik zou een OutputThing eerder "inputNode" noemen.