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

No exact or substring matches. trying for part
PICList Thread
'PIC Utilities for MPALC & I^2 C Code'
1994\07\13@072240 by john

flavicon
picon face

A while ago I mailed the list with some storage allocation macros and
a threat to supply interested parties with code for I^2 C bus protocol
communications and timed finite state machines.  Part of that is done:
but the code is moderately long so I suggest that you collect it, if you
are interested from ftp.dai.edinburgh.ac.uk, file /pub/user/pic-utils.tar.

You will find there the storage allocation macros I posted earlier, and some
other useful macros, e.g. a configuration macro that supports defaulting for
conditional compilation switches (the things that, when you forget to put
/D xxx=1 on the command line, MPALC says something like "line 1: Crit" and
crashes your machine ;-), as well as code for a multi-master I^2 C package
supporting master transmit and slave receive with interrupt detection of start
conditions (so your PIC doesn't have to spend all its time watching the bus).
The individual files in the directory in the tar file contain more information.

The finite state code will follow, as will other bits of the I^2 C stuff and
a neat UNIX c-shell script that calculates all the register values for a PIC
16C71 given clock rate, RTCC tick rate desired, and descriptions of the pin
functions (e.g. digital output, analogue input, digital tristate, etc.).  I
didn't manage to do this today, 'cos I've got to go on holiday in about an hour.
The code is there for people in a hurry -- in a month there will be more.

Have fun,

John Hallam                             spam_OUTjohnTakeThisOuTspamaifh.ed.ac.uk
Dept. of Artificial Intelligence
University of Edinburgh
5 Forrest Hill
Edinburgh EH1 2QL

'Old & New ??'
1994\07\14@203415 by ttkk

flavicon
face
Here's a quickie for anyone who knows.

       1) What's the difference between old & new version ROMS on the
Parallax programmer, are they just bug fixes?
       2) Will version 3.3 of PEP work with old programmer ROMS?
       3) Let me re-state that - are there any conflicts between old or
new programmer ROMS and the PEP software of ANY version?
       4) Are there any files on the Parallax BBS that may resolve my
clueless questions?

                               Thanx in advance,

                                                       tk

'Magnetic Card readers & PIC's'
1994\07\15@103926 by ttkk

flavicon
face
       I'm trying to design a keyless entry system using a magnetic card
reader. Has anyone out there done this using any of the PIC's? If so
which one and which card reader? Also what problems might I encounter
along the way.

                       Thanx for any help,

                                               TK

1994\07\15@133238 by mbmoore

flavicon
face
>       I'm trying to design a keyless entry system using a magnetic card
> reader. Has anyone out there done this using any of the PIC's? If so
> which one and which card reader? Also what problems might I encounter
> along the way.

If your card-reader is RS232, it won't be a problem because there is lots of
RS232 code around.  Since it looks like you're still trying to pic (pun
definately intended) one out, then look for RS232 type readers.  I have NOT
done this but it sounds pretty straight-forward.  One thing that I CAN think
of is - where are you going to store the card numbers?  You could hard-code
them into the PIC and re-program (use a UV erasable) them when needed.  Or,
you could have an external memory chip to keep the data in.  Or, you could
have all of them transmit back to a host computer.  If you are interested
in the latter, we might be able to put something together for you to do
RS232 from the reader, and then have the info. transmitted back to the host
over an RS232-BUS.  Write us back if you're interested and we'll talk about
the details.


*****************************************************************************
*  Paul Greenwood  ->  ->  ->  ->  ->  ->  ->  Custom Hardware Engineering  *
*---------------------------------------------------------------------------*
*  "Any sufficiently advanced technology is indistinguishable from MAGIC."  *
*                                 - Arthur C. Clarke                        *
*****************************************************************************


'Reading fuses from file & problems w PIC locking u'
1994\08\18@161759 by crocontroller discussion list
flavicon
face
Something I came across today - mpstart will read fuses and ID
locations from withon a .obj file, so there's no need to keep
setting the fuses each time you load it up. The only problem is
that to get mpalc to place data at $2000-2007 you need to use
org beyond its defined limits so you get a fatal error for each
word of data when assembling.
Perhaps ASPIC copes with this OK?

I've also descovered a problem when using 16C84s that once in a while
they lock up and only a powerdown will start them off again. The reset
pin doesn't do anything. It occurs primarily if I use my in-circuit programmer
after the chip has already been running. After the programming cycle is
complete, the device is presented with a reset pulse but just sits there.
If the device is programmed straight after power-up, the reset pulse
after programming starts it and it runs the program.
Any ideas?  All I can think of is that it's latchup on the MCLR pin
but I've tried driving it through a resistor, and non of the voltages
are outside the supply rails (except the 12V for programming).

Any ideas?
Thanks,
Simon
--
******************************************************************************
* Simon Harrison,  University of Newcastle U. Tyne    *                      *
* .....S.J.HarrisonKILLspamspam@spam@uk.ac.newcastle                        *   Oook               *
* Fax: 091-222-8180, Attn: S.Harrison                 *        - Librarian   *
* Telex (Preferred): 53654 UNINEW G, mark 1st line:   *                      *
* "TO:  S.J.HARRISON (DEPT. OF ELEC. ENG.)"           *                      *
******************************************************************************

1994\08\18@174037 by crocontroller discussion list

flavicon
face
> Something I came across today - mpstart will read fuses and ID
> locations from withon a .obj file, so there's no need to keep
> setting the fuses each time you load it up. The only problem is
> that to get mpalc to place data at $2000-2007 you need to use
> org beyond its defined limits so you get a fatal error for each
> word of data when assembling.
> Perhaps ASPIC copes with this OK?

Of course ASPIC supports this. The file DEMO.ZIP available on my BBS
(604-597-3479), Microchip's BBS and a few ftp sites shows how. Here is an
excerpt:

(From PICMACRO.ZIP)

...
      .switch PICDEVICE

       .case   1654
       .cpu    16c54
_RESVEC =       $01FF                   ;16c54
IDLOC = _RESVEC+1
FUSELOC = $FFF
       DEFSEG  REGS,  $00, $20         ;initial regs
       DEFSEG  CODE, $000,_RESVEC      ;Base code segment
       DEFSEG  RESET,_RESVEC,_RESVEC+1 ;Reset Vector
       DEFSEG ID,IDLOC,IDLOC+4        ;ID word segment
       DEFSEG FUSES,FUSELOC,FUSELOC+1  ;Config fuses

       .else

       .case   1655
       .cpu    16c55
_RESVEC =       $01FF                   ;16c55
IDLOC = _RESVEC+1
FUSELOC = $FFF
       DEFSEG  REGS,   $00, $20        ;initial regs
...
<code ommitted>


       .switch PICDEVICE
       .case 1654
       .case 1655
       .case 1656
       .case 1657
_CP     = %00001000             ;Code protect (0 = PROTECT)
_WDTE   = %00000100             ;WDT 0 = disable
_LPOSC  = 0                     ;LP Osc select
_XTOSC  = 1                     ;XT Osc select
_HSOSC  = 2                     ;HS Osc select
_RCOSC  = 3                     ;RC Osc select

       .else
       .case 1671
       .case 1684
_CP     = %00010000             ;Code protect (0 = PROTECT)
_PWRTE  = %00001000             ;Power up timer enable 0=disable
_WDTE   = %00000100             ;WDT 0 = disable
_LPOSC  = 0                     ;LP Osc select
_XTOSC  = 1                     ;XT Osc select
_HSOSC  = 2                     ;HS Osc select
_RCOSC  = 3                     ;RC Osc select
       .else
       .case 1742
_FPMM1  = %00010000             ;Extended Microcontroller (0 = CODE
PROTECT)
_FPMM2  = %01000000             ;Microcontroller mode (0 = CODE PROTECT)
_FPMM3  = %01010000             ;Microprocessor mode (0 = CODE PROTECT)
_FWDT1  = %00001100             ;WDT prescaler = 1  (0=disabled)
_FWDT64 = %00000100             ;WDT prescaler = 1
_FWDT256 = %00001000            ;WDT prescaler = 256
_LFOSC  = 0                     ;LP Osc select
_RCOSC  = 1                     ;RC Osc select
_XTOSC  = 2                     ;XT Osc select
_ECOSC  = 3                     ;EC Osc select (external clock)
       .endif

...
(From PLD.ASM  (the initial file))
;**********************************************************************
;*
;* Define PIC options and ID
;*
;**********************************************************************
       .if !clop_d             ;simulator won't tolerate fuses!

       SEG FUSES               ;Config fuse area

       .word _XTOSC|_CP|_PWRTE ;Mode: xt osc, no code protext, timer
enabled

       .if isdef( IDLOC )      ;if there is an ID area (ie. not 17C42)
        SEG ID
        .word  _year&$0f,_month,_day,_hour      ;set id number to compile
time
       .endif
       .endif
----------------------------
Note that the above code also generates a default id code as the compile
time
in BCD.

- Don Lekei

1994\08\18@174657 by crocontroller discussion list

flavicon
face
Sorry. Didn't mean to cast doubts about your program.... It's just I don't
use a PC for most of my work so don't really know anything about ASPIC.
I don't suppose you'd do an Atari version...
Simon
--
******************************************************************************
* Simon Harrison,  University of Newcastle U. Tyne    *                      *
* S.J.HarrisonspamKILLspamuk.ac.newcastle                        *   Oook               *
* Fax: 091-222-8180, Attn: S.Harrison                 *        - Librarian   *
* Telex (Preferred): 53654 UNINEW G, mark 1st line:   *                      *
* "TO:  S.J.HARRISON (DEPT. OF ELEC. ENG.)"           *                      *
******************************************************************************

'PICs & Real Time Clocks'
1994\08\25@151026 by crocontroller discussion list

flavicon
face
Hello PIC users,

Can any of you recommend a Real Time Clock that is easy to use with
the PIC16C57?  I have considered the DS1603 (a 32 bit elapsed time
module -- with crystal and battery built in).  I have also heard of
the TIC (Time In a Can) -- which is a self contained lithium battery
with a one line serial access to a RTC.  Unfortunately I can't figure
out who makes the TIC, or where to get the DS1603 (or even how much
one would cost.)

So could anyone tell me:

1) A good RTC to use with the PIC (<4 I/O lines please).
or
2) Who makes / where to get the TIC.
or
3) Where to get the DS1603.

Thanks in advance!

--Jason Gorden

1994\08\25@151853 by crocontroller discussion list

flavicon
face
Philips/Signetics makes two I2C RTCs. The PCF8573 & the PCF8583
both 8 pin dips. The '83 also has 256 X 8 static ram on board.
Don't know where you can get these mail order, same problem for
the Dallas part, but check with the distributors in your area,
which is?

Brian

1994\08\25@153136 by crocontroller discussion list

flavicon
face
Dallas will sell direct. Charge to the plastic of your choice.
Gordon

1994\08\25@153551 by crocontroller discussion list

flavicon
face
Responding to msg by .....breadKILLspamspam.....MAXWELL.EE.WASHINGTON.EDU (Brian
Read) on

>Philips/Signetics makes two I2C RTCs. The PCF8573 & the
>PCF8583  both 8 pin dips. The '83 also has 256 X 8
>static ram on board.  Don't know where you can get
>these mail order, same problem for  the Dallas part,
>but check with the distributors in your area,  which
>is?
>
>Brian

I'll also recommend the Signetics parts. You'll have the
added overhead of the I2C code but that should not be too bad.
Plus if you use the 8583 you get those 240 bytes of ram to play
with. I have spare PCF8583 (surface mount) on the shelf if you
need samples and have problems with the distributors.

Dallas parts can be ordered direct from Dallas Semiconductor.
(214) 450-0448. Double check that part # though. In my slightly

out of date data book the part number for the "Time-in-a-can"
is
DS1495L-XX. Call and get a data book anyway, they have a large
selection of RTCs and other neat stuff.

-carl-

Henry Carl Ott     N2RVQ
EraseMEcarlspam_OUTspamTakeThisOuTpipeline.com
-------------------------------
entropy requires no maintenance
-------------------------------

1994\08\25@155042 by crocontroller discussion list

flavicon
face
  "So could anyone tell me:  (3) Where to get the DS1603."

Dallas Semiconductor has a small-order desk that will take 1-10 piece
orders charged to credit cards.  Call +1-214-450-0448.  I've only used
them once, but found them very friendly.

                               Paul Milazzo <milazzospamspam_OUTbbn.com>
                               BBN Systems and Technologies
                               Cambridge, MA

1994\08\25@190615 by crocontroller discussion list

flavicon
face
I've had good success with an LP PIC and a 32khz Xtal as an RTC !

I feed the OscOut signal thru an op-amp buffer to the RTCC input with the
divider set to 128.  ( I use an TL27L1 .. can just barely buffer 32Khz, but
draws only 10-15 ua while doing so.  This MAY be overkill, but some LP Xtals
are sensitive to load, and run at multiples of their resonant if loaded too
heavily. )

I then poll the RTCC register, and when bit 7 is set, 128 x 256 32Khz clocks
have occurred.

DO NOT test bit7 of the RTCC.  Move it into a temporary register, and test
that.  That way, the lesser significant bits of the RTCC are unaffected.
( Testing the RTCC clears it as well. ) If you're a little late polling the
RTCC, little is lost, as the RTCC just wraps around and maintains those
bits for the next count.  Yes an individual "seconds" rollover may occur a
little late, but the error is NOT cumulative, merely a small offset.


( Here follows a mix of Microchip and Parallax code )


               mov     OPTION,#100111b         ; assign to pin
                                               ; trigger on 0->1
                                               ; assign prescaler to RTCC
                                               ; set prescalar to 1:128
check_seconds
              mov     w,RTCC
              mov     temp,w
              jb      temp.7,:rollover
              ret
:rollover


The above option and example was used for a 2 PIC board, in which the 32Khz
PIC was not doing duty as the RTC. ( He was a UART ! )  If a single
"programmable RTC" is desired, then the opamp is not necessary, and the
option assignments change, but idea remains the same.


Alan

--

Alan Rothenbush             |   There must be an ideal world, a sort of
Academic Computing Services |   mathematicians's paradise, where everything
Simon Fraser University     |   happens as it does in textbooks.
Burnaby, B.C., Canada       |                            Bertrand Russell


'Q: '71 Analog & Digital I/O'
1994\10\28@022522 by crocontroller discussion list
flavicon
face
Hi everyone.

I'm quite new to the world of PICs, and I've got a couple of (hopefully
simple) questions about the PIC16C71...


1. When a pin is configured as an analog input, can it still be used as
  a digital output?  Or would you first have to reconfigure it as
  digital I/O?  The reason why I ask, is that it appears that RA1
  can set up as digital I/O only if RA0 is also.

2. If you write a digital 1 or 0 to a pin which is configured as an
  analog input (and has a voltage connected to it), will it damage the
  PIC?  Or will the digital output just be ignored by the PIC?

3. The databook states that an analog input reads as a digital 0.  Does
  this mean it's not a good idea to do a BSF/BCF on PORT_A if you've
  got one or more pins set up as analog inputs?  I guess this kind of
  ties into question #2, since (I think) it would cause 0's to be
  output on all analog inputs.

4. Let's say I've got RA0 & RA1 set up as analog inputs, and RA2-RA4 as
  digital I/O.  What happens if I write to one of the digital outputs
  on PORT_A while an A/D conversion is taking place?  Will it cause an
  incorrect value to be converted?

I hope these questions make some sense.  Any responses will be greatly
appreciated.

Thanks,


--


- Richard Friesen                        Little Timmy took a drink,
(@spam@Richard_FriesenKILLspamspammindlink.bc.ca)        But now he'll drink no more,
                                        For what he thought was H2O
                                        Was H2SO4
------------------------------------------------------------------------------
--

1994\10\28@093003 by crocontroller discussion list

flavicon
face
>
> I'm quite new to the world of PICs, and I've got a couple of (hopefully
> simple) questions about the PIC16C71...
>
>
> 1. When a pin is configured as an analog input, can it still be used as
>    a digital output?

No.

> 2. If you write a digital 1 or 0 to a pin which is configured as an
>    analog input (and has a voltage connected to it), will it damage the
>    PIC?

Since the digital output is disabled: No.

> 3. The databook states that an analog input reads as a digital 0.  Does
>    this mean it's not a good idea to do a BSF/BCF on PORT_A if you've
>    got one or more pins set up as analog inputs?

No problem.

> 4. Let's say I've got RA0 & RA1 set up as analog inputs, and RA2-RA4 as
>    digital I/O.  What happens if I write to one of the digital outputs
>    on PORT_A while an A/D conversion is taking place?  Will it cause an
>    incorrect value to be converted?

No promise, but I don't see any reason why it should. If you want
your conversion to be as good as possible Microchip recomends
executing a "sleep" directly after the conversion is started. The end
of conversion interrupt will wake the PIC up. This however gives you
problem with defining the sampling rate (since the conversion then
has to be internally RC-timed) which is crucial for calculating the
anti-aliasing filter you need.

/Tomas

Tomas Westlund
OPQ Systems AB
SWEDEN
KILLspamtomasKILLspamspamopq.se

1994\10\28@110330 by crocontroller discussion list

flavicon
face
Hi everyone.

I'm quite new to the world of PICs, and I've got a couple of (hopefully
simple) questions about the PIC16C71...


1. When a pin is configured as an analog input, can it still be used as
  a digital output?  Or would you first have to reconfigure it as
  digital I/O?  The reason why I ask, is that it appears that RA1
  can set up as digital I/O only if RA0 is also.

2. If you write a digital 1 or 0 to a pin which is configured as an
  analog input (and has a voltage connected to it), will it cause
  excessive current and damage the PIC?  Or will the digital output
  just be ignored by the PIC?

3. The databook states that an analog input reads as a digital 0.  Does
  this mean it's not a good idea to do a BSF/BCF on PORT_A if you've
  got one or more pins set up as analog inputs?  I guess this kind of
  ties into question #2, since (I think) it would cause 0's to be
  output on all analog inputs.

4. Let's say I've got RA0 & RA1 set up as analog inputs, and RA2-RA4 as
  digital I/O.  What happens if I write to one of the digital outputs
  on PORT_A while an A/D conversion is taking place?  Will it cause an
  incorrect value to be converted?

I hope these questions make some sense.  Any responses will be greatly
appreciated.

Thanks,

--


- Richard Friesen                        Little Timmy took a drink,
(RemoveMERichard_FriesenTakeThisOuTspammindlink.bc.ca)        But now he'll drink no more,
                                        For what he thought was H2O
                                        Was H2SO4
------------------------------------------------------------------------------
--

1994\10\28@153143 by crocontroller discussion list

flavicon
face
> 1. When a pin is configured as an analog input, can it still be used as
>    a digital output?  Or would you first have to reconfigure it as
>    digital I/O?  The reason why I ask, is that it appears that RA1
>    can set up as digital I/O only if RA0 is also.

The manual claims not, but I think the original mask revision doesn't actually
work correctly.  In several of my applications I've found that I have to set
the TRIS bits to configure the pin as a digital input.  Otherwise the output
driver is enabled and fight my analog input.  This completely contradicts the
description and the logic diagram in the data sheet.

> 2. If you write a digital 1 or 0 to a pin which is configured as an
>    analog input (and has a voltage connected to it), will it damage the
>    PIC?  Or will the digital output just be ignored by the PIC?

I didn't get damage, although it might be possible.  Just set the corresponding
bit in the TRIS register to a 1 to make the pin a digital input.  Note that
even when you do this you can't actually _use_ it as a digital input if it
is configured as an analog input.

> 3. The databook states that an analog input reads as a digital 0.  Does
>    this mean it's not a good idea to do a BSF/BCF on PORT_A if you've
>    got one or more pins set up as analog inputs?  I guess this kind of
>    ties into question #2, since (I think) it would cause 0's to be
>    output on all analog inputs.

It's find to do a BSF or BCF on port A if the TRIS bits are set appropriately.
Just remember the usual caveats for using BSF & BCF on ports:  the instruction
will read the logic levels at the pin (NOT the output register), and perform
the logic operation on those, and write the result to the output register.
This means that if you have a pin the PIC is trying to drive high, but external
loading is keeping it low, and you execute a BSF to set some other bit on the
port, the PIC will start trying to drive the first pin low.

> 4. Let's say I've got RA0 & RA1 set up as analog inputs, and RA2-RA4 as
>    digital I/O.  What happens if I write to one of the digital outputs
>    on PORT_A while an A/D conversion is taking place?  Will it cause an
>    incorrect value to be converted?

Shouldn't affect it much, other than perhaps a tiny amount of noise (assuming
you have good grounding, etc.).

Cheers,
Eric


'MPSIM & PIC16C54'
1994\11\05@175111 by crocontroller discussion list
flavicon
face
I've been working with the code for my PIC16C54 project on the MPSIM
simulator from MicroChip. As soon as I ussue the GO command there's
a warning that uninitialized code at 01FF has been executed and then
everything else runs as I'd expect it to do. The manual says the '54's
PC defaults to 1F on power up. If I try to put something in that location
like many of the MicroChip BBS examples I get an assembler warning.
What's going on? Is this an assembler or simulator bug? Should I ignore
the MPSIM warning?

Tim McDonough -- spamBeGonetimmedspamBeGonespamcencom.net

'ID & Configuration regs on 16C84...'
1994\11\06@022834 by crocontroller discussion list

flavicon
face
Hi again.

I figured out why my simple program wasn't working: my programmer was
broken.  (In order to read/write a location, I would cycle MCLR/Vpp to
get the internal PC set to zero, then send Increment PC commands to
get to the address I wanted to diddle.  Unfortunately, I think I
didn't leave MCLR low long enough to reset the PC and so what I
thought were consecutive instruction words were actually spread out
through memory.  I realize that this is a really crufty way to do
things, but I was in a hurry.  I'm doing it better, and right, now.)

Anyway, I'm now trying to read/write the ID and Configuration regs,
but not having any luck.  The Microchip programming ref says that if
you increment the PC up to 0x2000, you'll be looking at the first ID
(or config, I forget) reg, but when *I* run the PC up to 0x2000 and do
a Read Program Memory command, I get whatever's at 0x0000.  I'm not
using the Load Configuration command to set the PC directly to 0x2000
because (according to my reading of the manual) you have to send a
word to be programmed, and then (presumably) do a Begin Programming
command.  For now, I just want to read the contents.  Can anybody
help?

(Anybody else notice that the uChip manuals, which at first look
pretty good, are actually not very clear on crucial points?)

Thanks,
---------------------------------------  -----------------------------
dave madden <TakeThisOuTdhmEraseMEspamspam_OUTvheissu.net.dcl.co.jp>  i don't know about your brain,
3-16-19 naka-machi #301                  but mine is really ... bossy.
musashino, tokyo 180 japan                                -l. anderson

1994\11\06@120055 by crocontroller discussion list

flavicon
face
On Sun, 6 Nov 1994, Dave Madden wrote:

> Hi again.
>
> Anyway, I'm now trying to read/write the ID and Configuration regs,
> but not having any luck.  The Microchip programming ref says that if
> you increment the PC up to 0x2000, you'll be looking at the first ID
> (or config, I forget) reg, but when *I* run the PC up to 0x2000 and do
> a Read Program Memory command, I get whatever's at 0x0000.  I'm not
> using the Load Configuration command to set the PC directly to 0x2000
> because (according to my reading of the manual) you have to send a
> word to be programmed, and then (presumably) do a Begin Programming
> command.  For now, I just want to read the contents.  Can anybody
> help?

 Now that I think of it I don't have ID reading implemented in my 16c84
programmer yet. I think you can do it this way(I'll try it myself this
afternoon):

 Do a Load Configuration to get the PC to 0x2000
 Send it some data(0x0000)
 DON'T do a Begin programming
 Do a Read Data
 increment address
 Read data...

 I think this should work, but I need to try it myself.

  Brian

------------------------------------------------------------------------------
"A little rebellion now and then is a good thing." | finger RemoveMEblanespamTakeThisOuTseanet.com
President Thomas Jefferson                        | PGP 2.6 email accepted
------------------------------------------------------------------------------

1994\11\07@024440 by crocontroller discussion list

flavicon
face
> (Anybody else notice that the uChip manuals, which at first look
> pretty good, are actually not very clear on crucial points?)
You think so huh?  Well try looking at the Parallel programming specs<gag>.
Also take a look athe the PICSTART16C(picture in the data book).  Now
look at the socket.  Now look again.  Seem odd?  It is a 28 pin socket.
Wow! its a picstart 16B with a new sticker on it. :)

later
       John
-----------------------------------------------------------------------------
John Johnson  Team OS/2 member | johnsonjEraseMEspam.....bga.com | EraseMEjohnsonjspamutdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done."  Around him lay Bill Gates and Microsoft apps.  Their
evil in this world at an end.
                                       Revelations of InfoWorld, Oct 11 1994

1994\11\07@063342 by crocontroller discussion list

flavicon
face
Dave,

I'm pretty sure that you have to do the config command to get at
the fuse locations.  If you are worried about overwriting the
address, you could load high bits to keep from writing anything.

Good luck,

Derrick

'MPSIM & PIC16C54'
1994\11\07@122648 by crocontroller discussion list

flavicon
face
<< The manual says the '54's
PC defaults to 1F on power up. If I try to put something in that location
like many of the MicroChip BBS examples I get an assembler warning.
What's going on? Is this an assembler or simulator bug? Should I ignore
the MPSIM warning? >>

There is only room for 1 instruction at 1FFH, and that should be a GOTO to
the start of your reset code (which should be at 100H or above, for
security and to save valuable subroutine space).

- Don

1994\11\07@175738 by crocontroller discussion list

flavicon
face
On Mon, 7 Nov 1994, Don Lekei wrote:

> There is only room for 1 instruction at 1FFH, and that should be a GOTO to
> the start of your reset code (which should be at 100H or above, for
> security and to save valuable subroutine space).
>
> - Don

Don,

Why do you recommend that the reset code is above 100h FOR SECURITY ?  I
understand about saving valuable subroutine space, but the security
comment puzzles me.

Gary Gaskell

'ID & Configuration regs on 16C84...'
1994\11\07@202617 by crocontroller discussion list

flavicon
face
I followed Brian Lane's suggestion about issuing a Load Config command
and then sending bogus data, followed by normal Read Program Memory
commands to get the ID and config data, and it worked!  Thanks, Brian.

In response to Derrick Early's message, I'm not particularly worried
about overwriting the ID info, but I'm terrified of accidentally
setting the Code Protection bit.  I don't have a parallel programmer,
so once CP is set, the part is no longer programmable.  (If you're
listening, Microchip, you should add a serial-mode command to do a
bulk erase.)

d.

1994\11\08@032924 by crocontroller discussion list

flavicon
face
Hi,

Dave Madden says:

> so once CP is set, the part is no longer programmable.  (If you're
> listening, Microchip, you should add a serial-mode command to do a
> bulk erase.)

I've found that using the parallel algorithm for bulk erase works
in serial mode too.  Here is a C code fragment that does this (use
your imagination for the functional behaviour of command(), out_word()
and delay() :-)

  command(LDCONF);
  out_word(0x3FFF);
  for ( i=0; i<7; ++i )
     command(INCADD);
  command(1);
  command(7);
  command(BEGPRG);
  delay(PRGDLY);
  command(1);
  command(7);

Hope that helps.

David

1994\11\08@191525 by crocontroller discussion list

flavicon
face
On Tue, 8 Nov 1994, Dave Madden wrote:

> I followed Brian Lane's suggestion about issuing a Load Config command
> and then sending bogus data, followed by normal Read Program Memory
> commands to get the ID and config data, and it worked!  Thanks, Brian.

 Glad to hear it worked! I still haven't had time to implement that
myself.

    Brian

------------------------------------------------------------------------------
"A little rebellion now and then is a good thing." | finger RemoveMEblaneEraseMEspamEraseMEseanet.com
President Thomas Jefferson                        | PGP 2.6 email accepted
------------------------------------------------------------------------------


'David Tait's programmer & 16C71'
1994\12\17@133149 by crocontroller discussion list
flavicon
face
>
> Hi,
>
> I have been using the D. Tait 16c84 programmer for some time.  I made 10
> circuit boards from AP circuits based on it -- I made some minor changes
> -- PNP transistors in place of the 4066 (or whatever).

I did the same. I replaced the 4066 with a couple of programmable LM317
circuits because I figured that I'd need to regulate the incoming DC
anyway. I also posted the software to Linux and added a read function and
a Motorola S-Record Hex loader. Pretty good for less that 1 week's work.

