Coding Tricks Summary

This page summarizes best practices and advanced techniques for programming on this system. Core idea: the main program handles scheduling, subroutines handle execution.

⚙️ System Features Review

Key Instructions

Instruction	Mnemonic	Function
`01`	JT	Digital Output: write value to GPIO pins
`09`	DZ	Conditional jump: if register value > threshold, jump
`0E`	ZY	Unconditional jump
`0C`	DY	Call subroutine (records return address, up to 16 levels deep)
`0D`	FH	Return from subroutine
`0F`	JS	Halt / stop
`10`	FZ	Assign: write to register
`11`	JFZ	Conditional jump: if register value ≠ threshold, jump
`15`	(rotate)	Bit operation / rotate instruction
`00`	(NOP)	Empty lines default to `00 0000 0000`, does nothing

Instruction Format

Each line format: line_number opcode P-0 P-1

P-0: First 4-digit HEX number
P-1: Second 4-digit HEX number

Target address positions for jump/call instructions:

Instruction Target Position Notes
DY P-0 Call subroutine, target address in first 4-digit HEX
ZY P-1 Unconditional jump, target address in second 4-digit HEX
FH Not needed System automatically records return address
JT Not needed Conditional jump, no target line address needed

Correct: DY 0060 0000 (call subroutine 0060, target in P-0)

Correct: ZY 0000 0005 (jump to line 005, target in P-1)

Instruction	Target Position	Notes
DY	P-0	Call subroutine, target address in first 4-digit HEX
ZY	P-1	Unconditional jump, target address in second 4-digit HEX
FH	Not needed	System automatically records return address
JT	Not needed	Conditional jump, no target line address needed

Input Signal Summary

Available input signals and their corresponding registers/instructions:

Signal Type	Register / Instruction	Purpose	Value Range
Button	R3E	Button status register	`0000` = not pressed, `0001` = pressed
Temperature	R2E	Temperature sensor reading	0 ~ 65535 (depends on actual sensor)
Color Sensor	R31	Red component value	0 ~ 255
	R32	Green component value	0 ~ 255
	R33	Blue component value	0 ~ 255
Analog Input (ADC)	AD instruction	Resistive sensors (light, sound, etc.)	`AD 0000 XXXX` reads channel 0 to register
		e.g., sound sensor, photo resistor, potentiometer	0 ~ max (hardware dependent)
Digital Input (GPIO)	14 instruction	Digital pin level reading	`0000` = low, `0001` = high

Output Signal / Module Summary

Available outputs and their corresponding registers/instructions. Below is a detailed breakdown organized by hardware type:

Output Type	Instruction / Register	Purpose	Example
Digital Output (GPIO)	JT (01)	Control LEDs, buzzer, relays, simple peripherals	`JT 00FF 00FF` set all pins high
PWM Control	R2A, R2B, R2C, R2D	PWM duty cycle registers (0~03E8 = 0%~100%), control LED brightness, motor speed	Write 0000 ~ 03E8 to adjust (max 03E8 = 100%)
WS2812B LED	CD (E4)	Set full-color LED color, format CD 00RR GGBB	`CD 00FF 0000` red full brightness
Delay Control	YS (02)	Program delay/wait	`YS 03E8 0000` delay 1 second
Register to Output	SS (13)	Output register value directly to digital pins	For complex pattern batch output

Hardware Module Details

🔊 Buzzer (IO Control, No Tone)

Use a GPIO pin connected to a buzzer, toggle high/low to make sound:

Pin State	Effect	Register Value
Constant high	Silent	`0001`
Constant low	Silent	`0000`
Fast high/low toggle	Makes pulsing sound	Toggle in program

; Short "beep" from buzzer (connected to GPIO bit 2)
JT  00FF  0004   ; Buzzer low = sound (assuming low-level triggered)
YS  0064  0000   ; 100ms delay
JT  00FF  0001   ; Buzzer off
FH  0000  0000   ; Return

🌬️ Small Fan (L9110H Dual H-Bridge Driver)

The L9110H requires 2 pins to control one fan (A-IA controls speed/direction, A-IB controls direction):

