Byron,
 Can you find a bit of time to formulate issues=20
sharply and answer it clearly and briefly as Olin does.=20
 We aren't your students sitting around a lecture-room.
 I'm posting this message, since your considerations=20
are highly interesting, but still too diffused to be easily
grasped.

   Mike.

Byron A Jeff wrote:
> On Thu, Aug 01, 2002 at 12:37:54PM -0600, shawnmulligan wrote:
> > Response to Byron A Jeff's argument:
> >
> > Firstly, realize that I feel that both of our approaches,=20
> though opposite,
> > may be right in different circumstances and with different=20
> people. Given
> > that, my response is not an attack of your method but=20
> simply a response.
> >
> > > * As a beginner, not heeding the advise of someone who is=20
> more experienced
> > than
> > >   you is a foolish venture. They've already been where=20
> you are now and
> > their
> > >   experience is valuable.
> >
> > While this argument sounds good, it simply assumes the=20
> premise that with
> > experience comes the ability to teach and guide beginners=20
> -- and this is
> > just the opposite of my argument. Have you ever had a=20
> teacher or professor
> > that couldn't teach? Who couldn't remember what it was like=20
> to be a student?
>=20
> Of course. And I've seen it a lot as a college professor. But it's the
> exception and not the rule. It pays to heed the advise of=20
> those who have
> been there before.
>=20
> >
> > > * As I have pointed out over and over and over and over=20
> again, the 16F84
> > has
> > >   the weight of inertia on its side. There's more books,=20
> tutorial, and
> > projects
> > >   using it because it's been around for nearly 8 years,=20
> whereas the others
> > have
> > >   come on the scene more recently.
> >
> > Inertia doesn't have to be bad. I argue that access to more=20
> books, turorials
> > and projects is the greatest strength of the 16F84. And=20
> remember, I'm only
> > recommending the 'F84 for beginners -- as a learning tool.
>=20
> But here's the problem. Users, especially beginners, take a=20
> new tool and try
> to use it as a solution for everything. It's what one of=20
> colleagues used to
> call "...you love what you learn." We all do it. To this day=20
> I still use
> Slackware Linux even though every newer Linux version=20
> generally has more
> features. The simple fact of the matter is that the 16F628 is=20
> much much closer
> to the higher end midrange and highrange PICs than the 16F84.=20
> A beginner
> can learn about the right tools right away instead of having=20
> to circumnavigate
> the obstacles presented by the 16F84.
>=20
> In short, if they can do it right from the beginning, why=20
> shouldn't they?
>=20
> >
> > >
> > > * The vast majority of the material that applies to the=20
> 16F84 can be used
> > >   with the newer chips. It's not a situation like the 18F=20
> series parts
> > where
> > >   there's a marked difference in the way that code gets=20
> done. 16F84 code
> > runs
> > >   on 16F62X and 16F87X parts virtually unchanged.=20
> Everyone seems to be
> > arguing
> > >   that this virtual aspect is too difficult for beginners=20
> to understand.
> >
> > Once again, it's because the vast majority of material that=20
> applies to the
> > 'F84 can be used with the newer chips that I recommend the=20
> 'F84 as the PIC
> > with built-in training wheels.
>=20
> You're still missing the point. There is a large conceptual=20
> gulf that occurs
> when transistioning from novice to intermediate usage. This=20
> is at the point
> where you have activites that you must do in software on the=20
> 16F84 vs. being
> able to use the builtin hardware on the other parts. Bit=20
> banging serial ports
> and doing software timers should not be the primary way to=20
> learn how to do
> these activites. But with the 16F84 one is forced to do it that way.
>=20
> That's the problem, while 16F84 code translates up, the code=20
> from other
> midrange PICs do not translate down. So novices have to=20
> relearn and rethink
> how to lay out projects when they outgrow their training wheels.
>=20
> It adds complexity, not reduces it.
>=20
> >
> > >   When I was first starting with PICs in 1995 or so, I=20
> ran into exactly
> > the
> > >   same problem that I'm descrbing between the 16C84 and=20
> the 16C71, which
> > had
> > >   A/D converters on PORTA. It required 2 extra lines of=20
> code to turn them
> > off.
> >
> > Being a beginner is all about learning, so I believe that a=20
> beginner's first
> > ADC should be built from discrete components. Then, when=20
> they move up to the
> > fancy micro with all the bells & whistles they'll=20
> understand 'how and why'
> > the device works and not simply set a few registers and=20
> feed information
> > into a black box that smartly spits out ones and zeros.
>=20
> I disagree. One should always learn the highest abstraction=20
> that works and
> continue to use it until the abstraction breaks. One should treat it
> exactly like a black box that smartly and correctly spits out ones and
> zeros until such time as the abstraction breaks down.
>=20
> Why not simply have our erstwhile users build their circuits=20
> from transistors
> then? The whole point of using a microcontroller is to=20
> provide a high level
> abstraction for programming activities. The extra hardware is=20
> part and parcel
> of that abstraction.
>=20
> Here's an example: you need a async serial port. With the=20
> 16F84 you are stuck
> with bitbanging. With the 16F628 you can use the hardware=20
> port. Now does this
> mean that you should not learn bitbanging? Of course not. You=20
> will need 2
> serial ports at some point in time. But you don't have to=20
> learn how to do it
> now. Use the abstraction until a time as it doesn't work anymore.
>=20
> It also illustrates what I'm talking about in terms of the=20
> 16F84 not being
> forward compatible. With the 16F84 one must learn to bitbang=20
> serial. But
> when one steps up later on, you'll have to relearn how to use=20
> the hardware
> serial port.
>=20
> I've been on both sides of this debate and I have to admit=20
> that I have been
> swayed. As a former computer science professor it was my firm=20
> belief that
> students should learn the process of programming from the=20
> ground up. I was
> persuaded to consider in a rather heated debate with a=20
> colleague that maybe
> the best way to teach programming data structures is from a=20
> usage standpoint
> first. Specifically teach using data structures with the C++=20
> Standard Template
> Library. I argued as you do, that doing it from the ground up=20
> will give a
> firmer foundation to build upon. My colleague pointed out=20
> that if students
> were unsuccessful in understanding and applying that low=20
> level knowledge that
> it wouldn't matter anyway. While we parted ways still=20
> fundamentally disagreeing
> I certainly was persuaded by that argument. You see part of=20
> the results here.
>=20
> Use the highest abstraction. The additional hardware supports=20
> that higher
> abstraction. It's possible to drop down later if necessary.
>=20
> I see one difference between us now. See I find the extra hardware the
> training wheels. You can do more with less code and less=20
> indepth understanding.
> You seem to think that the extra stuff is an impediment and=20
> that beginners
> should learn how to "Do it the hard way..." first.
>=20
> >
> >
> > > * Easy to use is a highly debatable topic:
> > >   - The programmer is more difficult. Novice users will=20
> build their own
> > >     programmers. Show me a 16F84 programmer that's as=20
> simple as the TLVP.
> >
> > If  a person can't build (or buy) an 'F84 programmer and=20
> program the chip
> > successfully (as millions before have done) then perhaps=20
> electronics is not
> > their thing and they should be seeking other hobbies and different
> > newsgroups.
>=20
> The programmer is a tool. Wasting time on it is like wasting=20
> time building
> a screwdriver. But many novices will have that level of=20
> understanding. So
> the simpler it can be made, the better off the novice will be.
>=20
> >
> >
> > >   - The last of features on a 16F84 quickly introduces=20
> complexity in
> > >     programming. Not having a hardware USART means having=20
> to bit bang. Not
> > >     having multiple timers means having to juggle the=20
> single 8 bit timer,
> > >     counting overflows, and tracking multiple virtual=20
> timers off the
> > single
> > >     real one. Not having a hardware CCP module means=20
> adding code to
> > capture
> > >     the length of time of a pulse or doing lower=20
> frequency PWM by hand.
> > >     Not having enough memory (program, RAM, and data=20
> EEPROM) causes
> > headaches
> > >     once one gets past the toy project. Not having an=20
> internal oscillator
> > >     means that one must deal with the oscillator issue=20
> immediately instead
> > of
> > >     being able to put it off until a later time.
> >
> > All true, but irrelevant to the beginner.  All of these=20
> wonderful things
> > will unfold to the beginner in due time. I wonder: Have you=20
> seen some of the
> > things that have been done with the 'F84. Many surpass the=20
> rank of  'toy
> > project.'
>=20
> I know. However in the end it required a much higher level of=20
> design complexity
> in order to achieve it. And the one thing we seem to agree on is that
> added complexity is not good for novice users.
>=20
> Another point I want to pound. Novices do not stay novices=20
> for long. So in
> starting out it is relevant as to what happens at the 1st and=20
> 2nd pleateau.
> You may have an argument if there was a vast difference in=20
> the beginning.
> There isn't a vast difference and in fact starting out favors=20
> the 16F628:
>=20
> * Simpler programmer
> * Less hardware (No oscillator)
>=20
> Then at the first transistion to real projects
>=20
> * Real hardware
> * Simpler programming interface
> * More can be done with less management because hardware is managing.
>=20
> Just think about the 1st time a programmer needs to monitor=20
> the length of a
> button press while receiving or transmitting a serial byte at=20
> the same time
> to know what I'm talking about at this level.
>=20
> The second transition is easier too...
>=20
> * More memory
> * More I/O
> * Shares many periperals with bigger better chips so a=20
> simpler transision up.
>=20
> BTW the oscillator issue is immediate because no successful=20
> PIC project runs
> without an oscillator.
>=20
> It's only simpler at the surface. In the true analysis it really is an
> issue where less is less (16F84) and more is more (16F628/16F87X)
>=20
> >
> > >    Finally it's all moot anyway because the other chips=20
> can run exactly
> > >    what the 16F84 does. It's just that when it's time to=20
> take the second
> > step
> > >    the others are ready to step up, while the 16F84=20
> struggles to keep up.
> >
> > I think this is a ridiculous point. That's not my=20
> experience, nor that of
> > the other engineers around the office here.
>=20
> That's nice. Apply your experience to my example above. For=20
> me it was more
> difficult to manage it on a 16F84 than a 16F877. And I'm not a novice
> programmer. Not impossible, but more diffiult that when the=20
> hardware to
> handle the job is around.
>=20
> >
> > > * Honestly when is the last time anyone here has been=20
> 'greeted' with a
> > RTFM?
> > >   This is the most useful and helpful forum I know. While=20
> I may suggest
> > that
> > >   a new user read/search the archives, turning them away=20
> isn't in this
> > list's
> > >   makeup.
> >
> > I have read many suggestions for new users to "Read the=20
> Manual." Now this
> > advise wasn't given with malice or with the 'F', just with a lack of
> > appreciation for the limitations of novices.
>=20
> My experience in this matter is in variance with yours. ;-)
>=20
> >
> > That said, I think this forum is very helpful and has a=20
> great membership.
>=20
> This is more my experience...
>=20
> > For example, I have really enjoyed reading the postings of=20
> Kiersen (sp?) and
> > seeing his questions get more and more complex. I feel like=20
> I'm taking the
> > journey with him. He's been given some great advice.
> >
> > > All in all I like Brendan's argument the best.=20
> Recommending the 16F84
> > nowadays
> > > is like recommending a 486 or Pentium 90 to a new=20
> computer buyer. The
> > > difference is that 16F84's are still available and the=20
> others are long
> > gone
> > > from the shelves. They were great in their time, but=20
> their time has passed
> >
> > This is a deceptive argument and doesn't really parallel=20
> the current debate.
> > I would respond that if you are learning beginning machine language
> > programming in say the Debug environment, a 486 is as good=20
> as anything. You
> > don't need an HP calculator when you are learning to add --=20
> at that stage
> > all you could do is stare at the pretty orange and blue=20
> keys, with all the
> > funky Greek lettering.
>=20
> However once one knows the basics, the calculator continues=20
> to be useful as
> you progress. Even if you don't use the stat functions, the=20
> programming, and
> the graphic capabilities initially, they will be there when=20
> you do need them.
>=20
> > [MSP430 deleted. Followed up in another thread... BAJ]
>=20
> BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics