pulse counter using LPC1768 proving to very challenging

Jon Kirwan wrote:
By comparison, the ADSP-21xx worked _exactly_
> as the docs said.  Always.  Exactly.  Never a question about
> them.  The assembly (up to 3 instructions per cycle) was
> nice, too.

 That one was intriguing.  I was several pages into the manual before I 
realized that the sample code I was reading wasn't BASIC.  Never wound up 
working with one, though.  There was an ADSP-2105 at the other end of the 
product from me, once.

	Mel.

On Sun, 19 Jun 2011 21:26:36 -0400, Mel
<mwilson@the-wire.com> wrote:

>Jon Kirwan wrote:
>By comparison, the ADSP-21xx worked _exactly_
>> as the docs said.  Always.  Exactly.  Never a question about
>> them.  The assembly (up to 3 instructions per cycle) was
>> nice, too.
>
> That one was intriguing.  I was several pages into the manual before I 
>realized that the sample code I was reading wasn't BASIC.  Never wound up 
>working with one, though.  There was an ADSP-2105 at the other end of the 
>product from me, once.

The ADSP-2105 was their "value line" part.  Cheap at $5,
memory serving.  I used them.  I also have an ISA board
system with one installed on it where you can download code
and play a bit.  I did most of my work on an ADSP-2111.  A
somewhat higher priced spread than the 2105.  I liked them a
lot.  Learned some things from the books that ADI produced
for them, as well.

Jon

Jon Kirwan wrote:
> On Sat, 18 Jun 2011 20:25:34 -0700, Don Y <nowhere@here.com>
> wrote:
>> Do you want to dope your own silicon?
> 
> I have done that.  Were you aware of a Bell Labs kit to do
> just that, put out in the mid 1960's??  (I've done it since,
> with my own home-brew oven, as well, made with a nickel
> plated, water cooled chamber and halogen lamps.  Long story
> there, too.)


Holy smokes I can't believe you mentioned that Bell Labs kit.  It was to
make a silicon solar cell, and my dad and I worked through it when I was
about 12.  I remember actually being able to see a change in the visual
properties at the edge of the wafer which was possibly evidence of the
doped junction.

My dad and I built the furnace with fire bricks and *asbestos panels*
that you could freely purchase in a hardware store.

We got our wafer Ni plated, but never could get any evidence of current
production.  It was a lot of fun though.


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

On Mon, 20 Jun 2011 18:22:59 -0700, "Mr.CRC"
<crobcBOGUS@REMOVETHISsbcglobal.net> wrote:

>Jon Kirwan wrote:
>> On Sat, 18 Jun 2011 20:25:34 -0700, Don Y <nowhere@here.com>
>> wrote:
>>> Do you want to dope your own silicon?
>> 
>> I have done that.  Were you aware of a Bell Labs kit to do
>> just that, put out in the mid 1960's??  (I've done it since,
>> with my own home-brew oven, as well, made with a nickel
>> plated, water cooled chamber and halogen lamps.  Long story
>> there, too.)
>
>Holy smokes I can't believe you mentioned that Bell Labs kit.  It was to
>make a silicon solar cell, and my dad and I worked through it when I was
>about 12.  I remember actually being able to see a change in the visual
>properties at the edge of the wafer which was possibly evidence of the
>doped junction.
>
>My dad and I built the furnace with fire bricks and *asbestos panels*
>that you could freely purchase in a hardware store.
>
>We got our wafer Ni plated, but never could get any evidence of current
>production.  It was a lot of fun though.

It's amazing to find another who knew about the kit!!  It's
still available, I think.  At least, I had some contact a few
years ago with the husband/wife pair who bought up the rights
for the Bell Labs kits.  I should see if they are still alive
and kicking.

Jon

Hi Jon,

On 6/18/2011 11:07 PM, Jon Kirwan wrote:

> I said that the group's interests have moved away from my own
> over the years.  That's true.  I _also_ believe that as the
> processors used and tools applied increasingly look more like
> traditional, hosted programming environments found on
> workstations, to that degree it also is less and less a
> differentiating feature.  Taken to its limit, there will be
> no difference in embedded development and any other and no
> point in choosing to use the adjective anymore.

I disagree.  Because the type of application and demands
of the "user environment/experience" differ greatly in the
two worlds.

As I said, a user interacts with a "device" (thing) differently
than with a "computer" (desktop application).  Everything about
how and where he uses it is different.  When you use a desktop
application, you are (typically) investing much more effort
*trying* to use it as *you* intend.  OTOH, when you use a
*device*, the interface wants to be intuitive, second-nature,
unobtrusive, etc.

You don't have some (arbitrary) set of "user interface guidelines"
imposed by (e.g.) MS to adopt (ah, yes... we must support a
'cut' operation... and this must be initiated with these magic
keystrokes...).  Rather, you design the interface to fit the
application and *environment* in which you expect the device to
be operated.

You don't think in terms of long, drawn out "operational sequences"
(create alpha channel from mask, darken, multiply, flood fill)
but, rather, simple, short-lived exchanges.  (consider an
automobile:  the most "involved" driving activity is probably
parallel parking?)

Likewise, you know the user is far less forgiving of any
"misunderstandings" (or, *gasp*, screwups!) on your part.
When you turn the steering wheel left, the car had *better*
turn left!  By contrast, in the desktop world, the user
expects problems interacting with the application (either
because of a lack of familiarity with its intricacies, bugs
in the application or whatever)

Look at the design and interaction you experience when using an
iPod (or other "portable media player") vs. a desktop media
player experience.  Which is friendlier?  More intuitive?

The desktop player's "controls" probably "make sense" -- to
the developer and to the user -- yet they are nowhere near as
intuitive and unobtrusive as the portable media player.

[IMO, this is where most of apple's products fall down, big time!]

> The group here has had this debate here.  Long threads about
> it.  I'm not changing any of the position I took a decade
> back about any of this.  It's the same stand today.  What
> makes embedded development "embedded" to me are how the
> skills and tools are differentiated from workstation
> development.  That's the main point.  It's not about the end
> product.

That starts to sound elitist.  As if only a person who has
developed his own film can call himself a photographer.  You
may *lament* the fact that others can now *simply* do things
that were, previously, signs of supreme accomplishment in
the field.  But, that doesn't make them any less so.

> If a washing machine uses Windows 7 Ultimate and Microsoft
> writes the .NET objects used to do the hardware interfacing
> at a low level and then provides abstraction objects to the
> programmer, then this particular washing machine programmer
> is no more an embedded programmer -- even though it is a
> washing machine -- than would be any other .NET Windows 7
> Ultimate programmer dragging and dropping a few objects onto
> a form.

So, if *I* were to write that .NET program, it, *somehow*
makes it an embedded program?  (whereas it wasn't when *he*
did so?  Even though, chances are, *he* will get the .NET
program "more correct" than I?)

I've a friend from school who has *probably* more "embedded
devices" in use than most people I know.  I wouldn't trust him
to design a voltage divider -- or even solder two wires
together without *also* putting a wire nut on them!  He could
easily have been designing compilers or writing desktop
applications had he not "started" by writing code for
"computers that don't look like computers".  And, I suspect
he could just as easily transition to that world if he had
the interest -- despite his "embedded" (?) background.

> Others have instinctively asked the questions you have asked.
> But I have considered them and don't agree with them once I
> thought more on it.  It's not a useful dividing line.  Sorry,
> but that's the end of it for me.  What _is_ useful to know
> are the types of experiences, talents, and backgrounds
> required to _do_ development for some sphere.  And in that
> sense, embedded has real meaning the way I apply it.  It has
> almost no useful meaning the way you seem to suggest.
>
> I'll stop here.  There's more to this, but I didn't want to
> go too far.  If you are interested, I've posted on this topic
> before and with more of my views on it exposed.  Still
> available in google, I'm sure.

Hi, Don,

On Tue, 21 Jun 2011 08:09:07 -0700, Don Y <nowhere@here.com>
wrote:

>On 6/18/2011 11:07 PM, Jon Kirwan wrote:
>
>> I said that the group's interests have moved away from my own
>> over the years.  That's true.  I _also_ believe that as the
>> processors used and tools applied increasingly look more like
>> traditional, hosted programming environments found on
>> workstations, to that degree it also is less and less a
>> differentiating feature.  Taken to its limit, there will be
>> no difference in embedded development and any other and no
>> point in choosing to use the adjective anymore.
>
>I disagree.  Because the type of application and demands
>of the "user environment/experience" differ greatly in the
>two worlds.
><snip>

I disagree, as well.  What binds us is our experiences and
knowledge of tools and practices.  Who we _are_.  Not end
use.  I think we are talking cross-purposes, though.  I know
you get it.  I think we are just talking across each others'
bow, so to speak.  I'm talking about what it is to be a tool
developer not a tool user.

>> The group here has had this debate here.  Long threads about
>> it.  I'm not changing any of the position I took a decade
>> back about any of this.  It's the same stand today.  What
>> makes embedded development "embedded" to me are how the
>> skills and tools are differentiated from workstation
>> development.  That's the main point.  It's not about the end
>> product.
>
>That starts to sound elitist.

That's probably my fault.  Bad writing.  But it's not.

I have a great deal of respect for Windows programmers, for
example.  I am one, as I have been programming nationally-
sold Windows programs since about Windows 3.0 (learned on
Win286 and Win386.)  I'm working on such a product this very
year, in fact.  So I'm not talking about lofting embedded
coders above Windows coders.  That would be crazy.

I just happen to know, quite well, that "who I have been" as
a Windows programmer is quite a lot different than "who I
have been" as an embedded programmer.  I include both types
of people inside me and reject neither of them.  But I simply
see within me two different skill sets and talents arranged
in different priority arrangements, when wearing one hat or
another.  The embedded side requires a far wider range of
skills, but not a "better" range.  There is no "better."

I readily admit I _prefer_ the embedded side of work.  That's
personal.  If you feel that is elitist, I can't help that.

>As if only a person who has
>developed his own film can call himself a photographer.  You
>may *lament* the fact that others can now *simply* do things
>that were, previously, signs of supreme accomplishment in
>the field.  But, that doesn't make them any less so.

Why would I care, Don?  Doesn't matter to me that others have
their interests and desires, different from mine.

But to use your example, that doesn't mean that a person who
owns a camera and doesn't know anything about developing film
will be someone that a film developer necessarily lumps into
their own social group.  If you imagine conflating these two
things into the same mush, I guess I then understand your
confusion about where I'm coming from.

I don't mean to be abrupt about it, but it is obvious to me
this way you write here isn't a useful way to divide things.

Put simply, if I wanted to waste my precious reading and
responding time on Windows and Linux programming issues, I'd
go find a Windows or Linux group.  They already have plenty
of places, in fact, for a wide variety of special interests
in their own categories.

In any case, I like your discussions here.  They sing to me
and I understand them pretty well and enjoy the issues
brought out by them.  Just so you know.

>> If a washing machine uses Windows 7 Ultimate and Microsoft
>> writes the .NET objects used to do the hardware interfacing
>> at a low level and then provides abstraction objects to the
>> programmer, then this particular washing machine programmer
>> is no more an embedded programmer -- even though it is a
>> washing machine -- than would be any other .NET Windows 7
>> Ultimate programmer dragging and dropping a few objects onto
>> a form.
>
>So, if *I* were to write that .NET program, it, *somehow*
>makes it an embedded program?  (whereas it wasn't when *he*
>did so?  Even though, chances are, *he* will get the .NET
>program "more correct" than I?)

You miss my point.  This is why we are talking at cross
purposes.  As I just wrote, I __like__ reading your posts.
That won't change at all just because you write a .NET
program.  Cripes, __I__ write .NET programs, for gosh sake. I
like to think that I'm still an embedded programmer.  My soul
doesn't change.

I enjoy the kinds of challenges, and seeing the kinds of
interesting solutions to them, that deeply embedded
development entails.  That's why I'm here.  Those challenges
often bring people with similar interests together.  I like
that fact.  To the degree that this group changes its
discussions towards .NET or Linux development, to that degree
I will read less and participate less.

Not because I don't do that development work -- I do -- but
because my personal interests lay elsewhere.  And not because
I mean to judge it harshly -- I don't.  But I don't define
myself as a Windows programmer, despite the fact that I've
now 25 years of such experience mixed within 38 years of
embedded experience.  I don't define myself as a Linux
developer, despite having been involved with Unix since the
v6 kernel days (mid to late 1970s.)  I prefer my embedded
side, love that aspect, what to share it with others.  The
rest is part of who I am, too, but it's not what I enjoy as
much.

If you wrote a .NET program, it would still be a .NET program
and wouldn't rely upon the kinds of shared experiences I like
listening to.  That doesn't take away from the fact that you
and I _do_ still have shared experiences and interests.  And
that comes out in your posts here.  It will, regardless.

Again, I'll stop here.  I think we are talking at cross
purposes and it won't help anything to beat an already dead
horse.

Jon

Hi Jon,

On 6/21/2011 12:47 PM, Jon Kirwan wrote:

>>> I said that the group's interests have moved away from my own
>>> over the years.  That's true.  I _also_ believe that as the
>>> processors used and tools applied increasingly look more like
>>> traditional, hosted programming environments found on
>>> workstations, to that degree it also is less and less a
>>> differentiating feature.  Taken to its limit, there will be
>>> no difference in embedded development and any other and no
>>> point in choosing to use the adjective anymore.
>>
>> I disagree.  Because the type of application and demands
>> of the "user environment/experience" differ greatly in the
>> two worlds.
>> <snip>
>
> I disagree, as well.  What binds us is our experiences and
> knowledge of tools and practices.  Who we _are_.  Not end
> use.  I think we are talking cross-purposes, though.  I know
> you get it.

No, that's the problem!  I keep rephrasing *my* points and
yours in an attempt to come up with something that I can
"relate to" as an aid (to me) to understanding the distinction
you're trying to make.

And, obviously, I keep missing the mark.  :-/

> I think we are just talking across each others'
> bow, so to speak.

[this was an excellent phrase -- I willhave to remember it!]

> I'm talking about what it is to be a tool
> developer not a tool user.

I'm assuming this, also, isn't the "differentiating factor"
that you're using between embedded/desktop so I won't go
into that, here...

[snip]

> Again, I'll stop here.  I think we are talking at cross
> purposes and it won't help anything to beat an already dead
> horse.

I'd really like to understand the point(s) you're making.
If you can be patient with me, to that end, I'd like to continue
this (in private).  Watch your inbox (though I may not get to it
today as I have a tree to cut down -- on someone else's
property!  :> )

[of course, if you're tired of it, feel free to click "delete" :> ]

Thx,
--don