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

_Sub string match.
PICList Thread
'Serial Programmers'
1994\05\11@183214 by Don Lekei

picon face
In-Reply-To:  spam_OUTjsevinskTakeThisOuTspamspd.dsccc.com

> ... It would be nice if it used the serial port,
>  so those of us with non-IBM-PC computers can use it....

I have been using a serial programmer for years which is completely ASCII
controlled and quite portable. It's from Baradine Products in North
Vancouver, BC. And it's not very expensive. It programs EPROMS, EEPROMS,
and microcontrollers including PIC 5X, 7X, 8X, 17c42 (and 6X is comming).
It uses the serial mode for 6x+ parts so you can use it for in-circuit
programming.

I have written a (sorry, DOS) based command line programmer for it (so it
can be used from a makefile) which is available on the MICROCHIP BBS.

Without trying to sound like an ad (I am not in any way connected with
Baradine) they can be contacted at 800-668-7886 (north america) or (604)
988-9853.

Don

'PISstart % serial I/O (mac) '
1994\05\12@124910 by jory

face picon face
ujonsson@magnus.acs.ohio-state.edu (Ulf Jonsson) write in response to an
earlier post of mine:

-snip-

ulf asks about mac asssembler...

-snip-

Here is some info I had that someone else had given me about mac
developmnt.  The assembler was about $100-150. Note that the programmer is
the same one Don Lekei and I have both mentioned and/or endorsed.

***************************begin insertion ****************************
There is a very good Macintosh assembler for the PIC called uASM from
Micro Dialects Inc, PO Box 190, Loveland, OH 45140, Ph: 513/271-9100.
It has integrated text editor, assembler, and communications modules.
It assembles code at between 7,500 to  lines per minute, fully supports
macros,
automatic labels, local labels, conditionally assembly, includes to 10
level deep.  The editor supports up to 10 open files at a time, full
search and replace including grep searches,  and file size limited only
by RAM available.  The terminal emulator supports data transfers at up
to 38,400 buad.  We have been using this assembler for over a year now
and have had no problems at all.  MDI is currently working on an upgrade
to support the 16C71, 84, 64, and 17C42.

We also use a programmer from Beradine Products Ltd, PO Box 86757, North
Vancouver, BC CANADA V7L4L3, Ph: 604/988-9853.  Gary Anderson is very
helpful and makes the only RS-232 termial serial port compatible
programmer I know of.  It supports communications up to 38,400 baud,
stand-alone or host operation, and is very inexpensive.  We have also
used this for over a year with no problems.

We use Macintosh for development partly because our application is for
the AppleTalk environment.  However we have found that development in
the Mac environment is much easier and more productive because of the
integration of these products.  The only thing we miss is the capability
to run a simulator or ICE from our Mac.  For those things we must use
our MS-DOS PC.
****************************end insertion *****************************

ulf goes on to ask:

>Do you know if the PicStart can be used through the serialport from the mac
>under SoftPC. I will buy one myself on the seminar but i don't know if I
>can use it with the mac or if I need to run to some PC user to burn my
>chips.
>
>Is it possible to play with the BasicStamp from a PC? I think you need a
>paralell port but is there some other way?


The PICstart *CANNOT* be used through the serial port of the mac using
SOFTPC. While the software works fine, uchip uses a completely nonstandard
serial connection which is completely incompatible with the mac's serial
ports. (i know this both from exapnded knowledge from uchip and those who
know a lot about mac serial, and also fro having tried it mayself with
total failure the result)

I know nothing (insert images of colonel klink) about STAMP, perhaps
someone else can help you.


{Quote hidden}

Normal can crystals die somewhere between 5000 and 10000 PSI (pretty
limited/rough data so far, since they worked @ 5000, then we went to 10,000
and the cans crushed... i also don't have long term data).

Oh yeah, the chips themselves will should take that pressure (if my
experience is any measure).


-jory

ps: one cute tidbit from my attempt to hook-up a picstart to mac serial was
that you can get the conversion from mac-->pc serial by opening the
appletalk tool with resedit. in it, there is a pict resource with the
pinout of the mac serial, and how to connect it to a pc serial cable)...



1994\05\28@142706 by ujonsson

flavicon
face

>
>The PICstart *CANNOT* be used through the serial port of the mac using
>SOFTPC. While the software works fine, uchip uses a completely nonstandard
>serial connection which is completely incompatible with the mac's serial
>ports.


Hi Jory,

Sorry that i posted the same question again. I belive fully in what you
said but a forgot your mail in the exitement over getting my own Picstart I
mixed it up with a post i got from a Amiga guy.

My wife was not happy when I told her that i might need space for one more
computer at home (Flintstone IBM PC).

Do you think that there is a possibility to get around the problem by any
meens, like putting a pic inbetween as a translator?


Ulf



'Parts, serial number'
1994\06\21@160115 by Stefan R. Jacob
picon face
> frame and the number is 244364266 not 144 as I mentioned in another
> letter. If you can check out the year for me I would appreciate it. I

Howdy,

it so happens that we are in possession of a complete stack of genuine
old British Leyland microfilms picked up at a bankruptcy auction (they
were stashed away in the drawer of a desk we took along!). So, courtesy of
(now defunct) BRANDO Automotives of Holland, here are the details for
your serial number #244364266 :

* 1964 ser.IIA 88" swb (non-station) 4 cyl.petrol lh-drive export version *

Will that do?

   So long,

Stefan R. Jacob  <.....100043.2400KILLspamspam@spam@CompuServe.com>
LROC of Hessen
Wiesbaden, Germany



'Xon/Xoff protocol in Asynchronous Serial I/O'
1994\08\01@173933 by ktor Dvorak
flavicon
face
Software handshaking Xon/Xoff on PIC16C84.
Do you know about some help in buffered serial protocol with Xon/Xoff ?

                                 Thanks in advance

RNDr. Viktor Dvorak
dvorakvspamKILLspamearn.cvut.cz
Praha
Czech Republic
Europe

1994\08\02@074839 by Derrick Early

flavicon
picon face
Hello Dr. Dvorak,

I'm a rookie at this microcontroller programming stuff, but I am very interested
in finding the answers to your questions.  Since, I have to write the same
routines for the pic16c64.

I wonder what clock speed you are using for the chip.  This may have
an effect on the number of program steps that the chip must wait for the
next bit.  You could calculate this value and set a loop parameter, so
you could generalize the code for any speed.

Also if the chip is wasting time waiting to send the next bit, you could use
that time to check for an xon (h'11') or xoff (h'13') byte to see if you should
stop sending bits.

You probably already thought of this, and remember I'm a rookie.

Yours,

Derrick Early, the rookie user

'Autobaud for serial link'
1994\08\22@133009 by crocontroller discussion list

flavicon
face
Has anyone got some code or ideas on how to sense the baud rate
of an Asynchronous Serial I/O automatically. Ideally this should be
done continuously allowing a RC clocked PIC to adjust calibration
as its operating freq changes.

Rasher

1994\08\22@154606 by crocontroller discussion list

flavicon
face
If you time the length of the start bit, you can sense bit rate in less
than one character on any odd character...

BillW

1994\08\23@040926 by crocontroller discussion list

flavicon
face
I have considered using the start bit to give the timing of the link
(baud rate) which as you say will only work for 50% of characters.

I was also thinking in terms of timing edge transitions and dividing
this time by the bit time to give number of bits at same level (mark or
space). Has anyone else considered this rather than the more conventional
measure the link at bit rate aftre delay of bit rate/2 from start  ??

I hope some of this makes sense !!!

Rasher

1994\08\23@143750 by crocontroller discussion list

flavicon
face
I have seen several systems where it was required to press
the space bar as the first character. In serial communications,
the least significant bit is transmitted first. For a space, the
bit pattern would look like the following:

_________                              ____           _______________
       |                             |    |         |
Mark   |                             |    |         |
       |_____________________________|    |_________|
            .    .    .    .    .    .    .    .    .    .    .
  1    Start  b0   b1   b2   b3   b4   b5   b6   b7 stop1 stop2  Mark



This conforms to 1 start bit, 8 data bits, no parity and two stop bits.
The processor then has six bits that are low in which to increment a
counter and calculate the serial data rate relative to it's own clock
frequency. The longer time for measurement makes for a more accurate
determination of the serial data rate.

Another example would be to use a ( , 8 , H , X , h or an x. These
characters will allow a measurement for four bits long. Althogh a
little less accurate, you only need to right shift your counter
twice ( divide by four ) in order to calculate your reload data
for your bit counter.

The BASIC interpreter in the 8051AH-BASIC chips requires you to press
the space bar to log on, and then for the real time clock to work,
you give the command xtal = xx.xxxxxx to match the crystal connected
to the micrcontroller.

Hope this help someone,
Jerry


'Serial programming'
1994\11\09@095604 by crocontroller discussion list
flavicon
face
My first experience of a PIC was in building a controller, serial comms device
and remote unit controller with LCD support and 16 remote units running
on a twisted pair network.....
Programming was done in serial mode from a compiler and programmer I wrote
in BASIC (euch! but only choice - no PC at home).  Problem was, I ruined
several PICs, as the CP bit set itself no matter what I wrote to the fuses...
Bit of a bugger when you've got a _small_ budget!

OK now I-m working on a PICSTART, but I tried this idea of sending the
parallel data to do bulk erase, but it didn't work.  It would be very nice
to build the serial bulk erase command into it.

Bryan

--
---------------------------------
BRYAN CROTAZ - .....b.crotazKILLspamspam.....ic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London  SW7 2BB
Tel. 071-594-8104
Fax. 071-225-2309 attn. STOIC

1994\11\09@120958 by crocontroller discussion list

flavicon
face
As a newbie to PICs, I'm interested to know why the CP bit always
set in your initial attempts, and what you found out to prevent
it.

John Kallend
(ex-patriot Brit in Chicago)

'Serial Programming...'
1994\11\09@161325 by crocontroller discussion list

flavicon
face
John asks what I did to prevent it...
I worked for the BBC over the summer and they bought me a PICSTART
kit for a project, which I subsequently borrowed and did it by
parallel means....
No serial solution to setting CP...or so _I've_ found.
Interested to know if someone's suggestion of sending the parallel
codes does actually work, and I just mucked it up....

Bryan

--
---------------------------------
BRYAN CROTAZ - EraseMEb.crotazspam_OUTspamTakeThisOuTic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London  SW7 2BB
Tel. 071-594-8104
Fax. 071-225-2309 attn. STOIC

1994\11\10@071903 by crocontroller discussion list

flavicon
face
Hi,

Bryan Crotaz wrote:

> John asks what I did to prevent it...
> I worked for the BBC over the summer and they bought me a PICSTART
> kit for a project, which I subsequently borrowed and did it by
> parallel means....
> No serial solution to setting CP...or so _I've_ found.
> Interested to know if someone's suggestion of sending the parallel
> codes does actually work, and I just mucked it up....

I've used a PICSTART-16B (V1.6 firmware) and although I can't be sure
how it deals with bulk erase, I do know that it uses _serial_mode_
programming for 16C84s.  Which, by the way, is useful to know if you
have a PICSTART but really wanted something for In-System Programming
(ISP); all you need to do is hook up 4/5 wires (Vpp, Vdd (maybe), RB6,
RB7 and GND) from the PICSTART ZIF socket to your application circuit.
Before I built my own ISP circuit that's what I used to do.  Perhaps
things have changed with the latest PICSTART firmware.

As I mentioned previously, I found the parallel codes for bulk erase work
in serial mode.  As I seem to be the only person to have said that, and
Bryan doesn't think it's true, I guess it would be helpful if someone
else could give some input to the discussion.

David


'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 - b.crotazspamspam_OUTic.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'
1995\02\19@044733 by Bryan Crotaz

picon face
Nope, Andy I meant no stopbit.
What effect does putting a stop bit in have on the reliability?

Bryan

(PS It's extremely easy to add one to the routine.)

--
---------------------------------
BRYAN CROTAZ - @spam@b.crotazKILLspamspamic.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 }

1995\02\19@150025 by Charles Manning

flavicon
face
On Feb 19,  9:41, Bryan Crotaz wrote:
} Subject: Serial
> Nope, Andy I meant no stopbit.
> What effect does putting a stop bit in have on the reliability?
>
> Bryan
>
> (PS It's extremely easy to add one to the routine.)
>


I hope I'm not butting in and grabbed the wrong end of the stick. I
assume RS232 style comms are under discussion.

The stop bit is required for two reasons that I can think of:

* Timing considerations (the data word is expected to be, say, 10 bits
long)

* Ensuring correct start bit detection. The stop bit is high and the
next start bit is low, thus providing a reliable transition.

Adding extra stop bits (more than one) can't harm things because the
stop bit value is the same as the idle state. Obviously it can knock
performance a bit.

-- Charles

1995\02\19@160830 by Andrew Warren

face
flavicon
face
Bryan Crotaz (KILLspamb.crotazKILLspamspamic.ac.uk) wrote:

>Nope, Andy I meant no stopbit.
>What effect does putting a stop bit in have on the reliability?

Bryan:

Without at least one stop bit after each character, there's no way to
detect the start bit of the next character.

-Andy


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

'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 ||
||   spamBeGonehenrispamBeGonespamfscz-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 (TakeThisOuThenriEraseMEspamspam_OUTfscz-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 - RemoveMEfastfwdspamTakeThisOuTix.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 ||
||   henriEraseMEspam.....fscz-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 (EraseMEhenrispamfscz-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 - RemoveMEfastfwdEraseMEspamEraseMEix.netcom.com
Fast Forward Engineering, Vista, California


'Serial UARTS?'
1995\03\29@034621 by Ronald D. Shaw
flavicon
face
>With the recent discussions concerning UARTS it seems as though it
>might be useful in some designs to have a UART that's serially
>interfaced somewhat like an EEPROM. If it had TX and RX buffers of
>a few bytes built in it would be all the nicer. Does such an animal
>exist to anyone's knowledge?

You might want to look at the Harris CSD68HC68S1  It is not a direct
solution, but it can be made to work. It is a single byte device.


'Multi-drop serial bus'
1995\04\24@122910 by Paul Greenwood
flavicon
face
> Hello,
>
>         There was a thread on the list a while back about implementing a
> multi-drop serial bus for PIC communications (RS422, I believe).  Can
> anyone help me find it?  I would like to know the resolution, ie, did
> they find a way to do it?  Is there existing code to implement this bus?
> Any help appreciated.
>
> Thanks,
>
> Martin Kirk
> Arizona State University
> RemoveMEmlkspam_OUTspamKILLspamasu.edu
> (602) 263-9270

Martin,

       I don't remember the discussion but let me explain something that works
quite well for me at low data rates (1200 baud).  I haven't hooked it to a
scope to see the waveforms but I THINK the design is sound.  What I do is tie
the Rx line going to the computer to RTS through a 2.2K resistor.  I write my
programs to pull RTS low (-12V).  I then connect the Rx line through an
opto-isolated transistor to +12V.  I can then switch the line from -12V to
+12V by energizing the optoisolator.  Also, I can connect many of these
together this way.  Then, I just connect the Tx pin of the computer to all
my PICs through a large resistor (I think I used 1Mohms so there was very
little loading).  Now, you have to work on your protocol because collisions
can definately take place.  Also, a limitation is that you cannot have one
PIC talk to another - just to the computer.

       If anyone has any comments on this, I'd like to hear them.  I've been
using this method for a long time - with no problems at all.

--

           -- Paul Greenwood --  (RemoveMEpabloTakeThisOuTspamspamaustin.ibm.com)

"We don't care.  We don't have to.  We're the Phone Company."


'In-system serial programming (?)'
1995\06\02@210632 by Albert J. Fahey
flavicon
picon face
Admittedly I am still figuring things out here ... but let
me ask this question ... Why is David Tait's 16C84 programmer
only labeled as for 16C84's?  Other PIC's have in-system serial
programming!  Isn't it just a question of software?

Why couldn't I use David Tait's programmer to program a
16C74?

Albert

1995\06\02@212338 by Byron A Jeff

flavicon
picon face
>
> Admittedly I am still figuring things out here ... but let
> me ask this question ... Why is David Tait's 16C84 programmer
> only labeled as for 16C84's?  Other PIC's have in-system serial
> programming!  Isn't it just a question of software?
>
> Why couldn't I use David Tait's programmer to program a
> 16C74?


One word: EEPROM

See the 16C84 EEPROM is self timed on the write. So once you send a
begin programming command it'll stop programming automatically.

All the other parts however use EPROM. So the programmer is obligated to
send a STOP programming in addition to the BEGIN program command. I believe
that the time is only 100 uS pulses which is difficult to get with any
accuracy in software.

Best bet would be a 16C84 that would handle the task easily. It can be self
programmed and then the programm driven by a 16C84 could programm all
the other parts.

Later,

BAJ

'Interfacing to MAXIM serial A/D and D/A'
1995\06\18@192903 by nino.benci

flavicon
picon face
Has anyone connected any of the MAXIM serial A/D and D/A's to any
PIC, especially the 16C71. This may be a simple question but for some
reason or other I cannot get the sample code in the Embedded
Controller Handbook, the one relating to interfacing to 93Cxx series
serial EEPROM's to work. I have tried to modify the code so that I
get 12 bit data as two 8 bit bytes into memory on the PIC. I
use the code in 4 wire mode and have checked that I am using
the correct clock phase. Data output is via a 1200 bps serial
line to a PC, this works as I issue a 'G' command to start
conversion of the A/D. When completed the 16 bit value should
be returned as two 8 bit bytes. Nothing happens. I have data
and clocking on the DO and CLK lines but nary a sign of life.
I also provide an 'O xxxx' which allows me to send a 12 bit value to
a D/A, same result, NOTHING. I know the 1200 bps
serial line works as it operates in FULL DUPLEX mode. Either the
format is incorrect or I have done something gravely wrong. Any
clues would be most appreciated

Nino Benci
Monash University - Physics
Wellington Rd, Clayton.
VICTORIA. AUSTRALIA. 3168
tel - 61 3 9905 3649    fax - 61 3 9905 3637
email - EraseMEnino.bencispamspamspamBeGonesci.monash.edu.au
************************************************************************
* Nino Benci - Chief Technical Officer       *                         *
* Monash University - Physics                *     Profound message    *
* Wellington Rd, Clayton. 3168               *      to be inserted     *
* Victoria, Australia.                       *       in the near       *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637 *          future         *
* EMAIL - RemoveMEnino.benciKILLspamspamsci.monash.edu.au       *                         *
************************************************************************


'Question??? Who needs more Serial RAM'
1995\07\05@170347 by Michael Bender
flavicon
face
> In searching for external memory solutions, it was soon found that nothing
> exists in the 16k byte, or larger size parts, with serial connectivity.

How about considering the following:

   1. Use a PAL as a serial-to-parallel converter. (2 chips - PAL and RAM).

   2. Use another (smaller/cheaper?) PIC as a serial-to-parallel converter
       and memory controller (2 chips - PIC and memory chip, or 1 chip -
       just use the PIC as a memory controller and internal memory as well).

   3. Use dual-ported VRAM; these typically have both a parallel and a
       serial port on them; in traditional frame buffer devices, the
       parallel port on the VRAM is used by the processor, and the serial
       port is used to shift data out of the VRAM to the DACs; you might be
       able to get VRAMs that allow both shift-in and shift-out operations.

How about checking the usual suspects - Maxim and Dallas?

mike

1995\07\09@211855 by Russ Hughes

flavicon
face
  GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!

I have also run intro this RAM memory limitation. I would like to use PIC's
more often in my project, they have all the processing power I need, but
since I often need to buffer atleast a couple of K of data.  This forces my
to turn to other chips (68HC11) that are more expensive and harder to get in
qty's.

  GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!

Tried the dual PIC solution but cost became a factor. Not only did it double
the cost of the processor(s), but the cost of programming (time is money),
and added 1/3 to my pc board size!

  GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!

Haven't tried VRAM'S, I don't have any experiance with them.

Russ Hughes
MCE Technology Group

1995\07\09@214008 by Nino Benci

flavicon
picon face
Russ Hughes <russSTOPspamspamspam_OUTONEWORLD.OWT.COM> wrote

{Quote hidden}

I have in front of me the Dallas Semi 90/91 data book and on page 813
is data for a 'DS1280, 3-wire to byte wide converter chip'. What
would it take for someone to get this device (DS1280FP-44) and two
681000 128k x 8 low power SRAM devices (all the smallest surface
mount packages available) and produce a sip module which could
provide up to 512k x 8 of NVSRAM for devices such as PIC's.

I would be willing but time I have not got.

Nino Benci.
************************************************************************
* Nino Benci - Chief Technical Officer       *                         *
* Monash University - Physics                *     Profound message    *
* Wellington Rd, Clayton. 3168               *      to be inserted     *
* Victoria, Australia.                       *       in the near       *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637 *          future         *
* EMAIL - spamBeGonenino.benciSTOPspamspamEraseMEsci.monash.edu.au       *                         *
************************************************************************

'Large Serial RAM interest??'
1995\07\11@085118 by Mark A. Corio

picon face
There have been a few requests for information about larger serial ram
devices.  A few multi-chip solutions were offered up (e.g. Nino Benci).  Is
there any interest in a single module for such a device.  We would be willing
to design and build such units if there is enough interest.  If you have any
interest please e-mail me directly with the following information:

What size memory do you desire (depth and width)?
What package format are you interested in (SIP, DIP, etc.)?
What quantities would you be interested in?
What price range are you willing to pay for such modules? (Please be
reasonable and honest).
Are there any special requirements (e.g. battery backup, low voltage, etc.).

I will be out of town the rest of this week but I will compile the results of
any replies when I return and post a summary to the list then.
Thanks,

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

** Designing Electronics For You **

1995\07\11@091427 by Adrian Godwin

flavicon
face
> There have been a few requests for information about larger serial ram
> devices.  A few multi-chip solutions were offered up (e.g. Nino Benci).  Is
> there any interest in a single module for such a device.  We would be willing
> to design and build such units if there is enough interest.  If you have any
> interest please e-mail me directly with the following information:

For a really large memory, how about extending an idea that's been
mentioned in this list before : driving DRAM from a PIC. One possibility
might be to wrap a PIC around a self-refresh DRAM - these have a pretty
low current consumption in self-refresh mode, and the PIC could be used
to provide the self-refresh pulses and a convenient interface.

NEC offer a 'silicon file memory' that's even lower power (though perhaps
not lower power per bit than 16Mbit self-refresh) but it dosen't seem to
be easily available above 1Mbit.

-adrian

'Serial RAM interest.'
1995\07\20@125159 by Mark A. Corio

picon face
Last week I posted an inquery for people interested in serial interfaced RAM
for the PIC's.  I received a reply from three people, each with widlely
different requirements: from a 128-byte device in a TO-92 package for $3.50
to a 32Kbyte device in a SIP package for $52.00.  All were interested in
single to low quantities.  If anyone is intereseted in a custom solution we
can do development work for them but there does not appear to be enough
interest here to develop a standard product at this time.  Thanks to those
who responded to my initial request.

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

** Designing Electronics For You **

'Serial Programming Mode'
1995\07\21@161640 by Albert J. Fahey

flavicon
picon face
In article <@spam@01HT4FN1PTFMB7JL2J@spam@spamspam_OUTHAMLET.CALTECH.EDU>, Erik Hermann
<spamBeGoneehermannspamKILLspamSUN.KOBLENZ.FH-RPL.DE> says:

>Is the serial programming mode of the 16C84 the same as for
>16C74 /64 ?
Pretty much ... in a general sense.
>
>Can I use the In-Circuit programmer for 16C84 with 16C74 ?
The circuit from AN589 is OK, for example.

>Are the voltages and the timings the same ?
The timing is, according to the Microchip programming spec.
not as critical for EPROM parts as I first thought (compared
to the EEPROM 16C84).  The commands you send the EPROM parts
are different in what Microchip calls the "Program Cycle" than
the EEPROM part.  In particular you have to send an "END
PROGRAMMING" command to the EPROM parts whereas you just wait
(>~100ms) for the EEPROM parts to automatically stop their
programming cycle.  Voltages are the same.

Also there are some differences in the configuration fuses, as one
would expect.

If you want to program these parts serially you should get the
Microchip data book (you can buy it from Digikey if you want, ~$8)
and read the section on the programming spec.

You can then do one of several things.
1)David Tait suggested to me that I use the circuit from AN589
and look at his code (because I was going to write some of my
own code to program these EPROM parts).  This was a good suggestion
and seems to work.  David Tait's code is pretty easy to read, is
cleaner and more complete than the code in AN589.  Although you
may also look at the AN589 code for reference. (i.e. you can
build and write your own like I did.  It's not too hard!)

You might add some things to the circuit for debug.  (e.g. I liked
David Tait's LED indicators so I added some the the AN589 circuit)

2)You can wait until I finish debugging my code that should work with
the AN589 circuit.  Then I'll send you a copy. (or post it or
something.)  It is pretty much working now ...  It's written in
Turbo C.

3)You can modify David Tait's code to program the parts.  I can
see that this will probably work without too much difficulty, now
that I've built and programmed my own.

A concern that people expressed before is that a ~1us resolution
timer was needed (or should be used) to program the EPROM parts.
So I wrote a "Loop calibration function", for lack of a better
name, that uses the PC Timer 2 and gives me a few microsecond
resolution on executions of an assembly language loop (vs a C "for"
loop).  This is probably not really needed though.

Albert

1995\07\28@100731 by David Tait

flavicon
face
Erik Hermann wrote:

> I've seen a very simple circuit to read (program ?)  the 16C84
> directly via PC-Parallel Port.
> But I don't remember where.

Perhaps you mean Microchip application note AN589.  A Postscript copy
can be snatched from Microchip:

ftp://ftp.ultranet.com/biz/mchip/an589.zip

Details of another approach are available; get:

ftp://ftp.ee.ualberta.ca/pub/cookbook/comp/ibm/pic84*

David
--
.....david.taitspam_OUTspamman.ac.uk

1995\07\28@101409 by Antti Lukats

flavicon
face
>Hi.
>
>I've seen a very simple circuit to read (program ?)  the 16C84
>directly via PC-Parallel Port.
>But I don't remember where.
>
>Does anyone know how to do this, or where to get this circuit ?
>
ftp://rasi.lr.ttu.ee/pub/sis/msdos/pgmtools/pip-02.zip is a
programmer software for PIC family micros + Serial EEPROM's
able to work with many selfmade PIC16C84 programmers

Programmer drivers are in:
ftp://rasi.lr.ttu.ee/pub/sis/msdos/drivers/

for schematics you may browse:
http://rasi.lr.ttu.ee/~sis
there are few links to pages with embedded
Programmer schematics.

Antti
TakeThisOuTsis.....spamTakeThisOuTrasi.lr.ttu.ee

1995\07\28@102019 by Erik Hermann

flavicon
face
>> I've seen a very simple circuit to read (program ?)  the 16C84
>> directly via PC-Parallel Port.
>> But I don't remember where.
>
>Perhaps you mean Microchip application note AN589.  A Postscript copy

I've already buildt this circuit, thanks.
But I'm looking for a simpler an cheaper circuit, because this part will
perhaps be used as an educational system for students.
That means, every student has to buy one.

>
>Details of another approach are available; get:
>
>ftp://ftp.ee.ualberta.ca/pub/cookbook/comp/ibm/pic84*

Ist this your cuircuit ?
I know it.


Thanks

  - Erik

1995\07\28@113241 by David Tait

flavicon
face
Erik Hermann wrote:

> I've already buildt this circuit [AN589], thanks.
> But I'm looking for a simpler an cheaper circuit, because this part will
> perhaps be used as an educational system for students.
> That means, every student has to buy one.

Well, the prize for the most simple circuit must go to Mark Cox.  The
PIC-FAQ has details of the primary FTP site for his design, however,
if you visit Silicon Studio's site as recommended by Antti in an
earlier post, you can grab a copy from there:

ftp://rasi.lr.ttu.ee/pub/sis/prod/microchip/3rd-Party/misc/blowpic.zip

Is this the one you mean?

> >ftp://ftp.ee.ualberta.ca/pub/cookbook/comp/ibm/pic84*
>
> Ist this your cuircuit ?
> I know it.

Yes.  I guess the implication is that you know it but have rejected it
also.  If you haven't looked at the cookbook site for a while then you
can now pickup some PCB artwork by Mike Laidlaw (pic84art.zip) which
is a bit more integrated than the version that has been there for a
while (pic84pcb.zip).

David
--
TakeThisOuTdavid.taitKILLspamspamspamman.ac.uk


'whereis the serial programmer project?'
1995\08\16@032451 by Erik Hermann
flavicon
face
>Apologies to all for posting what is probably a FAQ, but where do I find
>the schematics for the serial programmer I have seen people asking about?

Here !

TxD -----*-------------------------I
         I                         I
         I                         I
        ---                       ---
        I I  2k2                  I I  10k
        I I                       I I
        ---                       ---
         I   I\I                   I
         *---I I----*--------I     I
         I   I/I    I        I     I
        ---\        I +      I     I
    5V6 / \        ---       I     I
        ---        --- 100u  I     I
         I          I        I 14  I 4
         I          I     I--I-----I---I
         I          I     I Vdd   Vpp  I
         I          I   5 I            I
GND ------*----------*-----I Gnd        I
                          I            I   PIC 16C84
       22k                I            I
       --              12 I            I
RTS ---I  I----------------I RB6        I
       --                 I            I
       --              13 I            I
DTR ---I  I---*------------I RB7        I
       --    I            I            I
       2k2   I            I------------I
             I
CTS ----------I



>Also, what kind of software do I need to run it?  A parallel one would be
>fine.

rasi.lr.ttu.ee/pub/sis/msdos/pgmtools/pip-02.zip
             /pub/sis/msdos/drivers/com84.zip


cu
 Erik

'serial programmer'
1995\08\16@224520 by Antti Lukats

flavicon
face
>>
>> 16C84 is EEPROM. The rest are EPROM. EEPROMS are self timed for writing.
>> EPROMS are not.
>>
>> It'll require updating the software to issue both BEGIN and END program
>> statements.
>>
>
>So the only problems are the software issue and the voltage level issue?
>I think I can deal with those.  Is source available or do I need to start
>from scratch?
>
>Roger

PIP-02 software works for PIC16CXX micros. The issue is in RS-232
programmer hardware. Low VPP.

antti

----------------------------------------------------------
-- Antti Lukats                          Silicon Studio --
-- .....sisspamRemoveMErasi.lr.ttu.ee                    PO Box 3500    --
-- ftp://rasi.lr.ttu.ee/pub/sis          Tallinn EE0001 --
-- http://rasi.lr.ttu.ee/~sis            Estonia        --
----------------------------------------------------------

1995\08\17@005948 by Greg Riddick

flavicon
face
RE: Jeff Slaton

ATTN:UNABOMBER

Jeff Slaton is a prime example of how modern technology can be
used for evil and has been kind enough to leave his mailing
address. Go for it!

1995\08\17@025051 by David Harmon

picon face
On Thu, 17 Aug 1995, Greg Riddick wrote:
> Jeff Slaton is a prime example of how modern technology can be
> used for evil and has been kind enough to leave his mailing
> address. Go for it!
>
Note that his latest address looks a lot like a mail drop.  His previous
mailspam had the address 6808 Truchas Dr. NE / Albuquerue NM 87109

'Serial problem'
1995\08\17@212131 by Newson Edouard

flavicon
face
I am new in using PIC and got problem using a PIC16C74 to read serial data
that is transmitted by from a 8051.  Even though, I see the data been
transmitted on a scope at the receive pin of the PIC.  Sometimes, I get
an interrupt and sometimes I don't.  I was wondering If has something to
do with the FIFO and  I don't think that I understand how read serial by
using a PIC16C74.

I was wondering if anyone have any suggestion of how I can handle that
problem.  That would be very help

Thanks

N. Edouard

'Serial Interface'
1995\08\20@112200 by Mark A. Corio

picon face
Newson,

It was unclear from your note what your problem was.  We have
implemented an RS-232 serial interface to the 16C74 that works pretty well.
We used the ByteCraft MPC compiler (C-language).  If it would help I would
be glad to forward you the source code for our intterupt routine.  Please let
me know.

I tried to e-mail you directly and it bounced....hope you get this.

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

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


'Serial RAM'
1995\09\15@024849 by mlk
picon face
Hello,

       Is there a serial RAM device with the same 4 line interface:

       CLK
       CS
       DI
       DO

as Microship's 93LC66 (serial EEPROM)?  I would like to be able to interface
such a device to a PIC.  I have a 93LC66 interface working already.
Maybe there is a I*IC device as well.  I would appreciate the info.

Thanks,

Martin Kirk
Arizona State University
spamBeGonemlk@spam@spamspam_OUTasu.edu
(602) 582-5718

1995\09\15@032035 by divanov

flavicon
face
A question was asked:

>         Is there a serial RAM device with the same 4 line interface:
>
>         CLK
>         CS
>         DI
>         DO
>
> as Microship's 93LC66 (serial EEPROM)?  I would like to be able to interface
> such a device to a PIC.  I have a 93LC66 interface working already.
> Maybe there is a I*IC device as well.  I would appreciate the info.

Ramtron manufactures what they call FRAM (Ferro-electric RAM). It is
strictly speaking a non-volatile memory, but it's rated at 10 billion
read/write cycles, so one can often use it as normal RAM. It's pin
compatible with Microchip/Atmel/SGS serial-access devices. Prices in
South Africa are very competitive (less than USD1 for 2kbits SO8
package with I2C protocol), but I don't know who the US suppliers
would be, and what the US prices are. Hope this helps.

Cheers,

RI

1995\09\15@054721 by David Warman

flavicon
face
In message <TakeThisOuT199509150821.JAA25985spamspamlistserv.rl.ac.uk>, divanovEraseMEspamplessey.co.za wri
tes:
>Ramtron manufactures what they call FRAM (Ferro-electric RAM). It is
>strictly speaking a non-volatile memory, but it's rated at 10 billion
>read/write cycles, so one can often use it as normal RAM. It's pin
>compatible with Microchip/Atmel/SGS serial-access devices. Prices in
>South Africa are very competitive (less than USD1 for 2kbits SO8
>package with I2C protocol), but I don't know who the US suppliers
>would be, and what the US prices are. Hope this helps.

I rather like the look of these - so I did a little investigating

Ramtron have their WWW pages at URL:
       http://www.csn.net/ramtron

which include Postscript data sheets for these things.  (They are
a little large, and I'm having a little trouble downloading them at
the moment - though that might be the local web proxy).

Apparently they're based in Colorado Springs, so they have plenty
of US suppliers.  They've even got a couple in the UK.  List is at:
       http://www.csn.net/ramtron/repdisti.html

It's nice to see a company that puts the data sheets online _before_
they do the all the usual 'corporate' stuff ;-) [Which is still listed
as 'under construction' at the moment.]

Dave.

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

flavicon
face
rz
**

1995\09\22@173921 by Newson Edouard

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

Anyone help will be appreciate

Thanks,
Newson

1995\09\24@193446 by Newson Edouard

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

Thanks in advance,

Newson


'Serial programmer for 16C74'
1995\10\12@102608 by Halvor Austene
flavicon
face
We have tried to modify the C84 serial programmer from AN589 for use with
16C74 (Our ambition is to make a cheap universal PIC-programmer for our
students) We have only been able to program a 16C71 with our system but not
the 16C74. Does anyone have any experience with this.
Halvor Austene
Avdelingsredsleder
Avdeling for realfag og ingenixrutdanning
Hxgskolen i Vestfold
Pb. 2243,
3103 Txnsberg
Tlf: +47 33031152 (direkte)
Tlf. +47 33031000 (sentralbord)
Fax: +47 3301103

'17C5x async serial I/O'
1995\10\17@175543 by PETE KLAMMER

flavicon
face
I've coded up some interrupt-driven serial-port code for the 17C5x, with
flow control of output, and filled hundreds of screens of MS-Kermit under
Windows 3.11 at 115200bps (with 16550 chips and TurboCom/2 drivers) with no
apparent misses.  Although this was mostly output from the PIC, with
keystroke-rate input, I never noticed anything dropped.  Not a good test,
just an observation.

But the PIC data book narrative *is* scary: if you look at figure 13-4,
there is indeed no connection from ``START Detect'' to ``Majority Detect'';
in fact, it seems to be the other way around: if the Majority-Detect happens
to find 2 out of three bits down, that will be called a start bit.

Figure 13-7 is reassuringly misleading: it shows samples 7-8-9 being taken
ideally in the middle of the start bit.  Whereas in fact, if the narrative
is to be believed, 7-8-9 could just as well have happened where 1-2-3 are
shown, or where 15-16-1 are, etc.  In such cases, it seems that a startbit
could be missed, or sampling could fall pathologically on bit boundaries,
rather than bit centers!  In this case, just a little DC offset or 1-vs-0
duty cycle asymmetry would produce gobs of errors.

Hey, Microchip, what's all this ``no relationship'' stuff, anyhow?

{Quote hidden}

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

'Re[2]: 17C4X async serial I/O'
1995\10\18@224329 by PETE KLAMMER

flavicon
face
> Date: Wed, 18 Oct 1995 10:37:04 -0700
> From: @spam@bbolesspam_OUTspam.....ccmail.microchip.com (Brian Boles)
> Subject: Re[2]: 17C4X async serial I/O
>
>      Yes, the term "no relationship" is misleading.  In reality..
>
>      The majority detect acts primarily as a glitch filter.  When it
>      detects a majority of '0' this will be the leading edge of the start
>      bit.  The x16 counter is initialized and starts counting.  When the
>      x16 counter reaches its center, the contents of the majority detect
>      are taken as the bit value, which gives you the 7,8,9 samples.  The
>      circuit will work as in Fig. 13-7.
>
>      As for Fig. 13-4, there IS no connection between start bit detect and
>      majority counter, but what is not shown clearly is the connection
>      between start bit detect and the x16 counter and "clock" signal.  This
>      is how it is done.

