If I Had a Hammer

The most important tip I can think of is to document what you do, both hardware and software.

When you get to the point you're writing code in several languages on several compilers for different projects,

it's easy to forget what formula you used for s subroutine, or what version of the program is in the machine today.

Always have a header in every file noting the last edit date, a change log, input and output variables, and any

derived formulas or assumptions about initial conditions.  I'm working on a project that uses NFC chips to track

software and hardware versions/changes.

Scott

Can I have a "yay" for rsc (Scott)!!!  If I had a nickel for every time I have had to review what I have done over the course of the project.., So often the thing that kills greatness is the paperwork, or lack of it. The old saying is "if you have an hour to cut down a tree, spend 45min sharpening the saw".  Preparation and design should happen before any hardware or software gets implemented.  All the decisions about having something done in hardware, or in software should be determined with both groups represented in the room as well. Also, make sure you have the expertise to work with the tools you want to implement. I was on a project that decided to use FPGA components for a bundle of the routing circuits, but ran into a bit of a block when it was discovered the one person that knew how to design the FPGA firmware had exited a month before integration testing.

Big time thank you,

Jack

EDIT: My reply was quite long, so I decided to create a separate blog post from it: Using spreadsheets (Excel) for simple computations and approximations

I think there will be a huge amount of information over time in this thread, so it will be more readable for newcomers.

David

Thanks jack.chaney56 for the coaxing.

The work mentioned in my post was done for a client that owns the IP, so any discussion will be devoid of details, but I can describe the process I went through in general terms

Actually, after reading rsc's post on the importance of documentation, which I completely agree with, and your follow up, I realized I would be relying on the quality of my own documentation to remember how I solved the tricky bits of getting an e^x equation into an 8 bit PIC.  I worked on this problem back in 2010, so I remember that I did it, and that spread sheets and lookup tables were involved, but the details are not readily accessible in my working memory.  This is a great case study to illustrate why good documentation is so important.

I have found the project files and started to reacquaint myself with the details.  Looks like we will soon find out if my documentation from 7 years ago was of sufficient quality to allow me to resurrect the methods and share them here.

I hope to post again in a few days with an explanation of how I solved the problem.

Mark A.

No big science happened there, I basically put all the constants, variables and the equation itself to a speadsheet and let the Excel calculate 10 000 values of an air pressure from 0 m to 10 000 m with a step of 1 m.

Then I calculated the pressure difference between each of the 1 meter zone and estimated the error. The trend line could also be added (as described in my previous comment) with some approximation. For implementation into a microcontroller, sometimes a simplified equation works, sometimes a lookup table.

I was only interested in destinations easily reachable by a tourist (ca. 0 - 2500 m) in that case

I wanted to emphasize that counting thousands of values to see the function behavior is just a matter of seconds for today's computers. And visualizing the data is often priceless.

This is one awesome discussion, especially since some of this info might be really helpful in one of my upcoming projects.

Kas

As we used to say, the job isn't finished until the paperwork is done!

Planning and the lack of documentation has killed more projects than I can count.

After all, what good is a great build if nobody can figure out how to use it. (yes this is in reference to my last road test report.)

DAB

For people doing this as a hobby, I remember a relatively innocent posting* that showed up about 26 years ago today. Happy Birthday Linux

Jack

* From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki

Hello everybody out there using minix –

I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I’d like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I’ll get something practical within a few months, and
I’d like to know what features most people would want. Any suggestions
are welcome, but I won’t promise I’ll implement them :-)

Linus (torvalds@kruuna.helsinki.fi)

PS. Yes – it’s free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that’s all I have :-(.

Wow! How awesome is that eh?

A friend handed me a printed copy of the posting when I got to work after Labor Day that year.  I've been hooked ever since (still have my old Yag CD).

Jack.