A-IA	A-IB	Motor State	Description
PWM high	Low	Forward (speed adjustable)	Write speed value to A-IA PWM register
Low	PWM high	Reverse (speed adjustable)	Write speed value to A-IB PWM register
Low	Low	Coast stop	Motor slows naturally
High	High	Brake stop	Fast deceleration

; Fan forward, speed = 50% (assuming R2A=A-IA, R2B=A-IB)
FZ  002A  01F4   ; R2A = 01F4 (50%) → A-IA outputs PWM
FZ  002B  0000   ; R2B = 0 → A-IB stays low
FH  0000  0000   ; Result: fan forward, ~half speed

; Fan reverse, speed = 80%
FZ  002A  0000   ; R2A = 0 → A-IA low
FZ  002B  0320   ; R2B = 80% (0320) duty → A-IB outputs PWM
FH  0000  0000   ; Result: fan reverse, ~80% speed

; Fan stop (coast)
FZ  002A  0000   ; Both to 0
FZ  002B  0000
FH  0000  0000

Note: One L9110H chip can drive 2 independent motors (channel A and B), so controlling 2 fans requires 4 PWM pins.

🌈 External RGB LED (3 pins, IO or PWM Control)

Control red/green/blue with 3 independent pins:

Control Method	Wiring	Effect
Pure IO control	R/G/B to one GPIO each	Only 8 colors possible (on/off)
PWM control	R/G/B to one PWM pin each	Can mix ~16 million colors

; External RGB shows red (R pin → R2A, G → R2B, B → R2C)
FZ  002A  03E8   ; Red = max brightness
FZ  002B  0000   ; Green = off
FZ  002C  0000   ; Blue = off
FH  0000  0000   ; Result: pure red

; Show cyan (green + blue mixed)
FZ  002A  0000   ; Red = off
FZ  002B  03E8   ; Green = max
FZ  002C  03E8   ; Blue = max
FH  0000  0000   ; Result: cyan

; Breathing light gradient effect (red from dim to bright and back)
FZ  0025  0000   ; R25 = brightness counter, start at 0
FZ  002A  0000   ; First set red to 0
XDZ 0025  0032   ; Brightness + 50 (fine adjustment each step)
FZ  002A  0025   ; Write current brightness to R2A (red PWM)
YS  0019  0000   ; 25ms delay
DYZ 0025  03E8   ; Not at max brightness (03E8=100%) yet?
ZY  0000  022    ; Yes → keep increasing
ZY  0000  020    ; No → start over

🦾 Servo Motor (PCA9685 Module Driver)

The PCA9685 is an I²C-based 16-channel PWM expander chip — it uses only 2 wires (SDA data / SCL clock) to control 16 servos.

Feature	Description
Communication	I²C (2 wires)
Drivable servos	16 per module, chainable up to 62 modules → 992 total
PWM resolution	12-bit (4096 steps)
Typical servo frequency	50Hz (20ms period)
Servo pulse width	1ms = 0°, 1.5ms = 90° (center), 2ms = 180°

; Using PCA9685 to control servo angle
; Assuming system has I²C driver, configure PCA9685 registers to set servo angle
; Servo angle → PWM duty cycle mapping:
;   0°   → pulse 1.0ms → ~5% duty at 50Hz
;   90°  → pulse 1.5ms → ~7.5% duty at 50Hz
;   180° → pulse 2.0ms → ~10% duty at 50Hz

; Rotate servo to 90° (center position)
; Subroutine 0E0: Set channel 0 servo angle = parameter R20
; Here showing logic flow: send config data via I²C to PCA9685
0E0  FZ  0026  0040   ; PCA9685 I²C address = 0x40 (default)
0E1  FZ  0027  0006   ; Channel 0 register start = 0x06
0E2  FZ  0028  0000   ; PWM ON time = 0 (pull high from cycle start)
0E3  FZ  0029  0180   ; PWM OFF time = value for 1.5ms pulse (90°)
0E4  FH  0000  0000   ; Done via I²C register write

Why use PCA9685? Regular MCUs have limited PWM channels (typically 4-8), but PCA9685 expands to 16 PWM outputs with just 2 wires — perfect for multi-servo robotic projects. Servos themselves only need a PWM signal as position command, no continuous CPU intervention required.

