Documentation of pr...
 
Notifications
Clear all

Documentation of projects or questions

32 Posts
7 Users
5 Likes
3,348 Views
Inst-Tech
(@inst-tech)
Member
Joined: 2 years ago
Posts: 554
 

@will , Yes, remember those days well...lol My first go at programing was on a Data Nova 1200 using BASIC and a TTY 30chr/s and paper tape for storing the programs...I wrote a Tic-Tac-Toe program to play against the computer..The course I was taking was for Electronics, but we were studying computer circuits and programming mock computers using  octal, and hex machine language..most of the fellows that were taking computer programming were using fortran, so I taught them BASIC in exchange for them teaching me Fortran..Now I'm trying to learn C++..never ends does it?..Being a little "old school" probably helps with picking up this newer technology. After all, back to the basic fundamentals will get you through the rough spots. enjoy your comments.

regards,

LouisR

LouisR


   
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2043
 
Posted by: @foxy

I would like to suggest a discussion of documentation.  This should consist of schematics (elementary diagrams), connection diagrams where justified and flow charts. There should be something on rules and conventions for schematics and flow charts and a bit on how to decide if and when wiring diagrams and flow charts are justified.

 I have seen many questions on this and other forums along the line of "I connected it up and it doesn't work. What's wrong?"  In many, if not most cases the problem is very simple and is made difficult only by the inability to communicate what is done and should be done.

Foxy

The problem as I see it is posters without any real electronic or programming knowledge trying to run before they can walk or to get someone else to work out the details of some one off project that interests them.  Thus they simply lack the language required to describe their problem.

Learning to read a schematic or programming code is just a basic requirement. I also believe in having a "high level" description of the hardware/software solution. This doesn't require understanding how a particular software function or IC works internally only its input/output requirements.

 


   
ReplyQuote
Page 3 / 3