Merge branch 'jcarr' into devel

- Create a new log file and content files detailing the
  discussion about BACnet and Modbus protocols.

.gitignore

@@ -1,3 +1,4 @@
 *.swp
 go.mod
 go.sum
+*.pb.go

Makefile

@@ -15,7 +15,15 @@ goimports:
 
 test:
 	# GO111MODULE=off go run format_rich_log.go log/2025-08-20-rich.text
-	GO111MODULE=off go run format_rich_log.go log/2025-08-20-full.text
+	# GO111MODULE=off go run format_rich_log.go log/2025-08-20-full.text
+	GO111MODULE=off go run format_rich_log.go log/2025-08-20-final.text
 
 gemini-config:
 	cp ~/.gemini/GEMINI.md .
+
+gemini-go:
+	~/go/bin/gemini playback
+
+add:
+	~/go/bin/gemini --add log/BACnet.text
+	ls -lt ~/.config/gemini/

chat.proto

@@ -0,0 +1,24 @@
+syntax = "proto3";
+
+package main;
+
+message Row {
+        repeated string   fields          = 1;
+}
+
+message Table {
+        int32             columns         = 1;
+        repeated Row      rows            = 2;
+}
+message Chat {
+        bool              gemini          = 1;
+        bool              user            = 2;
+        string            content         = 3;
+        repeated string   mountpoints     = 4;
+}
+
+message Chats {                                 // `autogenpb:marshal` `autogenpb:mutex`
+        string            uuid            = 1;  // `autogenpb:uuid:9fd31f10-c25d-4d66-bc8d-5f6eb7c79057`
+        string            version         = 2;  // `autogenpb:version:v0.0.1`
+        repeated Chat     Chats           = 3;  // THIS MUST BE  Chat  and then  Chats
+}

log/BACnet.text

@@ -0,0 +1,12 @@
+uuid: "bacnet-log-01"
+version: "v0.0.3 go.wit.com/lib/protobuf/chatpb"
+Chats: {
+  from: USER
+  ctime: { seconds: 1724166000 }
+  ContentFile: "content/bacnet_q1.content"
+}
+Chats: {
+  from: GEMINI
+  ctime: { seconds: 1724166060 }
+  ContentFile: "content/bacnet_a1.content"
+}

log/content/bacnet_a1.content

