Searching \ for 'How To Learn a Programming Language' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'How To Learn a Programming Language'.

Truncated match.
PICList Thread
'How To Learn a Programming Language'
2008\12\07@211942 by Joseph Bento

face
flavicon
face
With apologies to Wouter van Ooijen, the following is from his PIC  
tutorial website:

First you know nothing;
YOU ARE HAPPY

You first learn about the chip:
YOU LEARN AND USE ASSEMBLY

You first find out there is an easier way, so you can spare some time  
to watch TV:
YOU LEARN AND USE C

You first find out there is a simpler way, so you can spare all the  
time in TV, cars, girls, bars, traveling, yatch, relaxing, etc:
YOU HIRE SOMEBODY ELSE TO WRITE THE CODE.

You first find out your money is going fast, so you decided to do some  
work:
YOU LEARN AND USE JAL

There are additional steps of course, but I'm stumbling along as I  
proceed past step one.

I think that I have, perhaps, forgotten how to study.  I'm a  
professional technician.  I build engineers' prototypes at work.  For  
that matter, I've had a soldering iron in my hand since I was a  
child.  I think that's part of my problem.  I know what I want to do;  
I know how the I/O pins are supposed to be utilized to design a  
circuit, but I have issues with learning the methodology of writing  
code.

Too many resources?  I have tutorials in Assembly, C, and JAL.  I can  
follow examples in each to light or blink an LED.  Once I accomplish  
that, I know enough to alter the existing code to light or blink an  
LED on an alternative port.

That's where I stop.  I don't know how to put the blocks together to  
proceed with my own ideas.  There may be only 37 or so instructions to  
a 16F84 (for example), but it's knowing what to do with those  
instructions.

So, how does one properly study to learn Assembly or any other  
language for that matter in the most efficient manner?  I follow the  
JAL projects in Bert van Dam's excellent book, and perhaps I'm  
learning something, but I'm doing well in developing my own projects.

I'm just expressing some frustrations.  I'm eager to learn, but I  
think I have too much information at my disposal adding to the  
confusion.  Should I forget Assembler and shelve the other language  
books?  Should I forget Assembler and spend my time learning a high  
level language such as C or JAL?

With any tutorial, I always like projects.  I find it much more  
rewarding to see the results and what changes or errors bring.

Supposedly, it is said that it takes 10 years of diligence to become  
an expert.  Well, maybe I have enough time left that I can achieve  
some manner of proficiency as a programmer.  :-)  I'm essentially at  
ground zero, so there's a lot of work to do!  With all my books et al,  
I just haven't quite began (or perhaps know how to begin) properly.

So, how does a career electronics technician enter into the realm of  
[PIC] programming?

Joe


2008\12\08@012231 by Michael Algernon

flavicon
face
I recommend a board that runs the Forth language.  You get lots of  
immediate satisfaction.
http://en.wikipedia.org/wiki/Forth_(programming_language)
I have one or two that I can provide for free.
MA


> On Dec 7, 2008, at 7:19 PM, Joseph Bento wrote:
>
> With apologies to Wouter van Ooijen, the following is from his PIC
> tutorial website:
>
> First you know nothing;
> YOU ARE HAPPY
>
[snip]
> So, how does a career electronics technician enter into the realm of
> [PIC] programming?
>
> Joe
>

 WFT Electronics
Denver, CO   720 222 1309
" dent the UNIVERSE "