>
> Anyway, it works like a champ for the 16C84, but I thought it would also
> be nice to program the 16C71.  The specs seem almost identical, but
> without a scope, I have had no success -- although my Parallax programmer
> works fine with the windowed 16C71's I'm using.

It's a software problem. The hardware is fine. I was just about to pull
one of the engineering samples of the 16C71 and try to program it when
reality hit me like a brick. The one difference between the '84 and the '71
is that the first uses EEPROM and the latter EPROM. The write to the EEPROM
is self-timed. So for the 16C84 all you need to do is send a BEGIN PROGRAM
command and wait for 10ms or more. That's why it's so easy to program.

The '71 (and all the others that are EPROM based) you must start and end
the programming in a timed manner. 100 uS pulses until the location programs
and then a N * 100 uS pulse to over-program the location. No easy to get
a PC to do reliably (especially in Linux where context switches happen
every 10 mS)

The solution is simple: Use a 16C84 as an interface between the PC and the
programmer. It's probably less than 100 lines of assembly to get the core
functionality of pp.c into an '84. One could even add a parallel/serial
interface.

In any case the control 16C84 can then issue the begin and end program
commands for the 16C71's with almost exact delays between the two.

Hope this helps,

BAJ

1994\12\19@225800 by crocontroller discussion list

flavicon
face
>
> > For PIC based products I was thinking more along the lines of a stand
> > alone compiler that would be run externally on a PC or other host. The
> > PIC would have a small kernal like the BASIC Stamp does that could load
> > the code into an EEPROM or program a 16C84 in-circuit. For all but
> > quick and dirty prototyping I don't like the idea of going the
> > interpreted route ala the Stamp.
> >
> > Tim McDonough -- RemoveMEtimmedspam_OUTspamKILLspamcencom.net
>
> You could just write your code generator to generate the tokens that are
> used by the BASIC stamp.  It doesn't care what language the tokens came from.

I know that the STAMP's primary claim to fame is that it has an extremely
small footprint. However exactly how much performance does it lose due to
getting its tokens for a serial EEPROM?

I adore PIC's because they're the smallest little speed demons around. The
STAMP is easy to use but I fear the performance hit required to get work done.

So I'm going for it all:

17C42 (25 Mhz) with 64K of 20 ns static RAM
16C84 with serial EEPROM and serial port to load the 17C42 RAM.

It's already wired. I'll be testing it at the end of this week.

It's a serious development system that sits on a 4x3 perfboard.

Later,

BAJ


'Programming && PIC vs. HC11'
1995\04\26@135401 by Ken Lierman
flavicon
face
Hello all,

I have a couple of questions regarding the PIC....

1) Not to start a religious debate or anything, but... Is there anyone out there
who has used both the HC11 and the PIC and would be willing to share their
experiences with both?

2) From the FAQ, it seems that a programmer can be made simply for the 16C84,
but there are no references to programmers for other parts. Are there any
available without dropping $200? If so, where can I get more info?

3) How do you get out of digest mode?  I had to unsubscribe and resubscribe!

TIA!!!

Kenneth Lierman


'HP & IRDA'
1995\06\22@085049 by Harrison Cooper
flavicon
face
Thought this might be of interest for those of you talking
(writing ?) about HP and IRDA.  EET just had an article on
net surfing and mentioned IR info available on the HP page
called "access HP".  Couldn't quite make out all the address
but might start with http://www.hp.com

Harrison Cooper
Evans & Sutherland Computer Corp
RemoveMEhcooperTakeThisOuTspamspames.com


'guitar tuner, PIC & MIDI (was:Freq.counter)'
1995\07\07@152636 by Uwe Schueler
flavicon
face
>... David's guitar tuner project .....

how about amplifying,low-pass filtering ( 3rd order), and clipping
the guitar signal with a cheapo 324 quad-opa. Generate the desired
reference freq. with the RTCC. Make a software-PLL style frequency-
comparator ( edge-triggered RS-flip-flop )which is set by ref.-timing
and reset by input signal . Connect a 'sharp' LED to the Fin>Fref port and
a 'flat' LED to the Fref>Fin port. As the input freq. comes up/
down towards the ref.freq. the flat/sharp LED will dim.
Just a quick idea; don't know if it makes sense.
Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
A guy fed a bright LED with a microcontroller generated reference
frequency  and used the stroboscobe effect to visually tune the strings
without making noise - nice !

>It would be interesting to also pursue the generation of MIDI from a
>guitar signal ....

and from other real world events.  In my free-time ( not much) I currently
work on such a project : a microphone is placed at each end of a 1m plastic
tube. If you hit the tube with e.g. a drum-stick the mikes generate pulses
with a runtime delay. A 16C54 along with a 324 opamp digitizes these pulses
( MIDI key velocity ) and calculates a MIDI-note-# from the trigger delays.

I 'll put schematics, layouts + code related to MIDI, musicelectronics, PICs
and other controllers on my ftp site as soon as possible ( late summer ?)
Will be announced here and on MIDI.boards

P.S.
I too have some code that sends MIDI. MIDI IN is tough.
a 20MHz PIC with HW-interrupt could do it. Somebody tried it ?
Anybody else doing MIDI with PICs ?
Uwe Sch"uler    __\     /__ ein genie
Physiologie      --\,,,/--  das sich nicht geniert
Gmelinstr.5        /" "\    ist wie ein rentier
D-72076 T"ubingen  \_V_/    das sich nicht rentiert
Tel: (49) 70 71 29 - 30 72  Fax: - 30 73

1995\07\07@153926 by Lou Sortman

flavicon
face
> Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
> A guy fed a bright LED with a microcontroller generated reference
> frequency  and used the stroboscobe effect to visually tune the strings
> without making noise - nice !

Oh man, I've gotta try it!

1995\07\07@162149 by Mike Brothers

flavicon
face
On Fri, 7 Jul 1995, Lou Sortman wrote:

> > Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
> > A guy fed a bright LED with a microcontroller generated reference
> > frequency  and used the stroboscobe effect to visually tune the strings
> > without making noise - nice !
>
> Oh man, I've gotta try it!
>
Must have to darken the room to tune??  Anyone have any ideas, helpful
hints to get this to work?  Seems that it would be a rather stright
forward project!

EraseMEelectronspamspamspamBeGonewln.com

1995\07\07@190930 by David B. Thomas

flavicon
face
Your suggestion for dealing with the harmonics is great.  But my tuner
attempts to determine by itself which string is being tuned.  I suppose
with expensive programmable filters you could detect the pitch, then dial
in the filter real quick to protect against the harmonics, which
intensify with time.  But if you put in a filter sufficient to chop the
harmonics of the low E string (86 Hz or so) you'd never pick up the high
E two octaves up.

My hackbuddy and I have decided to return to this project and see if we
can get it to work.  The idea will be: count on the fundamental being
strong for the first several cycles (seems to be safe), then start
ignoring any transitions that aren't close to the expected timings.  For
example, if you're tuning the 110 Hz A string, you'd initially get a 110
cycle square wave.  Then as the vibrations decay, you'd start seening
double, triple, or some oddball combination.  If I remember right, the
second harmonic is the most prominent and can be isolated.  But I'll have
to look again.  Anyway, it might be as simple as ignoring every odd
pulse, once the expected pitch is established.  Owell I'll try it and
post the results!

ps: about the code I've offered to put up... I was going to make it
available via ftp this morning but I forgot to move the files.  I'll do
it tomorrow when I'm dialed in from home.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\07@192632 by David B. Thomas

flavicon
face
Lou> > A guy fed a bright LED with a microcontroller generated reference
Lou> > frequency  and used the stroboscobe effect to visually tune the
Lou> > strings without making noise - nice !

Lou> Oh man, I've gotta try it!

Mike> Must have to darken the room to tune??  Anyone have any ideas,
Mike> helpful hints to get this to work?

Real men use xenon flash tubes.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\08@111432 by CRSO.pic

flavicon
face
David, here are a few suggestions for a solution to your problem with
harmonics:

1)  Use a dual speed PLL to initially lock onto the strong fundamental
   in 'fast' tracking mode and then automatically switch to 'slow' mode
   to stay locked onto the decaying fundamental (decrease capture
   range). The 'fast' speed would be optimized to lock onto the
   fundamental quickly and the 'slow' speed would be fast enough to
   track tuning variations but too slow to 'jump' over to a harmonic.
   The fundamental could then be measured by coupling the vco to the
   pic.

2)  Use zero crossing detection. It has the unique property of allways
   digitizing the lowest frequency, even if its not the strongest.
   A well designed front end, and possibly threshold tracking to
   maintain sensitivity could be used to extend its range.

3)  Use a switched capacitor filter with external clock input configured
   as a 'comb' filter. Lock on to the fundamental and feed it into the
   filter's clock, thereby attenuating its harmonics. Something
   creative would need to be done here to aquire the fundamental in the
   first place.

4)  Use the pic to implement an FIR or IIR filter.

5)  Use the pic to integrate its measurement of frequency and then use
   that to detect the rate-of-change. If the rate of change (slope)
   exceeds a pre-set value then we know the detection circuitry has
   switched from the fundamental to a harmonic. At that point in time
   divide the new frequency measurement by the fundamental to calculate
   the harmonic factor and use that factor in subsequent calculations.
   This idea would work best if the signal were processed first by a
   PLL to lock onto a single spectral component. In fact, you could use
   the lock detection circuitry of the PLL to detect when the
   switchover to a harminic occurs.

6)  Can you tell if a note is sharp or flat from its harmonic as well as
   from its fundamental? If so, then use a PLL front end to purify the
   spectrum (one frequency at a time) and do your function on the VCO
   signal.

7)  Use an analog input and implement a PLL in pic firmware, using a
   combination of the above ideas.

I really know absolutely nothing about music, but I hope these ideas are
usefull, or stimulate the formulation of new ones.

Regards, Dana Frank Raymond - Foxtrot Systems Ltd.
Internet: RemoveMEdana.raymondKILLspamspamcanrem.com. Compuserve: 73362,3052

1995\07\08@221133 by David B. Thomas

flavicon
face
On Sat, 8 Jul 1995, Dana Raymond wrote:

> 1)  Use a dual speed PLL to initially lock onto the strong fundamental

Would it really stay locked to the weak fundamental?

> 2)  Use zero crossing detection. It has the unique property of allways
>     digitizing the lowest frequency, even if its not the strongest.

It can't be that easy, can it?  I'm already amplifying and heavily clipping
the signal.  Isn't that the same thing?  Maybe I need to read up on zero
crossing detection.

> 3)  Use a switched capacitor filter [...]

Impractical but clever.

> 4)  Use the pic to implement an FIR or IIR filter.

What are these?

> 5)  Use the pic to integrate its measurement of frequency and then use
>     that to detect the rate-of-change.

What I was planning was simpler.  Once the harmonic kicks in I'll be able
to recognize it because transitions will suddenly arrive way too early.
I can simply discard transitions that aren't within a few percent of
where I expect to find them.

> 6)  Can you tell if a note is sharp or flat from its harmonic as well as
>     from its fundamental? If so, then use a PLL front end to purify the
>     spectrum (one frequency at a time) and do your function on the VCO
>     signal.

How does one "purify a spectrum" with a PLL?  What does that mean?  But
yes of course it is possible to track changes in a harmonic as readily as
the fundamental.

> 7)  Use an analog input and implement a PLL in pic firmware, using a
>     combination of the above ideas.

I've done this for another project and it worked *very* well.  However I
was able to isolate the fundamentals with analog filters ahead of time.

Thanks for all your cool suggestions.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\10@111741 by Tim Braun

flavicon
face
> From @uga.cc.uga.edu:owner-piclistSTOPspamspamspam_OUTMITVMA.MIT.EDU Fri Jul  7 14:28:45 1995
> From: Uwe Schueler <spamBeGoneuwe.schuelerSTOPspamspamEraseMEUNI-TUEBINGEN.DE>
> Subject:      Re: guitar tuner, PIC & MIDI (was:Freq.counter)
>
> >... David's guitar tuner project .....
>
> how about amplifying,low-pass filtering ( 3rd order), and clipping
> the guitar signal with a cheapo 324 quad-opa. Generate the desired
> reference freq. with the RTCC. Make a software-PLL style frequency-
> comparator ( edge-triggered RS-flip-flop )which is set by ref.-timing
> and reset by input signal . Connect a 'sharp' LED to the Fin>Fref port and
> a 'flat' LED to the Fref>Fin port. As the input freq. comes up/
> down towards the ref.freq. the flat/sharp LED will dim.
> Just a quick idea; don't know if it makes sense.

This has some possibilities.  But you need to guess the reference freq.
from early edge crossings to get the correct string.  Help me out now,
what would the algorithm look like in pseudo-code?

wait for an edge crossing.
start a timer.
next edge crossing is 1/2 period.
estimate string, get reference period, set up reference period in RTCC.
loop
 wait for an edge or RTCC timeout.
 if edge
  set sharp LED. ;; you'd want to re-sync the RTCC?
 if RTCC
  set flat LED.  ;; you'd have to re-sync the RTCC to the next edge?
 if (too many RTCC's with no edge)
  break, restart

So when you're close to 'in-tune', both LED's would be on?

> >It would be interesting to also pursue the generation of MIDI from a
> >guitar signal ....
>
> and from other real world events.  In my free-time ( not much) I currently
> work on such a project : a microphone is placed at each end of a 1m plastic
> tube. If you hit the tube with e.g. a drum-stick the mikes generate pulses
> with a runtime delay. A 16C54 along with a 324 opamp digitizes these pulses
> ( MIDI key velocity ) and calculates a MIDI-note-# from the trigger delays.

This sounds like a really fun midi-trigger.  I'd like to get a hold of
some of your results.  Are you digitizing Mike output with RC discharge
time?

> I 'll put schematics, layouts + code related to MIDI, musicelectronics, PICs
> and other controllers on my ftp site as soon as possible ( late summer ?)
> Will be announced here and on MIDI.boards

I'll look forward to this.

> P.S.
> I too have some code that sends MIDI. MIDI IN is tough.
> a 20MHz PIC with HW-interrupt could do it. Somebody tried it ?

32 usecs/bit doesn't leave much time.  Setting up an 'hc11 is quite
a bit easier.

> Anybody else doing MIDI with PICs ?

Not yet, but when my (non-existent) free time allows ..

> Uwe Sch"uler    __\     /__ ein genie

Tim Braun                             |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St                   | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8    | Email: KILLspamtimspamBeGonespamchs.mb.ca

1995\07\10@114056 by David B. Thomas

flavicon
face
On Mon, 10 Jul 1995, Tim Braun wrote:

> This has some possibilities.  But you need to guess the reference freq.
> from early edge crossings to get the correct string.  Help me out now,
> what would the algorithm look like in pseudo-code?
>
> wait for an edge crossing.
> start a timer.
> next edge crossing is 1/2 period.

Are you sure you can assume 50% duty cycle?  Depending on the DC level
when you clip, the 1/2 cycle transitions will hopefully be near the
middle but you can't count on the exact timing.  I time from one
low-to-high transition to the next to unask this question.

The rest of your algorithm looks good.  What I do is wait for the edge,
then peek at the RTCC and look up the count in a table.  See
http://www.rt66.com/dthomas/pic/pic.html if you want to see my tuner so
far.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\10@132711 by Sun St Louis

flavicon
face
I may have mailed this incorrectly.  If not, sorry for the duplicates. . .

{Quote hidden}

Please help my confusion - it seems to me that we are trying to over engineer
what could be an easy solution.

Wouldn't the normal tuning process be:
1.  "Pluck" the string.
2.  Listen for it being sharp or flat.
3.  Tune the string.
4.  Re-pluck the string.

If this is the case, why worry about decaying harmonics?  Just count
the number of zero crossings in 100 msec & compair to a table of expected
values.  If it is high or low out-of-range discard it & try again.

Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
would think you could still get a good frequency sample after 2 sec.  I could
be wrong here - I've never tried it.

I don't know much about guitars.  But I think the difference between the
1st string (low E) and the 6th (high E) is 2 octaves.  With a string way out-
of-tune, I think it is possible to tune to the frequency of another string.
Taking a string this far out-of-tune would be undetectable by your circuit.
You may want to consider using 8 LEDs: 1 per string, plus a high and low
indication.  This would let you know which string the circuit thought you
were tuning.


Jon Poland
Sun Microsystems Inc.
St. Louis, MO
(314) 569-4716
@spam@jon.poland@spam@spamspam_OUTcentral.sun.com

1995\07\10@175326 by David B. Thomas

flavicon
face
On Mon, 10 Jul 1995, Jon Poland SE Sun St Louis wrote:

> Please help my confusion - it seems to me that we are trying to over engineer
> what could be an easy solution.
>
> Wouldn't the normal tuning process be:
> 1.  "Pluck" the string.
> 2.  Listen for it being sharp or flat.
> 3.  Tune the string.
> 4.  Re-pluck the string.

No.  The way guitar players generally tune is to hit the string once,
good and hard, then adjust the peg as the string is decaying.  That
way you can adjust a continuous pitch until it's right.  If you try to
tune with only "that was too high" type information, it takes way too
many tries.  Being off by even a few cents is enough to make the
instrument sound sour.

> Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
> would think you could still get a good frequency sample after 2 sec.  I could
> be wrong here - I've never tried it.

2 sec. is enough time to know if you're right or not, but it's not
enough time to bring the string in.

> I don't know much about guitars.  But I think the difference between the
> 1st string (low E) and the 6th (high E) is 2 octaves.

<nod>

> With a string way out-
> of-tune, I think it is possible to tune to the frequency of another string.

Guitarists are smarter than this.  Very few guitar players have any
trouble at all getting it close, even very close, by ear.  The tuner
is just used for fine tuning.  Also, guitars tend to drift some but
not a lot.  A guitar that was packed up a month ago is unlikely to be
so far out of tune that an autodetect mechanism would identify the
wrong string.  And most musicians wouldn't fall for it even then.

Still, your idea of providing a display that shows which string was
detected is a good one, provided you can afford to add it in your
particular application.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\11@130232 by CRSO.pic

flavicon
face
-> > 1)  Use a dual speed PLL to initially lock onto the strong
-> Would it really stay locked to the weak fundamental?

Yes, I believe so. A PLL CAN track a signal outside its capture range if
it has been locked onto it in the first place and its loop
characteristic are such that it resists change that is too fast (a
change from the fundamental to a harmonic can be considered a fast
change). When the harmonic comes into the capture range (close enough in
frequency and strong enough compared to the fundamental) the PLL won't
move to it because its loop characteristics inhibit fast change.

-> It can't be that easy, can it?  I'm already amplifying and heavily

No, you're right, I goofed. I'm still trying to find the reference in
"The Art of Electronics" that got me confused on that one (An excellent
reference BTW. I highly recommend it).

-> > 4)  Use the pic to implement an FIR or IIR filter.
->
-> What are these?

Digital filters. You need a very fast CPU with an analog front end.

-> How does one "purify a spectrum" with a PLL?  What does that mean?
-> But yes of course it is possible to track changes in a harmonic as
-> readily as the fundamental.

What I mean by that is that A PLL will lock onto one spectral component
(frequency) if it is coherent, stays within the tracking range, and
doesn't change too fast (slew rate). If you take a standard audio range
PLL and pluck a guitar string the PLL's oscillator will be one
frequency; The base note (terminology correct?), and the phase should be
shifted at around 90 degrees from the fundamental. The PLL will either
stay locked onto the fundamental or switch abruptly to a harmonic if
that harmonic is strong enough.

By measureing the PLL's oscillator frequency, you arn't getting a lot of
noise due to harmonics. Its only one frequency, changing over time.

Good luck with your project.

Regards, Dana Frank Raymond - Foxtrot Systems Ltd.
Internet: spamBeGonedana.raymondspamKILLspamcanrem.com. Compuserve: 73362,3052

1995\07\11@143601 by David B. Thomas

flavicon
face
On Tue, 11 Jul 1995, Dana Raymond wrote:

> Yes, I believe so. A PLL CAN track a signal outside its capture range if
> it has been locked onto it in the first place and its loop
> characteristic are such that it resists change that is too fast (a
> change from the fundamental to a harmonic can be considered a fast
> change).

Okay yeah this makes sense.  I just need to make the loop fast enough to
lock onto the fundamental before the harmonic gets too strong (500 ms
response is plenty good enough) but slow enough that the almost-instant
switch to the harmonic doesn't -- scuse the pun -- phase it.

I'd really like to try this approach.  What would be some audio PLLs to
use?  Perhaps a 565?  567?  Or are there more modern, better ones?  I've
worked extensively with RF type PLLs (gotta whole drawer full of motorola
chips) but never worked with audio PLLs.

Incidentally, for anybody wanting to use a PIC to tune an RF circuit, I
highly recommend the MC145170 chip.  It's cheap (about $8), readily
available (Hamilton Hallmark, Newark), and miraculous.  Programmed with 3
wire interface.  Reference modulus can be any number from 4(?) to 32767.
Programmable divider from 40 to 65535.  Can be programmed to be
single-ended or dual-ended.  Ref. output available.  Sign of loop can be
inverted by programming.  Can directly synthesize up to 160 mc.  XTAL ref.
osc. on-board.  16 pin package.  I've used these with PICs and they work
great.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

1995\07\12@104408 by Doug Sellner

flavicon
face
All one needs is an audible tone refference to tune the guitar.  As the two
tones get closer they cause a 'RING' which allows a semi skilled musician
to tune-a-fish.

Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410

Voice (612) 924-9193 x 521
Fax   (612) 926-1145

Internet: .....dsellnerspam_OUTspamembay.com

1995\07\12@113047 by Tim Braun

flavicon
face
> Date:         Tue, 11 Jul 1995 21:46:25 -0500
> From: Doug Sellner <TakeThisOuTnews.....spamTakeThisOuTEMBAY.COM>
> Subject:      Re: guitar tuner, PIC & MIDI (was:Freq.counter)

> All one needs is an audible tone refference to tune the guitar.  As the two
> tones get closer they cause a 'RING' which allows a semi skilled musician
> to tune-a-fish.

Using 'beating' to tune a guitar is fine and good when you can hear the
guitar and reference ...

There are many commercial tuning devices on the market, any which
I've looked inside are based on microcontroller technology.  This is
a great application for a PIC.

> Doug Sellner

> Internet: TakeThisOuTdsellnerKILLspamspamspamembay.com

Tim Braun                             |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St                   | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8    | Email: .....timspamRemoveMEchs.mb.ca

1995\07\12@114547 by David B. Thomas

flavicon
face
On Tue, 11 Jul 1995, Doug Sellner wrote:

> All one needs is an audible tone refference to tune the guitar.  As the two
> tones get closer they cause a 'RING' which allows a semi skilled musician
> to tune-a-fish.

Yeah that "ring" is called beating.  It's the difference between the two
frequencies.  And you are right that lots of musicians use this technique
all the time and it works great.

However, a lot of musicians prefer to use electronic tuners, at least in
some situations.  Particularly, stage musicians like to have them.
You're playing and a string breaks -- you finish the song, then hit a
foot pedal and suddenly your tuner (with visual indicator) is in circuit
and your amp is not.  You tune up without bothering the audience, then
you're back in business.  Or, let's say another band is playing, and your
band is up next.  You probably couldn't hear yourself to tune, perhaps even
with a headset.

I personally am very accustomed to relying on my ears, a lot more than
electronic measuring devices.  I've never tried to play an instrument on
stage that I didn't first check with my ears.  But a lot of pro musicians
do this sort of thing all the time.

David
--
Their address sums up their attitude: One Microsoft Way
       http://www.rt66.com/dthomas/

'Stamp & 16c84 I2C?'
1995\07\13@033905 by BRIAN F PICKFORD

flavicon
face
Hi Any/All,

I need to acces both I2C ram and a PCF8583 (RTC) from both devices,
two separate projects.

Does anyone have any pointers or code snippets they dont mind
sharing?

Fraser

Mr B.F. Pickford             | Tel:(0114) 2768555 x 5072(switchboard)
University of Sheffield      |     (0114) 2825072       (direct)
Dept. of Civil & Struct. Eng.| Fax:(0114) 2728910
PO Box 600                   |
Mappin Street                |
Sheffield S1 4DU             |
United Kingdom               | E-Mail: RemoveMEB.PickfordspamspamBeGoneSheffield.ac.uk

'guitar tuner, PIC & MIDI (was:Freq.counter)'
1995\07\14@043548 by Chris Madden

flavicon
face
       Check out the "comp.dsp" newsgroup for a similar discussion.

       Chris Madden
       spamBeGonemaddenc@spam@spamspam_OUTitd1.ul.ie

1995\07\15@143142 by Tim Braun

flavicon
face
Well, I've had this response on my desk-top for a few days,
better get it away, though some of the comments I make here
have been made already.

{Quote hidden}

Being a guitarist, and having used a tuner, and having attempted to design
a tuner, once, I'll share a bit of my experience.  I don't think we're over-
engineering yet.

> Wouldn't the normal tuning process be:
> 1.  "Pluck" the string.
> 2.  Listen for it being sharp or flat.
> 3.  Tune the string.
> 4.  Re-pluck the string.

Guitarists pluck the string and adjust the tuning while it sounds, and I for
one would not consider it useful to have to stop the string and re-pluck
to check the adjusted frequency.

> If this is the case, why worry about decaying harmonics?  Just count
> the number of zero crossings in 100 msec & compair to a table of expected
> values.  If it is high or low out-of-range discard it & try again.

The upper harmonics do decay quite quickly.  The first and second harmonic
can be a problem.

> Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
> would think you could still get a good frequency sample after 2 sec.  I could
> be wrong here - I've never tried it.

I normally don't get a useful tuning measurement out of my commercial tuner
until about 1/2 second after the string is plucked.  If you can't get a
good frequency sample for 2-5 seconds/pluck, it is really laborious to
tune.

{Quote hidden}

The two E strings are indeed 2 octaves apart.  You can indeed tune a string
down to the next one, if you try.  The harmonics on a given pluck on a string
won't let you simply count zero crossings, as you can pluck to generate
harmonics or not.  The zero crossings should be harmonically related, though.

The low E is about 82.41 Hz, the A is about 110.0 Hz, the high B is
247.2 Hz, high E is 329.6 Hz.   Referenced to A-440Hz.  It's very useful
to be able to adjust the reference of a tuner.  Acoustic pianos are out
most of the time in most places.

Tim Braun                             |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St                   | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8    | Email: @spam@timRemoveMEspamEraseMEchs.mb.ca

'PIC & DSP'
1995\07\19@170636 by Rodger Richey

flavicon
face
    Microchip will be offering two new devices in the PIC17CXX family with
    the 8x8 hardware multiply that executes in a single instruction cycle.
    Some of the features of these devices are:

              PIC17C44
    ----------------------------------
     58 single word instructions
     DC - 25MHz clock input
     8K words of program memory
     454 bytes of data memory
     supports external memory (64Kx16)
     8x8 hardware multiplier
     33 I/O pins
     2 capture inputs
     2 PWM outputs
     4 timer modules
     USART
     Watchdog Timer

    The PIC17C43 offers the same features of the PIC17C44 except that is has 4K
    of program memory space.

    Rodger Richey
    Microchip Technology Inc.


______________________________ Reply Separator _________________________________
Subject: PIC & DSP
Author:  Dana Raymond <EraseMEdana.raymondspam@spam@canrem.com> at Internet_Exchange
Date:    7/19/95 3:15 PM


Just a little note along the lines of FFT and DSP:

Microchip's application note AN542 implements FFT functions on a 17C42
PIC.

Also, I've heard from Microchip that they plan on offering a PIC with an
8X8 single instruction cycle hardware multiply. I wasn't given any more
detail, but such a chip would be suitable in low end DSP applications.

Regards, Dana Frank Raymond - Foxtrot Systems Ltd.
Internet: @spam@dana.raymondspam_OUTspam.....canrem.com. Compuserve: 73362,3052


'pics & fcc'
1995\08\07@102132 by Mike Fahrion
flavicon
face
I have brought several pic products through FCC Class A and B testing.  We
have our own FCC listed test facility, so I wear two hats - design engineer
and emi test engineer.  We also run a limited test service for outside
customers, so we do get quite a lot of exposure to outside products as well.

