diff --git a/Makefile b/Makefile index fa35ebe..10df64d 100644 --- a/Makefile +++ b/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/ diff --git a/log/BACnet.text b/log/BACnet.text new file mode 100644 index 0000000..986bc92 --- /dev/null +++ b/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" +} diff --git a/log/content/bacnet_a1.content b/log/content/bacnet_a1.content new file mode 100644 index 0000000..65567ad --- /dev/null +++ b/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. \ No newline at end of file diff --git a/log/content/bacnet_q1.content b/log/content/bacnet_q1.content new file mode 100644 index 0000000..7f81442 --- /dev/null +++ b/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). \ No newline at end of file diff --git a/openocd-reboot.cfg b/openocd-reboot.cfg index cbb1691..bb70ea8 100644 --- a/openocd-reboot.cfg +++ b/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 diff --git a/reset_sifive_usb.sh b/reset_sifive_usb.sh old mode 100644 new mode 100755