Christopher (@stoneymonster) and Elecia (@logicalelegance) discuss embedded systems education and project documentation. Elecia wrote about her love of notebooks on the https://www.embedded.fm/blog-index.yEd, for when you don’t have Visio. Asciiflow.com, for when you don’t have yEd (or you want to put diagrams in your comments)We talked about many different documents and tried to note design vs implementation, product vs engineering vs user, and why we wanted them. We didn’t mention mechanical things because, ya know, software engineers. Some documentation we mentioned:Product documentationSchematics with block diagrams and comments. Also a GPIO to function spreadsheet.UI flow when the system has a screens (Balsamiq for wireframe testing UIs)SW spec and design doc: what do we plan to build and what are the tricky partsSW configuration and SW developer docs: how to rebuild the computer that can build the code from scratch, also notes on debugging methodologyUser manual: Usually not written by SW but may need SW’s patient inputCode comments: Functions and files get 5Ws: who, what, why, when, where, and how. Who should call this?What will its effect be? (“What will it do” but not in line by line detail!) How does it work?Why does it work this way?When should it be called?Where are its parameters? (“What” works here too but “where” is nice to remind you to check your memory assumptions.)Repository checkin commentsStyle guide (Such as Google’s or PEP)Manufacturing docs and tests docsAdafruit and Sparkfun both write good documentation, writing to users about how to use their code. Elecia likes Adafruit’s sensor library as a good set of code to review (including how much is in their docs vs their code).
Christopher (@stoneymonster) and Elecia (@logicalelegance) discuss embedded systems education and project documentation. Elecia wrote about her love of notebooks on the https://www.embedded.fm/blog-index. yEd, for when you don’t have Visio. Asciiflow.com, for when you don’t have yEd (or you want to put diagrams in your comments) We talked about many different documents and tried to note design vs implementation, product vs engineering vs user, and why we wanted them. We didn’t mention mechanical things because, ya know, software engineers. Some documentation we mentioned: Product documentation Schematics with block diagrams and comments. Also a GPIO to function spreadsheet. UI flow when the system has a screens (Balsamiq for wireframe testing UIs) SW spec and design doc: what do we plan to build and what are the tricky parts SW configuration and SW developer docs: how to rebuild the computer that can build the code from scratch, also notes on debugging methodology User manual: Usually not written by SW but may need SW’s patient input Code comments: Functions and files get 5Ws: who, what, why, when, where, and how. Who should call this? What will its effect be? (“What will it do” but not in line by line detail!) How does it work? Why does it work this way? When should it be called? Where are its parameters? (“What” works here too but “where” is nice to remind you to check your memory assumptions.) Repository checkin comments Style guide (Such as Google’s or PEP) Manufacturing docs and tests docs Adafruit and Sparkfun both write good documentation, writing to users about how to use their code. Elecia likes Adafruit’s sensor library as a good set of code to review (including how much is in their docs vs their code).
Christopher (@stoneymonster) and Elecia (@logicalelegance) discuss embedded systems education and project documentation.
Elecia wrote about her love of notebooks on the https://www.embedded.fm/blog-index.
yEd, for when you don’t have Visio. Asciiflow.com, for when you don’t have yEd (or you want to put diagrams in your comments)
We talked about many different documents and tried to note design vs implementation, product vs engineering vs user, and why we wanted them. We didn’t mention mechanical things because, ya know, software engineers. Some documentation we mentioned:
Product documentation
Schematics with block diagrams and comments. Also a GPIO to function spreadsheet.
UI flow when the system has a screens (Balsamiq for wireframe testing UIs)
SW spec and design doc: what do we plan to build and what are the tricky parts
SW configuration and SW developer docs: how to rebuild the computer that can build the code from scratch, also notes on debugging methodology
User manual: Usually not written by SW but may need SW’s patient input
Code comments: Functions and files get 5Ws: who, what, why, when, where, and how.
Who should call this?
What will its effect be? (“What will it do” but not in line by line detail!)
How does it work?
Why does it work this way?
When should it be called?
Where are its parameters? (“What” works here too but “where” is nice to remind you to check your memory assumptions.)
Repository checkin comments
Style guide (Such as Google’s or PEP)
Manufacturing docs and tests docs
Adafruit and Sparkfun both write good documentation, writing to users about how to use their code. Elecia likes Adafruit’s sensor library as a good set of code to review (including how much is in their docs vs their code).