I haven't seen any problems with the PIC itself.  Be careful about your
oscillator circuit.  Just don't use a canned oscillator, crystalls are
generally ok.  The last PIC product I designed & tested was a very simple
board.  Single sided, through hole construction w/4MHz RC oscillator and no
problems.  In most cases with simple products, the supporting system (if
there is one) gives more trouble than the product itself.


{Quote hidden}

This sounds like a good outfit (and cheap! - takes me about 4 hours just to
do the report!).  When selecting a test house I would shop for one in your
area first.  Although you don't have to be present for the test, if its your
first product through FCC it can be a good learning experience.

>What I learned from the process:
>- If you can keep the oscillator below 1.706MHz, then you don't have to
>test for radiated emmissions.

Careful here - fcc definition of digital device (requires testing) is "Any
unintentional radiator that generates and uses timing signals at a rate in
excess of 9000 pulses per second..." Its virtually impossible to get out of
the radiated portion of testing in the consumer or industrial market.  I
believe if the device uses less then 7 or 9 nano-watts of power you are
exempt, but that's about it.

>- If the product plugs into AC power, then you have to test for
>conducted emmissions if the clock is above 9 KHz
>(yes I said K Hz)  I don't know if you are exempt if you use a
>certified wall wart (?)

If you plug in to AC power, you are required to test for conducted as well.
If you plug into a host device (a mouse into a computer for example) then
the host device is tested for conducted with your device attached.
Conducted is an easy test (ie cheap) to perform.

>- Look at the FCC rule book and see if your product is exempt, lots are!

Good luck :).  If its a consumer or industrial market product, chances are
slim your exempt.  Automotive products generally are though.
Also remember that FCC gets you nothing outside the US...

>- get several bids, there will be a wide spread in cost

Definately.  Just for reference, we charge around $850 for a standard test
w/report. This can run higher if your product fails any portion of testing
and the time$ starts building.  I think $700-1200 would be a good target
price (not including the FCC app fee).  And as Gary mentions, the level of
service can vary.  Be sure the price at least includes the test report.
Some outfits may even do the FCC application for you (required for part B,
that and another check for ~$735 to the FCC)

>- try to find a local site.  It is good if you can be there to answer
>questions.

Good learning experience too!

>Gary Skinner,  Electronic Solutions Inc

This is all good advice from Gary - feel free to contact me also, I enjoy
giving advice on how to get through testing much more than the testing
itself!

Two more bits of advice
- purchase the Code of Federal Regulations Title 47, parts 0-19.  This book
contains all the FCC rules - and while its hard to read, its not that
expensive and is required background education, in my opinion.  The test
house you select will love having an educated customer!
- be aware that the Compliance Design journal is published by a testhouse
(now Inchscape) and if you believe everything you read, you would think that
getting a product to market isn't possible without every test under the sun.
They are probably a good testhouse and it is a useful journal, but just be
aware that there is a connection there....


-mike fahrion


'Problems using DT, DE directives & changing user E'
1995\09\05@073730 by Scott Stephens
flavicon
face
I've had problems using DT, ex.

Prompt
DT     "Enter the next digit.", H'00'

Rather than a page of RETLW's saves time & makes pretty'r code. Too bad
PSIM doesn't like it!
I also can't initialize user EE Ram, which really hurts. I also would like
to be able to reset the
cycle counter, just like the time counter with F5.

Does anyone know how? How about another simulator which people mention from
time to time.
It would be real nice if MPSIM had a pretty interface like PSIM.

1995\09\05@121734 by Darrel Johansen

picon face
    Well, you have to ask yourself if the pretty interface is more
    important than getting the job done *now*.  MPSIM does what you'd
    want, and if you get the quick reference card from your local FAE, you
    can probably get productive and up to speed with the command line
    interface and get your problems solved pretty quickly with it.

    Pretty interfaces are in the future for MPSIM, though.  Stay tuned to
    the Microchip BBS for more information (or stop by the Microchip booth
    at the Embedded Systems Conference in Santa Clara next week).


______________________________ Reply Separator _________________________________
Subject: Problems using DT, DE directives & changing user EE values i
Author:  Scott Stephens <spamBeGonestephnssEraseMEspamKIWI.PYROTECHNICS.COM> at Internet_Exchange
Date:    9/5/95 6:41 AM


I've had problems using DT, ex.

Prompt
DT     "Enter the next digit.", H'00'

Rather than a page of RETLW's saves time & makes pretty'r code. Too bad
PSIM doesn't like it!
I also can't initialize user EE Ram, which really hurts. I also would like
to be able to reset the
cycle counter, just like the time counter with F5.

Does anyone know how? How about another simulator which people mention from
time to time.
It would be real nice if MPSIM had a pretty interface like PSIM.

'Serial EEPROM & I2C'
1995\09\22@173507 by Newson Edouard

flavicon
face
rz
**

1995\09\22@173921 by Newson Edouard

flavicon
face
I want to interface a serial EEPROM with a PIC16C74.  However, I don't
know I2C protocol very well.  Does anyone knows any application notes
about I2C or has a send/receive source code for serial EEPROM?

Anyone help will be appreciate

Thanks,
Newson

1995\09\24@193446 by Newson Edouard

flavicon
face
I want to interface a serial EEPROM with a PIC16C74.  However, I don't
know I2C protocol well.  I would like to  know, if anyone knows of any
application notes about I2C or has a send/receive source code for serial
EEPROM?

Thanks in advance,

Newson

'Fault tolerant & EMI-proof code - ideas?'
1995\09\26@102604 by Scott Stephens

flavicon
face
I'm interested in ways to protect my application from the effects of EMI,
power supply spikes, lightning, et. I am considering some of the following:

Using the WDT to generate resets; re-initializing registers, to prevent the
PIC from hanging in a loop in the event the PC is corrupted.

Spreading SLEEP instructions between called routines, and testing for
invalid resets or WDT timeouts to call a error handler or re-initialization
routine.

Loading a register with a unique number, according to the routine that the
code is executing, and testing for this number in other routines that rely
on the calling routines data.

Periodicaly generating and testing checksums in register and User EE Rom.

Any other idea's or comments? References to good books or application notes
from any manufacturer's?

Has anyone experienced problems that would justify going to this much trouble?
Thanks.

'Cracking CP Pics & Port Timing'
1995\09\26@172740 by Christopher

flavicon
face
I saw a quick FAQ on cracking PIC's (16C84's) on a site on the Netherlands.
Has anybody tried this? (IT spoke of leaving VDD at .5vdc and VPP @ 12) Thus
placing the PIC into a mode unnoted in the data-sheet..  Has anybody tried
this?  I can't get this to work..

Also-  I am having great time problems talking between my decoder and the
chip..  Very strange.. I am using a constant 3.5 mhz clock input.  Seems like
the values change every day depending on temp, weather, etc..  Any ideas? Using
XT clock..

'Fault tolerant & EMI-proof code - ideas?'
1995\09\27@000658 by Jim Scorse

picon face
Try Intel's appnote #125 for a start on the noise aspect

1995\09\27@023132 by divanov

flavicon
face
Scott Stephens wrote:

... snip snip ...
> Using the WDT to generate resets; re-initializing registers, to prevent the
> PIC from hanging in a loop in the event the PC is corrupted.
> Spreading SLEEP instructions between called routines, and testing for
> invalid resets or WDT timeouts to call a error handler or re-initialization
> routine.
> Loading a register with a unique number, according to the routine that the
> code is executing, and testing for this number in other routines that rely
> on the calling routines data.
> Periodicaly generating and testing checksums in register and User EE Rom.
> Any other idea's or comments? References to good books or application notes
> from any manufacturer's?
> Has anyone experienced problems that would justify going to this much trouble?

The only place I've seen a similar programming approach is the IBM AT
BIOS routines (8086 assembler). The routines start with testing the
stack, PUSHing all registers with unique values, then clearing them
and POPing them to see if the values were restored. It goes further
on checking regs, jumps, etc... If something fails, it falls into a
HALT trap with a JMP $-1 placed after it. Maybe this was justified in
the good old days of discrete logic, but I really doubt that you will
have to go to such extents with your project...

The BIOS routines are published in the IBM AT Technical Manual. Have
fun.

divanovspamBeGonespamplessey.co.za


'Saving W & STATUS from Interrupt using SWAP, AN585'
1995\10\02@100438 by Scott Stephens
flavicon
face
>To: RemoveMEPICLIST@spam@spamspamBeGoneMITVMA.BITNET
>From: .....stephnss@spam@spamEraseMEmail.pyrotechnics.com
>Subject: Saving W & STATUS from Interrupt using SWAP, AN585 and RTOS's
>
>I was checking out AN585 Real time operating system and noticed that the
author uses:
>MOVWF Temp_W
>SWAPF STATUS,W
>MOVWF TEMP_Stat
>before the Interrupt service routine to save the W and Status registers.
Why use SWAPF STATUS,W ? I can see that if STATUS happens to be 0, the Z
flag would be set but that would happen AFTER the current status was saved
in TEMP_Stat, wouldn't it? Is there another reason?
>
>And does anyone have any other suggestion and/or ideas for multitasking and
reenterant code? I like the examples given, but have trouble getting my
routines to cooperate adapting it to the interrupt and single timer on a 16C84.
>


'Parallax PSIM & EEPROM'
1995\11\06@220716 by DOM ALTAMURO
flavicon
face
I'm adding EEDATA manipulation to a 16C84 program,
but PSIM doesn't seem to acknowledge it properly.

Am I doing something wrong (code below) or is it PSIM?

- Dom

;========================================================
;             Read EEDATA into *_time variables
;========================================================

               mov     EEADR,#0        ;center_time
               sb      RD              ;set read bit
               mov     center_time,EEDATA

               mov     EEADR,#1        ;right_time
               sb      RD              ;set read bit
               mov     right_time,EEDATA

               mov     EEADR,#2        ;stay_time
               sb      RD              ;set read bit
               mov     stay_time,EEDATA

---
~ SLMR 2.1a ~ 001

'Piezo Transducer & sonar'
1995\11\07@010431 by Scott Stephens

picon face
>On Mon, 6 Nov 1995, Errington A wrote:
>
>> I used a piezo tranducer between PA0 and GND on a PIC84 with no apparent
>> ill-effects.  I don't think you should have any problems with the transducer
>> between two pins.

If you wan't your Piezo disk to keep going & goint, and not depolarize from
DC potential applied across it, use a coupling cap. Piezo disks depolarize
like LCD's over time & temperature.

>I'm working on a small project that uses the PIC as an ultrasonic
>distance detector.  Instead of using a separate chip, I generated the
>40kHz directly from the chip to the transducer (I also tried one with
>a transistor amplifier).  The receiving end (using a 567 tone decoder) did
>not seem to work very well. Has anyone attempted similar projects?
>I need some hints on getting the receiver to work better.
>

I've read about some, as the idea occured to me to create an array of piezo
disks, which have been etched and enclosed to work at a higher frequency,
for the purpose of a phased-array sonar. (Sometimes I have trouble believing
their are realy fish where I fish)

567 tone decoders are not very sensitive. And five volts isn't very much to
drive the transducer with. Maybe using 12V on the open-collector RA4 could
increase your transmitted power, and using an active-filter amplifier ahead
of your PIC would increase sensitivity.

While I'm waiting I've found the following:

>To all who requested tiff images of my stereo sonar, I have sent ann image of
>the left receive channel.  The right channel is identical.  The transmitter is
>simply connected to a couple of I/O bits from the PIC.  Also included is a 5
>digit display.  The code, designed for a 16C74,  is still in a state of flux,
>but if desired I would be happy to share it.
>
>Lee Holeva

Could I get that Tiff? Thanks,

( Never got it :( )


L.Kleeman and R.Kuc, "An optimal sonar array for target
localization and classification", IEEE Int Conf Robotics and Automation, May
8-13 1994 San Diego, pp 3130-3135.

A more complete journal paper on the same system is to appear in the
approximately August 1995 edition of International Journal Robotics Research.

Other papers to appear in Intern Conf R&amp;A Nagoya May 1995 are:

H Akbarally and L Kleeman, "A sonar sensor for accurate 3D target
localisation and classification"

M H Hong and L Kleeman, "A low sample rate 3D sonar sensor
for mobile robots"

   Herbert Peremans, Koenraad Audenaert, Jan M. Van Campenhout, "A High-
   Resolution Sensor Based on Tri-aural Perception", Vol 9 No 1 Febr 1993,
   IEEE Transactions on Robotics and Automation

'[PICLIST] Sensing RC receiver impulses & PWM motor'
1995\11\07@091938 by Valehrach Roman

flavicon
face
Hi to all PICers out there!

In an attempt to reduce the amount of 'reinfented wheels' (esp. my own's)
I'm looking for some code (preferable with application notes for the circuits)
concering radio control and motor control - preferable with PICs (but no
exlusive):

1. Decoding the servo impulse/s from a RC receiver:
  * preferable a 'self learning' application
  * determination of multiple levels of modulation (centre, and max. would
    certainly be of help for the beginning)
  * 'fail save'-state whilste there is a signal loss/no signal

2. Controlling of a model motor (car/aeroplane):
  * multiple steps of speed/fine control of revolutions
    preferably PWM (pulse width modulation) with a high frequenzy
  * acceleration/deceleration slope (programable)
  * high currents of 50A (standard, with shorttime current of up to 100A)
  * single/dual direction control
  * motorbrake
  * current sensing to detect shorts/blocking motor

I thing it's obvious that I'm trying to build a RC motor controller. Since I
know that many commercial products nowadays have a PIC (I know of 54 or 84)
inside, it should be possible to build such a thing.
my draft for such a device:
  combination of the above (1., 2.)
  PIC 16C84 (still the only one I can program) with information storage
  in internal EEPROM (receiver impuls, slew rate, motor data)
  modular final stage for cars or planes (brake, single/dual direction,
  etc.)

Since there are so many (aren't there?) RC modellers on the list it would be
interesting to share informations/experiences on the subject of using PICs in
RC models (in the whole and motor controllers especially).

With the minimal research I have done so far I also encountered some questions:
* What is the best way to do multiple tasks with a PIC (esp. 16C84)?
 Ex.: In a motor controller I would have to watch for the incomming impulses
      whilst pulse width modulating a motor, sensing the current, etc.
      To bad if I'm stuck in a wait loop... (If you know what I mean :-)
      Since I want to use the 84 - How do I put the interrupts to best use?
* Which (power) transistors should I use in the final stage?
  BUZ11 looks promissing.. but SIPMOS TEMPFETs/PROFETs/TOPFETs also look good
  (though a much higher price, but temperature/shorts protection)
  What would be the "best" transistor for my task ? (low Rds[on] <50mOhm,
  Id[max] >20A, reasonable pricing/pice, etc.)

  BTW: I bought some BUZ11 which have an 'A' mark on the cooling metal.
       Does that mean that those FETs are in fact BUZ11As and not BUZ11s.
       The plastic housing has printed 'BUZ11' on it (NO A) but what about
       the mark on the metal... ???
       What's the best way to measure the Rds[on] with hobbiest equipment
       (some DVMs [not acurate in mOhms-Measuring], Scope [10MHz])?


Finaly you might ask yourself, why I don't buy one of those commercial juwels
(Ahh.. controllers)?
A. Inflexibility: ('Please define [in-]flex-i-bil-i-ty... Ahh')
  Commercial controllers are trimmed for a single task. If I want to
  control a model car and a model aeroplane I would have to buy two
  controllers <cliiing>, although I wouldn't use both models at the same time.
  It's allmost impossible to find a controller which is really adequat for the
  given task. 'Testing a controller ? - Impossible - buy it first!' <cling>
  I also want to control the slew rate ('Expensive... 8-]' <cling,cling>) of
  the motor with my PC ('Impossible... :-(').

B. The Price: (Isn't it allways ?)
  As I wrote above - RC motor controllers are sold at the price of juwels.
  But a diamond wouldn't explode/burn out if you connect the power supply
the     wrong way - And who didn't/doesn't make mistakes. Such controllers also
  age at a rapid speed (Every year there is something new). If the nowadays
controller is damaged nobody but the manufactorer will repair it (time delay,
  prohibitive cost). So it's off to the bank to get a new loan.

C. Experience:
  I'm still very new to the PICs. I know it will be a hard way to a functinal
  unit but I certainly will learn my share.
  With the knowledge gained I could easily repair the RC motor controller :-)
  Thus *no more garbage collection* for high tech stuff! ;-)
  And ... 'What you know You KNOW.'

Thanks in advance for your response(s)!

****************************************************************************
*   Roman VALEHRACH               eMail-to: .....e8927070RemoveMEspamstudent.tuwien.ac.at  *
*   student of technical university vienna     (subject of annual change)  *
*                                                                          *
*  "SHARE AND ENJOY, SHARE AND ENJOY... "               furry creatures  ->*
*  "The EARTH: ..... (ed., revised: MOSTLY) HARMLESS"   from alpha-centaur *
*  "Say.. is there ANY tea on THIS ship ?"              (footprints)       *
****************************************************************************

1995\11\07@114331 by Conny Andersson

flavicon
face
At 15.16 1995-11-07 +0100, Roman VALEHRACH wrote:

>Hi to all PICers out there!

Oh my, what a letter, almost as long as a spam ;)

-- chop --- chop --

>* What is the best way to do multiple tasks with a PIC (esp. 16C84)?

Use a "state" variable to control where you are in each task and execute
each task in turn via some time sharing scheme, e.g. 2ms for you, 5ms for
you and so on. To control time, you can setup a timer to count down to zero
and then generate an interrupt - set a flag and the current task will finish
what it's doing when the task checks this flag. Each critical input (such as
waveform period measurements) could generate interrupts on selected edges
and store these measurements for further processing in the appropriate task(s).

Just some thoughts ... hope it gives you some new ideas ...

>* Which (power) transistors should I use in the final stage?

I say, read the specifications and look at some examples in the data sheets.
Then try it out on a protoboard (maybe not 20A though).

To measure Rds[on] you can setup a test circuit with high power resistors
and try it out in practise. I did so when I started to build a mega led
display with over 1000 leds and controlled by the well-known Z80-processor.
(The project is currently on halt, I wonder why?)

-- chop --- chop --

>C. Experience:
>   I'm still very new to the PICs. I know it will be a hard way to a functinal
>   unit but I certainly will learn my share.

A small advice ... start with a simple project to learn the basics. I
started with the '54 and I was surprised how much code you actually could
fill it with.


-- Conny

1995\11\07@120021 by Mark A. Corio

picon face
What kind of RC model needs 50 or 100 Amps of current?  Even at 9-volts thats
into the horsepower range!!!

Mark A. Corio
Rochester MicroSystems, Inc.
200 Buell Road, Suite 9
Rochester, NY  14624
Tel:  (716) 328-5850
Fax:  (716) 328-1144
e-mail:  .....McorioSTOPspamspam@spam@aol.com

***** Designing Electronics For Research & Industry *****

1995\11\07@135127 by Scott Stephens

picon face
>What kind of RC model needs 50 or 100 Amps of current?  Even at 9-volts thats
>into the horsepower range!!!

The Kalt Whisper electric RC helicopter takes around 35 Amps (average), at
9.6 volts. It only flies for 6 minutes. People I've talked with say
performance just isn't comparable to gas motors. Maybe soon Zinc-air or some
other fuel-cell technology will make electric airplanes and helicopters a
bit more practical. The speed controller in the helicopter ad has 8 TO-220
power FET tabs protruding from its case.

1995\11\07@135134 by Scott Stephens

picon face
>I'm looking for some code (preferable with application notes for the circuits)
>concering radio control and motor control - preferable with PICs (but no
>exlusive):
>
The Circuit Cellar BBS (860) 871-1988, has the file SERVOPIC.ZIP in File
Area 1 from the October 1994, Issue #51
magazine. You may be able to get it from their web site. The code is for PWM
multiple servo's.

>1. Decoding the servo impulse/s from a RC receiver:
>   * preferable a 'self learning' application
>   * determination of multiple levels of modulation (centre, and max. would
>     certainly be of help for the beginning)
>   * 'fail save'-state whilste there is a signal loss/no signal

It might be better to use PIC to modulate and demodulate your signal,
tapping the receiver's comparator output and your transmitters modulation
input. That way, you can employ error detection and correction codes in
firmware.

>* What is the best way to do multiple tasks with a PIC (esp. 16C84)?
>  Ex.: In a motor controller I would have to watch for the incomming impulses
>       whilst pulse width modulating a motor, sensing the current, etc.
>       To bad if I'm stuck in a wait loop... (If you know what I mean :-)
>       Since I want to use the 84 - How do I put the interrupts to best use?

Read Microchip's AP-Note AN-585 "A real-Time Operating System for PIC16/17".
Read about state-machine design in a textbook. The April 92 Computer
Applications Journal has a good article on state-machine design.

>        What's the best way to measure the Rds[on] with hobbiest equipment
>        (some DVMs [not acurate in mOhms-Measuring], Scope [10MHz])?

I would observe the voltage drop across the FET, motor and batteries in
operation. Then use the series current to determine where the power is going.

I'm interested in a good power FET too. I don't like high-side drives &
charge pumps.

1995\11\07@135319 by Timothy McDonough DIAL UP1

flavicon
face
Many of the high performance airplanes such as the sailplanes flown in
F5B competition and even larger sport models use 18-26 cells and draw
50 amps plus. Some of the F5B racers will drain a 20+ cell pack of 1700
mAh batteries in 20 seconds or so.

Tim

On Tue, 7 Nov 1995, Mark A. Corio wrote:

{Quote hidden}

1995\11\07@135935 by Maurizio Conti

flavicon
face
At 15.16 07/11/95 +0100, you wrote:

>.....* What is the best way to do multiple tasks with a PIC (esp. 16C84)?

I have done much experience with the multitask problem .
The good results have obtained them using the technique of the finite state
machine.

Maurizio Conti                           / __  __  __       / ___ ____
RemoveMEmcontispamspamBeGoneiper.net                         / /__)/_  /__) /\  / /_    /
http://www.iper.net                    / /   /__ / \  /  \/ /___  /
                                                    /
------------------------------------------------------------------

1995\11\08@023210 by SONY-OD

flavicon
face
>I'm looking for some code (preferable with application notes for the circuits)
>concering radio control and motor control - preferable with PICs (but no
>exlusive):
>

I have built a small RX-FM receiver with synthetized frenquency for RC-model.
This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
since 2 months - no crash !!! -
If you are interested in PIC code, schematic and PCB, I will be happy to post
you the whole document.
I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
8031.

 Philippe TECHER at "spamBeGonesonyedeKILLspamspam@spam@iway.fr"

1995\11\08@040340 by Clyde Smith-Stubbs

flavicon
face
G'day,

> If you are interested in PIC code, schematic and PCB, I will be happy to post
> you the whole document.

I'd indeed be very interested in seeing this. Please post it - or if you like
you can upload it to our ftp site (ftp.hitech.com.au) and we can make
it available from there.

Regards, Clyde

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
clydespam_OUTspam@spam@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au  | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
                   HI-TECH C: Compiling the real world...

'slave & master configuration'
1995\11\08@093652 by Kamran Rahimi

flavicon
face
Hello everybody!
I wonder how a slave master configuration for 2 PIC microcontroller (in this
case 16c84) works.
regards Kamran

1995\11\08@182615 by Arne Alsvik

flavicon
face
At 15:34 08.11.95 +0100, you wrote:
>Hello everybody!
>I wonder how a slave master configuration for 2 PIC microcontroller (in this
> case 16c84) works.
>regards Kamran
>

I am also extremely interested  in information .

AN579 Using the 8-Bit Parallel Slave Port PS 50K
"ftp://ftp.ultranet.com/biz/mchip/appnotes/ps/an579.zip"

If anybode have a ASCII of the PS file ,Pleas e-mail it to me.

1995\11\09@040934 by Conny Andersson

flavicon
face
At 15.34 1995-11-08 +0100, Kamran wrote:

>I wonder how a slave master configuration for 2 PIC microcontroller (in this
> case 16c84) works.

Well, let the master PIC send messages to the slave and tell the slave what
to do, then read the result from the slave. It's no different than
interfacing another IC except that YOU define the protocol between them. Use
I2C if you like or plain parallell communication or RS232 or whatever feels
good.


-- Conny

'EEPROM & LCD Matrix'
1995\11\09@110800 by SONY-OD

flavicon
face
From "Philippe"<spamBeGonesonyede@spam@spamiway.fr>

On Tue, 7 Nov 1995 RemoveMEJohn.P.HollingsheadEraseMEspamKILLspamHAPPY.FIRSTNETHOU.COM wrote:

> Also, I'm looking for some good sources for the displays.  What I
> have in mind, is for using a pic 16c57 for taking the 2of 8 binarie
> from a cd22202e dtmfdecode chip, and outputing to a serial e-prom and
> to output to the display.  It then must be able to access the eeprom
> to get readback buffers.

I already do that, specially to read/write serial EEPROM, I use a 93C46, but
another type can also be driven with this code.

Here is a piece of code to drive EEPROM


;>>>>>> START OF SAMPLE CODE
; This what I do to drive a PLL MC145170 and a 96C46 EEPROM

;******************************************************************************
;   HCK      = PortC.1
;   DATA out = PortC.3
;   DATA in  = PortC.5
;   CS PLL   = PortC.2
;   CS ROM   = PortC.6
;
;----- PLL & EEPROM  Constants

bHCK           equ 1
PEnb           equ 2
REnb           equ 6
bDout          equ 3
bDin           equ 5
bLock          equ 0

;******************************************************************************
; READ Routine for SERIAL EEPROM (96C46 : 64 X 16Bit)
; REGISTER used:
;    Data1         -> $0E
;    Data2         -> $0D
;    Address/Temp  -> $0F
;    EETemp        -> $0A

        org $0600
                  ;76543210
SetDataOut     equ %10110001

EERead:  movlw SetDataOut   ; Set HCK/DOUT/ENB as OUTPUT
        tris  C
        bcf  SPort,bHCK    ; bHCK = 0
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        bsf  SPort,PEnb    ; PEnb = 1    PLL ACCESS disable

        bcf  SPort,bDOUT
        bsf  SPort,REnb
        nop
        nop
        bsf  SPort,bHCK
        nop
        nop

        call EEStart
        movf Temp,W        ; GET Address from Temp register
        andlw %00111111    ; it's a 6 bit ADDRESS
        iorlw  %10000000   ; ADD Read INSTRUCTION to the word
        call EERdOut
        call EERdIn
        movf  Data1,W
        movwf Data2
        call EERdIn
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        retlw 0

;---------------
EEStart: bcf SPort,bHCK
        bsf SPort,Renb
        bsf SPort,bDOut
        nop
        nop
        nop
        bsf SPort,bHCK
        nop
        nop
        bcf SPort,bHCK
        nop
        retlw 0

;---------------
EERdOut: bsf SPort,Renb
        movwf EETemp
        movlw 8
        movwf Temp
        bcf SPort,bHCK

EERdO_1: bcf SPort,bDOut
        rlf EETemp
        btfsc STATUS,Cy
        bsf SPort,bDOut
        nop
        nop
        bsf SPort,bHCK
        nop
        nop
        nop
        bcf SPort,bHCK
        decfsz Temp
        goto EERdO_1
        retlw 0

;---------------
$BREAK
EERdIn:  bsf SPort,Renb
        movlw 8
        movwf Temp
        bcf SPort,bHCK

EERdI_1: nop
        nop
        bsf SPort,bHCK
        nop
        bcf STATUS,Cy
        btfsc SPort,bDIn
        bsf STATUS,Cy
        rlf Data1
        nop
        bcf SPort,bHCK
        decfsz Temp
        goto EERdI_1
        retlw 0

;******************************************************************************
;******************************************************************************
; ENABLE, DISABLE and WRITE Routine for SERIAL EEPROM (64 X 16Bit)
; REGISTER used:
;    Data1         -> $0E
;    Data2         -> $0D
;    Address/Temp  -> $0F
;    EETemp        -> $0A
;    CounterA      -> $1D
;    CounterB      -> $1E


EEEnable:movlw SetDataOut   ; Set HCK/DOUT/ENB as OUTPUT
        tris  C
        bcf  SPort,bHCK    ; bHCK = 0
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        bsf  SPort,PEnb    ; PEnb = 1    PLL ACCESS disable

        bcf  SPort,bDOUT
        bsf  SPort,REnb
        nop
        nop
        bsf  SPort,bHCK
        nop
        nop
        bcf  SPort,bHCK

        call EEStart
        movlw %00110000    ; ENABLE WRITE INSTRUCTION
        call EERdOut
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        retlw 0

