[TriEmbed] TriEmbed Digest, Vol 8, Issue 7

[Scott Hall]

Good questions, all.  I embedded my answers below:

On 01/13/2014 03:10 PM, Charles McClelland wrote:
> Pete and all,
>
> Sorry I will miss tonight's meeting as I am very interested in the topic.  I
> look forward to watching the video of the session.  I just got my first
> Oshpark board in the mail today so this is a timely topic.  
>
> I have one suggestion for a future meeting which I will call software
> engineering and then explain what I mean.  As the sketches I write become more
> complex, I am running into some problems that may be of general interest:
> - When should I take functionality from the main body of the program to a
> function? to a library?

You want to consider breaking each "nugget" of effort or action into a
subroutine.  It will be far easier to follow your own intent and design later
when you come back to it, as well as show your code to others.

If you find that you want to do the same action over and over, then that action
begs to be in a library routine.  Libraries are for code chunks that are
repeated, and/or that provide a use or abstraction of a topic to other programs
(such as a motor driving library, or a temperature and humidity sensor library).

The idea of both of these is to separate low-level detail code from that of more
generalized code sections.  It helps with organizing your code, debugging it,
and reusing portions in multiple projects.

> - What is the best way to store and maintain the base functionality versus
> branches or forks.  For example, I write a wireless sensor sketch with one
> implementation for a temperature sensor and another for an accelerometer?

Don't think of it as branches and forks.  Think of it like this: you reach down
into your toolbox for a particular tool, use that tool, then take the item just
tooled and use the next tool on it, all the while shaping the item you are
working on.  In other words, think of it a series of steps and procedure.  You
build layers of procedures on top of one another.  Turning a stock on a lathe is
a good example, and makes a great metaphor for code.

> - When there are several libraries that offer similar functionality, what is
> the best way to determine which to use?  Don't expect a strict protocol here
> but would be interested in rules of thumb.

This is where you need to play analyst and engineer.  A hardware circuit has the
same problem, how do you select a transistor for instance?  If you look in some
of the older linear databooks, you find many possible transistors that might
work in your application.  You need to analyze the current requirements, the
type of the signal begin applied, what is the function at this point (switching,
amplification, modulation, filtering, etc), the frequency of the signal
(capacitance and impedance effects), whether you are needing it its saturated
mode or linear mode, bias voltage requirements, and so on.

For a library, you need to look at what you are trying to do, and does the
library simplify things for you, provide enough granularity and detail for what
you need, abstracts the nuggets of work that you need, makes you code more
simple or does it complexify things beyond your goals?

> - How do I handle the substitution of libraries for different target
> platforms.  For example, I had to substitute the TinyWireM library for Wire
> when I moved to an ATTiny and needed an I2C library - a real pain.

Sounds like you did it right -- and yes it indeed can be a real pain.  Your best
bet is to ask those around you (ie. us) what they might recommend.  Also read
and re-read literature, articles, and attend seminars on the subject.  Likely
someone else has gone through the pain before, and can save you effort or help
make the choice(s).

> - Should I be using a repository like Github and, if so, how is Github best used?

I strongly believe in maintaining one's own code in a code-versioning system for
a whole myriad of reasons, and git is one of the best of the ones I'd recommend.

That said, github is a good place to publicize and make available your project
to others.  However, a private repository makes more sense while you are in
early development.  That said, you might want to to collaborate with others on a
project.

> - Are there some things I should do to make my code more compact or efficient
> once I have it working as expected - something like readability vs efficiency
> in code?

There are a couple of good code-style and code standards books I could
recommend.  And DO NOT make the mistake of efficiency-vs-readability argument --
I can prove that the most efficient is indeed the most readable.  You want to
implement your code so you can come to it 6 months from now and know what the
hell you wrote -- called maintainability.  There are certain standards and
guidelines that if used for your code will make it easier for you and others to
follow it.  And I can make the argument that properly organized code, readable
and well structured code lends itself to being the most efficient code too.  I
do not believe on your trying to "optimize" your code into obscurity when a
compiler can likely do it better than you can.  If you are well structured, a
compiler can figure out what you are trying to do and optimize it for your.

> - Also, in reading this article
> <http://phys.org/news/2014-01-internet-poses.html> about the security of
> embedded systems - are there some security best practices for Arduino?

There are indeed some books on industry best practices -- one even titled "Traps
and Pitfalls" -- that can help you avoid various security mistakes, and to
"harden" the security of your project.

> If all this is too basic or has been covered, I apologize but wanted to throw
> out my suggestion in case there is a call for future agenda topics tonight.
>
> I am sorry I will mis tonight's meeting - I look forward to the next and thank
> you all again for your help and support.
>
> Chip
>

-- 
Scott G. Hall
Raleigh, NC, USA
ScottGHall1 at GMail.Com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140113/941bf71d/attachment.htm>