Pin Resource Usage Overview

Module	Pins Required	Pin Type
Single buzzer	1	GPIO
1 fan (L9110H)	2	PWM × 2
2 fans (L9110H)	4	PWM × 4
1 external RGB LED	3	GPIO or PWM × 3
1 servo (via PCA9685)	0 (uses 2 I²C bus lines)	I²C shared
16 servos (via 1 PCA9685)	0 (still just 2 I²C bus lines)	I²C shared

Core Capabilities

16-level nesting depth: subroutines can call other subroutines, max 16 levels
Recursion supported: a subroutine can call itself
Empty lines default to 00: unfilled lines are not "blank" — they are 00 0000 0000 and the program will execute and pass through them in sequence

📐 Core Principles: Three Iron Rules

Rule	Description
① Each subroutine does one thing	Each subroutine starts with its logic at line 1. Never let a "return point" fall through into another subroutine
② Every logic path ends with FH/ZY/JS	No matter which branch your subroutine takes internally, it must eventually hit FH, ZY, or JS
③ Don't place subroutines contiguously	Keep buffer space (default 00 lines) between subroutines, making future expansion easier

🏗️ Architecture 1: Layered Design

Divide the line-number address space into three layers, organized like a "library."

Suggested Layout

~ 01F  →  Main program layer   (control flow, decisions, call subroutines)
~ 07F  →  Atomic ops layer     (frequently-called short subroutines, each does one thing)
~ 0FF  →  Feature module layer (complete feature modules, can call atomic layer)

Why Layer?

Benefit	Description
Main program is instantly readable	000-03F contains only "who to call, where to jump" — logic is obvious
Fix once, benefit everywhere	Improve the "delay subroutine" and everything using it automatically improves
Replaceable when space is tight	If a feature isn't needed, overwrite it without touching other modules
Room for expansion	Leave blank lines between layers — adding new features in 3 months won't require shifting existing code

📚 Architecture 2: Atomic Operation Library (020-07F)

Write your most-used operations as tiny 1-3 line subroutines. These are your "standard library functions."

Example: LED Control Subroutines

Mnemonic Form
Instruction Form

CD  0000  0000   ; Sub 040: Turn all LEDs off
FH  0000  0000   ; Return

CD  00FF  FFFF   ; Sub 048: Turn all LEDs on
FH  0000  0000

FZ  002A  0080   ; Sub 050: Set PWM defaults
FZ  002B  0080
FZ  002C  0080
FH  0000  0000

E4  0000  0000
0D  0000  0000

E4  00FF  FFFF
0D  0000  0000

10  002A  0080
10  002B  0080
10  002C  0080
0D  0000  0000

Example: Delay Subroutines

Mnemonic Form
Instruction Form

YS  03E8  0000   ; Sub 060: Long delay (~1 sec)
FH  0000  0000

YS  000A  0000   ; Sub 068: Short delay (~40 ms)
FH  0000  0000

02  03E8  0000
0D  0000  0000

02  000A  0000
0D  0000  0000

With the atomic library, your main program becomes minimal

Mnemonic Form
Instruction Form

DY  0048  0000   ; LEDs on (target in P-0)
DY  0060  0000   ; Wait 1 sec
DY  0040  0000   ; LEDs off
DY  0060  0000   ; Wait 1 sec
ZY  0000  0005   ; Loop (ZY target in P-1)

0C  0048  0000
0C  0060  0000
0C  0040  0000
0C  0060  0000
0E  0005  0000

📝 Trick 3: Parameter Register Convention

This is what makes subroutines truly powerful. Agree that certain registers are reserved for passing parameters — write them before calling, and the subroutine reads them.

Suggested Convention (customize as needed)

**R20** = Delay parameter    Write before calling; subroutine uses it for timing
**R21** = Display mode       0=normal, 1=alarm, 2=blink
**R22** = Target register    Which register the subroutine operates on
**R23** = Target value       Value to write/compare

Example: Generic Delay Subroutine

Mnemonic Form
Instruction Form

; Main program
FZ  0020  01F4   ; Write param first: R20 = 500ms
DY  0060  0000   ; Call delay subroutine

