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

_Sub string match.
PICList Thread
'PIC Code Library'
1994\06\10@203406 by tom

flavicon
picon face
I'm setting up a code library for the PICs.

The way it will work is:

PIC users (YOU) send routines in by e-mail. I classify and index
them.
If a user wants a routine to do X, they send e-mail specifying X and
the mailler here does the obvious.

If the said user improves the routine, or performs the function in a
different fashion, they improve the library by sending their version.
etc. etc.  I assume you get the picture. <g>

So, what can _you_ offer ?
~~~~~~~~~~~~~~~~~~~~~~~~
We need routines of every complexity from basic in/out and timing
etc.
for brand new users upto whatever you can legally part with. :-)

SO, dig out the early stuff you did when you were first play^H^H^H^H
experimenting with the PICS and e-mail it ;-

TO:             spam_OUTPicsTakeThisOuTspamtakdsign.demon.co.uk
Subject:        Pic-code

As an extension to this it would be nice to offer complete packages.
i.e. circuit diag. + board layout ready to produce a board to
go with the software.

So, if you include a circuit diag, I'll lay out the boards and we'll
find an ftp site to hold them.
--
Cheers
                                     Tom



'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                             .....johnKILLspamspam@spam@aifh.ed.ac.uk
Dept. of Artificial Intelligence
University of Edinburgh
5 Forrest Hill
Edinburgh EH1 2QL


'example C code'
1994\08\22@150956 by crocontroller discussion list
flavicon
face
Hi,

I recently purchased the Custom Computer Services PCM C compiler for
PICs. if any PCM users would like to send me some example code that
they have used successfully with this compiler that would be
appreciated.

       thanks,
       owen


'Need PIC Object Code (Electronics Now Wand)'
1994\09\19@144010 by crocontroller discussion list
flavicon
face
Don Lekei prophesized:
> I have
> been toying with some Parallax-to-ASPIC macros, but I have little
> confidence in them yet as I do not know the actual  code generated by the
> Parallax "Instructions".

The Parallax User's manual shows the native instructions generated for
each Parallax mnemonic.  I could also assemble the assembler test file
(ie. all mneumonics) and send you the hex version.


'Multiplication code ?'
1994\10\27@121951 by crocontroller discussion list
flavicon
face
Hi,
OK, so I'm (quite) new to PICs and assembler programming. I have a
(hopefully) simple question: is there (and if yes, where) some short,
effective code on how to tell the PIC to perform an integer multiply
(non-multiples of two, that is, and without going down to AND's and OR's on
single-bit level).

Bye
 Markus

1994\10\27@151715 by crocontroller discussion list

flavicon
face
On Thu, 27 Oct 1994, Markus Imhof wrote:

> Hi,
> OK, so I'm (quite) new to PICs and assembler programming. I have a
> (hopefully) simple question: is there (and if yes, where) some short,
> effective code on how to tell the PIC to perform an integer multiply
> (non-multiples of two, that is, and without going down to AND's and OR's on
> single-bit level).
>
> Bye
>   Markus
>

I believe you will find the code for integer multiply already written in the
Microchip Embedded Controller Handbook.  It can be downloaded directly
from the Microchip bulletin board.  You don't even have to type it in.
Call Microchip directly to get directions for reaching their bulletin board.

Cheers,

Martin Kirk
Arizona State University

1994\10\27@182831 by crocontroller discussion list

flavicon
face
Markus,

Multiplcation is handled in some application notes.  See if you can get
them from Microchip or try an address like:

 ftp.sics.se

in some dir like /pub/mchipsoft/mchipsoft

best of luck

regards

Gary Gaskell
DSTC
Cooperative Research Centre for Distributed Systems Technology
Queensland University of Technology
Ph    +61-7-864 1051            FAX    +61-7-864 1282
Email gaskellspamKILLspamdstc.qut.edu.au   URL    http://www.dstc.edu.au/intro.html

On Thu, 27 Oct 1994, Markus Imhof wrote:

{Quote hidden}

1994\10\28@092343 by crocontroller discussion list

flavicon
face
Markus,

I wrote my own integer multiply bit by bit.  It sure takes a few lines of code
to do a*b.  Most of the basic math functions are written and available, but
I had a problem with some of the code.  As a result, I did my own.  Oh yeah,
I also needed to do a 3-byte times a 2-byte integer, and I couldn't find
anything already written.

Let me know if I can help.

Yours,

Derrick Early


'Code hopping with PICS'
1994\12\13@162736 by crocontroller discussion list
flavicon
face
Hi everybody

I am trying to develop a code hopper alarm remote control system using the
PIC16C54 or PIC16C56 micro.

Is there anybody else doing the same or who can help at all?

Regards

Werner Terreblanche
South Africa


EMAIL : .....wterrebKILLspamspam.....active.co.za

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

1994\12\14@105058 by tom

flavicon
picon face
Werner Terreblanche Wrote ;

> I am trying to develop a code hopper alarm remote control system using the
> PIC16C54 or PIC16C56 micro.
>
> Is there anybody else doing the same or who can help at all?
>
I offer the following for comments;

One way of producing a code hopper is as follows:-

1) Both transmitter and receiver contain an identical
  (psuedo) random number generator, and at installation they are put
  in sync i.e. both know what the last number was (have a learn mode
  on the rx, fire off the tx, presto there in sync).

2) Have the rx respond to the NEXT (x) random numbers i.e.

             rx a code
             try and match to next rand
              if fails try again (x) times

  This would be the rx window and needs to be large enough (contain
  sufficient tries) to account for accidental activation of the tx
  when out of range of the rx, as this would otherwise put the two out
  of sync.

3) on the tx each activation causes the next random number to be used
  on the rx each successful match causes the next random number to be
  used.

This way once a code has been used it will not be repeated for the
maximum iterations of the random number generator. any 'replay' device
would fail because it would simply play back a code that was not within
the match window.

Use the E2prom pic (16c84) or have an eeprom connected to the pic to
store the last number used (next random seed).

the following is a code segment of an 8 bit psuedo random generator,
this will give 0 to 255 in random order without repeating for 255
iterations, this could be expanded to a 16bit easily.

Each time it is called it requires the last number as the seed for the
next number.

;*******************************************************************************
**
; Code segment by Gary Whittaker 1993,  << Pubic Domain >>                     *
*
;          EraseMEgaryspam_OUTspamTakeThisOuTadvtech.demon.co.uk
**
;-------------------------------------------------------------------------------
**
; l_rand & rand must be defined as variables
**
; CALL this routine for each successive random number
**
;*******************************************************************************
**

;******* next random number routine expects seed (last rand) in l_rand,
;******* returns in next randome number in l_rand
;******* uses a 4 bit xor with rotate left (bits 3,4,5,7)

next_rand       MOVF    l_rand,w
               MOVWF   rand            ;take a copy (leaving one in w)
               BCF     rand,.3         ;set up xor bits 3+5
               BCF     rand,.5
               BTFSC   rand,.4         ;mov bits 4+7 into 3+5 ready for
               BSF     rand,.3         ;the xor
               BTFSC   rand,.7
               BSF     rand,.5
               XORWF   rand,w          ;xor 3+4,5+7 into 3+5
               MOVWF   rand
               BCF     rand,.3         ;clear xor bit 3
               BTFSC   rand,.5         ;mov bit 5 into 3 ready for xor
               BSF     rand,.3
               XORWF   rand,same       ;xor 3+5 into 3
               BCF     status,carry    ;set carry to result
               BTFSC   rand,.3
               BSF     status,carry
               RLF     l_rand,same     ;rotate next into l_rand
               BCF     status,carry    ;clear carry for safety

               RETLW   .0

;*******************************************************************************
*
end
__
  TAK

1994\12\14@225157 by crocontroller discussion list

flavicon
face
{Quote hidden}

Hmmmm..... I press my car-alarm transmitter a lot when walking down the
street (just for scientific purposes, of course :-) and I suspect that I may
have some sort of code-hopping system since the installer had to have both
transmitters when he installed the receiver (I think).

mike

1994\12\15@223244 by crocontroller discussion list

flavicon
face
Michael Bender wrote (regarding code-hopping remote controls):

> Hmmmm..... I press my car-alarm transmitter a lot when walking down the
> street (just for scientific purposes, of course :-) and I suspect that I may
> have some sort of code-hopping system since the installer had to have both
> transmitters when he installed the receiver (I think).

Typically each remote has a unique fixed code, and the reciever has to be
programmed for the remotes.  There is usually a switch on the alarm somewhere
to enable programming.

Eric

1994\12\16@001256 by crocontroller discussion list

flavicon
face
| Michael Bender wrote (regarding code-hopping remote controls):
|
| > Hmmmm..... I press my car-alarm transmitter a lot when walking down the
| > street (just for scientific purposes, of course :-) and I suspect that I may
| > have some sort of code-hopping system since the installer had to have both
| > transmitters when he installed the receiver (I think).
|
| Typically each remote has a unique fixed code, and the reciever has to be
| programmed for the remotes.  There is usually a switch on the alarm somewhere
| to enable programming.

What do you think the chances are that one of my remotes could be used
to activate another receiver? I would hope that each receiver and
transmitter from the same company have at least a fixed manufacturer
code, and then a portion of the rest of the code that was variable
based on the matching of the two units.

mike

1994\12\16@022542 by crocontroller discussion list

flavicon
face
>
> What do you think the chances are that one of my remotes could be used
> to activate another receiver? I would hope that each receiver and
> transmitter from the same company have at least a fixed manufacturer
> code, and then a portion of the rest of the code that was variable
> based on the matching of the two units.
>
> mike
>

Some manufacturers of remote controllers use encoder IC's entented for
simple remote control applications and not for high security environments.
These devices typically send only about 12 bits and that's it!

I once made a device that could read the code transmitted by the Tx and then
retransmit that same code at a later time (Using a PIC by the way!)  This
device could easily be used by thief to for example open a car with central
lock.  That is why I am interested in developing a code hopping system.

Regards

Werner
wterrebspamspam_OUTactive.co.za

1994\12\16@130627 by crocontroller discussion list

flavicon
face
On Fri, 16 Dec 1994, Werner Terreblance wrote:

> Some manufacturers of remote controllers use encoder IC's entented for
> simple remote control applications and not for high security environments.
> These devices typically send only about 12 bits and that's it!

 This is the way my Ungo transmitter is made. It has a 144049 buffer
with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
and that is connected to a 145026 encoder which transmits nine bits.

 Wouldn't be that hard for a thief with a little ee knowledge to hook a
PIC up to it and cycle thru the possible combinations...

>
> I once made a device that could read the code transmitted by the Tx and then
> retransmit that same code at a later time (Using a PIC by the way!)  This
> device could easily be used by thief to for example open a car with central
> lock.  That is why I am interested in developing a code hopping system.

 You might also want to look into one way encryption ciphers(hash
tables) there was a discussion on the cypherpunks mailing list several
months back about using one way functions in security applications.

  Brian

------------------------------------------------------------------------------
"Everyone is a prisoner holding their own key."    | finger @spam@blaneKILLspamspamseanet.com
   -- Journey                                     | PGP 2.6 email accepted
------------------------------------------------------------------------------

1994\12\16@141219 by crocontroller discussion list

flavicon
face
>>
>> What do you think the chances are that one of my remotes could be used
>> to activate another receiver? I would hope that each receiver and
>> transmitter from the same company have at least a fixed manufacturer
>> code, and then a portion of the rest of the code that was variable
>> based on the matching of the two units.
>>
>> mike
>>
>
>Some manufacturers of remote controllers use encoder IC's entented for
>simple remote control applications and not for high security environments.
>These devices typically send only about 12 bits and that's it!
>
>Werner


FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
combinations, but the base and the remote only have eight DIP switches in
them for setting your code.  When I called them up and said, "Hey, where are
these gizillions of codes?"  all they would say was, "It's in dere".

Are they saying the R/T have fixed code prefixes inside?  Would they
distribute matching sets to the same areas?  That would be bad.  Who's to
say they don't do this?

Anyone have any hard information on this?

- JohnR

--
John R. Haggis            KILLspamhaggisKILLspamspamnetcom.com
Millennium Research
(408) 269-1814 vox
(408) 269-9323 fax

1994\12\16@161440 by crocontroller discussion list

flavicon
face
>
John R. Haggis wrote:

> FWIW, I have an Ungo car alarm, and the docs say it's got gizillions of code
> combinations, but the base and the remote only have eight DIP switches in
> them for setting your code.  When I called them up and said, "Hey, where are
> these gizillions of codes?"  all they would say was, "It's in dere".
>
> Are they saying the R/T have fixed code prefixes inside?  Would they
> distribute matching sets to the same areas?  That would be bad.  Who's to
> say they don't do this?
>
> Anyone have any hard information on this?
>
> - JohnR
>

Even if they do have longer codes than just the eight bits, the code could
still be sampled by a fast microprocessor in much the same manner as the
multiple IR remote control devices work which "learns" a code.  Unless the
code is different every time you press the button, there will be an easy
option to decipher the code.  I have experimented with this and it is
definetely possible.

Regards

Werner Terreblanche
RemoveMEwterrebTakeThisOuTspamactive.co.za

1994\12\16@162305 by crocontroller discussion list

flavicon
face
>
> On Fri, 16 Dec 1994, Werner Terreblance wrote:
>
> > Some manufacturers of remote controllers use encoder IC's entented for
> > simple remote control applications and not for high security environments.
> > These devices typically send only about 12 bits and that's it!
>
>   This is the way my Ungo transmitter is made. It has a 144049 buffer
> with some of it's pins soldered to gnd(or 5v, can't tell) for the code,
> and that is connected to a 145026 encoder which transmits nine bits.
>
>   Wouldn't be that hard for a thief with a little ee knowledge to hook a
> PIC up to it and cycle thru the possible combinations...
>

There's an ad in the latest Nuts & Volts magazine for just such a device.
Of course, only lock smiths and car repossesion professionals ;-) can
buy them.  It claims that in a mere 10 minutes, 90% of all car alarms
on the market can be "silenced".

Perhaps there *is* money for EE's on "the dark side".

cje

--
Chris Elmquist, N0JCF           On Dr. McCoy's tombstone: "He's dead Jim".
spamBeGonechrisespamBeGonespamn0jcf.com
TakeThisOuTn0jcfEraseMEspamspam_OUTamsat.org

1994\12\17@011301 by tom

flavicon
picon face
> >
> John R. Haggis wrote:
>
> > Are they saying the R/T have fixed code prefixes inside?  Would they
> > distribute matching sets to the same areas?  That would be bad.  Who's to
> > say they don't do this?
> >
> > Anyone have any hard information on this?
Batching sets to an area would be uneconomical given the sales rates of alarms.
There are at least half a dozen different coding chips on the market, each uses
a slightly different way of producing the code.
_Most_ of them use at least 12 bit code.
A couple of Motorola devices use 3-way sensing on the inputs
i.e. pos, neg, or floating input gives a code differ.
Thats 12 x 3 x,,, er, who's got a calculator ? :)

Now if you did it with a PIC, you could have 8 bits user selected and a couple
of locs. with random nos pre-programmed. Mix and match before transmitting and
have the decode routine learn it's relevant Tx code. That gives you 24 bit code
with one 8 way dil-switch. Then transmit the code twice, the second time
inverted and code samplers will just fall over.

Then Werner wrote ;
> >
>
> Even if they do have longer codes than just the eight bits, the code could
> still be sampled by a fast microprocessor in much the same manner as the
> multiple IR remote control devices work which "learns" a code.  Unless the
> code is different every time you press the button, there will be an easy
> option to decipher the code.  I have experimented with this and it is
> definetely possible.

Possible, but an unrealistic time-scale. The micro does'nt have to be fast BTW
'cos the code is not transmitted all that fast, a PIC running at 8 Meg would
still take, from memory over 3 hours to cycle.
__
  TAK


'Re Serial code'
1995\02\18@131547 by Bryan Crotaz
picon face
I have a piece of code for reading and writing serial.
Clocked from the RTCC, written for 16C84, but should be easily
portable, as everything is done with #defines.
(Written for MPASM)
Anyone wanting it mail me direct.
If enough interest, I'll mail to the list.

One trick I use is to get a flag to go high for 1 second after
received word.  Done by decrementing counters in interrupt routine.

Baudrate is variable, as is no. of bits.
Works at present as one start bit, no stop bit., 1200 baud

Bryan

--
---------------------------------
BRYAN CROTAZ - RemoveMEb.crotazspamTakeThisOuTic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London  SW7 2BB
Tel. 0171-594-8104
Fax. 0171-594-8065 Attn. STOIC { NOTE NEW FAX NUMBER }

'serial code'
1995\02\26@161323 by Henri

flavicon
face
Hi there,
currently there was a discussion about serial programming and not
reinventing the wheel. Well, that's exactly how I feel, but I
didn't catch up any piece of code. So does somebody of you
have a teenie weenie piece of assembler code for reading serial
data on a 2-wire interface (SCLK,DATA) ?

Henri

--
=============> The sanest place is still behind the trigger <===============
[]-------------------------------[]---------------------------------------[]
||         Henri Schultze        || Magdeburg D-39122 Alt-Fermersleben 88 ||
||   henriEraseMEspam.....fscz-md.boerde.de     ||          The Cracker Company          ||
[]-------------------------------[]---------------------------------------[]
=================> in a world of compromise, some don't <===================

1995\02\26@202126 by Andrew Warren

face
flavicon
face
Henri Schultze (EraseMEhenrispamfscz-md.boerde.de) wrote:

>currently there was a discussion about serial programming and not
>reinventing the wheel. Well, that's exactly how I feel, but I
>didn't catch up any piece of code. So does somebody of you
>have a teenie weenie piece of assembler code for reading serial
>data on a 2-wire interface (SCLK,DATA) ?


Come on, Henri... Assembly-language programming doesn't get much easier
than this.

Since you didn't give any details, I'll assume that DATA is valid when
SCLK is high, and that you're only reading 8 bits from the interface.

       #DEFINE DATA    [any port]
       #DEFINE SCLK    [any other port]

       RECEIVE EQU     [any file register]

       ;.... initialize registers, setup port TRIS registers, etc. ....

       GETBYTE MOVLW   00000001B       ;PUT A "1" IN "RECEIVE"'S LSB SO
               MOVWF   RECEIVE         ;WE'LL KNOW WHEN WE'VE RECEIVED
                                       ;8 BITS.

               CLRC                    ;ASSUME WE'LL SHIFT A "0" INTO
                                       ;"RECEIVE".

       GETBIT  BTFSS   SCLK            ;WAIT FOR SCLK TO GO HIGH (CARRY
               GOTO    $-1             ;IS ALWAYS CLEAR HERE).

               BTFSC   DATA            ;IF DATA = 0, SKIP AHEAD.
               SETC                    ;OTHERWISE, SETUP TO SHIFT A
                                       ;"1" INTO "RECEIVE".

               RLF     RECEIVE         ;SHIFT THE CARRY INTO "RECEIVE".

               SKPNC                   ;IF WE'VE RECEIVED ALL 8 BITS,
               GOTO    DONE            ;GO EXIT.

               BTFSC   SCLK            ;OTHERWISE, WAIT FOR SCLK TO GO
               GOTO    $-1             ;LOW.

               GOTO    GETBIT          ;LOOP BACK.

       DONE    ....                    ;8 BITS OF RECEIVED DATA ARE IN
                                       ;"RECEIVE".  FIRST BIT RECEIVED
                                       ;IS IN THE MSB, LAST BIT IS IN
                                       ;THE LSB.

-Andy


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

1995\02\27@155453 by Henri

flavicon
face
-Andy wrote:
>
> Come on, Henri... Assembly-language programming doesn't get much easier
> than this.
Ohh. Shame on me :-)
But I mostly end up with some optimized code from some "AN..." of the
Embedded Control Handbook". So I like to see something good. And two
persons (mostly) have two different ideas. So I could already catch
some good idea from your code. Thanks for that.
>
> Since you didn't give any details, I'll assume that DATA is valid when
> SCLK is high, and that you're only reading 8 bits from the interface.
>
Well, I didn't want bother you all to much. So I reduced the problem
to a small kernel.
Actually I have to interface an ADC AD7714 to a PIC hostcontroller.
Things get a little bit easier when I (e.g. the PIC) provide the
SCLK. BTW: it's also a 3-wire interface, but that doesn't make a
difference in general. I have to send lots of control data to the
ADC, then initiate a read-cycle, then read 16/24bit of data.
Then I'll do just something with that conversion data I hopefully get.
But plenties of time probably will walk throu the land before I get
this far.

Bye
          Henri

--

{Quote hidden}

--
=============> The sanest place is still behind the trigger <===============
[]-------------------------------[]---------------------------------------[]
||         Henri Schultze        || Magdeburg D-39122 Alt-Fermersleben 88 ||
||   RemoveMEhenrispam_OUTspamKILLspamfscz-md.boerde.de     ||          The Cracker Company          ||
[]-------------------------------[]---------------------------------------[]
=================> in a world of compromise, some don't <===================

1995\02\27@231956 by Andrew Warren

face
flavicon
face
Henri Schultze (RemoveMEhenriTakeThisOuTspamspamfscz-md.boerde.de) quoted me...

>> Come on, Henri... Assembly-language programming doesn't get much
>> easier than this.

..then wrote:

>Ohh. Shame on me :-)


       Henri:

       Sorry... I didn't mean for it to sound like that.

       -Andy


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


'Real Opcodes (was "Solving an equation")'
1995\03\14@235850 by Andrew Warren
face
flavicon
face
Luigi Rizzo (RemoveMEluigiKILLspamspamlabinfo.iet.unipi.it) wrote:

>> getlog  jmp     pc+w
>          ^^^^^^^^^^^^
>what is the Microchip/OPCODE equivalent of this instruction ?


Luigi:

The real opcode equivalent is:

       GETLOG  ADDWF   PC

-Andy

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

'No-assemble code'
1995\03\21@185217 by James L. Johnson

flavicon
face
Hi again,

 Here's a real live example of Microchip code that won't assemble in
the Parallax PASM and I don't know why.  The error I get is in the
first line of the "test program".  The error says:

 "data was already entered at 000h"   and the line that generated it is:

 "main  movlw   0F3h"


 So ... what data was already entered?  There is no mention of a location
000h in the first place.  Perhaps this is one of those instances where
the assembler is totally confused by something else, but prints that as
the error.  You know how these software things are.

 Any ideas?

 Tnx,

 Jim Johnson
 spamBeGonejjohnsonSTOPspamspamEraseMEhpl.hp.com



;*******************************************************************
;        include "mpreg.h"

       include 'dbl_add.asm'   ; JJ - attempt at including a file
       include 'dbl_jj.asm'    ; JJ - another include file

;       org     0
;
LupCnt  equ     10             ; Number of iterations
;
SqrtLo  equ     10             ;ACCaLO
SqrtHi  equ     11             ;ACCaHI
;
NumLo   equ     1Dh
NumHi   equ     1Eh
count   equ     1Fh
;
;
init
       movlw   LupCnt
       movwf   count
       movf    NumHi,W
       movwf   SqrtHi
       movf    NumLo,W         ; set initial guess root = NUM/2
       movwf   SqrtLo
       bcf     STATUS,CARRY
       rrf     SqrtHi
       rrf     SqrtLo
       retlw   0
;
div2    bcf     STATUS,CARRY
       rrf     13,W        ;ACCbHI
       movwf   SqrtHi
       rrf     12,W        ;ACCbLO
       movwf   SqrtLo
       retlw   0
;
Sqrt    call    init
sloop   movf    NumLo,W
       movwf   12          ;ACCbLO
       movf    NumHi,W
       movwf   13           ;ACCbHI
;
       call    D_divS          ; double precision division
       call    D_add           ; double precision addition
;                               ; the above 2 routines are listed
;                               ; as seperate routines
       call    div2
       decfsz  count
       goto    sloop
       goto    over            ; all iterations done
;                               ; branch back to desired location
;
;*************************************************************
;               Test Program
;*************************************************************
;
main  movlw   0F3h
       movwf   NumHi
       movlw   0F6h       ; Set input test number = 62454
       movwf   NumLo     ;  = F3F6h
;
       goto    Sqrt      ; cannot use CALL : Math routines
;                         ; use up all the stack.
over    nop               ; all iterations done
;
self  goto    self      ; result = 00F9h = 249
;                         ; exact sqrt(62454) = 249.9
;
       org     0
       goto    main
;
       END

1995\03\22@034410 by Chuck McManis

flavicon
face
Jim, your specific problem is this:

At the beginning of your code it starts out:

>> init
>>         movlw   LupCnt
>>         movwf   count
>> ...

Now you've commented out the org 0 so that was ignored, however
in the absence of any directive the assembler starts loading code
at location 0. (makes sense yes?)

Now later in your program you have:

>>;
>>        org     0
>>        goto    main
>>;
>>        END

Which re-sets the program counter to zero and trys to assemble the
'goto main' into that address. Which overwrites the 'movlw LupCnt'
that you had in init above.

The correct fix for this specific problem is that you should move
the 'goto main' to be the first statement in your program and then
it will assemble at location 0 and all will be well.

I both agree and disagree with what has been said about Parallax's
assembler. On the one hand, if you've got working MPASM code it can
be a real pain to get it to assemble correctly with the Parallax
assembler. On the other hand, if you learn the Parallax assemblers
quirks early on (and MPASM has its own) then writing new code from
scratch can be fairly easy in both.

The lack of a macro facility and conditional assembly in the Parallax
assembler hurt it, however if you are using Linux then you could always
run cpp over the code before feeding it to pasm.

--Chuck McManis                      All opinions in this message/article are
Sun Microsystems Inc.                those of the author, who may or may not
Internet: KILLspamcmcmanisspamBeGonespamEng.sun.COM       be who you think it is.
Crypto-puzzle: *0U0JPFPrWRN9PkWRKeP5WRmIR9wP5QAWuIQP9Pu9tnIZ7AD1SIS


'Code protect'
1995\04\26@155949 by David Tait
flavicon
face
Amazing!  I have been sitting on the information about reading
protected 16C84s since March 1st 1995, but the very day I decide to
make it public, the same method is posted to alt.satellite.tv.europe
(see Lester Wilson's entry to the NEW PROGRAMMER thread).  In fact the
info there is a copy of a file I was asked to supply with my
programmer software and pre-dates the stuff included in my last
message.

Lester Wilson advertises hardware to read and write all types of ISO
7816 smart cards and program PIC16C84s.  I'm not sure his case would
be well served by making a working technique available to all and
perhaps there is a flaw in the method after all.  On the other hand
convincing punters that it is possible might increase his sales.  I
note his posting ends with these words: "I have used methods SIMILAR
to the above to achieve the same result."

This is my last posting on this subject.  I'm sorry to debase this
erudite mail list with such unsavoury matters.

David
--
EraseMEdavid.taitspamEraseMEman.ac.uk

1995\04\26@165225 by David Tait

flavicon
face
I think a null message escaped - sorry about that.

Anyway, I'm glad the code protect topic has come up again because it will
let me get this off my chest - sorry it's so long.

The security of the PIC code protection mechanism has been discussed
many times before.  It has even been discussed on the Microchip BBS:
in Message 61000 of the "Relablty" SIG David Wilkie of Microchip
ends one such thread with the soothing: "I assure you that the code is
safe once the protection bit is activated."

The vulnerability of the 16C84 is of particular concern. The 16C84 is
often used in smart cards issued by the satellite TV industry.  These
cards are intended to permit access to encrypted TV channels, and
clearly there is a lot of interest in being able to clone the cards
thereby avoiding payment to the TV providers.  This means the
protection topic is endlessly discussed in newsgroups like
alt.satellite.tv.europe.  Every so often this newsgroup carries
adverts for hardware which is claimed to be capable of reading
protected PICs.  I have always been skeptical of these claims.  I have
changed my mind.

The fact that I provide information on a homebrew 16C84 programmer
means that I often get asked whether I know how to read protected
PICs.  Recently an interesting situation arose.  I received yet
another request for this information at exactly the same time that
someone happened to send me details of a technique claimed to
unprotect PICs.  I simply passed these on from one correspondent to
the other.  Much to my surprise the requester later wrote back to say
the technique worked (but he destroyed 3 PICs in the attempt).  The
originator of the method is happy for the information to be placed in
the public domain although he wants to remain anonymous for some
reason.  So for the benefit of PICLIST readers (and I know that
includes Microchip employees) here are his instructions more or less
verbatim (although the description is tied to his programmer the other
guy used a variant of mine):


{Quote hidden}

I must admit it looks like a surefire way to destroy PICs to me so I
haven't tried it myself even though the originator claims that he has
never fried a 16C84 this way.  I realise the fact that I have never
tried it myself means that all this is just hearsay, but although
there are some points left to the imagination, the description is
explicit enough to be tested by those worried by such things.

I have no idea whether the method is related to Bela Gebles
<@spam@100324.526@spam@spamspam_OUTcompuserve.com> technique, but if you think this info is
worth GBP1000, then like him, I'll be happy to give you my bank
account details :-)  On the other hand if you think it's all hogwash,
then I'm sorry to have wasted your time.

David


'Binary Chain Codes'
1995\05\23@131558 by mlk
picon face
Hi all,
       I am now looking for a new linear position sensor for my robotics
PIC application.  I decided to leave the infrared LED to sensor link
alone because of the inherent calibration problems.  It turns out that
LEDs degrade with time to the point that constant recalibration would be
required.

       I am now exploring linear encoding for a more digital solution.
I have come across a type of absolute position linear encoding called
binary chain code which is a _non-repeating_ pattern of ones and zeros of
length 2^N.  In an N-bit code _any_ N-bit sequence appears only once in
the entire 2^N pattern so you always know where your are.

       My sensor is a Texas Instruments TSL213.  It is a 64x1 pixel
array with a simple 64-bit shift register output.  I can supposedly print my
pattern on a mylar strip and encode away. I am asking you guys if anyone has
experience with this type of position encoding especially with a PIC.  Maybe
one if you has some code written to deal with this.

Thanks,

Martin Kirk
Arizona State University
spamBeGonemlkspamKILLspamasu.edu
(602) 263-9270

1995\05\23@180957 by Walter Anderson, C.D.P.

flavicon
face
>array with a simple 64-bit shift register output.  I can supposedly print my
>pattern on a mylar strip and encode away. I am asking you guys if anyone has
>experience with this type of position encoding especially with a PIC.  Maybe
>one if you has some code written to deal with this.

I haven't used that type of encoder but it sounds similiar to a standard rotary

encoder, you might want to look at the application notes related to the rotary
encoders.

Did you find the information about the binary chain code in the application note
s for
the device or from some other source?  If its from another source could you site
the
reference? I would be interested in hearing more about this project and how it t
urns
out.

Walter Anderson
.....khadfwspam_OUTspamonramp.net

1995\05\23@182513 by mlk

picon face
On Tue, 23 May 1995, Walter Anderson, C.D.P. wrote:

> >array with a simple 64-bit shift register output.  I can supposedly print my
> >pattern on a mylar strip and encode away. I am asking you guys if anyone has
> >experience with this type of position encoding especially with a PIC.  Maybe
> >one if you has some code written to deal with this.
>
> I haven't used that type of encoder but it sounds similiar to a standard rotar
y
>
> encoder, you might want to look at the application notes related to the rotary
> encoders.
>
> Did you find the information about the binary chain code in the application no
te
> s for
> the device or from some other source?  If its from another source could you si
te
>  the
> reference? I would be interested in hearing more about this project and how it
t
> urns
> out.
>
> Walter Anderson
> TakeThisOuTkhadfw.....spamTakeThisOuTonramp.net
>

Walter,
       The source is Electronics Now, October 1994.  It was faxed to me
from TI as an app. note for their TSL213 64x1 pixel array product.

Martin Kirk
Arizona State University
TakeThisOuTmlkKILLspamspamspamasu.edu
(602) 263-9270

1995\05\23@235424 by Doug Sellner

flavicon
face
{Quote hidden}

HP PhotoOptics has a complete line of positioning sensors and strips for
this purpose.

Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410

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

Internet: RemoveMEdsellnerspamspamBeGoneembay.com

1995\05\24@042948 by S_GROB

flavicon
face
Martin Kirk wrote:
[...]

       I am now exploring linear encoding for a more digital solution.
I have come across a type of absolute position linear encoding called
binary chain code which is a _non-repeating_ pattern of ones and zeros of
length 2^N.  In an N-bit code _any_ N-bit sequence appears only once in
the entire 2^N pattern so you always know where your are.

       My sensor is a Texas Instruments TSL213.  It is a 64x1 pixel
array with a simple 64-bit shift register output.  I can supposedly print my
pattern on a mylar strip and encode away. I am asking you guys if anyone has
experience with this type of position encoding especially with a PIC.  Maybe
one if you has some code written to deal with this.

---------------------------------------------------
Hi all,

it seems, that the above problem has something to do with 'random bit
generation'.
an (electric) example:
- take a shift register, length 8 bit (bit0..bit7),
- the content of the shift register MUST not be b'00000000'!
- exor proper bits, e. g. bit7 xor bit6 xor bit4 xor bit2
- shift left this result bit into the shift register

with each shift you get a new 'random' byte. the principle can be expanded to
the desired length. the byte sequence will repeat after 2^N-1 shifts (when
xor-ing the correct bits), here it is after 255 shifts.
your problem will be to read 8 following bits from the sensor and recalculate
the order number in the range of 0..255.
An unefficient way would be to initialize the shift reg. with b'00000001', and
call the shifting procedure repeatedly until the result matches with the sensor
byte. the number of calls is equal to the position. it is easy to calculate /
compare with the following random number, but I do not know an algorithm to
calculate the preceeding value.
when using only 255 positions you could create a lookup-table, too :-)

I use this shifting principle for PIC-based software generation of random
numbers, it is also part of an application note.

By the way, what exactly does the TSL213?


Siggi


Siegfried Grob,                                   |
student of electrical engineering,                |
university of ulm, germany                        |
e-mail:  spamBeGonesiegfried.grob@spam@spamspam_OUTstudent.uni-ulm.de        |
tel&fax: +49 731 25148                            |
--------------------------------------------------'

1995\05\24@065212 by S_GROB

flavicon
face
Hi all,

in the meantime, I thought about my last mail and came to the conclusion that
is as simple to calculate the preceeding random number as the following one.

an example:      1 0 0 1 0 1 1 0           the actual random number
                ~ ~   ~   ~
                1*0 * 1 * 1      = 1      xor bit7,6,4,2

the next:  1 <-  0 0 1 0 1 1 0 1           shift left the new bit
                ~   ~   ~     ~
                0*  1 * 1  *  1   = 1     xor bit 7,5,3,0

the last:        1 0 0 1 0 1 1 0   -> 1    shift right this bit

the xor-ing is like a parity-calculation, the 4 old bits and the new bit always
have even parity. so it is always possible to calculate a missing bit from the
other four.
so if the last position code is known, calculate the following random numbers
out of the last position code until matching to get the relative forward
movement - or if not matching after a limited number of calculations,
calculate the preceeding random numbers until matching to get the relative
backward movement.

This all is a theoretical consideration. I did not test/simulate that yet.


Did everybody understand that?



By the way, what exactly does the TSL213?


Siggi


Siegfried Grob,                                   |
student of electrical engineering,                |
university of ulm, germany                        |
e-mail:  TakeThisOuTsiegfried.grobspamspamstudent.uni-ulm.de        |
tel&fax: +49 731 25148                            |
--------------------------------------------------'

1995\05\25@053414 by Kalle Pihlajasaari

flavicon
face
> >         I am now exploring linear encoding for a more digital solution.
> > I have come across a type of absolute position linear encoding called
> > binary chain code which is a _non-repeating_ pattern of ones and zeros of
> > length 2^N.  In an N-bit code _any_ N-bit sequence appears only once in
> > the entire 2^N pattern so you always know where your are.
>
> Is it better than standard way? I mean few parallel sensors and Gray coded
> strip.
Depends, the strip is only 1 bit wide and for a 16 bit resolution requires
a sense head 16 bits LONG not wide so may be possible to fit into smaller
spaces.

The problem that is solved with gray codes (only one bit changes at a time)
is not covered with the non repeating pattern code, you would need to either
have one more index track to indicate the read position or over sample the
code (16 x 4 = 64 ccd) and do edge detection and then read the center of the
bit position on all the code bits, remembering that you can have a sequence
of N (16) 1 bits which does make edge detection quite difficult.
--
Kalle Pihlajasaari     kalleEraseMEspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1995\05\25@213836 by mlk

picon face
Hi all,
       I have been off the air for a few days.  First I will respond to
S_GROB's question:

> By the way, what exactly does the TSL213?

       The TSL213 is a 64x1 pixel sensing array.  It comes in an 8-bit
package with a long window exposing the 64 pixels.  When given the SI
(start integration?) signal it ends the previous integration and
transfers the accumulated charge from pixel #1 to the output buffer.  65
successive clocks will step the output through all 64 pixels and get
ready for the next sweep.  The output is analog but when the integration
time and light intensity are selected correctly the output meets digital
1/0 specifications.

       Now for Jaroslaw Lis' question:

>Is it better than standard way? I mean few parallel sensors and Gray coded
strip.

       Bear in mind that I have not used part yet.  I am designing to it
now.  From my understanding the beauty of this approach is that it gives
an absolute position at all times.  There is no position count to keep
track of because the non-repeating code always corresponds to an absolute
position on the strip.  Also the TSL213 costs about $5 where the encoders
I have looked at are in excess of $20 each.  I need 8 of these
sensors per design so ... do the math.

       One thing to keep in mind.  The 64x1 array will be used to
oversample the coded strips.  I figure I can use a 3-bit Binary Chain
Code which gives 8 (2^3) bits in the code.  Precisely the code I will use
is:

               00010111
               ^^^
               [ ] <-- first window

       There are exactly six 3-bit windows on to this pattern:

       000
       001
       010
       101
       011
       111

       It works out that one gets 2^n - n + 1 distinct windows on any n
bit code.

       If I oversample at 16 pixels per bit I can detect the starting
position of the 3-bit code to within one of 16 positions.  That give a total
of 96 (6x16) positions I can resolve.  I only need about 70.  If my edge
detection is a little too noisy I can go to a 4-bit code and get greater
resolution.

       I welcome feedback here.  I would rather spot a colossal boo boo
before I have hardware, but I think this will do what I want it to do.
Absolute position is all I need for this application.

       Thanks for all the discussion of this topic.

Martin Kirk
Arizona State University
RemoveMEmlkEraseMEspamspam_OUTasu.edu
(602) 263-9270

1995\05\31@041804 by S_GROB

flavicon
face
Martin Kirk wrote some days ago:

> Hi all,
>         I have been off the air for a few days.  First I will respond to
> S_GROB's question:
>
> By the way, what exactly does the TSL213?
>
>         The TSL213 is a 64x1 pixel sensing array.  It comes in an 8-bit
> package with a long window exposing the 64 pixels.  When given the SI
> (start integration?) signal it ends the previous integration and
> transfers the accumulated charge from pixel #1 to the output buffer.  65
> successive clocks will step the output through all 64 pixels and get
> ready for the next sweep.  The output is analog but when the integration
> time and light intensity are selected correctly the output meets digital
> 1/0 specifications.
>
If I understand you right, the TSL213 is some sort of CCD array, or a kind
of analog shift register of 64 pixels. You can shift out each pixel sequen-
tially and convert its analogue value into a digital bit. So you get a
sequence of 64 bits representing 64 (bright or dark) pixels?

you continued:
(...)
{Quote hidden}

and if you add '00' (or in general the first n-1 bits) you get a full range
of 2^n patterns:
                 0001011100
                         ~~
000,001,010,101,011,111,110,100  :-)


continuing:
>
>         If I oversample at 16 pixels per bit I can detect the starting
> position of the 3-bit code to within one of 16 positions.  That give a total
> of 96 (6x16) positions I can resolve.  I only need about 70.  If my edge
> detection is a little too noisy I can go to a 4-bit code and get greater
> resolution.

again, if I understand you right, one bit of the Binary-Chain-Code is
represented by 16 pixels?
I. e. the pattern '000' is equal to 3*16=48 zeroes in the pixel array.
And as an 48-pixel-array can be positioned at 16 locations in a 64
full-array, you think to resolve these 16 locations?

In your example you thought to find one of your six patterns in the pixel
array to get a rough position, and to locate this pattern inside its
16-location-bandwith to get the exact position!?

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

You said, that you need a resolution of about 70 positions. But what is the
unit, in which you need your position? Do you need to know the position
as exactly as one pixel width or is your position-unit a multiple of pixels?
As I thought to read out of your lines, you want the maximum possible reso-
lution, based on a single pixel.
If yes, then it is a hard job to do! Theoretically, one bit of the binary-
chain-code is represented by 16 pixels, but reality will not be as digital
as you like it, it tends to be `fuzzy'. What I want to say is, that a bit can
be read as 15 or 17 pixels, too, which must not confuse your position-
calculation-routine!

So I would suggest one of the two following methods, based on the calculation
of random numbers I described earlier:


the unit: 1 position unit = 8 pixels
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resolution: 8 bit = 255 (or 256) positions.
divide the 64 pixel array into 8 pieces of 8-pixel-groups.
one 8-pixel-group represents one bit (8-times-oversampling).
the 64 pixel array is declared valid, if the middle five pixels of an
 8-pixel-group are the same. (the change between a 1- and a 0-bit occurs in
 the outer area of an 8-pixel-group, so no error will occur, if a bit is
 represented by 7 or 9 pixels instead of 8)
if the 64 pixel array is valid, you get an 8-bit-position-code out of the
 8 pieces.
now calculate your position out of this position-code (trial-and-error or
look-up-table)

example:
an 'x' as well as an 'o' represents a pixel. Just to show 8-pixel-groups.
pixel array: xxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxoooooooo
valid pattrn: ########      ################                 #########
            \______/\______/\______/\______/\______/\______/\______/\______/
read as:        1       0       1       1       0      0        1       0

inval. patt.:    ########      ################                 #########
            \______/
             ^^^^^ the middle four pixels are not the same



the unit: 1 position unit = 1 pixel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
this is max. resolution unit, resolution: 7 bit = 127*8 positions
again, one 8-pixel-group represents one bit (8-times-oversampling).
if pixel00..pixel04, pixel08..pixel12 and so on are equal each (no change
 inside a 5-pixel-group) then FineResolution:=0
else if pixel01..pixel05, pixel09..pixel13 and so on are equal each (no change
 inside a 5-pixel-group) then FineResolution:=1
else if pixel02..pixel06, pixel10..pixel14 and so on are equal each (no change
 inside a 5-pixel-group) then FineResolution:=2
...
else if pixel 07..pixel10 ... then FineResolution:=7
now build up a 7-bit-position-code out of the valid nibbles and calculate
the RoughResolution out of it.
ExactPosition:=RoughResolution*8 + FineResolution

(same) example:
pixel array: xxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxoooooooo
valid pattrn: ########      ################                 #########
1. run:      \______/\______/\______/\______/\______/\______/\______/
result:      ^^^^^ pixel00..pixel04 are not the same => invalid
2. run:       \______/\______/\______/\______/\______/\______/\______/
result:       ^^^^^ pixel01..pixel05 are equal => FineResolution:=1
position-code:   1       0       1        1      0       0       1
exact position := RoughResolution (1011001)*8 + FineResolution


Ist doch ganz einfach, oder?  [really simple, isn't it?]


I am sure that not everybody has understood this possible solution of a really
fascinating problem, but it is sufficient if at least Martin has :-)

I think, that my method elliminates all problems, which can occur due to
errors at the edge from a 1-bit and a 0-bit. The solution is a question of
resolution and algorithm and not really a problem of hardware, I think.
But if you have a fast and "tough" PIC, this should not be a big problem, too.

My 16C84 also survived after a rotated insertion into its socket.
So it is almost unbelievable, that a fried of mine killed his 16C84.
Maybe some 16C84 are tougher than others?

Siggi


Siegfried Grob,                                   |
student of electrical engineering,                |
university of ulm, germany                        |
e-mail:  @spam@siegfried.grobRemoveMEspamEraseMEstudent.uni-ulm.de        |
tel&fax: +49 731 25148                            |
--------------------------------------------------'


'various (probably useless) source code available'
1995\06\07@064603 by Eric Smith
flavicon
face
I've made available source code for four of my PIC-based projects

       PIC-Tock, a video clock
       DTMF dialer using PWM
       X-Y monitor tester
       Remote control for Sony A/V equipment

The code is available on the web:

       http://www.telebit.com/~eric/pic/

The code is offered under the terms of the FSF's General Public License.

The code comes with no warranty of any kind.  I don't make any claims about
it working at all.  There is essentially no documentation.  I use my own
assembler, so it will probably take at least some minor tweaks to get things
to assemble with MPASM or ASPIC.  I don't think there's much chance of getting
it to work with the Parallax toy assembler, because I use amazingly advanced
concepts such as parenthesized arithmetic expressions and conditional
assembly.

My web page describes various other projects for which the code is not
currently available, but I thought might be of interest.  I'll make some of
them available as time permits.

Cheers,
Eric

'Code Protect Bit (info)'
1995\06\30@143115 by stle.cudenver.edu>

flavicon
face
> Date: Fri, 30 Jun 1995 07:42:58 -0600
> From: Harrison Cooper <EraseMEhcooperspam@spam@DS9.SIM.ES.COM>
> Subject: Code Protect Bit (info)
>
> While at the seminar, they were talking about code protection.  They said
> that on the windowed parts, the masked to code protect location such that
> if you set the code protect bit and burned it, it would not erase this
> location, thus rendering the part useless.

I think this is something on newer parts; I have two 17C44 engineering
samples that are now doorstops, or paperweights (depending whether they're
resting legs-up or legs-down, I guess).

I have programmed and erased 17C42/JW parts dozens or hundreds of times, and
it made me very comfortable to know that the last, exact .HEX file I tried
in the windowed part was exactly the same, embedded fuses and all down to
the exact checksum, as the .HEX file handed over to manufacturing.

The 17C44 has an added ``feature'' that the definition of code protection
includes a fuse area that is unerasable.  And since OTP and windowed parts
are built from a common die pool, the mechanism intended to prevent prying
open and selectively erasing plastic DIP parts also prohibits use of code
protect on windowed parts.  Yes, you can erase everything ``else'', but then
you have an erased, windowed part that refuses programming.  It can't tell,
and doesn't care, that the code it is protecting is blank.

Peter F. Klammer, Racom Systems Inc.                   @spam@PKlammerspam_OUTspam.....ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708


'Hs anyone done any code for RC Servos?'
1995\07\02@035546 by Adam Eberbach
flavicon
face
> I'm using a PIC 16C71 to drive  3 hobby RC servos but I'm preety new to this
> assembler. Does anyone know where there is some code to drive servos? I
> know...I'm lazy but the best code is already working code.
> Thanks for your help.

Application note 532 uses a PIC 17c42 for servo control. What you really
want is a copy of the October 1994 (#51) Circuit Cellar INK. There is a
description of a device based on two 16c55s which provide up to 256 servo
channels controlled by a PC serial port. There is also good information
in the Basic Stamp manual, note #4. Basically servos reach the end of their
travel when fed pulses of 1 or 2ms duration - they center when fed 1.5ms
pulses. The RC unit that I looked at sent one 1.5ms pulse every 20ms and
varied in either direction by .4ms.

Adam Eberbach, R&D Engineer, Dataplex Pty. Ltd.

1995\07\02@151823 by David Tait

flavicon
face
Although I haven't seen the article, there was some info in Circuit
Cellar Ink (October 1994, Issue #51) about servos.  You can get the
associated PIC code (for pasm I think) by ftpmail from circellar.com.
An easy way to do this is to use Lou Sortman's WWW interface to the
ftpmail service:

http://tfnet.ils.unc.edu:80/cgi-bin/CCBBS

(Thanks Lou).

David
--
spamBeGonedavid.taitEraseMEspamman.ac.uk

1995\07\02@153105 by Henry Carl Ott

picon face
>> I'm using a PIC 16C71 to drive  3 hobby RC servos but I'm preety new to this
>> assembler. Does anyone know where there is some code to drive servos? I
>> know...I'm lazy but the best code is already working code.
>> Thanks for your help.
>
>Application note 532 uses a PIC 17c42 for servo control. What you really
>want is a copy of the October 1994 (#51) Circuit Cellar INK. There is a
>description of a device based on two 16c55s which provide up to 256 servo
>channels controlled by a PC serial port. There is also good information
>in the Basic Stamp manual, note #4. Basically servos reach the end of their
>travel when fed pulses of 1 or 2ms duration - they center when fed 1.5ms
>pulses. The RC unit that I looked at sent one 1.5ms pulse every 20ms and
>varied in either direction by .4ms.
>
>Adam Eberbach, R&D Engineer, Dataplex Pty. Ltd.
>
>

The code for the servo project is available from the Circuit Cellar FTPmail
server and is called "servopic.zip".
There is a very handy interface to the server available from WWW
       http://tfnet.ils.unc.edu/cgi-bin/CCBBS

There is also another very helpful reference project for servos by Scott
Edwards called "motion memory" He uses two joysticks to control 4 servos
with local memory for playback. I'm not sure where the source for this
project is. It used to be on the parallax board (in parallax format) but I'm
not sure it's still there. If you can't find it email me and I'll zap it to you.

Hope this helps....
carl

----------------------------------------
Henry Carl Ott      N2RVQ
carlottspamBeGonespaminterport.net
http://www.interport.net/~carlott/
----------------------------------------

1995\07\05@003816 by Richard John Farmer

picon face
>
> I'm using a PIC 16C71 to drive  3 hobby RC servos but I'm preety new to this
> assembler. Does anyone know where there is some code to drive servos? I
> know...I'm lazy but the best code is already working code.
> Thanks for your help.
>

Here it is, the code and schematic for a simple servo controller using a
PC joystick and a PIC 16c55. The code can be complied with MPALC or MPASM
and simulated with MPSIM. All are free from Microchip and available on
ftp.ultranet.com /biz/mchip + tons of other code examples. A demo version
of Circad is available mobius, but I can't remember the whole name of the
site. Some help? So you can play with this for free. If your in the Atlanta
area you can even come over and use my burner to make a chip if you bring
a beer.
Now a little on servos. Send one a 1ms pulse every 20-30 ms and it goes
all the way to the left, a 2ms pulse every 20-30ms and it goes all the way
to the right, 1.5 ms and it goes to the middle, simple. This code is simple
it just counts while the joystick pot charges a cap enough to be a 1, saves
the time, flips the pin to an output to discharge it (with a low out), then
flips it back to an input. The timing is all done in spin loops. If you want
to do something else the low time of 20-30ms is not critical. I actually
compensate for the variable high pulse time, but it isn't needed. The 16c5x
chips don't have interrupts and only 2 level deep stack, but hey they're
cheap and fast as hell. Remember, this is just something I cooked up one
afternoon, so it's not pretty but it works. Adjust the 47nF cap to compensate
for the variation in the joystick pots (that's why you have to twirl a
joystick when you start a new game).
My current project is a Xilinx SPROM programer. Anyone up on the *.MCS
file format. I've got the hardware designed, but I still don't have
all the info needed to parse the input file yet. The hardware is fully
software configurable so it'll make a good starting point for other
such project by the net.community. Anybody want a copy of my resume too :).
                                     -Cheers Rick

------------------------- begin code ----------------------------------------

            TITLE "Servo Controller"
            LIST P = 16C55
;            DATE 01SEP94
;            AUTHOR RICK FARMER
;            FILE NAME servo.ASM
;              Clock = 4MHz -> 1 instruction takes 1us
PIC55   equ     1FFH
STATUS  equ     3h              ; F3 Reg is STATUS Reg.
PortA   equ     5h
PortB   equ     6h              ; I/O Port Assignments
PortC   equ     7h
PULSE   equ    0Bh              ; pulse time high
DELAY   equ    0Ch              ; 1 ms count
DOWN    equ    0Dh              ; # ms /4 of low time
CAP     equ    0Eh              ; time to charge cap
LOWPUL  equ    0FH              ; pulse time high for duty cycle
Z       equ     2h
C       equ     0h
;********************************************************************

START   MOVLW  B'000111'        ;Select RTCC, internal clock source
                               ;  & prescale value = 256
       OPTION                  ;Actually load OPTION reg.
       movlw  00h              ;setup port A as output
       tris   PortA
       movwf  PortA            ;clear port A
       movlw  0FFh             ;setup ports B & C as input
       tris   PortB
       tris   PortC

BEGIN   MOVLW  0FFh             ;load 1ms. counter
       MOVWF  DELAY            ;get it into reg
       BSF    PortA,0          ;start pulse output

HIMS    NOP                     ;force loop into 4 cycle duty (even #)
       NOP
       DECFSZ DELAY            ;loop for 1st 1ms. of duty cycle
        GOTO  HIMS

HIGH    NOP                     ;force loop into 4 cycle duty (even #)
       NOP
       NOP
       DECFSZ PULSE            ;loop for high part of duty cycle
        GOTO  HIGH             ;while pulse > 0
       BCF    PortA,0          ;end pulse output

HIPUL   NOP                     ;force loop into 4 cycle duty (even #)
       NOP                     ;duty cycle compensation
       INCFSZ LOWPUL           ;loop for high part of duty cycle
        GOTO  HIPUL            ;while pulse > 0

       MOVLW  03h              ;load # ms * 4 counter
       MOVWF  DOWN             ;get it into reg
       MOVLW  0FAh             ;load 1ms. counter
       MOVWF  DELAY            ;get it into reg

LOW     NOP                     ;force loop into 4 cycle duty (even #)
       NOP
         INLOOP  NOP           ;force loop into 4 cycle duty (even #)
                 NOP
                  DECFSZ DELAY ;loop for low part of duty cycle
                 GOTO INLOOP
       DECFSZ DOWN             ;loop for low part of duty cycle
        GOTO  LOW

       movlw  0ffh             ;make rb1 an input
       tris   PortB            ;to let the cap charge

CHARGE  INCFSZ   CAP,1          ;start timing loop
        GOTO     NEXT          ;check for overflow
       DECF     CAP,1          ;make it FFh
       GOTO     DONE
NEXT    NOP                     ;timing nop
       NOP
       BTFSS  PortB,1          ;check input pin RB1
        GOTO   CHARGE          ;not charged yet

DONE    MOVF   CAP,0            ;but time in W
       MOVWF  PULSE            ;save time in
       MOVWF  LOWPUL

DUTY    NOP                     ;force this part to a constant 2ms
       NOP
       NOP
       NOP
       NOP
       INCFSZ CAP,1            ;loop unit roll over for constant duty cycle
        GOTO   DUTY

       movlw  0fdh             ;make rb1 an output
       tris   PortB            ;drive it low to discharge timing cap
       bcf    PortB,1          ;for a constant time

       GOTO   BEGIN            ;restart loop
       ORG    PIC55
       GOTO   START
       END

-------------------- end code, start uuencoded circad format servo.sch ------


end

Attachment converted: wonderlandone:servo.sch (????/----) (00002105)


'TRYING TO SHRINK CODE'
1995\08\12@021621 by Andrew Warren
face
flavicon
face
Kenny Baby <RemoveMEMCTKEAW@spam@spamspamBeGoneMH1.MCC.AC.UK> wrote:

{Quote hidden}

   What you have, Kenny, is code that'll display "DAOL " on the
   display.


>I NEED TO REPEAT THE ABOVE BLOCK AS MANY TIMES AS I HAVE LOOKUP TABLES
>
>IS THERE ANY WAY, OF TURNING IT INTO A UNIVERSAL CALL ROUTINE, I
>COULD PRE LOAD THE COUNT2 FILE BEFORE THE CALL IS MADE, BUT IS THERE
>ANY WAY OF GETTING AROUND THE 'CALL LCDROW1'. THE 'LCDROW1' BEING THE
>ONLY VARIABLE IN THE ROUTINE.


   Don't forget that the "MOVLW 0x04" is another variable for which
   you'll have to account.


{Quote hidden}

   I wish I knew why your signature annoys me so damned much... When I
   figure it out, I'll let you know.

   Anyway, try something like this:

       ADDRESS EQU     [any file register]
       COUNT2  equ     [another one]

       LOOKUP  MOVWF   PCL

       STRING1 DT      STRING2-STRING1+1,"This is String #1"
       STRING2 DT      STRING3-STRING2+1,"String #2"
       STRING3 DT      STRING4-STRING3+1,"You get the idea..."
       STRING4 ....

       DISPLAY MOVWF   ADDRESS
               CALL    LOOKUP
               MOVWF   COUNT2
       LOOP    INCF    ADDRESS
               MOVF    ADDRESS,W
               CALL    LOOKUP
               MOVWF   LCDDATA
               CALL    SENDLCD
               DECFSZ  COUNT2
               GOTO    LOOP

       ....

       MAIN    MOVLW   STRING1     ;DISPLAY STRING #1.
               CALL    DISPLAY     ;

               MOVLW   STRING2     ;DISPLAY STRING #2.
               CALL    DISPLAY     ;

               MOVLW   STRING3     ;DISPLAY STRING #3.
               CALL    DISPLAY     ;

   -Andy

--
Andrew Warren - .....fastfwd@spam@spamEraseMEix.netcom.com
Fast Forward Engineering, Vista, California

1995\08\12@040440 by DEZA ASENSIO, Roberto

flavicon
face
Hi Andy, Kenny and All:

Andrew Warren wrote:
{Quote hidden}

Good code!. But, if x'00' character isn't used at display, I will like
to simplify as:


       ADDRESS EQU     [any file register]

       LOOKUP  MOVWF   PCL

       STRING1 DT      "This is String #1",0
       STRING2 DT      "String #2",0
       STRING3 DT      "You get the idea...",0

       DISPLAY MOVWF   ADDRESS
       LOOP    CALL    LOOKUP
               IORLW   0           ; char null?
               SKPNZ               ; skip if not
               RETURN              ; all done
               MOVWF   LCDDATA
               CALL    SENDLCD
               INCF    ADDRESS
               MOVF    ADDRESS,W
               GOTO    LOOP

       ....

       MAIN    MOVLW   STRING1     ;DISPLAY STRING #1.
               CALL    DISPLAY     ;

               MOVLW   STRING2     ;DISPLAY STRING #2.
               CALL    DISPLAY     ;

               MOVLW   STRING3     ;DISPLAY STRING #3.
               CALL    DISPLAY     ;

Best regards:
    Roberto Deza  (.....rdezaRemoveMEspamcun.unav.es   .....rdaSTOPspamspam@spam@cpd.unav.es)

1995\08\14@132625 by CRSO.pic

flavicon
face
-> IS THERE ANY WAY, OF TURNING IT INTO A UNIVERSAL CALL ROUTINE, I
-> COULD PRE LOAD THE COUNT2 FILE BEFORE THE CALL IS MADE, BUT IS THERE
-> ANY WAY OF GETTING AROUND THE 'CALL LCDROW1'. THE 'LCDROW1' BEING THE
-> ONLY VARIABLE IN THE ROUTINE.

The technique I use is:

1)  Concatenate all output messages into one lookup table.
2)  Delimit all output messages with a unique byte values, such as 00h.
3)  Stuff the offset of the message in the table into COUNT2 before
   calling the output routine.
4)  The output routine should read the table element, test it for 00h,
   and then exit if a match occurs. Otherwise send the element and
   repeat.

The above method has an advantage in that if you have two messages, say
LFCRLF and CRLF, then you can simply supply LFCRLF<Delim> and index
to either the start (for LFCRLF) or the start+1 (for CRLF).

Another method may be used: CALLing a routine specified by a variable.
This one requires care however.

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

1995\08\14@224926 by Andrew Warren

face
flavicon
face
Dana Raymond <RemoveMEdana.raymondspamspamBeGoneCANREM.COM> wrote:

>The technique I use is:
>
>1)  Concatenate all output messages into one lookup table.
>2)  Delimit all output messages with a unique byte values, such as
>    00h.
>
>    [etc...]

Dana:

Someone else suggested this technique as well.  I didn't respond at
the time, but now that there are TWO of you advising this...

There's a very specific reason that the code I posted doesn't use
delimiters:  The LCD displays that are the subject of this thread use
"00" to represent one of their 8 custom characters.  "01" through "07"
are used, as well.  This would appear to leave "08" through "1F" as
valid choices for delimiters, but those values are often stored in
lookup tables as well, and used to DEFINE custom characters.

If you're careful, you can use delimiters with no problems, but your
code will be a little more "bulletproof" (and just as efficient) if you
use a method like the one I posted.

-Andy

--
Andrew Warren - spamBeGonefastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California

'SHRuNK CODE'
1995\08\15@041124 by Kenny Baby

flavicon
picon face
I now have it sussed (thinks me ), when I've cleaned it up a bit and
finished having ideas as to what else I can include in the table,that
can be sent all at the same time, I'll send it to you and you can
pick it to pieces.

Many thanks to you all
..

..

..

..

..

..

..

I've seen things you people wouldn't believe.
Attack ships on fire off the sholder of Orion.
I watched C-beams glitter in the darkness at Tan Hauser Gate.
All those moments will be lost in time,
like tears in rain.
Time to die.

Remember now, watch out for the Fairies......!

'TRYING TO SHRINK CODE'
1995\08\16@125013 by CRSO.pic

flavicon
face
-> There's a very specific reason that the code I posted doesn't use
-> delimiters:  The LCD displays that are the subject of this thread use

Thanks for your comments Andy. Actually, both techniques (strings
proceeded by a size byte, as used by DOS, and delimited strings) are
valid and have been used since the beginning of computing itself. Each
has its advantages and disadvantages. Both require a table read, an
index advance, a compare, and loop for each value. Both can be used to
concatenate strings together by two CALLS if the DISPLAY routine returns
the pre-advanced index in W.

However, the delimited method allows trailing substrings to be
transmitted so long as at least one value out of 256 is available as
EOS.

The sized approach has the advantage that leading substrings may be
transmitted if the DISPLAY routine has a second entry point (after size
byte read) and the caller preloads the size before calling DISPLAY.

I tend to use delimited strings for text, but have also used sized
strings (even in C!) when dealing with binary communications.

BTW thank you for your efforts to resolve the interrupts during ADDWF
PCL issue.

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

1995\08\16@205446 by Andrew Warren

face
flavicon
face
You wrote:

>However, the delimited method allows trailing substrings to be
>transmitted so long as at least one value out of 256 is available as
>EOS.

   You're right... This IS an advantage.  In fact, I usually use
   delimited strings, too; it just happens that I'm in the middle of a
   project that displays text strings on a Hitachi LCD, and my code
   broke as soon as I put custom characters in the strings.

>BTW thank you for your efforts to resolve the interrupts during ADDWF
>PCL issue.

   No problem...

   -Andy

--
Andrew Warren - spamBeGonefastfwd@spam@spamix.netcom.com
Fast Forward Engineering, Vista, California

1995\08\17@032636 by Timo Rossi

flavicon
face
Andrew Warren:
>     You're right... This IS an advantage.  In fact, I usually use
>     delimited strings, too; it just happens that I'm in the middle of a
>     project that displays text strings on a Hitachi LCD, and my code
>     broke as soon as I put custom characters in the strings.

At least the LCDs that I have used have the 8 user-defined
characters both in 0..7 and 8..15, so it would still be
possible to use zero as a delimiter.

--
<< Timo Rossi  --  email: RemoveMEtrossiEraseMEspamKILLspamjyu.fi >>

'PIC-based Closed Caption Decoder'
1995\08\21@052410 by Eric Smith

flavicon
face
By popular demand, the source code for the closed caption decoder that
Rich Ottosen and I designed is now available on the web.  As with my other
PIC projects, it is covered by the GNU General Public License, Version 2.
The URL is

       http://www.telebit.com/~eric/pic/caption.html

A copy of the text of the web page is attached below for your convenience.

Cheers,
Eric
http://www.telebit.com/~eric/pic/
-----------------------------------------------------------------------------
Closed-Caption Decoder

This is a closed-caption decoder with serial output, based on a PIC16C71, an
Elantec EL4581C sync separator, and an LM393 dual comparator (for data slicing
with automatic threshold).

This project was partially inspired by the article "Build the Text Grabber" by
Kelly McArthur in the November 1994 issue of Electronics Now, but where Kelly
used an 8031 based design requiring a total of 16 chips, we found it possible
to implement essentially the same functionality with four by using a PIC.

The code for this project is available under the terms of the Free Software
Foundation's General Public License, Version 2.  If you agree to the terms of
the license, you may obtain a copy via FTP.

The code won't do you much good if you don't have the schematic.  I don't yet
have it available in electronic form, but if you want it send me email and
I'll arrange to get it to you.

Sync Separation

We originally used a common National Semiconductor LM1881 sync separator (as
did Kelly), but it seemed fairly unreliable so we switched to the Elantec
EL4581C, which is a pin-compatible improved performance part.  It works much
better.

Because the field output of the LM1881 was particularly unreliable, we ended
up using only the composite sync output of the sync separator, and deriving
the horizontal sync, vertical sync and the field in software.  The Elantec
part probably generates perfectly good sync and field outputs, but it would
be more trouble than it is worth to switch back.

Using other PICs

Rich has recently converted the code to run on a PIC16C56.  The only advantage
of the '56 is that Rich had a Parallax downloader for the '5x family, and that
the '56 is cheaper than the '71.  Microchip now offers a '61 (which is a '71
without the A/D converter), which probably has comparable price to the '56.

Rich points out that the '56 version of the code isn't very maintainable and
the RAM is completely full.

Microchip's recently announced PIC16C62X series parts may be an even better
fit for this application, since they have two built-in comparators which might
replace the separate LM393.

Other Articles

Another good article regarding capturing digital data from video signals is
"Exploring the Vertical Blanking Interval" by Mark Barnes, published in the
April 1994 issue of Circuit Cellar Ink.  Mark's design is also 8031 based and
requires 24 chips, but in addition to closed captioning it also decodes
network time stamps, World System Teletext (WST), and North American Basic
Teletext Specification (NABTS).

Circuit Cellar also published in their May 1993 issue an article on the
Motorola MC68HC05CC1 chip, which is a single chip microcomputer specifically
designed for closed-caption decoding.

Standards

"Recommended Practice for Line 21 Data Service", ANSI/EIA-608-94, Sept. 1994

       Electronic Industries Accociation
       2500 Wilson Boulevard
       Arlington VA 22201

       American National Standards Institute
       11 West 42nd Street
       New York, NY 10036

"Television Captioning for the Deaf: Signal and Display Specifications"
Engineering Report No. E-7709-C
Public Broadcasting Service, May 1980

       Public Broadcasting Service
       1320 Braddock Place
       Alexandria, VA  22314

"Telecaption II Decoder Module Performance Specification"
National Captioning Institute, May 1985

       National Captioning Institute, Inc.
       5203 Leesburg Pike
       Falls Church, VA  22041

FCC Regulations:
       47 CFR 15.119
       47 CFR 73.699

'Simple code..'
1995\08\21@140908 by Stammnes V.G.S

flavicon
face
Can someone please tell me what these simple line of PIC16C84 code does :

MOVLW   067
MOVWF   10              : IS THIS SOME SPECIAL REGISTER OR RAM LOCATION ??
DECFSZ  10



tobias

1995\08\21@182500 by Brian Read

flavicon
face
MOVLW 067 : Move the literal 067 into the working register
MOVWF 10  : Move the working register to file 10 ( GP file in the '84)
DECFSZ 10 : Decrement the contents of file 10 and skip the next inst if the
         : zero flag is set by the decrement

To be correct the DECFSZ instruction should include the destination of the r
result:

DECFSZ   10,W
  or
DECFSZ   10,f

It defaults to f but.... (now, now Andy)

Happy bit fiddling,
Brian

'AN591 code ? (ADB interface)'
1995\08\28@074545 by Markus Imhof

flavicon
face
Hello,
I just downloaded AN591 - ADB from Microchip and was wondering if (and
where - URL?) the PIC code (and the Mac code ?) for that application are
available. It doesn't seem to be included in the .zip. Or would I just have
to take a few good looks at the flow diagram and go ahead ?

Bye
 Markus

1995\08\28@155904 by Doug Sellner

flavicon
face
>Hello,
>I just downloaded AN591 - ADB from Microchip and was wondering if (and
>where - URL?) the PIC code (and the Mac code ?) for that application are
>available. It doesn't seem to be included in the .zip. Or would I just have
>to take a few good looks at the flow diagram and go ahead ?
>
>Bye
>  Markus

DITTO!!!

Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410

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

Internet: spamBeGonedsellnerspam_OUTspamRemoveMEembay.com


'Docs and schematic for closed caption decoder'
1995\09\18@062320 by Eric Smith
flavicon
face
The schematics (in HPGL) and a theory of operation document for my PIC-based
closed caption decoder are now available in addition to the source code.
They may be downloaded from my PIC page.  The URL is now:
       http://www.spies.com/~eric/pic/

Cheers,
Eric

1995\09\19@233016 by Dave Russell

flavicon
face
>The schematics (in HPGL) and a theory of operation document for my PIC-based
>closed caption decoder are now available in addition to the source code.
>They may be downloaded from my PIC page.  The URL is now:
>        http://www.spies.com/~eric/pic/
>
>Cheers,
>Eric
>
>

I would like to build this unit Eric, could you tell me if there is a DOS
program to uncompress the GZ format.  I have tried a program called STEALTH
without any success.  Thanks for making your PIC expertise available to
those of us just starting to use these parts.

Thanks,

Dave Russell

'Sony IR Remote-Control Codes'
1995\09\20@034245 by Sten Dahlgren

flavicon
face
On Tue, 19 Sep 1995, Andrew Warren wrote:

> A while back, there was a discussion on Sony's IR remote-control
> formats.  Some helpful person posted a URL for the appropriate
> documents... Can someone please send me that URL in private e-mail?
>
Not answer to your specific question, but another pointer.

I have found some remote controller docs and code containing lots of info
on many remote controllers. the code is specific for hp48 but the info must
be useful.

I really dont remember the place where i found it but it must be some
hp48 related place, it was in sweden that i know for shure.
The file is named rem34bg.zip, you may try archie.

/Sten

--
Sten Dahlgren  CelsiusTech Systems   ! "I'd rather have 35 Hp under my arm
S-175 88 Jaerfaella      Sweden      ! than one under my backside"
.....sedaspamRemoveMEcelsiustech.se +46-8 58084430   ! join your nearest karting club now !!

'SONY IR-Codes, where to find.'
1995\09\21@070944 by Lotty

flavicon
face
Look at hemul.nada.kth.se (130.237.227.22)
I do not know the directory, but it was HP48 related.

Have fun!

  Lothar

'Debugging code without an ICE'
1995\09\21@234148 by ian smart

flavicon
picon face
At the moment I debug the difficilt problems in my PIC code by sending the
debug values as RS232 chars to my PC running Procomm and log the results.
While this works OK its slow to make changes.

What other techniques can be used in this debugging enviroment. I have never
seen a debug monitor used with PICS I gather the lack of ram and code space
restricts this type of debugging to the larger 8031 and 68hc11 type processors.

I would welcome any good suggestions on speeding up the debug cycle

Thanks



-------------------------------------------------------------------
Sender            Ian Smart
Location          Electronic Structure Of Materials Centre
                 Flinders University   Adelaide Australia
Email             ian.smartspam@spam@cc.flinders.edu.au
-------------------------------------------------------------------

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

'Debugging code without an ICE'
1995\09\26@191437 by mlk

picon face
On Fri, 22 Sep 1995, ian smart wrote:
>
> What other techniques can be used in this debugging enviroment.

Ian,

       I have been using a logic analyzer as the debugging tool for my
16C57 project.  I have some spare I/O so I output diagnostic codes to
flag the operation of individual segments of code.  I also output results
as needed so that I can check them.

       The logic analyzer is great because I can observe the external
events as well such as serial access to an A/D.  Logic analyzers are
expensive but I found an old Tektronics DAS 9100 for $300 in an
electronics salvage place.  I don't think they knew what they had.

Good Luck,

Martin Kirk
Arizona State University
EraseMEmlkRemoveMEspamSTOPspamasu.edu
(602) 582-5718

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

RemoveMEdivanovKILLspamspamTakeThisOuTplessey.co.za

'UART CODE'
1995\09\28@055056 by *DO_LATER

flavicon
picon face
I would appreciate it if anyone can send me some code to implement
the UART transmission on the PIC16C74 using software polling. I have
not been able to carry this out and would like to know what I have
done wrong.

Chris Holding

'p16C84 Code for VideoCrypt/D2MAC'
1995\09\28@094427 by Christopher

flavicon
face
If anybody has any code they wish to "exchange" for educational purposes..  I
have a growing library of it!  I am always looking for code with external
eeprom usage also.. twin pic, single pic, no problem!

Anything..  My interests are in VideoCrypt though with D2MAC also!


<spamBeGoneatvscs27spam@spam@email2.grafenwoehr.army.mil>>


'source code'
1995\10\16@131423 by Cheang Tak Meng, Felix
flavicon
face
I'm working on a digital alarm clock using 16C54 PIC IC. Do anyone of you
know the code. My criteria is a clock with alarm and input through push buttons.

1995\10\16@154123 by Falstaff

picon face
>
> I'm working on a digital alarm clock using 16C54 PIC IC. Do anyone of you
> know the code. My criteria is a clock with alarm and input through push
buttons.
>

How do you mean "I'm working on"?  You mean you want a shrink-wrapped
package you only need to solder together?

Frank

"Mutual respect, even if we disagree."
------------------------------------------------------------------------
Frank A. Vorstenbosch        +31-(70)-355 5241        RemoveMEfalstaffspam_OUTspamxs4all.nl

1995\10\16@175058 by Peter Jennings

picon face
> I'm working on a digital alarm clock using 16C54 PIC IC. Do anyone of you
> know the code. My criteria is a clock with alarm and input through push button
s.

There are two complete examples of clocks with alarms in Microchip's
Embedded Control Handbook. They are under the Multiplexing LEDs/
Keypad example, AN529. Probably available on their BBS or site, too.

Peter

--                                 peterjspamspamnetcom.com

'PICs and Rotary Encoders'
1995\10\18@095930 by Mike Goelzer

flavicon
face
       I would like to build a small odometer for a toy car.  The way I
plan to do this is to use a rotary encoder wheel that would rub along the
ground.  As the car
moved forward, the rotary encoder wheel would roll on the ground, and the
microprocessor would increment a counter of the distance traveled and display
it somehow.  My question is this, how accurate would this be?  In essence, I
would
hook the encoder wheel to some wheel that had a known circumference (say 1
cm) and then count the revolutions.  If I knew how many "clicks" (IOW,
changes in output) the encoder made per revolution, would it not be possible
to count these and increment a counter of centimeters traveled after each
revolution?  I have this nagging feeling that there is some flaw in this
idea that I haven't realized yet (especially since I've never worked with
encoders before).  If anyone has used a PIC + rotary encoder in a similar
application before, or sees some obvious flaw in the above logic that I'm
missing, please tell me.

Any comments on the feasibility idea would be appreciated.

Thanks.

-mike
--
Mike Goelzer
<spam_OUTmgoelzerspam_OUTspamspam_OUTus.net>

1995\10\18@112716 by Siegfried Grob

flavicon
face
Mike Goelzer wrote:


       I would like to build a small odometer for a toy car.  The way I
plan to do this is to use a rotary encoder wheel that would rub along the
ground.  As the car
moved forward, the rotary encoder wheel would roll on the ground, and the
microprocessor would increment a counter of the distance traveled and display
it somehow.  ...


My comments:

If you really want to use a rotary encoder you can find an application note
from/at parallax. I'm sorry, but I don't have the exact document name/number
available.

I would solve the problem in a cheaper, easier but less accurate way, which
seems to be still exact enough for toy applications. It is used in most
electronic speedometers for bicycles (at least in Germany).

Simply stick a litte magnet onto one of the rotating wheels and a reed-contact
(I'm not sure if this is the proper term, I mean these magnetically closed/
opened switches within a glass tube) at the chassis.
A PIC, preferrably a 16C84, will recognize one pulse for a complete revolution.
If you need data on the direction of driving, fix a second reed-contact next
to the first, and look which of the two contacts gave the first pulse with
the other pulse being delayed a bit.
The 16C84 can be operated in power-saving 'wake-up-on-keystroke' mode and the
accumulated driven distance can be permanently stored in the on-chip EEPROM.

Siggi

1995\10\19@040722 by m.d.simpson.bra0505

flavicon
face
I suggest when you make it, you by a cheapo mouse, and pull it
apart.  you'll have the led and detector, and the rotary
encoding wheel.  I think there's PIC software for a mouse in the
Microchip Databook, put basically all you need to do is find out
how many pulses there are to the CM (or better still a 1M for
accuracy), and divide the pulses by that to give distance.Mark

'PIC Mac-ADB code?'
1995\10\19@061302 by Ronald Leenes

flavicon
face
Microchip app note 591 describes how to hook up a PIC to the Apple Desktop
Bus. Does anyone know where to find the actual code for the PIC. I got no
reply from the writers of the code?

I would be very interested in building an I/O module interface for the Mac
via the ADB bus.
Anyone ever done this?



                                             Ronald

'Alarm Source Code (Help!!!!!!!)'
1995\10\19@122844 by Cheang Tak Meng, Felix

flavicon
face
To all users,

           I need to get a simple digital clock with alarm up and running
using a PIC16C54/56 as soon as possible. Ideally, the displays (7-Segment)
should be fully multiplexed with the input switches. The inputs are minutes
adjust, hour adjust, display alarm, alarm cancel. Further indicators are
colon flashing, AM/PM, alarm enabled/disabled (also via LED's). Microchips
application note AN529 is not suitable because it uses a 16C57, multiplexed
matrix keypad which is overly complicated.

Thanks

1995\10\19@130349 by Neil Gillies

flavicon
face
>To all users,
>
>            I need to get a simple digital clock with alarm up and running
>using a PIC16C54/56 as soon as possible. Ideally, the displays (7-Segment)
>should be fully multiplexed with the input switches. The inputs are minutes
>adjust, hour adjust, display alarm, alarm cancel. Further indicators are
>colon flashing, AM/PM, alarm enabled/disabled (also via LED's). Microchips
>application note AN529 is not suitable because it uses a 16C57, multiplexed
>matrix keypad which is overly complicated.
>
>Thanks
>

See all the stuff relating to ETI.

'PIC Mac-ADB code?'
1995\10\19@173606 by Chris Smolinski

flavicon
face
>Microchip app note 591 describes how to hook up a PIC to the Apple Desktop
>Bus. Does anyone know where to find the actual code for the PIC. I got no
>reply from the writers of the code?
>
>I would be very interested in building an I/O module interface for the Mac
>via the ADB bus.
>Anyone ever done this?
>
>
>
>                                              Ronald

Here's someone else who would be very interested in the same thing. I did
notice in one of the trade mags that Microchip sells a series of
micro-controllers for interfacing mice. One of them in for the Mac-ADB
port. I suspect that the code for this PIC would be most of what necessary
for interfacing to ADB.

I have the documentation from Apple that decribes the ADB bus and protocol.
I've just never had the time to "roll my own". I'd much prefer to start
with a working ADB interface and go from there.

Chris



----------------------------------------------------------------------------
|Check out my WWW page at http://www.access.digex.net/~cps/ for scientific   |
|software for the Mac, Free Radio, Shortwave Radio, and Spy Numbers Stations |
|information.                                                                |
|Finger me (cpsspam_OUTspamaccess.digex.net) for my PGP Public Key                      |
----------------------------------------------------------------------------

"Those who would sacrifice liberty for security deserve neither."
                      -Ben Franklin

'PICs and Rotary Encoders'
1995\10\20@202920 by Newfound Electronics

flavicon
face
>Mike Goelzer wrote,

>        I would like to build a small odometer for a toy car.  The way I
>plan to do this is to use a rotary encoder wheel that would rub along the
>ground.  As the car
>moved forward, the rotary encoder wheel would roll on the ground, and the
>microprocessor would increment a counter of the distance traveled and display
>it somehow.  My question is this, how accurate would this be?  In essence, I
>would

snip snip

{Quote hidden}

Mike,
         I have used a quadrature encoder with a PIC as a digital joystick.
The PIC generated a PWM output is simulate the anolog pot. Because of the
hign speed of the PICs and the bit testing instructions, the PICs are ideal
for this sort of work.

Here is my suggestion. Buy yourself a cheap mouse. Look at its specs. That
will tell you the distance per revolution. No Math required! Well actually,
for a single revolution, you must divide the count by four as the encoder is
quad-rate-ture. So I lied about the "no math" bit.

Actually, depending on the speed of the car you may need to gear down to the
encoder and use a 20Mhz PIC.

Rat the mouse?? and get the encoder section. Hook it up to the PIC, the
encoder outputs are at suitable levels.

For software, please see the mouse stuff in the embedded controller handbook
and also look at the parallax app notes as I seen something there using
quadrature encoders that appeared faster.

Of course with something like this, you will  have to  fiddle until your
fingers bleed to get it right. Have fun!

Regards

Jim Robertson


-----------------------------------------------------------------
NEWFOUND ELECTRONICS,  Makers of low cost,
mega featured PIC programming tools.
RemoveMEnewfoundKILLspamspam@spam@ne.com.au
------------------------------------------------------------------


'DTMF sample code to LCD'
1995\11\09@103803 by David G. Schmidt
flavicon
face
Check out the Sept 95 issue of Popular Electronics.  Terry Weeder of
Weeder technologies has done an article and sells such a unit cheaply,
kit form.  He has
interfaced a PIC to a serial EEprom and an lcd display with scrollback
buffers.  This issue is within the last year.  He used a 4 bit binary
output DTMF chip, but his code can be modified for your 2 of 8 output
chip.  BTW, does the chip have a selector for 4 bit binary out or 2 of 8?

--------------------------------------------
( Dave Schmidt       DSchmidt Technologies )
( dschmidtspamBeGonespam.....rain.org     Ventura, CA        )
( Own an FME? ->finger KILLspamdschmidtspam.....rain.org   )
--------------------------------------------

On Tue, 7 Nov 1995 spam_OUTJohn.P.HollingsheadspamKILLspamHAPPY.FIRSTNETHOU.COM wrote:

> I'm looking for code, pinouts etc for LCD matrix displays.

1995\11\09@130508 by David Brenegan

picon face
I was wondering if you could modify his design to use a 16c84
and have the dtmf chip and the lcd use some of the same
data lines and seperate enable lines? Does this seem possible
or would you potentially lose some dtmf tones comming in?
(I'm new at this stuff....).

Thanks.
_David

1995\11\10@023556 by adrian

flavicon
picon face
> I was wondering if you could modify his design to use a 16c84
> and have the dtmf chip and the lcd use some of the same
> data lines and seperate enable lines? Does this seem possible
> or would you potentially lose some dtmf tones comming in?
> (I'm new at this stuff....).


Hmmm.

Typical LCD - 4 data lines, R/W, E, RS       total 7 lines
Typical DTMF - 4 lines only, maybe five      lets say 4 lines
Serial EEPROM, clock and data                total 2 lines
                                             13 lines = 16C84

You could probably make it work without too much hassle.
I guess control control input keys, but DTMF could be used for this also.
You can use the EEPROM clock without a start condition as one of
the LCD lines (say RS) to free anothr line. This could be used with a diode
on the 4 LCD data lines to give a 4 key keypad.

piece of cake <-:

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

1995\11\10@055356 by Mike Keitz

flavicon
face
>I was wondering if you could modify his design to use a 16c84
>and have the dtmf chip and the lcd use some of the same
>data lines and seperate enable lines? Does this seem possible
>or would you potentially lose some dtmf tones comming in?
>(I'm new at this stuff....).
>
If the DTMF chip has an enable pin, then it can be used to share a bus with
the LCD, serial EEPROM, and other chips assuming they have enables as well.
Each chip needs a dedicated line back to the PIC to select it.  In a larger
system a decoder like a 74HCT138 could be used (unfortunately, the LCD,
93CXX, and most DTMF chips have active high enables, so an active-low
decoder wouldn't work well).  Data will not be lost since it only takes a
few microseconds to access each chip and go to the next one.  Also, many
DTMF chips latch the last tone code received until another one is detected.
I usually use the LCDs in the 4-bit mode to save PIC pins as well.

Using a bus like this, with none of the peripheral chips selected the PIC
pins can be used as inputs by driving them through resistors.  This could be
used for the 'tone detected' function from the DTMF chip as well as any user
controls that the project has.

Another note about this project, the HD44780-based LCD units have 80 bytes
of display RAM and 64 bytes of custom-character RAM, regardless of the size
of the screen.  Especially if the display is smaller than 80 characters, the
extra 128 bytes or so of RAM could be used for (volatile) scroll-back
storage instead of a serial EEPROM.  The specifications I have don't say how
much power the display units use with the display disabled though, it may
not be practical to 'sleep' them and keep the RAM alive if the
decoder/display is expected to retain the data for a long time.

-Mike

'Manchester Decodeing with a pic ??'
1995\11\13@112036 by PAUL

flavicon
picon face
Hi i want to decode manchester encoded signals with a pic chip is this possible
I have never programmed a pic chip before but have a 16c84 programmer and would
like to learn how to use it..

For those who do not know what manchester encoded signals are its where
a binary 1 is represented as 10 and 0 is 01 .
I am currently de-manchesteriseing a signal with a clock osc and a xor gate
and have ttl data in one side of the xor gate and the clock in the other.

I need to be in phase with the data stream for decodeing at the computer...


Any help or examples greatfully recieved ...


--
REGARDS PAUL.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i

mQCNAzBSGNEAAAEEAMlbTNvAO+qY8j6tRs/r+Ktu1jbuaWceP+H7fZGl1VVmCxm/
VQdGhFYcihIH/bFAGRs7kN4qK+aWcOlEgg4yiqGI/wvDiSeIagJ2Jbv4VLgUU5rO
6jwGAs36/YaZNRReAytpZevLoAdYC99EqGUgOET0LzfTI8FtU+CkpBZjI/SlAAUR
tChwYXVsIGQuIGJ1bG1lciA8cGF1bEBrZDZyZ2ouZGVtb24uY28udWs+
=YLQS
-----END PGP PUBLIC KEY BLOCK-----

'9600 baud @4MHz code is here'
1995\11\16@005311 by Newfound Electronics

flavicon
face
>
>>Julio,
>>Forwarded reply you requested.
>>P.S. You should be able to get 9600 baud @ 4Mhz without oscilliscopes or
>>much difficulty.
>
>   Thanks for the reply. But I would rather some code that really works. :)
>I'm hurry to finish my application. Thanks anyway.
>
>   Julio
>

Julio,

Sorry the code is not formated very well as had to port it from DOS into
windows and it scrambled everywhere!  This is what I used before and it is
based on the microchip application note, not the best but it worked. By
memory it worked well but the timings were not exact. No doubt others on the
PIC LIST will add and detract from it especially as it came from me.

Of course don't forget to change the processor type as needed.   I have
assembled it and there are no assembly errors but I have not tested it and
maybe I destroyed the code when I removed the peripherial features in the
"XMTW" routine.  I also had to make a small change the "SERIN" routine after
porting so this has not been tested by the assembler.

If you get stuck trying to get it to work, let me know and I'll see what I
can do.

Sorry for any mistakes in my English.

Regards,

Jim



;SERIAL ROUTINES 9600 BAUD @4MHz
;

list p=16c57


flags          equ     3       ; (Hang over from Z80 days!)
cntl_port  equ    7

c         equ     0       ; Carry Bit is Bit.0 of F3

                      org 08

rcvreg  res     1
xmtreg  res    1
count   res     1
dlycnt  res     1

baud_x  equ     .29
baud_4  equ     .43
baud_3  equ     .16
baud_2  equ     .33
baud_1  equ     .35
baud_y  equ     .31

dout       equ     3
din         equ     2

user         movlw   baud_3
              movwf   dlycnt
redo_2    decfsz  dlycnt
              goto    redo_2

serin
              clrf    rcvreg                ; clear all bits of rcvreg
              btfsc   cntl_port,din   ; check for a start bit
              goto    user                  ; delay for 104/2 us
              nop
              movlw   baud_4
              movwf   dlycnt
              decfsz  dlycnt
              goto $-1

              movlw   8               ; 8 data bits
              movwf   count
r_next     bcf     flags,c
              rrf     rcvreg
              btfsc   cntl_port,din
              bsf     rcvreg,7
              decfsz  count
              goto dlyy
              movlw baud_3         ;last half of last bit delay.
              goto save

dlyy        movlw   baud_y
              movwf   dlycnt
              decfsz  dlycnt
              goto $-1
              goto    r_next

xmtw      movwf   xmtreg
xmtr       movlw   8
              movwf   count
              bcf     cntl_port,dout       ; send start bit
              call    delay1
x_next     bcf     flags,c
              rrf     xmtreg
              btfsc   flags,c
              bsf     cntl_port,dout
              btfss   flags,c
              bcf     cntl_port,dout
delayx    movlw   baud_x
              call    save
              decfsz  count
              goto    x_next
              bsf     cntl_port,dout       ; send stop bit
              movlw   baud_x
              goto    save

delay1         movlw   baud_1
save             movwf   dlycnt
redo_1         decfsz  dlycnt
                   goto    redo_1
                   retlw   0

              end

1995\11\16@132936 by Paul Christenson [N3EOP]

flavicon
face
>Sorry the code is not formated very well as had to port it from DOS into
>windows and it scrambled everywhere!

>flags          equ     3       ; (Hang over from Z80 days!)
>cntl_port  equ    7
>
>c         equ     0       ; Carry Bit is Bit.0 of F3
>
>                       org 08

You probably would have been better off leaving the code in its        !
"scrambled" form.  If you are running Eudora under Windows, be         !
advised that by default it displays everything in a proportional       !
font.  You can change it to a "monospaced" font, and things will       !
line up properly.                                                      !
                                                                      !
As a test, the line to the right side of this message ------>          !
is (supposed to be) vertical.  If it isn't, either the editor I'm      !
using chopped off some spaces, or you are using a proportional font.   !
(However, it looks fine from here...)  Could someone tell me if it     !
is or not?  Thanks...                                                  !
                                                                      !
Paul                                                                   !

1995\11\16@194009 by Newfound Electronics

flavicon
face
>You probably would have been better off leaving the code in its        !
>"scrambled" form.  If you are running Eudora under Windows, be         !
>advised that by default it displays everything in a proportional       !
>font.  You can change it to a "monospaced" font, and things will       !
>line up properly.                                                      !
>                                                                       !
>As a test, the line to the right side of this message ------>          !
>is (supposed to be) vertical.  If it isn't, either the editor I'm      !
>using chopped off some spaces, or you are using a proportional font.   !
>(However, it looks fine from here...)  Could someone tell me if it     !
>is or not?  Thanks...                                                  !
>

Thanks for that info Paul, it will be very useful in the future.

Your line was all over the place but half a bottle of  scotch will
straighten it out nicely (until the morning anyway.  Well maybe the
monospaced font is a better choice. :-)

Remember, if anyone fines it doesn't work let me know and I'll fix it, ok?
It certainly worked reliably for me.

Regards

Jim

P.S.  For some reason my email is starting  at message 2 when I collect it.
I will get this fixed but in the meantime if someone has sent email and I
haven't replied in 24 hours max, this is why.

-----------------------------------------------------------------
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 RemoveMEnewfoundRemoveMEspamEraseMEne.com.au
------------------------------------------------------------------

1995\11\21@064515 by John W. Gutmann

flavicon
face
"Paul Christenson [N3EOP]" <km4ba!kd4nc!emory!PSUVM.PSU.EDU!PJC130> writes:

> >windows and it scrambled everywhere!
> (However, it looks fine from here...)  Could someone tell me if it     !
> is or not?  Thanks...                                                  !
>                                                                        !
> Paul                                                                   !

Paul,
   I received your mail and I am using 80 col screen, with
mono spaced font.    The line was vertical and straight up
in the same column.
   John W. Gutmann



--
__   _  _  _  _   John W. Gutmann  -  SYSOP -  Robots R4U BBS - 404-978-7300
|__)  |__|  |  |   KILLspamjohn.gutmannspamspamBeGonerobot4u.atl.ga.us              INTERNET EMAIL
|  \     |  |__|   ROBOT HOBBY; The Complete Manual for Individuals and Clubs
__    __    __    R.E.A.L. - Robot Experimenter Amateur League - Atlanta, GA
|__)  |__)  (__    ROBOTS R4U BBS -  P.O. Box 2050  - Stn. Mtn., GA  -  30086
|__)  |__)   __)   Voice 404-972-7082  Ans Machine  -  FAX 404-979-3660,,,,11

1995\11\21@064515 by John W. Gutmann

flavicon
face
"Paul Christenson [N3EOP]" <km4ba!kd4nc!emory!PSUVM.PSU.EDU!PJC130> writes:

> >windows and it scrambled everywhere!
> (However, it looks fine from here...)  Could someone tell me if it     !
> is or not?  Thanks...                                                  !
>                                                                        !
> Paul                                                                   !

Paul,
   I received your mail and I am using 80 col screen, with
mono spaced font.    The line was vertical and straight up
in the same column.
   John W. Gutmann



--
__   _  _  _  _   John W. Gutmann  -  SYSOP -  Robots R4U BBS - 404-978-7300
|__)  |__|  |  |   john.gutmannspamspamrobot4u.atl.ga.us              INTERNET EMAIL
|  \     |  |__|   ROBOT HOBBY; The Complete Manual for Individuals and Clubs
__    __    __    R.E.A.L. - Robot Experimenter Amateur League - Atlanta, GA
|__)  |__)  (__    ROBOTS R4U BBS -  P.O. Box 2050  - Stn. Mtn., GA  -  30086
|__)  |__)   __)   Voice 404-972-7082  Ans Machine  -  FAX 404-979-3660,,,,11

'Wake and Sleep code for 84 device'
1995\11\27@091011 by Mike Barrett

flavicon
face
Has anyone got any simple code that I can 'borrow' to make a '84 wake up
from sleep mode when an input changes state? I also want some code to put
the device back into sleep mode.

The application? Well I want to build my daughter an electronic gadget  for
christmas. Press a button and lights come on, the thing beeps and then
switches off !

Any help much appreciated!

Mike Barrett
=============================================
Mike Barrett                E-mail: RemoveMEbarrettspamBeGonespamRemoveMEcambridge.scr.slb.com
Schlumberger Cambridge Research      Phone: 01223 325200
PO Box 153, Cambridge, CB3 OHG. U.K    Fax: 01223 327019
=============================================

1995\11\27@115411 by Mike Barrett

flavicon
face
(Sending again as the first attempt seemed to have been rejected by the
listserver)

Has anyone got any simple code that I can 'borrow' to make a '84 wake up
from sleep mode when an input changes state? I also want some code to put
the device back into sleep mode.

The application? Well I want to build my daughter an electronic gadget  for
christmas. Press a button and lights come on, the thing beeps and then
switches off !

Any help much appreciated!

Mike Barrett
=============================================
Mike Barrett                E-mail: KILLspambarrettspamBeGonespamcambridge.scr.slb.com
Schlumberger Cambridge Research      Phone: 01223 325200
PO Box 153, Cambridge, CB3 OHG. U.K    Fax: 01223 327019
=============================================

1995\11\27@143422 by Scott Stephens

picon face
>Has anyone got any simple code that I can 'borrow' to make a '84 wake up
>from sleep mode when an input changes state? I also want some code to put
>the device back into sleep mode.

       ORG     H'000'          ;Reset vector for 16C84 PIC's
       btfsc   STATUS,_PD      ;
       goto    Star1
       goto    Star2

       ORG     H'004'          ;Interrupt vector
       goto    ISR

       ORG     H'005'
Star1   btfsc   STATUS,_TO
       goto    PwrUp           ;Power-up condition, TO & PD = 1
       goto    X_Init          ;WDT time-out, not sleep T0=0, PD=1
Star2   btfss   STATUS,_TO
       goto    Wake_up         ;WDT time-out, sleep T0=0, PD=0

Wake_up sleep

Check page 2-543 of the 94 databook for explanation of the TO and PD Status
bits., and the "SLEEP" instruction. PortB and INT interrupts will wakeup the
processor as well as a watch-dog timer time-out. Execution may start at the
ISR vector H'004' or elsewhere, depending on how the interrupts are configured.

1995\11\28@032313 by SONY-OD

flavicon
face
On Mon, 27 Nov 1995, Mike Barrett wrote:

>Has anyone got any simple code that I can 'borrow' to make a '84 wake up
>from sleep mode when an input changes state? I also want some code to put
>the device back into sleep mode.

This is sample code: " how to sleep and wake-up with portB"

Port B is able to wake up from sleep mode on a change state on its pin:
PB4, PB.5, PB.6 or PB.7,


There is to way to get out from sleep mode:
   - by an interrupt routine (GIE=3D1)
   - by an event (GIE=3D0)

1=B0/ Just configure PB4..PB7 as input for example:=20
       PB4 and PB.7, PB.5 and PB.6 are output

2=B0/ Make a read of port B to latch value,

3=B0/ Set RBIF bit to enable interrupt on portB change

4=B0/ go in sleep mode


--------------------------------
*** A/ Wake-up with interrupt

; before, be sure RBIF is not active, RBIE is not set, bank 0 is activated
; don't forget RBPU bit to set pull-up on or off (depend your hardware)

      org 0            ; RESET VECTOR
      goto start

      org 4            ; INTERRUPT VECTOR
      bcf INTCON,RBIE
      movf PORTB,W
      bcf INTCON,RBIF
      retfie


start: bsf   STATUS,RP0 ; STATUS address =3D 03h (or 83h), RP0 =3D STATUS.5
                       ; SWITCH to bank 1 (register 80h to FFh)
      movlw 090h       ; PB7 PB6 PB5 PB4 PB3 PB2 PB1 PB0
                       ;  in  out out in out out out out
      movwf TRISB      ; TRISB address =3D 86h

      bcf   STATUS,RP0 ; STATUS address =3D 03h (or 83h), RP0 =3D STATUS.5
                       ; SWITCH to bank 0 (register 00h to 7Fh)

      movf  PORTB,W    ; Read PORTB (PortB address =3D 03h)

      movlw 088h       ; GIE =3D 1 and RBIE =3D 1
      movwf INTCON     ; INTCON address =3D 0Bh

      sleep            ; ENTER SLEEP MODE, low power, no oscillator =20
      nop              ; after sleep instruction, at the wake up the next
instruction is executed before jumping to the INT vector

;   .... program will continue after wake-up and interrupt
      goto start

--------------------------------
*** B/ Wake-up without interrupt

; Another way is to skeep interrupt routine and use only PORTB wakeup
      org 0            ; RESET VECTOR
      goto start


start: bsf   STATUS,RP0 ; STATUS address =3D 03h (or 83h), RP0 =3D STATUS.5
                       ; SWITCH to bank 1 (register 80h to FFh)
      movlw 090h       ; PB7 PB6 PB5 PB4 PB3 PB2 PB1 PB0
                       ;  in  out out in out out out out
      movwf TRISB      ; TRISB address =3D 86h

      bcf   STATUS,RP0 ; STATUS address =3D 03h (or 83h), RP0 =3D STATUS.5
                       ; SWITCH to bank 0 (register 00h to 7Fh)

      movf  PORTB,W    ; Read PORTB (PortB address =3D 03h)

      movlw 008h       ; GIE =3D 0 and RBIE =3D 1, NO INTERRUPT
      movwf INTCON     ; INTCON address =3D 0Bh

      sleep            ; ENTER SLEEP MODE, low power, no oscillator =20
      nop              ; after sleep instruction, at the wake up
                       ; no interrupt is fetched due to GIE=3D0

      bcf INTCON,RBIE  ; clear no match  condition
      movf PORTB,W
      bcf INTCON,RBIF


;   .... program will continue after wake-up=20
      goto start



Regards,  =20
            Philippe.


'CORRECTION: ultrasonic xducer code.'
1995\12\06@194036 by Rolan
flavicon
face
Paulh has brought a very important point to my attention.

The code which I had recently posted may operate with a 4 mHz
crystal instead of the 1 mHz which I had stated in the previous message.

Sorry.

'code protection for 16C6X/7X'
1995\12\21@130623 by Dr Ben Heller

flavicon
face
I'm trying to program a windowed PIC 16C73 using a home-made programmer.
The  code protection bits seem to be set (configuration word reads 3FCF)
and I can't find a way to turn them off.  I've tried zapping the chip in
a UV eraser for over an hour without any success.  I'm aware that the
configuration has to be pretty robust for security reasons, but this
seems excessive.  Is there something else I should be doing?

I'm sure this question has a trivial answer, but I can't find it in the
data books.

Thanks for any assistance.

Ben Heller

1995\12\21@140554 by Brian Read

flavicon
face
You may have to zap them for another hour. I
guess the idea is that you don't set code protect
unless you really mean it. Others on the list and
the MCHIPBBS have reported loooooooong erase times
for the code protect bit in the '7X parts, up to 2
hours.

Brian

'My Code for Playing Tunes on a 16C84'
1995\12\31@105509 by Myke Predko

flavicon
face
Hi Gang,

My reader has been flooded (with about 60 notes) in the past three days with
requests for the tune code.  I guess there's some interest in it.  So, I've
spent a few hours, cleaning everything up and making sure it works properly
(actually, I only found one major error where F# was actually using D#'s value).

The hardware required is a PIC16C84 running at 1MHz (Using a crystal) and
driving a 0.47uF cap and Piezo-Speaker in series connected to RA0 and Vcc.

Now, looking at it, I could put all the source in a note and beam it off.
The problem is, the note would be roughly 2K Lines Long.

I don't really want to do this because I'm sure I'll be swamped with
requests for compiling the "C" Code (I don't think that many people are
using the old IBM "C/2" Compiler Version 1.10), so I would like to send out
that code as .EXE's and avoid all the questions about how to compile the code.

Does anybody have an ftp site I could dump the exe's, docs, and sample
tunes?  I'm also interested in finding out what people want in the package,
so after reading this note, if you feel there's something that you feel
should be added, please let me know or forever hold your peace.

What I am proposing to put in the package:

1.  A (very) brief Description of how everything works.

2.  The NOTES.EXE Program.  This Program produces Counter Values for the
various notes, their frequencies and durations (for 1/eigth, 1/quarter,
3/eigths, 1/half, 3/quarters, 4/quarters) for user specified beats per
minute.  The program is designed for a clock frequency of 1MHz.  It could be
changed for different frequencies, I just don't know if I'm that energetic.
NOTES.EXE produces NOTES.FYL which is a set of Equates for the SOUND.ASM
Source and SOUND.FYL Program.  NOTES.EXE produces Notes from the "A" below
middle "C" to the "D" One Octave above middle "C".  Again, I don't know how
energetic I am in increasing the note range and I don't know how high I can
go with the current Interrupt Handler (I did cut it down from the original
"FROSTY" Application) - maybe two or three more notes.  Sharps of all the
notes are included (if ya want a flat, go to the Sharp).  Just for the
purists out there; none of the frequencies are off from their respective
notes by more than 0.3%.

3.  The MUSICMKR.EXE Program.  This Program takes a tune input file
(Basically the note and the duration) and converts it into Assembler Table
Routines.  The Table Routines Produced can ONLY be used in the SOUND.ASM
Source.  MUSICMKR produces a *.FYL file, where "*" is the name of the Tune
Source File (Defaulting to type ".SRC").  The *.FYL file should be renamed
to SOUND.FYL before SOUND.ASM is Assembled.  MUSICMKR can be thought of as a
(very) simple compiler.

4.  SOUND.ASM Source.  This is the shell that sets up the Timer and the
Interrupts and plays the tune.  The tune stops when a note with a timer
value of "0" is encountered and starts playing over.  The code was produced
using a compiler I have written.  I am not willing to distribute the
compiler at this time (largely because there are a lot of problems with it I
have to debug).  Having said this, the code produced is quite efficient,
although there are two source statements which have 16 bit operations which
would be hard to understand.  SOUND.ASM calls in two include files,
NOTES.FYL and SOUND.FYL, which are the Notes and Duration Equates and the
Tune Tables, respectively.  SOUND.ASM should be compiled using MPASM, NOT MPALC.

5.  Sample Tunes.  I'll go through my kid's basic piano books and make up a
few sample tunes for the program.

That's about it.  When we have concensus on how the code should be
distributed I'll send it out.

Have a great New-Year!

Myke


'Sony I/R Receiver Code'
1996\03\13@102034 by myke predko
flavicon
face
                      =20
Hi Folks,

I got a version of the Sony InfraRed Receiver running.  I've copied in the
Source (my PIC Language) Code below because it is very similar to
pseudo-Code and the actual assembler code is a couple of hundred lines long.

The basic idea is to wait for a low transition, then time it (waiting a
little more than 2.5 ms) and then wait for the data (a high of 500 us
followed by a low either 700 us (a "0") or 1,300 us (a "1")).  Twelve Bits
are read.  If at any time during the read, a timeout occurs (ie data doesn't
come by the time it is expected), everything is thrown out and a new
high-to-low transition is waited for.

The mainline of the program simply loops around, waiting for the hardware
register to change and then outputs the bits read in.

To develop the code, four programs were written for a 16C84:

IRTEST1 - Flash an LED at a specific port.  Basically make sure the PIC is=
wired
Correctly to run.
IRTEST2 - Poll on RB0 and lite the LED when the I/R Rx'r line goes low.
IRTEST3 - Wait for RB0/INT to go low from the I/R Rx'r and Toggle the LED
IRTEST4 - Handle All I/R data coming in, if Valid Sony Format, output Bits

The PIC is run at 1Mhz, at 5 Volts, using a 40 KHz I/R Rx'r powered thru a
100 Ohm Resistor and 10 uF Cap in Parallel (as suggested earlier in the
PICList).  LED Digital output is through a 200 Ohm Resistor and LED with
it's anode attached to VCC.

Before actually trying out the code on hardware, I did a lot of work
simulating it.  The actual result was, after programming the PIC, the
program ran first time (much to my surprise).  If the ordering of the
conditions looks a little funny, I had to re-order the code a number of
times to ensure that the code would execute for all conditions without
taking so long as a transition would occur.  The actual timer values were
computed and checked empirically on the Simulator, by making them the last
instruction before returing from the Interrupt and adding 10 to the values
expected, they worked out fine.

In terms of actual testing, All I have done is run it and checked it with my
Sony stereo remote control.  I haven't recorded what each button does yet.
I have tried it out with different I/R Remotes (Panasonic TV/VCR and RCA
DSS) with the Sony running and I was surprised that the code/PIC were able
to find and decipher the Sony Commands.  I still haven't done a good
characterization of the field of view of the sensor, although with our
warmer weather, I should be able to do it in a couple of days from now.  The
only surprise I've received is that in the "Electronics Now" Article, it
seems to show that the 5th last bit (first bit of the trailer) is a one, I
seem to always get a zero.

One question I have is, what are the format other brands I/R remote
controls?  I'm wondering if this code could be used to read different brands
simply by changing the bit count and the timer intervals.  Does anybody have
any comments?

Probably the next thing I will do is create "IRTEST5", which will ONLY
measure the Low-to-High Transitions and see if it has the same
discrimination of IRTEST4.  Stay tuned...

Myke


Here's the IRTEST4 pseudo-Code:

;  IRTEST4 - Let's See if we can Read the Input Values
;
;  In this program, both the Timer and the Interrupt Pin is Used to receive=
and
;  validate the source.  Valid Data is output on RB7-1 and RA4-0 for the 12
;  bits.
;
;  Myke Predko
;  96.03.11
;


;  PIC Definitions
IM 16C84.DEF                    ;  Execute on a PIC16C84
OSC XT                          ;  Use a crystal oscillator

FR 10000000                     ;  Run at 1Mhz


;  Global Variables
bits  REG16 -1                  ;  Watch for the Expected Bits
tbits REG16 0                   ;  Temporary Value for "Bits"
state REG   0                   ;  Set for What we're Waiting for
count REG   0                   ;  Count How Many Bits we have


;  IRTEST4 Mainline
 porta =3D 0x01F                 ;  Make Sure the LEDs are off
 portb =3D 0x0FF
 trisa =3D 0                     ;  Allow output on all the Bits except=
RB0/INT
 trisb =3D 1                    =20

 option =3D ( option & 0x090 ) + 2   ;  Interrupt on Falling Edge of=
INT/RB0 Pin
                               ;  AND Setup the Timer to Use Internal=
Clock/8
 intcon =3D 0x090                ;  Enable the "INT" Input Bit

 while 1                       ;  Loop Around Forever
   if bits !=3D -1               ;  Then Something was Read in
     porta =3D bits & 0x01F
     portb =3D bits >> 4         ;  Display the High 12 Bits
     bits =3D -1                 ;  Reset Bits for the Next Command

;  END IRTEST4 Mainline


INT                             ;  Interrupt Handler

 if intcon & 2                 ;  Only if we have the Downward Interrupt
   if state =3D=3D 1               ;  Then, we have the Start of a "1"
     option =3D option & ( 0x040 ^ 0x0FF )  ;  Now, Look for the Falling=
Edge
     if count =3D=3D 0             ;  Then, We're Just Setting Up
       count =3D 12              ;  Get the Number of Bits to Handle
       state =3D 2               ;  Set the Proper Next State
       intcon =3D 0x030          ;  Waiting for Timer/Int Key
       tmr0 =3D 0x0FF - 18
     else                      ;  Else, we have a bit, Continue
       tbits =3D tbits << 1      ;  Move over the value
       if tmr0 > 220           ;  We have read a "1"
         tbits =3D tbits + 1
       count =3D count - 1
       if count                ;  Now, Just wait for Interrupt
         intcon =3D 0x030
         state =3D 2             ;  Now, Just Flip Around
         tmr0 =3D 0x0FF - 18     ;  Now, Set the Timer for Repeating
       else                    ;  Else, Just Save the Value
         bits =3D tbits          ;  Save the value
         tbits =3D 0
         state =3D 0
         intcon =3D 0x010
         tmr0 =3D 0x0FF - 18     ;  Now, Set the Timer for Repeating
   else                        ;  State =3D 2 (High to Low Transition)
     option =3D option | 0x040   ;  Now, Look for the Rising Edge
     intcon =3D 0x030            ;  Just Wait for the Proper Interrupts
     if state =3D=3D 0             ;  Then, we have the first bit
       tmr0 =3D 0x0FF - 88       ;  Set the Timer for Timeout
     else                      ;  State =3D=3D 2=7F
       tmr0 =3D 0x0FF - 61       ;  Reset the Timer for High/Low
     state =3D 1                 ;  Change the State
 else
   if intcon & 4               ;  ERROR - Time Out on a Value
     state =3D 0                 ;  Reset Everything and Wait some More
     tbits =3D 0
     count =3D 0
     option =3D option & 0x0BF   ;  Looking for a Low Transition
     intcon =3D 0x010            ;  Just wait for a Low Transition
   else                        ;  Some Spurious Interrupt
     intcon =3D intcon & 0x030   ;  Just Set Expected Bits

END                             ;  End the IRTEST4 Interrupt Handler

1996\03\13@130252 by myke predko

flavicon
face
                                      =20
Hi Folks,

Sorry if this is coming through twice, I think it didn't get through the
first time, so I'm resending it.

I got a version of the Sony InfraRed Receiver running.  I've copied in the
Source (my PIC Language) Code below because it is very similar to
pseudo-Code and the actual assembler code is a couple of hundred lines long.

The basic idea is to wait for a low transition, then time it (waiting a
little more than 2.5 ms) and then wait for the data (a high of 500 us
followed by a low either 700 us (a "0") or 1,300 us (a "1")).  Twelve Bits
are read.  If at any time during the read, a timeout occurs (ie data doesn't
come by the time it is expected), everything is thrown out and a new
high-to-low transition is waited for.

The mainline of the program simply loops around, waiting for the hardware
register to change and then outputs the bits read in.

To develop the code, four programs were written for a 16C84:

IRTEST1 - Flash an LED at a specific port.  Basically make sure the PIC is=
wired
Correctly to run.
IRTEST2 - Poll on RB0 and lite the LED when the I/R Rx'r line goes low.
IRTEST3 - Wait for RB0/INT to go low from the I/R Rx'r and Toggle the LED
IRTEST4 - Handle All I/R data coming in, if Valid Sony Format, output Bits

The PIC is run at 1Mhz, at 5 Volts, using a 40 KHz I/R Rx'r powered thru a
100 Ohm Resistor and 10 uF Cap in Parallel (as suggested earlier in the
PICList).  LED Digital output is through a 200 Ohm Resistor and LED with
it's anode attached to VCC.

Before actually trying out the code on hardware, I did a lot of work
simulating it.  The actual result was, after programming the PIC, the
program ran first time (much to my surprise).  If the ordering of the
conditions looks a little funny, I had to re-order the code a number of
times to ensure that the code would execute for all conditions without
taking so long as a transition would occur.  The actual timer values were
computed and checked empirically on the Simulator, by making them the last
instruction before returing from the Interrupt and adding 10 to the values
expected, they worked out fine.

In terms of actual testing, All I have done is run it and checked it with my
Sony stereo remote control.  I haven't recorded what each button does yet.
I have tried it out with different I/R Remotes (Panasonic TV/VCR and RCA
DSS) with the Sony running and I was surprised that the code/PIC were able
to find and decipher the Sony Commands.  I still haven't done a good
characterization of the field of view of the sensor, although with our
warmer weather, I should be able to do it in a couple of days from now.  The
only surprise I've received is that in the "Electronics Now" Article, it
seems to show that the 5th last bit (first bit of the trailer) is a one, I
seem to always get a zero.

One question I have is, what are the format other brands I/R remote
controls?  I'm wondering if this code could be used to read different brands
simply by changing the bit count and the timer intervals.  Does anybody have
any comments?

Probably the next thing I will do is create "IRTEST5", which will ONLY
measure the Low-to-High Transitions and see if it has the same
discrimination of IRTEST4.  Stay tuned...

Myke


Here's the IRTEST4 pseudo-Code:

;  IRTEST4 - Let's See if we can Read the Input Values
;
;  In this program, both the Timer and the Interrupt Pin is Used to receive=
and
;  validate the source.  Valid Data is output on RB7-1 and RA4-0 for the 12
;  bits.
;
;  Myke Predko
;  96.03.11
;


;  PIC Definitions
IM 16C84.DEF                    ;  Execute on a PIC16C84
OSC XT                          ;  Use a crystal oscillator

FR 10000000                     ;  Run at 1Mhz


;  Global Variables
bits  REG16 -1                  ;  Watch for the Expected Bits
tbits REG16 0                   ;  Temporary Value for "Bits"
state REG   0                   ;  Set for What we're Waiting for
count REG   0                   ;  Count How Many Bits we have


;  IRTEST4 Mainline
 porta =3D 0x01F                 ;  Make Sure the LEDs are off
 portb =3D 0x0FF
 trisa =3D 0                     ;  Allow output on all the Bits except=
RB0/INT
 trisb =3D 1                    =20

 option =3D ( option & 0x090 ) + 2   ;  Interrupt on Falling Edge of=
INT/RB0 Pin
                               ;  AND Setup the Timer to Use Internal=
Clock/8
 intcon =3D 0x090                ;  Enable the "INT" Input Bit

 while 1                       ;  Loop Around Forever
   if bits !=3D -1               ;  Then Something was Read in
     porta =3D bits & 0x01F
     portb =3D bits >> 4         ;  Display the High 12 Bits
     bits =3D -1                 ;  Reset Bits for the Next Command

;  END IRTEST4 Mainline


INT                             ;  Interrupt Handler

 if intcon & 2                 ;  Only if we have the Downward Interrupt
   if state =3D=3D 1               ;  Then, we have the Start of a "1"
     option =3D option & ( 0x040 ^ 0x0FF )  ;  Now, Look for the Falling=
Edge
     if count =3D=3D 0             ;  Then, We're Just Setting Up
       count =3D 12              ;  Get the Number of Bits to Handle
       state =3D 2               ;  Set the Proper Next State
       intcon =3D 0x030          ;  Waiting for Timer/Int Key
       tmr0 =3D 0x0FF - 18
     else                      ;  Else, we have a bit, Continue
       tbits =3D tbits << 1      ;  Move over the value
       if tmr0 > 220           ;  We have read a "1"
         tbits =3D tbits + 1
       count =3D count - 1
       if count                ;  Now, Just wait for Interrupt
         intcon =3D 0x030
         state =3D 2             ;  Now, Just Flip Around
         tmr0 =3D 0x0FF - 18     ;  Now, Set the Timer for Repeating
       else                    ;  Else, Just Save the Value
         bits =3D tbits          ;  Save the value
         tbits =3D 0
         state =3D 0
         intcon =3D 0x010
         tmr0 =3D 0x0FF - 18     ;  Now, Set the Timer for Repeating
   else                        ;  State =3D 2 (High to Low Transition)
     option =3D option | 0x040   ;  Now, Look for the Rising Edge
     intcon =3D 0x030            ;  Just Wait for the Proper Interrupts
     if state =3D=3D 0             ;  Then, we have the first bit
       tmr0 =3D 0x0FF - 88       ;  Set the Timer for Timeout
     else                      ;  State =3D=3D 2=7F
       tmr0 =3D 0x0FF - 61       ;  Reset the Timer for High/Low
     state =3D 1                 ;  Change the State
 else
   if intcon & 4               ;  ERROR - Time Out on a Value
     state =3D 0                 ;  Reset Everything and Wait some More
     tbits =3D 0
     count =3D 0
     option =3D option & 0x0BF   ;  Looking for a Low Transition
     intcon =3D 0x010            ;  Just wait for a Low Transition
   else                        ;  Some Spurious Interrupt
     intcon =3D intcon & 0x030   ;  Just Set Expected Bits

END                             ;  End the IRTEST4 Interrupt Handler

1996\03\13@155736 by David Harmon

picon face
On Wed, 13 Mar 1996, myke predko wrote:
>
> One question I have is, what are the format other brands I/R remote
> controls?

See ftp://hemul.nada.kth.se/home/d89-bga/hp/files/remote/remotes/

''65 as LCD driver-need code!'
1996\03\27@072039 by Moshe Fish

flavicon
face
Does anyone know of any shareware or code for the '65 that is available to drive
an 8 digit LCD with 3 backplanes. Has anyone got experience in this. I am
pressed for time and would even be willing to pay for it (provided it was a
reasonable amount).
-------------------------------------
Name   :Moshe Fish
E-mail :@spam@mfishSTOPspamspam@spam@netvision.net.il
Date   :03/27/96
Time   :14:33:12

'Error parsing in CodeWright'
1996\03\29@001333 by Ed VanderPloeg

flavicon
face
      Anyone out there successfully parsing the output from mpasm
      and/or mpasmwin when called from CodeWright (preferably version
      4.0)?  I've got both of the compilers to run just fine, and I
      think it's checking out the output file for errors, but the
      result is always "No Errors Found", even when I generate a
      truckload of them.  I'm using the latest errparse.dll, dowloaded
      from the Premia ftp site, and tried both the _MPAsmErrorInfo and
      the _MPAsmLSTErrorInfo parsers to checkout the .err and .lst
      files, respectively.  (...Andy?)

      -Ed VanderPloeg

1996\03\29@005732 by Andrew Warren

face
flavicon
face
Ed VanderPloeg <PICLISTspamBeGonespamspamBeGoneMITVMA.MIT.EDU> wrote:

> Anyone out there successfully parsing the output from mpasm and/or
> mpasmwin when called from CodeWright (preferably version 4.0)?
> I've got both of the compilers to run just fine, and I think it's
> checking out the output file for errors, but the result is always
> "No Errors Found", even when I generate a truckload of them. I'm
> using the latest errparse.dll, dowloaded from the Premia ftp site,
> and tried both the _MPAsmErrorInfo and the _MPAsmLSTErrorInfo
> parsers to checkout the .err and .lst files, respectively.
> (...Andy?)

Yeah, Ed... I'm probably a good person to ask, since I convinced the
guys at Premia to make those error-parsers available in the first
place.

When MPASM's error-formatting changed, those parsers broke.  I
haven't written a new one, but I'm sure a quick note to Premia's BBS
will get a new parser written.  Send them a sample of the .ERR and
.LST file output, preferably showing errors, warnings, and messages.

If you get no satisfaction from them, let me know and I'll write a
parser.  Unfortunately, I'm sorta pressed for time right now, so it
may be a while before I can do one.

-Andy

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


'Pic code protection alert!'
1996\04\04@174417 by Dennis Velthuis
flavicon
face
Hello pic users.

I have posted a message here some time ago about someone claiming to be
able to unprotect any '84 with a device called the picbuster II.
Now I read in alt.satellite.tv.europe that the picbuster III is coming.
I haven't heard any details about this device yet.

But what about the other pic's???

I was very surprised to read the following message some days ago in the
alt.cellular newsgroup ...

>>SERVICE THAT IS NOW  100% WORKING WE CAN GUARANTEE THAT
>>WE CAN READ ANY PIC16/C54 PIC16/C55 PIC16/C56 PIC16/C71 PIC16/84
>>WITH THE LOCK BIT ENABLED WE DONT EMULATE THE CODE WE GO STRAIGHT IN TAKE
>>THE LOCK BIT OF AND READ THE CODE OUT IN HEX
>>FORMAT IF YOU ARE INTRESTED IN THIS SERVICE AND PRICES PLEASE
>>EMAIL THANKS...

*glunk*, ANY pic? Wow, that's quite a claim!
Well, being curious I mailed the poster of the message asking some details
about this service and this is his answer ...

>>Hello i cant tell you how its done but we can read the pics with no problem
>>at all
>>the service costs $2000 for a pic54   and $2300 for abouth ie 56 71 ect
>>and ther is no hard ware avalible for sale to do it...
>>if you want any more info call ..
   <details deleted>

Now this makes me wonder. Is this really possible?
Pic's are used in many commercial products and I would assume that many
people don't want their pic code being read out.

I don't know if this is a serious claim, you might never know.
(well, he did mention the company's name and tel/fax number)

I think you all should be aware of the fact(?) that someone (maybe) can
read the code out of your product.

I hope someone can shed some light on this matter.
Let's solve this 'mystery' once and for all. :-)


Bye!

D. Velthuis

--
****************************************************************************
*             -= Dennis Velthuis =-    -= spam_OUTdenvSTOPspamspamhtsa.hva.nl =-              *
*                 -= Raving His Way Into Tha Future ;) =-                  *
*                   -= http://htsa.htsa.hva.nl/~denv =-
*     -= U Have The Right to Exchange Information, So Use This Right! =-   *
****************************************************************************

1996\04\05@044215 by Otto Tronarp

flavicon
face
At 00.43 1996-04-05 METDST, you wrote:
>Hello pic users.
>
>I have posted a message here some time ago about someone claiming to be
>able to unprotect any '84 with a device called the picbuster II.
>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>I haven't heard any details about this device yet.

I have a program called picbust. I don't have a pic programmer so I don't
know if it works but if some one want it I could post it to the list.

Regards Otto

1996\04\05@044215 by Otto Tronarp

flavicon
face
At 00.43 1996-04-05 METDST, you wrote:
>Hello pic users.
>
>I have posted a message here some time ago about someone claiming to be
>able to unprotect any '84 with a device called the picbuster II.
>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>I haven't heard any details about this device yet.

I have a program called picbust. I don't have a pic programmer so I don't
know if it works but if some one want it I could post it to the list.

Regards Otto

1996\04\05@044215 by Otto Tronarp

flavicon
face
At 00.43 1996-04-05 METDST, you wrote:
>Hello pic users.
>
>I have posted a message here some time ago about someone claiming to be
>able to unprotect any '84 with a device called the picbuster II.
>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>I haven't heard any details about this device yet.

I have a program called picbust. I don't have a pic programmer so I don't
know if it works but if some one want it I could post it to the list.

Regards Otto

1996\04\05@113924 by liver Niekrenz

flavicon
face
>
> Hello pic users.
>
> I have posted a message here some time ago about someone claiming to be
> able to unprotect any '84 with a device called the picbuster II.
> Now I read in alt.satellite.tv.europe that the picbuster III is coming.
> I haven't heard any details about this device yet.

Well, there was indeed an article about busting a protected pic sometime
ago in the above mentioned newsgroup.

You were given a detailed procedure about how to do this, so you don't
really need to use this horribly expensive service.

I saved this article and it looked really easy as far as I can remember.

oli

1996\04\05@113924 by liver Niekrenz

flavicon
face
>
> Hello pic users.
>
> I have posted a message here some time ago about someone claiming to be
> able to unprotect any '84 with a device called the picbuster II.
> Now I read in alt.satellite.tv.europe that the picbuster III is coming.
> I haven't heard any details about this device yet.

Well, there was indeed an article about busting a protected pic sometime
ago in the above mentioned newsgroup.

You were given a detailed procedure about how to do this, so you don't
really need to use this horribly expensive service.

I saved this article and it looked really easy as far as I can remember.

oli

1996\04\05@115615 by Mike Keitz

flavicon
face
>>I have posted a message here some time ago about someone claiming to be
>>able to unprotect any '84 with a device called the picbuster II.
>>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>>I haven't heard any details about this device yet.
>
>I have a program called picbust. I don't have a pic programmer so I don't
>know if it works but if some one want it I could post it to the list.
>
The '84 is reportedly easy to bust, though I haven't tried it myself.  I can
think of a similar method for the EPROM models, by raising the Vdd voltage
until the unit senses the CP bit as unprogrammed, then programming groups of
4 zeros over the program and X-oring the verify codes at each stage to
determine what was programmed (this would destroy the program in the PIC,
but of course a new one could be programmed with the now cracked program).
Since reprogramming of the first 64 locations is not disabled by the CP bit,
these can be cracked immediately with nothing more than an ordinary
programmer.  At the very least, put sensitive code or data in the top part
of the EPROM which is somewhat more protected.

The only defense I've heard of (If Microchip is putting new features in the
PICs to defeat cracking, they aren't saying anything here) is to burn out
the pin buffers on the pins used for programming / verifying (B6 and B7 on
14-bit units, probably B0-B3 on 12-bit units would be sufficient) after
programming.  Of course the pins are then not available for I/O purposes
either, and the PIC may end up destroyed entirely.  This should defeat most
"garage" methods that use the existing program/verify paths, but more
advanced ones like opening the package up and scanning the chip will
probably never be stopped.

-Mike

1996\04\05@115615 by Mike Keitz

flavicon
face
>>I have posted a message here some time ago about someone claiming to be
>>able to unprotect any '84 with a device called the picbuster II.
>>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>>I haven't heard any details about this device yet.
>
>I have a program called picbust. I don't have a pic programmer so I don't
>know if it works but if some one want it I could post it to the list.
>
The '84 is reportedly easy to bust, though I haven't tried it myself.  I can
think of a similar method for the EPROM models, by raising the Vdd voltage
until the unit senses the CP bit as unprogrammed, then programming groups of
4 zeros over the program and X-oring the verify codes at each stage to
determine what was programmed (this would destroy the program in the PIC,
but of course a new one could be programmed with the now cracked program).
Since reprogramming of the first 64 locations is not disabled by the CP bit,
these can be cracked immediately with nothing more than an ordinary
programmer.  At the very least, put sensitive code or data in the top part
of the EPROM which is somewhat more protected.

The only defense I've heard of (If Microchip is putting new features in the
PICs to defeat cracking, they aren't saying anything here) is to burn out
the pin buffers on the pins used for programming / verifying (B6 and B7 on
14-bit units, probably B0-B3 on 12-bit units would be sufficient) after
programming.  Of course the pins are then not available for I/O purposes
either, and the PIC may end up destroyed entirely.  This should defeat most
"garage" methods that use the existing program/verify paths, but more
advanced ones like opening the package up and scanning the chip will
probably never be stopped.

-Mike

1996\04\05@122608 by paul

flavicon
picon face
Yes pic buster does exist and theres also a programmer that need no extra
software  its all done in hardware and works on the latest 84 chips ....
Anyone want to swop one for a programmer that programs all pics ?

--
Paul Bulmer

1996\04\05@122608 by paul

flavicon
picon face
Yes pic buster does exist and theres also a programmer that need no extra
software  its all done in hardware and works on the latest 84 chips ....
Anyone want to swop one for a programmer that programs all pics ?

--
Paul Bulmer

1996\04\05@161634 by Robin Abbott

flavicon
face
Having seen all the code busting stuff on this list am I the
only person on the list who would rather that code busting
techniques were :

a) kept quiet, I don't need my code busted thanks.

b) rebutted by Microchip. The 16C84 code busting technique is
  available on at least 2 web sites, and appears to be well
  documented. WHY don't Microchip respond to these threats to
  their customers intellectual property ? Do other manufacturers
  have such duff protection ? My current thoughts are that if
  it is so easy to bust PIC code then anyone who cares about
  their code ought to go elsewhere.

Robin

+-----------------------------------------------------------------------+
|                                                                       |
|   RemoveMErobin.abbottspamspamdial.pipex.com                                         |
|                                                                       |
|  PIC programmers and BASIC development systems from                   |
|    FOREST Electronic Developments. Visit our home page at             |
|                                                                       |
|      http://www.ibmpcug.co.uk/~gmwarner/fed.htm                       |
+-----------------------------------------------------------------------+

1996\04\05@161634 by Robin Abbott

flavicon
face
Having seen all the code busting stuff on this list am I the
only person on the list who would rather that code busting
techniques were :

a) kept quiet, I don't need my code busted thanks.

b) rebutted by Microchip. The 16C84 code busting technique is
  available on at least 2 web sites, and appears to be well
  documented. WHY don't Microchip respond to these threats to
  their customers intellectual property ? Do other manufacturers
  have such duff protection ? My current thoughts are that if
  it is so easy to bust PIC code then anyone who cares about
  their code ought to go elsewhere.

Robin

+-----------------------------------------------------------------------+
|                                                                       |
|   TakeThisOuTrobin.abbottspamspamRemoveMEdial.pipex.com                                         |
|                                                                       |
|  PIC programmers and BASIC development systems from                   |
|    FOREST Electronic Developments. Visit our home page at             |
|                                                                       |
|      http://www.ibmpcug.co.uk/~gmwarner/fed.htm                       |
+-----------------------------------------------------------------------+

1996\04\05@162929 by Roger Books

flavicon
face
Well, I am probably going to draw flames about this since I am not writing
commercial applications (yet), however...

I wish that the code protection fuse didn't exist.  Why?

If someone wants to bad enough they are always going to find a way around
it.

So, someone from a country that is notorious for stealing software and
hardware designs manages to bypass the code fuse for your product.  They
manufacture your product, but since they didn't have the R&D they can
undercut you and you are hosed.

Because of the code protection fuse you can't read their code.  Is your
company going to invest in bypassing the code fuse, probably not unless they
have a good idea of what is going on.  You are hosed.

Without the fuse?  Well, you do a quick dump of the code, compare it to
yours, and the lawyers get to make money.

I, for one, don't believe that any of the manufacturers have a foolproof
method to keep someone from looking at your code.  Maybe I'm clueless.

Roger

1996\04\05@162929 by Roger Books

flavicon
face
Well, I am probably going to draw flames about this since I am not writing
commercial applications (yet), however...

I wish that the code protection fuse didn't exist.  Why?

If someone wants to bad enough they are always going to find a way around
it.

So, someone from a country that is notorious for stealing software and
hardware designs manages to bypass the code fuse for your product.  They
manufacture your product, but since they didn't have the R&D they can
undercut you and you are hosed.

Because of the code protection fuse you can't read their code.  Is your
company going to invest in bypassing the code fuse, probably not unless they
have a good idea of what is going on.  You are hosed.

Without the fuse?  Well, you do a quick dump of the code, compare it to
yours, and the lawyers get to make money.

I, for one, don't believe that any of the manufacturers have a foolproof
method to keep someone from looking at your code.  Maybe I'm clueless.

Roger

'PIC code protection woes'
1996\04\05@171430 by Todd Peterson

picon face
Recently I spoke with a higher-up at M-Chip, and he, in a round-a-bout way
assured me that the problem was being solved even as we spoke.  Does anyone
believe/ know this to be true?  I agree with the last post: If the
code-protect fuses are that easily defeatable, why not just remove them?
Then we're all on equal footing and can easily detect code similarity
between competitors.

It seems that we all are HEARING that they are easy to read; but does anyone
actually have first-hand knowledge of whether these methods work reliably?
It sounds as though anyone, with not much at all for equipment, can read
code-protected PICS.

comments?

Todd Peterson

===========================================================
*** Developers of the PICPlus(TM) Microcontroller Board ***

Todd Peterson, Computer Engineer   (KILLspamtpetersonspamspamspam_OUTnetins.net)
E-LAB Digital Engineering, Inc.

P.O. Box 246
Lawton, IA 51030-0246
(712) 944-5344

Visit us at: http://www.netins.net/showcase/elab/

E-Mail Now for Your Free PICPlus(TM) Information Packet!
TO: tpetersonRemoveMEspamnetins.net   (include POSTAL mailing address)
===========================================================

1996\04\05@171430 by Todd Peterson

picon face
Recently I spoke with a higher-up at M-Chip, and he, in a round-a-bout way
assured me that the problem was being solved even as we spoke.  Does anyone
believe/ know this to be true?  I agree with the last post: If the
code-protect fuses are that easily defeatable, why not just remove them?
Then we're all on equal footing and can easily detect code similarity
between competitors.

It seems that we all are HEARING that they are easy to read; but does anyone
actually have first-hand knowledge of whether these methods work reliably?
It sounds as though anyone, with not much at all for equipment, can read
code-protected PICS.

comments?

Todd Peterson

===========================================================
*** Developers of the PICPlus(TM) Microcontroller Board ***

Todd Peterson, Computer Engineer   (EraseMEtpetersonSTOPspamspamRemoveMEnetins.net)
E-LAB Digital Engineering, Inc.

P.O. Box 246
Lawton, IA 51030-0246
(712) 944-5344

Visit us at: http://www.netins.net/showcase/elab/

E-Mail Now for Your Free PICPlus(TM) Information Packet!
TO: spam_OUTtpetersonRemoveMEspamEraseMEnetins.net   (include POSTAL mailing address)
===========================================================

'Pic code protection alert!'
1996\04\05@174558 by hoss karoly

flavicon
face
>
> I have a program called picbust. I don't have a pic programmer so I don't
> know if it works but if some one want it I could post it to the list.
>
> Regards Ottoplease do because if it worx i'll have to go and learn 8752bh
i hope it wont because i like this little poliploid spider
bye
charley
TakeThisOuTtimothyRemoveMEspam@spam@bekes.hungary.net

1996\04\05@174558 by hoss karoly

flavicon
face
>
> I have a program called picbust. I don't have a pic programmer so I don't
> know if it works but if some one want it I could post it to the list.
>
> Regards Ottoplease do because if it worx i'll have to go and learn 8752bh
i hope it wont because i like this little poliploid spider
bye
charley
EraseMEtimothyRemoveMEspambekes.hungary.net

1996\04\05@204048 by ETS Electronics

flavicon
face
I also have the picbuster program but I have no docs. If you have a
readme or doc file please e-mail it to me. I am using the Microchip
PICSTART 16B1 programmer on COM2. When I run the picbust program I get
an error that states that it can't find the PIC device. I have tried all
of the common switches -? /? /h and so on.

Thanks in advanced.

       JIM

1996\04\05@204048 by ETS Electronics

flavicon
face
I also have the picbuster program but I have no docs. If you have a
readme or doc file please e-mail it to me. I am using the Microchip
PICSTART 16B1 programmer on COM2. When I run the picbust program I get
an error that states that it can't find the PIC device. I have tried all
of the common switches -? /? /h and so on.

Thanks in advanced.

       JIM

1996\04\06@072744 by Otto Tronarp

flavicon
face
--=====================_828825789==_
Content-Type: text/plain; charset="us-ascii"

At 00.45 1996-04-06 +0100, you wrote:
{Quote hidden}

--=====================_828825789==_
Content-Type: application/octet-stream; name="PICBUST.ZIP";
x-mac-type="42494E41"; x-mac-creator="6D646F73"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="PICBUST.ZIP"

UEsDBBQAAAAIAOhy2R4WIhavthQAABgmAAALAAAAUElDQlVTVC5DT03tWn1UVNe1P2e+nRnuXFA+
/AhcFIgSHVETjToiKoPSiA6D0cF0aalgpI3Qwkxau5pkjF0GmTzja/te+5r3UtR+vLaudl4k0cGs
kXjtYNOYoOZFmrQrZjTtviGOKAHk6963zx1QNOZp18ofb73Vg+t+7LPPnn323ue39zlXSdRlEJvN
RtSmaMmYZiT/a5szd57wBTflC26T/tH+0f7R/t+350/pCX8whbLrJHowjRr2p9C9rfOUoRDhjy5V
un9jhIfSHYpPK71DQEmHdtKccDozYsigJGIQ2CWTXaZRwmVwxvC+STCFwtsWmEb3z6CWVq8WNunA
RV9TFPiTBv7FCLkCdFN4gUCJ1jHZW+nPT6YEpRcRx2K8BXQOB94MesdSvD1mdizBmyvRkY+3Z5Mc
BXg7YHQsw5vd6FiOtx9n+POzUILRsQLfGqyOVXVa6VXqmP2k0bGyXgs/0XTugj5N+P2psIvAET0k
EzincZR7tdJDCmjIaeGolpzmxYgB9Wg2ns40t/oMMr50XhMdJt+0osCEolL3hnlKM2k8oW2lbY2R
UBPp+5C22ffk30c3byxHtnq9/cAUKhpcpRtC5Oje1+0B7Mpp0K+0N02J31Xeco9RbNThD1ARDihF
nd3hBRPhstJC9CGeuEtL3eGZk+CfFXhP2VguR6JXyje+XOIuhWeUYAvUKeUbkdYVfnAStChiODAJ
DisGu+ot+/5sGugKaVCtwPUWGpe2PsQRKFQCkd0nXTCbeHafhBnEf8IAeUpOoz5rKUwmOY1OChMI
bCK72jRRaVP5xl0RDn/khFF0tUP8D/TEA5SIWbZj/Ub7eeljOQ/T14MPzV/w8MJly1cUOotcKJkS
z51HnJcIEYOCdFi2N6ZkUHvjfIE2a44Qf0TfHm2P2jVI9J8walIyKTrBscqX1CRQtJBW+k8inzog
UKmJOFwq1WFD6veJ3MqojcTxiG+qPx+Dz2uUuUwqfZs0ZeBI7zdxWAZlYamVKomjxJfHuLTIhSTJ
zbgcCT5uJIJxfNDV+R8oND6GSHnEUepLQ4vqL5DFBo7WCzsN2fQCgYAsTSCOYh+PfRjY42ZdIAez
KXhlKXO4xaiFjuGIYQrVBvKzKf5GM6FtqDQ6gcXKnvz7aaDNtfsC/Fz2wH6ZcWpE+DqxBzj04Ouu
/fdT1X+NOJV26RWifT1w3dOYk0n9l6gvqf1C/C/Hn23LMeklI8GnLnyC3uFgiTRRkV4achQ8qcn6
QLy1LAivniI9Pxw23SftHp6ZV2dw8E9qZhpFt6vZpkY6rh8S/us42DYMuTr4JyNEOc/Gw6Z90WH5
j75+afyQKcVqzM0ViqqfqBJqar3C1lpfTaXgdLvXuu25uWSku7jmyYonqiuFVVXfFtb4tn+1qk4Q
kEzGjl5RV1Xhra6tiQ8Wbg7GtsFdvM4pjPSoDbtZbKfv7Zh3tnnS6cyMjQGuxFLafP/pzHC+5fiP
xoUsKuB0/6y8NLx7EvxyKKzSGnWwaqgoer1cbFliObDE0mw+nbnn3aJGXRE6JBLRkV0nNLfZ6PMb
HJdhJYGQHN45FZxDsIOi0CAPB5XmJUFyOrM+idlu5hDENFBqgGODUnQg0DGiN+Inqr4UVQezWfrD
QGg6CS+xoAZF0QGR3GODUwoskuHX49hc2wwz6FdM4dlTITQIl0nQitpAqrLn3UPoSWOkULFLOuKw
+7oiuuWRQlocKdSsiRRqSbMjRJi21nCWGZ4ehAKNlEECHQFuBk1n+NHRQkhzASpaPy683AxfHoR0
jZQ2cIyQQHtIR85dROvBTzF+vpvqMNeZHYnftTlSvmWZaUSTivIbvvfFsN4M2YPS74db3jbvOR/U
N+iZ3cNnzI2FCi7Jl+FlhcVcCos57zimRt+A9KNhzxj37uEesYQQgaercWls5k9nSj/sZ/q8OSAF
+tlyNbCEY5ReGSwNER2GaLnIkKRFMx2RgyB0cHHoQJ0YcIgIG4zioIzSqlIe8aX34iKnXj2DDFEF
jDh/BmXwIDpKvFRUWXx6lcDQwnYbWvziJlqgI+EnQ2HPVMgZgI0KCw8rfG/Yvn8ShX8b2oMW3mtI
ofN6wUkcgrffkeDtcZi9Vx2LvXMdk7x2xyLfR5BLYAlpkOEBsifdkABziFnxTQjk42MOyWlYslJ+
y9eDmNp5TKoaSkfBezsOZYhgJg0DSG0YbDgvzlVm5jn4OlzZo0BhaoNzN4j4ElHEpiwqt2bRA1kU
bARm6doQ1VD7V/qlr15vJtibRcPS1JCV4VUk8GXznnSOgqtfNLAZHCcE4znQtvvkb6L9RrR7C5mM
8YGGvz0bpCVgPjFAYJAzchkRQyqXFjGkcQkRw0SO2Ju0tL2V/YX05PjZjMN57a3+c6Thvl1thui1
40YhrKchLa5hTB1G7nyDvmhl9Fp4dwb84To0UxwQMpCmiVyzCqmw+rpjMqsREM69Gx15Xp1jjk/X
oO98yyH4Ehv1jjzM4634Ho7o8zpD6Pskfz4q4W2WuYmc357KGTp/helBpeq8L8mood/AqD/AyHkB
rBTWUlYjaCncR6F5ILxGgILroFHgbB/sG8ASwuxY47sG9dcloS8cEmDadfhIhlf6oB47UTOnAfuv
sJUL39MECbyfHNbRQ2DUw3fHBQ3wZjLO9VDEMIGmNy91BTogdVxQB68mQ2HKwx1es0fmJlDf36SN
xIPMP02OvoO3Hyfj5Qfssjc5PlJBm1ovBDr8FzPgXRMK8CVDRwqQFDibkpWBgsapcs5LSQS6+mFJ
ctifCjv6gOuTfmKCF2m4OxO+1gfZyTDUK9lIuCITHuuD900wPhk+7oWzJvhBn1TQy7zJHKAnh0mj
vr2j/RzzWU+jeEBLRbVTR8MGAeHiEIZdIgu7X0c/FRtTUrnG+WkcW6hqkZXKPcDiwcbigTKPo3c7
e+FdBZ7qhcX96FGDB36rdO5Gp64a9Rn1djCfrZW5VK7z9KjPtN4TzGcrZRTaeQQLvsNY8P2uQR/v
G3ez78VbdONHdYMPr4edmbC9F1zElwTnrrO5b+6FT3ugqVcq6XFB5Dp8h4SfyoTiXg8MGO3759Dd
J+1thvvoN0zwMb7Po+obPw5LoPfQCHC0Byp7pcQe+PMQ7CMjKyfAcXRZTkB/cB5F//z3eNgyIWdR
ds4iJz04h/oS0Jmvj2cF2J/ntoob4MXxnjNw2Gl+X3zZ2Kw5nSmy5HOqB4YG4sknp9++P43C4uuj
6LI3PY2GCcEfOsRKzWi/GnH/qpUe/dTVfir+19juaYyKuGLBSkA2HCMFoCVSj2F9qT2QkkSxYAy2
njlXr7HS2D6rLpY1GIvGgidisHdCVmusfJMYfnayWmZ7teEfToZFPWL4F5NhHt64dJjZE1/qU6gx
vJe2JFnQ0Kz85An8/tND0NwDck+0Ty0ueSwuL2GZfBSL5FaPWiT7ffRpowgfKwjgVr9s8W6V35K5
OHzjO+ddL0dkQxy8p/gHkrxFTZlUPoU7EoP8hsxlIGwdQMIbCN2+B/wDBT7+5aSRPUmGitZHGH+r
Q4P8GC+j/CdElxtWELWA9CXEQam9NatL0pAs2/G9lNWprGA193qNu9p4+a3OHu1AvNw0YOklaQmW
Yib9Ro/oYlA1dkYNes7oEeHPMlyQ4Z0BVRm0ys0tE/y2GwZkeL4b9z/56v7HO17d4Mwj6nannEBM
7vwTzOx1zH46DYN6ApZufLx0g5VKsATeljtb4Ijc+Yr0zWvwOxmyZVQ5VEBKNwT14E2E80mgJG7G
YNiAwVWZuLk8+hGsSJS+psDlnvBwCuzohsUDGK6Xh+PjwopSVLo+EIGrukZ9M1kZ6Nh5UVkKswiK
y06EhiQIJsKzSYgmWmkhQZl84qby6Jvw0x6GJg90Q+s1KUFxlZVucAW10M17YFJiEJcIH9Khr3xD
0YHN5Y+hTWp7wrNSYfAa7Lsm/UVm/OtVFMMnAB5HHOVDeZr4iHi86YMcHORxcBzFNsXlPDSMEb5A
h5j6HA+/43F9Y8zh5HXwLR7eSwQNmzyb+zZ+c/nK6EcRg44SRFukrOej/ci3loeXE+E9HuELZvAi
XBxCYYv4ozjrzXzIyDhn8vBCYrQ3SGEqHzTCfTzbKp3QwnEtkmyMZObhsk1EtelNtcX4ojchUoa1
tPtnx3kTroqQi3T/jC0TkctQGbS4ZBlPTqPOrua5XvREmDchI5LQc0XRPpU/vq8+SsnBx5PBrvWa
Yd1VNe+9RiDn0zAvwKGr+7HrryofTGbzqLOpieYlGcZrcSJbbLclmt9q0AIlNnjf9tlEM9+mJprZ
Nrzksku27bOJZjsTYLVBLQ8/skE1f3uiea4b3uFYaPBX4edd0hwNNGrgBIdp0K4YHk9mWTVzECq6
WfK53AXPdsHXNHCAg0oNVGhg6lXp7SsMjM92gRuHclDRBcUaMF+Vjlxp4e+HNNICWkgiLZUMz1rM
BAxElwdru8SQoiyb0V4/SNtdDaeQ5OjyiKY0q9HlXrvSvaxE2LBq7Wqn4CpeIUwvn71mBmF9Zd6K
Oq+wrLKyTlg0pvhX+5y42RE+p89VV/t4XcX27dU1j4/dNJiyrMQkJBiXP1G75evImWU1alR+Abc6
o3qoO53pZTNwoxPfJTnr6mrrhAqvsIgIgrt2O97cFXg1Tea0wrKaHcIjVTsEb62wpbbGW13jqxJG
RTpRZImw3ukuLip2FgprH1ElxvvcVRWVTLu4KrmELf2nr0BBL2ZsQwYcGfLna2mG1wLKkJ/TUh4u
EXjzavhXKeC5Apdj8JurWOQkq0XOoAURQevdVgYhpVwyEKzosQjHnIMo8sv+G/jxX0QNFnieuEYw
ZDnBUPnQCoUcPJEA+dzCGxH3F6lUjbiTVsSSVii7ygLmgxh4Y3hmwGIf9lkh5Yq09zLCgyuogRet
HjhhxeX2fWsItLejxFNWFRqsVxnE/DgGs2KdLc0WtpuIl7CYgHefxDRrFEtDygsoEtnZPnHD+vXM
LltjHkglmzbj+x55fdibAetimIgxTSKNHXF8EvNIEINDXfDMIDRfZxxzY/DppzfKYx2ICs61xwK7
rDkN2TkNToqz+6uFpfZLcNICX4pJfZ+YiMb4h9NfYDtmItqWeIiONLbdHhuttza2Ry+s8FZ8LkOL
ieje/CI1DJGW0WVDkk99kZJfI6YJWh0xafS4xCg1FlY9Wb2lapGWrfAFczQ3poSvc+YjZfbDDwqj
y7aqzi6sqP3Gjrrqx7d5hS/VbqsRSmrr6qrr8YhizsKFD5pIinHrHGF1bUWlsJUdYCwSts4Vyiqe
rLrxOm9kZY2IZKQH1UUnuKq3sLeHhPVVddVbd4y8C1vn40/WbK1+XCjy1VfVI8cCYU3Vt4S43mzE
w4KrFtHos22RMN1ZWe0Vvl61o16YnDZxEoKXPdWIQxbG3VlStV2l3DKKsFkwRUdVHGWtrdsxRt2x
VCQ7y1Yg3eurq2GQU1JRjaapqvEJ99AMDkFV85FRNfPvYRB60ay966I4ZppgabmbqBbTBOu9MCXc
CxN312B9TfN/Vvd7YbLdCxN/T1bg78EKdzALj2bJy/v7/rWY+Lvb6Q4z4e9uuDuNursl7zTK9vcD
HTPjRKswtq4YA+Om6VhXTLEKbueywuI1K9UiBuuDZIu64nNVRBlBF19d/KQ1Nz4w2cqQcIULcXCD
ex2ethayw1Zh7bo56nUuciTcCht3aKY0m2aFr95bi8DJChShuBC1M45ZwylWFWpHgGZdXXVVvbBk
ZHBqgqCWP3VV9fUqvCCulPoQJxjVlGtl87irBslWQRhbRBU9WuYsEwQs5OJ0pkRywt3EqDyPoq1W
19Z+44a6JVXebbWVTNbSOM+9qoMH2KwAKy5jaq1zrliHRVhu7qjl76INK9Ry48VbuerQWflCibNk
rbscqzXsY9Ni5FvLO3WcRTOq+kjpeKNGNaUlaFi+YU6qr9hRP7YUMKVxKtbjWXxlvXBLTWuaZTGy
39TcsU4d+dV475q160Y5SlAp4UavcURft7P00WI3OsfpXlbGghVnM9Gi5s7lxWvU/ImRzuqUmort
VbeV1hMtxWvWOVcLq5weoah4tfNzOBmjmpzvIlFdU9OXz6iuqcDshpaavmxG/ZbqatYzyVpW/Z0q
YemtlmB0NThH9gjjqBYn9fCD+J88Rp4XzLn5/Bk6Ia6yDXjEcnSvWjeOw69hemLcjMXpzU9k+L0M
zzg90+zn8VPhxGl4ZoBVIn4knDjtMweq7HwGS9bpKBUL1oFyfJ5w4zkoxCCmBElMZGzqIa7XHFwV
g9NKsCAmBk/FWFHaGhNxf8wZcZ/ctIT+Wt2kprGildXtOf4lRb60HP9TtMiXiDdNkc+8q027eD5H
fVExiOf3YvjDFCi6CNNISz4ee+fT+On+UupXz9YP4cn2IH5Sw4+af/yb2JJtHTnsazPw7IA5hfgs
7BHPPSzE+xXYQXzb4FUi2gPpPD1zMf1oAdnbEdhgyrCc9erte9hsWSRhILlZHLgF11oELRZyRWsf
XVMYXxjGeJw9uqZ43Ug0Osuca9ZhJ8yOgumj8GNZ8MOoCFOjMHgp/J0seC4aVFQb4fefT7Lk2LEV
ZqCXwUiyu2xLCsyiegwW/EoM/p2i4fDsavkn7e1nzn0p6Irt24eU6JW+cwFRPUF74xN4rRtC3fBq
NxzuVseh/XFDgafTbYYFlBTszFlAlWfaod6wk8N3P+STaCcsp7CUsj0Ksp65kK08g7/CZYwdcebm
CCsbwVNIUEcAi6lS9lM752O3KZC+4HPP7Pahu9kY1IcnuIHhyc6LxO/VJhB/tKv8sTMgupggdAbg
UYGegJ2oKt1Z8ojgK2MEx48MgxeYYVrHmqo9Tombqlzcz9MC/MRwEGeRJMOzMm6Yai8yXwxeGNPV
Nwy/ksF/QfrlB9Ak47yllz4wzUjVrnatm0PCj+Ugq9yqy2soNIJ4AWN/gKhffpoWU/x6emAhbXJQ
+CoZ/e7RcBIDHNzEfKEhZxFtzMF+vKVnUf9F6psb6Dgj7rzYZXOdOXXmVJbWJHrUJ/bnv5Rn+pvH
f8nk1e38I/H73y7Yg5YQ/Zds/jcLDuITOzlWv52OBhEaR12aY4JKff8fUEsBAhQAFAAAAAgA6HLZ
HhYiFq+2FAAAGCYAAAsAAAAAAAAAAAAgAAAAAAAAAFBJQ0JVU1QuQ09NUEsFBgAAAAABAAEAOQAA
AN8UAAAAAA==
--=====================_828825789==_--

1996\04\06@072744 by Otto Tronarp

flavicon
face
--=====================_828825789==_
Content-Type: text/plain; charset="us-ascii"

At 00.45 1996-04-06 +0100, you wrote:
{Quote hidden}

--=====================_828825789==_
Content-Type: application/octet-stream; name="PICBUST.ZIP";
x-mac-type="42494E41"; x-mac-creator="6D646F73"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="PICBUST.ZIP"

UEsDBBQAAAAIAOhy2R4WIhavthQAABgmAAALAAAAUElDQlVTVC5DT03tWn1UVNe1P2e+nRnuXFA+
/AhcFIgSHVETjToiKoPSiA6D0cF0aalgpI3Qwkxau5pkjF0GmTzja/te+5r3UtR+vLaudl4k0cGs
kXjtYNOYoOZFmrQrZjTtviGOKAHk6963zx1QNOZp18ofb73Vg+t+7LPPnn323ue39zlXSdRlEJvN
RtSmaMmYZiT/a5szd57wBTflC26T/tH+0f7R/t+350/pCX8whbLrJHowjRr2p9C9rfOUoRDhjy5V
un9jhIfSHYpPK71DQEmHdtKccDozYsigJGIQ2CWTXaZRwmVwxvC+STCFwtsWmEb3z6CWVq8WNunA
RV9TFPiTBv7FCLkCdFN4gUCJ1jHZW+nPT6YEpRcRx2K8BXQOB94MesdSvD1mdizBmyvRkY+3Z5Mc
BXg7YHQsw5vd6FiOtx9n+POzUILRsQLfGqyOVXVa6VXqmP2k0bGyXgs/0XTugj5N+P2psIvAET0k
EzincZR7tdJDCmjIaeGolpzmxYgB9Wg2ns40t/oMMr50XhMdJt+0osCEolL3hnlKM2k8oW2lbY2R
UBPp+5C22ffk30c3byxHtnq9/cAUKhpcpRtC5Oje1+0B7Mpp0K+0N02J31Xeco9RbNThD1ARDihF
nd3hBRPhstJC9CGeuEtL3eGZk+CfFXhP2VguR6JXyje+XOIuhWeUYAvUKeUbkdYVfnAStChiODAJ
DisGu+ot+/5sGugKaVCtwPUWGpe2PsQRKFQCkd0nXTCbeHafhBnEf8IAeUpOoz5rKUwmOY1OChMI
bCK72jRRaVP5xl0RDn/khFF0tUP8D/TEA5SIWbZj/Ub7eeljOQ/T14MPzV/w8MJly1cUOotcKJkS
z51HnJcIEYOCdFi2N6ZkUHvjfIE2a44Qf0TfHm2P2jVI9J8walIyKTrBscqX1CRQtJBW+k8inzog
UKmJOFwq1WFD6veJ3MqojcTxiG+qPx+Dz2uUuUwqfZs0ZeBI7zdxWAZlYamVKomjxJfHuLTIhSTJ
zbgcCT5uJIJxfNDV+R8oND6GSHnEUepLQ4vqL5DFBo7WCzsN2fQCgYAsTSCOYh+PfRjY42ZdIAez
KXhlKXO4xaiFjuGIYQrVBvKzKf5GM6FtqDQ6gcXKnvz7aaDNtfsC/Fz2wH6ZcWpE+DqxBzj04Ouu
/fdT1X+NOJV26RWifT1w3dOYk0n9l6gvqf1C/C/Hn23LMeklI8GnLnyC3uFgiTRRkV4achQ8qcn6
QLy1LAivniI9Pxw23SftHp6ZV2dw8E9qZhpFt6vZpkY6rh8S/us42DYMuTr4JyNEOc/Gw6Z90WH5
j75+afyQKcVqzM0ViqqfqBJqar3C1lpfTaXgdLvXuu25uWSku7jmyYonqiuFVVXfFtb4tn+1qk4Q
kEzGjl5RV1Xhra6tiQ8Wbg7GtsFdvM4pjPSoDbtZbKfv7Zh3tnnS6cyMjQGuxFLafP/pzHC+5fiP
xoUsKuB0/6y8NLx7EvxyKKzSGnWwaqgoer1cbFliObDE0mw+nbnn3aJGXRE6JBLRkV0nNLfZ6PMb
HJdhJYGQHN45FZxDsIOi0CAPB5XmJUFyOrM+idlu5hDENFBqgGODUnQg0DGiN+Inqr4UVQezWfrD
QGg6CS+xoAZF0QGR3GODUwoskuHX49hc2wwz6FdM4dlTITQIl0nQitpAqrLn3UPoSWOkULFLOuKw
+7oiuuWRQlocKdSsiRRqSbMjRJi21nCWGZ4ehAKNlEECHQFuBk1n+NHRQkhzASpaPy683AxfHoR0
jZQ2cIyQQHtIR85dROvBTzF+vpvqMNeZHYnftTlSvmWZaUSTivIbvvfFsN4M2YPS74db3jbvOR/U
N+iZ3cNnzI2FCi7Jl+FlhcVcCos57zimRt+A9KNhzxj37uEesYQQgaercWls5k9nSj/sZ/q8OSAF
+tlyNbCEY5ReGSwNER2GaLnIkKRFMx2RgyB0cHHoQJ0YcIgIG4zioIzSqlIe8aX34iKnXj2DDFEF
jDh/BmXwIDpKvFRUWXx6lcDQwnYbWvziJlqgI+EnQ2HPVMgZgI0KCw8rfG/Yvn8ShX8b2oMW3mtI
ofN6wUkcgrffkeDtcZi9Vx2LvXMdk7x2xyLfR5BLYAlpkOEBsifdkABziFnxTQjk42MOyWlYslJ+
y9eDmNp5TKoaSkfBezsOZYhgJg0DSG0YbDgvzlVm5jn4OlzZo0BhaoNzN4j4ElHEpiwqt2bRA1kU
bARm6doQ1VD7V/qlr15vJtibRcPS1JCV4VUk8GXznnSOgqtfNLAZHCcE4znQtvvkb6L9RrR7C5mM
8YGGvz0bpCVgPjFAYJAzchkRQyqXFjGkcQkRw0SO2Ju0tL2V/YX05PjZjMN57a3+c6Thvl1thui1
40YhrKchLa5hTB1G7nyDvmhl9Fp4dwb84To0UxwQMpCmiVyzCqmw+rpjMqsREM69Gx15Xp1jjk/X
oO98yyH4Ehv1jjzM4634Ho7o8zpD6Pskfz4q4W2WuYmc357KGTp/helBpeq8L8mood/AqD/AyHkB
rBTWUlYjaCncR6F5ILxGgILroFHgbB/sG8ASwuxY47sG9dcloS8cEmDadfhIhlf6oB47UTOnAfuv
sJUL39MECbyfHNbRQ2DUw3fHBQ3wZjLO9VDEMIGmNy91BTogdVxQB68mQ2HKwx1es0fmJlDf36SN
xIPMP02OvoO3Hyfj5Qfssjc5PlJBm1ovBDr8FzPgXRMK8CVDRwqQFDibkpWBgsapcs5LSQS6+mFJ
ctifCjv6gOuTfmKCF2m4OxO+1gfZyTDUK9lIuCITHuuD900wPhk+7oWzJvhBn1TQy7zJHKAnh0mj
vr2j/RzzWU+jeEBLRbVTR8MGAeHiEIZdIgu7X0c/FRtTUrnG+WkcW6hqkZXKPcDiwcbigTKPo3c7
e+FdBZ7qhcX96FGDB36rdO5Gp64a9Rn1djCfrZW5VK7z9KjPtN4TzGcrZRTaeQQLvsNY8P2uQR/v
G3ez78VbdONHdYMPr4edmbC9F1zElwTnrrO5b+6FT3ugqVcq6XFB5Dp8h4SfyoTiXg8MGO3759Dd
J+1thvvoN0zwMb7Po+obPw5LoPfQCHC0Byp7pcQe+PMQ7CMjKyfAcXRZTkB/cB5F//z3eNgyIWdR
ds4iJz04h/oS0Jmvj2cF2J/ntoob4MXxnjNw2Gl+X3zZ2Kw5nSmy5HOqB4YG4sknp9++P43C4uuj
6LI3PY2GCcEfOsRKzWi/GnH/qpUe/dTVfir+19juaYyKuGLBSkA2HCMFoCVSj2F9qT2QkkSxYAy2
njlXr7HS2D6rLpY1GIvGgidisHdCVmusfJMYfnayWmZ7teEfToZFPWL4F5NhHt64dJjZE1/qU6gx
vJe2JFnQ0Kz85An8/tND0NwDck+0Ty0ueSwuL2GZfBSL5FaPWiT7ffRpowgfKwjgVr9s8W6V35K5
OHzjO+ddL0dkQxy8p/gHkrxFTZlUPoU7EoP8hsxlIGwdQMIbCN2+B/wDBT7+5aSRPUmGitZHGH+r
Q4P8GC+j/CdElxtWELWA9CXEQam9NatL0pAs2/G9lNWprGA193qNu9p4+a3OHu1AvNw0YOklaQmW
Yib9Ro/oYlA1dkYNes7oEeHPMlyQ4Z0BVRm0ys0tE/y2GwZkeL4b9z/56v7HO17d4Mwj6nannEBM
7vwTzOx1zH46DYN6ApZufLx0g5VKsATeljtb4Ijc+Yr0zWvwOxmyZVQ5VEBKNwT14E2E80mgJG7G
YNiAwVWZuLk8+hGsSJS+psDlnvBwCuzohsUDGK6Xh+PjwopSVLo+EIGrukZ9M1kZ6Nh5UVkKswiK
y06EhiQIJsKzSYgmWmkhQZl84qby6Jvw0x6GJg90Q+s1KUFxlZVucAW10M17YFJiEJcIH9Khr3xD
0YHN5Y+hTWp7wrNSYfAa7Lsm/UVm/OtVFMMnAB5HHOVDeZr4iHi86YMcHORxcBzFNsXlPDSMEb5A
h5j6HA+/43F9Y8zh5HXwLR7eSwQNmzyb+zZ+c/nK6EcRg44SRFukrOej/ci3loeXE+E9HuELZvAi
XBxCYYv4ozjrzXzIyDhn8vBCYrQ3SGEqHzTCfTzbKp3QwnEtkmyMZObhsk1EtelNtcX4ojchUoa1
tPtnx3kTroqQi3T/jC0TkctQGbS4ZBlPTqPOrua5XvREmDchI5LQc0XRPpU/vq8+SsnBx5PBrvWa
Yd1VNe+9RiDn0zAvwKGr+7HrryofTGbzqLOpieYlGcZrcSJbbLclmt9q0AIlNnjf9tlEM9+mJprZ
Nrzksku27bOJZjsTYLVBLQ8/skE1f3uiea4b3uFYaPBX4edd0hwNNGrgBIdp0K4YHk9mWTVzECq6
WfK53AXPdsHXNHCAg0oNVGhg6lXp7SsMjM92gRuHclDRBcUaMF+Vjlxp4e+HNNICWkgiLZUMz1rM
BAxElwdru8SQoiyb0V4/SNtdDaeQ5OjyiKY0q9HlXrvSvaxE2LBq7Wqn4CpeIUwvn71mBmF9Zd6K
Oq+wrLKyTlg0pvhX+5y42RE+p89VV/t4XcX27dU1j4/dNJiyrMQkJBiXP1G75evImWU1alR+Abc6
o3qoO53pZTNwoxPfJTnr6mrrhAqvsIgIgrt2O97cFXg1Tea0wrKaHcIjVTsEb62wpbbGW13jqxJG
RTpRZImw3ukuLip2FgprH1ElxvvcVRWVTLu4KrmELf2nr0BBL2ZsQwYcGfLna2mG1wLKkJ/TUh4u
EXjzavhXKeC5Apdj8JurWOQkq0XOoAURQevdVgYhpVwyEKzosQjHnIMo8sv+G/jxX0QNFnieuEYw
ZDnBUPnQCoUcPJEA+dzCGxH3F6lUjbiTVsSSVii7ygLmgxh4Y3hmwGIf9lkh5Yq09zLCgyuogRet
HjhhxeX2fWsItLejxFNWFRqsVxnE/DgGs2KdLc0WtpuIl7CYgHefxDRrFEtDygsoEtnZPnHD+vXM
LltjHkglmzbj+x55fdibAetimIgxTSKNHXF8EvNIEINDXfDMIDRfZxxzY/DppzfKYx2ICs61xwK7
rDkN2TkNToqz+6uFpfZLcNICX4pJfZ+YiMb4h9NfYDtmItqWeIiONLbdHhuttza2Ry+s8FZ8LkOL
ieje/CI1DJGW0WVDkk99kZJfI6YJWh0xafS4xCg1FlY9Wb2lapGWrfAFczQ3poSvc+YjZfbDDwqj
y7aqzi6sqP3Gjrrqx7d5hS/VbqsRSmrr6qrr8YhizsKFD5pIinHrHGF1bUWlsJUdYCwSts4Vyiqe
rLrxOm9kZY2IZKQH1UUnuKq3sLeHhPVVddVbd4y8C1vn40/WbK1+XCjy1VfVI8cCYU3Vt4S43mzE
w4KrFtHos22RMN1ZWe0Vvl61o16YnDZxEoKXPdWIQxbG3VlStV2l3DKKsFkwRUdVHGWtrdsxRt2x
VCQ7y1Yg3eurq2GQU1JRjaapqvEJ99AMDkFV85FRNfPvYRB60ay966I4ZppgabmbqBbTBOu9MCXc
CxN312B9TfN/Vvd7YbLdCxN/T1bg78EKdzALj2bJy/v7/rWY+Lvb6Q4z4e9uuDuNursl7zTK9vcD
HTPjRKswtq4YA+Om6VhXTLEKbueywuI1K9UiBuuDZIu64nNVRBlBF19d/KQ1Nz4w2cqQcIULcXCD
ex2ethayw1Zh7bo56nUuciTcCht3aKY0m2aFr95bi8DJChShuBC1M45ZwylWFWpHgGZdXXVVvbBk
ZHBqgqCWP3VV9fUqvCCulPoQJxjVlGtl87irBslWQRhbRBU9WuYsEwQs5OJ0pkRywt3EqDyPoq1W
19Z+44a6JVXebbWVTNbSOM+9qoMH2KwAKy5jaq1zrliHRVhu7qjl76INK9Ry48VbuerQWflCibNk
rbscqzXsY9Ni5FvLO3WcRTOq+kjpeKNGNaUlaFi+YU6qr9hRP7YUMKVxKtbjWXxlvXBLTWuaZTGy
39TcsU4d+dV475q160Y5SlAp4UavcURft7P00WI3OsfpXlbGghVnM9Gi5s7lxWvU/ImRzuqUmort
VbeV1hMtxWvWOVcLq5weoah4tfNzOBmjmpzvIlFdU9OXz6iuqcDshpaavmxG/ZbqatYzyVpW/Z0q
YemtlmB0NThH9gjjqBYn9fCD+J88Rp4XzLn5/Bk6Ia6yDXjEcnSvWjeOw69hemLcjMXpzU9k+L0M
zzg90+zn8VPhxGl4ZoBVIn4knDjtMweq7HwGS9bpKBUL1oFyfJ5w4zkoxCCmBElMZGzqIa7XHFwV
g9NKsCAmBk/FWFHaGhNxf8wZcZ/ctIT+Wt2kprGildXtOf4lRb60HP9TtMiXiDdNkc+8q027eD5H
fVExiOf3YvjDFCi6CNNISz4ee+fT+On+UupXz9YP4cn2IH5Sw4+af/yb2JJtHTnsazPw7IA5hfgs
7BHPPSzE+xXYQXzb4FUi2gPpPD1zMf1oAdnbEdhgyrCc9erte9hsWSRhILlZHLgF11oELRZyRWsf
XVMYXxjGeJw9uqZ43Ug0Osuca9ZhJ8yOgumj8GNZ8MOoCFOjMHgp/J0seC4aVFQb4fefT7Lk2LEV
ZqCXwUiyu2xLCsyiegwW/EoM/p2i4fDsavkn7e1nzn0p6Irt24eU6JW+cwFRPUF74xN4rRtC3fBq
NxzuVseh/XFDgafTbYYFlBTszFlAlWfaod6wk8N3P+STaCcsp7CUsj0Ksp65kK08g7/CZYwdcebm
CCsbwVNIUEcAi6lS9lM752O3KZC+4HPP7Pahu9kY1IcnuIHhyc6LxO/VJhB/tKv8sTMgupggdAbg
UYGegJ2oKt1Z8ojgK2MEx48MgxeYYVrHmqo9Tombqlzcz9MC/MRwEGeRJMOzMm6Yai8yXwxeGNPV
Nwy/ksF/QfrlB9Ak47yllz4wzUjVrnatm0PCj+Ugq9yqy2soNIJ4AWN/gKhffpoWU/x6emAhbXJQ
+CoZ/e7RcBIDHNzEfKEhZxFtzMF+vKVnUf9F6psb6Dgj7rzYZXOdOXXmVJbWJHrUJ/bnv5Rn+pvH
f8nk1e38I/H73y7Yg5YQ/Zds/jcLDuITOzlWv52OBhEaR12aY4JKff8fUEsBAhQAFAAAAAgA6HLZ
HhYiFq+2FAAAGCYAAAsAAAAAAAAAAAAgAAAAAAAAAFBJQ0JVU1QuQ09NUEsFBgAAAAABAAEAOQAA
AN8UAAAAAA==
--=====================_828825789==_--

1996\04\06@151040 by hoss karoly

flavicon
face
thnx a lot I'll check it out and if
it works i'll send my ideas on how to use it
bye
charley
.....timothyspamspam.....bekes.hungary.net

1996\04\06@151040 by hoss karoly

flavicon
face
thnx a lot I'll check it out and if
it works i'll send my ideas on how to use it
bye
charley
timothyKILLspamspamEraseMEbekes.hungary.net

1996\04\09@022511 by ETS Electronics

flavicon
face
I also have the picbuster program but I have no docs. If you have a
readme or doc file please e-mail it to me. I am using the Microchip
PICSTART 16B1 programmer on COM2. When I run the picbust program I get
an error that states that it can't find the PIC device. I have tried all
of the common switches -? /? /h and so on.

Thanks in advanced.

       JIM

1996\04\09@022518 by hoss karoly

flavicon
face
>
> I have a program called picbust. I don't have a pic programmer so I don't
> know if it works but if some one want it I could post it to the list.
>
> Regards Ottoplease do because if it worx i'll have to go and learn 8752bh
i hope it wont because i like this little poliploid spider
bye
charley
EraseMEtimothy@spam@spam@spam@bekes.hungary.net

'PIC code protection woes'
1996\04\09@022522 by Todd Peterson

picon face
Recently I spoke with a higher-up at M-Chip, and he, in a round-a-bout way
assured me that the problem was being solved even as we spoke.  Does anyone
believe/ know this to be true?  I agree with the last post: If the
code-protect fuses are that easily defeatable, why not just remove them?
Then we're all on equal footing and can easily detect code similarity
between competitors.

It seems that we all are HEARING that they are easy to read; but does anyone
actually have first-hand knowledge of whether these methods work reliably?
It sounds as though anyone, with not much at all for equipment, can read
code-protected PICS.

comments?

Todd Peterson

===========================================================
*** Developers of the PICPlus(TM) Microcontroller Board ***

Todd Peterson, Computer Engineer   (@spam@tpetersonspamspamKILLspamnetins.net)
E-LAB Digital Engineering, Inc.

P.O. Box 246
Lawton, IA 51030-0246
(712) 944-5344

Visit us at: http://www.netins.net/showcase/elab/

E-Mail Now for Your Free PICPlus(TM) Information Packet!
TO: spamBeGonetpetersonRemoveMEspamEraseMEnetins.net   (include POSTAL mailing address)
===========================================================

'Pic code protection alert!'
1996\04\09@022716 by Roger Books

flavicon
face
Well, I am probably going to draw flames about this since I am not writing
commercial applications (yet), however...

I wish that the code protection fuse didn't exist.  Why?

If someone wants to bad enough they are always going to find a way around
it.

So, someone from a country that is notorious for stealing software and
hardware designs manages to bypass the code fuse for your product.  They
manufacture your product, but since they didn't have the R&D they can
undercut you and you are hosed.

Because of the code protection fuse you can't read their code.  Is your
company going to invest in bypassing the code fuse, probably not unless they
have a good idea of what is going on.  You are hosed.

Without the fuse?  Well, you do a quick dump of the code, compare it to
yours, and the lawyers get to make money.

I, for one, don't believe that any of the manufacturers have a foolproof
method to keep someone from looking at your code.  Maybe I'm clueless.

Roger

1996\04\09@022720 by Robin Abbott

flavicon
face
Having seen all the code busting stuff on this list am I the
only person on the list who would rather that code busting
techniques were :

a) kept quiet, I don't need my code busted thanks.

b) rebutted by Microchip. The 16C84 code busting technique is
  available on at least 2 web sites, and appears to be well
  documented. WHY don't Microchip respond to these threats to
  their customers intellectual property ? Do other manufacturers
  have such duff protection ? My current thoughts are that if
  it is so easy to bust PIC code then anyone who cares about
  their code ought to go elsewhere.

Robin

+-----------------------------------------------------------------------+
|                                                                       |
|   RemoveMErobin.abbottKILLspamspamRemoveMEdial.pipex.com                                         |
|                                                                       |
|  PIC programmers and BASIC development systems from                   |
|    FOREST Electronic Developments. Visit our home page at             |
|                                                                       |
|      http://www.ibmpcug.co.uk/~gmwarner/fed.htm                       |
+-----------------------------------------------------------------------+

1996\04\09@022742 by paul

flavicon
picon face
Yes pic buster does exist and theres also a programmer that need no extra
software  its all done in hardware and works on the latest 84 chips ....
Anyone want to swop one for a programmer that programs all pics ?

--
Paul Bulmer

1996\04\09@022931 by liver Niekrenz

flavicon
face
>
> Hello pic users.
>
> I have posted a message here some time ago about someone claiming to be
> able to unprotect any '84 with a device called the picbuster II.
> Now I read in alt.satellite.tv.europe that the picbuster III is coming.
> I haven't heard any details about this device yet.

Well, there was indeed an article about busting a protected pic sometime
ago in the above mentioned newsgroup.

You were given a detailed procedure about how to do this, so you don't
really need to use this horribly expensive service.

I saved this article and it looked really easy as far as I can remember.

oli

1996\04\09@022940 by Mike Keitz

flavicon
face
>>I have posted a message here some time ago about someone claiming to be
>>able to unprotect any '84 with a device called the picbuster II.
>>Now I read in alt.satellite.tv.europe that the picbuster III is coming.
>>I haven't heard any details about this device yet.
>
>I have a program called picbust. I don't have a pic programmer so I don't
>know if it works but if some one want it I could post it to the list.
>
The '84 is reportedly easy to bust, though I haven't tried it myself.  I can
think of a similar method for the EPROM models, by raising the Vdd voltage
until the unit senses the CP bit as unprogrammed, then programming groups of
4 zeros over the program and X-oring the verify codes at each stage to
determine what was programmed (this would destroy the program in the PIC,
but of course a new one could be programmed with the now cracked program).
Since reprogramming of the first 64 locations is not disabled by the CP bit,
these can be cracked immediately with nothing more than an ordinary
programmer.  At the very least, put sensitive code or data in the top part
of the EPROM which is somewhat more protected.

The only defense I've heard of (If Microchip is putting new features in the
PICs to defeat cracking, they aren't saying anything here) is to burn out
the pin buffers on the pins used for programming / verifying (B6 and B7 on
14-bit units, probably B0-B3 on 12-bit units would be sufficient) after
programming.  Of course the pins are then not available for I/O purposes
either, and the PIC may end up destroyed entirely.  This should defeat most
"garage" methods that use the existing program/verify paths, but more
advanced ones like opening the package up and scanning the chip will
probably never be stopped.

-Mike

1996\04\09@044109 by Keith Dowsett

flavicon
face
>Having seen all the code busting stuff on this list am I the
>only person on the list who would rather that code busting
>techniques were :
>
>a) kept quiet, I don't need my code busted thanks.

Not a hope. With the current state of the internet if anyone discovers
something which they regard as useful (but not profitable) they are free to
publish it.

>b) rebutted by Microchip. <minor snip..> WHY don't Microchip respond
>   to these threats to
>   their customers intellectual property ? Do other manufacturers
>   have such duff protection ?

I guess they didn't anticipate a really determined attempt to defeat their
protection, or they assumed that if someone throws enough time and money at
the problem it will be cracked one way or another. Hopefully they are
developing improved schemes for future releases.

> My current thoughts are that if
>   it is so easy to bust PIC code then anyone who cares about
>   their code ought to go elsewhere.

I think that the PICs have been subject to a particularly intensive attack
on their code protection schemes because they have been used in smart-cards
for satellite TV systems.  Duplicating these means big money and possible
access to 'banned' adult channels.  I would imagine that if the code
protection systems on other microcontrollers were subjected to the same
level of scrutiny they would soon be disabled by one means or another.
Perhaps in some way they have been a victim of their own success.

Just my thoughts.

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

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

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

'What is MPASM error code 302'
1996\04\09@202628 by Wilf Melling

flavicon
picon face
I have made a start on my very first PIC project, it is to be a home
alarm system (hopefully). So here my very first plea for help, I keep
getting the following message. I have read the manuals but the answer
does not jump out at me.

Message[302] C:\MPASM\HALARM.ASM 40 : Argument out of range.  Least
significant bits used.

Code sample with line numbers:-
39        Movlw   PORT_B_OUT      ;Define PORTB
40        Movwf   TRISB           ;as output

PORT_B_OUT   EQUates to b11111111

If anyone as any tips or know of any similar projects that have code
available to look at I would be VERY grateful.

TIA


--
Wilf Melling
Tel. +44 802 633888

1996\04\09@205810 by Dave Ritchie

flavicon
face
> Message[302] C:\MPASM\HALARM.ASM 40 : Argument out of range.  Least
> significant bits used.
>
> Code sample with line numbers:-
> 39        Movlw   PORT_B_OUT      ;Define PORTB
> 40        Movwf   TRISB           ;as output
>
> PORT_B_OUT   EQUates to b11111111
>
> If anyone as any tips or know of any similar projects that have code
> available to look at I would be VERY grateful.
>
> TIA
>
>
> --
> Wilf Melling
> Tel. +44 802 633888
>

I would start by changing this constant to decimal and retrying the
assembly - the EQU function of the assembler may be getting confused
here.....

-- Dave Ritchie
former assember maintainer for HP....
spamBeGonederKILLspamspamTakeThisOuTatl.hp.com

1996\04\09@210020 by Andrew Warren

face
flavicon
face
Wilf Melling <EraseMEPICLIST.....spamKILLspamMITVMA.MIT.EDU> wrote:

> I have made a start on my very first PIC project, it is to be a home
> alarm system (hopefully). So here my very first plea for help, I
> keep getting the following message. I have read the manuals but the
> answer does not jump out at me.
>
> Message[302] C:\MPASM\HALARM.ASM 40 : Argument out of range.  Least
> significant bits used.
>
> Code sample with line numbers:-
> 39        Movlw   PORT_B_OUT      ;Define PORTB
> 40        Movwf   TRISB           ;as output
>
> PORT_B_OUT   EQUates to b11111111

Wilf:

This has nothing to do with your problem, but if you want all the
PORTB pins to be outputs, PORT_B_OUT must equate to 00000000.

Ok...

The MPASM message refers not to PORT_B_OUT but to TRISB.

If you look at the instruction set for your PIC, you'll see that
register-oriented instructions only have room for 7-bit register
addresses, so they can only address 128 registers.  To accomodate
more than 128 registers, PICs employ a banking scheme that uses a few
bits of the STATUS register to select from multiple 128-register
banks.

If you try to directly access a register in any bank other than Bank
0, MPASM won't be able to fit the register's 8-bit address into the
instruction.  Instead, it'll just use the low 7 bits of the
register's address and generate the message you're seeing.

TRISB is located at address 086H, which puts it in Bank 1.  To access
it, you need to select bank 1 (by setting the RP0 bit in the STATUS
register), then write to register 006H.  Before accessing registers on
Bank 0, you'll need to switch back to that page by clearing the
RP0 bit.  Your code should look like this:

   BSF     STATUS,RP0

       MOVLW   PORT_B_OUT
   MOVWF   080H ^ TRISB

   BCF     STATUS,RP0

The "080H ^ TRISB" exclusive-ORs the TRISB address with 080H, thereby
clearing the high bit of the address... It's equivalent to "07FH &
TRISB", "TRISB - 128", and "006H".

-Andy

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

1996\04\09@234212 by Byron A Jeff

face picon face
{Quote hidden}

That's a great explaination Andy. Now can I ask a dumb question?
The 16C84 Datasheet (and I assume the others too) state that the FSR
will utilize all 8 bits of the file address on indirection. So would
the following work?

  movlw     TRISB
  movwf     FSR
  movlw     .0     ; Note that 0 bits are required for output
  movwf     INDF

It's the same number of instructions but I find it slightly more straight-
forward personally.

BTW I just re-read the databook and in fact the IRP bit in the status
register is prepended to the FSR giving a nine bit address. So in fact
4 128 register pages are accessible using indirection. Cool.

BAJ

1996\04\10@001802 by Andrew Warren

face
flavicon
face
Byron A Jeff <PICLISTSTOPspamspamKILLspamMITVMA.MIT.EDU> wrote:

> That's a great explaination Andy. Now can I ask a dumb question? The
> 16C84 Datasheet (and I assume the others too) state that the FSR
> will utilize all 8 bits of the file address on indirection. So would
> the following work?
>
>    movlw     TRISB
>    movwf     FSR
>    movlw     .0     ; Note that 0 bits are required for output
>    movwf     INDF
>
> It's the same number of instructions but I find it slightly more
> straight- forward personally.

   Byron:

   Yes, that will work perfectly.  Keep in mind that, although it's
   no longer than the bank-switching code FOR ACCESSING ONE
   REGISTER, it's much less efficient for cases that require
   multiple register accesses.

> BTW I just re-read the databook and in fact the IRP bit in the
> status register is prepended to the FSR giving a nine bit address.
> So in fact 4 128 register pages are accessible using indirection.

   Well, yeah... If any of the 16C6x, 7x, or 8x parts had more than
   2 pages, it'd be pretty useful.

   -Andy

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

1996\04\10@132120 by John Payson

flavicon
face
> >    movlw     TRISB
> >    movwf     FSR
> >    movlw     .0     ; Note that 0 bits are required for output
> >    movwf     INDF
> >
> > It's the same number of instructions but I find it slightly more
> > straight- forward personally.
>
>     Byron:
>
>     Yes, that will work perfectly.  Keep in mind that, although it's
>     no longer than the bank-switching code FOR ACCESSING ONE
>     REGISTER, it's much less efficient for cases that require
>     multiple register accesses.

While in most cases it makes more sense to use direct addressing with RP0
set/unset as appropriate, indirect addressing can be useful when rapidly
accessing registers in both banks.  For example, if you need rapidly and
repeatedly set TRISB and PORTB, it may make sense to point FSR to TRISB, so
that it may be accessed without any intermediate accesses to RP0.  This
technique can pay off especially well when trying to rapidly read the EEPROM
on a 16C84 [point FSR to EECTRL1].

'Dallas DS 1820 Code'
1996\04\16@160211 by Peter L. Taylor

flavicon
face
-- [ From: Peter L. Taylor * EMC.Ver #2.5.02 ] --

I've been lurking several months now.  It has done me good. But now I am
actually trying to do something with a PIC.

I'm using a 16C74 in a project and was hoping someone out there had some
code that controlled the Dallas 1820 temperature sensor.  I'm using MASM, so
I would prefer MASM code.

And before anyone suggests another pet part, I need to use the 1820 for
several reasons.  The main one is that I'm pin constrained on this project,
and have one digital line to spare.

Thanks.

'Parallax code with MPSIM?'
1996\04\16@214320 by Xaq

flavicon
face
I remember a while back some people using a conversion utility to convert
Parallax code to Microchip so that they could use MPSIM.  What utility was
it, and where can I get it.  I tried PAR2PIC but that creates a .sym file
and I couldn't get that file to work with MPSIM.

Also is there any other simulators that support the '74.

Thanks for your help,

Zach

1996\04\17@044902 by Don McKenzie

flavicon
face
On Tue, 16 Apr 1996, Xaq wrote:

> I remember a while back some people using a conversion utility to convert
> Parallax code to Microchip so that they could use MPSIM.  What utility was
> it, and where can I get it.  I tried PAR2PIC but that creates a .sym file
> and I couldn't get that file to work with MPSIM.
> Also is there any other simulators that support the '74.
> Thanks for your help,

There is a file swapcode.zip 56K on the parallax site in sub-directory
/pub/pub_up which I have been told, does the job. I don't know, I am just
now downloading it. Don...

Don McKenzie spamdonmck.....spam.....labyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck
Parallax Basic Stamp-1 Compatible "PIC Basic Compiler" available soon.

'Dallas DS 1820 Code'
1996\04\17@094629 by Kalle Pihlajasaari

flavicon
face
Hi Peter,

> -- [ From: Peter L. Taylor * EMC.Ver #2.5.02 ] --
>
> I'm using a 16C74 in a project and was hoping someone out there had some
> code that controlled the Dallas 1820 temperature sensor.  I'm using MASM, so
> I would prefer MASM code.

Just got my pile of Dallas data books yesterday so cannot help you
with code samples.  There is no technical reason why you can't
do it with one interface bin and a resistor.  You will have to go this
route if you need multiple sensors on you single pin.

> And before anyone suggests another pet part, I need to use the 1820 for
> several reasons.  The main one is that I'm pin constrained on this project,
> and have one digital line to spare.

What other reasons?  There is a simple to use 1 pin device the TMP03 and TMP04
from Analog devices that will be much easier to write code for.  I have
interfaced it to a Parallax stamp II and the Assembler code will not be that
much harder, granted you need to do a 24 bit divide to get full resolution.

There are hints and tips on my project page at the following URL

http://www.ip.co.za/people/kalle/project.htm#heat

Cost of the parts about US$ 1.75 in singles.

Cheers
--
Kalle Pihlajasaari     kalle.....spamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

'[PIC]Anyone use swapcode.exe?'
1996\04\17@110832 by Xaq

flavicon
face
I tried using swapcode.exe to convert some Parallax code to MPASM.  I got
about 300 errors from swapcode.exe and then a bunch from MPASM(The code
works fine when I use the Parallax assembler).  Any hints on getting it to work?



Zach

'Errors using Swopcode'
1996\04\19@210228 by Xaq

flavicon
face
I get this error every time I try and use Swopcode:
<copied from screen>

C:\PIC>swopcode twel.lst /HS /16C74
PIC series source file bidirectional translator Version 1.02
(C) 1995 Craig Webb, licensed to PARALLAX, INC. (916) 624-8333
Translates between Parallax PASM & PASMX assemblers and Microchip's MPASM v2.0


Converting duplicate local label names...
 No duplicate local labels.

Subscript out of range in line No line number in module SWOPCODE at address 1E13
:792B

Hit any key to return to system

What is wrong?


Zach

'Pic code protection alert!'
1996\04\22@094556 by n/a

flavicon
picon face
Hi,

In a previous mail Mike Keitz made reference to "opening the package up" Is
this possible? I'm interested in super-minaturising my application - is it
possible to buy the chip slices. If not, is it possible to "open the package".
I'm thinking in terms of grinding away the majority of the epoxy resin to
leave a thin slice. Has anyone any info on this.

         Geoff.

1996\04\22@144131 by Richard Klosinski

flavicon
face
At 02:33 PM 4/22/96 LCL, you wrote:
>Hi,
>
>In a previous mail Mike Keitz made reference to "opening the package up" Is
>this possible?

yes, I works at a FAC (failure analysis of components) at HP, we did it all
the time.

I'm interested in super-minaturising my application - is it
>possible to buy the chip slices.

you can purchase pics in die form, but you will need to contact Microchip.

If not, is it possible to "open the package".
>I'm thinking in terms of grinding away the majority of the epoxy resin to
>leave a thin slice. Has anyone any info on this.

don't do it!


Rich

1996\04\23@045221 by n/a

flavicon
picon face
>>In a previous mail Mike Keitz made reference to "opening the package up" Is
>>this possible?

>yes, I works at a FAC (failure analysis of components) at HP, we did it all
>the time.

How was this done?


      Geoff.

1996\04\23@120622 by Richard Klosinski

flavicon
face
At 09:46 AM 4/23/96 LCL, you wrote:
>>>In a previous mail Mike Keitz made reference to "opening the package up" Is
>>>this possible?
>
>>yes, I works at a FAC (failure analysis of components) at HP, we did it all
>>the time.
>
>How was this done?
>
>

1) the part to be analyzed was molded with epoxy into a round cylinder, with
  the top ( or bottom in some cases) exposed. This is to add some mass to make
  the part easier to handle.

2) the glob from above is inserted into a disk sander system (note that this
  sander is not a crude as the ones bought at home depot). This runs for a
  specific time (we know from past knowledge the time). After this process, the
  die is exposed.

3) then, the not so easy part... using an electron microscope (something
  everyone has). the part was analyzed for over-something failures (this is
  a visual thing). i knew people that could reverse engineer a ic just by
  looking at the die!

Rich

1996\04\24@031432 by Prashant Bhandary

flavicon
picon face
At 02:33 PM 22/04/96 LCL, you wrote:
>Hi,
>
>In a previous mail Mike Keitz made reference to "opening the package up" Is
>this possible? I'm interested in super-minaturising my application - is it
>possible to buy the chip slices. If not, is it possible to "open the package".
>I'm thinking in terms of grinding away the majority of the epoxy resin to
>leave a thin slice. Has anyone any info on this.
>
>          Geoff.
>
>

Have you looked at the surface mount version of 16c84? Not much can be
gained by grinding that critter down! I've had this idea for a tiiiny
circuit but the challenge of taking on SMT and the lack of a cheap,
small SMD H bridge and crystal have stopped me so far.

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: KILLspamprashbspam_OUTspamrta.oz.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\04\24@085942 by myke predko

flavicon
face
I'd have to agree with Prashant.  Where I work, we have labs which do F/A on
packaged components and the technicians who do it have tricks to expose and
prove problems that border on the artistic.

When I asked one of them about decapping a component, he thought I was
asking about the Circuit Cellar project which made a CCD Camera out of a
DRAM Chip, he just smiled and said good luck.

When I explained that it was to release a chip from a package, I got a long
lecture on why this is impractical.  The biggest reason why it is
impractical is that you will probably cut the the wirebonds to the lead
frame as you shave down the package.  As somebody mentioned before, you
should look at the SMT Packages (About 0.100" above the board for the SOIC
as opposed to 0.225" for the PTH DIP) or buying the individual dies and
investing in a wire-bonder.

Sorry I don't have better news,

Myke
{Quote hidden}

Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\04\25@002434 by Eric Strauts

flavicon
face
All this discussion on "opening the package" brought to mind a
project I worked on about 20 years ago.

It involved reverse engineering where it was necessary to identify
an IC with no markings. In order to see what the chip looked
like we used an epoxy dissolver. This stuff actually broke the polymer
bonds and left only the chip with the bond wires and lead frame intact.

I don't recall if the chip was damaged by the process since this was
not a concern. Sanding the chip was considered but we had no
precision equipment to do the job.

The epoxy dissolver was a commercial product made specifically for
salvaging potted assemblies and might still be available.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Eric Strauts                         |
| TEEM Electronics                     |
| Park Ridge, IL 60068                 |
| Email: spam_OUTestrautsspamTakeThisOuTix.netcom.com        |
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

1996\04\26@012708 by Prashant Bhandary

flavicon
picon face
At 10:31 AM 24/04/96 -0400, you wrote:
>On Wed, 24 Apr 1996, Prashant Bhandary wrote:
>
>> Have you looked at the surface mount version of 16c84? Not much can be
>> gained by grinding that critter down! I've had this idea for a tiiiny
>> circuit but the challenge of taking on SMT and the lack of a cheap,
>> small SMD H bridge and crystal have stopped me so far.
>
>Use a ceramic resonator.  You can use 2 pins from 16c84 as a 20 milliamp H
>bridge.  What would you use for a tiiiny source of power and tiiiny
>motors?
>

OK, remember you asked for this :-)

A new standard, DCC, has been established for model trains. The signal is
sent through the tracks. Normally the train has connections going directly
from the tracks to the motor and you control speed and direction by
controlling the voltage on the rails. But in this case, a decoder sits
in between and decodes the packet and drives the motor appropriately.
Now the decoder should fit inside a train and the scale of the train
defines the magnitude of the problem. I model N scale which is 1:160
and believe me when I say tiiiny I mean every i in that word.

As you can guess the power supply is connected to the tracks and can be as big
as you want it. The motor is already in the train. What remains is this
small space at your disposal to squeeze a PIC and an H bridge driver. The
16C84 is ideal for this job. It even has an EEPROM which is one of the
requirements. The SMT 4Mhz part is avilable in single unit quantities locally.
So is an SMT H bridge. The other SMT parts would be a few caps and resistors
and a bridge rectifier.

The ceramic resonator seems to be a good solution. The frequency would be 4 MHZ
as I need all the speed I can get. I will look around for an SMT version. The
PIC as an H bridge driver is not an option as the motor runs at a few hundred
milliamps(paralleling the outputs isn't enough either). I have found this SMT
H bridge  a little big and is a dual. I forget the part no. and I believe it
is a 24 pin gul wing SMT. I would like to see a single H bridge which is a
little smaller and possibly cheaper.

Regards

Prashant

P.S. I am posting this to the list too to get a few hints on SMT PIC apps.
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: .....prashb.....spamRemoveMErta.oz.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\04\26@034804 by John Payson

flavicon
face
> A new standard, DCC, has been established for model trains. The signal is
> sent through the tracks. Normally the train has connections going directly
> from the tracks to the motor and you control speed and direction by
> controlling the voltage on the rails. But in this case, a decoder sits
> in between and decodes the packet and drives the motor appropriately.
> Now the decoder should fit inside a train and the scale of the train
> defines the magnitude of the problem. I model N scale which is 1:160
> and believe me when I say tiiiny I mean every i in that word.

N scale is 1/2 of HO, right?  So you're looking at putting your control in
a space about 0.4"x0.4"x0.8"?  That's not very big...

Normally my inclination for controlling a model railroad would be to use a
single power-switching transistor and a direction-switching relay.  When
space is not a problem, this will save components and may save cost (esp. if
you'd want to opto-isolate things).  In your case, however, there isn't really
room for a relay. :-(

Given that, I expect your best bet may be to produce a 3-board stack.  The
bottom board will contain two SOTs on each side; the next board would contain
the rectifier for the PIC power supply, and two SOTs (which would switch the
high-side SOT's on the bottom board).  The top board would contain the PIC and
resonator on one side, and the filter caps and regulator for the PIC's supply
on the other.  By my figuring, this should all (barely) fit in the space you
have.

My other recommendation: switch to O gauge :-)

1996\04\26@084330 by Roger Books

flavicon
face
Prashant Bhandary wrote:

>  The ceramic resonator seems to be a good solution. The frequency would
>  be 4 MHZ as I need all the speed I can get. I will look around for an
>  SMT version.

Just out of curiosity, why do you need all the speed you can get?  4 million
(minus a few for jumps) instructions per second is pretty heavy duty for
things interfacing to human times.

I'm still kicking myself for that 4MHZ crystal I bought for my electrical
scoring box for fencing.  The 4059 programmable divider won't run at 4MHZ
and +5 Volts, it looks like the 4013 will just barely run at 4MHZ and +5.
That's what happens when I come from writing data acquisition software
for FSU's accelerator and have to listen to people scream constantly about
speed.  Oh well, next one runs at 2 or even 1MHZ.

Not that that may have anything to do with your train.

Roger

1996\04\26@155348 by Mike Keitz

flavicon
face
>> A new standard, DCC, has been established for model trains. The signal is
>> sent through the tracks. Normally the train has connections going directly
>> from the tracks to the motor and you control speed and direction by
>> controlling the voltage on the rails. But in this case, a decoder sits
>> in between and decodes the packet and drives the motor appropriately.
>> Now the decoder should fit inside a train and the scale of the train
>> defines the magnitude of the problem. I model N scale which is 1:160
>> and believe me when I say tiiiny I mean every i in that word.

N scale is very small.  The cars are maybe 3 or 4 inches long.

>Normally my inclination for controlling a model railroad would be to use a
>single power-switching transistor and a direction-switching relay.  When
>space is not a problem, this will save components and may save cost (esp. if
>you'd want to opto-isolate things).  In your case, however, there isn't really
>room for a relay. :-(
>

Assuming you get to build the power supply too, feed the track with AC
(constant voltage) and (inside the train) slice either positive or negative
half-cycles depending on the direction of travel commanded.  This will
simplify things since now you only need one switch, but it has to be
bidirectional.  For low frequencies a single triac (can you get triacs small
enough?) could work, higher frequencies could use inverse-series connected
MOSFETs or something similar.   A custom drive waveform which is a square
wave with maybe 10% return to zero time inbetween half-pulses would give the
triac time to turn off and also an interval to synchronously send data in
that will be fairly free of motor noise.

If space permits, you can sense the motor voltage while the drive is off,
this will be directly proportional to the speed.  Thus a closed-loop speed
control could be implemented.

The mind boggles at the possiblities of such a setup.  Every locomotive,
switch, and lamp-post in the whole model train landscape could be connected
in parallel with two wires back to the control panel.  (Ever heard of a
"smart lamp-post"?  You will.)

-Mike

1996\04\26@192601 by John Payson

flavicon
face
> Assuming you get to build the power supply too, feed the track with AC
> (constant voltage) and (inside the train) slice either positive or negative
> half-cycles depending on the direction of travel commanded.  This will
> simplify things since now you only need one switch, but it has to be
> bidirectional.  For low frequencies a single triac (can you get triacs small
> enough?) could work, higher frequencies could use inverse-series connected
> MOSFETs or something similar.   A custom drive waveform which is a square
> wave with maybe 10% return to zero time inbetween half-pulses would give the
> triac time to turn off and also an interval to synchronously send data in
> that will be fairly free of motor noise.

Hmm... I like this idea... [pondering how much a model RR setup would cost]...
Though thinking about it, what about running the rails with Manchester-coded
data [derived using a high-current bridge and a DC supply]?  This could be
really easy (hardware) to decode (you've got a +/- 20 volt data signal)...
all you'd need to decode it would be a resistor going to a PIC port pin [RA4
would have a Shmidt trigger, but if you use that one you'd need a diode or
else tie the signal to another pin as well].

> If space permits, you can sense the motor voltage while the drive is off,
> this will be directly proportional to the speed.  Thus a closed-loop speed
> control could be implemented.

Yup, this is possible but voltage->time is a little tricky to implement nicely
on a PIC; for fast speeds it could be done (use a resistor to convert voltage
into current, and use an RC timer).  Alternatively, you might be able to AC
couple to a port pin and measure the frequency of the back-EMF waveform.

> The mind boggles at the possiblities of such a setup.  Every locomotive,
> switch, and lamp-post in the whole model train landscape could be connected
> in parallel with two wires back to the control panel.  (Ever heard of a
> "smart lamp-post"?  You will.)

The one difficulty with this approach in general would be providing a back-
signal path from the locomotive to the main CPU; perhaps there could be a
current-sinking transistor in the locomotive to send data by modulating
current.

'Reply Titles (Model RR != PIC Code Protect)'
1996\04\26@205829 by Brian Boles

flavicon
face
    Folks, could we please change the name of the model RR thread.  We
    catch enough Code Protection hassle without further populating the
    list with "Code Protection Alert!"

    Thanks, Brian.

1996\04\26@221808 by Todd Peterson

picon face
At 05:57 PM 4/26/96 -0700, you wrote:
>     Folks, could we please change the name of the model RR thread.  We
>     catch enough Code Protection hassle without further populating the
>     list with "Code Protection Alert!"
>
>     Thanks, Brian.

speaking of railroads, does anyone know a good source of information on the
"DCC" model railroad communications setup?  The magazine Model Railroader
lists several companies offering DCC-compatible equipment - it looks to be
catching on.

-todd peterson

===========================================================
*** Developers of the PICPlusú Microcontroller Board ***        

Todd Peterson, Computer Engineer   (spam_OUTtpetersonTakeThisOuTspamEraseMEnetins.net)
E-LAB Digital Engineering, Inc.          
                                         
P.O. Box 246                            
Lawton, IA 51030-0246                                      
(712) 944-5344                            
                                         
Visit us at: http://www.netins.net/showcase/elab/          
                                         
E-Mail Now for Your Free PICPlusú Information Packet!
TO: EraseMEtpetersonspamBeGonespamKILLspamnetins.net   (include POSTAL mailing address)
===========================================================


'Model RR - A DCC decoder - How to?'
1996\05\01@005008 by Prashant Bhandary
flavicon
picon face
This is addressed to all PIC gurus on the list. The application is, you
guessed it, a DCC decoder which fits inside a tiny train. I am looking
for suggestions/ideas/advice.

What's DCC
----------
It is a packet based digital standard to drive toy trains. The signal swings
between +/- 12V(or so). The signal is connected to the rails and also provides
the power. The decoder reads the signal, decodes it and changes speed,
direction, lights, etc. accordingly. Each decoder has its own address allowing
each locomotive to be individually controlled by a single signal. Assorted
accessories like turnouts, signals, etc. may be driven off the same signal.
Neat, huh?

Which CPU?
----------
The PIC 16C84 is probably the only candidate in the PIC family or probably
any other family(?) for the following reasons.
1. Size. You can't use a DIP and an 18 pin SOIC is as small as you can get.
  It is hard to squeeze in one or more support chips.
2. Data EEPROM. Settings need to be stored on power down. There isn't enough
  space for a cell. This probably eliminates every other PIC.
3. ISP. A home-built might just be a little dearer than an off-the-shelf.
  Besides the fun of developing something yourself, the other factor is that
  you can 'upgrade' the software if necessary. This eliminates all EPROM/OTP
  varieties as the OTP is unsuitable and the EPROM versions come only in DIP
  or PLCC(?) and are too big.

DCC specs
---------
A 1 is a high followed by a low between 52 and 64 us. A 0 is a high followed
by a low between 90 and 10000 us. As the polarity is not fixed, the high and
low may be reversed. i.e. a 1 may be a low followed by a high between 52 and
64us.

All commands are sent as packets. A packet consists of atleast 10 1 bits, a
0 start bit, an 8 bit address, a 0 data start bit, one or more 8 bit data bytes
separated by 0 bits, a XOR 8 bit for error correction and a 1 packet end bit.
The idle condition is all 0s(?).

If the packet address matches the decoder address, the decoder acts on it. The
speed/direction packet is the most basic. More complex packets exist for other
functions like controlling lights, sound, accelaration/deaccelaration or even
reprogramming the decoder address. Packets are periodically retransmitted.

Gory details can be found at http://www.tttrains.com/nmradcc/s91.html, s92.html,
rp911.html, rp921.html, rp922.html, rp924.html.

Decoder requirements
--------------------
The main packet is for control of motor speed and direction. The motor has
14 speeds. This is done by PWM. Other packets may be progressively implemented.

How?
----
Wish I knew. Can it be done at all? My usual ploy for reading bitstreams is to
have a periodic interrupt to sample the input. I do RS 232 using this method
with an interrupt rate of 104 us for 1200 baud input. To sample a 52us signal,
say 2 times, would give about 25 steps @ 4MHz or 60 steps @ 10MHz. The first is
just too difficult for me and the second is daunting. A counter/capture would
have been great but 16C84 cousins have already been ruled out. A Port B
interrupt may be a problem due to noise(?). One way around this could be a
40 us interrupt that enables the Port B interrupt. The Port B interrupt
disables itself and sets
off the time again. This will give the main loop quiet periods to get on
with life in general. There remains the option of a loop timed just
right which also does PWM. How difficult would this be? Are there any other
options I haven't considered? Don't tell me a device to run toy trains is too
much for a PIC or any general purpose micro to handle :-)

Misc
----
The damn things are cheap(AU$50?) and getting cheaper :-) So why build it?
Because
it is there. Because you can change the software to keep it up to date with new
packets. Because you can implement special requirements. Because using PICs
is fun.

Decoders for driving accessories don't have size restrictions and may have more
options for implementation.

The other missing bit is the control station. This could be a PC driving a PIC.
This, again, is a lesser problem and is solvable. It is also the most expensive
part of a DCC setup and is more easily justified on economic grounds.

Regards

Prashant

P.S. Looks like Digikey sells single 10 MHz SMT PIC 16C84s. Anybody know of a
source in my neck o' the woods(Australia)? The supplier here wants a minimum
order of 126 pieces and this part is not popular enough for a bulk buy. Any
suggestions, Don?
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: RemoveMEprashbspamBeGonespamspamrta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\05\01@093850 by Norm Cramer

flavicon
face
At 02:49 PM 5/1/96 +1000, you wrote:
>

[snip]

>How?
>----

Based on my command station work with DCC and PICs, I think it can be done
quite simply.  The timing is from the zero crossings.  Use the DCC signal
and set up the PIC to interrupt on port B change.  Use the timer to time the
time between interrupts.  Check the time and see if it is a one or a zero.
The code to decode the packet is pretty straight forward.  I wrote a tool in
C to test my command station implimentation.  I uses times from the MPSIM
trace file and determines if the timing is correct for the DCC signal.  It
is just a development tool but I am willing to send it to you "as is" to
show how I detected packets.  There are probably some improvements needed
but it is basically a decoder (Note that the time limits used are for the
command station, not the decoder since it is testing the command station).
I think you could do this with a 4MHz 16C84.

>Wish I knew. Can it be done at all? My usual ploy for reading bitstreams is to
>have a periodic interrupt to sample the input. I do RS 232 using this method
>with an interrupt rate of 104 us for 1200 baud input. To sample a 52us signal,
>say 2 times, would give about 25 steps @ 4MHz or 60 steps @ 10MHz. The first is
>just too difficult for me and the second is daunting.

Agreed.
>A counter/capture would
>have been great but 16C84 cousins have already been ruled out.

Agreed!!!

>A Port B
>interrupt may be a problem due to noise(?). One way around this could be a
>40 us interrupt that enables the Port B interrupt. The Port B interrupt
>disables itself and sets
>off the time again. This will give the main loop quiet periods to get on
>with life in general.

I think this is the most likely solution.  I am not sure that noise is a
problem.  Some test would tell but this is the first approach I would take.
Another solution to the noise would be to "filter" the DCC signal with
software.  i.e. ignore polarity shifts that are smaller than the DCC 1's
time.  I still think with a +- 12VDC (or more I use +-18VDC) signal, that
noise on the zero crossing should be rare.  The protocol recommends
repeating packets as frequently as possible so it may not be a problem at all.

>There remains the option of a loop timed just
>right which also does PWM. How difficult would this be? Are there any other
>options I haven't considered? Don't tell me a device to run toy trains is too
>much for a PIC or any general purpose micro to handle :-)
>

The complexity of the timed loop and syncing with the command station
(streached zeros, timing tolerances etc) could be hard.

>Misc
>----
>The damn things are cheap(AU$50?) and getting cheaper :-) So why build it?
>Because
>it is there. Because you can change the software to keep it up to date with new
>packets. Because you can implement special requirements. Because using PICs
>is fun.

All very good reasons.

>
>Decoders for driving accessories don't have size restrictions and may have more
>options for implementation.

This may be the first thing to build, then use what you learn to build the
loco decoder.  BTW I bought a decoder for $29.95 (US) to test my command
station.  It may be a little large to put into an N scale loco though.

>
>The other missing bit is the control station. This could be a PC driving a PIC.
>This, again, is a lesser problem and is solvable. It is also the most expensive
>part of a DCC setup and is more easily justified on economic grounds.
>

I am working this part of the problem and have a workable solution. (As I
described via direct e-mail to you).

Regards,

Norm

1996\05\01@184559 by Don McKenzie

flavicon
face
On Wed, 1 May 1996, Prashant Bhandary wrote:

> This is addressed to all PIC gurus on the list. The application is, you
> guessed it, a DCC decoder which fits inside a tiny train. I am looking
> for suggestions/ideas/advice.
> Regards
>
> Prashant
>lots of snips--------------------------
> P.S. Looks like Digikey sells single 10 MHz SMT PIC 16C84s. Anybody know of a
> source in my neck o' the woods(Australia)? The supplier here wants a minimum
> order of 126 pieces and this part is not popular enough for a bulk buy. Any
> suggestions, Don?

Bob Nicol of Microzed in Armidale has a bigger stock of PIC parts than I
do, although SMT may also be a problem for him. I have never stocked them
for similar reasons. If that other mob has a stock of 4Mhz versions or
you have some, you could try pushing the chip speed a little.

With DIP parts, I have the 84/04 running off an 8Mhz crystal. Take your
pick out of the box. Any piece will work. When I told Gary Barnes of
Perth WA about this he sent me a little prototype board he had made up.

It has one of those 4 pin canned oscillators (ttl characteristics) and
will run any 84/04/P at 12 Mhz!!!

If you sent a man to the moon with it, watch out for legal stuff because
of manufacturers specs., but for 'you and I' projects, who cares!, as
long as it works 100%.

As I am sure you will be up against no stock in Australia. Do what I do,
go through digikey if you really need small quantities in a hurry at a
reasonable price.

Hope this is of some help. Don...

Don McKenzie @spam@donmckspamspamlabyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

PIC Basic Compiler available now. PIC Programmers starting at $15US
PicoSaurus, the 40 pin ETI PIC Basic with 8K EEPROM Free Windows Dev Sys

1996\05\02@032454 by Prashant Bhandary

flavicon
picon face
At 08:36 AM 1/05/96 -0500, you wrote:
>
>>A Port B
>>interrupt may be a problem due to noise(?). One way around this could be a
>>40 us interrupt that enables the Port B interrupt. The Port B interrupt
>>disables itself and sets
>>off the time again. This will give the main loop quiet periods to get on
>>with life in general.
>
>I think this is the most likely solution.  I am not sure that noise is a
>problem.  Some test would tell but this is the first approach I would take.
>Another solution to the noise would be to "filter" the DCC signal with
>software.  i.e. ignore polarity shifts that are smaller than the DCC 1's
>time.  I still think with a +- 12VDC (or more I use +-18VDC) signal, that
>noise on the zero crossing should be rare.  The protocol recommends
>repeating packets as frequently as possible so it may not be a problem at all.

The noise causing packets to be lost is not the problem. It may cause the
interrupt to be called too frequently to allow the main loop to run at all.
Filtering it out will still deprive the main loop its chance to run. The
main worry is it may interfere with the PWM. Noise would be due to dirty
track resulting in the signal dropping back to 0 intermittently. Pure +ve
to -ve transitions are hard to differentiate from drop to 0 without some
external components. So, whenever the train hits a dirty patch on the track,
it will mess up the PWM and falter. Hence my suggestion to block out
transitions for 40 us after a valid state change.

One possible way of differentiating between + to - transition and drops to
zero would be to use two inputs and do differential sensing in software.

The right place to do the PWM is another problem. PWM in the ISR can make
the ISR too long(?). Doing it in the main loop using the timer as a running
counter is an option.

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: TakeThisOuTprashbKILLspamspam@spam@rta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

'Pic code protection alert!'
1996\05\02@035401 by Mike Sunners

flavicon
face
On Fri, 26 Apr 1996, Prashant Bhandary wrote:

> A new standard, DCC, has been established for model trains. The signal is
> sent through the tracks. Normally the train has connections going directly
> from the tracks to the motor and you control speed and direction by
> controlling the voltage on the rails. But in this case, a decoder sits
> in between and decodes the packet and drives the motor appropriately.
> Now the decoder should fit inside a train and the scale of the train
> defines the magnitude of the problem. I model N scale which is 1:160
> and believe me when I say tiiiny I mean every i in that word.

 Unlimited possibilities! Multiple trains on a track. Collision detection.
Trains talking to trains. Trains talking to signals. Signals talking to
trains. Signals talking to signals. Trains switching points. Signals
switching points. Power down features. ... :-)
________________________________________________
Mike Sunners <.....mikesRemoveMEspamcaa.org.au> W +61 8 223 2519

'Model RR and DCC(was Re: Pic code protection alert'
1996\05\02@041934 by Prashant Bhandary

flavicon
picon face
At 09:22 AM 2/05/96 +0930, you wrote:
>  Unlimited possibilities! Multiple trains on a track. Collision detection.
>Trains talking to trains. Trains talking to signals. Signals talking to
>trains. Signals talking to signals. Trains switching points. Signals
>switching points. Power down features. ... :-)
>
Some of it is possible. Note that comms is just one way - one command control
station to many trains or accessories. Limited feedback is possible.

Multiple trains on a track - Definitely yes. This is what it's all about.
Collision detection - How? Do you mean packet collision which is just a comms
 thing or the type resulting in assorted bits of metal and plastic?
Trains talking to trains. Trains talking to signals. Signals talking to
trains. Signals talking to signals. Trains switching points. Signals
switching points. - Nope. This is one of my biggest gripes with DCC. Limited
 talkback capability.

Power down features. ... :-) Huh?

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: KILLspamprashbspamTakeThisOuTrta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

'Model RR - A DCC decoder - How to?'
1996\05\02@091003 by Norm Cramer

flavicon
face
At 05:24 PM 5/2/96 +1000, you wrote:

[snip]

>The
>main worry is it may interfere with the PWM. Noise would be due to dirty
>track resulting in the signal dropping back to 0 intermittently. Pure +ve
>to -ve transitions are hard to differentiate from drop to 0 without some
>external components. So, whenever the train hits a dirty patch on the track,
>it will mess up the PWM and falter. Hence my suggestion to block out
>transitions for 40 us after a valid state change.
>

Oops, haden't thought about the dirty track problem.  I like the
differential sensing approach and a block out for 40 usec should provide
"main loop" processing time.  At what rate do you want to do the PWM to the
motor?  If it is low enough, this approach should work.

>One possible way of differentiating between + to - transition and drops to
>zero would be to use two inputs and do differential sensing in software.
>
>The right place to do the PWM is another problem. PWM in the ISR can make
>the ISR too long(?). Doing it in the main loop using the timer as a running
>counter is an option.

What I have done in the command station to get it to fit into the 16c84 is
add a second timer in software that counts in 58usec intervals.  It's not
accuracte enough for PWM but works great for key debounce and autorepeate.
Depending on the PWM period, you may be able to just increment a counter
every time the timer isr happens. (Note 58usec is the 1's time) The command
station uses tmr0 to generate the DCC signal.


Another question to address is how to convert the PIC output level to a
voltage to run the motor in such a small space?  This doesn't need to be
solved yet but any ideas from the group would be usefull for planning.

How small does the decoder have to be?  The one I am using is about 1" x
3/4" and fits OK in an HO scale locomotive (HO SCALE is 87:1) but won't fit
in N scale (160:1).

Regards,

Norm

1996\05\02@124714 by Martin J. Maney

flavicon
face
On Thu, 2 May 1996, Prashant Bhandary wrote:

> track resulting in the signal dropping back to 0 intermittently. Pure +ve
> to -ve transitions are hard to differentiate from drop to 0 without some
> external components. So, whenever the train hits a dirty patch on the track,

If you can spare RA4 and one other I/O pin I think you could do this with
nothing but a couple of resistors and diodes (at least some of which you
would need to get the +-V into the PIC anyway).  RA4 because it has a
Schmitt trigger, and if the thresholds are stable enough and you fiddle
with the biasing that could possibly be enough all by itself.  But for
the cost of one more pin and a resistor you can add some
software-controlled hysteresis to what RA4 already provides.  This was my
first thought, since the input thresholds for the Schmitt input at RA4
are only rather loosely spec'd.  Looking at it again (in the table in
11.3 of the spec sheet), it's not even clear which side of the curve
those numbers are supposed to represent.

'WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED P'
1996\05\03@233219 by PETE KLAMMER

flavicon
face
> Date: Fri, 03 May 1996 18:17:00 -0700 (PDT)
> From: Eric Smith <TakeThisOuTericspamspam_OUTGOONSQUAD.SPIES.COM>
> Subject: Re: Windowed PIC16C622
>
> Kim Cooper of Microchip wrote:
> > Sorry, ocde protect on the newer devices, the PIC16C622 included, is
> > permanent.
>
> This is really disastrous, as sometimes the code protect bit is set
> erroneously by the programmer.  I've seen this happen on both the PICSTART
> and the Parallax programmers.  Maybe it's really a design defect in the
> device?  Anyhow, two out of five of my windowed '622 parts are now only
> suitable to be used as jewelry.
>
> Eric

I agree; they changed the rules without telling us.  There should be a
bright RED warning label on every new windowed PIC:
  WARNING: USING CODE-PROTECT ON THIS PART MAY BE BAD FOR ITS HEALTH!

I learned the hard way with a couple dearly-needed, direly-begged,
and painfully-lost 17C44 early engineering samples.  I got one shot of code
in each -- ``Wot!  OTP parts with windows!!?'' -- and now one is a doorstop
and the other is a paperweight.

I understand what Microchip did, but I still don't like it.  They put the
code-protect fuse (or *one* of them, anyway) under metalization, so it is
UV-proof.  The reason being, that the same dice are used for windowed or OTP
production parts, and Microchip wanted to thwart a certain kind of hacking:
popping the lid off an OTP and then selectively erasing just the
code-protect bit(s).  Worthy justification, I guess.  But even if I am smart
and careful enough to never leave embedded code-protect fuse settings in my
development code, its an inconvenience to have to either build different
files for development and production, without and with embedded fuse
settings, or else rely on manufacturing personnel to always remember to set
the code-protect fuse at the programming station.  Either way, it's an
invitation to forget one way or the other, and either accidentally lock up a
windowed part, or accidentally release unprotected code.

In truth, I have greater luxury than I admit: I use the PicMaster (ICE) for
most of my development, and -- SO FAR -- it hasn't become permanently
locked when I download code-protected hex files into it.

Peter F. Klammer, Racom Systems Inc.                   RemoveMEPKlammerspamspamSTOPspamACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1996\05\05@164114 by Przemek Klosowski

flavicon
face
Peter F. Klammer wrote

  I understand what Microchip did, but I still don't like it.  They put the
  code-protect fuse (or *one* of them, anyway) under metalization, so it is
  UV-proof.  The reason being, that the same dice are used for windowed or OTP

I believe that E(E)PROM cells can also be erased by soft Xrays. The problem
with Xrays is that they are 10-50 times more energetic than UV (UV quanta
by definition have energies in the range between 3 and 200 eV, and Xrays
are above that, with most typical Xray generators using 5,000-50,000 eV).
Thus, Xrays can induce radiation damage in the semiconductor, so you have to
be very careful with the dose. On the other hand, a little metalization won't
prevent the erasure by Xrays.

I suppose that a friendly dentist or crystallographer would let someone use
their Xray machine; would someone be willing to experiment a little with
the times necessary?

       p

1996\05\05@204255 by John Payson

flavicon
face
> I believe that E(E)PROM cells can also be erased by soft Xrays. The problem
> with Xrays is that they are 10-50 times more energetic than UV (UV quanta
> by definition have energies in the range between 3 and 200 eV, and Xrays
> are above that, with most typical Xray generators using 5,000-50,000 eV).
> Thus, Xrays can induce radiation damage in the semiconductor, so you have to
> be very careful with the dose. On the other hand, a little metalization won't
> prevent the erasure by Xrays.
>
> I suppose that a friendly dentist or crystallographer would let someone use
> their Xray machine; would someone be willing to experiment a little with
> the times necessary?

This would leave us back at square 1 it seems, in terms of security (though
no worse than many other OTP micros).  On the other hand, if X-rays work,
OTP's could be used as EPROMs :-)

Anyway, here's the idea I was thinking of for code-protect: rather than using
a "fuse" (EPROM location), why not have a RAM flag [i.e. latch] for that
purpose?  Require that in order for programming or reading to be performed
on the device, the PC must first feed the device a copy of the program within
it.  Have this behavior apply regardless of whether a "code-protect" flag is
set or not (there wouldn't have to be a code-protect flag).

While some care would need to be taken to prevent an unscrupulous person from
glitching the RAM flag, these semantics would allow a device with known cont-
ents to be verified (or programmed more) and a blank device (whose contents
are known implicitly) to be programmed and verified.

What do people think of this idea?

'Model RR - A DCC decoder - How to?'
1996\05\06@042152 by Prashant Bhandary

flavicon
picon face
At 08:05 AM 2/05/96 -0500, you wrote:
>Another question to address is how to convert the PIC output level to a
>voltage to run the motor in such a small space?  This doesn't need to be
>solved yet but any ideas from the group would be usefull for planning.
>
That shouldn't be difficult. I have envisaged two approaches. Use an H bridge
chip. One candidate which is available locally in one-ofs is UDN2916EB. This is
a 24 pin gull wing SMT. It has a lot more than I want - it is a dual H bridge
and has some current PWM circuitry. I would like to find a smaller single H
bridge.
The other alternative is to use 4 PIC outputs to drive a bridge. This will need
4 transistors+4resistors+4 diodes/1 bridge rectifier. This may even be smaller
and definitely cheaper than the single chip solution. Ordinary SMT components
are available at surplus stores at throwaway prices.

What are you using in your command station?

>How small does the decoder have to be?  The one I am using is about 1" x
>3/4" and fits OK in an HO scale locomotive (HO SCALE is 87:1) but won't fit
>in N scale (160:1).
>

I don't know the exact dimensions but I am looking at building it first in HO
and then move to N. Some commercial decoders for N are in two parts to make
installation easier. The N scale loco I have got seems to have enough space for
a decoder about 3/4" x 3/4" x 1/4".

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: .....prashbEraseMEspamrta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\05\06@092805 by Norm Cramer

flavicon
face
At 06:21 PM 5/6/96 +1000, you wrote:
>
>What are you using in your command station?
>

The command station is currently using a power op-amp made by SGS Thomson,
part L165.  It is only rated at 3A.  I will be switching to a full H bridge
using discreet n-chan mosfets and a fet-driver to get more current.  The
power op-amp might be a good approach for the decoder.  The disadvantage for
a command station is it needs a bipolar supply.  The decoder inherently has
a bipolar supply from the rails.  The only package information I have is a
TO-220 style case.  There may be a surface mount power op-amp out there
somewhere.  It's easy to get the op-amp to do bipolar but a little harder to
do PWM.  I haven't thought about how to make it do PWM, but it shouldn't be
too hard.


Regards,

Norm

1996\05\06@220712 by Prashant Bhandary

flavicon
picon face
At 08:24 AM 6/05/96 -0500, you wrote:
>The command station is currently using a power op-amp made by SGS Thomson,
>part L165.  It is only rated at 3A.  I will be switching to a full H bridge
>using discreet n-chan mosfets and a fet-driver to get more current.  The
>power op-amp might be a good approach for the decoder.  The disadvantage for
>a command station is it needs a bipolar supply.  The decoder inherently has
>a bipolar supply from the rails.  The only package information I have is a
>TO-220 style case.  There may be a surface mount power op-amp out there
>somewhere.  It's easy to get the op-amp to do bipolar but a little harder to
>do PWM.  I haven't thought about how to make it do PWM, but it shouldn't be
>too hard.

As you mentioned, power op amps need a bipolar supply which is a pain. Besides,
you aren't using the linear part. Single chip H bridges are easily available
which
make using discrete solutions unecessary. I don't know about the cost factor
though.
For example, the SGS Thomson L298 should give you enough juice. I don't remember
the rating but should be around 4A. It costs about AU$25. I remember seeing it
being used in a DCC station circuit and can dig it out for you if you like. For
low power applications I use a L293 rated at 600ma/1A. You get two in a 16/20
pin
DIP. I've used it to drive a stepper off a PC parallel port.

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: spamBeGoneprashbspamRemoveMErta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

'WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED P'
1996\05\08@143755 by PETE KLAMMER

flavicon
face
> Date: Sun, 05 May 1996 19:42:41 -0500
> From: John Payson <.....supercatEraseMEspamMCS.COM>
> Subject: Re: WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED PARTS
>
> Anyway, here's the idea I was thinking of for code-protect: rather than using
> a "fuse" (EPROM location), why not have a RAM flag [i.e. latch] for that
> purpose?  Require that in order for programming or reading to be performed
> on the device, the PC must first feed the device a copy of the program within
> it.  Have this behavior apply regardless of whether a "code-protect" flag is
> set or not (there wouldn't have to be a code-protect flag).
>
> While some care would need to be taken to prevent an unscrupulous person from
> glitching the RAM flag, these semantics would allow a device with known cont-
> ents to be verified (or programmed more) and a blank device (whose contents
> are known implicitly) to be programmed and verified.
>
> What do people think of this idea?

You would have to be sure that the part did not ``betray'' where the
mismatch occurred, so that incremental trial-and-error contents guessing
would not work.

For reading a part, this seems pointless.  But for verification, it is
better than the scrambled-signature bytes we get now: send in a whole second
copy of the program, which is compared internally, without betrayal of where
any mismatch occurs, and return a single ``yes'' or ``no''.  In fact, who
needs readout capability at all (who ever ``forgot'' what hex file is stored
in a programmed part?).  Why not make PIC code (E)PROM write-only?  (from the
point of view of pins or pads, of course.)

Code-protection must also defeat another mechanism: incremental bit-burning.
Suppose location 0000 in a protected part contains FFF2, and when you read
it you get the scrambled signature C6C6 (I'm making this up).  Then you
attempt to burn location 0000 with FFFE, and read back, and nothing has
changed: bit 0 was already 0.  Then you attempt to burn location 0000 with
FFFD, and read back, and the signature changed to B2B2 (or whatever).  That
tells you bit 1 must have been a 1; you just cleared it.  The code-protect
fuse should prevent this (does it?).

Peter F. Klammer, Racom Systems Inc.                   spamPKlammerspam_OUTspam@spam@ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1996\05\08@153152 by Andrew Warren

face
flavicon
face
PETE KLAMMER <spamPICLIST@spam@spamSTOPspamMITVMA.MIT.EDU> wrote:

> Code-protection must also defeat another mechanism: incremental
> bit-burning. ....  The code-protect fuse should prevent this (does
> it?).

Not on the first 64 bytes of the original 16C5x parts, Pete.

-Andy

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

1996\05\08@165312 by Eric T. Brewer

flavicon
face
At 12:37 PM 5/8/96, PETE KLAMMER wrote:
{Quote hidden}

I think a best of both world situation would be to have two bits. The first
bit is a ReadWrite/*WriteOnly mode bit. Once cleared, the bit cannot be set
by being erased (as the code protect bit is today with having metal over
the EPROM
cell). This allows the code array to be read during testing at the factory
or by a
programmer.

The second bit would be a Verify/*NoVerify bit. Once cleared, the array can
no longer
be verified, but the bit can be set via UV erasure. If the bit is set, the
array can be
verified by entering verify, setting the PC to 0, sending all of the code
for the code array
to the PIC and then reading a Yes/No result. Failure to sequence through
all of the
code space will result in a No response.

Given this, a part can have the ReadWrite/*WriteOnly bit accidentally
cleared without
making the part into jewelry. The part is very secure. A person trying to
"crack" it
would have to set the Verify/*NoVerify bit, then send 512x12 words of data
to a 16c54,
and then see if it verified. If they are one bit off in the 6144 bit
sequence, they get back a
No. If they don't sequence through all of the code array, they get a No.
This means
they have 2^6144 combinations to try. The average case would be 2^3072.
That is pretty
damn secure. You couldn't cycle through that number of combinations in a
number of
lifetimes!

I would put forth, that the average company would leave the the Verify/*NoVerify
alone as the part is already secure enough. By not clearing the bit, it
allows for some
failure analysis to be done when you get a bad part back. Since you have
the code
which is supposed to be programmed into the part, you can verify the part
still has the
correct code. If it does not, you still do some simple checks such sequence
through 512
different verify operations with successive words of code being zero. If
you got a Yes,
then you know a location got zapped somehow. You could check to see if the whole
part got zapped. You could see if a column of bits are zapped. Anyways, you
get the
idea.

You might ask why even have a Verify/*NoVerify bit. You don't have to. It is for
the extra paranoid companies out there! I certainly wouldn't need it.

cheers,
eric

PS. I haven't seen this in practice or print anywhere before. If someone
actually
implements this, they should give credit (Peter and myself) where credit is
due! Not
asking for royalties or anything, just a fleeting glimpse of fame!

'GUARANTEED CODE PROTECTION'
1996\05\24@155630 by rdmiller

picon face
On Fri, 24 May 1996, Eric T. Brewer wrote:
> At 8:32 AM 5/23/96, John Payson wrote:
[...]
> >[2] too much voltage on a port pin, with current to back it up [e.g. rect-
> >    ified raw power line--170v DC!]  Note: even this didn't blow up the whole
> >    chip--just the affected port pins.  Unfortunately, blowing up PB7 leaves
> >    the chip's code in a somewhat permanent state (the code that was in there
> >    still ran, but there was no way to change it)
>
> Sounds like a good way to really code protect your devices! Just blow away
> PB6 and PB7 on the newer (ISP) devices! ;)

Now we have an answer for the truly paranoid.
One hundred percent code protection, guaranteed.

Rick Miller

1996\05\24@175838 by Eric T. Brewer

flavicon
face
At 12:56 PM 5/24/96, Rick Miller wrote:
>On Fri, 24 May 1996, Eric T. Brewer wrote:
>> At 8:32 AM 5/23/96, John Payson wrote:
>[...]
>> >[2] too much voltage on a port pin, with current to back it up [e.g. rect-
>> >    ified raw power line--170v DC!]  Note: even this didn't blow up the
>>whole
>> >    chip--just the affected port pins.  Unfortunately, blowing up PB7 leaves
>> >    the chip's code in a somewhat permanent state (the code that was in
>>there
>> >    still ran, but there was no way to change it)
>>
>> Sounds like a good way to really code protect your devices! Just blow away
>> PB6 and PB7 on the newer (ISP) devices! ;)
>
>Now we have an answer for the truly paranoid.
>One hundred percent code protection, guaranteed.
>
>Rick Miller

Almost perfect. Someone can still use invasive techniques on the chip to
get a the code. This is what chip companies do. They take electron micrographs
of the chip and figure out the circuits. They can also probe the part to figure
out what bits are set to what. The downside, is the patient dies in the process!

But all in all, I think it is pretty good if you don't mind losing a port
pin or two!

eric

1996\05\24@181136 by Eric Smith

flavicon
face
On Fri, 24 May 1996, Eric T. Brewer wrote:
> Sounds like a good way to really code protect your devices! Just blow away
> PB6 and PB7 on the newer (ISP) devices! ;)

Rick Miller <spam_OUTrick@spam@spamDIGALOGSYS.COM> replied:
> Now we have an answer for the truly paranoid.
> One hundred percent code protection, guaranteed.

Not guaranteed.  There is at least one company in the UK (I forgot the
name, saw an ad a few months back in Nuts & Volts) that dumps PIC code
by deencapsulating the chip.  My guess is that they mask most of the chip
and UV erase the code protect cell (which won't work on newer PIC that have
the code protect cell covered by metallization).  But if they deencapsulate
the chip it is a small step for them to also do wafer probing to bypass the
blown I/O port or otherwise tap internal circuit nodes.

There is nothing that can be done to guarantee code protection short of not
programming the code into a part in the first place.

This technique might be useful on the '84 to thwart the published techniques.
However, even if the only obvious damage to the part is a failure of PB6
and PB7, the reliability of the entire part is suspect at best.  As with
overclocking, it would be very bad engineering practice to do this in an
an actual product.

For many (but by no means all) PIC applications I have seen, it is
sufficiently easy to determine what the PIC software does that it would be
more cost effective for me to write equivalent code from scratch rather than
send a locked PIC off to a company specializing in extracting protected code.

As an example:

Malik Dad previously asked how to extract code from a protected 16C54
used in a Sony PlayStation modification that circumvents the country code
restrictions.  I suspect that some clever engineer went to a lot of work
to reverse engineer the relevant part of the behavior of the PlayStation.

But I'd be willing to bet that a good engineer with one of the modified
PlayStations could easily figure out the behavior of the PIC and write
equivalent code from scratch in much less time than was required for the
original design.

If anyone wants to give me a modified PlayStation, I'd be willing to give
it a try :-)

Cheers,
Eric

'16C622 code protect "List of devices"'
1996\05\26@041200 by Newfound Electronics

flavicon
face
G'day all,

I've been off the piclist lately but found this in the 9605 log
and I see this question on non eraseable code protect devices
is so far answered.


Eric T. Brewer wrote
[
>
>Would you please provide a list of such devices?

>Thanks,
>eric

]

Eric,

All the following "A" suffix devices are "no erase" code protect
devices.

16C62A
16C64A
16C65A
16C73A
16C74A

The following three are effectively "A" revisions but they do not
have the "A" suffix. (It is likely revisions for these parts will
start with the "B" suffix.)

16C63
16C72
16C620
16C621
16C622

I strongly suspect these devices should be on the list
but don't know for certain (yet!):

16C70
16C71A

In the future there maybe a 16C61A and 16C60 also.
(My guess)

Misc others are:

PIC14000
PIC17C43
PIC17C44

It is a fair bet all "JW" devices from now on will have "no-erase"
code protection except for the 5x devices.

As far as I can tell none of the planned 5x "JW" revisions have
"no-erase" code protection.

In addition to "no erase" code protection, all the above devices
have the state of the PWRTE config bit reversed from earlier
devices. This means the PWRTE is different going from a 16C74
to a 16C74A.

No need to worry though if you use the correct header file for
the target PIC.



Jim Robertson
NEWFOUND ELECTRONICS

P.S. From version 3.05 onwards, my warp-3 will not allow "accidental"
programming of the code protection fuses even if they are on in the
HEX file. Use the /L- switch to bypass this safety.

1996\05\26@043728 by Don McKenzie

flavicon
face
On Sun, 26 May 1996, Newfound Electronics wrote:
> In addition to "no erase" code protection, all the above devices
> have the state of the PWRTE config bit reversed from earlier
> devices. This means the PWRTE is different going from a 16C74
> to a 16C74A.
>
> No need to worry though if you use the correct header file for
> the target PIC.

> Jim Robertson
> NEWFOUND ELECTRONICS
>
> P.S. From version 3.05 onwards, my warp-3 will not allow "accidental"
> programming of the code protection fuses even if they are on in the
> HEX file. Use the /L- switch to bypass this safety.

Now there's a nice safety lock Jim. When is the Warp-3 V3.05 available?

Don McKenzie TakeThisOuTdonmckspam_OUTspamlabyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

PIC Basic Compiler available now. PIC Programmers starting at $15US
Pic-Axe. The Tool for breaking new ground.

'DTMF decoder on pic'
1996\05\31@105826 by CDSI

flavicon
face
  I am looking for code to decode DTMF signals on a pic chip.  Any help
would be greatly appreciated.      John Moeller

'GUARANTEED CODE PROTECTION'
1996\05\31@115249 by Pedro Polonia

flavicon
face
Attachment converted: wonderlandthree:_tar.863.Re__GUARANTEED_COD (????/----) (000043E4)


'codecs'
1996\06\01@124112 by Stuart Allman
flavicon
face
I have yet another dilema to pose.  I need to have two A/D's and four D/A's
on this project.  I was thinking about using two codecs, but I can't find
one that meets or beats high end audio needs.  It seems like most of them
are made for computer related audio where noise level is not a priority.
When I amplify the signal to 100 watts this will be a real problem for me.

Does anyone have any recommendations on parts I could use with a 2101 or
2105 DSP.  I've heard that Crystal makes some really nice Codecs that could
meet CD quality standards.  Price is not the main issue, but no $100 parts
please, I'm still a student.

Stuart Allman
Studio Sound Design
KILLspamstudio.....spamTakeThisOuThalcyon.com

'Sharing code with PICLIST members'
1996\06\03@060635 by David Tait

flavicon
face
Wynn Rostek wrote:

> I can send code if anyone is really interested.

If, like Wynn, anyone has some PIC-related code they want to share,
please feel free to send me a copy via e-mail (as a MIME enclosure or
UUencoded) and I'll make it available on my FTP area:

ftp://ftp.mcc.ac.uk/pub/micro-controllers/PIC

Please warn me if you are going to send large (> few hundred K) files.

David
--
TakeThisOuTdavid.taitEraseMEspamRemoveMEman.ac.uk

1996\06\03@082752 by Wynn Rostek

flavicon
face
At 11:09 AM 6/3/96 +0100, you wrote:
>Wynn Rostek wrote:
>
>> I can send code if anyone is really interested.
>
>If, like Wynn, anyone has some PIC-related code they want to share,
>please feel free to send me a copy via e-mail (as a MIME enclosure or
>UUencoded) and I'll make it available on my FTP area:
>
>ftp://ftp.mcc.ac.uk/pub/micro-controllers/PIC
>
>Please warn me if you are going to send large (> few hundred K) files.
>
>David
>--
>spam_OUTdavid.taitRemoveMEspam.....man.ac.uk
>
>

; FILE: bunny.asm
;
; 11/30/95 Started work on this file     ...WAR...
;
; Simple bunny controller for 16C84




; Assemble with MPASM /e /l /rDEC /p16C84 bunny.asm




       include "p16cxx.inc"
       include "p16cxxd.inc"




; Set config fuses to 0x1a
;
; HS oscillator (6 MHz Xtal)
; Watchdog timer disabled
; Power-up timer enabled
; Code protection off




; For code at 10 WPM, each unit is 120 milliseconds long.
; This is 90 cycles of a 750 Hz tone.




; our variables
cnt     equ     0x0c
cyc     equ     0x0d
units   equ     0x0e
tmp     equ     0x0f




       org   0x000         ; The main line code starts here

; First we do all required initialization

Start

; Set port A as output
       bsf     STATUS,RP0      ;Bank 1
       movlw   0
       movwf   TRISA

; Enable port B pullups
       bcf     OPTION_REG,NOT_RBPU

; Switch back to bank 0
       bcf     STATUS,RP0      ;Bank 0

; Ready for main loop
Top
       bsf     RA1     ;key the transmitter

       movlw   41      ;wait 5 seconds
       movwf   units
       call    dlunit

       call    id      ;send ID

       movlw   131     ;wait 15.75 seconds
       movwf   units
       call    dlunit

       call    id      ;send ID

       movlw   41      ;wait 5 seconds
       movwf   units
       call    dlunit

       bcf     RA1     ;unkey the transmitter

       movlw   250     ;wait 60 seconds
       movwf   units
       call    dlunit
       movlw   250
       movwf   units
       call    dlunit

       goto    Top




; Send an ID message
id      call    dash
       call    dot
       call    dot
       call    spc
       call    dot
       call    ps
       call    dot
       call    dash
       call    dash
       call    spc
       call    dash
       call    dot
       call    dot
       call    dot
       call    spc
       call    dot
       call    dot
       call    dot
       call    dot
       call    dash
       call    spc
       call    dash
       call    dash
       call    dot
       call    dot
       call    spc
       call    dot
       call    dot
       call    dash
       call    spc
       call    dash
       call    dot
       call    dash
       call    dash
       call    ps
       call    dot
       call    dot
       call    dash
       call    dot
       call    spc
       call    dash
       call    dash
       call    dash
       call    spc
       call    dash
       call    dot
       call    dot
       call    dash
       call    ps
       return




; Send a dot
dot     movlw   1
       movwf   units
       call    tnunit
       movlw   1
       movwf   units
       call    dlunit
       return




;Send a dash
dash    movlw   3
       movwf   units
       call    tnunit
       movlw   1
       movwf   units
       call    dlunit
       return




;Finish a space
spc     movlw   2
       movwf   units
       call    dlunit
       return




;Finish a pause
ps      movlw   6
       movwf   units
       call    dlunit
       return




; Delay units * 90 cycles of 750 Hz tone
dlunit  movlw   90
       movwf   cyc
dlhi    nop
       bcf     RA0             ;set tone bit low
       call    haf             ;wait a bit

       nop                     ;waste 8 cycles for symmetry
       movlw   2
       movwf   tmp
dlmid   decfsz  tmp,1
       goto    dlmid

       bcf     RA0             ;set tone bit low
       call    haf             ;wait a bit

       decfsz  cyc,1           ;one less cycle to send
       goto    dlpad           ;do another cycle

       decfsz  units,1         ;Another unit done
       goto    dlunit
       return

dlpad   nop                     ;4 cycles for padding
       nop
       goto    dlhi




; Send units * 90 cycles of 750 Hz tone
tnunit  movlw   90
       movwf   cyc
tnhi    nop
       bsf     RA0             ;set tone bit high
       call    haf             ;wait a bit

       nop                     ;waste 8 cycles for symmetry
       movlw   2
       movwf   tmp
tnmid   decfsz  tmp,1
       goto    tnmid

       bcf     RA0             ;set tone bit low
       call    haf             ;wait a bit

       decfsz  cyc,1           ;one less cycle to send
       goto    tnpad           ;do another cycle

       decfsz  units,1         ;Another unit done
       goto    tnunit
       return

tnpad   nop                     ;4 cycles for padding
       nop
       goto    tnhi



; delay for half a cycle of 750 Hz

; A 750 HZ tone is 1.333333 milliseconds
; in duration.  This means each half cycle
; of the tone is 666.6666 microseconds.
; Since I'm using a 6.0 MHz Xtal, this
; is 1000 CPU cycles per tone half cycle.

; Since the routine that calls this to generate
; the tone takes 11 CPU cycles per Tone half
; cycle, we need to burn up 989 CPU cycles
; in this routine.

; This routine takes 13 + ((K -1) * 4) cycles
; where K is the argument for the movlw
; instruction.

haf
       nop
       nop
       nop
       movlw   245
       movwf   cnt
luphaf
       nop
       decfsz  cnt,1
       goto    luphaf
       goto    lupxt
lupxt   nop
       return




       end








; FILE: ddf1.asm




; Ducky direction finder controller for 16C84




;
; 12/07/95 Started work on this file     ...WAR...
;




; Assemble with MPASM /e /l /rDEC /p16C84 ddf1.asm




; RA0/RA1 are used to drive antenna switching.
; RA2/RA3 are used to drive phase indicators.
; RA4 is the audio input.




       include "p16c84.inc"




; Set config fuses to 0x1a
;
; HS oscillator (6 MHz Xtal)
; Watchdog timer disabled
; Power-up timer enabled
; Code protection off




; with a 6 Mhz  Xtal, each cycle is 66.667 usec long
; for a basic 400 Hz tone, the cycle is 2.5 msec.
; This means a half cycle is 1.25 msec, or 1875 CPU cycles.




; our variables
cnt     equ     0x0c
tmp     equ     0x0d




       org   0x000         ; The main line code starts here

; First we do all required initialization

Start

; Set low nybble of port A as output
       bsf     STATUS,RP0      ;Bank 1
       movlw   0xf0
       movwf   TRISA

; Switch back to bank 0
       bcf     STATUS,RP0      ;Bank 0

; Ready for main loop
Top     bsf     PORTA,0         ;Turn right antenna on
       bcf     PORTA,1         ;Turn left antenna off
       bcf     PORTA,2
       btfsc   PORTA,4
       bsf     PORTA,2
       call    haf             ;wait a bit
       nop                     ;Burn 2 cycles for symmetry
       nop
       bsf     PORTA,1         ;Turn left antenna on
       bcf     PORTA,0         ;Turn right antenna off
       bcf     PORTA,3
       btfsc   PORTA,4
       bsf     PORTA,3
       call    haf             ;wait a bit
       goto    Top




; delay for half a cycle of 400 Hz.

; A 400 HZ tone is 2.5 milliseconds
; in duration.  This means each half cycle
; of the tone is 1.25 milliseconds.
; Since I'm using a 6.0 MHz Xtal, this
; is 1875 CPU cycles per tone half cycle.

; Since the routine that calls this to generate
; the tone takes 9 CPU cycles per Tone half
; cycle, we need to burn up 1866 CPU cycles
; in this routine.

; This routine takes 10 + ((K - 1) * 16) cycles
; where K is the argument for the movlw
; instruction.

haf

; we need an extra 4 cycles of padding
; to get the time to come out right
       nop
       nop
       nop
       nop

; now we run the main loop 116 times

       movlw   117
       movwf   cnt

hafl    decfsz  cnt,1
       goto    dowt
       return

dowt    call    dly
       goto    hafl




; Burn up 9 cycles.

dly     movlw   2
       movwf   tmp
dlp     decfsz  tmp,1
       goto    dlp
       return




       end
Wynn Rostek
spamwarKILLspamspamKILLspampalmnet.net
spamwynnspam_OUTspampitcairn.ksc.nasa.gov
STOPspamwynn.rostekspam_OUTspamspamBeGoneksc.nasa.gov

Other Email addresses available if you really need 'em...

1996\06\03@124219 by David Tait

flavicon
face
Sorry, I meant send the code as _private_ e-mail :-).  Thanks anyway.

So far I have Wynn Rostek's files, Daniel Henzulea's "sonapic" package
and Bojan Dobaj's crippleware that recently turned up on the PICLIST
(plus some other stuff related to PIC programming).  If you are
thinking of adding to the collection it would be a good idea to
include a short description of what your code does or at least a
one-line description to update my table of contents.

David
--
spam_OUTdavid.taitspamspamBeGoneman.ac.uk
ftp://ftp.mcc.ac.uk/pub/micro-controllers/PIC
http://www.man.ac.uk/~mbhstdj/piclinks.html

'Code protect and the 16C74/JW'
1996\06\10@230025 by Robert Ct

flavicon
face
I am relatively new to the work of PIC and after having played around with
the 16c84 successfully, I decided to try my hand at the 16C74/JW.  Last
night, while trying out Bojan Dobaj shareware programmer, I selected Code
Protect ON - from 0400h to 0fffh  by accident and realized after erasing the
chip that that I could not get any memory pass the 03FF mark to revert to 3FFF.

Please someone tell me how I can get it back!!! (I have paid good money for
this chip and have not had a chance to use it once yet)  I have read the
datasheet 15 times over to find a way to recover for my mistake but to no
avail...

Remembering that Jim Robertson (Newfound Electronics) had mentioned
something about code protect, I went back to his note that warns about this
but only for the A device, no mention of the plain C74...

Can anyone help?

1996\06\11@020424 by fastfwd

face
flavicon
face
Robert Cote, <EraseMEPICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> I decided to try my hand at the 16C74/JW.  Last night, while trying
> out Bojan Dobaj shareware programmer, I selected Code Protect ON -
> from 0400h to 0fffh  by accident and realized after erasing the
> chip that that I could not get any memory pass the 03FF mark to
> revert to 3FFF.
>
> Please someone tell me how I can get it back!!!
> ....
> Remembering that Jim Robertson (Newfound Electronics) had mentioned
> something about code protect, I went back to his note that warns
> about this but only for the A device, no mention of the plain C74...

Robert:

If your 16C74 is not an "A" part, you simple need to put it back in
the eraser for another cycle (or two, or three, or four); the
code-protect bit (by design) takes a long time to erase.

-Andy

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

1996\06\11@101234 by Bojan Dobaj

flavicon
face
>I am relatively new to the work of PIC and after having played around with
>the 16c84 successfully, I decided to try my hand at the 16C74/JW.  Last
>night, while trying out Bojan Dobaj shareware programmer, I selected Code
>Protect ON - from 0400h to 0fffh  by accident and realized after erasing the
>chip that that I could not get any memory pass the 03FF mark to revert to 3FFF.
>
>Please someone tell me how I can get it back!!! (I have paid good money for
>this chip and have not had a chance to use it once yet)  I have read the
>datasheet 15 times over to find a way to recover for my mistake but to no
>avail...
>
>Remembering that Jim Robertson (Newfound Electronics) had mentioned
>something about code protect, I went back to his note that warns about this
>but only for the A device, no mention of the plain C74...
>
>Can anyone help?
>

P16Pro programmer, you tryed out, displeys the warning message when you try
to programm newer PICs (included 74) with code protect ON. In README.TXT
delivered with P16PRO is also a warning about that. I have included it because
I had a similar problem.

But what is done is done. You can try to put your PIC back in the eraser for
a longer time (up to 36 hours) and hope.


Bojan Dobaj, Slovenia
.....bojan.dobajspamspam_OUTuni-mb.si

'Code for pics'
1996\06\12@052856 by Bruce Bushby

flavicon
face
Hello

As a new comer to pic I am looking for information on what software
is used to run pic. I'm told that one would use c, compile it and then
use a pic programmer to down load into the pic's.

Any useful info on the start to finish of pic code would be appreciated,
and any uncompiled sofware to look at would also be useful.

THanks

Bruce

'Automatic code generator'
1996\06\13@132153 by Mark K Sullivan

flavicon
face
Just for fun, I have set up a code generator web page.  You put in an infix
expression like This*(That+23) and it writes PIC code to evaluate the
expression.  It's only 8 bits at this time.

http://niobrara.com/mks/evaluate8.html

If you want to see the previously discussed 2's complement in action, try, for
instance:

-(A+B)

I won't apologize here for the inefficiency of the generated code.  There's
enough of that on the web page ;)  Do let  me know if it actually generates
incorrect results.

- Mark Sullivan -

'DTMF Decode using 16C6x'
1996\06\13@212748 by Steve Hardy

flavicon
face
At the prompting of a fellow PIClister, <@spam@FECDSIEraseMEspamspamsubasekb.navy.mil>, I have
some code which will perform the complement of the DTMF code generation
function, i.e. will listen for and decode DTMF tones.

Whether this is useful is another matter (since the proper decoder
chips leave little to be desired) however it was a fun exercise.

The code has, as usual, been verified using MPSIM.  Unfortunately, my
version of MPSIM likes to reboot my machine if I feed it a stimulus file
longer than about 500 lines.  This means that I couldn't completely
verify the code as written.  On the other hand, I am confident that the
_algorithm_ is fairly robust.  It works even in the presence of substantial
noise so long as the noise is not correlated with any of the 8 DTMF tones.
The tone is detected within about 150ms (I don't know the complete
spec, but I think tones are supposed to last for at least 200ms).

As before, email me _directly_ requesting a copy and I will send it.

One good thing about the algorithm is that it will even work with a 1-bit
ADC (i.e. comparator) providing that the low- and high-group tones do
not differ by more than 10% from each other.  Whether this is useful
depends on how 'flat' the PSTN response is.

Since I don't trust the network to be flat within 1dB over 700-1700Hz,
I have implemented this using 8-bit samples.  This is tolerant of
substantial variations of frequency response.

The routine does not provide some of the other facilities needed for
a real-world app.  E.g. other code will need to determine whether a
tone is expected, and search for the proper pause between tones.

Regards,
SJH
Canberra, Australia

PS: Use this and the tone generator and you have yourself a 20bps modem!

1996\06\13@235911 by Eric Smith

flavicon
face
Steve Hardy <hardyTakeThisOuTspamKILLspamSWENG.STORTEK.COM> writes about DTMF decoding:

> The tone is detected within about 150ms (I don't know the complete
> spec, but I think tones are supposed to last for at least 200ms).

DTMF bursts are supposed to last 50 mS, and there is supposed to be at least
50 mS of silence between bursts.  Receivers should detect bursts as brief as
30 mS.

Eric

1996\06\14@004104 by Steve Hardy

flavicon
face
> From RemoveMEericTakeThisOuTspamgoonsquad.spies.com Fri Jun 14 14:02:16 1996
>
> Steve Hardy <@spam@hardySTOPspamspamSWENG.STORTEK.COM> writes about DTMF decoding:
>
> > The tone is detected within about 150ms (I don't know the complete
> > spec, but I think tones are supposed to last for at least 200ms).
>
> DTMF bursts are supposed to last 50 mS, and there is supposed to be at least
> 50 mS of silence between bursts.  Receivers should detect bursts as brief as
> 30 mS.
>
> Eric
>

This may be a problem >:^(  I was looking at NatSemi's application note
AN521 - they make their tone generator output 100ms tones.  My code
actually picks up the code in 76ms of sampling, however this was
repeated for reliability (making 152ms).  Sorry folks, much too slow!

In practice most tone generators seem to generate a lot more than the
minimum required.  Well, dammit, _my_ phone sounds a lot longer than
50ms!

The code could be modified to sample for several tones at once instead
of the 8 sequentially.  In theory, everything could be done sampling at
4*1633Hz for 10/697 seconds = 15ms (94 samples).  This may be a better
approach but obviously requires a swag of registers to store the
complete sample set.  My code uses just (?!) 17.

Regards,
SJH

1996\06\15@140812 by Steve Childress

flavicon
face
Would very much like a copy of the DTMF decoder code.
TIA
TakeThisOuTstevecTakeThisOuTspamRemoveMErain.org




Attachment converted: wonderlandthree:WINMAIL.DAT (????/----) (000056D5)

1996\06\17@060425 by Daniel Henzulea

flavicon
face
       I like to have a copy of your DTMF decoder code. I'm working in
20bps transmissions on phone lines (e.g. alarm systems), but the results
is not the best. The phone line in my country are so noises (that is...).

       Thanks in advance,

               Daniel.

1996\06\17@114632 by Alexej Vladimirov

flavicon
face
Hello PICers!

P> Would very much like a copy of the DTMF decoder code.

For all interesting for DTMF decoding: this code is now accessible
on my PIC page:
http://www.ormix.riga.lv/eng/mchip/mchip.htm

It's also can be downoladed from ftp:
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
File is 60K long.

Alexej Vladimirov  spam_OUTavladspamspam.....mail.ormix.riga.lv  [Microchip technical support]

--- GoldED/2 2.50+

'crystal codecs'
1996\06\17@123621 by Stuart Allman

flavicon
face
Does anyone know how to get ahold of a rep from crystal semiconductor.  A
northwest US rep would be optimal.  I tried e-mailing their support
address and I haven't received a reply.

Stuart Allman
studio.....spam@spam@halcyon.com

'Motor Quadrature encoder adjustment.'
1996\06\22@200454 by Alexandre Guimaraes

flavicon
face
I have some motors with quadrature encoders that I need to
adjust. The two sensors should generate a signal that is 90 degrees
apart.

       Does anyone know of a way to measure the phase difference of two
signals when the frequency is unkown ?

       I would like to implement it with a PIC to make my life easier.
The scope does not give me the precision I need and I think it should be
easier to make a PIC do it than to have a conventional phase difference
meter.

Thanks
Alexandre Guimaraes
spamBeGonealexgspamspam_OUTiis.com.br

1996\06\22@203152 by John Payson

flavicon
face
> I have some motors with quadrature encoders that I need to
> adjust. The two sensors should generate a signal that is 90 degrees
> apart.
>
>         Does anyone know of a way to measure the phase difference of two
> signals when the frequency is unkown ?

Fairly simple: what you need are the following:

Quad XOR gate, CMOS
 Pins: A1,B1,Y1,A2,B2,Y2,A3,B3,Y3,A4,B4,Y4,Vss,VDD

Two 10K resistors
 Pins: R1a,R1b; R2a,R2b

Two 100uF caps
 Pins: C1a,C1k; C2a,C2k

Positive 5 volt supply:
 Pins: PGround, PPlus5

Encoder inputs [ground-relative]:
 Pins: En1,En2

High-impedence zero-center voltmeter:
 Pins: MI1,MI2

Wire as follows:
 A1,B1,En1
 A2,B2,En2
 Y1,A3
 Y2,B3
 Y3,A4,B4,R1a
 Y4,R2a
 R1b,C1a,MI1
 R2b,C2b,MI2
 C1a,C1b,Vss,PGround
 VDD,PPlus

First ground one quadrature input and adjust the other until the meter
reads zero.  The repeat with the other.  Then enable both and adjust
until the meter reads zero (which will only happen when phase delta is
plus or minus 90 degrees).

1996\06\26@070355 by Joe McCauley

picon face
>I have some motors with quadrature encoders that I need to
>adjust. The two sensors should generate a signal that is 90 degrees
>apart.
>
>        Does anyone know of a way to measure the phase difference of two
>signals when the frequency is unkown ?
>
>        I would like to implement it with a PIC to make my life easier.
>The scope does not give me the precision I need and I think it should be
>easier to make a PIC do it than to have a conventional phase difference
>meter.
>
>Thanks
>Alexandre Guimaraes
>EraseMEalexg.....spamiis.com.br
>

Can I assume that you want direction information as well as
speed?

If so then you hook one of the Quad o/p lines to the D i/p
of a 74ls74 (or similar D type flip flop), and hook the other
to the CLK i/p. Then when the motor rotates in one direction
you get the Q output high and rotating in the other direction
you get  the Q output low. The speed info. you can get from either
quaderature output.

This can also be easily implemented on a PIC especially if you use an
interrupt line as the CLK and sample the other quad. o/p during the
interrupt.

Hope this helps.

Joe
_________________________________________________________________

Joe McCauley
Physics Department,           Tel: 353-1-6082218
Trinity College,              Fax: 353-1-6711759
Dublin 2,                     Email: spampmcculeyKILLspamspam@spam@mail.tcd.ie
Ireland.


'LCD code example corrections'
1996\07\03@153155 by Norm Cramer
flavicon
face
The LCD code that I made available has been updated.  It was missing a clock
of one byte of initialization data to the LCD.  It worked OK as it was, but
to match the data book, I corrected the code.  The code was written for a
2x20 LCD module but will work with the other modules.  You can get the
updated code from:

WEB:

http://niobrara.com/mks/pic/cramerlcd.h
and
http://niobrara.com/mks/pic/cramerlcd.asm

FTP: (should be updated soon)
ftp://ftp.mcc.ac.uk/pub/micro-controllers/PIC/cramer.zip

Norm

'Hamming Code info'
1996\07\04@052013 by fastfwd

face
flavicon
face
Ok... Due to popular demand, I've added a short overview of Hamming
error-correction codes to the "Answers" section of my company's web
page.

It's the answer to Question #21 in the "Other Processors/Misc"
section of the "Answers" page.

-Andy

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

1996\07\04@170701 by Don McKenzie

flavicon
face
> Ok... Due to popular demand, I've added a short overview of Hamming
> error-correction codes to the "Answers" section of my company's web
> page.
>
> It's the answer to Question #21 in the "Other Processors/Misc"
> section of the "Answers" page.
> -Andy
> Andrew Warren - RemoveMEfastfwdRemoveMEspamix.netcom.com
> Fast Forward Engineering, Vista, California
> http://www.geocities.com/SiliconValley/2499

Damn Andy,
This means another update to my disk file copy of your answers page that
I cart around on my notebook.

The one that I quote the answers to customers on a regular basis that
makes them think I'm a PIC guru.
<g> Don...

Don McKenzie TakeThisOuTdonmck@spam@spam@spam@labyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

PicoSaurus(tm).The 40 pin PICBasic with 8 channels of A-D, and real Uart.
PIC Basic Compiler. Programmers from $15 US, and Pic-Axe(tm) A New Tool.

'DTMF Decode using 16C6x'
1996\07\10@222445 by PAUL B

flavicon
picon face
Hi i was wondering what the current score is with the DTMF decoder
design i followed part of the thread but then had mail problems , is
there a working bit of code to play with ???
--
PAUL B

1996\07\10@223513 by Steve Hardy

flavicon
face
> From: PAUL B <TakeThisOuTpaulspamspamG0TTS.DEMON.CO.UK>
>
> Hi i was wondering what the current score is with the DTMF decoder
> design i followed part of the thread but then had mail problems , is
> there a working bit of code to play with ???
> --
> PAUL B
>

Paul, the code is available from:

http://www.ormix.riga.lv/eng/mchip/mchip.htm - PIC page
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_cod.zip

(Thanks to Alexej Vladimirov  KILLspamavladKILLspamspamspamBeGonemail.ormix.riga.lv)

Note that the decoder is not entirely satisfactory with respect to
the 'standards', but works if the tones last for over 150ms.

Regards,
SJH

1996\07\11@153612 by PAUL B

flavicon
picon face
>
>Paul, the code is available from:
>
>http://www.ormix.riga.lv/eng/mchip/mchip.htm - PIC page
>ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
>ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_cod.zip
>
>(Thanks to Alexej Vladimirov  spamBeGoneavladKILLspamspammail.ormix.riga.lv)
>
>Note that the decoder is not entirely satisfactory with respect to
>the 'standards', but works if the tones last for over 150ms.
>
>Regards,
>SJH

So what is needed to sort this problem out for dtmf under 150 ms ?

--
PAUL B

1996\07\11@170933 by Scott Dattalo

face
flavicon
face
PAUL B wrote:
>
> >
> >Note that the decoder is not entirely satisfactory with respect to
> >the 'standards', but works if the tones last for over 150ms.
> >
> >Regards,
> >SJH
>
> So what is needed to sort this problem out for dtmf under 150 ms ?
>

Paul,

With Steve's approach you need a little more power than a PIC can deliver.
Those of you familiar with Analog Device's DSP's may recall this approach
implemented in an ADSP-2100 (see chapter 14 of the Digital Signal Processing
Applications). There they have 16 Goertzel algorithms running in parallel.
8 of them are tuned to the 8 DTMF tones while the other 8 are tuned to the
second harmonic of the DTMF tones. The idea is that if a DTMF signal is
present, then only two of the Goertzel outputs in the lower group of 8
(actually one in the first four and the other in the second four) will have
any significant output. The reason for looking at the second harmonic is to
differentiate DTMF signals (low in 2nd harmonic) from ordinary voice (higher
in 2nd harmonic).

[A Goertzel algorithm provides an efficient means of computing the Discrete
Fourier Transform of a signal.]


I have an idea that may make DTMF decoding possible with a PIC. In a message
to Steve I wrote:

> Steve,
>
> I've been thinking about this DTMF stuff a little. I must confess that I have
> little interest beyond the theoretical aspects. In other words, I've never
> built any hardware or written any software to encode or decode DTMF signals,
> but I like to mess around with signal processing and efficient algorithms.
>
> O.K. Having said that, I would like you to consider this idea. Suppose you
looked
> at the zero crossing of the DTMF signals and attempted to perform the decoding
> based on the apriori knowledge of the 8 DTMF frequencies. The "zero-crossing"
> detector is a one-bit A to D converter, i.e. a comparator. (The 16C622 has two
> comparators.) The idea is to sample the comparator output and measure how long
> it takes for the signal to change states. The optimal sampling time and
criteria
{Quote hidden}

d(t)
> goes to zero when ever either the sine term or the cosine term goes to zero:
>
> d(t) = 0
> when
>   t = n / (fl + fh)       n = 0, +/- 1, +/- 2, etc.
> OR
>   t = (m + .5) / (fl - fh)       m = 0, +/- 1, +/- 2, etc.
>
> (actually, the .5 is an artifact of the cosine. Since phase is not important,
the .5
> can be ignored. In other words, the .5/(fl-fh) causes a time shift in the zero
crossings.)
>
> The minimum zero crossing frequency is ~ 1209+697 = 1906, while the maximum
is[Steve, your message has an error right here ^^^^^^^^^^^^]
> 941+1633 = 2574. So the sampling time needs to be fast enough to catch 2574 Hz
signal
> and perhaps slow enough to not overflow say an 8-bit variable counting the
1906 Hz
> pulse width. So roughly speaking, you wouldn't want to sample any faster than
1/1906/256
> or about 2 us.(Nor could you) My guess is that 10us is comfortable.
>
> Now for detection... If you look at the time spacing of the zero crossings of
the DTMF
> signals, you'll see something like so:
>
>   W W W N N W W W N N W W W N N W W W N N W W W N
>
> where do to my impatience, I've abbreviate wide pulses with W and a narrow
ones with N.
> The number of wide pulses between narrow pulses is roughly (exactly, averaged
over time)
> the ratio of the sum and difference of the DTMF tones:
>      fh + fl
> r ~ ---------
>      fh - fl
>
> The width of the wide pulses is the spacing between zero crossings due to the
sum of the
> DTMF tones, while the spacing in time of the narrow pulses is due to their
difference.
>
> W ~ 1/(fh + fl)
> space between N's ~ 1/(fh - fl)
>
> The reason there are narrow pulses is due to the two frequencies beating
together. Another
> way to look at it is there are certain integers m and n that can cause the
zero crossing
> gap to be decreased.
>
> As an example, suppose we were looking at key 1 (697,1209). The zero crossing
points
> occur at
>  n/(1209 + 697) = 0, 525us, 1049us, 1574us, 2099us, 2623us, 3148us, 3673us,
4197us, 4722us,
>                   5247us,  5771us, 6296us, ...
> and
>  m/(1209 - 697) = 0, 1953us, 3906us, 5859us, 7812us, 9765us, ...
>
> The pulse widths you would measure would be:
>
> 525, 524, 525, 379, 146, 524, 525, 525, 233, 291, ....
>  W    W    W    N    N    W    W    W    N    N
>
> So the wide pulses are ~525us, and there are three of them between the narrow
pulses.
>
> The time between the occurrence of the narrow pulses is about
379+146+524+525+525 or
> 2099us, which is approximately 1953us (=1/[1209-697]). Now this is not
accurate enough
> by itself to be used as an identifier of the frequencies, but it could be used
as a
> discriminator. Perhaps if you average several of these cycles the
approximation improves,
> but I haven't investigated this.
>
> If you repeat this example for the other 15 keys, you start to see a pattern
develop. I've
> written a simple program in MATLAB to demonstrate this. (It's at home and not
at work so I
> can't append a copy of it). It will cycle through the 16 keys and show the
DTMF signal and
> the "digitized" waveform superimposed.
>
> Now for the tough part... So far I've assumed that the two tones have the same
amplitude
> and that there is no noise. From a quick search on the WEB, I learned that
there could be
> up to three dB difference between the two. I emperically found with the MATLAB
program that
> 6 db difference makes it extremely difficult to tell the difference between
two DTMF signals,
> but 3 db can be done.
>
> I assume that the noise floor is several db below the tones. In which case,
the comparator
> hysterisis will "filter" it out. If it is not, then you have a problem. Also,
harmonic
> distortion could also be detrimental. However, I doubt (i.e. guess) that there
are no even
> harmonics and that the odd harmonics are at most 1/n^2 (n = harmonic number)
the amplitude
> of the fundamental. (This is similar to the Fourier series of a triangle
wave.)
>
> At any rate, I do not yet have an algorithm to efficiently pluck the DTMF
signals out of
> the acquired data.
>

And in a subsequent message I also wrote:

> I forgot to tell you one thing about sampling these pulses. It's possible to
miss a short
> pulse with the sampling scheme I described in the last message. This is
because under
> certain conditions the short pulse is shorter than the sampling period. In
this case,
> you would see one really wide pulse inplace of two wide pulses seperated by a
narrow one.
> I think it's possible to recognize when this happens, so it probably is no big
deal.
>

The only reason I'm throwing this stuff out here is maybe someone else has
already attempted
this approach and have either a) made it work or b) realize it's not possible.
Any ideas or
feedback?


Scott

'Mag stripe decode (was New Project)'
1996\07\16@093157 by Mark K Sullivan

flavicon
face
Been there, done that.  I was able to read track 1 and 2 concurrently with no
problem.  I didn't buffer the wole thing, I only needed to extract a few fields,
on the fly.  I also have a MS keyboard wedge that uses a 16C54 to do the mag
stripe decode and the PC keyboard encode.  It auto-detects XT/AT keyboards.

- Mark Sullivan -

'Mag Stripe Decode (about PC keyboard protocol)'
1996\07\18@145922 by Mark K Sullivan

flavicon
face
>how much effort is requierd and did you do anything to avoid collisions
>with KBD data with your design or just assume that users wont press keys
>and swipe at the same time.

I made the assumption.  You do have to monitor the shift state, though.  Some
computers don't like redundant shift release or shift press codes.

>What is required to auto-detect, check for reset pulse ?

I did it by counting transitions on the clock line with a 2.5mS timeout.  The XT
interface has a shorter word length.

- Mark Sullivan -

'Searching for SCI source code examples 16C74'
1996\07\22@220836 by NEIL GANDLER

flavicon
face
       While the SCI module seems very straight forward and easy to
use, I would like some reference examples to take a look at. I have found
nothing in the Application notes, nor anything on the microchip BBS. Just
curious if someone knows where I can get some example code routines.

                       Neil Gandler


'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 <PICLIST@spam@spamKILLspamMITVMA.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 - EraseMEfastfwdRemoveMEspam@spam@ix.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

'C code examples'
1996\07\23@134014 by balex

flavicon
face
Does anyone know where I can get examples of programs written in C for
PIC's.

Thanks,
Brad

'LCD Serial Controller code..fixed link..'
1996\07\25@093210 by Thomas Coonan

flavicon
face
    I hope I fixed my WWW link.  Sorry..
       http://www.mindspring.com/~tcoonan

1996\07\25@222910 by Ken Parkyn

flavicon
picon face
Thomas Coonan wrote:
>
>      I hope I fixed my WWW link.  Sorry..
>         http://www.mindspring.com/~tcoonanTom;
getting ERROR 304 when trying to access lcd.asm...
busy?

Cheers,
--
****************************************************************************
Ken Parkyn                                  email: RemoveMEK.ParkynspamspamEraseMEsct.gu.edu.au
Electronics Workshop                        phone: (07) 3875 7289
Division of Science and Technology          fax:   (07) 3875 7656

Griffith University
Nathan QLD 4111
Australia                                   Office: Science 2   Room
-1.17
****************************************************************************

1996\07\26@040405 by Don McKenzie

flavicon
face
Ken Parkyn wrote:
{Quote hidden}

You must have been early Ken. I had problems initially, but got in OK later.
Thanks Thomas.

Don McKenzie spamBeGonedonmckRemoveMEspamRemoveMElabyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
Picosaurus(tm) 40 pin PICBasic with 8 channels of A-D, and real Uart.
PIC Basic Compiler. Programmers from 15 USD.  Pic-Axe(tm) A New Tool.


'How do I set up _config in source code?'
1996\08\01@045749 by Dennis Frost
flavicon
face
The following appears in the 16c84 include file:

;==========================================================================
;       Configuration Bits

_CP_ON                       EQU     H'3FEF'
_CP_OFF                      EQU     H'3FFF'
_PWRTE_ON                    EQU     H'3FFF'
_PWRTE_OFF                   EQU     H'3FF7'
_WDT_ON                      EQU     H'3FFF'
_WDT_OFF                     EQU     H'3FFB'
_LP_OSC                      EQU     H'3FFC'
_XT_OSC                      EQU     H'3FFD'
_HS_OSC                      EQU     H'3FFE'
_RC_OSC                      EQU     H'3FFF'

;==========================================================================

It is obviously put there to make setting up the _config directive easy to
perform & later to read.

At the moment I use:   _config H'3FFF'          ;replace 3fff with the
applicable hex number

I want to know how to  'and' or 'or' the include file equates togeter and
then place them into _config

Doing this makes programming much eaisier as when the programmer loads your
hex file the WDT, PWRT, Osc etc are already set up.

Thanks
       Dennis


--------------------------------------------
Dennis Frost
Tel: +27 331 965125
Cel: +83 2275216
Pietermaritzburg, South Africa
--------------------------------------------

 _______________________________________
|     ______ ____   ____   _____ ______ |
|    / ____// __ \ / __ \ / ___//_  __/ |
|   / /_   / /_/ // / / / \__ \  / /    |
|  / __/  / _  _// /_/ / ___/ / / /     |
| /_/    /_/ |_| \____/ /____/ /_/      |
|                                       |
| Dennis Frost                          |
| Tel:   +27 331 965125                 |
| Cel:   +83 2275216                    |
| Email: @spam@dennis.frostspamBeGonespampixie.co.za       |
| Pietermaritzburg, South Africa        |
|_______________________________________|

1996\08\01@071439 by nogueira

flavicon
face
Dennis Frost wrote:
{Quote hidden}

Just put this way:
       __CONFIG _XT_OSC & _WDT_OFF & _PWRTE_ON & _CP_OFF

Octavio

========================================================
Octavio Nogueira
  e-mail:   spam_OUTnogueiraspamspammandic.com.br
homepage: http://ourworld.compuserve.com/homepages/tato
voice/fax: +55 11 240-6474
========================================================

'Decoding grey code with a pic.'
1996\08\14@045812 by Joe McCauley

picon face
Hi,

I need to get position info from a Stegman single turn absolute position
encoder. Getting the info is only a matter of clocking the unit and
shifting in the 24 bit grey code result.

Does anybody know the fastest way of converting this to binary using
a pic.

A pic is my preferred solution as I would like to do some position
comparision (ie. accept position info from another microcontroller
and read the encoder until that position has been reached.)

Other suggestions are welcome though.

Thanks.

Joe
_________________________________________________________________

Joe McCauley
Physics Department,           Tel: 353-1-6082218
Trinity College,              Fax: 353-1-6711759
Dublin 2,                     Email: spampmcculeyspamspamspammail.tcd.ie
Ireland.

1996\08\14@054311 by eza Asensio, Roberto

flavicon
face
Hi Joe and all,

At 09:58 14/08/96 +0100, you wrote:

>I need to get position info from a Stegman single turn absolute position
>encoder. Getting the info is only a matter of clocking the unit and
>shifting in the 24 bit grey code result.
>
>Does anybody know the fastest way of converting this to binary using
>a pic.

One easy way to convert the Gray code to binary is to do the XOR of the
current word with the shifthed_rigth version (lsb droped, 0 to msb) of this
same word.

Best regards:
--
Roberto Deza Asensio        |  spamBeGonerdezaKILLspamspamKILLspampopmail.cti.unav.es
Universidad de Navarra      |  TakeThisOuTrdezaspamspamcun.unav.es
Centro de Proceso de Datos  |  spamBeGonerdaspamcpd.unav.es

1996\08\14@084905 by eza Asensio, Roberto

flavicon
face
Hi Rick and all,

At 07:16 14/08/96 -0500, you wrote:

>>  One easy way to convert the Gray code to binary is to do the XOR of the
>> current word with the shifthed_rigth version (lsb droped, 0 to msb) of this
>> same word.
>
>That's wonderful!  :-)  I can use it!
>
>You wouldn't happen to know an easy way to *generate* grey code,
>would you?

Yes, I know the related trick:

To get the Grey code of a binary number, you do the XOR of the binary word
with the shifted_left version (0 to lsb, msb droped) of this same word.

I know this "old tricks" from a book of the year 74 related to RTL & DTL
logic (Resistor/Diode Transistor Logic...), but they have currently use.

Best regards:

P.D. I post this reply also to the list, as perhaps it will be of use to
someone.
--
Roberto Deza Asensio        |  EraseMErdezaEraseMEspampopmail.cti.unav.es
Universidad de Navarra      |  spamBeGonerdezaspam_OUTspam.....cun.unav.es
Centro de Proceso de Datos  |  spamrdaspamcpd.unav.es

1996\08\14@114904 by fastfwd

face
flavicon
face
Joe McCauley <RemoveMEPICLISTKILLspamspamKILLspamMITVMA.MIT.EDU> wrote:

> Getting the info is only a matter of clocking the unit and shifting
> in the 24 bit grey code result.
>
> Does anybody know the fastest way of converting this to binary using
> a pic.

Joe:

See the answer to Question #5, in the "Other Processors/
Miscellaneous" section of the "Answers" area on my company's web
page.

-Andy

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

'code reference book'
1996\08\16@134246 by Reginald Neale

flavicon
face
In the current copy of MIDNIGHT ENGINEERING, an author mentions that the
best reference he has ever read on programming is Steve McConnell's *Code
Complete.*
Has anyone here ever heard of it and can offer an opinion and/or source?

.....................Reg Neale.....................
"Ignorance is a renewable resource"   P.J. O'Rourke

1996\08\16@142015 by Dan Goodwin

picon face
Code Complete is a very good book. Around here, Massachusetts, it
is available at any well stocked book store.

-----------------------------
Dan Goodwin  KD1XN Waltham,MA
-----------------------------

On Fri, 16 Aug 1996, Reginald Neale wrote:

> In the current copy of MIDNIGHT ENGINEERING, an author mentions that the
> best reference he has ever read on programming is Steve McConnell's *Code
> Complete.*
> Has anyone here ever heard of it and can offer an opinion and/or source?
>
> .....................Reg Neale.....................
> "Ignorance is a renewable resource"   P.J. O'Rourke
>

1996\08\16@144524 by rdmiller

picon face
On Fri, 16 Aug 1996, Reginald Neale wrote:
> In the current copy of MIDNIGHT ENGINEERING, an author mentions that the
> best reference he has ever read on programming is Steve McConnell's *Code
> Complete.*
> Has anyone here ever heard of it and can offer an opinion and/or source?

Yes, my boss loaned me a copy of it...

It left me wishing I actually had the time to do it that way.

If I were managing a *LARGE* software project ("re-write WordPerfect")
I would follow it religiously.  The smaller a project is though, the
less and less you'll benefit from such methodical nit-picking.

"Code reviews" are shown in a more practically applicable way, but my
personal experience is that they really aren't worth much unless done
by someone who is already intimitely familiar with the task at hand.

       You hand me a block diagram that's no more than a
       concept drawing, then tell me that it has already
       been sold to a customer who expects it to ship in
       six weeks... and you expect a "Software Requirements
       Document" for your review?!?

Rick Miller (kb9obn) KILLspamrdmillerspamexecpc.com

1996\08\16@152931 by fastfwd

face
flavicon
face
Reginald Neale <PICLISTspam_OUTspamspamMITVMA.MIT.EDU> wrote:

> In the current copy of MIDNIGHT ENGINEERING, an author mentions that
> the best reference he has ever read on programming is Steve
> McConnell's *Code Complete.* Has anyone here ever heard of it and
> can offer an opinion and/or source?

Reg:

If you already write your code the way McConnell recommends, you'll
read through the book nodding your head in agreement and not
learning much.

If you don't, you'll do the same thing; reading a book like this (no
matter how many case histories and "coding horrors" examples are
included) is not going to change your methods.

Still, you shuld probably have a copy, especially if you don't own
any other "software construction techniques" books... McConnell has
managed to include references to most of the classic books and
articles.

Code Complete is published by Microsoft Press; if you can't find a
copy in your local bookstore, you can order it directly from them at
1-800-MSPRESS (in Canada, 416 293-8464, x340).

-Andy

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

1996\08\16@172652 by fastfwd

face
flavicon
face
Something else I should have said about Steve McConnell's "Code
Complete" book...

It has much more to do with the PHILOSOPHY of software construction
than with specific techniques.  McConnell does give a lot of
examples (mostly in Pascal, but there are a bunch of C and Ada
fragments, too), but if you're looking for a book full of handy
little routines or whatever, this ain't it.

-Andy

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

1996\08\17@115614 by Ray Gardiner

flavicon
face
>>[snip]
>
>        You hand me a block diagram that's no more than a
>        concept drawing, then tell me that it has already
>        been sold to a customer who expects it to ship in
>        six weeks... and you expect a "Software Requirements
>        Document" for your review?!?
>
>Rick Miller (kb9obn) .....rdmiller@spam@spamexecpc.com

You're not alone, check out....

  http://www.yourdon.com/books/deathmarch/dmsummary.html

I know it's not stricly PIC related but it's compulsory
reading for anyone involved in software engineering.





Ray Gardiner, 104 Macintosh Street, Shepparton, Victoria 3630,  Australia
@spam@rayspamnetspace.net.au

'Please help me with info. on Digital Code Lock usi'
1996\08\20@082900 by Ashton Anandlal

flavicon
face
Dear Readers

I am an in-service student studying Electronic Engineering at the M. L.
Sultan Technikon in Durban, SA. I am currently researching a project on
building a Digital Code Lock with a PIC16C54 that is interfaced to a solenoid
lock.


I wish for the project to have the following specifications:
1. Have a 10 digit key pad with a four digit unlock code.
2. Have a master and slave code.
3. The master code can be used to change the slave and the master code.
4. If the code is entered incorrectly more than three times the alarm must
sound.
5. The alarm must switch of after some time.

I thank anyone who can provide me information on the hardware and/or software
to build this project.

I would be using the PICSTART MICROCONTROLLER DEVELOPMENT SYSTEM.

I have just been introduced to PIC controllers so please send me as much
information as soon as possible.

With Sincere Thanks

Ashton Anandlal
Email : rugnundpRemoveMEspamwpogate.mlsultan.ac.za
postal : 9 Motlen Road
       Northcroft
       Phoenix
       Durban
       4068
       Republic of South Africa.

1996\08\20@085943 by Andy Errington

flavicon
face
Hi,

there was a project in Everyday Electronics (a UK magazine) a few months
back for just such a project.  I believe the source code was not
provided (surprise), but the features of the design would provide you
with some ideas: if you can see what can be done you will be able to do
it yourself.  I shall try and dig out a reference for you.

Points to note for your project:

You will need some sort of hard coded default master code which is used
the first time you run the circuit, or when you get a power fail.
You will need to understand how to interface a matrix keypad to the
processor and do debouncing of keypresses via software
You will need to think about what environment your system is being used
in and what are the implications if it should fail.

There are many other points to consider.  This probably a fairly easy
project, but challenging enough for a first project.

Good luck.

Andy (the other one)


{Quote hidden}

1996\08\21@073539 by hoss karoly

flavicon
face
I'd use a 16c84 because it has the neccesary eeprom
on my door there is a CORBY or GORBY -who cares
but it has a hard coded factory programming code which can be accessed
when a jumper is on at power on
after you change it enter the code for the new programming code
and you can enter the personal code
it is possible to remove one code only
if you push any button it gives a beep to let you know it's done
except * because if a * is followed by a # it gives panic alarm
these are the first few point came to my mind there's probably a
big bunch of important features not mentioned but I'll check the
other opinions too
bye
charley

'"C" Code Sharing'
1996\08\25@133131 by kodland

flavicon
face
    Good Morning PicList,

    I am just starting development on the PIC16c74 using the MPLAB and
    MPLAB-C packages.  I am lacking in some of the most basic routines:

    Ascii2Hex

    Hex2Ascii

    Floating Point Operations

    to name a few.  If anyone is interested in "sharing" these routines
    with me I would be much appreciated.  I am also willing to share my
    code as I develop it.

    Many thanks in advance.

    Keith

'Bar code scanning'
1996\08\26@034112 by Onat Ahmet

flavicon
face
Hi;

This one is about bar code scanning. I want to read bar codes
with a wand type scanner. (Both UPC and code39 would be nice, but
I can live with UPC only) The problem is, given the wide range and
fluctuations of the scanning speed, it seems difficult to calculate
the widths of the bars... Is there a simple method? Any code
fragments laying around? Please note that, what I am after is
not a decoding routine, but something that will enable me to
calculate the (ratios of) the widths of the bars and spaces.

Any pointers to FAQs, or Usenet groups are also appreciated.

Since barcodes were introduced 25 years ago, I guess they should
not require great computing power to read!

Thanks!

| Ahmet ONAT  Kyoto Univ. Japan                                 |
| E-mail    : spam_OUTonat@spam@spamRemoveMEkuee.kyoto-u.ac.jp                           |
| WWW page  : http://turbine.kuee.kyoto-u.ac.jp/staff/onat.html |
|             My 6 leg walker, RC airplanes & more in home page |

1996\08\26@040226 by fastfwd

face
flavicon
face
Onat Ahmet <spamPICLISTspamspamMITVMA.MIT.EDU> wrote:

> This one is about bar code scanning. I want to read bar codes
> with a wand type scanner. (Both UPC and code39 would be nice, but I
> can live with UPC only) The problem is, given the wide range and
> fluctuations of the scanning speed, it seems difficult to calculate
> the widths of the bars... Is there a simple method?

Ahmet:

Most bar codes include a constant pattern at both edges of the code
so you can calibrate your decode routine to the scanning speed...
It's real simple.

A quick web search shows that the December '94 issue of "Circuit
Cellar Ink" magazine allegedly contains an article on bar-code
decoding algorithms... Maybe you can find some pointers there.

-Andy

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

1996\08\26@055249 by Lee Jones

flavicon
face
> This one is about bar code scanning. I want to read bar codes
> with a wand type scanner. (Both UPC and code39 would be nice, but
> I can live with UPC only) The problem is, given the wide range and
> fluctuations of the scanning speed, it seems difficult to calculate
> the widths of the bars... Is there a simple method?

I don't have any advice if you want to compute the absolute widths
of the elements.  But I don't think you need that.  You can just
measure the ratios between light and dark and deduce if a bar was
"wide" or "narrow".  From that information, you can decode it.

I'd recommend "Handbook of Bar Coding Systems" by Harry E Burke.
My copy is copyright 1984 by NCR Corporation.  It's published by
Van Nostrand Reinhold.  It's not too thick and used to run ~$50.
An appendix at the back covers a dozen bar code standards.

You might also contact the "code control organizations".  UPC is
UPC Council in Dayton Ohio at 513-435-3870.  Code-39 is Interface
Mechanisms in Lynnwood Washington at 206-743-7036.  Both contacts
are from the vendor list in the above books bibliography.

                                               Lee

-------------------------------------------------------------------
Jones Computer Communications             .....leespam.....frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1996\08\26@060326 by Onat Ahmet

flavicon
face
       I don't have any advice if you want to compute the absolute widths
       of the elements.  But I don't think you need that.  You can just
       measure the ratios between light and dark and deduce if a bar was
       "wide" or "narrow".  From that information, you can decode it.
                                                       Lee

Hi;

To make myself clearer; I have no intention of measuring the *absolute*
widths of the bars and spaces; my problem is: How can I be sure of my
readings when the speed of the wand type scanner is fluctuating.
Or, maybe this is not a big problem at all?

Thanks for the info; I have received a couple of answers, hours after
sending in my question! PIC list is wonderful!

| Ahmet ONAT  Kyoto Univ. Japan                                 |
| E-mail    : spamonatKILLspamspamkuee.kyoto-u.ac.jp                           |
| WWW page  : http://turbine.kuee.kyoto-u.ac.jp/staff/onat.html |
|             My 6 leg walker, RC airplanes & more in home page |


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

The original question is included below for your convenience:

----------------------
This one is about bar code scanning. I want to read bar codes
with a wand type scanner. (Both UPC and code39 would be nice, but
I can live with UPC only) The problem is, given the wide range and
fluctuations of the scanning speed, it seems difficult to calculate
the widths of the bars... Is there a simple method? Any code
fragments laying around? Please note that, what I am after is
not a decoding routine, but something that will enable me to
calculate the (ratios of) the widths of the bars and spaces.

Any pointers to FAQs, or Usenet groups are also appreciated.

Since barcodes were introduced 25 years ago, I guess they should
not require great computing power to read!

Thanks!

1996\08\26@083547 by Walter Banks

picon face
Onat Ahmet wrote:

> This one is about bar code scanning. I want to read bar codes
> with a wand type scanner. (Both UPC and code39 would be nice, but
> I can live with UPC only) The problem is, given the wide range and
> fluctuations of the scanning speed, it seems difficult to calculate
> the widths of the bars... Is there a simple method? Any code
> fragments laying around? Please note that, what I am after is
> not a decoding routine, but something that will enable me to
> calculate the (ratios of) the widths of the bars and spaces.
>
> Any pointers to FAQs, or Usenet groups are also appreciated.
>
> Since barcodes were introduced 25 years ago, I guess they should
> not require great computing power to read!

Your right bar codes don't require a lot of computing power to read.
A long time ago I wrote code in a UCSD pascal system running on an apple
to read both UPC and CODE 39.

Basically bar code is is another communication format. To get information
you need clocking information to measure progress along the code,
calibration information to get a sense of the information and the
information itself.  Most barcode formats are designed with redundant
information in the code so that reading algothrims can do consistency
checks in the decoding process.

The two formats that you mention CODE39 and UPC are good representations
of two different types of barcode.

Code 39  is a character oriented barcode where each character is
represented by 9 bars. 5 dark bars with 4 white spaces inbetween is the
normal. Three of the bars are wide (typically 3 times the narrow) and
the remainder are narrow. The trick to reading this code is to
determine which of the bars are wide.  Each character is decoded
separtely. Code39 records usually start and stop with a "*" so the
reader knows that it decoded the whole record and not just part of it.


UPC is one of two fixed formats  11 digit and 6 digit. The 11 digit
format contains a guardband for speed calibration, 6 digits, a center
guardband, 6 more digits of information and a right guard band. The
symbol yields 11 digits of information and a check digit. Each digit is
encoded in a 7 unit wide space consisting of 4 bars. Two light and two
dark. The code is well thought out. It can be easily read forwards,
backwards and the cola bottle can be read full or empty. UPC is
suprisingly tolerant of printing and operator tolerances.  6 Digit UPC
uses left guard band 7 digits and a different right guard band.

We did some tests on people that may be of some use. The fastest speed
you will see in hand read code is about 42 inches per second. (A little
more than one meter per second)


Walter Banks
http://www.bytecraft.com

1996\08\29@075725 by alexg

flavicon
face
Onat Ahmet wrote:
>
> Hi;
>
> This one is about bar code scanning. I want to read bar codes
> with a wand type scanner. (Both UPC and code39 would be nice, but
> I can live with UPC only) The problem is, given the wide range and
> fluctuations of the scanning speed, it seems difficult to calculate
> the widths of the bars... Is there a simple method? Any code
> fragments laying around? Please note that, what I am after is
> not a decoding routine, but something that will enable me to
> calculate the (ratios of) the widths of the bars and spaces.

       The way I found is to change the reference every time I see a thin bar.
This way the reference should be good enough for decoding even if the
speed varies a lot. It all depends on which kind of Bar code you have,
code39 and ITF just have two bar widths but for UPC you have four. That
makes everything a little more critical. It is not a good idea to change
the reference if it varies much more than expected because it is
probably a reading error from the wand or an abrupt variation caused by
some "obstacle" in the wand's way.

>
> Any pointers to FAQs, or Usenet groups are also appreciated.
>
> Since barcodes were introduced 25 years ago, I guess they should
> not require great computing power to read!
>

       You will find out that there is not much written about the subject. It
seems like the people that have the algorithms prefer to keep them for
themselves. If you want I have a routine in 8031 assembler and FORTH
that decodes 2 of 5 codes. I am now working in a routine that can read
and decode the code on the fly using a state machine. If you are
interested we can work together on that.

Best regards,
Alexandre Guimaraes
RemoveMEalexgRemoveMEspamiis.com.br

'crystal codecs'
1996\08\29@115940 by Stuart Allman

flavicon
face
Has anyone ever tried to initialize a crystal codec with a PIC.  I'm
trying to do this, but I don't know if it's working because I can't feed
samples through until the codec it initialized.

'RLL codes'
1996\08\29@142032 by Dean Dunnigan

flavicon
face
Hello Picer's,

Sorry about being a little off topic but I'm having trouble
finding information on RLL decoding techniques and
algorithms.  I'm looking for this info particularly dealing with
RLL 2,7 code.  Info on this or where to look would be greatly
appreciated.

I would eventually like to adapt a PIC to do various decoding
algorithms for incoming RS232 serial info by either using a
lookup table or generating a software state machine.

Thanks in advance!!

Dean M. Dunnigan


'Decoding grey code with a pic.'
1996\09\04@145312 by Mike Halliday
picon face
I am sorry to be a kill joy but .... the xor ideas are not quite complete, or
ambiguous.

To generate Gray code *is* just a mater of using a shifted binary copy, the
reverse isnt true. For example assume the Gray value is 7, thus the expected
binary is 7 xor 3 (7 right shift) = 4. However a binary 4 xor 8 (4 shift
left) is 0c not 07.

Gray code should be generated by Gray = binary xor (binary * 2)
But binary is extracted as follows:-

For n the nth bit of n bits, B being the binary output bit, and G the Gray
input bit

1) B(n) = G(n)
2) B(n-1) = G(n-1) xor B(n)
3) B(n-2) = G(n-2) xor B(n-1)
4) B(n-3) = G(n-3) xor B(n-2)
......
5) B(0) = G(0) xor B(1)

From this it is clear that the binary value depends on the previous higher
binary bit. The good news is if the serial comes in most significant bit
first you can do the conversion on the fly. For the serious chip by chip
design of finite state machines transitions from states ordered according to
Gray code result in minimal wiring, because the Hamming distance is always 1.

What is user experience of the UK Forrest PICDE software like?
Happy coding.
Mike

1996\09\05@013159 by fastfwd

face
flavicon
face
Mike Halliday <KILLspamPICLIST.....spamKILLspamMITVMA.MIT.EDU> wrote:

> Gray code should be generated by Gray = binary xor (binary * 2)

   Mike:

   This is ALMOST correct.  Gray code is generated by:

       Gray = binary xor (binary / 2)

   That is, you must shift the input number RIGHT one position
   before XORing it with the original number.

{Quote hidden}

   Another way of looking at it, which may be easier to implement,
   is:

   1.  Reading from left to right, accept all the "0"'s and the
       first "1".
   2.  INVERT = TRUE.
   3.  Read the next bit.  If INVERT is true, invert that bit.
       Otherwise, accept it as-is.
   4.  If the bit you just read was a "0", loop back to Step 3.
   5.  Otherwise, invert the state of the INVERT flag, then loop
       back to Step 3.

   -Andy

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

1996\09\05@035914 by fastfwd

face
flavicon
face
I just wrote, on the subject of decoding Gray code:

>     1.  Reading from left to right, accept all the "0"'s and the
>         first "1".
>     2.  INVERT = TRUE.
>     3.  Read the next bit.  If INVERT is true, invert that bit.
>         Otherwise, accept it as-is.
>     4.  If the bit you just read was a "0", loop back to Step 3.
>     5.  Otherwise, invert the state of the INVERT flag, then loop
>         back to Step 3.

I wasn't thinking as clearly as I should have been... Here's a
slightly-more-generalized version of the above:

1.  INVERT = FALSE.
2.  Read the next (reading left-to-right) bit.  If INVERT is true,
   invert that bit. Otherwise, accept it as-is.
3.  If the bit you just read was a "1", invert the state of the
   INVERT flag.
4.  Loop back to Step 2.

Off the top of my head, an 8-bit Gray-code decoder could look like
this:

   FLAGS   EQU     [any register]
   COUNT   EQU     [any other register]
   GRAY    EQU     [yet another register]

   #DEFINE INVERT  FLAGS,0         ;TO MAKE THE CODE EFFICIENT, THIS
                                   ;FLAG MUST BE DEFINED AT
                                   ;BIT-POSITION 0.

   ; ENTER WITH THE GRAY-CODED NUMBER IN "GRAY".  EXITS WITH THE
   ; DECODED NUMBER IN "GRAY".

   DECODE:

           BCF     INVERT          ;START WITH "INVERT" FALSE.

           MOVLW   8               ;SETUP TO DECODE 8 BITS.
           MOVWF   COUNT           ;

   LOOP:

           RLF     GRAY,W          ;ROTATE THE NEXT BIT FROM BIT-
           RLF     GRAY            ;POSITION 7 TO BIT-POSITION 0,
                                   ;LEAVING A COPY OF IT IN THE
                                   ;CARRY.

           MOVLW   00000001B       ;PREPARE TO INVERT THE BIT, IF
                                   ;NECESSARY.  IF "INVERT" WAS
                                   ;DEFINED AT BIT-POSITION 0, THIS
                                   ;INSTRUCTION ALSO PREPARES US FOR
                                   ;INVERTING THE "INVERT" FLAG,
                                   ;SHOULD THAT PROVE NECESSARY.

           BTFSC   INVERT          ;IF WE SHOULDN'T INVERT THE BIT
                                   ;WE JUST READ, SKIP AHEAD.

           XORWF   GRAY            ;OTHERWISE, INVERT THE BIT.

           SKPNC                   ;IF THE BIT WE JUST READ WAS A
                                   ;"0", SKIP AHEAD WITHOUT INVERTING
                                   ;THE STATE OF THE "INVERT" FLAG.

           XORWF   FLAGS           ;OTHERWISE, INVERT THE STATE OF
                                   ;THE "INVERT" FLAG.

           DECFSZ  COUNT           ;HAVE WE DONE ALL 8 BITS?
           GOTO    LOOP            ;IF NOT, LOOP BACK.

   ; We're done... The decoded value is in "GRAY".

Twelve instructions, 82 cycles.

-Andy

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

'A better Gray-Code decoder'
1996\09\06@005824 by fastfwd

face
flavicon
face
Dudes:

Marv Isaacman, who prefers silent lurking on this mailing list to
flaunting his genius in front of us all by posting publicly, has come
up with the following optimization of the Gray-Code decoder I threw
together yesterday:

   COUNT   EQU     [any register]
   GRAY    EQU     [any other register]

   ; ENTER WITH THE GRAY-CODED NUMBER IN "GRAY".  EXITS WITH THE
   ; DECODED NUMBER IN "GRAY".

   DECODE:

           MOVLW   8               ;SETUP TO DECODE 8 BITS.
           MOVWF   COUNT           ;

   LOOP:

           RLF     GRAY,W          ;ROTATE THE NEXT BIT FROM BIT-
           RLF     GRAY            ;POSITION 7 TO BIT-POSITION 0,
                                   ;LEAVING A COPY OF IT IN THE
                                   ;CARRY.

           MOVLW   10000000B       ;PREPARE TO INVERT THE NEXT BIT,
                                   ;IF NECESSARY.

           SKPNC                   ;IF THE BIT WE JUST READ WAS
                                   ;EITHER A NON-INVERTED "0" OR
                                   ;AN INVERTED "1", SKIP AHEAD.

           XORWF   GRAY            ;OTHERWISE, INVERT THE NEXT BIT.

           DECFSZ  COUNT           ;HAVE WE DONE ALL 8 BITS?
           GOTO    LOOP            ;IF NOT, LOOP BACK.

   ; We're done... The decoded value is in "GRAY".

Nine instructions, 65 cycles.

-Andy

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

'"C" Code Sharing'
1996\09\07@052552 by rich

flavicon
picon face
part 0 637 bytes
    Ascii2Hex

    Hex2Ascii

    Floating Point Operations

    to name a few.  If anyone is interested in "sharing" these routines
    with me I would be much appreciated.  I am also willing to share my
    code as I develop it.

Keith,
       I am in a similar situation, we are about 3 weeks into a project using MPLABC and the 16c74.  There appears to be very little code around in C for this system as yet.

I am more than willing to participate in code sharing.
I have some unrefined but working IIC routines in C if anyone is interested.

mail me to discuss further.

Rich Milburn
rich@spam@spamEraseMEmmd-uk.demon.co.uk






'AT Keyboard code available'
1996\09\10@065802 by icio culibrk

flavicon
face
SendTo: spam_OUTpiclistspam_OUTspamRemoveMEmitvma.mit.edu

Hello!

Wow... I was practically bombed with requests about my AT keyboard
routines. Anyway, I just want to say that this 'famous' code is now
available at my home page. The url is http://www.arne.si/~mauricio.

Sorry for the dalay, but I had much work to do other than setting up
my improvised homepage.

I hope you'll find that code usefull. Please let me know if you encunter
any problems using it (incompatibility or whatever), so that I can
correct it for my applications also.

Enjoy,

mauricio

email: RemoveMEmauriciospam.....arne.si
      spammauricio.culibrk@spam@spamsnet.fer.uni-lj.si

http:  http://www.arne.si
      http://www.arne.si/~mauricio

1996\09\10@092309 by Gregg Kricorissian

flavicon
face
Hi Mauricio,

Many thanks for posting your keyboard routines!

..Gregg

PS: Love that Slo[WWW]enia logo!

**********************************************
At 12:55 PM 9/10/96 -0400, you wrote:
{Quote hidden}

'Dallas DS1202S RTC...help with code?'
1996\09\12@025010 by Ken Parkyn

flavicon
picon face
Hullo all;
Can anyone help me with how to use the above Real Time Clock.
I want to use it with a 16C84
Ta

*********************************************************
Ken Parkyn             email: K.ParkynEraseMEspamsct.gu.edu.au
Electronics Workshop   phone: (07) 3875 7289
Home:                  phone: (07) 3841 5135
Division of Science and Technology  fax:   (07) 3875 7656
Griffith University
Nathan QLD 4111
Australia  Office: Science 2  Room -1.17
*********************************************************

1996\09\12@030911 by donmck

flavicon
face
Ken Parkyn wrote:
>
> Hullo all;
> Can anyone help me with how to use the above Real Time Clock.
> I want to use it with a 16C84
> Ta
>
> *********************************************************
> Ken Parkyn             email: EraseMEK.ParkynspamspamBeGonesct.gu.edu.au

As one of my customers Ken, you haven't been reading my promo disk have
you. :)

Code in MicroChip Assembly, Basic Stamp 2, and FED Basic are available
from:
http://www.labyrinth.net.au/~donmck/rtc.html
Also the 1302 is a pin compatible equiv with many new features at the
same price.
Don...

Don McKenzie TakeThisOuTdonmckspamTakeThisOuTlabyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
Picosaurus(tm) 40 pin FED Basic with 8 channels of A-D, and real Uart.
MEL PicBasic Compiler. Programmers from 15 USD.  Pic-Axe(tm) A New Tool.

'Help with 68HC705C8 code'
1996\09\13@094127 by Charles Gautier

flavicon
face
Hello everyone,

I have a really weird problem to submit.  I have this binary to bcd
conversion routine that works for most values.  It takes the two byte
binary value storred in "BUFFER" and converts it to its four byte BCD
equivalent.  When I submit values that end with $FC ($01FC, $02FC,
etc.), the routine fails, although it works properly when walked through
by hand and using simulator software.  I have included the routine here
for reference.   Any help would be apreciated.

Thanks in advance.



;*******
; BINBCD
;
; This routine implements the binary to BCD conversion (not ASCII).
; A pointer to an array containing the binary data (up to 2 bytes) is
; passed in buffer. The data is passed on least significant byte
; first, and the buffer must be 5 bytes long. The result is placed in
; the input buffer, least significant digit first.
;
;  Variables needed by the routine:
;
; buffer        rmb    6
; bin_word      rmb    2
;
; *******

?binbcd         lda     buffer
               sta     bin_word
               lda     buffer+1
               sta     bin_word+1
               lda     #$00
               sta     buffer+1
               sta     buffer+2
               sta     buffer+3
               sta     buffer+4
               lda     bin_word
               sub     #$10
               sta     temp
               lda     bin_word+1
               sbc     #$27
               sta     temp+1

?bincd_dig4     lda     temp+1
               blo     ?bincd_dig3_in
               sta     bin_word+1
               lda     temp
               sta     bin_word
               inc     buffer+4
               sub     #$10
               sta     temp
               lda     temp+1
               sbc     #$27
               sta     temp+1
               bra     ?bincd_dig4

?bincd_dig3_in  lda     bin_word
               sub     #$e8
               sta     temp
               lda     bin_word+1
               sbc     #$03
               sta     temp+1

?bincd_dig3     lda     temp+1
               blo     ?bincd_dig2_in
               sta     bin_word+1
               lda     temp
               sta     bin_word
               inc     buffer+3
               sub     #$e8
               sta     temp
               lda     temp+1
               sbc     #$03
               sta     temp+1
               bra     ?bincd_dig3

?bincd_dig2_in  lda     bin_word
               sub     #$64
               sta     temp
               lda     bin_word+1
               sbc     #$00
               sta     temp+1

?bincd_dig2     lda     temp+1
               blo     ?bincd_dig1_in
               sta     bin_word+1
               lda     temp
               sta     bin_word
               inc     buffer+2
               sub     #$64
               sta     temp
               lda     temp+1
               sbc     #$00
               sta     temp+1
               bra     ?bincd_dig2

?bincd_dig1_in  lda     bin_word
               sub     #$0a
               sta     temp

?bincd_dig1     lda     temp
               blo     ?bincd_dig0_in
               sta     bin_word
               inc     buffer+1
               sub     #$0a
               sta     temp
               bra     ?bincd_dig1

?bincd_dig0_in  lda     bin_word
               sta     buffer
               rts

'pic code recovery'
1996\09\18@211056 by Steven Barry

flavicon
face
Dear Friends,

My hard drive crashed with a code for a Pic16c56,
Luckily I have a few pics laying around with this code,However
I had secured them.
Since there are a number of people offering this service, I am
intrigued to doing it myself.

Does anyone know how to reset the code ?
Where is the reset point located on the die ?
What do you use to reset it ?

Any information you can give me will be much appreciated

Thank you for your attention and cooperation

and Best regards from Steven Barry

1996\09\18@233350 by Todd Peterson

picon face
At 05:30 AM 9/18/96 -0700, you wrote:
>Dear Friends,
>
>My hard drive crashed with a code for a Pic16c56,
>Luckily I have a few pics laying around with this code,However
>I had secured them.
>Since there are a number of people offering this service, I am
>intrigued to doing it myself.


I'd try resurrecting the hard drive.  A company called Micro2000 makes some
good software (http://www.micro2000.com).  Also other companies.

Didn't you have ANY printed copies?

Good luck,

Todd Peterson

'SPI bus code'
1996\09\20@093342 by Gael Waiche

picon face
Thu, 19 Sep 1996 Micheal Yano Wrote:

>The last issue of MicroComputer Journal has a good article on SPI.
>
>Any chance that I could see your PIC code?
> Thanks.
>

Thanks for answering me, but as I live in France, I can't get a copy
of MicroComputer Journal... So I still need to know more about the
SPI bus. If nobody else from the the list can help me, would you mind
typing and sending me this article, or even sending me a copy by snail
mail?

Here is the PIC code I was talking about that implements SPI bus:

; Filename: ADVSPI.ASM
; **********************************************
; * Advanced Seminar Sample File               *
; * Revision: 1.0                              *
; * Date      Feb 6, 1996                      *
; **********************************************
; ****************************************************************************
; * This program shows examples of SPI transmission and reception            *
; ****************************************************************************
       LIST     P=16C74,F=INHX8M,R=DEC       ; Set processor to 16C74
       #INCLUDE C:/MPLAB/P16C74.INC ; Include processor INC file
       __CONFIG _XT_OSC&_WDT_OFF&_CP_OFF     ; Set up config bits
       __IDLOCS 5678                         ; Set up ID locations
       ERRORLEVEL 1,-302                     ; Turn OFF message ID 302

COUNT           EQU     20h     ; Location of count variable to count bits
SPIDATAL        EQU     21h     ; Location of SPI low byte data
SPIDATAH        EQU     22h     ; Location of SPI high byte data
#define         DOUT    PORTA,0 ; SPI port DOUT signal
#define         CS      PORTA,1 ; SPI port CS signal
#define         SCLK    PORTA,2 ; SPI port SCLK signal
#define         DIN     PORTA,3 ; SPI port DIN signal

       ORG 0
       clrf    PORTA           ; Clear output latch register
       bsf     STATUS,RP0      ; Switch to bank 1
       movlw   b'11111000'     ; Place PORTA direction data into W
       movwf   TRISB           ; Set RA0-2 outputs, RA3 input
       movlw   7               ; Place 7 into W
       movwf   ADCON1          ; Make RAX digital inputs
       bcf     STATUS,RP0      ; Switch to bank 0
mainloop
       movlw   b'01010101'     ; Place alternating 1 and 0 into W
       movwf   SPIDATAL        ; init SPI data low register
       movlw   b'00001111'     ; Place 00001111 into W
       movwf   SPIDATAH        ; init SPI data high register
       call    spidataio       ; Send/receive SPI data
       goto    mainloop        ; Jump back and do it again!

;**************************************************
;* 16 bit SPI serial I/O xmit and receive routine *
;* Data to Transmit:     ADRESL, ADRESH           *
;* Data to Receive:      ADRESL, ADRESH           *
;* Time = (13 * 16) + 7 = 215 cycles              *
;**************************************************
spidataio
       movlw   .16             ; Place bit count value into W
       movwf   COUNT           ; W -> COUNT for counting bits
       bcf     CS              ; Select the SPI device
loopspidata
       bcf     STATUS,C        ; Assume we are receiving a ZERO from SPI device
       btfsc   DIN             ; Skip if we are receiving a ZERO from SPI devic
e
       bsf     STATUS,C        ; Receive a ONE from the DIN line
       rlf     SPIDATAL,F      ; Rotate received bit into Low digit
       rlf     SPIDATAH,F      ; Rotate high digit, place xmiit bit into carry
       bcf     DOUT            ; Assume we are transmitting a ZERO to SPI devic
e
       btfsc   STATUS,C        ; Skip if we are senDOUTg a ZERO to SPI device
       bsf     DOUT            ; Transmit a ONE onto the DOUT line
       bsf     SCLK            ; Clock in the DOUT output
       bcf     SCLK            ; Lets get ready to clock the next digit!
       decfsz  COUNT,F         ; Skip if we have XMIT/RCV all 16 bits
       goto    loopspidata     ; Not done yet so loop back for next bit
       bsf     CS              ; De-select the SPI device
       return                  ; DONE receiving/xmiting - GO HOME!

   END


This file has been found on the Microchip's ftp server.

Bye

Gael.

'Need code to generate RC-5 infra red commands'
1996\09\24@101629 by Tim Jackson

flavicon
face
Hello all,

I am trying to find suitable code to allow me to connect and infra-red
LED to a port on a 16C84 so that I can remote control a Philips VCR.

I need to be able to generate the relevant infra-red output for the
following commands: POWER ON, RECORD, STOP.

If anyone's already done something like this I'd appreciate any advice
and especially some code too :-)

I expect there's a project lurking on a Web page somewhere that would
solve my problem but so far I haven't found one.

Thanks.



    /\_/\
   / o o \
  (== ^ ==)
    ) - (
   ( ) ( )
 ( ( ) ( ) )
 (_(_)_(_)_)

1996\09\24@104944 by Miller, Steve

flavicon
face
To transmit a long distance, you will need to use an external transistor
to boost the drive current of the output pin.  The PIC's output is
current limited.  The code is simply a variant of the bit bang serial
communication routine.  What is harder to come by is the actual codes,
baud rates, and encoding schemes that need to be transmitted.
Manufacturers are very tight with this info.  Several years ago I needed
to decode a SONY IR signal.  SONY was no help at all.  I ended up using a
logic analyzer to capture the output and then wrote my code mimic it.
Universal remotes are available for cheap these days.  If you are making
only a few of these devices, I would suggest that you purchase a
universal remote as your IR engine and use the PIC to fake out the key
closure on the universal remote.
That would be the quickest way to get it up and running.

stevemspamspam_OUTtanisys.com

----------
From:  pic microcontroller discussion [SMTP:spamPICLIST@spam@spamMITVMA.MIT.EDU]
Sent:  Tuesday, September 24, 1996 2:11 PM
To:  Multiple recipients of list PIC
Subject:  Need code to generate RC-5 infra red commands

To:           Multiple recipients of list PICLIST
<spam_OUTPICLISTTakeThisOuTspamKILLspamMITVMA.MIT.EDU>

Hello all,

I am trying to find suitable code to allow me to connect and infra-red
LED to a port on a 16C84 so that I can remote control a Philips VCR.

I need to be able to generate the relevant infra-red output for the
following commands: POWER ON, RECORD, STOP.

If anyone's already done something like this I'd appreciate any advice
and especially some code too :-)

I expect there's a project lurking on a Web page somewhere that would
solve my problem but so far I haven't found one.

Thanks.



    /\_/\
   / o o \
  (== ^ ==)
    ) - (
   ( ) ( )
 ( ( ) ( ) )
 (_(_)_(_)_)

1996\09\24@114656 by Tim Jackson

flavicon
face
>What is harder to come by is the actual codes ... manufacturers are
>very tight with this info.

No problem at all. The Philips RC-5 code, with all the detailed spec, is
readily available all over the show, especially on the Net.

>Universal remotes are available for cheap these days.  If you are making
>only a few of these devices, I would suggest that you purchase a
>universal remote as your IR engine and use the PIC to fake out the key
>closure on the universal remote.
>That would be the quickest way to get it up and running.

My final product will be a simple small black box with a few terminals
on it and an infra-red LED sticking out the one end.

The black box will be positioned directly in front of the VCR so the
maximum transmission distance doesn't have to be more than about a foot
or so.

I could certainly use one the many universal remotes that are around but
I want a matchbox sized unit which is going to do some timing based on
the state of the inputs and then output one of a few RC-5 commands so
that a PIC-based unit is just what I need.



    /\_/\
   / o o \
  (== ^ ==)
    ) - (
   ( ) ( )
 ( ( ) ( ) )
 (_(_)_(_)_)

'Need code to generate RC-5 infra red commands -Rep'
1996\09\24@121149 by Mark Jurras

flavicon
face
Easy way is to reverse engineer the VCR remote control. Put a scope on the
output of the chip that drives the LED and look for the frequency of the
burst 30-50Khz and the Burst Length for each bit and the burst pattern for
each command.

    _   _   _                   _   _   _         _   _   _
   | | | | | |                 | | | | | |       | | | | | |
____| |_| |_| |_________________| |_| |_| |_______| |_| |_| |_______

>>> Tim Jackson <RemoveMEtimj@spam@spamspamICON.CO.ZA> 24 September 1996  10:11 am >>>

I need to be able to generate the relevant infra-red output for the
following commands: POWER ON, RECORD, STOP.

If anyone's already done something like this I'd appreciate any advice
and especially some code too :-)

1996\09\24@122225 by Tim Jackson

flavicon
face
>Easy way is to reverse engineer the VCR remote control. Put a scope on the
>output of the chip that drives the LED and look for the frequency of the
>burst 30-50Khz and the Burst Length for each bit and the burst pattern for
>each command.

No problem in finding the full specification for the RC-5 code. I have
that already and it's available on the Net.

I was hoping someone had written the code for a PIC to GENERATE the
necessary pulse stream to drive an infra-red LED.


    /\_/\
   / o o \
  (== ^ ==)
    ) - (
   ( ) ( )
 ( ( ) ( ) )
 (_(_)_(_)_)

1996\09\24@123645 by Miller, Steve

flavicon
face
Some Sony code is available at the URL listed below.
This code is the property of Eric Smith and I am only pointing to it as a
reference.  I have not used his code and cannot comment as to its
accuracy.  Since the requirement is a Phillips system, the IR output
section would have to be modified to conform to Phillips specs.  However
this code could be a good starting point.

http://www.brouhaha.com/~eric/pic/index.html

1996\09\24@131449 by myke predko

flavicon
face
>>Easy way is to reverse engineer the VCR remote control. Put a scope on the
>>output of the chip that drives the LED and look for the frequency of the
>>burst 30-50Khz and the Burst Length for each bit and the burst pattern for
>>each command.
>
>No problem in finding the full specification for the RC-5 code. I have
>that already and it's available on the Net.
>

Don't count on the data on the Net being correct!  When I did my code for
the Sony I/R Receiver, I initially first used data in a magazine article
(which worked fine in the simulator, not in the real world) and then used
data from the Net (which worked just about as well as the magazine data).
To finally get it up and running, I had to look at the output on a 'scope
and measure everything.  Not a lot of work.  But it's necessary.

Myke

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

1996\09\24@132249 by Kalle Pihlajasaari

flavicon
face
Hi Tim,

> No problem in finding the full specification for the RC-5 code. I have
> that already and it's available on the Net.
>
> I was hoping someone had written the code for a PIC to GENERATE the
> necessary pulse stream to drive an infra-red LED.

You can have a look at a demo I did a few years ago (when PICs were
on the up and up) to test the life of batteries.  This used a
16C54(JW) at 3 volts with a 4MHz resonator if I recall and would
send out data continuously for about 3 days from a pair of N type
batteries (Half AAA) with an incrementing counter.  The code was
raw ASYNC data that I would feed into a PC with a SHARP integrated
receiver and a OPamp inverter and I could then see what was the last
sequence number.

You can have a look at the code made to assemble with the early
PICALC but should be adjustable :-)

http://www.ip.co.za/people/kalle/pic/irkey.asm

Cheers
--
Kalle Pihlajasaari     RemoveMEkalleRemoveMEspamTakeThisOuTdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1996\09\24@151107 by Eric Smith

flavicon
face
Tim Jackson <timjTakeThisOuTspam@spam@ICON.CO.ZA> wrote:
> I am trying to find suitable code to allow me to connect and infra-red
> LED to a port on a 16C84 so that I can remote control a Philips VCR.

It won't directly solve your problem, but there is code on one of my
web pages for controlling Sony equipment.  Perhaps it would be useful as
an example.

       http://www.brouhaha.com/~eric/pic/controls.html

Cheers,
Eric

1996\09\24@215610 by Steve Hardy

flavicon
face
{Quote hidden}

This just happens to be my specialty.  Since you only need a short
transmission distance, driving the IR LED directly from the PIC port
via a 220ohm resistor will give more than sufficient range.  The PIC
can also be coerced into modulating the LED at 40KHz or so, but you
will need to disable interrupts since it is a fairly tight code loop.

When programming the '84, one must decide on a suitable timebase.  The
logical choice is 256 instruction cycles i.e. TMR0 overflow when TMR0
is not prescaled.  At 10MHz, this translates to 102.4us.  Since most IR
control signals operate in bursts of at least 400us, this is an
adequate resolution.  The longest bursts last for less than 20ms, so a
counter (1..255) for the duration of each burst, in 102.4us units,
would also be adequate.

There needs to be a method of storing the codes.  The method I use is
to store a sequence of numbers such as

  5 10 20 5 13 8

The first number, 5, is a count of the following numbers.  Each of the
other numbers is a duration count i.e. on for 10 units, off for 20, on
for 5 etc.  There would always be an odd number of these, since the
last state whose duration is recorded should be an 'on' state.

I am not directly familiar with the Phillips spec, but most controls I
have examined use up to 32 transitions.  One Sony control was really
complex, with more than 64 transitions per code!

Since the 3 different codes you want to store will probably take up
more than 64 bytes, you won't be able to store them in the EEPROM.
Unless you can find an optimisation (e.g. common starting sequence)
then you are pretty much forced to 'hard code' the transition table in
the device's program memory i.e. use the retlw table lookup method.

Next comes the tricky bit.  If you don't have a-priori knowledge of the
code timings, then you need an empirical approach.  You will need to
purchase an IR demodulator module.  These have an active low output,
with the 40KHz carrier removed.  Next, make up a cable to attach to
your PC's parallel port.  The cable will supply power to the
demodulator, and also read its output.  Another input pin will supply a
steady clock with a period of 102.4us.  The PC (in a tight loop, with
interrupts disabled) polls the parallel port looking for the timing and
IR signals.  After a suitable maximum time it exits the loop and
displays the results.  A bit of extra code can automatically generate a
series of retlw instructions suitable for direct inclusion in the rest
of your PIC assembler.

[Practical note: those IR demodulators require a 0.1uF decoupling cap
across the supply.  Omission of this has caused me untold grief!]

You will notice that most controls repeat a sequence as long as the
button is pressed.  Your PC program should be smart enough to detect
the relatively long breaks between successive transmissions of the same
code.  You should note the break time (which can range from 20 to 300ms
in the controls I tested) and emulate it in the PIC code if necessary.

Since some devices will not perform the requested function if the code
is received only once (especially RECORD), it is best to repeat the
same code 3 or 4 times to be sure, to be sure...

Now regarding some practical PIC code, I have developed a kit which
performs a limited form of IR transmission.  Since the code for the kit
is public domain (copyright retained by me) I am happy to extract the
relevant part for your perusal.  Contact me directly, or if enough
interest I will post to this list (it's not all that long).  This code
will directly modulate an LED at 39KHz in chunks of 100us or so.

My current project is a universal remote control with lots of added
smarts, using a 16C74.  If only the !@#$ Parallax software would work!
The overriding project aims are to produce a control which looks and
feels good, lasts forever, a maximum of 40 large buttons, as easy to
use as a toaster, and more intelligence than the average toaster user.

Regards,
SJH
Canberra, Australia

1996\09\24@221434 by John Payson

flavicon
face
> Since some devices will not perform the requested function if the code
> is received only once (especially RECORD), it is best to repeat the
> same code 3 or 4 times to be sure, to be sure...

Another difficulty which has caused me grief in my efforts to find a good
universal remote for my home system is that at least one brand of stereo
receiver (my Magnavox unit) uses at least two different codes for every
button and repeated button pushes generate different codes.  So if the
"5" key on the remote has codes "f" and "F" and I punch in "555", the
remote would send out

     fffff      FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF     ffffffffffffff

Although this is a good design and provides excellent debounce properties,
it means that a universal remote would have to know two (or more) codes
for each button as the main unit will ignore any invalid key repeats.  I
don't know if any other devices use such a scheme (I'd like it myself if
I could program a remote to deal with it) but you might want to watch out
for it.

1996\09\24@224549 by Steve Hardy

flavicon
face
{Quote hidden}

Ah, so it's not my imagination!  I noticed this 'feature' on my Rotel CD
player.  I will have to add knowledge of this to my control.  Thanks.

Regards,
SJH
Canberra, Australia

1996\09\25@005750 by Prashant Bhandary

flavicon
picon face
> I am trying to find suitable code to allow me to connect and infra-red
> LED to a port on a 16C84 so that I can remote control a Philips VCR.
>
> I need to be able to generate the relevant infra-red output for the
> following commands: POWER ON, RECORD, STOP.
>
> If anyone's already done something like this I'd appreciate any advice
> and especially some code too :-)
>

A great reference for IR remotes in general can be found at
ftp://hemul.nada.kth.se/home/d89-bga/hp/files/REMOTE/REMOTE.HTML. It talks
about using an HP48 but important bit is a comprehensive description
of more IR remotes than you can count on a Martian hand.

Long ago, I had a requirement for a remote 'translator'. I have two Sony
VCRs and they have the same signals. So I came up with this scheme of
building a translator which would respond to commands for a unit I don't have
- a Philips CD for example - and then translate it to Sony VCR signals.
This unit would sit in front of my second VCR blocking the IR window. When I
use a Sony remote, the first VCR will respond and when I use a second non-Sony
remote the translator would trigger the second VCR. A programmable remote
would combine both remotes into one.

Anyway, like most of my projects, I did only part of it. I built a PIC circuit
to detect Sony signals - now why did I do that? I wanted something that detects
a non-Sony signal. Anyway, I had it decoding most Sony signals and sending the
result on a serial port to a VB program. This program would display the
function name. This worked. After that I tried a remote IR analyser which sensed
the IR signal and encoded the result and sent it on a serial port. A VB program
then displayed it like an oscilloscope signal. I got that working as well. At
this point I reached the end of my short attention span and then I... now what
was I just talking about?

Regards

Prashant

P.S. You are welcome to code, circuits or anything. It is just a jumble right
now.
And another important tip for IR demodulators - make sure you ground the
suckers.
--------------------------------+---------------------------------
 Prashant Bhandary             | Tel:  +61-2-9662 5299
 Spatial Information Solutions | Fax:  +61-2-9662 5348
 Roads and Traffic Authority   | Email: spamprashbTakeThisOuTspamrta.nsw.gov.au
 Rosebery NSW 2018, AUSTRALIA  | "2b|!2b" - William Shakespeare
--------------------------------+---------------------------------

1996\09\25@083724 by Anssi Ylatalo

flavicon
face
On Tue, 24 Sep 1996, Tim Jackson wrote:

> Hello all,
>
> I am trying to find suitable code to allow me to connect and infra-red
> LED to a port on a 16C84 so that I can remote control a Philips VCR.
>
My IR-related pic-stuff can be found at

       http://www.kotakk.fi/~y95sanyl/IR/

Feel free to use/hack/port/whatever ;-)

Anssi
---------------------------------------------------------------------
 Anssi Ylatalo                 Tel. +358-51-3118
 Viertolantie 20 B 9                +358-400-770 070
 45200 KOUVOLA
 FINLAND                       http://www.kouvola.ksaok.fi/~aylatalo

1996\09\25@084139 by Jacob Blichfeldt

flavicon
face
part 0 3997 bytes
When programming the '84, one must decide on a suitable timebase.  The
logical choice is 256 instruction cycles i.e. TMR0 overflow when TMR0
is not prescaled.  At 10MHz, this translates to 102.4us.  Since most IR
control signals operate in bursts of at least 400us, this is an
adequate resolution.  The longest bursts last for less than 20ms, so a
counter (1..255) for the duration of each burst, in 102.4us units,
would also be adequate.

There needs to be a method of storing the codes.  The method I use is
to store a sequence of numbers such as

  5 10 20 5 13 8

The first number, 5, is a count of the following numbers.  Each of the
other numbers is a duration count i.e. on for 10 units, off for 20, on
for 5 etc.  There would always be an odd number of these, since the
last state whose duration is recorded should be an 'on' state.

I am not directly familiar with the Phillips spec, but most controls I
have examined use up to 32 transitions.  One Sony control was really
complex, with more than 64 transitions per code!

Since the 3 different codes you want to store will probably take up
more than 64 bytes, you won't be able to store them in the EEPROM.
Unless you can find an optimisation (e.g. common starting sequence)
then you are pretty much forced to 'hard code' the transition table in
the device's program memory i.e. use the retlw table lookup method.

Next comes the tricky bit.  If you don't have a-priori knowledge of the
code timings, then you need an empirical approach.  You will need to
purchase an IR demodulator module.  These have an active low output,
with the 40KHz carrier removed.  Next, make up a cable to attach to
your PC's parallel port.  The cable will supply power to the
demodulator, and also read its output.  Another input pin will supply a
steady clock with a period of 102.4us.  The PC (in a tight loop, with
interrupts disabled) polls the parallel port looking for the timing and
IR signals.  After a suitable maximum time it exits the loop and
displays the results.  A bit of extra code can automatically generate a
series of retlw instructions suitable for direct inclusion in the rest
of your PIC assembler.

[Practical note: those IR demodulators require a 0.1uF decoupling cap
across the supply.  Omission of this has caused me untold grief!]

You will notice that most controls repeat a sequence as long as the
button is pressed.  Your PC program should be smart enough to detect
the relatively long breaks between successive transmissions of the same
code.  You should note the break time (which can range from 20 to 300ms
in the controls I tested) and emulate it in the PIC code if necessary.

RC-5 codes allready use a bit for 'showing' if the transmission have been breaked. A bit (no. 2 or 3 I think) toggles each time you release and press the button again.

Since some devices will not perform the requested function if the code
is received only once (especially RECORD), it is best to repeat the
same code 3 or 4 times to be sure, to be sure...

Now regarding some practical PIC code, I have developed a kit which
performs a limited form of IR transmission.  Since the code for the kit
is public domain (copyright retained by me) I am happy to extract the
relevant part for your perusal.  Contact me directly, or if enough
interest I will post to this list (it's not all that long).  This code
will directly modulate an LED at 39KHz in chunks of 100us or so.

I would like to see this piece of code too...

My current project is a universal remote control with lots of added
smarts, using a 16C74.  If only the !@#$ Parallax software would work!
The overriding project aims are to produce a control which looks and
feels good, lasts forever, a maximum of 40 large buttons, as easy to
use as a toaster, and more intelligence than the average toaster user.

Have you found any intelligent way of learning/storing the codes (for each button)? Or do you use a look-up table?

Regards,
SJH
Canberra, Australia


Regards
Jacob Blichfeldt

1996\09\25@084143 by Jacob Blichfeldt

flavicon
face
part 0 2462 bytes
----------
From:   Steve Hardy[SMTP:.....hardyspamspamBeGoneSWENG.STORTEK.COM]
Sent:   25. september 1996 19:49
To:     Multiple recipients of list PICLIST
Subject:        Re: Need code to generate RC-5 infra red

{Quote hidden}

On an old Grundig remote I have for a (just as old) television, the transmission (when a button is pressed) begins with one code, a break and then another. The last code is then transmitted repeatedly until the button is released. The first code might be for 'waking up' the standby unit in the receiver?

Ah, so it's not my imagination!  I noticed this 'feature' on my Rotel CD
player.  I will have to add knowledge of this to my control.  Thanks.

Have you any ideas of how to do that? I guess its no problem when the code allready have been 'learned' and stored, but what about the first time when its about to be stored?
Furthermore, what about the 'toggle' bit in the RC-5 format which toggles everytime the (same) button is released and depressed? If you learn one of the codes, ie. toggle-bit set to ex. 1, it'll present problems as the receiver won't be able to separate an IR-break, or a depressed button (will present a problem when muting, among others).

Regards,
SJH
Canberra, Australia


Regards
Jacob Blichfeldt, Denmark

1996\09\25@214012 by Steve Hardy

flavicon
face
> From: Jacob Blichfeldt <RemoveMEblchfldtspamspamKILLspamPOST3.TELE.DK>

Just one little thing, Jacob: when including quote from previous posting,
please make it distinct from the text _you_ add e.g. put '>' signs at
the start of each line.  Then it's so much easier for a respondent to
sort out the new stuff from the old.  Also, get rid of your long encoded
SIG - most of us can't make sense of it.

Having said that, this post replies to several postings in a similar
vein...

1:

{Quote hidden}

See below (4) for an explanation of why this 'code hopping' may not be such
a problem for learning remotes in practice.  However, I am not going to
take any chances with the remote I am building.  My proposal is to allow
the user (programmer) to press the button on the original remote _twice_.
The code in the universal remote (URC) will then examine the code sequences
to see if there is any difference.  If not, only one entry will be stored.
Otherwise, a 'primary' and 'alternate' sequence will be stored.

In the case that the first code (of any long button press) is different
from the auto-repeats, then the URC will recognise this and store a third
sequence called 'prologue'.

Since this is going to take a fair slice of the 16K of serial EEPROM I've
got, even more smarts will be required to find common sub-sequences and
munge them all together as 'macros'.  This, I'm afraid, will probably
have to take place in the external IBM PC - the SEEPROM contents will be
uploaded, manipulated in the PC, then downloaded in compressed form.

2:

{Quote hidden}

As said above, 100us resolution is adequate.  You must have a steady
clock, though.

> To overcome the problem: Resolution/max. time between transistions, I =
> thougt about using some kind of floating point format (unsigned, and in =
> a format easy to decode/encode by a PIC).

Don't bother.  Just use unsigned counts.

>
> Is there really no special way a binary sequence can be encoded, for =
> later comparision? Averaging or maybe some exotic mathematical way?
>

See above.  Since it's not strictly a 'binary sequence' (that implies
some assumptions about the encoding method) but rather a sequence of
timings, it is sufficient to just compare the lists of timings.  When
comparing samples in the sequence, assume the timings are equal if they
are different by 0 or 1.  E.g.  7 and 8 are considered 'equal' timings,
but not 7 and 9.  The sum of timings should also be within, say, 2 counts.

>
> 2. In my application I really dont need to know what the code means. I =
> just need to (free) buttons on a remote-control, one for up and one for =
> down. These are the only buttons the lightdimmer will have to learn, and =
> their original  purpose (on the RCU) doesn't mean anything.
>
> I would very much like to see your [Myke's] code.

3:

> From: Jacob Blichfeldt <blchfldtspamBeGonespamPOST3.TELE.DK>
>
> I would like to see this [SJH's] piece of code too...
>
> Have you found any intelligent way of learning/storing the codes (for =
> each button)? Or do you use a look-up table?

Since a few people have asked, the code is below (i.e. code for transmit
IR signal with 39KHz carrier, for PIC16C84).  Yes, there are reasonably
intelligent ways of storing the codes.  The way I do it uses the following
algorithm:

       Wait for IR signal (or abort if user presses key).
       Loop until 1 second or buffer full:
               Wait for next IR transition
               Store difference in time between this trans and the last
               Increment buffer pointer
       Search for repetitions of the same code.
       If repetitions found, isolate the basic sequence and store.

It is sufficient to store time differences in units of 100us.  When using
a PIC or any other device with limited memory resorces, the time differences
are stored in compressed format e.g. if the time diff is less than 128,
it is stored in 1 byte.  If > 128, it is stored in 2 bytes with the most
significant bit set to 1.  Most of the samples will store in 1 byte.
The final result is a string of bytes like

 <length of seq> <on time 1> <off time 1> <on time 2> <off time 2> etc.

You might be disappointed that it takes 30 odd bytes to store 1 code.
However, for a truly _universal_ remote control, it cannot make any
assumptions that the code is some binary encoding; i.e. such that it can
be analysed and stored in just a few bytes.  There are just too many
possibilities for encoding 0's and 1's.  Some encoding methods even use
trinary encoding: how are you going to store those pesky 2's?

4:

{Quote hidden}

Thanks for performing the experiment, Scott.  When you think about it, it
makes sense that the device should not _require_ alternating codes.  After
all, it would be a bit arrogant on the part of the device if it didn't
respond the the same code twice (after a suitable delay, perhaps).  How
could the device be sure that the 'alternate' code was not sent from the
control, but merely missed because the control was not pointed correctly.

Regards,
SJH
Canberra, Australia

The following code should be assembled using "MPASM filename.asm /c-"
Uses 2 file regs.


;=========================================================================
; IRMOD.ASM  --  IR modulation driver routines
;
; This source code is Copyright (C) Stephen James Hardy,
; Latham, A.C.T., Australia.
;
; Permission is hereby granted by the copyright owner for any individual
; to copy or modify this source code providing that this notice is
; retained in its entirety and providing that the source code or
; modifications thereof are not used for commercial gain.
;=========================================================================


       list    p=pic16c84
       include "p16c84.inc"

       radix   dec

CLKSPD  equ     10              ; Target clock speed (MHz).
                               ; Note that most of the code commentary
                               ; assumes a clock speed of 10MHz.

       if      CLKSPD==10
irmodlc equ     9               ; Loop timing constants for 39KHz mod.
irmodlc2 equ    9
prescale equ    1               ; exponent of 2 to divide TMR0 rate.
                               ; If 0, ticks over in 102.4us.  If 1,
                               ; basic unit is then 204.8us etc.
       else
       error   "Unsupported clock speed"
       endif


;-----------------------------------------------------------------
; Register mapping:
;-----------------------------------------------------------------
RBASE   equ     0Ch

       cblock  RBASE

       icounter                ; IR Tx delay counter

       endc



;-----------------------------------------------------------------
; Port pin mapping.  NB: If ports changed, modify pwrup code to
; select correct TRIS register:
;-----------------------------------------------------------------

IRLEDP  equ     porta
IRLEDB  equ     1               ; IR LED: RA1.  Active high.

DOUTP   equ     porta
DOUTB   equ     0               ; RA0 reflects state of IR transmit, without
                               ; modulation by 39KHz carrier.  Active low.


       org     0
;-----------------------------------------------------------------
; Power-up/reset initialisation
;-----------------------------------------------------------------
pwrup   clrf    porta           ; Port A outputs to zero (inactive)
       bsf     DOUTP,DOUTB     ; Except DOUT is inactive high.
       bsf     status,rp0      ; Select bank 1
       movlw   ~((1<<IRLEDB)|(1<<DOUTP)) ; All inputs except these two
       movwf   trisa
; Set RB pullups, falling edge interrupt, increment t0 on instruction cycle,
; assign prescaler as appropriate.
       if      prescale==0
       movlw   1<<psa
       else
       movlw   prescale-1
       endif
       movwf   option_reg

       clrf    status          ; Back to bank 0.


; Your code goes here.  E.g...

timeon  equ     6               ; 6 x unit on
timeoff equ     10              ; 10 x unit off

loop    movlw   timeon
       movwf   pcount
onloop  call    irmod
       decfsz  pcount
       goto    onloop
       movlw   timeoff
       movwf   pcount
offloop call    irmute
       decfsz  pcount
       goto    offloop
       goto    loop            ; Loop forever.

;------------------------------------------------------------------------
; Output 38KHz modulated IR until MSB of TMR0 transits high->low.  Leaves
; output off at return.  LED on for 13us, then off for 13us.  Must be
; called with interrupts disabled, and tmr0 should be >= zero and small.
; The prescaler can be used to change duration of transmission (1x, 2x, 4x,
; 8x etc).
;
; Either irmod or irmute is called.  irmod outputs modulated IR until
; TMR0 overflows to 0.  irmute merely waits for TMR0 to wrap.
;------------------------------------------------------------------------
irmod   bcf     DOUTP,DOUTB     ; Reflect active transmission
irmloop btfsc   tmr0,7          ; 1
       goto    lookfall        ; 2,3 - If high, look for falling edge
       bsf     IRLEDP,IRLEDB   ; 3
       movlw   irmodlc         ; 4
       movwf   icounter        ; 5
       decfsz  icounter        ;
       goto    $-1             ;
       if      clkspd==10
       nop
       endif
       bcf     IRLEDP,IRLEDB   ; 14
       movlw   irmodlc2        ; 15
       movwf   icounter        ; 16
       decfsz  icounter        ;
       goto    $-1             ;
       if      clkspd==10
       nop
       endif
       goto    irmloop         ; 25,26

lookfall bsf    IRLEDP,IRLEDB   ; 1
       movlw   irmodlc         ; 2
       movwf   icounter        ; 3
       decfsz  icounter        ;
       goto    $-1             ;
       bcf     IRLEDP,IRLEDB   ; 12
       movlw   irmodlc2        ; 13
       movwf   icounter        ; 14
       decfsz  icounter        ;
       goto    $-1             ;
       nop                     ; 23
       btfsc   tmr0,7          ; 24
       goto    lookfall        ; 25,26
       return

; Wait for falling edge of TMR0 MSB without transmitting IR.
irmute  bsf     DOUTP,DOUTB     ; Reflect inactive transmission
       btfss   tmr0,7
       goto    $-1
       btfsc   tmr0,7
       goto    $-1
       return



       end

'Dual code remote outputs'
1996\09\26@052432 by Kalle Pihlajasaari

flavicon
face
Hi,

{Quote hidden}

The Toshiba VCR that my neighbour has, has a learning feature.

It asks you to press the button on the donor remote TWICE.

Cheers
--
Kalle Pihlajasaari     spam_OUTkallespamspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

'Re : DTMF C.I. for encode-decode'
1996\09\27@234157 by hjmuller

flavicon
face
Jose Pineda Wrote:  (Jose Pineda escribio:)

> Date:    Thu, 26 Sep 1996 09:20:43 -0400
> From:    Jose Pineda <jpinedaspam_OUTspamRemoveMECONICIT.VE>
> Subject: DTMF
>
> Hi everybody:
>
>         I need to locate part numbers for chips for a reasonable cost
> which will accomplish the following functions:
>
>         1. Generator for DTMF, the entry of data can parallel or in
> serial.
>
>         2. Receiver for DTMF, the output of the data can be parallel or in
> serial.
>
>         I also need that they be independently integrated and that these
> functions are not incorporated in just one chip.
>
> Thank you.

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

English version (for the extensive majority)


Dear Jose:
         I am working in projects with relations to the telecommunications
and I utilize now integrated circuits for encoding-decoding DTMF signals.
         The comercial parts numbers are:
  DTMF encoder : UM91531 (Tone/Pulse diales with paralell input)
  DTMF decoder : UM9270/CMD8870 (DTMF decoder with latch)
         I hope it to be useful in your projects.
            Best Regards,   Hugo

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Version en espaniol (porque renegar del segundo idioma de internet ????)

No creen, los hispano-parlantes que se podrian enviar los mensajes en ambos
idomas a la lista ?, o al menos intentarlo si estos no son muy largos ....

Estimado Jose:
             Estoy trabajando en proyectos relacionados con las
telecomunicaciones y utilizo actualmente circuitos integrados para
codificar-decodificar DTMF.
             Los numeros de parte comerciales son :
   Codificador de DTMF: UM91531 (discador tono/pulso entrada paralela)
   Decodificador de DTMF : UM9270 o CMD8870 (Decodificador DTMF con latch)
             Espero que sean de utilidad para tus proyectos.
             Saludos,    Hugo

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+       Hugo Jorge Muller       +
=   H.J.M. Hardware & Software  =
+     Disen~os Electronicos     +
=      Esteban de Luca 74       =
+   (3100) PARANA (ENTRE RIOS)  +
-           ARGENTINA           -
*********************************
= E-mail : spamhjmullerspamBeGonespamSATLINK.COM =
+TEL/FAX/MODEM: (0054)-43-317569+
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=


'help with keyboard encoder'
1996\10\02@060704 by Herve Cousin
flavicon
face
Hi all,

for a small PIC-controlled terminal (LCD-Display), I got a "older"
mimi-keyboard (53 key) with a AY-5-2376 KB controller. Unfortunately, I did
not find any documentation about this chip. It has a label "GI" which is
probably General Instruments, however, as far as I know they have sold a
portion of their semiconductors. I also did not get any answer from their
technical support ... I am not a interessting client, probably ...

Does somebody have a data sheet or a pointer to it, or know this chip somehow ?

thanks for any help

Herve
Herve R. Cousin - Inorganic Analytical Chemistry,
Federal Institute of Technology (ETH-Z)
CH-8092 Zurich, Switzerland
Tel.:    + 41-1-632-4472, Fax:     + 41-1-632-1090,
spamcousinRemoveMEspaminorg.chem.ethz.ch, http://www.analytica.ethz.ch/cousin.html

'Anyone have 32 bit Binary to Ascii conversion code'
1996\10\02@114101 by Ted Linn

flavicon
face
One of the things I need to get a 16C57 to do is to convert a 32 bit binary
number to ascii for output to an LCD display.  I know an algorithm for doing
this but being new to this pic world I wondered if anyone would share code
or offer some suggestions or 'tricks' that might be helpful for doing this.

Thanks

'help with keyboard encoder'
1996\10\02@192232 by Robert Lunn

flavicon
face
>for a small PIC-controlled terminal (LCD-Display), I got a "older"
>mimi-keyboard (53 key) with a AY-5-2376 KB controller. Unfortunately, I did
>not find any documentation about this chip.

       I'll look in my old GI data book as soon as I can.

       May be a couple of days, though, before I get to my other
       office (where my data books are).

___Bob

1996\10\02@220611 by Robert Ct

flavicon
face
At 12:05 PM 10/02/96 +0200, you wrote:
>Hi all,
>
>for a small PIC-controlled terminal (LCD-Display), I got a "older"
>mimi-keyboard (53 key) with a AY-5-2376 KB controller. Unfortunately, I did
>not find any documentation about this chip. It has a label "GI" which is

Hi Herve,
I have information on this chip in the form of a booklet published by
SouthWest Technical Product Corporation called "Keyboard and Encoder".  This
10 page booklet includes a full schematic with pin numbering that should
help you find the info you need.  It also has all the code assignment chart
for lower and upper case mode.  I do not have a scanner handy but if you are
interested I will fax it to you.
As a quick overview, the 40 pin IC requires 5 volt on pin 1, -12 volts on
pin 18, ground on pin 17 and pin 20.  Shift and Control are at pin 4 and 5
respectively.  Matrix input from the keyboard goes to pin 21 to 37.  Outputs
are: 7 - parity, B1 - 15, B2 - 14, B3 - 13, B4 - 12, B5 - 11, B6 - 10 or 8
depending on case and B7 - pin 9.  The keypress (or strobe) comes from pin
7.  Pin 19 is connected to an RC combination consisting of a 0.01mf
capacitor and a 680k res.

Please let me know if you want the full booklet, I will gladly fax it to you.

Robert

1996\10\03@123157 by mike

flavicon
picon face
In message  <KILLspam2.2.32.19961002100509.00697c88spam_OUTspamspam_OUTelwood.ethz.ch>> PICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU writes:
> Hi all,
>
> for a small PIC-controlled terminal (LCD-Display), I got a "older"
> mimi-keyboard (53 key) with a AY-5-2376 KB controller. Unfortunately, I did
> not find any documentation about this chip. It has a label "GI" which is
> probably General Instruments, however, as far as I know they have sold a
> portion of their semiconductors. I also did not get any answer from their
> technical support ... I am not a interessting client, probably ...
>
> Does somebody have a data sheet or a pointer to it, or know this chip somehow
?
>


For what its worth, I used to use this chip some years ago, but it has
been obsolete for at least 8 years.

I know 'cos I spoke to a GI rep before designing it in to the product
and asked specifically if it was safe to design it in. I was told it was.

Six months later when trying to place pre-production quantity orders I
was given the news that it was no longer available. We had good success
it from some of the difficult to find IC suppliers though.


Regards,



Mike Watson

'Anyone have 32 bit Binary to Ascii conversion code'
1996\10\05@152709 by Ted Linn

picon face
One of the things I need to get a 16C57 to do is to convert a 32 bit binary
number to ascii for output to an LCD display.  I know an algorithm for doing
this but being new to this pic world I wondered if anyone would share code
or offer some suggestions or 'tricks' that might be helpful for doing this.

Thanks

'Help ITU programmer only downloads 1K of my code!'
1996\10\05@161030 by NEIL GANDLER

flavicon
face
I just finished a program for my PIC16c74 that was approximately
1900 lines (atleast according to the message from the microchip assembler).
I programmed my pics as I always had with my ITU pic programmer, and
apparantly, this programmer will not program more than 1K of Eprom, which
leaves half of my code out. This is how I came to that conclusion.

       1. When trying to read the contents of the PIc through the ITU
programming utilities, it only shows 1K on the Eprom's memory.
       2. When running my code, and I hit a subroutine that starts
after the 1K mark, the PIC resets.

Now I am almost sure the c74 is divided into 2 pages w/ 2k in each, so
there is no need to specify page bits in my code, besides, why is only
1K being downloaded to the PIC, perhaps I am missing something. Can
anyone help?

               Neil Gandler

1996\10\05@190714 by 87654321

flavicon
face
> I just finished a program for my PIC16c74 that was approximately
>1900 lines (atleast according to the message from the microchip assembler).
>I programmed my pics as I always had with my ITU pic programmer, and
>apparantly, this programmer will not program more than 1K of Eprom, which
>leaves half of my code out. This is how I came to that conclusion.
>
>        1. When trying to read the contents of the PIc through the ITU
>programming utilities, it only shows 1K on the Eprom's memory.
>        2. When running my code, and I hit a subroutine that starts
>after the 1K mark, the PIC resets.
>
>Now I am almost sure the c74 is divided into 2 pages w/ 2k in each, so
>there is no need to specify page bits in my code, besides, why is only
>1K being downloaded to the PIC, perhaps I am missing something. Can
>anyone help?
>
>                Neil Gandler
>
>
call ITU...they are extremely helpful....

1996\10\06@005139 by Martin J. Maney

flavicon
face
On Sat, 5 Oct 1996, NEIL GANDLER wrote:

>  I just finished a program for my PIC16c74 that was approximately
> 1900 lines (atleast according to the message from the microchip assembler).
> I programmed my pics as I always had with my ITU pic programmer, and
> apparantly, this programmer will not program more than 1K of Eprom, which
> leaves half of my code out. This is how I came to that conclusion.

Been there, did that.  The ITU has a tiny configuration file that
specifies the highest address that will be programmed.  I'm not sure now
if I somehow got the original installation copy, which is set to 1K, or
if I deleted it and the software defaulted to 1K, but I had exactly this
experience a while ago.  It wasn't until I got around to questioning the
config file (which I knew about, but dismissed because I had set it
months earlier and why would I have changed it?) that I found the trivial
answer to the mystery.

I still don't know how it got damaged, but I certainly do know what I'll
check immediately if I ever see evidence of incomplete programming ever
again!

Luck!

'Anyone have 32 bit Binary to Ascii conversion code'
1996\10\06@163438 by nogueira

flavicon
face
Ted Linn wrote:
>
> One of the things I need to get a 16C57 to do is to convert a 32 bit binary
> number to ascii for output to an LCD display.  I know an algorithm for doing
> this but being new to this pic world I wondered if anyone would share code
> or offer some suggestions or 'tricks' that might be helpful for doing this.
>
> Thanks

This routine converts a 32 bit binary number to BCD compacted,
to convert to ASCII just split the nibbles and add '0'
;******************************************************
; BIN2BCD
;RECEIVE BINARY NUMBER IN REG4,REG3,REG2,REG1 AND RETURN
DIG4,DIG3,DIG2,DIG1 AS BCD
;******************************************************
BIN2BCD
       BCF     STATUS,C
       MOVLW   32
       MOVWF   COUNT
       CLRF    DIG6
       CLRF    DIG5
       CLRF    DIG4
       CLRF    DIG3
       CLRF    DIG2
       CLRF    DIG1
LOOP24  RLF     REG1,1
       RLF     REG2,1
       RLF     REG3,1
       RLF     REG4,1
       RLF     DIG1,1
       RLF     DIG2,1
       RLF     DIG3,1
       RLF     DIG4,1
       RLF     DIG5,1
       RLF     DIG6,1
       DECFSZ  COUNT,1
       GOTO    ADJDEC
       RETURN
ADJDEC
       MOVLW   DIG1
       MOVWF   FSR
       CALL    ADJBCD
       MOVLW   DIG2
       MOVWF   FSR
       CALL    ADJBCD
       MOVLW   DIG3
       MOVWF   FSR
       CALL    ADJBCD
       MOVLW   DIG4
       MOVWF   FSR
       CALL    ADJBCD
       GOTO    LOOP24

ADJBCD
       MOVLW   3
       ADDWF   0,W
       MOVWF   TEMP
       BTFSC   TEMP,3
       MOVWF   0
       MOVLW   0x30
       ADDWF   0,W
       MOVWF   TEMP
       BTFSC   TEMP,7
       MOVWF   0
       RETLW   0


Octavio
--
========================================================
Octavio Nogueira
e-mail:   spamBeGonenogueiraspamspamspamBeGonemandic.com.br
homepage: http://ourworld.compuserve.com/homepages/tato
voice/fax: +55 11 240-6474
========================================================
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
Avaible at http://ourworld.compuserve.com/homepages/tato

'Destroying A/JW pics with code protection.'
1996\10\08@164933 by Otmar Ebenhoech

picon face
       For any of you using the Baradine Micro Burner, Beware!  Do not use
the O command (program config. fuses) on any new pic devices with non
erasable code protect bits. Theoretically we should be able to program the
new A devices by including the fuses in the code, but I'm still waiting for
relacements for my 74A/JW paperweights to find out. Baradine is working on
new firmware and thinks he'll have a fix in "a couple weeks".
       Why is a long story, I love Pics, but Microchip really blew it with
this one. Apparently, the 5X devices prefer to have those "unused" upper
code protect bits as zeros. Now if you apply that old standard to a 74A
you've destroyed your chip.
      While I'm ranting does anyone know why the power up timer enable bit
has been inverted on the new A chips? Was there a reason or is is just a
demented plot to make us feel bad at thier expense?

       I remember someone suggesting X-rays for erasing OTP devices. Did
anything come of that? Should I take my 74As to the dentist? :-)

Have Fun!

-Otmar-

  -----------------------------------------------------------------------
  Otmar Ebenhoech                        Electric Vehicle Components Ltd.
    "I wish I die sleeping like my grandfather,
                           not screaming in terror like his passengers."
  @spam@tessspamspamspam_OUTnetcom.com                                         (415) 494-9255
  -----------------------------------------------------------------------

'Dallas 1820 Code'
1996\10\18@101611 by Randy Murray

flavicon
face
    Does anyone have code for the 16C84 to interface to the Dallas 1820
    Digital Thermometer?

    Thanks,

    Randy

'CCS C code?'
1996\10\18@114536 by Norm Cramer

flavicon
face
I just ordered the CCS C compiler.  Are there any sites with example code or
libraries of C code?  Anyone interested in sharing code?

Norm

'Dallas 1820 Code'
1996\10\18@123527 by Randy Murray

flavicon
face
    Does anyone have or can anyone point me to code for the 16C84 to
    interface to the Dallas 1820 Digital Thermometer?

    Thanks,

    Randy

'CCS C code?'
1996\10\18@155543 by dontronics

flavicon
face
Norm Cramer wrote:
>
> I just ordered the CCS C compiler.  Are there any sites with example code or
> libraries of C code?  Anyone interested in sharing code?
>
> Norm

I have a feeble attempt at supporting a CCS C Compiler Self Help Group
at:
http://www.labyrinth.net.au/~donmck/ccs.html
Some additional info can be found here.
All contributions and snippets of code are welcome, however it's not the
ideal venue. Really needs a list like this one. I have spoken to CCS
about this and it's an option they may look at in the future.

Don...

Don McKenzie KILLspamdonmckspamKILLspamlabyrinth.net.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

SimmStick(tm) coming soon.
EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
Picosaurus(tm) 40 pin FED Basic with 8 channels of A-D, and real Uart.
MEL PicBasic Compiler. Programmers from 15 USD.  Pic-Axe(tm) A New Tool.

'Dallas 1820 Code'
1996\10\19@050013 by nogueira

flavicon
face
part 0 5647 bytes

Octavio
--
========================================================
Octavio Nogueira
e-mail:   KILLspamnogueiraspamspamspammandic.com.br
homepage: http://ourworld.compuserve.com/homepages/tato
voice/fax: +55 11 240-6474
========================================================
"ProPic" The first Production PIC Programmer running in
Windows and under US$ 20.00.
Avaible at http://ourworld.compuserve.com/homepages/tato

;###############################################################################
#
;###############################################################################
#
;################ routines to DS1820
############################################
; all this routines are to work on a 4MHz PIC, DS1820 connected to RA0
;
; Use the routines like this

;       call    Reset           ;send reset
;       movlw   0xCC            ;skip ROM
;       call    Write
;       movlw   0x44            ;convert Temp
;       call    Write
;
; wait at least 500ms
;
;       call    Reset           ;send reset
;       movlw   0xCC            ;skip ROM
;       call    Write
;       movlw   0xBE            ;read scrachpad
;       call    Write
;       call    Read            ;read temp LSB
;       movwf   TLSB            ;store
;       call    Read            ;read temp MSB
;       movwf   TMSB            ;store
;       call    Read            ;read User 1
;       movwf   USER1           ;store
;       call    Read            ;read USER2
;       movwf   USER2           ;store
;       call    Read            ;read don't care
;       call    Read            ;read don't care
;       call    Read            ;read COUNT REMAIN
;       movwf   CO_RE           ;store
;       call    Read            ;read COUNT PER C
;       movwf   CO_PE           ;store
;       call    Read            ;read CRC
;       call    Reset           ;send reset


;******************************************************
; Routine to read a data from DS1820
; return the data in W
;******************************************************
READ    clrf    TEMP
       movlw   8
       movwf   COUNT
       bsf     PORTA,DS1

RD0     BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000000'
       MOVWF   TRISA           ;  RA0 as output
       BCF     STATUS,RP0      ;  Page 0
       bcf     PORTA,DS1       ;0 start bit
       nop                     ;1
       nop                     ;2
       BSF     STATUS,RP0      ;3 Page 1
       MOVLW   B'00000001'     ;4
       MOVWF   TRISA           ;5 RA0 as input
       BCF     STATUS,RP0      ;6 Page 0
       bsf     PORTA,DS1       ;7
       nop                     ;8
       nop                     ;9
       nop                     ;10
       nop                     ;11
       nop                     ;12
       nop                     ;13
       movf    PORTA,W         ;14 read bit
       andlw   B'00000001'
       bcf     STATUS,C
       btfss   STATUS,Z
       bsf     STATUS,C
       rrf     TEMP,1
       call    Delay50
       decfsz  COUNT,1         ;repete for 8 bits
       goto    RD0
       BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000001'
       MOVWF   TRISA           ;RA0 as input
       BCF     STATUS,RP0      ;Page 0
       movf    TEMP,W
       return

;******************************************************
; Routine to write a data in DS1820
; receive the data in W
;******************************************************
Write   movwf   temp            ;store data
       BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000000'
       MOVWF   TRISA           ;RA0 as output
       BCF     STATUS,RP0      ;Page 0
       movlw   8
       movwf   COUNT
WR0     bcf     STATUS,C        ;clear carry
       bcf     PORTA,DS1       ;start bit
       call    Delay10         ;wait 15us
       rrf     TEMP,1          ;read bit
       btfsc   STATUS,C        ;bit is 1?
       bsf     PORTA,DS1       ;yes, line goes to 1
       call    Delay50         ;wait 45us
       bsf     PORTA,DS1       ;line returns to 1
       decfsz  COUNT,1         ;repet for 8 bits
       goto    WR0
       BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000001'
       MOVWF   TRISA           ;RA0 as input
       BCF     STATUS,RP0      ;Page 0
       return


;******************************************************
; routine to send a reset pulse to DS1820
;******************************************************
Reset_DS
       BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000000'
       MOVWF   TRISA           ;RA0 as output
       BCF     STATUS,RP0      ;Page 0
       bcf     PORTA,DS1       ;pulse em 0
       call    Delay500
       bsf     PORTA,DS1
       BSF     STATUS,RP0      ;Page 1
       MOVLW   B'00000001'
       MOVWF   TRISA           ;RA0 as input
       BCF     STATUS,RP0      ;Page 0
       call    Delay500
       return

;*********************************************************
; Rotina de Delay de 15 us
;*********************************************************
Delay10 movlw   1
       movwf   COUNT2
       decfsz  COUNT2,1
       goto    $-1
       nop
       return
;*********************************************************
; Rotina de Delay de 45 us
;*********************************************************
Delay50 movlw   15
       movwf   COUNT2
       decfsz  COUNT2,1
       goto    $-1
       return
;*********************************************************
; Rotina de Delay de 500 us
;*********************************************************
Delay500
       movlw   180
       movwf   COUNT2
       decfsz  COUNT2,1
       goto    $-1
       return


'stepper control code for rs-232'
1996\10\20@095506 by BARBAROS ASUROGLU

flavicon
picon face
part 0 533 bytes
sorry for the late reply.i send the zip of code as step232.zip

barbaros


---------------------------------------------------------
Barbaros ASUROGLU - TA2CBA      AMPR GATEWAY : 44.176.1.1

Member Of ANTRAK - Amateur Radio Club Of ANKARA - TURKEY

Home Page: http://www.metu.edu.tr/~antrak
---------------------------------------------------------

        " SCIENTIA DUX VITAE CERTISSIMUS "

                                         K.ATATURK

Attachment converted: wonderlandfive:STEP232.ZIP 3 (pZIP/pZIP) (000047FD)

1996\10\20@154741 by Bob Blick

picon face
Barbaros writes:

>Hi eveyone who is interested in stepper control.
>
>sorry for the late reply.i send the zip of code as step232.zip
>
>barbaros

OK, I have gotten 4 copies of it so far. Please stop sending them!
Thanks, Bob

'stepper control code for rs-232--sorry'
1996\10\21@053859 by BARBAROS ASUROGLU

flavicon
picon face
sorry for sending the code several times there was a problem in the
server of us .i apologize to occupy your service with the same message
several times.we fixed that problem.....:)

barbaros


---------------------------------------------------------
Barbaros ASUROGLU - TA2CBA      AMPR GATEWAY : 44.176.1.1

Member Of ANTRAK - Amateur Radio Club Of ANKARA - TURKEY

Home Page: http://www.metu.edu.tr/~antrak
---------------------------------------------------------

        " SCIENTIA DUX VITAE CERTISSIMUS "

                                         K.ATATURK

'Scale error in AN616 digital filter code?'
1996\10\21@145200 by Paul Bjork

flavicon
face
To any digital signal processor types out there:

I'm replacing my PID module with a more general IIR filter-based
module for a digital control system.  The algorithm and code in AN616
seems usable if a little sparse on documentation.  There seems to be a
discrepency in the definitions for where the LSB's and MSB's are
stored in the IIR code module, IIRfilt.c.

The filter() function documentation states that the

                                       "output is in MSB of y_n (y_n=MSB, y_n+1
=LSB)"

yet the code inside the function uses the reverse definition, ie:,
y_n+1=MSB.  For example, the following code:

               movf    accbHI,w
               movwf   y_n+1
               movf    accbLO,w
               movwf   y_n

I assume here that the MSB of any result would be stored in a variable
called xxxxHI.  This is rectified in the last two lines of code, where
the MSB stored in y_n+1 is moved to y_n so it looks like an 8-bit
result for the main calling program to use.  Okay, I can deal with
this.

However, the scale_y_n routine called _just previously_ to this  seems
to require that the LSB _is_ in y_n+1, but only in the start_scale
segment of code.  The scale by 8 should left shift the LSB into the
MSB but the code is actually the reverse:

               bcf     status,c        ; clear carry
               rlf     y_n+1           ;       and rotate y(n) left
               rlf     y_n

which seems to rotate the MSbit into the LSbit, while 0's are rotated
into the right side of the MSB.  Hmmm, this doesn't seem right.  But
it might not have been too noticable in testing since the LSB is
thrown away anyway.

Can anyone shed some public light on this?

While you're here, is anyone interested in trading a reasonably well
documented IIR canonical form filter software module similar to that
in AN616 for my pretty well documented PID control software module?
Please reply privately.



Paul Bjork
bjork012KILLspamspam.....gold.tc.umn.edu

Display limited to first 300 matches. Add keywords to narrow the result set or browse by year:
- In 1996 , 1997 only
- Today
- New search...