C51 Code Explanation & Teaching Visualization

What does C51 Code Explanation & Teaching Visualization do?

Transforms a complete C51 source program submitted by the user into teaching materials targeted at beginners in higher vocational 'Microcontroller Application Technology' courses. Source code integrity and readability are prioritized over graphic aesthetics; explanations are based on actual statements, not comments, filenames, or assumed circuits.

Input and Delivery Scope

• Default delivery is a Chinese PNG infographic, 1814×867 pixels, landscape, white background, suitable for placement below a PPT title. Default attempt is 1 page, with pagination added for readability; explicit user specification of page count or layout takes precedence.
• When the user requests only parsing, prompts, or planning, only that scope is fulfilled. Authoring this skill itself does not imply image generation; without actual code, examples or placeholder text are not treated as programs.
• Reads the complete code, program name (if any), image count, layout, and known circuit conditions. If code is missing, it must be requested; other reasonably inferable parameters are stated with default values and the process proceeds. Unknown active logic levels can be analyzed with explicit assumptions, or can simply display port bit states.
• Filename follows user input or explicit source code annotation; if unrecognizable, 'unnamed_program.c' is used and noted as a display name, not claimed as the original filename.
• Output is written to a separate result directory within the current task by default; user work is not written to the skill directory.

Immutable Source Baseline

1. Save the source file in its original bytes. For chat code, extract only the text inside code fences, preserving blank lines, indentation, and trailing newlines, and establish a baseline after saving. Different encodings must be explicitly decoded; substitution characters must not be used to swallow errors.
2. Record the filename, encoding, SHA-256, physical line count, content of each line, and the number of bracket characters. Bracket count, including those in comments/strings, is only a character audit, not a syntax check.
3. Do not rewrite identifiers, constants, comments, operators, brackets, or repeated statements. Do not optimize code or automatically add brackets. Do not insert ellipses within the source area. Errors are explained outside the diagram.
4. Default to preserving original line order and indentation. Line numbers and syntax coloring belong to the display layer and must not be written back to the source text. Tabs can be displayed expanded according to explicit tab stops, but original characters are retained for verification.
5. Pagination or dual-code columns must cover every line of the source file exactly once, with continuous numbering in the original order. Code snippets re-referenced in the explanation area do not count as source page repetition, but must be clearly distinguished.

Building Teaching Explanations Based on the Program

During analysis, read references/c51-analysis.md and organize based on the actual program:

• Input/output pins, types, variable initial values, and function responsibilities.
• The real relationships between initialization, main loops, conditional branches, blocking loops, and interrupts.
• Expression evaluation order, loop counts, shift/rotate operations, port values, and state changes.
• Whether key detection, debouncing, re-confirmation, wait-for-release actually exist, and whether a single press could trigger repeated actions.
• Known circuit facts, necessary assumptions, and parts that cannot be determined from the source code alone.

Each key explanation uses a format of 'directly quoted statement from source → statement function → actual effect'. Select only 3–6 knowledge points relevant to the current page, with functional summaries typically in 2–4 items. Do not fabricate knowledge points not present in the source code just to meet a count.

Layout and Generation

Before generating images, read references/rendering.md, which contains the rendering tool commands, teaching JSON format, and pagination rules.

• White background, thin border, rounded corner cards, with a safety margin of 20–30px on all sides. Code in blue theme; key explanations in green; operating effects in orange; flow in cyan. If there are no historical images, create based on these specifications and do not claim to have matched unseen historical works.
• Do not add an extra course title. The code card title displays the actual filename, with 'C Language (51 MCU)' and page number annotated on the right.
• The code area on the left typically occupies 55%–65% of the width, using a monospace code font with a fallback font supporting Chinese. Comments in green, keywords in blue/purple, literals in orange. Code and comments must not overflow, be cropped, or be crammed using minuscule font sizes.
• The right side contains program functions, key statements, hardware effects, and the actual flow, distributed across relevant pages; not all modules need to be repeated on every page. Long code can use dedicated code pages plus explanation pages.
• Prioritize running this skill's scripts/render_infographic.py for deterministic full PNG rendering. It is responsible for source line reading, pagination, line numbering, syntax highlighting, teaching cards, port LEDs, and flow nodes with connecting lines. Teaching content is written to JSON after your analysis; the tool does not infer semantics.
• If the script rejects output due to line width, text capacity, or layout constraints, adjust pagination or layout; use programmatic SVG/HTML or other tools if necessary to achieve the same source baseline and coverage verification. Do not truncate or silently shrink text to bypass failures.
• Regular cards, pins, LEDs, seven-segment displays, and arrows should be drawn programmatically, without needing image generation models. Use an available imagegen skill only when the user desires or the content genuinely requires bitmap illustrations; it can only handle non-code material. Do not let an image model redraw source code and then claim accuracy.
• If a user-specified page count cannot satisfy both completeness and readability, explain the required number of pages and the reason, offer explicit layout choices; do not arbitrarily delete source code. In automatic page count mode, directly adopt clear and readable pagination.

Verification and Delivery

1. Reconstruct the text from all source pages, perform a character-by-character comparison with the baseline, check for continuous line numbers, no duplicates, no omissions, original closing brackets, and trailing newlines. Keep a checklist of results.
2. Check program explanation, branch conditions, key behavior, and hardware states; LED levels, bit order, and direction must be consistent with known wiring or stated assumptions.
3. Open each final PNG image, check whether code, Chinese comments, flow nodes, and explanatory text are clear, with no overlap, missing characters, cropping, or misalignment; confirm the actual dimensions of each image.
4. Distinguish verification scope: source comparison proves input consistency; final pixel readability also requires visual inspection. Do not treat source hash or PNG hash as proof of OCR or semantic correctness.
5. Deliver the images along with a brief description: page count, source lines and main explanation content per page, actual dimensions, completed verification scope, identified source program issues, and hardware assumptions. Provide links to source baseline and manifest.json for review.
6. If only prompts, a code panel, or unverified drafts are obtained, clearly indicate the delivery status and do not call it a complete teaching infographic. When tools are limited, explain the actual limitations and what has been completed.