@@ -0,0 +1,20 @@
+You've described the situation perfectly. The protocol you're thinking of for HVAC and industrial controls is almost certainly **BACnet** or **Modbus**.
+
+Both are foundational protocols in building automation and industrial control, and they share the same conceptual space as CAN bus does for vehicles.
+
+First, to clarify your other point: **CAN bus** (Controller Area Network) is exactly what it's called. It's a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer.
+
+Here is a breakdown of the industrial/HVAC equivalents:
+
+| Protocol | Primary Use | Physical Layer | Key Concept (How it's like CAN bus) |
+| :--- | :--- | :--- | :--- |
+| **BACnet** | **Modern HVAC & Building Automation** | Runs on many layers, but commonly **RS-485** (a 2-wire bus, like CAN) or Ethernet (BACnet/IP). | This is the dominant, open standard for complex building control (chillers, air handlers, lighting, security). It allows devices from different manufacturers to interoperate in a single system. |
+| **Modbus** | **Industrial Controls & Simple HVAC** | Also commonly runs on **RS-485** (Modbus RTU) or Ethernet (Modbus TCP). | This is the de facto standard for industrial devices. It's simpler than BACnet and is a master-slave protocol (one device polls, others respond), but it serves the same purpose of connecting sensors, drives, and controllers on a shared network. |
+| **LonWorks** | Building, Home, and Industrial Automation | Twisted Pair (Free Topology) | A strong competitor to BACnet. It's a peer-to-peer protocol, which is conceptually very similar to CAN's multi-master design, where any device can initiate communication. |
+
+### Which one are you thinking of?
+
+*   If you're thinking about a modern, large commercial building's entire automation system, the answer is **BACnet**.
+*   If you're thinking about the most common, simple, and widespread protocol for connecting industrial sensors, VFDs (Variable Frequency Drives), and basic controllers, the answer is **Modbus**.
+
+Given the direct comparison to CAN bus as a system-wide network, **BACnet** is the most likely protocol you're trying to remember for the HVAC world.

log/content/bacnet_q1.content

@@ -0,0 +1 @@
+there is a protocol used in HVAC and instustrial controls but I forgot what it is called. It is similar in concept to what the automotive industry uses called "canBUS" or "CAN BUS" (I'm not sure what that is called either).

openocd-reboot.cfg

@@ -1,4 +1,5 @@
-# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board
+# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v5)
+# Correctly handles separate JTAG and System resets to prevent timeouts.
 
 # ----------------------------------------------------------------
 # 1. Adapter and Board Configuration
@@ -6,6 +7,8 @@
 adapter driver ftdi
 ftdi channel 2
 ftdi vid_pid 0x0403 0x6011
+adapter speed 1000
+
 ftdi layout_init 0x0808 0x0a1b
 ftdi layout_signal nSRST -oe 0x0200
 ftdi layout_signal nTRST -data 0x0100 -oe 0x0100
@@ -15,40 +18,34 @@ ftdi layout_signal nTRST -data 0x0100 -oe 0x0100
 # ----------------------------------------------------------------
 transport select jtag
 set _CHIPNAME riscv
-jtag newtap $_CHIPNAME cpu -irlen 5 ;# P550 has an IR length of 5
+jtag newtap $_CHIPNAME cpu -irlen 5
 
-# Define the 4 P550 cores
 target create riscv.cpu0 riscv -chain-position $_CHIPNAME.cpu -coreid 0
 target create riscv.cpu1 riscv -chain-position $_CHIPNAME.cpu -coreid 1
 target create riscv.cpu2 riscv -chain-position $_CHIPNAME.cpu -coreid 2
 target create riscv.cpu3 riscv -chain-position $_CHIPNAME.cpu -coreid 3
-
-# Group the cores for simultaneous operations like halt/resume
 target smp riscv.cpu0 riscv.cpu1 riscv.cpu2 riscv.cpu3
 
 # ----------------------------------------------------------------
 # 3. Reset Configuration and Execution
 # ----------------------------------------------------------------
 
-# This is the key command. It tells OpenOCD that a "reset" should
-# assert (pull low) the nSRST signal.
-# srst_only: Asserts only nSRST, not nTRST (JTAG reset).
-# srst_pulls_trst: Informs OpenOCD that the board hardware ties nSRST and nTRST together.
-reset_config srst_only srst_pulls_trst
+# CRITICAL: Configure the reset strategy.
+# 'srst_only': The 'reset' command will only pulse the nSRST line.
+# 'separate':  Tells OpenOCD that nSRST and nTRST are independent signals.
+#              This allows the 'init' command to correctly reset the JTAG TAP
+#              (using nTRST) before trying to communicate with it.
+reset_config srst_only separate
 
-# Initialize OpenOCD and connect to the target
+# Initialize OpenOCD. This will now correctly reset the JTAG chain.
 init
 
-# Halt the cores to gain control
-halt
-
-# This command now triggers the nSRST signal as configured above.
-# It will pulse the reset line, causing a full hardware reboot.
-echo "!!! Pulsing system reset (nSRST) to reboot the board..."
+# Issue the system reset. Because of the config above, this will now
+# cleanly pulse the nSRST line, causing a hardware reboot.
+echo "!!! Issuing system reset to reboot the board..."
 reset
 
-# Optional: If you want the board to start running immediately after reboot
-# resume
+echo "!!! Board has been reset and should be rebooting now."
 
 # Exit OpenOCD
 shutdown