EEDisable:movlw SetDataOut   ; Set HCK/DOUT/ENB as OUTPUT
        tris  C
        bcf  SPort,bHCK    ; bHCK = 0
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        bsf  SPort,PEnb    ; PEnb = 1    PLL ACCESS disable

        call EEStart
        movlw %00000000    ; DISABLE WRITE INSTRUCTION
        call EERdOut
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        retlw 0

EEWrite: movlw SetDataOut   ; Set HCK/DOUT/ENB as OUTPUT
        tris  C
        bcf  SPort,bHCK    ; bHCK = 0
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        bsf  SPort,PEnb    ; PEnb = 1    PLL ACCESS disable

        call EEStart
        movf Temp,W        ; GET Address from Temp register
        andlw %00111111    ; it's a 5 bit ADDRESS
        iorlw %01000000    ; ADD WRITE INSTRUCTION to the word
        call EERdOut
        movf Data2,W       ; Get the "HIGH WORD"
        call EERdOut
        movf Data1,W       ; Get the "LOW WORD"
        call EERdOut

        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        nop                ; NOW, waiting for acknowledge
        bsf  SPort,bHCK
        nop
        clrf Temp
        bcf  SPort,bHCK
        nop
        bsf  SPort,REnb
        movlw MaxWriteTime
        movwf CounterA

EEWait_1:bsf SPort,bHCK
        nop
        nop
        btfsc SPort,bDIn
        goto EEWait_2
        nop
        bcf SPort,bHCK
        nop
        decfsz Temp
        goto EEWait_1
        decfsz CounterA
        goto EEWait_1
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        retlw 1            ; return "1" there is a problem to write th WORD !!!

EEWait_2:bcf  SPort,bHCK
        bcf  SPort,REnb    ; REnb = 0    ROM ACCESS disable
        retlw 0            ; return "0", OK.

;>>>>>> END OF SAMPLE CODE

'slave & master configuration'
1995\11\09@153419 by John Payson

flavicon
face
> Well, let the master PIC send messages to the slave and tell the slave what
> to do, then read the result from the slave. It's no different than
> interfacing another IC except that YOU define the protocol between them. Use
> I2C if you like or plain parallell communication or RS232 or whatever feels
> good.

I've been working on a good bus protocol for potentially-busy CPU's.  The
best I've come up with so far for connecting precisely two CPU's which may
be arbitrarily busy and do not have any "special" hardware useable for such
a task is described below.  Note that I2C does not meet this criterion since,
without hardware assistance, a busy slave device could miss bits coming from
the master.

Hardware:
 The hardware consists of two open-collector signal wires for a two-device
configuration, or three or four [four wires will reduce CPU overhead on any
devices that aren't being addressed] open-collector wires for any other
number of devices.

Protocol:
 All data bytes are formatted as nine bits: a "0" start bit and eight data
bits.  Other than during a byte, all "1" bits received will be ignored.  Any
device transmitting should send at least one "1" bit before the first zero
bit, and messages are ended by sending a "1" bit where the start bit would
be expected.

During idle state, both lines are idle.  To send a zero, the sender asserts
line A; the receiver then asserts line B to acknowlege receipt.  Once the
sender sees B asserted, he releases A; the receiver will then release B.
Once the sender sees B released, he can send the next bit.

To send a one, the procedure is as above except that the sender asserts B
and the receiver acknowleges by asserting A, etc.

If the sender is sending a message to which a reply is expected, he will
assert B to send the final "1" and the receiver will assert A.  Then the
sender will release B and the receiver will release A and assert B [to
send his leading "1" bit].  Since the sender has released B and yet it
is still asserted, the sender can tell that B has acknowleged the sender's
release of B and is trying to send a bit.

While this protocol is somewhat speed-limitted by the requirement of two
transitions in each direction for each bit sent, it is completely insensitive
to any unexpected delays either party might experience.  Naturally, if one
party is busy with a 90ms task every 100ms the throughput will suffer, but
any bits sent will be (eventually) received and confirmed.

What does everyone think of this as a protocol?

'EEPROM & LCD Matrix'
1995\11\09@223809 by Tesaro Sandu

flavicon
face
Hello all ..
sorry about the topic .. its a different one  ..

we are doing a project with the PIC16C54-lp/p, the supply voltage is 3V
and the Xtal is 32.786 kHz .(watch crystal)..

it basically just gets the result from 4 swithes, and flashes a LED
acordingly..

Our problem is that some do not want to start. The crystal does not want
to start on some units. We are using 33p caps with them .. We have tried
different values, and we still get the same problem ...

We tried the delayed reset .. still is the same problem...

HELP ;)


Any ideas pplz ...  --
------------------------------------------------------------------------------

    Quote : Ambition is the key to success.
            Do you listen to your heart or someone elses ?
            Life is short, Make the most of it!

    Tesaro Sandu                   or                   Love-God (IRC)

                        call on  : (0416) 141 818
                   email on : spamBeGonetsanduspam_OUTspamRemoveMEst.nepean.uws.edu.au
          http: //http://www.st.nepean.uws.edu.au/users/tsandu/index.html

------------------------------------------------------------------------------

1995\11\09@225719 by Brad Phillips

flavicon
face
About those watch crystals....

I had the same problem a few days ago. Try some 47pF caps and see how you
go - this was my solution.
cheers, Brad

'slave & master configuration'
1995\11\10@033944 by Newfound Electronics

flavicon
face
>I've been working on a good bus protocol for potentially-busy CPU's.  The
>best I've come up with so far for connecting precisely two CPU's which may
>be arbitrarily busy and do not have any "special" hardware useable for such
>a task is described below.  Note that I2C does not meet this criterion since,
>without hardware assistance, a busy slave device could miss bits coming from
>the master.

cut........

>What does everyone think of this as a protocol?
>
Clumsy and unnecessary. Consider this protocol.

Two pics or any other devices, with one input and one output each. they
don't ever change (great for the PC printer port). To communicate one drops
its output the other then provides an ack etc.......  and then provides the
clock for the sender. Work out the details yourself  but I've given you the
idea.

You have with just two fixed lines bidirectional tranfer with handshaking
built in!

This is how the parallax programmer comunicates the the PC with just two
fixed direction lines. Its  brilliant!

Regards,

Jim Robertson

-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
mega featured PIC programming tools.
.....newfoundspamRemoveMEne.com.au
------------------------------------------------------------------

'PIC16C84 & PortB interrupt'
1995\11\10@043916 by SONY-OD

flavicon
face
I try to use a PIC16C84 and I get MICROCHIP documentation. There is something
strange:

 PortB can generate INTERRUPT when there is change on RB.4..7, the
documentation said: these pins are sampled on the Q1 cycle of read.
The new input is compared with old latched value in every instruction cycle.

HOW IT IS possible an interrupt occurs if portB is latched only on a READ
instruction ?
Does this means that it's neccessary to read PORTB every time to generate
an interrupt ?
MICROCHIP Doc. said: PortB can generate instruction in SLEEP mode, HOW it
is possible if portB is latched only on a read ?

Is it a mistake of the MICROCHIP doc. ?

Someone can help me please,

       Philippe <sonyedespam@spam@iway.fr>

'slave & master configuration'
1995\11\10@044747 by John Payson

flavicon
face
> Two pics or any other devices, with one input and one output each. they
> don't ever change (great for the PC printer port). To communicate one drops
> its output the other then provides an ack etc.......  and then provides the
> clock for the sender. Work out the details yourself  but I've given you the
> idea.
>
> You have with just two fixed lines bidirectional tranfer with handshaking
> built in!
>
> This is how the parallax programmer comunicates the the PC with just two
> fixed direction lines. Its  brilliant!

For this protocol to work, however, it is necessary that the device
responding to the clock do so within a known, finite, amount of time
and this time limits the speed of communications (e.g. if the slave
may take up to 1ms to respond to the clock pulse, then the master
must wait 1ms after every bit to ensure that it's reading the correct
data).  There are some cases in which this requirement is acceptable--
often a micro will have nothing better to do than wait for clock signals
from a PC.  But if both devices may be genuinely busy, I don't think
any approach without two bidirectional wires or latching hardware will
work.

1995\11\10@073547 by David Knell

flavicon
face
[snip]
>Two pics or any other devices, with one input and one output each. they
>don't ever change (great for the PC printer port). To communicate one drops
>its output the other then provides an ack etc.......  and then provides the
>clock for the sender. Work out the details yourself  but I've given you the
>idea.
[snip]

Hmm.  This one's fine provided that the sender can keep up with the clock
provided by the receiver.  John Payson's go can cope with either end being
busy at any time for as long as required.

I think I've figured out how to apply it to many devices using the third
line, but perhaps John would be kind enough to post that bit too?

Dave

'PIC16C84 & PortB interrupt'
1995\11\10@112247 by Mike Keitz

flavicon
face
>I try to use a PIC16C84 and I get MICROCHIP documentation. There is something
>strange:
>
>  PortB can generate INTERRUPT when there is change on RB.4..7, the
>documentation said: these pins are sampled on the Q1 cycle of read.
>The new input is compared with old latched value in every instruction cycle.
>
>HOW IT IS possible an interrupt occurs if portB is latched only on a READ
>instruction ?

When the port is read by the program, the interrupt-compare latch is reset
to agree with the present state of the port inputs.  Thus the interrupt
condition goes away then until a pin changes (actually, I think the RBIF
flag needs to be manually reset as well).  In other words, the read resets
the compare function so a further change is required.  The sampling is done
on every instruction cycle.  If the sample doesn't agree with the latched
value (last value read), the RBIF flag is set, which causes an interrupt if
RBIE and GIE are also set.

>Does this means that it's neccessary to read PORTB every time to generate
>an interrupt ?

No.  It is only necessary to read port B once while the external hardware is
in the 'non-interrupt' state (this defines what the state is), then clear
RBIF, and set RBIE and GIE.  The next change of one of the B4-B7 pins will
generate an interrupt.  Before leaving the interrupt routine, be sure that
the port and the latch agree with each other (by doing a read) and the RBIF
is clear so another interrupt won't occur immediately.

>MICROCHIP Doc. said: PortB can generate instruction in SLEEP mode, HOW it
>is possible if portB is latched only on a read ?

The latch is one input of the compare, the pin state is the other.  The
value in the latch is held during sleep from the last value read while the
CPU was running.  The path from the pins through to the comparators is
apparently held open during sleep.

>Is it a mistake of the MICROCHIP doc. ?

The system as it is described in the doc seems to make sense to me, though
their description isn't real clear.  I'm not sure why the convoluted
implementation of latching twice, it seems that a one-cycle pipeline
(generating a pulse each time a pin were different from the last cycle)
would have worked just as well if the RBIF indeed has its own latch.

-Mike

'[PICLIST] Sensing RC receiver impulses & PWM motor'
1995\11\10@120511 by Preben Granberg

flavicon
face
>>I'm looking for some code (preferable with application notes for the circuits)
>>concering radio control and motor control - preferable with PICs (but no
>>exlusive):
>>
>
>I have built a small RX-FM receiver with synthetized frenquency for RC-model.
>This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
>a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
>since 2 months - no crash !!! -
>If you are interested in PIC code, schematic and PCB, I will be happy to post
>you the whole document.
>I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
>8031.
>
>  Philippe TECHER at "EraseMEsonyedeRemoveMEspamSTOPspamiway.fr"
>

Please, one copy to me to !!!

Preben
Creative Micro
Hinbjerg 38
DK-2690 Karlslunde
Denmark
Tel +45 4615 4655
Fax +45 4215 3977

'PIC16C84 & PortB interrupt'
1995\11\10@130911 by Conny Andersson

flavicon
face
At 10.36 1995-11-10 +0100, Philippe wrote:

>  PortB can generate INTERRUPT when there is change on RB.4..7, the
>documentation said: these pins are sampled on the Q1 cycle of read.
>The new input is compared with old latched value in every instruction cycle.
>
>HOW IT IS possible an interrupt occurs if portB is latched only on a READ
>instruction ?

Easy! The pins are sampled AND put in the portB register by the
MOVF/SWAPF/... instructions BUT they are also "sampled" by the interrupt
logic - two separate sample-circuits. The actual data on the pins are not
nescessarily the same as the actual data in the register.


-- Conny

'slave & master configuration'
1995\11\11@040111 by Newfound Electronics

flavicon
face
>For this protocol to work, however, it is necessary that the device
>responding to the clock do so within a known, finite, amount of time
>and this time limits the speed of communications (e.g. if the slave
>may take up to 1ms to respond to the clock pulse, then the master
>must wait 1ms after every bit to ensure that it's reading the correct
>data).  There are some cases in which this requirement is acceptable--
>often a micro will have nothing better to do than wait for clock signals
>from a PC.  But if both devices may be genuinely busy, I don't think
>any approach without two bidirectional wires or latching hardware will
>work.
>
>
My apologies, I was off  track.  I hadn't reviewed close enough your orginal
criteria and you are right of course, an interupt would knock out my system.

I haven't checked in detail and taking your word for it,  your system could
work in the circumstances you outlined though you probably wouldn't be
recommending it as the first one to consider. Usually there are other
"work-arounds" otherwise a protocol like this would be commonly known and used.

Also, I didn't mean to send my reply as it was. I always start of brash and
mellow down on the second or third revision. I changed proceedure with
eudora and sent the 1st draft accidentally. I didn't mean to it be so sharp
on this matter, sorry.

Regards,

Jim


-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
mega featured PIC programming tools.
RemoveMEnewfoundKILLspamspamTakeThisOuTne.com.au
------------------------------------------------------------------

'PIC16C84 & PortB interrupt'
1995\11\11@061235 by adrian

flavicon
picon face
On the topic of the port B int on a 16C84...

Would I be right in thinking that setting or clearing B0-3 using bit
operations would mean a port read and write and hence clear any pending
interrupt for B4-7 change ?

The way I read it, I cannot use B0-3 for any I/O without risking loss of a
pending B4-7 change interrupt, which meant is was useful for getting out of
sleep but not much else.

Did I miss read the spec, or is this how it works ?

--
_
(_) _| _ . _  _   Tel +44 973 222257
( )(_|(  |(_|| )  Fax UK 0500 222258                    E&OE

'slave & master configuration'
1995\11\11@154856 by John Payson

flavicon
face
>  I haven't checked in detail and taking your word for it,  your system could
> work in the circumstances you outlined though you probably wouldn't be
> recommending it as the first one to consider. Usually there are other
> "work-arounds" otherwise a protocol like this would be commonly known and
used.

Well, often there are other features that can be used, most notably either:
[1] a UART on one/both ends [makes things REAL obvious/easy]; [2] a function
to latch whether a port pin has changed [even if it has since changed back]--
this allows a decent bidirectional interleaving protocol to be run on two
single-directional wires; or [3] a function to keep a pin pulled low after
something external pulls it low [I2C clock works like this].  I was suggesting
my protocol in the context of people using a device like the 16C54 which has
none of the above, talking to a PC printer port which has none of the above.

> Also, I didn't mean to send my reply as it was. I always start of brash and
> mellow down on the second or third revision. I changed proceedure with
> eudora and sent the 1st draft accidentally. I didn't mean to it be so sharp
> on this matter, sorry.

'PIC16C84 & PortB interrupt'
1995\11\11@182557 by Andrew Warren

face
flavicon
face
Adrian Kennard <spamBeGoneadrianspam@spam@RHANNA.DEMON.CO.UK> wrote:

>On the topic of the port B int on a 16C84...
>
>Would I be right in thinking that setting or clearing B0-3 using bit
>operations would mean a port read and write and hence clear any pending
>interrupt for B4-7 change ?

   Adrian:

   No.  Interrupts set the RBIF flag; once set, that flag will trigger a
   jump to the interrupt vector as soon as its enable flag (RBIE) and GIE
   are both set.

   However...

   There's a major flaw in the Change-on-Port-B Interrupt logic.  If you
   read from Port B at the same instant that a change on RB4-7 occurs, the
   RBIF flag will NOT be set.  BSF/BCF instructions perform a read, of
   course, so if you ever do BCFs, BSFs, or any other Port-B read operation,
   you can pretty much forget about using the Change-on-Port-B interrupt.

   -Andy

--
Andrew Warren - RemoveMEfastfwdspam_OUTspamix.netcom.com
Fast Forward Engineering, Vista, California

'slave & master configuration'
1995\11\12@082659 by Newfound Electronics

flavicon
face
>Well, often there are other features that can be used, most notably either:
>[1] a UART on one/both ends [makes things REAL obvious/easy]; [2] a function
>to latch whether a port pin has changed [even if it has since changed back]--
>this allows a decent bidirectional interleaving protocol to be run on two
>single-directional wires; or [3] a function to keep a pin pulled low after
>something external pulls it low [I2C clock works like this].  I was suggesting
>my protocol in the context of people using a device like the 16C54 which has
>none of the above, talking to a PC printer port which has none of the above.

Sorry again John but I'm really lost now!

YOUR intial crittia was for devices arbitrarily busy. Your then described a
system that I though, and still think was "fringe" and unlikely to be
required.  I put forward a commonly used system that didn't require
bidirectional lines and also would work if the devices were  arbitrarily
busy. As david Knell pointed out the downfall of this system is if the
sending device is interrupted during transfer.

Correct me if I'm wrong but the 16C54 does not have interrupts so the
problem has been eliminated at one end already.  The PC does have interrupts
and if interupted will sending could miss the clock.  But as one end is
stable, you could extend my forwarded system to provide a "clock echo" from
the reciever  or a million other systems  without the need for bidirectional
lines.

Speaking of bidirectional lines, which lines of a PC printer port are
defined as neccessarily bidirectional? Hmm?

I suggested there were work arounds to the problem you first preposed and
David Knell extended to include arbitrarily delays after transfer had began,
a much harder problem. None of the work arounds I had in mind included
uarts, latches, bells, whistles or even sirens, just good software design.

If your system works, and agian I stress I haven't nutted it out (knowing
there's no need) enough to say that it does,  It still must surely be the
last gasp solution given the range of simple solutions available. My system
synchonizes the devices at the start of the tranfer and the only way it will
fail is if it is interrupted, so why not turn off the interrupts and be done
with it? If latency is a problem allow interrupt windows between bits. You
can always reestablish synchronization after each bit exactly as you first did.

BTW A 16c54 and the printer port for your system you say? Didn't I point out
the parallax programmer used the system I forwarded?  Isn't the parallax
programmer a 16C57 talking to a printer port? And, yes it doesn't require
bidirectional lines or any sort of "two for one" protocol.

Regards,

Jim


-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
mega featured PIC programming tools.
newfoundspamspamne.com.au
------------------------------------------------------------------

1995\11\13@004606 by John Payson

flavicon
face
> Sorry again John but I'm really lost now!
>
> YOUR intial crittia was for devices arbitrarily busy. Your then described a
> system that I though, and still think was "fringe" and unlikely to be
> required.  I put forward a commonly used system that didn't require
> bidirectional lines and also would work if the devices were  arbitrarily
> busy. As david Knell pointed out the downfall of this system is if the
> sending device is interrupted during transfer.
>
> Correct me if I'm wrong but the 16C54 does not have interrupts so the
> problem has been eliminated at one end already.  The PC does have interrupts
> and if interupted will sending could miss the clock.  But as one end is
> stable, you could extend my forwarded system to provide a "clock echo" from
> the reciever  or a million other systems  without the need for bidirectional
> lines.

The 16C54's lack of interrupts does not eliminate the problem at the PIC's
end if, as in my example [controlling a multiplexed set of lights which is
driven by a shift register while analog-reading photogates] the PIC has to
do something besides talking to the PC; in my case, the code will execute
one light-change and photosensor-read, then talk to the PC until the timer
indicates it's time to change the lights and read the next photosensor, etc.
Another project I've done with worse timing constraints [albeit before I
came up with this protocol--getting the timing to work consistently was a
major pain] involved genlocking video: my CPU could spend all the time it
wanted talking to the PC [merely counting sync pulses] until the display
time arrived, but once the start-of-display scan line came, it had to spend
all its time for the next 2ms outputting video data.

> Speaking of bidirectional lines, which lines of a PC printer port are
> defined as neccessarily bidirectional? Hmm?

/ACK, /Strobe, /Autofeed, /Reset, and the other output control signal are
all open-collector with feedback inputs.

> I suggested there were work arounds to the problem you first preposed and
> David Knell extended to include arbitrarily delays after transfer had began,
> a much harder problem. None of the work arounds I had in mind included
> uarts, latches, bells, whistles or even sirens, just good software design.

I had merely mentioned the uarts, latches, etc. because if they exist they
allow for better protocols; I2C, for example, is an effective multi-master
protocol using only two wires but it requires hardware assistance for a CPU
to operate as anything other than a sole master.

> If your system works, and agian I stress I haven't nutted it out (knowing
> there's no need) enough to say that it does,  It still must surely be the
> last gasp solution given the range of simple solutions available. My system
> synchonizes the devices at the start of the tranfer and the only way it will
> fail is if it is interrupted, so why not turn off the interrupts and be done
> with it? If latency is a problem allow interrupt windows between bits. You
> can always reestablish synchronization after each bit exactly as you first
did.

If you leave interrupt windows between bits, that will impose a maximum
speed based upon the maximum possible latency.  While it's possible to come
up with better protocols which rely on specific behavior on the part of the
two systems [e.g. send a byte, then wait for the "slow" device to do an
"extra" transition on its clock or data wire to indicate it's just done an
interrupt] such protocols tend to be rather fragile and are often only useful
in the applications for which they are developed.  I was suggesting my proto-
col as an alternative which, while not optimal in every application would be
useable in all and which could therefore be coded once and re-used whenever
such a protocol was needed.

> BTW A 16c54 and the printer port for your system you say? Didn't I point out
> the parallax programmer used the system I forwarded?  Isn't the parallax
> programmer a 16C57 talking to a printer port? And, yes it doesn't require
> bidirectional lines or any sort of "two for one" protocol.

Ah, but the Parallax programmer doesn't exactly have to do a whole lot while
it's talking to the PC.  In some applications, however, the PIC may be doing
extremely time-critical things [analog input being the most likely in many
cases, though video output or analog PWM'ing would also qualify] and be
unable to afford the time it would take to monitor for PC communication.

1995\11\13@091753 by Newfound Electronics

flavicon
face
>The 16C54's lack of interrupts does not eliminate the problem at the PIC's

cut cut...

>all its time for the next 2ms outputting video data.

Well, lets agree to disagree, I still don't see that any of the above
necessitates bidirectional lines os esoteric protocols.
>
>> Speaking of bidirectional lines, which lines of a PC printer port are
>> defined as neccessarily bidirectional? Hmm?
>
>/ACK, /Strobe, /Autofeed, /Reset, and the other output control signal are
>all open-collector with feedback inputs.

I'm not sure enough to argue and what the defined standard is but in
practice different systems are used and what works on many cards may fail on
others just when you were sure of universal compatibility. |I  have been
caught with an eprom emulator  and a 8748/9 burner, both published in US
mags via DIY in hong kong..

>If you leave interrupt windows between bits, that will impose a maximum
cut cut......
>useable in all and which could therefore be coded once and re-used whenever
>such a protocol was needed.

As long as the technical merrits are on the table I'm not going to argue
endlessly on philosophical design preferences. Personally, I believe in
tailor made optimal solutions but I realize it a personal choice.
>
>Ah, but the Parallax programmer doesn't exactly have to do a whole lot while
>it's talking to the PC.  In some applications, however, the PIC may be doing
>extremely time-critical things [analog input being the most likely in many
>cases, though video output or analog PWM'ing would also qualify] and be
>unable to afford the time it would take to monitor for PC communication.

John, whatever....   but I still fail to see how you have adaquately
promoted  your system as been practical. Purely from a technical point, the
issue is far from resolved.

I know what works for me and all the senarios you forwarded I am sure I can
solved in simpler ways than you prepose. As I said before, maybe the whole
matter is philosophical, but regardless of, I don't feel comfortable
continuing as others are paying to down load this and it hasn't appeared to
have wide spread appeal (interestingly!).

I wish you good luck with your system and I'll move on.

Regards

Jim

-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
mega featured PIC programming tools.
spam_OUTnewfoundspam_OUTspamspam_OUTne.com.au
------------------------------------------------------------------

'PIC16C84 & PortB interrupt'
1995\11\13@115230 by John Payson

flavicon
face
>     There's a major flaw in the Change-on-Port-B Interrupt logic.  If you
>     read from Port B at the same instant that a change on RB4-7 occurs, the
>     RBIF flag will NOT be set.  BSF/BCF instructions perform a read, of
>     course, so if you ever do BCFs, BSFs, or any other Port-B read operation,
>     you can pretty much forget about using the Change-on-Port-B interrupt.

Does MOVWF perform a read-before-write? [I realize, of course, that if it
did so it would ignore the value read, but it's probably easier to have the
hardware do the read for all of the ALU-freg ops].  What about CLRW?  Does
that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
LSB's to something else cause that something else to be read [hopefully
harmlessly] instead?

1995\11\13@123306 by Mike Keitz

flavicon
face
>What about CLRW?  Does
>that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
>LSB's to something else cause that something else to be read [hopefully
>harmlessly] instead?

An interesting question, if it exists this side effect could be useful for
something (not sure what yet).  If the possible extra read could be a
problem, you could replace CLRW with ANDLW 0 (exactly the same effect as
CLRW; W=0 and Z flag =1) or of course MOVLW 0 (W=0, but Z unchanged) instead
and forget about the CLRW "instruction" (as you've noticed, it's actually
coded as CLRF x,w) altogether.

-Mike

'slave & master configuration'
1995\11\13@125709 by Martin Nilsson

picon face
>>something external pulls it low [I2C clock works like this].  I was suggesting
>>my protocol in the context of people using a device like the 16C54 which has
>>none of the above, talking to a PC printer port which has none of the above.
>
> Sorry again John but I'm really lost now!

John, I think your 2-wire bidirectional protocol idea is very
good. Asynchronous protocols are tricky, and I'm not sure I understand
all details, but it certainly looks like good and robust
engineering. Incidentally, I have seen a proprietary protocol invented
by Sony for high speed communication between a PC and their
DataDiscman, using similar principles. Keep up the good work!

> YOUR intial crittia was for devices arbitrarily busy. Your then described a
> system that I though, and still think was "fringe" and unlikely to be
> required.  I put forward a commonly used system that didn't require
> bidirectional lines and also would work if the devices were  arbitrarily
> busy. As david Knell pointed out the downfall of this system is if the
> sending device is interrupted during transfer.

Jim, the fundamental flaw of the system you describe is its time
dependence. It was a serious mistake of Parallax to use this protocol,
since it causes malfunction of their PIC programmer, as has been noted by
several subscribers to this mailing list in the past (eg with an HP host
and an IBM host).

It isn't possible to control the timing of a generic PC compatible so
well that you can communicate with the speed that Parallax
expects. There are two possible solutions: (1) Either slow down the
current protocol so much that PC timing can be guaranteed, or (2) use
an asynchronous protocol, like the one John suggested. The latter
alternative is preferrable, since it allows much higher bandwith.
(John, don't worry about your protocol being speed limited - it is
the synchronous protocols that are speed limited!)

The serious thing is that Parallax *cannot* correct this design
mistake with just new PC software. In both cases, they would have to
replace the PIC in the socket. In (2), they would also have to replace
the parallel port plug, as their current plug uses pins 2, 11, and 25.

> Correct me if I'm wrong but the 16C54 does not have interrupts so the
> problem has been eliminated at one end already.  The PC does have interrupts
> and if interupted will sending could miss the clock.  But as one end is

Interrupts and cache memory. You also need to go through the PC
parallel port interface, and signals *do not* appear on the port any
precise delay after setting the corresponding register bits.

> stable, you could extend my forwarded system to provide a "clock echo" from
> the reciever  or a million other systems  without the need for bidirectional
> lines.
>
> Speaking of bidirectional lines, which lines of a PC printer port are
> defined as neccessarily bidirectional? Hmm?

There is description of this in the excellent PC Parallel Port
FAQ. Out of my memory, at least 16 and 17 (pulled-up OC, can be both
written and read). You can also connect a status line output with a status
input to get a bidirectional line.

{Quote hidden}

did.

Jim, if you have a portable routine for outputting precisely timed
signals on a PC parallel port, what accuracy can you get?  Can you
submit it to the list? I'm sure that list subscribers would be very
interested in testing it.

> BTW A 16c54 and the printer port for your system you say? Didn't I point out
> the parallax programmer used the system I forwarded?  Isn't the parallax
> programmer a 16C57 talking to a printer port? And, yes it doesn't require
> bidirectional lines or any sort of "two for one" protocol.

I agree that the Parallax system makes a good case in point :-).