So, to put it more accurately (may I put words in your mouth?) there is ``no
relationship'' between the *phase* of the async sampler clock and the leading
edge of the async start bit; in other words, there is 1/16 bit time of
ambiguity in the exact timing of the async bit sampling.

But there definitely ``is relationship'' (stop me if I'm wrong) between the
leading edge of the start bit and the *count* of the  of the async sampler
clock: namely, the async sampler clock is reset when the leading edge is
detected, and from then on, majority-of-three sampling is done approximately
at the middle of each bit.

Actually, I can see how it can be done with just the fast shift register
alluded to.  Why not just describe *exactly* how it is done, instead of the
counter illusion?

>      BTW, this discussion is limited to the 17C4X data sheet, the 16C6X and
>      16C7X data sheets are more accurate on this point.

The illustrations in my 16C6X and 16C7X pages in the 95/96 Data Book don't
even identify the majority circuit, just a box marked ``DATA RECOVERY''.
Nowhere is start-bit detect described or illustrated.

I would like to guess that start-bit detect is triggered whenever the 16-bit
shift register (shifting in from the left) reaches this condition (M=Mark,
the idle line condition; S=Space, the signaling condition; x=don't care, the
noise margin condition, Y=majoritY of three, i.e. S-S-x or S-x-S or x-S-S):

        x x x x x x x Y Y Y x x x x x S
       151413121110 9 8 7 6 5 4 3 2 1 0

In other words, the first space sample I see, which is followed by
majority-of-three space condition at mid-bit, defines a start bit.  Another
possibility is:

        x x x x x x x Y Y Y x x x Y Y Y
       151413121110 9 8 7 6 5 4 3 2 1 0

... in other words, majority-of-three followed a half-bit later by
majority-of-three again.  Which way do you do it?

>      Rgds, Brian.

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

'17C5x async serial I/O'
1995\10\20@061835 by CTKEAW%mh1.mcc.ac.uk%UKACRL.bitnet

flavicon
face
Is'nt this (from memory) exactly how a 6402 UART works..?

Just get a data sheet for a 6402 and it will show you all the timing
diagrams for a uart.
,
,
,
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......!


'16C84 serial numbers'
1995\11\17@132357 by C J Norton
flavicon
face
Hi,

I'm having problems programming 2 16C84 PICs but as they are the only 2    I
have I have no way of knowing whether it is the programmer hardware,
software or the PICs themselves. I saw a recent message mentioning PIC
serial no's. Mine are 9440 CBA; would there be any reason for them to be any
different from other PICs?
Also is it possible to damage them by applying Vpp without Vdd present?
(spot the novice)

Thanks, Chris

1995\11\17@203933 by Newfound Electronics

flavicon
face
>Hi,
>
>I'm having problems programming 2 16C84 PICs but as they are the only 2    I
>have I have no way of knowing whether it is the programmer hardware,
>software or the PICs themselves. I saw a recent message mentioning PIC
>serial no's. Mine are 9440 CBA; would there be any reason for them to be any
>different from other PICs?
>Also is it possible to damage them by applying Vpp without Vdd present?
>(spot the novice)
>
>Thanks, Chris

Well Chris

I'm going to have to be careful here. I might end up being the "first port
of call" for people who have programmers and no backup.

PICs are generally robust but the Vpp voltage is critical and as I have
said, appears to be the real weak spot of the PIC chips. Appling Vpp without
Vdd is not such a good move but as I have never done it I cannot give any
indication if it is *likely* rather than possible, to destroy your chips.

Can you contact the designer of your programmer or is it "one of those type."

Again, it is hard to know what to do without either expertise or a working
programmer on hand.

Regarding batch numbers, I asked Arne for them purely so that others have
the oppertunity to say if they had problems with that batch. It's just
covering all bases, that's all. Usually there is no real practical difference.

BTW  At this very time, I am trouble shooting one of my programmers via
email. It's my fault for sending him a dud in the first place. Come Monday,
if the problem is not fixed I will send a new programmer via express airmail
and hope like hell Edward will send the other back. (it has three zif
sockets I would not like to lose if I can help it!)

There are others offering such service also. As long as you and all others
know what you get when you buy, or don't buy rather, a programmer we can all
be happy. It is unfortunate that things are so "unbalanced" at the moment.
Good designs and the back up for them look like disappearing soon.

Sorry for the whinge, I know some people must be getting sick of me. But I
don't see the designers of these programmers jumping up and down to help
anyone out and I don't see any other forum where issues can be discussed.

Regards

Jim




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

email newfoundspamBeGonespamne.com.au
------------------------------------------------------------------

'Programmer backup (was 16C84 serial numbers)'
1995\11\18@045342 by David Tait

flavicon
face
Newfound Electronics wrote:

> Good designs and the back up for them look like disappearing soon.

Jim, I wonder if you could elaborate on the above statement.

> But I don't see the designers of these programmers jumping up and down
> to help anyone out ...

Perhaps I'm just touchy this morning but as the designer of a simple
16C84 programmer I would like to point out that, although short of
jumping up and down, I do try to help people out.  I have setup a
FTP site where help notes and user contributed software can be found:

ftp://ftp.mcc.ac.uk/pub/micro-controllers/PIC/

and I answer all queries relating to the programmer as promptly as
possible.  All the information, software and help is given free of
charge.

David
--
RemoveMEdavid.tait@spam@spamspamBeGoneman.ac.uk

1995\11\19@031536 by Newfound Electronics

flavicon
face
{Quote hidden}

For the benefit of all others, I offered david my thoughts on these matters
in private email *before* I read his above reply and *after* he had posted
it so they actually crossed in the mail by coincidence.

David has emailed privately since and there is general agreement on the
problems people at the entry level face with their first programmer. In
fact, David was able to expand further with his own experiences. It was a
very useful exchange and a pity the thoughts were not shared publicly.

So theres no issue between myself and David relating  to the second point
above. (unless David disagrees.) So those looking for a reply with a bit of
bite, sorry!

I consider David to be a pioneer and his efforts honourable. Certainly, none
of my remarks were aim at David,  or necessarily anyone else. If help is
available to users for these programmers great, If they're happy, I'm happy
and will shut up.

If you look back in the last two weeks there has been requests for help with
cheap programmers on the piclist. It would have been nice to be able to
point to a source of help in these cases . This is what I have based my
thoughts on, nothing else.

As my comment has lead David to remind us of his offerings, it has proved to
be of some use to all of us concerned.

As long as there is clear understanding by all parties, everyone is
protected especially the new comers who can't be expected to know what to
look out for.

Regarding my first statement:

" Good designs and the back up for them look like disappearing soon."

I hope this is just a paranoid rambling but I am concerned that the volume
of cheap programmers may mean "mid level" programmers are squeezed out of
the market. This would mean a big jump from your first programmer to a full
production programmer.

If something works as it is supposed to then I guess you could say that was
a "good design."

What I refer to by "good design" is something that is high in utility,
automation and sophisication etc. but with great ease-of-use. If even an
experienced PIC user was to design a programmer for all the PICs and
possible programming options, I feel they would be stunned by the level of
sophisication possible.

Long list goes here:  "   "

Throw in some extras like OTP fuse protection, serial numbers, configuration
files the possibilities add up. This is before you come up against ID
locations that appear, disappear and change there size depending on what
documentation you look at, Checksums with similar problems, program modes
and commands for the 16C84 join in on the act etc. You have a lot to contend
with.

My fear is that  cheaper programmers will capture the imagination and
market, and mid level programmers that do the above and  generally keep
up-to-date will be the ones to go.

I hope my fear is unfounded  but this is what I meant if it clears the
matter up.

Regards and thanks for my  indulgence with the "soap box."

Jim

'Any low cost serial (for Mac) programmers for 16c7'
1995\11\21@143003 by Eric Brewer

flavicon
face
Hi,

I am looking for a low cost serial based programmer which I can interface to a
Mac. I have no problem in writing code to interface with the programmer. I
currently have a assembler/simulator/programming software which I wrote
in 1987 which works with the old PicPro programmer. I have updated the
assembler for the 71/73 and now just need some way to program the parts other
than running SoftWindows and using the PicStart software (this is really a
chore!).

Thanks,
eric

'Self-timed Serial bus Protocols'
1995\11\23@122455 by Martin Nilsson

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

Lured you out of the hole, finally... :-) Thanks for your illuminating
comments!

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

I'm sorry I was sloppy about clearly stating my assumptions. When I
say "self-timed" I mean that the protocol should give the same result
regardless of the delays in the wires.  You use it in a slightly
different (less extreme) meaning, with the very reasonable assumption
that wire propagation time is small. I think both of these can be
referred to as "self-timed."  In my sense, skew cannot be a problem by
definition, or otherwise the protocol wouldn't be self-timed. (When I
say "self-timed" in the following, I refer to it in this sense unless
noted otherwise.)

This is a stronger constraint on the algorithms. You are right as you
say that the bottleneck is often "ts," the switching time from reading
the port to setting it. However, with faster hardware, the bottleneck
will be "tp," the propagation delay on the bus. The absolute minimum
of tp is c/L, where c is the speed of light, and L is the length of
the bus, which means about 3 ns for L = 1 m.  That is for an optical
bus. For a bus made of copper, tp will be more like an order of
magnitude larger, or about 30 ns. For supercomputers and other extreme
high performance bus applications where ts<<tp, self-timed buses will
never be the fastest solution. They pipe line signals on the bus, but
on the other hand the bus needs to be tuned extremely well for this to
work.

Summarizing, for ts>>tp, self-timed protocols will likely be much
faster.  For ts<<tp, non-self-timed protocols can be much faster but
it is difficult to implement them so that they are faster. For ts = tp
approximately, the throughput is similar but, self-timed protocols
will be guaranteed safe.

{Quote hidden}

You are absolutely right. This is a bug, but it can be fixed (below).
I find some consolation in the fact that you are making precisly the
same mistake in your own procedure... :-) If you rename your wires 01K
to BCA, your "Send Zero" procedure sends precisely the problematic
"10" sequence.

{Quote hidden}

If I paraphrase it using the "follow the leader" metaphor, the bug is
that if the leader (master) returns to the previous position, a slave
will not be able to tell whether it is the leader that holds down the
line, or if it is a slow slave that hasn't moved yet. I guess this bug
shows how easy it is to make mistakes when designing self-timed
circuits.

In order to send a bit, there must be a selection of at least two
distinguishable states for the master to move to. This seems to
require at least four wires in my scheme. If the wires are ABCD, and
the initial idle state is A, the first move is A->AB->B, the master
*cannot* move B->AB for the above reason, but has to move either
B->BC->C or B->BD->D. This selection gives one bit of information.

> > Suppose again that the current idle state is A.  In order to transfer
> > control to a new master, the old master asserts B, releases A, and
> > converts to a slave.
>
> With a protocol like the above, there is no such complex requirement for a
> master/slave handoff.  Since everyone [including the old and new master]
> explicitly acknowleges everything they see, no one except the master needs
> to know who's master.

Unfortunately, there must be a handoff for the protocol to be strictly
self-timed.  Your "clobber" and "attention" procedures are
asynchronous relative to the bit sending protocol. This is what I find
really tricky. It may be the best asynchronous approach, but I would
need to consider it more carefully.

A read by a master from a slave is an example where you absolutely
want to have atomic bus access. The master sends the address to the
slave, converts the slave into master, and has the data sent back.
Nobody should be let in on the bus until the process is complete.

> > The really tricky thing is arbitration in a multi-master system.  This
> > is impossible in a pure self-timed system, so there are two
> > possibilities:
>
> Why is arbitration impossible in a self-timed system if devices have
> unique addresses?

I'm sorry I was careless about my formulations. Arbitration between
two contenders is not possible (with my definition self-timed) since it
introduces dependence on wire delays.

Corrections to the final part: Protocols can be constructed in the
same way as before, but there is one choice less for the master at
every stage, so it should be modified as follows:

[Nerd warning] A six-wire protocol can be constructed in the same way
as the four-wire scheme. Then we get 1/3 bits/wire/time unit. It can
be further generalized to n wires, of which k are asserted in an idle
state. I spent saturday night proving [proof still holds] that the
maximum bandwidth/wire
 2
is log Phi bits/wire/time unit = 0.694, where Phi is the golden ratio =
1.618... . I hadn't expected this ratio to go over 0.5, but one can get
arbitrarily close to it for large n (it is a tight bound).
Some interesting pairs (n, bits) are
         (4, 1), (6, 2), (7, 3), (9, 4), (15, 8), (21,12),...

{Quote hidden}

Your protocol here is simpler, but it is not self-timed in the sense I
have used. My formula does require self-timing, which with my definition
implies being deadlock-free.

-- Martin


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

'Auto adaptive(?) serial routine'
1995\11\25@075208 by mauricio

flavicon
face
Hi everybody,

In one of my applications, I need a serial RX/TX routine capable to
'recognize' the speed of the serial line, so it can adjust itself to
that speed (eg. I have a '84 based 'host' to which I want to attach
few 'terminals' working at 1200, 2400, 4800, 9600 baud).
Did anybody try something similar?
Any ideas on how to determine the RX speed, possibly without loosing
a byte of data?

Thanx,

Max

1995\11\26@165816 by Peter Jennings

picon face
I have done such a thing for other processors, but not the PIC (yet).

In general, all you have to do is time the start bit and use the
count as the time delay for sending and receiving bits. It is
necessary to carefully craft loops that are symmetric for
time determining, sending and receiving. No big deal really.

The first byte detected needs to be one with a space after the
start bit, so you are restricted in what characters can be used
for the rate detection. After that, any character can be received.
'*' 02Ah is a popular choice.

If you only send the right characters, I suppose you could do
speed determination on every byte, but it is more usual to only
check on the first character received after a reset or other
external indication. You could use the DTR as an indicator.

{Quote hidden}

--                                 peterjEraseMEspam@spam@netcom.com

1995\11\27@000958 by Joel Carvajal

flavicon
face
On Sat, 25 Nov 1995, Mauricio Culibrk wrote:

> Hi everybody,
>
> In one of my applications, I need a serial RX/TX routine capable to
> 'recognize' the speed of the serial line, so it can adjust itself to
> that speed (eg. I have a '84 based 'host' to which I want to attach
> few 'terminals' working at 1200, 2400, 4800, 9600 baud).
> Did anybody try something similar?
> Any ideas on how to determine the RX speed, possibly without loosing
> a byte of data?
>
> Thanx,
>
> Max
>

I haven't tried it myself but a lot of people have done that already.
However, I'm not sure what do you mean by "..without loosing a byte of
data?".  Usually, you connect to something (host) that is already sending
data, for synchronization with whoever wants to connect.  The data usually
is such that you could actually try all possible baud rates (brute force,
but you could think of other techniques) and then when the expected data
is finally received, you inform the host that you are know synchoronized
with his baud rate.  So in that case, you do lose some bytes of data  but
its OK.  Those data are for, as I said, to,let you synchronize with the host.

To summarize, in order to connect to a host at his baud rate, the host
must send a "synchronization" data.  Of course you must know the data.
You then adjust your baud rate until you receive the correct data.  When
you finally is in "harmony" with your host, inform him, and the
rest of the communication then proceeds.

Hope I was of help.  Good luck!

1995\11\28@082426 by Andrew Warren

flavicon
face
Mauricio Culibrk wrote:

> In one of my applications, I need a serial RX/TX routine capable
> to 'recognize' the speed of the serial line, so it can adjust
> itself to that speed (eg. I have a '84 based 'host' to which I
> want to attach few 'terminals' working at 1200, 2400, 4800, 9600
> baud). Did anybody try something similar? Any ideas on how to
> determine the RX speed, possibly without loosing a byte of data?

Joel Carvajal <RemoveMEjoelspamspamBeGoneTDS.PFI.NET> replied:

> To summarize, in order to connect to a host at his baud rate, the
> host must send a "synchronization" data.  Of course you must know
> the data. You then adjust your baud rate until you receive the
> correct data.  When you finally is in "harmony" with your host,
> inform him, and the rest of the communication then proceeds.

Mauricio:

If you're sending standard ASCII using no parity, 8 data bits, and 1
stop bit, you don't need to send a string of known synchronization
data at the start of your transmissions as Joel suggests.

Instead, you can simply start a timer at the first HI-to-LO
transition (the start bit), then check the timer at every LO-to-HI
transition.  Set the timer up so that it'll time out after slightly
more than the length of 9 bits at your slowest baud rate (>7.5
milliseconds for your 1200 baud rate).  I'd probably set the timer
to expire in 8.192 milliseconds; if I used the RTCC and were running
at 4 MHz, I'd set the prescaler to divide-by-32 so that the timer
could be contained in just one byte.

When the timer expires, the value it contained at the last LO-to-HI
transition will be the time between the leading (falling) edge of the
start bit and the leading (rising) edge of the stop bit.  A simple
table-lookup will tell you what baud rate you're receiving.

This technique works because the MSB is never set in standard ASCII,
so the leading edge of the stop bit will always be visible.

Note that this technique will NOT work if there's no delay between
one character and the next; the second character must not be
transmitted until at least 8.192 milliseconds after the start of the
first character.

-Andy

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

1995\11\29@102333 by mauricio

flavicon
face
Thanx to all that responded to my questions.

Max

1995\11\29@143824 by Lee Jones

flavicon
face
Mauricio Culibrk wrote:

> In one of my applications, I need a serial RX/TX routine capable
> to 'recognize' the speed of the serial line, so it can adjust
> itself to that speed (eg. I have a '84 based 'host' to which I
> want to attach few 'terminals' working at 1200, 2400, 4800, 9600
> baud).

I meant to reply earlier and got busy.  Sorry.

There are both synchronous and asynchronous serial communications.
With sync serial, a separate wire provides a clock transition in
the middle of each data bit.  No such thing as baud rate detecting.
I'll assume you mean _async_ serial comm.

With asynchronous serial, the data is sandwiched in between a start
bit and a stop bit.  Normally, there are 8 data bits between as in
the following diagram:

  0  marking     !---:''':''':''':''':''':''':''':''':
                 !   :   :   :   :   :   :   :   :   :
  1  spacing  ---!   :...:...:...:...:...:...:...:...:---:
                 Start 0   1   2   3   4   5   6   7  Stop

RS232 specified the physical properties of the interface.  This
includes voltages.  At the transmitter, logic 0 or "spacing" is
+5 to +25V while logic 1 or "marking" is -5 to -25V.  Marking and
spacing are terms that date back to Teletype days.

RS232 receiver must accept -25 to -3 or +3 to +25.  Range between
-3 and +3V is supposed to be used for hysteresis to reject noise.
Lots of receiver chips do NOT handle the -3V to +3V range correctly.
Their rejection band is about 1/2 a volt somewhere around 0V.

Note that the transmitter side minimum output is specified as a
higher voltage than the minimum specified at the receiver to allow
resistive drop in the wire.  Also, it's a 1-wire voltage based
interface, so you need a ground wire.  And be carefull of current
flows between the equipment on the ground wire -- particularly if
the two ends are located some distance from each other.

Normally an async RS232 interface is idle and marking (-5 to -25V).
When a character is transmitted, the start bit guarantees a low to
high transition (from marking to spacing).  The stop bit is used to
guarantee that (irrespective of the data) in a continuous stream of
characters, the line will be driven back down to the marking state
before the next start bit is sent.

When you see the leading edge of a start bit, you should wait 1/2
bit time and then sample again.  If the line is back at marking,
then you ignore it as noise.  This helps reject noise pulses of up
to 1/2 bit time.


The "baud rate" is the number of bits per second when the line is
running continuously.  The difference between bits per second and
baud rate is that baud rate may vary from 0 bps to maximum.  Thus
the baud rate is the correct term for an async line while BPS (bits
per second) is correct for a sync line.  [Misuse of this term is a
pet peeve of mine.]  So for 1200 baud, each bit is 1/1200 second wide.

The data bits are sent LEAST significant bit first.  Originally,
Teletypes used 7 data bits(*).  The 8th bit (data bit 7 above)
was used for a parity bit.  With inclusion of the parity bit, if
you counted up all the 1's data bits, you got an odd number (for
odd parity) or an even number (even parity).  Now the 8 data bits
are all used for sending 1 octet (aka byte) from the computer.

For example, an ASCII J (capital J, dec 74, octal 112, hex 4A) is:

  0  marking     !---+---!   !---!   !---+---!   !---!
                 !       !   !   !   !       !   !   !
  1  spacing  ---!       !---!   !---!       !---!   !---
                 Start                                Stop
  ASCII J (4A hex) =   0   1   0   1   0   0   1   0

While, an ASCII A (capital A, dec 65, octal 101, hex 41) is:

  0  marking     !---!   !---+---+---+---+---!   !---!
                 !   !   !                   !   !   !
  1  spacing  ---!   !---!                   !---!   !---
                 Start                                Stop
  ASCII A (41 hex) =   1   0   0   0   0   0   1   0

Now a more direct reply to your question.  I assumed you wanted to
sense baud rate because you weren't in control of both sides of the
communications link.  And at power up, the other end might have
changed and be at an unknown rate.  And I assume that you are NOT
using a built-in USART (like in the PIC 16c65 or 16C74).

So I'm assuming you have a 1 bit input watching the received async
data line.  You can look at the start bit width to determine baud
rate -- ASSUMING the first data character cooperates.  Note that the
example of A above allows this, the J does not (result would be off
by a factor of 2).

As a cross-check, you use the measured bit time to check for a stop
bit at the expected location.  If the stop bit is not at a marking
state, then you have a framing error or data overrun.  Maybe it was
noise or whatever, but you have to try again.

So you can auto-sense baud rate if the low order bit of the first
character is a 1 (50% probability).  Luckily, common characters that
people use to "wake up" a system are all odd (i.e. have a low order
bit of 1) like carriage return (13 dec, 0D hex), escape (27 dec, 1B
hex), or control-C (03 hex).

This also shows why, without knowing ahead of time what the first
character is, you cannot auto-detect baud rate without the possibility
of loosing a character.

Hope this long discussion wasn't too boring and is helpfull.

                                               Lee Jones

(*) Way, way back the Teletypes used 5 data bits, but I'll ignore
   that for this discussion.  Early Teletypes at 110 baud also
   used 2 stop bits -- but everybody uses 1 stop bit now.

-------------------------------------------------------------------
Jones Computer Communications             leespam_OUTspam@spam@frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1995\11\29@163614 by rdemay

flavicon
face
> In one of my applications, I need a serial RX/TX routine capable
> to 'recognize' the speed of the serial line, so it can adjust
> itself to that speed (eg. I have a '84 based 'host' to which I
> want to attach few 'terminals' working at 1200, 2400, 4800, 9600
> baud).

Alright,
  I've read a few of the suggestions on an autobauding, almost
everyone included a critical point on the subject.   But I didn't
see one that included all of key considerations (especially
importance of what the data stream looks like).

1.  Is first character known?  If so the baud rate can be determined
by measuring the time from beginning of start bit to
first bit that is a mark (logic 1).  Based on where this bit is
located in the character you can determine the baud rate --
i.e. if it's bit 0, then the measured time is the width of 1 bit.
With this method you won't lose any characters.

2.  If the first character is unknown, you must consider what
the data stream "looks like"? Is the stream continuous? Are the
characters "back to back"? (It's very simple to transmit data at
9600 baud without any space between charaters)  Is there
a pattern (CR/LF after every 80 characters for example)?

If characters are are at least 8.33milliseconds apart (1 character
at 1200 buad), then measuring the time from start bit to stop
bit will work (with 8.33 millisecond timeout of course).  You
always lose one character with this method.

Worse Case: If the characters are continuous, back to back and with no
pattern (and first character unknown), ahhhhhh ---- what
in the world are you going to do with this anyway (just
kidding)?  If this is the case, it's rather difficult to get in sync
and determine the baud rate (data better not be critical!).
You can try keeping track of the shortest 1-0-1 width time
(obvious limit this to .104 milliseconds --1/9600).   For
example: a 1-0-1 width of .208 ms, can't be 1200 & 2400 baud
but can be 4800 or 9600, so you assume 4800 until you measure
one of .104 ms.  You will need to get in sync with the start bit
as well (stop bit must line up on every character -- if not
try again).


As you can see, several methods of autobauding will work, but
you need to know what the datastream looks like before you
can determine which method is best.

:)

Rod
spamBeGonerdemay@spam@spambb-elec.com

1995\11\29@170329 by Przemek Klosowski

flavicon
face
  Worse Case: If the characters are continuous, back to back and with no
  pattern (and first character unknown), ahhhhhh ---- what
  in the world are you going to do with this anyway (just
  kidding)?  If this is the case, it's rather difficult to get in sync
  and determine the baud rate (data better not be critical!).

I suppose in that case you have to collect a second or so of data, run a FFT
and select the lowest frequency :^)

1995\11\30@082152 by mauricio

flavicon
face
Hi!

Thanx to Rod, Lee, Andrew and all others who spend their time to answr me...
Basically, I had the same idea to detect the baud rate, with respective
limitations (known first byte....). As I said, I wont't loose any
byte of async serial data, so I just wondered if there are some tricks...

Thanx again,

max


'Macintosh Serial Interface?'
1995\12\01@022310 by Ben Kwok-Yiu Li
picon face
I am trying to get a piece of hardware to work with the Mac interface.
It is based on the Eye Mouse in a Circuit Cellar a while back.  Do Mac's
have the same RS232 or is it the RS422 or something completely
different?  If anybody knows, I am dying to find out!...as project
deadline approaches quickly.  Also posted before is the alternative to
the serial, a MIDI interface.  Any help would be greatly appreciated.

ben
_____________________________________________________________________________
| RemoveMEbenliEraseMEspamKILLspamuclink2.berkeley.edu | spamBeGonebenlispam_OUTspamRemoveMEocf.berkeley.edu | .....benlispamRemoveMEbdt.com ******|
|---------------------------------------------------------------------------|
|WEB Page under construction...coming soon to a WWW Server near you...******|
|---------------------------------------------------------------------------|
|"If we don't stop him now, Bill Gates will take over the entire galaxy, he |
|already has Earth, and Mars." - Anonymous                                  |
|___________________________________________________________________________|

1995\12\01@084235 by Lee Jones

flavicon
face
> I am trying to get a piece of hardware to work with the Mac interface.
> [snip]  Do Mac's have the same RS232 or is it the RS422 or something
> completely different?

The Macintosh uses RS-422.  However, Apple built the hardware to
allow easy interoperability with RS-232 devices.

Here's my monospaced ASCII rendering of the female mini-DIN8 jack
on the back of all modern Macintoshes.  Note the physical gap
between pins 4 & 5 (for orientation).

         .-|-|-.     1 = HskO (handshake out)
        /       \    2 = HskI (handshake in / external clock)
       /  8 7 6  \   3 = TxD- (transmit data minus)
       ! 5   4 3 !   4 = Grd  (signal ground)
       \   2 1   /   5 = RxD- (receive data minus)
        \       /    6 = TxD+ (transmit data plus)
         '-----'     7 = n.c. (no connection)
                     8 = RxD+ (receive data plus)

[The above drawing should look circular and all the equal signs]
[should be in a vertical line.  If they are not, switch to a   ]
[monospaced font with tab stops each 8 characters.             ]


To make a Mac to RS232 DTE serial cable (i.e. Mac to modem):

Macintosh               RS-232
mini-DIN8               DB-25P               DE-9P
male plug               (male)               (male)   RS-232 usage

 1  HskO  ----------+-  20  DTR  ------------  4     Data Terminal Ready
                    '-   4  RTS  ------------  7     Request To Send
 2  HskI  ------------   5  CTS  ------------  8     Clear To Send
 3  TxD-  ------------   2  TxD  ------------  3     Transmit Data
 4  Grd   ------------   7  SG   ------------  5     Signal Ground
 5  RxD-  ------------   3  RxD  ------------  2     Received Data
 6  TxD+
 7  n.c.
 8  RxD+  ------------   7  SG   ------------  5     Signal Ground
   shell  ------------   1  FG   ------------ shell  Frame Ground

The above cable supports hardware handshake (RTS-CTS flow control)
if your Mac software knows how to use it.  Alternately (for software
handshake, aka X-ON/X-OFF, only), you can wire as follows:

 1  HskO  ------------  20  DTR  ------------  4     Data Terminal Ready
 2  HskI  ------------   6  DSR  ------------  6     Data Set Ready

The hardware handshake cable is much more usefull and also works
fine in software handshake environments.

RS232 is a single ended, voltage oriented interface.  RS422 is a
differential interface.  Once a common signal ground is provided,
the Mac's TxD- line becomes RS232 TxD.  It meets the RS232 specs
since Apple wisely chose +5V and -5V as their differential driver
outputs.

In the reverse direction, the Mac's RxD- and RxD+ lines are looking
for differential voltage as a comparative pair.  By tying the Mac's
RxD+ line to signal ground, the RxD- line becomes a single ended,
voltage-oriented input line.  It can be directly driven by the RS232
RxD line.


Recall that RS232 is non-symmetrical.  It has DTE (Data Terminal
Equipment) and DCE (Data Circuit-terminating Equipment) sex ends.
DTE usually uses a male DB-25 or male DE-9 (IBM PC/AT or modern PC
clone).  In modern convention, DCE usually uses a female connector.
To work, one end device must be DTE and the other must be DCE.

Examples -- terminals and PCs are DTE;  modems are DCE.

Important: You _MUST_ plug DTE into DCE.

In RS232, all signal description terms are from the DTE perspective.
So TxD (Transmitted Data) is the data stream going from the terminal
or PC into the modem.


You can plug the "Mac to RS232 DTE" cable described above directly
into a modem.  If you are going to plug it into a PC serial port, you
will need a separate null modem.

Or you can redesign the cable, build in the null modem, and have a
"Mac to RS232 DCE" cable.  Swap the DB25P male plug for a DB25S female
socket connector.  Swap the transmit and receive data lines (pins 2 &
3 on DB25).  Swap the handshake lines (Mac 1 to DB25 pin 4 or 20, not
both; and Mac 2 to DB25 pin 5, 6, 8, or all three) as appropriate for
the style of flow control you are using.


It is possible to hand-solder to the little, tightly spaced pins on
a mini-DIN8 male connector.  I've done it.  As a better alternative,
I recommend buying a premade Mac peripheral cable with mini-DIN8 male
plugs at BOTH ends.  Then cut it in half (or as appropriate), use your
ohm meter to figure out the wire color code, then solder on a DB25 or
DE9 connector as you see fit.  Much easier (and, as a side benefit,
you get a nice molded plug on the Mac mini-DIN8 end).

                                               Lee

-------------------------------------------------------------------
Jones Computer Communications             leespam@spam@frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1995\12\01@084856 by Chris Smolinski

flavicon
face
On Thu, 30 Nov 1995, Ben Kwok-Yiu Li wrote:

> I am trying to get a piece of hardware to work with the Mac interface.
> It is based on the Eye Mouse in a Circuit Cellar a while back.  Do Mac's
> have the same RS232 or is it the RS422 or something completely
> different?  If anybody knows, I am dying to find out!...as project
> deadline approaches quickly.  Also posted before is the alternative to
> the serial, a MIDI interface.  Any help would be greatly appreciated.

Mac's use a RS422 interface. I can dig up the serial port pinout. You can
wire the ports for RS232 also.

Chris


> ben
> _____________________________________________________________________________
> | EraseMEbenliRemoveMEspamSTOPspamuclink2.berkeley.edu | RemoveMEbenliKILLspamspamTakeThisOuTocf.berkeley.edu | spamBeGonebenlispam@spam@bdt.com ******|
> |---------------------------------------------------------------------------|
> |WEB Page under construction...coming soon to a WWW Server near you...******|
> |---------------------------------------------------------------------------|
> |"If we don't stop him now, Bill Gates will take over the entire galaxy, he |
> |already has Earth, and Mars." - Anonymous                                  |
> |___________________________________________________________________________|
>

1995\12\01@110926 by mark bolding

flavicon
face
I two days ago bought a cable like the one Lee describes below. I have
used cables like this in the past to talk to RS-232 devices with no problems.
The cable I bought cost about $10. I bought it localy (Birmingham AL) so I don't
know where you can order it by mail :(
       I will be using the the cable to talk to a 17C42 via a MAX232.  I'm usin
g
LabView on the Mac, so talking to the 17C42 should be a piece of cake. The 17C42
will be used to drive some LCD shutters in a vision science experiment.

Mark

Lee Jones wrote:

snip

{Quote hidden}

snip

===Mark Bolding========================
===UAB Vision Science Research Center==
===http://vision.vsrc.uab.edu/mbolding/

1995\12\01@121524 by David Tait

flavicon
face
Ben Kwok-Yiu Li wrote:

> Do Mac's have the same RS232 or is it the RS422 or something completely
> different?

I answered a similar question on the Microchip BBS a few month's back.
Here is roughly what I said then:

If your Mac is the same as my old Mac SE then it's not exactly RS232 (I
think it's RS422 or somesuch) but can be made to interwork with RS232.
The connections are via a Mini-8 connector:

   8 7 6         8 RXD+   7 GPi   6 TXD+
  5  4  3        5 RXD-   4 GND   3 TXD-
    2 1             2 HSKi    1 HSKo

GPi  is a general purpose input (don't ask me what it's for).
HSKi is Handshake in.
HSKo is Handshake out.

To connect a 3-wire RS232 cable to the Mac:

    RS232              MAC
    -----              ---
     RXD               TXD-
     TXD               RXD-
     GND               GND RXD+ (i.e. RXD+ is wired to GND.)

I usually resolve the ambiguity about which pin is which by using a
DVM to find TXD+ or TXD- as they will be at +/-12V unlike RXD+ or RXD-
which will be around 1V or so.

David
--
RemoveMEdavid.taitspam_OUTspamman.ac.uk

1995\12\02@013821 by Steve Childress

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

Do you have the pin-out of a MAX232 chip?

----------
From:   mark bolding[SMTP:mboldingspamspamVISION.VSRC.UAB.EDU]
Sent:   Friday, December 01, 1995 11:18 AM
To:     Multiple recipients of list PICLIST
Subject:        Re: Macintosh Serial Interface?

I two days ago bought a cable like the one Lee describes below. I have
used cables like this in the past to talk to RS-232 devices with no problems.
The cable I bought cost about $10. I bought it localy (Birmingham AL) so I don't
know where you can order it by mail :(
       I will be using the the cable to talk to a 17C42 via a MAX232.  I'm
using
LabView on the Mac, so talking to the 17C42 should be a piece of cake. The 17C42
will be used to drive some LCD shutters in a vision science experiment.

Mark

Lee Jones wrote:

snip

{Quote hidden}

snip

===Mark Bolding========================
===UAB Vision Science Research Center==
===http://vision.vsrc.uab.edu/mbolding/



------ =_NextPart_000_01BAC03D.BA724920
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhkGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG
AEABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAFgAAAAAAAAAgSsfpL6jEBmdbgDd
AQ9UAgAAAABwaWMgbWljcm9jb250cm9sbGVyIGRpc2N1c3Npb24gbGlzdABTTVRQAFBJQ0xJU1RA
TUlUVk1BLk1JVC5FRFUAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABcAAABQSUNMSVNUQE1J
VFZNQS5NSVQuRURVAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAmAAAAJ3BpYyBtaWNyb2NvbnRy
b2xsZXIgZGlzY3Vzc2lvbiBsaXN0JwAAAAIBCzABAAAAHAAAAFNNVFA6UElDTElTVEBNSVRWTUEu
TUlULkVEVQADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAA98+AQiABwAYAAAASVBNLk1p
Y3Jvc29mdCBNYWlsLk5vdGUAMQgBBIABACAAAABSRTogTWFjaW50b3NoIFNlcmlhbCBJbnRlcmZh
Y2U/AAcLAQWAAwAOAAAAywcMAAEAFgAmABgABQA4AQEggAMADgAAAMsHDAABABYAJgALAAUAKwEB
CYABACEAAAAyREY4NzVERjJCMkNDRjExOTQ1QTQ0NDU1MzU0MDAwMAADBwEDkAYA3AYAABIAAAAL
ACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQDAv9PHgMC6AR4AcAABAAAAIAAAAFJF
OiBNYWNpbnRvc2ggU2VyaWFsIEludGVyZmFjZT8AAgFxAAEAAAAWAAAAAbrAgMfT33X4LiwrEc+U
WkRFU1QAAAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABAAAABzdGV2ZWNAcmFpbi5vcmcA
AwAGEI87uAkDAAcQ4AQAAB4ACBABAAAAZQAAAERPWU9VSEFWRVRIRVBJTi1PVVRPRkFNQVgyMzJD
SElQPy0tLS0tLS0tLS1GUk9NOk1BUktCT0xESU5HU01UUDpNQk9MRElOR0BWSVNJT05WU1JDVUFC
RURVU0VOVDpGUklEQVkAAAAAAgEJEAEAAABdBQAAWQUAAEgKAABMWkZ1otfNCf8ACgEPAhUCqAXr
AoMAUALyCQIAY2gKwHNldDI3BgAGwwKDMgPFAgBwckJxEeJzdGVtAoMzdwLkBxMCgH0KgAjPCdk7
8RYPMjU1AoAKgQ2xC2DgbmcxMDMUUAsKFFEFC/JjAEAgRG8geQUIYCARgHZlIHRoNRuQcAuALQhg
BUBvZoQgYQXQQVgyMxHgGxFwBSA/CoUKi2xpMQQ4MALRaS0xNDTPDfAM0B9jC1kxNgqgA2D1E9Bj
BUAtIYcKhyA7DDB1IQZGA2E6Io4hBgyCIFEAwHJrIAbhZAuAZ8BbU01UUDoG0ibCAEBWSVNJT04u
AFZTUkMuVUFC4C5FRFVdIi8jPQZgDwIwJG8leyQgaWRheS4sGuAFkBPgYgSQIDBCMS2wMTk5NS6Q
MTY6HuAUsE0pPyM9VG9DK38le011bHQFIGz7G5AWEGMFIAiQAjAEIBxxgx7AE8AgUElDTCgAxlQv
fypOdWJqIUExn2kle1JlOBBNANALgHSYb3NoBlMHQCBJAjA1BJBmANBlHX8ehDM21yAHGkUhBkkb
oHcbAC2BGQQgYWcbAAbgdWdouwVAHKBjAaAz0R7AaxuU+wIgG5BMCeA/MAeQBQEuIOcEIC4gFaB3
Lj7RG2IKhXp1EbBkQFQEIEDFBAAg+wuAG6RhNQE6gBugB0AmcDFF0VJTLRzyDbB2ac8t8AQgA/Ab
sCBuGwAhAdFAgW1zLgqFVBvBQGS/PuA/1QWgNQEBoBwyJBkwL0LCP9VHgDTQb0BgbHnAIChCaXJt
JtERgMJtFLBMKSBzGwA+4NJkAiAndAqFa0fAB+D+dxvAFhAbE0BgA6AFsASBnUuiYkwwAMADEToo
CoX3USY+4APwbAMgLiBDoSbRHxujG7JAZEXZHKAxN0N+NBHgRxAcoBymQsA7MCfXTPBSUwqFTAGg
VgiQB+D/AiAbozoxLbBNUUYCUnNF4f8bwVRkOqAIYCawUhIcoDRB/y3wHGJAYEDgQsBI8lRjCoX3
UdhD0UXRZAUQG4FNUAeA+UGAQ0RZYRxAO2FE8xygP0cQAJBXMQTwNFFaYWV4/nAGcQeAAjBIdgqF
OjAmYLs77EGSSkFRR1EhEjo77OpzAwBwO+w+MWEmMUDhjxyhANBGRBzyRFRFTUDjOuRAZChpLlrx
ZlUEYvRtKWOGPmUnOjhrHEaEx2UnTJEfQERJTi8waxwkREJGoDVQbY5FLfw5UGxoB0Ab0QpAUpBr
HP4ocKJNMHFPclRGhUOwP5APQzZp6FEgGtAgSHNr5k9RICGIKy1RIAHQblFcVFJ2aiGAUSA0biRh
PwGQMWAEkEyROxE58GFkbnl1SXsPUSAndzF4wlKWVAXwd+03a7RlcQpQ9zUBZbErMWR1SRHgdhI+
4KV37SAu0CBDfN8gbXQuQzPQSMJ+7zNRIFR4/kR3MYCNf/GE4XfehLFRIfxUcgBxTJAFQHkydUl4
0Z5HCyBRIYCNffFTR4nf44FxUSFTaWd50omgCGD7fyuBcVKE/4SEjmF33n/xX34jLfBdQUPgiI02
hMMr43VJffFuLmNIdnWybXH9jmErjq+K/4wPjR9RITqg70KAAyCAfnXxRpb/mhUkIP9M4BuQmOxl
KBvBSnEbgUBkcHN1cHAVsQQgEYFkfncKwBuQEYB/IDqgZfIo/XzBLYGiGOBOgQWgAjADYGxsKWOf
ZK09pSBhciB+QiakpSGmP6aCpLgosSD7VuBfE1NfdTnwEbAKwBFwH4GQK0EEkKd6QBB0cDpELy9e
9C52c6mwLkZ1AaBoUGR1LydmL7877DxfPW8hFQqFFTEAsXAAAAADABAQAAAAAAMAERAAAAAAQAAH
MKD+KsCAwLoBQAAIMKD+KsCAwLoBHgA9AAEAAAAFAAAAUkU6IAAAAAC0Mg==

------ =_NextPart_000_01BAC03D.BA724920--

1995\12\02@205716 by AV Presentations

picon face
On Thu, 30 Nov 1995, Ben Kwok-Yiu Li wrote:

> I am trying to get a piece of hardware to work with the Mac interface.
> It is based on the Eye Mouse in a Circuit Cellar a while back.  Do Mac's
> have the same RS232 or is it the RS422 or something completely
> different?  If anybody knows, I am dying to find out!...as project
> deadline approaches quickly.  Also posted before is the alternative to
> the serial, a MIDI interface.  Any help would be greatly appreciated.
>
Hi,
I'm not familiar with the article you mentioned, but if your project
involves a MAC mouse, rs-232 is not the solution.  Macs use the ADB port
(Apple Desktop Bus) for the mouse and keyboard.  It is a clocked TTL
serial bus @ about 1200 baud.  I saw a source listing for the pic
somewhere for ADB.  Try the Microchip BBS.

morris beverly    spam_OUTavpresspam_OUTspamspam_OUTworld.std.com

'Help on serial eproms'
1995\12\04@223257 by Joe Callahan

flavicon
face
Where can I get info on how serial eproms and eeproms are programmed? I
want to build a promgrammer and write a program to send data to them.

Thanks in advance.

joe....

callahanspam_OUTspamaz.com

'Serial Communications RS232'
1995\12\06@021713 by Ben Kwok-Yiu Li

picon face
I have figured the parts needed to do a straight send/no receive RS232.
Can someone explain to me if this is correct.

If I only wanted to send serial, I only need to hook up the transmit line
and the ground(or reference) line.  Any help on PIC code for 1671 to send
this data?

_____________________________________________________________________________
| RemoveMEbenliKILLspamspam@spam@uclink2.berkeley.edu | benlispamBeGonespam.....ocf.berkeley.edu | KILLspambenlispam.....bdt.com ******|
|---------------------------------------------------------------------------|
|WEB Page under construction...coming soon to a WWW Server near you...******|
|---------------------------------------------------------------------------|
|"If we don't stop him now, Bill Gates will take over the entire galaxy, he |
|already has Earth, and Mars." - Anonymous                                  |
|___________________________________________________________________________|

'Max 232 pin out, was Re: Macintosh Serial Interfac'
1995\12\06@151235 by mark bolding

flavicon
face
Steve Childress wrote:
>
> ------ =_NextPart_000_01BAC03D.BA724920
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Do you have the pin-out of a MAX232 chip?

You can get a data sheet from Maxim by calling
1 800 998 8800.


===Mark Bolding========================
===UAB Vision Science Research Center==
===http://vision.vsrc.uab.edu/mbolding/

1995\12\06@155321 by Clyde Smith-Stubbs

flavicon
face
Mark Bolding wrote:
> Steve Childress wrote:
> >
> > Do you have the pin-out of a MAX232 chip?
>
> You can get a data sheet from Maxim by calling
> 1 800 998 8800.

Maxim do have a WWW site with data sheets on it in Acrobat format. The
URL is http:/http://www.maxim-ic.com. Unfortunately perhaps half the parts
listed have a one page data sheet that says "Coming Soon"! And
the MAX-232 is one of these :=(

On the other hand, if you were after the data sheet for a MAX 2402
spread-spectrum radio transmitter, it's right there!


--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
spam_OUTclydespamKILLspamhitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au  | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
FREE! Download our shareware (FREE for noncommercial use) MS-DOS C Compiler!
            Point your Web browser at http://www.hitech.com.au/

'Macintosh PIC direct connect Serial?'
1995\12\13@153239 by Ben Kwok-Yiu Li

picon face
Can I use the app note in the Embeeded handbook about direct serial with
a Macintosh interface?  I only need to transmit to the MAC.

_____________________________________________________________________________
| RemoveMEbenliRemoveMEspamEraseMEuclink2.berkeley.edu | KILLspambenlispamspamBeGoneocf.berkeley.edu | benlispamspambdt.com ******|
|---------------------------------------------------------------------------|
|WEB Page under construction...coming soon to a WWW Server near you...******|
|---------------------------------------------------------------------------|
|"If we don't stop him now, Bill Gates will take over the entire galaxy, he |
|already has Earth, and Mars." - Anonymous                                  |
|___________________________________________________________________________|

'Serial EEPROMs and the SSP module'
1995\12\14@125920 by Martin J. Maney

flavicon
face
I'm designing a small controller application that needs a modest amount
of EEPROM storage to be attached to a 16C73 PIC, and I'm looking for
suggestions on choosing the I2C or 3/4 wire (SPI?) interface versions
- those would be the 24LC01 or 93LC46 parts.  There appears to be no
difference in cost or availability, and the performance differences that
do exist seem to be completely immaterial for this application (ie, I
donnn't care how fast they transfer data, etc).  So I seem to be able to
choose which device I use on the basis of conveninence of the driver code
I'll need, and this is where I have a few questions.

I2C first: it seems pretty clear that the SSP doesn't do anything at all
for master-mode operation of an I2C interface, so I may as well ignore it
and just wiggle the interface pins via the PORTx and TRISx registers.  Yes?

For the 3/4 wire interface I'm not so sure - does that protocol
correspond to the SPI mode of the PIC's synchronous port?  If so, is it
more than a family resemblance - does the SPI mode actually handle the
protocol used with the EEPROM?  It looks to me like it doesn't: the SPI
mode seems to be strictly byte oriented, while the EEPROM seems to need a
varying number of bits for its commands (the data itself is in byte-size
bits, but the command and perhaps address aren't, if I'm reading things
correctly).

The sample code in the app notes is for a 16C5x without any hardware
assistance, and this would almost certainly be usable, but with an eye
towards potential future applications I'd like to know if there are
better solutions possible for the PICs with the SSP module hardware
available.

Thanks!

1995\12\14@233010 by John Payson

flavicon
face
> I2C first: it seems pretty clear that the SSP doesn't do anything at all
> for master-mode operation of an I2C interface, so I may as well ignore it
> and just wiggle the interface pins via the PORTx and TRISx registers.  Yes?

While I've not tried it, I think you may be able to use the PIC's hardware
to your benefit in I2C master mode if you set it for a micro-wire (SPI)
style port and tie the data in and out wires together.  You'd have to do
start and stop sequences by hand, but could probably let the SPI port bang
out the actual bytes of data.

'High Speed Serial'
1995\12\15@033014 by m.d.simpson.bra0505

flavicon
face
Has anybody managed to transmit and receive at baud rates of
about 38k baud on a 10MHz 16C84?  I recon it's just about
possible if using interrupt-on-change 7:4.  Anyone done it, do
you have the code?
Mark

1995\12\15@043353 by Eric Brewer

flavicon
face
Assuming you want to either send or receive but not both at the same time,
I have done 38.4kbaud on 16c5X series with 4mhz (RC) oscillator. Of course,
having
a better clock source makes the code a bit easier. Are you sure you need
this to be
interrupt driven? What are you using the serial for? What are the constraints?

Cheers,
eric

>Has anybody managed to transmit and receive at baud rates of
>about 38k baud on a 10MHz 16C84?  I recon it's just about
>possible if using interrupt-on-change 7:4.  Anyone done it, do
>you have the code?
>Mark

1995\12\15@051207 by m.d.simpson.bra0505

flavicon
face
> Assuming you want to either send or receive but not both at the same time,
> I have done 38.4kbaud on 16c5X series with 4mhz (RC) oscillator. Of course,
> having
> a better clock source makes the code a bit easier. Are you sure you need
> this to be
> interrupt driven? What are you using the serial for? What are the constraints?
I'll need to send/receive in the same code, possibly not at the same time,
though that would be nice. It's for a midi project.  I need to AtoD a pressure
sensor, and insert volume control messages in a midi stream (so it needs to
be midi aware).  I figure at midi speed I have 80 cycles to play around with
per every bit.
I could split it 40 (bit processing) / 40 (data processing), but occasionally
I might need more than 40 cycles to do the serial AtoD, hence using interrupts
instead.  I've started writing the code, but thought if someone has already
done something similiar, then it would save re-inventing the wheel so to speak.

Cheers

Mark

1995\12\15@074711 by Bill Cornutt

flavicon
face
----------
>It's for a midi project.  I need to AtoD a pressure
>sensor, and insert volume control messages in a midi stream (so it needs to
>be midi aware).  I figure at midi speed I have 80 cycles to play around with
>per every bit.


Although it may be too slow for your application, I think that
a TV color crystal 3.5075... mhz will give you a midi baud rate
when devided by some power of 2.  So by using such a crystal for
the PIC osculator, the RTC could generate the timming simply.

Bill C.

1995\12\15@083147 by Byron A Jeff

face picon face
>
> ----------
> >It's for a midi project.  I need to AtoD a pressure
> >sensor, and insert volume control messages in a midi stream (so it needs to
> >be midi aware).  I figure at midi speed I have 80 cycles to play around with
> >per every bit.
>
>
> Although it may be too slow for your application, I think that
> a TV color crystal 3.5075... mhz will give you a midi baud rate
> when devided by some power of 2.  So by using such a crystal for
> the PIC osculator, the RTC could generate the timming simply.

Bill I'm not so sure about that. The MIDI bit rate of 31250 was picked because
the 16x rate (which is common for generating serial bit rates) is exactly
500 Kbps. This is easily obtainable from multiples of 1 Mhz. The colorburst
frequency of 3.5745 Mhz would need to be divied by 112 to get something close.

It's much easier to divide 1,2,4,5,8 or 10 Mhz down to 500000 Hz.

BTW you'll have to work real hard to get a PIC to do midi stuff. I'd advise
either using a dedicated UART (a 16550 would be outstanding here) or maybe
use 2 PICS (1 for the UART, the other to do the work).

My student wrote some serial routines that struggled at 19200 on a 16C84. I
guess a 20 Mhz part could do the job at 31250...

BAJ

1995\12\15@090337 by Byron A Jeff

face picon face
-
- ----------
- >It's for a midi project.
-
- Although it may be too slow for your application, I think that
- a TV color crystal 3.5075... mhz will give you a midi baud rate
- when devided by some power of 2.

Not exactly. The MIDI bit rate was picked for easy generation from
microprocessor crystal rates.

1X   -    31250
16X  -   500000
32X  -  1000000
128X -  4000000
320X - 10000000
640X - 20000000

And it's exact too. So just use a 4, 10, or 20 Mhz crystal and then divide
using the Timer0 prescaler and Timer0 to generate the correct bit rate.

BAJ

1995\12\15@121551 by Martin J. Maney

flavicon
face
On Fri, 15 Dec 1995, Mark D. Simpson wrote:
> I'll need to send/receive in the same code, possibly not at the same time,
> though that would be nice. It's for a midi project.  I need to AtoD a pressure
> sensor, and insert volume control messages in a midi stream (so it needs to

At this point my immediate thought is "have you considered the 16C7x
chips?"  The '73 would make you life a lot simpler: with an onboard A/D
converter and UART the hairiest parts of the job are all but done for
you (he said, with his fingers crossed).  I'm using that chip in a similar
sort of application, and I've sketched what I would need to do to make it
work without the hardware A/D and UART, and I think it would be just
barely possible (I was planning for 19.2K, actually), but it requires the
actual processing code to be sliced and diced into tiny fractions.  My
first hack at it used up most of the clock cycles in overhead, which
meant I'd need even tinier slices for the real work, and I said "bah!"
Then I ordered ITU's nice little programmer package.

OTOH, if you just want to do it on the 5x chip to see if it can be done,
don't let me discourage you!  It will be ugly and a lot of work, but it
ought to be possible.  I think.

BTW, if you've got an incoming MIDI stream then it seems to me that you
do indeed have to design for simultaneous send and receive.  Unless you
are somehow assured that the sending end will wait for you to finish
transmitting, which seems unlikely.  :-)

'PC keyboard serial data'
1995\12\15@171019 by adrian

flavicon
picon face
Anyone have details of the serial data used for PC keyboards ?
I want to connect a PIC and a keyboard together..

Ta.

--
_                Happy Christmas and a Merry New Year
(_) _| _ . _  _   Tel +44 973 222257
( )(_|(  |(_|| )  Fax UK 0500 222258                    E&OE

1995\12\15@180742 by Ben L Wirz

flavicon
face
       There was an article in Circuit Cellar less than a year a ago on
the subject, well shoot I try to find it real quick.  I was wrong there
were two articles:

April and May of 1995

Hope this helps,
Ben

Ben Wirz                Check out My Home Page for Great Deals on Bulk
                       Buy Electronics (LMD 18200 H Bridge and PIC 16C84)
RemoveMEblw2spamBeGonespamRemoveMEcec.wustl.edu      http://cec.wustl.edu/~blw2/index.html

On Fri, 15 Dec 1995, Adrian Kennard wrote:

> Anyone have details of the serial data used for PC keyboards ?
> I want to connect a PIC and a keyboard together..
>
> Ta.
>
> --
>  _                Happy Christmas and a Merry New Year
> (_) _| _ . _  _   Tel +44 973 222257
> ( )(_|(  |(_|| )  Fax UK 0500 222258                    E&OE
>

'Serial programmer question'
1995\12\15@182859 by Patrick C Leger

flavicon
face
Hi,

I just built an RS-232 powered 16C84 programmer (the one with 1
diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
with it.  The 78L05 sucks the tx line (and thus MCLR) down to about 7
volts, which is apparently not enough to kick it into programming
mode.  I verified this behavior with another 78L05 running on the
serial line, driving only a 4.7K resistor + smoothing cap; when
nothing is connected to the serial line, I get about 12V on it; when
the 78L05 is connected, I get from 5 to 7V depending on the 78L05's
load.

Am I incorrect in thinking that the '84 needs 12V on MCLR to put it
into programming mode?  All the other signals to the chip looked fine.
Or do I just have a cheesy 78L05?  It's made by JRC/NJR.

--
Chris Leger (KILLspamblahspamBeGonespamcmu.edu)
Carnegie Mellon University
Field Robotics Center

1995\12\15@191541 by Rolan

flavicon
face
On Fri, 15 Dec 1995, Patrick C Leger wrote:

> Hi,
>
> I just built an RS-232 powered 16C84 programmer (the one with 1
> diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
> with it.  The 78L05 sucks the tx line (and thus MCLR) down to about 7
> volts, which is apparently not enough to kick it into programming
> mode.  I verified this behavior with another 78L05 running on the
> serial line, driving only a 4.7K resistor + smoothing cap; when
> nothing is connected to the serial line, I get about 12V on it; when
> the 78L05 is connected, I get from 5 to 7V depending on the 78L05's
> load.
>
> Am I incorrect in thinking that the '84 needs 12V on MCLR to put it
> into programming mode?  All the other signals to the chip looked fine.
> Or do I just have a cheesy 78L05?  It's made by JRC/NJR.
>

It is true the specs call for 12 or 13 Volts on the MCLR pin, but those
are the just the specs ;)

In reality, the PIC can go into the program mode with much less. I think
my serial port surfs on the edge of 7-9 volts during programming. Rather
than pulling apart your circuit, you might want to try a serial port
on a different computer.

-()---()---()---()---()---()---()---()---()---()---()---()---()---()---()-
Rolan Yang            http://hertz.njit.edu/~rxy5310   Electrical Engineer
@spam@rxy5310STOPspamspam@spam@hertz.njit.edu                             kyuriusspamBeGonespamspamBeGonetsb.weschke.com
VR,ROBOTICS,FENCING,HACKING,INDUSTRIAL MUSIC,ART,EXPLOSIVES,INLINE SKATING
                   THESE ARE A FEW OF MY FAVORITE THINGS.
-()---()---()---()---()---()-----()-()---()---()---()---()---()---()---()-
4 out of 10 people are annoyed by ^ this.

1995\12\15@193649 by Arne Alsvik

flavicon
face
At 18:25 15.12.95 -0500, you wrote:
>Hi,
>
>I just built an RS-232 powered 16C84 programmer (the one with 1
>diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
>with it.  The 78L05 sucks the tx line (and thus MCLR) down to about 7
>volts, which is apparently not enough to kick it into programming
>mode.  I verified this behavior with another 78L05 running on the
>serial line, driving only a 4.7K resistor + smoothing cap; when
>nothing is connected to the serial line, I get about 12V on it; when
>the 78L05 is connected, I get from 5 to 7V depending on the 78L05's
>load.
>
>Am I incorrect in thinking that the '84 needs 12V on MCLR to put it
>into programming mode?  All the other signals to the chip looked fine.
>Or do I just have a cheesy 78L05?  It's made by JRC/NJR.
>


I do connect a power supply between 7805 and the diode (I use not a 78l05).

Arne -Norway

1995\12\15@193856 by Arne Alsvik

flavicon
face
At 18:25 15.12.95 -0500, you wrote:
{Quote hidden}

I do connect a power supply between 7805 and the diode (I use not a 78l05).

Arne -Norway

'PC keyboard serial data'
1995\12\15@215545 by Dennis J. Eberl

picon face
Hello Ben & Adrian,

Sorry I can't quote but here's my 2 cents worth. Ben is right, John
Dybowski's two-part article is very thorough although part 2 tacks on a
desccription of how to fake your PC into thinking it is getting keystrokes
when in fact it is really reading a Dallas Semi. Touch Memory. A bit too
convoluted.

A shorter route might be the following (although I highly recommend reading
Dybowski if you have access to back issues of CC Ink): (1) find just about
any edition of Peter Norton's Programmer's Guide to the IBM PC and pull a
xerox of Chapter Six, "Keyboard Basics" and, maybe Chapter Eleven, as well.
These will demystify scan codes. Scan codes are nothing new. Every matrix
scanned keyboard emits scan codes, which are translated into more civilized
and useful codes like USASCII. It's just that IBM decided that you need two
for each key: one for the downstroke and one for the upstroke, which most
programs I've seen just throw away.

A second and ultimately more useful source is Philips Semiconductor's
application note AN434, which shows you how to kludge a simple electrical and
software interface a la I2C with an additional line for data to/from the
keyboard. (Don't let the I2C part scare you: it's basically just a
synchronous serial link. Philips is just pushing I2C.) Electrically you need
any two bidirectional pins on a PIC, two diodes, and two pull-ups, power, and
ground. Something like this:


PIC pin* ------>|---------- Keyboard Clock (pin 5)**

PIC pin* ------>|---------- Keyboard Data  (pin 3)**

+5V      ------------------ Keyboard Vcc   (pin 2)**

DC Rtn   ------------------ Keyboard GND   (pin 4)**

* You need a 10K ohm pull-up on the PIC side of the
  diode ( --->|--- this thing).
** You can also control the keyboards RESET (pin 1), or
  leave it disconnected. The keyboard resets itself at
  power up. The pin numbers shown are from AN434. Alway
  double check. They are for the standard big old 5-pin
  connector. (The PS/2 has a 6th pin that's not used,
  I don't know if the pinout is the same.) Please take
  all this with a large grain of something medicinal as
  I left my glasses upstairs!


Hope this helps. If you have trouble finding this stuff,
give me a shout at spam_OUTdeberlSTOPspamspamlocalnet.com along with your
mailing address. It's not at all hard to interface any of the matrix-only $10
keyboards with a from mux/demux. Don Lancaster shows how in his CMOS
Cookbook. I prefer
the way they did it in the Otrona Attache (a CP/M machine I wish was before
my time). Actually, two 4051 counting up off of six pins of a PIC will do
just fine (8 x 8 = 1 of 64 scan codes each time a key is pressed).
You need an additional line to the pick for keypress, etc. Actually, this
could be made even simpler - 2 lines from the PIC with a 3rd or 4th for SHIFT
and CTRL if you want. Hope this helps. Nice lose my "lurker" status and
finally contribute something to this SIG.

Dennis Eberl
Amherst, NY
VOX: (716) 691-9232
FAX: (716) 564-1709
net: RemoveMEdeberlspamspamlocalnet.com

'Serial EEPROMs and the SSP module'
1995\12\16@052214 by Robin Abbott

flavicon
face
Martin,

I too have had troubles with the I2C module, it's hopeless ! In the
end I gave up and copied code written for the '57. If you'd like
I can send you the source code for driving a 24LC65 which is
actually much harder than the 24LC01, and could be cut down
fairly easily, however it may not be commmented as well as you'd
like!

Robin

TakeThisOuTrobin.abbottspamspamRemoveMEdial.pipex.com

1995\12\17@094325 by BBoles

flavicon
face
The '73 module does not do master mode I2C, so you would have to bit-bang it.

The 93LC46 is a "Microwire" (TM National) interface and does not directly
correspond to the SPI modes.

However, it is easier to run an interface to the 93XXXX series.  See App Note
#AN-613 for info. (It's in the new ECH Update Book).

Rgds, Brian.


______________________________ Reply Separator _________________________________
Subject: Serial EEPROMs and the SSP module
Author:  "Martin J. Maney" <KILLspammaneyspamspamspam_OUTMCS.COM> at Internet_Exchange
Date:    12/14/95 11:58 AM


I'm designing a small controller application that needs a modest amount
of EEPROM storage to be attached to a 16C73 PIC, and I'm looking for
suggestions on choosing the I2C or 3/4 wire (SPI?) interface versions
- those would be the 24LC01 or 93LC46 parts.  There appears to be no
difference in cost or availability, and the performance differences that
do exist seem to be completely immaterial for this application (ie, I
donnn't care how fast they transfer data, etc).  So I seem to be able to
choose which device I use on the basis of conveninence of the driver code
I'll need, and this is where I have a few questions.

I2C first: it seems pretty clear that the SSP doesn't do anything at all
for master-mode operation of an I2C interface, so I may as well ignore it
and just wiggle the interface pins via the PORTx and TRISx registers.  Yes?

For the 3/4 wire interface I'm not so sure - does that protocol
correspond to the SPI mode of the PIC's synchronous port?  If so, is it
more than a family resemblance - does the SPI mode actually handle the
protocol used with the EEPROM?  It looks to me like it doesn't: the SPI
mode seems to be strictly byte oriented, while the EEPROM seems to need a
varying number of bits for its commands (the data itself is in byte-size
bits, but the command and perhaps address aren't, if I'm reading things
correctly).

The sample code in the app notes is for a 16C5x without any hardware
assistance, and this would almost certainly be usable, but with an eye
towards potential future applications I'd like to know if there are
better solutions possible for the PICs with the SSP module hardware
available.

Thanks!

'Serial programmer question'
1995\12\18@094219 by Rick Miller

picon face
Patrick C Leger wrote:
>
> Hi,
>
> I just built an RS-232 powered 16C84 programmer (the one with 1
> diode, 1 cap, 1 78L05, and 3 resistors), but I'm having some problems
> with it.  The 78L05 sucks the tx line (and thus MCLR) down to about 7
> volts, which is apparently not enough to kick it into programming
> mode.

Chris,

Check your regulator ...is it really a 78*L*05?
It should be just the same size as an ordinary transistor.

I built my first PicBlaster with a 7805 (no "L") and had identical
results.  Make sure you're using the "L"ow-power regulator.
--
Rick Miller    <http://www.execpc.com/~rdmiller>

'PIC 16C74 Serial Xmit Problems'
1995\12\20@230902 by Brad Morrow

flavicon
face
Hi John;

I am currently debugging the transmit portion of my firmware for the 16C74.  I
can not make it work without send bad characters every so often.  I have done
several RS-232 implementations in the past, but this one is the most difficult
one to get working properly.

Is it possible you could shed some light on my problem?  I have been in contact
with Microchip, but am getting no where fast.

Regards,

Brad Morrow

--
-
--------------------------------------------------------------------------
Brad Morrow                                      Advanced Systems Division
Product Design                                  e-mail: morrowRemoveMEspamasd.sgi.com
Silicon Graphics, Inc.                      voice-mail:      (415)390-1311
2011 N. Shoreline Blvd.                            fax:      (415)961-9075
Mountain View, CA 94039-7311
--------------------------------------------------------------------------

1995\12\21@082545 by Mark A. Corio

picon face
Are you using serial transmit interrupts?  If you are you must be very
careful to properly save and restore the state in the interrupt service
routine.  We had similar problems before and that was our cause.  We also
went to a polled transmit routine and used the interrupts only on the receive
of a character as our application was not required to do anything else during
the transmission time.

Another thing to consider...are you using proper level shifting circuits to
get the +/-5 to +/- 12 volts required for RS-232 (as much discussed
recently)?  If not you may be on the hairy edge of your receiver's noise
margins.

Good Luck!!

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

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

1995\12\21@134023 by Glyn Davies 'Gryn'

flavicon
picon face
>
> Hi John;
>
> I am currently debugging the transmit portion of my firmware for the 16C74.  I
> can not make it work without send bad characters every so often.  I have done
> several RS-232 implementations in the past, but this one is the most difficult
> one to get working properly.
>
> Is it possible you could shed some light on my problem?  I have been in
contact
> with Microchip, but am getting no where fast.
>
> Regards,
>
> Brad Morrow
>

Sounds like you are over running whatever you are sending to.  I've been playing
with a 74 @20Mhz, & 9600 and have overrun lots of kit !

One bet might be to get it to talk to something with a 16550, see what's going
on, or use one of those serial snooping boxes if you have one available.

Alternatively, try slowing down the baud rate, I'm about to implement an
Xon/Xoff for the 74, (when I've finished my Xmas exams :)

Glyn

--

Glyn D / http://www.cs.man.ac.uk/~daviess / Computer Science 3rd year

------------------------------------------------------------------------
             "Whom computers must destroy, they must first drive mad."
                                                       -- fortune

                                    "What if everyone felt like that?"
                                                       -- Catch 22
------------------------------------------------------------------------


'In Circuit Serial Programming (and apologies)'
1996\03\21@042649 by Dennis Velthuis
flavicon
face
Hello.

First, I am terribly sorry of the rude accidental posting I did.
I was NOT aware of the fact that a reply to a message on the piclist would
arrive on the pic-list.
Hereby I want to apologise myself to anyone I have offended by my 'junk' mail.
Again, sorry. I wish I could turn back the clock.

Now to the topic...

I want to be able to do some in circuit serial (re)programming of a
circuit I have. In general, I want to experiment with the fact that a '84 can
be programmed whilst in the target circuit.
The circuit consists of a 16c84, vdd is directly connected to vpp.

Now my question is, is this possible? I personally don't think so
'coz vdd needs to be 5v and vpp needs to be 13.5v.
I think I will blow it up while trying to program this circuit.
But maybe not, I don't want to throw away my picstart 16b, nor the '84.

Is it possible with extra circuitery?
Should the circuit contain an extra resistor between vdd and vpp and if yes
what value?

How long can the programmer to '84 cable be in general?
I want to be able to use quite a long cable (1 meter), are there any things
I should be aware of?

I was also wondering, has the picstart16b1 the ability to do in circuit
serial programming or do I need a special programmer?
If yes, what kits are out there with this ability? (commercial and diy)

Many questions, I hope one of you specialists can help me.

Thanks in advance.







--
****************************************************************************
*             -= Dennis Velthuis =-    -= spam_OUTdenvRemoveMEspamEraseMEhtsa.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\03\21@053656 by Newfound Electronics

flavicon
face
>Hello.
Cut..
>Again, sorry. I wish I could turn back the clock.
>
Yer. I know the feeling.

{Quote hidden}

Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
scramble the memory!

>
>How long can the programmer to '84 cable be in general?
>I want to be able to use quite a long cable (1 meter), are there any things
>I should be aware of?

I meter long cable probably won't cause to many problems but this is a
matter I'm not expert on. There is nothing extra to consider just because
you are actually programming a chip. The usual data comms considerations
apply. I'm to uneducated to say much more.

>I was also wondering, has the picstart16b1 the ability to do in circuit
>serial programming or do I need a special programmer?
>If yes, what kits are out there with this ability? (commercial and diy)

The PICSTART 16B used the serial method of programming (I think!) BUT this
is not necessarily the same as ISP. Maybe you can experiment and get the
PICSTART to program in-system.

It should be possible. Just don't load RB6 and RB7 on the target.

I recommend you start with the 16C84 in a bare socket (and the Vdd-Vpp
resistor) and bring GND (5), Vdd (15), Vpp (4)  RB6 (13) and RB7(14) across
to it. Get it working in the socket first to verify the use of the serial
program method and correct wiring THEN transpose to you target. This way you
can track where problem occur. Pin numbers in () are for the 16C84.

There are many kit programmers that will program the 16C84 in-system but I
feel you should be able get the PICSTART to do what you want.
>
>Many questions, I hope one of you specialists can help me.

Me, a "specialist?" A title at last?!
>
>Thanks in advance.
>

Regards and good luck,

Jim

1996\03\21@060013 by Dermot

flavicon
face
On Thu, 21 Mar 1996, Newfound Electronics wrote:

> >Should the circuit contain an extra resistor between vdd and vpp and if yes
> >what value?
>
> Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
> resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
> scramble the memory!
>
Hi,

While it will limit any current flow to a fairly harmless level, a
resistor alone will not prevent the Vpp voltage appearing on the 5 volt
Vdd supply line. I prefer to use a diode and resistor in series. The
programmer should hold Vpp to ground before applying the actual Vpp in
programming mode thus providing an ESD path.

Regards,
_________________________________________________________________________
 __     __   ___             __   ____  <>  Electrical Engineering Dept.
/  \   /_   /__/  /\  /\    /  /   /    <>    University of Bradford
/___/  /__  /  \  /  \/  \  /__/   /     <>            England

1996\03\21@062749 by Newfound Electronics

flavicon
face
>On Thu, 21 Mar 1996, Newfound Electronics wrote:
>
>> >Should the circuit contain an extra resistor between vdd and vpp and if yes
>> >what value?
>>
>> Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
>> resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
>> scramble the memory!
>>
>Hi,
>
>While it will limit any current flow to a fairly harmless level, a
>resistor alone will not prevent the Vpp voltage appearing on the 5 volt
>Vdd supply line. I prefer to use a diode and resistor in series. The
>programmer should hold Vpp to ground before applying the actual Vpp in
>programming mode thus providing an ESD path.

Dermot,

At no stage should there be Vpp applied without Vdd. It is the presence of
Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
any programmer applied Vpp without Vdd.

Regarding ESD. While the programmer may hold Vpp at ground, what about when
it is not connected? This is when ESD "scrambling" can occur. I know it less
likely if the usual preventative measures are taken, BUT I know it has
happened and it appears to happen at ESD levels that ordinarily wouldn't
harm the rest of the componentry. IMHO the resistor method has no drawbacks
and does serve to prevent such occurences. I can see only positives for it
myself. However, many people do use the diode without to many problems.

BTW  The "victim" in the case I know of had to reprogram 100 16C84 based
boards again. Ouch!

Regards

Jim

1996\03\21@065734 by Dermot

flavicon
face
On Thu, 21 Mar 1996, Newfound Electronics wrote:

> At no stage should there be Vpp applied without Vdd. It is the presence of
> Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
> any programmer applied Vpp without Vdd.

Hi Jim,

I think we may be at cross purposes here. The original inquiry (as I
understood it) was about a circuit that had Vpp hard-wired to Vdd,
presumably to hold MCLR* high in normal operation. Thus the Vpp voltage
level would appear on the Vdd line. However even with a large value
resistance between Vpp/MCLR* and Vdd, the programming voltage can still
appear on Vdd.

>
> Regarding ESD. While the programmer may hold Vpp at ground, what about when
> it is not connected? This is when ESD "scrambling" can occur. I know it less
> likely if the usual preventative measures are taken, BUT I know it has
> happened and it appears to happen at ESD levels that ordinarily wouldn't
> harm the rest of the componentry. IMHO the resistor method has no drawbacks
> and does serve to prevent such occurences. I can see only positives for it
> myself. However, many people do use the diode without to many problems.

Obviously if the resistor alone works well, it's a matter of choice, but
personally, I would be very wary of not using a diode/resistor combination,
with perhaps a
higher value resistor to Vss for additional ESD discharge purposes.

>
> BTW  The "victim" in the case I know of had to reprogram 100 16C84 based
> boards again. Ouch!

Yes :-)

Regards,

_________________________________________________________________________
 __     __   ___             __   ____  <>  Electrical Engineering Dept.
/  \   /_   /__/  /\  /\    /  /   /    <>    University of Bradford
/___/  /__  /  \  /  \/  \  /__/   /     <>            England

1996\03\21@084559 by Bill Cornutt

flavicon
face
----------

>I want to be able to do some in circuit serial (re)programming of a
>circuit I have. In general, I want to experiment with the fact that a '84 can
>be programmed whilst in the target circuit.


While I can not answer your question, or because I can not
answer your question, I have an alternative for you.

The Basic Stamp does what you want.  It is a pic programmed
with an interperter.  The basic tokens are storred in serial
eeprom.  To program a '84' for such a function may not be
practical because of development time and/or memory,

But the concept may be a good one to use.

The 64 bytes of eeprom data could hold I/O pin configuations
and/or data constants.  Also the data eeprom could contain tokens
to control program flow.  (a very high level interperter?)

So if you wish to have just a reconfiguable program or I/O, then
the only cost would be the serial interface program and its I/O pins.

I do not know for what purpose you wish to reprogram the PIC, but
the concept is interesting.  I have written a program for the IBM PC
that is a platform for testing methods of solving mazes.  The program
accepts commands such as "go right", "turn left", and "test foward".
The program returns a true if the command was excuited or a false if
there was an obstruction in the way.  I then added a celluar automata
routine with a eight by eight matrix program to run the maze.  This
became a self learning program for the "maze runner" and had good
results.  Could this "self learning" feature be implimented on a PIC?

Bill C.

1996\03\21@092850 by Norm Cramer

flavicon
face
{Quote hidden}

When I tried this, I had problems getting the circuit to program correctly.
I added a jumper that connects the Vdd of the chip to the rest of the
circuit.  When I need to program, I remove the jumper before attaching
the programmer.  This has worked so far.  I currently don't have anything
attached to the programming clock and data pins (RB6,RB7) in my circuit.  I do
have the diode from circuit Vdd to the MCLR pin to protect the rest of the
circuit while programming.  BTW I am using the ITU PIC-1 programmer but if
your programmer uses serial programming, the same should apply.

>
>>
>>How long can the programmer to '84 cable be in general?
>>I want to be able to use quite a long cable (1 meter), are there any things
>>I should be aware of?

The signal is serial but the voltage levels are not the same as
EIA-232 (AKA RS-232).  The main concerns I would have is voltage drop for
a 1m run and cross talk from the clock and data signals.  Cross talk can
be minimized by using sheilded twisted pair (STP) cable but you may not be
able to compensate for voltage drop.  Try it and see.

>>I was also wondering, has the picstart16b1 the ability to do in circuit
>>serial programming or do I need a special programmer?
>>If yes, what kits are out there with this ability? (commercial and diy)

Don't know if PICSTART can do serial programming but the PIC-1 from ITU can.
If you can wirewrap the programmer, buy the plans and software package only
since the circuit is quite simple.  I bought the full kit and am quite pleased
with it.  ITU even responded to my sugesstions to improve the kit.

>
>I recommend you start with the 16C84 in a bare socket (and the Vdd-Vpp
>resistor) and bring GND (5), Vdd (15), Vpp (4)  RB6 (13) and RB7(14) across
>to it. Get it working in the socket first to verify the use of the serial
>program method and correct wiring THEN transpose to you target. This way you
>can track where problem occur. Pin numbers in () are for the 16C84.
>

This is great advice.  When my first attempts to program in circuit failed,
I had to go back and take things off until I found the problem.  Would have
been much smarter to approach it this way.

BTW in circuit programming is the only way to go.  I can program the chip, test
it find my bugs and reprogram it in a few mins.


Hope this helps,

Norm
TakeThisOuTcramerRemoveMEspam@spam@dseg.ti.com

1996\03\21@094325 by Newfound Electronics

flavicon
face
>On Thu, 21 Mar 1996, Newfound Electronics wrote:
>
>> At no stage should there be Vpp applied without Vdd. It is the presence of
>> Vdd that stops Vpp appearing on the Vdd pin. I would be VERY concerned if
>> any programmer applied Vpp without Vdd.
>
>Hi Jim,
>
>I think we may be at cross purposes here. The original inquiry (as I
>understood it) was about a circuit that had Vpp hard-wired to Vdd,

Dermot,

Yes, that WAS the case but had been dealt with before we came to the diode V
resistor bit. It had to be otherwise ISP is not possible.

>presumably to hold MCLR* high in normal operation. Thus the Vpp voltage
>level would appear on the Vdd line. However even with a large value
>resistance between Vpp/MCLR* and Vdd, the programming voltage can still
>appear on Vdd.

I don't know what you mean Dermot. To my understanding we have a low
impedence source controling Vdd and a high impedence source from Vpp/MCLR.
The voltage difference is dropped across the resistor. What could I be
missing? At worst Vpp contributes a little extra current, Right??

{Quote hidden}

I guess it is a matter of choice and just as you are wary, I too, am wary of
the diode. For 16C84 systems I tend to leave it out.

In the case I am refering to, the victim subjected his PCBs to a finishing
proceedure. Before he discovered my programmer he use to program within the
programmer and tranfer the chips. When he got my programmer with the ISP
option he modified his circuit and added the diode (I told him to). When he
used the same finishing proceedure this is when the 16C84 scrambled. (And I
coped an ear full!)

He is now using just a resistor with no further problems.

So maybe under normal circumstances, the diode is ok. But in my view the
resistor is safe and eliminates the possibility.

BTW. The ESD problem with the 16C84 occurs because it requires so little
current to enter the program mode. It doesn't tend to happen on the EPROM
based PICs which require more oumph (did I spell that right?) on the Vpp pin.

>
Regards,

Jim

1996\03\21@095350 by Newfound Electronics

flavicon
face
>>Yes. The value can be 4K7-22K. 10K is good. Some people use a diode but a
>>resistor is better as it allow ESD to discharge. ESD on the Vpp pin CAN
>>scramble the memory!
>
>When I tried this, I had problems getting the circuit to program correctly.
>I added a jumper that connects the Vdd of the chip to the rest of the
>circuit.  When I need to program, I remove the jumper before attaching
>the programmer.  This has worked so far.  I currently don't have anything
>attached to the programming clock and data pins (RB6,RB7) in my circuit.  I do
>have the diode from circuit Vdd to the MCLR pin to protect the rest of the
>circuit while programming.  BTW I am using the ITU PIC-1 programmer but if
>your programmer uses serial programming, the same should apply.

Norm,

Have you tried reducing or eliminating the 100R resistor (R11 on my ITU
programmer) This might fix you problem and eliminate the need for the Vdd
jumper. This 100R resistor was discussed a month or two ago on the piclist.
>
>>>I was also wondering, has the picstart16b1 the ability to do in circuit
>>>serial programming or do I need a special programmer?
>>>If yes, what kits are out there with this ability? (commercial and diy)
>
>Don't know if PICSTART can do serial programming but the PIC-1 from ITU can.
>If you can wirewrap the programmer, buy the plans and software package only
>since the circuit is quite simple.  I bought the full kit and am quite pleased
>with it.  ITU even responded to my sugesstions to improve the kit.

Yes, the new PCB looks very impressive and the ITU programmer has been well
supported.

{Quote hidden}

Regards

Jim

1996\03\21@104345 by Norm Cramer

flavicon
face
>>
>>When I tried this, I had problems getting the circuit to program correctly.
>>I added a jumper that connects the Vdd of the chip to the rest of the
>>circuit.  When I need to program, I remove the jumper before attaching
>>the programmer.  This has worked so far.  I currently don't have anything
>>attached to the programming clock and data pins (RB6,RB7) in my circuit.  I do
>>have the diode from circuit Vdd to the MCLR pin to protect the rest of the
>>circuit while programming.  BTW I am using the ITU PIC-1 programmer but if
>>your programmer uses serial programming, the same should apply.
>
>Norm,
>
>Have you tried reducing or eliminating the 100R resistor (R11 on my ITU
>programmer) This might fix you problem and eliminate the need for the Vdd
>jumper. This 100R resistor was discussed a month or two ago on the piclist.

I'll check, I remember that I did not install one of the resistors but don't
remember wich one.  I'll see if it was R11.  Thanks for the tip.

Norm

1996\03\21@131856 by John Payson

flavicon
face
> >How long can the programmer to '84 cable be in general?
> >I want to be able to use quite a long cable (1 meter), are there any things
> >I should be aware of?
>
> I meter long cable probably won't cause to many problems but this is a
> matter I'm not expert on. There is nothing extra to consider just because
> you are actually programming a chip. The usual data comms considerations
> apply. I'm to uneducated to say much more.

The cable length is limitted primarily by:

[1] What speed do you send the data; the lower the speed the longer the cable
   can be.

[2] If you want to RUN the processor with the ISP cable hooked up [often very
   handy during development], what sort of protection is there on /MCLR to
   prevent spontaneous glitches?

1996\03\21@163553 by Don McKenzie

flavicon
face
On Thu, 21 Mar 1996, Dennis Velthuis wrote:

> Hello.
>
> First, I am terribly sorry of the rude accidental posting I did.
> I was NOT aware of the fact that a reply to a message on the piclist would
> arrive on the pic-list.
> Hereby I want to apologise myself to anyone I have offended by my 'junk' mail.
> Again, sorry. I wish I could turn back the clock.

I'm sure the list understands now what really took place Dennis. Yes put
it behind you. Take Andy's advice and ignore/delete all SPAMS and they will
stop.

{Quote hidden}

My 84 programmer uses a bulldozer approach for this task. It hardware
switches everthing. It may not suit your setup but the circuit can be
examined at http://www.labyrinth.net.au/~donmck
This may give you some ideas.

I have often thought of getting one of those cheap DB-25 two way switch
boxes and wiring it up as follows:

Connect an 18 pin socket to a DB-25 plug so it can accept the 84 device
and plug this into the common leg of the switch.
Crimp two flat ribbon cables with DIP headers one end and DB-25's the
other. One cable connects to your target, the other to your Picstart or
any programmer. You now have a load/run switch.

Cables, I keep them as short as possible. For me that means 6 inches.

Hope this helps Don...

Don McKenzie spamdonmck.....spamspamtbsa.com.au
DonTronics Tullamarine, Australia
http://www.labyrinth.net.au/~donmck

PIC Programmers starting at $15US, BS1/2 & Alternatives 18/28 PIC proto
PicoSaurus, the 40 pin ETI PIC Basic with 8K EEPROM Free Windows Dev Sys

1996\03\22@080500 by Derrick Early

flavicon
picon face
Dennis,

With a few well place diodes you should not have any trouble with
doing an in circuit programming.  You may want to make sure that
your oscillator is off while programming.  I had trouble with
it incrementing the program locations.  So instead of starting a
0x0000, the program would load randomly from 0x0001 to 0x0010.
Once I disabled the oscillator, everything worked great.  I think
that you should still be able to use your picstart.  If you can't,
you could always build David Taite's programmer.

Good luck.

Yours,
--
Derrick Early
earlyspam_OUTspam@spam@finite.nrl.navy.mil

1996\03\22@082618 by Dermot

flavicon
face
On Thu, 21 Mar 1996, Newfound Electronics wrote:

> I don't know what you mean Dermot. To my understanding we have a low
> impedence source controling Vdd and a high impedence source from Vpp/MCLR.
> The voltage difference is dropped across the resistor. What could I be
> missing? At worst Vpp contributes a little extra current, Right??

Hi Jim,

Yes, It's my logic that's a little fuzzy. I'm thinking in terms of the
circuit I'm currently working on where the programming voltage is derived
from a different source to the PIC Vdd supply line which itself contains a
blocking diode. Your description relates to the PIC deriving Vpp and Vdd
from the programmer, clearly a better arrangement.

I'll bear this, and the potential 16C84 ESD problem, in mind in any future
designs.

Regards,
_________________________________________________________________________
 __     __   ___             __   ____  <>  Electrical Engineering Dept.
/  \   /_   /__/  /\  /\    /  /   /    <>    University of Bradford
/___/  /__  /  \  /  \/  \  /__/   /     <>            England

'WTB serial ADC'
1996\03\25@092240 by Andy Errington

flavicon
face
Can anyone recommend a good cheap A/D chip for interfacing to a Stamp or
PIC?

What I am looking for is:

10bit resolution
serial data out
8 pin DIL package
0-2.5v or 0-5v analogue in range
Single rail supply (5v pref)
Cost less than 10GBP in one-off quantities

Fast conversion is not important, I am only interested in a value once per
second.

Andy
--
---------------------------------------------------------------------
Andrew M Errington                               Tel: +44 1524 593678
Microcomputer Consultant                         Fax: +44 1524 844011
The Computer Centre                  Mobile (Orange):     0976 243931
Lancaster University                      .....a.erringtonspamspam.....lancaster.ac.uk
Lancaster LA1 4YW     www.lancs.ac.uk/people/cpaame/cpaame.htm
---------------------------------------------------------------------
"A dog is not just for Christmas, there may be some left for
sandwiches on Boxing Day" - Vladimir Illich Ulyanov 1920
>

'serial ADC'
1996\03\25@144210 by nogueira

flavicon
face
Andy Errington wrote:
>
> Can anyone recommend a good cheap A/D chip for interfacing to a Stamp or
> PIC?

Try the Maxim MAX187/189, it's 12 bits 8 pins runs on 5V, it's serial and cheap,
you can find data sheet at Maxim's site http://www.maxim-ic.com

Octavio

nogueiraKILLspamspamEraseMEmandic.com.br

'WTB serial ADC'
1996\03\26@133603 by Scott Dattalo

face
flavicon
face
Andy Errington wrote:
>
> Can anyone recommend a good cheap A/D chip for interfacing to a Stamp or
> PIC?

Have you considered a voltage-to-frequency converter? National Semiconductor
makes an LM331 that satisfies:

>
> What I am looking for is:
>
> 10bit resolutionNo problem. In fact 14 bit resolution is easily achievable.

> serial data outA matter of interpretation. The "serial output" is a clock.

> 8 pin DIL packageYes

> 0-2.5v or 0-5v analogue in rangeNo problem, although you will need an external
analog switch to dynamically obtain
both ranges.

> Single rail supply (5v pref)Yes

> Cost less than 10GBP in one-off quantitiesDigikey lists it at ~8USD in one-of
quantities, but then the price drops in half in 25 piece
quantities.

> Fast conversion is not important, I am only interested in a value once per
second.Good, because the V/F converter is not fast.


Another good feature of V/F converters is that they inherently low pass filter
and can also
be designed to notch out certain frequencies (such as 50 or 60 Hz). In fact,
I've obtained
over 100dB of normal mode rejection at 60Hz!


Scott

1996\03\26@145442 by Scott Dattalo

face
flavicon
face
(I'm resending this to fix the formatting. There's no new info.)

Andy Errington wrote:
> Can anyone recommend a good cheap A/D chip for interfacing to a Stamp or
> PIC?

Have you considered a voltage-to-frequency converter? National Semiconductor
makes an LM331 that satisfies:

>
> What I am looking for is:
>
> 10bit resolutionNo problem. In fact 14 bit resolution is easily achievable.

> serial data outA matter of interpretation. The "serial output" is a clock.

> 8 pin DIL packageYes

> 0-2.5v or 0-5v analogue in rangeNo problem, although you will need an external
analog switch to dynamically obtain
both ranges.

> Single rail supply (5v pref)Yes

> Cost less than 10GBP in one-off quantities

Digikey lists it at ~8USD in one-of quantities, but then the price drops in half
in 25 piece
quantities.

> Fast conversion is not important, I am only interested in a value once per
second.Good, because the V/F converter is not fast.

Another good feature of V/F converters is that they inherently low pass filter
and can also
be designed to notch out certain frequencies (such as 50 or 60 Hz). In fact,
I've obtained
over 100dB of normal mode rejection at 60Hz!

Scott


'serial memory'
1996\04\15@232516 by Juan Abba
flavicon
face
For a new application under analysis, we will need about 2K of RAM  memory for
data arrays storage.

Serial memory could be a solution, as it appears that a 20MHZ 16C73 we are
planning to use will be  fast enough for the application, with spare time for
serial data handling.

Have searched the Microchip 1995/1996 data book, but have only found serial
EEPROM's.

Is there anybody  with experience on I2C type serial RAM, volatile equivalent to
the microchip I2C serial EEprom family????
Pls. provide details


juan

1996\04\16@001936 by Clyde Smith-Stubbs

flavicon
face
Juan Abba <EraseMEjuanabba@spam@spam@spam@AX.APC.ORG> wrote:

> Is there anybody  with experience on I2C type serial RAM, volatile equivalent
to
>  the microchip I2C serial EEprom family????

I don't have any experience with it, but Philips have a 256x8 I2C interfaced
RAM device. You can use 8 on the I2C bus (maybe more) which would give you
the 2K you need. The part no, is PCF8570 - you can get a data sheet from
http://www.semiconductors.philips.com/ps/acrobat/3041.pdf.


--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
@spam@clydespamspamKILLspamhitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email spamBeGoneinfoRemoveMEspamEraseMEhitech.com.au

1996\04\16@040025 by Chaipi Wijnbergen

flavicon
picon face
On Tue, 16 Apr 1996, Juan Abba wrote:

> For a new application under analysis, we will need about 2K of RAM  memory for
> data arrays storage.
>
> Serial memory could be a solution, as it appears that a 20MHZ 16C73 we are
> planning to use will be  fast enough for the application, with spare time for
> serial data handling.
>
> Have searched the Microchip 1995/1996 data book, but have only found serial
> EEPROM's.

I also looked at this and decided that it would be too slow and too
small, so I added an external SRAM 32K and wrote a small program that
will be able to read and write to it using some I/O bits.

chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : RemoveMEchaipiKILLspamspamRemoveMEtohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

1996\04\16@070308 by Byron A Jeff

face picon face
>
> On Tue, 16 Apr 1996, Juan Abba wrote:
>
> > For a new application under analysis, we will need about 2K of RAM  memory
for
> > data arrays storage.
> >
> > Serial memory could be a solution, as it appears that a 20MHZ 16C73 we are
> > planning to use will be  fast enough for the application, with spare time
for
> > serial data handling.
> >
> > Have searched the Microchip 1995/1996 data book, but have only found serial
> > EEPROM's.
>
> I also looked at this and decided that it would be too slow and too
> small, so I added an external SRAM 32K and wrote a small program that
> will be able to read and write to it using some I/O bits.

It not only takes a few I/O bits (11-12 at a minimum if you use external
latches and a decoder) but quite a lot of board real estate with the
extra chips offboard. It's a good solution if you need fast access and
a lot of memory and most importantly you can spare the board real-estate.

I've come across another possible solution: The Dallas SemiConductor RAMPort.
It's a 24 pin 600 mil 2K static ram specifically designed for attachment
to microcontrollers because it not only internalizes the previously mentioned
latches and decoder, but it also duplicates the 8 bit port you need to talk
to it. So instead of losing 10 I/O pins (8 data, 2 control) you actually only
lose the 2 control pins because the 8 data pins are duplicated by the part.

The parts use a 3 byte sequence to read and write so it's quite fast relative
to a serially accessed part.

The part numbers are DS1380 and DS1381. The 1381 has a built in lithium
battery for data retention while the 1380 has battery pins to attach an
external pattery. $9 and $11 in singles through the DalSemi extremely
experimenter friendly 1-800 line (factory direct, no minimum order,
credit card, fast delivery, what more can you ask for).

I plan to use the part in an upcoming project soon to be announced here.

Hope this helps,

BAJ

1996\04\16@141301 by mike

flavicon
picon face
In message <TakeThisOuT829627543.21060.0spamvms.dc.lsoft.com> spamBeGonePICLISTKILLspamspamTakeThisOuTMITVMA.MIT.EDU writes:
> For a new application under analysis, we will need about 2K of RAM  memory for
>  data arrays storage.
>
> Serial memory could be a solution, as it appears that a 20MHZ 16C73 we are
>  planning to use will be  fast enough for the application, with spare time for
>  serial data handling.
>
> Have searched the Microchip 1995/1996 data book, but have only found serial
>  EEPROM's.
>
> Is there anybody  with experience on I2C type serial RAM, volatile equivalent
to
>  the microchip I2C serial EEprom family????
> Pls. provide details
>
>
juan,

You could try a RAMTron serial FRAM. They behave like EEProms, but have *NO*
write delay and 10 billion (10^10) cycle read/write endurance figure.

The FM24C16 is a 2K by 8 device with I2C at 100kHz and 400kHz.

I've used them before with no problems.

The data book gives a 800 number: (800) 545-FRAM/DRAM.


Regards,

Mike Watson
--
Mayes uk

1996\04\17@082521 by Philippe TECHER

flavicon
face
Juan Abba <EraseMEjuanabba.....spamKILLspamAX.APC.ORG> wrote:
> Is there anybody  with experience on I2C type serial RAM, volatile equivalent
to
>  the microchip I2C serial EEprom family????

Hi,

Here is the code to drive an I2C RAM/EEPROM (PIC16C54..57), you can also
use 93C46( or 06 or ...) EEPROM type, but the protocol is different.
Be carrefull about timing, I2C application note said I2C Clock can run only
at 100KHz !

;*****************************************************************************
;**************  RAM / EEProm ACCESS ROUTINE on I2C Bus **********************
;   HCK = PortA.0
;   SDA = PortA.1   (In/Out)
;*****************************************************************************

I2C_Address    equ %10100000       ; ITEM address on I2C Line
                          ;---------------- REGISTERS
Address        equ $18     ; Address to Read/Write
DataHi         equ $19     ; Word DATA (16Bits)
DataLo         equ $1A

Data1          equ $10
Data2          equ $11

TempTxRx       equ $1B     ; Temporary register
I2CCnt         equ $1C     ; Counter to send/Receive bits

                          ;---------------- CONST
I2CSetOUT      equ %0000   ; Value to configure SDA as OUTPUT
I2CSetIN       equ %0010   ; Value to configure SDA as INPUT
I2CPort        equ 5       ; PORT A is I2CPort
HCK            equ 0       ; PortA.0
SDA            equ 1       ; PortA.1

I2CAckWait     equ 20      ; WAIT time to check ACKNOWLEDGE

I2CError       equ 1       ; return value if error
I2COk          equ 0       ; return value if OK


;******************************************************************************
;*****************************************************************************
; RAM / EEProm ACCESS ROUTINE on I2C Bus
;   HCK = PortA.0
;   SDA = PortA.1   (In/Out)

;*****************************************************************************
; WRITE WORD Data to I2C-RAM/EPROM
;    Address : Address of the 2 Byte to WRITE
;    DataHi  : Hi Data
;    DataLo  : Lo Data

I2CWriteData   call  I2CStart      ; START BIT

              movlw I2C_Address   ; Put SLAVE address on I2C line
              iorlw %00000000     ; To WRITE a DATA at ADDRESS
              movwf TempTXRX      ; TempTXRX = Address of I2C Item

              call  TxData        ; Transfert DATA on SDA Line
              call  AckWait0      ; Wait for Acknowledge
              btfss STATUS,2      ; Skip if Z=1
              goto  I2CStop

              movf  Address,W     ; Address to Access in W
              movwf TempTXRX      ; Address to Access in W

              call  TxData        ; Transfert DATA on SDA Line
              call  AckWait0      ; Wait for Acknowledge
              iorlw 0
              btfss STATUS,2      ; Skip if Z=1
              goto  I2CStop

              movf  Data1,W       ; DataLO to WRITE in W
              movwf TempTXRX

              call  TxData        ; Transfert DATA on SDA Line
              call  AckWait0      ; Wait for Acknowledge
              iorlw 0
              btfss STATUS,2      ; Skip if Z=1
              goto  I2CStop

              movf  Data2,W      ; DataHI to WRITE in W
              movwf TempTXRX

              call  TxData        ; Transfert DATA on SDA Line
              call  AckWait0      ; Wait for Acknowledge
              iorlw 0

              call  I2CStop       ; STOP BIT
              retlw I2COk

;*****************************************************************************
; Output TempTXRX on SDA Line

TXData         movlw I2CSetOut     ; Set SDA as OUTPUT
              tris  A
              bcf   I2CPort,SDA   ; SDA = 0
              movlw 8             ; I2CCnt = 8
              movwf I2CCnt

TXDataLoop     bcf   I2CPort,SDA   ; SDA = 0
              rlf   TempTXRX
              btfsc STATUS,CY     ; Skip if CARRY=0
              bsf   I2CPort,SDA
              bsf   I2CPort,HCK   ; HCK = 1
              nop
              nop
              nop
              nop
              bcf   I2CPort,HCK   ; HCK = 0
              decfsz I2CCnt
              goto  TXDataLoop
              nop
              nop
              retlw I2COk

;*****************************************************************************
; Read TempTXRX on SDA Line

RXData         movlw I2CSetIN      ; Set SDA as INPUT
              tris  A
              movlw 8             ; I2CCnt = 8
              movwf I2CCnt
              clrf  TempTXRX

RXDataLoop     bsf   I2CPort,HCK   ; HCK = 1
              bcf   STATUS,CY     ; CARRY = 0
              btfsc I2CPort,SDA   ; Skip if SDA=0
              bsf   STATUS,CY
              rlf   TempTXRX
              nop
              bcf   I2CPort,HCK   ; HCK = 0
              nop
              nop
              nop
              decfsz I2CCnt
              goto  RXDataLoop
              retlw I2COk

;*****************************************************************************
; Wait k Cycle for Acknowledge from slave

ACKWait0       movlw I2CSetIN
              tris  A
              bsf   I2CPort,HCK   ; HCK = 1

              movlw I2CAckWait    ; I2CCnt = I2CAckWait (Wait TIME)
              movf  I2CCnt

ACKLoop0       btfss I2CPort,SDA   ; Skip if SDA = 1
              goto  AckOk0
              decfsz I2CCnt
              goto  AckLoop0
              bcf   I2CPort,HCK   ; HCK = 0
              retlw I2CError

ACKOk0         bcf   I2CPort,HCK   ; HCK = 0
              retlw I2COk

;*****************************************************************************
; Wait k Cycle for Acknowledge from MASTER, if SDA line goes down then, an
; error occur (because SLAVE want to interrupt transmission)

ACKWait1       movlw I2CSetOut
              tris  A
              bcf   I2CPort,SDA   ; HCK = 0
              bsf   I2CPort,HCK   ; HCK = 1
              nop
              nop
              nop
              nop
              bcf   I2CPort,HCK   ; HCK = 0
              nop
              nop
              retlw I2COk

;*****************************************************************************

ACKWaitEnd     movlw I2CSetIN
              tris  A
              bsf   I2CPort,HCK   ; HCK = 1
              nop
              nop
              nop
              nop
              btfss I2CPort,SDA   ; Skip if SDA = 1
              goto  AckEr1
              bcf   I2CPort,HCK   ; HCK = 0
              retlw I2COk

ACKEr1         bcf   I2CPort,HCK   ; HCK = 0
              retlw I2CError

;*****************************************************************************
; OutPut the Start CONDITION

I2CStart       movlw I2CSetOut
              tris  A
              bsf   I2CPort,SDA   ; SDA = 1
              bsf   I2CPort,HCK   ; HCK = 1
              nop
              nop
              nop
              nop
              bcf   I2CPort,SDA   ; SDA = 0
              nop
              nop
              nop
              nop
              bcf   I2CPort,HCK   ; HCK = 0
              nop
              retlw 0

;*****************************************************************************
; OutPut the Stop CONDITION

I2CStop        movlw I2CSetOut     ; Set SDA as OUTPUT
              tris  A
              bcf   I2CPort,SDA   ; SDA = 0
              bsf   I2CPort,HCK   ; HCK = 1
              nop
              nop
              nop
              nop
              bsf   I2CPort,SDA   ; SDA = 1
              nop
              nop
              nop
              nop
              bcf   I2CPort,HCK   ; HCK = 0
              nop
              retlw I2CError      ; An ERROR is finishig by a STOP Condition

;*****************************************************************************
; END OF I2C CODE

'Serial protocols (was RS-422)'
1996\04\24@091017 by mfahrion

flavicon
face
> similar packet structure and using a polled approach. This means a desperate
> device has to wait till the host gets around to talking to it. I would be
> interested to hear a multi-master approach using a serial comms port too.

The SAEJ1708 spec "Serial Data Communications between microcomputer
systems in heavy duty vehicle applications" defines a simple
multi-master serial com protocol for use with RS-485-ish two wire (half
duplex) devices.  Basically all you need to do is bias/drive the
lines to prevent "unresolved contention" (if two drivers speak at the
same time a logic 0 always wins).  The rest of it is very
straightforward; check for idle lines before transmitting, monitor
your transmission for contention errors and if an error is detected,
retry after a prescribed time period (which is different for each
device).

Its a very straightforward protocol.  In their case they have put a
filter and some protection on the port itself making it a very robust
system, with the penalty of being reduced to 9600 baud and <1000
feet.  Those  mods aren't required to use their protocol however -
just the biasing technique.

I believe the spec is around $100 - contact me if I can be of any
help.

Good Luck
-mike

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Fahrion                spammfahrionspambb-elec.com      http://www.bb-elec.com/
B&B Electronics Mfg Co      ph.(815) 433-5100 ext.215    fax (815) 434-7094
707 Dayton Road                 PO Box 1040                  Ottawa IL 61350
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

'Serial Ram Chips?'
1996\04\30@210140 by Peter Homann

picon face
Hi,

Does anyone know if there are any large (> 2KBytes) ram chips that
are serial addressable. I've seen that there are quite a few
EERAM chips, and quite a few 256 Byte chips.

I have a data logging application that needs 8KB -32 KB of RAM.

Thanks,

Peter.
--
_______________________________________________________________________
Peter Homann   email: peterhSTOPspamspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925


'Serial Ram Chips?'
1996\05\01@105656 by Thomas Coonan
flavicon
face
>EERAM chips, and quite a few 256 Byte chips.
>
>I have a data logging application that needs 8KB -32 KB of RAM.
Dallas Semiconductor, of course, makes loads of NV-SRAM but mostly
parallel.  They also have the support chips which turn regular
SRAMs into NVs by inserting them in the Vcc pins.  They have a
serial 16-pin NV-Ram called "EconoRAM".  They have NV-RAMs that are
SIPs and stand up on end (if that helps).

XICOR makes a much smaller EEPROM which *also* has a shadow RAM
feature (you write to the SRAM and it automatically transfers
it to EEPROM on power down).

Phillips makes, for example, 256B I2C device PCF8570..

BENCHMARQ is another NV-RAM vendor.

I'd like to hear what you end of with.

Thomas.CoonanSTOPspamspamKILLspamSciatl.com

1996\05\01@133623 by Reginald Neale

flavicon
face
>Hi,
>
>Does anyone know if there are any large (> 2KBytes) ram chips that
>are serial addressable. I've seen that there are quite a few
>EERAM chips, and quite a few 256 Byte chips.
>
>I have a data logging application that needs 8KB -32 KB of RAM.
>
>Thanks,
>
>Peter.
>--
>_______________________________________________________________________
>Peter Homann   email: @spam@peterh.....spamspamadacel.com.au       Work : +61 3 9596-2991
>Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
>250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

Two companies who are currently advertising this kind of device:

EXEL at http://www.exel.com

XICOR at http://www.xicor.com

Reg

.....................Reg Neale.....................
"Ignorance is a renewable resource"   P.J. O'Rourke

1996\05\01@162503 by Michael S. Hagberg

flavicon
face
>Hi,
>
>Does anyone know if there are any large (> 2KBytes) ram chips that
>are serial addressable. I've seen that there are quite a few
>EERAM chips, and quite a few 256 Byte chips.
>
>I have a data logging application that needs 8KB -32 KB of RAM.
>
>Thanks,
>
>Peter.

Digi-Key (http://www.digikey.com) sells microchip and national serial eeproms
upto 16K bits (2K bytes). These devices are listed in the manufactures
data books as upto 64K bit versions.  Upto 8 devices can be daisy chained
on the same I/O.  Best of all they are 8 pin dip or surface mount.

download data specs from microchip.

michael

1996\05\01@175823 by Peter L. Taylor

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


> >Does anyone know if there are any large (> 2KBytes) ram chips that
> >are serial addressable. I've seen that there are quite a few
> >EERAM chips, and quite a few 256 Byte chips.
> >
> >I have a data logging application that needs 8KB -32 KB of RAM.
> >
> >Thanks,
> >
> >Peter.
>
> Digi-Key (http://www.digikey.com) sells microchip and national serial eeproms
upto 16K
> bits (2K bytes). These devices are listed in the manufactures data books
as
> upto 64K bit versions.  Upto 8 devices can be daisy chained on the same
I/O.
> Best of all they are 8 pin dip or surface mount.
>
> download data specs from microchip.
>
> michael
>

National Semiconductor makes a 4M/8M bit serial flash ram part.  The part
numbers are: NM29A040/080.  The data sheet is one their web page (www
.natsemi.com/), or I could e-mail it to anyone interested.  The parts come
in a 28 pin SOIC or PLCC.  Only 6 pins are used;  the die must be really big
.

The only gotchas of this part are: 1)It is National Microwire compatible,
which isn't necessarily Microchip SPI compatible, 2)Before using the part
you have to read the upper block to find any bad blocks that shouldn't be
used.

If anyone figures out how to use the Microchip SSP port, in SPI mode, with
this part, please let me know.  As far as I can figure, the only way to
interface to it is use three port lines, and bypass the SSP module.

Peter Taylor
TransEra Corp.

1996\05\01@181241 by Scott Dattalo

face
flavicon
face
Peter Homann wrote:

> I have a data logging application that needs 8KB -32 KB of RAM.
>

Peter,

Parallax has an app note that interfaces a PIC16C55 to a 1Mb X 1 Dynamic
Ram chip. You can get this app note (and all of the rest of their app
notes) via ftp:

ftp://ftp.parallaxinc.com/pub/acrobat/picapps.pdf

Their home page is at

http://www.parallaxinc.com/

This approach certainly meets your 32K X 8 = 256k bit memory requirements.
However, it sucks up 15 I/O pins in the process. (Actually, you could get
by with using only 12 in your application.) This is more than a serial
interface, but less than a standard parallel interface.

Scott

'Large Serial RAM solution...'
1996\05\16@230231 by Peter Homann

picon face
Hi,

I was browsing through a DALLAS Data book looking for a large serial
RAM solution, and have come accross this possible solution.

The DALLAS DS1280 is a 3-Wire to Bytewide Converter Chip. It allows
serial access up to 512KB of memory. It converts the serial data to
the standard JEDEC memory configuration, A0 - A18, D0 - D7, and
the usual control signals.

Online data sheets may be found at http://www.dallas.com, or if you don't
have WWW access like me a postscript file may be ftp'ed from

       matrix.dalsemi.com /pub/datasheets/1280.ps

I hope this is useful.

Peter.
--
_______________________________________________________________________
Peter Homann   email: spampeterh.....spam.....adacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\05\17@071520 by mike

flavicon
picon face
In message  <199605170218.AA05012.....spamitchy.adacel.com.au> KILLspamPICLISTspam_OUTspamMITVMA.MIT.EDU
writes:
> Hi,
>
> I was browsing through a DALLAS Data book looking for a large serial
> RAM solution, and have come accross this possible solution.
>
> The DALLAS DS1280 is a 3-Wire to Bytewide Converter Chip. It allows
> serial access up to 512KB of memory. It converts the serial data to
> the standard JEDEC memory configuration, A0 - A18, D0 - D7, and
> the usual control signals.
>
> Online data sheets may be found at http://www.dallas.com, or if you don't
> have WWW access like me a postscript file may be ftp'ed from
>
>         matrix.dalsemi.com /pub/datasheets/1280.ps
>
> I hope this is useful.
>
Peter,

Have you (or anyone else) got any PIC code to drive this chip?

If so, can you post or e-mail a copy.


Thanks,


Mike

'Analizing AN555..+ serial timeout'
1996\05\23@021022 by Edwin Baaij

flavicon
face
Hello,

Before modifying AN555, I'm trying to understand the source code. Much of it
I do understand but I'm puzzled by the following:

In the code for GetChar, _SbitDetected and RcvNectBit, I frequently find code
like;

 clrf  _rtcc
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option    ; assign Prescaler to TRM0

 bcf _rp0
 clrf  _rtcc
 bsf _rp0
 movlw 0Fh
 movwf _option    ; assign Prescaler to WDT

 clrwdt
 movlw _OPTION_SBIT
 movwf _option    ; assign Prescaler to TMR0?
 bcf _rp0
 movlw 0xFF
 movwf _rtcc      ; load rtcc with 0xFF


To me it looks like they're assigning the Prescaler back and fore between
TRM0 and WDT. And I can figure out why!
In the code for _RcvNextBit is't done 4 times!!!:

_RcvNextBit:
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option     ;WDT -> TMR0?

 bcf _rp0
 clrf  _rtcc
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option     ;WDT -> TMR0?

 bcf _rp0
 clrf  _rtcc
 bsf _rp0
 movlw 0Fh
 movwf _option     ; TMR0 -> WDT?

 clrwdt
 movlw (_OPTION_INIT | RtccPrescale) ;
 movwf _option       ; Final assignment?
;

Does anybody know what's done with this code? My purpose is to modify the
code in a way that i'm able to generate a timeout when it takes to long
before the next byte is received. A start bit now generated a rtcc
rollover-interrupt. My idea is to let this be done by the external interrupt
or the port-B change interrupt. It looks to me that than I have the timer
free to count for a timeout.

Is there somebody who has alredy made this kind of modification, and if yes,
willing to share the source??

Edwin
Edwin Baaij  (Electronic Engineer)
*********************************************************************
University of Amsterdam                 phone:  +31-20-5256346
Van der Waals,- ZeemanInstitute         fax:    +31-20-5255877
Valckenierstraat 65-67                  e-mail: spam_OUTbaaijspamTakeThisOuTphys.uva.nl
1018 XE Amsterdam
*********************************************************************

1996\05\29@020635 by Edwin Baaij

flavicon
face
Hello,

Before modifying AN555, I'm trying to understand the source code. Much of it
I do understand but I'm puzzled by the following:

In the code for GetChar, _SbitDetected and RcvNectBit, I frequently find code
like;

 clrf  _rtcc
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option    ; assign Prescaler to TRM0

 bcf _rp0
 clrf  _rtcc
 bsf _rp0
 movlw 0Fh
 movwf _option    ; assign Prescaler to WDT

 clrwdt
 movlw _OPTION_SBIT
 movwf _option    ; assign Prescaler to TMR0?
 bcf _rp0
 movlw 0xFF
 movwf _rtcc      ; load rtcc with 0xFF


To me it looks like they're assigning the Prescaler back and fore between
TRM0 and WDT. And I can't figure out why!
In the code for _RcvNextBit is't done 4 times!!!:

_RcvNextBit:
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option     ;WDT -> TMR0?

 bcf _rp0
 clrf  _rtcc
 clrwdt
 bsf _rp0
 movlw 07h
 movwf _option     ;WDT -> TMR0?

 bcf _rp0
 clrf  _rtcc
 bsf _rp0
 movlw 0Fh
 movwf _option     ; TMR0 -> WDT?

 clrwdt
 movlw (_OPTION_INIT | RtccPrescale) ;
 movwf _option       ; Final assignment?
;

Does anybody know what's done with this code? My purpose is to modify the
code in a way that i'm able to generate a timeout when it takes to long
before the next byte is received. A start bit now generated a rtcc
rollover-interrupt. My idea is to let this be done by the external interrupt
or the port-B change interrupt. It looks to me that than I have the timer
free to count for a timeout.

Is there somebody who has alredy made this kind of modification, and if yes,
willing to share the source??

Edwin
Edwin Baaij  (Electronic Engineer)
*********************************************************************
University of Amsterdam                 phone:  +31-20-5256346
Van der Waals,- ZeemanInstitute         fax:    +31-20-5255877
Valckenierstraat 65-67                  e-mail: .....baaij.....spamRemoveMEphys.uva.nl
1018 XE Amsterdam
*********************************************************************

1996\05\29@024446 by fastfwd

face
flavicon
face
Edwin Baaij <spam_OUTPICLISTTakeThisOuTspamEraseMEMITVMA.MIT.EDU> wrote:

> Before modifying AN555, I'm trying to understand the source code.
> Much of it I do understand but I'm puzzled by the following:
> ....
> To me it looks like they're assigning the Prescaler back and fore
> between TRM0 and WDT. And I can't figure out why! In the code for
> _RcvNextBit is't done 4 times!!!:
> ....
> Does anybody know what's done with this code?

Edwin:

I haven't looked at that code, but my guess is that they're switching
the TMR0 prescaler between divide-by-1 and divide-by-something-else;
the only way to achieve a TMR0 prescaler of divide-by-1 is to assign
the prescaler to the WDT.

Does this seem reasonable?

-Andy

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

'PIC'73 serial communication'
1996\05\29@125007 by K.Louison

flavicon
face
I'm using the PIC'73 for two-way serial communication.  I poll the
RCIF bit (PIR1 [5]) to detect when data has been received. I have
noticed that this bit sets of its own accord after the program has
run for some time (this occurs even in MPSIM) when no data has been
sent.  I have tried clearing the receive registers (RCREG) twice
during start-up initialisation  but this has no effect.
My serial communication registers are set as follows:
RCSTA - F0h
TXSTA - 66h
PIR1 - 10h
PIE1 - 00h
I suspect that I'm making some simple error but I can't think what.
Any ideas?


'Serial bulk erase program on '84'
1996\06\02@182705 by Martin Nilsson
picon face
Microchip Databook 95/96 (for the first time) says that the bulk erase
program command for the 16C84 can be given serially. I tried this with
several '84s in a serial programming circuit without any effect. The
other commands work fine, including programming. I use heavy bypass on
power. The most recent '84 I tried was 9601 CBW. Has anybody had a
similar problem? (Yes, I did check the code, and yes, I did give a begin
programming command after the bulk erase command :-)

-- Martin

Martin Nilsson                           http://www.sics.se/~mn/
Swedish Institute of Computer Science    E-mail: RemoveMEmnspamBeGonespamspamsics.se
Box 1263, S-164 28 Kista                 Fax: +46-8-751-7230
Sweden                                   Tel: +46-8-752-1574

1996\06\02@224004 by Newfound Electronics

flavicon
face
>Microchip Databook 95/96 (for the first time) says that the bulk erase
>program command for the 16C84 can be given serially. I tried this with
>several '84s in a serial programming circuit without any effect. The
>other commands work fine, including programming. I use heavy bypass on
>power. The most recent '84 I tried was 9601 CBW. Has anybody had a
>similar problem? (Yes, I did check the code, and yes, I did give a begin
>programming command after the bulk erase command :-)
>
> -- Martin
>
Martin,

Everyone else has had a similar problem. The bulk erase commands DON'T WORK!

I have discussed this matter with the well known programmer designers and
the only way to perform a bulk erase is to use the CODE PROTECT BIT erase
sequence. Before doing this to a load program data command and load 3FFFh
into the device. This is not in the data specs but is required.

The only person who has a bulk erase system for the seperate '84 memories is
Ken Pergola designer of the Micro Brisc programmer. How he does it I don't
know but he also says the specified commands do not work.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS

'16cxx serial port problems.'
1996\06\03@111727 by Chaipi Wijnbergen

flavicon
picon face
Hi,

About 6 weeks ago I posted a note on this list saying that the Israeli
rep for Microchip, warrned me againsed using BRGH high on the 16C74. and
that it would not be fixed in the upcommong 16C74A. I have not
expirienced any problems with it and I got evidence from others as well
that it is working fine, but 16C65 has the same UART, and some peaple do
have problems, so, do not use it.

Chaipi


> The number of significant defects in the PIC16C65 is an outrage.  I spent a
> great deal
> of time trying to debug some serial-comm code, only to discover that the SCI
> doesn't
> work dependably when the "BRGH" bit is set.  It was an insidious problem,
since
> only
> about 10% of my received packets were corrupted.
>
>
> -----------------------------------------
> Frank Latos, Duo Systems Inc.
> @spam@flatosspamspammich.com
> -----------------------------------------
>

'Serial Communications'
1996\06\06@110554 by Karl E. SCHERER

flavicon
face
Harrison Cooper wrote :
>Setpoints and storage - I need a simple RS232 type interface
>with a PC to send down the desired setpoint and to read back
>the two temperatures.

There are (many) helpful Application Notes, even with examples
at :

http://www.futureone.com/microchip/appnotes/appnotes.htm

For example :

PIC16Cxx Application Notes

- AN555 Software Implementation of Asynchronous Serial I/O

Ciao
KES

'Serial Port'
1996\06\06@161600 by Newson Edouard

flavicon
face
I am like to use one of Microchip microcontroller that has on board UART to
handle some serial communication.  However, I don't know which one to
get.

I don't want to use the 16C74 because is has a bad baudrate generator.

Any help is appreciated.


-Newson

1996\06\06@170313 by Todd Peterson

picon face
At 04:15 PM 6/6/96 -0400, you wrote:
>I am like to use one of Microchip microcontroller that has on board UART to
>handle some serial communication.  However, I don't know which one to
>get.
>
>I don't want to use the 16C74 because is has a bad baudrate generator.

This brings up an interesting point.  I have heard several (actually more
than several) complaints about hardware problems in the mid to upper level
PIC devices.  I even had someone tell me they were going to stop designing
with Microchip parts because of the hardware errors.

Now I know how easy it would be every time a program isn't operating
properly to blame the hardware, but I am getting the impression there are
actually a few problems other than the "baud rate generator=1" problem he
mentioned above.  Has anyone been keeping a list of the problems so we don't
all learn the hard way?  I know there have been revisions to some of the
chips (xxxA), but I understand even the revisions aren't quite perfect.

Can someone spread some light on the matter?  Hopefully I'm way off base here.

Todd Peterson
E-LAB Digital Engineering, Inc.

http://www.netins.net/showcase/elab

1996\06\06@170318 by Wireless Scientific

flavicon
face
At 4:15 PM 6/6/96, Newson Edouard wrote:
>I don't want to use the 16C74 because is has a bad baudrate generator.


Is this a well know fact? If so, it is documented?

Just curious because I've been using '73s.

craig

1996\06\06@173810 by John Payson

flavicon
face
{Quote hidden}

I suspect [beware: this is a WAG] that the problems with the PIC stem in
large measure from the fact that the higher-end devices evolved from an
architecture in which certain critical items were not issues.  For ex-
ample, the general design of the original PIC CPU would probably result in
a register read every instruction cycle whether it was called for in the
instruction or not.  Since register reads had no effect, this was not really
an issue.  Unfortunately, later PICs have registers which are affected by
reads; these registers can thus sometimes get hit unintentially.

Note as well that in the original PIC design, there were no asynchronous
events as far as the CPU was concerned.  Although the timer prescalar
could run asynchronously with the rest of the system, its output was run
through a simple synchronizer [i.e. a double-latch] before activating any-
thing the CPU controlled.  The effects on the CPU were thus easy to model
and understand.  In the newer PICs, however, there are more asynchronous
features and this in turn causes more risks of failure.

Without knowing the internal details of how Microchip's new designs are
implemented, it's hard to know what parts might cause marginal or wrong
behavior given unfortunate timings between events, but I would think the
best ways to avoid trouble would probably be to:

 [1] Run the UART shift clock synchronously with the instruction cycle.
     If finer control of the baud rate is desirable (which IMHO would be
     a great feature) it should IMHO be obtained by using a 4089-style
     circuit rather than merely dividing from a faster clock.  In fact,
     use of a 4089-style circuit would probably allow even a 4MHz PIC
     to operate its UART at _ANY_ speed up to 62Kbits/second within 1%,
     or a 20MHz PIC to operate at any speed up to 300Kbits/second.  If
     anyone wants details on how this would work, e-mail me.

 [2] If fast counters are going to run asynchronously, it might be useful
     to have them count graycode, then go through a latch, then through
     an XOR network [to convert the graycode to binary], then to the CPU.
     This should allow the CPU to read the counters at arbitrary times and
     get reliable results.

 [3] No port/register should be affected by both writing and reading.  If
     a read-only port has side-effects when it's read, that's no problem
     provided that the port is not affected by any asynchronous external
     events.

What do other people think of these design principles?

1996\06\06@191118 by Frank Latos

flavicon
face
Todd Peterson wrote:
>
> At 04:15 PM 6/6/96 -0400, you wrote:
> >I am like to use one of Microchip microcontroller that has on board UART to
> >handle some serial communication.  However, I don't know which one to
> >get.
> >
> >I don't want to use the 16C74 because is has a bad baudrate generator.
>
> This brings up an interesting point.  I have heard several (actually more
> than several) complaints about hardware problems in the mid to upper level
> PIC devices.  I even had someone tell me they were going to stop designing
> with Microchip parts because of the hardware errors.
>
> Now I know how easy it would be every time a program isn't operating
> properly to blame the hardware, but I am getting the impression there are
> actually a few problems other than the "baud rate generator=1" problem he
> mentioned above.  Has anyone been keeping a list of the problems so we don't
> all learn the hard way?  I know there have been revisions to some of the
> chips (xxxA), but I understand even the revisions aren't quite perfect.

Well, the errata sheet for the 16C65 (available on the Microchip web site) seems
to be accurate and complete.  At least I haven't encountered any problem not
described in this document, and I've just about completed my first C65 project.

The thought of abandoning Microchip parts for future designs occurred to me
more than once as I read over the errata.  The thought of releasing a chip
design
with so many flaws in really rudimentary peripherals leads me to question the
basic competence of the people responsible.

And to top it off, the final item on the errata:
"In a device brown-out, some peripheral modules may be disabled ... only a
Power-on
Reset will re-enable them (MCLR will not)."

-----------------------------------------
Frank Latos, Duo Systems Inc.
TakeThisOuTflatosKILLspamspam@spam@mich.com
-----------------------------------------

'Silicon Bugs (was: "Re: Serial Port")'
1996\06\06@192604 by fastfwd

face
flavicon
face
Todd Peterson <.....PICLISTRemoveMEspamMITVMA.MIT.EDU> wrote:

> I am getting the impression there are actually a few problems [with
> the midrange PICs] other than the "baud rate generator=1" problem
> he mentioned above.  Has anyone been keeping a list of the problems
> so we don't all learn the hard way?

Yes, Todd... Microchip keeps a list and distributes it in the form of
"errata" sheets.  They're available from your Microchip rep; my rep,
in fact, telephones me whenever a new one comes out.

-Andy

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

1996\06\06@194511 by Brian Boles

flavicon
face
    The eratta are on the BBS and the WWW site also.  We aren't proud of
    it, but we won't hide it from our customers either!  (unlike some
    other micro folks)

    Rgds, Brian.


______________________________ Forward Header __________________________________
Subject: Silicon Bugs (was: "Re: Serial Port")
Author:  Andrew Warren <TakeThisOuTfastfwdspamspam_OUTIX.NETCOM.COM> at Internet_Exchange
Date:    6/6/96 4:29 PM


Todd Peterson <RemoveMEPICLISTspamspamSTOPspamMITVMA.MIT.EDU> wrote:

> I am getting the impression there are actually a few problems [with
> the midrange PICs] other than the "baud rate generator=1" problem
> he mentioned above.  Has anyone been keeping a list of the problems
> so we don't all learn the hard way?

Yes, Todd... Microchip keeps a list and distributes it in the form of
"errata" sheets.  They're available from your Microchip rep; my rep,
in fact, telephones me whenever a new one comes out.

-Andy

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

1996\06\06@212910 by Juan Abba

flavicon
face
Brian, I want to retrieve the eratta for the 16C74, 16C74 and 16C65.

which  files should I look for at the WWW  ??????
thanks
juan

At 16:43 06/06/96 -0700, you wrote:
>     The eratta are on the BBS and the WWW site also.  We aren't proud of
>     it, but we won't hide it from our customers either!  (unlike some
>     other micro folks)
>
>     Rgds, Brian.
>
>
>______________________________ Forward Header
__________________________________
{Quote hidden}

1996\06\07@013908 by John Payson

flavicon
face
> Brian, I want to retrieve the eratta for the 16C74, 16C74 and 16C65.
>
> which  files should I look for at the WWW  ??????

They're under tech support.  Since the files take awhile to download via
modem if you don't have a direct net connection, I'll summarize (this
summary is not complete, but indicates the ones I remember).  First,
though, an editorial....



Some people, here and elsewhere, have sharply criticized Microchip for
releasing chips with "so many" bugs.  Despite my like for the PIC, I
am inclined, depressedly, to agree with them that many of the high-end
PICs' peripherals are rendered largely useless by these bugs.

HOWEVER, despite the problems in the high-end chips I STILL intend to
support MicroChip to the extent I can.  Despite the failings of the
PICs in the more "upscale" applications, the lower models such as the
16C5x or 16C62x are IMHO some of the best "little" micros there are:
cheap, fast, and great to program.  Further, the PIC family is the ONLY
family of micros I know of where someone can buy an under-$10 micro from
Digi-Key, $10 or so in stuff from Radio Shack, and grab some free info
off the web, and have an in-circuit development system.

In addition, despite their shortcomings, Microchip has been reasonably
forward about their chips' problems.  Perhaps this was their long-standing
intent; perhaps they're merely trying to avoid a "Pentium" fiasco.  I
personally don't really care which--I just want them to survive and keep
producing great little micros [though a 28-pin EEPROM part would be nice]...


In closing, I would just like to offer my moral support to the folks at
Microchip who are probably sweating nervously as to how the market will
react to their "buggy" chips.  It is only through their hard work and
effort that such wonderful chips as the 16C84 are available, and I hope
in future even more wonderful things will spring forth.  If there is
anything I can do to help anyone at Microchip in their efforts to produce
better (hopefully bug-free) chips I would be happy to do what I can, and
I invite anyone at Microchip to write me personally (if needed, I'll sign
a reasonable non-disclosure agreement).

    -- John




Anyway, here's what I remember offhand of the errata I've looked at.  This
is not an exhaustive list, and my description of II is unlike any in the
errata but I think it describes the actual mechanics of the related prob-
lems.  So here goes...



I. Serial Hardware Bugs

 [A] UARTs will not receive reliably if BRGH is set for high baud rates.

 [B] SPI mode has clocking problems

 [C] I2C mode has problems in master mode [for I2C mastering, it's often
   easier to ignore the I2C hardware].

 [D] Suspected problem [not listed in errata, nor tested]: Writing a byte
     to the outgoing serial buffer will clear any incoming byte that
     happens to be there.  [If this is not the case, it would see M'chip
     added some logic to the CPU core to prevent read-before-write on
     MOVWF.]

II. CPU Core Limitation/Quirk

 [A] On 16Cxx, all instructions other than xxxLW will perform a read of
     the address specified in the lower seven address bits.  [On the
     16C5x, the lower 5 bits, but no registers are affected by reads so
     this is a non-issue].

   - On all 16Cxx except the 5x parts, this affects MOVWF (does a read
     before write), and depending upon where FSR is pointing, may also
     affect NOP and the canonical form of CLRW (with an address of 0).
     If one is courageous, one might be able to specify an address in
     CLRW to simultaneously perform the read and clear W; this is most
     likely not useful.

   - On the 16C64, 16C74, and other parts with a parallel slave-port,
     the LSB's of the RETURN instruction will cause the port to be read,
     potentially causing a host CPU store there to be misregistered.  A
     possible workaround would be to use a different opcode for RETURN,
     but I don't know if the hardware would accept any others.

III. Power/crosstalk problems

 [A] Some PICs will not power-up reliably without an externally-imposed
     reset [/MClr].

 [B] Some PICs will not reliably assert the PO flag on power-up and this
     flag should not be used for power-on detection.

 [C] On the 16C71, the CPU oscillator can cause crosstalk with the ADC
     input right next to it.  In addition, use of an external RC main
     oscillator may cause the internal RC for the ADC to fail if it is
     used.  Both of these problems may be somewhat mitigated by using
     the CPU clock as the ADC source.

 [D] On parts with an "external" crystal oscillator option (e.g. to use
     a watch crystal for a timebase and something else for the main CPU
     clock) this oscillator may pick of crosstalk from the main oscillator
     if both are used simultaneously, and use of this other oscillator may
     cause increased power draw as its digital input function is not dis-
     abled by use as an oscillator.

 [E] Some chips will behave badly in case of brownout and will have to
     be power-cycled to recover.

IV. Other miscellaneous

 [A] On the 16C74, the ADC may be inaccurate for measuring voltages over
     3 volts.

 [B] On some parts with extra timers, these timers will malfunction in
     certain modes (see errata for more details).

 [C] On the PIC16C84, it is possible to unblow the security fuse and read
     out the chip contents.  This is not believed possible on the other
     chips.

 [D] On many of the newer ceramic chips, there is no way to unblow the
     security fuse--even UV erasure won't help.  This is mentioned in the
     data sheets, but should be repeated.

V. Documentation notes:

 [A] The pinouts for the 28-pin surface mount parts are documented in-
     correctly.  See Errata for correct pinouts.

 [B] On the 16C62x, the PORTB inputs operate as "normal" PIC inputs; only
     the PORTA inputs operate as schmidt triggers.

 [C] For some devices, the exact AC/DC tested parameters don't match the
     data sheets.

'Serial Port'
1996\06\07@040203 by Chaipi Wijnbergen

flavicon
picon face
On Thu, 6 Jun 1996, Newson Edouard wrote:

> I am like to use one of Microchip microcontroller that has on board UART to
> handle some serial communication.  However, I don't know which one to
> get.
>
> I don't want to use the 16C74 because is has a bad baudrate generator.

I use the 16C74 with great success, as long as you set BRGH low, then you
have a fantastic URAT. this should not be a factor when choosing which
part to use.

Chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : spamchaipi@spam@spamSTOPspamtohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

'Serial handshaking'
1996\06\07@043602 by Ronald Leenes

flavicon
face
Hi,

I'm working on a serial to centronics converter using a 16C84 and a
Max232. Handshaking is implemented using the CTS line (may be the RTS
line, I write this at my office, the diagram is at home). The Pic tells
the computer (a Mac in my case) not to send any data when it has things
to do, or when the printer is off-line.
The code I wrote for the Pic does work. If I use a communications
program, all letters types in are printed neatly. If I send data at a
higher rate, things go wrong. Some characters are missing. This in effect
means that handshaking does not work correctly, I think.
CTS goes low alright, and on static tests, the Mac stops moving data when
CTS goes low. STill the actual system does not dunction correctly.

When do I drop CTS? At the end of a byte, during receival of a byte or
what?
I realy don't see what goes wrong. The code to print the received
character is something like 15 cycles max. The rest of the time the Pic
listens to the serial port. Why does it miss chraracters, even if
handshaking does not work?

Can anyone shed some light on this?



Ronald Leenes                                       phone: +31 53 489 42
31
University of Twente                                  fax: +31 53 489 22
55
Dept of Public Administration and Public Policy
spamBeGoner.e.leenesspamBeGonespam@spam@bsk.utwente.nl

P.O. Box 217, 7500 AE Enschede, the Netherlands

'Linux driver for serial port programmer'
1996\06\25@095345 by Ralph Metzler

flavicon
face
Hi,

I made a beta version of a Linux driver for the simple PIC16C84 serial
port programmer available at:

http://www.thp.uni-koeln.de/~rjkm/linux/serp.cc

compile with: g++ -O2 -o serp serp.cc

syntax: serp [-h] [-e] [-p port] prog.hex

-h       toggles between the different hex file types
-e       erases the PIC first
-p port  sets the port address to port

It expects data EEPROM data at 0x2100-0x213f
No fuse support or documentation (besides this mail) yet ...

Ralph

------------------------------------------------------------
Ralph Metzler                          RemoveMErjkmRemoveMEspamRemoveMEthp.uni-koeln.de
Institute for Theoretical Physics
Cologne, Germany
============================================================

'16c84 for serial coms using an555 or similar.'
1996\06\27@180507 by David S. Ebsen

flavicon
face
Hi,
    I'm working on a project using a 16c84-10 for serial (rs-232) interface.
I'm trying to use AN-555 as a shell but am not having much luck.  The main
problem I'm running into is that the code was written for a 16c71 using rtcc,
which the 84 apparently doesn't have.  Does anybody know a good method for
using the 84 for this or a similar application?  Or has anybody converted this
application note for use on a 84?  I'm shooting for 96, n, 1, with handshake.
At this point I can use any four I\O pins.  Any help will be appreciated as I
am somewhat pressed for time.
                                                                 Thanks in
advance,
                                                                   Dave

1996\06\27@190640 by Brian Read

flavicon
face
Dave:

rtcc is what MC used to call TMR0. Both the '71 and the '84
have TMR0 and you should have no problems in the code conversion
(there ain't none required) going from a '71 to a '84 as long as
you are not using the A/D part of the code (:-)

Brian

1996\06\27@220550 by Byron A Jeff

flavicon
picon face
>
> Hi,
>      I'm working on a project using a 16c84-10 for serial (rs-232) interface.
>  I'm trying to use AN-555 as a shell but am not having much luck.  The main
>  problem I'm running into is that the code was written for a 16c71 using rtcc,
>  which the 84 apparently doesn't have.

Microchip changed terminology a couple of years ago. RTCC is now TMR0 on all
products. AN555 was written before the change and hasn't been updated. Of
course both the 16c84 and the 16c71 have TMR0.

>  Does anybody know a good method for
>  using the 84 for this or a similar application?
>  Or has anybody converted this  application note for use on a 84?
>I'm shooting for 96, n, 1, with handshake.

9600? right? Should be no problem. One of my students had 16C84's talking
fine at 19200 BPS using TMR0 for delays. The one thing we figured out is
that it worked best if TMR0 is just allowed to free run especially at
the higher baud rates. Resetting the timer introduces jitter.

>  At this point I can use any four I\O pins.  Any help will be appreciated as I
>  am somewhat pressed for time.

Good luck,

BAJ

1996\06\27@230924 by John Payson

flavicon
face
>
> >
> > Hi,
> >      I'm working on a project using a 16c84-10 for serial (rs-232)
interface.
> >  I'm trying to use AN-555 as a shell but am not having much luck.  The main
> >  problem I'm running into is that the code was written for a 16c71 using
rtcc,
{Quote hidden}

'#2 16c84 for serial coms/an555'
1996\06\28@165129 by David S. Ebsen

flavicon
face
OK, so the tmr0 and rtcc are one of the same address. This still doesn't solve
my problem.  I got rid of all the A/D code and instead made the 84 output a
constant to my  PC but the program isn't even get that far.  On start up all of
portb is high (incl. inputs)  and my PC gives me a serial port fail message
even if I clear port b on start up and set RTS/CTS = FALSE.  I tried a new pic
with no luck.  I'm using a MAX-232a setup with a db-9 using cts, rts, tx,  rx,
and ground , pins 8, 7, 3, 2, 5 (db-9) respectively.  Does anybody have any
sugestions?  Or if someone would be so kind as to share some known working code
with me so i can figure out what I'm doing wrong, that would be great.

Thanks, Dave


'In Circuit Serial Programming with serial Programm'
1996\07\05@085034 by Gerrit Gehnen
flavicon
face
Hello friends,

currently i'm entering the wonderful world of PIC. For the beginning,
i just want to start with a simple '84 programmer and a proto-board.
Now ZIF sockets for 18 pins are very difficult to get and they are very
expensive. So i want to use a in circuit programmer using the serial
mode. From the archive i got some advices, to disable the oscillator (in
my case a 4Mhz crystal) and to set a resitor between Vdd and Vpp.

Now to the difficult part: To aviod an additional power supply i want to
use the design of a RS232-attached programmer. Has someone experience
with this design and in circuit programming?

Thanks in advance.

 Gerrit

--
Dipl.-Ing. Gerrit Gehnen
gehnenKILLspamspamspamhni.uni-paderborn.de
Heinz Nixdorf Institut
Rechnerintegrierte Produktion
Uni-GH Paderborn
Tel. +49/5251/60-6262 Fax. +49/5251/60-6268       ...und das war's auch
schon

1996\07\08@012029 by Newfound Electronics

flavicon
face
>Hello friends,
>
>currently i'm entering the wonderful world of PIC. For the beginning,
>i just want to start with a simple '84 programmer and a proto-board.
>Now ZIF sockets for 18 pins are very difficult to get and they are very
>expensive. So i want to use a in circuit programmer using the serial
>mode. From the archive i got some advices, to disable the oscillator (in
>my case a 4Mhz crystal) and to set a resitor between Vdd and Vpp.

Gerrit,

I beleive I was the person responsible for both the above recommendations.
You only need to "kill" the oscillator if there is a big >10mS delay from
the time Vdd rises to the time Vpp rises. The resistor between Vpp and Vdd
instead of a diode is only to allow for ESD that can (and has) built up on
the Vpp pin and caused the chip to scramble the EEPROM. Most people still
use the diode with good results. ESD is not allows big problem but if you
process the PCB further with spray-on lacquers and stuff, this is when
problems occur.


>
>Now to the difficult part: To aviod an additional power supply i want to
>use the design of a RS232-attached programmer. Has someone experience
>with this design and in circuit programming?

Hmmm. I have never seen a design where doing this has resulted in the 84
being programmed within the specs. No one I know of has shown how to get
both the Vpp voltage (13V) and the Vdd current (50mA) for the serial port at
the same time. Still, these programmers supposedly work even way out of
spec. But this is one thing I wont recommend.

Jim

P.S have a look at TELtronik. I thing they have a low cost '84 programmer.

http:/http://www.hway.net/teltro/tel_home

'Linux serial port programmer'
1996\07\08@052456 by Ralph Metzler

flavicon
face
Hi,

since last week the latest version (0.2) of a serial port programmer driver
for Linux is available at:

http://www.thp.uni-koeln.de/~rjkm/linux/serp.cc

Reading and fuse programming support has been added since the first release.
There is also some experimental code for the 24C65 EEPROM but for me only
reading works. For writing the voltage levels are probably too much off the
specs!?

Because many people accessed the file on our web server I would really
be interested if it works for anyone.
If I created network traffic for something that only works on my hardware,
please tell me!

Ralph

'In Circuit Serial Programming with serial Programm'
1996\07\08@055847 by Alexej Vladimirov

flavicon
face
Hello Gerrit!

08 Jul 96, Gerrit Gehnen <spam_OUTgehnen@spam@spamHNI.UNI-PADERBORN.DE> writes to all:

P> Now to the difficult part: To aviod an additional power supply i want
P> to use the design of a RS232-attached programmer. Has someone
P> experience with this design and in circuit programming?

Try to look at http://www.ormix.riga.lv/eng/mchip/c1.htm

This is RS232-attached programmer without additional power supply, program
all serial PIC's and I2C NVRAM's (16C6X/7X/8X/14XXX/24CXX) and have
in-circuit programming capability.

Alexej Vladimirov  TakeThisOuTavladspam_OUTspammail.ormix.riga.lv

--- GoldED/2 2.50+

'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: KILLspamK.Parkyn.....spamTakeThisOuTsct.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 spam_OUTdonmckRemoveMEspam.....labyrinth.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.

'Simple Transmit/Receive Serial Routines Needed For'
1996\07\31@110214 by Matt Boothe

picon face
If anyone has any serial routines to transmit and receive characters using
the 16c73's UART, and would be willing to mail them to me I would be most
grateful.  I have had limited success writing these routines myself even
though it seems like it should be straightforward.

By the way, I am aware of the BRGH=1 problem, and am using BRGH=0.  My problem
mainly concerns the ReceiveChar routine.  It works fine for the first
character in, but doesn't want to receive any more characters.

I was able to make the TransmitChar routine work, but I have a feeling that
my solution is less tham optimal.  Anyway, thanks for any help.

----------------------------------------------------------------
Matt Boothe <spammbootheKILLspamspamKILLspamvt.edu>    Blacksburg, Virginia, Earth
(540) 951-0952

Language is a very difficult thing to put into words.
                           -- Voltaire


'Serial Video Display Module'
1996\08\19@173957 by thoffman
picon face
I'm working on an automotive project and I have need of a simple way
to output video to a normal NTSC monitor. I've looked at a bunch of
solutions and I think I found one that will work. When I researched
this problem it came to me that maybe other people could use a self
contained module to do the same thing. Remember that none of this is
set in concrete and the features listed are only the one's I need.
Your needs may be different (if so tell me)...

Here's what I came up with; see if it could be useful and send me a
note:

- Easy to use 3-wire (Enable, SerialData, Clock) serial interface
- Software selected NTSC or PAL Video
- Composite and Y/C (S-Video) Outputs
- Extensive Command Set (23 commands)
- Flexible Character Sizing: Up to 12 lines and 12 to 36 columns
- 256 predefined characters
- Each character is defined in a 12x18 dot matrix
- 16 Colors for Foreground or Screen Background
- Flashing text on a character-by-character basis
- 6 different software selected flash rates
- Small board size: 3" x 4.5"
- 10-pin header connector for communications
- Cursor Control
- Power Saving Sleep Mode
- Other display features similar to text LCD modules

I'm not sure about pricing yet, but I'm fairly sure it won't be over
$100. If there is enough interest I may be able to have a few ready by
the beginning of next year. More info is available on a web page I put
together. Please check out the page and give me some feedback. I want
to be sure to include as many important features as possible:

http:http://www.flash.net/~thoffman/video.html

Thanks!

1996\08\20@045734 by Andy Errington

flavicon
face
Hi,

I saw the two words 'automotive' and 'video', and I have to comment that
in the UK it is illegal to have a video display in view of the driver of
a car.  I am unsure of the scope of this law (or if it has now been
dropped), since recently BMW were selling a top of the range model which
had a TV incorporated in the dash.  I wonder if the law prohibits
specifically a CRT, and you get round it by using an LCD.

>I'm working on an automotive project and I have need of a simple way
>to output video to a normal NTSC monitor. I've looked at a bunch of
>solutions and I think I found one that will work. When I researched
>this problem it came to me that maybe other people could use a self
>contained module to do the same thing. Remember that none of this is
>set in concrete and the features listed are only the one's I need.

Why not use a Teletext style video generator.  It is all
character-based, and gives you 40x24 characters (in the UK with PAL), 8
colours, flash mode and graphics (where each character is a 3x2 pixel
block).  A chip that does this was used in the BBC Micro (from Acorn
Computers), and I think the part number began 'SAA' (I am sure someone
has a BBC handbook just to hand.  I seem to have omitted to bring mine).

Anyway this is my opinion.  You are welcome to it...    =:^)

Andy (the other one)

1996\08\20@052509 by Clyde Smith-Stubbs

flavicon
face
Andy Errington <spama.erringtonspam_OUTspamLANCASTER.AC.UK>

> I saw the two words 'automotive' and 'video', and I have to comment that
> in the UK it is illegal to have a video display in view of the driver of
> a car.

Curious. In Australia most taxis now have a display mounted above the instrument
panel which gives them information about what jobs are on offer, special
messages
etc. Many other delivery vehicles have similar systems - all mounted in view
of the driver. I don't believe any of them are CRT based, but some of them
are quite large flat display panels much like an LCD TV set.

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
STOPspamclydespam_OUTspamspamBeGonehitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
---------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email spam_OUTinfospamspamBeGonehitech.com.au

1996\08\20@055133 by David Tock

flavicon
face
Andy Errington wrote:
>
> Hi,
>
> I saw the two words 'automotive' and 'video', and I have to comment that
> in the UK it is illegal to have a video display in view of the driver of
> a car.  I am unsure of the scope of this law (or if it has now been
> dropped), since recently BMW were selling a top of the range model which
> had a TV incorporated in the dash.  I wonder if the law prohibits
> specifically a CRT, and you get round it by using an LCD.
>

AFAIK, the law is still in place. BMW are careful to switch the TV off
when the ignition is on. It is a couple of years since I was working in this
area, but the companies I was working with had letters of exemption  allowing
them to use LCD and CRT displays (for navigation aids and vision enhancement
aids using head up displays).

Incidentally, it is not just direct sight of the display that counts. The
driver must not be able to see any relections of it either...

1996\08\20@061830 by David Knell

flavicon
face
{Quote hidden}

It's the SAA5050.  There's others which are more integrated - the
SAA5050 requires you to feed it data at the right rate; I wrote a
driver once for a teletext display generator which consisted of
an 8K SRAM and one other chip which addressed the SRAM, generated
RGB & sync and had an I2C bus for communication.  I'd guess it
would be found in the appropriate Philips databook, which I don't
have to hand.  I do have my BBC service manual, though :-)

Dave

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

1996\08\20@064607 by clint

flavicon
picon face
In your message dated Tuesday 20, August 1996 you wrote :
> Hi,
>
> I saw the two words 'automotive' and 'video', and I have to comment that
> in the UK it is illegal to have a video display in view of the driver of
> a car.  I am unsure of the scope of this law (or if it has now been
> dropped), since recently BMW were selling a top of the range model which
> had a TV incorporated in the dash.  I wonder if the law prohibits
> specifically a CRT, and you get round it by using an LCD.
The law states that it is illegal to have a video display, sure, but if the
video display is relaying information about the vehicle (speed etc.) it's ok.
I believe Aston Martin use CRTs to provide this kind of info on some models (or
at least it's an option). A video display with TV etc. is prohibited for obvious
reasons and I think the BMW gets around it by disabling the display whilst in
motion.
> Why not use a Teletext style video generator.  It is all
> character-based, and gives you 40x24 characters (in the UK with PAL), 8
How about the 6845 CGA (?) VDU Controller, should be loads of them about and
still fairly easy to use?
> Anyway this is my opinion.  You are welcome to it...    =:^)
>
> Andy (the other one)
>

--
If you have a problem with excess cash, mail all those
unwanted notes in plain packing to;
                      EraseMEclintRemoveMEspamclintsmc.demon.co.uk

1996\08\20@214714 by Robert Lunn

flavicon
face
At 07:24 PM 20/08/96 +1000, you wrote:

>Andy Errington <.....a.erringtonspamspam_OUTLANCASTER.AC.UK>
>
>> I saw the two words 'automotive' and 'video', and I have to comment that
>> in the UK it is illegal to have a video display in view of the driver of
>> a car.
>
>Curious. In Australia most taxis now have a display mounted above the
instrument
>panel which gives them information about what jobs are on offer, special
> messages, etc.

       And of course many large trucks, buses, semis, etc. have a small TV
       mounted on the dash that provides a view to the driver from the rear
       of the vehicle (for safe reversing).

___Bob

1996\08\21@051157 by Eric Smith

flavicon
face
> How about the 6845 CGA (?) VDU Controller, should be loads of them about and
> still fairly easy to use?

Here's why not to use the 6845, according to Steve Jobs in the article
"An Interview: The Macintosh Design Team" in the February 1984 issue of Byte
magazine:

Steve Jobs:  Do you realize that in an IBM PC the video board, just the
   black-and-white video plug-in card, has got way more chips than the entire
   Macintosh?"
[...]
Steve Jobs:  I just thought I'd show this to you.  This is the IBM video
   board; it's only video, nothing else.  It's 69 integrated circuits, more
   chips than an entire Macintosh, and it basically does nothing.  And it
   doesn't even do that very well.
Chris Espinosa:  Fourty percent more chips than the Mac.
Steve Jobs:  So that sort of gives you a feeling.  And again, this just has
   the video on it.  Macintosh, in addition to having video that's far
   higher in resolution and far faster, [...]
[...]
Steve Jobs:  If you bite into that IBM display board, it'll totally flicker
   if you do it at the wrong time.

He was referring to the IBM Monochrome Display Adapter (MDA).  And although
he mentions the low resolution and fliker, he left out an even more scathing
criticism of the MDA card:  It couldn't do bit-mapped graphics at all!  For
years video cards for PC clones have used high-integration ASICs (which usually
contain a functional equivalent of a 6845).

The 6845 was useful in the late 70s and early 80s, and could replace a fair
number of TTL MSI chips, but it isn't a very good choice for new designs today
because you still have to add a bunch of additional chips to make it do
anything useful, and because it is an NMOS chip and draws quite a bit of power
by today's standards.

The 6845 might be useful if you want to build a one-of-a-kind device (and thus
can't engineer something more modern), but the original poster was hoping to
find something highly integrated, small, cheap, and with a simple bit-serial
interface.

The TI TMS9118 and TMS9918 families provided a much higher integration
solution, and saw widespread use in the TI 99/4 home computer and the
Japanese MSX computers.  All you have to add is a pair of 16K*4 DRAMs.  They
have a simple 8-bit parallel interface.  Unfortunately the availability is
poor now, and they were also NMOS.  Yamaha LSI makes the V9938 and V9958,
which are software compatible upgrades from the TI parts, but I'm not sure
how available they are.

It would seem that the ideal single-chip solution could now be built in a DRAM
process and contain a frame buffer, a simple processor, and a small masked ROM
with code and character sets.  I wonder whether any DRAM vendors have
considered making such a thing.  It's sort of a logical evolution from VRAM,
although it probably wouldn't be useful in PCs or workstatons.

Of course, you could just build a gate array and use a standard DRAM or VRAM
and a DAC to build a three-chip solution.  The gate array could even provide
digitally generated NTSC or PAL color encoding.

Cheers,
Eric

1996\08\21@102147 by myke predko

flavicon
face
>
>> How about the 6845 CGA (?) VDU Controller, should be loads of them about and
>> still fairly easy to use?
>

>Cheers,
>Eric
>
>

How about the Motorola 6847?  (I believe this is the correct number.)  I
used it when I designed/built a CPM compatible back when I was in university.

The chip was largely used in the video games of the time (able to display 24
x 40 characters and limited colour (NTSC) graphics).  I believe the Radio
Shack Colour TRS-80s used them.

The chip internally provides a character generator with an burned in font,
address and data lines and outputs composite video.  The address and data
bus can be accessed at any time (you have to tell the 6847 you're accessing
the busses and it will tri-state it's outputs) or an output will tell you
when a retrace is taking place so you don't get "snow" on the screen when
you update.

It's a pretty nifty solution, you just require the 6847, an SRAM (I used the
full 8K!), some tri-state divers, and some miscellaneous analog parts
(Including a colour-burst crystal).

Myke

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

1996\08\21@121245 by John Payson

flavicon
face
> > How about the 6845 CGA (?) VDU Controller, should be loads of them about and
> > still fairly easy to use?
>
> Here's why not to use the 6845, according to Steve Jobs in the article
> "An Interview: The Macintosh Design Team" in the February 1984 issue of Byte
> magazine:
>
> Steve Jobs:  Do you realize that in an IBM PC the video board, just the
>     black-and-white video plug-in card, has got way more chips than the entire
>     Macintosh?"
> [...]
> Steve Jobs:  I just thought I'd show this to you.  This is the IBM video
>     board; it's only video, nothing else.  It's 69 integrated circuits, more
>     chips than an entire Macintosh, and it basically does nothing.  And it
>     doesn't even do that very well.
[snip]
> Steve Jobs:  If you bite into that IBM display board, it'll totally flicker
>     if you do it at the wrong time.
>
> He was referring to the IBM Monochrome Display Adapter (MDA).  And although
> he mentions the low resolution and fliker, he left out an even more scathing
> criticism of the MDA card:  It couldn't do bit-mapped graphics at all!  For
> years video cards for PC clones have used high-integration ASICs (which
> usually contain a functional equivalent of a 6845).

Actually, sounds more like a CGA.  The MDA does not have the flicker problems
Jobs mentioned, and it also does more than display video (it's a printer
port too--yippee).  And the big reasons the CGA has so many chips are:

<1> Complication of displaying both text and graphics

<2> Poor design [e.g. their cursor circuit]

1996\08\21@125345 by thoffman

picon face
>How about the Motorola 6847?  (I believe this is the correct number.)  I
>used it when I designed/built a CPM compatible back when I was in university.
>
>The chip was largely used in the video games of the time (able to display 24
>x 40 characters and limited colour (NTSC) graphics).  I believe the Radio
>Shack Colour TRS-80s used them.
>
>The chip internally provides a character generator with an burned in font,
>address and data lines and outputs composite video.  The address and data
>bus can be accessed at any time (you have to tell the 6847 you're accessing
>the busses and it will tri-state it's outputs) or an output will tell you
>when a retrace is taking place so you don't get "snow" on the screen when
>you update.
>
>It's a pretty nifty solution, you just require the 6847, an SRAM (I used the
>full 8K!), some tri-state divers, and some miscellaneous analog parts
>(Including a colour-burst crystal).

The 6847 is a wonderful solution, BUT it is obsolete. As far as I know
Motorola isn't making them any more. This is one of the single chip
solutions I looked at, and I wanted to use it, but nobody could find a
source for them. Some of the other chips were the TI 9918 (used in the
TI 99/4a computer) and the Comodore custom chips in the VIC-20, C64,
and Amigas. Atari also had a decent set of custom chips in its 8-bit
home computers. All of these were great, but where did they go? I
guess computer and home console game video system are so advanced now
that there's no market for the low res stuff any more.

There are, however, on-screen display generator chips out there for
TVs, VCRs, and Camcorders... These are great for text only solutions
since they handle almost everything for you, but they won't do
graphics. The NEC uPC6145 does have 16 user definable characters in
RAM though if you can count that...

The search continues!
Tim

1996\08\21@144734 by Eric Thompson

flavicon
face
>>The 6847 is a wonderful solution, BUT it is obsolete. As far as I know
>>Motorola isn't making them any more. This is one of the single chip
>>solutions I looked at, and I wanted to use it, but nobody could find a
>>source for them. Some of the other chips were the TI 9918 (used in the
>>TI 99/4a computer) and the Comodore custom chips in the VIC-20, C64,
>>and Amigas. Atari also had a decent set of custom chips in its 8-bit
>>home computers. All of these were great, but where did they go? I
>>guess computer and home console game video system are so advanced >now
>>that there's no market for the low res stuff any more.
>>
>>There are, however, on-screen display generator chips out there for
>>TVs, VCRs, and Camcorders... These are great for text only solutions
>>since they handle almost everything for you, but they won't do
>>graphics. The NEC uPC6145 does have 16 user definable characters in
>>RAM though if you can count that...

Who else besides NEC makes these on-screen display generators.  I've
been thinking about doing a text only display...

       Thanks,
               Eric

1996\08\21@164318 by Richard Katezansky

flavicon
face
>Who else besides NEC makes these on-screen display generators.  I've
>been thinking about doing a text only display...
>
>        Thanks,
>                Eric


Fujitsu- MB88303, 88323, 88325

Mitsubishi- M50554 ect.

Most of these are 20-24 characters per line 10-12 lines per screen.

All overlay on a video source some will do color if generating their own sync.

******************************
Richard Katezansky
Tangent Electronics Ltd.
Montreal, Canada
******************************

1996\08\21@170032 by Chris Elmquist

flavicon
face
Eric Thompson wrote:
>
> Who else besides NEC makes these on-screen display generators.  I've
> been thinking about doing a text only display...

Me too.  I've always been impressed by the crisp, clear textual displays
most VCRs and TVs can generate on an NTSC display.

Are these chips something you could actually get along with
documentation ?  Chances are good you might even be able to
gen-lock them (for overlay of text) to an incoming NTSC signal.

Chris

--
Chris Elmquist, N0JCF
@spam@chriseEraseMEspamspamn0jcf.com
n0jcfTakeThisOuTspamKILLspamamsat.org

1996\08\21@175123 by Walter Banks

picon face
> > Who else besides NEC makes these on-screen display generators.  I've
> > been thinking about doing a text only display...
>
> Me too.  I've always been impressed by the crisp, clear textual displays
> most VCRs and TVs can generate on an NTSC display.
>
> Are these chips something you could actually get along with
> documentation ?  Chances are good you might even be able to
> gen-lock them (for overlay of text) to an incoming NTSC signal.


Most of the VCR's and TV's use speciallized chips that have video
character generaters built in. A few are based on familliar chips most
are processors developed for the application area. None of the ones that
I have seen are available in low volume programmable versions.

Walter Banks
fttp://http://www.bytecraft.com

1996\08\21@204026 by owler, Gary

flavicon
face
> From: Richard Katezansky
> To: Multiple recipients of list PICLIST
> Subject: Re: Serial Video Display Module
> Date: Wednesday, 21 August 1996 16:42
>
> >Who else besides NEC makes these on-screen display generators.  I've
> >been thinking about doing a text only display...
> >
> >        Thanks,
> >                Eric
>
>
> Fujitsu- MB88303, 88323, 88325
>
> Mitsubishi- M50554 ect.
>
> Most of these are 20-24 characters per line 10-12 lines per screen.
>
> All overlay on a video source some will do color if generating their own
sync.


Motorola make an Advanced Monitor On-Screen Display chip, the MC141543,
which has inbuilt 128 character and graphic symbol ROM, 3 selectable
resolutions- 320, 480, or 640 dots per line, I2C interface. Font is 10x16
with various options like bordering, shadowing, colour (max. 4 colours per
row).

They also make a Color Television Composite Video Overlay Synchronizer, the
MC1378, to overlay an RGB signal onto a external video signal, PAL or NTSC.

Gary.
--------------------------------------------
Email: RemoveMEGary.FowlerTakeThisOuTspamdsto.defence.gov.au
Phone: +61 8 8259 5767
Fax:   +61 8 8259 5672

Defence Science & Technology Organisation
PO Box 1500, Salisbury, South Australia 5108
--------------------------------------------

1996\08\22@022105 by Luiz Marques

flavicon
face
Motorola makes OTP MCUs (68HC705xx) with built-in video characters
generators.

Try http://motoserv.indirect.com and look for CSIC chips

Luiz Marques

1996\08\22@124506 by gton%lancaster.ac.uk%UKACRL.bitnet

flavicon
face
Here is a message that appeared on the Stamps list, sorry if any of you have see
n it before.

Andy

>
Just happened to have read the September edition of Electronics World
(published in the UK but also available in the US I understand). Article
re using the NEC uPD6145 chip for putting characters onto a video
signal--- PAL/SECAM/NTSC etc. Chip uses SPI link and looking at the rest
of the circuit it would suggest it would be really Stamp friendly to
implement. If anyone gets a Stamp version up and running before me,
please give me a call.
(Author of the article is-
Ian Polczynski at 77, Glanton Way, Dianella, Western Australia 6062)
--
Edward Buckley

- To subscribe -or- unsubscribe send e-mail to @spam@majordomoSTOPspamspamparallaxinc.com and
- put SUBSCRIBE stamps -or- UNSUBSCRIBE stamps in the body of the message



Attachment converted: wonderlandthree:WINMAIL.DAT (????/----) (0000753B)

1996\08\22@130204 by nigelg

flavicon
picon face
In message  <TakeThisOuTm0utJwa-000NVbCTakeThisOuTspamRemoveMEn0jcf.com> spam_OUTPICLISTspamspam.....MITVMA.MIT.EDU writes:
> Eric Thompson wrote:
> >
> > Who else besides NEC makes these on-screen display generators.  I've
> > been thinking about doing a text only display...
>
> Me too.  I've always been impressed by the crisp, clear textual displays
> most VCRs and TVs can generate on an NTSC display.
>
> Are these chips something you could actually get along with
> documentation ?  Chances are good you might even be able to
> gen-lock them (for overlay of text) to an incoming NTSC signal.

I've been looking at the circuit for a Pace satellite receiver, this uses an
on-screen display, which can be either gen-locked over the picture, or replace
the existing picture completely with a coloured background. The chip used is
the M50555001P from Mitsubishi. It's controlled via an I2C bus and enable line,
and just requires composite sync, the incoming video enters one pin, and
leaves via another with the displayed text overlayed. There are of course a
handfull of components around the chip, including a 17.734MHz xtal (for PAL)
and an LC circuit for generating the bit-clock.

Like any of these sorts of circuits, the problems seem to be finding out what
data needs supplying via the bus. Do Mitsubishi have a web site, where
hopefully they may give details like this?.

BTW, the reason for looking at the circuit was to try and add a gen-locked
time display to a video camera signal for recording on security tapes.

Nigel.

         /----------------------------------------------------------\
         | Nigel Goodwin   | Internet : nigelg.....spam@spam@lpilsley.demon.co.uk |
         | Lower Pilsley   |                                        |
         | Chesterfield    |                                        |
         | England         |                                        |
         \----------------------------------------------------------/

'PIC16c84 Serial I/O'
1996\08\27@135516 by Philip Lalone

flavicon
face
       Is it possible to do serial I/O with a PIC16c84 clocked at 4MHz?
I'd perfer 19200/38400 or a variable speed, where can I get information
or routines for doing this?
                                               Thanks,
                                               Philip Lalone
                                               spamBeGoneplalonespamspam_OUTalphax.com

1996\08\27@150254 by John Payson

flavicon
face
>         Is it possible to do serial I/O with a PIC16c84 clocked at 4MHz?
> I'd perfer 19200/38400 or a variable speed, where can I get information
> or routines for doing this?

Nearly anything is possible.  As to what's practical...

By far, the easiest way of doing serial I/O is with dedicated polling
routines.  Such routines will do nothing except either output a character
or input a character (the input character routine will wait until either
it receives a character or times out).  Polled I/O is half-duplex only,
and may severely impact the rest of the system (e.g. everything stops when
the input routine is waiting for a character)  On the other hand, it's
simple to code and can go extremely fast (even 115,200 would be no problem
for a 4MHz PIC).

The other approach to handling serial I/O is to use a routine which gets
called at the baud rate (for transmit) or at three times the baud rate
(for serial) and handles the outgoing/incoming data.  Such a routine may
be implemented very nicely as a state machine, though I don't have any
code handy to post.

'I2C sharing lines with Dallas serial'
1996\08\27@185530 by Wireless Scientific

flavicon
face
Folks,

I'm running a little tight on PIC I/O pins, namely I have three lines
available. I would like to tie a Dallas DS1302 RTC and Philips 8570 serial
RAM onto these three lines.

PIC     RTC     RAM
B0      RST\
B1      IO      SDA
B2      SCLK    SCL

My question deals with possible protocol collisions with these two devices.
It's easy to not select the RTC with RST line when talking to the RAM.
However the reverse is not true. Do you think talking to the RTC with its
protocol on B1 and B2 could inadvertantly issue legitimate commands to the
RAM?

I know some of you have pondered this condition, any ideas?

Thanks,
craig

1996\08\27@190337 by John Payson

flavicon
face
> PIC     RTC     RAM
> B0      RST\
> B1      IO      SDA
> B2      SCLK    SCL
>
> My question deals with possible protocol collisions with these two devices.
> It's easy to not select the RTC with RST line when talking to the RAM.
> However the reverse is not true. Do you think talking to the RTC with its
> protocol on B1 and B2 could inadvertantly issue legitimate commands to the
> RAM?
>
> I know some of you have pondered this condition, any ideas?

To avoid selecting the RAM, you must prevent its SDA pin from falling while
its SCL pin is high, or else ensure that if its SDA pin does fall while SCL
is high that when it rises again SCL either high or 'still high'.

1996\08\27@204210 by Henry Carl Ott

picon face
At 07:02 PM 8/27/96 -0400, you wrote:
>Folks,
>
>I'm running a little tight on PIC I/O pins, namely I have three lines
>available. I would like to tie a Dallas DS1302 RTC and Philips 8570 serial
>RAM onto these three lines.
>

-----------snip------------------------
>
>Thanks,
>craig

Why not use the Phillips PCF8583?
RTC with 256 bytes of SRAM in one package.


carl

----------------------------------------------------------------
Henry Carl Ott   N2RVQ   | talk/chat  carlott@204.74.7.186
EraseMEcarlott.....spaminterport.net    | http://www.interport.net/~carlott/
----------------------------------------------------------------
"A day job...in an office? My worst nightmare!"-Ticknophobia

1996\08\27@231004 by Wireless Scientific

flavicon
face
At 08:41 PM 8/27/96 -0400, Henry Carl Ott wrote:
{Quote hidden}

Carl,

It appears like I need to do a little more "research" into Philips'
offerings. Thanks for the tip!

craig

1996\08\27@232855 by Wireless Scientific

flavicon
face
At 08:41 PM 8/27/96 -0400, Henry Carl Ott wrote:
{Quote hidden}

Carl,

I did actually look around immediately after I received your mail. The
PCF8583 is not listed at the Philips site. It is however on various chip
directories.
Is this a new part?

craig

1996\08\28@130528 by Jimmie Curry

flavicon
face
----------
> I'm running a little tight on PIC I/O pins, namely I have three lines
> available. I would like to tie a Dallas DS1302 RTC and Philips 8570
serial
> RAM onto these three lines.
>
> My question deals with possible protocol collisions with these two
devices.
> It's easy to not select the RTC with RST line when talking to the RAM.
> However the reverse is not true. Do you think talking to the RTC with its
> protocol on B1 and B2 could inadvertantly issue legitimate commands to
the
> RAM?
>
> craig

Things to consider:

Many I2C devices do not have a reset line which would assure proper initial
conditions.  These devices often depend on a "power up" to reset to initial
conditions. It is prudent to issue a sequence of signals which would
effectively abort any ongoing commands.  This is important in embedded
systems which may be reset without going through a "power up".  An I2C buss
will not work properly as a shared resource!  Care must be taken in a
multitasking system to allow one and only one task to control the buss.  A
common pitfall is to attempt to control the buss in foreground and also
allow access by an ISR.

The Phillips data book titled "I2C Peripherals for Microcontrollers", 1992
is an excellent reference.  I may be able to find code which issues the
sequence of signals needed to resync the devices if your interested.

Thanks,
Jimmie

       Jim Curry and Associates
       13339 N. Central Expy.
       Dallas, TX 75243
       Voice:    214 680-1540
       Fax:      214 680-1562
       Email:    spamjcurryKILLspamspam@spam@airmail.net
       Web Page: http://web2.airmail.net/jcurry/

1996\08\28@143322 by Wireless Scientific

flavicon
face
At 12:03 PM 8/28/96, Jimmie Curry wrote:
>Many I2C devices do not have a reset line which would assure proper initial
>conditions.  These devices often depend on a "power up" to reset to initial
>conditions. It is prudent to issue a sequence of signals which would
>effectively abort any ongoing commands.  This is important in embedded
>systems which may be reset without going through a "power up".  An I2C buss
>will not work properly as a shared resource!  Care must be taken in a
>multitasking system to allow one and only one task to control the buss.  A
>common pitfall is to attempt to control the buss in foreground and also
>allow access by an ISR.
>
>The Phillips data book titled "I2C Peripherals for Microcontrollers", 1992
>is an excellent reference.  I may be able to find code which issues the
>sequence of signals needed to resync the devices if your interested.
>
>Thanks,
>Jimmie



Jimmie,

Thanks for the information, I'll order the I2C data book ASAP. After the
recent comments from this list, I'm leaning towards I2C only. Now if I can
only get availibility.

Thanks,
craig

1996\08\28@154325 by Henry Carl Ott

picon face
At 11:27 PM 8/27/96 -0400, you wrote:
----snip--------------
>Carl,
>
>I did actually look around immediately after I received your mail. The
>PCF8583 is not listed at the Philips site. It is however on various chip
>directories.
>Is this a new part?
>
>craig
>

Well, the 8583 part is listed in the 1992 Philips/Signetics data handbook
(which has been already mentioned as a good reference for I2C).
If you can't find it in the current data books/sites it might be
discontinued. It's certainly worth finding out, because it's handy part.
How big is your production run? If it's low I might be a able to point you
to a cheap surplus source of SMD PCF8583.

hope this helps...

carl

----------------------------------------------------------------
Henry Carl Ott   N2RVQ   | talk/chat  carlott@204.74.7.186
carlottspamspamTakeThisOuTinterport.net    | http://www.interport.net/~carlott/
----------------------------------------------------------------
"A day job...in an office? My worst nightmare!"-Ticknophobia

1996\08\28@174032 by Wireless Scientific

flavicon
face
At 3:43 PM 8/28/96, Henry Carl Ott wrote:
{Quote hidden}

The newest I2C databook is on the way. After it arrives, I'll verify that
8583 is still in production. Both Marshall and Newark have it listed.


Have you used it with a battery to keep time and NVRAM across power downs?

craig

1996\08\28@191522 by Henry Carl Ott

picon face
At 05:46 PM 8/28/96 -0400, you wrote:
>>----snip--------------

>>
>>carl
>
>The newest I2C databook is on the way. After it arrives, I'll verify that
>8583 is still in production. Both Marshall and Newark have it listed.
>
>
>Have you used it with a battery to keep time and NVRAM across power downs?
>

Craig,

The actual project was battery powered to begin with. I used a 16c54 to
talk to the 8583 RTC and log switch closure events into a 93LC66. I wanted
EE storage so that data would be saved even with battery failure. On demand
the device would dump the logged data into a pc via the serial port. I only
used a couple of bytes of the 8583 SRAM as a sanity check to see if battery
power had ever failed. Everything ran on a 3volt lithium coin cell.
The fun part of the project was fitting the I2C code, the eeprom support,
and a small rs232 mini monitor routine into a 16c54. When I was done I had
broken a whole slew of programming rules, but I still had one program
location free.  I would have killed for two more levels in the hardware
stack. Don't ask why I used the parts I did, they were on the shelf.


And as a bonus to anybody else following this thread:

I have a quantity of SMD PCF8583 on the shelf collecting dust. If anyone
wants a couple (with crystals) send a SASE to the below snailmail address
and I'll drop them in the post. You are on your own for the data sheets.
The fine print: I'm doing this as a favor to experimenters on the pic
mailing list that might have trouble getting samples from the manufacturer.
So first come, first serve till I run out of the ones I set aside.

later...

carl

H. Carl Ott
22 Nixon Ave.
Staten Island, NY 10304-2210

1996\08\28@193220 by Robert Lunn

flavicon
face
>Many I2C devices do not have a reset line which would assure proper initial
>conditions.  These devices often depend on a "power up" to reset to initial
>conditions. It is prudent to issue a sequence of signals which would
>effectively abort any ongoing commands.  This is important in embedded
>systems which may be reset without going through a "power up".

       I have successfully run an I2C eeprom and a non-I2C LCD controller
       chip on the same clock/data lines.  There is no intrinsic reason
       this can't be done, as long as due attention is given to the
       generation of I2C start and stop states.

       However, the comments quoted above are correct.  You should never
       assume the state of the I2C component when you begin a transaction.

___Bob


'PIC16c84 Serial Data'
1996\09\01@001217 by Philip Lalone
flavicon
face
       Is it possible to get the PIC16c84 to output serial data directly?
I've been trying it, and it seems to send out the 20 higher than the ASCII
character I send, but that isn't consistant.  I've tried the Parallax,
and Microchip source.

I have TX connected to a pin on port A, and i've tried -5v on all of the
pins (It doesn't send anything without it).  I have it hooked up to a dumb
terminal, and all of the settings are correct.  Does anybody have any
ideas what's wrong, or any working tested source for the PIC16c84?

                                       Thanks,
                                       Philip Lalone
                                       Alpha-X Development

1996\09\01@072322 by id John Philip Bodger

flavicon
face
Philip, you wrote:-
>        Is it possible to get the PIC16c84 to output serial data directly?
>I've been trying it, and it seems to send out the 20 higher than the ASCII
>character I send, but that isn't consistant.  I've tried the Parallax,
>and Microchip source.
>I have TX connected to a pin on port A, and i've tried -5v on all of the
>pins (It doesn't send anything without it).  I have it hooked up to a dumb
>terminal, and all of the settings are correct.  Does anybody have any
>ideas what's wrong, or any working tested source for the PIC16c84?

Check this out, it's taken directly from a working program. It's written for
Parallax's PASMX compiler. Sorry I don't have it in standard Mchip code but
it might give you an idea of where you're going wrong. I don't use a
negative power source and it works just fine connecting to an ordinary PC
clone via 2 meters of cable.
Also, remember that RA.4 is an open collector output and won't work properly
without some external support components.

All the best.

Dave.

;Serial RS232 via a 22K input resistor routines.
;Can freely use volatile registers: TempC, TempD, TempE, HexDec, R0;
;as this all runs with interrupts disabled.
SerialTest      call    SavePorts
               setb    RP0             ;Select Page 1
               mov     !RB,#11111101b  ;all but RB.1 are inputs
               clrb    RP0             ;Select Page 0
               clrb    SerOut          ;'MARK' RS232 logic 1 = -0v.
:test           jb      SerIn,:skip ;if input high then RS232 not connected.
               call    RXbyte          ;get command letter into TempE.
               cjne    TempE,#'T',:rx  ;Should we transmit config values ?
               call    RXbyte          ;get address of byte to transmit
               mov     FSR,TempE       ;address of indirect source in RAM
               mov     TempE,INDIRECT  ;load TempE with the byte to send
               call    TXbyte          ;transmit one byte
               jmp     :test
:rx             cjne    TempE,#'R',:test ;Should we receive new config values ?
               call    RXbyte          ;get address of byte to receive
               mov     FSR,TempE       ;save address
               call    RXbyte          ;receive one byte of data
               mov     INDIRECT,TempE  ;store the received byte in RAM
               setb    KeyFlag.Config  ;indicate EEPROM needs updating.
               jmp     :test
:skip           clrb    Options.Lockout ;Clear Lockout indicator normally.
               sb      LockInput       ;if input high then not locked out.
               setb    Options.Lockout ;if input low then indicate lockout.
               call    RestorePorts
               ret

;Receive a single byte into TempE.
RXbyte          jnb     SerIn,RXbyte    ;Detect start bit = +5v.
               call    HalfBitDelay    ;wait half a bit.
               jnb     SerIn,RXbyte    ;if start bit bad, go back and wait.
               mov     TempD,#8        ;Set counter to receive 8 bits.
               clr     TempE   ;Clear received byte to get ready for new one.
:rxbit          call    BitDelay        ;wait one bit time.
               movb    C,/SerIn        ;put inverted bit into carry.
               rr      TempE           ;rotate bit in Carry into receive byte.
               djnz    TempD,:rxbit    ;keep going for 8 bits.
               call    BitDelay        ;position into middle of stop bit.
               ret                     ;return with byte in TempE.

;Transmit a single byte from TempE.
TXbyte          mov     TempD,#8        ;Eight bits in the byte
               setb    SerOut
               call    BitDelay        ;send start bit = +ve voltage.
:txbit          rr      TempE           ;rotate bits right into carry, 0 first.
               movb    SerOut,/C       ;output inverted bit
               call    BitDelay
               djnz    TempD,:txbit    ;round the loop for 8 bits worth.
               clrb    SerOut          ;stop bit = -ve voltage.
               call    BitDelay        ;one stop bit for 8N1.
               ret

;Bit time delay = 8 + 4 * n, where n=bit delay number.
;calculate as = 4/1843200 * (4 * n + 8) seconds.
BitDelay        mov     TempC,#46       ;2400 baud with 1.8432MHz clock.
DelayLoop       nop                     ;delay 1 clock
               djnz    TempC,DelayLoop ;total loop = 4 clocks
               ret

;Half a bit delay at start.
;Time wasted = 9 + 4 * n, where n=~1/2 bit delay number.
;calculate as = 4/1843200 * (4 * n + 9) seconds.
HalfBitDelay    mov     TempC,#22       ;2400 baud with 1.8432MHz clock.
               jmp     DelayLoop

'12c50x serial programmer'
1996\09\13@120800 by Robert S Gray

flavicon
face
Does anyone have a simple schematic and software to program these new
pics?

1996\09\14@084932 by nogueira

flavicon
face
Robert S Gray wrote:
>
> Does anyone have a simple schematic and software to program these new
> pics?
My ProPic hardware/software will be able to program it soon.

Octavio
--
========================================================
Octavio Nogueira
e-mail:   RemoveMEnogueiraRemoveMEspammandic.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

'Help using serial a/d'
1996\09\14@123814 by Gerry Smith

flavicon
face
I'm having a bit of difficulty figuring out how to hook up a 5 mhz clock
signal to NS' adc12138.  How do I hook up a crystal to produce a 5 mhz
clock signal on 1 pin only?  The PICs all have 2 OSC pins to hook up
a crystal.  Thanks for any help.

1996\09\14@233717 by fastfwd

face
flavicon
face
Gerry Smith <TakeThisOuTPICLIST@spam@spam@spam@MITVMA.MIT.EDU> wrote:

> I'm having a bit of difficulty figuring out how to hook up a 5 mhz
> clock signal to NS' adc12138.  How do I hook up a crystal to produce
> a 5 mhz clock signal on 1 pin only?  The PICs all have 2 OSC pins to
> hook up a crystal.

Gerry:

The PICs include a built-in oscillator circuit.  To generate a 5 MHz
clock signal to drive your A/D converter, you have two options:

1.  Run your PIC at 5 MHz and just tap off the PICs OSCOUT pin to drive
the ADC.

2.  Build your own external oscillator using a couple of inverters.
Take a look at the "External Crystal Oscillator Circuit" section in
any Microchip data book (it's Section 7.2.3 in the Enhanced PIC16C5x
Data Book, for instance)... They show a couple of circuits you can
use.

-Andy

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

'12c50x serial programmer'
1996\09\15@222441 by Jim Robertson

flavicon
face
At 11:01 AM 9/13/96 -0500, you wrote:
>Does anyone have a simple schematic and software to program these new
>pics?
>
Robert,

Programming the 12C50x devices is only a little different to programming
the 16Cxx devices. Any ISP programmer supporting the 16Cxx devices can
easily be updated to support the 12C50x. The circuit is the same except
for the different pinouts of course.

I would expect that the likes of David Tait and the other "big boys" of
the programmer world will be along anytime now with their 12C50x offerings.

I have my PICSTART 16B programming the little suckers now. Well, I mean
I have it doing simulated programming on a 16Cxx as I don't have any 12C50x
parts to test with. One of the unfortunate "side effects" of living in
Australia. :-(

Stay tuned, I think your enquiry is just ahead of all the 12C50x goodies coming.

-Jim

1996\09\16@142617 by David Tait

flavicon
face
Newfound Electronics wrote:

> I would expect that the likes of David Tait and the other "big boys" of
> the programmer world will be along anytime now with their 12C50x offerings.

Somehow I doubt that was a compliment :-)

Anyway, the new academic year starts about now so I won't be playing
with PICs for quite a while.  Last Easter I did find some time to
build a 16C5X/XX programmer so that I could experiment with unfamiliar
(to me) PICs.  I'm not prepared to release my software (I have enough
trouble supporting my free 16C84 programmer) but if anyone is
interested in the hardware design I've written a WWW page describing
it (the page includes the schematic):

http://www.man.ac.uk/~mbhstdj/upp.html

As Jim confirmed, the 12C50X programming spec has no surprises so my
new programmer could easily be made to work with these devices.

Despite my attachment to my own programmer design I guess if you
really want to homebrew a programmer then you should try Octavio
Nogueira's shareware offering:

http://ourworld.compuserve.com/homepages/tato/

His page claims he is adding the 12C50X devices to the already
long list of PICs that it can program.

David
--
KILLspamdavid.taitKILLspamspamspamBeGoneman.ac.uk
http://www.man.ac.uk/~mbhstdj/piclinks.html

'TI-Calculator serial protocol's'
1996\09\18@110202 by Les Troyer

flavicon
face
Does any one have info on the protocol used in TI graphing calculators.  I
am persuing an application in which a pic would collect data for a short
period of time.  I would like to then display the data on a graphing type
calculator.  I know using a PC with Excel would be easier; but at a much higher
cost.

I have tried contacting TI without any success thus far.

--
Les Troyer
Sr. Analyst
Siemens Power Corp
2101 Horn Rapids Rd.
Richland, Wa. 99352-0130

Voice    (509) 375-8695
Fax      (509) 375-8940
Operator (509) 375-8100
email spamBeGoneljtKILLspamspamnfuel.com

Ad Hoc, Ad Loc, Quid Pro Quo; So Little Time SO Much To Know.
  -Jeromy Hillery Dillery Boo, PHD, MS and Q

1996\09\18@145559 by nogueira

flavicon
face
Les Troyer wrote:
>
> Does any one have info on the protocol used in TI graphing calculators.  I
> am persuing an application in which a pic would collect data for a short
> period of time.  I would like to then display the data on a graphing type
> calculator.  I know using a PC with Excel would be easier; but at a much
higher
{Quote hidden}

Some time ago I did the same thing but using HP48GX
and I used infrared comunications, but I'm sure TI is
diferent.

Octavio
--
========================================================
Octavio Nogueira
e-mail:   EraseMEnogueiraRemoveMEspam@spam@mandic.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

1996\09\18@174447 by William Chops Westfield

face picon face
   Does any one have info on the protocol used in TI graphing calculators.  I
   am persuing an application in which a pic would collect data for a short
   period of time.  I would like to then display the data on a graphing type
   calculator.

For that matter, does anyone know whether LCD displays of the sort used in
"graphing calculators" have hit the "experimentor" market anywhere?  I guess
they'd be about 100x100 fairly large dots?

BillW

1996\09\18@212349 by Philip Lalone

flavicon
face
On Wed, 18 Sep 1996, Les Troyer wrote:

> Does any one have info on the protocol used in TI graphing calculators.  I
> am persuing an application in which a pic would collect data for a short
> period of time.  I would like to then display the data on a graphing type
> calculator.  I know using a PC with Excel would be easier; but at a much
higher
> cost.

The protocol and complete technical information for all TI calculators
is available at http://www.ticalc.org.
                                               Philip Lalone
                                               Alpha-X Development

'Serial I/O Problem'
1996\09\26@222017 by Joshua Woods

picon face
This is it ->

* I'm using a PIC178C42A with 128K of external Program FLASH and 128K of BB CMOS SRAM
* I need a total a 3 serial ports for this device
* One of the ports requires TX,RX,CTS,RTS,DTR,DSR,DCD,RI,GND (for a 400Mhz MODEM)
* The other two ports only need TX,RX,GND.

Q:  What would be the best way to switch between ports? Multiplexing may get messy,  However a DUART is possibility, component size and power consumption is very important for this design.

Any suggestions?



Thanks


Joshua Woods
RemoveMEj.woodsspamspamEraseMEqut.edu.au
http://www.scsn.bee.qut.edu.au

1996\09\27@000859 by Wireless Scientific

flavicon
face
At 12:18 PM 9/27/96 +1000, Joshua Woods wrote:
>This is it ->
>
>* I'm using a PIC178C42A with 128K of external Program FLASH and 128K of BB
CMOS SRAM
>* I need a total a 3 serial ports for this device
>* One of the ports requires TX,RX,CTS,RTS,DTR,DSR,DCD,RI,GND (for a 400Mhz
MODEM)
>* The other two ports only need TX,RX,GND.
>
>Q:  What would be the best way to switch between ports? Multiplexing may
get messy,  However a DUART is possibility, component size and power
consumption is very important for this design.
>
> Any suggestions?
>


Yes cut down on the speed of that modem, what a screamer!

craig
____________________________________________________
Dr. Craig Hollabaugh
Wireless Scientific, Inc.
1890 S. 14th, Suite 105
Amelia Island, FL 32034
904 261 6977
904 261 2129 fax
STOPspamwsci.....spamnet-magic.net

'Help on 16c84 Serial Comms'
1996\09\29@123537 by JACQUES LE ROUX

picon face
Hi There!

Can anyone help me with serial communication (rs232) on the PIC16C84.

I would appreciate it.

Thanks
Jacques le Roux

1996\09\30@001744 by Eric Rossello

flavicon
face
part 0 835 bytes
----------
From:   JACQUES LE ROUX[SMTP:spamBeGonepicmicroRemoveMEspamRemoveMEIAFRICA.COM]
Sent:   Sunday, September 29, 1996 3:55 PM
To:     Multiple recipients of list PICLIST
Subject:        Help on 16c84 Serial Comms

Hi There!

Can anyone help me with serial communication (rs232) on the PIC16C84.

I would appreciate it.

Thanks
Jacques le Roux

Hi Jacques:

Please find attached the code from a Microchip application note to transmit/receive using the RTCC timer interrupts. I personally had to manually "tune" the values calculated by the "load RTCC" macro.

Good luck !

PS: By the way, tes-vous franais ?
[[ 16CXX.H : 770 in WINMAIL.DAT ]][[ RCVR.ASM : 771 in WINMAIL.DAT ]][[ RS232.ASM : 772 in WINMAIL.DAT ]][[ RS232.DOC : 773 in WINMAIL.DAT ]][[ RS232.H : 774 in WINMAIL.DAT ]][[ TXMTR.ASM : 775 in WINMAIL.DAT ]]
Eric


'16C73 Serial Port - Help!'
1996\10\22@080356 by Maurice De Jersey
picon face
Hi,

Being new to PIC programming I'm trying to get the Async port on
the PIC16C73 to work in interrupt mode.  My interrupt routine is
where I'm sending and receiving data.  Rather than bore you all
with the problems I seem to be having with serial interrupts, I
would like to ask if anyone has a small code fragment that they
could share with me to help me on my way.

Also does MPLAB simulator simulate the serial port correctly in
terms of interrupts and general fuctionality (ex data xfer).

Cheers
Maurice

'Pic Serial Nodes'
1996\10\23@133337 by Beacham, Bill HSD

flavicon
face
I am working on a project to link remote nodes by a serial link. I want to
use a PIC 16C74 with its internal UART. I would like to use an existing
electrical specification and an existing protocol that is common to existing
off the shelf products that can be used in home automation/control. I've
read where RS485 is used and I can get inexpensive buss interface chips.
What I am after is a standard protocol. Does any one have any information in
this area including how difficult it would be to impliment the protocol in
a PIC. I plan to dedicate a single PIC to impliment the Physical, Data Link
and Network layers of the OSI model.

Thanks
Bill
SPE L.L.C.
Enfield Ct.

1996\10\23@235516 by Gerhard Fiedler

flavicon
face
At 12:55 23/10/96 -0700, you wrote:
>I am working on a project to link remote nodes by a serial link. I want to
>use a PIC 16C74 with its internal UART. I would like to use an existing
>electrical specification and an existing protocol that is common to existing
>off the shelf products that can be used in home automation/control. I've
>read where RS485 is used and I can get inexpensive buss interface chips.
>What I am after is a standard protocol.

If you come up with any information, I'd be interested in that, too. Andrew
David <@spam@AndyspamBeGonespamUltronics.co.uk> gave me this info (haven't checked it out yet)
"Arcnet is based on RS-485, http://www.smc.com should have some info on
Arcnet." Arcnet is one of the industry field buses.

'serial port on 16c74'
1996\10\28@201609 by TONY NIXON 54964

flavicon
picon face
If an over run error occurs on the 16c74 in asynchronous mode then
RCSTA,OERR will be set = 1.

FERR will be set = 1 for a framing error.

The data sheet seems to have a conflict in clearing these bits.

On the page describing RCSTA it states, to clear OERR, you must CLEAR
CREN. On the page describing the asynchronous receiver, you must SET
the CREN bit. Which is true?

I would imagine to SET this bit, otherwise the continuous receive is
disabled.

If I clear the overrun error by setting/clearing the CREN bit, does
this also clear a framing error.

Thanks for any help

Tony


Just when I thought I knew it all,
I learned that I didn't.

1996\10\29@194704 by Brian Boles

flavicon
face
______________________________ Forward Header __________________________________
Subject: Re: serial port on 16c74
Author:  Stan D'Souza at MCHIP_AZ
Date:    10/29/96 10:44 AM


    Some detail in the data book ....

    The OERR bit is cleared by writing a 0 to CREN.  However the reception
    will not start (once again) until CREN = 1.  I didn't see any conflict
    in the data sheet.

    In the RCSTA section yes it states that OERR can be cleared by
    clearing CREN, which is true, but if you don't want to enable your
    reveiver anymore, then CREN can be made equal to 0 and left there till
    you want to enable the receiver.  Then at that time you would make
    CREN = 1.

    Framing error will not be cleared until a correctly framed byte is
    received.  Framing error is always associated with the byte received.
    When you read the last byte, the location from which you read does not
    reset or clear until a new byte overwrites it through the serial
    receiver.

    -Stan.


______________________________ Forward Header __________________________________
Subject: serial port on 16c74
Author:  TONY NIXON 54964 <spam_OUTAnthony.nixonspamspamENG.MONASH.EDU.AU> at Internet_Exchange
Date:    10/29/96 12:09 PM


If an over run error occurs on the 16c74 in asynchronous mode then
RCSTA,OERR will be set = 1.

FERR will be set = 1 for a framing error.

The data sheet seems to have a conflict in clearing these bits.

On the page describing RCSTA it states, to clear OERR, you must CLEAR
CREN. On the page describing the asynchronous receiver, you must SET
the CREN bit. Which is true?

I would imagine to SET this bit, otherwise the continuous receive is
disabled.

If I clear the overrun error by setting/clearing the CREN bit, does
this also clear a framing error.

Thanks for any help

Tony


Just when I thought I knew it all,
I learned that I didn't.

'Serial port(s) on PIC'
1996\10\30@004852 by tjaart

flavicon
face
Hi Everybody!

It seems that the absense of a second UART on the reasonably priced
PIC's (not the 17CXX) is one of the last benefits of the Intel chips
keep over Microchip's PICS.

Perhaps we can nag & nag & nag & nag Microchip until they include a
second UART on chips like the 16C74. Doing it in software is a pain in
the butt. Am I alone, or is there anybody else that agree?

Anyway, here's the code :

loop:
       movlw   nag_nag_nag_nag
       movwf   MICROCHIP
       goto    loop:

--
Friendly Regards

Tjaart van der Walt
______________________________________________________________
|  Another sun-deprived R&D Engineer slaving away in a dungeon |
|WASP International GSM vehicle tracking and datacomm solutions|
|           +27-(0)11-622-8686 | http://wasp.co.za             |
|______________________________________________________________|

1996\10\30@095138 by Byron A Jeff

face picon face
>
> Hi Everybody!
>
> It seems that the absense of a second UART on the reasonably priced
> PIC's (not the 17CXX) is one of the last benefits of the Intel chips
> keep over Microchip's PICS.

Um exactly which Intel parts have the second UART and what's their cost?
The 8051, 803[12], and 8751 don't right?

>
> Perhaps we can nag & nag & nag & nag Microchip until they include a
> second UART on chips like the 16C74. Doing it in software is a pain in
> the butt. Am I alone, or is there anybody else that agree?

Well it may be useful but I've found that PICs make very good software UART
engines with some caveats. Specifically:

1) Works well in half duplex operation
2) Doesn't require a lot of time intensive work while serial stuff is going on.

I've just finished a half duplex software UART that will do 38400 using a
14.7456 Mhz crystal. With a 19.6608 Mhz crystal you can get 38400 operation
(38400 * 512 -> 19.6608 Mhz) and have time leftover to do other stuff.

My UART implementation uses precise delays and no interrupt. However it would
be fairly simple to convert it to using interrupts for delays and a state
machine. Then the PIC could do other work and get interrupted for each bit
to be transferred.

The other thing I like about software UARTS is that I can pick and choose the
pins that I want to run them on. And potentially I could build several of
them into a single PIC.

Also there are some fairly simple hardware UARTS that could easily be attached
to a PIC. One of my favorites is the Signetics 2691. Comes in a 28 pin skinny
DIP, has a 4 byte receive buffer, and has an extra timer on board, along with
the standard baud rate generator.

I'm designing a portable MIDI sequencer. Each MIDI channel requires a UART.
I'm planning on using the Cirrus Logic CL-CD-180 8 port UART. Each channel
has 8 bytes of send and receive buffers and the part comes in a 84 pin PLCC
so it doesn't take a whole bunch of space. 2 PIC ports and a latch are required
for interfacing.

And of course if you're tight for space just program another small PIC as
software UART and interface it to the main PIC. Cheaper than a real UART,
takes less space and power, and you already have them in your box.

I haven't really used a UART since I've started programming PICs not that I
think about it. All of the serial interfaces I've built in the last two years
are software PIC UARTs.

BTW I've finally figured out the secrets to precise delays:

1) Never reset your timer, let it free run.
2) Use another register to store the end of the delay. Update that register
instead of the timer.
3) Use a crystal that is a integral multiple of the bit rates you want to
produce. Use 18.432 Mhz if you need 57.6K and 115.2K or the 19.6608 Mhz if
you need only up to 38.4K.

My last crack at UART code produced a UART that only worked up to 2400 BPS
because I reset the timer. Using the 14.7456 Mhz crystal, a free running
timer, and an extra register to hold the end of the next delay, 38.4K was
no problem. My next test is 57.6K and 115.2K because I'll scale back the
prescale from 1:16 to 1:8.

Anyway PIC software UARTS are a godsend for me. I know I can pull together
a PIC and a MAX232 and have a serially programmable I/O controller in a
matter of minutes.

BAJ

1996\10\31@030925 by Werner Terreblanche

flavicon
face
Tjaart van der Walt <spamtjaartspamspamspamWASP.CO.ZA> wrote:

>Perhaps we can nag & nag & nag & nag Microchip until they include a
>second UART on chips like the 16C74. Doing it in software is a pain in
>the butt. Am I alone, or is there anybody else that agree?

Tjaart

 Maybe its time you should consider using the CCS C compiler.  I
recently started using it and one of the most usefull functions is
its capability to add a software serial port on ANY of the pic
devices.  What a pleasure to be able to use printf statements on
devices like the PIC16C84!  And if you need two serial ports on one
device its no problem at all, because the compiler already caters for
that.  And its defineteyl not a pain in the butt to implement.

I do all my development work now using that compiler and I add printf
statements while debugging my software.  Once I'm happy that its
working I just delete the printf statements and re-compile.  Its
really worth the $99 that you pay for it.

Regards
Werner
--
Werner Terreblanche   Tel +27 21 7102251   Fax +27 21 721278
spamBeGonewterrebKILLspamspamKILLspamplessey.co.za (work) OR TakeThisOuTwernerspamspamaztec.co.za  (home)


'>16Kbit serial EEPROMS?'
1996\11\02@141552 by Matthew Mucker
flavicon
face
My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
wondering if there were any serial EEPROM devices out there larger than
that, wnd what the approximate cost is in units of one. I think I have to
go serial, 'cuz there aren't enough pins on a '54 to address a whole word
of external memory without a lot of support circuitry, which would add a
lot of cost.

Thanks-Matt


 "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."

1996\11\02@150419 by Ian Stirling

flavicon
face
>
> My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
> more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
> wondering if there were any serial EEPROM devices out there larger than
> that, wnd what the approximate cost is in units of one. I think I have to


Xicor's serial flash may be interesting, up to 64kbit I think, try
http://www.xicor.com/


{Quote hidden}

--
Ian Stirling.                        |  http://www.mauve.demon.co.uk/
AKA Caeser, Bolonewbie.              |  With information on the PDA I'm making.

1996\11\02@151913 by Byron A Jeff

face picon face
>
> My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
> more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
> wondering if there were any serial EEPROM devices out there larger than
> that, wnd what the approximate cost is in units of one.

Microchips 24X65 are 64Kbit parts and are addressable so that 8 of them
can live on a 2 bit I2C bus. thats 64KBytes for about $40. and 2 IO pins.

>I think I have to
> go serial, 'cuz there aren't enough pins on a '54 to address a whole word
> of external memory without a lot of support circuitry, which would add a
> lot of cost.

Check out digikey at http://www.digikey.com

BAJ

1996\11\03@032419 by Dorin Dogaroiu

flavicon
face
Try 24C65 ( made by Microchip and others ) which has an IIC
interface and also has pins for selecting the address of the chip,
so you can use multiple chips on the same IIC bus ( I don't
remember exactly but I think that you can use 8 chips ).  IIC
routines for PICs you can find in AN541 and AN555 from Microchip.


                               Best regards,

                                               Dorin
{Quote hidden}

1996\11\04@092825 by Wireless Scientific

flavicon
face
At 2:22 PM 11/2/96, Matthew Mucker wrote:
>My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
>more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
>wondering if there were any serial EEPROM devices out there larger than
>that, wnd what the approximate cost is in units of one. I think I have to
>go serial, 'cuz there aren't enough pins on a '54 to address a whole word
>of external memory without a lot of support circuitry, which would add a
>lot of cost.

National make a 8Mbit serial flash part. check their site.
craig



________________________________________________________
Dr. Craig Hollabaugh
Wireless Scientific, Inc.
1890 South 14th Street
Building 100, Suite 105
Amelia Island, FL 32034
904 261 6977
904 261 2129 fax
spamBeGonewscispamnet-magic.net

Or you might know me as
Dr. Craig Hollabaugh
Analog Microelectronics, Georgia Institute of Technology
EraseMEhollaEraseMEspammonique.adgrp.gatech.edu

or

Dr. Craig Hollabaugh
Aerospace Department, University of Texas, Austin
spamBeGonehollaspam_OUTspam.....cfdlab.ae.utexas.edu

1996\11\04@092829 by Wireless Scientific

flavicon
face
At 3:02 PM 11/2/96, Ian Stirling wrote:
>>
>> My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
>> more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
>> wondering if there were any serial EEPROM devices out there larger than
>> that, wnd what the approximate cost is in units of one. I think I have to
>
>
>Xicor's serial flash may be interesting, up to 64kbit I think, try
>http://www.xicor.com/

I've prototyped the XICOR 24F128 connected to a '73. It worked fine with a
CCS compiled C program.

craig




________________________________________________________
Dr. Craig Hollabaugh
Wireless Scientific, Inc.
1890 South 14th Street
Building 100, Suite 105
Amelia Island, FL 32034
904 261 6977
904 261 2129 fax
spamwscispamnet-magic.net

Or you might know me as
Dr. Craig Hollabaugh
Analog Microelectronics, Georgia Institute of Technology
RemoveMEhollaKILLspamspamKILLspammonique.adgrp.gatech.edu

or

Dr. Craig Hollabaugh
Aerospace Department, University of Texas, Austin
EraseMEhollaspamBeGonespamspamcfdlab.ae.utexas.edu

1996\11\04@093654 by Wireless Scientific

flavicon
face
At 3:19 PM 11/2/96, Byron A Jeff wrote:
>>
>> My next project would need a lot of EEPROM-- I figure about 2Kbytes, but
>> more would be nice.  National Semi makes 16Kbit serial EEPROMS, but I was
>> wondering if there were any serial EEPROM devices out there larger than
>> that, wnd what the approximate cost is in units of one.
>
>Microchips 24X65 are 64Kbit parts and are addressable so that 8 of them
>can live on a 2 bit I2C bus. thats 64KBytes for about $40. and 2 IO pins.


National's new 8Mbit serial part costs around $20.

1996\11\04@121032 by John Magrane (IsMail)

flavicon
face
>>National Semi makes 16Kbit serial EEPROMS, but I was wondering if
>>>there were any serial EEPROM devices out there larger than that, wnd
>what the approximate cost is in units of one.

Microchip makes serial eeproms up to 64kbits. The 24C65 is $2.64 is
single units in DIP.

John Magrane
Field Apps Eng
Bell Industries
408 734-8570
KILLspamjmagranespambellind.com

'Serial port(s) on PIC'
1996\11\05@132229 by Mike Geipel

flavicon
face
Tjaart van der Walt <tjaartspam_OUTspamspamWASP.CO.ZA> wrote:

> Perhaps we can nag & nag & nag & nag Microchip until they include a
> second UART on chips like the 16C74. Doing it in software is a pain in
> the butt. Am I alone, or is there anybody else that agree?

Yes!  I *really* need a processor with an SPI channel and two UARTs.
(I don't have the option of using a software UART...)

I've heard that the 17C752 will have two UARTs, but not an SPI port.  :-(
(Actually, it's too expensive for my application anyway.)
I'd really love to see the 16C65A with a second UART.  Hint, hint.


Although I hate using an external UART with the 16C65A, I don't have
much choice...  so here's my question:
 Does anybody know about a really *small* UART?
 Perhaps something in an SOIC-14 package?  (Smaller is better!)


advTHANKSance (THANKS in advance),
--
Mike Geipel                  (N4IXJ) | Eurotherm Controls Inc.
Telephone:       (703) 471-4870 x387 | 11485 Sunset Hills Road
"Mike.Geipelspamspam@spam@Controls.Eurotherm.COM" | Reston, VA   22090-5286

'>16Kbit serial EEPROMS--summary'
1996\11\06@014746 by Matthew Mucker

flavicon
face
Thank you to all who responded to my request for information regarding
serial EEPROMs greater than 16Kbit.  I found your advice tremendously
helpful.

From your responses, I was able to locate devices from three manufacturers
that all seem to fit the requirements.  The manufacturers are Atmel, Xicor,
and Microchip.  I found the results of my search quite amusing in one
sense-- all three vendors make essentially the same chip!  They all use the
I2C bus, and at first glance are even pin-compatible!  (Except for a 'write
protect' pin which is implemented slightly differently on all three
versions.)

I guess my choice will boil down to cost/availability.  I just thought I'd
post a summary of my findings for others.  Once again, thanks for the
collective help.

-Matt


 "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."

'Serial Routines'
1996\11\06@153629 by Mr M R Bowman

flavicon
picon face
Hi again, i have another problem, i need to me able to send
some serial data over a radio link at 9600 baud, and then feed
this data into the parallel port on a PC.  I have an RS232
transmit routine that works fine.  But i cannot get any of
the Receive routines that are in the Application notes
AN510.AN555 etc to work properly if at all on on my 16c84.

Any ideas.

Cheers.
--

+-------------------------------------------------------------------+
|       Martin Bowman - University of Warwick, Coventry, UK         |
|                     - 3rd Year Electronic Engineering             |
|                     - E Mail (spamBeGoneesukq.....spamwarwick.ac.uk)                |
|                     - Packet  .....G7VHE@spam@spamGB7COV.GBR.EU                 |
+------------------ IF IT AINT BROKE - DONT FIX IT -----------------+

'>16Kbit serial EEPROMS--summary'
1996\11\06@163738 by Bob Fehrenbach

picon face
Matthew Mucker <@spam@mmuckerspamAIRMAIL.NET> wrote:
>>From your responses, I was able to locate devices from three manufacturers
>that all seem to fit the requirements.  The manufacturers are Atmel, Xicor,
>and Microchip.  I found the results of my search quite amusing in one
>sense-- all three vendors make essentially the same chip!

  Caution!  In a couple of cases where I designed in a Microchip part,
  a Xicor part would not function in the same socket with the same
  software.  At the time I was in crunch mode and didn't have the time
  to figure out why.  A quick scan of the data books did not point out
  any obvious differences.  I had a chat with a Microchip technical
  person on this and he agreed there was a difference but couldn't
  remember what it was.

  Perhaps someone has persued this in more detail and could post his/her
  findings.

--
Bob Fehrenbach    Wauwatosa, WI     bfehrenbRemoveMEspamexecpc.com

1996\11\06@235129 by Giles L. Honeycutt

flavicon
face
I have run into this problem with one chip working and another brand not on the
serial EE, What if found was the Microchip that I used would
work faster than it's spec, and my program I wrote worked with it, when I
changed parts, I had to modify the program for propor timming. Now I
do all my timming from the "real" specs of the Buss (not the part), such as I am
writing for a 100kbit I2C as apposed to the 400Kbit, because
my clock/calender chip is only rated at the slower spec (watch out for this
yall!) and most the EEproms will work up to the 400Kbit Standard.
Giles L. Honeycutt

Bob Fehrenbach wrote:
{Quote hidden}

'Serial programmers and the 16c84'
1996\11\06@235921 by Giles L. Honeycutt

flavicon
face
Anyone know about using the 16c84 programmer in the microchi handbook at a
programmer for the other pics?  The timming needs to be changed,
and the voltages.  Anyone done it? anyone have the program code to driving it?

Giles L. Honeycutt
spam_OUTgileami@spam@spamRemoveMEix.netcom.com

'>16Kbit serial EEPROMS--summary'
1996\11\07@015053 by Matthew Mucker

flavicon
face
>Matthew Mucker <spammmuckerspamspamAIRMAIL.NET> wrote:
>>>From your responses, I was able to locate devices from three manufacturers
>>that all seem to fit the requirements.  The manufacturers are Atmel, Xicor,
>>and Microchip.  I found the results of my search quite amusing in one
>>sense-- all three vendors make essentially the same chip!
>
>   Caution!  In a couple of cases where I designed in a Microchip part,
>   a Xicor part would not function in the same socket with the same
>   software.  At the time I was in crunch mode and didn't have the time
>   to figure out why.  A quick scan of the data books did not point out
>   any obvious differences.  I had a chat with a Microchip technical
>   person on this and he agreed there was a difference but couldn't
>   remember what it was.
>
>   Perhaps someone has persued this in more detail and could post his/her
>   findings.
>
After posting my summary, I found an application note on Xicor's web page
stating that the three are indeed very similar, and giving a design process
to ensure compatibility in an application with any of the three chips.  I
don't know what the number of the app note is, but interested readers may
start their search at:

http://www.xicor.com/appnote/an12.htm

This is an unrelated app note, but will have a link to the app note index.

-Matt


 "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."

'Serial programmers and the 16c84'
1996\11\07@071929 by Byron A Jeff

face picon face
>
> Anyone know about using the 16c84 programmer in the microchi handbook at a
>  programmer for the other pics?  The timming needs to be changed,
> and the voltages.  Anyone done it? anyone have the program code to driving it?

Well I'd suggest either getting a copy of the PIC databook or taking a look
at the programming specifications pages on the microchip web page. A short
summary:

- All PICS require a nominal 13V programming voltage.

- 16C5X parts are parallel programmable only, 16CXX are parallel/serial, 12CXX
are serial only, and 17CXX use a somewhat complex parallel scheme.

- The 16C8X can be programmed by sending a "Begin Programming" command only
because it's program memory is EEPROM and does self timed writes. For every
EPROM part (i.e. every other PIC for now) requires either a "End programming"
command or a programming pulse. These pulses are nominally 100 uS
(microseconds). Also a program overpulse after the cell is programmed with
the value is required. Note this requires some rather high resolution timing,
whereas the 16C8X doesn't.

- The difference between production programmers and development programmers
is that the Vcc of development programmers is fixed (usually at 5V). If
you plan to run your PIC at another voltage (i.e. down to 2V) it's real
important that the program is verified at both ends of the Vcc scale because
what verifies at 5V may not work at 2V.

So the upshot is that any 16C8X programmer is probably going to need a high
resoltion timer and some software changes to program other 16CXX/12CXX parts
using the serial programming algorithm.

16C5X and 17CXX parts are a completely different animals that need parallel
programmers.

Hope this helps,

BAJ

1996\11\07@110152 by Giles L. Honeycutt

flavicon
face
Well Byron, thanks for the input, but what I am looking for is not how to do it,
but for someone that has done it.  The timming most likely needs to be done in
ASM. I have seen some programs and circuits on the internet that are very close,
or for a paticular pic.  I am wanting to make a low cost in-cir programmer
without
haveing to spend a week writing the program to drive the programmer.  I guess
what I realy need is some source code (ASM) for serial programming a pic with
the
printer port of a PC.  The circuit is simple.

Byron A Jeff wrote:
{Quote hidden}

--

 GiLes L. HoNEYcuTt
 *****************( Lost and confused )*********************
 @spam@gilesamispam_OUTspamix.netcom.com

'Serial port(s) on PIC'
1996\11\08@042839 by liebchen

flavicon
face
Mike Geipel wrote:
> > Perhaps we can nag & nag & nag & nag Microchip until they include a
> > second UART on chips like the 16C74. Doing it in software is a pain in
> > the butt. Am I alone, or is there anybody else that agree?
>
> Yes!  I *really* need a processor with an SPI channel and two UARTs.
> (I don't have the option of using a software UART...)
>
> I've heard that the 17C752 will have two UARTs, but not an SPI port.  :-(
> (Actually, it's too expensive for my application anyway.)
> I'd really love to see the 16C65A with a second UART.  Hint, hint.

Well, you may have heard the wrong. Look at the datasheet of the 17C752,
it has
two UARTS/SCI and one SSP (either I2C or SPI). So it has what you want!

regards Wolfram

--

+------------------------------------------------+
! Wolfram Liebchen, Forschungsinstitut fŸr Optik !
! .....liebchenspam.....ffo.fgan.de                    !
+------------------------------------------------+

'Serial Comms With the 16C84'
1996\11\11@053136 by efoc

flavicon
face
Hi all,

Firstly FLAME SHIELDS UP

Now I know this is probably a question that has been asked a thousand
times before but ..........

Does anybody have any idea how to code serial comms on the 16C84 and
more inportantly can tell me how, with code examples also please.

Thanks Peter.....

FLAME SHIELDS DOWN

--
==================================
= New Ideas come from those who  =
= didn't know it wasn't possible =
==================================

1996\11\11@113634 by icio culibrk

flavicon
face
SendTo: spampiclistKILLspamspammitvma.mit.edu

:: Baines <RemoveMEefocRemoveMEspamCELTIC.CO.UK> :: wrote:

> Does anybody have any idea how to code serial comms on the 16C84 and
> more inportantly can tell me how, with code examples also please.
>
> Thanks Peter.....
>

Check at http://www.arne.si/~mauricio/pic.htm, if you can't access the
web, please, let me know and I'll send that to you via e-mail.

Regards,

mauricio

1996\11\12@022345 by Werner Terreblanche

flavicon
face
Baines <KILLspamefoc.....spamKILLspamCELTIC.CO.UK> wrote:

> Does anybody have any idea how to code serial comms on the 16C84 and
> more inportantly can tell me how, with code examples also please.

Baines

 There are a few example routines of how to do this in assembler on the
Microchip
Web page, but if you know a little bit of C, then I can really
recommend the CCS PCM C compiler.  Just as an example, the code to
output "Hello World!" on the serial port would then be as simple as
this:


#include <16C84.H>
#fuses   HS,NOPROTECT,NOWDT
#use delay(clock=4000000)
#use rs232(baud=9600,xmit=PIN_B0,rcv=PIN_B1)

main()
{
  printf("Hello World!");
}


What could be simpler than that!   :)  :)

Rgds
Werner
--
Werner Terreblanche   Tel +27 21 7102251   Fax +27 21 721278
wterrebspam_OUTspamspam_OUTplessey.co.za (work) OR KILLspamwernerspam@spam@aztec.co.za  (home)

1996\11\12@030539 by efoc

flavicon
face
mauricio culibrk wrote:
>
> SendTo: @spam@piclistRemoveMEspammitvma.mit.edu
>
> :: Baines <efoc@spam@spamEraseMECELTIC.CO.UK> :: wrote:
>
> > Does anybody have any idea how to code serial comms on the 16C84 and
> > more inportantly can tell me how, with code examples also please.
> >
> > Thanks Peter.....
> >
>
> Check at http://www.arne.si/~mauricio/pic.htm, if you can't access the
> web, please, let me know and I'll send that to you via e-mail.
>
> Regards,
>
> mauricio

Hi, thanks for the tip but I CANOT get access to the web from this
terminal so could you please email me the asm code.

Thanks Peter
--
==================================
= New Ideas come from those who  =
= didn't know it wasn't possible =
==================================

1996\11\12@030746 by efoc

flavicon
face
Werner Terreblanche wrote:
{Quote hidden}

Thanks for the tip but I do not have access to this compiler, My first
language is 'C' but my budget does not run into a 'C' compiler, I'm not
that wealthy :)))), If you know of a good public domain or cheap
shareware compiler that will do the job then can you please point me at
it or even email me the asm code to do the job .


Thanks Peter



--
==================================
= New Ideas come from those who  =
= didn't know it wasn't possible =
==================================

1996\11\12@083035 by Martin Darwin

flavicon
face
At 08:07 AM 11/12/96 +0000, you wrote:

[munch...]

>Thanks for the tip but I do not have access to this compiler, My first
>language is 'C' but my budget does not run into a 'C' compiler, I'm not
>that wealthy :)))), If you know of a good public domain or cheap
>shareware compiler that will do the job then can you please point me at
>it or even email me the asm code to do the job .

Try http://personal.eunet.fi/pp/jokinen/ for a 16c84 C compiler. It has all of
the basic operations but no fancy stuff like serial communications but it's
free.

Try the following code for serial out.  I don't guarantee that it will work but
it should give you some ideas.  Note: you will have to manually edit the
asm("movwf      0x00"); line in the output file because the compiler doesn't
properly do asm("").  BTW the assembly line is needed because the compiler
doesn't compile x_byte = (x_byte >> 1); properly.  A few bugs but otherwise
a good compiler.

MD


char i;
char j;
char temp3;
char temp4;
char k;

/* This function sends data (through a RS_232 chip) to a computer */
/* at 4800,8,N,1. The data to be sent is the first parameter.     */
/* This function uses the counter variables: i and j              */

put_byte(x_byte)
char x_byte;
{
       /* Send the start bit */

       i=8;
       j=67;                           /* 136/2 for 4800 */
       clearbit(PORTA,0);
       do {} while(--j);               /* Fast loop */

       /* Send the data */

       do
       {
               x_byte = (x_byte >> 1);

               asm("movwf      0x00");         /*    Compiler bug fix */

               if (bitset(STATUS,0))
                       setbit(PORTA,0);
               else
                       clearbit(PORTA,0);
               j=65;                           /* 134/2 for 4800 */
               do {} while(--j);               /* Fast loop */
       }
       while(--i);

       /* Send the stop bit */
       /* If possible waste 4 cycles here */
       j=70;                           /* 139/2 for 4800 */
       setbit(PORTA,0);
       do {} while(--j);               /* Fast loop */

}

main()
{
       TRISA = 0;
       k=0;
       while(1) {
               send_byte(k);
               k++;
       }
}

interrupt()
{
       retint();

}

--
Martin Darwin   a.k.a Rambo [Ctf] (see you at quake.mgl.ca)
spams721099@spam@spamuottawa.ca             3rd year Computer Engineering
http://aix2.uottawa.ca/~s721099         University of Ottawa
Clan Ctf - http://www.geocities.com/TimesSquare/3541/

'Low power RTC chip with serial interface'
1996\11\17@063505 by Zemin Liu

flavicon
face
HI,

I have a project which needs a battery powered real-time clock (RTC) chip. The
chip should have a serial port that can be connected to a PIC16C54. Does any
one know where there is such kind of chip, its type and source? Any help is
greatly appriciated.

Z. Liu

1996\11\17@082849 by maud

picon face
Zemin Liu wrote:
>
> HI,
>
> I have a project which needs a battery powered real-time clock (RTC) chip. The
>  chip should have a serial port that can be connected to a PIC16C54. Does any
>  one know where there is such kind of chip, its type and source? Any help is
>  greatly appriciated.
>
> Z. Liu

Zemin,

I suggest you have a look at the Dallas DS1302.  This is an 8-pin
animal, it has very low current requirements, and is relatively easy to
talk to using a '54.

For further information on the device, check out their web site at
http//http://www.dalsemi.com/.

Good luck

John

1996\11\17@160617 by Don McKenzie

flavicon
face
Zemin Liu wrote:
> I have a project which needs a battery powered real-time clock (RTC) chip. The
>  chip should have a serial port that can be connected to a PIC16C54. Does any
>  one know where there is such kind of chip, its type and source? Any help is
>  greatly appriciated.

http://www.labyrinth.net.au/~donmck/rtc.html
has pointers to PIC code examples and data sheets on the Panasonic
NJU6355 and Dallas 1202/1302 Real Time Clocks.

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

SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
EASY PIC'n Beginners Guide to using PIC 16/17 MicroChip products.
MEL PicBasic Compiler. Programmers from 15 USD.  Pic-Axe(tm) A New Tool.

1996\11\18@002934 by tjaart

flavicon
face
Don McKenzie wrote:
>
> Zemin Liu wrote:
> > I have a project which needs a battery powered real-time clock (RTC) chip.
The
> >  chip should have a serial port that can be connected to a PIC16C54. Does
any
{Quote hidden}

Try Philips 8583. It's a IIC device. Works well.
--
Friendly Regards

Tjaart van der Walt
______________________________________________________________
|  Another sun-deprived R&D Engineer slaving away in a dungeon |
|WASP International GSM vehicle tracking and datacomm solutions|
|           +27-(0)11-622-8686 | http://wasp.co.za             |
|______________________________________________________________|

1996\11\18@021446 by nigelg

flavicon
picon face
In message  <EraseME9611171134.AA21186spamKILLspamzsu.edu.cn> PICLISTEraseMEspamMITVMA.MIT.EDU writes:

> I have a project which needs a battery powered real-time clock (RTC) chip. The
>  chip should have a serial port that can be connected to a PIC16C54. Does any
>  one know where there is such kind of chip, its type and source? Any help is
>  greatly appriciated.

I'm currently developing a genlocked time display for video camera signals,
the clock chip I'm using is the Philips PCF8583P. This is an eight pin I2C
chip, and also includes 256 bytes of EEPROM which can be used for storage.

I've not got it hooked up to a PIC yet, but I've got it connected to my PC,
and with the power disconnected it consumes 2.4uA from a 2.4v nicad.

In the UK it's available from RS Components, or many other sources. It's also
used in a number of VCR's, in particular Grundig ones (with a battery, so the
clock is always running), and in a Sharp TV/VCR (with a capacitor, only gives
a limited backup).

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : EraseMEnigelgspamspamBeGonelpilsley.demon.co.uk     |
       | Lower Pilsley   | Web Page : http://www.lpilsley.demon.co.uk |
       | Chesterfield    |                                            |
       | England         |                                            |
       \--------------------------------------------------------------/

1996\11\18@132849 by Matthew Mucker

flavicon
face
At 07:34 PM 11/17/96 +0800, you wrote:
>HI,
>
>I have a project which needs a battery powered real-time clock (RTC) chip. The
> chip should have a serial port that can be connected to a PIC16C54. Does any
> one know where there is such kind of chip, its type and source? Any help is
> greatly appriciated.
>
>Z. Liu
>
Dallas Semi makes ALL KINDS of realt time clocks, with various features and
whatsits.  Many can be battery backed for 10 years with a lithium battery
(uh... I think... this is from memory).  Call Dallas and get a databook.

-Matt

1996\11\18@133917 by Shawn Ellis

flavicon
face
>>
>>I have a project which needs a battery powered real-time clock (RTC) chip. The
>> chip should have a serial port that can be connected to a PIC16C54. Does any
>> one know where there is such kind of chip, its type and source? Any help is
>> greatly appriciated.
>>
>>Z. Liu
>
Phillips semiconductor makes a low power clock/calendar chip with an I2C
interface, I;ve used this chip with great success backed-up with a lithium
battery.  Ask for Phillips' I2C data book/catalog.

1996\11\20@145451 by Juan Jose Abba

flavicon
face
I also have the need to keep a clock running using a minimum of battery
current, and I was planning to go mostly software for the clock, instead of
a dedicated chip.

my plan is
1>install a 32.768 KHz xtal to T1osc pins.   I am looking to the 16C74 but
other chips have same capability.
2>control the clock increments with a Timer one interrupt routine.
3>put the pic to sleep during the time was not processing data.
During this period the 32KHZ oscillator will remain working, providing an
interrupt and wake up of the PIC, every desired period of time , up to two
seconds, ( see microchip AN580).

the interrupt routine will be something like;


int mili_sec,sec,min,hour,day,month,clock_flag;
#INT_TIMER1
TIMER1_INT_HANDLER()
{

Timer_1_high = 0x80;  // one second interrupt periods
                     // this will be the adjustment to compensate
                     // for slow / fast xtals
if (++sec>=60)
{
sec =0;
if  (++min>=60)
   {
     min = 0;
     if (++hour>=24)
      {
      hour = 0;
      ++day;
      IF ((day>28)&&(month==2))    // requires more work for leap year

      day = 32;
          IF((day>30)&&(((month<8)&&(!BIT_TEST(month,0)))
          ||((month>7)&&(BIT_TEST(month,0)))) )
          day = 32;
             IF ( day >31)
              {
              day = 1;
                if (++month>12)
                month = 1;          // year update not included yet
               }
            }
         }
     }

              {
          clock_flag = true;   // clock_flag true will advise
                                // main routine to display clock
                               // , clear flag and set pic to sleep.
              }
}

appears to me that having the code space this approach should be cheaper
than a dedicated chip.
juan


{Quote hidden}

1996\11\22@053536 by John Payson

picon face
> my plan is
> 1>install a 32.768 KHz xtal to T1osc pins.   I am looking to the 16C74 but
> other chips have same capability.
> 2>control the clock increments with a Timer one interrupt routine.
> 3>put the pic to sleep during the time was not processing data.
> During this period the 32KHZ oscillator will remain working, providing an
> interrupt and wake up of the PIC, every desired period of time , up to two
> seconds, ( see microchip AN580).
>
> appears to me that having the code space this approach should be cheaper
> than a dedicated chip.

This approach has many advantages; among them: the potential ability to
use a cheap RC oscillator as your main CPU clock.  For applications that
will be periodically waking from sleep, an RC clock can be extremely des-
irable because unlike a crystal it can start up nearly instantly.

Unfortunately, according to Microchip's errata sheet for the 16C74, that
oscillator really isn't as useful as you'd like.  If memory serves...

[1] When the main oscillator is running, it can sometimes garble the
   oscillation of T1.

[2] When T1 is running, the part uses an excessive amount of power (which
   pretty much defeats the purpose of sleep mode).

If Microchip produced a chip which fixed these problems, added a gray-counter
to the UART (allowing much finer baud-rate control and rendering the BRGH
bug irrelevant), included a built-in programmable/nudgeable RC, and was nice
and cheap... well, I'd sure like 'em.

By gray counter, btw, I mean a counter which uses graycode step patterns in
a feedback circuit to allow fractional counting.  For not much more logic
than a self-reloading timer, you could have a counter which would output
2^K [K=0..6] pulses for every 256-N [N=0..127] put in.  Such a timer could
generate any baud rate within its range, within 1%; if its range needed to
be extended, a simple prescalar would suffice.  Given the combination of
such a baud-rate generator, a 32KHz crystal, and an RC oscillator, it would
be practical to have a device sleep while waiting for serial input and be
able to grab the first byte.  Would anyone else find such a device interest-
ing?


'Serial, In-circuit programming'
1996\12\10@042558 by Gregg Kricorissian
flavicon
face
Dear PIC'ers

As usual I have this problem ... I haven't seen anything written about
serial in-circuit programming of the 16LC84, aside from the little bit in
the data book on page 52.  I hadn't paid much attention to it until
recently; that is, now that I know I have to use an SOIC package device in
the final product design.

I see in-circuit programming to be very advantageous, since it will allow us
to load a routine for hardware verification during manufacturing test, and
then re-program the 16LC84 with the operating code ... all without
disturbing the hardware.

Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
the Microchip CD) about considerations for in-circuit programming: neither
how one should size the isolating resistors shown on page 52, nor the
availablilty of a commercial serial programmer.  Is it one of those things
that's "left as an exercise for the reader", or is there a product already
available to do the job?

Because of time constraints, I'd rather buy than build one, but building is
still do-able.  Perhaps it's nothing more than building a driver/buffer
stage between my Picstart and the application circuit?  Does anyone out
there have any good pointers for in-cicuit programming?

Many thanks,
... Gregg

1996\12\10@070150 by Jim Robertson

flavicon
face
At 04:10 AM 12/10/96 -0500, you wrote:
>Dear PIC'ers
>
>As usual I have this problem ... I haven't seen anything written about
>serial in-circuit programming of the 16LC84, aside from the little bit in
>the data book on page 52.  I hadn't paid much attention to it until
>recently; that is, now that I know I have to use an SOIC package device in
>the final product design.


Snip...

{Quote hidden}

Gregg,

It is starting to be a little dated now, but you can download the
documentation for my PP1 programmer. It has a chapter on ISP and what I
know about it back then. You may find the knowledge contained of value,
then again you might not....

It is in the FTP section of my web grossly neglected web site at.

http://www.labyrinth.net.au/~newfound

Feel free to pick my brians (within reason) or even to buy one of my
programmers (says me very squeamishly...) :-)


Regards,

Jim

1996\12\10@122617 by John Payson

picon face
> As usual I have this problem ... I haven't seen anything written about
> serial in-circuit programming of the 16LC84, aside from the little bit in
> the data book on page 52.  I hadn't paid much attention to it until
> recently; that is, now that I know I have to use an SOIC package device in
> the final product design.