FZ  0020  07D0   ; Different param: R20 = 2 seconds
DY  0060  0000   ; Same subroutine! Different effect

10  0020  01F4
0C  0060  0000

10  0020  07D0
0C  0060  0000

Key insight: The subroutine doesn't need to know "why" we're delaying. It just does "whatever the agreed-upon location says." You change parameters, not subroutine code.

🔄 Trick 4: Recursive Programming (16 Levels Deep)

Since recursion is supported (a subroutine can call itself) with 16 levels of nesting, you can implement real recursive algorithms.

Example: Blink N Times Recursively

Mnemonic Form
Instruction Form

; Main program
FZ  0020  0005   ; R20 = blink 5 times (recursion counter)
DY  0010  0000   ; Call "blink" subroutine
JS  0000  0000

; Sub 010: Blink recursively (R20 = remaining count)
DYZ 0020  0000   ; If R20 > 0, continue
ZY  0000  0020   ; Else jump to 020 (return without doing anything)

CD  00FF  FFFF   ; LEDs ON
YS  01F4  0000   ; Delay
CD  0000  0000   ; LEDs OFF
YS  01F4  0000   ; Delay
XDZ 0020  0001   ; R20 = R20 - 1 (decrement counter)
DY  0010  0000   ; ← Call itself! Recursion!
FH  0000  0000

FH  0000  0000   ; Recursion terminator: return

10  0020  0005
0C  0010  0000
0F  0000  0000

0A  0020  0000
0E  0020  0000

E4  00FF  FFFF
02  01F4  0000
E4  0000  0000
02  01F4  0000
XDZ 0020  0001
0C  0010  0000
0D  0000  0000

0D  0000  0000

Execution Flow (with R20=5)

Call stack depth progression:

Level 0: Main → DY 010
Level 1: 010 → check 5>0 → blink once → R20=4 → DY 010
Level 2: 010 → check 4>0 → blink once → R20=3 → DY 010
Level 3: 010 → check 3>0 → blink once → R20=2 → DY 010
Level 4: 010 → check 2>0 → blink once → R20=1 → DY 010
Level 5: 010 → check 1>0 → blink once → R20=0 → DY 010
Level 6: 010 → check 0=0 → jump 020 → FH return
  ← Unwind: level 5 FH → 4 FH → ... → level 1 FH → main

As long as your counter doesn't exceed 15, you won't overflow the nesting depth.

🛡️ Trick 5: Fall-Through Prevention for Subroutines

The most common bug: after returning from a subroutine, the program "falls through" in sequence into the next block of code, causing unintended execution.

Anti-Pattern (buggy)

Mnemonic Form
Instruction Form

010  DY  0015  0000   ; Sub 010: calls 015 (target in P-0)
                  ; ← NO FH! Returns to 011, then falls through!
011  00  0000  0000   ; Default empty line (00)
...
015  15  1101  0001   ; ← Gets executed TWICE!
016  FH  0000  0000

0C  0015  0000
00  0000  0000
...
15  1101  0001
0D  0000  0000

Good Pattern (correct)

Mnemonic Form
Instruction Form

DY  0015  0000   ; Sub 010: calls 015
FH  0000  0000   ; ← Must end with FH/ZY/JS!
                  ; Lines 012+ won't be reached via normal flow

15  1101  0001   ; Sub 015
FH  0000  0000   ; ← Must end with FH/ZY/JS!

0C  0015  0000
0D  0000  0000

15  1101  0001
0D  0000  0000

Bumper Guard Pattern (safer)

Mnemonic Form
Instruction Form

DY  0015  0000
FH  0000  0000   ; Normal return
JS  0000  0000   ; ← Bumper guard: stop if we somehow get here
JS  0000  0000
JS  0000  0000

15  1101  0001
FH  0000  0000
JS  0000  0000   ; ← Bumper guard

0C  0015  0000
0D  0000  0000
0F  0000  0000
0F  0000  0000
0F  0000  0000

15  1101  0001
0D  0000  0000
0F  0000  0000

📊 Complete Example: Full Architecture

Combining all the techniques above into one complete program.

Main Program Layer (000-01F)

Mnemonic Form
Instruction Form

FZ  0020  0000   ; Initialize status register
FZ  0021  0001   ; Direction register: 1=forward