I don't want to pick on Parallax, because they make good products, and
I think they have a good company policy in general. However, I have
pointed out this problem to them and essentially received a short-cut
answer like "Tough luck for you - We can't test all PCs." There is no
question Parallax has been aware of the time dependence problem. A
good protocol for high-speed communication with a PC must necessarily
be time independent.

Cheers,

-- Martin

Martin Nilsson
Swedish Institute of Computer Science    E-mail: mnspam_OUTspamsics.se
Box 1263, S-164 28 Kista                 Fax: +46-8-751-7230
Sweden                                   Tel: +46-8-752-1574

'PIC16C84 & PortB interrupt'
1995\11\13@150424 by Andrew Warren

face
flavicon
face
John Payson <RemoveMEsupercatKILLspamspam@spam@MCS.COM> wrote:

>Does MOVWF perform a read-before-write?

   No.

>What about CLRW?  Does that read [IND] if the 7 lsb's of opcode are zero?

   No, but why not just use MOVLW 0 (if you don't want the Z flag to be
   affected) or ANDLW 0 (if you do)?

   -Andy

--
Andrew Warren - fastfwdspamBeGonespam.....ix.netcom.com
Fast Forward Engineering, Vista, California

1995\11\13@190107 by John Payson

flavicon
face
> >What about CLRW?  Does
> >that read [IND] if the 7 lsb's of opcode are zero?  Would changing the 7
> >LSB's to something else cause that something else to be read [hopefully
> >harmlessly] instead?
>
> An interesting question, if it exists this side effect could be useful for
> something (not sure what yet).  If the possible extra read could be a
> problem, you could replace CLRW with ANDLW 0 (exactly the same effect as
> CLRW; W=0 and Z flag =1) or of course MOVLW 0 (W=0, but Z unchanged) instead
> and forget about the CLRW "instruction" (as you've noticed, it's actually
> coded as CLRF x,w) altogether.

I was just realizing that, because of the existence of writable registers
in the 16Cxx (though not 16C5x) which are altered by reading, MOVWF has to
be an oddball instruction; on the 16Cxx, almost all of the instructions whose
first two bits are "00" fit the following formula:
 read F-register selected by OP0-6
 take that and W; compute a value and flags [incl. "skip" flag] using the
   operation specified by OP8-12
 store the result in W if OP7 is 0, or back in the F resister if OP7 is 1

The only exceptions are:
 movwf
 nop
 clrwdt
 retfie
 return
 sleep
 tris
 option

Note that were it not for the existence of read-modified registers, even
these instructions could be executed with the above formula provided that
something else was "also" done [except for MOVWF, all of them would decode
as "take W and some F-register, then store W into W].  I wonder if that's
how they are in fact decoded on the 16C5x?

PS--Does anyone know how the TRIS and OPTION instructions are decoded?  I'd
like to be able to access EECTL and EEDATA without having to muss around
with bank-switching on the 16C84.

'slave & master configuration'
1995\11\14@082643 by Newfound Electronics

flavicon
face
>>>something external pulls it low [I2C clock works like this].  I was
suggesting
>>>my protocol in the context of people using a device like the 16C54 which has
>>>none of the above, talking to a PC printer port which has none of the above.
>>
>> Sorry again John but I'm really lost now!
>
>John, I think your 2-wire bidirectional protocol idea is very
>good. Asynchronous protocols are tricky, and I'm not sure I understand
>all details, but it certainly looks like good and robust
>engineering. Incidentally, I have seen a proprietary protocol invented
>by Sony for high speed communication between a PC and their
>DataDiscman, using similar principles. Keep up the good work!
>
cut cut......
{Quote hidden}

If anyone is seriously interested in the long reply to this please email me
direct and I will send a copy or upload to the pic list if there is a number
of people asking.

Regards

Jim





-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Now available WARP-3
Programs all PICs, 3 textool sockets. can reduce erase time 40-50%
ISP port,  fast, All options. 24Cxx & 93Cxx serial eeprom read/program
bonus offer.  Price: TBA approx $100US

email KILLspamnewfoundspam.....ne.com.au
------------------------------------------------------------------

1995\11\14@084544 by Ray Bellis

flavicon
picon face
I missed the original posting detailing a good asynchronous
bidirectional protocol.  I need something similar myself so
I'd be grateful if someone would send me a copy.

Thanks,

Ray.

1995\11\15@090947 by eyal

flavicon
face
On Thu, 09 Nov 95 John Payson wrote:


---------- cut------------

>
> I've been working on a good bus protocol for potentially-busy > CPU's.

---------- cut -----------

> Protocol:
>   All data bytes are formatted as nine bits:
>   a "0" start bit and eight data bits.
>   Other than during a byte, all "1" bits received will be ignored.  Any
>   device transmitting should send at least one "1" bit before the first zero
>   bit.
>
---------- cut -----------

Can you please explain the last sentence.
It looks like a limitation to me (if one data bit mast be '1' there is only
7 data bits).


Eyal Oppenheimer
ASE R&D
Aladdin Knowledge Systems Ltd.
Tel:    +972-3-537-5795
Fax:    +972-3-537-5796
E-mail: spam_OUTeyalspamKILLspamaladdin.co.il
WWW Home Page:  http://www.aks.com/

'[PICLIST] Sensing RC receiver impulses & PWM motor'
1995\11\16@073047 by Tony Chilton

flavicon
face
>
> I have built a small RX-FM receiver with synthetized frenquency for RC-model.
> This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
> a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
> since 2 months - no crash !!! -
> If you are interested in PIC code, schematic and PCB, I will be happy to post
> you the whole document.
> I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
> 8031.
>
>   Philippe TECHER at "RemoveMEsonyedeRemoveMEspamEraseMEiway.fr"
>

I would appreciate a copy

regards

Tony Chilton

1995\11\16@090619 by EFBRYA

flavicon
face
>
> I have built a small RX-FM receiver with synthetized frenquency for RC-model.
> This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
> a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
> since 2 months - no crash !!! -
> If you are interested in PIC code, schematic and PCB, I will be happy to post
> you the whole document.
> I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
> 8031.
>
>   Philippe TECHER at "KILLspamsonyedespamspamBeGoneiway.fr"
>

I like a copy

Thanks!

Eric Bryan
efbryaspamspamacxiom.com

1995\11\16@232936 by Joel Carvajal

flavicon
face
>
> I have built a small RX-FM receiver with synthetized frenquency for RC-model.
> This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
> a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
> since 2 months - no crash !!! -
> If you are interested in PIC code, schematic and PCB, I will be happy to post
> you the whole document.
> I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
> 8031.
>
>   Philippe TECHER at "RemoveMEsonyedespamBeGonespamRemoveMEiway.fr"
>

I like a copy

Thanks!

Joel R. Carvajal
KILLspamjoelspamBeGonespamtds.pfi.net

1995\11\18@100402 by wurmfeld

picon face
Hi, I am looking for just a link, I am currently modifing my son's toy
school bus with a motor and lights... I was looking at infrared to control
it. Perhaps what you have can also do the trick. Please EMAIl me the details
to @spam@davidwSTOPspamspam@spam@ggx.com.


Many Thanks,
David.

1995\11\18@104216 by Mohamad Shalan

flavicon
face
I am interested in the infrared control. Let me know if u
get anything

       bye,
       shalan.

1995\11\18@213711 by A.Perkins

flavicon
face
At 08:30 AM 11/8/95 +0100, you wrote:

>I have built a small RX-FM receiver with synthetized frenquency for RC-model.
>This receiver use RF and PLL MOTOROLA chip, for RF part and a PIC16C57 with
>a small EEPROM to decode the RC signal. This circuit run in 2 meters glider
>since 2 months - no crash !!! -
>If you are interested in PIC code, schematic and PCB, I will be happy to post
>you the whole document.
>I 'm now developping a TX-FM synthetized tranceiver with LCD panel and a
>8031.
>
>  Philippe TECHER at "sonyedespamBeGonespamspamBeGoneiway.fr"
>

I'd love to get a copy.

Thanks  AP

'Self-timed bus protocols (was: slave & master conf'
1995\11\20@121318 by Martin Nilsson

picon face
John Payson wrote in an earlier message to the Piclist that he has a
3-wire communication protocol for connecting an arbitrary number of
devices that may be arbitrarily busy. However, to the best of my
knowledge, he has not given any further details of his protocol.

I think this idea is very interesting. Among the potential advantages
of such a protocol is that it wouldn't require guaranteed response
times from the bus nodes. It would run faster with faster technology,
without a redefinition of the protocol. No problems with skew.  Less
problems with noise, cable capacitance, etc. I think most of you who
have experienced interfacing an I2C device to a PC have felt the need
for something like this,

Here is my version of the bit layer for such a self-timed serial bus
protocol (S2P?).  I don't think it can be done in too many ways, and
several of you have probably come to the same conclusions. I'm
interested in your opinions and solutions.

The bus uses three wires A, B, and C, conceptually pulled-up
open-collector connected like I2C. (It could be an optical bus or
a combinatorial circuit, of course.)  An idle state is when exactly
one of the bus lines is asserted, A, B, or C.

Suppose the current idle bus state is A. A bus master sends a one by
asserting B and releasing A. When the slaves see the transition A->AB
they also assert B and release A. The slaves play "follow the leader."
When A goes high, the master knows that everybody has received the
bit, and the bus is in the new idle state B. If the master had wanted
to send a zero, it asserts C and causes a bus transition sequence
A->AC->C. So far, everything is rather simple. Only two transitions is
necessary for sending one bit.  The bandwidth is 1/3 bits/wire/time
unit, where a time unit is four times the propagation delay of the bus.

Suppose again that the current idle state is A.  In order to transfer
control to a new master, the old master asserts B, releases A, and
converts to a slave. When the new master sees that B is asserted, it
asserts C and releases A. The new master waits until only C is asserted.
Then it asserts A and releases C. The sequence of bus states is
A->AB->ABC->BC->C->AC->A.
A slave will see one of the following subsequences:
A->AB->ABC->BC->C->AC->A.
A->AB->BC->C->AC->A.
A->ABC->BC->C->AC->A.
and it should assert B, C, and A in sequence. This control transfer
can't be done in many ways without risking deadlock. For instance,
a sequence
A->AC->ABC->BC->C->CA->A
could be seen by a slave as
A->AC->BC->...
and could be mistaken for the sequence
A->AC->C->BC->B...
which would cause deadlock.

The really tricky thing is arbitration in a multi-master system.  This
is impossible in a pure self-timed system, so there are two
possibilities:

1) Require that a new master always receives control from an
old master, in a round-robin or similar manner (ie. no arbitration).
2) Allow a non-self-timed procedure for arbitration.

The disadvantage with the first alternative is that the procedure of
transfering control may take some time to find the node that wants to
become master. However, it isn't very easy to come up with a practical
procedure for the second alternative. For instance, the simple
arbitration procedure where each node tries to send a 1 first in John
Payson's 2-wire scheme will deadlock the bus if both nodes contend
simultaneously. Ideas?

Slaves can attract the attention of a master in an idle state A by
pretending to be masters, and letting the master resume control
with the control transfer procedure above.

[Nerd warning] A five-wire protocol can be constructed in the same way
as the three-wire scheme. Then we get 2/5 = 0.4 bits/wire/time unit. It can
be further generalized to n wires, of which k are asserted in an idle
state. I spent saturday night proving that the maximum bandwidth/wire
 2
is log Phi bits/wire/time unit = 0.694, where Phi is the golden ratio =
1.618... . I hadn't expected this ratio to go over 0.5, but one can get
arbitrarily close to it for large n (it is a tight bound).
Some interesting pairs (n, bits) are
        (3, 1), (5, 2), (7, 3), (9, 4), (15, 8), (62, 40).
For 3 < bits < 39, 2*n = 3*(bits+2). In practice, it is rather complicated
to decode the signals for large n, so a more practical way would be to use
the five-wire scheme replicated. This would produce (10, 4) and (20, 8)
solutions which are not all that bad.

Cheers,

Martin Nilsson
Swedish Institute of Computer Science    E-mail: spamBeGonemnspamsics.se
Box 1263, S-164 28 Kista                 Fax: +46-8-751-7230
Sweden                                   Tel: +46-8-752-1574

1995\11\21@031052 by John Payson

flavicon
face
> John Payson wrote in an earlier message to the Piclist that he has a
> 3-wire communication protocol for connecting an arbitrary number of
> devices that may be arbitrarily busy. However, to the best of my
> knowledge, he has not given any further details of his protocol.

Sorry 'bout that. :-)

> I think this idea is very interesting. Among the potential advantages
> of such a protocol is that it wouldn't require guaranteed response
> times from the bus nodes. It would run faster with faster technology,
> without a redefinition of the protocol. No problems with skew.  Less
> problems with noise, cable capacitance, etc. I think most of you who
> have experienced interfacing an I2C device to a PC have felt the need
> for something like this,

Well, there are skew and such requirements to be dealt with if cable lengths
are significant, but in most cases uniformity of signal arrival should not
be a problem; the biggest limitation on speed will likely come from the CPU
speeds since the protocol is intended for non-hardware-assisted applications.

{Quote hidden}

Nice scheme.  Unfortunately, I think it breaks if master sends a 1 followed
by a 0.  Specifically: XYZ are the devices [X master]; for each state the
devices following the name in uppercase are those that are asserting the
line, those in lowercase are those that have last sampled the line as
asserted, and those in lowercase preceded by "!" are those that have last
sampled the line unasserted:

A=xYZ B=X
A=xyZ B=XY
A=y B=XYZ ; Z has released A; X and Z have polled it and seen it high; Y
           hasn't polled it yet.
A=XZ B=Y  ; B is still waiting for A to be de-asserted.

It looks like you account for this in your change-of-master handling (which
you IMHO overcomplicate) but you don't account for it in the bit-sending
protocol.

My protocol for three wires or four-wires low-overhead is as follows:
[wire names: "0", "1", "K", and "A" for zero, one, acK, and Attention;
 the Attention wire is optional]

[in four-wire state description "-" means wire asserted by nobody; "M"
 means asserted by master only; "S" by slave only; "X" by "everyone";
 "*" by master and [maybe] slaves]

Idle State: 01KA = --XX
Send Zero : 01KA = M-SX  X--X  S-MX --XX
Send One  : 01KA = -MSX  -X-X  -SMX --XX

Clobber   : 01KA = M-SX  XmSM  SX-M   -X-X  -SMX  --XX [see below]

Signal Attention: 01KA = ***S  MMX-  --SM  ---X

If a device is trying to send a "0" when clobber state occurs [either
XXXX or XX-X], it should forfeit to the device sending the "1".  Similarly,
a "0" should not be registered by a receiver until the "--XX" state has been
reached.  If a device doesn't think it will need any communication for a
while, [and other devices know this] it may go into hybernation [all lines
floating except "A", which is asserted] unless/until it sees all lines are
asserted.  In this case, it should assert K and float A.  If A rises before
"0" or "1" does, the device should assume an attention sequence and start
watching for possibly useful data.  If "0" or "1" rises, the device should
float "K", assert "A", and go back to sleep.

> Suppose again that the current idle state is A.  In order to transfer
> control to a new master, the old master asserts B, releases A, and
> converts to a slave.

With a protocol like the above, there is no such complex requirement for a
master/slave handoff.  Since everyone [including the old and new master]
explicitly acknowleges everything they see, no one except the master needs
to know who's master.

> The really tricky thing is arbitration in a multi-master system.  This
> is impossible in a pure self-timed system, so there are two
> possibilities:

Why is arbitration impossible in a self-timed system if devices have
unique addresses?

{Quote hidden}

Well, I think for a 10/4 solution an easier approach is to have two control
wires and eight data wires.  In the idle state, the wires are
 X- lastbyte
To send two bytes of data, the transitions should be
 SM -byte 1-
 -X -byte 1-
 MS -byte 2-
 X- -byte 2-

Not as mathematically elegant as an arithmetic code, but easier I suspect.
BTW, does your formula consider deadlock avoidance as a requirement?

1995\11\21@031052 by John Payson

flavicon
face
> John Payson wrote in an earlier message to the Piclist that he has a
> 3-wire communication protocol for connecting an arbitrary number of
> devices that may be arbitrarily busy. However, to the best of my
> knowledge, he has not given any further details of his protocol.

Sorry 'bout that. :-)

> I think this idea is very interesting. Among the potential advantages
> of such a protocol is that it wouldn't require guaranteed response
> times from the bus nodes. It would run faster with faster technology,
> without a redefinition of the protocol. No problems with skew.  Less
> problems with noise, cable capacitance, etc. I think most of you who
> have experienced interfacing an I2C device to a PC have felt the need
> for something like this,

Well, there are skew and such requirements to be dealt with if cable lengths
are significant, but in most cases uniformity of signal arrival should not
be a problem; the biggest limitation on speed will likely come from the CPU
speeds since the protocol is intended for non-hardware-assisted applications.

{Quote hidden}

Nice scheme.  Unfortunately, I think it breaks if master sends a 1 followed
by a 0.  Specifically: XYZ are the devices [X master]; for each state the
devices following the name in uppercase are those that are asserting the
line, those in lowercase are those that have last sampled the line as
asserted, and those in lowercase preceded by "!" are those that have last
sampled the line unasserted:

A=xYZ B=X
A=xyZ B=XY
A=y B=XYZ ; Z has released A; X and Z have polled it and seen it high; Y
           hasn't polled it yet.
A=XZ B=Y  ; B is still waiting for A to be de-asserted.

It looks like you account for this in your change-of-master handling (which
you IMHO overcomplicate) but you don't account for it in the bit-sending
protocol.

My protocol for three wires or four-wires low-overhead is as follows:
[wire names: "0", "1", "K", and "A" for zero, one, acK, and Attention;
 the Attention wire is optional]

[in four-wire state description "-" means wire asserted by nobody; "M"
 means asserted by master only; "S" by slave only; "X" by "everyone";
 "*" by master and [maybe] slaves]

Idle State: 01KA = --XX
Send Zero : 01KA = M-SX  X--X  S-MX --XX
Send One  : 01KA = -MSX  -X-X  -SMX --XX

Clobber   : 01KA = M-SX  XmSM  SX-M   -X-X  -SMX  --XX [see below]

Signal Attention: 01KA = ***S  MMX-  --SM  ---X

If a device is trying to send a "0" when clobber state occurs [either
XXXX or XX-X], it should forfeit to the device sending the "1".  Similarly,
a "0" should not be registered by a receiver until the "--XX" state has been
reached.  If a device doesn't think it will need any communication for a
while, [and other devices know this] it may go into hybernation [all lines
floating except "A", which is asserted] unless/until it sees all lines are
asserted.  In this case, it should assert K and float A.  If A rises before
"0" or "1" does, the device should assume an attention sequence and start
watching for possibly useful data.  If "0" or "1" rises, the device should
float "K", assert "A", and go back to sleep.

> Suppose again that the current idle state is A.  In order to transfer
> control to a new master, the old master asserts B, releases A, and
> converts to a slave.

With a protocol like the above, there is no such complex requirement for a
master/slave handoff.  Since everyone [including the old and new master]
explicitly acknowleges everything they see, no one except the master needs
to know who's master.

> The really tricky thing is arbitration in a multi-master system.  This
> is impossible in a pure self-timed system, so there are two
> possibilities:

Why is arbitration impossible in a self-timed system if devices have
unique addresses?

{Quote hidden}

Well, I think for a 10/4 solution an easier approach is to have two control
wires and eight data wires.  In the idle state, the wires are
 X- lastbyte
To send two bytes of data, the transitions should be
 SM -byte 1-
 -X -byte 1-
 MS -byte 2-
 X- -byte 2-

Not as mathematically elegant as an arithmetic code, but easier I suspect.
BTW, does your formula consider deadlock avoidance as a requirement?

'PIC16C84 & PortB interrupt'
1995\11\23@023010 by Dan Matthews

picon face
Sorry Andy,

I hate to correct you when you are 99.9% right, but...

In the PIC16CXX architecture EVERY instruction that accesses a register
performs a read first, for the exact reason mentioned, simplification of design.

In this case, a MOVWF to PORTB during what would be a change on PORTB
interrupt will in fact clear the interrupt condition.

       best regards,

               Dan Matthews

At 12:03 PM 11/13/95 -0800, you wrote:
{Quote hidden}

1995\11\23@133253 by Andrew Warren

flavicon
face
Dan Matthews <TakeThisOuTdmatthewspamspamRemoveMEprimenet.com> wrote:

> I hate to correct you when you are 99.9% right, but...
>
> In the PIC16CXX architecture EVERY instruction that accesses a
> register performs a read first, for the exact reason mentioned,
> simplification of design.
>
> In this case, a MOVWF to PORTB during what would be a change on
> PORTB interrupt will in fact clear the interrupt condition.

Thanks, Dan...  My message to John Payson was just the singlw word,
"no", so I guess the portion that was "99.9% right" was the
list's mail address, his quoted question, and my signature.

It was bad enough when only instructions that performed an EXPLICIT
read or read-modify-write kept the interrupt from happening... This
new information makes the change-on-portB interrupt almost
COMPLETELY worthless.  Does Microchip see this as a bug and plan to
correct it in future revs of the chip?

-Andy


Andrew Warren - KILLspamfastfwdspamspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California

1995\11\23@232947 by Dan Matthews

picon face
Actually, the "99.9% correct" was in reference to your many other extensive
replies found here and on the BBS.

       Best regards,

               Dan Matthews

At 10:30 AM 11/23/95 -0800, you wrote:
{Quote hidden}

1995\11\24@013644 by Martin J. Maney

flavicon
face
On Thu, 23 Nov 1995, Andrew Warren wrote:

> It was bad enough when only instructions that performed an EXPLICIT
> read or read-modify-write kept the interrupt from happening... This
> new information makes the change-on-portB interrupt almost
> COMPLETELY worthless.  Does Microchip see this as a bug and plan to
> correct it in future revs of the chip?

I have no connection with Microchip other than that I'm designing a 16C73
into a product currently being prototyped, but I believe I can predict
the answer.  They will say "no".  The data sheet has always [always = in
the 1994 and 1995/1996 books] implied that this feature was intended for
use in applications where the input change is used to wake the chip from
a sleep state, and of course when the chip is sleeping it won't be
reading or writing the port B pins and disturbing the change sensing...

There's even an application note that demonstrates exactly this use,
isn't there?

So I believe that this is _exactly_ the operation that Microchip designed
into those pins on port B, and the bug is only that you wish they worked
otherwise than they do.  The 1995/1996 databook is pretty explicit about
this:  "the interrupt on change feature is reccomended for wake-up on key
depression operation and operations where port B is used only for the
interrupt on change feature."  I think they could allow as well
applications where bit 0 is used as an external interrupt input (for
non-sleeping applications).

1995\11\28@121907 by BBoles

flavicon
face
    Actually, we understand this as a bug and it is being fixed in all new
    devices including upcoming 'A' versions of '74, '73, '65, '64 , etc.

    Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: PIC16C84 & PortB interrupt
Author:  "Martin J. Maney" <spam_OUTmaneyRemoveMEspamEraseMEMCS.COM> at Internet_Exchange
Date:    11/24/95 12:34 AM


On Thu, 23 Nov 1995, Andrew Warren wrote:

> It was bad enough when only instructions that performed an EXPLICIT
> read or read-modify-write kept the interrupt from happening... This
> new information makes the change-on-portB interrupt almost
> COMPLETELY worthless.  Does Microchip see this as a bug and plan to
> correct it in future revs of the chip?

I have no connection with Microchip other than that I'm designing a 16C73
into a product currently being prototyped, but I believe I can predict
the answer.  They will say "no".  The data sheet has always [always = in
the 1994 and 1995/1996 books] implied that this feature was intended for
use in applications where the input change is used to wake the chip from
a sleep state, and of course when the chip is sleeping it won't be
reading or writing the port B pins and disturbing the change sensing...

There's even an application note that demonstrates exactly this use,
isn't there?

So I believe that this is _exactly_ the operation that Microchip designed
into those pins on port B, and the bug is only that you wish they worked
otherwise than they do.  The 1995/1996 databook is pretty explicit about
this:  "the interrupt on change feature is reccomended for wake-up on key
depression operation and operations where port B is used only for the
interrupt on change feature."  I think they could allow as well
applications where bit 0 is used as an external interrupt input (for
non-sleeping applications).


'Re[2]: PIC16C84 & PortB interrupt'
1995\12\01@112214 by John Payson
flavicon
face
> On Thu, 23 Nov 1995, Andrew Warren wrote:
>
> > It was bad enough when only instructions that performed an EXPLICIT
> > read or read-modify-write kept the interrupt from happening... This
> > new information makes the change-on-portB interrupt almost
> > COMPLETELY worthless.  Does Microchip see this as a bug and plan to
> > correct it in future revs of the chip?

[bboles replied]
>
>      Actually, we understand this as a bug and it is being fixed in all new
>      devices including upcoming 'A' versions of '74, '73, '65, '64 , etc.
>
>      Rgds, Brian.

What precisely is Microchip fixing in the 'A' versions?  Most of the quirks
I can see with the PortB behavior (and read-modify-write in general) are
things that a "clever programmer" might exploit in some way.

Also, what is the specific behavior of the register read logic?  Does it
do the read for any opcode whose top six bits are not "00 0000", or does
it read regardless?  If the latter, does this cause any potential problems
with serial I/O on the '74 [since reading the input latch clears it, and
the output latch shares the input latch's address]?

PS--Personally, my preferred implementation for an "interrupt-on-change"
pin feature would be to have the interrupt triggered if/when the signal on
the port pin does not match the output latch.  This could then be easily
cleared either by "movf port,f" or by most read-modify-write operations on
the port.

1995\12\01@173239 by BBoles

flavicon
face
    Without getting into a lot of detail on what is different on 'A'
    parts, the PortB is fixed such that it will work as described in the
    datasheet.  We did think about a interrupt on change that would work
    relative to the output port, but that would be a spec change.

    The device does a read for any instruction cycle except literals.
    This wasn't a problem except on the 74/64 with IBF flag in TRISE.
    Here a RETURN (000Dh) instruction would read PORTD and clear the IBF
    flag. Oops!  There isn't an instruction that can accidentally hit
    SSPBUF.

    P.S. also fixed on Rev. A.

    Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: PIC16C84 & PortB interrupt
Author:  John Payson <TakeThisOuTsupercatRemoveMEspam@spam@MCS.COM> at Internet_Exchange
Date:    12/1/95 10:20 AM


> On Thu, 23 Nov 1995, Andrew Warren wrote:
>
> > It was bad enough when only instructions that performed an EXPLICIT
> > read or read-modify-write kept the interrupt from happening... This
> > new information makes the change-on-portB interrupt almost
> > COMPLETELY worthless.  Does Microchip see this as a bug and plan to
> > correct it in future revs of the chip?

[bboles replied]
>
>      Actually, we understand this as a bug and it is being fixed in all new
>      devices including upcoming 'A' versions of '74, '73, '65, '64 , etc.
>
>      Rgds, Brian.

What precisely is Microchip fixing in the 'A' versions?  Most of the quirks
I can see with the PortB behavior (and read-modify-write in general) are
things that a "clever programmer" might exploit in some way.

Also, what is the specific behavior of the register read logic?  Does it
do the read for any opcode whose top six bits are not "00 0000", or does
it read regardless?  If the latter, does this cause any potential problems
with serial I/O on the '74 [since reading the input latch clears it, and
the output latch shares the input latch's address]?

PS--Personally, my preferred implementation for an "interrupt-on-change"
pin feature would be to have the interrupt triggered if/when the signal on
the port pin does not match the output latch.  This could then be easily
cleared either by "movf port,f" or by most read-modify-write operations on
the port.

'MAX232 PINOUTS & RS252'
1995\12\19@020226 by Newfound Electronics

flavicon
face
>Can anyone send me the pinout for a MAX232 chip?
>EraseMEstevecRemoveMEspamrain.org

 C1+ 1   16 Vcc
  V+ 2   15 GND
 C1- 3   14 T1out
 C2+ 4   13 R1in
 C2- 5   12 R1out
  V- 6   11 T1in
