Searching \ for '[EE] 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'.

Exact match. Not showing close matches.
PICList Thread
'[EE] How To Learn a Programming Language'
2008\12\08@012812 by M. Adam Davis

face picon face
Note: Not trimmed as the original post was improperly tagged, so
perhaps many have not seen it.

Joe,

Well, about the only thing I can tell you is to start small, and make
incremental improvements or add new features onto what you have
already.

For instance, you say you can blink the LED.  Now try to:
- Blink the LED faster
- Blink the LED slower
- Blink the LED at exactly (as close as the oscillator will allow) 4Hz
- Blink the LED at 20kHz (measure with frequency counter or oscilloscope)
- Blink the LED at different duty cycles (5% of the cycle on to 95%
off, through 95% on to 5% off) - This is pulse width modulation (PWM),
where you vary the pulse width.

Once you've done all the above, which should seem pretty
straightforward to you, try to add some 'bling':
- By using a high frequency and changing the duty cycle you can dim the LED
- Have it slowly turn on and back off, pulsating
- Have it turn on suddenly and then slowly fade out
- Hook up an RGB LED and have dim each one (need to manage three
pulse width modulation counters)
- See what happens if you change the frequency instead of the duty
cycle in a pulsating manner
- Hook up a speaker to the above and hear the siren sound

Now you can try out some of the other features of the chip.
- Read about the PWM peripheral and do the above with that instead of loops
- Program it so a button will change modes (have 6 different types of
blinking modes, each time you press the button it uses adifferent
mode) - now you've got a "rave" LED toy
- Hook up a potentiometer to an A/D input and get readings - have the
readings control the brightness of the LED, or the speed of flashing -
if the duty cycle is 5% on and 95% off, and you control the rate of
flashing then you have a strobe light and can watch water drops at the
sink

The basic idea is to start with what you have and make very tiny
changes.  The above may seem easy when you read it, but there are all
sorts of programming concepts hidden in there (mostly lots of program
flow control issues) that you'll have to work through.  They won't be
difficult, but once you've finished the above, it won't seem so
daunting to take on something harder.

Further, much of the above can be done in an few evenings, which is
nice since instant gratification is a big help in getting started in
PIC programming.

The reality is that you've run into one of the biggest skills a good
programmer needs - the ability to see a complex project, and break it
down into tiny, solvable chunks.  Right now you don't quite see how
you can take your ideas and complete them, but you need to look at it
and break it down into a smaller problem.

So, for instance, some recent discussion on this list is cat doors.
One person wants to use a servo to close the door slowly, some
solenoids to lock it at various times, and RFID to detect their pet.
Let's pick this apart:
1. Solenoids activate at various times
  - Needs time keeping
     - Needs to know time of day (we'll skip year, month, day, and
assume every day the schedule is the same)
       - Need to develop a small routine that counts seconds
         - Need a timer that sets a flag every second
         - When that flag is set, increment the seconds counter, and
reset the flag
         - If seconds > 59, reset seconds to 0, increment minutes
         - If minutes > 59, reset minutes to 0, increment hours
         - If hours > 23, reset hours to 0
         - Check if hours, minutes, and seconds == a pre-set time to
activate a particular solenoid
         - Check if we match a pre-set time to deactivate a particular solenoid
2. RFID
  - Needs to communicate with an RFID reader
    - Needs UART, SPI, or some other serial peripheral interface
      - Needs to initialize serial peripheral (correct baud rate, bits, etc)
      - Needs to check for received characters and buffer them
        - Needs a space to store incoming data, or needs to process
it on the fly
...

This is a skill that will only come through practise, but we're more
than happy to help with this, so feel free to discuss your ideas and
desires here, and we'll help you understand what you need to know to
get over the gap.

-Adam

On Sun, Dec 7, 2008 at 9:19 PM, Joseph Bento <spam_OUTjosephTakeThisOuTspamkirtland.com> wrote:
{Quote hidden}

> -

2008\12\08@022945 by Vitaliy

flavicon
face
Joseph Bento wrote:
>> So, how does a career electronics technician enter into the realm of
>> [PIC] programming?
[snip]
{Quote hidden}

You've asked many questions, but I think the main one is "how do I learn to
program?"

I think the answer depends a lot on how you learn in general, and where you
are starting at. There are a few general guidelines that should work for
everybody. Adam had a lot of great ideas in his email, but I especially
agree with this statement:

M. Adam Davis wrote:
> The reality is that you've run into one of the biggest skills a good
> programmer needs - the ability to see a complex project, and break it
> down into tiny, solvable chunks.  Right now you don't quite see how
> you can take your ideas and complete them, but you need to look at it
> and break it down into a smaller problem.

Software development is about managing complexity. Keep things simple and
straightforward, and remember that "Any fool can write code that a computer
can understand. Good programmers write code that humans can understand."
(Martin Fowler)

I know for a fact that many people (including Byron and Olin) disagree with
me, but I would suggest that you jump right into programming in a higher
level language, like C, or even BASIC. I work on reasonably complex
commercial projects, even though I never wrote a "real" program in PIC
assembly.

Another thing I would strongly encourage, is working with a higher-end PIC,
like an 18F or a 33F/24H. They're not much more expensive, Microchip has
free compilers for both families, and everyone agrees they are much easier
to program than the 16Fs.

To reiterate what Adam said, work in baby steps. When you decide on a
project, pick a small task, and get it working. Then pick another task, and
so on. Make only small changes, and compile/test as often as possible (this
will make debugging much easier).

Save copies of working code, or better yet, start using Subversion. There's
nothing worse than spending two hours trying to figure out which of the
changes you made, broke the program (especially if your changes aren't the
problem).

I will end the email with a suggestion on what NOT to do. I think the
biggest killer projects, is too much documentation. Don't fall into the trap
of trying to design everything on paper, before coding it. Design a little
bit, code it, repeat.

Good luck, and have fun!

Vitaliy

2008\12\08@100130 by Joe Bento

face
flavicon
face
M. Adam Davis wrote:
> Note: Not trimmed as the original post was improperly tagged, so
> perhaps many have not seen it.
>
>  
Yes, I realized my error almost as soon as I posted the message.  I
resent it tagged as [PIC], so I hope people will forgive me that that
the message ended up in two areas of the list.

>
> This is a skill that will only come through practise, but we're more
> than happy to help with this, so feel free to discuss your ideas and
> desires here, and we'll help you understand what you need to know to
> get over the gap.
>
> -Adam

Thank you so much, Adam, for your suggestions.  Part of my problem is I
want to do too much too quickly.  The electronic assembly is not a
problem for me, so I've been frustrated that I can't just dive right
into that complex project I've been dreaming up.

Among your suggestions was blinking the LED at precise rates and fading
and dimming.  I've tried neither.  Many of the tutorials I have discuss
PWM, and I imagine that is what would be used (or could be used) to
control an LED in that manner.

Obviously I have a lot of work to do.  I need to decide from among my
printed materials what is good and what is essentially obsolete.  Many
still continue to use the 16F84.  While I have a couple of these chips,
I'm not certain if I should learn on them or jump right to a more
current 18F series chip.

One puzzling aspect of nearly all the tutorials is their use of the TRIS
statement.  The tutorials even state this command is obsolete.  
Microchip says its obsolete and discourages its use.  MPLAB gives a
warning, etc.  Yet I don't (yet) know what the alternative command is.  
Nothing I've yet read has been thorough enough to demonstrate the
replacement command.

Well, with the reader ratings, my best reference is probably "Easy
Microcontrol'n" from Square 1.  Somehow, after I ordered the book, I
wasn't really impressed. Despite its use of TRIS and a 16F84, is this
still a recommended reference?

What is among the things I hope to do with a PIC?  I'm very fond of
old-display technology.  I have a large collection of Nixie tubes, VFD
tubes, Numitrons, and 7-segment LEDs.  I'm looking at projects like
clocks, frequency counters, digital VFO, etc.  Code for many of these is
freely available, and I've used some of these sources already.  Anything
someone else designs may not have all the features you many want
yourself, so eventually I hope to acquire the knowledge to do some of my
own development.

Thanks again.  Your help and suggestions are greatly appreciated.

Joe

2008\12\08@134123 by M. Adam Davis

face picon face
On Mon, Dec 8, 2008 at 10:01 AM, Joe Bento <.....josephKILLspamspam@spam@kirtland.com> wrote:
> Among your suggestions was blinking the LED at precise rates and fading
> and dimming.  I've tried neither.  Many of the tutorials I have discuss
> PWM, and I imagine that is what would be used (or could be used) to
> control an LED in that manner.

When I was first starting out I found that trying to do things by hand
- no perhipherals (also referred to a "bit banging" since you're
controlling the port directly instead of using a peripheral) - led me
to a better understanding of what was happening.

I don't know that this is strictly necessary.  For instance, I would
recommend that beginners learn and use the UART ratehr than bit
banging a serial connection if possible.  On the other hand, you're
eventually goign to need to troubleshoot it, so knowing what's going
on at the lower levels will help you further down the line.  The
biggest issue is simply getting the peripheral to work the way you
want it to, and without an understanding of what it's doing it gets
really hard to debug.

So I still lean towards doing in code by hand (control the port
directly).  But the main aim is to give you some simple examples of
beginner to intermediate complexity software - bit banging this stuff
is not so difficult that you would have a hard time understanding what
the software needs to do, and this will teach you a lot of the
programming concepts you need to learn (control loops, mainly).

> Obviously I have a lot of work to do.  I need to decide from among my
> printed materials what is good and what is essentially obsolete.  Many
> still continue to use the 16F84.  While I have a couple of these chips,
> I'm not certain if I should learn on them or jump right to a more
> current 18F series chip.

You might as well jump to a more modern PIC.  There are differences,
mainly in peripherals, but for generic programming you'll be better
off in the long run.

> One puzzling aspect of nearly all the tutorials is their use of the TRIS
> statement.  The tutorials even state this command is obsolete.
> Microchip says its obsolete and discourages its use.  MPLAB gives a
> warning, etc.  Yet I don't (yet) know what the alternative command is.
> Nothing I've yet read has been thorough enough to demonstrate the
> replacement command.

TRIS is a shortcut that won't always be around.  There is a set of
registers that controls pin direction (whether a pin is input or
output).  However, these registers are located in another memory bank
- which you'll learn about soon enough - and so you need several
instructions to work with these port direction control registers.

TRIS shortcuts that and makes writing these easy - one instruction, one cycle.

Even though they are depreciated, and may eventually go away, if the
chip support them you might as well use it for speed and ease of
reading the code.  Just be aware that a some future point your
production line will grind to a halt when you start getting a 100%
failure rate because microchip finally did away with it and your
latest batch of chips are affected (not likely, actually, they'd at
least give a new revision to the chip and you should be paying to
revision errata if you're doing production with their parts).

> Well, with the reader ratings, my best reference is probably "Easy
> Microcontrol'n" from Square 1.  Somehow, after I ordered the book, I
> wasn't really impressed. Despite its use of TRIS and a 16F84, is this
> still a recommended reference?

I haven't checked out that particular book.  Some of the other books
are ok for a beginner.  The concepts you learn, and some of the code
will work fine in an 18F chip.  Some things you may have to update for
the new chip (for instance, many newer chips have A/D that is on by
default, so you have to turn it off before you can use some of the
pins as digital - the 16F84 pins were all digital on powerup).

The 16F84 is essentially 14+ years old now, and has a lot of traction
- this is one reason you see so many tutorials about it.  It was a
chip you could program very inexpensively, and didn't require a UV
eraser.  Once others started doing what Mchip did (cheap chips,
readily availabel to hobbyists through digikey and similar) then many
people moved away from it, and there isnt' as much information online
about the newer chips.

But, for the most part, it's upward compatible, so the code and
concepts are very similar to the new chips.

> What is among the things I hope to do with a PIC?  I'm very fond of
> old-display technology.  I have a large collection of Nixie tubes, VFD
> tubes, Numitrons, and 7-segment LEDs.  I'm looking at projects like
> clocks, frequency counters, digital VFO, etc.  Code for many of these is
> freely available, and I've used some of these sources already.  Anything
> someone else designs may not have all the features you many want
> yourself, so eventually I hope to acquire the knowledge to do some of my
> own development.

Working from other people's code is a great way for you to get into
this, actually.  You have the skills necessary to build and program
the projects that exist.  Once you've built someone else's project,
think about a way to modify it to do something slightly different,
then dig into the code.  It'll be hard at first, but it'll get easier,
and eventually it'll be easier for you to build your own project than
it would be to copy someone else's.

-Adam

--
Please rate and vote for my contest entry:
mypic32.com/web/guest/profiles?profileID=50331

2008\12\08@140206 by PAUL James

picon face

When I was first learning PIC programming, they had just been released
by Microchip (GI).  This was around 1990 or so.
There were a few ap notes, and the only code I found available is what
was in the apnotes.

So, I studied the apnotes, and tried to see how the author performed a
certain function or operation.  Then I would modify
That function to serve my purpose.  When I got it to work, I would go on
to something else.  After a while, I would try new
Functions and operations on my own.  Most worked.  Some didn't.  But I
had a good grasp of what would and wouldn't work in
A given circumstance.  From there, it has gotten easier and easier.  And
I almost exclusively program in assembly language.

I have tried many HLL's, but don't really like any of them  I think they
are way over rated for the PIC's.  I will use one
On ocassion when a contract customer demands it.  Other than that, I use
assembly language.  And I am very good at it if I
Do say so myself.  

But, my main point is this....

1. Look at how other people accomplish a given task or function.

2. Adapt the algorithim to your problem.  Don't use the other person's
code without their permission first though.

3. Write code for your task at hand.  Refine it as necessary.

4. Keep it handy somewhere in case you need it again for projects down
the road.

5. always study other peoples code to see how they accomplish a given
task or function.  Try to think of ways you can improve
  or streamline the operation to make it faster, use less memory, add a
bit of functionality without upping the code significantly, etc., etc.

This is the way I started learning PIC coding.  And I still study other
people's code when I get a chance just to keep up with what is out
there.

This philosophy has served me well in the past, and has done so since.
For nearly 20 years now.  It will probably work for you too.
And it isn't rocket science.  Anyone can do it.

Hope this helps you out.




       
Regards,

       
Jim







{Original Message removed}

2008\12\08@145033 by Vitaliy

flavicon
face
Joe Bento wrote:
> Obviously I have a lot of work to do.  I need to decide from among my
> printed materials what is good and what is essentially obsolete.  Many
> still continue to use the 16F84.  While I have a couple of these chips,
> I'm not certain if I should learn on them or jump right to a more
> current 18F series chip.

Even if you decide to go with a 16F chip, don't use the 16F84. You get more
resources for less money with other members of the family:

http://finitesite.com/d3jsys/16F628.html

But I don't think anyone on this list would disagree with me that a PIC from
the 18F family would be a better starting point.

Vitaliy

2008\12\08@151422 by Byron Jeff

flavicon
face
On Mon, Dec 08, 2008 at 02:49:44PM -0500, Vitaliy wrote:
> Joe Bento wrote:
> > Obviously I have a lot of work to do.  I need to decide from among my
> > printed materials what is good and what is essentially obsolete.  Many
> > still continue to use the 16F84.  While I have a couple of these chips,
> > I'm not certain if I should learn on them or jump right to a more
> > current 18F series chip.
>
> Even if you decide to go with a 16F chip, don't use the 16F84. You get more
> resources for less money with other members of the family:
>
> http://finitesite.com/d3jsys/16F628.html

Even better is the 16F88. Same page updated for that chip:

http://finitesite.com/d3jsys/16F88.html

>
> But I don't think anyone on this list would disagree with me that a PIC from
> the 18F family would be a better starting point.

It certainly would.

BAJ

2008\12\09@004208 by Joseph Bento

face
flavicon
face

On Dec 8, 2008, at 11:40 AM, M. Adam Davis wrote:
>
> You might as well jump to a more modern PIC.  There are differences,
> mainly in peripherals, but for generic programming you'll be better
> off in the long run.
>

I have a fair selection of chips to choose from.  I have solderless  
breadboards, a PicKit 2, Wisp648, and even a ICD 2 that was discarded  
at work after someone buggered up the RJ-12 connector.  (Very simple  
repair job, but since time is money, my time is more valuable to the  
company than the replacement cost of the ICD 2.  My hobby time,  
however, was rewarded with a nice programmer / debugger.)

You and others who have replied have given me a bit of encouragement  
to continue and hopefully persevere.   Perhaps 'persevere' isn't the  
word I should use, as I hope to ultimately be successful.

>
> TRIS is a shortcut that won't always be around.  There is a set of

It seems what you're saying is that I shouldn't (yet) worry about  
using the shortcut.  However, I understand that I also shouldn't be  
surprised one day if it no longer works.  However, as mentioned, I  
would expect there to be an incremental step in any part number, along  
with new documentation.

>
> The 16F84 is essentially 14+ years old now, and has a lot of traction

This might also be the reason that it remains available.  Since I have  
a few 16F84As, I may begin some tutorials using one.  But upon  
successfully lighting or blinking the LED, perhaps it would behoove me  
to try the same experiment with a more modern chip.  I do have a  
couple 18F2620s in my parts bins.  One downside is the 200 page  
datasheets.  I understand much better when I'm working with a paper  
copy rather than scrolling a PDF.  Ink cartridges don't last too long  
when printing such documents.  :-)

> But, for the most part, it's upward compatible, so the code and
> concepts are very similar to the new chips.

I'm looking forward to trying this out.

>
> Working from other people's code is a great way for you to get into
> this, actually.  You have the skills necessary to build and program
> the projects that exist.  Once you've built someone else's project,
> think about a way to modify it to do something slightly different,
> then dig into the code.  It'll be hard at first, but it'll get easier,
> and eventually it'll be easier for you to build your own project than
> it would be to copy someone else's.

A few weeks ago, I built a single VFD clock.  It uses a 16F84A, and a  
3.58MHz colorburst crystal.  Since I did not build it with a trimmer  
cap in series with the crystal, I can't make any fine-tune  
adjustments.  It loses about a second a day.  Anyhow, it works by  
alternating tens of hours, hours, 10s of minutes, then minutes.  The  
display then blanks for 5 seconds or so and the process repeats.  
Times under 10:00 and over 12:00 and the tens place is masked - using  
the 12hr asm code.   I've been pouring over the author's code, wanting  
to specifically shorten that 5-second blank time and have been unable  
at this point to see where that occurs.  Also, the author provided the  
option for use of a colorburst crystal or a 4MHz crystal for the  
timebase, and gave instructions for which line of code to modify.  
Obviously, with the provided information, that was easy enough.  Now  
I'm a bit lost again where he defines the "ticks" as 9.15ms or 8.19ms  
depending on the crystal used.  I understand the concept of "why" but  
not how the numbers were derived.    Here's a snippet:

#IFDEF  _3_58MHZ                ; number of ticks per second for 3.58  
MHz:
TCK0    EQU     .109            ; nominal
TCK1    EQU     .111            ; every 10 secs
TCK2    EQU     .113            ; every min
TCK3    EQU     .115            ; every 10 mins
TCK4    EQU     .114            ; every hour
TCK5    EQU     .110            ; every 10 hours
TCK6    EQU     .111            ; every 24 hours
#ENDIF

I obviously need to learn some basics before I dig too deeply into  
others' code.  But I'll admit to feeling frustrated that I'm not  
understanding this, which seems simple.  This looks (to me) to be  
where the crystal frequency is defined to make this project function  
as a real time clock.  I did look up 'EQU' and see it stands for  
equals.  I see there is also much more to learn in addition to the  
instruction set for the chip.

Thanks, all  for putting up with me.

Joe


2008\12\09@023930 by Wouter van Ooijen

face picon face
>> TRIS is a shortcut that won't always be around.  There is a set of
>
> It seems what you're saying is that I shouldn't (yet) worry about  
> using the shortcut.  However, I understand that I also shouldn't be  
> surprised one day if it no longer works.  However, as mentioned, I  
> would expect there to be an incremental step in any part number, along  
> with new documentation.

(14-bit cores) You probably missed the alternative because it is so
obvious: write to the TRIS register(s) (in bank 1). For larger chips
this is the only alternative anyway for the higher ports.

On 12-bit cores there is no TRIS register, so using the TRIS instruction
is the only option.

IIRC >14 bit cores have no TRIS instruction, only TRIS registers.

Does anyone know of a 14-bit chip that does not implement the TRIS
instruction? IIRC some chips don't mention the instruction in the
datahseet, but it still works (16F877A?).

--

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\09@030832 by Vitaliy

flavicon
face
Wouter van Ooijen wrote:
> 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.

I still don't quite get what you are talking about. It almost sounds like
you're talking about an Adapter or a Facade pattern: an object that allows
other objects to be "adapted" to the higher-level interface. But then again,
I don't think it is what you have in mind.

Let's say you were writing flight control software for Apollo 11. Limit the
scope as you see fit, what would be the middle-out approach as applied to
this situation?

What do you think about a highly iterative approach to software development?

Vitaliy

2008\12\09@101857 by Joe Bento

face
flavicon
face
Wouter van Ooijen wrote:
>>> TRIS is a shortcut that won't always be around.  There is a set of
>>>      
>> It seems what you're saying is that I shouldn't (yet) worry about  
>> using the shortcut.  However, I understand that I also shouldn't be  
>> surprised one day if it no longer works.  However, as mentioned, I  
>> would expect there to be an incremental step in any part number, along  
>> with new documentation.
>>    
>
> (14-bit cores) You probably missed the alternative because it is so
> obvious: write to the TRIS register(s) (in bank 1). For larger chips
> this is the only alternative anyway for the higher ports.
>  
I've been doing some reading, and don't claim to completely understand
this yet.  If I wish to avoid using the "illegal" TRIS instruction, it
looks like I'd do something like this:

movlw       0x00       ;load w with 0x00
movwf       trisb        ;write to tristate B, port B outputs

It's certainly time to pull out the breadboard and wire up a "hello
world" led to try this.


Joe

2008\12\09@105546 by Wouter van Ooijen

face picon face
> I've been doing some reading, and don't claim to completely understand
> this yet.  If I wish to avoid using the "illegal" TRIS instruction, it
> looks like I'd do something like this:
>
> movlw       0x00       ;load w with 0x00
> movwf       trisb        ;write to tristate B, port B outputs

Basically OK, but the devil is in the details. Read about memory paging.

This document has a chapter on the instruction set, including memory
paging, starting from P37. But the document is preliminary, so all bugs
are for free: http://www.voti.nl/hvu/2TPRJ5/DB038.pdf

--

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\09@113621 by olin piclist

face picon face
Joe Bento wrote:
> movlw       0x00       ;load w with 0x00
> movwf       trisb        ;write to tristate B, port B outputs

You have the right idea partially, but a few details are wrong or missing:

1 - "load W with 0x00" is a really useless comment.  (Aside: I always
chuckle when someone goes out of his way to specify the radix of 0).

2 - Labels start in column 1 and opcodes in column 2 or greater.

3 - These two lines should be preceeded by BANKSEL TRISB, or some other
means to guarantee the bank is set properly or a comment explaining this
section of code has a dependency on the bank setting.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@122241 by Joe Bento

face
flavicon
face
Wouter van Ooijen wrote:
> This document has a chapter on the instruction set, including memory
> paging, starting from P37. But the document is preliminary, so all bugs
> are for free: http://www.voti.nl/hvu/2TPRJ5/DB038.pdf
>  

Wouter, are you planning on offering this dwarf board (DB038) for sale
(assembled or kit)?  After perusing the manual, I think this might be a
useful product to learn with, as everything appears to be there.


Joe

2008\12\09@122751 by Joe Bento

face
flavicon
face
Olin Lathrop wrote:
> Joe Bento wrote:
>  
>> movlw       0x00       ;load w with 0x00
>> movwf       trisb        ;write to tristate B, port B outputs
>>    
>
> You have the right idea partially, but a few details are wrong or missing:
>
> 1 - "load W with 0x00" is a really useless comment.  (Aside: I always
> chuckle when someone goes out of his way to specify the radix of 0).
>
> 2 - Labels start in column 1 and opcodes in column 2 or greater.
>
> 3 - These two lines should be preceeded by BANKSEL TRISB, or some other
> means to guarantee the bank is set properly or a comment explaining this
> section of code has a dependency on the bank setting.
>  

More to add to my notes.  I was under the assumption that the port had
to be set to 0 to designate it as an output, or perhaps I'm
misunderstanding your 1st comment.

Forgive my ignorance.  I think I'll follow a bit better when I get a
simple circuit with LED wired up to see the results.

Joe

2008\12\09@124252 by PAUL James

picon face
Actually, the Radix isn't zero.  It's Hex.  0x00 is a number in the
radix of choice, ie hex.
About the comment being useless, I would tend to agree because you can
easily see from the instruction
That you are loading the 'w' register with zero.  So, in that respect,
it is useless.
It would be better to make a comment something along the lines of
"Loading TRISB register with zero to make port an output"


Regards,

Jim

{Original Message removed}

2008\12\09@124814 by olin piclist

face picon face
Joe Bento wrote:
>>> movlw       0x00       ;load w with 0x00
>>
>> 1 - "load W with 0x00" is a really useless comment.  (Aside: I always
>> chuckle when someone goes out of his way to specify the radix of 0).
>
> I was under the assumption that the port had
> to be set to 0 to designate it as an output, or perhaps I'm
> misunderstanding your 1st comment.

The MOVLW 0 instruction is correct, it's the comment that's useless.  The
fact that you specifically insisted it be a hexadecimal zero is merely
humorous.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@125708 by olin piclist

face picon face
PAUL James wrote:
>> I always chuckle when someone goes out of his way to specify
>> the radix of 0
>
> Actually, the Radix isn't zero.  It's Hex.

Note I said "the radix of 0", referring to the fact that it was specifically
a hex zero, implying a octal or binary or decimal zero wouldn't work here.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@133023 by Wouter van Ooijen

face picon face
Joe Bento wrote:
> Wouter van Ooijen wrote:
>> This document has a chapter on the instruction set, including memory
>> paging, starting from P37. But the document is preliminary, so all bugs
>> are for free: http://www.voti.nl/hvu/2TPRJ5/DB038.pdf
>>  
>
> Wouter, are you planning on offering this dwarf board (DB038) for sale
> (assembled or kit)?  After perusing the manual, I think this might be a
> useful product to learn with, as everything appears to be there.

Yes, but it will take some more documentation effort before it is a
'sellable' product. And I must get some more experience with SMD work,
up to now it was all handwork which makes the board to expensive (think
E 200). I don't think it is viable as a kit, far too much SMD work. I
don't think there is a picture of the bottom in the document, but there
are a lot of components there!

This is the 5'th incarnation of this board. The first version used a
pickit1 clone and a 14-bit PIC, then a pickit2 clone and 40 pin PIC
(16F917), next an F887 and an Ethernet interface (never got that to
work), then an L298 motor driver (too much diodes to add) and now a dual
L6202 motor driver, which seems to be OK. A minor problem is the PS/2
interface: you can't keep the peripheral 'quiet' (at least not both a
kbd and a mouse) when the lines are high. Got to look into that. And I'd
like to have an RS485 interface, but the board is full :( The pickit2
clone is another minor nuisance: it won't work with the current pickit2
firmware, and I don't want to change the circuit.

But it sure is a good classroom board!

--

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\09@133152 by Wouter van Ooijen

face picon face
> More to add to my notes.  I was under the assumption that the port had
> to be set to 0 to designate it as an output, or perhaps I'm
> misunderstanding your 1st comment.

not the port, the direction register (TRIS register)

> Forgive my ignorance.  I think I'll follow a bit better when I get a
> simple circuit with LED wired up to see the results.

Being ready to admit your ignorance will get you a long way. It is a
rare attitude, especially among PIClist members :)


--

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\09@151523 by Vitaliy

flavicon
face
>>> movlw       0x00       ;load w with 0x00
>>> movwf       trisb        ;write to tristate B, port B outputs
>>>
>>
>> You have the right idea partially, but a few details are wrong or
>> missing:
>>
>> 1 - "load W with 0x00" is a really useless comment.  (Aside: I always
>> chuckle when someone goes out of his way to specify the radix of 0).

I agree that a comment should describe the "why" of what you are doing.
However, sometimes I also write 0 as 0x00 (for consistency, and it's easy to
change 0x00 to a 0x0C).


>> 3 - These two lines should be preceeded by BANKSEL TRISB, or some other
>> means to guarantee the bank is set properly or a comment explaining this
>> section of code has a dependency on the bank setting.

You would not have to worry about bank selects if you used an 18F or higher.
Switch, before it is too late! :-)


> More to add to my notes.  I was under the assumption that the port had
> to be set to 0 to designate it as an output, or perhaps I'm
> misunderstanding your 1st comment.

You are correct, you need to set the respective TRIS bit to "0" to designate
it as an output. By the way, this is what the above operation would look
like in C:

TRISBbits.TRISB2 = 0; // make RB2 an output


> Forgive my ignorance.  I think I'll follow a bit better when I get a
> simple circuit with LED wired up to see the results.

No need to apologize, you've done nothing wrong. Remember that Olin can
sometimes be very direct or even rude (he can't help it).


Vitaliy

2008\12\09@162959 by olin piclist

face picon face
Vitaliy wrote:
> You would not have to worry about bank selects if you used an 18F or
> higher. Switch, before it is too late! :-)

You are correct that TRISB is in the access bank, but be aware that not all
SFRs are.  I don't want someone getting the impression you don't have to
consider banking at all on a PIC 18.  That is definitely not the case.

> No need to apologize, you've done nothing wrong.

Even ignoring the bad comment, this is only true if he is on a PIC 18.
Maybe that was stated earlier, I haven't followed the thread that closely.
If not, then ignoring banking is definitely wrong.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@163240 by apptech

face
flavicon
face
>>> I always chuckle when someone goes out of his way to specify
>>> the radix of 0

>> Actually, the Radix isn't zero.  It's Hex.

> Note I said "the radix of 0", referring to the fact that it was
> specifically
> a hex zero, implying a octal or binary or decimal zero wouldn't work here.

I won't even start to note that Heisenberg indicates that no value of zero
is valid for very long at all, no matter how radical.


       Russell

2008\12\09@164712 by Peter Onion

flavicon
face

On Tue, 2008-12-09 at 11:41 -0600, PAUL James wrote:
> Actually, the Radix isn't zero.  It's Hex.  0x00 is a number in the
> radix of choice, ie hex.

Olin didn't say the radix was zero..  He said "the radix OF zero"

Why specify a radix (16 in this case) when zero is the same no matter
which radix you use !

PeterO


2008\12\09@171501 by M. Adam Davis

face picon face
Mainly so you don't trip yourself up later accidently when you go to change it.

-Adam

On Tue, Dec 9, 2008 at 4:46 PM, Peter Onion <Peter.OnionspamKILLspambtinternet.com> wrote:
{Quote hidden}

> -

2008\12\09@171812 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> You would not have to worry about bank selects if you used an 18F or
>> higher. Switch, before it is too late! :-)
>
> You are correct that TRISB is in the access bank, but be aware that not
> all
> SFRs are.  I don't want someone getting the impression you don't have to
> consider banking at all on a PIC 18.  That is definitely not the case.

I think that it would be fair to say that if he was programming in C on a
PIC18F, that for all intents and purposes he would not have to worry about
banking.

>> No need to apologize, you've done nothing wrong.
>
> Even ignoring the bad comment, this is only true if he is on a PIC 18.
> Maybe that was stated earlier, I haven't followed the thread that closely.
> If not, then ignoring banking is definitely wrong.

The "you've done nothing wrong" part was in reference to Joe's apology. As
far as I can tell, he has done everything you would expect a person new to
PICs to do.

Writing a comment that says the same thing as the line of code it's
describing is a common mistake that everyone makes. Typing "0x00" instead of
a "0" is a matter of personal preference, and no reason for ridicule.

Since Joe had obviously done his homework, and made an effort to solve the
problem before bringing it to the list, I think he deserves a little praise
and encouragement.

Vitaliy


2008\12\09@174451 by olin piclist

face picon face
apptech wrote:
> I won't even start to note that Heisenberg indicates that no value of
> zero is valid for very long at all, no matter how radical.

We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@174830 by olin piclist

face picon face
Vitaliy wrote:
> I think that it would be fair to say that if he was programming in C
> on a PIC18F, that for all intents and purposes he would not have to
> worry about banking.

True, but the code posted was in assembler.

> Since Joe had obviously done his homework, and made an effort to
> solve the problem before bringing it to the list, I think he deserves
> a little praise and encouragement.

I agree.  But that doesn't mean bad comments and forgetting about banking
should not be pointed out.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\09@181100 by Wouter van Ooijen

face picon face
> We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)

I have a batch of low-accuracy zero's in stock
(black-black-unspecified-silver). Anyone interested?

--

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\09@181745 by Mark Rages

face picon face
On Tue, Dec 9, 2008 at 5:09 PM, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:
>> We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)
>
> I have a batch of low-accuracy zero's in stock
> (black-black-unspecified-silver). Anyone interested?
>

Sure, you can use several in series to achieve higher accuracy.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
EraseMEmarkragesspam_OUTspamTakeThisOuTmidwesttelecine.com

2008\12\09@183008 by Joe Bento

face
flavicon
face


Olin Lathrop wrote:
>
> We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)
>
>  
Everyone is probably familiar with 0 ohm "resistors."   Ever note that
they indeed list their value as 0 ohms +/- 5%?  I'm still trying to find
one that's a few percent off.  :-)

Joe

2008\12\09@184501 by Michael Algernon

flavicon
face
How much ?  And what is the shipping weight ?
MA

On Dec 9, 2008, at 4:09 PM, Wouter van Ooijen wrote:

{Quote hidden}

 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\09@191409 by Jinx

face picon face
> >> We're using engineering 0, which is 0 +-5% unless otherwise  
> >> specified ;-)
> >
> > I have a batch of low-accuracy zero's in stock
> > (black-black-unspecified-silver). Anyone interested?

> How much ?  And what is the shipping weight ?

$0 +/- 5%, 0kg +/- 5%

2008\12\09@222108 by Forrest Christian

flavicon
face
Jinx wrote:
> How much ?  And what is the shipping weight ?
>  
>
> $0 +/- 5%, 0kg +/- 5%
>
>  
I'd like to take an infinite number of those please.   I'll probably
still end up with a package which is 0kg +-5%, including the packaging.

-forrest


2008\12\09@230305 by M. Adam Davis

face picon face
On Tue, Dec 9, 2008 at 5:44 PM, Olin Lathrop <olin_piclistspamspam_OUTembedinc.com> wrote:
> We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)

LOL - you got me with that one.

hehehe

-Adam

--
Please rate and vote for my contest entry:
mypic32.com/web/guest/profiles?profileID=50331

2008\12\10@013954 by Wouter van Ooijen

face picon face
Michael Algernon wrote:
> How much ?  And what is the shipping weight ?

Roughly Aleph-0, and zero (+/- 10%). Maybe I can even reduce the weight
little bit by using RLE encoding, that always works good with strings of
0's.

Yesterday my 6-y old son asked if there were any other operators besides
+ - * / and sqrt. I told him there were, but I could not explain them
yet. But a few weeks ago he discussed with a friend whether 'the largest
number' exists or not, so I told him a little about the properies of
aleph-0. (http://en.wikipedia.org/wiki/Aleph_number) I hope he won't
confuse his teacher too much...


--

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\10@015747 by Marcel Birthelmer

flavicon
face
Roughly Aleph-0, and zero (+/- 10%). Maybe I can even reduce the weight
> little bit by using RLE encoding, that always works good with strings of
> 0's.
>
> Yesterday my 6-y old son asked if there were any other operators besides
> + - * / and sqrt. I told him there were, but I could not explain them
> yet. But a few weeks ago he discussed with a friend whether 'the largest
> number' exists or not, so I told him a little about the properies of
> aleph-0. (http://en.wikipedia.org/wiki/Aleph_number) I hope he won't
> confuse his teacher too much...
>

You should have him stay at the Hilbert Hotel sometime...

2008\12\10@021158 by apptech

face
flavicon
face
>> I won't even start to note that Heisenberg indicates that no value of
>> zero is valid for very long at all, no matter how radical.

> We're using engineering 0, which is 0 +-5% unless otherwise specified ;-)

Ok, adjusting by 5% each way, that's the range

   0 <= X <= 0            :-)

Heisenberg is still knocking.


       Russell

2008\12\10@022650 by Wouter van Ooijen

face picon face
> You should have him stay at the Hilbert Hotel sometime...

Probably next year. He could grasp A - 1 = A, A / 2 = A, etc, but then
asked about A / A....


--

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\10@051636 by Alan B. Pearce

face picon face
>so I told him a little about the properies of aleph-0.
> (http://en.wikipedia.org/wiki/Aleph_number) I hope
>he won't confuse his teacher too much...

Shades of the science teacher I had in first year secondary school, who had
difficulty with the explanation of AC that was given on an instructional
movie she showed us. DC she was happy, AC she couldn't understand ...

2008\12\10@052603 by apptech

face
flavicon
face
> Roughly Aleph-0, and zero (+/- 10%). Maybe I can even reduce the weight
> little bit by using RLE encoding, that always works good with strings of
> 0's.

I tried that, but got a divide by zero error :-(.

   R

2008\12\10@105555 by Bob Ammerman

picon face
>PAUL James wrote:
>> Actually, the Radix isn't zero.  It's Hex.  0x00 is a number in the
>> radix of choice, ie hex.
>
> Olin didn't say the radix was zero..  He said "the radix OF zero"
>
> Why specify a radix (16 in this case) when zero is the same no matter
> which radix you use !
>
> PeterO

Actually, it makes a lot of sense to use hex here: it reminds the user that
the value is a collection of individual bits.

However, nobody questioned why the instruction is needed at all. Why not
just use a

  clrf trisb

instead?

-- Bob Ammerman
RAm Systems

2008\12\10@131709 by Vitaliy

flavicon
face
Bob Ammerman wrote:
>> Why specify a radix (16 in this case) when zero is the same no matter
>> which radix you use !
>>
> Actually, it makes a lot of sense to use hex here: it reminds the user
> that
> the value is a collection of individual bits.

Well said.


> However, nobody questioned why the instruction is needed at all. Why not
> just use a
>
>   clrf trisb
>
> instead?

Probably because the OP might want to configure the port to have some inputs
in the future?


2008\12\10@213552 by Joseph Bento

face
flavicon
face

On Dec 9, 2008, at 3:48 PM, Olin Lathrop wrote:

>
>> Since Joe had obviously done his homework, and made an effort to
>> solve the problem before bringing it to the list, I think he deserves
>> a little praise and encouragement.
>
> I agree.  But that doesn't mean bad comments and forgetting about  
> banking
> should not be pointed out.
>

I apologize, but bad comments will probably be common for awhile.  :-)

My example:
movlw       0x00       ;load w with 0x00

might be entirely self explanatory to someone familiar with the  
instruction set.  Remember that I am just learning and assembly is  
rather cryptic to me still.  I do speak binary and hexadecimal,  
however, and I can carry a reasonable conversation in octal.  :-)

I haven't touched on banking in my studies yet.  The whole point of my  
example many messages back was to try and understand an alternative to  
the TRIS statement.  So many tutorials state that TRIS is obsolete,  
higher level chips do not support it at all, and Microchip may decide  
to drop its recognition at any time.  YET - all these tutorials  
continue to use it despite the warnings.  I was just trying to gain an  
understanding on an alternative.

Keep up the constructive criticism, Olin.  It makes me want to try  
harder.  :-)

Joe

2008\12\10@214105 by Joseph Bento

face
flavicon
face

On Dec 9, 2008, at 10:48 AM, Olin Lathrop wrote:
>
> The MOVLW 0 instruction is correct, it's the comment that's  
> useless.  The
> fact that you specifically insisted it be a hexadecimal zero is merely
> humorous.

Perhaps next time I should try:

movlw        b'00000000'                ;lets call this a binary 0
movlw        d'00'                        ;and this a decimal zero

Perhaps I'm beginning to see the humor, but cut me some slack, OK?  :-)

Joe

2008\12\11@150032 by Peter

picon face
> Perhaps next time I should try:
> movlw        b'00000000'                ;lets call this a binary 0
> movlw        d'00'                        ;and this a decimal zero

If you will start using a revision control system and try that trick then you
will have two revisions that output the same code but check out different via
the toolchains diff. That will lead to a lot of head-scratching down the road,
either by you or by the poor sod who will inherit your sources for maintenance.

Peter


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