DY  0080  0000   ; Call "read sensors"
DY  00A0  0000   ; Call "display status"
DY  00C0  0000   ; Call "check alarm"
DY  0060  0000   ; Call "delay"
ZY  0000  0010   ; Loop

01F  JS  0000  0000   ; Redundant halt (never reached, but reassuring)

10  0020  0000
10  0021  0001

0C  0080  0000
0C  00A0  0000
0C  00C0  0000
0C  0060  0000
0E  0010  0000

01F  0F  0000  0000

Atomic Operations Library (040-07F)

Mnemonic Form
Instruction Form

CD  0000  0000   ; Sub 040: Clear LEDs
FH  0000  0000

CD  00FF  FFFF   ; Sub 048: Light LEDs (white full)
FH  0000  0000

CD  00FF  0000   ; Sub 050: Alarm LED (flash red)
YS  00FF  0000
CD  0000  0000
YS  00FF  0000
FH  0000  0000

FZ  0020  03E8   ; Sub 060: Delay (R20 controls duration)
YS  (R20) 0000
FH  0000  0000

E4  0000  0000
0D  0000  0000

E4  00FF  FFFF
0D  0000  0000

E4  00FF  0000
02  00FF  0000
E4  0000  0000
02  00FF  0000
0D  0000  0000

10  0020  03E8
02  (R20) 0000
0D  0000  0000

Feature Module Layer (080-0FF)

Mnemonic Form
Instruction Form

080  AD  0000  0010   ; Sub 080: Read sensors, store in R10
081  FH  0000  0000

0A0  AD  0000  0010   ; Sub 0A0: Display based on R10
0A1  JT  00FF  (R10)
0A2  FH  0000  0000

0C0  DYZ 0010  0032   ; Sub 0C0: If R10 > 50, alarm
0C1  DY  0050  0000   ; YES → call alarm subroutine
0C2  FH  0000  0000
0C3  DY  0048  0000   ; NO → normal display
0C4  FH  0000  0000

080  A0  0000  0010
081  0D  0000  0000

0A0  A0  0000  0010
0A1  01  00FF  (R10)
0A2  0D  0000  0000

0C0  0A  0010  0032
0C1  0C  0050  0000
0C2  0D  0000  0000
0C3  0C  0048  0000
0C4  0D  0000  0000

💡 Advanced: Condition-First vs Condition-Last

Two approaches to combining condition checks with subroutines — each has advantages.

Approach A: Condition-First (Traditional)

Mnemonic Form
Instruction Form

; Check in the main program, then call
DYZ 0010  0032   ; Main program checks: R10>50?
DY  0050  0000   ; YES → call alarm
ZY  0000  0014   ; Skip normal branch
DY  0048  0000   ; NO → call normal display
...

0A  0010  0032
0C  0050  0000
0E  0014  0000
0C  0048  0000
...

Feature: The main program worries about "decision logic" — code is scattered.

Approach B: Condition-Last (Encapsulated, Recommended)

Mnemonic Form
Instruction Form

; Main program just calls — decision lives inside the subroutine
010  DY  00C0  0000   ; Call "smart display" subroutine
011  ...

; Sub 0C0: Decides internally what to display
0C0  DYZ 0010  0032   ; Check condition inside subroutine
0C1  ZY  0000  00C4   ; >50 → jump to alarm branch
0C2  DY  0048  0000   ; Else normal display
0C3  FH  0000  0000   ; ← Return
0C4  DY  0050  0000   ; Alarm branch
0C5  FH  0000  0000

010  0C  00C0  0000
011  ...

0C0  0A  0010  0032
0C1  0E  00C4  0000
0C2  0C  0048  0000
0C3  0D  0000  0000
0C4  0C  0050  0000
0C5  0D  0000  0000

Feature: The main program stays clean forever. Decision logic is hidden in the subroutine. Changing thresholds doesn't touch the main program. This is the recommended pattern for large programs.

📋 Quick Checklist

After writing code, verify against these items:

Check	Description	OK?
Does every subroutine end with FH/ZY/JS?	Prevents program "fall-through"	☐
Is your main program just DY/ZY/JS calls?	Main program should be a "calling list"	☐
Recursion counter ≤ 15?	Max 16 nesting levels — keep 1 for main	☐
Register usage follows your convention?	Don't let two subroutines share a register for different purposes	☐
Are there buffer lines between subroutines?	Default 00 lines = your buffer	☐
Are DY targets in P-0 and ZY targets in P-1?	DY=P-0, ZY=P-1, FH/JT don't need target	☐

🎯 The Goal

When your code looks like the example below, you've fully mastered this architecture:

; Main program (you can understand the entire program at a glance)
DY  0080  0000   ; Initialize (DY target in P-0)
DY  0090  0000   ; Read input
DY  00A0  0000   ; Make decision
DY  00B0  0000   ; Output result
DY  00C0  0000   ; Delay
ZY  0000  0001   ; Loop (ZY target in P-1)

; ↓ HOW things are done lives entirely in subroutines

The main program becomes a "configuration table". You're not writing code — you're writing a directory of "which features to call." Three months from now, you'll glance at it and instantly know the whole program's intent.

🌟 Complete Example: Smart Environment Monitoring System

Below is a comprehensive example combining multiple inputs (temperature, sound, button) and multiple outputs (external RGB LED, L9110H fan, IO buzzer, PCA9685 servo), demonstrating how to implement a "smart room environment monitoring system" using the layered architecture.

Feature Description

Feature	Trigger Condition	Action
Temperature Monitoring	R2E > threshold 1 (e.g., 30°C)	Start fan (L9110H) + RGB LED shows red
Temperature Alarm	R2E > threshold 2 (e.g., 40°C)	Fan full speed + IO buzzer "beep beep beep" alarm
Ambient Brightness	Analog input (ADC channel 0) < threshold	External RGB LED shows warm white (R2A/R2B/R2C three-channel PWM)
Button Control	Button pressed (R3E = 0001)	Toggle manual/auto mode + servo rotate 90° to open curtain
Noise Alert	Analog input (ADC channel 1) > threshold	RGB LED quick blue flash

Hardware Wiring Convention

; PWM pin allocation (R2A-R2D connected to different peripherals):
;   R2A → External RGB LED R channel (PWM dimming)
;   R2B → External RGB LED G channel (PWM dimming)
;   R2C → External RGB LED B channel (PWM dimming)
;   R2D → Spare (can connect other PWM devices)
;
; L9110H fan driver (2 PWM pins):
;   GPIO bit 0 (A-IA) → Fan forward speed (controlled via PWM duty cycle)
;   GPIO bit 1 (A-IB) → Fan reverse direction (this example uses only forward, so fixed at 0)
;
; Buzzer:
;   GPIO bit 2 → IO-controlled buzzer (high/low toggle makes sound)
;
; PCA9685 servo (via I²C, no extra GPIO pins used):
;   Channel 0 → Curtain servo, 0°=closed, 90°=open

Parameter Register Convention

R20 = low temperature threshold (e.g., 30°C value)
R21 = high temperature threshold (e.g., 40°C value)
R22 = low brightness threshold (ADC channel 0)
R23 = noise threshold (ADC channel 1)
R24 = operating mode (0=auto, 1=manual)
R25 = temporary storage / status flag

Complete Program (Mnemonic Form)

Main Program Layer (000-01F): Scheduling Only

DY  0080  0000   ; Initialize: set default parameters
DY  0085  0000   ; Read all sensors
DY  0090  0000   ; Make decisions based on sensor values
DY  00A0  0000   ; Execute output actions
DY  00C0  0000   ; Delay/wait
ZY  0000  0001   ; Back to 001, loop monitoring

Initialization Subroutine (080-084)

FZ  0020  1E00   ; Temperature low threshold = 0x1E00 (~30°C)
FZ  0021  2800   ; Temperature high threshold = 0x2800 (~40°C)
FZ  0022  0500   ; Brightness low threshold = 0x0500
FZ  0023  0A00   ; Noise threshold = 0x0A00
FH  0000  0000   ; Return

Sensor Reading Subroutine (085-08F)

; Read analog input channel 0 (brightness/light), result to R2A
085  AD  0000  002A   ; ADC channel 0 → R2A