T2out 7   10 T2in
R2in 8    9 R2out


>
>Also does anybody know the difference between the MAX232 and MAX252?
>
>Thks Ben
>

The data for the MAX252 in in the '92 MAXIM data book. I do not have it, sorry.
From the summary here's what I can tell.

MAX252  RS232 "ISOLATION" INTERFACE

* Needs no caps,
* Two rx/tx drivers .
* "A" and "B" versions with "B" cheaper because of less isolation (500V vs
1500V).
* 20Kvps rated.
* MAX252  has shutdown and tristate modes. (From this we know they are not
pin compatable)

Sorry for the delay guys, my new MAXIM data book arrived just today. There
are some very sexy parts in it!

Regards

Jim Robertson

1995\12\19@023626 by Steve Childress

flavicon
face
------ =_NextPart_000_01BACDA1.AE5D78A0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Got a phone # for ordering a catalog?

----------
From:   Newfound Electronics[SMTP:spamnewfound.....spamspamNE.COM.AU]
Sent:   Tuesday, December 19, 1995 1:00 PM
To:     Multiple recipients of list PICLIST
Subject:        MAX232 PINOUTS & RS252

>Can anyone send me the pinout for a MAX232 chip?
>stevecspam_OUTspam@spam@rain.org

 C1+ 1   16 Vcc
  V+ 2   15 GND
 C1- 3   14 T1out
 C2+ 4   13 R1in
 C2- 5   12 R1out
  V- 6   11 T1in
T2out 7   10 T2in
R2in 8    9 R2out


>
>Also does anybody know the difference between the MAX232 and MAX252?
>
>Thks Ben
>

The data for the MAX252 in in the '92 MAXIM data book. I do not have it, sorry.
>From the summary here's what I can tell.

MAX252  RS232 "ISOLATION" INTERFACE

* Needs no caps,
* Two rx/tx drivers .
* "A" and "B" versions with "B" cheaper because of less isolation (500V vs
1500V).
* 20Kvps rated.
* MAX252  has shutdown and tristate modes. (From this we know they are not
pin compatable)

Sorry for the delay guys, my new MAXIM data book arrived just today. There
are some very sexy parts in it!

Regards

Jim Robertson



------ =_NextPart_000_01BACDA1.AE5D78A0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IigHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG
AEABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAFgAAAAAAAAAgSsfpL6jEBmdbgDd
AQ9UAgAAAABwaWMgbWljcm9jb250cm9sbGVyIGRpc2N1c3Npb24gbGlzdABTTVRQAFBJQ0xJU1RA
TUlUVk1BLk1JVC5FRFUAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABcAAABQSUNMSVNUQE1J
VFZNQS5NSVQuRURVAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAmAAAAJ3BpYyBtaWNyb2NvbnRy
b2xsZXIgZGlzY3Vzc2lvbiBsaXN0JwAAAAIBCzABAAAAHAAAAFNNVFA6UElDTElTVEBNSVRWTUEu
TUlULkVEVQADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAA98+AQiABwAYAAAASVBNLk1p
Y3Jvc29mdCBNYWlsLk5vdGUAMQgBBIABABsAAABSRTogTUFYMjMyIFBJTk9VVFMgJiBSUzI1MgBk
BgEFgAMADgAAAMsHDAASABcAJAAmAAEAUgEBIIADAA4AAADLBwwAEgAXACQAEQABAD0BAQmAAQAh
AAAANTExODIwREE3RjM5Q0YxMTk0NUE0NDQ1NTM1NDAwMDAAzwYBA5AGANQFAAASAAAACwAjAAAA
AAADACYAAAAAAAsAKQAAAAAAAwA2AAAAAABAADkAgPOEu+TNugEeAHAAAQAAABsAAABSRTogTUFY
MjMyIFBJTk9VVFMgJiBSUzI1MgAAAgFxAAEAAAAWAAAAAbrN5LuE2iAYUjl/Ec+UWkRFU1QAAAAA
HgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABAAAABzdGV2ZWNAcmFpbi5vcmcAAwAGEGbxm9cD
AAcQEAMAAB4ACBABAAAAZQAAAEdPVEFQSE9ORSNGT1JPUkRFUklOR0FDQVRBTE9HPy0tLS0tLS0t
LS1GUk9NOk5FV0ZPVU5ERUxFQ1RST05JQ1NTTVRQOk5FV0ZPVU5EQE5FQ09NQVVTRU5UOlRVRVNE
QVksREUAAAAAAgEJEAEAAABZBAAAVQQAAGYHAABMWkZ1+26YAv8ACgEPAhUCqAXrAoMAUALyCQIA
Y2gKwHNldDI3BgAGwwKDMgPFAgBwckJxEeJzdGVtAoMzdwLkBxMCgH0KgAjPCdk78RYPMjU1AoAK
gQ2xC2DgbmcxMDMUUAsKFFFFC/JjAEAgR28FQGEIIHBoAiBlICMgXwIQBcAFsASBC4BnGyFjZmEB
kBWgZz8KhQqLbBBpMTgwAtFpLTE8NDQN8AzQHyMLWTE21wqgA2AT0GMFQC0hRwqH1x/7DDAgxkYD
YToiTiDGBwyCB7ICEHVuZCBFDmwhAQNgAwBjc1tTME1UUDobgCYkQE4ARS5DT00uQVV+XSHvIv0G
YAIwJC8lO1QBClBzZGF5LCBEiwWQE+BiBJAgMTktYCkuEDk1LgA6HsAgUGZNKN8i/VRvKx8lO01Y
dWx0BSAmoCAWEGOPBSAIkAIwBCBvZiAegAMTwC7gSUNMSVNU4y8fKe51YmohATE/MkwwQVgyMxHg
NNBOT1RVVAXwJgfwUxhAMnMdTx5TMzYfxxpFIMY+9kMDkQBweRtyEbAmYQeA2CB0aBuQM+BuCGAF
QL8b0hswOZURcAUgHTY+E8FSdgWQQHILcS4FsGfjOvxDQEMxKy4AQ0EgkPAgVmNjQudEEEOQEeAj
Q9EugEdORELpLSBqM0PCNCzgMT+hQugyz0OQRuBD0UaQUjELgEdZ/0ZwLoBD0RHgSJBHKkQQRnCf
RABD0RrQRwBIt1QyP6JeN0PCLtBMUEi4Uk0xILo4RLI5TdFHKDr8PkEGgEFsc28gZG8HkcM+QQbg
ZHkgaz+QB+B1PzJkBpBmBJAJ8C2gIPkt0HR3CeE/IzmVAHAmcI85kjrQQPdBBlRoawQg/kIJ8E/d
S+ZSUhzRG8NTtp060CBOAU4BPzInORHgGTmRSU1YJAbgb2su9CBJUREgP5AFQBGAQbANWWB0LWBQ
8HJyeS7HQQYj4j8jc3VtAMBcsOtb4FLBJwQgdxGABUBbYOMcwFORZWxsXNYKhVkFCzqSOdEiNRBP
TEFUEElPTiJbUE5URaBSRkFDRTr8KgexjwmABCA/kByxcHMsY2fEVHdRAHJ4LwzQURA3BRBBsBGg
IFzWY9AiQbNiQFRiIkJiQGYyaQIg217BXEBoZ5MRcGVkkC3h+y3QHMB1EbA0QweQBCAEAEcG8BzQ
aCEgKDUewFbdZ9BzCoVFYGtBKWaIAdD8S3ZkoDOQHNAJgGaIYMazEYAEIHNoP7BRIHc+Ir8mcCbQ
NJFtkT7wBHFzW0D+KF1lBABe0BuQUfZR0ArA/xuQW7EKhT9xHLADcAqwAZH1JqApOvxTXJJYdw2w
C2DZUdBndROwLWBtUdAnoW9aTnJxZhImcGppwAVAdP8EcC1AW0BX8RYQCoVyglDw7z8BZjFR0BGw
eFHQCrE0IYlZcnQhOvxSZWcLEftrlgqFSgdwB/Et0TQgAiC/Tv87nzyvIQIKhRUxAINQAAAAAwAQ
EAAAAAADABEQAAAAAEAABzAgB/yu5M26AUAACDAgB/yu5M26AR4APQABAAAABQAAAFJFOiAAAAAA
1sU=

------ =_NextPart_000_01BACDA1.AE5D78A0--

1995\12\19@201250 by Newfound Electronics

flavicon
face
Steve Childress wrote:

>------ =_NextPart_000_01BACDA1.AE5D78A0
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>
>Got a phone # for ordering a catalog?
>

Yer, but I don't think Veltek send them outside Australia. Anyway, with
maxim you actually need 4 volumes, 1992/93/94/95 as they don't repeat data
sheets.

What is all this base64 stuff and  how do I decode it? Can Eudora do  it for
me or do I need a special utility?

>
>------ =_NextPart_000_01BACDA1.AE5D78A0
>Content-Type: application/ms-tnef
>Content-Transfer-Encoding: base64
>
>eJ8+IigHAQ

etc, etc

>1sU=
>
>------ =_NextPart_000_01BACDA1.AE5D78A0--
>
>

Regards,

Jim


'Current sink & inductive loads'
1996\03\26@110053 by Harrison Cooper
flavicon
face
Well, isn't it wonderfull when you find out a device went obsolete
and no one told you....case in point is a relay I have been using
for years.  Typically, I'll drive it thru a small signal transistor
by putting it in saturation, and sinking the current thru the collector.
So, now (just before I am getting some boards made), I must find a new
relay.  OK, here is one that need 30mA at 5V.  Choices are 1)same old
way using a transistor, or 2) sink the current via the PIC output port.
As I remember some past posts, someone mentioned that you could use two
ports tied together to get a max of 50mA current sink capacity.
However, that makes me a little nervous on making sure that both pins
switch at the same time, such that neither one would be taking a larger
spike of current.  In addition, being this is an inductive load, a larger
current inrush will occur (not sure what this is spec'ed at).  Will the
PIC ports clamp at 25mA for inrush ?  Of course, I will put a diode across
the coil to help with switching noise. Reliability points me to using the
transistor, simplified manufacturing and PC layout push me toward just
using the PIC port.

What say folks...

.....hcooperspamspam.....corp.es.com

'Visiting ultrasonics, again... (&again)'
1996\03\27@112119 by terogers

flavicon
face
Harrison Cooper wrote:
>
> Well, since the ultrasonic sensor I am trying to build it
> interfaced to a PIC, its legal to talk about it here, right?
>
> OK, I tried a couple of different circuits.  To generate the
> (more stuff here..)

You could try to get your analog guy to sit down and look at what's in
the Polaroid unit. Don't make any rash assumptions - it's like the
comments found buried in the SS system legacy code ('Subtle!'). I can't
really tell you what to do (what I've done belongs to Time Tech) but I
can tell you that just 'cause it's simple doesn't mean it's easy. If you
look at it right you'll get what you want.

Tom Rogers VP - R&D Time Tech, Inc.

'Current sink & inductive loads'
1996\03\27@175100 by John Payson

flavicon
face
> As I remember some past posts, someone mentioned that you could use two
> ports tied together to get a max of 50mA current sink capacity.
> However, that makes me a little nervous on making sure that both pins
> switch at the same time, such that neither one would be taking a larger
> spike of current.

You certainly should ensure in software that both ports are changed at the
same time (using an instruction like MOVWF, ANDWF, etc.) rather than using
BSF/BCF.  Beyond that, though, there shouldn't be any problems.

>                   In addition, being this is an inductive load, a larger
> current inrush will occur (not sure what this is spec'ed at).  Will the
> PIC ports clamp at 25mA for inrush ?  Of course, I will put a diode across
> the coil to help with switching noise. Reliability points me to using the
> transistor, simplified manufacturing and PC layout push me toward just
> using the PIC port.

Any load inductance will actually REDUCE the current inrush when it's turned
on [but will try to keep current flowing when it's turned off].  Load capaci-
tance will increase inrush currents on power-on, and will require outrush
currents for rapid power-off.  Motors usually behave like moderate-sized
inductors when not moving and like capacitors when they are moving.  Relays
are usually pretty much straight inductive.


'Power Brown Outs & meeting massacre'
1996\04\04@001625 by Ed VanderPloeg
flavicon
face
      James,

      I had the same problem, but fortunately my product was in the
      early prototype stage at the time.  The PIC's main CPU and
      oscillator sections start up at a lower voltage than does the
      memory, thus locking the chip up upon brown-out or power-up
      when the supply doesn't ramp up quick enough.

      The watchdog timer will only protect you against software
      lock-up, not against the CPU core itself going off into the
      twilight zone, which is what it sounds like you have here.

      Without getting into too much detail on the various power-up
      requirement specs, the internal power-up timer (PWRT) and
      oscillator start-up timer (OST) specs, you can simply enable
      the PWRT if your power supply will always ramp up in less than
      28ms AND the supply shuts off at low voltage instead of going
      into un-regulation mode.

      If your power supply can't do that, then simply toss a Motorola
      MC34064 onto the /MCLR (active low RESET) pin, along with a cap
      and resistor or two if you like.  This is a little 3 pin
      undervoltage sensing IC, and will hold the '74 in reset unless
      the voltage is above 4.6 V.  It comes in many different
      flavours like wider temperature ranges, different cutoff
      voltage like 4.3 or 2.7 volts, TO-92 or SO-8 packages, etc.
      Similiar devices are available from many other manufacturers.
      Oh, and they cost way less than $1 U.S. each in low quantities.
      The microchip databook shows some other cheap alternative
      brown-out protection circuits.

      Of course, Microchip has realized this deficiency in the
      standard '74 as well, and have introduced the '74A as a result.
       As far as I can tell (note the subtle disclaimer) the only
      difference is the addition of a brown-out reset circuit (BOR).
      When enabled via the BODEN bit (love those acronyms) the BOR
      will hold the device in reset once VDD falls below about 4V,
      and will keep it in reset until VDD has remained above 4V for
      more than 28 to 132ms (72ms nominal).

      For the BOR to kick in and reset the chip, VDD must remain
      below 4V for at least 100usec.  I assume that Microchip in
      their wisdom has made this delay less than the time is takes
      the chip lock up, though I could find no indication or
      guarantee of this in the databook.

      So basically you have three choices:  Improve your power
      supply, add in something like a MC34064 (happy rework & PCB
      changes), or go for the 74A's and save your '74 stock for a
      future project.  Now get in there and call another meeting to
      say you've got a fix.  Ok, maybe test it first.

      -Ed VanderPloeg.



______________________________ Reply Separator _________________________________
Subject: Power Brown Outs
Author:  pic microcontroller discussion list <PICLISTKILLspamspamEraseMEMITVMA.MIT.EDU> at
InterNet
Date:    4/3/96 7:34 PM


Here's a brain buster.
We have a stand alone CO gas monitor (safety equipment) that uses a
PIC16C74.
If the power supply is momentarily shorted (milliseconds), the PIC does
not recover, but locks up in random modes.
We have the Watchdog timer ON and CLRWDT is only given one time in the
main program loop.
Any ideas?  I was massacred today in an engineering meeting as this
instrument was on the verge of its first major shipment.
Thanks.

--
Regards, James Musselman, President

Radix/Cobalt Instruments, Inc.
PO Box 897
Clovis, CA  93613 USA
tel  209-297-9000
fax  209-297-9400

Check out my home page  http://rdx.com

'16C84 & TMR0 as Counter'
1996\04\25@214522 by Patrick S. Coutu

flavicon
face
       Hi Pic'ers,
     i I am having difficulty in using the 16c84's t TMR0 register.

1996\04\26@013713 by Robert Lunn

flavicon
picon face
>         Hi Pic'ers,
>       i I am having difficulty in using the 16c84's t TMR0 register.
>

Yeah...  So?

Seriously, you can't expect anybody to help unless you give a lot
more information than this!

___Bob

1996\04\29@162044 by Florian Bloemer

flavicon
face
>         Hi Pic'ers,
>       i I am having difficulty in using the 16c84's t TMR0 register.
Has anyone a source code where the 16c84 is used as a counter?
I'd like to get it.

--
nice greetings from
   _/_/_/_/_/_/   _/               _/_/_/_/        ==PGP key on request==
  _/             _/             _/       _/     _______________________
 _/_/_/_/       _/             _/       _/    / EraseMEf.bloemer@spam@spam@spam@link-r.de
_/             _/             _/       _/    / 2:2494/315@fidonet
_/             _/_/_/_/_/_/    _/_/_/_/      / 21:490/2300.23@gernet


'AVCASE51 & Windows NT/Clyde Smith-Stubbs'
1996\05\04@030520 by James Musselman
flavicon
face
Clyde Smith-Stubbs wrote:
>
> @spam@dmanzerspamspamKILLspamwimsey.com (Doug Manzer) wrote:
>
> > Although this runs fine in Borland C, the compiler gives me a
> > warning "Call to function without prototype" for:
> >This has nothing to do with the original thread.

I have AVCASE v2.12 for 80C31.  Mr Clyde, will this compiler run under windows
NT 3.51? 4.0?
thanks, James

--
Regards, James Musselman, President

Radix/Cobalt Instruments, Inc.
PO Box 897
Clovis, CA  93613 USA
tel  209-297-9000
fax  209-297-9400

Check out my home page  http://rdx.com

'X-Ray Erasure & neutrons.'
1996\05\07@033650 by Keith Dowsett

flavicon
face
>
>Some other people have tried EPROMS and OTP MCU (including PIC)
>in a nuce reactor, but with bad results. All PIC's where destroyed
>befor erasure. Only device being erased with radiation was i8751
>and the device was slightly damaged.

Yeah, slow and fast neutrons play hell with semiconductors. We have exposed
a ccd camera to neutron flux then had to rebuild it (replacing lots of
semiconductors). Even conventional transistors suffer if the dose is high
enough, let alone the tiny ones in microcontrollers.

Keith.
==========================================================
Keith Dowsett         "Variables won't; constants aren't."

E-mail:      spamBeGonekdowsettRemoveMEspamEraseMErpms.ac.uk
Phone:       0181-740-3162
Fax:         0181-743-3987

Snail mail:  MRC Clinical Sciences Centre, Cyclotron Unit.
                Hammersmith Hospital. London W12 0NN.

'Parallax vrs MPSA & 16c5x vrs 16c6x'
1996\05\14@163645 by David E. Queen

flavicon
face
{Quote hidden}

1996\05\14@173001 by hoss karoly

flavicon
face
David E. Queen wrote:
> >Also I think most of the people here speak MPASM but the book
> >is PASM. I am worried about the confusion that may be caused
> >by trying to keep the differences (what ever they are) straight.
>
> >
> >Anyone care to comment on the choice of an assemblier?

hardcore assembly wizards tend to use microchip because it lets U
make dense code
but i make small and silly things and the pasm is easy to learn and use
check out the mnemonics and decide
this is only my opinion and not the ULTIMATE TRUTH
bye
charley

'HTML @Mozilla & WWW trouble?'
1996\05\18@235936 by Scott Stephens

picon face
While we debate the appropriateness, maybe someone who commented about
@Mozilla before on this list, can explain why I can't use netscape to get
certain web sites. The host is contacted, but I never get data. And most
often, if I use a shell acount and Lynx, I can contact the web site just
fine. FTP too. I believe @Mozilla as Netscape's user name is to blame.
Mosaic is no better. Any suggestions?



At 02:21 PM 5/17/96 -0400, you wrote:
>Hi all,
>
>I recieved far more response to my posting asking for information about
>off-line viewing of HTML files than I had expected.  To the few that
>expressed dis-satisfaction with my topic, I would like to apologize.  Since
>the majority of the information I have collected and need to view is PIC
>information that was suggested or pointed to on the PICLIST, I thought it was
>appropriate....sorry.  To all those who gave me useful information...THANKS!

1996\05\20@091256 by Mike DeMetz

flavicon
face
> To:            Multiple recipients of list PICLIST <TakeThisOuTPICLISTspamMITVMA.MIT.EDU>

> While we debate the appropriateness, maybe someone who commented about
> @Mozilla before on this list, can explain why I can't use netscape to get
> certain web sites. The host is contacted, but I never get data. And most
> often, if I use a shell acount and Lynx, I can contact the web site just
> fine. FTP too. I believe @Mozilla as Netscape's user name is to blame.
> Mosaic is no better. Any suggestions?
>
Not sure what you are describing. Mozillia is Netscape's POP/SMTP
email program.
**********************************************************
*Mike DeMetz                      SYSCON International   *
*spamBeGonemikedKILLspamspamTakeThisOuTsyscon-intl.com            South Bend, IN USA     *
*aka EraseME73165.1230.....spamKILLspamcompuserve.com    using Pegasus Mail     *
**********************************************************

'PIC Tools & Basic Stamp'
1996\05\20@224123 by Jim Hobbs

flavicon
face
We have finished a 6 month project, it is done and gone.  We now have
excesses PIC and Basic Stamp development tools. I have been given a list of
what there is for sale.  Some new, some used, obviously nothing very old.
Everything has been tested to be in working order.  These are Parallax
development tools.  I don't want to offend anyone with posting a -for sale
message-, but these are good tools and someone may want to get a good deal
on them.

PIC Programmer          With latest firmware upgrade.           $75
                       Includes manuals on disk, software
                       cables and power supply.

PIC PGM Adapter         PIC 40 PIN ZIF Adapter          $25

PIC PGM Adapter         18/28 Pin SOIC Adapter          $100

PIC PGM Adapter         PIC 16C64 PLCC Adapter          $100
_________________

ClearView 'xx           PIC16Cxx emulator requires modules.     $400
                       Includes manuals, software, cables
                       and power supply.

ClearView module                      PIC16C71 module                   $75

ClearView modules                     PIC16C62/63/65/72/73/74 module    $150
_________________

Clearview '5x           PIC 16C5x emulator.  Includes   $400
                       Software, cables, and manual.
_________________

Basic Stamp I           Ten BSI; new, still in package. $25 each

Carrier boards          Two BS1 carrier boards.         $10 each
_________________

Basic Stamp II          Ten BSII; new, still in package $35 each

Carrier boards          Four BSII carrier boards.               $15 each
_________________

Stamp Experiment board  Experiment board for BSI and BSII.      $100
                       SW1 broke, but could be replaced, still
                       works though.

Everything will be shipped UPS COD, cash, money order, and cashier check only.
The PIC tools have been tested to be working.  If you have any immediate
problems, we will replace or have the item repaired.
If you are interested please email me.


:) James

1996\05\21@015332 by michele

flavicon
face
Hi, James
I'm a student from Italy, i would know if it's possible to receive  one (1)
STAMP 1 MODULE  (25$) AND ONE (1) STAMP II MODULE  (35$). May be  i need a
special software for these modules if yes, can i have it?
So if the answer to everything is yes :-), please send me something similar
to pro-forma invoice.
Thank you very much.
Michele

spammichele.mspamtelcen.caen.it

Viareggio - ITALY


{Quote hidden}

'MPLAB & win 95'
1996\05\22@073323 by pic

flavicon
face
I have just been trying to get the MPLAB S/W to work on
windows95. Everything seems to install correctly, but when
I run it up and try selecting 'Project\New' nothing happens.
If I load up an asm file and select 'File\SaveAs' nothing
happens.

I have installed the same zip file on a machine running win311,
and the whole thing seems to work fine.

Anyone had these problems?

Suggestions?

Wayne G Boyd.

1996\05\22@092458 by Wireless Scientific

flavicon
face
At 12:27 PM 5/22/96, pic wrote:
>I have just been trying to get the MPLAB S/W to work on
>windows95. Everything seems to install correctly, but when
>I run it up and try selecting 'Project\New' nothing happens.
>If I load up an asm file and select 'File\SaveAs' nothing
>happens.

I had the same problem and found that running MPLAB from the start menu
item was the problem. I didn't have time to figure out the fix then but I
created a shortcut to the exe and now everything works fine.

1996\05\22@093256 by Norm Cramer

flavicon
face
Yes, I had the same problem.  It is due to an "outdated" .dll file.  I think
it was the bwcc.dll.  Win3.11 doesn't have it in the system directory so it
uses the one in the mplab directory.  Win95 has it (I think) in the system
directory and uses it from there.  I copied the file to the system directory
and now mplab works fine.  BTW I am at work now (the Win3.11 machine) so I
can't verify the file name of the DLL that I copied but I think it was the
bwcc.dll file.  Someone else may be able to verify the file name.

Good luck,

Norm

At 12:27 PM 5/22/96 PDT, you wrote:
{Quote hidden}

1996\05\22@120113 by Pete Brink

picon face
Wayne,

Norm is absolutely correct.  The file's name is BWCC.DLL.  MPLAB installs this
DLL to the same directory as MPLAB.  Apparently there is something Microsoft is
not telling us.  Windows and Windows 95 are supposed to look first in the same
directory as the executable for any required DLLs.  Apparently this is not
happening.  Either there is already an old version of BWCC.DLL loaded by another
program, or Windows actually looks in the \SYSTEM directory first for BWCC.DLL.

In any case, to solve the problem, copy the BWCC.DLL file from the MPLAB
directory to the \WINDOWS\SYSTEM directory and your problems should go away.

Pete Brink


______________________________ Reply Separator _________________________________
Subject: Re: MPLAB & win 95
Author:  Norm Cramer <cramerSTOPspamspamDSEG.TI.COM> at Internet_Exchange
Date:    5/22/96 8:30 AM


Yes, I had the same problem.  It is due to an "outdated" .dll file.  I think
it was the bwcc.dll.  Win3.11 doesn't have it in the system directory so it
uses the one in the mplab directory.  Win95 has it (I think) in the system
directory and uses it from there.  I copied the file to the system directory
and now mplab works fine.  BTW I am at work now (the Win3.11 machine) so I
can't verify the file name of the DLL that I copied but I think it was the
bwcc.dll file.  Someone else may be able to verify the file name.

Good luck,

Norm

At 12:27 PM 5/22/96 PDT, you wrote:
{Quote hidden}


'modems & approval'
1996\06\03@095006 by Harrison Cooper
flavicon
face
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.

'modems & approval -Reply'
1996\06\03@102551 by CDSI

flavicon
face
  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.


line in----.22 cap-----|                                    | ------|--------
                                |                                    |
zener
                                | coupling transformer  |         |
                                |                                    |
zener
line in----.22 cap-----|                                    | ------|--------

 If anyone has code for a DTMF decoder for a pic chip, I am presently
looking for help in this area,   Thanks....

John Moeller

1996\06\03@103024 by Wireless Scientific

flavicon
face
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

http://www.isi.net/ebs/cermetek/index.html

That's certainly a place for me to start.

Thanks,
craig

1996\06\03@105438 by David Knell

flavicon
face
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.

{Quote hidden}

------------------------------------------------------------
David Knell
Tel: 01843 846558
Fax: 01843 846608
E-mail: daveSTOPspamspamKILLspamdave-ltd.co.uk

1996\06\03@110859 by Wireless Scientific

flavicon
face
At 10:22 AM 6/3/96, CDSI wrote:
>   If you are looking for specific telephone info, feel free to e-mail me.  I


Thanks, I'll take you up on that.

craig

1996\06\03@131212 by fastfwd

face
flavicon
face
Harrison Cooper <@spam@PICLIST.....spamspamMITVMA.MIT.EDU> 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

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.

-Andy

Andrew Warren - spamfastfwd.....spam.....ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\06\03@143948 by Eric Smith

flavicon
face
Harrison Cooper <hcooper.....spamES.COM> writes:

> 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).

Any offers?

Eric

'MPLab & programming'
1996\06\04@092548 by Harrison Cooper

flavicon
face
So, why didn't they include the various programmers, or at least
MPstart ?  I will admit its nice to edit and assemble within the same
window now, but I still have to min the window and jump into the DOS
window to run the programmer - unless I'm missing something here.
BTW, I have yet to see any crashes running it on 3 different machines
(all 486 jobs).

1996\06\04@095416 by Mike DeMetz

flavicon
face
> So, why didn't they include the various programmers, or at least
> MPstart ?  I will admit its nice to edit and assemble within the same
> window now, but I still have to min the window and jump into the DOS
> window to run the programmer - unless I'm missing something here.
> BTW, I have yet to see any crashes running it on 3 different machines
> (all 486 jobs).
>
Someone asked if they planned to support the PICSTART and they said
no.
**********************************************************
*Mike DeMetz                      SYSCON International   *
*KILLspammikedspam_OUTspamsyscon-intl.com            South Bend, IN USA     *
*aka spam_OUT73165.1230spamTakeThisOuTcompuserve.com    using Pegasus Mail     *
**********************************************************

1996\06\04@102726 by Jattie van der Linde

flavicon
face
Harrison Cooper wrote:
>
> So, why didn't they include the various programmers, or at least
> MPstart ?  I will admit its nice to edit and assemble within the same
> window now, but I still have to min the window and jump into the DOS
> window to run the programmer - unless I'm missing something here.
> BTW, I have yet to see any crashes running it on 3 different machines
> (all 486 jobs).

The Mpstart is included. Just run it from the Icon in the same
directory.

1996\06\04@131911 by fastfwd

face
flavicon
face
Mike DeMetz <.....PICLIST.....spamRemoveMEMITVMA.MIT.EDU> wrote:

> > So, why didn't they include the various programmers, or at least
> > MPstart ?  I will admit its nice to edit and assemble within the
> > same window now, but I still have to min the window and jump into
> > the DOS window to run the programmer - unless I'm missing
> > something here. BTW, I have yet to see any crashes running it on 3
> > different machines (all 486 jobs).
>
> Someone asked if they planned to support the PICSTART and they said
> no.

Guys:

MPLAB supports the Picstart Plus now, and soon will support the PRO
MATE and PRO MATE II.

-Andy

Andrew Warren - spam_OUTfastfwdTakeThisOuTspamEraseMEix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

'MPLab & Picstart - where ?'
1996\06\04@151116 by Harrison Cooper

flavicon
face
Andrew Warren had indicated that Picstart is supported by MPLab.
OK, I still can't find the interface.  I am running ver 3.01.00.
Is it in a newer version (yet to be released ?)  Like I said, I
may be missing something.

1996\06\04@161402 by fastfwd

face
flavicon
face
Harrison Cooper <EraseMEPICLISTspamBeGonespamKILLspamMITVMA.MIT.EDU> wrote:

> Andrew Warren had indicated that Picstart is supported by MPLab.

   Wait a minute... I said the Picstart PLUS was supported, not the
   old Picstart 16s.

> OK, I still can't find the interface.  I am running ver 3.01.00. Is
> it in a newer version (yet to be released ?)  Like I said, I may be
> missing something.

   You are.

   In addition to the MPLAB software which you already have, you
   need to download a file called (I think) PSPLUS.ZIP.  This file
   contains the Picstart Plus "plug-in' for MPLAB.

   -Andy

Andrew Warren - RemoveMEfastfwdspamBeGonespamspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\06\05@040516 by mike

flavicon
picon face
In message  <@spam@199606042013.NAA25026spamspamdfw-ix6.ix.netcom.com> TakeThisOuTfastfwdKILLspamspam@spam@ix.netcom.com
writes:
> Harrison Cooper <.....PICLISTRemoveMEspamMITVMA.MIT.EDU> wrote:
>
> > Andrew Warren had indicated that Picstart is supported by MPLab.
>
>     Wait a minute... I said the Picstart PLUS was supported, not the
>     old Picstart 16s.
>
Is there a good reason why the "old" picstart 16s are not supported?
There is a lot of them out there.

What about the 3rd party programmers, are (m)any of them supported?


Mike Watson

'MPC & MPLAB problems....'
1996\06\07@190607 by Carlos E Lopez-Reyna

flavicon
face
Does any body know how get MPLAB to show an absolute listing of
an MPC (C compiler) file ? I have succesfully compile and generated
*.lst files from within MPLAB but when time to debug comes the
absolute listing option is dim. This doesn't happen with regular
assambler files. Any help would be greatly appreciated.


                                       Carlos Lopez-Reyna

1996\06\09@005851 by John & Maria Perry

flavicon
face
From:    Carlos E Lopez-Reyna <KILLspamclopezspamTakeThisOuTENIAC.SEAS.UPENN.EDU>

> Does any body know how get MPLAB to show an absolute listing of
> an MPC (C compiler) file ? I have succesfully compile and generated
> .lst files from within MPLAB but when time to debug comes the
> absolute listing option is dim.

I had this same problem, and was about to send a desperate query to the list
(I _HATE_ MPLAB's insistence on going to the source), when I realized that all
I had to do was load the list file as a simple file.  Behold, MPLAB even
highlighted the correct instructions for me!

Eventually, I even found out that I could get rid of those damn pop-ups into
the original source by going to the WINDOW menu and killing the source window
item.  Now I'm doing fine with the absolute listing alone.

Isn't there any way to make my preference permanent?


john perry
TakeThisOuTjperryspamspam_OUTnorfolk.infi.net

1996\06\10@113503 by Jim Kape

picon face
    John, Maria, and Carlos,

    I have a solution for you.  In your first line of source code, place:

    #pragma option v

    This will tell the C Compiler to put enough information into the code
    description file for MPLAB to pull it out automatically.  So instead
    of manually opening the absolute listing, you can pull it in via the
    window selection.  This will also give you access to symbols, labels,
    etc.

    If you don't want it automatically pulling up the source, go to
    options->environment setup and turn off Track Source Code.  This will
    allow the program memory or the absolute listing to be stepped,
    without worrying about the code.

    Hope that helps,

    Jim


______________________________ Reply Separator _________________________________
Subject: Re: MPC & MPLAB problems....
Author:  John & Maria Perry <RemoveMEjperryspamspamSTOPspamNORFOLK.INFI.NET> at Internet_Exchange
Date:    6/9/96 12:57 AM


From:    Carlos E Lopez-Reyna <.....clopezEraseMEspamENIAC.SEAS.UPENN.EDU>

> Does any body know how get MPLAB to show an absolute listing of
> an MPC (C compiler) file ? I have succesfully compile and generated
> .lst files from within MPLAB but when time to debug comes the
> absolute listing option is dim.

I had this same problem, and was about to send a desperate query to the list
(I _HATE_ MPLAB's insistence on going to the source), when I realized that all
I had to do was load the list file as a simple file.  Behold, MPLAB even
highlighted the correct instructions for me!

Eventually, I even found out that I could get rid of those damn pop-ups into
the original source by going to the WINDOW menu and killing the source window
item.  Now I'm doing fine with the absolute listing alone.

Isn't there any way to make my preference permanent?


john perry
spamBeGonejperryspamRemoveMEnorfolk.infi.net

'RS485 & RS422'
1996\06\13@061105 by pic

flavicon
face
I'm looking at designing a multi drop comm's system for control purposes.
I have been investigating RS485, and RS422 keeps on coming up along with it,
so I know there can't be much difference between them, but what is the
difference ?

Thanks in advance for any responses,

Wayne.
------------------------------------
Wayne G Boyd
(Digital Sys. Eng.)
E-mail: .....wayneEraseMEspamjce.wintermute.co.uk
------------------------------------

1996\06\13@062405 by Clyde Smith-Stubbs

flavicon
face
pic<spampicspam_OUTspam@spam@jce.wintermute.co.uk> wrote:

> I'm looking at designing a multi drop comm's system for control purposes.
> I have been investigating RS485, and RS422 keeps on coming up along with it,
> so I know there can't be much difference between them, but what is the
> difference ?

They are both 5V differential (twisted pair) but RS422 is unidirectional -
the drivers are always enabled (but you can have more than one receiver) whereas
RS485 is bi-directional - the transmitters are tri-stated when not talking.
RS485 also has better common-mode isolation specs.


--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
spamclyde@spam@spamSTOPspamhitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email spamBeGoneinfospamBeGonespam@spam@hitech.com.au

1996\06\13@064235 by Jattie van der Linde

flavicon
face
pic wrote:
>
> I'm looking at designing a multi drop comm's system for control purposes.
> I have been investigating RS485, and RS422 keeps on coming up along with it,
> so I know there can't be much difference between them, but what is the
> difference ?
>
> Thanks in advance for any responses,
>
> Wayne.
> ------------------------------------
> Wayne G Boyd
> (Digital Sys. Eng.)
> E-mail: RemoveMEwayneRemoveMEspamRemoveMEjce.wintermute.co.uk
> ------------------------------------

RS485 is a multidrop version of RS422.

1996\06\13@091038 by Thomas Coonan

flavicon
face
>>
>> I'm looking at designing a multi drop comm's system for control purposes.
>> I have been investigating RS485, and RS422 keeps on coming up along with it,
>> so I know there can't be much difference between them, but what is the
>> difference ?
>>
>> Thanks in advance for any responses,
>>
>> Wayne.
>> ------------------------------------
>> Wayne G Boyd
>> (Digital Sys. Eng.)
>> E-mail: wayneKILLspamspamspamjce.wintermute.co.uk
>> ------------------------------------
>
>RS485 is a multidrop version of RS422.
.. because.. RS485 tolerates opposing voltages driving same output
wire and doesn't hurt the driver.  I'm not sure what the resulting
contested voltage is e.g. wire-or and wire-and.
RS422 gives you the longer distance and noise immunitity, whereas
RS485 allows all the funky CDMA bus schemes..

1996\06\13@094635 by mfahrion

flavicon
face
>
> I'm looking at designing a multi drop comm's system for control purposes.
> I have been investigating RS485, and RS422 keeps on coming up along with it,
> so I know there can't be much difference between them, but what is the
> difference ?
>
> Thanks in advance for any responses,
>
> Wayne.

This will probably be beaten to death but.....

422 and 485 are very similar, in many cases 485 transceivers are used
in 422 applications.  The primary difference is that an RS-485 driver
can be tri-stated, allowing multiple drivers to share a line, which
allows 2-wire mode to be used.  2-wire mode ties each nodes driver
and receiver together on the same twisted pair and communicates half
duplex with up to 32 other nodes (more with special hardware).

422 can have multiple receivers sharing a driver, but since it
doesn't tri-state the drivers no two drivers may share a line.
Distances and baud rates are very similar if not identical to 485.
The input impedance of a 422 receiver is a bit lower than 485, which
allows less nodes to be hung on one driver (10 instead of 32).
RS-422 can be used in point to point systems or as the master of a
master/slave 4-wire 485 network.

We have a pretty decent app note on 422 and 485 on our web site at
http://www.bb-elec.com

Other good info can be found in the app notes in the back of NSC's
latest Interface Data Book.

Hope this helps.

-mike

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Fahrion                spam_OUTmfahrion@spam@spambb-elec.com      http://www.bb-elec.com/
B&B Electronics Mfg Co      ph.(815) 433-5100 ext.215    fax (815) 434-7094
707 Dayton Road                 PO Box 1040                  Ottawa IL 61350
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1996\06\13@110112 by T.Nelson

flavicon
picon face
On Thu, 13 Jun 1996, pic wrote:

> I'm looking at designing a multi drop comm's system for control purposes.
> I have been investigating RS485, and RS422 keeps on coming up along with it,
> so I know there can't be much difference between them, but what is the
> difference ?

RS485 is a true multi-drop setup - I believe the spec is 32
drivers/receivers on a twisted pair bus (about a mile long?)?

RS422 is meant for single send/receive pairs - no multidrop.

To meet RS485 automatically qualifies the chip for use as RS422.  So,
manufactures - being frugal - make one chip in high quantities (and at
cheaper cost) than two different chips.  Personally, I am not aware of a
commercially 422 only chip you can buy (I believe you can buy 422
pre-assembled boards though - even though you can't use them as 485 -
they use the 485 chips).

My source on info comes from the National Semiconductor Communications
Data Book - I like the SN75176 chip in particular - cheap from DigiKey
and well designed.

If you order from DigiKey - you can pay an extra buck and get the data
sheet for the chip.


                                \\\|///
                              \\  ~ ~  //
                               (  @ @  )
--|---------------------------oOOo-(_)-oOOo----------------------------------
--| Troy D.F. Nelson                     | EMAIL  TakeThisOuTnelsonspam_OUTspamcerc.wes.army.mil
--| Coastal Engineering Research Center  | Voice  601-634-3568
--| USAE Waterways Experiment Station    | FAX    601-634-3151
--|------------------------------------Oooo.---------------------------------
                           .oooO     (   )
                           (   )      ) /
                            \ (      (_/
                             \_)

'Newbish questions on project & timer.'
1996\06\29@220351 by Mr Andrew V Cerasuolo

flavicon
face
Hi to all pic users,

I'm about to start a new version of an old project which I'm planning to use
a 16c84 with. It is basically a timer with the following constraints :

A) The timer has to be physically small, the previous one, which this
replaces was approx 4" X 6".
B) It has to be able operate off batteries (aa's 9v etc but NOT
rechargeable's) for at least 10 hours.
C) It has to have a largish 6 digit lcd display the previous one used a 6
digit direct drive 12.7mm high digits similar to RS cat 589-288. It will be
used outdoors and conventional 16 X 1 or 40 X 2 alpha displays are too small.
D) several buttons one which will "freeze" the display (i.e time will update
internally but not be shown on the display).