In-circuit programming is wonderful, if you are aware of its constraints.

> I see in-circuit programming to be very advantageous, since it will allow us
> to load a routine for hardware verification during manufacturing test, and
> then re-program the 16LC84 with the operating code ... all without
> disturbing the hardware.

Great for debugging (before and after production) too...

> Trouble is I can't find anything in my MPLAB or Picstart PLus manuals (or
> the Microchip CD) about considerations for in-circuit programming: neither
> how one should size the isolating resistors shown on page 52, nor the
> availablilty of a commercial serial programmer.  Is it one of those things
> that's "left as an exercise for the reader", or is there a product already
> available to do the job?

I don't know about commercial serial programmers; I know I've built two of
my own, and incorporated circuitry directly onto the boards for a couple
other products.  As for software, I'm afraid I don't know; my good stuff I
developed for work, and I don't know if I can give it away.

As for the isolation resistors, that really depends upon your application;
if you are using RB6 and RB7 for output only, you can skip the resistors
entirely (though you need to ensure that whatever they control won't "mind"
if these mins have signals on them during programming).  If they are inputs
only, the resistors can be large, subject only to the constraint that large
values may slow down the response of the port.  The final caveat to consider
is that if the PC is to be left connected you may want to have it wired so
as to be able to "tri-state" itself from those two pins or else use a relay
on your programmer to disconnect those pins entirely.

