Barry Gershenfeld wrote:
>> USB was well thought out and is very useful.
>
> I got the same speech about PCI as an improvement over the ISA bus,
> making
> the world truly plug-and-play.  I guess I saw that as a frill, since I
> could configure hardware anyway.

PCI was a significant improvement over ISA.  Even if you understood what I/O
address and IRQ settings were, it was still a hassle to make sure none of
your devices collided.  And then it wasn't about the .01% of the people that
understood what hardware configuration was anyway.  PCI and USB are about
making things easier for the 99.99% of computer users who don't understand
the magic behind things.  It's also about reducing support costs and making
computers accessible to ever increasing numbers of morons, who ultimately
drive the prices down and indirectly pay a lot of our salaries.

Even though I do understand much of the magic behind the curtain, I like PCI
and USB as apposed to ISA and RS-232.  Understanding how it works still
doesn't tell me which I/O address to assign or whether I need a half twist
or straight cable between this device and that, or having to dig out or make
the right adapter cable because one device used a male DB-9 and the other a
female DB-15.  Good riddance.

Both PCI and USB achieve the better moron-level experience by pushing
complexity onto developers, but it's really not that big a deal.  USB is
actually a pretty nice way to connect even simple home brew devices to a PC.
The extra stuff on the micro and host ends only needs to be developed once,
then it can be used for lots of different projects.  I tend to use USB now
even for one off projects where a few years ago I would have used RS-232.

> Now, all of these claims do have
> their merits; it's just overkill for something like connecting a
> keyboard.

Not really.  You seem to think of USB as high overhead just because it
appears complex.  There are now plenty of micros with USB hardware built in
and firmware freely available.  Allowing you to plug something in and having
it just work isn't overkill.  You certainly can't do that with old RS-232
keyboards.  The dedicated keyboard and mouse ports on desktop PCs do just
work too, but it doesn't make sense for PCs with built in keyboards and
pointing devices to have such ports.  It makes more sense for such PCs to
have more of the general USB ports that you can plug in a keyboard and mouse
in those cases where you want to use external devices, but allow the same
ports to be used for other things when you are willing to use the built in
devices.

>> On the contrary, this is exactly the right time to read the datasheets.
>>  You
>> get the most bang for the buck by reading the documentation *before*
>> bumping
>> around in the dark wondering why nothing works.  Sitting down and
>> reading the datasheet may not be fun, but trying to debug something
>> without the proper understanding is a lot less fun and a lot more time
>> consuming.
>
> You should appreciate that not everyone learns the same way.

That's a lame argument I've heard too often.  All the really good engineers
I know have the sit down and read the datasheet first mentality.  Some
people don't have the patience for that or lose interest without a bunch of
instant gratification steps along the way, but that doesn't make it a good
idea.  Those kinds of people may eventually be able to do something useful,
but it's a good early warning indicator that they'll never be really good
engineers.  I've seen this too often, and the correlation is quite strong.

You can learn most of something by poking at pieces.  That may work, even be
desirable, in some disciplines, but not for detail oriented disciplines like
designing circuits and or writing firmware.  The problem with that you don't
learn all the things that are possible.  You may learn that a timer can be
used a certain way, but when faced with a new problem you have to have in
your head all the ways the timer could be used.  Without that, you wouldn't
think of looking in the timer chapter and realize it is a good solution to
the new problem because you've never seen a example of it being used that
way before.

> I will often work from the inside out.

But that doesn't make it a good idea.  This is a statement about you, not
about the method.

> So last week I was looking at the
> code, and I saw calls for the timer.  So I decided to investigate that.
> This brings me to
> the 32-bit Peripheral Library Guide (324 pages--did I mention I also
> have to learn a new compiler?) and I see the various timer functions.
> So, now to
> make sense of that I have to go to the datasheet (but do I want the part
> datasheet or the family datasheet?) where I find that the hardware for
> the timer hasn't changed radically, but then I think Microchip is
> designing the peripherals, so they at least should look familiar. So,
> then, the drill...
>
> - Read the datasheet section on the timer
> - Return to the library documentation, where now their calls and
> parameters should make more sense
> - Return to the program, where the use of the timer should make more
> sense.

This makes my point.  If you had read the datasheet first, then looked at
the library and the code, things would make sense from the start.  More
importantly, you'd know what was possible regardless of what this particular
app did and the library chose to surface.  You'd probably even find the
libary is largely pointless for those that have read the datasheet and can
handle the 5 to 10 lines of code it takes to set up most peripherals.
Peripheral libraries are mostly to give the impression that microcontroller
programming is easier than it really is.

> In this way, I can grok the thing an item at a time as I encounter each
> piece.

Exactly.  You won't know about the pieces you didn't encounter.  That may
work for understanding someone else's design, but is no good for
synthesizing your own design for a new problem.

>>  If you are looking for instant gratification, go find something other
>> than microcontrollers to play with.
>
> Homebrew aircraft, perhaps? ;)

I'm not sure what this is reference too, but it's funny you should mention
that since one of my side projects is making a piece of foam core fly, or at
least glide initially.  I've got a CAN side project to get to a certain
point first, then hopefully I can get back to this one in a few weeks.

If you just dropped a piece of foam core it would flutter to the ground like
a leaf.  Even if you gave it a initial push along a glide path, it would
quickly go into flutter mode.  Basically I want to make a flying wing from a
sheet of foam core.

The first pass will do a controlled glide only, meaning it won't have a
engine.  It won't have a tail either.  Way too many people have done that,
so it would be a lot less fun.  I know flying wings have been done before
too, but a lot less so on the hobby level and it sounds like a much better
challenge with more room for innovation.

In theory it takes 3 degrees of freedom to control a aircraft.  With a
vertical tail, you only need three control surfaces to provide those three
degrees of freedom.  I don't know if it can be proven mathematically, but it
looks to me like it takes at least 4 control surfaces when everything is in
a single plane.

I have two control surfaces on the trailing edge of each side of the wing,
for a total of 4.  Pitch and roll are easy, but yaw is more complicated
since it has to be achieved via drag.  But using the control surface to
create drag on one side also introduces forces in the other dimensions,
which then need to be cancelled out with the additional control surfaces.
This will make the control algorithms interesting.

I've thought about the algorithms and think I know how to approach this, but
I'm sure there'll be surprises along the way.  I'll probably plunk down a
dsPIC with enough PWM modules to make driving the hobby servos easy to allow
me to concentrate on the control algorithm.  The extra electrical power for
the dsPIC should be small compared to that required by the servos anyway.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist