README: split off getting_started page, reword & reorganize

[nsaulnier-ti]

The README.md is too long, with too much information. If we want customers to refer back to this page regularly for build instructions, we should not make them scroll past the single-use "getting started" steps every single time.

1. Move getting started information to getting_started.md

2. restructure the getting started information:
   2a) discuss MCU+ SDK vs Linux SDK, and split information by which SDK is used
   2b) split "install dependencies" into 2 sections: manual installation, and
   using the install script
   2c) add links from section to section to make it less likely that customers
   will skip over an important step on accident
   2d) Generate buildfiles explaination added

3. Restructure README.md

Future work: after the PRU Academy goes live

1. Add links to the PRU Academy throughout the README.md
2. Remove section "Steps to add a new OPEN PRU project", as this will be
   completely covered in the PRU Academy Getting Started Labs. This will
   cut the README file down to a managable length for customers.

[nsaulnier-ti]

@manojKoppolu & @jeremiasLehmann please review to make sure I did not mess up any of the intent for your documentation.

Outstanding questions:

1. getting_started > Generate buildfiles: Did I summarize this properly? Or was there a different intent?
2. README.md > Basic Building with CCS > Build flow: What is meant with this sentence: The PRU header file is moved to <open-pru/examples/pru_io/empty/firmware/device/>

[pratheesh-ti]

Feedback from CoPilot
Here are some options to improve readability of the README for a new user:

1. Add a Quick Start section at the top.

   • Provide 3–5 bullet points with the absolute basics and first steps for getting started (e.g., prerequisites, how to clone, initial build command).

2. Use clearer section headings and a Table of Contents.

   • The current navigation links are useful, but a numbered Table of Contents can help users quickly find what they need.

3. Summarize supported devices in a table.

   • Instead of a long list, use a markdown table for supported devices and links, making it easier to scan.

4. Add prerequisite and setup instructions before example builds.

   • Explicitly state required tools (CCS, make/gmake, MCU+ SDK), environment variables, and any installation steps.

5. Use syntax highlighting for code blocks.

   • For bash commands, use triple backticks with language specified:

     make -s -C examples/empty/firmware/am243x-lp/icss_g0_pru0_fw/ti-pru-cgt all

   • This makes commands easier to read.

6. Separate platform-specific instructions.

   • Group Windows and Linux instructions into separate subsections for clarity.

7. Add diagrams or workflow images.

   • Visual guides (e.g., build flow, file structure) help new users grasp the overall process.

8. Clarify technical terms and acronyms.

   • Briefly explain terms like PRU, R5F, EVM, CCS, etc., on first use.

9. Provide example output.

   • Show what success looks like after building (e.g., “If build succeeds, you’ll see…”).

10. Use concise, direct language.

    • Shorten sentences and avoid complex structures. For example, “Run this command to build all projects:” instead of longer explanations.

[pratheesh-ti]

Feedback from CoPilot

Certainly! Here are targeted recommendations to improve readability for new users of the
getting_started.md file in the TexasInstruments/open-pru repo:

---

1. Add a “Quick Start” Section at the Top

Provide a short, actionable summary for getting started. Example:

## Quick Start

1. Install the required SDK and tools for your platform (Windows/Linux).
2. Run the provided dependency install script, or follow manual steps.
3. Generate buildfiles using the correct make command for your device.
4. Build and run your PRU project!

---

2. Use Clear Section Headings and Numbering

Number major steps and use more descriptive headers, e.g.:

• 1. Supported Host Environments
• 2. PRU Initialization Overview
• 3. Dependency Installation (Manual & Script)
• 4. Generate Buildfiles

---

3. Streamline and Clarify Instructions

• Use short sentences and simple language.
• For each step, make sure it’s clear who should do it (Windows/Linux, MCU+/Linux SDK, etc.).
• Group platform-specific instructions into clearly separated blocks.

---

4. Add Prerequisite Checklist

Provide a bullet list of what users need before starting:

• Supported OS versions
• Required SDKs
• Node.js version
• Make/gmake tools
• Disk space requirements

---

5. Use Tables for Supported Devices and SDKs

Replace long lists with tables. For example:

Device	MCU+ SDK Download	Linux SDK Download
AM243x	Link	N/A
AM64x	Link	Link

---

6. Emphasize Key Commands and Outputs

• Use code blocks with syntax highlighting (bash, powershell).
• Bold or highlight essential commands and expected outputs.

---

7. Add Troubleshooting Tips

Briefly mention common issues and how to fix them (e.g., PATH problems, permissions, re-opening terminals).

---

8. Add Visuals/Diagrams

• Show workflow diagrams or images for installation steps.
• Visual file structure for where dependencies/tools should go.

---

9. Remove Redundancies and Excessive Details

• Move advanced or device-specific details to “Advanced Setup” or “Appendix” sections.
• Keep the main flow focused and direct.

---

10. Link to Additional Resources

Add links to official TI forums, SDK docs, or FAQ at the end for further help.

---

[nsaulnier-ti]

Feedback from CoPilot

1. Add a “Quick Start” Section at the Top

Done

2. Use Clear Section Headings and Numbering

Not appropriate for this document

3. Streamline and Clarify Instructions

Already organized like this. added explicit Windows / Linux to each section title.

4. Add Prerequisite Checklist

Information is already inline

5. Use Tables for Supported Devices and SDKs

Not appropriate for this document

6. Emphasize Key Commands and Outputs

Done

7. Add Troubleshooting Tips

Not appropriate now, can be added later as needed

8. Add Visuals/Diagrams

Not needed in getting_started, though something like this should be added to the README to help customers navigate

9. Remove Redundancies and Excessive Details

Already done, improving the flow and removing redundancy was the whole point of this commit.

10. Link to Additional Resources

Not appropriate for getting_started.