> Because of time constraints, I'd rather buy than build one, but building is
> still do-able.  Perhaps it's nothing more than building a driver/buffer
> stage between my Picstart and the application circuit?  Does anyone out
> there have any good pointers for in-cicuit programming?

I wouldn't be surprised if the PicStart could handle ISP'ing easily; I've
never done it.  One concern I'd have regarding your application, however,
is that I'd suggest if possible using RB6 and RB7 for outputs only (or else
for nothing at all) and putting moderately large (e.g. 47K) resistors in
series with the RB6 and RB7 wires.  Since you're using the LC part, it sounds
as if your voltage won't always be at a nice even +5; when programming, you
should have VDD at +5, but you should also verify your part at whatever volt-
age it will be running in the "real world".

1996\12\10@131236 by Alberto Alonso (Albund)

picon face
In message <RemoveME2.2.32.19961210091040.00a49eecRemoveMEspamTakeThisOuTalfred.ccs.carleton.ca>, grkricor@cc
s.carleton.ca writes:
>Dear PIC'ers
>

[Deleted stuff]

>Because of time constraints, I'd rather buy than build one, but building is
>still do-able.  Perhaps it's nothing more than building a driver/buffer
>stage between my Picstart and the application circuit?  Does anyone out
>there have any good pointers for in-cicuit programming?
>
>Many thanks,
>... Gregg

I'm currently developing a serial programmer. The following will be some
of its features:

* Still the power from the computer. (No damm adaptor needed).
* Connects to the serial port.
* Smallest desing posible. I'm trying to fit it into the D-sub case.
* Modularity. Have the posibility of connecting a 5 pin cable or
adaptors with ZIF sockets.
* Production quality. Verify the PIC for all ranges of voltages (this is
just a wish which probably won't be able to do, at least on the size
that I want).
* RS232 comm capabilities? I was planning on using a MAX232 chip to
handle serial communications using pins B6 and B7 (since most of my
applications use the computer for communications). This might be
implemented in a module due to size constraints.
* Free??? My design will probably be free. I will plan on selling the
kits to put it together or just sell the board (this depends on whether
there is enough interest to send it to a production place).

Anyway, the desing should be complited by mid Jan or Feb. Let me know if
you guys are interested since that would make me do it faster and also
how many of you would like to purchase at least the board (so that I
send it to a production place).

Cheers,

Alberto

1996\12\11@083754 by Jens Dyekjfr Madsen

flavicon
face
Alberto Alonso (Albund) wrote:
>
> In message <2.2.32.19961210091040.00a49eecTakeThisOuTspam@spam@alfred.ccs.carleton.ca>,> grkricor@cc
{Quote hidden}

