Subject:
Re: [gnupic] PK2 resources for beginners who would like to achieve something
From:
Peter Keller ####@####.####
Date:
30 Jun 2009 04:50:42 -0000
Message-Id: <20090630045039.GA28879@cs.wisc.edu>
Hello,
On Tue, Jun 30, 2009 at 03:56:36AM +0000, Darwin Pintado wrote:
> Thanks for all the response. For the past days, I've been doing a research
> on the the device I have -> PIC16F690 to have a big picture understanding
> and the device I have as of the moment. I am still in the process of
> understanding each modules and I was wondering in the I/O ports, lets say
> PORTC, I am curiuos why there are unimplemented bits and unknown bits.
If I understand your concern correctly, you can see an example of this
on page 76 in the 2008 pic16f690 datasheet[0]. 'x' means unknown and
this is in regards to when the chip is powered on. When the chip is
powered on, those bits, and consequently the ports themselves, are
in an unknown state. If you notice, PORTC defaults to 'read' status
(via the TRISC port), which means it isn't also emitting random logic
high/low onto the lines connected to the port. This is important because
it prevents the chip from putting the associated logic connected to it
into an unknown state upon power up.
The '-' you see in the data sheet, suppose page 80, means that writes will
be ignored on those bits, and reads will return 0. Unimplemented means
that those bits simply aren't used, for anything. Even though that is the
case, I recommend only writing 0 to them when loading those registers since
there could be silicon bugs or whatnot you might tickle if you write 1 to
unimplemented bits on a write.
The 'u', also on page 80, means unchanged. If you inspect the PORTC
line on page 80, you'll see that on POR (Power On Reset), or BOR (Brown
Out Reset), the values in PORTC will be unknown, but on all other
resets--suppose the watch dog timer resets the device, the bits will
be unchanged in PORTC. All of the registers have a behavior like this,
and for the specific features you are using in a project, you must ensure
that each register (associated with those feature) behaves how you expect
and you understand why.
The PIC16F690 has a fair number of modules that often share pins.
This is why you have to turn of the analog channels ANSEL and ANSELH
for the corresponding PORTC pins in order to get digital I/O on the
pin when initializing PORTC (as described on page 76, example 4-4). In
fact, on one pin, you cannot do analog i/o and digital i/o _at the
same time_. You can switch between them, though. Page 80 shows the
initialization state for the ANSEL/ANSELH bits and the portion of the
data sheet that describes those two registers tell you that 1 means
analog input and 0 means digital I/O.
For your intial project, get a single LED blinking using bit 0 of PORTA
(and a hardcoded delay loop to waste time, instead of an interrupt driven
solution--no need to complicate what you need to learn). The PORTA
portion of the data sheet shows example initialization of the port.
Once you get that going, then hook up all of the pins of PORTA and
make a "knight rider" display of an led going back and forth across the
registers. When you get that done, make a display using all the pins on
ports A, B, C (in a straight line on your breadboard), and have an LED
go from one end to the other end. If you get that done, you'll have a
good understanding for how to initialize and use the ports in a digital
I/O output context. For digital input, if it is from another logic chip,
it is generally pretty easy, but if it is from a switch, you are required
to worry about to properly debounce a switch. There are decent papers
on this on the internet.
Some modules like the SSP module are pretty complex--don't expect to just
"pick those up" with a single, or even multiple, readings. The I2C and SPI
communication models are complex (I2C is more complex than SPI). I'd leave
those for last in learning how to use this uP after you're grounded in
the other modules. I personally have used every feature of the PIC16F690
except I2C and the PWM module for various hobby projects. (I know how
to do PWM, but I just did it in assembly instead of using the module
since I needed many more pins with PWM on it than the module allowed me.)
The electrical things you initially need to worry about are these:
1. Crosstalk
a. magnetic
b. capacitive
2. clock line noise
3. Don't exceed current ratings for pins or other hardware.
1 is what happens if you have physically parallel data lines with a lot of
current in them, suppose 20ma each. When you write patterns like 11101111 and
00010000 over and over again, you'll probably get glitches on the lines from
the magnetic fields interacting with each other. To reduce this, put less
current through the data line, like 2ma or so. With enough research, you
can find decent papers on the net about cross talk. There isa similar analogue
for when the coupling is capacitive, and some research on the net will explain
it better.
2 happens because clock lines often have high current in order to have
enough oomph to make it across the board and to feed multiple chips. These
should be placed far away from other lines, or pass over them at right angles
to the data lines.
3 means have a good understanding of the current you actually need
for something and ensure you use resistors of the right wattage at the
appropriate times.
Since I don't have an oscilloscope, I learned the hard and long way about
cross talk, how to recognize it, and avoid it. I'm fastidious about it now
in my designs because it is so hard to debug electrical signals if they
glitch. With some care, I haven't had any more problems.
Also, one more thing. Understand all of your configuration bits, and set them
ALL to known values. Don't rely on default values for them. Simply understand
them and set them correctly. While messing about with the PIC initially, use
a 4MHz clock. This frequency is relatively safe on breadboards.
Thank you.
-pete
[0] http://ww1.microchip.com/downloads/en/DeviceDoc/41262E.pdf
P.S. Since I'm just a hobbiest, I am probably wrong on things, so make
sure you understand things as you do them and don't assume anything
about the chip, the surrounding hardware, or some idiot like me on a
list somewhere. :)
