Home

Welcome to the TheBookProject-Public Wiki!

During a sabbatical (Nov 23 - Feb 24), I focused on writing a book to capture some of my skills that I have not found well documented in books. This wiki will share some of the book content, research notes, and lessons learnt.

Quick links

• The writing process
• Book content
  • Debugging general info
  • Debugging serial protocols

Book content

As a senior embedded engineer with a strong firmware background, I am very familiar with debugging my software by watching the hardware. I have seen many engineers with a software background struggle when debugging communications with a peripheral; they never look at the physical bus and get lost in data sheets. There is not any book out there about this subject. I have taken on the challenge.

My writing experience

I write extensively at work. I maintain wiki and README.md pages about our tools and development environment. I write requirements, specifications, test plans, API documentation and code comments. I write in plain text and markdown, native formats for wikis and code repositories. I admit that it has been some time since I wrote using Google Docs, MS Word or Pages. I have a mutt accent. I am British but have lived and worked in California for 30 years. As you can imagine, I bring idioms from both nations and can trip people up with my vocabulary.

Writing for work produces documentation that "does the job", but internal documentation does not go through the same rigorous review process as software. Every author leaves their voice in such semi-formal writing. We had an inclusive writing policy, avoiding cultural idioms. I've been here for 30 years, yet I still don't get most baseball or American football references. Writing for a book means that I have to be more formal and add a review process. I also need to make sure that a consistent style is followed, and make sure the flow is not only good across a 300-line wiki page but across a 300-page book. To facilitate this, instead of peer reviewers and professional editors, I am leaning on modern AI assistants.

As for the text entry tools. Rather than rely on revision tracking in a text tool I am using what engineers know best, a repository. I am staying with Markdown formatted documents. Markdown gives me the basics of being able to place diagrams in the text, and mark headings. I can split chapters and sections into separate files, and use tools to render them as PDFs or HTML pages.