The previous design used lot's of chips and a specific chip which is a bit
difficult to get here "down under".

Now my questions :
1) does the project seem feasable with a pic16c84 ?.
2) Has anyone used a 16c84 to drive a direct drive LCD via
       A) ICM7211 (RS 427-332/304-807/308-590)
or      B) PCF8577CP (RS 809-964) I2C lcd driver
Is there an alternative to the above 2 ? and readily available in single
quantities ?.
3) I was planning on using TMRO but I'm not clear on how to use so it
interrupts the main code every 600ms. (i.e the display will be updated every
600ms). Of course if the "freeze" button is pressed the time will update
internally but the display will not update until it is released.
4) Can I use a 32KHz xtal , as this will use less power than a standard 4
MHz xtal , or is not worth it ?. Will I be able to generate the 600ms
interrupts with a 32KHz xtal or should I use a weird xtal like 3.59MHz (tv
color burst f ?). ?.

I'd appreciate any answers , and will try and clarify any points if they are
not clear.
Thanks & Ciao Andrew,
+-----------------------------------------------------------------------+
Andrew Cerasuolo
EMAIL:KILLspamandrew.....spamTakeThisOuTdeakin.edu.au
+-----------------------------------------------------------------------+

1996\06\30@211902 by Mark K Sullivan

flavicon
face
>Now my questions:
>1) does the [LCD timer] project seem feasable with a pic16c84 ?.

Sure, easy.  That and an LCD driver.  Have you thought about the 16C923?  I'm
not sure how soon the '923 will be available, though.

>2) Has anyone used a 16c84 to drive a direct drive LCD via
>       A) ICM7211 (RS 427-332/304-807/308-590)
>or      B) PCF8577CP (RS 809-964) I2C lcd driver
>Is there an alternative to the above 2 ? and readily available in single
>quantities ?.

Barring the 16C923, I would use the PCF8577.  There are many others, but that's
a fine choice.  The ICM7211 will only drive 32 segments.  You will probably need
more (6*7 = 42).  The PCF8577 will drive up to 64 in 2:1 multiplex.  If, by any
chance, some digits need not show all 10 possible values (i.e. 0 and 1, blank 1,
and 2, etcetera), you may be able to get by with only 32 segments.  Some devices
could be smaller than the 40 pin DIP package but since that is probably smaller
than your LCD display, I assume it won't make the project any bigger.

Note that, for outdoor use, you have to watch the temperature range of LCDs.
Sometimes you need a heater which is not good in a battery powered system.

>3) I was planning on using TMRO but I'm not clear on how to use so it
>interrupts the main code every 600ms. (i.e the display will be updated every
>600ms). Of course if the "freeze" button is pressed the time will update
>internally but the display will not update until it is released.

Since you say the 600mS is for display update (which I'm not sure I understand.
I would probably use the interrupt to keep time and let the main loop update the
display whenever it is idle.), it shouldn't be critical.  Just set the prescaler
to 16 and let the timer overflow continuously.  This will give you 500 mS with a
32.768 KHz crystal.  Also 500 mS is nice if you take my hint and use the TMR0
interrupt for timing.  If it has to be 600 mS, set the prescaler for 32 and load
102 into the timer every time you get an interrupt.  32768/4/32*.6 = 154 and
256-154 = 102.  That'll get you about between 601.5 and 601.6 mS.

>4) Can I use a 32KHz xtal , as this will use less power than a standard 4
>MHz xtal , or is not worth it ?. Will I be able to generate the 600ms
>interrupts with a 32KHz xtal or should I use a weird xtal like 3.59MHz (tv
>color burst f ?). ?.

There should be no problem with a 32 KHz crystal and low power mode unless
you need a much faster clock for whatever it is you are timing.  I would use 2
or 3 1.5V alkaline cells in series or one lithium cell.  You won't need a
regulator.  At 32KHz you should be able to run for months with AA cells.
I'm not sure why you say "not worth it".  What's the extra cost or difficulty
of using a 32 KHz crystal?

- Mark Sullivan -

1996\06\30@233839 by Steve Hardy

flavicon
face
> From: Mark K Sullivan <TakeThisOuTmsullivanEraseMEspamRemoveMEVAX.NIOBRARA.COM>
>
> >3) I was planning on using TMRO but I'm not clear on how to use so it
> >interrupts the main code every 600ms. (i.e the display will be updated every
> >600ms). Of course if the "freeze" button is pressed the time will update
> >internally but the display will not update until it is released.
>
> Since you say the 600mS is for display update (which I'm not sure I
understand.
> I would probably use the interrupt to keep time and let the main loop update
the
> display whenever it is idle.), it shouldn't be critical.  Just set the
prescaler
> to 16 and let the timer overflow continuously.  This will give you 500 mS with
a
> 32.768 KHz crystal.  Also 500 mS is nice if you take my hint and use the TMR0
> interrupt for timing.  If it has to be 600 mS, set the prescaler for 32 and
load
> 102 into the timer every time you get an interrupt.  32768/4/32*.6 = 154 and
> 256-154 = 102.  That'll get you about between 601.5 and 601.6 mS.


Note: when a new value is loaded into TMR0, there is a 2-cycle latency
before the counter starts updating again.  Thus for a 154-cycle loop,
load TMR0 with 256+2-154 = 104.  As Microchip notes in the data sheet
this will compensate for the latency.  I have used this technique to
generate exact 100us loops with no jitter.

Another important note:  do not merely load TMR0 with a new value, since
the actual timings then become dependent on the number of cycles executed
in the interrupt routine before the TMR0 reload (i.e. you will have to
count cycles).  It's a matter of taste, but I prefer to ADDWF a constant
to TMR0 since it is then independent of interrupt latency etc.  Use the
following since it worked for me with a PIC16C84:
CYCLES  equ     154
       ...
       movlw   259-CYCLES
       addwf   TMR0,f

The desired number of cycles are subtracted from 259 to compute the
amount by which to bump the clock forward.  As I mentioned on this list
way back, there is a discrepancy between the 259 constant versus the
expected 258.  259 is required (at least in the '84), implying that the
device actually has a 3-cycle latency, not 2 as the doc would have
it).


At 32768Hz, 154 cycles is 601.56125ms.  The 600ms required is quite
extraordinary (why not use 500ms since it can be generated exactly?).
If this is indeed required, one way I have used to generate timings
at frequencies which are not simple divisions of the clock frequency
is to generate 'corrections' every now and again.  In this example,
since the clock is running 'slow' at 601.6ms, every few times through
the loop the timer should be cut short i.e. use loop delay of 153
cycles = 597.65625ms.  Find the smallest integer constants A and B
such that (A+B)*600 = A*601.56125 + B*597.65625.  If A and/or B are too
large, pick different loop times.  Ideally, one of A or B should be
1 since this simplifies the loop logic.

[Anyone got a good algorithm for finding A and B?]


>
>
> - Mark Sullivan -
>

Regards,
SJH
Canberra, Australia


'Newbish questions on project & timer.'
1996\07\01@091335 by Martin Nilsson
picon face
Steve,

> cycles = 597.65625ms.  Find the smallest integer constants A and B
> such that (A+B)*600 = A*601.56125 + B*597.65625.  If A and/or B are too
> large, pick different loop times.  Ideally, one of A or B should be
> 1 since this simplifies the loop logic.
>
> [Anyone got a good algorithm for finding A and B?]

The smallest integer solution to the Diophantine equation ax-by=0 (a,b>0)
is (x,y) = (b/gcd(a,b), a/gcd(a,b)). I your case,

(A+B)*600 = A*601.56125 + B*597.65625

<=>

1.56125 A = 2.34375 B

<=>

249 A = 375 B

The smallest solution is (A,B) = (375,249), since
gcd(249,375)=1. Close, but not exact, is (A,B) = (3,2), since 249 is
near 250.

(A good way to find approximate solutions with small integers is to
truncate the continued fractions expansion of a/b. In some reasonable
sense this gives the "best" possible approximation, but I guess you
don't need this here.)

-- Martin

Martin Nilsson                           http://www.sics.se/~mn/
Swedish Institute of Computer Science    E-mail: spam_OUTmnRemoveMEspam.....sics.se
Box 1263, S-164 28 Kista                 Fax: +46-8-751-7230
Sweden                                   Tel: +46-8-752-1574

1996\07\01@093225 by Kalle Pihlajasaari

flavicon
face
Hi,

> > From: Mark K Sullivan <spammsullivanKILLspamspamKILLspamVAX.NIOBRARA.COM>
> >
> Note: when a new value is loaded into TMR0, there is a 2-cycle latency
> before the counter starts updating again.  Thus for a 154-cycle loop,
> load TMR0 with 256+2-154 = 104.  As Microchip notes in the data sheet
> this will compensate for the latency.  I have used this technique to
> generate exact 100us loops with no jitter.

You will still have jitter of 3 clocks if you sample or (I guess)
1 clock if you interrupt due to the occasional goto 2 cycle instruction
but if you use the and method you will have long term absolute
accuracy as the current value is used for setting the new timing point.

{Quote hidden}

I get different results with MPLAB-SIM and the 16C84 silicon by a count
of one, I erad about this problem and erroneously thought that it had
been fixed in the version I downloaded a few weeks later so if you have
to get 1 cycle accuracy just check if your measured error is or the same
magnitude as one change in your count value and adjust it (if you were
using the simulator to count cycles).

Also the Add to TMR0 might be responsible fot the extra cycle as it might
read the timer at phase 1, and the timer might get incremented but the
old value is used for the Add instruction and then you loose the extra
tick when you write the TMR0 value back.

Also remember that If you use the prescaler it will be cleared when
you write to TMR0 and you cannot find out what the value was and cannot
correct for the lost sub-counts.  SO do not write to the TMR0 unless
you have no prescaler if you want 1 clock long term accuracy.

{Quote hidden}

Microsoft Excel does a good job with the solver tool :-)
I have put up a calculator on my web site, have a look and
let me know, PIC web page coming soon with all sorts of
usefull information.

http://www.ip.co.za/people/kalle/files/delayc.xls

You will need Microsoft Excel or similar.

Cheers
--
Kalle Pihlajasaari     spamkallespam_OUTspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1996\07\02@001920 by Steve Hardy

flavicon
face
> From: Kalle Pihlajasaari <STOPspamkallespam_OUTspamspamBeGoneDEVICE.DATA.CO.ZA>
>
> Hi,
>
> > > From: Mark K Sullivan <spam_OUTmsullivanspamspamBeGoneVAX.NIOBRARA.COM>
> > >
> > Note: when a new value is loaded into TMR0, there is a 2-cycle latency
> > before the counter starts updating again.  Thus for a 154-cycle loop,
> > load TMR0 with 256+2-154 = 104.  As Microchip notes in the data sheet
> > this will compensate for the latency.  I have used this technique to
> > generate exact 100us loops with no jitter.
>
> You will still have jitter of 3 clocks if you sample or (I guess)
> 1 clock if you interrupt due to the occasional goto 2 cycle instruction
> but if you use the and method you will have long term absolute
> accuracy as the current value is used for setting the new timing point.

Correct, there is actually a 1-cycle jitter in general.  I didn't see
it in my particular application because of the pattern of instructions
executed - the interrupt always occurred on a 1-cycle instruction (I
guess I was lucky, since the application depended on exact timing).


{Quote hidden}

I found exactly this problem with the simulator.  The above seems like
a very plausible argument for why this is so.  It makes sense that
the timer is incremented _after_ Q1 since registers are read at Q1 -
preventing interlock problem.  The simulator does not simulate any
events at timescales less than 1 instruction (4 phases) which is
probably why it handles this situation incorrectly.


>
> Also remember that If you use the prescaler it will be cleared when
> you write to TMR0 and you cannot find out what the value was and cannot
> correct for the lost sub-counts.  SO do not write to the TMR0 unless
> you have no prescaler if you want 1 clock long term accuracy.


Actually, the prescaler value can be deduced, so its effect can
sometimes be compensated for.  The prescaler is zero at the time of
interrupt, so its value at the time the clock is reset is the number of
instructions executed since the interrupt plus some latency plus the
one-cycle uncertainty referred to above.  If a 1-count uncertainty in
the prescaler value is of small concern (i.e. when using large
prescale) then this technique may still be useful.

Unfortunately, apart from being inexact it also makes calculation of
the timer constants more difficult.


> [cut]
> Cheers
> --
> Kalle Pihlajasaari     EraseMEkallespamKILLspamdata.co.za
> Interface Products     Box 15775, Doornfontein, 2028, South Africa
> +27 (11) 402-7750      Fax: +27 (11) 402-7751
>

Regards,
SJH
Canberra, Australia

'PicStart Plus & PIC14000'
1996\07\12@043819 by Pedro Renato e Vasco

flavicon
face
Hi,

I have a PicStart Plus programmer and i have some problems with it. It
says that a blank PIC16C73/JW is not blank but all zeros. I don't know
if it is a soft or a hardware problem but i'm positiv shure that the
16C73 is fine and blank (all 3FFF) confirmed with a PicStart 16C and a
PROMATE. The other problem is that a PIC14000/JW takes about 30 min of
erasure with UV ( STAG SE1T UV eraser ) till PicStart Plus says it's
blank (program memory).
If anyone had problems like this ones, please say something... (Is there
any hope of solutions ?)
Best Regards,
               Renato Ferreira

--------------------------------------------------------
MCS - Micro Controlo e Sistemas - Solucoes de Engenharia

'coding & decoding'
1996\07\13@135928 by ali marami

