>I need to count pulses from one pin, and then calculate the pulses per
>second. I'll use the AC zero crossing to increment one counter, then
>every sixty/fifty counts read the other counter to get a pulse per
second count. {Quote hidden}
> ....
>Then .... calculate a 10%, 15% and 20% reduction value and do a
>comparison of these reduced values to the calulated pulse per second
>and turn on outputs if any of these dropped in the ranges.
> ....
>1) Can the PIC handle this? My gut feeling is yes.
> ....
>3) Any pointers on doing the divide routines? I played around with it
>and using logical shifts I can kind of get there, but I believe there
>is some routines already developed.
Harrison:
Yes, the PIC can handle this without even breaking a sweat. In fact, if
you used an external EEPROM, you could do it with a 16C54.
I assume that the whole point of this thing is to measure the speed of
an AC motor in order to determine how much torque it's generating
(perhaps against an obstacle). Am I close?
I've been trying for a long time to figure out what it is that separates
hardcode real-time embedded-systems programmers from all those wimps who
write code for desktop machines, and your question #3 seems to be a
perfect example:
98% of programmers would try to find those 10%, 15%, and 20% speeds by
doing a division, and would waste their time and the microprocessor's
doing it.
The 2% of us who do small-microcontroller programming for a living would
probably avoid the division altogether, by just seeing whether it took
67, 71, or 75 seconds to count the number of pulses that originally took
only 60 seconds.
I just finished building the 16C84 programmer described in application
note 589, and I'm now kludging together some software to make it work.
Right now, I'm using parts of David Tait's program for his own
hardware as well as the source code for AN589, since the AN589 code is
just for communicating with the PIC and doesn't provide a front end
for reading hex files from disk and loading them into the PIC. Does
anyone have a canned DOS program for loading hex files into the PIC
using the AN589 hardware? The program I've kludged together is
somewhat messy...
Chris
--
Chris Leger (blahKILLspamcmu.edu)
Carnegie Mellon University
Field Robotics Center
>I just finished building the 16C84 programmer described in application
>note 589, and I'm now kludging together some software to make it work.
>Right now, I'm using parts of David Tait's program for his own
>hardware as well as the source code for AN589, since the AN589 code is
>just for communicating with the PIC and doesn't provide a front end
>for reading hex files from disk and loading them into the PIC. Does
>anyone have a canned DOS program for loading hex files into the PIC
>using the AN589 hardware? The program I've kludged together is
>somewhat messy...
>--
>Chris Leger (EraseMEblahspam_OUTTakeThisOuTcmu.edu)
>Carnegie Mellon University
At work we have several Macintosh Quadra computer systems setup with the
computers situated in a well air conditioned central equipment area with
the monitor and keyboard cables running back to the work stations. Problem
is that the keyboard / mouse interface, as Apple calls it - the Apple
Desktop Bus, does not like runs of more than 110' or so. Up to now we
simply kept the runs under that length.
Yesterday a new system user started and insists on using a Kensington Turbo
Mouse that doesn't have the "balls" to drive all that cable. Interesting
thing is that if you looped a regular mouse through the Turbo Mouse it
(Apple mouse) works fine. I scoped the thing and the data is getting kind
of rounded, but not terrible, and the 5 volt supply line seems fine. The
Turbo mouse works great if not used with a cable extension.
I says to myself hey, how about a ADB repeater project, knowing full well
that somebody must be selling such a device but this could be a good excuse
to play with pics at work so I look into it a little deeper. I manage to
find a thick Xerox of the ADB spec and low and behold Apple has a 16c54 in
a couple schematics as an ADB tranceiver. Small world. The ADB is a 4 wire
interface with a bi-directional data line, 5v, ground and a reserved pass
through wire.
Because the interface is bi-directional on a single wire, it makes a
repeater idea kind of tricky.
Any thoughts or ideas would be greatly appreciated.
> I can't help thinking that the above design is much simpler (from a
> hardware viewpoint) than the discrete CMOS design. I can understand the
> desire to support people without pic programmers, but I think a lot of us do
> have the capacity.
What gets me is that MICROCHIP does not have the part and protocol
used in their serial programming chip in the PICSTART programmer
series available as a loose part. It is a QTP or mask version
and would cost the same as a standard PIC.
Anyone who is doing pic development has to buy at least some Mchip
components and if he were to buy one more programming chip
that was able to programm everything with just a MAX (or equivalent)
and a few (<5) well placed transistors for the higher voltages he
could then program anything. It is almost as if the little people
are not really not encouraged to get started without a comitting
investment.
This chip could then become the industry standard for programmers and
Mchip would have more chip programmers in the field than any other
chip supplier.
Sorry to bother the list with this, but have I been unsubscribed or has the
list died?
I have received nothing since the 14th of this month. [sept.]
--
TAK
Pwy fydd yma ymhen can mlynedd ? Na fyddwn.
> Sorry to bother the list with this, but have I been unsubscribed or has the
> list died?
> I have received nothing since the 14th of this month. [sept.]
> --
> TAK
> Pwy fydd yma ymhen can mlynedd ? Na fyddwn.
>
> I've only received a couple of messages myself. Guess the PIC series
> are just so easy to use that no one has any more questions :)
That's true and maybe everyone on this list is overloaded with interesting
projects ... I'm not but that's because I'm still studying for my
master's degree in electrical engineering ...
However, I can come up with one question:
Microchip! Why don't you take the PicMaster software and make
a hardware emulating add-on module so that all of us who can't
afford a complete PicMaster system still can use the user friendly
environment of the PicMaster software? (for free of course :-) )
(I really don't like the DOS-MPSIM software ... it's 1995 now!)
> Sorry to bother the list with this, but have I been unsubscribed or has the
> list died?
> I have received nothing since the 14th of this month. [sept.]
> --
> TAK
> Pwy fydd yma ymhen can mlynedd ? Na fyddwn.
what's happened to microchips www page. I keep (for the past two days)
getting a netscape error "ERROR 404, File not found or does'nt exist
or is read protected". anybody any ideas. ,
,
,
I've seen things you people wouldn't believe.
Attack ships on fire off the sholder of Orion.
I watched C-beams glitter in the darkness at Tan Hauser Gate.
All those moments will be lost in time,
like tears in rain.
Time to die.
>what's happened to microchips www page. I keep (for the past two days)
>getting a netscape error "ERROR 404, File not found or does'nt exist
>or is read protected". anybody any ideas. ,
>,
>,
>I've seen things you people wouldn't believe.
>Attack ships on fire off the sholder of Orion.
>I watched C-beams glitter in the darkness at Tan Hauser Gate.
>All those moments will be lost in time,
>like tears in rain.
>Time to die.
>
>Remember now, watch out for the Fairies......!
>
>
It looks fine to me!
Steve Addison
University of Aberdeen
Tillydrone Avenue
Aberdeen
Scotland
UK
AB9 2TN
Tel: UK 01224 272889
Fax: UK 01224 272396
Dear friends,
I got an app. note from microchip web site(http://www.ultranet.com) whose name is
an593.zip .after unzip,an593.ps file was generated that i could not read it.
Can you help me what can i read this file in dos or windows?
kind regards
A.Marami
electronics engineer
>Dear friends,
>I got an app. note from microchip web site(http://www.ultranet.com) whose name is
>an593.zip .after unzip,an593.ps file was generated that i could not read it.
>Can you help me what can i read this file in dos or windows?
>kind regards
>A.Marami
>electronics engineer
>
It's a Postscript file, you can send this file to a printer that understands
Postscript. However, I think you can read it if you get the Ghostscript
package for Windows, see below.
... but isn't there a text-only app-note for an593?
-- Conny
---------------------------------------------------------------------------
This is GSWNGUI2 April, 1993
A Command Line Graphical User Interface for the MS Windows program:
Ghostscript for Windows Ver. 2.5.2
Its purpose is to make the use of Ghostscript for Windows more convenient,
and to make its use feasible for the average user.
Ghostscript is a Postscript Interpreter. It can display, print on inexpensive
printers, and store in graphics image files the Postscript files intended
to be printed on expensive Postscript printers.
This interface makes the use of the MS Windows version of Ghostscript
much easier.
This is Revision 2. It improves on the interface for Version 1, eliminates
a couple of bugs, and adds multiselect features.
This software is freely redistributable. It is not to be sold.
The accompanying gswngui.wri is a Windows Write file describing use of the
program. It can be read under Windows Write, or printed. It is 6 pages long.
The user will have to get the Ghostscript for Windows software from
the Internet, or from a well stocked BBS.
On the internet, one source of Ghostscript for the PC is:
wuarchive.wustl.edu
Look under the ftp directory:
mirrors/msdos/postscript
The Windows version of Ghostscript is gs252win.zip and support files
will be needed as well. See my documentation.
A good site for Windows software, and where I found gs252win.zip is the
Internet site:
dear friends,
I have sent this question 2 or 3 days ago,but i did not receive any answer,so
i think maybe you have not receive this question.let me repeat it:
i got an application note from microchip web site(http://www.ultranet.com)whose name
is an593.zip.after unzip this file i got an593.ps file,but i could not read it.
can you help me how can i read this file in dos or windows?
i am looking forward hearing from you in soon.
regards
A.Marami
electronics engineer
an593.ps is a postscript file. You can print it on a postscript printer or
you'll need a postscript viewer like ghostscript (I think that is what they
call it). You may be able to do a text-only dump into Word using their
encap postscript import function.
For some time, I've wanted to try implementing a Apple Desktop Bus (ADB)
interface on a PIC. Other than a very short application note in the
Microchip Handbook, I haven't seen any details on doing this. So, armed
with the Macintosh Family Hardware Reference (from Apple, which describes
the ADB interface and protocol in detail) I decided to roll my own.
It isn't done yet, but it is a start. The code I've included at the end of
this message does the following:
It monitors the ADB bus for the Attention Signal (800 usec low). It then
waits (delays) for 65 usec for the Sync Signal, then reads in the eight
data bits of the command which is sent from the Mac. The first four bits
are the address. The next two are the action (generally Talk or Listen),
the last two are the register number (0-3).
The program checks that the address is equal to 6 (arbitrarily picked by me
for testing. A "real" ADB device supports address arbitration which occurs
at bus reset time). If the address matches, the Talk and Register number
bits are displayed via four LEDs connected to RA0 to RA3 outputs. The ADB
bus is connected to RB bit 1. No provision for transmitting exists yet.
This is all done on a 16C84, BTW, running at 8 MHz. 4 MHz operation should
be possible, if you re-adjust the timing loops.
Using the ADB Parser program (supplied on APDA CDs, *extremely useful*) I
can send various commands over the bus, and verify that the program does
what it should.
This is just a start, but hopefully it can grow into a full fledged ADB
Device controller. I wanted to see how easy it would be to hack something
together. I'm interested in what others think, comments and criticisms are
both welcome. I'd also like to work with others interested in ADB
interfacing.
(This is my first real PIC program, BTW)
Chris
(excuse the double spacing, the pc likes to put in extra linefeeds that the
Mac doesn't want to take out)
;Apple Desktop Bus test
; Set the device type, oscillator type, watchdog timer status, and code
----------------------------------------------------------------------------
|Check out my WWW page at http://www.access.digex.net/~cps/ for ham radio |
|software for the Mac; Free Radio, Shortwave Radio, and Spy Numbers Stations |
|information. |
|Finger me (RemoveMEcpsTakeThisOuTaccess.digex.net) for my PGP Public Key |
----------------------------------------------------------------------------
"Those who would gladly sacrifice liberty for security deserve neither."
-Ben Franklin
Hi,
>I was interested in doing an frequency counter. Great ! There is an application
>note in the Microchip book (frequency counter, I think the number is an592).
>I read it, and I didn't understand how it works. I thought the best to do is
>to get the file from Microchip and simulated it.
>But, the file was in Postscript. So, I had to type it !
>After simulation, my conclusion is (but perhaps I'm wrong):
> This file can't work !!
> Example: movlw B'10000100' seams to be the instruction to configure the entry
> port !
>So, my questions are:
> Am I wrong, or some files (or perhaps the most of them) of the Microchip
> book were not tested ? If so, where can I find a list of file tested ?
>
>Thanks for reply
>
>Yves Bergeon
>
>I have come to the same conclussion re AN592, however I am using the "it's
the thought that counts" and used the general idea, i.e. gating the RTCC
(TMR0 on the 'c74, which I'm using) and the use of a I/O port to pull the
external frequency source low when you are not counting and a fixed software
delay to set the gate period. I am also interested in inputs from others on
this app note as well as a source for the 3 wire led LT8522.
Well, I spent a few more hours playing around with the simple ADB code I
posted to the list earlier, and have made a few improvements:
It now sort-of supports address re-location (which occurs when the bus is
reset, and the Mac has to shuffle conflicting device addresses around). I
say sort of because it still doesn't monitor for collisions during this
process, which all good ADB devices should do. This obviously is bad if you
choose the same address as another device (such as your mouse). But I start
at address 6, which is probably never used (and certainly isn't on my
setup), so it works for me. Something to be fixed later.
Data can be sent to register 1. The 24 bits sent are shuffled out another
of the PIC's output pins to a Maxim MAX532 Dual 12 bit D/A converter (along
with an output for the data clock and one for chip select). Now my Mac can
send two analog signals to the outside world!
Data can be read from register 1. When a Talk request is made, the PIC
tells a Burr Brown ADS7807 16 bit A/S converter to perform a conversion.
The 16 bits of data are then read in a digital input (using the same clock
pin as for the D/A) and sent to the Mac. Now my Mac can read an analog
signal from the outside world!
As I said earlier, collision detection is not performed. That should be one
of my next goals.
I was using register 0 for my analog I/O, but the Mac always checks
register 0 of the last addressed ADB device to see if it has anything else
to send. That resulted in data continuously being sent from the PIC once it
started. Not good. Well behaved ADB devices only respond to a Register 0
Talk command if they have something new to send (which isn't really
possible to implement for my uses).
Next step is to add some digital I/O. I was thinking of using some shift
registers to get the data into and out of the PIC. They would appear as
register 2 to the Mac.
I also have four LEDs hooked up to RA0-RA3 outputs. They indicate the PICs
new address when you send a Listen Register 3 command. Since they're just
for diagnostic purposes, they will probably have to go to make room for the
I/O necessary to talk to the shift registers.
Anyone know how Apple handles requests to license use of the ADB bus (they
apparently have a patent on it). It is just a formality (fill in a form)?
Or do they want big bucks $$$ too? I'd like to market a cheap
analog/digital I/O device for the Mac using the ADB for the interface.
Well, I hope this stimulates some more ADB interfacing projects on the
list, and I hope to hear from others. Thanks to those who have written to
me already. I have cleaned up the interrupt handler as was suggested
(although it isn't being used in this application).
Chris
;Apple Desktop Bus test
;4 November 1995
;Copyright 1995 Chris Smolinski
;No portion of this software may be used in any commercial application without
;express written consent. blah blah blah... - the lawyers
;
;Communicates with:
;MAX532 Dual 12 bit D/A converter (Listen Register 1)
;ADS7807 16 bit A/D converter (Talk Register 1)
; Set the device type, oscillator type, watchdog timer status, and code
; protect status
Loop1 mov Count0,#1 ; each loop count is 5 usec
mov ADBAddress,0
mov ADBTalk,0
mov ADBReg,0
Loop nop ;(1)
nop ;(1)
nop ;(1)
nop ;(1)
nop ;(1)
jb detector,notdetected ; jump if no adb signal (2)
ijnz Count0,Loop ; (3)
notdetected dec Count0
cjb Count0,#150,Loop1 ; jmp back to loop if <200
;
; ok, we have received an "attention" signal.
;
; now wait for 65 usec for the sync signal to finish
; (in an ideal world, we would actually verify that the sync signal was
; present for the 65 usec)
;
mov Count0,#26 ;26 loops * 2.5 usec/loop = 65 usec
WaitSync nop ;(1)
nop ;(1)
djnz Count0,WaitSync ;(3)
;
; Delay 50 usec to be centered on each bit of data
;
mov Count0,#20 ;20 loops * 2.5 usec/loop = 50 usec
WaitDelayA nop ;(1)
nop ;(1)
djnz Count0,WaitDelayA ;(3)
; now read first address bit
jnb detector,AddressB ; jmp if a 0 (2/3)
setb ADBAddress.3 ; (1)
TalkReg1
clrb SCLK ; serial data clock to low
clrb adCtrl ; initiate A/D conversion
call SendBit1 ; send a 1 (start)
setb adCtrl
mov Count1,#16 ; counts 8 bits of data
TalkReg1A setb SCLK ; clock out data bit
movb Temp.0,/adData ; get complement of input
mov W,>>Temp ; input now in Carry bit
call SendBit
clrb SCLK ;
djnz Count1,TalkReg1A
call SendBit0 ; send a 0 (stop)
jmp Loop1 ; all done
TalkReg3
call SendBit1 ; send a 1 (start)
mov Temp,Reg3h ; copy reg 3h
mov Count1,#8 ; counts 8 bits of data
TalkReg3A rl Temp ; shift bit into carry
call SendBit
djnz Count1,TalkReg3A
mov Temp,Reg3l ; copy reg 3l
mov Count1,#8 ; counts 8 bits of data
TalkReg3B rl Temp ; shift bit into carry
call SendBit
djnz Count1,TalkReg3B
call SendBit0 ; send a 0 (stop)
jmp Loop1 ; all done
movb Temp.0,detector ; get input (4)
mov W,>>Temp ; input now in Carry bit (1)
rl Byte0 ; input now in storage (1)
movb DATA,detector ; D/A data line (4)
setb SCLK ; strobe SCLK (1)
clrb SCLK ; (1)
DataLoopB jnb detector,DataLoopB ; jmp if a 0, wait for high
; xor RA,#00000001b ; Invert LED (bit 0 port A)
jmp Loop1
; if carry is set, a 1 is transmitted, otherwise a 0 is transmitted
; note, since a transistor is used to pull the ADB data line low, the
; TX output is set to a 1 to pull the data line low to a zero. Got it?
;
SendBit jc SendBit1
SendBit0 setb TX ; pull line low, start of bit
mov Count0,#26 ;26 loops * 2.5 usec/loop = 65 usec
SendBit0A nop ;(1)
nop ;(1)
djnz Count0,SendBit0A ;(3)
clrb TX ; pull line high, end of bit
mov Count0,#14 ;14 loops * 2.5 usec/loop = 35 usec
SendBit0B nop ;(1)
nop ;(1)
djnz Count0,SendBit0B ;(3)
ret
SendBit1 setb TX ; pull line low, start of bit
mov Count0,#14 ;14 loops * 2.5 usec/loop = 35 usec
SendBit1A nop ;(1)
nop ;(1)
djnz Count0,SendBit1A ;(3)
clrb TX ; pull line high, end of bit
mov Count0,#26 ;26 loops * 2.5 usec/loop = 65 usec
SendBit1B nop ;(1)
nop ;(1)
djnz Count0,SendBit1B ;(3)
ret
----------------------------------------------------------------------------
|Check out my WWW page at http://www.access.digex.net/~cps/ for ham radio |
|software for the Mac; Free Radio, Shortwave Radio, and Spy Numbers Stations |
|information. |
|Finger me (cpsEraseME.....access.digex.net) for my PGP Public Key |
----------------------------------------------------------------------------
"Those who would gladly sacrifice liberty for security deserve neither."
-Ben Franklin
Chris Smolinski <EraseMEcpsACCESS.DIGEX.NET> wrote:
>Well, I spent a few more hours playing around with the simple ADB code I
>posted to the list earlier, and have made a few improvements:
> .................. SNIP............
>
>Anyone know how Apple handles requests to license use of the ADB bus (they
>apparently have a patent on it). It is just a formality (fill in a form)?
>Or do they want big bucks $$$ too? I'd like to market a cheap
>analog/digital I/O device for the Mac using the ADB for the interface.
>
> .................. SNIP............
Apple charges a one time $50 license for ADB. The give you several documents
regarding the low level timing of ADB which is different from Inside Mac.
You need to contact someone in the Developer Services group.
In addition to supporting an initial address (which you have as 6), you need to
have your own handler ID (which Apple assigns).
Hi, when I started looking on the net, for info on PICs, I found that most
app notes were in either .ps or .pdf file format. I read, in piclist digest,
that Marami, was asking question on how to read ANXXX.PS (Postscript files).
I have tried to send this info to him directly, but his e-mail address is
not correct and keeps getting bounced back.
Since this info is relevant to PIC data sheets, I am posting this to piclist.
The easiest way to get viewer/printer for PIC anxxx.ps files, is to retrieve
Aladdin Ghostscript, and Ghostview. These allow you to print the files using
a non postcript printer. You must have ghostscript to run ghostview, be
prepared for a lot of files! (divide 64k into 3500k to get some idea of how
much E-Mail you will get)
That is how I retrieved my ghostscript and ghostview. The ftpmail server
will get any ftp file, uuencode and send to you as 64k e-mail sections!
If you have problems send email to RemoveMEftpmailTakeThisOuTspamftp.sunet.se, and in body of
message "help", the ftpmail server will send you info back on proper usage.
Example as follows will retrieve all files needed to run ghostscript and
ghostview on MS-WINDOWS 16 bit system:
--------------------------------------------------------------------------------
To:EraseMEftpmailspamspamBeGoneftp.sunet.se
From:RemoveMEusernameKILLspamserver.domain.name.
Subject:
Cc:
Bcc:
Atachments:
--------------------------------------------------------------------------------
reply-to usernameSTOPspamspam_OUTserver.domain.name.
open ftp.cs.wisc.edu
cd ghost/aladdin
get gs333ini.zip
get gs333win.zip
get gs333fn1.zip
cd ghost/rjl
get gsview13.zip
quit
----------------------------------------------------------------------------
****************************************************************************
If you want files for win32, change the "get gs333win.zip to "get gs333w32.zip"
If you want files for ms-dos, change the "get gs333win.zip to "get gs333dos.zip"
If you want files for os/2, change the "get gs333win.zip to "get gs333os2.zip"
If you have non-msdos computer such as MAC/SUN use the base address:
ftp://ftp.cs.wisc.edu/ghost
Look for read.me files which tell you where those particular ghostscript files
are located.
****************************************************************************
regards
********************************************************************************
* Tom Brown
E-Mail:spamBeGonetombrownSTOPspamEraseMEindo.net.id *
* Bumi Karang Indah Phone: 62-21-7508264 *
* Jalan Karang Asri II, **************************************************
* Blok C2/#43, Lebak Bulus * "If something is worth doing,
*
* Jakarta, Seletan 12440 * It's worth doing right the first time" *
* Indonesia * *
********************************************************************************
OK, we've all discussed the merits or non-merits of fuzzy logic.
Lets not do this again.
I have an application where a STD bus (8088) SCC is using a
output card, and A-to-D card to do the simple task of a
temperature controller of an enclosed cabinet. Basically a
setpoint is setup, and the air conditioner is run (or not run)
to reach the setpoint, where it keeps it stable. This is a
overkill, but the only reason it was used is originally it was
doing alot more stuff - but all that was removed and is now run
from an external PC. Fine, but who cares.
Will the fuzzy explorer (can it) do the same thing ? What type
of interface does it need - can it accept setpoints ? I need
some input from someone who has actually used it in this manner.
What can be done to modify the user program, and is it available ?
On the other hand, perhaps the PIC14000 might work just as well ?
Other than more work for software interface would be needed - how
does the temperature sensor work (internal and external) - what
is it calibrated against, etc. The data sheet really lacks on
this info. Anyone know if Data I/O supports the PIC14000 ? I
didn't see it on the last update.
I've done quite a bit of work with the 6805 and 8051 micro
variants. I am now looking to use a PIC due to their supurb features
and low power consumption.
I am planning to construct a remote frequency counter (personal
project), for a frequency in the range of 0 to 250 cycles/munute
(Quite low). It needs to calculate the frequency and output it in
a serial format at 2400 Baud.
The frequency is to be output at a maximum of one every 5 seconds,
and may be as slow as once every 15 seconds.
As for power requirements, I need it to
1 Use as little poweras possible
2 Run off 3 -3.3 volts.
3 Use as slow an oscillator as possible, yet still provide
the necessary frequency calculation accuracy.
4 Utilise the low power modes where possible.
From what I can work out the 16C84 may be a good choice due to its
ease of programming and small package size.
What I'm looking for is any pointers on how to accomplish this. Any
applicable application notes, or other documentation that may help.
Note that I don't have WWW access, only anonoymous FTP facilities.
Any help or comments will be appreciated.
Thanks,
Peter.
--
_______________________________________________________________________
Peter Homann email: EraseMEpeterhEraseMEadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>I've done quite a bit of work with the 6805 and 8051 micro
>variants. I am now looking to use a PIC due to their supurb features
>and low power consumption.
>
>I am planning to construct a remote frequency counter (personal
>project), for a frequency in the range of 0 to 250 cycles/munute
>(Quite low). It needs to calculate the frequency and output it in
>a serial format at 2400 Baud.
>
>The frequency is to be output at a maximum of one every 5 seconds,
>and may be as slow as once every 15 seconds.
At the University of Washington they are working on a fast pitch detection
algorithm. I guess they looking at when the waveform repeats and how
closely it resembles the previous period. So you could grab samples every
1/125 of a second and analyze the data in a similar manner. You might want
to do this in MATLAB first, then port it. Depending on the input, the other
way I can think of is to just count 0 crossings.
> I am planning to construct a remote frequency counter (personal
> project), for a frequency in the range of 0 to 250 cycles/munute
> (Quite low). It needs to calculate the frequency and output it in
> a serial format at 2400 Baud.
>
> The frequency is to be output at a maximum of one every 5 seconds,
> and may be as slow as once every 15 seconds.
I made something like it with the PIC16C74, it was designed to measure
frequencies up to about 50KHz. it had one timer running in as a real
time clock in high frequncy (this was to allow for high resolution in the
frequncy measurment). then I opened the RB0 (external interrupt) mask for
some time and each time an interrupt arrived, I sampled the timer, then I
was able to say which time between pulses I have. there was alot more
averaging and noise cancelation in my algorith.
BUT, I think that for your application this is too complicated, what I
would do in your application is have one timer running in a frequency
that I would like to have a frequency resolution for and have another
timer count pulses in it's clock input. then precicly every 1 second I
will read the timer and see how many counts I had in the last second, so,
here you have the frequency.
In message <.....199604290625.AA29445spam_OUTscratchy.adacel.com.au> TakeThisOuTPICLIST.....TakeThisOuTMITVMA.MIT.EDU
writes:
> Hi,
>
> I am planning to construct a remote frequency counter (personal
> project), for a frequency in the range of 0 to 250 cycles/munute
> (Quite low). It needs to calculate the frequency and output it in
> a serial format at 2400 Baud.
>
> The frequency is to be output at a maximum of one every 5 seconds,
> and may be as slow as once every 15 seconds.
>
> As for power requirements, I need it to
> 1 Use as little poweras possible
> 2 Run off 3 -3.3 volts.
Peter,
You may already know this, but if not, Maxim do an RS232 converter chip
that runs from 3V to 5.5V and produces true RS232 levels.
It is the MAX 3232.
In fact I have run it on the bench with a C71 at less than 2V supply and
still they both worked!
I am planning on using a PIC16C5X for a project. The project
doesnt require much mathematical computation or the highest speed. It
basically will be
1. Controlling and ultrasonic transmitter and receiver and
calculate object distance as an ultrasonic rangefinder.
2. Sending simple protocol signals to communicate with an
external device.
3. Performing simple logic and using the timer to perform
time dependent operations.
I am concerned about the limitation of the 5 series.
The reason I would like to use the 5 series is that I found a 5 series
emulator for about $200. Alot of people told me an emulator would save
alot of headaches when debugging and will save alot of time. My main question
is, what do the higher end PICs provide? I know I have enough RAM and EPROM for
my code and program.
1. Interrupts would be a conveninent features instead of polling, the 5 series
doesnt have them.
2. The maximum nested subroutine limit of 2 may cause a problem, not sure yet.
If a C compliler compensate for this, then it would be no problem.
3. Some extra independent timers would be a big help.
4. Is it worth using a higher end PIC and just write code with trial
and error.
Also, would any of you recommend using a C compiler to reduce the
time it takes to write code, the only problem is that the emulator
requires code in assembly and it may be alot of trouble trying to debug
the compiled assembly, than if I wrote the code myself in assembly.
Does anyone know where I can get a C compiler for 16C5X series and
find some examples?
Seeking career in Instrumentation and Digital System Design
San Jose, California August 1996
www.acsu.buffalo.edu/~gandler/resume.html
______________________________________________________________________________
A 16C84 (EEPROM) is good for trial and error type programming.
I have seen some prototype boards that let you program them
in circuit.
**********************************************************
*Mike DeMetz SYSCON International *
*.....mikedRemoveMEsyscon-intl.com South Bend, IN USA *
*aka RemoveME73165.1230spamBeGonecompuserve.com using Pegasus Mail *
**********************************************************
Hi Neil,
I just developed a system based on PIC16C84 and ultrasonic sensors (one
transmitter and one receiver). The system can evaluate distances betwen
0.1 and 6 m and send this to a PC on serial port. If you are interested in
code routines or schemes send me an e-mail at:
> I just developed a system based on PIC16C84 and ultrasonic sensors (one
> transmitter and one receiver). The system can evaluate distances betwen
> 0.1 and 6 m and send this to a PC on serial port. If you are interested in
> code routines or schemes send me an e-mail at:
í would be very interested in seing how you did it. It would be
perfect for a small robot I am planning to build. If you could e-mail
code and some details of the hardware I would be very grateful.
Hi, i'm Frank and i am writing from Italy.
Do you Know if somewhere there is a programmer that works with a serial
port RS422
or an ADB port of an Apple cpu? Maybe I can use a programmer for RS232
serial port, using a sotware DOS emulator (softPC from Insigna) but i'm
not sure if this solution is OK: can you tell me anything about?
I must program, erase and re-program memory and data (EEPROM) areas of
PIC 16C8x.
Please, if you know something or if you can help me, send me a
message.
<fraguiEraseMEmbox.vol.it>
Hi, i'm Frank and i am writing from Italy.
Do you Know if somewhere there is a programmer that works with a serial
port RS422
or an ADB port of an Apple cpu? Maybe I can use a programmer for RS232
serial port, using a sotware DOS emulator (softPC from Insigna) but i'm
not sure if this solution is OK: can you tell me anything about?
I must program, erase and re-program memory and data (EEPROM) areas of
PIC 16C8x.
Please, if you know something or if you can help me, send me a
message.
<RemoveMEfraguiEraseMEspam_OUTmbox.vol.it>
There are a number of options available for Mac based programming
solutions. Aside from the use of a windows emulator on a Mac, native
assemblers are available and SERIAL programmers abound.
To search for assemblers point your browser at "search.shareware.com"
and try the keyword assembler. I also have a demo copy of 5Asm from
Micro Dialects and it appears to be a nice full featured assembler for
the Mac.
Another site of interest is "www.access.ch/whoswho/showwho?rklingler".
I have not used any of the products pictured there but Mac based
assemblers and programmers are being offered. Hope this helps.
>Date: Wed, 15 May 1996 09:35:39 +0100
>From: Ronald Leenes <@spam@r.e.leenesRemoveMEEraseMEBSK.UTWENTE.NL>
>Subject: Re: PIC programmer for Apple
>
>Franco,
>
>as far as I know there is no such thing as a programmer that works on the
>Mac.
The picstart can be used on the faster Macs. It ends up taking very long
to compile larger programs (some of mine can take 15 minutes on a 6115
running softwindoze).
Wiring of the serial cable to the picstart is important and a bit abnormal.
About a year ago Karl Grabe showed me how to do it. This is what I have
saved from then.
Here's what I found...
It only works on my PB180 with Soft AT only when most of the extensions are
off.
It works on a Power PC running Soft windows (Native) in dos mode with all
the extensions on.
It won't work on my Duo 230 with Soft AT at all. :-(
I find I'm still not totally clear on which pins are what but if it's wrong
I just flip it. I think the apple modem tool is correct if you use it to
look at the open end of the female on the picstart, or printer or whatever.
I found that a female DIN8 packages fit nice in a 9 pin D-sub cover. Just fill
it with hot glue. Makes a cute short adapter.
Thank you so much for the tip. Can I distribute it freely?
>Hi Otmar,
>I've looked at your setup and there are a few differences see my setup below.
>Note pins 6 & 7 on the DB9!
>Also you are correct about the apple modem tool diagram being slighly wrong.
>
>
>Macintosh DIN8 PicStart DB9
>
>Pin# Pin#
>1 Hsko.................4 Data Ready
>2 Hski.................8 RTS
>3 Txd-.................3 Rx
>4 Gnd..................5 Gnd
>5 Rxd-.................2 Tx
>6 Txd+ (n/c)
>7 Gpi (n/c)
>8 Rxd+.................5 gnd (see note below)
>
>
>Remaining DB9 Pins:
>1 (n/c)
>6 (+5v) connected to 7 (CTS)
>
>Notes:
>Pins connected together on DIN connector: 8 (Rxd+) and 4 (Gnd)
>Pins connected together on PC DB9 connector: 6 (+5v) and 7 (CTS).
>
>Let me know if you get this working and we could let other Mac users know via
>the picklist or bbs.
>-Karl
-Otmar-
-----------------------------------------------------------------------
Electric Vehicle Components Ltd.
It's often said that life is strange, But compared to what? sf
Otmar Ebenhoech EraseMEtess@spam@netcom.com (415) 494-9255
-----------------------------------------------------------------------
>Date: Wed, 15 May 1996 09:35:39 +0100
>From: Ronald Leenes <@spam@r.e.leenesspam_OUT.....BSK.UTWENTE.NL>
>Subject: Re: PIC programmer for Apple
>
>Franco,
>
>as far as I know there is no such thing as a programmer that works on the
>Mac.
The picstart can be used on the faster Macs. It ends up taking very long
to compile larger programs (some of mine can take 15 minutes on a 6115
running softwindoze).
Wiring of the serial cable to the picstart is important and a bit abnormal.
About a year ago Karl Grabe showed me how to do it. This is what I have
saved from then.
Here's what I found...
It only works on my PB180 with Soft AT only when most of the extensions are
off.
It works on a Power PC running Soft windows (Native) in dos mode with all
the extensions on.
It won't work on my Duo 230 with Soft AT at all. :-(
I find I'm still not totally clear on which pins are what but if it's wrong
I just flip it. I think the apple modem tool is correct if you use it to
look at the open end of the female on the picstart, or printer or whatever.
I found that a female DIN8 packages fit nice in a 9 pin D-sub cover. Just fill
it with hot glue. Makes a cute short adapter.
Thank you so much for the tip. Can I distribute it freely?
>Hi Otmar,
>I've looked at your setup and there are a few differences see my setup below.
>Note pins 6 & 7 on the DB9!
>Also you are correct about the apple modem tool diagram being slighly wrong.
>
>
>Macintosh DIN8 PicStart DB9
>
>Pin# Pin#
>1 Hsko.................4 Data Ready
>2 Hski.................8 RTS
>3 Txd-.................3 Rx
>4 Gnd..................5 Gnd
>5 Rxd-.................2 Tx
>6 Txd+ (n/c)
>7 Gpi (n/c)
>8 Rxd+.................5 gnd (see note below)
>
>
>Remaining DB9 Pins:
>1 (n/c)
>6 (+5v) connected to 7 (CTS)
>
>Notes:
>Pins connected together on DIN connector: 8 (Rxd+) and 4 (Gnd)
>Pins connected together on PC DB9 connector: 6 (+5v) and 7 (CTS).
>
>Let me know if you get this working and we could let other Mac users know via
>the picklist or bbs.
>-Karl
-Otmar-
-----------------------------------------------------------------------
Electric Vehicle Components Ltd.
It's often said that life is strange, But compared to what? sf
Otmar Ebenhoech spamBeGonetessEraseMEnetcom.com (415) 494-9255
-----------------------------------------------------------------------
Kalle had an valid comment on approval to hook things to the
phone lines. I'm not 100% sure on this, but it seems to me
that if you build something yourself (such as CID) for yourself
and as long as you follow good engineering and construction
practices, you don't have a problem tying it to the phone line
(unless telco comes a knockin'). If you want a production item,
then approval is necessary. Perhaps Andrew Warren can verify this
(I picked on him, because he seems to know quite a bit about alot
of things). However, you can buy a pre-qualified module with the
telco interface. Is it CerTek that has these things ? They are
out there, somewhere around $20 or so. Not sure about the name.
If you are looking for specific telephone info, feel free to e-mail me. I
have been working for several years on different telephone interface
projects. Mouser electronics 1-800-346-6873 (I do not work for these
folks) has a telephone coupler for as little as $1.52 part # 42TL016. If
you take the phone line in through .22Uf caps into the coupler, and then
place two 3.5v zener diodes arrows pointing away from each other
across the lines to clip the ring voltage, you will then be able to use the
phone line with the pic chip ,etc.. and make the phone company happy.
At 7:50 AM 6/3/96, Harrison Cooper wrote:
>Kalle had an valid comment on approval to hook things to the
>phone lines. I'm not 100% sure on this, but it seems to me
>that if you build something yourself (such as CID) for yourself
>and as long as you follow good engineering and construction
>practices, you don't have a problem tying it to the phone line
>(unless telco comes a knockin'). If you want a production item,
>then approval is necessary. Perhaps Andrew Warren can verify this
>(I picked on him, because he seems to know quite a bit about alot
>of things). However, you can buy a pre-qualified module with the
>telco interface. Is it CerTek that has these things ? They are
>out there, somewhere around $20 or so. Not sure about the name.
Harrison,
DAA and other modem goodies are available from Cermetek at
In this small island off the coast of Europe, your're supposed
to get BABT approval for your device *before* connecting it to
the phone line. This rule is, needless to say, widely ignored.
>Kalle had an valid comment on approval to hook things to the
>phone lines. I'm not 100% sure on this, but it seems to me
>that if you build something yourself (such as CID) for yourself
>and as long as you follow good engineering and construction
>practices, you don't have a problem tying it to the phone line
>(unless telco comes a knockin'). If you want a production item,
>then approval is necessary. Perhaps Andrew Warren can verify this
>(I picked on him, because he seems to know quite a bit about alot
>of things). However, you can buy a pre-qualified module with the
>telco interface. Is it CerTek that has these things ? They are
>out there, somewhere around $20 or so. Not sure about the name.
>
>
> Kalle had an valid comment on approval to hook things to the
> phone lines. I'm not 100% sure on this, but it seems to me
> that if you build something yourself (such as CID) for yourself and
> as long as you follow good engineering and construction practices,
> you don't have a problem tying it to the phone line (unless telco
> comes a knockin'). If you want a production item, then approval is
> necessary. Perhaps Andrew Warren can verify this
Consider it verified. Yes, you need FCC approval (in the States...
PTT in Europe, etc.) before you can sell any device that connects to
the phone line. All they're really interested in is safety, so if
your device is isolated from the line via opto-isolators or
transformers, you'll get the approval.
> However, you can buy a pre-qualified module with the
> telco interface. Is it CerTek that has these things ? They are
> out there, somewhere around $20 or so. Not sure about the name.
I think you mean Cermetek. They make two kinds of DAAs (Direct Access
Arrangements, which Cermetek calls DCPH, Direct Connect Protective Hybrid):
1: Basic DAA, requires some care to make sure it meets all relevant part 68
specs (things like billing delay timer, typically implemented in software).
Relatively inexpensive, but doesn't come with transferrable part 68
certification. This is useful if you don't want to design the phone line
interface yourself, but to use it in production you will still have to get
your product certified. Since certification is the expensive part, IMHO
you might as well design your own and save some money.
2: Fully-compliant DAA with transferrable certification. Really expensive,
but it does everything.
Of course, if you're outside the US, all bets are off.
I have a pile of Cermetek CH 1810s, which I think are the first kind.
Condition unknown, but believed working. No data, although a sheet should be
available from Cermetek (try directory assistance for area code 408).
Please let me start by appologising for sending file attachments to the
PICLIST group.
Gee can you Imagine being Cheesed out by 50 Guys for sending files while
in the meantime you considder yourself 'Prince Charming" for being so
nice as to share your resources. SORRY GUYS
Some blokes even send me back the files in text format. It does'nt
really bother me as I transfer about 1M per second on the Network direct
link to Internet. So please it takes you longer to send the files than
It takes me to Receive 50 of those.
I just did not realize the problem even existst. What more can I say. I
even Apologised personally to all who send me some snotty mail regarding
the incident.
I've got a great big Budget set aside for PIC development and all I'm
trying to achieve is help the guys who does not have the funds available
and to learn from others experience.
Would everone who has been offended by my curtusy please accept my
apologies. I can gaurentee you that it will defenately not happen again.
Thanks a lot for the formal apology. The attachment didn't bother me too
much. The snotty attitude you got was probably the built up frustrations
from people who receive a lot of other unwanted attachments.
Thanks again for taking the time to send an apology.
At 04:58 PM 6/4/96 +0200, you wrote:
>Please let me start by appologising for sending file attachments to the
>PICLIST group.
Thank you,
Bryan
>
> The snotty attitude you got was probably the built up frustrations
>from people who receive a lot of other unwanted attachments.
>
>
..... or who do not have 1M/sec direct connections to the Internet. I was in
fact please to receive the files since I am into building programmers now. I
took about 40 seconds to receive them. Anyone in this discussion group & who
took 10 min or over to download them I think should get better hardware or
server connections as a minimum system requirement in 6/96. (?)
What Jattie did I suspect will become the norm soon. The onus will then be
on the recipient to set his mailer not to receive files. Or (if the files
clog up the server waiting for delivery) a separate pic group may start
where file transfers are allowed. Just thoughts ..
regards, peter
-----------------------------------------------------------------------------
Peter J. Crowcroft
PO Box 88458, Sham Shui Po, Hong Kong
Voice: 852-2720 0255. Fax: 852-2725 0610 Email: .....diykitSTOPspam@spam@hk.super.net
Web: http://www.hk.super.net/~diykit
-----------------------------------------------------------------------------
In message <199606050127.JAA25369EraseME@spam@is3.hk.super.net> RemoveMEPICLISTspamBeGoneMITVMA.MIT.EDU
writes:
> >
> > The snotty attitude you got was probably the built up frustrations
> >from people who receive a lot of other unwanted attachments.
> >
> >
>
> ..... or who do not have 1M/sec direct connections to the Internet. I was in
> fact please to receive the files since I am into building programmers now. I
> took about 40 seconds to receive them. Anyone in this discussion group & who
> took 10 min or over to download them I think should get better hardware or
> server connections as a minimum system requirement in 6/96. (?)
Something of an arrogant position to take I think.
With file transfers, would you have any recommended size limit. Would my
near 1Meg Pic related windows program be acceptable in your world of
ultra high technology? With the ever increasing size of exe files, where
do you draw the line on what is reasonable and what is not?
As far as I can tell, broadcasted binary files on the internet are
frowned upon other than in the alt.binaries newsgroups. Lets keep this
list clean and tidy and free from posted files.
>
> What Jattie did I suspect will become the norm soon. The onus will then be
> on the recipient to set his mailer not to receive files. Or (if the files
> clog up the server waiting for delivery) a separate pic group may start
> where file transfers are allowed. Just thoughts ..
But why do you need file transfers via the list? Why?
Files can be sent by private e-mail, placed on web pages, ftp sites,
the Microchip BBS. Why use the list?
>Gee can you Imagine being Cheesed out by 50 Guys for sending files while
>in the meantime you considder yourself 'Prince Charming" for being so
>nice as to share your resources. SORRY GUYS
Been there, done that. I say "F*ck 'em if they can't take a joke"!
Thank you for posting your note. I want you to know that I agree with your
position 100%.
>> > The snotty attitude you got was probably the built up frustrations
^^^^^^
>> >from people who receive a lot of other unwanted attachments.
I think Jattie has a lot to learn about making humble apologies. :-)
>> ..... or who do not have 1M/sec direct connections to the Internet. [ ... ]
>
>Something of an arrogant position to take I think.
I agree with you.
>As far as I can tell, broadcasted binary files on the internet are
>frowned upon other than in the alt.binaries newsgroups. Lets keep this
>list clean and tidy and free from posted files.
I agree with you. If posting binary files to our PIC list becomes more common,
I will unsubscribe. This would be a real loss to me, but I cannot affort to
have my mailbox fill to capacity and potentially lose an important _text_
message while I am away for a week or more.
>> What Jattie did I suspect will become the norm soon. The onus will then be
>> on the recipient to set his mailer not to receive files. Or (if the files
>> clog up the server waiting for delivery) a separate pic group may start
>> where file transfers are allowed. Just thoughts ..
>
>But why do you need file transfers via the list? Why?
No reason. Anyone thinking that there is, is a newbee or a bozo!
>Files can be sent by private e-mail, placed on web pages, ftp sites,
>the Microchip BBS. Why use the list?
I agree!
Thanks again for presenting your _sane_ point of view.
> What Jattie did I suspect will become the norm soon.
I certainly hope not.
Even though I have a high-bandwidth connection, I still don't want big files
mixed in with a discussion list. I keep an archive of the list, and I don't
really want it filled with lots of copies of the latest software
de jour.
If this becomes the normal method for file distribution (as you suggest),
mailing lists and newsgroups will become even more clogged with requests like
"I missed the latest version of bogomatic, will someone please send it again"
followed by 536 copies of it provided by people trying to be helpful.
> The onus will then be on the recipient to set his mailer not to receive
> files.
I could certainly do this, but the average person with AOL or a low-end ISP
is not likely to be able to.
> Or (if the files clog up the server waiting for delivery) a separate pic
> group may start where file transfers are allowed. Just thoughts ..
What's wrong with FTP? If someone doesn't have direct access to FTP, there
are mail-based servers which will allow them to get the files by email
without mailing them to everyone.
And if someone wants to make files available for FTP but doesn't have access
to a server, I (and probably many others here) would be glad to put them on
my server.
I was one of the people who sent Jattie email about this, although I tried
to be polite and constructive rather than flaming and returning a copy of
the program.
>Please let me start by appologising for sending file attachments to the
>PICLIST group.
>
>Gee can you Imagine being Cheesed out by 50 Guys for sending files while
>in the meantime you considder yourself 'Prince Charming" for being so
>nice as to share your resources. SORRY GUYS
>
>Some blokes even send me back the files in text format. It does'nt
>really bother me as I transfer about 1M per second on the Network direct
>link to Internet. So please it takes you longer to send the files than
>It takes me to Receive 50 of those.
>
>I just did not realize the problem even existst. What more can I say. I
>even Apologised personally to all who send me some snotty mail regarding
>the incident.
>
>I've got a great big Budget set aside for PIC development and all I'm
>trying to achieve is help the guys who does not have the funds available
>and to learn from others experience.
>
>Would everone who has been offended by my curtusy please accept my
>apologies. I can gaurentee you that it will defenately not happen again.
>
>Best regards
>
>Jattie van der Linde.
Jattie, Thanks for the attachments. Being one of the low budget amateurs
planning to learn about PICs cheaply I found them useful. Whilst I can
understand peoples annoyance at the attachments I have seen far worse
breaches of internet "best practice". Don't take the flames to heart,
put any future files on an FTP server (try Andy Harrington at the
University of Lancaster who may oblige as he seems a friendly bloke) and
get on with life. It is often the case that those that shout loudest
about mistakes are some of the worse offenders when it suits their aims.
I must say that this mailing list is pretty well behaved compared with
some I subscribe to.
--
Stephen John Farthing MBCS G0XAR
Melksham, Wiltshire UK
RSGB G-QRP 7766
Newfound Electronics wrote:
> Is it possible to "TAP" the crystal oscillator from a PIC device using a
> high impedance schmitt trigger (74HC14?) or something the like?.
>
> I need a buffered 4MHz signal for the rest of the system and it would be nice
> if I can save $$ on a seperate "canned" oscillator.
>
> The frequency of the crystal MUST NOT be altered as it also sets baud rates.
> (Actually, some slight, (<1%) variation can be tolarated.)
Hang the gate on the CLKOUT line (not CLKIN), and make sure it has a FET
input circuit. Just about any CMOS part should be fine. If you find that
the frequency varies (which it may, due to gate-source capacitance), you
might try reducing or eliminating the capacitor on that leg of the crystal.
(Note that I've never tried this myself. It just seems to make sense in
an electrical sort of way to my warped [pre-coffee] brain at 6:00am.)
--
Rick Miller
<RemoveMErdmillerEraseMEKILLspamexecpc.com>
>Is it possible to "TAP" the crystal oscillator from a PIC device using a
>high impedance schmitt trigger (74HC14?) or something the like?.
I often use the PIC oscillator to drive auxillary circuits. I normally replace
one of the 20 pF load capacitors to ground with a 20 pF coupling capacitor to
the auxillary circuit. You can use the PIC to bias the aux circuit to approx
VDD/2 by shunting this capacitor with 100K or so.
If you keep the lead capacitance down, I don't see why a 74HC14 wouldn't work.
Check the input capacitance of the 'HC14 and try to keep the crystal load
capacitance in the right range.
> > Is it possible to "TAP" the crystal oscillator from a PIC device using a
> > high impedance schmitt trigger (74HC14?) or something the like?.
> >
> >i I need a buffered 4MHz for the rest of the system and it would be nice
> > if I can save $$ on a seperate "canned" oscillator.
> >
> > The frequency of the crystal MUST NOT be altered as it also sets baud rates.
> > (Actually, some slight, (<1%) variation can be tolarated.)
>
> Hang the gate on the CLKOUT line (not CLKIN), and make sure it has a FET
> input circuit. Just about any CMOS part should be fine. If you find that
> the frequency varies (which it may, due to gate-source capacitance), you
> might try reducing or eliminating the capacitor on that leg of the crystal.
>
> (Note that I've never tried this myself. It just seems to make sense in
> an electrical sort of way to my warped [pre-coffee] brain at 6:00am.)
I have used one crystal to drive two 16C5X-HS PICs at 20 MHz in production
with no problems.
Use a standard occilator circuit (Xtal + 2 x 27pF) and feed OSC out
to the OSC in of the second PIC. I also prototyped a design with
a dozen (12) PICs working in series at 20MHz (did not go into production)
and also tested it out at 25 and 32 MHz but the internal OSC is not
able to buffer at > 20MHz clock rates. The first PIC (driven from an
oscillator can) worked fine though.
Cheers
--
Kalle Pihlajasaari spamBeGonekallespam_OUTRemoveMEdata.co.za
Interface Products Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750 Fax: +27 (11) 402-7751
I just built a PIC programmer and I am anxious to use it. I've used
Motorola's 68340 and Intel's 8085 microprocessors before, but now I want
to learn how to use the less expensive PIC's. Does anyone know of some
simple applications that would help me to learn how to use it. Any
comments would be appreciated.
My first PIC application was to blink an LED and sound a tone.
It took me a couple tries before I had everything working though.
Sometimes getting used to new tools is the hardest part.
Once I had that running though, it was a snap to go on to driving
multiple stepper motors at variable speeds as well. :-)
Don't make your first try too difficult. Give yourself a chance
to prove the tools (compiler, assembler, programmer) before you
do anything that would require debugging your software.
Beware the Watchdog Timer! (It bit me in the butt since I didn't
know how to turn it off the first time.)
--
Rick Miller
<.....rdmillerRemoveMEexecpc.com>
On Thu, 20 Jun 1996, Brad Alexander wrote:
> Hello everyone,
> I just built a PIC programmer and I am anxious to use it. I've used
> Motorola's 68340 and Intel's 8085 microprocessors before, but now I want
> to learn how to use the less expensive PIC's. Does anyone know of some
> simple applications that would help me to learn how to use it. Any
> comments would be appreciated.
I'm looking for a programmer working on Apple.
Is there anyone who have built the MIPI interface (Machine Independent
Parallel Interface) from David Tait and have implemented it on Apple?
I usually work with PIC16C84 and i must program EEPROM area.
If you know something that can help, please, answer me.
Thanks
> Is there anyone who have built the MIPI interface (Machine Independent
> Parallel Interface) from David Tait and have implemented it on Apple?
By Apple I assume you mean the Mac.
I seriously doubt whether there is a second MIPI in the world. My
MIPI description is on the GNUPIC site (see my WWW page) with a tag
supplied by Rick Miller that says "It looks overly complicated." which
will sum it up for most people. One good thing that came out of the
MIPI discussion on the PICLIST last year was Erik Hermann's MIPP (on
my FTP site). The MIPP would be a better bet, but I don't know anyone
who has ported it to the Apple Mac. The MIPP was meant to bootstrap a
16C84 based programmer (never came to fruition as far as I know) but
will act as a standalone programmer.
The ETI programmer by Robin Abbott would be even better. You should
try to convince Forest Electronic Developments (Robin's company) to
write some Mac software to go with it (see my WWW page for contact
details). In fact the July 1995 issue of ETI magazine has a detailed
description of the required dialogue between programmer and computer
and it should be straightforward to write some simple host software
for the Mac. If anyone would like to do that perhaps Robin would be
willing to supply all the information required (are you reading this
Robin?).
I'm inheriting a Mac from a departing colleague in October, maybe I'll
see then whether I can produce a simple 16C84 programmer for the Mac,
but I'm sure there a lot of people who would make a better job of it
than me.
I have an unfinished simple PIC programmer design on my desk
it uses both serial ports and two transistors to program
16CXX series of PIC's
I havent found time to finish this project, but some test
programs are written. I also had many other ideas how to do MAC
PIC programmer. One option is to use Parallax Basic Stamp II
it connects directly to MAC, firmware can be downloaded and
the the hardware required is only two transistors. I build
that BS2 PIC programmer wrote the Basic programs for it and
there it is now waiting...
I still have plans to release Macintosh software tools for
microcontroller design, (not only for PIC's) but I am currently
very busy with one bigger project (what I suppose will be of
great interest to anyone dealing with PIC's Stamps and low
cost microcontrollers)
As said some projects partly done, some plans for the future,
but at this moment no promises on any release dates...:)
However its nice to now there are people around with MAC's
(I have one too, to allow me to write software for you out
there...I have no other uses for my MAC)
I dont like the 'SHAREWARE' concept, those if I write some
software it will be either free or commercial. At the moment
I cant spend all my time writing software to be given away
for free.
As I get my current project launched (assumed sept) I will
get back to MAC development tools. So call again to our
WEB pages in September. For the meanwhile my advice take
an advantage of the Summer, do whatever you do, but dont
waste your time with MAC PIC tools, until Summer is gone,
and then think again,... maybe the PIC programmer and
maybe other things for MAC will be there for you :)
>Frank <RemoveMEfraguispam_OUTmbox.vol.it> asked:
>
>> Is there anyone who have built the MIPI interface (Machine Independent
>> Parallel Interface) from David Tait and have implemented it on Apple?
>
>By Apple I assume you mean the Mac.
>
>The ETI programmer by Robin Abbott would be even better. You should
>try to convince Forest Electronic Developments (Robin's company) to
>write some Mac software to go with it (see my WWW page for contact
>details). In fact the July 1995 issue of ETI magazine has a detailed
>description of the required dialogue between programmer and computer
>and it should be straightforward to write some simple host software
>for the Mac. If anyone would like to do that perhaps Robin would be
>willing to supply all the information required (are you reading this
>Robin?).
And if Robin's arm can't be twisted perhaps MAC users might consider
looking in my direction. I am already talking to several MAC users
who have offered help in getting a MAC protocol working. Intially, this
would NOT mean native MAC software but a suitable protocol for an
upgraded PICSTART 1B and my WARP-3 and WARP-17 programmers to work
under a DOS emulator. Already, MAC users are using MPASM this way.
However, If someone already had a MAC "front-end" with the visual
interface and the file handling, conversion etc, this would be the
ideal start as the programmer interfacing would be simple to add.
I beleive there is enough interest in PIC tools for the MAC for someone
to seriously offer support for it. As I understand, some DOS tools work
already on a MAC but a _REAL_ programmer for all the PICs is missing.
Jim Robertson
NEWFOUND ELECTRONICS
P.S. David, I will forward you my web page address shortly and I hope you
will add it to your links. At the moment I don't have much public stuff
on it. It's just support existing users. Stay tuned...
>Frank,
>
>I have the same problem you have. I now have an old PC on my desk, just
>for programming the PIC.
>There is a Mac Pic programmer:
>http://www.access.ch/whoswho/showwho?rklingler
>
>So far I've been unable to reach Richard Klingler (I've tried both e-mail
>and fax). Anyone had any luck?
>
>I'm willing to put effort in getting a programmer (and an assembler) to
>run on a Mac.
>
>Ronald
I'm in the same boat. The assembler and other tools (at least the versions
that I have) will run OK on a Mac under Insignia's SoftPC or SoftWindows.
The thing that WON'T work is the connection between the computer and the
actual programmer. It is my understanding that this is a result of
Microchip's having chosen a non-standard serial protocol for this link.
If you find some way around this, I'd certainly like to know about it.
.....................Reg Neale.....................
"Ignorance is a renewable resource" P.J. O'Rourke
I was just searching through the Embedden control handbook and
could not ifnd any app notes for the SCI of the any of the PICs,
only software implementation of serial I/O with the lower end processors.
Anyone have a clue?
I want to connect such as PPI8255, 8250, 8279 etc on PIC17C44, but I think
it's not match with the read/write timing.
PIC17c44 on 25MHz, in datasheet, write pulse width=0.25Tcy = 40nS
in 8279-5 , minimum write pulse width is 250nS.
Any suggestion please.....
Thanks.
>
> I want to connect such as PPI8255, 8250, 8279 etc on PIC17C44, but I think
> it's not match with the read/write timing.
> PIC17c44 on 25MHz, in datasheet, write pulse width=0.25Tcy = 40nS
Yup. That puppy is some fast isn't it?
> in 8279-5 , minimum write pulse width is 250nS.
That presents a small challenge yes?
> Any suggestion please.....
Sure. Throw more hardware at the problem. One solution: Create a separate bus
by adding 2 74HCT573, a 74HCT244 and a 74HCT259. Use the 573 (or use can use a
373 if you can stand the layout) to latch the 16 bits of the '44 bus. Use 8
bits for data, and the other 8 bits for address/control. Wire the 244 (I'd
probably use a 245 becuse of the straight-through pin layout) to act as
an input buffer. Depending on how many devices, the 259 (an 8 bit addressible)
latch may not be necessary. But it gives you 8 independantly controllable
output bits to play with for control, RW, etc.
Now you can just control this new bus in software. For output just latch
the the data, turn the chip on using Chip select, wait the required time,
then turn CS off. The delay is only 5 or 6 NOPs.
For reading the same. Latch the address, turn on CS, delay, read data.
Another possibility due to the static nature of the chip is to simply
gate the clock of the 17C44 off (using an AND or OR gate) for the required
amount of time whenever a I/O device is accessed. Something like a 8 bit
shift register wired to shift 1's all the time but is cleared when I/O area
is accessed. The output of the shift register could then gate the clock to the
17C44. The shift register is also clocked by the same clock. Depending on the
output you pick you can tune the delay. The only other thing is that you'd
need a FF in front of the CLEAR input of the shift register so that you can
reset the pulse that clears the shift register. If you didn't the first time
you did I/O the system would hang because the 17C44 never progresses to raise
the line that cleared the shift register in the 1st place. A 74HCT74 configured
to clock in a zero and with the one of the outputs of the shift register
wired to reset that same FF should do it. You'll need an inverter so use a
NAND gate instead of the AND. So the sequence:
1. 17C44 selects an address for an I/O device. Assume falling edge.
2. This signal is inverted (by NAND gate) and fed into clock of '74 FF with
D input wired to 0. so a 0 gets clocked into FF. Wire Q of FF to CLEAR of
shift register. So the shift register gets cleared.
3. Pick any output that goes low (any shift register output or Q) and wire
to the reset of the FF. May want to delay that by running through a couple
of NAND based inverters. Anyway after a short delay the FF will reset resetting
both Q and the shift register CLEAR (which Q is connect to) to 1. But the
damage is done: the shift register has been cleared. Note that the FF will not
be metastable on the clock because the clock is edge based. The clock is
currently 0 due to the memory access to the I/O device.
4. Now the shift register (whose CLEAR has been reset remember) will start
clocking 1's back across the register. You can even half the 17C44 clock
by running it through the other half of the '74 FF if you need longer
delays (40ns * 16clocks) = 640ns (that should be long enough).
5. The appropriate output of the shift register is connected to the last
NAND gate that gates the clock. As long as the bit of the register is 0 the
clock will stay in the same state. Once that 1 propogates across to the
output pin, the clock will start up again.
So with 3 chips (shift reigster, nand gate, and FF) you can create variable
delays for I/O devices.
This isn't a new trick. This same design is used to swap out RAM/ROM from
the interrupt vector area for old 68000 based products.
Use whichever one suits you best.
BTW be careful about phase shifts in the clock when you stop it. You'll need
to figure out which state the clock is in when the delay hits and keep the
clock in that exact state. a fast glitch may screw things up.
From: Byron A Jeff <byronspamGEMINI.CC.GATECH.EDU>
At 09:23 AM 7/13/96 -0400, you wrote:
>>
>Sure. Throw more hardware at the problem. One solution: Create a separate bus
>by adding 2 74HCT573, a 74HCT244 and a 74HCT259. Use the 573 (or use can use a
>373 if you can stand the layout) to latch the 16 bits of the '44 bus. Use 8
>bits for data, and the other 8 bits for address/control. Wire the 244 (I'd
>probably use a 245 becuse of the straight-through pin layout) to act as
>an input buffer. Depending on how many devices, the 259 (an 8 bit addressible)
>latch may not be necessary. But it gives you 8 independantly controllable
>output bits to play with for control, RW, etc.
>
>Now you can just control this new bus in software. For output just latch
>the the data, turn the chip on using Chip select, wait the required time,
>then turn CS off. The delay is only 5 or 6 NOPs.
>
>For reading the same. Latch the address, turn on CS, delay, read data.
What if I make a 'Special function Register'?
suppose PIC17C44 in microprocessor mode
address memory FFFFh is for I/O Address (16 bit) and
memory FFFEh low is for I/O data (8 bit) and
memory FFFEh high is for I/O Control (CS,WR,RD).
and make full decode for that address.
So, I can get 64K address for I/O(8bit) OR 256 address x16 bit.
If this is implemented, what should I call ?
it's memory mapped I/O
or (memory mapped I/O) mapped I/O
or what? :-)
Thanks.
New Line
Frans gunawan
Simokerto 74
Surabaya 60143
Indonesia
This is an old trick, but some may not know about it.
The problems:
1. Swap W and a file register without using any additional registers
2. Cyclically permute 2 registers and W i.e. A=W,B=A,W=B
3. Swap 2 file regs without changing W or any other registers.
A bit of cheating is allowed i.e. we don't count the status register as
having been 'used'. XORWF instructions modify the status.Z bit. But
then again, so does MOVF.
The answers (at least some of the possible ones). Let A and B
represent the file registers to swap:
1.
xorwf a,w
xorwf a
xorwf a,w
2.
xorwf a,w
xorwf a
xorwf a,w
xorwf b,w
xorwf b
xorwf b,w
3.
xorwf b
xorwf a
xorwf b,w
xorwf a,w
xorwf b
xorwf a
xorwf b,w
xorwf a,w
Remember that you save _two_ file registers over the straightforward
way of using temporary registers and move instructions. E.g. unless
I am mistaken, the straightforward way of implementing (3) is
movwf temp1
movf a,w
movwf temp2
movf b,w
movwf a
movf temp2,w
movwf b
movf temp1,w
I am using a PIC 16C55 to read RS-232 data in one one pin then send
it straight back out again on another pin. My eventual aim is to
encrypt the input data & then have the reverse done with another PIC
so that I can transmit encrypted RS-232 data over the air.
I am using Procomm on a PC to test my code - I transmit a text file &
make sure I get back the correct data. My code works as long as I
have character pacing set to 30mSec or greater (space between each
byte sent) at 9600 baud. If I try to push it any faster than that I
lose bits. I am testing for start bit, reading in 8 more bits until I
have a byte then transmitting a start bit, the 8 bits collected & a
stop bit. I guess this is why it's failing - while transmitting the
byte out the next byte is coming in & I miss it (or part of it).
I guess I need a UART. Am I right in thinking that with a UART the
PIC would magically find the whole byte waiting somewhere & could
send out a byte at a time so data could be coming & going at once? If
so, does anyone know a UART that is readily available - must work
both ways at 300 to 9600 baud.
Either that or a completely different algorithm? I just tried
transmitting each bit after receiving it but this looks worse than
doing it a byte at a time.
I just did a quick scan through the PIC digest & noted that some
newer PICs might have UARTs built in. My PIC Programmer is a
Parallax PIC16CXX version 3 & I'm not sure whether it can handle
these new fangled devices! I haven't touched PICs for a year or more
since I discovered Stamps but I am pretty sure a Stamp couldn't
handle this sort of work. Hmm, maybe I had better try it as well.
I'm off to the Parallax WWW site now for a look but would be grateful
if anyone has any suggestions in the meantime.
I had a similar problem with a serial to centronics converter. The
solution is to use handshaking to stop incoming data when you're sending
data from the PIC.
You may need a buffer in case the sender does not react quickly enough to
the handshake (as in my case).
Also you may want to run the pic at a higher speed, that gives you more
headroom to do the encryption.
My converter uses a 16C84 P04 running at 12 Mhz. It handles 57k6 serial
data quite nicely.
>I guess I need a UART.[....]
If your PIC can afford to dedicate most of itself to the UART functionality,
then you can even use a 16C54 to handle ASYNC (probably a general theme in
microcontrollers, I guess...) My little LCD project does "bit-bangin'" UART
RX (but not TX, although this is easier), purely by monitoring bit input
and delays.
> >I guess I need a UART.[....]
> If your PIC can afford to dedicate most of itself to the UART functionality,
> then you can even use a 16C54 to handle ASYNC (probably a general theme in
> microcontrollers, I guess...) My little LCD project does "bit-bangin'" UART
> RX (but not TX, although this is easier), purely by monitoring bit input
> and delays.
>
> http://www.mindspring.com/~tcoonan
Actually, if your RX routine can just sit around until data comes in, Rx
is just as easy as TX; in fact, when running half-duplex it's often easy
to get a speed more than twice as fast as could be gotten full-duplex
because your code can receive bits without worrying about anything else.
Even a 1MHz 6502 can bit-bang at a decent speed half-duplex.
> Hello There
>
> Does anyone know of any information regarding the use of PICs in
> automotive applications.
>
> I am looking for any information on the net concerning automotive
> electronics.
>
>
> Any help in finding information on this subject would be gratefully
> received.
>
>
>
> Bye for Now
>
>
>
> Barryb
>
The best bet for *anyone* wanting to get more info on automotive
electronics is to join up for the "do-it-yourself Electronic Fuel
Injection" listserv group. This group discusses electronics, mathematics,
etc. on automotive-related topics.
and put in the body of the message (leave subject field blank):
subscribe diy_efi youremail@address
with you substituting your email address for "youremail@address"
There is also a project which several people are building a EFI
controller using a Motorola 68332. To subscribe to this listserv,
send mail to the same address, but use as a message:
subscribe efi332 youremail@address
There are also some WWW pages for these groups, see:
-
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------
Bruce A. Bowling
Staff Scientist - Instrumentation and Controls
The Continuous Electron Beam Accelerator Facility
12000 Jefferson Ave - Newport News, VA 23602
(804) 249-7240 RemoveMEbowlingKILLspam@spam@cebaf.gov http://devserve.cebaf.gov/~bowling
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------
Over the last year or two that I've subscribed to the PICLIST I have
received assistance from many people here. I just wanted to say THANK YOU to
everyone involved.
The PICLIST and its members are a wonderful resource. One that I certanly
appreciate. Again, thank you!
I have just downloaded MPLAB in the hope that it would have
a Windows based PIC START 16B and/or 16C programmer application.
But alas it does not. Does anyone know of a Windows based
application to drive the PIC START 16B and 16C?
Maurice De Jersey wrote:
>
> Hi,
>
> I have just downloaded MPLAB in the hope that it would have
> a Windows based PIC START 16B and/or 16C programmer application.
> But alas it does not. Does anyone know of a Windows based
> application to drive the PIC START 16B and 16C?
>
> Cheers
> Maurice
Get the PICSTART PLUS (+-R900). It is supported by MPLAB, and supports
ALL PIC products (18,28,40 pin)
Has anyone used a PIC to receive or transmit packets of serial data from a
Macintosh using the Mac AppleTalk network protocols? I am trying to
connect a PIC onto the Mac AppleTalk network so as to respond as though it
is a device on the network (such as a printer.
----------------------------------------------------------------------------
------------------------
Stephen H Alsop, S&S Systems Ltd, Bretton Court, Manor Road
Wales Village, Sheffield, S31 8PD, England
Tel: 01909 773399 * Fax: 01909 773645
------------------------------------------------------------------
email: spam_OUTs.ssystemsKILLspameasynet.co.uk
www, when finished : http://easyweb.easynet.co.uk/~s.ssystems
Stephen H Alsop <RemoveMEs.ssystemsRemoveMEEraseMEEASYNET.CO.UK> wrote:
> Has anyone used a PIC to receive or transmit packets of serial data from a
> Macintosh using the Mac AppleTalk network protocols? I am trying to
> connect a PIC onto the Mac AppleTalk network so as to respond as though it
> is a device on the network (such as a printer.
It's going to be tricky. The physical and link layers of LocalTalk use
FM0-encoded data with HDLC framing, at a rate of around one bit every 4
microseconds. I don't think a 20 MHz PIC will even be able to implement
a digital PLL to recover the data, let alone deal with HDLC framing or
higher layer protocols.
You're probably better off with a Zilog Z181 or Z182, which have a Z80 CPU
and a built-in SCC that can handle the physical layer and some of the link
layer for you. Zilog will even license a LocalTalk implementation to you.
If you really need to do this on a PIC, you should use a PIC17Cxx with an
external 85C30A or 85C230 SCC.
>>have a nice day and fix your bugs!
>>antti
>
>Antti, are you a registered user of ProPic ? I plan to purchase the
>software within the next 20- 30 days, after which I would be entitled to
>ask for bug fixes. Unregistered shareware users don't have the right to
>request fixes/ upgrades. Lighten up, all of this is just ones and
>zeroes!
No I am not. But I am not a user at _all_, its my friend who built the
programmer, and I did not _request_ for updates. I simple pointed out
few minor bugs thats all. (in too hard words)
ProPic software does work, I got it working too, after downloading
_all_ files from /tato website and reading the red warning on his page
I should have read the red, but I just ignored it. Silly me!
I verified C84 and C71 programming, so I suppose all 18/28/40 pins
except 55x work with current release. and the noise have not been
there anymore :)
I dont have problem with my printer ports, I do have 2 (no hercules)
and ProPic sees them in wrong order, but thats minor thing. It simply
isnt possible to acces the bios segment from VB so easy. It really
is minor problem.
Oh jes, I was going to appologize! Well dont know how to do that,
as I never do. But yes I was in a hurry to make too many conclusions,
and to tuff in words. Will not happen again. SORRY. Sorry for
wasted bandwith too.
antti
PS I am usually a friendly person, dont know what happened to me today:(
Maybe because I dont get days off when other people do?
-- Silicon Studio Ltd.
-- http://www.sistudio.com
Well it's the holiday season and like Tim Allen it's time for me to start
working on my Christmas Lights. I decided this year to soften the chasing
lights scene and to use fading in and out of different strings. While my
Motorola MOC3010 type circuits works fine, for dimming I need to detect
zero crossings. I plan to turn the lights one an off for whole cycles instead
of trying to triggerfor a portion of the cycle which generates that buzzing
sound.
Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
but I have to ask the dumb question: What's the return on the AC line? I can't
see how connecting just the hot line of the AC power is going to get you
anywhere and I'm damn scared to connect the neutral up anywhere near the
microcontroller.
1) That's not a dumb question - you can have lots of fun with mains failure
when you bring the neutral close to the "ground".
2) Provided your circuit operates from the live and neutral ONLY, you may
attach the neutral to the 0V (ground) - unless of course some dumb idiot
wire the power to you with the live and neutral swapped - do first check that.
3) Use an isolating 1:1 transformer - but if you do this you might as well
use the supply transformer (if you have one).
4) I once got my 50Hz timing info by wrapping a wire around a fluorescent
light and taking the SINGLE wire into the PIC. I made a digital (wall) watch
that hasn't lost a 1/50th of second in 5 years. PS. To see how little
current you need to switch a PIC input, take a window device, run a program
that waits in a loop for a pin to go high, then low, before toggling another
pin and see how the period varies as you vary the amount of light let in
through the window.
Hope this helps.
Jan van der Watt
[I went to ACTIVE-WORLDS and virtually stayed there]
In message <KILLspam199612060422.XAA32389spamBeGonegemini.cc.gatech.edu> PICLISTspamMITVMA.MIT.EDU
writes:
> Well it's the holiday season and like Tim Allen it's time for me to start
> working on my Christmas Lights. I decided this year to soften the chasing
> lights scene and to use fading in and out of different strings. While my
> Motorola MOC3010 type circuits works fine, for dimming I need to detect
> zero crossings. I plan to turn the lights one an off for whole cycles instead
> of trying to triggerfor a portion of the cycle which generates that buzzing
> sound.
>
I did this once, but found flicker at low intensities was too much.
Some quick sums:
If you go for 6 bits of brightness, at minimum brightness, you
will have 1 cycle on every 64 cycles, which in the UK (50Hz)
works out as 1.28 seconds between flashes.
I went over to switching mid-cycle to avoid the flicker.
Byron A Jeff wrote:
>
> Well it's the holiday season and like Tim Allen it's time for me to start
> working on my Christmas Lights. I decided this year to soften the chasing
> lights scene and to use fading in and out of different strings. While my
> Motorola MOC3010 type circuits works fine, for dimming I need to detect
> zero crossings. I plan to turn the lights one an off for whole cycles instead
> of trying to triggerfor a portion of the cycle which generates that buzzing
> sound.
>
> Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
> but I have to ask the dumb question: What's the return on the AC line? I can't
> see how connecting just the hot line of the AC power is going to get you
> anywhere and I'm damn scared to connect the neutral up anywhere near the
> microcontroller.
We've been down this path before..
You're best off using a transformer; you can often steal the ac input to
the bridge and diode clamp it to come up with a suitable cmos level
signal. All you need to do is overdrive the diodes enough to get fast
edges, maybe 3 to 5 times, and this works out to be the input to, say,
the 12v or 15v supply in a multi output supply. If you need a separate
transformer, you can get by with a really wee one.
With PIC processors you can get by with a wee transformer and gross
input to the bridge because the power is going to so low. In this case
the same transformer winding can perform both jobs. I use a typical
poorly regulated ac wall wart for this; the 5v regulator gets between 13
and 19 volts, and the ac peaks above that.
For power switching zero crossing detection this gets you plenty close
enough, and you're not connected directly to that high compliance
source..
>
> Byron A Jeff wrote:
> >
> > Well it's the holiday season and like Tim Allen it's time for me to start
> > working on my Christmas Lights. I decided this year to soften the chasing
> > lights scene and to use fading in and out of different strings. While my
> > Motorola MOC3010 type circuits works fine, for dimming I need to detect
> > zero crossings. I plan to turn the lights one an off for whole cycles
instead
> > of trying to triggerfor a portion of the cycle which generates that buzzing
> > sound.
> >
> > Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
> > but I have to ask the dumb question: What's the return on the AC line? I
can't {Quote hidden}
> > see how connecting just the hot line of the AC power is going to get you
> > anywhere and I'm damn scared to connect the neutral up anywhere near the
> > microcontroller.
>
> We've been down this path before..
> You're best off using a transformer; you can often steal the ac input to
> the bridge and diode clamp it to come up with a suitable cmos level
> signal. All you need to do is overdrive the diodes enough to get fast
> edges, maybe 3 to 5 times, and this works out to be the input to, say,
> the 12v or 15v supply in a multi output supply. If you need a separate
> transformer, you can get by with a really wee one.
Well the transformer is definitely a possibility. But the Microchip engineers
seemed to be real proud of the fact that the diodes on the I/O pins could
be used for the purpose with just a resistor to limit current.
Another thing is that the same issue I raised is still present. Presuming
I use a transformer and I tie one leg of the secondary to the PIC input pin,
where does the other leg go? GND? All the transformer does is change the
voltage, it does not address the issue of how to integrate the return...
>
> 1) That's not a dumb question - you can have lots of fun with mains failure
> when you bring the neutral close to the "ground".
I thought so.
>
> 2) Provided your circuit operates from the live and neutral ONLY, you may
> attach the neutral to the 0V (ground) - unless of course some dumb idiot
> wire the power to you with the live and neutral swapped - do first check that.
Yup that is definitely a possibility. I was planning to drive this circuit
with a wall wart. But it's easy enough to build a quick 5V supply. But the
same issue are still there. Presuming I'm using an integrated bridge rectifier
does it matter which leg of the secondary is connected to ground and which
leg is connected to the input pin?
> Another thing is that the same issue I raised is still present. Presuming
> I use a transformer and I tie one leg of the secondary to the PIC input pin,
> where does the other leg go? GND? All the transformer does is change the
> voltage, it does not address the issue of how to integrate the return...
Well, it does. With a transformer you can safely tie one side of the
secondary to ground. With mains input directly, you need to tie
the neutral to the PIC "ground", but you must not connect this to a real
ground, since not only can't you be sure the active and neutral are not
reversed, even if the neutral really is neutral, connecting it to
ground will trip earth-leakage detectors due to ground-loop currents.
The transformer primary is easily protected from fingers; the entire
PIC circuit is not. If you do want to float the PIC at mains potential,
then use an isolation transformer during testing, and even then
you still have to be careful of the transformer secondary, since it
can kill you too. A low-voltage transformer is much safer.
Mind you, you Yanks only have to be careful of 115V - 240V will
kill you twice as fast!
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411 RemoveMEclydespamBeGoneRemoveMEhitech.com.au | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422 http://www.hitech.com.au | QLD, 4051, AUSTRALIA. |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.hitech.com.au/
>
> Byron A. Jeff wrote:
>
> > Another thing is that the same issue I raised is still present. Presuming
> > I use a transformer and I tie one leg of the secondary to the PIC input pin,
> > where does the other leg go? GND? All the transformer does is change the
> > voltage, it does not address the issue of how to integrate the return...
>
> Well, it does. With a transformer you can safely tie one side of the
> secondary to ground. With mains input directly, you need to tie
> the neutral to the PIC "ground", but you must not connect this to a real
> ground, since not only can't you be sure the active and neutral are not
> reversed, even if the neutral really is neutral, connecting it to
> ground will trip earth-leakage detectors due to ground-loop currents.
That's the answer I've been looking for. Thanks. Any reason why the App
Note doesn't address these issues? Rhetorical question mind you...
>
> The transformer primary is easily protected from fingers; the entire
> PIC circuit is not. If you do want to float the PIC at mains potential,
> then use an isolation transformer during testing, and even then
> you still have to be careful of the transformer secondary, since it
> can kill you too. A low-voltage transformer is much safer.
But one or two other issues are raised. Since I'm trying to do zero crossing
will the transformer have any phase effects? Also since the voltage is smaller
will it not take longer from the zero crossing for the secondary to reach the
2V threashold? Meaning that the PIC detecting the zero crossing will be much
longer than if I was trying to detect directly from the 120V line.
Mind you this isn't worth getting killed over so I will use the transformer,
but I was just wondering.
Byron A Jeff wrote:
>
...........
> Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
> but I have to ask the dumb question: What's the return on the AC line? ......
Byron:
The idea in AN521 is to use the clamping action of the input protection
diodes
to turn the 115 VAC mains voltage into a square wave. The app note
shows a
5 meg resistor between the hot (black wire in US) and the input pin. I
think
your question is what to do with the white neutral wire. I think the
answer
is to put a 5 meg ohm resistor in series with it to the PIC ground.
This way
you are not concerned about improper house wiring.
On a similar note, when the origional fuzz busters came out the
manufacturer
gave instructions for the truckers to connect one wire to ground and the
other to a hot wire(no polarity needed). This worked because they used
a full wave bridge rectifier in the DC powered fuzzbuster.
PMFJI, I have not seen Appl. Note 521, but a transformer is considered to be a
separately derived voltage source by the National Electrical Code(N.E.C.)
and the voltage
across the secondary windings is of course ungrounded unless you connect one of
the windings to ground. If we are talking about 115 volts(nominal), then
normally
this is a single phase voltage and one side(one of the secondary windings)
is the
hot and one side(the opposite winding from the hot) is the grounded
neutral. Therefore, the secondary of isolation(120 volt to 120 volt) transformer
should have one winding connected to ground. This can connect to the equipment
grounding conductor(the third wire in a 3 wire plug that is not the hot or
neurtal)
or to grounded building steel, a ground rod, or other acceptable methods per
the
N.E.C. This derived ground(grounded neutral) on the secondary of the transformer
is then also connected to the power ground connection of the PIC chip. Rather or
not this is also signal ground also is a whole other topic for discussion. I
hope
this helps.
Bernie Parent, P.E.
>>
>> Byron A Jeff wrote:
>> >
>> > Well it's the holiday season and like Tim Allen it's time for me to start
>> > working on my Christmas Lights. I decided this year to soften the chasing
>> > lights scene and to use fading in and out of different strings. While my
>> > Motorola MOC3010 type circuits works fine, for dimming I need to detect
>> > zero crossings. I plan to turn the lights one an off for whole cycles
> instead
>> > of trying to triggerfor a portion of the cycle which generates that buzzing
>> > sound.
>> >
>> > Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
>> > but I have to ask the dumb question: What's the return on the AC line? I
> can't
>> > see how connecting just the hot line of the AC power is going to get you
>> > anywhere and I'm damn scared to connect the neutral up anywhere near the
>> > microcontroller.
>>
>> We've been down this path before..
>> You're best off using a transformer; you can often steal the ac input to
>> the bridge and diode clamp it to come up with a suitable cmos level
>> signal. All you need to do is overdrive the diodes enough to get fast
>> edges, maybe 3 to 5 times, and this works out to be the input to, say,
>> the 12v or 15v supply in a multi output supply. If you need a separate
>> transformer, you can get by with a really wee one.
>
>Well the transformer is definitely a possibility. But the Microchip engineers
>seemed to be real proud of the fact that the diodes on the I/O pins could
>be used for the purpose with just a resistor to limit current.
>
>Another thing is that the same issue I raised is still present. Presuming
>I use a transformer and I tie one leg of the secondary to the PIC input pin,
>where does the other leg go? GND? All the transformer does is change the
>voltage, it does not address the issue of how to integrate the return...
>
>BAJ
>
>
>
> PMFJI, I have not seen Appl. Note 521, but a transformer is considered to be a
> separately derived voltage source by the National Electrical Code(N.E.C.)
> and the voltage
> across the secondary windings is of course ungrounded unless you connect one
of
> the windings to ground.
App Note 521 specifically talks about wiring the 115V directly to the PIC
without the use of an isolation transformer. After reading here I've decided
that it's a bad idea and I plan to use a transformer.
> I hope this helps.
It really does. I'll go ahead and step the voltage down to 9VAC and detect the
zero crossings from there.
All this talk of bulky transformers and direct line connection to the
PIC makes many people nervous. Perhaps a small optoisolator to
facilitate zero detection, and a triac to 'fire' your lights ?
>----------
>From: Byron A Jeff[SMTP:KILLspambyronspamBeGoneCC.GATECH.EDU]
>Sent: Friday, December 06, 1996 12:26PM
>To: Multiple recipients of list PICLIST
>Subject: Re: Dumb question on Application Note 521
>
>>
>> PMFJI, I have not seen Appl. Note 521, but a transformer is considered to
>>be a
>> separately derived voltage source by the National Electrical Code(N.E.C.)
>> and the voltage
>> across the secondary windings is of course ungrounded unless you connect
>>one
> of
>> the windings to ground.
>
>App Note 521 specifically talks about wiring the 115V directly to the PIC
>without the use of an isolation transformer. After reading here I've decided
>that it's a bad idea and I plan to use a transformer.
>
>> I hope this helps.
>
>It really does. I'll go ahead and step the voltage down to 9VAC and detect
>the
>zero crossings from there.
>
>BAJ
>
>
> >
> > PMFJI, I have not seen Appl. Note 521, but a transformer is considered to be
a
> > separately derived voltage source by the National Electrical Code(N.E.C.)
> > and the voltage
> > across the secondary windings is of course ungrounded unless you connect one
> of
> > the windings to ground.
>
> App Note 521 specifically talks about wiring the 115V directly to the PIC
> without the use of an isolation transformer. After reading here I've decided
> that it's a bad idea and I plan to use a transformer.
>
> > I hope this helps.
>
> It really does. I'll go ahead and step the voltage down to 9VAC and detect the
> zero crossings from there.
>
> BAJ
I'm glad that you folks all have a healthy respect for mains potential,
and transformers have lots of wonderful properties, especially for those
working on the circuit itself.
However, zillions of PRODUCTS operate safely without transformer
isolation, benefiting from improvements in size, weight, efficiency, and
cost. These products are properly INSULATED, of course. Remember, even
transformers depend on INSULATION for their isolation.
I don't hesitate to design without transformer isolation. Many of my
products use series capacitor power supplies, and any mention of this
always brings out dozens of responses of the "You're crazy if you don't
use a transformer!" variety. I take comfort in the simple fact that the
vast majority of electrical products in the world don't use a
transformer. However, it is too true that knowledge and care are
essential. Electricity can kill. I use isolation transformers, battery
operated scopes, differential probes, etc. Take care.
--
Yeah, you've got to try pretty hard to kill yourself with 110-120 VAC.
Of course, we use 240+ VAC for larger loads (air conditioners and the
like), but not for general household use.
>I don't hesitate to design without transformer isolation. Many of my
>products use series capacitor power supplies, and any mention of this
>always brings out dozens of responses of the "You're crazy if you don't
>use a transformer!" variety. I take comfort in the simple fact that the
>vast majority of electrical products in the world don't use a
>transformer. However, it is too true that knowledge and care are
>essential. Electricity can kill. I use isolation transformers, battery
>operated scopes, differential probes, etc. Take care.
Could you start me off on the practical design of a series capacitor supply?
I've got a 2 channel sequencer using a 16C84 which uses a resistor-zener
supply from the 120V, 120V through a resistor for zero crossing and two
triacs driven directly from PIC pins. However, the current required by
PIC and triac drive means that the resistor has to be low enough that it
gets somewhat warm. I can see the idea of using a capacitor there but
don't know where to start in terms of cap. value or type etc.
> In article <spam_OUT32A85C12.10AESTOPspamwhidbey.com>,
> Paul Mathews <RemoveMEoptoengspamwhidbey.com> wrote:
>
> >I don't hesitate to design without transformer isolation. Many of my
> >products use series capacitor power supplies, and any mention of this
> >always brings out dozens of responses of the "You're crazy if you don't
> >use a transformer!" variety. I take comfort in the simple fact that the
> >vast majority of electrical products in the world don't use a
> >transformer. However, it is too true that knowledge and care are
> >essential. Electricity can kill. I use isolation transformers, battery
> >operated scopes, differential probes, etc. Take care.
>
> Could you start me off on the practical design of a series capacitor supply?
> I've got a 2 channel sequencer using a 16C84 which uses a resistor-zener
> supply from the 120V, 120V through a resistor for zero crossing and two
> triacs driven directly from PIC pins. However, the current required by
> PIC and triac drive means that the resistor has to be low enough that it
> gets somewhat warm. I can see the idea of using a capacitor there but
> don't know where to start in terms of cap. value or type etc.
>
> Thanks.
>
Just some thougths:
type:
The capacitor should at least be built for the AC-voltage you are using.
Important: The value for the maximum voltage for the capacitor
('Spannungsfestigkeit') has to be for 'AC' ! I think such
capacitors are called 'Mains Voltage Capacitors'
(Netzspannungskondensatoren).
value:
Let's say the maximum average current of your circuit is Iav .
The capacitor has to supply your circuit in one half-wave -->
IC_average = 2*Iav.
now the average Voltage of the capacitor during loading your circuit :
UC_average = ( sqrt(2) * 120 / pi ) - U_Zener (Hope that's right, haven't
any reference handy now)
and with Q=U*C=I*t -->
C = I*t/U = IC_average * 1/(2*f) / UC_average
Another thing:
IMHO you should use a X-capacitor ('Schaltfester
Netspannungs-Kondensator') Oh where's my english dictionary right now
???? :-(
A X-capacitor is a capacitor which works with MAINS-voltage and you can
short-circuit (also if fully loaded) without damaging it.
If you use a 'normal' main-voltage capacitor then you should use a
small series resistor (say 220 Ohm --> Imax = sqrt(2)*120 / 220 = 0.8 A)
for protecting the capacitor.
One addition:
Because of the capacitor you get a phase shift between the AC-voltage and
your load-current pulses , so your zero-detect circuit has to be
connected directly with a resistor to the AC-voltage.
bernhard.
PS.: Hope all is correct and you can understand it ! For those
words I wasn't sure about I wrote the german translation :-)
>
> In article <KILLspam32A85C12.10AEspamspam_OUTwhidbey.com>,
> Paul Mathews <optoengRemoveMEwhidbey.com> wrote:
>
> >I don't hesitate to design without transformer isolation. Many of my
> >products use series capacitor power supplies, and any mention of this
> >always brings out dozens of responses of the "You're crazy if you don't
> >use a transformer!" variety. I take comfort in the simple fact that the
> >vast majority of electrical products in the world don't use a
> >transformer. However, it is too true that knowledge and care are
> >essential. Electricity can kill. I use isolation transformers, battery
> >operated scopes, differential probes, etc. Take care.
>
> Could you start me off on the practical design of a series capacitor supply?
> I've got a 2 channel sequencer using a 16C84 which uses a resistor-zener
> supply from the 120V, 120V through a resistor for zero crossing and two
> triacs driven directly from PIC pins. However, the current required by
> PIC and triac drive means that the resistor has to be low enough that it
> gets somewhat warm. I can see the idea of using a capacitor there but
> don't know where to start in terms of cap. value or type etc.
>
> Thanks.
For 120VAC nominal, 1.0uF film capacitor rated 400VDC or 250VAC will
provide 35mA or so at a low DC voltage. You can scale the capacitance
and voltage rating up or down for other situations, but you will
probably find that many considerations lead to taking other approaches
if you need more than about 50mA. Some people insist that you should
use 2 capacitors of twice the capacitance, one connected to each line
(mains) input wire, to further isolate the circuit from the line,
especially with unpolarized plugs. My own view is that this is
unnecessary, provided that you insulate everything properly. If you
need to drive your triac(s) directly, the 2 capacitor approach
complicates things (see below).
It's wise to put some resistance in series with the AC capacitor,
preferably a carbon comp type of 100 Ohms or so, to limit the effects of
transient turn-on and high frequency noise currents. If you use SMT
thickfilm resistors, at least 3 '1206' resistors in parallel should be
substituted. Also, I recommend transient absorbing avalanche breakdown
diodes (tradenames like 'Tranzorb') instead of MOVs to protect
everything. MOVs degrade over time. One popular tranzorb P/N is
P1.5KE120CA.
The load seen by the line with series capacitance must conduct current
in both directions, and there are lots of diode and regulator
arrangements that work. Perhaps the simplest is a bridge rectifier with
a shunt regulator such as a zener diode. Of course, you need a filter
capacitor across the zener, and you may need further regulation,
depending on your requirements. The zener conducts any current not used
by the remainder of the circuitry. For a 5.1V zener, it will have a
worst case dissipation of less than a quarter Watt. If you want to use
a 5V regulator, choose a zener voltage high enough to keep the regulator
happy, > 7.5V for 78L05.
Regarding how to drive the triacs: You will discover that your circuit
'ground' is at a slightly different potential than one of the line
inputs (the rectifier forward voltages) and at a radically different
potential compared to the other (the voltage across the capacitor). One
approach to the problem of putting the triac cathode at the appropriate
potential for direct gate drive is to use additional diode(s) in series
with the triac cathode so that load currents raise its potential to
approximately the same as circuit common. Another approach is to use
optocoupler(s) to drive the triac(s), or, for light loads, use triac
output optocouplers. Have a look at Motorola MOC3021 or similar.
Of course, the 'common' or 'signal ground' potential of your circuit
will ride on the line waveform, and makes for some interesting
oscilloscope probing problems. Please be careful to use isolation
transformers, etc. when you're working with a live circuit. In fact,
avoid using the line power input as long as possible and whenever
possible during development. You may find that much of your development
work can be done with a dc supply, particularly if you use optocoupler
drive. Alternatively, consider using 24VAC during development: scale
the capacitance up to 5uF or so (film cap rated ~100VDC).
Film capacitors come in lots of shapes and sizes. Good small ones are
made by Illinois Capacitor and Paktron, among others.
--
Bernhard Schweighofer wrote:
>
....<snip>
> Just some thougths:
>
> type:
> The capacitor should at least be built for the AC-voltage you are using.
> Important: The value for the maximum voltage for the capacitor
> ('Spannungsfestigkeit') has to be for 'AC' ! I think such
> capacitors are called 'Mains Voltage Capacitors'
For the low currents contemplated for miniature products, most film caps
with adequate voltage ratings will be OK, and most are 'self-healing'
for voltage overloads. Just remember that DC voltage ratings must be at
least root 2 x higher than AC ratings. Also, voltage transients do
happen, constantly, so design in a margin.
> (Netzspannungskondensatoren).
>
> value:
> Let's say the maximum average current of your circuit is Iav .
> The capacitor has to supply your circuit in one half-wave -->
> IC_average = 2*Iav.
> now the average Voltage of the capacitor during loading your circuit :
> UC_average = ( sqrt(2) * 120 / pi ) - U_Zener (Hope that's right, haven't
> any reference handy now)
>
> and with Q=U*C=I*t -->
>
> C = I*t/U = IC_average * 1/(2*f) / UC_average
>
> Another thing:
> IMHO you should use a X-capacitor ('Schaltfester
> Netspannungs-Kondensator') Oh where's my english dictionary right now
> ???? :-(
> A X-capacitor is a capacitor which works with MAINS-voltage and you can
> short-circuit (also if fully loaded) without damaging it.
> If you use a 'normal' main-voltage capacitor then you should use a
> small series resistor (say 220 Ohm --> Imax = sqrt(2)*120 / 220 = 0.8 A)
> for protecting the capacitor.
Yes. The resistor(s) should be a type that doesn't emit flames or smoke
when failing. Beware that thickfilm chip resistors have poor overload
characteristics.
>
> One addition:
> Because of the capacitor you get a phase shift between the AC-voltage and
> your load-current pulses , so your zero-detect circuit has to be
> connected directly with a resistor to the AC-voltage.
>
Good point. You can still use the high-value-resistor method here, or
correct for the phase shift in software.
> bernhard.
>
> PS.: Hope all is correct and you can understand it ! For those
> words I wasn't sure about I wrote the german translation :-)
>
> Bernhard Schweighofer alias spam_OUTschweigiRemoveMEEraseMEsbox.tu-graz.ac.at
> (Student at Graz University of Technology, Austria)
Byron A Jeff wrote:
>
> >
> > 1) That's not a dumb question - you can have lots of fun with mains failure
> > when you bring the neutral close to the "ground".
>
> I thought so.
>
> >
> > 2) Provided your circuit operates from the live and neutral ONLY, you may
> > attach the neutral to the 0V (ground) - unless of course some dumb idiot
> > wire the power to you with the live and neutral swapped - do first check
that.
>
> Yup that is definitely a possibility. I was planning to drive this circuit
> with a wall wart. But it's easy enough to build a quick 5V supply. But the
> same issue are still there. Presuming I'm using an integrated bridge rectifier
> does it matter which leg of the secondary is connected to ground and which
> leg is connected to the input pin?
>
> BAJ
no not if you want only power and you use a transformer "for safety"
reversing the secondary leads only counts if the sine wave needs to be
in phase.Like coupling two transformers.I did not read the data sheet
you alluded to. However if I understand what you are trying to do :power
the pic and derive a sync signal for controlling a triac optocoupler
to enable zero crossing switching: then you may derive the sync signal
from the input to the bridge rectifier and the return path will be the
bridge rectifier giving a half wave current limit that and you're on
your way as to the pic itself thats what I'm here to learn.
ps batteries might last to christmas optically coupled this sounds like
fun.
...I just thought of something use a zero crossing triac output
optocoupler with a battery powered pic and to heck with the sync
signal,propagation delays,troubleshooting hazards etc.
Byron A Jeff wrote:
>
> Well it's the holiday season and like Tim Allen it's time for me to start
> working on my Christmas Lights. I decided this year to soften the chasing
> lights scene and to use fading in and out of different strings. While my
> Motorola MOC3010 type circuits works fine, for dimming I need to detect
> zero crossings. I plan to turn the lights one an off for whole cycles instead
> of trying to triggerfor a portion of the cycle which generates that buzzing
> sound.
>
> Enter AppNote 521 "Interfacing to AC Power Lines". Conceptually it's simple
> but I have to ask the dumb question: What's the return on the AC line? I can't
> see how connecting just the hot line of the AC power is going to get you
> anywhere and I'm damn scared to connect the neutral up anywhere near the
> microcontroller.
>
> Can anyone clarify?
>
> BAJ
BYRON if your running your lights from 220/110 volts and your control
box is plastic
with no exposed metal parts, and if you feel comfortable developing the
system
then there is no reason not to use a direct connection to the mains
you can use a resistor, cap or both to drop your voltage from the mains
voltage
to power the pic with no transformer
I would only condone this method if the circuit is totaly isolated (no
exposed metal parts)
preferably no user controls or switches and designed so that
Live/Neutral reversal
would not present a problem
A .1mF cap at 50 hz has an approx resistance of 31k at 220V gives 7mA
.47mF = 6k7 32mA
1mF = 3k1 69mA
At 60Hz the resistance would be lower and curent less
--
Peter Cousens
email: spampeter.....spamcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,
phone: + 3081 380534, +3081 324450 voice/fax
After Bill Gates announced to the world that he was Microsoft,
his wife was asked to comment. She said that as his wife, she
had been the first to notice this problem
Good summary. I realize that HV Caps are completely different beasts from
the low voltage ones.
What I was trying to say was (and I probably should have been a lot more
explicit), there are a lot of issues with capacitors and before specifying
them, you have to make sure they are appropriate for the application.
myke
Paul wrote...
>Myke, first please note the following excerpt from one of my msgs, and...
Today, the commercial sector is advancing computer and communication
technology at a breakneck pace. In 1992, optical fiber was being installed
within the continental U.S. at rates approaching the speed of sound (if
computed as total miles of fiber divided by the number of seconds in the year).
Aviation Week and Space Technology, October 28, 1996
To save the troubles of zero crossing detection just use a opto-coupler
with zero-crossing detection built in. Toshiba make some that are
surprisingly cheap.
The one I have used is a TLP3063 (this is more or less an industry standard
number).
It will directly fire a TRIAC.
If you don't need to turn on for less than one half cycle then this is the
easy way.
You could then easily run your project off a battery as the opto-coupler
only needs about 5mA.
This has turned out to be a long interesting thread...
Cheers
Dennis
____________________________________________________
FROST - Electronic Design, Manufacture & Consulting.
Dennis Frost
Tel: +27 331 965125
Cel: +83 2275216
Email: dennis.frostKILLspamEraseMEpixie.co.za
Pietermaritzburg, South Africa
____________________________________________________
>
> To save the troubles of zero crossing detection just use a opto-coupler
> with zero-crossing detection built in. Toshiba make some that are
> surprisingly cheap.
I know. I just happen to have all the MOC3010's I need for this project.
And as the app note points out all that's really needed is a single
high valued resistor. Now Tech Brief 008 on the web site points out
that the best way to be sure that you don't slag anything is to fuse the
ground and neutral lines together. That way if you get an incorrectly
wired socket such that hot is on the wrong line, then the fuse will
immediately blow saving both the house circuitry and the project.
> The one I have used is a TLP3063 (this is more or less an industry standard
> number).
> It will directly fire a TRIAC.
> If you don't need to turn on for less than one half cycle then this is the
> easy way.
> You could then easily run your project off a battery as the opto-coupler
> only needs about 5mA.
Power was never ever the issue. It was gravy to learn how to design and
use transformerless power supplies.
BAJ
>
> This has turned out to be a long interesting thread...
The original application for the thread was to control
AC mains lights
There is another way to control AC mains that does
involve zero crossing
It does require a few more components but the results
are superb
It's suitable for lights, motor control and many other AC
mains apps
The components that follow are for 220V
You run the AC through your load, in series with a bridge rectifier.
The +/- you connect to a cap (1 or 2 microFarad 400V, parallel up some
.47's )
in parallel with a transistor (eg. TIPL 760 )with a 220 Ohms 50W
(depends
on the power you want to draw) in series (in the collector)
to limit the current to a safe level.
A MPSA 42 to drive it, a BC 549 to drive the MPSA, which is driven buy
an opto
Power for the "hot side" is taken from the mains via a 22k 1 watt
resistor
The opto is driven non from syncronised PWM direct from the Pic.
The TIPL 760 works in switch mode and shorts out the bridge via the 220
Ohms
resistor the entire circuit is very efficent
and should handle at least 100 Watts probabaly more
After Bill Gates announced to the world that he was Microsoft,
his wife was asked to comment. She said that as his wife, she
had been the first to notice this problem
I am a new subscriber to the pic list and I was wondering if anyone had compiled a list of pic apps from questions and projects people have posted to the list any help would be appreciated!!!
Cory D. Raak
Electronics Technician
PCB Developer
Gentex Corporation
Email @spam@coryrspamKILLspamgntx.com
"You either do or do not. There is no try." Yoda
P> I am a new subscriber to the pic list and I was wondering if anyone
P> had = compiled a list of pic apps from questions and projects people
P> have = posted to the list any help would be appreciated!!!
P> I am a new subscriber to the pic list and I was wondering if anyone
P> had = compiled a list of pic apps from questions and projects people
P> have = posted to the list any help would be appreciated!!!
There are several levels to such an application, hardware access probably
the easiest, assuming some form of user interaction. I wrote a display
manager that handled 4 x 20 display and a 4x4 keypad (the keypad was on
another chip), centered text lines, European accented characters, text and
numeric entry fields, editing, including backspacing, insertion of choices
from a list and so on. It can be done, I managed to fit it all on a 57
with a 2-wire serial command/keystroke/reply interface and an I2C bus to
access menu text.
The LCD I used was really easy at the hardware level: parallel 8 bit data,
a command/data line, and a clock/strobe. The biggest problem was the
strobe length: it varied depending on data or command type.
The point I'm trying to make is: what are you going to do with this LCD?
Static display of status messages, or user interaction. PIC, PC or
mainframe, design it carefully right from the start.
While we are on a LCD thread. There is 4 and 8 bit parallel
C code on our BBS. It is essentially the same as any one
of a multitude of other code packages except it is written
in C and the same source works on 9 or 10 platforms with
no changes other than port definitions.
Does anyone have a favorite graphics display with 64 *128 to
128 * 256 resolution? How about touch overlays?
I have an LCD display that I have been wanting to find hookup data on.
The display area is 5.9" X 1.7". The driver chip is a HD61830AOO (just one)
and on the back of the pcb is the number _LM213XB_ . Any info on where I
could get info is much appreciated. Thanx in advance.
kim walker
> While we are on a LCD thread. There is 4 and 8 bit parallel
> C code on our BBS. It is essentially the same as any one
> of a multitude of other code packages except it is written
> in C and the same source works on 9 or 10 platforms with
> no changes other than port definitions.
>
> Does anyone have a favorite graphics display with 64 *128 to
> 128 * 256 resolution? How about touch overlays?
>
> Walter Banks
>
>I have an LCD display that I have been wanting to find hookup data on.
>The display area is 5.9" X 1.7". The driver chip is a HD61830AOO (just one)
>and on the back of the pcb is the number _LM213XB_ . Any info on where I
>could get info is much appreciated. Thanx in advance.
This is an Hitachi chip. Their LCD data book contains the info
you need. If I'm back at my office between now and Monday (and
nobody else has given you more info) I will put some details on
the list.
___Bob
(or you could just call Hitachi and demand they support your use
of the component :) )
Some time ago we had a discussion on handy serial comms monitoring
programs. One of my collegues wrote a WIN95 app that shows you what
goes on on two serial lines at all the baudrates, parity etc.
It has two windows that scroll together, so you can see how your
horrible PIC program responds to incoming data and vice versa.
It only READS the RS232, not write.
If you want it, drop me e-mail.
NOTE : It only works on WIN95 an WINDOWS NT. We are *NOT* going to
do it for Unix, Apple, your pocket calculator or any other platform,
so DON'T EVEN ASK.
--
Friendly Regards
Tjaart van der Walt
______________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| WASP International |
| GSM and GPS value-added applications |
|+27-(0)11-622-8686 | http://wasp.co.za | TakeThisOuTtjaartwasp.co.za |
|______________________________________________________________|
Sorry for using the list for this reply, but I've received
stacks&stacks of requests for the app. We are working on it to
make it a bit more user-friendly, so please be patient.
Please note that there is no user manual and the software is for free.
If I'm asked by enough people, and Jory OK's it, I'll mail the software
to the list, otherwise I'll mail it directly.
--
Friendly Regards
Tjaart van der Walt spamBeGonetjaartKILLspamTakeThisOuTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| ASP International http://wasp.co.za |
| GSM and GPS value-added applications |
| Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8686 |
|_____________________________________________________________|
We are still working on it - please be patient. I've had offers
of posting the software onto websites and archives, and think it
is probably a good idea.
--
Friendly Regards
Tjaart van der Walt EraseMEtjaart.....KILLspamwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| ASP International http://wasp.co.za |
| GSM and GPS value-added applications |
| Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8686 |
|_____________________________________________________________|
I hope that someone on the PIC list can help me to help someone else. I
design units (using PICs) to try and assist handicapped people in a
Sheltered Workshop environment.
BACKGROUND
One person has severe muscular dystrophy - his muscles have completely
wasted away. He now cannot walk, move his arms or sit up. It really is
sad and upsetting to see him. The only thing he can do is to watch TV or
try to use a computer. Unfortunately he cannot move his arms properly in
order to fully operate a mouse or the keyboard. He can just move his
fingers.
I am therefore trying to use a small rotary encoder connect to a PIC, to
send ASCII characters to his PC's com port. I have sorted out the PIC side
and can read the rotary encoder and send out ASCII ok.
However, I need to write a PC utility which needs to read the PC's serial
port and display the received character on a small window on the PC (always
in front). It is not useful to display the ACSII character on a separate
LCD connected to the PIC as this would require him to move his head
unnecessarily - hence the reason for displaying the character on the PC.
When this PC utility receives, eg $03 ASCII (which will be sent when he
presses a big button connected to the PIC) it is to drop the current
character displayed in the small PC window into the PC keyboard buffer. If
he was in a word processor that character should then be picked out of the
keyboard buffer and dropped into his document.
I therefore need software source (so that it can be modified) or guidance
on how
to write a PC utility for Windows 95 to:
- Create a small resizable window always in front.
- To always run even in the background.
- To keep looking and receiving data from a com port
(which is user selectable)
- To display the received char in the window (font and size selectable).
- When ASCII $03 (or another special char, which is user selectable) is
received, to drop the last ASCII character, as currently displayed in the
small window, into the keyboard keyin buffer.
- To signal to the PC low level keyin routines that a 'keyboard' key press
has occurred and the character is in the buffer.
- The other standard program should then pick up the character and use it
as normal, thus dropping it into the document being written.
I have done the PIC program OK.
I really need help with the PC side as I simply have not got a clue. ( I
have just bought Borland Delphi for the PC and I am struggling as I have
never programmed a PC before - I have only used Macintosh).
I would like to help this unfortunate person hence my request to the LIST
for assistance, even though the PIC side has been done.
Many thanks
----- from Stephen H Alsop, JP at -----
email: spams.ssystemseasynet.co.uk
www : http://easyweb.easynet.co.uk/~s.ssystems
S&S Systems Ltd, Bretton Court, Manor Road
Wales Village, Sheffield, S31 8PD, England.
Tel: 01909 773399 * Fax: 01909 773645 * Mobile: 0973 305527
:
: I hope that someone on the PIC list can help me to help someone else. I
: design units (using PICs) to try and assist handicapped people in a
: Sheltered Workshop environment.
:
: BACKGROUND
: One person has severe muscular dystrophy - his muscles have completely
: wasted away. He now cannot walk, move his arms or sit up. It really is
: sad and upsetting to see him. The only thing he can do is to watch TV or
: try to use a computer. Unfortunately he cannot move his arms properly in
: order to fully operate a mouse or the keyboard. He can just move his
: fingers.
:
: I am therefore trying to use a small rotary encoder connect to a PIC, to
: send ASCII characters to his PC's com port. I have sorted out the PIC
side
: and can read the rotary encoder and send out ASCII ok.
:
: However, I need to write a PC utility which needs to read the PC's serial
: port and display the received character on a small window on the PC
(always
: in front). It is not useful to display the ACSII character on a separate
: LCD connected to the PIC as this would require him to move his head
: unnecessarily - hence the reason for displaying the character on the PC.
:
: When this PC utility receives, eg $03 ASCII (which will be sent when he
: presses a big button connected to the PIC) it is to drop the current
: character displayed in the small PC window into the PC keyboard buffer.
If
: he was in a word processor that character should then be picked out of
the
: keyboard buffer and dropped into his document.
:
:
: I therefore need software source (so that it can be modified) or guidance
: on how
: to write a PC utility for Windows 95 to:
:
: - Create a small resizable window always in front.
: - To always run even in the background.
: - To keep looking and receiving data from a com port
: (which is user selectable)
: - To display the received char in the window (font and size selectable).
: - When ASCII $03 (or another special char, which is user selectable) is
: received, to drop the last ASCII character, as currently displayed in
the
: small window, into the keyboard keyin buffer.
: - To signal to the PC low level keyin routines that a 'keyboard' key
press
: has occurred and the character is in the buffer.
: - The other standard program should then pick up the character and use it
: as normal, thus dropping it into the document being written.
:
: I have done the PIC program OK.
:
: I really need help with the PC side as I simply have not got a clue. ( I
: have just bought Borland Delphi for the PC and I am struggling as I have
: never programmed a PC before - I have only used Macintosh).
:
: I would like to help this unfortunate person hence my request to the LIST
: for assistance, even though the PIC side has been done.
:
: Many thanks
:
: ----- from Stephen H Alsop, JP at -----
: email: s.ssystemsSTOPspameasynet.co.uk
: www : http://easyweb.easynet.co.uk/~s.ssystems
: S&S Systems Ltd, Bretton Court, Manor Road
: Wales Village, Sheffield, S31 8PD, England.
: Tel: 01909 773399 * Fax: 01909 773645 * Mobile: 0973 305527
:
> However, I need to write a PC utility which needs to read the PC's serial
> port and display the received character on a small window on the PC
(always
Well, delphi seems like a good place to start except that your not going to
have the low-level access to actually place the character in the keyboard
buffer unless you write a DLL and/or .ASM driver. However, a quick/dirty
way of doing this might be to use 2 serial ports, and spit the character
bakc out of the PC (using .com drivers built into Delphi) and into the PC's
now empty Keyboard port (Just a serial port in itself). But I think you
should be able to use it as it is and spit the character back at the PIC's
serial port, then have the PIC bit-bang it into the PC's Keyboard port.
Protocol for the PC's keyboard port may not even have to be learned if you
get the right adapter--- (RS232 ---> keyboard, IO ---> keyboard, etc....)
Stephen H Alsop wrote:
>
> I hope that someone on the PIC list can help me to help someone else. I
> design units (using PICs) to try and assist handicapped people in a
> Sheltered Workshop environment.
> Huge Great Snip
OK Steve following our telephone conversation I have also enlisted the
help of a fellow programmer of mine called Phill Cozens who will be
emailing you also.
Now as I said on the telephone the method of getting a char from the
com port and placing it into the keyboard buffer is quite simple.
The big problem you will face is that what ever application cas the
current focus will be the one to process it.
This can also be worked around by getting the instance of all running
applications and selecting the one of interest and sending the
WM_KEYDOWN message to that window.
I will put together a rough prototype over the next few days and get it
to you. just to confirm the protocols will be 9600,8,n,1 (with no H/W
handshaking) the "commit" char will be ASC 03.
Cheeers Peter.........
==================================
= New Ideas come from those who =
= didn't know it wasn't possible =
==================================
What you are describing sounds an awful lot like a mouse or trackball. Is
there some reason that you are not using a miniature trackball ???
If you want to "replace" the keyboard with your PIC based device, you could
have it emulate a keyboard (send out scan codes when the big button is
pushed) and just plug it into the keyboard port on your PC. If there is a
requirement for limited eye movement, I would consider simply mounting a
small LCD display on the edge of the monitor with velcro. The advantage of
this approach is that the pseudo keyboard device would work with almost any
PC or PC application...
>> However, I need to write a PC utility which needs to read the PC's serial
>> port and display the received character on a small window on the PC
>(always
>
>Well, delphi seems like a good place to start except that your not going to
>have the low-level access to actually place the character in the keyboard
>buffer unless you write a DLL and/or .ASM driver. However, a quick/dirty
>way of doing this might be to use 2 serial ports, and spit the character
>bakc out of the PC (using .com drivers built into Delphi) and into the PC's
>now empty Keyboard port (Just a serial port in itself). But I think you
>should be able to use it as it is and spit the character back at the PIC's
>serial port, then have the PIC bit-bang it into the PC's Keyboard port.
>Protocol for the PC's keyboard port may not even have to be learned if you
>get the right adapter--- (RS232 ---> keyboard, IO ---> keyboard, etc....)
>
>
I think the problem here is that as the potential user has limited
control over his hands and fingers, he needs to be able to see
which character will be sent to the keybaord buffer before it is
sent. Other wise he will have a lot of back-spacing to do.
I can only give you ideas on part of the problem you are trying to
solve. Several people have written routines to allow one to put a PIC
in the electrical path between the keyboard and the P.C. The PIC can then
exercise the keyboard data lines to fake key presses. Another factor you will
need to think of when trying to stuff the keyboard buffer is that there are
two characters that get stuffed. One is a byte called a scan code and the
other, supplied by the operating system, is the character. Different
keyboards such as the 83-key type or the AT-style keyboard generate totally
different scan codes for the same keys so you will have to design your
system for the right style keyboard or even several styles. You could
still use a com port for the letter preview function, but the actual sending
process to the buffer is probably easier if you can actually fake key strokes
to the keyboard input port.
>
> I hope that someone on the PIC list can help me to help someone else. I
> design units (using PICs) to try and assist handicapped people in a
> Sheltered Workshop environment.
>
> BACKGROUND
> One person has severe muscular dystrophy - his muscles have completely
> wasted away. He now cannot walk, move his arms or sit up. It really is
> sad and upsetting to see him. The only thing he can do is to watch TV or
> try to use a computer. Unfortunately he cannot move his arms properly in
> order to fully operate a mouse or the keyboard. He can just move his
> fingers.
>
> I am therefore trying to use a small rotary encoder connect to a PIC, to
> send ASCII characters to his PC's com port. I have sorted out the PIC side
> and can read the rotary encoder and send out ASCII ok.
>
> However, I need to write a PC utility which needs to read the PC's serial
> port and display the received character on a small window on the PC (always
> in front). It is not useful to display the ACSII character on a separate
> LCD connected to the PIC as this would require him to move his head
> unnecessarily - hence the reason for displaying the character on the PC.
>
> When this PC utility receives, eg $03 ASCII (which will be sent when he
> presses a big button connected to the PIC) it is to drop the current
> character displayed in the small PC window into the PC keyboard buffer. If
> he was in a word processor that character should then be picked out of the
> keyboard buffer and dropped into his document.
--- snip ---
>
> I would like to help this unfortunate person hence my request to the LIST
> for assistance, even though the PIC side has been done.
>
> Many thanks
>
Win95 has in-built access features for people with disabilities. On is the
ability to take ASCII from a serial
port and insert it into the keyboard stream. I know this is not exactly what
you want as it would then need an
external display, but is an alternative if your project bogs down.
Another option is an on-screen keyboard such as WiViK. This lets you use
switches (1 to 5) or a pointing
device(mouse, pad) to select functions via a scanning method, dwelling on the
key or clicking the mouse. It is
not a cheap option (about AUD$1200-000 but is excellent. I have worked with a
number of people with
disabilities using WiViK, in particular, one man with very advanced MND who used
a BBS for communication and
wrote a book using one finger.
I'm actually working in a similar project. The person here is a girl (Maria)
and has similar muscular problems as you describe.
Some time ago I posted a message in EDESIGN mail list. Didn't want to make
it in the PICLIST because of the off-topic matter. I got a real bunch of
messages offering good ideas to make the interface and also a lot of very
useful URLs to have a look.
There are a few companys manufacturing computer interfaces for disables
people. They do also provide the Windows drivers and all the programs you
will need, so think is real worth to have a look around in the web and see
what's already in the market.
Richard Jackson wrote:
>
>
> > BACKGROUND
> > One person has severe muscular dystrophy - his muscles have completely
> > wasted away. He now cannot walk, move his arms or sit up. It really is
> > sad and upsetting to see him. The only thing he can do is to watch TV or
> > try to use a computer. Unfortunately he cannot move his arms properly in
> > order to fully operate a mouse or the keyboard. He can just move his
> > fingers.
> Another option is an on-screen keyboard such as WiViK. This lets you use
> switches (1 to 5) or a pointing
> device(mouse, pad) to select functions via a scanning method, dwelling on the
> key or clicking the mouse. It is
> not a cheap option (about AUD$1200-000 but is excellent. I have worked with a
> number of people with
> disabilities using WiViK, in particular, one man with very advanced MND who
used
> a BBS for communication and
> wrote a book using one finger.
>
> Richard Jackson
>
> Adelaide S. Aust
I also have a friend that has big problems (because a broken neck): can
You indicate me a place where is possible to get more information about
those or similar devices .
Do know other ways to get information about such systems to let people
communicate with computer ???
thanks in advance!!!
gaspare
I am writing code to use the PIC chip as a classic embedded controller.
One of the commands I would like to implement is a remote reset. This
would allow the controlling system to issue a command that would tell the
PIC to restart and re initialize itself.
Is there an easy way to reset the PIC processor from a running application ???
The PIC in this particular endeavor is a 16C73A...
At 06:19 PM 17/2/97 -0500, you wrote:
>Greetings,
>
>I am writing code to use the PIC chip as a classic embedded controller.
>One of the commands I would like to implement is a remote reset. This
>would allow the controlling system to issue a command that would tell the
>PIC to restart and re initialize itself.
>
>Is there an easy way to reset the PIC processor from a running application ???
>
>The PIC in this particular endeavor is a 16C73A...
you could just fall into loop and wait for Watchdog reset to happen.
(you must have Watchdog enabled)
there is no direct commands to implement reset in software.
What about just a GOTO to address 00 ? This will restart the code as if
a power-on reset occurred. In your initilization routine, you will have
to set all the flags and options to known states. But, I do not see why
it would not work. Have I overlooked something?
---- Steve
----------
From: pic microcontroller discussion [SMTP:PICLIST.....MITVMA.MIT.EDU]
Sent: Monday, February 17, 1997 6:19 PM
To: PICLIST
Subject: Application controlled reset ???
Greetings,
I am writing code to use the PIC chip as a classic embedded controller.
One of the commands I would like to implement is a remote reset. This
would allow the controlling system to issue a command that would tell the
PIC to restart and re initialize itself.
Is there an easy way to reset the PIC processor from a running
application ???
The PIC in this particular endeavor is a 16C73A...
At 05:50 PM 17/2/97 -0600, you wrote:
> What about just a GOTO to address 00 ? This will restart the code as if
>a power-on reset occurred. In your initilization routine, you will have
>to set all the flags and options to known states. But, I do not see why
>it would not work. Have I overlooked something?
>
> ---- Steve
GOTO 00 is not same as (COLD)reset. It depends on application program
what happends by GOTO 00, if the program expect to be running after
reset, ie expect some re-gisters have "reset" value, then GOTO 00
might just hang your program.
If your application originally began from a 'START' address, then if
a reset condition occurred you could GOTO a 'STARTB' address which
can leave some flags in a known state.
If an input pin going low will cause the reset condition then a flag
could be set indicating the reset. The 'STARTB' address does not
clear this flag, so the normal programs execution will ignore the low input
and clear the flag when this input goes high again.
Tony
Just when I thought I knew it all,
I learned that I didn't.
Now, When you wanted to reset the device, enable the Pin to be low and the
PIC will reset itself. When the PIC resets, all the I/O Ports go back to
Input and the _MCLR line goes back up high and you can start executing from
the beginning with a reset PIC again.
The reset code would be:
bcf PORTn, Pin ; Make Sure the Pin is Low
bsf STATUS, RP0
bcf TRISn, Pin ; Enable the Pin
bcf STATUS, RP0
goto $
The last two instructions would be for "safety", but probably wouldn't be
executed. If an open collector (RA4) Pin was used, then the move to Bank1
wouldn't be required and the code would simply be:
bcf PORTA, 4
If it's an 18 Pin device, this really gets easy because RA4 is beside _MCLR.
>If your application originally began from a 'START' address, then if
>a reset condition occurred you could GOTO a 'STARTB' address which
>can leave some flags in a known state.
>
>If an input pin going low will cause the reset condition then a flag
>could be set indicating the reset. The 'STARTB' address does not
>clear this flag, so the normal programs execution will ignore the low input
>and clear the flag when this input goes high again.
>
>Tony
>
>
>Just when I thought I knew it all,
>I learned that I didn't.
>
>
"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne
Bob Segrest wrote:
>
> Greetings,
>
> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset. This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...
>
> Bob Segrest
I use a similar command. Clear PCLATH and PCL. It works fine for me,
because
I save the output states in EEPROM, so when the PIC starts up, its loads
all
the default output values.
The stack overflows badly when you do this, so the emulator doesn't like
the
command, but it works well in the OTP parts.
--
Friendly Regards
Tjaart van der Walt KILLspamtjaartspam_OUTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| ASP International http://wasp.co.za |
| GSM and GPS value-added applications |
| Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8686 |
|_____________________________________________________________|
In a message dated 97-02-17 18:30:14 EST, you write:
<<
At 06:19 PM 17/2/97 -0500, you wrote:
>Greetings,
>
>I am writing code to use the PIC chip as a classic embedded controller.
>One of the commands I would like to implement is a remote reset. This
>would allow the controlling system to issue a command that would tell the
>PIC to restart and re initialize itself.
>
>Is there an easy way to reset the PIC processor from a running application
???
>
>The PIC in this particular endeavor is a 16C73A...
you could just fall into loop and wait for Watchdog reset to happen.
(you must have Watchdog enabled)
there is no direct commands to implement reset in software.
antti
>>
Now for my 2 cents worth.
One way that I have implemented this sort of thing is to use the Watchdog
timer to automatically reset the chip if it does not recieve a signal from
the host etc.
A periodic signal generated from a host computer prevents the remote
controllers from resetting. If the signal is not there the remote will
reset.
If there is no host computer you could implement a reset instruction using
the watch dog timer by simply jumping to a tight loop that does not clear the
WDT. The net result will be a reset in a few milliseconds.
Hope this helps
Dave Duley
V.P. DreiTek Inc.
At 11:57 AM 17/02/1997 -0400, you wrote:
>At 05:50 PM 17/2/97 -0600, you wrote:
>> What about just a GOTO to address 00 ? This will restart the code as if
>>a power-on reset occurred. In your initilization routine, you will have
>>to set all the flags and options to known states. But, I do not see why
>>it would not work. Have I overlooked something?
>>
>> ---- Steve
>
>GOTO 00 is not same as (COLD)reset. It depends on application program
>what happends by GOTO 00, if the program expect to be running after
>reset, ie expect some re-gisters have "reset" value, then GOTO 00
>might just hang your program.
>
>antti
Personally I have never considered it wise to rely on what state the
hardware might be in after a cold start. I believe robust programming means
initializing every thing to the state you want it right after power up and
before you use those peripherals.
So having said that I would jump t a routine that would a) disable all
interrupts if your flavour of the PIC has them and b) GOTO zero. If that
hangs your program you probably deserve it. <grin>
John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc. Ph. 1-250-544-4950
PO Box 20002 Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9
> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset. This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...
I have used a I/O pin in the past to reset PICs and Parallax Stamps.
Just connect your remaining pin to the _MCLR pin and when you want
to reset you just drive the pin to an output and then write a
zero to it. This is very effective and clears the condition on the
pin when the chip has reset as the pins all change to inputs
after the reset.
The other alternative of letting the watchdog run-out by turning
off interrupts and running in a tight loop would cause a reset
from about 20 ms to 2 seconds later (depending on the watchdog
prescaler). This requires you to have the watchdog fuse enabled
and also the reset will not be exactly the same as a MCLR reset.
You also need to service the watchdog in the rest of your code.
This option is not available with most of the preprogrammed interpreter
chips like the Stamps which is why I used the first method above.
Perhaps better yet is to use a pin to short the supply rail to ground
with the help of an external transistor that will cause a genuine
cold reset. This might be requiired by some of the periferals
on some of the early silicon that had some quirks where a WD
or MCLR reset were nor enough to clear a stuck periferal (UART
I think was the problem one)
> From: John Dammeyer <.....johnd.....RemoveMEISLANDNET.COM>
>
> >
> >GOTO 00 is not same as (COLD)reset. It depends on application program
> >what happends by GOTO 00, if the program expect to be running after
> >reset, ie expect some re-gisters have "reset" value, then GOTO 00
> >might just hang your program.
> >
> >antti
> Personally I have never considered it wise to rely on what state the
> hardware might be in after a cold start. I believe robust programming means
> initializing every thing to the state you want it right after power up and
> before you use those peripherals.
>
> So having said that I would jump t a routine that would a) disable all
> interrupts if your flavour of the PIC has them and b) GOTO zero. If that
> hangs your program you probably deserve it. <grin>
It's no _less_ wise to rely on the published reset state than to rely
on the machine's correct execution of your initialisation code.
Really, in a small ram machine you shouldn't be wasting space doing
something which the manufacturer has guaranteed will be done for
you. I will concede, however, that you should document any reliance
on reset state.
In the case of the original posting, where it is desired to simulate
a reset, then the above paragraph is not entirely true. Nevertheless
one cannot truly simulate a reset by executing instructions from location
zero. For a start, assertion of !MCLR immediately puts all port pins
in a high impedance state. This cannot be done by sequential instructions
since only one port can be hi-Z'd(*) at once. Also, are you _really_
going to go to the trouble of randomising your file registers?
Regards,
SJH
Canberra, Australia
(*) Some times I envy the American pronunciation of 'Z' (zee) since
it is much easier to say 'hi-zeed' than 'hi-zeded'. Also the
American use of 'EZ' (easy) looks all wrong in the English speaking
world - eezed?
Bob Segrest wrote:
>
> Greetings,
>
> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset. This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...
>
> Bob Segrest
The way I normaly do it is to use the watchdog timer in the program as
normal.
when I want a reset I go into a loop eg:
'It was five hours of Boggs's "channelling". After three hours
I asked him to summon up the soul of Jimi Hendrix and requested
All Along the Watchtower. You know, the guy's been dead
twenty years but he still hasn't lost his edge'
Mulder
>> From: John Dammeyer <RemoveMEjohndspamBeGonespamISLANDNET.COM>
>>
>> >
>> >GOTO 00 is not same as (COLD)reset. It depends on application program
>> >what happends by GOTO 00, if the program expect to be running after
>> >reset, ie expect some re-gisters have "reset" value, then GOTO 00
>> >might just hang your program.
>> >
>> >antti
>> Personally I have never considered it wise to rely on what state the
>> hardware might be in after a cold start. I believe robust programming means
>> initializing every thing to the state you want it right after power up and
>> before you use those peripherals.
>>
>> So having said that I would jump t a routine that would a) disable all
>> interrupts if your flavour of the PIC has them and b) GOTO zero. If that
>> hangs your program you probably deserve it. <grin>
>
>It's no _less_ wise to rely on the published reset state than to rely
>on the machine's correct execution of your initialisation code.
>
>Really, in a small ram machine you shouldn't be wasting space doing
>something which the manufacturer has guaranteed will be done for
>you.
If you never change what was done by the manufacturer after a power on reset
I suppose it will still be the same after a 'warm' start. However relying
on that can be catastrophic if the manufacturer changes something in a chip
revision that is perhaps not fundamental to the operation of the of the
processor but convenient for manufacturing.
>I will concede, however, that you should document any reliance
>on reset state.
I agree.
>
>In the case of the original posting, where it is desired to simulate
>a reset, then the above paragraph is not entirely true. Nevertheless
>one cannot truly simulate a reset by executing instructions from location
>zero. For a start, assertion of !MCLR immediately puts all port pins
>in a high impedance state. This cannot be done by sequential instructions
>since only one port can be hi-Z'd(*) at once.
If the ports are required to be in a HiZ state for some type of operation
and you cannot do that explicitly then perhaps we are discussing poor
programming or design practices and insisting that we be able to practice
them.
>Also, are you _really_
>going to go to the trouble of randomising your file registers?
Why on earth would you want to do that? I have seen C programmers get into
trouble by using auto-initialization for their variables and then when they
emulate a soft reset wonder why programs blow up. Relying on random
variable values is even more dangerous.
int i = 5; is a perfect example of a variable that is initialized by startup
code.
Unless that re-startup is emulated perfectly, relying on i == 5 is
dangerous. If there is a _need_ for a system initiated restart -
non-watchdog - then the initialization of i belongs in an init function.
When Pascal was developed auto init was not included; I believe for a good
reason. By forcing a programmer to deliberately set variables to what they
must be, there is an element of repeatability in the application.
In an embedded system, that can be as explicit as copying a series of values
contained in ROM into the variables; but then it's controlled.
As I recall a Redstone missle went splashdown because a variable was named
starting with an I,J or K rather than an R or S. For non Fortran
programmers, variables defined starting with an I,J, or K were
automatically Integers and those starting with an R or S were automatically
floating point. We have come a long way since then with proper typing and
compilers complaining about mixing types. Relying on reset values is taking
a step backwards in time and has the _potential_ of subtle bugs in code.
I realize I won't get consensis with this but it's my opinion.
Regards,
John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc. Ph. 1-250-544-4950
PO Box 20002 Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9
> >I will concede, however, that you should document any reliance
> >on reset state.
>
> I agree.
>
> >
> >In the case of the original posting, where it is desired to simulate
> >a reset, then the above paragraph is not entirely true. Nevertheless
> >one cannot truly simulate a reset by executing instructions from location
> >zero. For a start, assertion of !MCLR immediately puts all port pins
> >in a high impedance state. This cannot be done by sequential instructions
> >since only one port can be hi-Z'd(*) at once.
>
> If the ports are required to be in a HiZ state for some type of operation
> and you cannot do that explicitly then perhaps we are discussing poor
> programming or design practices and insisting that we be able to practice
> them.
Excuse me for butting in here, but I think you missed the point.
All ports are set to HiZ by a /MCLR or POR at the same time. I
think the point that was being made is that it is not possible
to do that in software as you can only change one tris reg at
a time. So truly simulating a reset in software is not possible.
>
> >Also, are you _really_
> >going to go to the trouble of randomising your file registers?
>
> Why on earth would you want to do that?
No-one would want to do that, but after a POR, all ram is in a
random state. IFF you wanted to truly simulate POR in software, you
would have to randomise the ram contents or it wouldn't be
a true simultaion.
Here's a question that somebody probably has a real quick answer to:
I have a circuit in which I independantly power a PIC (and it's reset line)
with respect to the components that it interfaces to. The Power is
controlled to the PIC via an Opto-isolator and _MCLR is isolated by a
forward biased diode (the PIC is in an ISP Programmer attached to the
circuit).
One of the lines the PIC is attached to is an LED, connected to a Current
Limiting Resistor and Vcc. The PIC sinks the LED current.
The problem comes in when I turn off the Power and _MCLR to the PIC (Ground
is still connected) - the LED lights! Is there anything that I can do to
eliminate the current path?
Thanx,
myke
"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne
dax.sim.es.com) wrote:
