Category Archives: Learning

And… here we are

Posted on by
11

This week what we have all been fearing has happened to me: GitHub Copilot generated code for me which seems to meet all the requirements but which I don’t understand very much at all.

To date GitHub Copilot for me has just been mostly a useful auto-complete tool and it hasn’t given me any code which I didn’t understand. But with this code (to control two different hardware timers/counters on my Arduino) I don’t really understand it at all. I have passing familiarity with some of the registers used because I saw them named in the datasheet (which I have only skimmed so far) but basically I don’t understand how this works.

It is tempting to ignore the fact that I don’t fully understand and move on, but there’s a part of me which wants to return to the datasheet so I can understand what every assignment GitHub Copilot offered actually does and what every value it calculated implies. Is that the best use of my time?

Controlling Arduino Uno with Serial commands

Posted on by
Reply

@kline helped me with Phase 1 of my Crustacean Chirpy Chip Challenge project, which I have completed (sort of). I got the programming done but I didn’t do all the reading (yet).

Note to self: My Arduino Uno knockoff identifies itself as a “QinHeng Electronics USB Serial” USB device.

This is my code:

enum state { OFF, ON, FLASH };

enum state state = OFF;

int blink_pin = 13;

void setup() {
  pinMode( blink_pin, OUTPUT );
  Serial.begin( 9600 );
}

void loop() {
  if ( Serial.available() > 0 ) { read_command(); }
  switch ( state ) {
    case ON :
      digitalWrite( blink_pin, HIGH );
      break;
    case OFF :
      digitalWrite( blink_pin, LOW );
      break;
    case FLASH :
      int pin = digitalRead( blink_pin );
      digitalWrite( blink_pin, !pin );
      delay( 500 );
      digitalWrite( blink_pin, pin );
      delay( 500 );
      break;
  }
}

void read_command() {
  String command = Serial.readString();
  command.trim();
  command.toLowerCase();
  Serial.print( "Command: " );
  Serial.println( command );
  if ( command == "on" ) {
    state = ON;
  }
  else if ( command == "off" ) {
    state = OFF;
  }
  else if ( command == "flash" ) {
    state = FLASH;
  }
  else {
    Serial.println( "Unknown command." );
  }
}

This is my setup:

The code which would actually implement the spec, as given:

void read_command() {
  char c = Serial.read();
  switch ( c ) {
    case 'a' :
      state = ON;
      break;
    case 's' :
      state = OFF;
      break;
  }
}

Embedded Systems with ARM Cortex-M Microcontrollers in Assembly Language and C

Posted on by
Reply

Today I learned about Embedded Systems with ARM Cortex-M Microcontrollers in Assembly Language and C (Fourth Edition) by Yifeng Zhu while watching Lecture 9: Interrupts on YouTube. The full list of associated lectures are here: Short Lectures.

Can a Directed Acyclic Graph always be put into the plane?

Posted on by
Reply

ChatGPT 4

User:

can a Directed Acyclic Graph always be put into the plane?

ChatGPT:

A Directed Acyclic Graph (DAG) can usually be drawn in the plane, but whether it can be drawn without any edges crossing (i.e., as a planar graph) depends on the specific structure of the DAG.

Planarity of a Graph:

A graph is considered planar if it can be embedded in the plane without any of its edges crossing each other. Not all graphs are planar. The planarity of a graph is generally tested using Kuratowski’s Theorem, which states that a finite graph is planar if and only if it does not contain a subgraph that is a subdivision of either the complete graph K5 (five vertices each connected to every other vertex) or the complete bipartite graph K3,3 (two sets of three vertices with every vertex of the first set connected to every vertex of the second set).

DAGs and Planarity:

  • Acyclicity: A DAG, by definition, does not contain any cycles. This property alone does not guarantee planarity, but it does simplify the analysis since any subgraph involving cycles can be ignored when considering potential K5 or K3,3 configurations.
  • Structure and Complexity: The more complex the connectivity of the DAG (especially in terms of vertex connectivity and the number of edges relative to the number of vertices), the higher the chance that it could contain a non-planar configuration. A simple DAG with a tree-like structure, where each node has a few successors, is likely planar. However, as the number of edges and vertices increases, and especially if the graph forms dense interconnections between nodes, it could potentially include subdivisions of K3,3, making it non-planar.

To determine whether a specific DAG is planar, one would typically either:

  1. Look for subdivisions of K5 or K3,3 directly,
  2. Use algorithmic tools that implement planarity testing algorithms (such as the ones based on path addition or cutting algorithms).

Therefore, while many DAGs can indeed be drawn in the plane without crossing edges, it’s not universally true for all DAGs; the specific structure and connectivity must be considered.