>
> Hi all.
>
> I've been interested in 8051s for ages - but someone recently introduced
> me to the ridiculously cheap DIY PIC16C84 programmers, and Im now a
> total convert...
Most of us are.
>
> Some questions:
>
> The PIC mnemonics, IMHO, are terrible. Is there a 'standard' better
> mnemonic set?
Well parallax has a set of mnemonics that are 8051 based. The two problems
are that you no longer know exactly how long each instruction is and that
you need the parallax assembler.
Personally I find the PIC instruction set very clean and concise. Very good
for compiler writing. A PIC compiler of a language somewhere between C and
BASIC is one of my summer projects.
>
> Are there any example PIC sources available?
Call Microchip or a local rep and ask for the applications notes for the
PIC series. It has dozens of example programs for you to look at. And all
of them are in the original PIC instruction set so you can see how the
set operates.
> Is the serial programming algorithm of the 16C84 the same or similar to
> that of the other two recent PICs (I forget the names - the 33 IO pin
> one, and the one with internal ADC) -
There are two 40 pin chips (17C42 and 16C64). The internal ADC is a 16C71.
> Can I use a similar modified serial programmer to blow these?
The 16C84 and the 16C71 use almost the same serial algorithm.
A good idea is to get the Microchip Microcontroller data book. It has not
only the data sheets for all the parts but the programming algorithms too.
Michchip is just too cool with the way they interact with us hobby
enthusiasts!
> It is always better to get used to the manufacturer's mnemonics as any code
> examples or help you get from others is likely to be in that form. A good
> macro assembler will allow you to generalize your code to make it more
> portable.
I take your point as a general idea, but come on - ADDWF f,d where d is
*direction*!!! Whats wrong with ADD f,W / ADD W,f?
Ive programmed Z80, 6502, 8051, 77C82, ARM2, 68000 - and I have to say
that the PIC has the least user friendly mnemonics of the lot.
Still - Im sure I'll get used to them in time...
Peter
-
Peter Knight Email: spam_OUTp.j.knightTakeThisOuTuk.ac.bradford Mono: Cathedrow
_ _ _ _
Who says you can't display letters on a 7 | _| |_ |_ |_| _| _ _ _|
segment display? OK, so you can't do a W..|_ |_| |_ | | |_ |_| | |_| _|
Tom,
Thanks for the question:
> Tell me more about ASPIC ?
I will try to avoid making it sound like an ad <smile>...
ASPIC is a shareware assembler (reg = $100 CDN ($69 US)) which has been in
use since late 1991 for PIC and since 1986 for other processors (NEC
78c10, Mitsubishi MELPS 8 and 16 bit). It is **DESIGNED** for embedded
controler design, so it has som unusual features like character set
translation (eg. for LED, LCD, and On Screen Displays), bit labels,
environment labels, etc.
It is very stable (only 3 bugs reported and fixed in the last 2 years), and
it integrates well with other developement tools. A short list of features
reads something like:
- One assembler for 16c5X, 16c7X, 16c8X, 17c42
- Compatable with PICSIM (MPSIM)
- Compatable with MAKE, and with auto-error tracking editors
- Many times faster than PICALC (MPALC)
- Standard base notation (Intel & Motorola format)
- CODE and FUNCTION macros
- Auto register bank management
- Text/data translation
- Automaticly generates RETLW tables for text and data tables
- Built-in version management and assembly control functions
- user command-line switches
- many other features
(hope that didn't sound too much like an ad, but the shareware license has
an unusual clause absolving those who don't register but only use it for
non-commercial purposes)
I can't ftp from compuserve, but it is available around. Try microchips
bbs (3rdparty file area) or my BBS @(604) 597-3479.
I just received confirmation of my registration for the upcoming PIC seminar,
along with a few brochures.
One of the brochures includes some parts I had not previously heard of, the
PIC16C74 and PIC17C44.
The PIC16C74 is apparently sort of an improved combination of the 16C64 and
16C71. It is available in 40 and 44 pin packages like the 16C64, and has
even more memory (4K*14 program, 192*8 data). It has an 8-channel 8-bit A/D
(presumably similar to the 4-channel A/D of the 16C71).
I hope the PICSTART-16C will program the 16C74. I don't want to buy yet
another programmer. (By the way, does anyone know whether the PICSTART-16B
will program the 16C58A?)
The PIC17C44 appears to be a 17C42 with more memory. I've never been
convinced that the 17C42 was a very cost effective part, so I doubt that the
17C44 will be either.
On 18 May 1994, Peter Knight <.....P.J.KnightKILLspam@spam@bradford.ac.uk> wrote:
> I take your point as a general idea, but come on - ADDWF f,d where d is
> *direction*!!! Whats wrong with ADD f,W / ADD W,f?
I agree with your comments about Microchip's syntax being suboptimal, but
I should point out that the ",d" doesn't specify the direction, it specifies
the destination. While this may seem like a minor point, consider the
SUBWF instruction:
SUBWF FOO,W ; W := FOO - W
SUBWF FOO,F ; F := FOO - W
While discussing subtract instructions, I should point out that the SUBLW
instruction subtracts the contents of W *FROM* the literal, which is not what
people generally expect.
At first this seemed brain-damaged but then I discovered that it is useful.
If you want to take the two's complement of W, for instance, you can use
SUBLW 0 ; W := 0 - W
If you want to subtract a literal from W, you can use the ADDLW
instruction with the two's complement of the literal:
ADDLW 0feh ; W := W - 2
Some assemblers will let you write this in a natural form:
> On 18 May 1994, Peter Knight <P.J.KnightKILLspambradford.ac.uk> wrote:
> > I take your point as a general idea, but come on - ADDWF f,d where d is
> > *direction*!!! Whats wrong with ADD f,W / ADD W,f?
>
> I agree with your comments about Microchip's syntax being suboptimal, but
> I should point out that the ",d" doesn't specify the direction, it specifies
> the destination. While this may seem like a minor point, consider the
> SUBWF instruction:
OK - my mistake - I did mean destination...
Thanks for the hint on SUBLW - I missed that subtle point!
Peter
-
Peter Knight Email: .....p.j.knightKILLspam.....uk.ac.bradford Mono: Cathedrow
_ _ _ _
Who says you can't display letters on a 7 | _| |_ |_ |_| _| _ _ _|
segment display? OK, so you can't do a W..|_ |_| |_ | | |_ |_| | |_| _|
TRISYS, Inc has placed two shareware packages 'idesw.zip' and 'mvsw.zip'
on ftp server ftp.sics.se in the /pub/mchipsoft directory area. (they
should be made available for download by the sysop in a day or so, after
he checks them out) Give them a try.. mail any comments to the
email server EraseMEpicspam_OUTTakeThisOuTfigment.mit.edu, or directly to TRISYS, Inc at trisysspam_OUTramp.com
If you are not interesed in these environments.. Some windows
help files for the PIC processors have been uploaded there also.
If you are downloading the environments, do not download the help
files also because they are zipped with 'idesw.zip' and 'mvsw.zip'
idesw.zip - This is a shareware Windows 3.1 MDI compliant integrated
editor and assembler for the Microchip PIC family of parts.
It supports the PIC16C5X, PIC16C6X, PIC16C7X, PIC16C8X, and PIC17C42
processors.
mvsw.zip - this is a shareware Windows 3.1 MDI compliant editor,
assembler, and simulator for the Microchip PIC16C 54, 55, 56,57, & 58
processors. It provides the following capabilities.
* Integrated editor/assembler/error windows.
- Editor provides Undo, Cut, Copy, Paste.
- Supports multiple fonts & Windows printer driverrs.
- All windows (error, listing, and memory) updated after
assembly automatically.
- Double click on error line takes you to the source
code line with the error.
* Simulation
- Quadrature based simulation. Single step by quadrature.
- Allow modification of any file register or special
function register at any quadrature, as well as the
instruction pipeline, stack, prescaler etc.
* Timing/Stimulus
- Set and display testpoints on processor pins.
- Create stimuls for processor pins.
- Does not support printing at this time.
- Connect output from one pin to input of another.
- Registered version supports simultaneous multiple processor
simulation. Useful for testing/simulating communication between
processors.
- Registered version supports connection of one processorr pin
to another processor pin.
* Breakpoints on.
- Read or Write
- Register value 'is greater than', 'is less than', and
'masked with' a value is true.
- Break on line in listing window.
The registered version will support COD output format for compatiblity
with Microchips burners and emulators. The shareware version supports
only the PIC16C54 processor while the registered version supports the
entire PIC 16C5X processor family. The registered version supports
multiple processor simulations.
Additional processor families will be developed to support the entire
Microchip PIC processor families. Registered users will be notified
when these processors additions are available.
All the documentation for both the Assembler and MicroView environments
is online.
We are currently working on native language versions of these products
and will have them available soon. If you would be interested in
assisting language conversions to your native language, please contact
TRISYS at @spam@trisysKILLspamramp.com
Please send any questions or comments to: KILLspamtrisysKILLspamramp.com.
We can also be reached on the Microchip bulletin board. Post messages
in the 3rdparty forum or send mail to trisys.
I need some beta testers for a piece of software I will be releasing to the net.
The program is a fairly basic pic disassembler, and I need to have as much code
run through it and checked as possible.
Now I realise this is NOT the most useful piece of software around (but it may
be useful to decode programs that have been "lost" in .asm format).
It is however a start on the road to an assembler/debugger system. The major
_feature_ of these tools being that they may be compiled/run on any machine
or OS having a C compiler capable of building them.
The disassembler decodes from an INHX16 style file (default output of MPALC) and
produces Microchip standard mnemonics. It will decode either 12 or 14 bit pic
code.
The beta testers in return for testing and suggestions will receive the huge kudos (?)
of having their names in the readme file :-) and some input on the final release
version of this and any other code.
The final bugs^H^H^H^Hfeatures are currently being hammered out, but the code should
be delivered (via e-mail) early next week to those lucky people who want it.
=%-)
Ian
p.s. I will just be supplying the C code, so beta testers must have a compiler
for their platform! The code has been developed on a Sun (Solaris 2.3) using Sun's own
compiler. I can produce MS-DOS and Linux targets (I hope ;-) for a final release but
others (amigas and macs) will require someone else to build them for me (hint hint).
p.p.s. The final release will probably be released as "postcard-ware" i.e. licence to use
requires the sending of a postcard of your hometown to me...
I am programming an 71' series and whenever I issue a clrb ra.4 which is
the open collector pin all of the RA ports are set to 0. This is really
screwing me over hard as the other RA ports are control lines that
respond 4x as fast as my PIC thus I end up over driving my lines. Any
ideas? is this a flaw with the 71? If you think you know what i am
talking about and want more info email me. I really could use some help.
later
John
_____________________________________________________________________________
John Johnson |If it's not OS/2.|RemoveMEjohnsonjTakeThisOuTccwf.cc.utexas.edu
|It's crap! |spamBeGonejohnsonjspamBeGoneghostwheel.bga.com
OOOO SSSS /2222 2222 11 | |
O O S / 2 2 1 |"We need breath- |"Bite me." Tom Servo
O O SSSS / 2222 2222 1 |-ing room!" |
O O S / 2 2 .. 1 | Bill Gates |"I want to decide who lives
OOOO SSSS/ 2222 2222 .. 111| |and who dies" Crow T. Robot
-----------------------------------------------------------------------------
> Is "CLRB" one of the Parallax instructions? What does it actually assemble
> into? Hopefully a "BCF"? I avoid the Parallax instructions like the plague;
> IMHO all they do is obfuscate the code. Sometimes I define macros, but
> certainly not to make it look like an 8051.
I actually like them. While not true Microchip instructions, I think they
read better. In actuality all they are are macros. Plus I am overly fond of
their simulator, Microchips is better in some places though, well most
actually.
>
> There are various wierd problems that can occur when you try to use BCF and
> BSF (or any other read/modify/write instructions, such as INCF) on I/O ports.
> I can't be sure exactly what's happening without knowing more about how you
> are using the other port A pins.
I called microchip and they knew of the problem. It deals with the fact that
ra.4 does not have tris bit for it. Screw up in the mask. If i had
taken time to dl the eratta sheets on teh 71 I would have found this out.
And yes it does stim directly from your above statement. when you bcf
5,4 the whole tris reg gets messed up and you can end up driving the pin
w/o any output(ouch)
>
> A common problem (but not necessarily the one troubling you) is that the the
> read/modify/write instructions read the actual voltage level at the pin, not
> the bit in the output latch. If external hardware drives the lines this
> can cause unexpected behavior. For instance, if you write $ff to the port, and
> external hardware is forcing PA0 low, and then you do a BCF porta,4, the output
> latch for PA0 will be set to 0, and the chip will start driving it low.
ummm yup exactly what happend. Ended up sucking a whole lot of current.
Almost 200mA.
>
> I'd recommend writing the entire port with a MOVWF when you want to change it.
> (Microchip recommends this also for a different reason).
wheter you recommend it or not is irrelevent :) its the only way around
my problem. So in fact your suggestion is not mearly a suggestion but
law..
thanks for your help. and to all of the others who offered me help too..
live long and PIC, sorry I just had to say it
_____________________________________________________________________________
John Johnson |If it's not OS/2.|TakeThisOuTjohnsonjEraseMEspam_OUTccwf.cc.utexas.edu
|It's crap! |RemoveMEjohnsonjTakeThisOuTghostwheel.bga.com
OOOO SSSS /2222 2222 11 | |
O O S / 2 2 1 |"We need breath- |"Bite me." Tom Servo
O O SSSS / 2222 2222 1 |-ing room!" |
O O S / 2 2 .. 1 | Bill Gates |"I want to decide who lives
OOOO SSSS/ 2222 2222 .. 111| |and who dies" Crow T. Robot
-----------------------------------------------------------------------------
> TRISYS, Inc has placed two shareware packages 'idesw.zip' and 'mvsw.zip'
> on ftp server ftp.sics.se in the /pub/mchipsoft directory area. (they
> should be made available for download by the sysop in a day or so, after
This is now available; Has anyone managed to get a run out of it yet ?
I tried to run the demo progs and get errors like;
can't POP - stack full
Or words to that effect.
I also get run time errors <stack overflow> Same problem ??
Comments anyone ?
--
Cheers
Tom
Tom:
I have gotten one other report of a <stack overflow>. I cannot
duplicate this on my machine. Could you tell me what you are
doing to generate this? I'll upload a updated version soon, with
a larger stack, maybe this will help.
The error can't POP stack full? This does not exist in
the software (I assume you are using MicroView). But to you
get these kinds of errors while running the simulation or
is it just a Windows message?
I have gotten a bug report on the assembler (The same is
use for both Assemble and MicroView) It is:
A bad mnemonic after a lable is skipped over. It should
be flagged as an error! The work around is to not put
a mnemonic on the same line as a label. (Or just write
perfect code the first time :-).
It has already been fixed but we are adding a few other
upgrades to the assembler before putting it back on
the MicroChip BBS and the ftp.sics.se sites.
Any other comments, error reports, and suggestions are
greatly appreciated.
Another note. There are supplemental instructions
discussed in some Microchip documentation. (like clrb)
which are not discussed in the part data sheets.
We have created an include file which has these defined
as macros. It can be downloaded from the Microchip BBS.
We will include it with the new zip file when we upload
the new version. (comming SOON).
To get to the Microchip BBS:
- Call your compuserve access number. There is a
toll free number to find out what it is (I don't
know it)
- When you connect. It plus then return.
- At the prompt type : MCHIPBBS
That all!! Trisys files can be found in the /3rdparty
forum and library.
Thanks (Please keep comments comming)
David Foringer (TRISYS, Inc.)
Hi.
On stack overflow problem reported with the TRISYS
assembler and MicroView.
The assembler does not currently process the '.' (period)
operator. (Don't use it!) The next version will support
the period for bit representations. (i.e. BTFSS STATUS.C)
Hope this helps. If you are having any other problems
Let us know and we will fix them ASAP!
David Foringer (TRISYS, Inc).
I have a problem with the program mpsim and the watchdog-generator at the
PIC 16c54. My program is resetet by the watchdog only the first time after I
called the sleep comand. There is no time-out after the second sleep comand.
Is it an error of mine or a bug in the mpsim?
I bought the PIC C compiler from CCS (The guy in Milwaukee) thinking it
would make programming 16c5x's even easier. (I also have the Parallax
PGM & EMU) And reallly I can only say positive things about the compiler.
It is a simple TurboVision app, and truly easy to use and convenient. So
I have a question for anyone who may also be using this compiler. I am
using the serial library to do printf()'s getchar()'s etc, and of course
the code works fine when I use an RS232 chip, but I would like to take the
signal directly off the PICs pin. The problem with this is that I need to
send the complement of each bit if I do it that way. I could use a 7404,
but then I might as well use an RS232 chip. Does anyone know how to change
how the serial library works so I can do it this way?
Has anyone networked several PICs (or STAMPs) together ?
Did you use RS-485 ? How about simply wiring toegether several
open-drain outputs on different PICs ? Are there any examples
of software for networking ?
Bob Armstrong (RemoveMEbobspam_OUTKILLspampoco-adagio.santa-clara.ca.us) wrote:
>
> Has anyone networked several PICs (or STAMPs) together ?
> Did you use RS-485 ? How about simply wiring toegether several
> open-drain outputs on different PICs ? Are there any examples
> of software for networking ?
>
Not yet, but I will be doing something pretty similar in the next couple
months. I've seen a neat wire-OR scheme for RS-485 where you use cheaper
RS-422 drivers ( a little, I think) and hook data input up to the driver
enable pin. Essentially allows wire-or with simpler protocols.
I'll post anything interesting that comes up.
/s/ Bill
Yes, we (Custom Hardware Engineering) have been networking the PIC for
home-automation products using our "RS232-BUS". It's simple, easy to use,
and an open protocol. We simply connect multiple PICs together on an RS232
line. Their is a transmit and a recieve line (just like RS232). The
transmit line connects to one of the data lines of multiple PICs through a
large resistor (1meg). So, there isn't much drain on this line. The
receive line is tied to -12V through a 2.2K resistor somewhere on the bus
and is tied to an opto-isolator which can pull the line to +12V by a normally
off pin on each PIC. When the communication is only between a "host"
(normally a PC), and the other devices on the bus, the data protocol is
simply two bytes of address data followed by two bytes of command/data. The
devices then return their address followed by two bytes of response data
(if needed). It is possible for devices to speak to one another on the bus
but in this case, it is required that the device respond in some manner, so
the sender knows that a collision has not occured.
For more specifics, feel free to write me back. Also, a quicky - we are
offering a line of home-automation products that work over our RS232-BUS
protocol. At present, we have a temperature sensor and a thermostat based
on the PIC and this protocol but we will have much more in the coming months.
We are also looking at offering kits if anyone is interested. To get on our
mailing list, just respond to this note asking to be placed on it and I'll
add you. We won't send out lots of mail - just notify you of new products
and any information you may want/need concerning out RS232-BUS devices.
*****************************************************************************
* Paul Greenwood -> -> -> -> -> -> -> Custom Hardware Engineering *
*---------------------------------------------------------------------------*
* "Any sufficiently advanced technology is indistinguishable from MAGIC." *
* - Arthur C. Clarke *
*****************************************************************************
>From: Mark <RemoveMEmbmooreTakeThisOuTspambga.com>
>and an open protocol. We simply connect multiple PICs together on an RS232
>line. Their is a transmit and a recieve line (just like RS232). The
This sounds a little like RS485. I am curious why you decided not to
take this route as this would make you more compatible with other products
(including the line of home automation modules from Circuit Cellar).
YOurs, Ed
+---------------------------------------+-----------------------------------+
| Edward Cheung, Ph.D. | The opinions expressed herein |
|Satellite Servicing Robotics Laboratory| do not necessarily reflect |
| NASA Goddard Space Flight Center | those of my employers' |
| Code 714.1, Bldg T11B | |
| Greenbelt, MD 20771 | |
| 301-286-1269(office) 286-1717(fax) | My next book: |
| Internet: EraseMEcheungspamspamBeGoneasylum.gsfc.nasa.gov | Statistics, Demos and Other Lies |
+---------------------------------------+-----------------------------------+
> A secondary piece of code runs fine in the simulator, but nevers runs on
> the hardware (same hardware that runs a simplier but similar program).
If you ever use indirect addressing at all, make sure you set the FSR to zero
before you initialize any other memory. The simulator probably starts with
zero in the FSR, but the chip doesn't. Since two bits of the FSR determine
which register bank is directly accessible, if you don't initialize it your
direct RAM accesses will be to a random bank. Then when you set the FSR
in preparation to use IND, you will lose all your data.
Then again, you might have an entirely different problem :-)
A secondary piece of code runs fine in the simulator, but nevers runs on
the hardware (same hardware that runs a simplier but similar program).
Is there any known traps that I particularly should watch when I goto the
hardware? I have spent the last two weekends on this problem, so any
advice would be appreciate. I am happy to send my code to anyone that
may help solve the problem.
regards
Gary Gaskell
DSTC
Cooperative Research Centre for Distributed Systems Technology
Queensland University of Technology
Ph +61-7-864 1051 FAX +61-7-864 1282
Email RemoveMEgaskellKILLspamdstc.qut.edu.au
Pitfalls I have run into that may or may not be what you're up
against:
1. FSR in a 57 may be pointing to any register bank on startup. The
simulator might assume bank 0 always. Clear the FSR at the start of
all 57 code that cares about the bank switching ability.
2. I've found SLEEP to not work sometimes if it's in the second half
of a page.
3. You may have code that spills over a page boundary and uses jumps,
in which case it jumps to the wrong page. My habit is to always
include org 0, org 100h, org 200h ... org 700h in every '57 program,
and put at least a nop at the top of each half page, so any time
anything spills over, the assembler will tell you.
4. Never compare RTCC directly with anything. Move it to W first, or
the PIC will give erroneous results. For instance, testing RTCC will
never set the Z bit, even though if you repeatedly move RTCC to W and
test W you'll see zero every 256 ticks.
5. Remember to reset page select registers after a call to a
subroutine not on the current page. Otherwise, local jumps aren't ;^)
Good luck finding your problem. I've discovered most of these by
putting checkpoints in where I flash LED's or whatever, until I figure
out what's wrong.
1) What's the difference between old & new version ROMS on the
Parallax programmer, are they just bug fixes?
2) Will version 3.3 of PEP work with old programmer ROMS?
3) Let me re-state that - are there any conflicts between old or
new programmer ROMS and the PEP software of ANY version?
4) Are there any files on the Parallax BBS that may resolve my
clueless questions?
I'm using Parallax's assembler to target a 16C57. I noticed an
interesting behavior: When I use LCALL instruction to jump to a
sub-routine in another bank, subsequent jump instructions (JNZ, etc)
in the main code don't work correctly.
This is because the LCALL sets the bank select bits. When the RET
instruction is executed, these don't get reset back to the bank of the
LCALL. So any 9-bit jumps go to the bank where the subroutine was
located! This is easily fixed by using LSET just before the RET to set
the bank select bits back to the calling bank (which means you can only
call that subroutine from one bank).
Example:
org 00h ; bank 0
lcall other_sub ; call subroutine in bank 1
mov w, some_variable ; do something afterwards
xor w, #012h
jnz :not_twelve ; this jump will not work correctly! Bank select
... ; bits are set to 01.
..
:not_twelve ; this line will not be reached
... ; instead, jnz will jump to somewhere in bank 1
..
org 200h ; bank 1
other_sub ; bank select bits are 01 at this point
...
..
RET ; bank select bits do not change with this ret.
-------
Anyone have insight on this problem? The LSET workaround is OK, but I'm
wondering if I'm missing something.
--
Greg Bell | "Ever see a company's sales drop sharply due to an gregSTOPspamspam_OUTcqt.com | annoying ad campaign? You will."
-----------------------------------------------------------------------
CommQuest Technologies, Inc. (619) 633-1618 x133
You're right on top of the issue. I have noticed this too. My
current habit is to do this kind of thing:
lcall subroutine
lset $
The $ means the current address so that will always bring the page
select registers back to reality. I definitely take advantage of
optimizing situations, though. For example...
lcall subroutine
lset $
ljmp someplace
In the above you can remove the lset, since ljmp overwrites the page
select registers anyway. The same is true if there are no intervening
jumps in a string of code between "long" calls.
lcall subroutine
mov...
add...
or...
anything but a jump....
lcall someplaceelse
I'll usually put lset $ in anyway, then comment it out with an
additional comment that it is not needed any why.
My basic strategy to getting the most out of the '57 is the following:
and add code from there (replace nops as needed). That way if you
overflow a 256-word half-page, the assembler will tell you. You might
also want to change the order so all the legitimate call destinations
are together:
2. Using jump instructions, you can place subroutines at any location.
Of course, the actually destination of the call must be in the first
256 words of a given 512 word page.
For example
org 0h
Subroutine
ljmp Sub_body
org 100h
Sub_body
actual code here
ret
3. anything with a JMP PC+W (lookup table) must go in the first 256
words of a 512 word page.
4. Always explicitly clear FSR on startup. Initial register bank
selection is random! (Though it genuinely doesn't matter if you leave
FSR alone throughout your code.)
5. Unless you have grouped closely related subroutines, plan on using
LCALL always to call subroutines, and always follow with LSET $. That
way you can relocate code at will.
6. Certain optimizations beyond the above are easy. Long strings of
calls to the same routine can be one LCALL followed by a string of
simple CALLs and an LSET $ at the end, etc.
7. For some reason, I've had SLEEP fail when it's not in the first 256
words of a page. Just so ya know.
Thanks to David Thomas, Stuart Lea, Don lekei and Eric Smith for a some
previous advice. I am still having trouble, that I can't see how to attack.
My question then, was for help about why might a PIC16C57 program work fine
on the Microchip simulator, but never on the chip.
I believe that I have properly checked:
1. that the FSR is adjusted for the right data page
2. the status flags are set for the right program page
3. FSR has been initialised properly
4. All other registers that could affect this have been checked for initialisation
5. the RTCC is not compared directly but with the value in W
6. page select bit are properly maintained;
To describe the situation.
I wanted to extend code from the ap notes for provide me with 4
general purpose timers. these were designed to count down and
then trigger a flag (and action) when they timed out. The code
is yet to be modified for decimal rather than hex, but that is
just work for later.
The problem.
The timers never time out.
analysis:
If we set the timer with a value of 5 (seconds), but XORing
with constants it has been possible to trigger LEDs to indicate
that the value is decremented.
BUT,
the timer is decremented from 5 to 4, and then next time from 4
to 3, BUT it never seems to be decremented to 2 or to 1.
Hopefully you could help by:
1. Suggestions for further analysis
2. Suggestions of what might be wrong.
I am becomeing quite frustrated - it affects my confidence in
embedded programming. There are not spurious processes that
could be messing it up (it is not a DOS program!), so I am
failing to see where the difficulty could be.
Thanks for any advice. The code is appended.
PS the watchdog is not timeing out. The chips have been tried
with it on and off. I also have the chip blinking an LED (Port A
bit 3) to ensure that it is still ticking over, and that never
stops or fails.
I am including a listing file and a source file.
------------------------------------------------------------------------------
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 1
Line PC Opcode
0001 ; TST2.asm May 1, 1994
0002 ; modified to test PIC out and do demos. extra comments
added
0003 ; Insert BCD timers and test
0004 ; Original code from the Applications notes from Microchi
p.
0005 ;
0006 ; Gary Gaskell mods for count down timers.
0007 ;
0008 LIST P= 16C57
0009 ;
0010 ; Coding policy:
0011 ; A routine is a section of code. This defintion may be r
efined to two types
0012 ; of routines. The first is a PROCEDURE. Procedures may
be called
0013 ; using the stack of the PIC. The second is a "CODE SEQU
ENCE". This
0014 ; type of routine may not be called, only jumped/branched
to. The
0015 ; intention is to limit the likelihood to too many calls
resulting in
0016 ; an overflow on the stack.
0017 ; Level 0 This code is Base code (stack is empty)
0018 ; Level 1 Called from base code, may call another rou
tine. (stack=1)
0019 ; Displine and quality code requires that a r
eturn is
0020 ; executed.
0021 ; Level 2 Called from base or Level 1 code. The stack
is now full
0022 ; so no calls are allowed. branching only, b
ut a return
0023 ; is essential to unwind the stack.
0024 ; CONSTANTS will be in UPPERCASE, with variables in lowe
rcase.
0025 ;
0026 ;
0027 ; define equates:
0028 ;
0029 07FF PIC57 equ 7FFH
0030 ;
0031 ; external osc used = 4.096mHz. prescaler of 32 used, wh
ich gives a
0032 ; 31.25 microsec inc of the RTCC. If the rtcc is initial
ly loaded with 96
0033 ; it would overflow to 0 in 5.00ms. giving 0.00% error
0034 ; If the crystal is 4.000 Mhz (prototype Xtal), NB 4Mhz x
tal gives 1 Mhz
0035 ; internal clock. then overflow at 32usec,
0036 ; requiring 156.25 rtcc cycles, ie msecs should be 100, b
ut an error needs
0037 ; to be corrected. , Easier option is to decrease interva
l to 4 ms and to
0038 ; alter the constant for the seconds to 250 (249 actually
). NB gives
0039 ; 4000 instructions before the RTCC overflow must be caug
ht.
0040 ;
0041 ; MTICKS EQU d'96' ; for 4.096 Mhz xtal
0042 ; MTICKS EQU d'100' ; for 4.000Mhz xtal
0043 ; MTICKS equ d'131' ; for 4.000MHz xtal and
4msec overflow
0044 0001 MTICKS equ d'1' ; for testing
0045 ; Number of rttc timeouts to equal one second.
0046 ; NumRollover equ d'199'
0047 ; NumRollOver equ d'249'
0048 0001 NumRollover equ d'1' ; for testing
0049 ;
0050 ; needs fixing to right value
0051 0000 key_hit equ 0
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 2
Line PC Opcode
0052
0053 0001 same equ 1 ; register operation sourc
e=dest
0054 0000 C EQU 0
0055 0000 BEP EQU 0
0056 0000 RTATS EQU 0
0057 0001 DC EQU 1
0058 0001 HR10 EQU 1
0059 0002 Z EQU 2
0060 0002 HR EQU 2
0061 0004 MIN EQU 4
0062 0004 FLASH EQU 4
0063 0005 PA0 EQU 5
0064 0006 PA1 EQU 6
0065 0000 F0 EQU 0
0066 0005 LEDon EQU 5 ; is set if the LED is on. bit 5 of alflag
0067 0003 led equ 3 ; bit of portA for the le
d.
0068 0005 dataP1 equ 5 ; bit 5 of FSR (sets from
DP0 to dataPg 1)
0069 ;
0070 ; Constants for timers etc
0071 ; these are set if the timer is active
0072 0000 timer1 equ 0 ; bit numbers for flag "t
imeFlag"
0073 0001 timer2 equ 1
0074 0002 timer3 equ 2
0075 0003 timer4 equ 3
0076
0077 ; these are set if the timer has finished and awa
its action
0078 0004 tmr1end equ 4
0079 0005 tmr2end equ 5
0080 0006 tmr3end equ 6
0081 0007 tmr4end equ 7
0082
0083 ; This is the number of bytes that separate the t
imer, from
0084 ; a copy of its setup values
0085 0008 OFFSET equ 8
0086
0087
0088 ;
0089 ; DEFINE RAM LOCATIONS
0090 ;
0091 0001 RTCC EQU 1
0092 0002 PC EQU 2
0093 0003 STATUS EQU 3
0094 0004 FSR EQU 4
0095 0005 PORT_A EQU 5
0096 0006 PORT_B EQU 6
0097 0007 PORT_C EQU 7
0098 ;
0099 0008 MSTMR EQU 8 ; ms timer
0100 0009 STMR EQU 9 ; sec timer
0101 ;
0102 000A MTMR EQU 0A ; min timer
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 3
Line PC Opcode
0103 000B HTMR EQU 0B ; hour timer
0104 ;
0105 000C temp EQU 0C ;
0106 000D tmp2 EQU 0D ;
0107 ;
0108 000E timeFlag EQU 0E ; min entry
0109 000F dummy EQU 0F ; hour entry
0110 ;
0111 ; New data page : Page 0
0112 0011 tmp3 EQU 11
0113 0012 genFlag equ 12 ; general flags
0114 0013 digit equ 13
0115 0014 new_key equ 14
0116 0015 KEY_NIBL EQU 15
0117 0016 DEBOUNCE EQU 16
0118
0119 0017 MIN_SEC EQU 17 ; MIN/seconds timer
0120 ;
0121 ; PORT pin definitions
0122 ;
0123 ; Port A: s
0124 ; bit0 led to flash
0125 ; bit 1-3 unsed i/o
0126 ;
0127 ; define the RAM locations of DATA PAGE 1 (timers)
0128 ; NB to use these RAM locations (variables) the correct b
its of the
0129 ; FSR must be set (5&6).
0130 ; setup 5 timers. Each will store BCD time values and be
decremented to-
0131 ; wards zero. NB if these timers are moved the code that
works on that
0132 ; must be updated.
0133 ;
0134 ; Timers placed in Data Page 1
0135 0030 stmr1 equ 30
0136 0031 mtmr1 equ 31
0137 0032 stmr2 equ 32
0138 0033 mtmr2 equ 33
0139 0034 stmr3 equ 34
0140 0035 mtmr3 equ 35
0141 0036 stmr4 equ 36
0142 0037 mtmr4 equ 37
0143 0038 stmr1Val equ 38
0144 0039 mtmr1Val equ 39
0145 003A stmr2Val equ 3A
0146 003B mtmr2Val equ 3B
0147 003C stmr3Val equ 3C
0148 003D mtmr3Val equ 3D
0149 003E stmr4Val equ 3E
0150 003F mtmr4Val equ 3F
0151 ;
0152 ;
0153 ;
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 4
Line PC Opcode
0154 ; *******************************************************
*********************
0155 0000 org 0
0156 START
0157 0000 0A1E goto initialise
0158 ; this routine runs a test on the leds
0159 ; all the relevent leds are lit up for 2 secs.
0160 ;
0161 test_hardware
0162 0001 0C01 movlw D'1' ; flash every two for 2 se
cs
0163 0002 0037 movwf min_sec
0164 ;
0165 ;
0166 norm_time
0167 0003 0412 bcf genFlag, 0 ; put in real time
0168 0004 0432 bcf genFlag, 1
0169 ;
0170 time_loop
0171 ; call update_display
0172 ; bsf status, PA1 ; goto page 2
0173 ; call service_keys
0174 0005 05A3 bsf status, PA0 ; goto page 1
0175 0006 0900 call update_timers ; wait and update timers
(Realtime)
Warning: [Warning 1] : line 175 : Address change across page boundary, ensure page bits are set
0176 0007 04A3 bcf status, PA0
0177 0008 0D00 iorlw 0 ;
0178 0009 0743 btfss status, Z ;
0179 000A 0A0C goto GPtime ;
0180 ; movf genFlag, w ; see if in atm
0181 ; andlw B'00000011'
0182 ; xorlw B'00000001'
0183 ; btfsc status, z ; skip if not
0184 retrn
0185 000B 0A05 goto time_loop
0186
0187 GPtime
0188 ; code sequence to call general purpose timers
0189 ; Pre: only called after a second interval has past
0190
0191 000C 05A3 bsf status, PA0 ; goto page 1
0192 000D 0975 call servTmr ; service the gen purpose
timers
Warning: [Warning 2] : line 192 : Address change across page boundary, ensure page bits are set
0193 000E 09A5 call TmrAct
Warning: [Warning 3] : line 193 : Address change across page boundary, ensure page bits are set
0194 000F 04A3 bcf status, PA0 ; reset page flags
0195 0010 0915 call ChangeState
0196 0011 0A0B goto retrn
0197
0198 on
0199 ; Level 2 routine.
0200 ; set led on, by setting it low, set in flag and at port.
0201 ; Pre:
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 5
Line PC Opcode
0202 ; Post:
0203 0012 05B2 bsf genflag, LEDON
0204 0013 0465 bcf port_a, led
0205 0014 0800 retlw 0
0206 ;
0207 ChangeState
0208 ; Level 2 routine
0209 ; routine to change the state of the led. this is only e
ntered if the
0210 ; min_sec timer has reached zero.
0211 ;
0212 ; Pre:
0213 ; POst:
0214 ;
0215 ; reset value for blinks the led ever 2 secs
0216 0015 0C01 movlw D'01' ; 2 secs
0217 0016 0037 movwf min_sec
0218 ; check the led status on/off?
0219 0017 0212 movf genflag, w
0220 0018 0E20 andlw B'00100000'
0221 0019 0643 btfsc status, z ; if ledon is on
0222 001A 0A12 goto on ; turn it on
0223 001B 0565 bsf port_a, led ; turn it off
0224 001C 04B2 bcf genflag, ledon
0225 001D 0800 retlw 0
0226
0227
0228
0229 ;********************************************************
****************;
0230 ; This routine set up ports A, B, C and the internal
0231 ; real time clock counter.
0232 ; Level 1 routine
0233 ; Pre:
0234 ; Post: Timers have been setup.
0235 ; Ports have been setup
0236 ; The prescaler is set
0237 ;
0238 initialise
0239 001E 0064 clrf FSR
0240 001F 0C0F movlw B'00001111' ; make active high
0241 0020 0025 movwf port_a
0242 0021 0C00 movlw B'00000000' ; set port A as outputs
0243 0022 0005 tris port_a
0244 ;
0245 0023 0CFF movlw B'11111111' ; set levels high
0246 0024 0026 movwf port_b
0247 0025 0C00 movlw B'00000000' ; set portB as output
0248 0026 0006 tris port_b
0249 ;
0250 0027 0C00 movlw B'00000000' ; set levels low
0251 0028 0027 movwf port_c
0252 0029 0C00 movlw B'00000000' ; set port C as output
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 6
Line PC Opcode
0253 002A 0007 tris port_c
0254 ;
0255 ; OPTION REG setup
0256 ; bits 7,6,5,4,3,2,1,0
0257 ; 6,7 not avail
0258 ; 5 rt source o = int, 1, edge on rtcc pin
0259 ; 4 rtcc edge l->H '0', H-->L '1'
0260 ; 3 prescaler assignment 0 rtcc, 1 wdt
0261 ; 1,2,3 ratio of prescaler '100' = 1:32
0262 ; 000 -> scale 1:2
0263 ; 111 -> scale 1:256
0264 ; NB if scale used for wdt, then ratio is 1/2 of the rtcc
scale
0265 ; movlw B'00000100' ; set up prescaler (1:32
)
0266 002B 0C00 movlw B'00000000' ; for testing
0267 002C 0002 option
0268 ;
0269 002D 0C01 movlw MTICKS ; rtcc = 5msecs
0270 ; init the rtcc with a value MTICKS, so that when it time
s out it is
0271 ; almost exactly 5msecs.
0272 002E 0021 movwf rtcc
0273 002F 0068 clrf mstmr
0274 0030 0069 clrf stmr
0275 0031 006A clrf mtmr
0276 0032 0C12 movlw 12H ; make hours = 12
0277 0033 002B movwf htmr
0278 0034 0072 clrf genFlag
0279 0035 05A3 bsf status, PA0
0280 0036 0940 call initTmr
Warning: [Warning 4] : line 280 : Address change across page boundary, ensure page bits are set
0303 ;
0304 ; This routine is called on every loop.
0305 update_timers
0306 ;
0307 ; Pre:
0308 ; Post: returns 1 in W if a 1 second interval has past
0309
0310 0200 0004 clrwdt
0311 timerLoop
0312 ; the timer loop is currently set to time out every 5ms.
NB it must be
0313 ; less than 18 ms or the watchdog may time out.
0314 0201 0000 nop ; allow time for rtcc = 0
to be available
0315 0202 0201 movf rtcc, w ; is rtcc =0
0316 0203 0743 btfss status, z ; if 0 then skip
0317 0204 0A01 goto timerLoop ; else loop
0318 ; setup real time counter again to count out the
next 5ms
0319 0205 0C01 movlw MTICKS ; rtcc = 5ms or 4ms
0320 0206 0021 movwf rtcc
0321 0207 02A8 incf mstmr ; inc 5 ms
0322 ; btfsc genFlag, key_hit ; no key hit, then sk
ip
0323 ; goto chk_de_bounce ; else debounce
0324 ;
0325 ; check to see if a second has rolled around. IE 200 x 5m
s = 1 sec
0326 ; or 250 x 4ms = 1sec
0327 0208 0208 movf mstmr, 0 ; get mstmr in W
0328 0209 0F01 xorlw NumRollOver ; if enough to equal 1 se
c then skip
0329 020A 0743 btfss status, z
0330 020B 0800 retlw 0 ; return as not a second
interval
0331 ;
0332 ; inc seconds count
0333 020C 0068 clrf MSTMR ; CLEAR ms-TMR
0334 020D 0217 movf min_sec, w ; get min_sec timer
0335 020E 0E0F andlw B'00001111' ; mask minutes
0336 020F 0743 btfss status, z ; zero then skip
0337 0210 00F7 decf min_sec
0338 0211 0C09 movlw stmr ; load fsr with s_tmr
0339 0212 0024 movwf fsr
0340 0213 0926 call inc_60 ; inc secs
0341 0214 0D00 iorlw 0 ;
0342 0215 0743 btfss status, z ;
0343 0216 0801 retlw 1 ; only a sec passed
0344 ;
0345 ; inc minutes count
0346 0217 03B7 swapf min_sec
0347 0218 0217 movf min_sec, w ; get min_sec in w
0348 0219 0E0F andlw B'00001111' ; mask seconds
0349 021A 0743 btfss status, z ; skip is not set
0350 021B 00F7 decf min_sec ; else dec
0351 021C 03B7 swapf min_sec ; swap back
0352 ; call chk_silnc_tim ; silence on?
0353 021D 0C0A movlw mtmr ; inc mins
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 8
Line PC Opcode
0354 021E 0024 movwf fsr ;
0355 021F 0926 call inc_60
0356 0220 0D00 iorlw 0 ; do an operation
0357 0221 0743 btfss status, z ; if 0 then skip
0358 0222 0801 retlw 1 ;
0359 ;
0360 ;inc hour count
0361 ; Level ?
0362 ; Increment the hour count.
0363 0223 0C0B movlw htmr ; get htmr in fsr
0364 0224 0024 movwf fsr
0365 0225 0937 call inc_hr
0366 ;
0367 inc_60
0368 ; inc the register pointed to by the FSR modulo 60. NB B
CD is used.
0369 ; Pre: The Fsr is a timer register that is desired to be
incremented by 1
0370 ; modulo 60.
0371 ; Post: inc has occurred. If the result is 1 a inc was n
ormal. If the
0372 ; result is 0, then the tmr overflowed (=60)
0373 0226 02A0 incf f0 ; inc and get in w
0374 0227 0200 movf f0, 0
0375 0228 0E0F andlw B'00001111' ; mask high bits
0376 0229 0F0A xorlw B'00001010' ; = 10 them make it 0
0377 022A 0743 btfss status, z
0378 ; normal condition, return 1 (okay), unit digit i
ncremented
0379 022B 0801 retlw 1 ; else ret non zero
0380 022C 0CF0 movlw B'11110000' ; zero lsb
0381 022D 0160 andwf f0
0382 022E 03A0 swapf f0 ; swap indirect
0383 022F 02A0 incf f0
0384 0230 0200 movf f0,0 ; get in w
0385 0231 03A0 swapf f0 ; swap f0 back
0386 0232 0F06 xorlw D'6'
0387 0233 0743 btfss status,z
0388 ; normal condition, return 1, tens digit incremen
ted
0389 0234 0801 retlw 1
0390 ; mod 60 overflow, return 0.
0391 0235 0060 clrf f0
0392 0236 0800 retlw 0
0393 ;
0394 inc_hr
0395 ; FSR is pointing to the timer.
0396 ; i don't think that the hour timer is BCD.
0397 ; pre:
0398 ; post:
0399 0237 02A0 incf f0 ; inc hour timer
0400 0238 0200 movf f0, w
0401 ;
0402 chk_13
0403 0239 0200 movf f0, w ; get in w
0404 023A 0F12 xorlw 12h ; see if 13
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 9
Line PC Opcode
0405 023B 0743 btfss status, z ; yes then skip
0406 023C 0000 nop
0407 023D 0801 retlw 1 ; flags that a second int
erval has past
0408 ;
0409 set_1_hr
0410 023E 0C01 movlw B'00000001' ; SET TO 1
0411 023F 0020 MOVWF f0
0412
0413 ; The general purpose timers are not affected if their va
lue is zero.
0414 ;
0415 InitTmr
0416 ; Initialise timers
0417 ; Timers can run for 255 minutes or over 4 hours.
0418 ; Procedure to initialise the general purpose timers syst
em. This will be
0419 ; by constants in the first place, but later from the NV
RAM.
0420 ; Pre: Data page is 0
0421 ; Post: Data page is 0
0422 ; Initialise the backup of the timer values. (this will
eventually
0423 ; come from the NVRAM)
0424 ;
0425 ; Set all timers to zero in the first instance.
0426 ;
0427 ; set data page to 1
0428 0240 05A4 bsf FSR, dataP1
0429 0241 006E clrf timeFlag
0430 ; move in address of first timer and then increment
the addr, clearing
0431 ; each timer as we step through the timers. Curren
tly this is the
0432 ; first 8 bytes of data page 1
0433 0242 0C30 movlw stmr1
0434 ClrLoop
0435 0243 0024 movwf fsr
0436 0244 05A4 bsf FSR, dataP1 ; maintain data page
0437 0245 0060 clrf f0 ; clears seconds part
of timer
0438 0246 02A4 incf fsr, same ; inc so to clear minu
tes part
0439 0247 0060 clrf f0 ; clears mins part
0440 ; test to see all timers are clear
0441 0248 0204 movf fsr, W
0442 0249 0F37 xorlw mtmr4
0443 024A 0E0F andlw b'00001111' ; ensure high nibble i
s clear
0444 024B 0743 btfss STATUS, Z ; = --> skip
0445 024C 0A43 goto ClrLoop
0446
0447 ; install some setup values
0448 024D 0C10 movlw 10
0449 024E 0038 movwf stmr1Val
0450
0451 024F 0C01 movlw 1
0452 0250 003A movwf stmr2Val
0453 0251 003C movwf stmr3Val
0454 0252 003E movwf stmr4Val
0455 0253 003B movwf mtmr2Val
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 10
Line PC Opcode
0456 0254 0C02 movlw 2
0457 0255 003D movwf mtmr3Val
0458 0256 0C10 movlw 10
0459 0257 003F movwf mtmr4Val
0460 ; reset data page to 0
0461 0258 04A4 bcf FSR, DataP1
0462 0259 0800 retlw 0
0463
0464 SetTimer
0465 ; This procedure sets the timer to it's backup value
0466 ;
0467 ; Pre: W is the timer (the address of the seconds part o
f the tmr)
0468 ; Data Page is 0
0469 ; Post: The timer is set to the corresponding timer setu
p values
0470 ; Data page is 0
0471
0472 ; the offset to the setup values is currently 8 bytes hig
her than the
0473 ; timer variable locations
0474
0475 ; set to the timer data page
0476 025A 05A4 bsf FSR, dataP1
0477
0478 ; firstly transfer the seconds values
0479 ; calculate timer using the offset in W
0480 025B 002C movwf temp ; Save timer address
0481 025C 0C08 movlw OFFSET
0482 025D 01CC addwf temp, w ; calculate reg of the i
nitial value
0483 025E 0024 movwf FSR ; save this address in F
SR
0484 025F 05A4 bsf FSR, dataP1 ; maintain data page
0485 ; get timer (secs) value
0486 0260 0200 movf f0, W ; get setup value
0487 0261 002D movwf tmp2 ; save value, then get b
ack timer address
0488 0262 020C movf temp, W ; get timer address agai
n
0489 0263 0024 movwf fsr
0490 0264 05A4 bsf FSR, dataP1 ; maintain data page
0491 0265 020D movf tmp2, W
0492 0266 0020 movwf f0
0493
0494 ; Now transfer the minutes value
0495 0267 0C09 movlw OFFSET+1
0496 0268 01CC addwf temp, w ; calculate reg of the i
nitial value
0497 0269 0024 movwf FSR ; save this address in F
SR
0498 026A 05A4 bsf FSR, dataP1 ; maintain data page
0499
0500 ; get timer (mins) value
0501 026B 0200 movf f0, W
0502 026C 002D movwf tmp2 ; save value, then get b
ack timer address
0503 026D 02AC incf temp, same
0504 026E 020C movf temp, W
0505 026F 0024 movwf fsr
0506 0270 05A4 bsf FSR, dataP1
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 11
Line PC Opcode
0507 0271 020D movf tmp2, W
0508 0272 0020 movwf f0
0509 0273 04A4 bcf FSR, dataP1 ; reset data page pointe
r
0510 0274 0800 retlw 0 ; ???
0511
0512
0513
0514 ServTmr
0515 ; Services the timers, decrementing the active timers
0516 ; Pre: Must called from main loop, as there are calls in
this routine
0517 ; Data Page is 0
0518 ; Post: Data Page is 0
0519
0520 ; testing
0521 ; bcf port_a, 2
0522 ; set to data page 1
0523 0275 05A4 bsf FSR, dataP1
0524
0525 ; get timer address in working register
0526 0276 0C30 movlw stmr1
0527
0528 ; check to see timer active
0529 0277 060E btfsc timeFlag, timer1
0530 ; if it is decrement it
0531 0278 0990 call timerDec
0532
0533 ; if the value returned in w is 1, then the timer i
s finished
0534 ; so set it's flag
0535 0279 0F01 xorlw d'1'
0536 027A 0643 btfsc status, z ;
0537 027B 058E bsf timeFlag, tmr1end ;
0538
0539 027C 0C32 movlw stmr2
0540 027D 062E btfsc timeFlag, timer2
0541 027E 0990 call timerDec
0542 ; if the value returned in w is 1, then the timer i
s finished
0543 ; so set it's flag
0544 027F 0F01 xorlw d'1'
0545 0280 0643 btfsc status, z ;
0546 0281 05AE bsf timeFlag, tmr2end ;
0547
0548 0282 0C34 movlw stmr3
0549 0283 064E btfsc timeFlag, timer3
0550 0284 0990 call timerDec
0551 ; if the value returned in w is 1, then the timer i
s finished
0552 ; so set it's flag
0553 0285 0F01 xorlw d'1'
0554 0286 0643 btfsc status, z ;
0555 0287 05CE bsf timeFlag, tmr3end ;
0556
0557 0288 0C36 movlw stmr4
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 12
Line PC Opcode
0558 0289 066E btfsc timeFlag, timer4
0559 028A 0990 call timerDec
0560 ; if the value returned in w is 1, then the timer i
s finished
0561 ; so set it's flag
0562 028B 0F01 xorlw d'1'
0563 028C 0643 btfsc status, z ;
0564 028D 05EE bsf timeFlag, tmr4end ;
0565
0566 028E 04A4 bcf FSR, dataP1
0567 028F 0800 retlw 0
0568
0569
0570 timerDec
0571 ; Pre: W = stmr1 | stmr2 | stmr3 | stmr4 (addresses)
0572 ; the seconds are never 0, either counting down, or
0573 ; reset to 60
0574 ; post:
0575 ;
0576 ; testing
0577 ; bcf port_a, 2
0578
0579 0290 0024 movwf fsr
0580 0291 05A4 bsf FSR, dataP1 ; ensure that data pag
e remains ok
0581 0292 00E0 decf f0, same ; dec seconds, then
0582
0583 ; *******************************************************
*****************
0584 ; *******************************************************
*****************
0585 ; This is where I have found the timer not to progress.
It will light the
0586 ; LED on port A if the Xorlw is for 3 or 4 as it counts d
own, but it never
0587 ; gets to the stage where comparsion (via XOR) with 1 or
2, lights the LED.
0588 ; I take this to mean that, it never gets to the value of
1 or 2.
0589
0590 ; movf f0, w
0591 ; xorlw 4
0592 ; btfsc status, z
0593 ; bcf Port_A, 1
0594 ; xorlw 3
0595 ; btfsc status, z
0596 ; bcf Port_A, 0
0597 ; xorlw 2
0598 ; btfsc status, z
0599 ; bcf Port_A, 2
0600
0601 0293 0743 btfss status, z ; if zero dec minutes
0602 0294 0800 retlw 0
0603
0604 ZeroSecs
0605 ; The seconds have zeroed, so if no mins left end, else d
ec mins
0606 ; and set seconds to 60
0607 ; Pre: FSR is the ADDR of the seconds part of the timer
0608 ; Data page is 1
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 13
Line PC Opcode
0609 ; Post: Data page is 1
0610 ; retlw 1 if the timer is finished
0611
0612 ; testing
0613 0295 0405 bcf Port_a, 0
0614 0296 02A4 incf FSR, same ; so to move to mins
part
0615 0297 0200 movf f0, w
0616 0298 0EFF andlw B'11111111' ; test for zero
0617 0299 0743 btfss status, z ; skip if 0
0618 029A 0A9E goto decNow ; else dec the minut
es now
0619
0620 ; testing
0621 029B 0445 bcf Port_A, 2
0622 029C 04A4 bcf FSR, dataP1
0623 029D 0801 retlw 1 ; return from timerD
ec, noting
0624 ; that the tmr is fi
nished
0625
0626 decNow
0627 ; Pre: accessed by a goto from ZeroSecs
0628 ; Post:
0629 029E 00E0 decf f0, same ; dec minutes
0630 029F 00E4 decf FSR, same ; access seconds add
ress
0631 02A0 0C60 movlw 60
0632 02A1 0020 movwf f0 ; set seconds
0633
0634 ;testing
0635 02A2 0425 bcf Port_a, 1
0636 02A3 04A4 bcf FSR, dataP1 ;
0637 02A4 0800 retlw 0 ; return from timerD
ec
0638
0639
0640
0641 TmrAct
0642 ; Take initial action if a timer is finished.
0643 ; Pre: The finshed flag for the timer is set
0644 ; Post: The finshed flag is cleared
0645 ; testing
0646 ; bcf port_a, 2
0647
0648 02A5 068E init1 btfsc timeFlag, tmr1end
0649 02A6 0AAE goto TmrAct1
0650 02A7 06AE init2 btfsc timeFlag, tmr2end
0651 02A8 0AB5 goto TmrAct2
0652 02A9 06CE init3 btfsc timeFlag, tmr3end
0653 02AA 0ABD goto TmrAct3
0654 02AB 06EE init4 btfsc timeFlag, tmr4end
0655 02AC 0AC5 goto TmrAct4
0656 02AD 0800 retlw 0 ; return from T
mrAct routine
0657 ;
0658 02AE 048E TmrAct1 bcf timeFlag, tmr1end ; clear the end
ed flag
0659 02AF 040E bcf timeFlag, timer1 ; stop timer de
crementing
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 14
Line PC Opcode
0660 ; testing
0661 ; bcf Port_A, 2
0662 02B0 0C32 movlw stmr2
0663 02B1 095A call setTimer
0664 02B2 052E bsf timeFlag, timer2 ; activate time
r2
0665 02B3 0405 bcf port_A, 0
0666 02B4 0AA7 goto init2
0667 02B5 04AE TmrAct2 bcf timeFlag, tmr2end ; clear the end
ed flag
0668 02B6 042E bcf timeFlag, timer2 ; stop timer de
crementing
0669 02B7 0C34 movlw stmr3
0670 02B8 095A call setTimer
0671 02B9 054E bsf timeFlag, timer3 ; activate time
r3
0672 02BA 0505 bsf Port_A, 0 ; turn off prev
ious led
0673 02BB 0425 bcf Port_A, 1 ; turn on led
0674 02BC 0AA9 goto init3
0675 02BD 04CE TmrAct3 bcf timeFlag, tmr3end ; clear the end
ed flag
0676 02BE 044E bcf timeFlag, timer3 ; stop timer de
crementing
0677 02BF 0C36 movlw stmr4
0678 02C0 095A call setTimer
0679 02C1 056E bsf timeFlag, timer4 ; activate time
r4
0680 02C2 0525 bsf Port_A, 1 ; turn off prev
ious led
0681 02C3 0445 bcf Port_A, 2 ; turn on led
0682 02C4 0AAB goto init4
0683 02C5 04EE TmrAct4 bcf timeFlag, tmr4end ; clear the end
ed flag
0684 02C6 046E bcf timeFlag, timer4 ; stop timer de
crementing
0685 02C7 0545 bsf Port_A, 2 ; turn off prev
ious led
0686 02C8 0465 bcf Port_A, 3
0687 02C9 05A3 bsf status, PA0
0688 02CA 05C3 bsf status, PA1
0689 02CB 0BFF goto sys_reset
Warning: [Warning 5] : line 689 : Address change across page boundary, ensure page bits are set
0690 02CC 0800 retlw 0 ; return from T
mrAct routine
0691
0692 ;
0693 ;
0694 ; *******************************************************
*******************
0695 0000 org PIC57
0696 sys_reset
0697 07FF 0A00 goto start
Warning: [Warning 6] : line 697 : Address change across page boundary, ensure page bits are set
0698 ;
0699 0000 end
16c5x/xx Cross-Assembler V4.14 Released Sun Jul 31 15:05:04 1994 Page 15
------------------------------------------------------------------------
and the asm file
; TST2.asm May 1, 1994
; modified to test PIC out and do demos. extra comments added
; Insert BCD timers and test
; Original code from the Applications notes from Microchip.
;
; Gary Gaskell mods for count down timers.
;
LIST P= 16C57
;
; Coding policy:
; A routine is a section of code. This defintion may be refined to two types
; of routines. The first is a PROCEDURE. Procedures may be called
; using the stack of the PIC. The second is a "CODE SEQUENCE". This
; type of routine may not be called, only jumped/branched to. The
; intention is to limit the likelihood to too many calls resulting in
; an overflow on the stack.
; Level 0 This code is Base code (stack is empty)
; Level 1 Called from base code, may call another routine. (stack=1)
; Displine and quality code requires that a return is
; executed.
; Level 2 Called from base or Level 1 code. The stack is now full
; so no calls are allowed. branching only, but a return
; is essential to unwind the stack.
; CONSTANTS will be in UPPERCASE, with variables in lowercase.
;
;
; define equates:
;
PIC57 equ 7FFH
;
; external osc used = 4.096mHz. prescaler of 32 used, which gives a
; 31.25 microsec inc of the RTCC. If the rtcc is initially loaded with 96
; it would overflow to 0 in 5.00ms. giving 0.00% error
; If the crystal is 4.000 Mhz (prototype Xtal), NB 4Mhz xtal gives 1 Mhz
; internal clock. then overflow at 32usec,
; requiring 156.25 rtcc cycles, ie msecs should be 100, but an error needs
; to be corrected. , Easier option is to decrease interval to 4 ms and to
; alter the constant for the seconds to 250 (249 actually). NB gives
; 4000 instructions before the RTCC overflow must be caught.
;
; MTICKS EQU d'96' ; for 4.096 Mhz xtal
; MTICKS EQU d'100' ; for 4.000Mhz xtal
; MTICKS equ d'131' ; for 4.000MHz xtal and 4msec overflow
MTICKS equ d'1' ; for testing
; Number of rttc timeouts to equal one second.
; NumRollover equ d'199'
; NumRollOver equ d'249'
NumRollover equ d'1' ; for testing
;
; needs fixing to right value
key_hit equ 0
same equ 1 ; register operation source=dest
C EQU 0
BEP EQU 0
RTATS EQU 0
DC EQU 1
HR10 EQU 1
Z EQU 2
HR EQU 2
MIN EQU 4
FLASH EQU 4
PA0 EQU 5
PA1 EQU 6
F0 EQU 0
LEDon EQU 5 ; is set if the LED is on. bit 5 of alflag
led equ 3 ; bit of portA for the led.
dataP1 equ 5 ; bit 5 of FSR (sets from DP0 to dataPg 1)
;
; Constants for timers etc
; these are set if the timer is active
timer1 equ 0 ; bit numbers for flag "timeFlag"
timer2 equ 1
timer3 equ 2
timer4 equ 3
; these are set if the timer has finished and awaits action
tmr1end equ 4
tmr2end equ 5
tmr3end equ 6
tmr4end equ 7
; This is the number of bytes that separate the timer, from
; a copy of its setup values
OFFSET equ 8
MIN_SEC EQU 17 ; MIN/seconds timer
;
; PORT pin definitions
;
; Port A: s
; bit0 led to flash
; bit 1-3 unsed i/o
;
; define the RAM locations of DATA PAGE 1 (timers)
; NB to use these RAM locations (variables) the correct bits of the
; FSR must be set (5&6).
; setup 5 timers. Each will store BCD time values and be decremented to-
; wards zero. NB if these timers are moved the code that works on that
; must be updated.
;
; Timers placed in Data Page 1
stmr1 equ 30
mtmr1 equ 31
stmr2 equ 32
mtmr2 equ 33
stmr3 equ 34
mtmr3 equ 35
stmr4 equ 36
mtmr4 equ 37
stmr1Val equ 38
mtmr1Val equ 39
stmr2Val equ 3A
mtmr2Val equ 3B
stmr3Val equ 3C
mtmr3Val equ 3D
stmr4Val equ 3E
mtmr4Val equ 3F
;
;
;
; ****************************************************************************
org 0
START
goto initialise
; this routine runs a test on the leds
; all the relevent leds are lit up for 2 secs.
;
test_hardware
movlw D'1' ; flash every two for 2 secs
movwf min_sec
;
;
norm_time
bcf genFlag, 0 ; put in real time
bcf genFlag, 1
;
time_loop
; call update_display
; bsf status, PA1 ; goto page 2
; call service_keys
bsf status, PA0 ; goto page 1
call update_timers ; wait and update timers (Realtime)
bcf status, PA0
iorlw 0 ;
btfss status, Z ;
goto GPtime ;
; movf genFlag, w ; see if in atm
; andlw B'00000011'
; xorlw B'00000001'
; btfsc status, z ; skip if not
retrn
goto time_loop
GPtime
; code sequence to call general purpose timers
; Pre: only called after a second interval has past
bsf status, PA0 ; goto page 1
call servTmr ; service the gen purpose timers
call TmrAct
bcf status, PA0 ; reset page flags
call ChangeState
goto retrn
on
; Level 2 routine.
; set led on, by setting it low, set in flag and at port.
; Pre:
; Post:
bsf genflag, LEDON
bcf port_a, led
retlw 0
;
ChangeState
; Level 2 routine
; routine to change the state of the led. this is only entered if the
; min_sec timer has reached zero.
;
; Pre:
; POst:
;
; reset value for blinks the led ever 2 secs
movlw D'01' ; 2 secs
movwf min_sec
; check the led status on/off?
movf genflag, w
andlw B'00100000'
btfsc status, z ; if ledon is on
goto on ; turn it on
bsf port_a, led ; turn it off
bcf genflag, ledon
retlw 0
;************************************************************************;
; This routine set up ports A, B, C and the internal
; real time clock counter.
; Level 1 routine
; Pre:
; Post: Timers have been setup.
; Ports have been setup
; The prescaler is set
;
initialise
clrf FSR
movlw B'00001111' ; make active high
movwf port_a
movlw B'00000000' ; set port A as outputs
tris port_a
;
movlw B'11111111' ; set levels high
movwf port_b
movlw B'00000000' ; set portB as output
tris port_b
;
movlw B'00000000' ; set levels low
movwf port_c
movlw B'00000000' ; set port C as output
tris port_c
;
; OPTION REG setup
; bits 7,6,5,4,3,2,1,0
; 6,7 not avail
; 5 rt source o = int, 1, edge on rtcc pin
; 4 rtcc edge l->H '0', H-->L '1'
; 3 prescaler assignment 0 rtcc, 1 wdt
; 1,2,3 ratio of prescaler '100' = 1:32
; 000 -> scale 1:2
; 111 -> scale 1:256
; NB if scale used for wdt, then ratio is 1/2 of the rtcc scale
; movlw B'00000100' ; set up prescaler (1:32)
movlw B'00000000' ; for testing
option
;
movlw MTICKS ; rtcc = 5msecs
; init the rtcc with a value MTICKS, so that when it times out it is
; almost exactly 5msecs.
movwf rtcc
clrf mstmr
clrf stmr
clrf mtmr
movlw 12H ; make hours = 12
movwf htmr
clrf genFlag
bsf status, PA0
call initTmr
movlw stmr1 ; set W = timer1
; call setTimer
; testing
movlw 5
bsf fsr, DataP1
movwf stmr1
bcf fsr, DataP1
bsf timeFlag, timer1 ; activate timer
bcf status, PA0
goto test_hardware
;
;
; *************************************************************************
;
; TIMER MODULE
;
; *************************************************************************
; All routines related to timer update are located at address
; 200 and above.
;
org 200
;
; This routine is called on every loop.
update_timers
;
; Pre:
; Post: returns 1 in W if a 1 second interval has past
clrwdt
timerLoop
; the timer loop is currently set to time out every 5ms. NB it must be
; less than 18 ms or the watchdog may time out.
nop ; allow time for rtcc = 0 to be available
movf rtcc, w ; is rtcc =0
btfss status, z ; if 0 then skip
goto timerLoop ; else loop
; setup real time counter again to count out the next 5ms
movlw MTICKS ; rtcc = 5ms or 4ms
movwf rtcc
incf mstmr ; inc 5 ms
; btfsc genFlag, key_hit ; no key hit, then skip
; goto chk_de_bounce ; else debounce
;
; check to see if a second has rolled around. IE 200 x 5ms = 1 sec
; or 250 x 4ms = 1sec
movf mstmr, 0 ; get mstmr in W
xorlw NumRollOver ; if enough to equal 1 sec then skip
btfss status, z
retlw 0 ; return as not a second interval
;
; inc seconds count
clrf MSTMR ; CLEAR ms-TMR
movf min_sec, w ; get min_sec timer
andlw B'00001111' ; mask minutes
btfss status, z ; zero then skip
decf min_sec
movlw stmr ; load fsr with s_tmr
movwf fsr
call inc_60 ; inc secs
iorlw 0 ;
btfss status, z ;
retlw 1 ; only a sec passed
;
; inc minutes count
swapf min_sec
movf min_sec, w ; get min_sec in w
andlw B'00001111' ; mask seconds
btfss status, z ; skip is not set
decf min_sec ; else dec
swapf min_sec ; swap back
; call chk_silnc_tim ; silence on?
movlw mtmr ; inc mins
movwf fsr ;
call inc_60
iorlw 0 ; do an operation
btfss status, z ; if 0 then skip
retlw 1 ;
;
;inc hour count
; Level ?
; Increment the hour count.
movlw htmr ; get htmr in fsr
movwf fsr
call inc_hr
;
inc_60
; inc the register pointed to by the FSR modulo 60. NB BCD is used.
; Pre: The Fsr is a timer register that is desired to be incremented by 1
; modulo 60.
; Post: inc has occurred. If the result is 1 a inc was normal. If the
; result is 0, then the tmr overflowed (=60)
incf f0 ; inc and get in w
movf f0, 0
andlw B'00001111' ; mask high bits
xorlw B'00001010' ; = 10 them make it 0
btfss status, z
; normal condition, return 1 (okay), unit digit incremented
retlw 1 ; else ret non zero
movlw B'11110000' ; zero lsb
andwf f0
swapf f0 ; swap indirect
incf f0
movf f0,0 ; get in w
swapf f0 ; swap f0 back
xorlw D'6'
btfss status,z
; normal condition, return 1, tens digit incremented
retlw 1
; mod 60 overflow, return 0.
clrf f0
retlw 0
;
inc_hr
; FSR is pointing to the timer.
; i don't think that the hour timer is BCD.
; pre:
; post:
incf f0 ; inc hour timer
movf f0, w
;
chk_13
movf f0, w ; get in w
xorlw 12h ; see if 13
btfss status, z ; yes then skip
nop
retlw 1 ; flags that a second interval has past
;
set_1_hr
movlw B'00000001' ; SET TO 1
MOVWF f0
; The general purpose timers are not affected if their value is zero.
;
InitTmr
; Initialise timers
; Timers can run for 255 minutes or over 4 hours.
; Procedure to initialise the general purpose timers system. This will be
; by constants in the first place, but later from the NV RAM.
; Pre: Data page is 0
; Post: Data page is 0
; Initialise the backup of the timer values. (this will eventually
; come from the NVRAM)
;
; Set all timers to zero in the first instance.
;
; set data page to 1
bsf FSR, dataP1
clrf timeFlag
; move in address of first timer and then increment the addr, clearing
; each timer as we step through the timers. Currently this is the
; first 8 bytes of data page 1
movlw stmr1
ClrLoop
movwf fsr
bsf FSR, dataP1 ; maintain data page
clrf f0 ; clears seconds part of timer
incf fsr, same ; inc so to clear minutes part
clrf f0 ; clears mins part
; test to see all timers are clear
movf fsr, W
xorlw mtmr4
andlw b'00001111' ; ensure high nibble is clear
btfss STATUS, Z ; = --> skip
goto ClrLoop
; install some setup values
movlw 10
movwf stmr1Val
SetTimer
; This procedure sets the timer to it's backup value
;
; Pre: W is the timer (the address of the seconds part of the tmr)
; Data Page is 0
; Post: The timer is set to the corresponding timer setup values
; Data page is 0
; the offset to the setup values is currently 8 bytes higher than the
; timer variable locations
; set to the timer data page
bsf FSR, dataP1
; firstly transfer the seconds values
; calculate timer using the offset in W
movwf temp ; Save timer address
movlw OFFSET
addwf temp, w ; calculate reg of the initial value
movwf FSR ; save this address in FSR
bsf FSR, dataP1 ; maintain data page
; get timer (secs) value
movf f0, W ; get setup value
movwf tmp2 ; save value, then get back timer address
movf temp, W ; get timer address again
movwf fsr
bsf FSR, dataP1 ; maintain data page
movf tmp2, W
movwf f0
; Now transfer the minutes value
movlw OFFSET+1
addwf temp, w ; calculate reg of the initial value
movwf FSR ; save this address in FSR
bsf FSR, dataP1 ; maintain data page
; get timer (mins) value
movf f0, W
movwf tmp2 ; save value, then get back timer address
incf temp, same
movf temp, W
movwf fsr
bsf FSR, dataP1
movf tmp2, W
movwf f0
bcf FSR, dataP1 ; reset data page pointer
retlw 0 ; ???
ServTmr
; Services the timers, decrementing the active timers
; Pre: Must called from main loop, as there are calls in this routine
; Data Page is 0
; Post: Data Page is 0
; testing
; bcf port_a, 2
; set to data page 1
bsf FSR, dataP1
; get timer address in working register
movlw stmr1
; check to see timer active
btfsc timeFlag, timer1
; if it is decrement it
call timerDec
; if the value returned in w is 1, then the timer is finished
; so set it's flag
xorlw d'1'
btfsc status, z ;
bsf timeFlag, tmr1end ;
movlw stmr2
btfsc timeFlag, timer2
call timerDec
; if the value returned in w is 1, then the timer is finished
; so set it's flag
xorlw d'1'
btfsc status, z ;
bsf timeFlag, tmr2end ;
movlw stmr3
btfsc timeFlag, timer3
call timerDec
; if the value returned in w is 1, then the timer is finished
; so set it's flag
xorlw d'1'
btfsc status, z ;
bsf timeFlag, tmr3end ;
movlw stmr4
btfsc timeFlag, timer4
call timerDec
; if the value returned in w is 1, then the timer is finished
; so set it's flag
xorlw d'1'
btfsc status, z ;
bsf timeFlag, tmr4end ;
bcf FSR, dataP1
retlw 0
timerDec
; Pre: W = stmr1 | stmr2 | stmr3 | stmr4 (addresses)
; the seconds are never 0, either counting down, or
; reset to 60
; post:
;
; testing
; bcf port_a, 2
movwf fsr
bsf FSR, dataP1 ; ensure that data page remains ok
decf f0, same ; dec seconds, then
; ************************************************************************
; ************************************************************************
; This is where I have found the timer not to progress. It will light the
; LED on port A if the Xorlw is for 3 or 4 as it counts down, but it never
; gets to the stage where comparsion (via XOR) with 1 or 2, lights the LED.
; I take this to mean that, it never gets to the value of 1 or 2.
; movf f0, w
; xorlw 4
; btfsc status, z
; bcf Port_A, 1
; xorlw 3
; btfsc status, z
; bcf Port_A, 0
; xorlw 2
; btfsc status, z
; bcf Port_A, 2
btfss status, z ; if zero dec minutes
retlw 0
ZeroSecs
; The seconds have zeroed, so if no mins left end, else dec mins
; and set seconds to 60
; Pre: FSR is the ADDR of the seconds part of the timer
; Data page is 1
; Post: Data page is 1
; retlw 1 if the timer is finished
; testing
bcf Port_a, 0
incf FSR, same ; so to move to mins part
movf f0, w
andlw B'11111111' ; test for zero
btfss status, z ; skip if 0
goto decNow ; else dec the minutes now
; testing
bcf Port_A, 2
bcf FSR, dataP1
retlw 1 ; return from timerDec, noting
; that the tmr is finished
decNow
; Pre: accessed by a goto from ZeroSecs
; Post:
decf f0, same ; dec minutes
decf FSR, same ; access seconds address
movlw 60
movwf f0 ; set seconds
TmrAct
; Take initial action if a timer is finished.
; Pre: The finshed flag for the timer is set
; Post: The finshed flag is cleared
; testing
; bcf port_a, 2
init1 btfsc timeFlag, tmr1end
goto TmrAct1
init2 btfsc timeFlag, tmr2end
goto TmrAct2
init3 btfsc timeFlag, tmr3end
goto TmrAct3
init4 btfsc timeFlag, tmr4end
goto TmrAct4
retlw 0 ; return from TmrAct routine
;
TmrAct1 bcf timeFlag, tmr1end ; clear the ended flag
bcf timeFlag, timer1 ; stop timer decrementing
; testing
; bcf Port_A, 2
movlw stmr2
call setTimer
bsf timeFlag, timer2 ; activate timer2
bcf port_A, 0
goto init2
TmrAct2 bcf timeFlag, tmr2end ; clear the ended flag
bcf timeFlag, timer2 ; stop timer decrementing
movlw stmr3
call setTimer
bsf timeFlag, timer3 ; activate timer3
bsf Port_A, 0 ; turn off previous led
bcf Port_A, 1 ; turn on led
goto init3
TmrAct3 bcf timeFlag, tmr3end ; clear the ended flag
bcf timeFlag, timer3 ; stop timer decrementing
movlw stmr4
call setTimer
bsf timeFlag, timer4 ; activate timer4
bsf Port_A, 1 ; turn off previous led
bcf Port_A, 2 ; turn on led
goto init4
TmrAct4 bcf timeFlag, tmr4end ; clear the ended flag
bcf timeFlag, timer4 ; stop timer decrementing
bsf Port_A, 2 ; turn off previous led
bcf Port_A, 3
bsf status, PA0
bsf status, PA1
goto sys_reset
retlw 0 ; return from TmrAct routine
I didn't read all of your code & have not used the 57 ( I am using the '71)
but I did check the '57 op-codes. A movf RTCC to W will set the Z flag but
will also clear the prescaler. Could this tie in with your troubles, or have
you allowed for it?
There may be more to it that this, but a quick look shows that you are
moving RTCC into W and then expecting the Z bit in the status register
to indicate the zero or nonzero status of the RTCC. I don't think the
movf instruction affects the Z bit, so try adding a specific test.
> There may be more to it that this, but a quick look shows that you are
> moving RTCC into W and then expecting the Z bit in the status register
> to indicate the zero or nonzero status of the RTCC. I don't think the
> movf instruction affects the Z bit, so try adding a specific test.
>
> David
The Microchip data pages say that movf does set the Z bit. Besides the
seconds timing seems to working fine. A LED i have blinking is regular
and never fails.
> I didn't read all of your code & have not used the 57 ( I am using the '71)
> but I did check the '57 op-codes. A movf RTCC to W will set the Z flag but
> will also clear the prescaler. Could this tie in with your troubles, or have
> you allowed for it?
>
> Good luck,
> Brian
Brian, I thought you may have hit the problem, but it does not appear
so. Firstly if the movf RTCC, w did change the prescaler, then the
whole time would be out (and my LED blinking each second would not be
operational). I did try resetting the prescaler after each operation
with the RTCC, but this gave not change.
The Microchip data page is confusing. It talks in note 4 of the
instruction table, about the prescaler being reset, but is ambiguous. (to
me atleast)
I have RA4 on a 4.7K pullup. When I drive the pin high I only get a voltage
of 2 volts maybe 2.1. 4.7K!!! Anyway It hangs around .68mV when I am
not driving it low. I really need help with this. I fall below ttl
level from time to time and its killing me. It works fine if I put a
680Ohm pullup on it but then my lower voltage is horrendus(sp). I know
about the screwed up tristate reg on it and I only move an image of RA
into the ra reg(not the tristate I leave it alone).
Help please....
later
John
_____________________________________________________________________________
John Johnson |If it's not OS/2.|@spam@johnsonj@spam@spam_OUTccwf.cc.utexas.edu
|It's crap! |spamBeGonejohnsonjKILLspamghostwheel.bga.com
OOOO SSSS /2222 2222 11 | |
O O S / 2 2 1 |"We need breath- |"Bite me." Tom Servo
O O SSSS / 2222 2222 1 |-ing room!" |
O O S / 2 2 .. 1 | Bill Gates |"I want to decide who lives
OOOO SSSS/ 2222 2222 .. 111| |and who dies" Crow T. Robot
-----------------------------------------------------------------------------
You might have noticed that the application note describing software
stack management (to allow for more than 2 active calls) isn't usable
on PICs with more than 512 bytes of program memory.
Has anyone already extended the example it so that is usable on
"bigger" PICs too (I'm using the '57 myself, for now) and would like
to share it with us?
After reading a message concerning someone having a firmware release of 1.7,
I wanted to know if anyone has a newer version of the firmware or can tell
me if there are any advantages over version 1.5 (which I have).
>I have found that every once in a while our PICSTART refuses to program
>properly, but I put it down to the ZIF socket - devices placed centrally
>do not program properly but ones placed at the left side program OK.
Hmmm...
I've used the PICStart 16B since version 1.4 (keep getting upgrades, like
candy), and it's always been flakey. I have one at work and another at
home. Both the same.
I've never even tried shifting the part in the ZIF socket. Sometimes it
programs first time, usually it takes three attempts. Without shifting the
chip at all. I chalk it up to flakey timing and bad exception handling.
Which is also pure conjecture... My $0.02
I'm interested in that "Unix" code the other guy has.
there was some (good) response about my new "Multi process Kernel". So "I" will
post it now to our ftp server ftp.ntb.ch. Actually my sysop will do that
hopefully within some days. (/public/MicroChip/Pic/...)
To avoid too much questions later I've described details more precise
in the source. That4s why it lasted so long... Thanks for your patient.
There will also be 2 samples showing the usage of MpK and a simple shell
that I use. (Comes up with shareware boxer, telemate and 4DOS).
One sample (FSS) has got an ORCAD pcb design included ...
Read the *.idx files for an overview.
BTW: MpK sounds a little bit too proud! So don't blame me afterwards...
PS: Somewhere out in the net is an 2 week old message called "MpK coming soon".
It is supposed to wait there in an endless loop !!?? So just delete it
if it finaly appears somehow...
I did not find these directories or any information on MpK at ftp.ntb.ch.
Or any PIC info at all???? I'm very interested in MpK, so let me know if its
at another site. Thanks a million Steve
----------{Original Message removed}
>
> I did not find these directories or any information on MpK at ftp.ntb.ch.
> Or any PIC info at all???? I'm very interested in MpK, so let me know if its
> at another site. Thanks a million Steve
Hi Steve,
With a little search I found that the original directory is :
Something I came across today - mpstart will read fuses and ID
locations from withon a .obj file, so there's no need to keep
setting the fuses each time you load it up. The only problem is
that to get mpalc to place data at $2000-2007 you need to use
org beyond its defined limits so you get a fatal error for each
word of data when assembling.
Perhaps ASPIC copes with this OK?
I've also descovered a problem when using 16C84s that once in a while
they lock up and only a powerdown will start them off again. The reset
pin doesn't do anything. It occurs primarily if I use my in-circuit programmer
after the chip has already been running. After the programming cycle is
complete, the device is presented with a reset pulse but just sits there.
If the device is programmed straight after power-up, the reset pulse
after programming starts it and it runs the program.
Any ideas? All I can think of is that it's latchup on the MCLR pin
but I've tried driving it through a resistor, and non of the voltages
are outside the supply rails (except the 12V for programming).
Any ideas?
Thanks,
Simon
--
******************************************************************************
* Simon Harrison, University of Newcastle U. Tyne * *
* RemoveMES.J.HarrisonspamBeGoneuk.ac.newcastle * Oook *
* Fax: 091-222-8180, Attn: S.Harrison * - Librarian *
* Telex (Preferred): 53654 UNINEW G, mark 1st line: * *
* "TO: S.J.HARRISON (DEPT. OF ELEC. ENG.)" * *
******************************************************************************
> Something I came across today - mpstart will read fuses and ID
> locations from withon a .obj file, so there's no need to keep
> setting the fuses each time you load it up. The only problem is
> that to get mpalc to place data at $2000-2007 you need to use
> org beyond its defined limits so you get a fatal error for each
> word of data when assembling.
> Perhaps ASPIC copes with this OK?
Of course ASPIC supports this. The file DEMO.ZIP available on my BBS
(604-597-3479), Microchip's BBS and a few ftp sites shows how. Here is an
excerpt:
...
(From PLD.ASM (the initial file))
;**********************************************************************
;*
;* Define PIC options and ID
;*
;**********************************************************************
.if !clop_d ;simulator won't tolerate fuses!
SEG FUSES ;Config fuse area
.word _XTOSC|_CP|_PWRTE ;Mode: xt osc, no code protext, timer
enabled
.if isdef( IDLOC ) ;if there is an ID area (ie. not 17C42)
SEG ID
.word _year&$0f,_month,_day,_hour ;set id number to compile
time
.endif
.endif
----------------------------
Note that the above code also generates a default id code as the compile
time
in BCD.
Sorry. Didn't mean to cast doubts about your program.... It's just I don't
use a PC for most of my work so don't really know anything about ASPIC.
I don't suppose you'd do an Atari version...
Simon
--
******************************************************************************
* Simon Harrison, University of Newcastle U. Tyne * *
* spamBeGoneS.J.Harrison@spam@spam_OUTuk.ac.newcastle * Oook *
* Fax: 091-222-8180, Attn: S.Harrison * - Librarian *
* Telex (Preferred): 53654 UNINEW G, mark 1st line: * *
* "TO: S.J.HARRISON (DEPT. OF ELEC. ENG.)" * *
******************************************************************************
Anybody here got one of these? Have you used other ICEs that compete
with it? It seems like a pretty good price ($699) if it works as
advertised, and I've used the front end software when it was just
a simulator. At least, it *looks* the same.....
You can get topic-0.1.zip from ftp.funet.fi in the directory
/pub/microprocs/pic/topic. (If your filing system doesn't support
multiple dots in the filename, enter a command like "get topic-0.1.zip
topic01.zip" to store it with a different local filename).
Below I've included the short README file.
Enjoy!
-- vinsci
README:
This README file describes Topic release 0.1, an assembler for the PIC
microcontroller series. The PIC is manufactured by Microchip Technlogy
Inc.
This assembler is published under the GNU General Public License in
the hope that others will use and benefit from this program as well as
contribute their own improvements and extensions for all of us to
share.
What it doesn't do (yet):
While I believe Topic does things the right way, it currently lacks
features that will hopefully be available in later versions. Such as
pseudo instructions (easily added), macros (the code to insert macros
already exist and works), optional ",0" or ",1" as a second argument
(easiliy added), real expressions and operators (this is the biggest
drawback in this first release), conditional assembly (we need to see
if GASP, the Gnu ASsembler Preprocessor, suits our needs) etc.
What it does:
It does support symbols (any length symbol name), file inclusion, good
warning and error message capability (some of the messages in this
release are on the lighter side -- see the source in case you don't
understand a message). It also supports a variety of ways to write
constants. It writes a simple symbol table, reporting which symbols
were really used and which were not. It writes an object file in the
same format as Microchip's MPALC assembler if the assembly was
successful, or none if not. Topic doesn't crash your machine when it
doesn't see what it expected (unlike MPALC).
This software is pretty much experimental so far (it's less than a
week old, what do you expect?), but it is cleanly written. There are
even a few comments.
Currently, it only supports the 12 bit variants of the PIC, but I've
designed the assembler so that it is very easy to extend it to the 14
bit core as well and make the choice while the assembler is running
(ie. using an assembler directive). Some constants in the source now
make the assembler believe the memory size is 2048 instruction words
as for the PIC 16C57, which I work with, hmmm ;-), but all this is
very easily changed.
OK, how do I improve it and recompile it?
First get a standard C compiler. I used the GNU C compiler GCC which
is available for free on the net and is a very good compiler and has
everything you need.
For MSDOS systems, get the variant of GCC called DJGPP:
If you have a make utility, just CD into the Topic subdirectory and
type MAKE. To compile by hand, give the command "gcc -o topic
topic.c". Easy! (If you're using DJGPP, you can now run the file
topic, which is still in unix format, with the command "go32 topic
source.asm" to assemble source.asm and produce source.obj. You can
also create a normal executable with DJGPP, after that the command
would be "topic source.asm", as on a unix system.)
Spots that could use some improvement are marked by the word fixme.
Are you improving the assembler?
Any improvements and/or bug fixes that are clean and well thought out
are welcome by e-mail at the address below. Please use the DIFF
command "diff -c2 topic.c newtopic.c >diffs" to produce the diffs
file, and e-mail me that along with a description of the diff in
question. Make separate diffs for changes/improvements that aren't
related and send them in separate e-mails. All changes should follow
the GNU coding standards to reasonable extent to maintain readability.
Enjoy! E-Mail: vinsciEraseMEnic.funet.fi
Mail: Leonard Norrgard
Skolhusgatan 32 A 14
FIN-65100 VASA
Phone: +358-49-434808
>
> You can get topic-0.1.zip from ftp.funet.fi in the directory
> /pub/microprocs/pic/topic. (If your filing system doesn't support
> multiple dots in the filename, enter a command like "get topic-0.1.zip
> topic01.zip" to store it with a different local filename).
>
> Below I've included the short README file.
>
> Enjoy!
>
> -- vinsci
>
Good! I'm glad to see someone starting this! I'm presently using the gnu
c compiler, and I'm pleased to see some software development for the pic's
following the same route.
What about a simulator? It sure would be nice to have some control over
what a simulator can do.
I have also just finished an assembler for pics, just the
documentation and a bit more testing left to do before its released.
Compared to topic is has:
pros: macros, real expressions, conditional assembly, local variables
and labels, 12 and 14bit pics, a simple disassembler.
cons: own object file format (with conversion tools to and from
intel hex.) C format numbers (i.e. 0xff etc), and error handling
is "simplistic" and finally no clever name (topic, aspic) thought
up yet ;-)
I will try to get the docs done this weekend and put it up for ftp
next week. It has been built under linux and gcc, but should work under
any unix or even dos (using djgpp).
=%-)
Ian
p.s. votes for next tool being taken, simulator or picstart code downloader.
p.p.s. does anyone know the format of the picstart download protocol or
e-mail address for someone at microchip who might know.
> Damn, beaten by a couple of days... ;-)
> I have also just finished an assembler for pics, just the
> documentation and a bit more testing left to do before its released.
Heh ;-) I skipped the docs part altogether, which probably saved a
couple of days...
> Compared to topic is has:
>
> pros: macros, real expressions, conditional assembly, local variables
> and labels, 12 and 14bit pics, a simple disassembler.
Sounds great!
> cons: own object file format (with conversion tools to and from
> intel hex.)
This is not necessarily a con; running those conversion tools
is anyway easiliy automated as needed.
> C format numbers (i.e. 0xff etc), and error handling
> is "simplistic" and finally no clever name (topic, aspic) thought
> up yet ;-)
Well, it seems a bit hotter than Topic, so maybe Tropic would be nice? ;-)
> Ian
>
> p.s. votes for next tool being taken, simulator or picstart code downloader.
> p.p.s. does anyone know the format of the picstart download protocol or
> e-mail address for someone at microchip who might know.
A picstart code downloader should be pretty easy and very desirable to
get out of the MSDOG/Windows dependance (I just hate to have to boot
my PC ten times a day whenever the system crashes; not that booting
takes such a long time but it interrupts my flow of thoughts).
For the simulator which I'm sure we'll build sooner or later, I've
been thinking of using the combination of C and Tcl/Tk (see
comp.lang.tcl). Tcl is a rather nice library that would give the
simulator great scripting capabilities, while Tk is a GUI toolkit for
Tcl with the look and feel of Motif. Tcl/Tk interfaces very well with
C allowing the simulator to be written partly in Tcl (faster to
edit/test/fix) and partly in C (faster final code); thus one can start
most of it off in Tcl and then code the timecritical parts in C
routines as needed. Tk provides some nice features that are ideal for
a CPU simulator, or any program that needs to update screen data as
variables change.
Tcl/Tk come with an X11 or BSD type public license and are available
under both Unix/X11 (Linux, for example) and MSDOS/Windows (for those
unfortunate of you ;-), so the simulator could be used by a large
number of people.
>
> Hi everyone.
>
> I'm just starting to learn about the PICs, and I'm looking for
> recommendations for a programmer (for a PC). I've seen a couple listed in
> the FAQ, but I'd like a few opinions before I commit any of my hard-earned
> cash to one of them.
> Here's what I'd like to know...
>
> 1. Prices. I'm looking for something affordable. I've seen a couple of
> them
> advertized for under $200 U.S. That would be about right for me.
> 2. Ease of use. Remember, I'm a beginner.
> 3. Which microcontrollers will it program?
I use the Parallax programmer, which is under $200, is extremely easy
to use and will program only (I think) 16C5X and 16C71. I also use
the Parallax downloader (ROM emulator) and I have been very pleased
with it too. No fancy Windows interface, but would you honestly want
one?
I would rather have a command line utility -- the Parallax programming
software: "PEP" is, unfortunately, interactive, but stil only takes a few
keystrokes (and no painful mouse-clicks) to program a PIC.
So that's my opinion, but I have no experience really with other
programmers or emulators.
I like the Baradine Microburner because it supports all existing PICs (with
appropriate adapters), and although it is shipped with a !@#$ interactive
interface like the other ones, it is completely ascii terminal based and
can be simply controlled by command line using the FREEWARE BURN.ZIP which
you can pick up on Microchip's BBS, my BBS, or probably several ftp sites.
It can also be operated from nearly any computer with a serial port!
I think it's a bit more than $200 US but well worth it in time and errors
saved through automated programming!
an555 is REALLY OLD. It'l take you a bit of work to get it to compile with
any of the current tools.
------- Advertizing suplement --------------------------------
Try ASPIC with it, it's a lot easier to debug, because it provides more
meaningful error messages an will pop up your editior on the offending
line(s) if your editor supports that feature (eg. Brief, multi-edit,
Winedit, Codewrite, etc.).
------------------------------------------------------------------------
>
> Hi everyone.
>
> I'm just starting to learn about the PICs, and I'm looking for
> recommendations for a programmer (for a PC). I've seen a couple listed in
> the FAQ, but I'd like a few opinions before I commit any of my hard-earned
> cash to one of them.
> Here's what I'd like to know...
>
> 1. Prices. I'm looking for something affordable. I've seen a couple of
> them
> advertized for under $200 U.S. That would be about right for me.
>
There is also one free programmer for the 16C84 . It is available via
anonymous FTP at : bode.ee.ualberta.ca , /pub/cookbook/ibm/parallel/...
You will find a schematic and software in C.
>
> You may want to try Digi-Key (1-800-344-4439). That temperature range will
> be pushing the specs. So, you probably will need to go to some of the
> crystal manufactures, such as CTS, Epson of AMerica or ECS. Sounds
> like a military temperature range??
> By the way the official operating specs for the pic chip is 0 to 70 C.
>
> Mike
>
>extended temperature version of the 16c64. I think that they work in the -40
>to
>105 C range. Since I've already written a mess of code for it, can someone
>verify this?
>Yours,
>Derrick Early
Hallo Derrick!
The 16C64, as far as I understand,will be available in extended temp.
Initially I think that Industrial is the one Microchip will put thru.
It has -40 - +85 C as it_s limits. The one you are looking for is the "E" temp
which is Automotive temprange going from -40 to +125 C and that one will be
early 1995 or something.
Jason, can you forward me any details on this - it's not one we've seen in
the UK at all (even the CCS guy in Milwaulkee who yuo got it from)?
Tks in advance
--
Alex R. Baker Phone: +44 628 851077 Car: +44 831 494921
Field Applications Engineer Fax: +44 628 850259 Email: @spam@alexRemoveMEEraseMEmicrochp.demon
Arizona Microchip Technology .co.uk
>
> Has anyone tried to program a PIC using the Needham Electronics
> EMP-20 device programmer? The EMP-20 looks like a flexible and very
> portable unit (two key points for me), and it is alledged to
> program almost every part that I care about. The question is, how
> well does it work on PICs in real life?
> David A. Boulton | knowledge is just a polite
> EraseMEboulton@spam@netcom.com | term for dead,
>
It works just fine. I use the 16c5x parts and never had a problem.
Like most burners it has a graphical interface, but you can write
an ini file that feeds it keystrokes. For example I call mine from
a bat file that recompiles my code with new EQUs from command line
arguements, then calls the burner program, burns the chip, and then
exits. All I need to do is drop in a chip before I hit return. The
EMP-20 gets it's versatility by using simm like modules to reroute
pin connections in hardware rather than software. If you order it
from Digi-Key you get the first 4 of 9 currently available with it.
Normally Needham only gives you the first three with it, but they
gave me all 4 since Digi-Key was back ordered at the time. This
was important since all the Microchip parts use simm # 4. BTW the
unit has a 48 pin ZIF. The simms go for about $40 US. It is very
portable as it connects to the parallel port with a standard centronics
printer cable, and port address is fully programmable. Good unit,
good service when I needed a clue on the ini file syntax. I'd recommend
it. Costs ~$450 US, more than the other PIC burners, but it'll do
tons more. Question is do you need the added features and what is
your budget. The answer to these questions will decide for you. -Rick
I have the PGM16 from Advanced Transdata Corporation. Having never seen
a picstart or paralax programmer, it might be an OEM or clone of one of
them, but in my sample of 2 parallel ports to connect it to (clone
DX-2/66 and Zeos sub-notebook) it runs great.
I regularly travel with the Zeos & programmer. Very convenient. Their
real time ICE also runs well on the Contenda - I can't imagine tucking my
desktop system in the back seat of the plane to take my development
system on the road. AS it is, an old briefcase serves as a complete real
time ICE / programmer capable system.
If anyone knows if this PGM16 critter is a clone of one of the other
programmers please let me know.
I'm trying to use the EEPROM on a PIC 16C84 to store some configuration
information. I wrote the following program to test the EEPROM. It should
fill the EEPROM with its address location (ie EEPROM @ address 3Fh is loaded
with 3Fh) and then read the lower 10 EEPROM addresses and display them
on a LCD display connected to the PIC. Unfortuneately it doesn't work.
I've also checked the EEPROM with my programmer (PICSPA) which indicates
that the EEPROM was not altered by the program. Additionally, I've
preprogrammed the 16C84 data EEPROM with the PICSPA and then tried to
read it with the same negative results.
I've tried everything I can think of to access and test the PIC's data
EEPROM. If there is an experienced 16C84 programmer that can find any
problems in my code (The offending code follows this plea), I would sure
like to know what I'm doing wrong.
Thanks,
Scott Colson
Background:
PIC 16C84 operating at 4Mhz using an RC clock.
All called routines have been tested seperately and work correctly.
The last section of the routine properly reads the EEDATA and EEADR
registers, but the EEDATA register always contains the value 01h which
is the last value written to it in the previous code section.
I'm trying to use the EEPROM on a PIC 16C84 to store some configuration
information. I wrote the following program to test the EEPROM. It should
fill the EEPROM with its address location (ie EEPROM @ address 3Fh is loaded
with 3Fh) and then read the lower 10 EEPROM addresses and display them
on a LCD display connected to the PIC. Unfortuneately it doesn't work.
I've also checked the EEPROM with my programmer (PICSPA) which indicates
that the EEPROM was not altered by the program. Additionally, I've
preprogrammed the 16C84 data EEPROM with the PICSPA and then tried to
read it with the same negative results.
I've tried everything I can think of to access and test the PIC's data
EEPROM. If there is an experienced 16C84 programmer that can find any
problems in my code (The offending code follows this plea), I would sure
like to know what I'm doing wrong.
Thanks,
Scott Colson
Background:
PIC 16C84 operating at 4Mhz using an RC clock.
All called routines have been tested seperately and work correctly.
The last section of the routine properly reads the EEDATA and EEADR
registers, but the EEDATA register always contains the value 01h which
is the last value written to it in the previous code section.
Although many people have let me know that they have got the
programmer to work it is worth giving a few words of caution if you
are thinking of building it:
* I developed this project using a 20MHz 386DX machine and have
subsequently found the C version to be unreliable when used with my
33MHz 486DX. Obviously a timing problem and I will try to fix this
when I get some spare time. The Qbasic version still worked though,
and the C version worked with turbo mode switched off.
* Please note that the executable packaged with the programmer info
was built for hardware using a 7406. If you use a 7407 you must
uncomment "#define U7407" and recompile. The Qbasic source is also
intended for hardware using a 7406. To use the Qbasic program with
7407 based hardware then include these definitions:
(Due to a typo, the program erroneously suggests that you
should use ClkHi = 4. Sorry about that.)
* If you don't use LS buffers you should substitute a 7805 for the
78L05.
I recently designed a PCB for the programmer which should make life
easier for intending constructors (it was while testing my PCB that I
found the timing problem). The details will be packaged with the next
release of the software (i.e the one that corrects the timing bug). I
can't promise when that will be ready though.
It doesn't seem to be as widely known as it should be that there is
information on another 16C84 programmer available on the net. This
one was designed by Henk Schaer and is (at least was when I last
looked) available as
>
> Hi,
>
> I tried to mail this last week but it doesn't seem to have made it
> onto the list.
>
> Derrick Early mentioned he was hoping to build a 16C84 programmer.
> You can ftp the info about this programmer from:
>
> ftp://ftp.ee.ualberta.ca:/pub/cookbook/comp/ibm/pic84pgm.zip
>
David,
I received your message last week just fine. I looked at the picprog.zip
files, and it also looks like a good setup for a programmer. My only
problem with it is that it doesn't appear to include the source for the
software. I guess that someone could just send email to the author, and
you may be able to get a copy.
On Sep 6, 11:13, David Tait wrote:
[stuff deleted]
>
> * I developed this project using a 20MHz 386DX machine and have
> subsequently found the C version to be unreliable when used with my
> 33MHz 486DX. Obviously a timing problem and I will try to fix this
> when I get some spare time. The Qbasic version still worked though,
> and the C version worked with turbo mode switched off.
I've had this kind of problem before with other cctry connected to PC
parallel ports. One way to fix it is to edit the CMOS configuration of
the PC and slow down the 8-bit I/O access by adding a few wait states.
Maybe this can work in this case too.
>I've tried everything I can think of to access and test the PIC's data
>EEPROM. If there is an experienced 16C84 programmer that can find any
>problems in my code (The offending code follows this plea), I would sure
>like to know what I'm doing wrong.
Scott - this code works. It is written in ASPIC.
WARNING - ASPIC HANDLES REGISTER BANKING: you will need to add that in
your code!
This assumes that you have included the segment managemant macros (SEGMACS.ASI),
and the default segment definitions in (PICMACRO.ASM).
(We first need to generate overriding bit labels for EECON1 bits if we are
compiling
with 5.32, Registered users with 5.33beta or later need not worry about this)
.ds 3 ;PCL,STATUS,FSR image
TRISA: .ds 1
TRISB: .ds 1
.ds 1 ;(tris C)
;***************************************************************************
;** EECON1
;** *** DANGER *** WE NEED TO RE-DEFINE THE EECON1 BITS TO FIX A BUG IN
;** ASPIC 5.32! **DO NOT USE THE INTERNAL DEFINITIONS!!!
;**
;***************************************************************************
;***************************************************************************
;** EE_READ - read EEPROM address in W
;** Return the contents of the EEPROM location in W
;** returns the value in W
;**
;** Data is stored in EEPROM in 1's compliment to increase the 1's density
;** This increases the life of the EEPROM
;**
;** Preserves ALL TEMPS (ASPIC takes care of all of the register banking!)
;**
;***************************************************************************
EE_READ:
CLRWDT ;reset watchdog timeout
..loop:
BTFSC B.WR ;wait for previous write to end
goto ..loop
;***************************************************************************
;** EE_WRITE - Write W to the EEPROM location in TEMP
;**
;** returns the value in W
;**
;** Data is stored in EEPROM in 1's compliment to increase the 1's density
;** This increases the life of the EEPROM
;**
;** The location is read first and is not written if the contents have not
;** changed.
;**
;** Preserves W and all TEMPS
;**
;***************************************************************************
EE_WRITE:
CLRWDT ;reset watchdog timeout
..loop: ;
BTFSC B.WR ;wait for previous write to end
goto ..loop; ;
MOVWF EEDATA ;set data
MOVFW TEMP ;
MOVWF EEADR ;set address
MOVFW EEDATA ;GET data back
SEB B.RD ;initiate READ
XORLW $FF ;flip bits to improve endurance
XORWF EEDATA ;CHECK if data is the same
BZ eew_x ;data is the same, don't write
MOVWF EEDATA ;set data to write
SEB B.WREN ;make sure write is enabled
movlw $55 ;** MAGIC NUMBER FOR EE WRITE
clb GIE ;disable interrupts
movwf EECON2 ;\******************************
movlw $AA ; \ MAGIC CODE
movwf EECON2 ; / DO NOT CHANGE
bsf B.WR ;/******************************
movfw EEDATA ;restore W
eew_x:
XORLW $FF ;flip bits
retfie ;RETURN and re-enable INTS
> On Sep 6, 11:13, David Tait wrote:
> [stuff deleted]
> >
> > * I developed this project using a 20MHz 386DX machine and have
> > subsequently found the C version to be unreliable when used with my
> > 33MHz 486DX. Obviously a timing problem and I will try to fix this
> > when I get some spare time. The Qbasic version still worked though,
> > and the C version worked with turbo mode switched off.
>
> I've had this kind of problem before with other cctry connected to PC
> parallel ports. One way to fix it is to edit the CMOS configuration of
> the PC and slow down the 8-bit I/O access by adding a few wait states.
> Maybe this can work in this case too.
In many cases the chips of the parallel card are too slow to alllow the
high speed switching of a fast card. For instance, you might have a bt
set low, you then pulse the bit high, then a 486 clock cycle or two later
return it to low. All fine in theory, but the card hasn't had time to
switch to the high state before it was instructed to return low.
Yeah, putting in wait delays will work. Another one you could try is
feed the output of one or two of the bits back into parallel port. That
way, you could read when the card has made the switch.
Oh, by the way, I'm new to the PIC group. Can anyone tell me something
about the PIC? What it can do, features, nice stuff, etc? Thanks.
Don Lekei prophesized:
> I have
> been toying with some Parallax-to-ASPIC macros, but I have little
> confidence in them yet as I do not know the actual code generated by the
> Parallax "Instructions".
The Parallax User's manual shows the native instructions generated for
each Parallax mnemonic. I could also assemble the assembler test file
(ie. all mneumonics) and send you the hex version.
16C61 = 16C71 with no ADC (or a 16C56 with interrupts if you prefer to
look at it that way)
16C73 = 16C74 in a 28 pin package - misses off the parallel slave port.
Full d/s available from a disti near you for the 16C61, and also a
flyer for the 16C73 from the same source.
Best regards
Alex R. Baker - Field Apps Engineer Ph: +44 628 851077 Car: +44 831 494921
Arizona Microchip Technology Fx: +44 628 850259 Email: .....alex@spam@EraseMEmicrochp.dem
on.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY E
MPLOYER
Is anyone else out there working on a decent development environment
for PIC programming under Linux? I'm writing a downloader to drive
a serial programming board like Russ Reiss' or David Tait's from the
parallel port. Right now it has decent libraries but the actual driver
code is pretty weak (I'm a fan of the add-features-as-I-need-'em school
of software design). However, a couple of weeks ago I mentioned
to several people that I'd probably be releasing an alpha version in
about a week, so I'm announcing version 0.1 now even though it's still
got a long way to go before it's even "alpha". I'd like to offer my
code to the community so that instead of having N different downloaders
each with its own strengths and weaknesses, we can have one comprehensive
programmer... so if you're thinking of writing a programmer or similar
tool, drop me a line and see if it would be easier to extend my code.
(If you just want a programmer and no hassle, though, my code isn't
at that stage yet.)
--
... William Lewis. ----- .....wimlRemoveMEnetcom.com ----- Seattle, WA, USA
"The mind is not a vessel to be filled, but a fire to be kindled."
I've been porting the C code for the assembler and serial programmer
by ED Technical Publications. They had an article for their 16C5X
programmer kit in Electronics Now(?).
Anyway, the code is truly gross and helps to feed my generalization
that engineers who are not "programmers" should not be allowed to
write code. I've got it compiling under Linux pretty clean using
gcc with almost all the warnings turned on (not just -Wall) for
the assembler and have yet to finish work on the downloader code.
If someone has the same kit, I can mail you my version and the originals.
DOSEMU works but is less that ideal.
I guess a copylefted simulator would be a noble eventual goal for
many of us.
> I've been porting the C code for the assembler and serial programmer
> by ED Technical Publications. They had an article for their 16C5X
> programmer kit in Electronics Now(?).
>
What sort of serial protocol is used ? Is it sustainable with common
Unix serial drivers, or do you have to do some clever stuff with the
handshake lines ?
A generic serial connection to the programmer sounds a nicer solution
than porting the parallel-port programmer, since it would be usable with
all Unixes rather than being Linux-specific. A special device driver
that only works on PC-Linux seems barely better than a DOS-only utility
to me.
Are the protocols that Microchip uses to talk to the Picstart (and
perhaps other programmers) published anywhere ? It seems to involve
a lot of handshake-line-waving, but perhaps it's just doing excessive
flowcontrol - I don't know whether it will work with the accepted
handshake protocols.
> If someone has the same kit, I can mail you my version and the originals.
> DOSEMU works but is less that ideal.
I don't have the kit. Are the sources copyright / not copyable ?
>> I've been porting the C code for the assembler and serial programmer
>> by ED Technical Publications. They had an article for their 16C5X
>> programmer kit in Electronics Now(?).
I've been struggling along with the PICSTART and it sucks. My housemate has
a Linux machine and with the advent of this Linux base, we could share the
programmer.
Can somebody give me a firm reference to this serial programmer kit?
>Jory,
>
>May I suggest that somebody (you?? or some automated mechanism) post a
>how-to-post type article.
>
>While I read what flies past, I never seem to be able to find the how-to-post
>info when I need it.
in case this detail is keeping people from jumping into the fray:
there are basically two ways to post to the pic list:
2. you can "reply" with your mailer software to a message which was sent to
thepic list.
note that if you simply reply to a message someone sent to the pic list,
your response will go to the list, and not to the individual who sent the
message.
in order to send to the original poster, you must manually supply their
email address (which is notes in their original mail to the list).
I hacked up a little PIC programmer on a Z80-based computer I had
lying around, and it seemed to work (I could program stuff into the
EEPROM and read it back) so I wrote, and hand-assembled, the following
program, which I thought would blink the lines of port B on & off in
such a way that I could see on a scope that things were working.
Unfortunately, all I get is 33%-duty cycle pulses out of RB0 and RB2,
and nothing elsewhere. Can one of you PIC gurus tell me what I'm
doing wrong?
0000 0005 (reset vector)
...
0005 1683 BSF 3,5 ; Select page 1
0006 3000 MOVLW 0 ; Clear TRISB
0007 0086 MOVWF 86
0008 1283 BCF 3,5 ; Point back to page 0
0009 0186 CLRF 6 ; Port B all LOW
000a 30FF MOVLW FF
000b 0086 MOVWF 6 ; Port B all HIGH
000c 0064 CLRWDT
000d 2809 GOTO 9
[This is my *very* *first* PIC program; be gentle! :-)]
Thanks,
--------------------------------------- -----------------------------
dave madden <spamBeGonedhmKILLspam@spam@vheissu.net.dcl.co.jp> i don't know about your brain,
3-16-19 naka-machi #301 but mine is really ... bossy.
musashino, tokyo 180 japan -l. anderson
> What sort of serial protocol is used ? Is it sustainable with common
> Unix serial drivers, or do you have to do some clever stuff with the
> handshake lines ?
The source for the 16C7X chip in the programmer is also on the BBS.
>From what I have been able to understand from the source, the protocol
is pretty asynchronous (read: hideous amounts of time spent sending
handshake characters in lockstep back and forth instead of using flow
control) and can be implemented with really easy blocking I/O so the
code should be trivial to port. If I have to do funky serial setup
using termios or something, then one camp (BSD or SysV) will be
unhappy.
> A generic serial connection to the programmer sounds a nicer solution
> than porting the parallel-port programmer, since it would be usable with
> all Unixes rather than being Linux-specific. A special device driver
> that only works on PC-Linux seems barely better than a DOS-only utility
> to me.
If I had the choice again, I'd be inclined to get some commercial
serial-based product since kits are annoying. Good thing I got my
brother to put this one together. :-)
The one good thing about this kit is that it does verify at min and
max voltage levels. A definite drawback is that this thing only does the
16C5X series chips.
When I get around to porting the serial routines, it won't be very
Linux specific. I just won't promise it will work on platform XX unless
someone gives a nice XX system. :-)
> Are the protocols that Microchip uses to talk to the Picstart (and
> perhaps other programmers) published anywhere ? It seems to involve
> a lot of handshake-line-waving, but perhaps it's just doing excessive
> flowcontrol - I don't know whether it will work with the accepted
> handshake protocols.
Has someone tried asking for the protocol specs? It always amazes me
how hardware venders can be so protective about a few API/comm specs
that are absolutely useless without the hardware they sell!
> > If someone has the same kit, I can mail you my version and the originals.
> > DOSEMU works but is less that ideal.
> I don't have the kit. Are the sources copyright / not copyable ?
Everything is copyrighted. Automatically by law. However, there seems
to be no restriction on the distribution. I didn't need to do anything
special to get it from their BBS.
I offered to mail it to people because most people here use the MicroChip
or PICSTART products and couldn't care less about source for PICPROG.EXE
Personally, it would be nice to have a unified set of unix tools with
a back end for each product but that's probably wishful thinking.
I'm jumping in to this late, so please pardon me if I ask something obvious.
> > What sort of serial protocol is used ? Is it sustainable with common
> > Unix serial drivers, or do you have to do some clever stuff with the
> > handshake lines ?
What programmer is this? I've had a few ideas in my head for awhile for a
device such as this. It sounds like this might be specific to a certain
small part of the PIC family. What I have in mind would be a lot more
general purpose.
>
> The source for the 16C7X chip in the programmer is also on the BBS.
> From what I have been able to understand from the source, the protocol
> is pretty asynchronous (read: hideous amounts of time spent sending
> handshake characters in lockstep back and forth instead of using flow
> control) and can be implemented with really easy blocking I/O so the
> code should be trivial to port. If I have to do funky serial setup
> using termios or something, then one camp (BSD or SysV) will be
> unhappy.
Of course, the way to deal with this is to write two object modules (
one for BSD, one for SYSV) which abstract serial IO to the appropriate level,
and then link in the one that you need. The rest of the code doesn't have
to know about the differences then.
>
> > A generic serial connection to the programmer sounds a nicer solution
> > than porting the parallel-port programmer, since it would be usable with
> > all Unixes rather than being Linux-specific. A special device driver
> > that only works on PC-Linux seems barely better than a DOS-only utility
> > to me.
True. In fact, hey, just write another serial object module for DOS.
>
> If I had the choice again, I'd be inclined to get some commercial
> serial-based product since kits are annoying. Good thing I got my
> brother to put this one together. :-)
Well, I must be wierd then. I like building kits. The ones from Micromint
are a dream, BTW. Of course, they should offer you the choice of buying
an assembled and tested unit if you want to.
> The one good thing about this kit is that it does verify at min and
> max voltage levels. A definite drawback is that this thing only does the
> 16C5X series chips.
Aha, as I figured. If I ever get around to designing my programmer, it will
have a variety of Vcc and Vpp and programming algorithms. I will probably
base it on an 8051 due to external memory addressing issues and the presence of
a real UART onboard. Oh, and I already have a programmer for 8751s.
Programming will be via the serial port, with a choice of XON/XOFF or hardware
handshaking, and the protocol will be open. Normal asyncronous serial support
is necessary for platform independence. Once that is done, parallel port
support is just another access method. A major goal of this is to be
able to program not only the entire PIC family, but also other microcontrollers,
EPROMS, and EEPROMS.
Is somebody already doing this? Is anyone interested in banging out the details
and the hardware with me? Would the world be terribly mad at me if I wrote
the host side software in C++ instead of C?
> When I get around to porting the serial routines, it won't be very
> Linux specific. I just won't promise it will work on platform XX unless
> someone gives a nice XX system. :-)
Reasonable.
> Personally, it would be nice to have a unified set of unix tools with
> a back end for each product but that's probably wishful thinking.
Oh yes. And no fancy GUI stuff. I want to be able to use the tools from a
makefile. If someone else wants to write a fancy front end for the tools,
they can, but the command functionality must be there.
Right now, I'm working on an
assembler which will be flexible enough to work on all of the PIC family just
by loading up a different table of opcode descriptions. A feature of this
assembler will be strong typing and promotion such that:
clr label
translates to
clrf 6
if label is register file 6 and
clr label
translates to
cbf 6,0
if label is register file, bit 0.
I already have that functionality, but I am redesigning the assembler to make
expression parsing work correctly with parentheses, and make it more flexible.
Excerpts from mail: 31-Oct-94 Re: 16C84 downloader for Linux by Lou Sortmanspam_OUT@spam@NCINFO.IOG.U
> Aha, as I figured. If I ever get around to designing my programmer, it will
> have a variety of Vcc and Vpp and programming algorithms. I will probably
> base it on an 8051 due to external memory addressing issues and the
presence of
> a real UART onboard. Oh, and I already have a programmer for 8751s.
> Programming will be via the serial port, with a choice of XON/XOFF or
hardware
> handshaking, and the protocol will be open. Normal asyncronous serial
support
> is necessary for platform independence. Once that is done, parallel port
> support is just another access method. A major goal of this is to be
> able to program not only the entire PIC family, but also other
microcontrollers,
>
> EPROMS, and EEPROMS.
>
> Is somebody already doing this? Is anyone interested in banging out
the details
>
> and the hardware with me? Would the world be terribly mad at me if I wrote
> the host side software in C++ instead of C?
I'm going to design a _very_ similar universal programmer, but I
have a few other things that I'd like it to do such as chip
identification and verification. I've been researching bits and pieces
of it as I get time, but the actual project will have to wait until the
summer. I'm not much of an analog person, so that's the stuff that I
really have to research... Go ahead and use C++! It would be a crime
not to. I'm going to go with an HC11 or HC16 microcontroller instead of
an 8051 variant though.
Chris Kristof
Junior ECE
Carnegie Mellon University
There are several new PICs on the way. The '63 and '73 were listed in some
marketing literature given out at the seminar earlier this year. The '61 and
'65 are mentioned in various files included with the PICSTART-16C. I asked a
Microchip employee about them, and he was very surprised to find out that the
PICSTART referred to these parts; he said they weren't supposed to be talking
about them yet.
PIC16C61: a 16C71 without the A/D converter (lower cost)
PIC16C63: a 16C64 in a 28-pin package
PIC16C65: a 16C74 without the A/D converter (lower cost)
PIC16C73: a 16C74 in a 28-pin package
Some of the marketing literature from the seminar also described a 17C44,
which is a 17C42 with more memory.
Last year I didn't think the 17C4x was very cost effective, since the prices
were comparable to the 68HC11, although admittedly the 17C42 runs faster.
Since Motorola is unable to keep up with demand and 68HC11 prices have gone
up considerably, the 17C42 is looking very attractive.
The Mitsubishi 377xx family also is good for high performance low power
embedded applications, but I can't actually recommend Mitsubishi because they
are very hard to deal with and tend to screw small companies royally.
I thought that one of the PICS had a UART built in but I can't find any.
Am I missing something or is there one that does RS232 using a built-in
UART? I do NOT want to do RS232 using PIC code - I want speed...!!!
I'll second Eric's comments on Mitsubishi (being hard to deal with).
When I was considering design ideas for a widget we eventually built
11,000 of, I called Mitsubishi to ask about a 'perfect for the task'
4-bit CPU that they had. I had a terrible time getting through, only
to find that they wouldn't even *talk* to me unless I could promise
an initial production run of 100,000+ pieces. Paid up front. (!)
Microchip sent me free samples and an apps engineer. Easy, huh?
> I thought that one of the PICS had a UART built in but I can't find any.
> Am I missing something or is there one that does RS232 using a built-in
> UART? I do NOT want to do RS232 using PIC code - I want speed...!!!
yea there is. Its the 17c42. Its pretty expensive though. As far as
speed I have done 19.2Kbps. How fast do you need it to be? If it really
bothers you about "waisting" time use something like the 84 or the 71
which have interupt. preload the RTCC and service and interupt. yes it
it a waist, kind of. But that depends on you needing the RTCC or not.
Also the 17c42 is large(40 pin). Most of my work is B-size cards for VXI
and a 40 pin device had better be well worth the price.
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | spamBeGonejohnsonjspam_OUTRemoveMEbga.com | .....johnsonjRemoveMEutdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
I have been looking over the docs on how to preform parallel programming
of a pic. The 6/7/8 all program similar. However they all reference a
"RT"pin. Which pin is this? I assume that on the 18 pin devices that it
is the RTCC pin(as all of the others are used). however on the 40 pin
devices I am not sure. could it be/is it the timer0 pin???? Any help
would be nice. BTW if you wonder why I am using parallel its because
1)its a personal project and 2)Its 10X faster.
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | johnsonj@spam@bga.com | EraseMEjohnsonjRemoveMESTOPspamutdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
Paul Greenwood <RemoveMEpabloKILLspamTakeThisOuTaustin.ibm.com> asks:
> I thought that one of the PICS had a UART built in but I can't find any.
> Am I missing something or is there one that does RS232 using a built-in
> UART? I do NOT want to do RS232 using PIC code - I want speed...!!!
Only the PIC16C74 and the PIC17C42 have a hardware UART.
IMHO, the material in the Microchip application notes on serial communication
completely fall flat on the full-duplex case. They recommend sampling at
twice the bit rate, which would be fine except that they say to delay 1.25
bit times from detecting the leading edge of the start bit so that the sampling
of the data bits falls within the center of the bit times. It's pretty hard
to delay 1.25 bit times when you are sampling at .5 bit time intervals. If
you were only doing half duplex, you could do a non-standard sample interval
for the stop bit because you wouldn't be screwing up the transmit timing.
What I've found works best is to sample at 3 times the bit rate. After the
detection of the start bit, delay four sample times (1 1/3 bit) before
sampling the first data bit, and three sample times between each additional
receive bit. This guarantees that the data bit sampling occurs in the middle
third of the bit times (unless the start bit was a glitch, which could be
detected by sampling it again one sample time after the initial detection).
This allows for a +- 6% speed tolerance between the transmitting device and
the receiving PIC. The transmit code in the PIC obviously just runs every
third sample time. I implemented this all on the 16C71 using two state
machines for transmit and receive, and using the RTCC as an interrupt source.
It is possible to achieve fairly high data rates without too much CPU time
consumed.
I used the same technique in the 16C57 but without interrupts. I chose a
crystal frequency such that 1/3 bit time worked out to an integral number of
RTCC counts, and resync to the RTCC for each sample time. This means that the
application code has to run in short time slots.
Tried to post this earlier, but it didn't get through, I don't think:
Has anyone thought of using the WDT? Just check the flag bits at the
beginning of your program, and you can tell if you're starting from
scratch (better init everything) or just waking up from the WDT.
You can set the WDT prescaler to the interval you want, then do your
loop stuff, and go to sleep. The WDT will wake you up. You just have
to structure your program to branch to the loop entry from the
beginning if it's a WDT entry...
That is, if you're not already planning to use the WDT for the obvious...
Someone give me a sanity check on this... I may use it in an upcoming
project.
Regards,
- JohnR
--
John R. Haggis outside mail, please respond to:
IBM Almaden Research Center spamBeGonehaggis@spam@netcom.com
927-2474 / ZZHAGGIS AT ALMADEN
--------- Forwarded Message Follows ---------
"My plan is to assign the prescaler to the RTCC and spin waiting for
it to equal zero."
That works; my usual technique is to set the RTCC to a negative number
and bit-test the MSB. Remember to account for the delay between
initializing the RTCC and when it begins to increment.
>
> Has anyone thought of using the WDT? Just check the flag bits at the
> beginning of your program, and you can tell if you're starting from
> scratch (better init everything) or just waking up from the WDT.
>
> You can set the WDT prescaler to the interval you want, then do your
> loop stuff, and go to sleep. The WDT will wake you up. You just have
> to structure your program to branch to the loop entry from the
> beginning if it's a WDT entry...
>
> That is, if you're not already planning to use the WDT for the obvious...
>
> Someone give me a sanity check on this... I may use it in an upcoming
> project.
>
> Regards,
>
> - JohnR
>
The only problem I see here is that the WDT is a free running on-chip
RC oscillator. To quote the DataBook for the PIC16C71:
The WDT has a nominal time-out period of 18 ms, (with
no prescaler). The time-out periods vary with
temperature, VDD and process variations from part to
part (see DC specs).
So you see, if you want accurate timing, the use of the RTCC is required
since it works off of the crystal controlled oscillator. If you put the
part to sleep, the crystal oscillator stops and you cannot really get
very accurate timing.
When I built a recording accelerometer using the 16C71, I used the RTCC
with prescaler, checked for zero in the RTCC in a tight loop, On RTCC=0
I sampled, did a little averaging processing, saved the sample to memory
via serial routine to EEPROM, then entered my loop. I figured out ahead
of time that by the time I finished my routines, the RTCC was no longer
at zero so I was not worried about entering the loop and immediately
jumping out again. Also, with the prescaler set to at least 4, you will
not miss the RTCC=0 point. I chose not to use the RTCC interrupt
because I didn't need to do anything else until the time for the next
sample rolled around. Your milage may vary of course.
Regards,
Jerry
===============================================================================
Jerry Ethridge Richardson, Tx. |
ERICSSON NETWORK SYSTEMS /O\ exujetspamexu.ericsson.se \_______[|(.)|]_______/
o ++ O ++ o
===============================================================================
>
> I thought that one of the PICS had a UART built in but I can't find any.
> Am I missing something or is there one that does RS232 using a built-in
> UART? I do NOT want to do RS232 using PIC code - I want speed...!!!
>
19200 full duplex in a PIC16C54HS running at 18.432 MHz with 2/3 of
the CPU time left over. Could that be something..?
The application note with the RS232 state machine is NOT the most
efficient way to do a software UART. If I remember right it can do
9600 in a 20 MHz PIC but you will have no time left for other things.
Let me know if you're interested!
> 19200 full duplex in a PIC16C54HS running at 18.432 MHz with 2/3 of
> the CPU time left over. Could that be something..?
> The application note with the RS232 state machine is NOT the most
> efficient way to do a software UART. If I remember right it can do
> 9600 in a 20 MHz PIC but you will have no time left for other things.
> Let me know if you're interested!
>
I'd be interested in seeing a better way to bit bang a UART if you'd
post a sample of the code. Thanks.
> 19200 full duplex in a PIC16C54HS running at 18.432 MHz with 2/3 of
> the CPU time left over. Could that be something..?
> The application note with the RS232 state machine is NOT the most
> efficient way to do a software UART. If I remember right it can do
> 9600 in a 20 MHz PIC but you will have no time left for other things.
> Let me know if you're interested!
I still think I'm pushing the limits of what the PIC can do with all the
other stuff I need to be doing - but, I AM interested if you're giving
out code...!!!
Excerpts from mail: 2-Nov-94 Re: (Fwd) Re: PIC16C5.. by Jerry EthridgespamBeGone.....EXU.ERICS
> When I built a recording accelerometer using the 16C71, I used the RTCC
Did you build the accelerometer from "scratch," or did you just
augment a commercially available accelerometer? Either way, I'd
appreciate a little blurb about what you did. I'm going to be needing
an accelerometer at some point and have had trouble finding one that
does what I need but doesn't cost $500. (I need three for a student
project...)
Chris Kristof
Junior ECE
Carnegie Mellon University
>
> Did you build the accelerometer from "scratch," or did you just
> augment a commercially available accelerometer? Either way, I'd
> appreciate a little blurb about what you did. I'm going to be needing
> an accelerometer at some point and have had trouble finding one that
> does what I need but doesn't cost $500. (I need three for a student
> project...)
>
> Chris Kristof
> Junior ECE
> Carnegie Mellon University
>
Hello Chris,
I use an Analog devices ADXL50 accelerometer. It is an excellent product
which cost me $75 about 10 months ago. Accelerometers are generally
coming down in price. I will send you a list of manufacturers at the end
of this post.
Back to my device. I use the Analog Devices part because it is very small
(TO-5 can I think). It is very linear, has a built in unused amp that
the designer can use for several puposes, etc. Get the data sheet on it,
I think you will like it.
I use the PIC16C71 because it had an A/D converter on board. It is very
small, has a bigger stack, and you don't have to do all that page switching
stuff if you do far calls in the program. I save the data to EEPROM. I am
currently using two 93c66 for a total of 1024 samples. I wrote the software
to buffer 20 samples in a rotating ram buffer, and if the last five samples
all exceed 2 G's, then I set a flag that means liftoff of the rocket has
been detected. I then start saving subsequent samples to EEPROM starting with
the 21 position. Once the EEprom is full, I go back and save the buffered
data in the first 20 positions of the EEPROM. This way, I see a small section
where the rocket is sitting on the pad, then I see the liftoff etc. After all
this is complete, The device goes to sleep.
I recover the rocket, pull the EEPROMs and put them in another device that
uses a 16C71 and a Maxim RS232 converter chip. I wrote software to do 9600
baud transfer, and to convert the data to ascii. What I get is a stream
of numbers that can be directly pasted into my spreadsheet for plotting.
It works extremely well and I have been asked to make it available to the
rocket hobby industry.
The version I'm working on now will use Microchips new EEPROMs, the
24LC65 that have 8k. Also, I will use a 10 bit, serial A/D converter
for better resolution, and I will include a small Dallas Semiconductor
RS232 converter on the same board. The Dallas part steals -12 volts from
the host computer in order to transmit it's data without charge pump
circuitry to make the negative voltage. The whole thing will be very
small, since I will try to get most of the parts in the surface mount
package.
Anymore questions, let me know.
Regards,
Jerry
Here is the promised list of acclerometers:
>>>>>>>>>>>>>>>> List of Accelerometer Manufacturers <<<<<<<<<<<<<<<<<<<<<<
-------------------------------
Analog Devices ADXL50 accelerometer.
Power Supply........................... +5V (+/- 5%)
Measurement Range...................... +/- 50g
Pre-Amp Zero-g output level............ +1.8V
Pre-Amp output span.................... +1.8V (+/-1.2V) at +/-50g
Uncommitted amp output range........... +0.25V to +4.75V
Overall Accuracy....................... 5% of Full Scale
Linearity.............................. 0.5% of Full Scale
Bandwidth.............................. DC to 1kHz
Voltage Noise (p-p)
at BW = 0.3kHz..................... +/-0.24% of Full Scale
at BW = 1.0kHz..................... +/-0.48% of Full Scale
Transverse Sensitivity................. 2%
Unpowered Shock Survival............... 2000g
I've found several Distributors:
Newark Electronics..................... 1-800-281-4320
Hamilton-Hallmark...................... 1-800-332-8638
Active Electronics..................... 1-800-677-8899
*******************************
Silicon Designs, Inc.
- Capacitive Accelerometers
Model 1010, Digital output:
Produces Digital pulse train in which the density of pulses
(number of pulses a second) is proprtional to applied acceleration.
It operates with a single +5 volt power supply and requires a clock
of 100kHz - 1MHz. The output is ratiometric to the clock frequency
and independent of the power supply voltage. Two forms of digital
signals are provided for direct interfacing to a microprocessor or
counter.
This devices comes in a PLCC package that is smaller than a penny.
Model 1210, Analog output:
Privides two analog outputs, 1-4 volts, or 4-1 volt, with O g's
at 2.5 volts. The outputs can be used either differentially or single
ended referenced to 2.5 volts. Two reference voltages--+5.0 and +2.5
volts (nominal)-- are required; the output scale factor is ratiometric
to the +5 volt reference voltage.
Address:
Silicon Designs, Inc.
1445-NW Mall Street
Issaquah, WA. 98027-5344
Tel: (206) 391-8329
Fax: (206) 391-0446
Prices start at about $100 and they offer a digital accelerometer
evaluation board for $200.
***********************************
Silicon Microstructures, Inc.
Model 7170 series and 7130 series capacitive accelerometers.
These are relatively large devices with built in ASIC signal
processing.They have very good accuracy specs and are pre-calibrated.
I have not contacted them personally but they will send you some
brochures on all of their devices. They also make pressure sensors.
Address:
Silicon Micostructures, Inc.
46725 Fremont Boulevard
Fremont CA. 94538
Tel: (510) 490-5010
Fax: (510) 490-1119
If you contact AMP, they will send you alot of information on
their piezo sensors and include a little piezo film sensor
for you to experiment with.
Their most interesting device is the AHC-04-08 accelerometer/shock
sensor that contains three sensing elements oriented to measure
acceleration in two linear axes and one angular axis. Each sensor
has a dedicated channel with adjustable gain, an adjustable comparator,
and selectable output control to provide either a digital or analog
signal. It is a low profile surface mount chip with 14 pins. It has internal
eeprom for programming the adjustable gains, and output modes.
The only problem I see with this device is that it has a lower
limit on the frequency response. Typically about 7-13 Hz. This means
if it were subjected to a steady 10 G acceleration for example, the
output would rise to 10 G's then decay down to zero even though it
were still at 10 G's. This is good for measuring shocks but not
steady accelerations.
A good point is that it was only $30 for a single unit.
I'm using the PIC 16C84 in a control application, and since the
software is yet a bit unstable, I have added a RESET button to let
the user (that is, me) restart the program when it has lost track of
what is happening. I don't use the WDT for this since the control
program is actually running. It has only missed a few input signals
that makes it out of phase.
When the program starts, it has to initialize a few other components
(an LCD and also some mechanical units), which takes a few seconds.
What I want to do is to detect after a reset if the reset is due to me
pressing the button (connected to the MCLR pin), or due to power-up.
If I could only change the TO or PD bits in the status register, this
would be a simple task, but since I can't I don't know how to do this.
Any suggestions? (please don't ask me to fix the program... I'm
trying to!)
>
> Hook your reset button to both the MCLR and a input port, then just check the
> pin on startup.
>
> Steve
Thanks for the suggestion, Steve. I havn't tried this yet, but
doesn't the PIC halt execution until the MCLR pin goes high again
after reset? If this is the case (which I think it is), then I'm
afraid the suggested method will not work.
> >
> > Hook your reset button to both the MCLR and a input port, then just check th
e
> > pin on startup.
> >
> > Steve
>
> Thanks for the suggestion, Steve. I havn't tried this yet, but
> doesn't the PIC halt execution until the MCLR pin goes high again
> after reset? If this is the case (which I think it is), then I'm
> afraid the suggested method will not work.
Isn't there a one-button wake-up appnote in the embedded systems book?
If so, can't that be modified to meet your needs?
Couldn't you just ground a cap. through a diode with a slow charge time on input
pin, slow enough so when button is released the restart delays would expire and
program would still have time to sense a low on input pin. Thats the cheap way.
Steve
---------------Original Message---------------
>
> Hook your reset button to both the MCLR and a input port, then just check the
> pin on startup.
>
> Steve
Thanks for the suggestion, Steve. I havn't tried this yet, but
doesn't the PIC halt execution until the MCLR pin goes high again
after reset? If this is the case (which I think it is), then I'm
afraid the suggested method will not work.
I have now solved the problem by simply assigning another IO-pin to my
"RESET" button. The pin is polled in software, and the program
restarts without the initialization code after the button-press is detected.
Actually, I wrote the original artice not only because I wanted a
solution to my specific problem, but to hear if anyone has any ideas
on how to detect the reason for reset from software. From the data
sheet it seems like the TO and PD bits in the STATUS register can be
used to differentiate between different causes of reset (Section 4.1).
I think I now know what these abbreviations stand for (TO=time-out,
PD=power down=sleep ?) This explains, I think, why it's impossible to
determine the exact reason for reset from them (they are simply not
implemented for that purpose, to the opposite from what I first
though...)
Anyway, there could have been some bit in some register somewhere that
is set to a known state on POR, and unchanged on a MCLR reset. In
this case it would have been possible to change this bit after
power-on, and to examine this bit after every reset... I see from
Table 4.1.1 that there are no such bits...
> It will work -- the catch is that you use an RC on the reset pin. The
> keypress wakeup app note that someone else alluded to is the right
> approach.
< stuff deleted >
I've got a SIMILAR type of question..... The databook says that when
powering up a PIC, Vdd must start from 0V. I've found this, unfortunately
to be correct. Is there any way that you guys can think of to implement
an inexpensive circuit to bring the power to 0V QUICKLY after power is
disconnected so that you can QUICKLY power back up instead of waiting for
the PIC to drain your power supply caps?
You've probably heard it before, but I'll say it again:
The best single book on electronics (as practiced by folks
like us) is The Art of Electronics, by Paul Horowitz
and Winfield Hill. I've read a lot of books on electronics
and designed a lot of products, and this covers most
everything in enough detail to get you going.
The Art of Electronics
Horowitz & Hill
Cambridge University Press
ISBN 0-521-37095-7
This book begins with "What's a resistor", progresses through
capacitors and inductors, transistors, ICs, etc......and by
the end there's state machines, CPUs, micropower design, sensor
interfacing and the like. There's a bare minimum of heavy math,
replaced instead by good *intuitive* descriptions of what the
parts are doing. It even covers power-on-reset circuits! :-)
GO to the bookstore.
BUY the book.
SET it on the toilet tank.
READ a chapter on each visit.
You'll be an electronics guru in thirty days. Or maybe less,
depending on your diet. :-)
> GO to the bookstore.
> BUY the book.
> SET it on the toilet tank.
> READ a chapter on each visit.
>
> You'll be an electronics guru in thirty days. Or maybe less,
> depending on your diet. :-)
> I am using a PIC 16C57 and I am looking for an elegant way to
>handle page switching. I am using a software stack as well and the two
>(page switching and s/w stack) are proving to be somewhat tedious.
The file "demo.zip" which can be found most places that "aspic.zip" is
found, has a set of macros to aid in bank management. These are in
PICMACRO.ASM. While the version of the macros in this file may not have
been fully tested in a '57 design (the pocket logic analyzer that it is the
source code for was a 16c71 design), I use these macros in all of my PIC
designs including '57.
They are (of course) written for ASPIC, but they should give you some
clues. Beware that ASPIC performs some functions to aid in bank tracking,
although fully automatic bank management is only perfomed with 16cXX core
parts as there are side effects when bank switching on 5X parts.
>I am using the Parallax assembler so I don't have macro capability.
> Does anyone know of an elegant way to make the paging transparent?
I will resist being so bold and/or self-serving as to suggest a solution to
this delema.
>>Sooo, I'm wondering if Parallax will sell the
>>compiler they designed seperately (cheap!!?!)
>
>For about $50, they'll sell you their assembler, simulator, and "PIC
>Applications Notes" book. These days, that passes for "cheap".
>
>Ran
Are these tools just for the PIC chip or for their BASIC STAMP ?
What software is available for the Basic Stamp at all ?
Kind regards, Volkmar
Volkmar Gross, Softwork Telematica, Bremen, Germany (Fone&Phax: +49 421 74434)
>>>-----------------------------------------------------------------------------
>
Das Plank'sche Wirkungsquantum ist der Heizwert eines Baud (Max Demon)
>>>-----------------------------------------------------------------------------
>
=*= Error: Keyboard not connected - Press F1 to continue =*=
> Weeellll, the PIC technical group would be a far cry from ba.personals, in
> terms of justification and public merit. But please, Ran, tell us about
> what you saw, and what you know about starting newsgroups. Is it different
> on different branches of the tree? I've heard alt. is very easy, while
> other branches are more difficult.
I am not Ran, but since I can answer this question I'll answer it anyway:
+ Creation of a newsgroup in alt is quite easy, but there is no guarantee
that sites will carry it. Individual news maintainers will decide whether
to carry the group. Some sites don't carry any alt groups.
+ Creation of a newsgroup in "the big seven" (among which sci and comp)
is harder:
Required is a Request For Discussion posted in the moderated newsgroup
news.announce.newgroups, followed by at least 21 days of discussion in
news.groups, followed by a Call For Votes in news.announce.newgroups.
This takes at least 42 days (make it two months, with Christmas).
Also required is a sufficient number of YES votes (roughly 100 more YES
than no votes, and at least 2/3 YES votes).
Are there already that many people who would even vote on the proposal?
See the documents in news.answers (or was it news.announce.newgroups?)
for details.
Some questions that will have to be answered in the process is why
the current newsgroups (like for example sci.electronics) could not
handle the PIC related posts by using a '[PIC]' tag on all PIC-related
posts and a reader with killfile capability, and why a mailing list would
not be appropriate.
If the discussion and the voting went well, then there is a fair chance
that news maintainers will carry the new group. No guarantees though.
>
> - JohnR
I am afraid I contributed to the organizational noise here, but in the
hope that this noise will disappear.
--
Sincerely yours,
In case y'all missed the latest CC Ink and parallax's add, there are
now two new version of the basic stamp:
1) smaller: A version using surface mount components, packaged on a
14 pin SIP board. Looks about 1.5x.5 inches, including leads.
otherwise, appears to be equivilent to the current stamp. $29.
2) bigger: Using a larger PIC, but still in surface mount, this version
provides 16 IO lines, and 2K bytes for your basic program ("600
instructions" vs "100 instructions" in the old stamp.) Packaged
on a circuit board that fits in a 24pin DIP socket.
In response to several questions about Muscle Wires I have
forwarded a copy of the latest FAQ file from Mondotronics, the company
that makes them. Roger Gilbertson, the president, makes his e-mail
address available for other questions. It is in the FAQ.
Thank you for your interest in our Muscle Wires(R) products. Here's our
latest Muscle Wires Frequently Asked Questions file. We also have a product
flyer as a separate email file. Please request it from us if you have not
received it already.
If you provide us with your postal address we will send you our printed
version (with photos) and keep you informed with future mailings.
Thanks again for your interest!
Roger G. Gilbertson
President
/\ /\ /\
//\\//\\//\\ Mondo-tronics, Inc. Phone 415-455-9330
///// // // ///// 524 San Anselmo Ave #107-20 Fax 415-455-9333
\\//\\//\\// San Anselmo, CA 94960 email spamBeGoneinfomondo.com
\/ \/ \/ USA Order Line 800-374-5764
A: Muscle Wires are thin, highly processed strands of a nickel-titanium
alloy called nitinol - a type of Shape Memory Alloy that can assume
radically different forms or "phases" at distinct temperatures.
Q: How do Muscle Wires work?
A: At room temperature Muscle Wires are easily stretched by a small force.
However, when conducting an electric current, the wire heats and changes to
a much harder form that returns to the "unstretched" shape - the wire
shortens in length with a usable amount of force.
Q: How much do Muscle Wires shorten?
A: Muscle Wires can be stretched by up to eight percent of their length and
will recover fully, but only for a few cycles. However when used in the
three to five percent range, Muscle Wires can run for millions of cycles
with very consistent and reliable performance.
Q: How strong are Muscle Wires?
A: Large wires are stronger than small ones, and strength varies with
diameter. The strength to expect from a wire when heated is shown by the
Recovery Weight in the table below.
The Deformation Weight indicates the amount needed to stretch a wire when
cool - about one sixth the force exerted when the wire is heated. Our
largest wire has over 45 times the strength of the smallest size, so you
can easily match wire strength to your needs.
Q: What if I need more strength?
A: For more strength, use two or more wires in parallel. This gives you as
much strength as needed, and still keeps the fast cycle times of smaller
wires.
Q: How fast can Muscle Wires activate?
A: Muscle Wires contract as fast as they are heated - in one thousandth of
a second or less. To relax, the wire must be cooled, which depends on the
conditions surrounding the wire, and its size. Our new Flexinol HT series
of wires has a higher transition temperature and cools up to 50% faster
than the LT wires. The table below gives typical cycle rates for both LT
and HT wires in still air. Moving air or immersing the wires in a fluid
like a water/glycerine mixture can increase these by ten times or more.
Q: How much power do Muscle Wires use?
A: The power needed to activate a wire depends on its diameter, length, and
the surrounding conditions. The table below gives typical current levels
for "room temperature" conditions. Power can be increased, but once the
wire has fully shortened, power should be reduced to prevent overheating.
-----------------------------------------------------------------
Table 1. Flexinol Muscle Wire Properties
-----------------------------------------------------------------
Wire Linear Typical Deform. Recovery Typical
Wire Diameter Resist. Current Weight* Weight* Rate**
Name (microns) (ohm/m) (mA) (grams) (grams) (LT/HT)
-----------------------------------------------------------------
Flexinol 037 37 860 30 4 20 52/68
Flexinol 050 50 510 50 8 35 46/67
Flexinol 100 100 150 180 28 150 33/50
Flexinol 150 150 50 400 62 330 20/30
Flexinol 250 250 20 1,000 172 930 9/13
-----------------------------------------------------------------
* Multiply by 0.0098 to get force in Newtons
** Cycles per minute, in still air, at 20 Centigrade
LT = low temp 70 degrees C, HT high temp 90 degrees C
-----------------------------------------------------------------
Q: How long do Muscle Wires last?
A: When used in the three to five percent range under proper conditions
Muscle Wires can run for millions of cycles. Often, other parts of a device
will fail or need adjusting long before the Muscle Wire does.
Q: What are the advantages of Muscle Wires?
A: Compared to motors or solenoids, Muscle Wires have many advantages:
small size, light weight, low power, a very high strength-to-weight ratio,
precise control, AC or DC activation, low magnetism, long life, and direct
linear action.
These features let you create whole categories of amazing new devices that
would be difficult or impossible with anything other than Muscle Wires.
Q: What are the keys to using Muscle Wires?
A: For longest lifetimes and best performance from your Muscle Wire
devices, follow these key points:
* Have good electrical & mechanical connections.
* Protect the wire from overheating.
* Protect the wire from overstraining.
Each of these can be accomplished in many different ways. These topics and
more are covered in detail our new 128 page "Muscle Wires Project Book".
For more on this book and all our other products, see our Muscle Wires
Products flyer. Please request it if you have not received it already, and
contact us with any further questions you may have. Thanks again!
/\ /\ /\
//\\//\\//\\ Mondo-tronics, Inc. Phone 415-455-9330
///// // // ///// 524 San Anselmo Ave #107-20 Fax 415-455-9333
\\//\\//\\// San Anselmo, CA 94960 email spam_OUTinfoSTOPspammondo.com
\/ \/ \/ USA Order Line 800-374-5764
======================================================================
Legal. (C)1994 Mondo-tronics, Inc. Muscle Wires is a registered
trademark of Mondo-tronics, Inc. so please use it with the
M and the W capitalized. Eat your vegetables. :(*)
> I'm building a hard disk based audio recorder.
> Yes, it's a mad idea, but there you go.
>
> Trouble is, recording at 16bit, 48kHz, 25MHz clock, I get about
> 32 instructions per byte (4 bytes per stereo sample).
> Now does anyone know how to control a hard disk (80Mb) from a 17C42?
> I have an IDE card, should I use it?
> (I assume it would be easier that way)
> In that case, does anyone have the pinout and spec for the IDE bus?
>
> Bryan
>
> --
> ---------------------------------
> BRYAN CROTAZ - RemoveMEb.crotazspamic.ac.uk
> ---------------------------------
> TECHNICAL MANAGER
> Student Television Of Imperial College
> Beit Quad, Prince Consort Road
> London SW7 2BB
> Tel. 0171-594-8104
> Fax. 0171-594-8065 Attn. STOIC { NOTE NEW FAX NUMBER }
I found that IDE sucks, although it is fairly simple to connect to. I
have recently thrown together a CCD based scanner with a SCSI port and
connects to a MAC portable. The CCD output is scanned into FIFO for
speed and then sent as blocks of 512 byte via the SCSI interface. The
programming is simple. For a good example get the files 'DAQ3000.ASM,
SCSIFAST.ASM and SCSIMOVE.PAS' from the CCInk BBS. These are very
good examples of SCSI code for data transfer. To get these files
send the file names as follows to 'TakeThisOuTftpmailspamRemoveMEcircellar.com',
'GET filename'
This method has allowed me to create a more universal interface for
data acquisition. I hope that this is of help.
> > 1. In a file TUTOR.ASM, constants are preceded by a period e.g.
> >
> > movlw .5
> > moves a value of 5 to w. What is the period for?
>
> '.' = Decimal
I have thus far only used the Parallax assembler for a 16C57. I am
surprised to see this reference to a fractional number...(0.5 I assume).
Does this really refer to the value of 0.5? How is this stored in
the w register???
> > > 1. In a file TUTOR.ASM, constants are preceded by a period e.g.
> > >
> > > movlw .5
> > > moves a value of 5 to w. What is the period for?
> >
> > '.' = Decimal
>
> I have thus far only used the Parallax assembler for a 16C57. I am
> surprised to see this reference to a fractional number...(0.5 I assume).
> Does this really refer to the value of 0.5? How is this stored in
> the w register???
>
> Thanks,
>
> Martin Kirk
> EraseMEmlkSTOPspamRemoveMEasu.edu
>
It represent decimals 5, not a half. Just a method of distinguishing
between hex, octal and decimal.
-Alasdair
[ The opinions expressed are my own and are therefore undeniably correct ]
[ beyond a shadow of a doubt. ]
>Fellow PIC users,
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
>which contract when heated. I believe that I will use alternating
>current to heat the wires so that I don't have to regulate the all that
>power just for heating wires.
>
> 1) Would someone suggest an efficient way to switch A/C power using
>PIC outputs.
Hi Martin,
I don't know about your power/space/money limits, but there are a few
optocouplers capable of AC-switching, with integrated zero-crossing
detection.
>
> 2) I have been looking into using a triac but I have little
>experience with them and I am not sure just how they work. Does a triac
>switch on and off with it's control or does it stay triggered as long as
>the A/C power is applied?
Not that easy. I'm no expert either, but a Triac will stay conducting
unless the next zero crossing of the AC (control removed). You might apply
a continouus trigger signal to the triac, but some of them don't like it if
they are triggered at the wrong time with respect to the AC phase (don't
ask me about that - that's about all I know). In addition, triggering away
from the zero crossing will (might, if you are lucky) produce HF
distortions, which might interfere with the rest of your equipment.
I seem to remember a device which allow one to apply some
percentage of the AC waveform similar to pulse width modulation. That
is:
full power = full waveform
half power = 180 degrees of waveform
X% power = appropriate % of the waveform
>A quick follow on question,
>
> I seem to remember a device which allow one to apply some
>percentage of the AC waveform similar to pulse width modulation. That
>is:
> full power = full waveform
> half power = 180 degrees of waveform
> X% power = appropriate % of the waveform
>
>I do not remember what that device is. Any help?
I don't know the correct English name, but you find that in (most)
so-called dimmers for lamps. It's basically a triac, a
zero-crossing-detector, and some sort of delay device (might all boil down
to a RC and a trigger diode). If you want to use it with a PIC, you'll have
to detect the time of the zero-crosing of your AC, wait
(1 - X%) * (1/ACfrequency), and then trigger your triac (or opto-coupler
*without* zero-crossing detector) (basically).
>
>Thanks Markus for your quick reply.
You're welcome. Any distraction appreciated (at that moment :-) )
Using AC (triac method )to control the nitinol wires is possible. But I strongly
suggest that you use zero crossing opto isolators to do the switching. Check
out Digi Key for a selection of solid state relays. Everything you need for AC
switching in one package. A lot of the relays are TTL compatible.
The other scheme that you were refering to in your second post was using SCR,s
in a bridge configuration. This scheme is even more diffcult to emplement than
PWM.
You could try the SGS Thompson L298n this is a TTL compatible Dual H-Bridge
capable of 1.5 amps per bridge. Standard chip used to drive Electro Magnets
Steppers etc.. I believe that Texas Instr. makes this chip also.
> 1) Would someone suggest an efficient way to switch A/C power using
>PIC outputs.
>
> 2) I have been looking into using a triac but I have little
>experience with them and I am not sure just how they work. Does a triac
>switch on and off with it's control or does it stay triggered as long as
>the A/C power is applied?
>
>Thanks all,
>>A quick follow on question,
>>
>> I seem to remember a device which allow one to apply some
>>percentage of the AC waveform similar to pulse width modulation. That
>>is:
>> full power = full waveform
>> half power = 180 degrees of waveform
>> X% power = appropriate % of the waveform
>>
>>I do not remember what that device is. Any help?
Joseph D. West
Electronics Lab. Supervisor
College of Mechanical Eng.
Ohio State University
I am using a 16C57 in a project driving nitinol "muscle wires"
which contract when heated. I believe that I will use alternating
current to heat the wires so that I don't have to regulate the all that
power just for heating wires.
1) Would someone suggest an efficient way to switch A/C power using
PIC outputs.
2) I have been looking into using a triac but I have little
experience with them and I am not sure just how they work. Does a triac
switch on and off with it's control or does it stay triggered as long as
the A/C power is applied?
A triac will switch on when a gate signal is applied and if there's enough
forward current through the device, it will continue to conduct until voltage
across the main terminals drops to zero (ie. there won't be enough holding
current to maintain the conduction state.)
Martin, I'll assume you need to have a continuously variable capability when
driving the wires, so this implies using AC phase control rather than the
zero-crossing circuits which have binary capability only, if you're not going
to get too complicated.
Motorola has a pair of devices, TDA 1085/1185 which provide all the functions
to drive triacs for phase control. The input is a continuously variable
voltage, so you'll have to generate that somehow by the PIC, which, if I'm
correct, doesn't have a DAC. Maybe you could get PIC to generate a PWM signal
which could be averaged with appropriate signal conditioning, shouldn't be
hard, and apply this to the triac controller. Any fuzzy stuff in my message
should be cleared up with a quick look at the data and application sheets.
>
>Martin Kirk writes:
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
> which contract when heated. I believe that I will use alternating
> current to heat the wires so that I don't have to regulate the all that
> power just for heating wires.
>
> 1) Would someone suggest an efficient way to switch A/C power using
> PIC outputs.
>
> 2) I have been looking into using a triac but I have little
> experience with them and I am not sure just how they work. Does a triac
> switch on and off with it's control or does it stay triggered as long as
> the A/C power is applied?
>
Using pulse width modulation at the pic output to trigger the triac may result
in beating or heterodyning of the pwm with the A/C. This could result in
unpredictable varying currents through the triac.
To fix this, The PIC's clock could be locked in phase with the A/C, with a
PLL. Or A/C zero crossings sensed with an input port, and a time delay,
based on the desired output current, choosen to trigger the triac (or SCR)
and vary its conduction period.
>
>Martin Kirk writes:
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
> which contract when heated. I believe that I will use alternating
> current to heat the wires so that I don't have to regulate the all that
> power just for heating wires.
>
> 1) Would someone suggest an efficient way to switch A/C power using
> PIC outputs.
>
> 2) I have been looking into using a triac but I have little
> experience with them and I am not sure just how they work. Does a triac
> switch on and off with it's control or does it stay triggered as long as
> the A/C power is applied?
>
Using pulse width modulation at the pic output to trigger the triac may result
in beating or heterodyning of the pwm with the A/C. This could result in
unpredictable varying currents through the triac.
To fix this, The PIC's clock could be locked in phase with the A/C, with a
PLL. Or A/C zero crossings sensed with an input port, and a time delay,
based on the desired output current, choosen to trigger the triac (or SCR)
and vary its conduction period.
>Martin Kirk writes:
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
> which contract when heated. I believe that I will use alternating
> current to heat the wires so that I don't have to regulate the all that
> power just for heating wires.
Hmm. Just because you are using DC doesn't mean you have to "regulate all
that power". Just rectify and filter (perhaps only a little) your
transformer output (you probably need the transformer anyway!), and use
the unregulated DC as the "high side" of your nitinol driver supply. You
standard high-current drivers, or even ordinary transistors to tie the
other end of the nitinol to "ground" - All the "driver" ICs can handle
voltages above the "supply voltage" on the output pins without problems.
All the messages about messing with AC makes me think this would be a
much easier way to go - once you have DC, you can easilly PWM the driver
pins to get variable amounts of heating...
>Martin Kirk writes:
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
> which contract when heated. I believe that I will use alternating
> current to heat the wires so that I don't have to regulate the all that
> power just for heating wires.
Hmm. Just because you are using DC doesn't mean you have to "regulate all
that power". Just rectify and filter (perhaps only a little) your
transformer output (you probably need the transformer anyway!), and use
the unregulated DC as the "high side" of your nitinol driver supply. You
standard high-current drivers, or even ordinary transistors to tie the
other end of the nitinol to "ground" - All the "driver" ICs can handle
voltages above the "supply voltage" on the output pins without problems.
All the messages about messing with AC makes me think this would be a
much easier way to go - once you have DC, you can easilly PWM the driver
pins to get variable amounts of heating...
Concerning the "." as a decimal indicator and "0x" for hex, neither of these
are in my MPASM manual. The manual gives "D" for decimal, "X" for hex. My
manual, on the other hand, gives a (very brief) explanation of the IP
command in MPSIM. Previous corresponence on this list suggested that
this was a mystery command.
On the whole, I don't find the manuals to be very well written.
Concerning the "." as a decimal indicator and "0x" for hex, neither of these
are in my MPASM manual. The manual gives "D" for decimal, "X" for hex. My
manual, on the other hand, gives a (very brief) explanation of the IP
command in MPSIM. Previous corresponence on this list suggested that
this was a mystery command.
On the whole, I don't find the manuals to be very well written.
The other day I was looking through some old Scientific American magazines.
The September 1977 issue (special issue on Microelectronics) has a full-page
ad from General Instrument Corporation advertising a range of microcontrollers
including several PICs. This confirmed what I had been told by others - that
Arizona Microchip acquired the PIC design from GI.
Does anyone know the full story? How old is the PIC architecture? What happened
to GI?
Microcontrollers featured in the ad include:
PIC1655 "For music" with a picture of a record-player
PIC1650 "For applicances" with picture of a microwave oven
PIC1670 "For 'anything'" with picture of digital scales & cash register
I've got a 1982 GI databook that describes the PIC1655, of course at that
time you could only get them with Masked ROMs (no EPROM and definitely
no EEPROM).
> I am trying to develop a code hopper alarm remote control system using the
> PIC16C54 or PIC16C56 micro.
>
> Is there anybody else doing the same or who can help at all?
>
I offer the following for comments;
One way of producing a code hopper is as follows:-
1) Both transmitter and receiver contain an identical
(psuedo) random number generator, and at installation they are put
in sync i.e. both know what the last number was (have a learn mode
on the rx, fire off the tx, presto there in sync).
2) Have the rx respond to the NEXT (x) random numbers i.e.
rx a code
try and match to next rand
if fails try again (x) times
This would be the rx window and needs to be large enough (contain
sufficient tries) to account for accidental activation of the tx
when out of range of the rx, as this would otherwise put the two out
of sync.
3) on the tx each activation causes the next random number to be used
on the rx each successful match causes the next random number to be
used.
This way once a code has been used it will not be repeated for the
maximum iterations of the random number generator. any 'replay' device
would fail because it would simply play back a code that was not within
the match window.
Use the E2prom pic (16c84) or have an eeprom connected to the pic to
store the last number used (next random seed).
the following is a code segment of an 8 bit psuedo random generator,
this will give 0 to 255 in random order without repeating for 255
iterations, this could be expanded to a 16bit easily.
Each time it is called it requires the last number as the seed for the
next number.
;*******************************************************************************
**
; Code segment by Gary Whittaker 1993, << Pubic Domain >> *
*
; .....garyspam.....advtech.demon.co.uk
**
;-------------------------------------------------------------------------------
**
; l_rand & rand must be defined as variables
**
; CALL this routine for each successive random number
**
;*******************************************************************************
**
;******* next random number routine expects seed (last rand) in l_rand,
;******* returns in next randome number in l_rand
;******* uses a 4 bit xor with rotate left (bits 3,4,5,7)
next_rand MOVF l_rand,w
MOVWF rand ;take a copy (leaving one in w)
BCF rand,.3 ;set up xor bits 3+5
BCF rand,.5
BTFSC rand,.4 ;mov bits 4+7 into 3+5 ready for
BSF rand,.3 ;the xor
BTFSC rand,.7
BSF rand,.5
XORWF rand,w ;xor 3+4,5+7 into 3+5
MOVWF rand
BCF rand,.3 ;clear xor bit 3
BTFSC rand,.5 ;mov bit 5 into 3 ready for xor
BSF rand,.3
XORWF rand,same ;xor 3+5 into 3
BCF status,carry ;set carry to result
BTFSC rand,.3
BSF status,carry
RLF l_rand,same ;rotate next into l_rand
BCF status,carry ;clear carry for safety
RETLW .0
;*******************************************************************************
*
end
__
TAK
> Werner Terreblanche Wrote ;
>
> > I am trying to develop a code hopper alarm remote control system using the
> > PIC16C54 or PIC16C56 micro.
> >
> > Is there anybody else doing the same or who can help at all?
> >
> I offer the following for comments;
>
> One way of producing a code hopper is as follows:-
>
> 1) Both transmitter and receiver contain an identical
> (psuedo) random number generator, and at installation they are put
> in sync i.e. both know what the last number was (have a learn mode
> on the rx, fire off the tx, presto there in sync).
>
> 2) Have the rx respond to the NEXT (x) random numbers i.e.
>
> rx a code
> try and match to next rand
> if fails try again (x) times
>
> This would be the rx window and needs to be large enough (contain
> sufficient tries) to account for accidental activation of the tx
> when out of range of the rx, as this would otherwise put the two out
> of sync.
>
> 3) on the tx each activation causes the next random number to be used
> on the rx each successful match causes the next random number to be
> used.
Hmmmm..... I press my car-alarm transmitter a lot when walking down the
street (just for scientific purposes, of course :-) and I suspect that I may
have some sort of code-hopping system since the installer had to have both
transmitters when he installed the receiver (I think).
Michael Bender wrote (regarding code-hopping remote controls):
> Hmmmm..... I press my car-alarm transmitter a lot when walking down the
> street (just for scientific purposes, of course :-) and I suspect that I may
> have some sort of code-hopping system since the installer had to have both
> transmitters when he installed the receiver (I think).
Typically each remote has a unique fixed code, and the reciever has to be
programmed for the remotes. There is usually a switch on the alarm somewhere
to enable programming.
| Michael Bender wrote (regarding code-hopping remote controls):
|
| > Hmmmm..... I press my car-alarm transmitter a lot when walking down the
| > street (just for scientific purposes, of course :-) and I suspect that I may
| > have some sort of code-hopping system since the installer had to have both
| > transmitters when he installed the receiver (I think).
|
| Typically each remote has a unique fixed code, and the reciever has to be
| programmed for the remotes. There is usually a switch on the alarm somewhere
| to enable programming.
What do you think the chances are that one of my remotes could be used
to activate another receiver? I would hope that each receiver and
transmitter from the same company have at least a fixed manufacturer
code, and then a portion of the rest of the code that was variable
based on the matching of the two units.
>
> What do you think the chances are that one of my remotes could be used
> to activate another receiver? I would hope that each receiver and
> transmitter from the same company have at least a fixed manufacturer
> code, and then a portion of the rest of the code that was variable
> based on the matching of the two units.
>
> mike
>
Some manufacturers of remote controllers use encoder IC's entented for
simple remote control applications and not for high security environments.
These devices typically send only about 12 bits and that's it!
I once made a device that could read the code transmitted by the Tx and then
retransmit that same code at a later time (Using a PIC by the way!) This
device could easily be used by thief to for example open a car with central
lock. That is why I am interested in developing a code hopping system.
I no longer seem to be receiving the PIC mail. The automatic response
from the listserver tells me that I am still registered on the PIC list.
Can anyone tell me how to go about getting the flow of mail turned on
again?
With all the discussions dealing with an RS-232 interface, has anyone ever
done a current loop comm line using RS-422 or RS-485 as the medium ?
The hardware is the easy part - Maxim also makes chips for this. Is the serial
stream from the source the same format as RS-232 - I would guess not.
FYI, RS422 is used in industrial applications for multidrop type connections -
such as several controllers all one a single comm line, each with its own
address to decode, but not point to point as RS-232 is.
:wq
Just like RS232, RS422 & RS485 specify: voltage
levels, driver type (single ended,differential)
connector type and pinout, and signal conventions.
They do _not_ specify protocol. You can run standard
Async. on any of these. The sender and receiver just
need to talk/listen in the same language (protocol).
The overhead for multidrop can be done with hardware
or it could be done in a PIC application just using
the PIC. I have worked on a project where we used
RS485 & Std Async. It was 80C186 based, not PIC.
>
> Just like RS232, RS422 & RS485 specify: voltage
> levels, driver type (single ended,differential)
> connector type and pinout, and signal conventions.
> They do _not_ specify protocol. You can run standard
> Async. on any of these. The sender and receiver just
> need to talk/listen in the same language (protocol).
> The overhead for multidrop can be done with hardware
> or it could be done in a PIC application just using
> the PIC. I have worked on a project where we used
> RS485 & Std Async. It was 80C186 based, not PIC.
>
> Brian Read
>
> Some manufacturers of remote controllers use encoder IC's entented for
> simple remote control applications and not for high security environments.
> These devices typically send only about 12 bits and that's it!
This is the way my Ungo transmitter is made. It has a 144049 buffer
with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
and that is connected to a 145026 encoder which transmits nine bits.
Wouldn't be that hard for a thief with a little ee knowledge to hook a
PIC up to it and cycle thru the possible combinations...
>
> I once made a device that could read the code transmitted by the Tx and then
> retransmit that same code at a later time (Using a PIC by the way!) This
> device could easily be used by thief to for example open a car with central
> lock. That is why I am interested in developing a code hopping system.
You might also want to look into one way encryption ciphers(hash
tables) there was a discussion on the cypherpunks mailing list several
months back about using one way functions in security applications.
Brian
------------------------------------------------------------------------------
"Everyone is a prisoner holding their own key." | finger @spam@blanespamKILLspamseanet.com
-- Journey | PGP 2.6 email accepted
------------------------------------------------------------------------------
>
> How does one do multidrop? I assume that the pic has tri-state...
> How do you do addressing without extra lines?
With RS-485 one would use a RS-485 transceiver which have separate XMIT
and receive pins, or you could share. Two pin support is possible.
With multidrop you go to a 9 bit protocol. The ninth bit indicates if the
data is a address or data. UARTS with multidrop hardware support can be
set to listen for a particular address and ignore all other bytes. In this
mode all the receivers will wait for an address packet. When one is received
each will check against their own address. All negative matches will result
in the UART going back into address only mode. The one (or more) that matches
switch the UART to receive the data. PICS of course be programmed to emulate
this behavior but they'll have to eat the overhead of reading rach byte.
Hope this helps,
BTW I wanted everyone to know that I finally got David Tait's PIC 16C84
programmer to funtion properly under Linux. Thanks for all the suggestions.
>>
>> What do you think the chances are that one of my remotes could be used
>> to activate another receiver? I would hope that each receiver and
>> transmitter from the same company have at least a fixed manufacturer
>> code, and then a portion of the rest of the code that was variable
>> based on the matching of the two units.
>>
>> mike
>>
>
>Some manufacturers of remote controllers use encoder IC's entented for
>simple remote control applications and not for high security environments.
>These devices typically send only about 12 bits and that's it!
>
>Werner
FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
combinations, but the base and the remote only have eight DIP switches in
them for setting your code. When I called them up and said, "Hey, where are
these gizillions of codes?" all they would say was, "It's in dere".
Are they saying the R/T have fixed code prefixes inside? Would they
distribute matching sets to the same areas? That would be bad. Who's to
say they don't do this?
Multi-drop is kind of like I2C, everybody listens
for traffic addressed to them, then takes control of
the buss for their needs, when done the buss is released.
You can have several different approaches but the simplest
is to do it just like I2C (but without the clocking from the
iaster).
> How does one do multidrop? I assume that the pic has tri-state...
> How do you do addressing without extra lines?
>
> -mike
Well if your question is how do the chips know when they are the
addressee of a message, it is easy. They listen to all of the packets
and either throw away those that aren't too them, or they only listen
until the address deviates from theirs and they just ignore the rest of
the packet. Multidrop communication can be done with nothing more than
using pull-up resistors, sortof like the I2C app note in the PIC
embedded controller book.
> FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
> combinations, but the base and the remote only have eight DIP switches in
> them for setting your code. When I called them up and said, "Hey, where are
> these gizillions of codes?" all they would say was, "It's in dere".
>
> Are they saying the R/T have fixed code prefixes inside? Would they
> distribute matching sets to the same areas? That would be bad. Who's to
> say they don't do this?
>
> Anyone have any hard information on this?
>
> - JohnR
>
Even if they do have longer codes than just the eight bits, the code could
still be sampled by a fast microprocessor in much the same manner as the
multiple IR remote control devices work which "learns" a code. Unless the
code is different every time you press the button, there will be an easy
option to decipher the code. I have experimented with this and it is
definetely possible.
>
> On Fri, 16 Dec 1994, Werner Terreblance wrote:
>
> > Some manufacturers of remote controllers use encoder IC's entented for
> > simple remote control applications and not for high security environments.
> > These devices typically send only about 12 bits and that's it!
>
> This is the way my Ungo transmitter is made. It has a 144049 buffer
> with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
> and that is connected to a 145026 encoder which transmits nine bits.
>
> Wouldn't be that hard for a thief with a little ee knowledge to hook a
> PIC up to it and cycle thru the possible combinations...
>
There's an ad in the latest Nuts & Volts magazine for just such a device.
Of course, only lock smiths and car repossesion professionals ;-) can
buy them. It claims that in a mere 10 minutes, 90% of all car alarms
on the market can be "silenced".
Perhaps there *is* money for EE's on "the dark side".
> >
> John R. Haggis wrote:
>
> > Are they saying the R/T have fixed code prefixes inside? Would they
> > distribute matching sets to the same areas? That would be bad. Who's to
> > say they don't do this?
> >
> > Anyone have any hard information on this?
Batching sets to an area would be uneconomical given the sales rates of alarms.
There are at least half a dozen different coding chips on the market, each uses
a slightly different way of producing the code.
_Most_ of them use at least 12 bit code.
A couple of Motorola devices use 3-way sensing on the inputs
i.e. pos, neg, or floating input gives a code differ.
Thats 12 x 3 x,,, er, who's got a calculator ? :)
Now if you did it with a PIC, you could have 8 bits user selected and a couple
of locs. with random nos pre-programmed. Mix and match before transmitting and
have the decode routine learn it's relevant Tx code. That gives you 24 bit code
with one 8 way dil-switch. Then transmit the code twice, the second time
inverted and code samplers will just fall over.
Then Werner wrote ;
> >
>
> Even if they do have longer codes than just the eight bits, the code could
> still be sampled by a fast microprocessor in much the same manner as the
> multiple IR remote control devices work which "learns" a code. Unless the
> code is different every time you press the button, there will be an easy
> option to decipher the code. I have experimented with this and it is
> definetely possible.
Possible, but an unrealistic time-scale. The micro does'nt have to be fast BTW
'cos the code is not transmitted all that fast, a PIC running at 8 Meg would
still take, from memory over 3 hours to cycle.
__
TAK
I've heard a lot of talk about PIC programmers, and just wanted to let you know
that we offer our programmer in a "Hobbyist Pack" configuration. You have to
supply the cables and power supply, and you have to print the docs. But, you
get an assembled and tested programmer, and you get the necessary assembler and
simulator software. At half the normal price, we've had a lot of takers lately.
To use the Hobbyist Pack programmer, you'll need a PC with a parallel port.
You'll also need Windows, if you want to print the PDF-format docs.
At this time, the programmer supports the 16C5x, 16C71, and 16C84. With an
optional 40-pin adapter (which you can buy or build), it also supports the
16C64 and 16C74.
------------------------ Lance Walley ---------------------------
President
Parallax, Inc.
I am always pleased to have representatives from various industry-related
companies on the PIC list. I also appreciate when these representatives
give cogent, pertinent answers to specific questions about their products
(the various folks at Microchip, and Don Lekei being two excellent
examples).
However, I was a little concerned that the post quoted below (from Lance
Walley of *Parallax*) might be crossing the line into inappropriate
commercial promotion. It is certainly on the reasonable side of commercial
posts (vaguely on topic, not too long, posted by a list member, etc.).
Nonetheless, it is essentially an unsolicited, unpaid advertisement (and
just in time for the Christmas rush ;)
To my mind, it is a rough call, since I want to retain the knowledge of
someone like Lance, without subjecting the PIC list to a stream of junk
mail.
How do other people feel about this? Did the discussion of David Tait's
programmer warrant the (admittedly brief) mention/promotion of the Parallax
Hobbyist Pack? Do members of the list want a more explicit policy on
commercial/industry postings (heck, maybe everyone else likes advertising
in this context). At this time, we have no explicit policy, and Lance was
certainly within his rights (which might differ from netiquette... but
violation of netiquette is not yet officially punishable on this forum ;)
I am not trying to give Lance too hard a time. Istead, I would use his post
as a jumping point to proactively deal with this issue (an issue which I
think we will continue to see as more suppliers get hooked to the net,
possibly viewing the PIC list as a great way to hit a tasty well-targeted
market for essentially free.)
ps: I got a note from someone in digest mode who had not received a digest
for a few days. If someone who is in digest mode could drop me a private
email if they are still getting their digests, I could tell if it is a
problem specific to the one acount or something more general. thanks.
>Hi, guys (and gals)...
>
>I've heard a lot of talk about PIC programmers, and just wanted to let you know
>that we offer our programmer in a "Hobbyist Pack" configuration. You have to
>supply the cables and power supply, and you have to print the docs. But, you
>get an assembled and tested programmer, and you get the necessary assembler and
>simulator software. At half the normal price, we've had a lot of takers
>lately.
>
>To use the Hobbyist Pack programmer, you'll need a PC with a parallel port.
>You'll also need Windows, if you want to print the PDF-format docs.
>
>At this time, the programmer supports the 16C5x, 16C71, and 16C84. With an
>optional 40-pin adapter (which you can buy or build), it also supports the
>16C64 and 16C74.
>
>
>------------------------ Lance Walley ---------------------------
> President
> Parallax, Inc.
I certainly had no objection to the "ad", nor do I have any objection
to "ads" running in the future. I suspect that my opinion is currently
tempered by the fact that Parallax builds and sells some pretty good
stuff. I also suspect my opininon in the future may well depend on how
many "ads" start appearing.
With that in mind, a rigidly enforced policy that ads have a one word subject
.. ADVERTISEMENT .. may solve the problem.
Alan
--
Alan Rothenbush | There must be an ideal world, a sort of
Academic Computing Services | mathematicians's paradise, where everything
Simon Fraser University | happens as it does in textbooks.
Burnaby, B.C., Canada | Bertrand Russell
I'm sorry that you had some problems with the Hobbyist Pack. It's our first
attempt at a product with on-disk docs., and we're learning. We tried it on
several PCs, but they must have already had ATM installed. As for the phone
cable, we updated the docs to make this a bit clearer (we state that the
customer should use a twisted cable); we also suggest that customers use a
cable that's meant for a phone, and we mention the grocery store or Radio
Shack as a source. Anyway, we'll make whatever changes are necessary, as we
learn more about it.
------------------------ Lance Walley ---------------------------
President
Parallax, Inc.
I'm game to receive things like the note from Parallax on the
DISCOUNTED, hobby class unit. Just like I don't mind hearing about
TI DSK kits, DS750, motorola hc11 promos etc., these are designed
to give deep discounts to folks like us in the hobby area to
hopefully get us started using a particular product / technology.
I would NOT go for any announcements in a group like this for
Standard Commercial List Price offers. Not that there shouldn't
be a forum for such things, but not here.
I think all my above examples qualify - the TI DSK only has
one price, LIST, but is really not a product for the pro. It's
truly an entry into experimenting at a price for hobbyists; the
standard COMMERCIAL product starts closer to a thou.
I think Parallax's posts so far have been fine, but then I frequently make
quasi-commercial posts to the mailing list most closely involved with my
comany's products. As was said, the Internet IS commercial, these days.
Even in days gone by, it was deemed appropriate for companies to post
technical information of likely interest to the members of the mailing
list. After some discussion, even a few hard-heads were forced to admit
that price is a very important part of technical information these days.
In general, what should be avoided is stuff that looks like advertisments.
Especially self-indulgent, competition-bashing, technical-content free
advertisements (like ours! Or our competitors!) Also to be avoided are
personal vendettas and competition bashing in general. (eg, it would be
OK to send the parallax assemblers list of opcodes and what not, but it
would NOT be OK to repsond to someone's request for help with source code
by starting "first get rid of that piece of crap microchip assembler and
buy ours instead.") (This OUGHT to be obvious, and come under the heading
of "be polite". However, I read plenty of stuff from people who just haven't
gotten the idea.)
I think the "advertisement" in this case was acceptable. It was for a
product related to the mail list; as you point out it was very short;
and, it was not an obnoxious "send xxx before midnight tonight and
get ghinsu steak knives..." type of ad.
The suggestion of placing ADVERTISEMENT in the subject line seems to
be a good one by the way.
Regarding manufacturers reps, etc. participating in the list all I
would recommend is that they don't use every post to hawk their
products and that the discussions do not ever degenerate to mud
slinging at the competition. A comment such as "product abc will
accomplish what you want by doing thus and so..." is acceptable.
A comment like "well you wouldn't have that problem if you used
our new widget instead of that other brand..." is out of line so
far as I'm concerned.
I'm glad to see the manufacturer or service provider available to answer
questions and provide free advice about their product and/or service. It
wasn't like the obnoxsciouse, unsolicited price list mailed to the world
a week ago.
Being the owner of a Parallax Programmer, I remember reading something
regarding that programmer not exactly following the Microchip programming
process, something about programming voltages maybe? I wonder if that can
effect the long term reliability of a PIC.
Also, does Parallax have their BBS available by ftp? I would like some
toll-free downloads :)
Jory wrote;
> However, I was a little concerned that the post quoted below (from Lance
> Walley of *Parallax*) might be crossing the line into inappropriate
> commercial promotion. It is certainly on the reasonable side of commercial
> posts (vaguely on topic, not too long, posted by a list member, etc.).
> Nonetheless, it is essentially an unsolicited, unpaid advertisement (and
> just in time for the Christmas rush ;)
I'd like to congratulate Lance on <IMHO> managing to walk a *very* fine line
between "a helpful posting" and "crass commercialism" :)
>
> To my mind, it is a rough call, since I want to retain the knowledge of
> someone like Lance, without subjecting the PIC list to a stream of junk
> mail.
>
> How do other people feel about this? Did the discussion of David Tait's
> programmer warrant the (admittedly brief) mention/promotion of the Parallax
> Hobbyist Pack?
Yes, it was <nearly> bang on topic. ;) But too late for Xmas for me ;(
> At this time, we have no explicit policy, and Lance was
> certainly within his rights (which might differ from netiquette... but
> violation of netiquette is not yet officially punishable on this forum ;)
Well, to quote a well known balding Englishman, " Make it so. . "
> I am not trying to give Lance too hard a time. Istead, I would use his post
> as a jumping point to proactively deal with this issue (an issue which I
> think we will continue to see as more suppliers get hooked to the net,
> possibly viewing the PIC list as a great way to hit a tasty well-targeted
> market for essentially free.)
In another Msg. Alan Rothenbush Proposed allowing advertising providing it was
identified as such on the subject: line.
I am *strongly* against this idea. I have to *pay* to download this stuff and I
ain't gonna pay to get junk mail. In fact I rather approved of the way Jory
treated the last "spam" that came our way.
I vote for a version of that to be robo-posted to everyone that joins the list,
then we've got a chance to retire on the profits ;)
Anyone else ?
Oh, BTW. What about the FAQ ?
How close to "advertising" do you want that to be ?
Where do *I* draw the line ?
Yours, Puzzled of Warrington UK ;)
__
TAK
>I'm glad to see the manufacturer or service provider available to answer
>questions and provide free advice about their product and/or service. It
>wasn't like the obnoxsciouse, unsolicited price list mailed to the world
>a week ago.
>
>Being the owner of a Parallax Programmer, I remember reading something
>regarding that programmer not exactly following the Microchip programming
>process, something about programming voltages maybe? I wonder if that can
>effect the long term reliability of a PIC.
>
>Also, does Parallax have their BBS available by ftp? I would like some
>toll-free downloads :)
>
>Scott Stephens
Indeed, our programmer does not follow the programming process exactly. A
"production quality" programmer will program and verify PICs at 4.5 and 5.5
volts. Our programmer simply programs and verifies at 5 volts. However, I
was told the following info: the minimum programming pulse is 11 uS, and
our programmer uses 100 uS pulses; also, a 3X overpulse is performed for
absolute sureness. Many customers use our programmer for production purposes,
and we have never heard of a long-term reliability problem (if it's any
comfort, our programmer is used to program all PICs that are used in our
products, like the Stamp).
Regarding the BBS and ftp, we just got our ftp sight up a few days ago.
Essentially, the BBS files are now available via ftp. In time, the BBS will
actually be "Internetable" itself. For now, the BBS files are simply copied
to our server. I don't think our sysop has made the usual description files,
but most files have self-explanatory names.
------------------------ Lance Walley ---------------------------
Parallax, Inc.
The Parallax post seemed appropriate to me... low key, to the point, and
concerning something aimed at small company/hobbiest types. I'd rather
see you concern yourself with raising the S/N ratio by discouraging some
of the small talk.
> IMHO:
>
> I am always pleased to have representatives from various industry-related
> companies on the PIC list. I also appreciate when these representatives
> give cogent, pertinent answers to specific questions about their products
> (the various folks at Microchip, and Don Lekei being two excellent
> examples).
>
> However, I was a little concerned that the post quoted below (from Lance
> Walley of *Parallax*) might be crossing the line into inappropriate
> commercial promotion. It is certainly on the reasonable side of commercial
> posts (vaguely on topic, not too long, posted by a list member, etc.).
> Nonetheless, it is essentially an unsolicited, unpaid advertisement (and
> just in time for the Christmas rush ;)
>
> To my mind, it is a rough call, since I want to retain the knowledge of
> someone like Lance, without subjecting the PIC list to a stream of junk
> mail.
>
> How do other people feel about this? Did the discussion of David Tait's
> programmer warrant the (admittedly brief) mention/promotion of the Parallax
> Hobbyist Pack? Do members of the list want a more explicit policy on
> commercial/industry postings (heck, maybe everyone else likes advertising
> in this context). At this time, we have no explicit policy, and Lance was
> certainly within his rights (which might differ from netiquette... but
> violation of netiquette is not yet officially punishable on this forum ;)
>
> I am not trying to give Lance too hard a time. Istead, I would use his post
> as a jumping point to proactively deal with this issue (an issue which I
> think we will continue to see as more suppliers get hooked to the net,
> possibly viewing the PIC list as a great way to hit a tasty well-targeted
> market for essentially free.)
>
> jory bell
> jorySTOPspamKILLspammit.edu
>
> ps: I got a note from someone in digest mode who had not received a digest
> for a few days. If someone who is in digest mode could drop me a private
> email if they are still getting their digests, I could tell if it is a
> problem specific to the one acount or something more general. thanks.
>
> >Hi, guys (and gals)...
> >
> >I've heard a lot of talk about PIC programmers, and just wanted to let you
know
> >that we offer our programmer in a "Hobbyist Pack" configuration. You have to
> >supply the cables and power supply, and you have to print the docs. But, you
> >get an assembled and tested programmer, and you get the necessary assembler
and {Quote hidden}
> >simulator software. At half the normal price, we've had a lot of takers
> >lately.
> >
> >To use the Hobbyist Pack programmer, you'll need a PC with a parallel port.
> >You'll also need Windows, if you want to print the PDF-format docs.
> >
> >At this time, the programmer supports the 16C5x, 16C71, and 16C84. With an
> >optional 40-pin adapter (which you can buy or build), it also supports the
> >16C64 and 16C74.
> >
> >
> >------------------------ Lance Walley ---------------------------
> > President
> > Parallax, Inc.
>
I did not consider Lance's post out of place in the context of the
discussion. His post, to me, was merely informative, and not a blatant
commercial announcement. And since it elicited at least one (so
far) review of the product from a user, it may be helpful to the rest of
us in choosing such products in the future.
While the internet does allow free advertising for commercial
enterprises, the advertisers must also accept the immediate feedback,
which is often critical. No other medium gives us that ability.
* Douglas Martin * Design Engr/Elec. Technician * @spam@dmartin.....spambgsuvax.bgsu.edu *
* BGSU Department of Chemistry - Bowling Green, Ohio - USA *
* 'Ticking away the moments that make up a dull day . . .' - Pink Floyd *
***** *****
> IMHO:
>
> I am always pleased to have representatives from various industry-related
> companies on the PIC list. I also appreciate when these representatives
> give cogent, pertinent answers to specific questions about their products
> (the various folks at Microchip, and Don Lekei being two excellent
> examples).
>
> However, I was a little concerned that the post quoted below (from Lance
> Walley of *Parallax*) might be crossing the line into inappropriate
> commercial promotion. It is certainly on the reasonable side of commercial
> posts (vaguely on topic, not too long, posted by a list member, etc.).
> Nonetheless, it is essentially an unsolicited, unpaid advertisement (and
> just in time for the Christmas rush ;)
>
> To my mind, it is a rough call, since I want to retain the knowledge of
> someone like Lance, without subjecting the PIC list to a stream of junk
> mail.
>
> How do other people feel about this? Did the discussion of David Tait's
> programmer warrant the (admittedly brief) mention/promotion of the Parallax
> Hobbyist Pack? Do members of the list want a more explicit policy on
> commercial/industry postings (heck, maybe everyone else likes advertising
> in this context). At this time, we have no explicit policy, and Lance was
> certainly within his rights (which might differ from netiquette... but
> violation of netiquette is not yet officially punishable on this forum ;)
>
> I am not trying to give Lance too hard a time. Istead, I would use his post
> as a jumping point to proactively deal with this issue (an issue which I
> think we will continue to see as more suppliers get hooked to the net,
> possibly viewing the PIC list as a great way to hit a tasty well-targeted
> market for essentially free.)
>
> jory bell
> spamjory..........mit.edu
>
> ps: I got a note from someone in digest mode who had not received a digest
> for a few days. If someone who is in digest mode could drop me a private
> email if they are still getting their digests, I could tell if it is a
> problem specific to the one acount or something more general. thanks.
>
> >Hi, guys (and gals)...
> >
> >I've heard a lot of talk about PIC programmers, and just wanted to let you
know
> >that we offer our programmer in a "Hobbyist Pack" configuration. You have to
> >supply the cables and power supply, and you have to print the docs. But, you
> >get an assembled and tested programmer, and you get the necessary assembler
and {Quote hidden}
> >simulator software. At half the normal price, we've had a lot of takers
> >lately.
> >
> >To use the Hobbyist Pack programmer, you'll need a PC with a parallel port.
> >You'll also need Windows, if you want to print the PDF-format docs.
> >
> >At this time, the programmer supports the 16C5x, 16C71, and 16C84. With an
> >optional 40-pin adapter (which you can buy or build), it also supports the
> >16C64 and 16C74.
> >
> >
> >------------------------ Lance Walley ---------------------------
> > President
> > Parallax, Inc.
Lance Walley <lwalley.....PARALLAXINC.COM> wrote :
>
> Indeed, our programmer does not follow the programming process exactly. A
> "production quality" programmer will program and verify PICs at 4.5 and 5.5
> volts. Our programmer simply programs and verifies at 5 volts. However, I
Does anyone have figures for the failure rate at marginal voltages (i.e.
the proportion of PICs that verify OK at 5v but not at 4.5 or 5.5) ?
I need to build an in-system programmer for the 16c84 and from what
Lance says it may not be worth adding the minor extra complexity of a
programmable supply rail.
>Forwarded message:
>> Every time i try to obtain a copy of MPA10200.ZIP from any of the ftp
>> mirror sites for the Microchip bbs the result is a file with 0 size.
>> The ftp transfer is set for binary and it seems to accept the
>> commands with no problems. Can any one help.
>>
>
>Ths ftp-area at ftp.luth.se is just a mirror of ftp.sics.se, so
>a bad copy at sics will show up at ftp.luth.se too.
>
>By the way, I have now moved from Lulea (Luth) to finish my studies in
>Lund, and the microchip files at ftp.luth.se will probably be
>discarded. If anyone has any comments on why the area at ftp.luth.se
>should exist (ftp.sics.se is also located in Sweden) let me know!
>(don't reply to this mail, but do send comments to KILLspamhedexspam_OUTaxis.se (my
>new email-adress))
>/Anders Hedberg
>
>
What needs to happen pretty soon is that the net community at large
makes some kind of decision before the time to ponder is all used up.
There are two basic objections to advertising, especially on the net
one, they are often unsolicited, otherwise they would be sent to
the intended as e-mail and secondly there is a concensus that people
should not be able to get commercial 'gain' for 'free', this is also
only relevant with regard to the bandwidth that the adverts might
consume.
There is a lot of other traffic that is of no benefit to the majority
but is allowed to fill up the net as it is not ostensibly commercial,
this is things like faqs, binaries, pictures and mostly people over
quoting what others say. (I do not profess to be innocent of all the
above indiscressions) One must also not forget that many of the bits
of information that we list and news users receive in our chosen
work fields are used to finacial gain, they may be so much wasted
bandwidth to others.
Having said all that there seems to be some simple steps that could be
taken. I have little say in the running of these things but what I
propose is probably not new or novel. Rather than have a Flag in the
document there could be a header entry such as 'X-Type : ADVERT' this
would allow people the full use of the system and people or forwarders
who object to seeing or transporting ads would be able to fine tune their
software to delete, not-display, flag, truncate, bounce :-), flame
or ignore the postings if they were there or had a size larger than say
25 lines of content (I hear that the lines tag is not always supported).
If the forwarder wanted to make money it would only forward ads that had
a pre-registered 'Organisation : ...' tag that they had a billing agreement
with.
What the ned does not need/want is to stat dictating what individuals
may or may not do, just how one can identify actions so those individuals
can make their own choices on what to do with them. Ship ads only when
the links are idle perhaps then the corporates will increase the link
speed to make sure their ads get delivered.
The Parallax ad was relatively ok as it was appropriate to the discussion
and would have informed many readers, if those who object had a way
of making the ads vanish and not seeing the ad quoted (another feature of
the X-Type : ADVERT tag and the posting sw) then all would be happy.
Anyone ever used a PIC to decode ethernet packets? Say, you are looking for
a single opcode within the packet that when decoded, allowed the controller
to do something - i.e., the ethernet packet would be decoded to trigger the
controller.
In article: <RemoveME9412100210.aa18243spamBeGonespampunt.demon.co.uk> @spam@ssmithspamcsuvax1.murdoch.edu.au
writes:
> The other day I was looking through some old Scientific American magazines.
> The September 1977 issue (special issue on Microelectronics) has a full-page
> ad from General Instrument Corporation advertising a range of microcontrollers
> including several PICs. This confirmed what I had been told by others - that
> Arizona Microchip acquired the PIC design from GI.
This is more tha just a story...see below.
>
> Does anyone know the full story? How old is the PIC architecture? What happene
d
> to GI?
>
Back in 1965, GI formed a Microelectronics Division, and indeed used
this division to generate some of the earliest viable EPROM and EEPROM
memory architectures. As you may be aware, the GI Microelectronucs
Division were also responsible for a wide variety of digital and analog
functions, in the AY3-xxxx and AY5-xxxx families.
GI also generated a 16 bit microprocessor, called the CP1600, in the
early 70s. This was a reasonable microprocessor, but not particularly
good at handling i/os. For some very specific applications where good
i/o handling was needed, GI designed a Peripheral Interface Controller
(or PIC for short), in around 1975. It was designed to be very fast,
since it was i/o handling for a 16 bit machine, but didn't need a huge
amount of functionality, so its microcoded instruction set was small.
Hopefully, you can see what's coming....yes, the architecture designed
in '75 is substantially the PIC16C5x architecure today. Granted, the
1975 version was manufactured in NMOS, and was only available in masked
ROM versions, but still a good little uC. The market, however, didn't
particularly think so, and the PIC remained designed in at a handful of
large customers only.
During the early 80s, GI took a long hard look at their business, and
restructured, leaving them to concentrate on their core activities,
which is essentially power semiconductors. Indeed they are still doing
this very successfully now. GI Microelectronics Division became GI
Microelectronics Inc (a wholly owned subsidiary), which in 85 was
finally sold to venture capital investors, including the fab in
Chandler, Arizona. The venture capital people
took a long hard look at the products in the business, and got rid of
most of it - all the AY3- and AY5- parts and a whole bunch of other
stuff, leaving the core business of the PIC and the serial and parallel
EEPROMs and the parallel EPROMs. A decision was taken to restart the
new company, named Arizona Microchip Technology, with embedded control
as its differentiator from the rest of the pack.
As part of this strategy, the PIC165x NMOS family was redesigned to use
one of the other things that the fledgling company was good at, i.e.
EPROM - the concept of the CMOS based, OTP and eraseable EPROM program
memory PIC16C5x family was born.
Does this answer your questions?
Alex R. Baker - Field Apps Engineer Ph: +44 628 851077 Car: +44 831 494921
Arizona Microchip Technology Fx: +44 628 850259 Email: TakeThisOuTalexKILLspam@spam@microchp.dem
on.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY E
MPLOYER
On the PIC the DECF instruction doesn't reset carry on underflow so
implementing multiprecision down counters requires using the zero
state. This code will count down a 16 bit value in 4 cycles (16 clocks)
MOVF COUNT_LO_BYTE,F ; Test this byte
BTFSC ZERO_BIT ; (bit 2, f3)
DECF COUNT_HI_BYTE ; Decrement the high byte
DECF COUNT_LO_BYTE ; Decrement the low byte
>I need a set of standards that are well know and are generally accepted
>for the use in the design of control systems. .... The standards that I
>adopt will be for my own use, but they must be able to withstand review
>by the government. Can anyone point me in the right direction?
Derrick:
You could start by writing your code in Ada...
Seriously, the government has already spent considerable time creating a
set of software standards. I'm surprised that, working for the Navy,
you don't already know this.
Get a copy of MIL-STD-1521, which covers software design and
documentation. I hear that it's lately been replaced by a newer DoD
spec, but I don't know the new number. In any case, "1521" should be
available from all the usual sources for military, ANSI, or ISO
standards.
Code written to 1521 is guaranteed to withstand review by the
government.
>Here is my situation. The input data is 8-bit, two's complement
>data. I need to multiply two inputs together then multiply the result
>by 8 and still get the result to fit in 16 bits.
>
>As I see it the max 8-bit value can be FFh (-1). In order to
>make the multiply work for the 16-bit math I need to set all upper 8
>bits (I think) so that my multiplier data is FFFFh. This will cause an
>overflow if I have two such values to multiply so I was going to limit
>one of my inputs to 5 bits (ie, max value = 1Fh). But if I do this how
>do I use this 5-bit representation of -1 in the 16-bit adder???
Martin:
The two's-complement representation was designed to solve exactly your
problem. If you're using narrow numbers (with a small number of
digits) and want to translate them to wider numbers (with more digits),
all you have to do is "sign-extend" your numbers. That is, replicate
the sign bit (the narrow representation's leftmost bit) to the left,
filling all the "extra" bits in the wider representation.
In your case, you want to extend 5-bit numbers in the range [-16 - 15]
to 16-bit numbers. Here... Take a look at the 5-bit and 16-bit
representations of some numbers in that range:
As you can see, bit-positions 5-15 in the 16-bit numbers contain the
same value (0 for positive numbers, 1 for negative) that's in bit 4.
[If you're REAL unfamiliar with binary notation, I guess I should tell
you that the bits are numbered from right to left, starting with bit
number 0. If you're not, I apologize for talking down to you.]
If you were writing your own math routines or were more comfortable with
binary math, I'd recommend that you write your multiply routine to use
the 5-bit value directly; the resulting code would be shorter and would
execute more quickly. However, since you're using pre-packaged
routines, just extend the sign bit into the upper bits before you do the
multiplication, and you'll be fine.
> Here is my situation. The input data is 8-bit, two's complement
> data. I need to multiply two inputs together then multiply the result by
> 8 and still get the result to fit in 16 bits.
>
> As I see it the max 8-bit value can be FFh (-1). In order to
> make the multiply work for the 16-bit math I need to set all upper 8 bits
> (I think) so that my multiplier data is FFFFh. This will cause an
> overflow if I have two such values to multiply so I was going to limit
> one of my inputs to 5 bits (ie, max value = 1Fh). But if I do this how
> do I use this 5-bit representation of -1 in the 16-bit adder???
>
Hi Martin,
I'm not sure that I fully understand what you are trying to do. If you
convert your data from two's complement, you can simply multiply the
two values and then left shift the 16-bit result three times for the 8*a*b
result.
If you leave the data in 2's comp. format, when you multiply you will
get the following:
a+a2=h'100' or a2=h'100'-a these are your 2's comp values
b+b2=h'100' or b2=h'100'-b
Now multiplying a2*b2
a2*b2 = h'10000' - h'100'*a - h'100'*b + a*b
For a 16-bit result, the h'10000' overflows. To get your desired value
of a*b you must correct the a2*b2 result by the following
a*b = a2*b2 + h'100'*a + h'100'*b - h'10000'
This simply means to add a and b to the high byte of the 2 byte a2*b2 result,
but your data is still in 2's comp. So you'll need to substitute
So, you can get your a*b from you a2*b2 by subtracting a2 and b2 from the
high byte of a2*b2. You may want to use the 16-bit subtraction with a2
and b2 as the high byte.
Now that you have a*b, just left shift three times for 8*a*b.
I have looked at several ways to make PC boards at home/office
with varying levels of success. From your post, it sounds like
you are having some problems with transferring the toner to
the copper. I tried a couple of products "designed" for this
approach and I was not very impressed with the results. I wound
up using 3m CG300 Laser printer transparency film. Print the
PCB on the film & heat transfer (with clothes iron on cotton
setting) it to the copper (BTW place a piece of paper over the
plastic film so the plastic does not melt onto the iron!) This
works pretty well.
If you want higher quality than this, you can treat the PCB
with a UV curable photo-resist. This is more time consuming
as it requires coating the PCB, exposing it under UV light for
20 minutes or so, and then etching. Plus, you may like working
around UV light; I don't! Accidents can and do happen!
Another approach, which is a little more expensive but is faster
than all the above is to print the design directly onto the
copper. You may be wondering how the PCB wraps around the drum.
It doesn't. There is a company called Bit Bangers in Florida
(no affiliations, kickbacks, etc... for me) which make 1/2 copper
sheets which have a thin silicone adhesive backing. So, you place
the copper sheet in the manual feed tray (the manual feed should
be a fairly straight shot through your laser printer) and hit print.
The toner is printed directly to the copper. Peel the backing off
and place on the FR4 (or whatever material you want to use as a
base) and place into your normal etch bath. Works great!
The cost is US$15.00 for a single 8.5x11 inch copper sheet. They
have "LaserPCB" packs which contain copper sheets with FR4. They
are US$30.00, US$70.00, and US$130.00 for 2-pack, 5-pack, 10-pack,
respectively. Their phone number is 800.251.7776 or outside the US
407.745.9321.
> How well does this adhesive hold up when you solder to the copper
> above it ?
It holds up pretty well. I would not recommend a lot of re-work.
For your average boards, I have been pretty impressed. They say not
to use a soldering iron temperature above 550.
Since I started this "introduction series" (again?) I will tell you a bit
about my interest in PIC:s.
I'm a student at Linkoping University (LiTH) in the middle-south-east of Sweden.
I study Applied Physics and Electrical Engineering (third year) and my
interest in electronics started when I was about 10-12 years old (I think).
As my studying occupies most of my time, I have only built two "major"
PIC-based gadgets, an RPM-counter for cars and a "magic wand"
(presented in Everyday with Practical Electronics recently) but MY wand is
better ...
I am a EE, working at IBM developing AIX/UNIX workstations. I work with the
PICs in my spare time in an attempt to create the ultimate home-automation
system for myself.
Oh yeah, I live in Austin, TX, USA. I'm 27, 5'11", 166lbs, (oh, this isn't a
personal ad, huh?).
> Pablo,
>
> Home automation? What kinds of things are you thinking of doing?
>
> Any particulars yet?
>
> ... JC
Well, first of all, I have 3 things already done and I'm actually trying to
sell them -- look for an add in the back of Circuit Cellar's Feb. issue.
First of all, some buddies and I created a communications protocol (VERY
SIMPLE and EASY to use). We call this RS232-BUS. It's simply RS232 wired
multi-drop with addressing. Then, we created a temperature taking device,
expanded that to a thermostat, and we also made an 8-bit I/O device for
interfacing to relays, alarm systems, or just about anything else. If you
want detailed information, mail a letter to .....chaseEraseMEbga.com and someone will
send you detailed information.
In the future, I hope to do some infra-red transmitting/receiving devices,
some "control panels", motion sensors, etc... We have a pretty good list
of useful things we hope to do. Right now though, it's mostly for our own
use but once we develop something and test it - why not sell it?
I saw that you're interested in robotics - write me if you need any help - I
have some interest in this area and I'd be willing to help you get started.
On Thu, 26 Jan 1995, Paul Greenwood wrote:
> Oh yeah, I live in Austin, TX, USA. I'm 27, 5'11", 166lbs, (oh, this isn't a
> personal ad, huh?).
Hmm when I traded you that PIC i would guess you were a little shorter
and a little heavier :) just joking
>
> Is there anyone else in Austin on the list?
yup, but only in summers,spring break and cmas brake.
I am a EE&CS student at the University of Texas at Dallas. I am an ex UT
Austin student(left to come here for a telecom specialization.) Creeping
along my 3rd year of both CS and EE(EE is more fun btw).
I started using PICs to make aviation test equipment(tach pusle
generator) and quite my job there before i was finished because the bozo
didnt pay me. Went to work for a company in Austin and my first
finalized project was a braking simulator for Canada rail(used 3 pics and
two Xlinx and a whole lot of f**king analog stuff[yes i hate analog]).
On more to the point. Every hardware project I do i use a pic in
some way. They are totally easy and all my profs are impressed because
they have never heard of it and think its neat(i now share my programmer
with 2 of my profs at school who also tinker w/ pics).
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | spamjohnsonj@spam@STOPspambga.com | spamBeGonejohnsonjspamBeGone@spam@utdallas.edu
C&H Technologies VXI Plug N' Play member
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
I'm John Kallend, prof. of engineering. I'm fooling around with PICs
with a thought of introducing them into freshman projects. I'm open
to ideas that will turn-on the students. To educate myself I've
started a couple of projects related to my hobby/obsession - R/C model
airplanes (especially rocket powered).
> I'm John Kallend, prof. of engineering. I'm fooling around with PICs
> with a thought of introducing them into freshman projects. I'm open
> to ideas that will turn-on the students. To educate myself I've
> started a couple of projects related to my hobby/obsession - R/C model
> airplanes (especially rocket powered).
Hello, I am Tracy Reed. I am a sophomore at San Diego State University
majoring in Aerospace Engineering. I have not yet begun toying around with
microcontrollers yet, but I have recently decided to give it a try. I am
looking at both the PIC and 68hc11, although I think I have just about
decided to go with the 68hc11. I hope to one day make a data logging
system for my radio control airplanes. Perhaps even get into flight
control if things go well. I noticed you were in RC, so I thought this
would be a good time to introduce myself. What are doing doing with PICs
and RC planes? I see you do boost gliders. I do model rocketry as well
(although I haven't launched anything in ages). I am mainly into gas
powered RC planes. I have designed a flying wing and I am in the process
of building it, althoug school has it temporarily on hold. Hopefully, I'll
finish it this summer. I want to have some sort of way to measure altitude
and airspeed etc to get some real performance data on my planes. At the
moment, I have absolutely no experience with microcontrollers. I know
enough assembly on the PC to make it print "Hello world" but that's about
all I can really do from memory. PC assembly has been a royal pain so far.
Microcontrollers seem to be quite a bit simpler than PC's (huge
understatement :), so it looks like they are a good place to start
learning about digital electronics.
Jason Gorden wrote ...
>
> What did you use to count RPM? Magnetic pickup? How did you implement
> it on the PIC?
>
Well, I used the signal from the ignition coil (very simple huh) but it works
quite well. With a limiter/transient detector I managed to create a stable
input to the PIC16C55. Then I used the PIC as a frequency counter to get the
correct RPM-value. The "counting time" will vary with the number of
cylinders of your car and is about 0,3s with 4 cyls, so you will get a new
RPM reading every 0,3s (which I find a bit too slow).
The display has four digits and is VERY special. It's multiplexed (only 13
lines)
and it was probably used to measure the weight of vegetables and stuff like
that.
The first two digits are now used as a peak RPM and the other two displays
the actual RPM. In addition to this there are five bars at the bottom of the
display and why not use them too ... (of course?)
This took about 3/4:s of the EPROM and to fill the PIC I included a
test-sequence-intro with flashing backlight in red/green/yellow and display
of all LCD-segments.
In message <RemoveMEm0rXc6S-0000mhCRemoveMERemoveMEdc.cis.okstate.edu>, "Tracy R. Reed" writes:
>Microcontrollers seem to be quite a bit simpler than PC's (huge
>understatement :), so it looks like they are a good place to start
>learning about digital electronics.
Yes, and no. A good way to start learning about digital electronics
is to try to build some very simple logic circuits. Get some 2-input nand
gates, flipflops, counters, etc and play with them. These chips have been
around in one form or other for well over 20 years. You can get many
interesting IC's for Pennies a piece. There are countless books and magazine
articles around with circuit ideas and there is no law at all against just
sitting there and designing something on your own.
If you get several different logic families such as TTL, CMOS, etc,
you will gain an appreciation for their advantages and disadvantages.
When you get really tired of tearing up a circuit that is perfectly
good except for this one little logic problem, you will truly love
microprocessors.
The practical side to this line of thinking is that it is almost
certain that accidents will happen. CMOS IC's can turn to nothing in a
microsecond if exposed to static electricity and TTL chips will let all their
smoke out if you try to sink too much current through an output or somehow
manage to get 12 volts on the 5-volt line . One tends to get much more
careful after a couple of such things and it is better to have learned on
cheap stuff than the latest and greatest VLSI technology.
I am an amateur radio operator and am interested in electronic
communication and controls of all kinds. I just got on this list to learn
more about the PIC. I am familiar with the 68HC11 and hope that the PIC
can be used in those projects for which the HC11 would be overkill.
Martin McCormick WB5AGZ Stillwater, OK
OSU Computer Center Data Communications Group
I'm currently a design engineer for a contract design and electronics
manufacturer in Central Illinois (USA). We do a lot of 8-bit designs
and some 16-bit products. Our main processor of choice is the Intel
8051 family but we also use some Motorola, Zilog, and of course PIC
parts.
In several former lives I've worked in educational television, the
technical side of theatre, and done quite a bit of remote sensing and
monitoring work in the nuclear power industry.
Hobby interests include amatuer radio (N9PUZ, formerly WD9EDT), Radio
Control Airplanes, and old Ford 8N tractors.
>Hi there,
>I have a question about the name of the PIC.
>What does that actually mean?
>I`ve been told something like "pipeline controller" or so.
>Does anybody know exactly?
>
>Henri
I believe 'PIC' is a name coined by Microchip as an acronym for 'Peripheral
Interface Controller'.
Yes, Peripheral Interface Controller is the acronym.
______________________________ Reply Separator _________________________________
Subject: FW: Name
Author: pic microcontroller discussion list
<PICLIST%TakeThisOuTMITVMA.BITNETspam_OUTuga.cc.uga.edu> at internet
Date: 1/31/95 7:08 AM
>Hi there,
>I have a question about the name of the PIC.
>What does that actually mean?
>I`ve been told something like "pipeline controller" or so.
>Does anybody know exactly?
>
>Henri
I believe 'PIC' is a name coined by Microchip as an acronym for 'Peripheral
Interface Controller'.
>Can anyone recommend a readily available power MOSFET with low on
>resistance (<0.03 ohm) when directly driven from a PIC output (5 volt
>supply). I ordered what looked like a promising device from Digi-key,
>only to find out that it was "vapor-ware". Current capacity required
>is modest, but must have low Ron. Thanks
>
>jk
If you can get +12V somewhere you can switch MOSFETS with the PIC. Just
connect the PIC output pin to the MOSFET gate and pull the gate to 12V with
a 10k or so resistor, larger means slower response when turning on. You
may want to put a small, 500 ohms or so, between the PIC and MOSFET gate.
This is to limit the short current spikes that may occur when discharging
the gate capacitance of the MOSFET. Now you can turn the MOSFET on my
making the PIC pin an INPUT, this should put the pin into a high impedance
state, letting the MOSFET gate be pulled high by the 10k resistor. To turn
the MOSFET off, just make the pin an output and drive it low, pulling the
MOSFET gate to ground.
>Thanks for keeping us posted on the situation with the Stamp II 's. Just
>from a curiousity point of view, what has been the major problems in
>producing the software for these packages? Is it that you are trying to use
>another PIC?
George,
There haven't been any problems, per se, but the creator of the Stamp is
grossly unable to estimate project completion times (just like the rest of
us, including myself when I work on projects).
Indeed, we are using a different PIC, which does pose problems not seen on
the original Stamp. We're also trying to add new functions.
------------------------ Lance Walley ---------------------------
Parallax, Inc.
>>Can anyone recommend a readily available power MOSFET with low on
>>resistance (<0.03 ohm) when directly driven from a PIC output (5 volt
>>supply). I ordered what looked like a promising device from Digi-key,
>>only to find out that it was "vapor-ware". Current capacity required
>>is modest, but must have low Ron. Thanks
>>
>>jk
>
>If you can get +12V somewhere you can switch MOSFETS with the PIC. Just
>connect the PIC output pin to the MOSFET gate and pull the gate to 12V
with a
>10k or so resistor, larger means slower response when turning on. You may
want
>to put a small, 500 ohms or so, between the PIC and MOSFET gate. This is
to
>limit the short current spikes that may occur when discharging the gate
>capacitance of the MOSFET. Now you can turn the MOSFET on my making the
PIC
>pin an INPUT, this should put the pin into a high impedance state, letting
the
>MOSFET gate be pulled high by the 10k resistor. To turn the MOSFET off,
just
>make the pin an output and drive it low, pulling the MOSFET gate to
ground.
>
>Hope this help,
>-shane
You might have a problem with this. Every i/o pin on a pic has protection
diodes
to both VSS and VDD. This limits the pin voltage to about 5.6 volts (if
vdd=5v).
I suppose you could get around this with yet another diode, but now it's
getting
a bit more complicated then the original request.
later .......
carl
Henry Carl Ott N2RVQ spamcarlKILLspamKILLspampipeline.com
------------------------------------------------
No wife, no horse, no spell checker.
------------------------------------------------
I've used a BUK553-100B logic level power mosfet manufactured by Philips
Semiconductors for switching from PICs - however its Rds(on) is about
0.22 ohms - higher than requested.
You could drive these via a 470R resistor from a PIC port pin. The resistor
should protect the PIC from any capactively coupled spikes on the gate
when switching large currents.
Unfortunately, as you want an Rds(on) < 0.03 ohms the Id capability tends
to be large and consequently the gate capacitance is also large. This means
the turn on will be very 'leisurely'.
The BUK106 might be useful as it is temperature & overload protected and
has an output pin to flag a fault condition.
Hope this is useful,
Sean Hagan
---------------------------------------
BIME
(Bath Institute of Medical Engineering) spambimespam_OUTbath.ac.uk
---------------------------------------
"John S. Kallend" <STOPspamMETMKALLENDspam_OUTspamBeGoneMINNA.ACC.IIT.EDU> wrote on
>Subject: power MOSFET that can be switched by PIC
>
>Can anyone recommend a readily available power MOSFET with low on
>resistance (<0.03 ohm) when directly driven from a PIC output (5 volt
>supply). I ordered what looked like a promising device from Digi-key,
>only to find out that it was "vapor-ware". Current capacity required
>is modest, but must have low Ron. Thanks
Hi John,
Harris makes N-Channel Logic Level Power FETs (MegaFETs). Their device
RFP50N05L has rDS(ON)= 0.027 Ohms at VGS=4V. Is that short enough for your
circuit?
Kind regards, Volkmar
---
Volkmar Gross, Softwork Telematica, Bremen, Germany (Fone&Phax: +49 421 74434)
>>>-----------------------------------------------------------------------------
>
Planck's quantum is the calorimetric equivalent of a Baud (Max Demon)
I recently bought some IRLZ44's from Digikey. They have an Rds of .028 ohms.
and are "logic level". They were in stock and arrived in three days. What
were you looking for?
--Chuck
The Microchip FTP site has been updated to include endure.zip. This
file is about 600K in size and contains the current distribution of
the endurance software for evaluating the performance of EEPROM's
in embedded control designs.
It has all new libraries and reflects the current 10 Million cycle
gaurentee now being offered by Microchip.
Here is, as promised, the info I have on the TO flag bug.
Note that the following is based on my experience only, so it may
be that I've misunderstood something. Therefore I would like to
here from anyone who can confirm or deny that this problem exists.
The story: In July 1994 I was working on a project that involved
PIC16C57. The electro-magnetic working environment for the PIC's
was pretty nasty -- to say at least, so I used the Watch dog to
catch any program run-aways.
The PIC's (8 of them) were controlled from a PC through a serial
connection. If one of the PIC's didn't respond to a request from
the PC, then the PC would reset the PIC's via the MCLR pin -- an
extra safety precaution.
The initialization code in the PIC's used the TO (TimeOut) bit in
the Status register to determine if a reset was caused by Watch dog
time-out or by a MCLR/power-up reset.
I use the CLRWDT instruction in the program, this instruction sets
the TO bit to "1", so after a MCLR reset the TO bit should be "1",
since a MCLR doesn't affect the TO bit (according to the manual).
However, I noticed that when the PC did a MCLR reset of the PIC's,
some of them would execute the power-up reset routine (as
expected), while others executed the watch-dog time out reset
routine. When I repeated the MCLR pulse, the pattern seemed to be
random, that is, at one time a PIC would do a power-up reset, the
next time a time-out reset...
The power-up/time-out ratio appeared to be around 50/50.
Very strange I thought -- must be a software bug... So I wrote a
short program that simply copied the TO bit to an output port
connected to a LED. When the PIC's were reset by MCLR, some of the
LED's turned on and some off - in other words: the same problem.
Well, maybe it's a hardware problem then ? I took a small PCB, put
on a PIC, a crystal, 8 LED's and a MCLR reset key. Wrote a program
that shifted the TO bit into a register, then copied the register to
the port, so that the LED's would show the status of the TO flag
after the last 8 resets.
After power up, the pattern on the LED's shifted one position each
time I did a MCLR reset or provoked a WDT time-out by stopping the
oscillator. The value shifted in after a WDT time-out was always
"0" (as expected) and the first TO bit shifted in after power-up
was always "1" (also as documented in the manual).
But after a MCLR reset the TO bit had an apparently random value :((
I discovered that the problem ONLY occurres when the prescaler is
assigned to the RTCC. When assigned to the WDT (even if set to 1:1)
then the TO bit isn't affected by MCLR reset.
I tried using different oscillator configurations and speeds -
didn't affect the problem.
Next I tried different supply voltages - no influence.
Then I disabled the Watch dog by blowing the WDT fuse - and I still
got random 1's and 0's in the TO bit !!!
Note that when the watch dog timer is disabled, then the TO bit
should *NEVER* be "0", since a watch dog time-out is the only event
that can set the TO bit to "0" (according to the manual).
I tested different devices. No difference between the EPROM / OTP
parts I tested.
Besides the 16C57's, the 16C55's also have the bug. 16C54 and 16C56
probably also, since they have the same core as 16C57, but I haven't
tested.
The 16C58A did not have the bug (Strange - since it's the same
core as the other 16C5X's ? - or maybe not ? ).
The PIC16C71 does not have the bug. My guess is that 16C84, 16C64
and 16C74 work fine, since their core is based on '71, but I
haven't tested.
Well, what did I do ?
After discussing the problem with the local distributor (exatec),
I send the source code to them and later the hardware too. They
didn't come up with anything, so they passed the code/hardware to
Microchip and told me that "They (Microchip) are looking into my
problem".
I guess they look very carefully, because they have been looking for
more than 6 months now.
As stated in the beginning, I'm very interested in hearing from
anyone that have had the same or similar problems -- and perhaps
solved them ?
For the time being, my solution is simply not to use PIC16C54-57
in any new designs, where I need to determine the cause of reset.
This is not what I would call a satisfactory solution to the problem.
To summarize: The TO bug affects an application when:
* The TO flag is checked after reset and
* The reset may be caused by MCLR and
* The prescaler is assigned to RTCC and
* PIC16C54-57 is used
I hope that someone on the PICLIST can help me with this problem
- or, at least, that this information can help you from running
into a similar problem in future designs.
>For the time being, my solution is simply not to use PIC16C54-57
>in any new designs, where I need to determine the cause of reset.
>This is not what I would call a satisfactory solution to the problem.
Michael:
If you have the registers to spare, you may want to try simply loading a
few (four of them, perhaps) with known values. Check the contents of
those registers on reset. If they contain the proper values, you can
assume that the PIC was reset via MCLR. If they don't, assume that the
PIC was just powered up.
I am setting up a PIC page on our WWW server, with information about my own
experience with PICs, together with links to related web pages. This is a
personal initiative, and I would like to know the sort of things that may be
of interest to people, and also if you know of any links to useful PIC pages
(I have put links to Microchip's Home Page and Parallax).
I will also use this page to distribute my Visual Basic program which
downloads object code to the PIC16C84 (although it isn't there yet as I have
some copyright problems to overcome)
If there are no other PIC pages then that makes me the first, so hopefully
everyone will point to me, but this means I need something interesting to
put there!
Both pages are 'under construction' and may include references to things
that don't exist, however they've only been there for 2 days, so no flames
please!
You wrote:
> If you have the registers to spare, you may want to try simply loading a
> few (four of them, perhaps) with known values. Check the contents of
> those registers on reset. If they contain the proper values, you can
> assume that the PIC was reset via MCLR. If they don't, assume that the
> PIC was just powered up.
Yes, useful tip for checking if reset was caused by power-up or
by MCLR reset.
However the subject were Watch Dog Timeout reset vs. MCLR reset.
According to the manual, the TO bit should indicate whether a
Watch dog timeout has occurred. But under some circumstances the
TO bit does NOT have the correct value. That is the problem.
As some of you know, Some of the files referenced in the
pages of Curcuit Cellar Ink are made available on their
BBS; and can be obtained via internet email if you send
a message requesting them to their FTPMail server.
I have asked for and received permission to provide
this service. Of course, Curcuit Cellar Ink does not
assume responsibility for it since I don't work for them.
Someone wrote me and indicated a problem with my WWW interface to the
Circuit Cellar Ink FTPmail server.
It appears that in Mosaic (at least the X version), the submit button was
rendered as a field rather than a button, so there was no way to submit
the form with your email address. I have fixed that problem.
I am mentioning this here in case anyone tried it and gave up because it
didn't work. If that is the case, you probably threw the URL away. It is: http://tfnet.ils.unc.edu/cgi-bin/CCBBS
Oh, by the way; Once you have entered your email address and gotten the
list of file areas, save that document as a bookmark. It contains your
email address so you won't have to "log in" again. The same is true of any of
the file area listings.
>I am using a windowed PIC16C56 with a 32kHz oscillator. The power
>drawn when the window is open is a nice 15uA, but when I put a piece of
>black electrical tape over the window, the current consumption rises by
>a factor of 20. Does anyone have any idea why this is happening? All
>unused pins are grounded or pulled high.
Darwin:
Aaron had a good suggestion -- it's likely that you've failed to
initialize some registers, so your code isn't behaving properly when the
window's covered -- but the code he showed was for the 16C57. For your
16C56, use the following:
USEFSR EQU 0
FSR EQU 4
PORTA EQU 5
MOVLW PORTA ;PREPARE TO ZERO ALL REGISTERS EXCEPT
MOVWF FSR ;THE FSR, RTCC, PC, AND PROCESSOR STATUS
;REGISTERS.
CLRRAM CLRF USEFSR ;ZERO A REGISTER.
INCFSZ FSR ;HAVE WE DONE THEM ALL?
GOTO ZEROEM ;IF NOT, LOOP BACK AND ZERO ANOTHER.
>
> Sheesh, but that is a broad question. My suggestion is that you call up
> Intel, Motorola, and Microchip representatives in your area (these may
> be distributors or field offices) and ask to speak to a "Technical Sales
> Engineer" or "The person in product marketing responsible for the <xx>"
> (insert the name of the processor). Then tell them you are planning a
> microcontroller design and are looking for a processor to design in.
> Tell them you are considering these three processors. Ask if they have
> any literature on the advantages of their processor with respect to these
> others.
>
> What you should get are three biased accounts, biased toward the processor
> they make. Then read them all and decide what you want.
>
>
> --Chuck
>
>
> On Tue, 14 Mar 1995, Andy Hill wrote:
>
> > Darwin Hawes <@spam@hawesSTOPspamPHYSICS.UBC.CA> writes:
> > > On Fri, 10 Mar 1995, Andy Hill wrote:
> > > > If the problem is worse when the window is covered, I'd agree with
> > > > the "uninitialized register/port" crowd.
> > >
> > > That would have been my guess, except that the power consumption rises if
> > > I put on the cover on a running processor, so it is not an uninitialized
> > > port on power up. The processor seems to function both with and without
> > > the cover.
> > >
> > OK, and you stated earlier that the power consumption rises over a
> > period of seconds after you cover the processor window. Do you have
> > enough data to tell if the rise is linear or more of an exponential
> > (RC-time-constant) sort of progression? Do you have any tri-state
> > busses that aren't being driven for long periods of time? Any ports
> > that are in input-mode that aren't being driven or pulled-up?
>
> The rise seems to be non linear, but in the opposite sense as an RC time
> constant. It starts slowly, then increases rapidly, then stops. There
> were a few inputs that were not being driven, but changing these did not
> have any effect. I tried the same experiment with another 56, and a
> brand new '61. The other '56 worked better than the first, only rising
> to 0.1mA. The '61 had low power consumption with or without light. From
> this I would guess it was some sort of damage from the UV erasing that
> caused the problem.
>
>
What we have here is the photovoltaic effect. Small but with CMOS it doesn't
take much. The chip is acting like a solar cell and appling a small but
significant charge in the gate of a lot of the transistors. Not much, but
enough for them to leak a little bit each. Multiply by god knows how many
thousands and it becomes significant. The delay is due to the input capcitance
of the gate, it's real small, but then again the chip is silicon just not
optimized for the effect. The reason it doesn't build up enough to send
you off into the weeds is that you basicly have a no load solar cell that
has a max voltage just high enough to be noticeable, i.e. it barely gets
you into the linear region, but it can't switch the other half of the totem
pole.
uk.ac.bradford Mono: Cathedrow