All ideas, text, drawings and audio , that are originated by WFT  
Electronics ( and it's principals ),  that are included with this  
signature text are to be deemed to be released to the public domain as  
of the date of this communication .

2008\12\08@021645 by Wouter van Ooijen

face picon face
> So, how does a career electronics technician enter into the realm of  
> [PIC] programming?

With the knowledge that time limits your options..

I am from the other side (Informatics by profession, but always been an
electronics enthusiasts). I know how to write a compiler and done
one-and-a-half, but I can't really grok or even calculate an active filter.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\12\08@071140 by Byron Jeff

flavicon
face
On Mon, Dec 08, 2008 at 01:22:09AM -0500, Michael Algernon wrote:
> I recommend a board that runs the Forth language.  You get lots of
> immediate satisfaction.
> http://en.wikipedia.org/wiki/Forth_(programming_language)
> I have one or two that I can provide for free.

Learning Forth has been on my todo list for a while. I started writing a
simple PIC crossassembler in GForth a while ago. Set it aside when life got
busy again.

Forth fundamentally is that RPN calculator previously discussed in other
threads on steroids. It facilitates natural language type interfaces.
A line like this:

100 HZ PIN4 PORTB 2 SECONDS BLINK

Would be a perfectly natural FORTH expression.

My personal attraction is from the implementation side. Forth is designed
to be extensible. So you can start with a primitive core Forth and extend
it to your needs on a per application basis.

Two forths for PICS that immediately come to mind are PicFORTH:

http://www.rfc1149.net/devel/picforth

which is limited to a couple of chips in the 16F family and requires a
hosted forth (GForth I believe) on the PC to function. The other is
FlashForth:

http://flashforth.sourceforge.net

which is interesting because it is complete self hosted on the PIC 18F
family. This means that you take the core FlashForth image, burn it to an
18F part, hook up a serial port to your PC, terminal, PDA, or any other
serial device, and program away without any host loaded software other than
a stock terminal program.

Hope this gives some insight.

BAJ

2008\12\08@093930 by Carey Fisher

face picon face
I think you won't have any trouble learning the languages per se by reading
manuals and trying stuff.  What you really need to put some effort into
learning is how to do the upfront design.  I usually sit down with a piece
of paper and say to myself: "Self, what is it I want to do with this
program?".  So, for example, you decide to make a string of LEDs turn on and
then off one at a time.  Now, what do you need to know to accomplish this?
You need to know how to hook up the LEDS, how to turn on a single LED, how
to turn off a single LED, how to set up a counter to cycle through the LEDs
etc.

In other words, Design From the Top Down starting with what you want the end
item to do.  Then break it up into lower level functions and then even lower
level functions until you are at the level of "primitive" functions e.g.
"turn LED on".  THEN, referring to the language's manual, Code From the
Bottom Up:  write a segment of code to turn on an LED, then a segment of
code to turn off an LED.  Then code a routine that turns a LED On then Off
by calling the two lower level routines.

Notice, I didn't mention what language to use.  If you can do the above for
one language, you can easily learn to do it for nearly any language (except
maybe APL;).  I'd start with native assembly language and then move on to C
or Forth or whatever.  They're all pretty much the same except for specific
syntax and built-in constructs.  As a practical matter, I believe you can do
anything in nearly any language. (Real Time applications in COBOL are tough,
however!)

Carey



Liberty without learning is always in peril; learning without liberty is
always in vain.
- John F. Kennedy


On Mon, Dec 8, 2008 at 1:22 AM, Michael Algernon <spam_OUTpicTakeThisOuTspamnope9.com> wrote:

{Quote hidden}

> -

2008\12\08@100320 by Wouter van Ooijen

face picon face
> If you can do the above for
> one language, you can easily learn to do it for nearly any language (except
> maybe APL;).  

Definitely including APL.

One note on top-down versus bottom-up: IMHO neither is really OK. What
one should do is divide-and-conquer the complexity: faced with a problem
and the means to solve it (our case a computer language with some
libraries) you must design an interface layer that is about half-way in
complexity between the two. Once you have done that, you have two
problems of half the complexity, which should each be about four times
as easy as the initial problem. I would call this 'middle-out' design.

Note that this is not dividing the problem in two: that is a vertical
divide-and-conquer, I prefer a horizontal divide.

As for languages: once you've seen a few imperative languages you have
seen them all. There are nice things like OO, generics, exceptions,
event-driven architectures, etc; but that is all easy once you have the
right mindset (but that can take 10's of years). IMHO only the
lazy-functional languages (Haskell being the prime example) are really
different. But I have not seen those used in embedded systems, mainly
because the relation between a HLL statement and the time it takes to
execute is not easy.

On that subject, for all who think a 20% difference between two
benchmark runs on a modern computer must be meaningful:
http://www.youtube.com/watch?v=DKVRkfXrBpg


--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\12\08@115917 by Clint Sharp

picon face
In message <.....7713BA8C-C7C1-44D9-ADC3-9846F666D72DKILLspamspam@spam@kirtland.com>, Joseph
Bento <josephspamKILLspamkirtland.com> writes
>Too many resources?
I fell over the same stumbling blocks, too much information, too many
examples etc.

Following tutorials leaves me cold, I get no satisfaction from following
them and get bored easily (borderline ADHD maybe), I found that just
(just, hah) picking or creating a small project that interested me and
banging away at it using the datasheets for the components was the best
way to learn.

The books and examples were only really useful when I knew more and had
a feel for the op codes, what they did and how they affected the various
status registers etc..

>That's where I stop.  I don't know how to put the blocks together to
>proceed with my own ideas.  There may be only 37 or so instructions to
>a 16F84 (for example), but it's knowing what to do with those
>instructions.

Same frustration here as well when I started playing with PICs and
microcontrollers in general. It's just knowledge and having the will to
do something that interests you
>
>Joe
>
>

--
Clint Sharp

2008\12\08@120742 by 'Grif'

flavicon
face

Read an article in the mid 90's about top down and bottom up when top down was the "Only" correct answer.  He made the argument that the programming effort looked more like a pear with two pointy ends.  Narrow at the top and bottom.  You sort of started at the top to get an idea of how things "felt" then moved to the bottom to try to get the hardware looking like something the program needed, then put the time into the middle getting the top look and feel to play nice with the bottom up efforts.  Anyway, it made sense to me before grey hair.

-----Original Message-----
>From: Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl>

>One note on top-down versus bottom-up: IMHO neither is really OK. What
>one should do is divide-and-conquer the complexity: faced with a problem
>and the means to solve it (our case a computer language with some

2008\12\08@122600 by Wouter van Ooijen

face picon face
> He made the argument that the programming effort looked more like a pear with two pointy ends.

And I thought I had made it up myself...

Any name? reference?


--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\12\08@124721 by 'Grif'

flavicon
face
Nope,,, just a foggy, grey hair memory ;-)  I was doing VMS maintanence on DCL wrappers (generating REGIS graphics) on some of the most nasty fortran code you've ever seen at the time.

{Original Message removed}

2008\12\08@125151 by William \Chops\ Westfield

face picon face
>> He made the argument that the programming effort looked more like a  
>> pear with two pointy ends.

> And I thought I had made it up myself...

Yeah; me too.  Strict top-down or bottom-up would seem to apply when  
one "end" is significantly harder than the other, and is really a  
matter of choice between doing the easy parts first or the hard parts  
first (both of which have certain advantages, of course.)  In MANY  
situations, and especially in embedded/microcontroller apps, BOTH ends  
are "interesting."

BillW

2008\12\09@002212 by Carey Fisher

face picon face
It's not a Top-down vs Bottoms-Up choice...  It's Top-down design so you can
define what modules need to be written.  Then Bottoms-up coding so you can
create the simplest routines first, then put them together progressively
until you get a complete application.
Carey


On Mon, Dec 8, 2008 at 10:02 AM, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:

{Quote hidden}

> -

2008\12\09@023518 by Wouter van Ooijen

face picon face
Carey Fisher wrote:
> It's not a Top-down vs Bottoms-Up choice...  It's Top-down design so you can
> define what modules need to be written.  

I was talking primarily about design, any implementation is mainly to
check that the (interface-) design is viable.

My problems with top-down design are
- it does not force re-use
- it does not (necessarily) match the available resources (lowest level)

Note that my arguments mainly apply to non-trivial projects. A design
that fits in one head is definitely trivial.


--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...