Take a look at
  http://www.ebar.dtu.dk/~c888600/newpic.htm
or
  http://www.gbar.dtu.dk/~c888600/newpic.htm

Programmer is not production quality. But it meets RS232 standards.
Vpp is 13V and Vcc is stable at 5.1V during read/program.

Regards,
Jens

1996\12\11@094934 by Jens Dyekjfr Madsen

flavicon
face
Gregg Kricorissian wrote:
{Quote hidden}

Take a look at
  http://www.ebar.dtu.dk/~c888600/newpic.htm
or
  http://www.gbar.dtu.dk/~c888600/newpic.htm

Programmer is not production quality. But it meets RS232 levels.
Programming voltage is 13V and Vcc is 5.1V during program/read.

Regards,
Jens Dyekjfr Madsen

'Serial transmission'
1996\12\11@223448 by techccs

flavicon
face
Hello,

   I need to know the all of the serial standards and what distances
they are capable of transmitting reliably.  I want to use this with a
16C84.  I believe RS485 can transmit a great distance, but what
distance?

Brian

'fast serial memory?'
1996\12\13@120437 by Stephen Bannasch

flavicon
face
I'm looking for a type of data storage memory which can be accessed serialy
while still written to and read from at speeds up to 10K bytes per second.
I need a minimum storage of 8K.  A write speed of 50K would be great.

The application is in a data interface/logger which can log data slowly as
well as capturing medium-speed signals.

EEPROM or Flash would be nice but is not necessary because the system will
operate from a battery.

Any ideas?



--Stephen Bannasch
 Director of Technology, Concord Consortium
 37 Thoreau St., Concord, MA  01742
 tel: 508 371 3477, main number: 508 369 4367, fax: 508 371 0696
 stephenTakeThisOuTspamspamBeGoneconcord.org, http://www.concord.org

1996\12\13@130306 by : pklammer

flavicon
face
> Date: Fri, 13 Dec 1996 12:05:31 -0500
> From: Stephen Bannasch <spamstephenTakeThisOuTspamCONCORD.ORG>
> Subject: fast serial memory?
>
> I'm looking for a type of data storage memory which can be accessed serialy
> while still written to and read from at speeds up to 10K bytes per second.
> I need a minimum storage of 8K.  A write speed of 50K would be great.

Ramtron FRAM is available in I2C (100kbps or 400kbps) and SPI (2Mbpx)
interfaces, in 2KB packages.  The SPI arrangement would cost you
3 common bus pins (MOSI, MISO, SCK) plus one select (CS*) per chip.
There is an addressable variety of the I2C part that lets you put up
to 8 packages on the same bus, which costs you just 2 pins (SCL, SDA).

Try http://www.ramtron.com, or (800)545-FRAM; I have purchased retail in the
past from Lange Sales, (303)795-3600.

> --Stephen Bannasch
>   Director of Technology, Concord Consortium
>   37 Thoreau St., Concord, MA  01742
>   tel: 508 371 3477, main number: 508 369 4367, fax: 508 371 0696
>   .....stephenspamspamBeGoneconcord.org, http://www.concord.org
>

1996\12\17@034227 by Wolfram Liebchen

flavicon
face
At 12:05 13.12.96 -0500, Stephen wrote:
>I'm looking for a type of data storage memory which can be accessed serialy
>while still written to and read from at speeds up to 10K bytes per second.
>I need a minimum storage of 8K.  A write speed of 50K would be great.
>

Hi Stephen,

you could use a 3-wire to bytewide converter (Dallas DS1280) and connect a
standard SRAM or a nonvolatile SRAM (Dallas DS1230).
This gives you SPI-bus access to a large RAM-size.

Look at http://www.dalsemi.com/DocControl/index.html
there is the information.

regards,

Wolfram



+-----------------------------------------------------+
| Wolfram Liebchen                                    |
| Forschungsinstitut fŸr Optik, TŸbingen, Deutschland |
| .....liebchenTakeThisOuTspamEraseMEffo.fgan.de                         |
+-----------------------------------------------------+

1996\12\17@093730 by Jens Dyekjfr Madsen

flavicon
face
Wolfram Liebchen wrote:
{Quote hidden}

Serial sampling with DRAM:
     !4x sample clock
     !                    256Kx8 DRAM-module
*----------*                   *--------*
!20-bit  A0!------------------>!/CAS    !
!counter   !  *------------*   !        !
!        A1!--! 20ns delay !-->!/RAS    !
!          !  *------------*   !        !/--\
!       ...!                   !  D0..D7!     Din/
!          !                   !        !\--/ out
!          !------------------\!        !
!  A10..A19!                   !A0..A8  !
!          !------------------/!     /WE!---- R/W
!          !                   !     /OE!---- /OE
*----------*                   *--------*

Regards,
Jens Dyekjaer Madsen

'Serial sampling.'
1996\12\17@112503 by Madsen, Jens

flavicon
face
Serial sampling with DRAM used for video sampling:

     !4x sample clock
     !                    256Kx8 DRAM-module
*----------*                   *--------*
!2044    A0!------------------>!/CAS    !
!counter   !  *------------*   !        !
!        A1!--! 20ns delay !-->!/RAS    !
!          !  *------------*   !        !/--\
!          !                   !  D0..D7!     Din/
!          !                   !        !\--/ out
!          !------------------\!        !
!   A2..A10!                   !A0..A8  !
!          !------------------/!     /WE!---- R/W
!          !                   !     /OE!---- /OE
*----------*                   *--------*

Counter counts to 511*4. The memory contain 511*512 samples.

Regards,
Jens Dyejaer Madsen

'Serial transmission'
1996\12\17@234345 by Luiz Marques

flavicon
face
Brian if you have www access you can get the application notes AN-409 and
AN-759 from National Semi. These are related to RS-485.

You can go via http://www.natsemi.com

However Maxim makes devices with 1/8 unit-load input impedance that
guarantees up to 256 transceivers on the bus. ie MAX1483


>     I need to know the all of the serial standards and what distances
> they are capable of transmitting reliably.  I want to use this with a
> 16C84.  I believe RS485 can transmit a great distance, but what
> distance?

Up to 4000 ft.

> Brian

I hope to make a future project about home automation using a shielded
twisted cable runing RS-485 into the electric conduits.

Good luck and Merry Christmas to all PicListers,
Luiz Marques

1996\12\18@091835 by D. R. Chicotel

flavicon
face
At 01:47 AM 12/18/96 -0800, you wrote:

>Brian if you have www access you can get the application notes AN-409 and
>AN-759 from National Semi. These are related to RS-485.
>
>You can go via http://www.natsemi.com
>
>However Maxim makes devices with 1/8 unit-load input impedance that
>guarantees up to 256 transceivers on the bus. ie MAX1483
>
>

I looked up the app-note for MAX1483.  It looks very much like what I want.
I want a multi-drop bus with multiple transceivers over large distances too.

My question is this:  How do you keep the network nodes from talking at the
same time?  I understand how i2c works to resolve this with start and stop
conditions, or how RTS, CTS handshaking works, but the MAX1483 doesn't have
a clock  line or any other handshaking lines, just two twisted pair data
lines.  Am I missing something or
am I just dense?

Thanks.  DRC

1996\12\18@094642 by Byron A Jeff

face picon face
{Quote hidden}

Neither. That layer doesn't address flow control or contention issues. It's
the responsibility of the layer above: i.e. software. Some suggestions:

1) Primary-secondary polling. Have a master unit poll the secondaries.
Secondaries can only talk when spoken to. Not real good if real time
response needed.

2) Virtual token ring. Pass around a token, the node that has the token can
talk. When done pass the token to the next node. Again not real good for
real time response.

3) 1) with attention. Use a second twisted pair for an attention line so
that the seondaries can signal the primary for attention. Can use a timeout
scheme to prioritize either the type of activity that need attention or
to prioritize the nodes.

Bottom line: contention becomes a software issue. A separate clock proobably
isn't a good idea due to the propagation delays over very long distances.

In this instance, speed kills. If you keep it slow, then any of the above
techniques can work.

BAJ

'Serial sampling.'
1996\12\18@105707 by Madsen, Jens

flavicon
face
Madsen, Jens wrote:
{Quote hidden}

The Idea is to use a 511 counter combined with the internal 512 counter.
This makes 511*512 = 261632 samples. Max clock is 7.6MHz with 70ns DRAM.
Minimum clock is 64KHz, but most LPT-ports handles more than 100KHz(486).
The counter may be asynchronous since the DRAM's contain internal latch.
The circuit is not complete but only to ilustrate that it is very simple
to use DRAM - and I think you need more components if you use SRAM.

Regards,
Jens Dyekjaer Madsen

'Need AN547 "Serial Port Utilities" for 16C63'
1996\12\29@180214 by Brooke

flavicon
face
Hi:

I would like to use the interupt driven serial port transmit &
receive like in AN547 but the app note is written for 17C42.

Has anyone converted this into code for a 16CXX chip that has
the USART module?

Happy Holidays,
Brooke


'Serial waitfor with CCS C'
1997\01\05@185412 by MSI: Sean Cunningham
flavicon
face
Can anyone show code examples for CCS C for how to implement a waitfor
serial routine, as in the following PBASIC Code:

serin 2,N9600,("aba"),w5,w6,w7

[waits for the characters "aba" and then retrieves the next 3
characters].

1997\01\06@065035 by Chaipi Wijnbergen

flavicon
picon face
On Sun, 5 Jan 1997, MSI: Sean Cunningham wrote:

> Can anyone show code examples for CCS C for how to implement a waitfor
> serial routine, as in the following PBASIC Code:
>
> serin 2,N9600,("aba"),w5,w6,w7
>
> [waits for the characters "aba" and then retrieves the next 3
> characters].


How about something like :


#use Delay (Clock=4000000)
#use RS232(Baud=9600, Xmit=PIN_B7, Rcv=PIN_B6)
#include <stdio.h>


main ()
{
   byte ucState = _DidNotRecieveAnythingYet;
   /*-------------------------------------------------------------------*\
   | Loop forever                                                        |
   \*-------------------------------------------------------------------*/
   do
     {
      /*----------------------------------------------------------------*\
      | Check If need communication                                      |
      \*----------------------------------------------------------------*/
      if (kbhit())
         {
          /*------------------------------------------------------------*\
          | Get a character                                              |
          \*------------------------------------------------------------*/
          ucSerialInput1 = getc();
          switch (ucState)
            {
             case _DidNotRecieveAnythingYet:
                  if (ucSerialInput1 == 'a')
                      ucState = _RecieveFirstA;
             break;
             case _RecievedFirstA:
                  if (ucSerialInput1 == 'b')
                      ucState = _RecieveB;
                  else
                      ucState = _DidNotRecieveAnythingYet;
             break;
             case _RecievedB:
                  if (ucSerialInput1 == 'a')
                     {
                      w5 = getc();
                      w6 = getc();
                      w7 = getc();
                      ... do something ...
                      ucState = _DidNotRecieveAnythingYet;
                     }
             break;
         }
    }
}


Chaipi

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : STOPspamchaipiEraseMEspamtohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

'Casio Calculator Serial Port'
1997\01\08@135746 by Tim Kerby

picon face
Has anyone ever used the serial port on a casio graphics calculator?  It is
a small headphone jack.  I think a large storage bank of programs and graph
data would be neat or by using the screendump as a portable terminal!

I would be interested to hear from anyone.

Thanks

Tim

'Serial LCD Interface'
1997\01\13@085707 by Ben Wirz

flavicon
face
Hello Everyone,

    Wirz Electronics has a new product that we would like to introduce to
everyone.

    The Serial LCD Interface (SLI) is a self contained display unit with
TTL and RS232 compatible asynchronous serial inputs. The unit is designed to
allow the engineer, technician, or hobbyist to integrate it into a circuit
with a minimum of interfacing requirements.  Jumperless control and
automatic detection of data rates eliminates difficult interfaces and
complex controlling code.  Low cost and line-powering features make it
suitable for use in commercial products.  With both alphanumeric and
hexadecimal display mode, SLI is a powerful debugging and display tool for
many applications.

Features:

  Jumperless Control/Operation
  Wide Baud Range, 30 to 125,000 bps
  RS232 and TTL Compatible
  RS232 Serial Powered *
  Auto-Baud Rate Detection
  ASCII and Hex Display Mode
  D Sub 9 Female Connector (DB-9) and IDC Connector
  Allows direct control of the LCD functions and features
  Designed for all 8x1 to 40x2 character HD44780 controlled
  LCDs with 14x1 pin connectors

Suggested Retail Price for a complete SLI Kit: $25.00 (US)
Suggested Retail Price for a complete SLI Kit and 16x2 LCD: $30.00 (US)

More information can be found at:  http://wirz.com/sli/

An Adobe Acrobat SLI Technical Reference is available at:
ftp://wirz.com/Serial_LCD/sli.pdf

Distributors:

Australia
DonTronics
PO Box 595, Tullamarine 3043
Tel: +613 9338-6286 Fax: +613 9338-2935
http://www.labyrinth.net.au/~donmck/

South Africa
Interface Products (Pty) Ltd.
PO Box 15775, Doornfontein 2028
Tel: +27 (11) 402-7750 Fax: +27 (11) 402-7751
http://www.ip.co.za/ip/

United States
Wirz Electronics
6100 Pershing 2-A, St. Louis MO 63112
Tel: +1 (314) 862-3370 Fax: +1 (314) 862-3371
http://www.wirz.com/


Sincerely,

Ben Wirz
Wirz Electronics
benspamBeGonespamwirz.com
Ben Wirz                For Microchip PIC Products including the Simm Stick
                       development system and Easy PIC'n Book, as well
Wirz Electronics        as Motor Control, Polaroid Sonar Units, and more
ben@spam@spamwirz.com            Hobbyist Robotic & Electronic Supplies, visit:
                       http://www.wirz.com/

'Olivetti D1010 Electronic Notebook serial interfac'
1997\01\17@002501 by Dennis Frost

flavicon
face
Hi everyone

I have a Olivetti D1010 Electronic Notebook. (Personal diary)
It has a serial interface that I want to use to backup the data it holds.
Does anyone know what protocol etc they use?

Thanks
       Dennis

____________________________________________________
FROST - Electronic Design, Manufacture & Consulting.
Dennis Frost
Tel:   +27 331 965125
Cel:   +83 2275216
Email: spam_OUTdennis.frostspamspampixie.co.za
Pietermaritzburg, South Africa
____________________________________________________

PS Anyone looking for someone in the hardware/software development fields,
I am available. I intend leaving South Africa for the West coast of the US
early this year.

'serial comms'
1997\01\17@012040 by TONY NIXON 54964

flavicon
picon face
I was wondering if anyone knows of a simple program around that would
allow basic 'talking' on the PC serial port using DOS.

I'm using Windows Terminal program, but am having intermittant
trouble talking to it using a PIC74.

Any help appreciated

Tony


Just when I thought I knew it all,
I learned that I didn't.

1997\01\17@134357 by James and Iliana Holbrook

flavicon
face
At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>
>I'm using Windows Terminal program, but am having intermittant
>trouble talking to it using a PIC74.
>
>Any help appreciated
>
>Tony
>
>
>Just when I thought I knew it all,
>I learned that I didn't

Tony,
       I use a program called Maxterm.. it's a dos comm program that was
designed for talking to microcontrollers. It has several nice features that
come in handy. I would be glad to email it to you.
                                       James

1997\01\17@162435 by Michael S. Hagberg

flavicon
face
At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>

i alway liked procomm, there is a shareware version that i often
use on customers systems to check modems or link to other
serial devices.

michael

1997\01\17@180144 by Eduardo J. Martinez Velez

flavicon
face
part 0 594 bytes

       I use a program called Maxterm.. it's a dos comm program that was
designed for talking to microcontrollers. It has several nice features that
come in handy. I would be glad to email it to you.
                                       James


----------------------------
Thanks for all - Mil gracias
----------------------------
Eduardo Jorge Mart’nez VŽlez
a   Asesoria
&   &
 s   Sistematizacion
INET: ejmvspam_OUTspamRemoveMEsatlink.com
 spam73070.3653spamBeGonespamcompuserve.com
CServe: 73070,3653
2000-Rosario-SF-Argentina
TelFax: (54)(41)254561
Tel: (54)(41)8804
----------------------------

1997\01\17@215133 by John Payson

picon face
> At 05:13 PM 1/17/97 GMT+1100, you wrote:
> >I was wondering if anyone knows of a simple program around that would
> >allow basic 'talking' on the PC serial port using DOS.
>
> i alway liked procomm, there is a shareware version that i often
> use on customers systems to check modems or link to other
> serial devices.

I used to use ProComm, but I nowadays prefer to use COMMO.  I find that
COMMO--despite being much smaller than the others (less than 64K for all
needed file, not counting help or docs) includes a full scripting language,
some internal upload/download protocols (Xmodem and Ymodem variants) as
well as the ability to auto-launch a Zmodem receive upon seeing the H:\pic\efo~3.txt
indicator.  In addition, it includes a built-in text editor and scrollback
buffer (64K limit on each); the scrollback buffer logs what scrolls off
the screen (so it often yields decent results even in cases where other
programs do not; if a program displays "MORE" and then upon receiving a
keystroke overwrites that with the continued display, the "MORE" will not
appear in the scrollback) and the program can log to a file either [1]
Everything that comes in the port, or [2] Everything that scrolls off
the screen.

Really great program.

1997\01\18@153945 by Dorin Dogaroiu

flavicon
face
>At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>
>I'm using Windows Terminal program, but am having intermittant
>trouble talking to it using a PIC74.
>
>Any help appreciated
>
>Tony
>

- Try using procomm for DOS. It is very good.

- check the software which is delivered with new modems cards (
Commit, Bitcom ...) because they have also dirrect connection option.

- devellop your own. There is a Turbo Pascal shareware library for
communication functions ( by Marshall Software) which has also
examples of terminal programs, so you can configure the software on
your own whishes. If you are interested on this library, I can mail
it to you.

                                       Dorin

------------------------------------
Dorin Dogaroiu
Research Institute for Computers
Bucarest, Romania
E-mail  :  spamdogaroiudRemoveMEspampcnet.pcnet.ro
          KILLspamddorinspam_OUTspamspam_OUTkappa.ro
------------------------------------

1997\01\18@234826 by myke predko

flavicon
face
James,

What are the features in Maxterm that makes it well suited for talking to
microcontrollers?

myke
{Quote hidden}

A New Era in Computing:

HAL 9000

Born January 12, 1997 - Urbana Illinois

1997\01\19@114640 by James and Iliana Holbrook

flavicon
face
At 11:45 PM 1/18/97 EST, you wrote:
>James,
>
>What are the features in Maxterm that makes it well suited for talking to
>microcontrollers?
>
Myke,
       The features that I like are control of the DTR & RTS lines,
download pacing with the pace character settable from the interface, scroll
back buffer, intergrated editor ( you can make quick changes to code and
download it without changing programs ), the baud rate is settable from the
interface, there is also a character redefinition mode that gives you a hex
display and an ascii display of your information at the same time ( very
handy for memory dumps ), it's small, quick, easy to use and runs great in a
DOS window in Win 3.11 or Win95.
       And maybe the nicest feature is that it's free.

       I hope that answered all your questions.
                                               James

1997\01\19@233012 by tjaart

flavicon
face
James and Iliana Holbrook wrote:
>
> Tony,
>         I use a program called Maxterm.. it's a dos comm program that was
> designed for talking to microcontrollers. It has several nice features that
> come in handy. I would be glad to email it to you.
>                                         James

Can it monitor COM1 & COM2 simultaneously? Geez, I'd give my eye teeth
for a nice terminal prog that displays in two columns, and where you can
define 'return carriage' characters. Something like this :
------------------------------------------------------------
baudrate = XXXX 8N1           | baudrate = YYYY 8N1
return = ASCII 13             | return = ASCII 26
------------------------------------------------------------
This text comes from the PIC  |
                             |This text comes from the 'oth
                             |er' side of the comms
blah blah blah                |
                             |blah blah blah
blah blah blah                |
                             |blah blah blah

et cetera....


--
Friendly Regards

Tjaart van der Walt
______________________________________________________________
|  Another sun-deprived R&D Engineer slaving away in a dungeon |
|WASP International GSM vehicle tracking and datacomm solutions|
|+27-(0)11-622-8686 |  http://wasp.co.za   | @spam@tjaartspamspamspam_OUTwasp.co.za |
|______________________________________________________________|

1997\01\20@035138 by Chaipi Wijnbergen

flavicon
picon face
On Mon, 20 Jan 1997, Tjaart van der Walt wrote:

> Can it monitor COM1 & COM2 simultaneously? Geez, I'd give my eye teeth
> for a nice terminal prog that displays in two columns, and where you can
> define 'return carriage' characters. Something like this :
> ------------------------------------------------------------
> baudrate = XXXX 8N1           | baudrate = YYYY 8N1
> return = ASCII 13             | return = ASCII 26
> ------------------------------------------------------------

You need the DSCOPE.EXE program from http://www.ednmag.com, I got it from that
web site. I looked again and was unable to find it any more, It was
shareware, I think that I can send it to does individuals that will email
directly yo me.

Chaipi

'Serial port IRQ clashes'
1997\01\20@110140 by Jan van der Watt

flavicon
face
Sorry for being a little slow.....

I vaguely remember a request for (decent) PC based serial comms programs and
the reason for the request was something to do with Windows being
intermittent...

(In all cases the OS is Lose95, I mean Win95, and I used both Hyperterminal
and a VC++ 4.0 demo TTY program to test this with)

Well, I've just spent the whole day staring at RS232 signals wondering why
the hell the PIC wasn't getting its message throught to the PC. Then I tried
it on my uncomplicated LAPTOP.  It seems that when there is more than one
COM port on the same IRQ, you really require the flow control signals to
operate in accordance with the RS232 standard (am I making sense?).

On my PC I have 4 COM ports, and I can set the IO card to what I want, but
95 insist that COM3 stay on IRQ4, and COM4 on IRQ5. (Useless info : When I
stick a modem on COM4 it talks to it, but the modem response isn't seen.) If
however, I stick it on COM3, the same IRQ as COM1, my mouse, using the modem
makes the mouse hang up. If I stick PIC comms there, the mouse hangs up, but
the PIC talk isn't received unless you move the mouse !

On my laptop, there is only a COM1 (trackball is COM2). Sticking the PIC
there works all the time without fail.

Has anyone got any comments on how/why/whether my deductions are incorrect ?

Jan van der Watt
[I came, I saw, and what a party we had!]

1997\01\20@115930 by Christopher Zguris

picon face
At 06:01 PM 1/20/97 +0200, you wrote:
[stuff on 4 com ports deleted]

From memory, Com1 & Com3 share an IRQ, and Com2 and Com4 share an IRQ. So,
two devices that are always active (or - at least - require handshaking?)
won't work on the same IRQs (modem and mouse on com1 and com3 won't work,
for example). However, under Win 3.1 the IRQ is _settable_ for each com port
(under ports, click on the port, then click on Advanced). Doing that, you
should be able to move the conflicting Com ports to another IRQ (I know the
modem I installed supports IRQs in addition to the standard ones). I haven't
tried it (much), but doing that should allow for 4 working Com ports. The
only potential problem is an IRQ conflict, but that's easy to troubleshoot
(time-consuming, but not difficult). Once you've figured out what IRQs and
base addr's go with what _write_it_down_. I upgraded a motherboard and had
to move all sorts of stuff around for the ethernet card, modem, etc. Royal
pain in the butt, but us PC-users _like_ pain.

>Jan van der Watt
>[I came, I saw, and what a party we had!]
>
>

Chris

   ======================================================================
         Christopher Zguris  -  KILLspamczgurisspamKILLspaminterport.net  -  Uhhh, Ear?
                     1991 VFR 750 (with aspalt detailing)
                             IVFROC, HSTA, HRCA
      Lord, grant me the serenity to accept the things I cannot change,
       the courage to change the things I can, and the wisdom to hide
     the bodies of those people I had to kill because they p***ed me off.
   ======================================================================

1997\01\20@121714 by Kalle Pihlajasaari

flavicon
face
Hi Jan,

> On my PC I have 4 COM ports, and I can set the IO card to what I want, but
> 95 insist that COM3 stay on IRQ4, and COM4 on IRQ5. (Useless info : When I
> stick a modem on COM4 it talks to it, but the modem response isn't seen.) If

Sharing interrupts is not well supported in hadware on standard periferals.
Usually when they 'share' the same interrupt they cannot do this at the same
time and one of the ports has to be inactive.

There might be ways of moving the IRQs to non standard values on W95
if you hack an INI file or something.  I know on NT this is possible even
thought it also suggests the default values.

Obviously this has nothing to do with PICs directly.

Cheers
--
Kalle Pihlajasaari   KILLspamkallespamspamspamip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

1997\01\20@121920 by myke predko

flavicon
face
>At 06:01 PM 1/20/97 +0200, you wrote:
>[stuff on 4 com ports deleted]
>
>>From memory, Com1 & Com3 share an IRQ, and Com2 and Com4 share an IRQ. So,
>two devices that are always active (or - at least - require handshaking?)
>won't work on the same IRQs (modem and mouse on com1 and com3 won't work,
>for example).

COM1/COM3 - IRQ4 (But, note that it's actually Vector 0x00C)
COM2/COM4 - IRQ3 Not 5 as originally put - Actually Vector 0x00B

>However, under Win 3.1 the IRQ is _settable_ for each com port
>(under ports, click on the port, then click on Advanced). Doing that, you
>should be able to move the conflicting Com ports to another IRQ (I know the
>modem I installed supports IRQs in addition to the standard ones).

I think this is more of a hardware feature unique to your PC that allows
software configuration.  I haven't seen too many PCs (some laptops) that
allow you to change Serial Port Configurations (although in the laptop cases
you have to reboot). I have seen many PCs that allow the user to change the
Port Configuration, but this has to be done from a power-up screen.

>I haven't
>tried it (much), but doing that should allow for 4 working Com ports.

Actually, most (if not all) modern PCs will only allow THREE working COM
ports.  The address space for COM4 (0x02E8-0x02EF) is used for IBM 8514A
compatiblity that's available in most SVGA graphics cards.

This one bit me on the butt big time a few weeks ago.

I'm really surprised at the compatiblity issues you're having (most programs
are pretty good at sorting out/passing along interrupts) and I suspect the
original problem is with where the IRQs were originally set (ie IRQ3 for
COM1) - if they don't follow conventions, typically the software doesn't
know what's going on.

To fix the problem, make sure everything is "Standard" - right now, I am
running my PICSTART Plus on COM1 and Tek 'scope Control Software on COM3.
No problems running them both.

Good luck,

myke

"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do"

Bruce Wayne

'serial comms'
1997\01\20@122539 by nuje

flavicon
picon face
In message  <199701180240.UAA18325KILLspamspam.....Mars.mcs.net> PICLISTspamBeGonespamMITVMA.MIT.EDU writes:
> I used to use ProComm, but I nowadays prefer to use COMMO.  I find that
> COMMO--despite being much smaller than the others (less than 64K for all
> needed file, not counting help or docs) includes a full scripting language,
> some internal upload/download protocols (Xmodem and Ymodem variants) as
> well as the ability to auto-launch a Zmodem receive upon seeing the H:\pic\efo~3.txt
> indicator.  In addition, it includes a built-in text editor and scrollback
> buffer (64K limit on each); the scrollback buffer logs what scrolls off
> the screen (so it often yields decent results even in cases where other
> programs do not; if a program displays "MORE" and then upon receiving a
> keystroke overwrites that with the continued display, the "MORE" will not
> appear in the scrollback) and the program can log to a file either [1]
> Everything that comes in the port, or [2] Everything that scrolls off
> the screen.
>
> Really great program.
>

Can you tell us where we can get Commo, please.


Regards,


Mike Watson

'Serial port IRQ clashes'
1997\01\20@145019 by Christopher Zguris

picon face
At 12:15 PM 1/20/97 EST, you wrote:
[snip]
>>However, under Win 3.1 the IRQ is _settable_ for each com port
>>(under ports, click on the port, then click on Advanced). Doing that, you
>>should be able to move the conflicting Com ports to another IRQ (I know the
>>modem I installed supports IRQs in addition to the standard ones).
>
>I think this is more of a hardware feature unique to your PC that allows
>software configuration.  I haven't seen too many PCs (some laptops) that
>allow you to change Serial Port Configurations (although in the laptop cases
>you have to reboot). I have seen many PCs that allow the user to change the
>Port Configuration, but this has to be done from a power-up screen.

I installed an internal modem in a friends' 486 a few days ago. I set it as
Com3, then changed the IRQ to one other than the default. On the modem,
there was a jumper. Under Windows 3.1, as I said, under "ports", under
"advanced" I changed the IRQ to match the (non-default) I had set on the
modem. The configuration was changed _under_ Windows and _not_ the powerup
screen. The problem was the motherboard had Com1 & Com2 installed already,
and a PS/2 mouse running from another port (no idea how). I could _not_
control/disable the built-in ports, so I decided to work around them to get
at the modem, and it worked fine. If Win 3.1 can do this, I can't imagine
Win'95 _not_ doing it (possible, I suppose).

Chris

   ======================================================================
         Christopher Zguris  -  czgurisspamspam_OUTinterport.net  -  Uhhh, Ear?
                     1991 VFR 750 (with aspalt detailing)
                             IVFROC, HSTA, HRCA
                   "WARNING! System has become unstable!"
                                - Windows 3.1
   ======================================================================

'serial comms'
1997\01\20@151957 by Luis Fernandez

flavicon
face
Hi,

>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.

I'm using START. Is a SIMPLE and "naked" terminal. You just invoque it as:

       START <COM PORT NUMBER> <BAUD RATE>
       Ej: START 2 9600

I use it for simple communications using the serial port. Has no other
feature except echo-on/off :-)

The good thing is that this just sizes 14.370 bytes. Works in any old PC.

Anyone interested just send me a message directly.




Luis Fernandez Cormenzana
RadioBit Sistemas, S.L.
       Vehicle fleet control systems
       Patrol presence controllers

Fax/Tel:+34-6-585 64 57
e-mail: .....radiobitRemoveMEspamKILLspamdragonet.es
http://www.dragonet.es/users/radiobit

'Serial port IRQ clashes'
1997\01\20@155144 by John Dammeyer

flavicon
face
At 06:01 PM 20/01/1997 +0200, you wrote:
[snip]
>
>On my PC I have 4 COM ports, and I can set the IO card to what I want, but
>95 insist that COM3 stay on IRQ4, and COM4 on IRQ5. (Useless info : When I
>stick a modem on COM4 it talks to it, but the modem response isn't seen.) If
>however, I stick it on COM3, the same IRQ as COM1, my mouse, using the modem
>makes the mouse hang up. If I stick PIC comms there, the mouse hangs up, but
>the PIC talk isn't received unless you move the mouse !
>
>On my laptop, there is only a COM1 (trackball is COM2). Sticking the PIC
>there works all the time without fail.
>
>Has anyone got any comments on how/why/whether my deductions are incorrect ?
>
>Jan van der Watt


It goes like this.

By default (in softare and therefore to some extent hardware),  COM1 is
always on IRQ4, COM2 is always on IRQ3.  Then if you add a COM3 it
piggybacks onto IRQ4 and COM4 piggybacks onto IRQ3.

Many of the Com and modem boards cannot accept any other assignment for
IRQs.  There are however four default address groups assigned for the four
COM ports.

So why won't it work.  History and Intel method of handling Interrupts.
Conventionally and Ideally an interupt should be active low and pulled high
with a resistor and triggered on the level ont the edge.  Then any
interrupting device just has to use an open collector transistor to
activiate the interrupt.  Software then polls each device attached to an IRQ
# and handles it all.  That is as it _should_ be.  On PCs the interrupt is
active high, edge triggered, and some cards leave it high and then pulse it
low.  When pulsed it returns to the dormant high state which causes the
interrupt.  The PIC (Programmable Interrupt Controller) then ignores that
edge (yes edge triggered, not level triggered) until the next pulse to low.

Some cards use an active device to pull the line high and others tri-state
the IRQ output and then un-tri-state it to cause the int. (the input to the
tri-state driver is hardwired to the appropriate logic level).

As you can imagine, this makes for a difficult interrupt sharing arrangement
because one device causes an interrupt and then another from a different
device comes along,  only the first will be recognized due to the fact that
the edge of the second is masked by the level of the first.

In other words,  to properly share interrupt lines you need level sensitive
and the polarity of the PC doesn't allow that and so most COM and Modem
cards don't support it.

That is why IBM-PC always stould for "Itsy Bitsy Micro Piece of Crap"

Wonderful eh?

John


Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\01\20@160014 by John Verberkmoes

flavicon
face
The info from Myke Predko seems to be the most accurate I've seen so far.
Here is some practical info.

------------------------------------------------------
Typically (but not necessarily)
Comm1 and Comm3 ---> Int 4
Comm2 and Comm4 ---> Int 3
------------------------------------------------------
but...
You can set it up differently if you want to.

You set it usually in the CMOS/BIOS setup screen on your PC's or via
jumpers/DIPS on a Comm board.

Now Comm1 and Comm3 "share" an interrupt but "share" is really being
optimistic. For most purposes you really can only use (Comm1 OR Comm3) and
(Comm2 OR Comm4).

Next, you can change interrupts in Windows control panel but it only tells
Windows what interrupt to expect. The hardware will continue to use what it
was set to.

Windoze 95 takes this away but it didn't set the interrupt anyway so we
didn't lose much.

There is a problem with PC's and the allocation of interrupts( there aren't
really enough). They designed the PC so that every stupid device needs its
own interrupt. If you have a Sound card, Network Card and your 2 comm ports
are full you are pretty much done adding hardware (unless you want to get
funky). PS/2 mice help as they use a higher interrupt that is usually free.

To add more serial devices you can use a multiport serial card. These allow
multiple comm ports to use one IRQ ( the hardware in the card makes this
possible).

Bottom line....PC's kinda suck. I don't think IBM was thinking ahead to
Pentium/sound blasters/networks/64MB mem/trackballs/hand scanners/etc...
when they designed the PC. There is help on the way with USB and Firewire
(I hope these work better than Plug and Pray).

'serial comms'
1997\01\20@170831 by William Chops Westfield

face picon face
   >I was wondering if anyone knows of a simple program around that would
   >allow basic 'talking' on the PC serial port using DOS.

If you (still) have basica (or GWBASIC), it has quite good support for the
com ports (1 and 2, anyway.)  Very early in the PC's life, I wrote a
termnial emulator/file transfer program in a combination of assembler and
basica (the assembler does the terminal emulation, basica does user
interface, configuration, and file transfers (xmodem.)  If the assembler
part is missing, the basica will do "dumb terminal" as well, but not all
that well...

I'd be willing to post or make this FTPable if anyone is interested.

The "commercial" version of this program, which might have been a worthy
competitor of Crosstalk I, crashed and burned for business reasons :-(

BillW

Display limited to first 300 matches. Add keywords to narrow the result set or browse by year:
- In 1997 , 1998 only
- Today
- New search...