; Read analog input channel 1 (sound), result to R2B
086  AD  0001  002B   ; ADC channel 1 → R2B

; Copy temperature value (R2E) to R2C for easier comparison
087  JFZ 002C  002E   ; R2C = R2E (temperature)

; Copy button status (R3E) to R25
088  JFZ 0025  003E   ; R25 = R3E (button)

089  FH  0000  0000   ; Return

Decision Logic Subroutine (090-09F): Condition-First Pattern

; Check if button pressed → toggle mode
090  DYZ 0025  0001   ; R25(button) > 0 ?
091  ZY  0000  093    ; Not pressed → skip toggle
092  XDZ 0024  0001   ; Pressed → R24 = 1 - R24 (toggle)
093  XDZ 0025  0001   ; Clear button flag, avoid repeated triggering

; Check temperature → determine fan state
094  DYZ 002C  0020   ; Temperature > low threshold ?
095  DY  00B0  0000   ; Yes → fan-on processing
096  DY  00B5  0000   ; No → fan-off processing

; Check brightness → determine lighting
097  DYZ 0022  002A   ; Threshold > brightness reading ? (i.e., too dark)
098  DY  00BA  0000   ; Yes → turn lights on
099  DY  00BF  0000   ; No → turn lights off

; Check noise → flash alert
09A  DYZ 002B  0023   ; Sound > noise threshold ?
09B  DY  00C5  0000   ; Yes → flash alert
09C  FH  0000  0000   ; No → return

Output Action Subroutine (0A0-0DF)

; ===== Temperature-related (0B0-0B9)=====
; Note: Fan driven by L9110H, A-IA=GPIO bit 0 (PWM speed control), A-IB=GPIO bit 1 (direction)
;       This example uses only forward, so A-IB is always 0

0B0  DYZ 002C  0021   ; Temperature > high threshold ? (serious overheat)
0B1  ZY  0000  0B4    ; Yes → jump to serious alarm
0B2  FZ  002A  01F4   ; No → fan half speed (PWM=01F4 (50%)), adjust duty at R2A output bit 0
0B3  FH  0000  0000   ; Return
0B4  FZ  002A  03E8   ; Serious: fan full speed
0B5  DY  00D0  0000   ; Call buzzer alarm subroutine
0B6  FH  0000  0000   ; Return

0B7  FZ  002A  0000   ; Temperature not high: turn off fan
0B8  FH  0000  0000   ; Return

; ===== Lighting-related (0BA-0C1)=====
; Note: External RGB LED uses R2A(R)/R2B(G)/R2C(B) three-channel PWM for color brightness control

0BA  FZ  002A  03E8   ; R channel = max (warm white: red+green, blue slightly dimmer)
0BB  FZ  002B  03E8   ; G channel = max
0BC  FZ  002C  0320   ; B channel = ~80% (makes light warmer)
0BD  FH  0000  0000   ; Return

0BE  FZ  002A  0000   ; Turn off: all three PWM channels to zero
0BF  FZ  002B  0000
0C0  FZ  002C  0000
0C1  FH  0000  0000   ; Return

; ===== Noise Alert (0C2-0C9)=====

0C2  FZ  002A  0000   ; R = off
0C3  FZ  002B  0000   ; G = off
0C4  FZ  002C  03E8   ; B = max → blue flash
0C5  YS  0100  0000   ; Delay ~250ms
0C6  FZ  002C  0000   ; Blue = off
0C7  YS  0100  0000   ; Wait a bit more
0C8  FH  0000  0000   ; Return

; ===== General Delay (0C9-0CD)=====

0C9  YS  01F4  0000   ; Main loop delay ~500ms
0CA  FH  0000  0000   ; Return

; ===== Buzzer Alarm (0D0-0DB)=====
; Note: IO buzzer connected to GPIO bit 2, low-level triggered. Continuous "beep beep beep" three times

0D0  JT  00FF  0004   ; GPIO bit 2 = low → buzzer sound
0D1  YS  0032  0000   ; Sound 50ms
0D2  JT  00FF  0000   ; GPIO bit 2 = high → stop
0D3  YS  0064  0000   ; Interval 100ms
0D4  JT  00FF  0004   ; Second beep
0D5  YS  0032  0000
0D6  JT  00FF  0000
0D7  YS  0064  0000
0D8  JT  00FF  0004   ; Third beep
0D9  YS  0032  0000
0DA  JT  00FF  0000
0DB  FH  0000  0000   ; Alarm done, return

