Project Logs

Collapse

• Using GPIO

  Michiel TJampens • 3 days ago • 0 comments

  Because rtvals are in, and i figure people here prefer actual hardware I started on adding GPIO's.

  
  The code is fairly easy because i use diozero, just extend FlagVal and add a listerener for isr.
  Input does add a couple properties:
  

  • gpio name
  • idle level (low,high)
  • pullogic (internal,external,none) (if internal, idle is translated to pullup/pulldown setup)
  • debounce time

  And two custom arrows besides all the flag ones.

  • pressed for idle to !idle
  • release for !idle to idle

  All the code related  to gpio can be found here and the parser addition here. It's only about 200 lines in total so not much to talk about.

  Below is the method that accept the isr event. Not much to it, but just to show that because it contains a timestamp the debouncing can be done be comparing those instead of an actual timer.

  public void accept(DigitalInputEvent event) {
          //Logger.info("Trigger: " + event);
          var newState = event.getValue();
          if (event.getEpochTime() - lastTrigger < debounceMs) {
              lastTrigger = event.getEpochTime();
              return;
          }
  
          if (newState) { //FALSE -> TRUE
              raiseBlock.start();
          } else { // TRUE -> FALSE
              fallBlock.start();
          }
          value = newState;
          lastTrigger = event.getEpochTime();
      }

  Now that GPIO are added, next will be I2C. Those are already a part of dcafs for years, but got an update a couple of months ago so stuff like this is possible.
  

  This is how to read the current temperature from a AHT20 sensor, convert it to scientific values and store in memory. Given it's a bit like 'lite' pathforward, i figured it's a suitable step towards it.

  <i2cop id="sample" info="Get a temp/hum measurement">
  	<write reg="0xAC">0x33 0x00</write> <!-- Trigger a conversion -->
  	<read delay="100ms" reg="0x71" bitsplit="8,20,20,8"/> 
  	<store group="aht20">
  		<!-- 8bits  -> i0 -> status (ignoring) -->
  		<int i="0" name="status"/>
  		<!-- 20bits -> i1 -> raw humidity -->
  		<int i="1" name="rawhum"/>
  		<!-- 20bits -> i2 -> raw temperature -->
  		<int i="2" name="rawtemp"/>
  		<!-- 8bits  -> i3 -> crc (ignored) -->
  		<int i="3" name="crc"/>
  	</store>
  	<math>
  		<op>i1=(i1/2^20)*100</op> <!-- Raw humidity to percentage -->
  		<op>i2=(i2/2^20)*200-50</op> <!-- Raw temperature to °C -->
  	</math>
  	<store group="aht20" db="data:aht20">
  		<real i="1" name="humidity" scale="1" unit="%"/>
  		<real i="2" name="temperature" scale="2" unit="°C"/>
  	</store>
  </i2cop>

• Realtime Values added

  Michiel TJampens • 05/14/2025 at 15:15 • 0 comments

  Realtime Values aka rtvals added

  The first major step was writing the parser and adding tasks. That was described in the 'details'. It layed the groundwork for the 'active' side of diagrams. Meaning things that don't 'respond' but get triggered 'directly' (i know vague difference).
  

  This allowed for fairly straightforward addition of the first reactive component in the form of rtvals.

  In this update, realval and integerval were added. Which allows diagrams to react to updates of those. To take it a step further, I wanted derived values to be possible. The way i did this might be a bit odd... but it works (so far).

  Major difference with the active side is that condition blocks now get access to data within scope, which is the newly received value and the current value.
  

  Another new element is the math block, this requires a math parser, wanted to write my own and the result is explained here. It gets the same scope.

  But using the logic like it works in task wouldn't allow much flexibility. Which is why the update method inside a realval or integerval is this.

  public boolean update(double value) {
          var pre = preCheck.start(value, this.value);
          if (ignorePre || pre) {
              var res = math.eval(value, this.value, 0.0);
              var post = postCheck.start(value, this.value, res);
              if (ignorePost || post) {
                  this.value = res;
                  return true;
              }
          }
          return false;
      }

  This could be shown in a diagram like this:

  Those dotted lines are optional and taken care of by the parser.  It allows the use of the arrows on the conditional block without it affecting the update. The first one isn't used on the drawio side yet, but the second one is. If the condition block is placed in front of the Update real block, ignorePost is false. If after it, that becomes true. And just to not have to bother with null checks, no condtion is translated to a dummy one that doesn't do anything.
  
  Adding to that the earlier stated scope being available to both condition and math, and you get a setup that is really flexibile because those blocks are 'inside' the realval and get old and new data.

  Putting all that into action, allowed things like this:

  Incoming data refers to an update request for 'water_pressure', all the other values are updated because they are 'derived' from that val. Furthermore, as you can see in the bottom right, that's an 'active side' block, it's possible to start active sequences in an otherwise reactive diagram.
  
  If you wanted to put logic like that to use, an active side like this can be added. Active uses data updated by the reactive side to determine the sample rate of a sensor. The set/clear flag block is newly adding to make it visually clearer.But if you wanted it to be a bit more reactive, it would require the addition of a boolean val that can react based on an updated state. FlagVal was therefore added to the drawio options, with the option of 4 arrows that correspond to all the combinations of L and H.
  

  It's possible to take this a step further (but maybe to far) and get rid of the interval. This just keeps track of sample count instead of time passed.
  

  
  So now that the foundations are layed, it's possible to start on adding actual hardware. Next step is GPIO.

View all 2 project logs