flavicon
face
Hi all,
I am designing  a burglar car alarm system with
PIC16C54/xt chip.
I use an AX5326 encoder for transmitting codes and
an AX5327 for decoding in receive.But i have some
questions about them:
1.Do you know the manufacturer of AX5326?
2.In many car alarms i have seen they omit the AX5327
chip in rece{ver and they decode with PIC16c54 chip do
you know how and is there any source program for doing this?
3.For tranfering PDF files must i use binary or ascii mode?
4.How can i rea  the PDF files?
Any help from you is appreciated.
rgds
A.Marami

1996\07\13@163613 by fastfwd

face
flavicon
face
ali marami <EraseMEPICLISTRemoveMEspamMITVMA.MIT.EDU> wrote:

> I am designing  a burglar car alarm system with
> PIC16C54/xt chip.
> I use an AX5326 encoder for transmitting codes and
> an AX5327 for decoding in receive.But i have some
> questions about them:
> 1.Do you know the manufacturer of AX5326?

   No, but it sounds equivalent to Motorola's MC145026 and MC145027.

> 2.In many car alarms i have seen they omit the AX5327 chip in
> rece{ver and they decode with PIC16c54 chip do you know how and is
> there any source program for doing this?

   It's very simple; the transmitter chip sends strings of data,
   each of which contains nine trinary digits.  Each string is
   separated from the next by a 4-digit-wide gap.

   The nine trinary digits correspond to the states of the nine
   Address pins on the transmitter chip.

   If an address pin is high, the chip sends:
     _____________   _____________
    |             | |             |
   _|             |_|             |_

   If the pin is low, the chip sends:
     _               _
    | |             | |
   _| |_____________| |_____________

   If the pin is open, the chip sends:
     _____________   _
    |             | | |
   _|             |_| |_____________

   You should really get a copy of the MC145026 data sheet from
   Motorola; it's available, among other places, in their "CMOS
   Appication-Specific Standard ICs" data book (Literature Number
   DL130).

> 3.For tranfering PDF files must i use binary or ascii mode?

   Binary.

> 4.How can i rea  the PDF files?

   You need a copy of Adobe Acrobat Reader; I'm sure that it's
   available from Microchip's ftp site.

   -Andy

Andrew Warren - .....fastfwdspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

'Code question about saving and restoring W & Statu'
1996\07\22@221500 by NEIL GANDLER

flavicon
face
I just finished my first interrupt routine for a PIC 16c74 and looked at
p. 2-639 of the microntoller databook. They suggest a routine
to save the current value of the STATUS and W register before
procedding through the interrupt routine and restoring these values
upon completion of the routine. What I don't understand is why
they swap the nibbles of the status register. I would appreciate
any advice.

               Neil Gandler

1996\07\22@225110 by John Payson

flavicon
face
>  I just finished my first interrupt routine for a PIC 16c74 and looked at
> p. 2-639 of the microntoller databook. They suggest a routine
> to save the current value of the STATUS and W register before
> procedding through the interrupt routine and restoring these values
> upon completion of the routine. What I don't understand is why
> they swap the nibbles of the status register. I would appreciate
> any advice.

It is probably not necessary to swap the nybbles of the status register
(though it doesn't hurt anything; "movf XX,w" takes just as long as
"swapf XX,w").  It is, however, necessary to swap the nybbles of the W
register (and the status may have been swapped for consistency).  If the
W register wasn't swapped, an attempt to reload it using a "movf XX,w"
would trash the status register.  By contrast, "swapf XX,w" does not have
this effect.

By the way, there are a couple of other approaches that could be used for
similar effect; I don't think anything would be any shorter than the
"swapf" approach, though, even though that approach does have one "waste"
instruction.

1996\07\22@225531 by Sherif Abdel-Kader

flavicon
face
On Mon, 22 Jul 1996, NEIL GANDLER wrote:

>  I just finished my first interrupt routine for a PIC 16c74 and looked at
> p. 2-639 of the microntoller databook. They suggest a routine
> to save the current value of the STATUS and W register before
> procedding through the interrupt routine and restoring these values
> upon completion of the routine. What I don't understand is why
> they swap the nibbles of the status register. I would appreciate
> any advice.
>
>                 Neil Gandler

Neil,

Because the SWAPF instruction does not affect the Z bit in the STATUS
register. If you save STATUS using MOVF STATUS,temp_STATUS, you end up
affecting the Z bit in the process. They swap it back in the restore part
so no information is lost.

Sherif

1996\07\22@225907 by fastfwd

face
flavicon
face
NEIL GANDLER <@spam@PICLISTEraseMEspamspamMITVMA.MIT.EDU> wrote:

> I just finished my first interrupt routine for a PIC 16c74 and
> looked at p. 2-639 of the microntoller databook. They suggest a
> routine to save the current value of the STATUS and W register
> before procedding through the interrupt routine and restoring these
> values upon completion of the routine. What I don't understand is
> why they swap the nibbles of the status register.

Neil:

If you use MOVF instructions instead of SWAPs, you'll corrupt the
Status register's Z bit.

-Andy

Andrew Warren - fastfwdTakeThisOuTspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\07\23@021530 by Rusu Dan Victor

flavicon
face
On Mon, 22 Jul 1996, NEIL GANDLER wrote:

>  I just finished my first interrupt routine for a PIC 16c74 and looked at
> p. 2-639 of the microntoller databook. They suggest a routine
> to save the current value of the STATUS and W register before
> procedding through the interrupt routine and restoring these values
> upon completion of the routine. What I don't understand is why
> they swap the nibbles of the status register. I would appreciate
> any advice.
>
>                 Neil Gandler
>

The swap instruction will not affect any flag, and will store the status
register in W. (look at the second parameter of the instruction!).
If you are using a simple movfw instruction, that will affect the flags
in the status register, and the saved value is different from the
original one!

Dan


'Diffrence between C84 & C71?'
1996\08\04@170955 by Papageorgiou Spiros
flavicon
face
Hi PIcers?

I wrote a piece of code which runs fine on a 16C84 and then i tried it
on a 16C71 without success.. I don't really understand why, 'cause
the two uCs seem to be identical with the exception of course of the
DA converter of the C71 and the EEPROM of the 16C84.
Since my code doesn't use any DA or EEPROM i believe it should run on
both UC without modifications. Right?
Anybody knows what might be wrong?

Tips: Thesame source was recompiled for each uC.
I'm testing the 2 chips on the same board that works well. (the 16C71 actually
runs).
The program doesn't even use timers and watchdogs and such things.

Thanx
Spiros Papageorgiou
Email:
RemoveMEmc89114TakeThisOuTspamcentral.ntua.gr

1996\08\04@202012 by Fernando Martin

flavicon
face
Papageorgiou Spiros wrote:
{Quote hidden}

Hi
When you want to run code written for the C84 or C61 on a C71, you must
add a line to your program (at the begining) in which you must set the
3 least significative bytes of the register ADCON1. If not, some inputs
(RA0-3) will be configured as analog input after the reset and they do
not work as you expected (as digital inputs).
Bye.

--|----------------------------------------------------------------|--
--|                                                                |--
--|    Fernando G. Martin        EMAIL  TakeThisOuTfgmartinTakeThisOuTspamRemoveMEstarnet.net.ar    |--
--|                                                                |--
--|----------------------------------------------------------------|--

1996\08\05@034823 by mike

flavicon
picon face
In message  <spam_OUT199608042108.AAA09884spamspam.....central.ntua.gr> PICLIST.....spam@spam@MITVMA.MIT.EDU
writes:
> Hi PIcers?
>
> I wrote a piece of code which runs fine on a 16C84 and then i tried it
> on a 16C71 without success.. I don't really understand why, 'cause
> the two uCs seem to be identical with the exception of course of the
> DA converter of the C71 and the EEPROM of the 16C84.
> Since my code doesn't use any DA or EEPROM i believe it should run on
> both UC without modifications. Right?

Right.

I generally do my initial development on a C84 before moving over to
a C61 or C71 (which ever the final design will use).

Mike

'KW/hour & Current sensing project'
1996\08\05@052522 by radiobit

flavicon
face
Thanks to all the answers to my request about the KW/hour meter.

Kalle Pihlajasaari wrote:
>Have a look on my project page
>
>http://www.ip.co.za/people/kalle/project.htm#energy

Very interesting page. There is information about special ICs and modules
manufactured by a South African company (SAMES). The circuits provide direct
power indication and some of them can operate directly with a display.

Ray Crampton wrote:
>    I used an E-field hall effect sensor and an H-field hall effect sensor
>     (E for voltage, H for current measurement).

I have not read about E-field and H-field hall sensors. Manufacturers just
don«t provide such information (at least in the small advertisements in the
mags).
Anyway don't think voltage has much effect on the measuring as it can be
considered constant 220 AC. The application doesn't need such accuracy and
the current variations would be long term.

Paul Mathews wrote:
>Three ways to sense current:
>
>1. Current Transformer, CT, may or may not have ferrite core.  Output is
>AC voltage isolated from line and usually symmetrical around the
>potential of either lead, so you have to deal with bipolar waveform.

I have just got the info from a US current transformer manufacturer and the
price for the piece is around $66. That's little high for this project

>2. Hall effect device.  Output depends on type of device but is tied to
>the potential of the power supply(ies), so whether it is isolated
>depends on how you supply power.

Just waiting for prices at the moment but sounds as the best option.

>3. Current sense resistor.  Output is AC Voltage not isolated from line.

Will have to study a way to isolate the *human interface* (yes, there is any)
Or ask to my lawyer for the cost of a fried customer (if any) ;-)

>All of these signals need supporting circuitry and some kind of
>digitization.  Don't forget that current and Voltage are out of phase
>for reactive loads, and that the current waveform can be distorted
>dramatically.

This is not a precision application and think the usual electro-mechanical
power meters do not take into account this phase factor. The idea is just to
substitute on of this bulky boxes and get a similar KW/hour counting. Or at
least one which doesn't cause any heart attack !.

 Bob Minchin and Nigel Goodwin refered to an UK Electronics Magazine:

>The UK magazine 'Everyday and Practical Electronics' did just such a project
>in the Feburary & March issues this year. The software can be downloaded from
>their new FTP site, FTP://ftp.epemag.wimborne.co.uk/pub/PICS. It uses a 16C84
>with an external A/D, the mains current is sampled via a hall-effect
>transducer.

Would you please give me the address of EPE. Seems to be the same weel I
wanted to invent here ;)
About the FTP address guess this is just the directory but which is the file
name or is there a 00-index.txt ?

>I've built one, it works really well!. It displays units used, and the total
>cost. Pressing a front panel button will display the elapsed time since the
>unit was plugged in to the mains.

Even better to know that it really works !

>There was some postings to the list from me and one or two others regarding
>this
>around April this year. I've not got them anymore but have a look around in the
>Piclist Archive. The magazine articles you need are in February and March 1996
>issues.

I'll look into the archived mail. Thanks

 Tim McDonough wrote:
>In the August 1996 issue of Circuit Cellar Ink there is a column by Jeff
>Bachiochi that describes some home made current sensing using toroids, etc.
>It might help you with your project.

Have no way to access to such magazine. Do you know if they have any web
page or e-mail ?

Thanks everybody. Seems that the UK project and the South African Chips are
the best ready made and tested option available.


Luis Fernandez Cormenzana
RadioBit Sistemas, S.L.

Fax/Tel:+34-6-585 64 57
e-mail: spamBeGoneradiobitspamspam_OUTdragonet.es

1996\08\05@073757 by Kalle Pihlajasaari

flavicon
face
Hi again,

> >http://www.ip.co.za/people/kalle/project.htm#energy
>
> Very interesting page. There is information about special ICs and modules
> manufactured by a South African company (SAMES). The circuits provide direct
> power indication and some of them can operate directly with a display.

I have added some new information I found about the LEM hall trasducers
at the end of my SAMES section, If anyone finds out a non-800 number or
a Fax number for LEM I would be pleased to receive it via e-mail to add
to my page.

Cheers
--
Kalle Pihlajasaari     EraseMEkalle.....spamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

'Diffrence between C84 & C71?'
1996\08\05@142107 by Eric Smith

flavicon
face
Papageorgiou Spiros <spammc89114KILLspamspam@spam@CENTRAL.NTUA.GR> wrote:
> I wrote a piece of code which runs fine on a 16C84 and then i tried it
> on a 16C71 without success.. I don't really understand why, 'cause
> the two uCs seem to be identical with the exception of course of the
> DA converter of the C71 and the EEPROM of the 16C84.

On the 16C71, you have to explicitly turn the A/D converter off.  Why
on earth didn't Microchip make this the default?

Cheers,
Eric

1996\08\05@150851 by John Payson

flavicon
face
> Papageorgiou Spiros <mc89114spamspamTakeThisOuTCENTRAL.NTUA.GR> wrote:
> > I wrote a piece of code which runs fine on a 16C84 and then i tried it
> > on a 16C71 without success.. I don't really understand why, 'cause
> > the two uCs seem to be identical with the exception of course of the
> > DA converter of the C71 and the EEPROM of the 16C84.
>
> On the 16C71, you have to explicitly turn the A/D converter off.  Why
> on earth didn't Microchip make this the default?

Most likely they disabled the digital inputs on reset to avoid excess
current draw that might otherwise result from having the port pins at
an indistinct logic level (unlike digital inputs which might float but
would usually tend one way or the other, A/D inputs in normal usage
would probably tend to be somewhere in the middle of the sacle).  The
rationale is reasonably sound; it would have been nicer to have a little
more transparent implementation, however.

1996\08\05@183608 by Brian Boles

flavicon
face
    The A/D is default "ON" because of the shared analog/digital inputs.
    If the default was off, and the I/O pin was digital, and then your
    board was providing an analog signal; bad things would happen to the
    digital input.  So all inputs default to analog.

    Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Re: Diffrence between C84 & C71?
Author:  Eric Smith <RemoveMEericRemoveMEspamGOONSQUAD.SPIES.COM> at Internet_Exchange
Date:    8/5/96 11:19 AM


Papageorgiou Spiros <TakeThisOuTmc89114@spam@spam@spam@CENTRAL.NTUA.GR> wrote:
> I wrote a piece of code which runs fine on a 16C84 and then i tried it
> on a 16C71 without success.. I don't really understand why, 'cause
> the two uCs seem to be identical with the exception of course of the
> DA converter of the C71 and the EEPROM of the 16C84.

On the 16C71, you have to explicitly turn the A/D converter off.  Why
on earth didn't Microchip make this the default?

Cheers,
Eric

'16c 74 & 64..'
1996\08\06@232655 by Pablo Mochcovsky

flavicon
face
Hi,
I was wondering if the 16c64 is fully compatible with the 16c74
(without the A/D & serial options). The fact is that I've designed a system on
the 16c74 but I didn't use the A/D and the serial comunication
interface at all, and now I want to reduce the costs as down as I can.
So that I thought on using the 16c64 for final applications.
I'll really appreciate any idea.
Thank's in advancce

Pablo Mochcovsky
Buenos Aires, Argentina.

1996\08\07@052337 by Jim Robertson

flavicon
face
>Hi,
>I was wondering if the 16c64 is fully compatible with the 16c74
>(without the A/D & serial options). The fact is that I've designed a system on
>the 16c74 but I didn't use the A/D and the serial comunication
>interface at all, and now I want to reduce the costs as down as I can.
>So that I thought on using the 16c64 for final applications.
>I'll really appreciate any idea.
>Thank's in advancce
>
>Pablo Mochcovsky
>Buenos Aires, Argentina.
>
Pablo,

You must also consider the size difference, the 16C64 is only 2K while
the 16C74 is 4K. There are other differences, the 16C64 has less PWM
outputs.

If you are under 2K and not using these peripherials, then the 16C64
can be used as a replacement. I often mix the devices during development
myself.

Also consider the 16C65, this is a more direct replacement of the 17C74.
However it would probably be more expensive than the 16C64 and I have
heard the 16C65 is full of bugs. Check it out anyway.

Jim

1996\08\07@072133 by fastfwd

face
flavicon
face
Pablo Mochcovsky <TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU> wrote:

> I was wondering if the 16c64 is fully compatible with the 16c74
> (without the A/D & serial options). The fact is that I've designed a
> system on the 16c74 but I didn't use the A/D and the serial
> comunication interface at all, and now I want to reduce the costs as
> down as I can. So that I thought on using the 16c64 for final
> applications.

Pablo:

The 16C65 is a more-precise match.  Internally, it IS a 16C74, but
with the A/D disabled.

-Andy

Andrew Warren - KILLspamfastfwdKILLspamspamspamBeGoneix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

'PIC16C622 & Analog Comparators'
1996\08\07@161727 by Scott Dattalo

face
flavicon
face
One of the really cool things about the PIC16C622 is that it
has two analog comparators. They're very fast and work over the
entire temperature range (which includes the automotive temp
range!). However, there are a couple of short comings when you
wish to provide hysteresis. And considering that about 99.7% to
99.8% of the time I use an analog comparator I also design it
such there is some hysteresis, this makes the 622 comparators
a little difficult to use.

There are essentially two ways to provide hysteresis:
1) Apply positive feedback to the positive terminal
2) Apply negative feedback to the negative terminal

For example, if your reference voltage is on the "+" terminal
of the comparator and your signal is applied to the "-" terminal,
then you can either feed a portion of the comparator's output
back to the positive terminal or you can invert the comparator's
output and feed it back to the negative terminal. The latter
case is the only one available when using the 622's, and is
shown below:



                                 R4
                        +------/\/\/\-------+
              R3        |   |\              |
   Vin  ----/\/\/\------+---|-\             |
                            |  \            |
                            |   \    |\     |
                            |U1 /----| \o---+--- Vd(T)
              R1            |  /     | /
   Vref  ---/\/\/\------+---|+/      |/ U2
                        |   |/
                        \
                        /  R2
                        \
                        /
                        |
                       ----
                      / / /

 U1 is the comparator, U2 is an inverter. The Vref,R1,R2 circuit
can also be the internal 622 voltage reference (but you could just
as well use an external one). R3 and R4 form the hysteresis circuit.


Actually, I should be a little more specific. There are really eight
different ways to configure the PIC16C622 analog comparators. However,
if you wish to use both comparators and have totally separate hysteresis
circuits for each one, then you're confined to the configuration shown
above.

Now the question... Part 1) Has anybody else dealt with this issue and
2) What did you use for the inverter?


FYI 1, I have simulated this circuit using PSPICE. Since I want to use the
automotive temperature range, I cannot use the "standard" 74XX14 type IC's
(which are only good to at best the 80 degree C industrial temperature
range). I have used an NPN transistor (the infamous 2N3904) with quasi-
encouraging results.

FYI 2, AN611 is the only one that discusses 622's comparators. Unfortunately,
the author did not need hysteresis in his application ( one of those 0.03%
abnomalies I presume... actually, his signals were internally generated
and [I guess] less noisy then the typical case).

FYI 3, I have not tested a real circuit (yet).

Scott

1996\08\07@170814 by Mike Riendeau

flavicon
face
Scott Dattalo wrote:

>One of the really cool things about the PIC16C622 is that it
>has two analog comparators. They're very fast and work over the
>entire temperature range (which includes the automotive temp
>range!). However, there are a couple of short comings when you
>wish to provide hysteresis. And considering that about 99.7% to
>99.8% of the time I use an analog comparator I also design it
>such there is some hysteresis, this makes the 622 comparators
>a little difficult to use.

If you were using one of the comparators with an interrupt, would
it be possible to reconfigure the reference voltage "on the fly"
to provide hysteresis?  I don't know much about this part, and I breezed
through AN611 very quickly. The APP note says that the reference
divider is a 16 tap resistor network with a limited range, but
this may be OK for some applications.

1996\08\07@181514 by Scott Dattalo

face
flavicon
face
Mike Riendeau wrote:
>
>
> If you were using one of the comparators with an interrupt, would
> it be possible to reconfigure the reference voltage "on the fly"
> to provide hysteresis?

Yes, but... Three minor problems. One, the settling time of the 622's
internal voltage reference circuit is relative slow (10 microseconds).
Second, any kind of "software hysteresis" will significantly reduce
the effective comparator speed. For example, the 622 comparators are
spec'd with a 400ns response time, where response time is measured
with "one of the inputs at (Vdd-1.5)/2 and the other transitioning
from Vss to Vdd". Now, even if the reference circuit had an
instantaneous response, the software overhead to change to a new
level would rapidly consume time that could be used for sampling.
(see FYI 4, below). Third, the same comparator is used by both
comparators. If you change the reference voltage for one then you
will affect the performance of the other.

FYI 4, I'm going to use the full bandwidth of these puppies (one
puppy == one comparator). The normal mode is quiescent which
means there is no signal and consequently no change of states
in the comparators outputs. When a signal occurs, it will last
for 100 microseconds or so. I'll catch the initial transition with
an interrupt (after a little of interrupt latency of course). I'll
sample the subsequent transitions once every 400ns.

FYI 5, I've used external comparators and PORT B's change on interrupt
capability with the approach discussed in FYI 4 with great success.

Thanks,
Scott

1996\08\07@183412 by Jon Bertrand

flavicon
face
    I'm not up to speed on this part so here are a few questions:

    Does the ref. voltage come out to and external pin (I'm guessing it
    doesn't or why would you be asking this)?

    What kind of reference is it - does it have a sensitivity to VCC that
    could be exploited?

    Jon Bertrand
    spamBeGonejonbKILLspamspamcirris.com



______________________________ Reply Separator _________________________________
Subject: Re: PIC16C622 & Analog Comparators
Author:  pic microcontroller discussion list <PICLIST@spam@spamKILLspamMITVMA.MIT.EDU> at
Address-InternetPO
Date:    8/7/96 5:02 PM


Mike Riendeau wrote:
>
>
> If you were using one of the comparators with an interrupt, would
> it be possible to reconfigure the reference voltage "on the fly"
> to provide hysteresis?

1996\08\07@191220 by Scott Dattalo

face
flavicon
face
Jon Bertrand wrote:
>
>      Does the ref. voltage come out to and external pin (I'm guessing it
>      doesn't or why would you be asking this)?

If you want it to, then yes it does. You should probably guess that it does
instead of it doesn't. Because..., suppose you wish to look at a "small"
AC signal, let's say +/- 100 mv for the sake of arguement. If you wish
to digitize it with the comparator, then you will want the signal's DC
component to equal the DC voltage of the reference. This way, the signal
will oscillate about the reference voltage; positive excursions will cause
the 622's comparator to go low and negative execursions will cause it to
go high. The polarity reversal is because reference voltage is internally
tied to the positive terminal of the comparator. (That is in the mode
that makes the comparators' outputs available for feedback). And when the
negative terminal is at a higher voltage then the positive terminal, the
output of the comparator is low.

Now, you can easily offset the AC signal with one capacitor and one resistor:

          C
          ||
   AC ----||----+--------- AC signal + DC offset
          ||    |
                /
                \  R
                /
                \
                |
                +------- Reference Voltage

R and C can be chosen such that they do not load the AC signal or the
reference voltage. There are a few details that I'm still glossing over,
but I think you get the idea.


>      What kind of reference is it - does it have a sensitivity to VCC that
>      could be exploited?

It's a 16 resistor voltage divider that is fed from Vdd. There is also another
resistor and switch that allows you to provide an additonal DC offset.
Take a look at the data sheet for more details. They describe the output voltage
as a function of the switch settings. If anyone is interested in the source
impedance as a function of the switches, I'll post those equations.

Scott

'LCD's mfg & resellers'
1996\08\10@104855 by Luiz Marques

flavicon
face
Hello All,

Due great interest in apps using LCDs I will build a list of manufactures
and reseller of LDC modules.

Any collaboration reply to my email or piclist

Further I will post the complete list here

I suppose Peer Ouwehand will compile a list to your home page

TIA
Luiz Marques

1996\08\10@132225 by Pekka Ritamaki

flavicon
face
to : Luiz Marques
>Due great interest in apps using LCDs I will build a list of manufactures
>and reseller of LDC modules.
I have 4*20 ( or smaller) LCD-module: which has following specs:
-9600 or 2400 baud input, Clear, delete, cursor forward, backward commands
gotorow 1-4 commands.All commands work from row 4 to 1 or backwards
- Logo from PIC16C84 EEPROM to display ROW1-4 with one command
- options: 12bit 2-ch AD-converter to RS-232 ( temperature reading  coming)
- 4 -buttons read to RS-232
- Backpack construction to LCD-module 7-24 V in 5 mA or 5V
- Price USD 69
- details in my ww-page
Regard Pekka
Pekka Ritamaki PROBYTE Oy Nirvankatu 31
FIN-33820 TAMPERE Finland http://www.sci.fi/~pri
Electronics product design: hardware+software+development tools
puh INT +358-31-2661885 fax INT +358-31-2661886

1996\08\12@175912 by Peer Ouwehand

flavicon
face
At 11:52 96/08/10 -0700, you wrote:
>Hello All,
>
>Due great interest in apps using LCDs I will build a list of manufactures
>and reseller of LDC modules.
>
>Any collaboration reply to my email or piclist
>
>Further I will post the complete list here
>
>I suppose Peer Ouwehand will compile a list to your home page
>
>TIA
>Luiz Marques

I will, as soon as I receive the info.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
       Peer Ouwehand
       EraseMEpouwehaRemoveMEspam@spam@iaehv.nl
       http://www.iaehv.nl/users/pouweha/

       Welcome my son, welcome to the machine. (Pink Floyd)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

'VoicePorts---Audio->A/D->UART->RS-232 TX & RX rvrs'
1996\08\22@045003 by John Welling

flavicon
face
I am seeking a simple expedient path to a "VoicePort" audio digital
sampler to RS-232 port driver.   Parameters for this device and
complementary receiver of reverse process are:
Telephone handset Audio into A/D converter sampling 8-bit bytes at
22,050 sample rate with serial data fed to UART(16550) outputting 57,600
bit rate to MAX-232 RS-232 driver.
Also needed is the reverse process for RS-232 data RX to D/A to decoded
audio from a SEPARATE port.
I would prefer standalone hardware for dedicated function without the
usual bulk of programming and debugging associated with 57k port speeds
to keep UNBROKEN STREAM OF DIGI-AUDIO DATA FLOW IN REAL TIME.
Basic Device Layout:
    TX
AUDIO-->ADC0831------->16550------->MAX232--------------->RS-232-->
              (A/D conv.)          (UART)     (Level Shifter)

 RX AUDIO<--DAC0808<--74HC154<--16550<------MAX232<-----RS-232--<
                        (D/A conv.)      (ser/par)    (UART)    (Level
Shifter)
                          (convert)

I am reasonably sure about this design, but not experienced at how to
program/initialize the 16550 UARTs.  Perhaps init/config data can be
loaded thru a parallel port buffered into the UART.  This design was
chosen to avoid lengthy programming of any CPU's
because these VoicePorts are a mere FUNCTIONAL expediency to demo voice
thru RS-232 .
    Also, if there is a more timely design to accomplish the objective,
I would be open to consider it.  The above design is not mandatory.  I
considered a PIC 16C74 with A/D and serial I/O with drawbacks of extra
hardware and interface for 8-bit D/A reverse process and extra load of
programming.
    Tried to link PC soundcard Record & Play A/D-D/A functions to
RS-232, but 57,600 port speed precludes anything but custom Visual C++
pgrm to pipe .wav streamed I/O thru Win32 API (Win95 platform).

Does anyone have a better notion, preferably in specific chipset readily
available?

TIA,
-John
RemoveMEsirejohnspamspamEraseMEbbs-la.com

1996\08\22@093921 by liebchen

flavicon
face
John Welling wrote:
>
> (snip)
> Telephone handset Audio into A/D converter sampling 8-bit bytes at
> 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
> bit rate to MAX-232 RS-232 driver.
> (snip)

John,

I can't follow your computation. If you have 22 kSamples/s, you would
need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).

Wolfram

--

+-----------------------------------------------+
! Wolfram Liebchen, STOPspamliebchen.....spamipserv.ffo.fgan.de !
!        Forschungsinstitut fuer Optik          !
+-----------------------------------------------+

1996\08\22@100938 by mfahrion

flavicon
face
> John Welling wrote:
> >
> > (snip)
> > Telephone handset Audio into A/D converter sampling 8-bit bytes at
> > 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
> > bit rate to MAX-232 RS-232 driver.
> > (snip)
>
> John,
>
> I can't follow your computation. If you have 22 kSamples/s, you would
> need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).
>
> Wolfram

I get the same result - but still shouldn't be a big problem.  Using
"special" 232 transceivers you can easily go 230Kbaud and possibly
460Kbaud.  That's a lot of interrupts though - I'd consider using a
16750 UART instead of the 16550A (64 byte FIFO's instead of 16) or
even something more specialized.

-mike
spamBeGonemfahrionRemoveMEspamRemoveMEbb-elec.com

1996\08\22@213646 by Lee Jones

flavicon
face
>> Telephone handset Audio into A/D converter sampling 8-bit bytes at
>> 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
>> bit rate to MAX-232 RS-232 driver.

Why bother with 22,050 samples/second with telephone handsets?  They
were designed for a frequency range of ~300 to ~3000 Hertz.  Most of
the carbon microphones and little speakers used in handsets just don't
have the frequency response to justify this high a sample rate.

Telephone companies chose 8,000 8-bit samples/second to give an upper
frequency response of ~4000 Hertz (Nyquist limit).

This is why the telephone companies use a 64,000 bits/second digital
data rate for each call.  It's reflected in the ISDN bearer (B) and
DS1 (aka T-1 in USA, E-1 in Europe) channel signalling rates. [FYI:
56,000 bps is the result of stealing the low order bit for "robbed
bit" signalling of on-hook/off-hook state].

> I can't follow your computation. If you have 22 kSamples/s, you would
> need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).

Common asynchronous serial transmission uses 10 bits consisting of
1 start bit, 8 data bits, no seperate parity bit, and 1 stop bit.  Thus,
22,050 8-bit samples per second requires 220,500 bits/second or higher
(ignoring flow control and error checking).

If you use a synchronous protocol, you could approach 176,400 bits per
second (22,050 samples/sec * 8 bits/sample).  The actual data rate
would be higher due to frame synchronization data, packet size, etc.

> I get the same result - but still shouldn't be a big problem.  Using
> "special" 232 transceivers you can easily go 230Kbaud and possibly
> 460Kbaud.

RS-232 was not designed to run at those speeds.  It may; but EMI/RFI
may be a real issue.  I'd switch to RS-422, RS-423, or RS-485.

                                               Lee Jones

-------------------------------------------------------------------
Jones Computer Communications             @spam@leespamBeGonespamfrumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

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