Architecture Explanation

The code above demonstrates these key techniques:

Minimal main program (000-005): only 6 lines — you can understand what the entire system does at a glance
Condition-first: subroutines internally check whether they need to execute (e.g., 094-09C), the main program doesn't need to worry
Modular layering: each function has an independent subroutine, modifying one doesn't affect others
Parameter register convention: R20-R25 all used for parameter passing, subroutines don't need to "re-read"
Clear line number partitioning: 080-084=init, 085-089=read sensors, 090+=decision output
Flexible multi-hardware control: L9110H fan with PWM speed control, RGB LED with three-channel PWM color mixing, buzzer with IO toggle sound, servo with PCA9685 I²C expansion

Compact Version (Practical Running Code)

If hardware resources are limited, you can write this more compact version (retaining core architecture):

; Main program
DY  0080  0000   ; Initialize
AD  0000  002A   ; Read brightness → R2A
AD  0001  002B   ; Read sound → R2B
JFZ 002C  002E   ; Read temperature → R2C
DY  0090  0000   ; Decision & output
YS  03E8  0000   ; 1 second delay
ZY  0000  001    ; Loop

; Initialize
FZ  0020  1E00   ; Temperature threshold 1
FZ  0021  2800   ; Temperature threshold 2
FZ  0022  0500   ; Brightness threshold
FH  0000  0000   ; Return

; Decision & output (condition-first, all together)
DYZ 002C  0020   ; Temperature > threshold 1 ?
FZ  002A  01F4   ; Yes → fan half speed (PWM 50%)
DYZ 0022  002A   ; Too dark ?
FZ  002B  03E8   ; Yes → green light on (ambient lighting)
FZ  002B  0000   ; No → green light off
FH  0000  0000   ; Return to main program

⚙️ System Features Review​

Key Instructions​

Instruction Format​

Input Signal Summary​

Output Signal / Module Summary​

Hardware Module Details​

🔊 Buzzer (IO Control, No Tone)​

🌬️ Small Fan (L9110H Dual H-Bridge Driver)​

🌈 External RGB LED (3 pins, IO or PWM Control)​

🦾 Servo Motor (PCA9685 Module Driver)​

Pin Resource Usage Overview​

Core Capabilities​

📐 Core Principles: Three Iron Rules​

🏗️ Architecture 1: Layered Design​

Suggested Layout​

Why Layer?​

📚 Architecture 2: Atomic Operation Library (020-07F)​

Example: LED Control Subroutines​

Example: Delay Subroutines​

With the atomic library, your main program becomes minimal​

📝 Trick 3: Parameter Register Convention​

Suggested Convention (customize as needed)​

Example: Generic Delay Subroutine​

🔄 Trick 4: Recursive Programming (16 Levels Deep)​

Example: Blink N Times Recursively​

Execution Flow (with R20=5)​

🛡️ Trick 5: Fall-Through Prevention for Subroutines​

Anti-Pattern (buggy)​

Good Pattern (correct)​

Bumper Guard Pattern (safer)​

📊 Complete Example: Full Architecture​

Main Program Layer (000-01F)​

Atomic Operations Library (040-07F)​

Feature Module Layer (080-0FF)​

💡 Advanced: Condition-First vs Condition-Last​

Approach A: Condition-First (Traditional)​

Approach B: Condition-Last (Encapsulated, Recommended)​

📋 Quick Checklist​

🎯 The Goal​

🌟 Complete Example: Smart Environment Monitoring System​

Feature Description​

Hardware Wiring Convention​

Parameter Register Convention​

Complete Program (Mnemonic Form)​

Main Program Layer (000-01F): Scheduling Only​

Initialization Subroutine (080-084)​

Sensor Reading Subroutine (085-08F)​

Decision Logic Subroutine (090-09F): Condition-First Pattern​

Output Action Subroutine (0A0-0DF)​

Architecture Explanation​

Compact Version (Practical Running Code)​