> me if I'm wrong:
>
>
>
>              |
>              |     10K Resistor
>   PIC   RXIn |-----^^^^^^-------------------+-------------------- From PC
>              |                              |
>              |                              >
>              |                              < "Pull Down" Resistor
>              |                              >
>              |                              |
>              |                              +-------------------- To PC
>              |                              |
>              |           Resistor         |^
>         TXOut|-----------^^^^^------------|
>              |                            |\
>              |                              |
>              |                             +12 Volts
>              |
>
> This will send a Negative Voltage nominally and then send a Positive

>
> On Tue 29 Jul, Glen Fry <spamBeGonefrySTOPspamEraseMEMAIL.POWERUP.COM.AU> wrote:
> >
> > Hi,
> >
> > I'm about to start designing a small system that is to provide reasonably
> > accurate temp control, drive a 2x16 or 2x20 lcd and handle12 inputs and 10
> > outputs.
> >
> > I'm probably going to use a `74 for the job.
> > I'm looking to those of you that have experience with these these things for
> > advice.
> >
> > 1. I need to store temp setting and some other data in NV memory. I require
> > about 128 Bytes. May be written to once or twice a day. Can I use the EEProm
> > in the 74 for this?
>
> There is no EEPROM in the'74, so you'd have to use an external device
> (I2C preferred since it may share the bus with the ADC)
>
> > 2. I need a cheap but reliable 10 bit A/D with IIC. (dosen't every one?)
>
> Hmmm, I've been looking for I2C ADCs and have been unlucky so far.  Instead
> I found the MAX186, which is 12 bits, with 8 channel MUX and internal 4.096V
> reference.  Unfortunately, it requires 4 pins to drive it.

>
> Hello everyone
>
> I have a 16F84 program that currently uses 3 PWM outputs that were done in
> software. I want to expand the code, but the timing issues for PWM make it
> pretty difficult.
>
> If I go to a PIC with PWM hardware can I configure that hardware to run at low
> frequencies i.e. 15Hz or 30Hz and 100Hz?
>
> Can a PIC with multiple PWM outputs be configured so each PWM pin has its own
> frequency?
>
>  I've been having fantasies of being able to configure the PWM in hardware to
> accomplish these tasks.
>
> Can it be done?
> Which PIC has the most flexibility for these tasks?
>
> Thanks in advance
>
> Jon

> Need PIC Hardware Emulator recommendations (16C74)
>
> I have been working on a large personal project using the PIC16c74, for
> almost two years. I am getting sick of burning and erasing these things
> every time I have a code change. Debugging this way is tedious,
> frustrating and time consuming. I am searching for a simple hardware
> emulator, that will allow me to set breakpoints, step through my code
> and eliminate the constant hassle of erasing and burning PICs! Cost is
> an issue. I would like to spend less than $600. I am looking for
> recommendations from people who have experience using PIC emulator tools
> and can provide some constructive advice. Thanks
>
> Neil Gandler
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

> Hi All,
>
> I'm currently doing a project with a 16C73A in which I require a
> software controlled MCLR reset. I need this because I have the
> following problem :
>
> When I power-up the PIC the software is running with no problems. When
> for example a certain external voltage drop is detected on an A/D
> channel (the total unit is battery powered, but the PIC is safely
> supplied by a 7805 regulator), the software jumps to a subroutine.
> When this external voltage is back to normal again, the software will
> be reset by jumping out of the subroutine back to Start (address 0)
> initializing all registers again etc. etc.
> The problem is that after this 'soft-reset' I experience some problems
> with my A/D conversions resulting in large conversion errors. When I
> reset the processor by pulling down MCLR, everything works fine again.
>
> So my question is, is it possible to (MCLR) reset the 16C73A just by
> using some instructions?
> Right now, I've connected an NPN transistor to RA4 to pull down MCLR
> when I exit the above mentioned subroutine. But until this doesn't
> work yet.

>
> Paul B. Webster VK2BZC wrote:
> > When I was taught "C", one of the big plus-es (this was before C++ ;-)
> > was the lack of a "goto" statement.  I suspect tutors/ lecturers still
> > wax lyrical on this.
>
> Um, C has a "goto".  Are you thinking of PASCAL?
>
> main()
> {
> loop:
>         thing();
>         goto loop;
> }
>
> Admittedly you don't often _need_ to use a "goto".
>
> main()
> {
>         while(1) thing();
> }
>
> But I think it is not as evil as setjmp() and longjmp().
>
> --
> James Cameron                                      (RemoveMEcameronEraseMEKILLspamstl.dec.com)
>
> OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
> COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
> Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
> Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.
>
> "Specialisation is for insects." -- Robert Heinlein.

>Paul B. Webster VK2BZC wrote:
>> James Cameron wrote:
>> > But I think it is not as evil as setjmp() and longjmp().
>>   Is that a sort of takeajmp() ?
>
>setjmp() marks a point in your code.
>
>longjmp() can be used anywhere in the code to unwind the stack, all
>stack allocated variables, and resume execution after the setjmp().
>
>It is sort of a steroidal or global goto; can be used in any part of a
>program, not just within a function.
>
>I imagine it would be difficult to implement on PIC ... requires ability
>to unwind (pop) the stack.  Means the compiler would have had to
>implement the stack as a set of file registers.
>
>--
>James Cameron                                      (spamBeGonecameronspam_OUTRemoveMEstl.dec.com)
>
>OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
>COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
>Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
>Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.
>
>"Specialisation is for insects." -- Robert Heinlein.
>

>How do I tell teh UART in a PC to speak even though the modem/handshake
>lines tell it not to?
>
>It looks like THAT is more of a problem than the IRQs were :-(
>
>Andy
>
>==================================================================
>Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
>==================================================================
>
>

> How do I tell teh UART in a PC to speak even though the modem/handshake
> lines tell it not to?
>
> It looks like THAT is more of a problem than the IRQs were :-(
>
> Andy
>
> ==================================================================
> Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
> ==================================================================
>
>

> option will work also.
>
> Cross-wired connection:
>
>         10 MHz            100 MHz
>     1 -------    3        1------- 3
>     2 --------   6        2------- 6
>     3 --------   1        3--------1
>                                 4--------4
>                                 5--------5
>     6 ---------  2        6------- 2
>                                  7------- 7
>                                  8--------8
>
>
> Best regards
>     Gregory  V.Oleynikov
>
> john pearson wrote:
>
> > I am new to networking. I want to connect my two computers together.
> > I am looking at a Eithernet starter kit with two 10/100 nics and a

>
> Sorry, no URL but Yahoo or similar should find it.
>
> Andy
>
>
>
>    \-----------------/
>     \     /---\     /
>      \    |   |    /          Andy Kunz
>       \   /---\   /           Montana Design
> /---------+   +---------\     http://www.montanadesign.com
> | /  |----|___|----|  \ |
> \/___|      *      |___\/     Go fast, turn right,
>                                and keep the wet side down!
>

>
> >
> > At 09:17 PM 1/14/99 +0100, you wrote:
> > >Is there an equivalent "0-modem" possibility for transciever
> > >connections (those D15 connectors with the shifting locks)?
> >
> > AUI port.
> >
> > You guys should ALL download a copy of "The Hardware Book"
> > from the net.
> > It's a collection of all kinds of cables, interfaces,
> > pinouts, etc. that
> > are handy.  I keep a shortcut on my desktop so I can grab it any time.
>
> Could you attach the shortcut to an email? or is it a short cut to the file
> on your machine?
>
> >
> > Sorry, no URL but Yahoo or similar should find it.
> >
> > Andy

>
> Kevin Fisk wrote:
> >
> > >
> > > At 09:17 PM 1/14/99 +0100, you wrote:
> > > >Is there an equivalent "0-modem" possibility for transciever
> > > >connections (those D15 connectors with the shifting locks)?
> > >
> > > AUI port.
> > >
> > > You guys should ALL download a copy of "The Hardware Book"
> > > from the net.
> > > It's a collection of all kinds of cables, interfaces,
> > > pinouts, etc. that
> > > are handy.  I keep a shortcut on my desktop so I can grab it any time.
> >
> > Could you attach the shortcut to an email? or is it a short cut to the file
> > on your machine?
> >
> > >
> > > Sorry, no URL but Yahoo or similar should find it.
> > >
> > > Andy
>
> I had a link from my web page until early last year. The
> owner of the 'Hardware Book' was killed in a motorcycle
> accident. His page went down a few days later. It was one
> of the best sites on the net.
>

>
> On Tue, Jan 19, 1999 at 03:59:11PM -0600, Scott Newell wrote:
> > Every once in a while, people discuss building PIC programmers or other
> > hardware for use under Linux.  Now that I've got a Linux machine built up,
> > I'm interested in using the PC's serial and parallel ports to interface to
> > various devices, including some PIC projects.
> >
> > Does anyone have any good links or pointers to this kind of low-level
> > device access?  (I'm comfortable with C++, and I really don't want to deal
> > with the backwards AT&T-style x86 assembler syntax.)
>
> Two good books that cover this topic are:
>
> Linux Device Drivers by Alessandro Rubini (O'Reilly)
>
> and
>
> Linux Kernel Internals 2/E, Edited by Michael Beck (Addison-Wesley)
>
> In addition, the book
>
> Programming the Parallel Port; Interfacing the PC for Data
> Acquisition and Process Control by Dhananjay V. Gadre (R&D Books)
> www.amazon.com/exec/obidos/ASIN/0879305134/qid=916833059/sr=1-2/002-150

>
> while mostly DOS-oriented, does have one chapter on
> writing a Linux device driver for a parallel-port DAQ
> application (beware, though, I found that this book
> uses really funky jargon and diagrammatic conventions,
> and is rife with typos. Still, if you can get past that,
> there's a lot to learn from it).
>
> Most of what goes on at that level is typically
> done in ANSI C, rather than C++.

>
> >
> > On Tue, Jan 19, 1999 at 03:59:11PM -0600, Scott Newell wrote:
> > > Every once in a while, people discuss building PIC programmers or other
> > > hardware for use under Linux.  Now that I've got a Linux machine built up,
> > > I'm interested in using the PC's serial and parallel ports to interface to
> > > various devices, including some PIC projects.
> > >
> > > Does anyone have any good links or pointers to this kind of low-level
> > > device access?  (I'm comfortable with C++, and I really don't want to deal
> > > with the backwards AT&T-style x86 assembler syntax.)
> >
> > Two good books that cover this topic are:
> >
> > Linux Device Drivers by Alessandro Rubini (O'Reilly)
> >
> > and
> >
> > Linux Kernel Internals 2/E, Edited by Michael Beck (Addison-Wesley)
> >
> > In addition, the book
> >
> > Programming the Parallel Port; Interfacing the PC for Data
> > Acquisition and Process Control by Dhananjay V. Gadre (R&D Books)
> > www.amazon.com/exec/obidos/ASIN/0879305134/qid=916833059/sr=1-2/002-1

> >
> > while mostly DOS-oriented, does have one chapter on
> > writing a Linux device driver for a parallel-port DAQ
> > application (beware, though, I found that this book
> > uses really funky jargon and diagrammatic conventions,
> > and is rife with typos. Still, if you can get past that,
> > there's a lot to learn from it).
> >
> > Most of what goes on at that level is typically
> > done in ANSI C, rather than C++.
>
> Bob,
>
> I'm thinking that the device driver level is a bit too far under the surface
> for what Scott wants to do. Both parallel and serial interfaces are accessible
> from the user level, the parallel port via the port interface, the serial
> ports via the already excellent serial driver.
>
> The Linux IO-Port programming Mini-Howto has more than enough information to
> get started. It can be found at:
>
> http://metalab.unc.edu/LDP/HOWTO/mini/IO-Port-Programming.html
>
> As another poster pointed out the low level interface code for the Linux
> based picprg by Brian Lane of Nexus computing:
>
> http://www.tatoosh.com/nexus/picpgmr.shtml
>
> is quite instructive.
>
> For the most part a Linux driver is required under one of three conditions:
>
> 1) Interrupts are involved.
> 2) Timing is critical.
> 3) Access must be managed to multiple simultaneous users/applications
>
> For simple stuff to the parallel port just use the user level I/O interface
> and make the application setuid root (because I/O require root access).
>
> BTW it may bear repeating (I haven't seen a Linux based environment discussion
> lately) that a Linux based PIC environment is doable. Last semester I had one
> of my students build a parallel port based 16[CF]84 programmer that uses
> Nexus Computers picprog to program, Timo Rossi's picasm located:
>
> http://www.iki.fi/trossi/pic/
>
> for an assembler, and I experimented with Scott Dattalo's gpsim simulator at:
>
> http://interstice.com/~sdattalo/gnupic/gpsim.html
>
> Which works really well but I think need in addition to the complicated node
> and waveform based pin simlation a really simple interface where you can just
> set a pin high or low for input.
>
> I banged out two quick light control projects over the holidays with this
> setup and was extremely happy to finally retire my PICSTART/DOSEMU based
> system that I was using earlier.
>
> Next on my project list is adding a second 16C84 based programmer with a
> serial interface which will program the rest of the PIC family.
>
> I'm looking forward to hearing more about PIC and Linux integration here on
> the list.
>
> BAJ

> I am a beginner at PIC programming and built a test circuit using the
> 16C84.  The circuit uses a magnetic switch for an input and when the switch
> closes, and LED and piezo buzzer turn on.  Simple right?  Well, not for me!
>
> Here is the problem:  when I physically move closer to the breadboard (with
> the mag switch open), the LED turns on (but not the buzzer), getting
> brighter as I get closer to the breadboard.  Once this happens, the
> operation of the circuit is all messed up.  If I close the switch,
> sometimes the LED goes on, sometimes the buzzer sounds, sometimes both, and
> sometimes the LED works opposite, i.e. when the switch is open, the LED is
> ON, and vice-versa.
>
> Brief description on the circuit:  10 MHz Crystal (ECS) w/ 33 pF caps
> directly to ground; PORTA<0> switch input, PORTA<1> led output, PORTA<2>
> piezo output.
> LED output feeds an 74HC04 inverter; output of inverter to LED cathode; LED
> anode through 100 ohm resistor to +5V.  All unused 74HC04 inputs direct to
> ground.  All unused PIC I/O are configured as outputs and left unconnected
> to anything.  !MCLR pulled up to +5V.
>
> As for hardware, I configure the I/O ports on reset, and basically run a
> tight loop scanning the inputs, and changing the outputs based on the
> input.
>
> Any ideas?  Hardware or software?  I can't do much else until I figure out
> what is going on here.
>
> Thanks in advance for the help.
>
> --John

> I am a beginner at PIC programming and built a test circuit using the
> 16C84.  The circuit uses a magnetic switch for an input and when the switch
> closes, and LED and piezo buzzer turn on.  Simple right?  Well, not for me!
>
> Here is the problem:  when I physically move closer to the breadboard (with
> the mag switch open), the LED turns on (but not the buzzer), getting
> brighter as I get closer to the breadboard.  Once this happens, the
> operation of the circuit is all messed up.  If I close the switch,
> sometimes the LED goes on, sometimes the buzzer sounds, sometimes both, and
> sometimes the LED works opposite, i.e. when the switch is open, the LED is
> ON, and vice-versa.
>
> Brief description on the circuit:  10 MHz Crystal (ECS) w/ 33 pF caps
> directly to ground; PORTA<0> switch input, PORTA<1> led output, PORTA<2>
> piezo output.
> LED output feeds an 74HC04 inverter; output of inverter to LED cathode; LED
> anode through 100 ohm resistor to +5V.  All unused 74HC04 inputs direct to
> ground.  All unused PIC I/O are configured as outputs and left unconnected
> to anything.  !MCLR pulled up to +5V.
>
> As for hardware, I configure the I/O ports on reset, and basically run a
> tight loop scanning the inputs, and changing the outputs based on the
> input.
>
> Any ideas?  Hardware or software?  I can't do much else until I figure out
> what is going on here.
>
> Thanks in advance for the help.
>
> --John
>