Searching \ for ' PIC16F877' 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/microchip/devices.htm?key=16F
Search entire site for: 'PIC16F877'.

No exact or substring matches. trying for part
PICList Thread
'Datasheet for PIC16F877'
1998\11\30@213836 by Ray Doerr

picon face
   Does anyone know where I can get the Datasheet for the PIC16F877.  All I
could find on Microchip's site was a couple of App Notes.  Also any idea as
to when this chip will be available.


Thanks Ray


'The PICmicro PIC16F877 and the DT106 SimmStick!'
1999\06\13@031920 by Don McKenzie
flavicon
face
The PICmicro PIC16F877 and the DT106 SimmStick!
I have decided to go ahead with the design for a SimmStick, and
hopefully get a product to market within a month or two.

Rather than use up the bandwidth here, I have placed a page at:
http://www.dontronics.com/dt106.html

Comments welcome.

Don McKenzie  spam_OUTdonTakeThisOuTspamdontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

'LCD test program for PIC16F877 on a SimmStick.'
1999\06\14@205534 by Don McKenzie

flavicon
face
I think have found someone who can write applications and html code
faster than I can post them. :-)

LCD test program for PIC16F877 on a SimmStick.
Programming the PIC16F877 on a SimmStick.
http://www.dontronics.com/vicuni.html

Don McKenzie  .....donKILLspamspam@spam@dontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

'Digi-Key and the PIC16F877-20/P'
1999\06\15@170703 by Don McKenzie

flavicon
face
I just contacted Digi-Key for sales of PIC16F877-20/P Micros.
This is the only 87x part they are showing as in stock.

This is what I was told when I attempted to make a bulk purchase:

>Microchip has been having problems with these chips
>and it is them that will only let us sell 10 to a customer

Pushing further, I couldn't find out any more.
"Having Problems" Does anyone know what that really means?

Don McKenzie  donspamKILLspamdontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

1999\06\15@175845 by Andy Kunz

flavicon
face
>"Having Problems" Does anyone know what that really means?

... delivering.

I just bought 40 today from FAI, and placed a PO for 500 '876s w/o a problem.

Andy
==================================================================
  Andy Kunz - http://www.montanadesign.com - .....andyKILLspamspam.....montanadesign.com
          Life is what we do to prepare for Eternity
==================================================================

1999\06\15@190521 by Tony Nixon

flavicon
picon face
Don McKenzie wrote:

>Microchip has been having problems with these chips
>and it is them that will only let us sell 10 to a customer

>"Having Problems" Does anyone know what that really means?


Probably no-one. Don't forget these chips are a new item and are bound
to have bugs of some form or another.

As I heard at the seminar...

We, the users are the guinea pigs that help sort the problems out with
new devices. That's why there's so many periferals on them. It makes it
easier to debug 1 chip than a whole lot of new ones. No doubt in the
future there will be a few smaller spin offs from this design.


A real bummer, the (ES) chip I got from the seminar refuses to do
anything. Maybe it's just a plastic look-a-like.

--
Best regards

Tony

'The Engine' - Design your own programmer.

http://www.picnpoke.com
Email EraseMEpicnpokespam_OUTspamTakeThisOuTcdi.com.au

1999\06\15@221138 by Don McKenzie

flavicon
face
Tony Nixon wrote:
>
> Don McKenzie wrote:
>
> >Microchip has been having problems with these chips
> >and it is them that will only let us sell 10 to a customer

snip---

> A real bummer, the (ES) chip I got from the seminar refuses to do
> anything. Maybe it's just a plastic look-a-like.

The one we programmed came from the same (ES) batch I'm sure.
See pic at:
http://www.labyrinth.net.au/~donmck/vicuni/16f877.html

> Best regards
> Tony
> 'The Engine' - Design your own programmer.
> http://www.picnpoke.com
> Email picnpokespamspam_OUTcdi.com.au

Don McKenzie  @spam@donKILLspamspamdontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

'Digi-Key and PIC16F877-20/P'
1999\06\16@045740 by Alexey Vladimirov

flavicon
face
16 Jun 99, Don McKenzie writes to All:

P> I just contacted Digi-Key for sales of PIC16F877-20/P Micros.

P> This is what I was told when I attempted to make a bulk purchase:

>> Microchip has been having problems with these chips
>> and it is them that will only let us sell 10 to a customer

P> Pushing further, I couldn't find out any more.
P> "Having Problems" Does anyone know what that really means?

Looks like Digi-Key try to restrict international orders for Microchip
products. When I try to order 4 pcs PIC16F877-20/P and some PIC16C73A, I get
the following response from Digi-Key international sales:

=== Cut ===

>>Due to current regulations we are unable to ship the PIC16C73A-20I/SO-ND
>>and PIC16F877-20/P-ND to your country at this time.  Please let me know
>>if you have substitutes for these or if you would like me to cancel
>>them.

=== Cut ===

I have been ordered Microchip parts from Digi-Key many times for some urgent
needs - no problem till this time. Anybody have some ideas, what this
"regulations" really means ?

Alexey

Check Microchip Net Resources, more than 700 links now...
http://www.geocities.com/SiliconValley/Way/5807


'Question about programing of PIC16F877'
1999\09\16@102217 by levent oral
picon face
<x-flowed>Hello,
My question is that
I have written program for PIC16C74A about showing of two channels analog
signal's values on LCD, and it is succesful
But when I have writen the same program into PIC16F877, result is
unsuccesful, I changed only Processor type and
#include "pic16f877.inc"
and ADRES register to ADRESH.

Configuration bits
Oscillator              XT
WDT                     OFF
Power Up Timer          ON
Code Protect            OFF
Brown Out Detect        ON
Low Voltage Program     ENABLED
Data EE Protect         OFF
Flash Program Write     Enabled
Background Debug        Disabled


Programming is succesful but program is not working correctly in circuit.
what is  my mistakes,

Thanks for your helps.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

</x-flowed>

1999\09\16@110141 by Mike Mansheim

picon face
I ran into a similar problem:
If the low voltage program configuration bit is
enabled (which is the default), then pin RB3 is no
longer available as a digital i/o.  If you were using
that pin  with the C74, could be the reason things
don't work now.
Ref p.134 of F87X data sheet.

--- levent oral <KILLspaml_oralKILLspamspamHOTMAIL.COM> wrote:
{Quote hidden}

______________________________________________________
> Get Your Private, Free Email at
> http://www.hotmail.com
>

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

1999\09\16@212739 by Peter van Hoof

flavicon
face
It would be helpful if your post would give some clue what goes wrong
besides not working correctly exactly what does not work correctly

One thing comes to mind here.... the 877 has a of 10 bit a/d converter while
the 74a if I'm not mistaking is only 8.
Bit 7 in the ADCON1 register determines if the result in adresh,adresl is
left or right aligned, if the bit is 1 the 6 leftmost bits in adresh are 0
while the lower two bits are the msb's of the conversion.

If this is not the problem , look in the differences in the peripherals you
use (specifically the ad converter

Hope this helps


Peter van Hoof
-------------
RemoveMEpvhTakeThisOuTspamvertonet.com
http://go.to/pvh

> {Original Message removed}

1999\09\18@021837 by levent oral

picon face
<x-flowed>Thanks for your helps.
You are are right, problem is RB3 that you said in your mail.
Now my program is works correctly,
Thanks again,



{Quote hidden}

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

</x-flowed>


'Programming PIC16F877'
1999\10\10@142200 by Edson Brusque
face
flavicon
face
Hello,

   I need a PC in-system serial programmer to program the PIC16F877. Any
programmer who program the PIC16F84 will do?

   Best regards,

   Brusque

___________________________________________________________________________
| | || |\| | || || |\|\ Edson Brusque :-^= (RemoveMEbrusquespamTakeThisOuTflynet.com.br)
| | || ||| | || || |||| Musician, Tech Consultant, Programmer, Developer
| |_||_||| |_||_||_|||| Rodeio / SC / Brazil / Earth / Solar Syst / Milk...
| \_\\_\|| \_\\_\\_\||| Giro In'Italia homepage: http://flynet.com.br/giro
|  |  |  |  |  |  |  || C.I.Tronics Lighting Designers: citronics.com.br
|__|__|__|__|__|__|__||---------------- ICQ# 15937748 ---------------------
\__\__\__\__\__\__\__\|        The SoundFont Users Group Mailing List is at
----------------------|   www.geocities.com/SiliconValley/Port/6619/
---------------------------------------------------------------------------

1999\10\10@143859 by Robin Abbott

flavicon
face
FED (below) and a number of others on the PIC Ring sell programmers for the
F877. Unfortunately you cannot simply program the 877 as an 84 owing to
different program and EEPROM data lengths and the config fuses. A number of
F84 programmers can program the F877 with appropriate software, if you have
one you need to contact the suppliers.

Robin Abbott - robin.abbottEraseMEspam.....dial.pipex.com

**************************************************************************
*
* Forest Electronic Developments
* http://dspace.dial.pipex.com/robin.abbott/FED
*
**************************************************************************

{Original Message removed}

1999\10\10@154700 by Don McKenzie

flavicon
face
Edson Brusque wrote:
>
> Hello,
>
>     I need a PC in-system serial programmer to program the PIC16F877. Any
> programmer who program the PIC16F84 will do?

The cheaper "David Tait" style printer port jobs can usually be made to
work.
P16PRO PICMicro Programmer Software Registration
http://www.dontronics.com/p16pro.html

This will allow you to test the programmer.

Don McKenzie  EraseMEdonspamdontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

'Inefficient use of Program Memory in PIC16F877'
1999\10\14@094903 by David Williams

flavicon
face
Hello all,
I have a question.  I have a bunch of data that is 14 bits in size.  I'm
using Hitech PIC-C so I've placed the data in an integer.  I've done
something like this:

const int data[256] = {0x2324,0x2425,0x3233, ..... };

So I compile and I notice that in the program memory ROM the data is
stored like this:

3F24 3F23 3F25 3F24 ....

Look at all that space that could be used.  My 256 array takes up 512
words of program memory.  Now my data is only 14 bits big.  Is there
anyway I can delcare a variable 14 bits in size such that my constant
table of data that is 256 14bit words big could be stored in 256 words of
program memory?

Same goes for charaters.  If I never plan to use characters with an ASCII
value greater than 127, then can I find some efficent way to store these
7bit characters in program memory without using 1 word per character.  Ie
stick two 7bit characters in 1 word of program memory.

Note:  I don't want to use the write to and read from program memory
capabilities of the PIC16F877 because that would just cause more code to
be writen and hence more program memory occupied.  Soemthing like the
const expression which stores values in ROM is what I'm looking for.

Thanks
Dave

1999\10\14@133611 by Byron A Jeff

face picon face
>
> Hello all,
> I have a question.  I have a bunch of data that is 14 bits in size.  I'm
> using Hitech PIC-C so I've placed the data in an integer.  I've done
> something like this:
>
> const int data[256] = {0x2324,0x2425,0x3233, ..... };
>
> So I compile and I notice that in the program memory ROM the data is
> stored like this:
>
> 3F24 3F23 3F25 3F24 ....
>
> Look at all that space that could be used.  My 256 array takes up 512
> words of program memory.  Now my data is only 14 bits big.  Is there
> anyway I can delcare a variable 14 bits in size such that my constant
> table of data that is 256 14bit words big could be stored in 256 words of
> program memory?

Nope. This is the standard. Each one of these is an actual instruction.
A RETLW with the 8 bit value to return.

{Quote hidden}

Well you can't really have it both ways. You can do it if you at least read
the program memory, if not write it. But if you plan to use the existing
mechanism, then you're stuck. BTW if you do implement read/write of program
memory, then the program cannot be transferred to anything other than other
16C87X family members.

This is the price of a harvard architecture machine. Data isn't really designed
to be stored in the program memory space.

BAJ

1999\10\14@180721 by Andy Kunz

flavicon
face
>const int data[256] = {0x2324,0x2425,0x3233, ..... };

I store big tables in EEPROM whenever possible.

Just had a neat application of it.  We're doing a TV interface for an MPI
Zenith set, and I have all kinds of messages to send to the screen during
test mode.

Not having enough ROM for it, I stuck them in EEPROM (we have 8Kx8 there).
The messages going to the set can now be in any language.  We have a
"world" compatible box without even trying!

Just a thought.

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
RemoveMEandyEraseMEspamEraseMErc-hydros.com      http://www.rc-hydros.com     - Race Boats
RemoveMEandyspam_OUTspamKILLspammontanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\10\14@185439 by paulb

flavicon
face
Byron A Jeff wrote:

>> Note:  I don't want to use the write to and read from program memory
>> capabilities of the PIC16F877 because that would just cause more code
>> to be writen and hence more program memory occupied.

> Well you can't really have it both ways.

 Said it in one!

>>  Something like the const expression which stores values in ROM is
>> what I'm looking for.

 I see the problem.  Read Program Memory is most certainly how you get
the data *out* of the memory again, but how do you *code* it into the
program.  The "DB" or whatever shoves it into RETLWs.

 It's an *assembler syntax* question, not a coding one, if that makes
sense.  I don't know the answer.   If necessary, I would fiddle the
object files to get the job done, but is there an easy way provided?
--
 Cheers,
       Paul B.

1999\10\17@114747 by Myke Predko

flavicon
face
Hi David,

use the "dw" assembler directive.

ie:

data  dw  0x02324, 0x02425, 0x03233...

It will store the data in the format you want into program memory and can be
read using the EEPROM program memory read commands.

myke
{Original Message removed}


'Errata for PIC16F877s'
1999\11\18@051548 by Craig Peacock
flavicon
face
Does anyone recall seeing any errata document(s) in regards to
configuration bits of the 16F87x series?

I'm under the impression Microchip released errata about the
configuration bits on the 16F877, however at the time I received it, it
wasn't relevant and thus I filed it appropriately. (It's possible it
could of been another processor) Now I can't seem to find it on
Microchip's web page.

What is interesting is that I have another errata document (Printed) at
work for the 16F877 regarding problems with self programming in
Mask/Revision B Parts. This document, document number 80053a, details
with sample code a work around. However it seems to not exist anymore on
Microchips Website. I'm wondering if the previous document suffered the
same fait.

Regards,

Craig Peacock

1999\11\18@055951 by Wollenberg, Frank

flavicon
face
Craig Peacock wrote:

> Does anyone recall seeing any errata document(s) in regards to
> configuration bits of the 16F87x series?

Sorry, i knows about only two documents on Microchip's web page, named
80051b and 80052b.

> What is interesting is that I have another errata document (Printed) at
> work for the 16F877 regarding problems with self programming in
> Mask/Revision B Parts. This document, document number 80053a, details
> with sample code a work around. However it seems to not exist
> anymore on Microchips Website.

Can you send me this document, either directly or by posting into this list
?

Thanks in advance,
Frank Wollenberg

1999\11\19@190131 by Craig Peacock

flavicon
face
Frank,

> > Does anyone recall seeing any errata document(s) in regards to
> > configuration bits of the 16F87x series?
>
> Sorry, i knows about only two documents on Microchip's web page, named
> 80051b and 80052b.
>
> > What is interesting is that I have another errata document (Printed) at
> > work for the 16F877 regarding problems with self programming in
> > Mask/Revision B Parts. This document, document number 80053a, details
> > with sample code a work around. However it seems to not exist
> > anymore on Microchips Website.
>
> Can you send me this document, either directly or by posting into this
list ?

Not a problem. I have emailed you a scanned PDF copy. If anyone
else is interested please email me.

Regards,

Craig Peacock

1999\11\20@070955 by Peter Keller

flavicon
face
part 0 1107 bytes
x-html> May I have it too ?
Peter Keller
 

Craig Peacock schrieb:

Frank,

> > Does anyone recall seeing any errata document(s) in regards to
> > configuration bits of the 16F87x series?
>
> Sorry, i knows about only two documents on Microchip's web page, named
> 80051b and 80052b.
>
> > What is interesting is that I have another errata document (Printed) at
> > work for the 16F877 regarding problems with self programming in
> > Mask/Revision B Parts. This document, document number 80053a, details
> > with sample code a work around. However it seems to not exist
> > anymore on Microchips Website.
>
> Can you send me this document, either directly or by posting into this
list ?

Not a problem. I have emailed you a scanned PDF copy. If anyone
else is interested please email me.

Regards,

Craig Peacock

1999\11\20@153538 by Nihat DA▄DEMáR

flavicon
face
Please send me too.

----- Original Message -----
From: Craig Peacock <RemoveMECraig.PeacockTakeThisOuTspamspamSENET.COM.AU>
To: <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU>
Sent: 20 Kasàm 1999 Cumartesi 01:55
Subject: Re: Errata for PIC16F877s


> Frank,
>
> > > Does anyone recall seeing any errata document(s) in regards to
> > > configuration bits of the 16F87x series?
> >
> > Sorry, i knows about only two documents on Microchip's web page, named
> > 80051b and 80052b.
> >
> > > What is interesting is that I have another errata document (Printed)
at
{Quote hidden}

1999\11\21@153605 by Tom Handley

picon face
  Craig, is that errata sheet from the DS80053A sheet? This was included
with the preliminary data book and applies to engineering samples with
the Rev B or "ES" parts. If not, I would like to know which version you
have. I have a few thousand lines of codes in an 877 right now... Thanks,

  - Tom

At 10:25 AM 11/20/99 +1030, Craig Peacock wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

1999\11\22@044519 by Craig Peacock

flavicon
face
Tom,

>    Craig, is that errata sheet from the DS80053A sheet? This was included
> with the preliminary data book and applies to engineering samples with
> the Rev B or "ES" parts. If not, I would like to know which version you
> have. I have a few thousand lines of codes in an 877 right now... Thanks,

Yes, thats the one. What revision/mask is shipping now? We have just
brought a tube of them still with Rev B Mask?

Regards,

Craig Peacock

1999\11\22@160312 by Tom Handley

picon face
  Craig, I have no idea what rev they are shipping now. I talked to my
local rep last month and he indicated it would be awhile before the next
(re: fixed) rev ships but he had no time-line.

  - Tom

At 08:13 PM 11/22/99 +1030, Craig Peacock wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

'CVASM v5.8 - Can't Program the PIC16F877'
1999\11\22@160321 by Tom Handley

picon face
  Jerry, I've been beta testing the Carmacon programmer software and when I
use CVASM v5.8 to program various 16F877 *.OBJ files, the programmer will
not read the files. This is with the Carmacon release and beta software.
When I go back to CVASM v5.6, everything works fine. I have'nt talked to
Carl at Carmacon yet.

  Note, v5.8 did fix the problem of calling routines in the 1000h and
1800h banks.

  I've posted this to both the Parallax and MIT lists. Thanks,

  - Tom


------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

1999\11\22@172215 by Jerry Merrill

flavicon
face
Tom:
Could you be more specific about the Carmacon software "will not read the
files?"
Does it have specific complaints?.....crash.....read bad data?.... I do not
know much about their software.

IIRC, we updated the EEPROM data statements in the OBJ files between those
two releases.  The earlier release assumed 64 bytes of EEDATA (WRONG!). The
F87X devices have 128 or 256 bytes.

It could be that the Carmacon software is choking on the extra EEDATA
statements or that we mis-encoded it in the HEX statements. (this is the
first device series that uses more than 64 bytes).

Could you send HEX files to me? One with your code assembled with 5.6 and
one assembled with 5.8?

I'll post this to the Parallax list as well so the people there do not
think I ignored you :)


At 02:59 PM 11/22/99 , you wrote:
{Quote hidden}

Jerry Merrill

RemoveMEjerrymKILLspamspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\11\23@073813 by Tom Handley

picon face
  Jerry, I think you found the problem. I was mistaken in saying the
release software had a problem as it does not support the 16F877...
(I've been using beta for quite awhile). There are known issues with
EEPROM in the current beta software and that was next on my `to test'
list. The error I get is "Data out of range error". I'll contact Carl
at Carmacon and get back to you. Thanks,

  - Tom

At 04:06 PM 11/22/99 -0600, Jerry Merrill wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)


'CVASM v5.8 - Can't Program the PIC16F877'
1999\12\01@092547 by Tom Handley
picon face
  Jerry, Carmacon has updated their WinPep programming software to
version 2.03 and it has fixed the issue I mentioned below. CVASM v5.8
now works fine with their software and 16F876/877 devices. Thanks,

  - Tom

I wrote:
>   Jerry, I think you found the problem. I was mistaken in saying the
>release software had a problem as it does not support the 16F877...
>(I've been using beta for quite awhile). There are known issues with
>EEPROM in the current beta software and that was next on my `to test'
>list. The error I get is "Data out of range error". I'll contact Carl
>at Carmacon and get back to you. Thanks,

>   - Tom

At 04:06 PM 11/22/99 -0600, you wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

1999\12\01@105219 by Jerry Merrill

flavicon
face
Thanks for 'closing the loop' and glad to hear you are up-n-running.

Jerry


At 08:17 AM 12/1/99 , you wrote:
>   Jerry, Carmacon has updated their WinPep programming software to
>version 2.03 and it has fixed the issue I mentioned below. CVASM v5.8
>now works fine with their software and 16F876/877 devices. Thanks,
>
>   - Tom
>
<SNIP>


Jerry Merrill

spamBeGonejerrymSTOPspamspamEraseMEtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

'need help on usart routine with PIC16F877'
1999\12\01@232412 by Nzabus

flavicon
face
i have implement an usart routine with PIC16F877 to display a simple menu
message.
it's seems to work well but i'm not able to stabilyse my menu.
each time i power on my circuit menu is displayed and this process continue
all 2 seconde (about).
i want that menu come just one time and wait for another task.
if someone can help me how to do that i will appreciate.
a part of my routine is :

list      p=16f877            ; list directive to define processor
#include <p16f877.inc>        ; processor specific variable definitions

__CONFIG _CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _XT_OSC &
_WRT_ENABLE_ON & _LVP_ON & _DEBUG_OFF & _CPD_OFF

temp0  equ 20h
check  equ 21h

CR equ 0x0D
LF equ 0x0A

ORG 00h ; Reset Vector
main: goto init_uart

ORG 10h ; Begining of Program space

;---------------------------------------------------------------------------
--
; Main Program
;---------------------------------------------------------------------------
--

init_uart:
bsf STATUS,RP0 ; select bank 1
bcf STATUS,RP1
movlw 19h   ;9600 baud @4MHz
movwf SPBRG
movlw b'00100100'  ;transmit enable, Async, High baud rate
movwf TXSTA
; bsf PIE1,TXIE
bsf PIE1,RCIE
bcf STATUS,RP0 ; selact bank 0
bcf STATUS,RP1
movlw b'10010000'  ;Serial port Enable, continous reception
movwf RCSTA
.
.
.
.
.

Start:

clrf temp0  ;initialize table index
main_loop:
movf temp0,w  ; update table index
call menu  ; get menu table entry
movwf check
movf check,w  ;load acc with table char
bz continue1
call put_char ;display character
incf temp0,f  ;inc. index
goto main_loop ;repeat until done

continue1:

goto    continue1
.
.
.
.
.
.

put_char:
; btfss PIR1,TXIF ;check TX Buff flag
bsf STATUS,RP0 ; select bank 1
bcf STATUS,RP1
btfss TXSTA,TRMT
goto put_char ;If buff full wait
bcf STATUS,RP0 ; select bank 0
bcf STATUS,RP1
movwf TXREG  ;if buff empty output next char
return
.
.
.
.
.
.
.
echo_char:
bcf STATUS,RP0 ; select bank 0
bcf STATUS,RP1
btfss PIR1,RCIF
goto echo_char ;If buff full wait
movf RCREG,w
call put_char ;if buff empty output next char
return
.
.
.
.

menu:
addwf PCL,f
dt "MENU:",CR,LF
dt "READ TEMPERATURE...... [1] ",CR,LF
dt "SET U/C ATTENUATION....[2] ",CR,LF
dt "SET D/C ATTENUATION....[3] ",CR,LF,0
.
.
.
.


end

1999\12\02@144621 by Agnes en Henk Tobbe

flavicon
face
>each time i power on my circuit menu is displayed and this process continue
>all 2 seconde (about).
>i want that menu come just one time and wait for another task.
> __CONFIG _CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _XT_OSC &
>_WRT_ENABLE_ON & _LVP_ON & _DEBUG_OFF & _CPD_OFF


IMHO you would want to reset your watchdog timer once in a while.....

VK2GWK - HENK
Home page: http://www.users.bigpond.com/tobbe/index.htm

'Solution: RE: PIC16F877 return instruction does no'
1999\12\18@144324 by Douglas Fast

flavicon
face
Peter,

Thanks for the reply.  No answer was the best in this case.  It caused me to
review what I was acutally doing ... and I found a pointer to memory that
was going astray.  All is well now.

Doug

-----Original Message-----
From: Peter van Hoof [KILLspampvhspamBeGonespamVERTONET.COM]
Sent: Friday, December 17, 1999 10:07 PM
To: EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU
Subject: Re: PIC16F877 return instruction does not return properly


I didn't really get into it very far but I see various problems here
perhaps because not enough of the source is listed


'Programing Pic16F877 with MOD EMUP?'
2000\02\10@140248 by Kev
picon face
part 0 16 bytes
</x-html>

2000\02\10@154054 by Don McKenzie

flavicon
face
> Kev wrote:
>
> I've found drivers for 16F84 programing but have not seen any for
> 16F87x chips.
>
> Do these exist or is it possible to patch existing software?
>
> The MOD EMUP is the somewhat dated programer from JDR Micro Devices.

is it a standard David Tait type of programmer that uses the printer
port, a power supply section for vpp, couple of transistors, maybe a 74
type chip?

if so, try
http://www.dontronics.com/p16pro.html

Don McKenzie    @spam@don@spam@spamspam_OUTdontronics.com      http://www.dontronics.com

World's Largest Range of Atmel/AVR and  PICmicro Hardware and  Software.
Free Basic Compiler and Programmer http://www.dontronics.com/runavr.html

'Internal UART interrupts in PIC16F877'
2000\02\12@020523 by ranma

flavicon
face
Hi everyone,

I am sure I read recently (on the "gotchas" thread) about bugs in the
implementation of UART interrupts on the 16F877. Namely, they don't work.

I am in the process of writing an interrupt handler which seems to be going
fine, but never is triggered by the UART TX or RX interrupts. I am mostly
concerned about the RX buffer full interrupt, as I want to put some code in
the handler to buffer any data that tries to sneak in when the program is
busy. The relevant flags are working fine, just no interrupt is triggered.

Yes, the relevant interrupt enables are enabled. I am using Octavio's ICD
(great thing - by the way) to develop this but I don't think this interferes
with the RX/TX interrupts.

Any ideas?

David

2000\02\12@025425 by Robert Rolf

picon face
David Thompson wrote:
> I am sure I read recently (on the "gotchas" thread) about bugs in the
> implementation of UART interrupts on the 16F877. Namely, they don't work.

The chip interrupts work fine. MPSIM's simulation DOESN'T!

> I am in the process of writing an interrupt handler which seems to be going
> fine, but never is triggered by the UART TX or RX interrupts. I am mostly
> concerned about the RX buffer full interrupt, as I want to put some code in
> the handler to buffer any data that tries to sneak in when the program is
> busy.

So set up a proper ring buffer and you'll never miss a character.

>The relevant flags are working fine, just no interrupt is triggered.
>
> Yes, the relevant interrupt enables are enabled. I am using Octavio's ICD

Did you turn on the USART? (SPEN & CREN in RCSTA, TXEN in TSXTA)
Did you configure TRISC appropriately? C6 out, C7 In. You shouldn't
need to set TRISC but by explicitly setting it up (and putting a 1 in
PORTC:6) you avoid a glitch character transmission on startup).

> (great thing - by the way) to develop this but I don't think this interferes
> with the RX/TX interrupts.

Depends on what resources it consumes. You have to ensure that
you aren't using the scratch memory the ICD needs.

Why is it that something as common as an interrupt driven serial
ring buffer is constantly being reinvented? I searched the web
for more than a week, looked at Microchip app notes, and ended up
writing one from scratch. Now my employer owns it and I can't publish
it. I'm sure it's been reinvented a hundred times by now. I guess
shared code libraries don't yet exist in picland.


spamBeGoneRobert.RolfspamKILLspamUALberta.ca

2000\02\12@035938 by Peter Keller

flavicon
face
Robert Rolf schrieb:

> Why is it that something as common as an interrupt driven serial
> ring buffer is constantly being reinvented? I searched the web
> for more than a week, looked at Microchip app notes, and ended up
> writing one from scratch. Now my employer owns it and I can't publish
> it. I'm sure it's been reinvented a hundred times by now. I guess
> shared code libraries don't yet exist in picland.

So we shoud come together and write those often used routines in asm and c.
We should publish the code, so everybody who is interested could test it.
Then, it may becomes a "standard".
Who will start ?
Peter

>
>
> .....Robert.Rolfspam_OUTspamUALberta.ca

'Internal UART interrupts in PIC16F877 [OT]'
2000\02\12@085244 by piclist.com

face picon face
That what the techref and piclist.com are designed for... anyone who wants
to publish one can fill out a membership form, log on, drill down to the
correct page:
http://techref.massmind.org/io/serials
for example, and use the little form at the bottom to post their code.

Notes:
1. Use HTML in the big text field. So for code listings add a "<PRE>" at the
start, convert "<" to "&lt;" etc... and finish with a "</PRE>"

2. The address above is redirected via JavaScript to
204.210.50.240/techref/default.asp?url=io/serials.htm
so if you have JavaScript turned off, you get a 404 document that tries to
explain how to do this redirection manually. Robert, I think this is what
you ran into.

3. Don't worry if it doesn't post quite right, I get an email when anyone
posts and I will edit it.

James Newton
TakeThisOuTjamesnewton.....spamTakeThisOuTgeocities.com
1-619-652-0593 phone
http://techref.massmind.org


{Original Message removed}

2000\02\13@002724 by ranma

flavicon
face
Hi Robert,

>So set up a proper ring buffer and you'll never miss a character.

Done that, not a problem

>Did you turn on the USART? (SPEN & CREN in RCSTA, TXEN in TSXTA)
>Did you configure TRISC appropriately? C6 out, C7 In. You shouldn't
>need to set TRISC but by explicitly setting it up (and putting a 1 in
>PORTC:6) you avoid a glitch character transmission on startup).

Everything is set up correctly. The UART sends and receives characters as
expected. I just don't get any interrupt generated. I have been testing the
ring buffer by triggering another interrupt (RB0) via a pushbutton, just to
get into the interrupt handler. It then correctly sees that the receive
register has data waiting and puts it in the buffer. If the RX interrupt
triggered correctly it would happen automatically of course... I think that
you would all agree that if the UART can successfully transmit and receive,
AND you can generate interrupts from other sources, ALL you should need to
get the RX interrupt going is to make sure that RCIE is set.

I've even tried running the F877 in the demo board without the ICD, but it
makes no difference.

I also looked at all the suggested published serial code. Very little
published used interrupts at all. The only one that did was buggy.

I think I've had enough for today. I can only assume that somehow my F877's
RX interrupt is broken (unlikely I know..)

It's a pity that your code is not available. It sounds like it would be just
the thing....

Dave.

2000\02\13@163051 by Robert Rolf

picon face
David Thompson wrote:

> Everything is set up correctly. The UART sends and receives characters as
> expected. I just don't get any interrupt generated. I have been

Did you turn on PIE in INTCON? The USART is a peripheral
so you have to turn on both PIE & GIE.

>ring buffer by triggering another interrupt (RB0) via a pushbutton,

But RBIE doesn't need PIE to be set.

> you would all agree that if the UART can successfully transmit and receive,
> AND you can generate interrupts from other sources, ALL you should need to
> get the RX interrupt going is to make sure that RCIE is set.

No, you need GIE, PIE, and RCIE set.

> I've even tried running the F877 in the demo board without the ICD, but it
> makes no difference.

Of course it won't if it's a software error. I'll bet that you
didn't set PIE.

> I also looked at all the suggested published serial code. Very little
> published used interrupts at all. The only one that did was buggy.

Yeah, I know. Or they don't use a ring buffer.

> I think I've had enough for today. I can only assume that somehow my F877's
> RX interrupt is broken (unlikely I know..)

It's not. Your code is.


> It's a pity that your code is not available. It sounds like it would be just
> the thing....

Yeah, I know the feeling. Nothing like learning all the tricks
for yourself.

Robert

2000\02\13@165416 by l.allen

picon face
>
> > I think I've had enough for today. I can only assume that somehow my F877's
> > RX interrupt is broken (unlikely I know..)
>
> It's not. Your code is.
>
>
> > It's a pity that your code is not available. It sounds like it would be just
> > the thing....
>
> Yeah, I know the feeling. Nothing like learning all the tricks
> for yourself.
>
> Robert

I must confess, I am sometimes reluctant to share my code
because I tend to be happy just to get the thing running.
That includes hideous little cludges that work around a problem I
cant figure out. If I was a good programmer I would resolutely work
away until the code was tight and presentable but... I don't care...
as long as it goes.
If I publish my code all the clever people will say.. what a lousy
code writer.. shame.. shame.. shame... shame.
I bring this up because 90% of this applies to serial / uart code. I
hate it, especially simultaneous tx and rx.
The other 10% tends to revolve around ADC problems.
_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\02\14@083423 by ranma

flavicon
face
Yep, that was it. I didn't think that there would be THREE flags to set GIE,
PEIE and RCIE. Silly newbie mistake. Thanks for your help.

Dave

{Original Message removed}

2000\02\14@084436 by ranma

flavicon
face
Hi Lance,

I understand and have a similar fear, but I will publish the code here when
it is complete anyway.

<RANT>
Some people are sure to snigger, but it will have something most PIC code
doesn't - readability. Unusual concept, I know, but everyone (especially
newbies like me) will be able to understand how it works. Like you, I don't
care if someone can write it in half the size, using completely obtuse code,
this forum is here to help others right?... not to show off.
</RANT>

I like to think that truly clever people will suggest improvements, not put
you down for clumsy code.

Dave

{Quote hidden}

_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\02\14@125608 by Erik Reikes

flavicon
face
At 12:54 AM 2/12/00 -0700, Robert Rolf wrote:
>David Thompson wrote:
>> I am sure I read recently (on the "gotchas" thread) about bugs in the
>> implementation of UART interrupts on the 16F877. Namely, they don't work.
>
>The chip interrupts work fine. MPSIM's simulation DOESN'T!
>
>> I am in the process of writing an interrupt handler which seems to be going
>> fine, but never is triggered by the UART TX or RX interrupts. I am mostly
>> concerned about the RX buffer full interrupt, as I want to put some code in
>> the handler to buffer any data that tries to sneak in when the program is
>> busy.
>
>So set up a proper ring buffer and you'll never miss a character.

<snip>

>Why is it that something as common as an interrupt driven serial
>ring buffer is constantly being reinvented? I searched the web
>for more than a week, looked at Microchip app notes, and ended up
>writing one from scratch. Now my employer owns it and I can't publish
>it. I'm sure it's been reinvented a hundred times by now. I guess
>shared code libraries don't yet exist in picland.

#define RING_SIZE 20;

char incoming[RING_SIZE];

#pragma origin = 0x4

interrupt int_server( void)
{
       int_save_registers    // W, STATUS (and PCLATH)



       if (RCIF)
       {

               incoming[index] = RCREG;
               index++;
               index = index % RING_SIZE;

               RCIF = 0;
       }

       int_restore_registers // W, STATUS (and PCLATH)
}

Make sure that GIE, RCIE, and PEIE are set, as well as your UART.



Erik Reikes
Software Engineer
Xsilogy, Inc.

TakeThisOuTereikesKILLspamspamspamxsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\02\14@131241 by Erik Reikes

flavicon
face
Yeah, but anyone with any sort of spine whatsoever would be obligated to
post their better code and say why it was better.  In this case you get the
advantage of stealing it outright.

For reference, I steal about 75% of my production code.  I end up having to
port a lot of it to different micros and/or differences in specific
application, but it is rare indeed when I have to sit down and start
something completely from scratch.

The bossman doesn't care where I got it as long as it is basically legal
and as long as it works.


At 12:42 AM 2/15/00 +1100, you wrote:
{Quote hidden}

Erik Reikes
Software Engineer
Xsilogy, Inc.

.....ereikesspamRemoveMExsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\02\14@154738 by William Chops Westfield

face picon face
> Some people are sure to snigger, but it will have something most PIC code
> doesn't - readability. Unusual concept, I know, but everyone (especially
> newbies like me) will be able to understand how it works.

Well, there you go.  Write clever optimized code, and people will complain
that it is unreliable and difficult to understand.  Write obvious code and
people will complain that it is slow and ... obvious.

You can't win.

BillW

2000\02\14@155734 by Dave VanHorn

flavicon
face
> Well, there you go.  Write clever optimized code, and people will complain
> that it is unreliable and difficult to understand.  Write obvious code and
> people will complain that it is slow and ... obvious.
>
> You can't win.
>
> BillW

Yeah it's All Right now,
I learned my lesson well,
You see you, Can't Please Everyone, so ya
Got-ta please yourself.


I write it so I can understand it in a year. So far, it's working :)

'OT:Re: Internal UART interrupts in PIC16F877'
2000\02\14@165027 by James Paul

flavicon
face
"Wouldn't It Be Nice" if all software/firmware writing were a
Garden Party?

                                     Regards,

                                       Jim


On Mon, 14 February 2000, Dave VanHorn wrote:

{Quote hidden}

RemoveMEjimspamspamBeGonejpes.com

'SPI with PIC16F877'
2000\02\29@130655 by Tobie Horswill

flavicon
face
Hi,

   I'm trully sorry my first post to this group was in RTF! I think I've
corrected this now, thanks for your polite reminders.


   I'm trying to implement SPI communication with a serial DAC and a PIC
16F877 but can't seem to get the PIC's SSPSTAT to change values. I've tried
changing banks, intialising TRIS and SSPCON before and after the SSPSTAT,
enabling disabling SSP interrupts but nothing works. The SSPSTAT register
remains at '00000000' whatever I do. Actually the BF (buffer flag) does
shift to 1 once the SSPBUF register has been written to and has emptied
itself but it then remains stuck that way...

   Nevertheless, scope analysis of the SDO pin shows I'm pretty close to
getting things to work but I can't seem to get the clock and the data
properly
aligned without the CKE bit in the SSPSTAT register properly set.

Help please, I'm stuck!!!


'Programming the PIC16F877'
2000\04\03@093452 by naxel
flavicon
face
Greetings to all PIClisters,

I have recently developped a PIC programmer circuit, based on Taits'
design, which worked fine for a PIC16F84. The problem occured when I
tried to program a brand new PIC16F877. At that time, I had no idea of
the LVP ability (I know, I know, RTFM next time :) ), so RB3 was
unconnected. The programming was successful (or so it seemed), but
something weird happened then. All ports of the PIC16F877 that were
configured as outputs, could not rise their voltage to +5. To my
understanding, the PIC is now useless, blown, and that has something to
do with the programming process and the RB3 pin. Later, I found out
about disabling the LVP from the configuration word, but that applies to
all programming attempts after the first.

What should I do with the RB3 pin in order to successfully program the
PIC16F877 for the first time, when all I have is a high voltage
(12-14Volt) programmer (except from obtaining/building a LVP
programmer)?
I desperately need a solution for my final project in university.
Any advice or reference (or good news about the blown chip :) ) is
welcome.

Thank you all in advance.

Nickolas Axelos

2000\04\03@191028 by Tony Nixon

flavicon
picon face
Nickolas Axelos wrote:

> What should I do with the RB3 pin in order to successfully program the
> PIC16F877 for the first time, when all I have is a high voltage
> (12-14Volt) programmer (except from obtaining/building a LVP
> programmer)?
> I desperately need a solution for my final project in university.
> Any advice or reference (or good news about the blown chip :) ) is
> welcome.
>
> Thank you all in advance.
>
> Nickolas Axelos

Use a 10K resistor from RB3 to +5V and a 100N cap from RB3 to GND.

--
Best regards

Tony

http://www.picnpoke.com
spamBeGonesales@spam@spamspam_OUTpicnpoke.com

2000\04\03@234954 by Byron A Jeff

face picon face
>
> Nickolas Axelos wrote:
>
> > What should I do with the RB3 pin in order to successfully program the
> > PIC16F877 for the first time, when all I have is a high voltage
> > (12-14Volt) programmer (except from obtaining/building a LVP
> > programmer)?
> > I desperately need a solution for my final project in university.
> > Any advice or reference (or good news about the blown chip :) ) is
> > welcome.
> >
> > Thank you all in advance.
> >
> > Nickolas Axelos
>
> Use a 10K resistor from RB3 to +5V and a 100N cap from RB3 to GND.

Interesting. I was just re-reading the 16F87X programming specification and
I just don't see any reference to RB3 when high voltage programming the
part.

I ask because one of my students is at the point where she is trying to
program a 16F87X with a standard Tait style programmer. The programmer
does 16F84's just fine and we've modified the code to substitute a 0x18
begin programming only cycle instead of a 0x08 Begin programming erase
cycle which is simply a begin programming command for the 16F84.

The circuit you show above would pull RB3 from 0 to 5 volts. But is this
necessary if MCLR is going from 0 to 13V?

Look forward to your response.

BAJ

2000\04\04@003101 by Tony Nixon

flavicon
picon face
Byron A Jeff wrote:
> > Use a 10K resistor from RB3 to +5V and a 100N cap from RB3 to GND.

> The circuit you show above would pull RB3 from 0 to 5 volts. But is this
> necessary if MCLR is going from 0 to 13V?

It holds RB3 low during powerup only. Sometimes the chip won't program
in HV mode when LVP is enabled (default), but it may be a problem only
if this pin is floating. I have tried both ways, and have been caught
out leaving RB3 unconnected, but the RC approach seems to work. You can
see the same circuit in the ROMzap PDF file.

--
Best regards

Tony

http://www.picnpoke.com
TakeThisOuTsalesspamspampicnpoke.com

2000\04\04@015122 by Jim Robertson

flavicon
face
At 11:48 PM 4/3/00 -0400, you wrote:
>>
>> Use a 10K resistor from RB3 to +5V and a 100N cap from RB3 to GND.
>
>Interesting. I was just re-reading the 16F87X programming specification and
>I just don't see any reference to RB3 when high voltage programming the
>part.
>
>
>The circuit you show above would pull RB3 from 0 to 5 volts. But is this
>necessary if MCLR is going from 0 to 13V?
>
>Look forward to your response.
>
>BAJ

This is what I sent to the piclist back in August 1999.

<Quote>

Hi Folks,

Here is the results of some experimenting with the new 16F87x flash parts.
There is a hidden problem with programming these parts and it relates to
the low voltage program mode and the low voltage program control pin RB3.
The type of programming problems I found are similar to those reported on
the piclist by several others.

When these parts a blank (like when new) or any other time the when the LVP
config bit is programmed as a '1' the state of RB3 becomes an issue. It
must NOT
be tied high as VDD rises or unpredictable results occur. I could not get any
satisfaction trying to read or program a part in this condition. Exactly
why I
cannot say. It appears that the chips cannot enter either the low or high
voltage
programming state.  This condition is not documented in the programming
specs so
we are left to wonder.

If RB3 is low there is no problem.

It would not be a good idea to leave RB3 floating as it is an input. I
believe this
may also cause unpredictable results but based on my tests they are not as
common as
when RB3 is held high.

The implications of this are:

1) Some programmers will not be able to program these flash parts unless
modified.
Three programmers in this boat include the propic II, Multi picpro and the
first
release of my own warp-13 (there are details of work arounds on my web page.
The newer Warp-13a has a hardware fix.) No doubt there are other
programmers in
this group.

2) Most programmers should have a resistor fitted to ground on RB3 to
prevent this
input from floating.

3) ICSP will need to be modified to allow for the role of RB3. For many
apps 5-wire ICSP
will need to became 6-wire ICSP with RB3 also connected. If the target circuit
holds RB3 low this will not be required.

4) Care must be taken to ensure that the circuit on a target board ICSP
allows for
RB3 to be pulled low via the programmer.

I believe when these considerations are taken the problems with programming
the flash
parts will disappear as they have for me.

Jim

</quote>

Octavio (PROPIC II) also had discovered this problem independently from
myself and Tony's
solution is actually originally from Octavio who told me in private email
(after I
had posted the above) and I told Tony in a phone conversation. My solution
was to add a
separate transistor switching stage to the RB3 pin.



Regards,

Jim Robertson
NEWFOUND ELECTRONICS
________________________________________
Email: newfoundEraseMEspampipeline.com.au
http://www.new-elect.com
MPLAB compatible PIC programmers.
________________________________________

2000\04\04@062536 by briang

flavicon
face
In-Reply-To: <RemoveME38E96746.59DA0082EraseMEspamspam_OUTeng.monash.edu.au>

Tony Nixon <@spam@Tony.NixonRemoveMEspamEraseMEENG.MONASH.EDU.AU> wrote:
> Byron A Jeff wrote:
> > > Use a 10K resistor from RB3 to +5V and a 100N cap from RB3 to GND.
>
> > The circuit you show above would pull RB3 from 0 to 5 volts. But is this
> > necessary if MCLR is going from 0 to 13V?
>
> It holds RB3 low during powerup only. Sometimes the chip won't program

Why can't you just pull RB3 down with a resistor?
Why does it need to go high after it's been low during power up?

Brian Gregory.
EraseMEbriangspam@spam@cix.co.uk

'need PIC16F877 in SF Bay area (10-12 April) !!!'
2000\04\10@140515 by Chris Cavigioli

flavicon
face
I have a PIC16F877 which just got fried and I've ported my application back
to my PIC16F84, but I would prefer to get another PIC16F877 today or
tomorrow because I am close to the very limit of the 'F84 1K internal
program memory limit.

I'm in the Sunnyvale/San Jose, CA area days and San Francisco evenings.

The application must be complete for an art show opening on 13 April in San
Francisco.

Can anyone let me know where I can zoom by with my car and pick one up in
this area?  Price is not so critical.

cellphone:  (415) 254-4545
office:     (650) 584-5591

Help is greatly appreciated!
Thanks in advance,
-chris

P.S.
We are creating a large-scale art installation using 2 x Polaroid 6500
ultrasonic sensors and 60 DC electric motors to control this interactive
art work.  I created a system which expanded the I/O of the PIC16F84 to 120
inputs and 120 outputs using a 4-wire serial link via 8-conductor LAN
cables (differential pairs using AM26LS31 and AM26LS32A).  It's very cool
(if it works).  The PIC talks to a Macintosh via s/w UART (or '877 h/w
USART).  The Macintosh is running MAX MIDI software from IRCAM to control
this whole thing.

We are still having problems with the 6500 sonars.  We have tried many
things to get them to detect up to the advertised 35 feet.  All tries have
seen a distance limit of 19 feet.  Any hints are welcome.

Contact me if you'd be interested to see this or help me get my last bugs
sorted out!

2000\04\10@150519 by Richard Poland

flavicon
face
Chris,
If you can't find one in your area, try Digi-Key (http://www.digi-key.com), they stock
the
DIP and PLCC versions and can ship overnight (you can try for same day)
to most of North America (even to us up here in Canada).

Richard

Chris Cavigioli wrote:

{Quote hidden}

2000\04\10@150736 by Erik Reikes

flavicon
face
I've got one kicking around here somewhere, but I'm in San Diego.  I could
fed ex you one.

I did a similar project when I was in college (not nearly as complex).  It
consisted of a face that had articulated features (eyes and mouth) that
would change expression based on how far away you were from it.  I didn't
have the dough for the polaroid ranger so I used IR interrupters.  When a
viewer would walk closer to the face it would smile.  When they walked away
it would frown.

My stepper motor driver was a couple of relays which would unfortunately
cause the PIC84 I was using to reset occasionally causing some really
strange expression to come out.  All the art students thought my face was
artistically horrible, but when they turned it around and saw the balsa and
kite string counterbalance arrangement they thought that it was really cool
and said this and that about the human condition.  As a result my face was
displayed facing backwards....

Let me know if you still need the 877 and I'll drop it off to fed ex. this
afternoon.

At 10:52 AM 4/10/00 -0700, you wrote:
{Quote hidden}

Erik Reikes
Senior Software Engineer
Xsilogy, Inc.

@spam@ereikesspam_OUTspam.....xsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\04\10@151808 by William Bross

flavicon
face
You may want to try Fry's Electronics
550 E. Brokaw Road
San Jose, CA
(408) 487-1000
(408) 487-1018 FAX

Holiday Hours
Monday-Friday 8AM - 10PM
Saturday 9AM - 10PM
Sunday 9AM - 8PM

Bill

At 10:52 AM 4/10/00 -0700, you wrote:
{Quote hidden}

2000\04\10@182150 by Chris Cavigioli

flavicon
face
Fry's doesn't carry PICs ... I asked them (Arques Ave store).
-chris

At 03:17 PM 4/10/00 -0400, you wrote:
{Quote hidden}

2000\04\10@182753 by Chris Cavigioli

flavicon
face
Thanks, I'll try to find one here, but check again at 5pm today if nothing
else turns up.  I'd need 10 MHz version.
-chris

more later.....

At 12:11 PM 4/10/00 -0700, you wrote:
{Quote hidden}

'RS232 / Comm problem with PIC16F877'
2000\04\19@052832 by Jonathan Evans

flavicon
face
Hello all,

We have a PIC16F877 ICD development board (from Microchip) which we use
with MPLAB (v5). We have been trying to develop the first stage of
serial line communication protocol for the PIC but are having the
most annoying problem - and I'm going round in circles with it.

I cannot seem to successfully receive characters. Transmission has proved
to be fine, but reception gives a constant FERR (framing error). I
understand that this is caused by the
"reception of STOP bit as 0 instead of 1".

I have attached a file (commtest.asm) to try and illustrate what we are
doing, and the register configuration we are trying. The program tries to
simply echo each character back to the RS232 line as it is received (we
are using a standard MAX233 device for the TTL->RS232 voltage conversion).



; ===============================================================
; commtest.asm
; ===============================================================

list p=16f877

; Include file, change directory if needed
 include "p16f877.inc"


; Start at the reset vector
 org 0x000
 nop
Start


Main

  call InitComm
  goto EchoTest

InitComm
     ; At first we didn't have the the PORTC / TRISC
     ; code (because the Microchip code doesn't
     ; mention them - but we have included them to try

  bcf STATUS,5     ; select BANK 0
  bcf STATUS,6
  movlw 0x00       ; Set PORTC to all ZEROS
  movwf PORTC

  bsf STATUS,5     ; Select BANK 1
  bcf STATUS,6

  movlw 0xC0       ; Select PORTC bits 6 & 7 to USART
  movwf TRISC

     ; We have tried a range of baud rates, included 300, 9600, 19.2K
     ; at both high and low clock rates (BRGH)
  movlw   0x0B
  movwf SPREG      ;SPERG = 11 (for 19.2K high speed)
  movlw 0x24       ;Set TXSTA for Async, High speed, 8 bit data
  movwf TXSTA
  bcf PIE1,TXIE    ;Disable Transmission Interrupt
  bcf PIE1,RCIE    ;Disable Receive Interrupt


  bcf STATUS,5     ; Select BANK 0
  bcf STATUS,6

  movlw 0x90       ; Set RXSTA for Async, 8 bit data
  movwf RCSTA

   return


EchoTest
  bcf STATUS,5      ; Select BANK 0
  bcf STATUS,6

RCIFloop
  btfss PIR1,RCIF   ; Loop, while RCIF = 0
  goto RCIFloop

  btfss RCSTA,FERR  ; Check for Frame-Error
  goto NoFRAMEError ; If no FERR then skip

  movf RCREG,0      ; Copy RCREG -> w

  ;bcf RCSTA,CREN   ; Tried this ... doeen't make difference
  ;bsf RCSTA,CREN   ; Clears error (flag CREN 0 then 1)
  goto TXIFloop     ; Jump to Transmission Loop

NoFRAMEError
  movf RCREG,0      ; Copy RCREG -> W

TXIFloop
  btfss PIR1,TXIF   ; Loop, while TXIF = 0
  goto TXIFloop

  movwf TXREG       ; Copy W -> TXREG
  goto RCIFloop     ; Jump to start of loop

  end
; ===============================================================



We have noticed the following which might help to identify the problem:

* We have confirmed the baud rate is correct using a scope and logic
analyser (we are using a clock freq of 3.6864 MHz).

* We seem to have no problem with transmission, all characters are correctly
received.

* The busy-wait on the RCIF flag seems to work correctly. The program will
wait forever until a character is sent to the PIC, at which point the
program continues immediately. This seems to indicate the detection of the
START bit is OK.

* The value of the RCREG is *always* 0x00. This is suspicious because I
understand we should see the bit pattern that was received, even if it is
marked as possible framing error.

* Because of the above, it has occured to me that since every bit is seen as
0, then the STOP might also and hence the FERR. However, I don't understand
why every bit is seen as 0 ... especially when the START bit transition from
1 -> 0 is detected OK.

* It has also occured to me that the "constant" zero problem might be
because the direction register of PORTC is incorrect (TRISC). However,
looking around similar code and playing with the value seems not to have
helped.

* We have played around with 9 bit data and 2 stop bits and confirmed with
the logic analyser that the timing of the stop bit sample seems to be
correct (i.e. after the data has ended and the line has returned to logic
HIGH).


Sorry for the length of this, but I am at a complete loss as to how to
proceed further. Any help or advice that anyone could give would be very
gratefully received.

Many thanks in advance,

Jonathan

====================================================================
Dr Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool               E-Mail: evansjonspamBeGonespamliv.ac.uk
LIVERPOOL   L69 3GJ                       Fax: (+44)-(0)151-794-4540
United Kingdom (UK)                       Tel: (+44)-(0)151-794-4602
====================================================================

2000\04\19@060640 by Wollenberg, Frank

flavicon
face
Jonathan,
I have your code revisited and no failure detected.
The only principal difference compared to my UART rx/tx coding is the
initializing of RC6/7 port pins. I'm programming TxD as output and RxD as
input. I know, there was a thread on this list discussing that. Many
piclister has initialized the ports as input or output (i didn't remember).
Try my initializing coding, it's an iddea.
Frank

{Quote hidden}

2000\04\19@070154 by Jonathan Evans

flavicon
face
Guten Tag Frank,

Thanks for replying to my message. I had already playing with the TRISC
register but after your message I have tried it again.

I have tried changing from

   TRISC = 0xC0
to
   TRISC = 0x80

Does this sound correct ? What values are other people using ?

However, it still doesn't work (no visible difference anyway).

Looking at the PIC16F877 data sheet it seems to imply that the direction reg
is automatically set by enabling the USART peripheral (SPEN) ... however
seem to be able you fiddle with it afterward.

I have tried changing the RX pin (RC7) to an output and the RCIF flag
doesn't seem to trigger on a start bit any longer.

Has anyone else come across this constant FERR problem ... it got to be
something simple ...

BTW, I forgot to mention last time that I swap the PIC for an identical one
and same problem (just in case it was a fault chip).

Thanks again,

Jonathan


{Original Message removed}

2000\04\19@102119 by M. Adam Davis

flavicon
face
I've checked your code against mine, and cannot see any reason why you are not
getting the serial info.  I imagine you've gone over the wiring multiple times,
but it almost seems like you have an electrical problem.  Perhaps RTS is going
into your RX?  It may (depending on handshaking) go low for the entire byte,
causing all zeros and a framing error.  Perhaps your interface circuit (max232
or other) is fried?

Jonathan Evans wrote:
{Quote hidden}

2000\04\19@102320 by M. Adam Davis

flavicon
face
I set TRISC to 0b.1100.0000 (0xC0) for both rx/tx as input.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}

2000\04\19@111759 by Jonathan Evans

flavicon
face
Hi Adam,

Thanks for your message. Yep, it very odd indeed.

The MAX233 is fine, I can see the TX and RX signal both before and after.
I've also swapped the PIC itself with another identical unit and same
problem.

One thing though, I not using any handshaking ... should I? I only have a
RX/TX/GND lines. The PIC USART doesn't rely on the extra timing information
handshaking would provide would it ? I have seen other people's code that
uses RTS/CTS but implemented though some other port lines (used to enable /
disable various parts of the USART).

However, the specification document doesn't mention them so I assumed they
were optional. Are they ?

Thanks,

Jonathan

{Original Message removed}

2000\04\19@112833 by M. Adam Davis

flavicon
face
No, the PIC doesn't need or use handshaking in the hardware UART.  If you can
see the signal going into the PIC and verify that it is within parameters, then
you should be all set.

You should probably check other factors, then.  Put bypass caps on the PIC,
check the OSC2 and make sure the crystal is actually at 3.6864MHz, etc.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}

2000\04\19@114454 by James Paul

flavicon
face
Guys,

Just a thought.  I know on a PC , the RS232 data is inverted by
the computer when transmitted, and reinverted when received by
the receiving system.  And, I see you you're not using a PC at
this time, but are you inadvertently (or purposely) inverting
the data, and trying to receive on the wrong edge?
Like I say, just a thought.

                                      Regards,

                                        Jim



On Wed, 19 April 2000, "M. Adam Davis" wrote:

{Quote hidden}

> > {Original Message removed}

2000\04\19@114911 by Kčbek Tony

flavicon
face
Hi,
Just a thought:

>We have a PIC16F877 ICD development board (from Microchip) which we use
>with MPLAB (v5). We have been trying to develop the first stage of
>serial line communication protocol for the PIC but are having the
>most annoying problem - and I'm going round in circles with it.

Are You trying to use the uart while using the ICD at the same time ?
In that case a snip from the ICD User guide: "RB6 & RB7 reserved for
programming"

I sucks, doesn't it ? the one thing that's really hard to debug is
serial comm's
and in that case the ICD is useless. :-(

So to sum it up: Debugging/using/looking/fiddling/etc with the UART
while using the ICD is not allowed/impossible/etc.

Therefore I'm going to try to make an serial framework app (
as the exellent initiative from Thomas McGahee the other day )
for the 16F87xx ( with initialisation, buffers, terminator handling,
token parser, etc ), I just need more time :-) .....
Its a bit hard to debug, my ICD doesnt help me....


/Tony


Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: tony.kubekEraseMEspam@spam@flintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\04\19@120749 by Andrew Kunz

flavicon
face
part 0 3027 bytes
Tony,

The UART is on RC not RB.  RB 4-7 are the
interrupt-on-change-when-I-feel-like-it pins.

Andy










K

Ÿbek Tony <RemoveMEtony.kubekspamspamBeGoneFLINTAB.COM> on 04/19/2000 11:41:58 AM

Please respond to pic microcontroller discussion list <spamBeGonePICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
                                                                               
                                                                               
                                                                               


                                                             
                                                             
                                                             
To:      PICLISTspam_OUTspam@spam@MITVMA.MIT.EDU                              
                                                             
cc:      (bcc: Andrew Kunz/TDI_NOTES)                        
                                                             
                                                             
                                                             
Subject: Re: RS232 / Comm problem with PIC16F877            
                                                             








Hi,
Just a thought:

>We have a PIC16F877 ICD development board (from Microchip) which we use
>with MPLAB (v5). We have been trying to develop the first stage of
>serial line communication protocol for the PIC but are having the
>most annoying problem - and I'm going round in circles with it.

Are You trying to use the uart while using the ICD at the same time ?
In that case a snip from the ICD User guide: "RB6 & RB7 reserved for
programming"

I sucks, doesn't it ? the one thing that's really hard to debug is
serial comm's
and in that case the ICD is useless. :-(

So to sum it up: Debugging/using/looking/fiddling/etc with the UART
while using the ICD is not allowed/impossible/etc.

Therefore I'm going to try to make an serial framework app (
as the exellent initiative from Thomas McGahee the other day )
for the 16F87xx ( with initialisation, buffers, terminator handling,
token parser, etc ), I just need more time :-) .....
Its a bit hard to debug, my ICD doesnt help me....


/Tony


Tony K

Ÿbek, Flintab AB
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: spamBeGonetony.kubek@spam@spamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ


2000\04\19@122226 by Jonathan Evans

flavicon
face
Hi,

So are we saying that the RB6 & RB7 problem limits use of the USART (which I
thought was only on RC6 and RC7). Transmission seems to work OK, but
Reception ...

I have noticed though that the USART flags TXIF and RCIF never change state
in STEP mode. I have therefore been running the code without
debug-interruption.

Is there some other flag / MPLAB setting which I must change to prevent it
interferring with the USART ... or is it impossible to use the ICD
development kit for Serial comms (seems unlikely ... especially since there
is room for a MAX232 and DB9 connection on the development board).

Thanks,

Jonathan


{Original Message removed}

2000\04\19@142013 by Kčbek Tony

flavicon
face
>Tony,

>The UART is on RC not RB.  RB 4-7 are the
>interrupt-on-change-when-I-feel-like-it pins.

>Andy

OOoops...
sorry You are entirely correct, RB6 & RB7 has nothing to do with the
uart
when concerning the pic, my project however needed these for
other communication related issues so I had 'this in my head' when
writing the un-thoughtful mail.
Again sorry to all thoose on the list,

ICD does help when using the internal UART :-)


/Tony


Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: RemoveMEtony.kubekEraseMEspamKILLspamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\04\19@153537 by James Paul

flavicon
face
Jonathan,

Have you figured out anything yet?  I was just curious as I
seen the discussion fall off the list.

                                     Regards,

                                       Jim



On Wed, 19 April 2000, Jonathan Evans wrote:

{Quote hidden}

> {Original Message removed}

2000\04\19@154744 by M. Adam Davis

flavicon
face
I have the next few days off.  If I have time, I'll use my ICD (homebuilt) to
program the 16f877 with very basic serial code, and test it out.  When it works
(it'll work, if it knows what's good for it!) I'll send you the asm file, and
you can see if it works similarily on yours.

If it doesn't work, then at least I can spend some time debugging it.

-Adam

Jonathan Evans wrote:
{Quote hidden}

2000\04\20@054314 by Claudio Rachiele IW0DZG

flavicon
face
Jonathan, the following code in not all mine.
I have copied it from net and it doesn't work. I have debugged it until
everything works.
Hope this can help you.

    Title  "USART TESTER"
    ;
    ; Author  Claudio RACHIELE IW0DZG
    ;
    ; Working  20000318
    ;
    list p=16f877,c=140    ; processor type
    errorlevel          1, -(305)
    #include "p16f877.inc"
    __CONFIG  _PWRTE_ON&_HS_OSC&_LVP_OFF&_WDT_OFF

temp  equ   7Fh               ;
;
; -----------
; DESCRIPTION
; -----------
;
; Baud Rate = 9600, No Parity, 8 bits & 1 Stop Bit
;
; -------------
; PROGRAM START
; -------------
;
    org  0         ; startup = 0000H
    clrf STATUS         ; bank 0
    goto BootStart
    org  4
ISR  goto 5         ;
    org  5
;
; --------------------------------------------------
; SET UP THE PORTS TO SUIT YOUR CIRCUIT REQUIREMENTS
; --------------------------------------------------
;

BootStart
    banksel PORTA       ; bank0
    movlw     b'00000000'
    movwf     PORTA
    movlw     b'00000000'
    movwf     PORTB
    movlw     b'01000000'
    movwf     PORTC
    movlw     b'00000000'
    movwf     PORTD
    movlw     b'00000000'
    movwf     PORTE

    banksel TRISA       ; bank1
    movlw     b'00000001'
    movwf     TRISA
    movlw     b'00000000'
    movwf     TRISB
    movlw     b'11000000'    ; set RC6 & RC7 as input
    movwf     TRISC
    movlw     b'00000000'
    movwf     TRISD
    movlw     b'11101000'
    movwf     TRISE
    movlw     b'00000111'
    movwf     ADCON1         ; porta inputs = digital not analog
;
; BAUD RATE SETTINGS
;
                   ;  Baud Values with BRGH = 0
                   ;  ((20000000/9600)/64)-1 = 32
;    movlw     d'207'    ;  1200 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'103'          ;  2400 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'25'           ;  9600 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'12'           ; 19200 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'255'          ;  1200 baud @ 20 Mhz Fosc +1.73 err
;    movlw     d'129'          ;  2400 baud @ 20 Mhz Fosc +0.16 err
;    movlw     d'32'          ;  9600 baud @ 20 Mhz Fosc -1.36 err
;    movlw     d'15'          ; 19200 baud @ 20 Mhz Fosc +1.73 err

                   ;  Baud Values with BRGH = 1
                   ;  ((20000000/9600)/16)-1 = 32
    movlw     d'129'         ;  9600 baud @ 20 Mhz Fosc +0.16 err
    movwf     SPBRG
    movlw     b'00100100'    ; brgh = 1
    movwf     TXSTA           ; enable Async Transmission, set brgh
    banksel RCSTA       ; bank0
    movlw     b'10010000'
    movwf     RCSTA          ; enable Async Reception
    movf RCREG,w
    movf RCREG,w
    movf RCREG,w        ; flush receive buffer
;
;
; ------------------------------------
; PROVIDE A SETTLING TIME FOR START UP
; ------------------------------------
;
    clrf temp
Settle
    decfsz  temp
    goto Settle

LWaitCom
    call      RecLoop         ; wait and read from RS232
    movwf     PORTB          ; show value for diagnostic purpose
TxLoop
    nop
    btfss     PIR1,TXIF ;xmit buffer empty?
    goto TxLoop         ;no, wait

    movwf     TXREG

    goto LWaitCom  ; no
;
; ----------------------------
; RECEIVE CHARACTER FROM RS232
; ----------------------------
; This routine does not return until a character is received.

RecLoop
    nop
    btfss     PIR1,RCIF ; check for received data
    goto RecLoop
    movf RCREG,w
    return
    end

CIAO
                      Claudio Rachiele IW0DZG


Jonathan Evans <.....evansjonspamRemoveMELIVERPOOL.AC.UK> on 04/19/2000 11:15:49 AM

Please respond to pic microcontroller discussion list
     <PICLISTspam@spam@MITVMA.MIT.EDU>

To:   undisclosed-recipients:;, EraseMEPICLISTRemoveMEspamSTOPspamMITVMA.MIT.EDU
cc:    (bcc: Claudio Rachiele IW0DZG/Italy/IBM)
Subject:  RS232 / Comm problem with PIC16F877




Hello all,

We have a PIC16F877 ICD development board (from Microchip) which we use
with MPLAB (v5). We have been trying to develop the first stage of
serial line communication protocol for the PIC but are having the
most annoying problem - and I'm going round in circles with it.

I cannot seem to successfully receive characters. Transmission has proved
to be fine, but reception gives a constant FERR (framing error). I
understand that this is caused by the
"reception of STOP bit as 0 instead of 1".

I have attached a file (commtest.asm) to try and illustrate what we are
doing, and the register configuration we are trying. The program tries to
simply echo each character back to the RS232 line as it is received (we
are using a standard MAX233 device for the TTL->RS232 voltage conversion).



; ===============================================================
; commtest.asm
; ===============================================================

list p=16f877

; Include file, change directory if needed
 include "p16f877.inc"


; Start at the reset vector
 org 0x000
 nop
Start


Main

  call InitComm
  goto EchoTest

InitComm
     ; At first we didn't have the the PORTC / TRISC
     ; code (because the Microchip code doesn't
     ; mention them - but we have included them to try

  bcf STATUS,5     ; select BANK 0
  bcf STATUS,6
  movlw 0x00       ; Set PORTC to all ZEROS
  movwf PORTC

  bsf STATUS,5     ; Select BANK 1
  bcf STATUS,6

  movlw 0xC0       ; Select PORTC bits 6 & 7 to USART
  movwf TRISC

     ; We have tried a range of baud rates, included 300, 9600, 19.2K
     ; at both high and low clock rates (BRGH)
  movlw   0x0B
  movwf SPREG      ;SPERG = 11 (for 19.2K high speed)
  movlw 0x24       ;Set TXSTA for Async, High speed, 8 bit data
  movwf TXSTA
  bcf PIE1,TXIE    ;Disable Transmission Interrupt
  bcf PIE1,RCIE    ;Disable Receive Interrupt


  bcf STATUS,5     ; Select BANK 0
  bcf STATUS,6

  movlw 0x90       ; Set RXSTA for Async, 8 bit data
  movwf RCSTA

   return


EchoTest
  bcf STATUS,5      ; Select BANK 0
  bcf STATUS,6

RCIFloop
  btfss PIR1,RCIF   ; Loop, while RCIF = 0
  goto RCIFloop

  btfss RCSTA,FERR  ; Check for Frame-Error
  goto NoFRAMEError ; If no FERR then skip

  movf RCREG,0      ; Copy RCREG -> w

  ;bcf RCSTA,CREN   ; Tried this ... doeen't make difference
  ;bsf RCSTA,CREN   ; Clears error (flag CREN 0 then 1)
  goto TXIFloop     ; Jump to Transmission Loop

NoFRAMEError
  movf RCREG,0      ; Copy RCREG -> W

TXIFloop
  btfss PIR1,TXIF   ; Loop, while TXIF = 0
  goto TXIFloop

  movwf TXREG       ; Copy W -> TXREG
  goto RCIFloop     ; Jump to start of loop

  end
; ===============================================================



We have noticed the following which might help to identify the problem:

* We have confirmed the baud rate is correct using a scope and logic
analyser (we are using a clock freq of 3.6864 MHz).

* We seem to have no problem with transmission, all characters are
correctly
received.

* The busy-wait on the RCIF flag seems to work correctly. The program will
wait forever until a character is sent to the PIC, at which point the
program continues immediately. This seems to indicate the detection of the
START bit is OK.

* The value of the RCREG is *always* 0x00. This is suspicious because I
understand we should see the bit pattern that was received, even if it is
marked as possible framing error.

* Because of the above, it has occured to me that since every bit is seen
as
0, then the STOP might also and hence the FERR. However, I don't understand
why every bit is seen as 0 ... especially when the START bit transition
from
1 -> 0 is detected OK.

* It has also occured to me that the "constant" zero problem might be
because the direction register of PORTC is incorrect (TRISC). However,
looking around similar code and playing with the value seems not to have
helped.

* We have played around with 9 bit data and 2 stop bits and confirmed with
the logic analyser that the timing of the stop bit sample seems to be
correct (i.e. after the data has ended and the line has returned to logic
HIGH).


Sorry for the length of this, but I am at a complete loss as to how to
proceed further. Any help or advice that anyone could give would be very
gratefully received.

Many thanks in advance,

Jonathan

====================================================================
Dr Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool               E-Mail: RemoveMEevansjonKILLspamspamTakeThisOuTliv.ac.uk
LIVERPOOL   L69 3GJ                       Fax: (+44)-(0)151-794-4540
United Kingdom (UK)                       Tel: (+44)-(0)151-794-4602
====================================================================

2000\04\21@104417 by M. Adam Davis

flavicon
face
I set TRISC to 0b.1100.0000 (0xC0) for both rx/tx as input.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}


'Does any one have a PIC16F877 programmer schematic'
2000\06\08@120426 by Ricardo Reis
flavicon
face
part 0 122 bytes

--  Rfiles  --  2000 --
Rfiles Productions

Attachment converted: creation:Ricardo Jorge Reis.vcf (TEXT/CSOm) (00016307)

2000\06\08@144537 by Don B. Roadman

flavicon
face
On 7 Jun 2000, at 19:08, Ricardo Reis wrote:

> Thanks
>
>
> --  Rfiles  --  2000 --
> Rfiles Productions
>
Ricardo, I'm not sure if I got all your message, as it is in some
strange format. Is it some microsoft stuff? Anyway, damn near
anything will program an 877. The old old david tait programmer will
program an 877. I am currently using an ITU programmer which I
bought for roughly $15 a few years ago. I think he (Cris
Sakkas) died, but his design was just a david tait clone. The only
thing I have ever done was to use a pulldown resistor to be sure the
low voltage programming pin wasnt floating.

2000\06\08@151441 by John Hansen

flavicon
face
<x-flowed>At 01:42 PM 6/8/00 -0500, you wrote:
>On 7 Jun 2000, at 19:08, Ricardo Reis wrote:
>
> > Thanks
> >
> >
> > --  Rfiles  --  2000 --
> > Rfiles Productions
> >
>Ricardo, I'm not sure if I got all your message, as it is in some
>strange format. Is it some microsoft stuff? Anyway, damn near
>anything will program an 877. The old old david tait programmer will
>program an 877. I am currently using an ITU programmer which I
>bought for roughly $15 a few years ago. I think he (Cris
>Sakkas) died, but his design was just a david tait clone. The only
>thing I have ever done was to use a pulldown resistor to be sure the
>low voltage programming pin wasnt floating.


Which software are you using with it for 877's?

TNX,

John Hansen

</x-flowed>

2000\06\08@165335 by Don McKenzie

flavicon
face
John Hansen wrote:
{Quote hidden}

http://www.dontronics.com/p16pro.html will work with it.

Don McKenzie    spamBeGonedonspam@spam@dontronics.com      http://www.dontronics.com

The World's Largest Range of Atmel/AVR  & PICmicro Hardware and Software
Free Basic Compiler and Programmer http://www.dontronics.com/runavr.html
The Little "rAVeR!" AVR & Basic Kit http://www.dontronics.com/dt006.html

2000\06\08@180516 by Don B. Roadman

flavicon
face
On 8 Jun 2000, at 15:13, John Hansen wrote:

> Which software are you using with it for 877's?
>
> TNX,
>
> John Hansen

Almost any software will work with it. P16pro, for example. Propic
should work if you swap the invertor chip for a noninverting buffer
chip.  These programmers were just another of the zillion David tait
variants, so any programming software that works with a david tait
will work with them. Just check to make sure the pins are correct
for each of the programming signals, and that the polarity is correct.

2000\06\08@184536 by Tony Nixon

flavicon
picon face
Ricardo Reis wrote:
>
> Thanks
>
> --  Rfiles  --  2000 --
> Rfiles Productions

Check out ROMzap and raid your junk bin for the bits.

http://www.picnpoke.com/demo/romzap.html

--
Best regards

Tony

http://www.picnpoke.com
RemoveMEsalesspam_OUTspampicnpoke.com

2000\06\14@085006 by Don B. Roadman

flavicon
face
On 8 Jun 2000, at 15:13, John Hansen wrote:

> Which software are you using with it for 877's?
>
> TNX,
>
> John Hansen

Almost any software will work with it. P16pro, for example. Propic
should work if you swap the invertor chip for a noninverting buffer
chip.  These programmers were just another of the zillion David tait
variants, so any programming software that works with a david tait
will work with them. Just check to make sure the pins are correct
for each of the programming signals, and that the polarity is correct.

'Is there Any PIC16F877 circuits/projects archive ?'
2000\06\14@123831 by Albert Goodwill

picon face
Is there Any PIC16F877 circuits/project archive ?

albertgoodwillspamspamyahoo.com



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

'[PIC] PIC16F877 projects archive'
2000\06\16@115311 by Albert Goodwill

picon face
Where can I find PIC16F877 based sample projects ?

spam_OUTalbertgoodwillspam_OUTspamspam_OUTyahoo.com



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


'[PICLIST] Multiple serial INPUT lines on PIC16F877'
2000\07\11@142707 by Albert Goodwill
picon face
I would like to use multiple (4) lines as serial (RS232) data input line for
PIC16F877.
Data comes to PIC16F877continuously from all serial channels.
I  will perform a very simple calculation on incoming data and control a R/C
servo (PWM) motor as a function of this calculation.

               ====================
               |                                             |
        ---->|Serial data in 1        PWM |-------> R/C Servo motor
        ---->|Serial data in 2                   |----
        ---->|Serial data in 3                   |----
        ---->|Serial data in 4                   |----
               |                                             |
                ====================

Questions:
(1) Is it possible to get data from multiple serial channels simultaneously?
(2) Is it possible to use higher than 9600 baud rate for channels?
(3) Can I use timerX interrupt to perform "background" calculation?
(4) Can I use timerY to generate PWM signal while using multiple serial
input channels?
(5) Is there any limititation on use of timer interrupt when using multiple
serial input channels?
(6) Any example on above mention topics?
(7) Many thanks...

albertgoodwillspam_OUTspamyahoo.com



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

'[PIC]: Multiple serial INPUT lines on PIC16F877 an'
2000\07\11@145554 by M. Adam Davis

flavicon
face
See below for comments...

Albert Goodwill wrote:
>
> I would like to use multiple (4) lines as serial (RS232) data input line for
> PIC16F877.
> Data comes to PIC16F877continuously from all serial channels.
> I  will perform a very simple calculation on incoming data and control a R/C
> servo (PWM) motor as a function of this calculation.
>
>                ====================
>               |                    |
>          ---->|Serial data in 1PWM |-------> R/C Servo motor
>          ---->|Serial data in 2    |----
>          ---->|Serial data in 3    |----
>          ---->|Serial data in 4    |----
>               |                    |
>                ====================
>
> Questions:
> (1) Is it possible to get data from multiple serial channels simultaneously?

Yes

> (2) Is it possible to use higher than 9600 baud rate for channels?

Yes, but trickier.  Plan on using a clock speed of 16MHz or more

> (3) Can I use timerX interrupt to perform "background" calculation?
> (4) Can I use timerY to generate PWM signal while using multiple serial
> input channels?

Yes, you will also then need another timer for the serial reception.

> (5) Is there any limititation on use of timer interrupt when using multiple
> serial input channels?

If you use interrupts for other things, you will need to use an interrupt for
the serial reception as well.

> (6) Any example on above mention topics?

Can't help there.  (no time to look)  Try checking the PIC archives for multiple
serial ports on PIC.

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\11@180418 by Bob Ammerman

picon face
There was a thread on this topic just a couple of weeks ago: multiple
bit-banged UARTs.  Check the PICLIST archive.

I have an (untested) implementation that will support 4 UARTs at relatively
high rates and will leave enough time to drive a PWM for the servo (which is
really a very low bandwidth operation).

Bob Ammerman
RAm Systems
(high performance, high function, low-level software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

'[PIC]: PicBasic Compiler for PIC16F877'
2000\07\23@120041 by Albert Goodwill

picon face
I'm happily using PicBasic Compiler for PIC16F84 .

Can it be used for PIC16F877?

albertgoodwilspamBeGonespam.....yahoo.com
l


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

'[PIC]: Some C and Basic codes to test PIC16F877 on'
2000\07\23@120656 by Albert Goodwill

picon face
(1) Where can I find some C and Basic codes to test PIC16F877 on DT106
board?

(2) Any LCD, serial I/O, PWM code ?

(3) I'm using demo version P16PRO 3.63 programming SW of Bojan Dobaj which
only allows 256 bytes of codes. Is there any other programming SW suitable
for DT106?

KILLspamalbertgoodwillspam.....yahoo.com



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

'[PIC]: PicBasic Compiler for PIC16F877'
2000\07\25@105508 by Randy A.

picon face
Check in your manual or in the list of PICs that can be compiled.  I have the
PicBasic Pro and I know it does a LOT of different PICs.

Randy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements


'[PIC]: Power supply supervisors for PIC16F877...'
2000\08\03@141523 by Jeffrey Siegel
flavicon
face
I used a Mitel MIC2754 power supply supervisor to control MCLR of a
PIC16F877 board (battery powered...as little current as possible!).  It
works fine but has the annoying specification of taking between 140ms and
560ms of "reset pulse width".  This seems crazy...especially being such a
wide setting.

I've never worked with the PIC before - are there other MCLR handlers which
are super low power and give lower (or more consistent) pulse widths for
this application?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\08\03@175039 by Olin Lathrop

flavicon
face
> I used a Mitel MIC2754 power supply supervisor to control MCLR of a
> PIC16F877 board (battery powered...as little current as possible!).  It
> works fine but has the annoying specification of taking between 140ms and
> 560ms of "reset pulse width".  This seems crazy...especially being such a
> wide setting.
>
> I've never worked with the PIC before - are there other MCLR handlers
which
> are super low power and give lower (or more consistent) pulse widths for
> this application?

I'm not sure exactly what your "power supply supervisor" is supposed to do,
but
are you aware that the PICs have brown out detect, power supply threshold
detect, and delayed startup?  For most applications the built in power up
features are sufficient so that you don't need external logic to release
MCLR once the power supply is fully up.  Unless you actually need an
external hard reset, you can usually tie MCLR to Vdd.  Check out section
12.3, "Reset", of the PIC16F87x manual starting on page 125.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinspamKILLspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[PICLIST] Programming Woes PIC16F877'
2000\10\26@105724 by Michael Rigby-Jones
flavicon
face
Yes, that old chesnut...again.

I have looked back through the last few weeks of comments from the likes of
Jim Robertson amnd Tony Nixon, but the particular problem I have dosen't
seem to have cropped up yet AFAICT.

I have a product using a 16F877 which is programmed via ICSP using a Promate
programmer.  RB3 has been asigned the role of an SPI clock, and during
programming is actually floating, which isn't generaly a good idea it seems.
However, until now we have *NEVER* had a problem.  All chips have programmed
and verified at high/low voltages.  The problem I am seeing is that after
programming some chips once, I can't program them again.  The fuses we
normaly use for programming are HS osc, brownout enabled, watchdog enabled,
power on timer enabled, all code protect disabled, low voltage programming
disabled, debug mode disabled.

Having tried to program the part, MPLAB reports a failure.  Further
investigation shows that none of the code  or data eeprom memory has been
programmed and the CPD config bit is somehow set.  The Promate seems to
perform a bulk erase at the start of the programming cycle, but it does not
erase anything!  I can read back all the original data from the chip.  In
fact the only things programable on these parts are the config bits apart
from CPD which seems to be remaining set (although it should not have been
set originaly)

I have tried everything I can think of, including grounding RB3 during
programming and grounding the osciliator pins.  I have verified the
programming voltages: clock, data and Vpp and all are correct. I now have 4
of these parts (which are SMD devices in a very small product so not too
easy to replace).  Any ideas?

Puzzled from Paignton.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@110528 by Michael Rigby-Jones

flavicon
face
Dang...forgot the header....

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\29@175736 by Tony Nixon

flavicon
picon face
Michael Rigby-Jones wrote:
>
> Yes, that old chesnut...again.

> I have tried everything I can think of, including grounding RB3 during
> programming and grounding the osciliator pins.

OSC2 is an output, so I wouldn't ground it, just OSC1.

This probably isn't the source of your problem though.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
salesspamspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\10\30@031904 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Having found our ICD, I connected it up, and it programmed the device
perfectly.  I wasn't convinced but a verify confirmed it.  So then I
reconnected it to the Promate and tried to read it.  All the program data
came back as 0x0FF (not even 0x3FF).  The device programmed with the ICD
worked perfectly.  The Promate continues to work fine with other parts, it's
just these few devices it will not program or read.  I have checked out the
ICSP cable and it's fine.  The FAE is down in a couple of days so I'll let
him figure it out!

Mike

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics





'[PIC]: PIC16F877 and 186 solenoids'
2000\11\07@191152 by Brent Brown
picon face
Hi,

I'm just sketching up an interesting looking project at the moment
that some of you might be able to offer advice on.

A PC in a machine needs to control a whole heap of 24V DC
miniature compressed air solenoid valves. There can be up to 186
of these solenoids in one machine. Only a few valves will be on
simultaneously, and they draw about 300mA each. Worst case
scenario is 20% of the valves on at the same time. Prime
objectives are speed of control by the PC (minimum software
overhead and time delay before valve actuation.) There might be
1000 valve operations per second.

My ideas so far:-

- PC parallel printer port connected to PSP on PIC16F877 for fast
byte-wise transfer of data from the PC.

- PIC stores an image of valve data in RAM.

- PIC drives a whole bunch of TPIC6A595 8 bit serial input DMOS
power driver shift register IC's, connected in series, with clock and
data line from the micro's synchronous serial port. 20MHz PIC can
clock data at 1.25 or 5MHz.

- Might arrange the power shift registers in groups with a strobe line
per group to speed up the process.

My questions?:-

- Can the PC parallel port in a fancy mode like ECP or EPP or
something automatically generate a strobe pulse when 8 bits of
data are output? This would reduce the PC overhead.

- Has anyone used the TPIC6A595 from TI, or the A6A595 from
Allegro with good or bad comments, hints or tips? Is the built in
protection any good?

- Any comments welcome.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spamBeGonebrent.brownspamclear.net.nz

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestSTOPspamspammitvma.mit.edu




2000\11\07@193728 by Tony Nixon

flavicon
picon face
Brent Brown wrote:
>
> My questions?:-
>
> - Can the PC parallel port in a fancy mode like ECP or EPP or
> something automatically generate a strobe pulse when 8 bits of
> data are output? This would reduce the PC overhead.
>
> - Has anyone used the TPIC6A595 from TI, or the A6A595 from
> Allegro with good or bad comments, hints or tips? Is the built in
> protection any good?
>
> - Any comments welcome.


You would still be limited by the OS of the PC as to how much data
transfer comes in/out of the parallel port.

186 bits, 1 for each solenoid = 24 bytes (worst case) of data to send
plus handshaking. Multiply this by 1000 changes / second and perhaps the
PC will not be able to cope reliably.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
RemoveMEsalesspamspampicnpoke.com

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspamRemoveMEmitvma.mit.edu




2000\11\08@044349 by Brent Brown

picon face
{Quote hidden}

Yep, thats what I'm afraid of. 1000 might be too high a figure to put
on it, don't know exactly what it will be. To write one byte of a data
to a standard parallel port you need one instruction to put out the
data and two more instructions to toggle the strobe line. 3
instructions where 1 could do.

I have been looking at EPP and ECP all day. Does pretty much
what I want - at this stage it all looks a bit too complicated, but I'm
keen to hear from anyone thats done this on a PIC.

Another option is just writing 7 bits of data to a standard parallel
port, with the 8th bit being 1 and 0 on alternate writes. From this
changing bit I can generate a logic pulse to strobe the data into the
latch (PSP port). One instruction on the PC and 7 bits of data is
transferred.

Solenoids will usually change one at a time, so rather than dump
24 bytes of data for all 186 solenoids in one go I'll just send the
address of the solenoid that needs to be turned on. One mode of
operation is to then get the PIC to turn off the solenoids a certain
period of time after each one gets turned on. This cuts data traffic
by a half. Think I can do that by having a one byte for each
solenoid, counting down every millisecond until it gets to zero and
the valve is turned off. Probably will have one PIC for each bank of
64 valves.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  KILLspambrent.brownspamspamspam_OUTclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@045906 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

I haven't yet seen the original post (delayed I guess) but 24bits x 1000
=24000 bits/sec which is < 3Kbytes sec. 100Kbytes/sec is fairly easily
obtainable on even a standard parallel port with a relatively modern CPU.

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@094116 by Olin Lathrop

flavicon
face
> A PC in a machine needs to control a whole heap of 24V DC
> miniature compressed air solenoid valves. There can be up to 186
> of these solenoids in one machine. Only a few valves will be on
> simultaneously, and they draw about 300mA each. Worst case
> scenario is 20% of the valves on at the same time. Prime
> objectives are speed of control by the PC (minimum software
> overhead and time delay before valve actuation.) There might be
> 1000 valve operations per second.

You didn't say what your target latency actually is, but your data rate isn't
that high.  You have 186 bits to control, which comes out to 24 bytes.  So
let's say 32 bytes need to be sent to define the desired state of all
valves.  At 115.2Kbaud, that's less than 3mS.  I'm guessing that is
acceptable, in which case RS-232 is a reasonable option.

I also don't know how much you can dedicate the solution to just this exact
task, or if you need to leave room in the architecture for some changes to
the requirements.  If you only need to sovle this specific problem, then you
could use a bunch of PICs in parallel as RS-232 to output bit converters.
Since communication is one way, all the PICs could listen to all the data,
then just react to the bits they control individually.  You need some scheme
so that the PICs can sync to the host data stream, but I doubt you will need
as many as 32 bytes to get 186 bits of payload.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinRemoveMEspamEraseMEcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@094738 by staff

flavicon
face
Brent Brown wrote:
{Quote hidden}

Brent, there are a LOT of pins on a parallel port;
data port:      8 lines bi-direction
status port:    5 input lines
control port:   6 output lines

That is from memory, I use the parallel port to control a few
things with projects. See:
http://www.senet.com.au/~cpeacock
for some really good port specs stuff.

If you use the 6 output lines for decoding you get 64 "banks"
of 8 data lines. I'm sure you could get more with some clever
software. 64x8 = 512 active output lines, with a refresh/update
of 1/64.

The parallel ports are also *very* quick if you can run without
windows, ie, dos only bootup.

Hope this helps!
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@095602 by Bob Ammerman

picon face
There are many ways of doing this. As Olin's message indicated we could help
a lot more if we had more details:

You say about 1000 'events' per second. Is that an average or a max.

How much delay is allowable between the time the PC wants to turn on an
output and when it actually happens. How much 'jitter' in that delay is
acceptable?

If the PC wants to turn on several outputs at once, how much difference in
the actual time they are turned on is acceptable?

What environment is the PC program running in (DOS, WIN9x WINnt, Linux,
???). This has a _huge_ bearing on attainable performance/latency.

Is this a one-off, or a production item?

How cost sensitive?

Anything else you can think of that might help us?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@095605 by Don Hyde

flavicon
face
My personal bias would be to put as much of the time-critical operation as
possible into the PIC, and let the PC mostly do slow and operator-interface
stuff.

I would go for higher-level commands going between the PC and the PIC.
Stuff like "turn on #43 for 27 mS".

For communications, unless you want to get into a lot of work qualifying
PC's, and messing with writing PC drivers and stuff, the only I/O you can
really count on is the serial port.  PC's pretty much always have serial
ports that will go to 115.2K, and Windoze exposes fairly usable API's for
them.  I've found the Windoze API's for the parallel port to be much less
friendly -- they distinctly assume that you have a printer hooked up to it,
with a printer driver for it.

Unless you're planning to run some non-M$ realtime OS on the PC, you have
absolutely no guarantees for timing, so I would put anything time- or
safety-critical into the PIC, where you have much more control over what is
going on.

> {Original Message removed}

2000\11\08@100215 by Bob Ammerman

picon face
Yep, Roman got me to thinking, this application don't need no stinkin' PIC
;-)

Just tie a bunch of TPIC6B595 serial power shift registers directly to the
parallel port.

One chain of shift registers on each data pin.

Use the other parallel port pins to clock in the data and strobe the shift
regs load input.

Done!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@100340 by Bob Ammerman

picon face
Yes, of course, the NO PIC idea I just posted assumes that you are running
Windowsless (and for really good time resolution DOSLESS).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: Don Hyde <TakeThisOuTDonHRemoveMEspam@spam@AXONN.COM>
To: <EraseMEPICLISTRemoveMEspamMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 9:54 AM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> My personal bias would be to put as much of the time-critical operation as
> possible into the PIC, and let the PC mostly do slow and
operator-interface
{Quote hidden}

it,
> with a printer driver for it.
>
> Unless you're planning to run some non-M$ realtime OS on the PC, you have
> absolutely no guarantees for timing, so I would put anything time- or
> safety-critical into the PIC, where you have much more control over what
is
> going on.
>
> > {Original Message removed}

2000\11\08@101413 by staff

flavicon
face
Bob Ammerman wrote:
>
> Yes, of course, the NO PIC idea I just posted assumes that you are running
> Windowsless (and for really good time resolution DOSLESS).
>

Actually dos doesn't chew timeslice unless you press a key or wiggle the
mouse. I have done a lot of testing and use home made dos programs
for port control with 100% timing accuracy. You can check the PIT chip
in the PC by passively polling it (3.?? MHz) to get ticks and use these
to
time events on the ports. I even check things like vertical retracing of
the video driver to give flicker free animation and stuff. The PC will
perform as accurately as a big PIC if you lose windows!!
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PICLIST] build problem with PIC16F877 - bank2'
2000\11\08@141850 by Sam Linder

flavicon
face
To all the smart PICers out there:

First let me apologize for the length of this query, but I felt that all of
the information was necessary.

I've got a strange build problem that doesn't make much sense to me and I'm
hoping someone out there can deciper the following data and explain what I'm
doing wrong (yes, I've read the Hi-Tech C Manual and read the Hi-Tech C Help
files). The following lines are lifted straight from the Error Section of
the Hi-Tech C Manual.

fixup overflow in expression *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255. This error
occurred in a complex expression.

fixup overflow referencing *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255.


In module COMOMAIN.C:
bank2 unsigned int  ui_flowsensor_threshold;

In module COMOSE~1.C:
extern bank2 unsigned int ui_flowsensor_threshold;

My PIC16F877 program is mostly written in C, with a bit of in-line assembly
tossed in as needed. As can be noted from the above lines, the variable
unsigned int  ui_flowsensor_threshold is defined as "living" in bank2 where
there appears to be plenty of room (see RAM Map at end of this email). Yet I
get the error messages seen below and my build fails. If I simply change the
variable to "live" in bank1, I get a successful compile. Que Pasa?


Building COMO.HEX...

Compiling COMOSE~1.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOSE~1.C"
Enter PICC -HELP for help

Compiling COMOMAIN.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOMAIN.C"
Enter PICC -HELP for help

Linking:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -INTEL -Ecomo.err
-Mcomo.map -PSECTMAP -16F877 -oCOMO.HEX -N -fakelocal -asmlist COMOSE~1.OBJ
COMOMAIN.OBJ COMO1W~1.OBJ COMODE~1.OBJ "
Error[000] comose~1.obj 134 : Fixup overflow referencing symbol
_ui_flowsensor_threshold (loc 0x19F6 (0x19B2+68), size 1, value 0x110)
Error[000] comose~1.rlf 2575 : Fixup overflow in expression (loc 0x78
(0x78+0), size 1, value 0x110)

MPLAB is unable to find output file "COMO.HEX".

Build failed.



UNUSED ADDRESS RANGES

BANK0            007F-007F
BANK1            00EC-00EF
BANK2            011F-016F
BANK3            0190-01EF
CODE             0800-0804
                 1000-1020
                 1800-1FFF
COMBANK          007F-007F
CONST            0800-0804
                 1000-1020
                 1800-1FFF

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@150900 by Sam Linder

flavicon
face
This message is being re-transmitted as I had forgotten the required [PIC]:
notation.

To all the smart PICers out there:

First let me apologize for the length of this query, but I felt that all of
the information was necessary.

I've got a strange build problem that doesn't make much sense to me and I'm
hoping someone out there can deciper the following data and explain what I'm
doing wrong (yes, I've read the Hi-Tech C Manual and read the Hi-Tech C Help
files). The following lines are lifted straight from the Error Section of
the Hi-Tech C Manual.

fixup overflow in expression *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255. This error
occurred in a complex expression.

fixup overflow referencing *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255.


In module COMOMAIN.C:
bank2 unsigned int  ui_flowsensor_threshold;

In module COMOSE~1.C:
extern bank2 unsigned int ui_flowsensor_threshold;

My PIC16F877 program is mostly written in C, with a bit of in-line assembly
tossed in as needed. As can be noted from the above lines, the variable
unsigned int  ui_flowsensor_threshold is defined as "living" in bank2 where
there appears to be plenty of room (see RAM Map at end of this email). Yet I
get the error messages seen below and my build fails. If I simply change the
variable to "live" in bank1, I get a successful compile. Que Pasa?


Building COMO.HEX...

Compiling COMOSE~1.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOSE~1.C"
Enter PICC -HELP for help

Compiling COMOMAIN.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOMAIN.C"
Enter PICC -HELP for help

Linking:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -INTEL -Ecomo.err
-Mcomo.map -PSECTMAP -16F877 -oCOMO.HEX -N -fakelocal -asmlist COMOSE~1.OBJ
COMOMAIN.OBJ COMO1W~1.OBJ COMODE~1.OBJ "
Error[000] comose~1.obj 134 : Fixup overflow referencing symbol
_ui_flowsensor_threshold (loc 0x19F6 (0x19B2+68), size 1, value 0x110)
Error[000] comose~1.rlf 2575 : Fixup overflow in expression (loc 0x78
(0x78+0), size 1, value 0x110)

MPLAB is unable to find output file "COMO.HEX".

Build failed.



UNUSED ADDRESS RANGES

BANK0            007F-007F
BANK1            00EC-00EF
BANK2            011F-016F
BANK3            0190-01EF
CODE             0800-0804
                 1000-1020
                 1800-1FFF
COMBANK          007F-007F
CONST            0800-0804
                 1000-1020
                 1800-1FFF

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]: PIC16F877 and 186 solenoids'
2000\11\08@161118 by Brent Brown

picon face
> Yep, Roman got me to thinking, this application don't need no stinkin' PIC
> ;-)
>
> Just tie a bunch of TPIC6B595 serial power shift registers directly to the
> parallel port.
>
> One chain of shift registers on each data pin.
>
> Use the other parallel port pins to clock in the data and strobe the shift
> regs load input.
>
> Done!
>
> Bob Ammerman

Hmmm, maybe. Might be too much PC software overhead, but I'll
think about that one some more though. Thanks.

You said TPIC6B595 and I said TPIC6A595 - does that mean you
have some experience with these things or was it just a typo?

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spambrent.brown.....spamspamclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@161130 by Brent Brown

picon face
> My personal bias would be to put as much of the time-critical operation as
> possible into the PIC, and let the PC mostly do slow and operator-interface
> stuff.
>
> I would go for higher-level commands going between the PC and the PIC.
> Stuff like "turn on #43 for 27 mS".

Me too. I'm most concerned about getting the data out of the PC
with minimum effort and in a reasonably elegant kind of way. The
PIC side will be a bit of a challenge, but I'm still happier to be
programming on the PIC side!

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  brent.brownspam_OUTspam@spam@clear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@161322 by Brent Brown

picon face
Hi,

So many replies while I was asleep!...[warning]: long post follows,
read at your own risk!

OK, I'm not doing the whole project, but a few more details:-

- It's for a commercial product not a one off. The prototype WILL be
the released version!

- Cost is not too critical, balance with low component count, ease
of assembly, reliability etc. Eg. the TPIC6A595 is more expensive
than some options but is supposed to have short circuit protection.
One less failure in the field, for any reason, is a huge saving.

- Running Windows 95 on a Pentium III big something. Large
application that is very CPU and I/O intensive (not my
programming, thank goodness). Runs a huge number of analog
inputs. Uses one or two huge analog multiplexing boards that I laid
out (hooray!). Samples at 333kHz, I think anywhere from 150-
550'ish analog inputs. Pretty sure this keeps the PC busy.

- The main output of all this is up to 186 air valves. High speed is
the issue, my client wants something better than 250us latency
when switching on any single valve. Because of this speed
requirement the program will access the valves one at a time rather
than "send all 24 bytes" approach. I think this almost rules out
RS232 also. Two bytes at 115.2kbaud is around 175us, getting
close.

- Not sure exactly of the number of outputs that need to be
changed per second. I'm using 1000 per second as a maximum.

- CPU time for the output task should be minimized. Something
like 1 or 2% of total time would be nice.

The first design idea used a 24 bit parallel I/O card connected to a
whole bunch of address decode logic and latches and stuff. Very
cunning design - it could switch any valve in a single 8 bit write to
one of the 3 8 bit ports. I'm told it takes about 1.5us to write to an
ISA card. Only problem with this design is that it is very big - over
50 chips per board (two boards), and requires an I/O card. I think
we can come up with a more elegant solution, here goes!:-

What I am planning at the moment is the following: Up to 4 PIC
boards of 64 valves each (64,128,192 or 256 valves total), all
sharing the same standard parallel port, same lines. Probably hang
them all off a ribbon cable.

PC writes a control byte with 2 address bits to select one of the
four PIC boards, and a command. The PIC board that has the
matching 2 bit address (set by DIP switches?) then pays attention.
The PC then writes one or more address bytes, each of which
contains a 6 bit address which is the address of one of the 64
valves on the selected PIC board to turn on. The PIC sets a
software timer for this valve and turns it on.

A control byte is recognised by bit 6 being 1, and an address byte
is recognised by bit 6 being 0. Either byte is identified as being
sent by bit 7 toggling. (The PC does this in software, inverting bit 7
each time it writes anything out). Bit 7 is decoded by a simple gate
circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
the PC can send either byte in just 1 I/O write (1.5us), and can turn
on any valve on any board with just 2 I/O writes (3us).

The Control byte has a command in it that sets the mode of
operation of the PIC board, eg. an address instruction turns the
valve on, or off, or toggles it, or turns it on for a predefined period of
time, or turns it on for a specified period of time. Additionally the
control byte can set the value of the timer.

Each PIC controls 64 valves using 8 x TPIC6A595 power shift
registers in series. To update the outputs the PIC clocks out 64
bits of data using the MSSP. At 1.25MHz this woud take about
50us plus overheads, lets say <100us anyway. I intend to reserve 1
byte of RAM for each valve, 64 bytes total. When a valve is required
to be turned a timer value is placed into it's shadow RAM location.
This is decremented every millisecond. The main line code scans
through the shadow RAM and makes a 64 bit word that repesents
the on/off state for all the valves and this is the data that is clocked
out. The PIC repeats this as fast as possible, and maybe only
clocks the data out if it has changed since last time.

Not sure if that's clear or not! Still would like to hear from someone
that has used the TPIC IC's or has experience with EPP or ECP.

Thanks, Brent.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  .....brent.brownspamspam.....clear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@171506 by Dwayne Reid

flavicon
face
At 10:11 AM 11/9/00 +1300, Brent Brown wrote:

>You said TPIC6B595 and I said TPIC6A595 - does that mean you
>have some experience with these things or was it just a typo?

I thought that I'd jump in here for a moment - just how much current to you
really need, Brent?  I use a *LOT* of TPIC6B595 chips - the nice thing
about them is that they are pin compatible with the TPIC6595 (note the lack
of the 'B') if you connect pins 1 & 20 to pins 10 & 11 (power GND).  They
are fairly robust - I've never killed an output stage but they are *VERY*
sensitive to over-voltage on the logic supply.

I like them a lot.  I tend to mix them and 74HC595s as needed on my SPI busses.

dwayne



Dwayne Reid   <dwaynerKILLspamspamEraseMEplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 16 years of Engineering Innovation (1984 - 2000)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]:build problem with PIC16F877 - bank2'
2000\11\08@171902 by Andrew E. Kalman

flavicon
face
Re:

>In module COMOMAIN.C:
>bank2 unsigned int  ui_flowsensor_threshold;
>
>In module COMOSE~1.C:
>extern bank2 unsigned int ui_flowsensor_threshold;
>
>My PIC16F877 program is mostly written in C, with a bit of in-line assembly
>tossed in as needed. As can be noted from the above lines, the variable
>unsigned int  ui_flowsensor_threshold is defined as "living" in bank2 where
>there appears to be plenty of room (see RAM Map at end of this email). Yet I
>get the error messages seen below and my build fails. If I simply change the
>variable to "live" in bank1, I get a successful compile. Que Pasa?

Your declarations appear to be correct.

Some other things to look at are whether you've correctly defined any
pointers to ui_flowsensor_threshold, and whether you are passing it
as a parameter and your parameter list is correctly defined,
especially if you're passing it by reference.

In other words, all references to ui_flowsensor_threshold (not just
the two above) that should have a bank2 specifier must have it or
else you'll have this sort of problem.  The reason why it works in
bank1 is that bank1 and the unspecified bank0 are really equivalent
in this case (one covers 0x00-0x7F, the other 0x80-0xFF), and (I
suspect that) somewhere else in your code you're accessing
ui_flowsensor_threshold (unbenknownst to you) as if it were in one of
those banks (probably bank0, as that's the default). Absolutely
everything must be consistent or you'll get this kind of error.
That's why I suggest using typedefs with the bank specifier in them,
instead of an explicit bank specifier for each declaration, etc.

There's an App Note (AN-3) on our web site that covers this issue in-depth.

Regards,

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   EraseMEaek@spam@spam@spam@pumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]: PIC16F877 and 186 solenoids'
2000\11\08@172312 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <@spam@brent.brownspamspamKILLspamCLEAR.NET.NZ>
To: <spamBeGonePICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 4:11 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> > Yep, Roman got me to thinking, this application don't need no stinkin'
PIC
> > ;-)
> >
> > Just tie a bunch of TPIC6B595 serial power shift registers directly to
the
> > parallel port.
> >
> > One chain of shift registers on each data pin.
> >
> > Use the other parallel port pins to clock in the data and strobe the
shift
> > regs load input.
> >
> > Done!
> >
> > Bob Ammerman
>
> Hmmm, maybe. Might be too much PC software overhead, but I'll
> think about that one some more though. Thanks.

There should be no more overhead here than banging the bits out to a PIC.
You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or at
most 200 microseconds.

You would chain 3 '595s off of each data bit.

> You said TPIC6B595 and I said TPIC6A595 - does that mean you
> have some experience with these things or was it just a typo?

Um, no. Just the number I grabbed out of my Digikey catalog. There are
apparently several flavors of this in the world.

{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@172930 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <TakeThisOuTbrent.brownspamCLEAR.NET.NZ>
To: <spamBeGonePICLISTKILLspamspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 4:11 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


{Quote hidden}

What do you mean 250 uS 'latency'. You are going to have perhaps many
milliseconds or more of jitter/latency introduced by Windows.

Is it the on-time that must be strictly controlled?

{Quote hidden}

Watch out: you will be simultaneously changing /WR and data bits on the PSP
port. Check you setup and hold requirements!

{Quote hidden}

Use 8 PIC outputs and feed them into 8 '595s at once (each one does 8
outputs).

Now your output is something like:

   movf        outs_0,w
   movwf     PORTB
   bsf           PORTA,TPIC_CLOCK
   bcf           PORTA,TPIC_CLOCK

repeat the above 8x to output all 64 bits then

   bsf           PORTA,TPIC_LOAD
   bcf           PORTA,TPIC_LOAD


{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]:build problem with PIC16F877 - bank2'
2000\11\08@182600 by Sam Linder

flavicon
face
Thank you for the insight. I accessed your website and downloaded AN-3 and
followed the suggestion. As you knew it would, it worked. I was passing
ui_flowsensor_threshold by reference to a function as follows:

function call:
ConvertASCIITo16BitBinary(&ui_flowsensor_threshold, uc_rxptr+2);

function declaration:
ConvertASCIITo16BitBinary(unsigned int *ui_binaryvalue, unsigned char
*uc_bufferptr);

It never occured to me that the function should be declared as follows:
ConvertASCIITo16BitBinary(bank2 unsigned int *ui_binaryvalue, unsigned char
*uc_bufferptr);

This raises an interesting situation. I was calling the function using two
different integer variables as input. One of them was in bank2, the other in
bank0. It appears that I need to ensure that all integer inputs calling this
particular function must be in the same bank or I'll get another error.
Something I'll have to watch for very carefully in the future with all my
other functions.

Thanks again for the assistance.



{Original Message removed}

'[PIC]: PIC16F877 and 186 solenoids'
2000\11\08@184828 by Brent Brown

picon face
> There should be no more overhead here than banging the bits out to a PIC.
> You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or at
> most 200 microseconds.

Yes, I know 100us doesn't sound much, but repeated 1000 times
per second (worst case) is 10% CPU time, way too much.

Think of a field of 186 valves. Any one could be activated at
random, and it basically has to turn off a fixed time period later. It
makes sense to only send the minimum data required to turn on
that one valve, and then get the PIC to turn it off later.

As for the 250us I referred to as latency. Maybe not the right word.
The most important thing is that the valve turns on at the right time,
second most important, only slightly less important, is that it turns
off at the right time. My client wants no more than a maximum of
250us variation in the delay from instruction issued till event
happening. I don't know (and don't want to know) all the Windows
issues, that's his problem, but I want the hardware to be the
smallest possible factor in it.

Have been talking to my client since recent postings, and we have
decide to try out EPP mode on the parallel port. Sounds like you
can send or receive 8, 16 or 32 bits in one PC instruction, and the
EPP port takes care of all the handshaking. We will knock up a
test board to try it out in 16 bit mode. I have a max of 10us
between bytes before the EPP port times out. That's 50
instructions with a 20MHz clock right? What am I letting myself in
for...

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spambrent.brownspamclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@190722 by Tony Nixon

flavicon
picon face
Brent Brown wrote:

> What am I letting myself in for...

Fun :-)

--
Best regards

Tony

mICro's
http://www.picnpoke.com
salesSTOPspamspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]:build problem with PIC16F877 - bank2'
2000\11\08@191117 by Andrew E. Kalman

flavicon
face
Sam wrote:

>This raises an interesting situation. I was calling the function using two
>different integer variables as input. One of them was in bank2, the other in
>bank0. It appears that I need to ensure that all integer inputs calling this
>particular function must be in the same bank or I'll get another error.
>Something I'll have to watch for very carefully in the future with all my
>other functions.

Yep, you got it. It will be  a runtime error, not a compile-time
error. The function will set the bank bits according to the parameter
declaration, and you'll find it operating on data in the wrong bank.
It's a bit tricky until you do it a couple of times, then it becomes
second nature.

To avoid such problems, I ended up using two typedefs for each type
of variable, with just a single-character postfix to differentiate
the two typedef names.

The first (what I call the qualified typedef) is used for variable
declarations and includes the bank specifier. The other, used
exclusively in parameter declarations, does not, in the sense that
the parameter itself is not banked (i.e. not qualified), although it
may very well point to a banked object. All of which is explained in
AN-3 as you found out.

I'm glad I was able to help ...


--

 ______________________________________
  Andrew E. Kalman, Ph.D.   aekSTOPspamspamKILLspampumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]: PIC16F877 and 186 solenoids'
2000\11\08@214757 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <@spam@brent.brown.....spamspamCLEAR.NET.NZ>
To: <spamPICLIST.....spam.....MITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 6:47 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> > There should be no more overhead here than banging the bits out to a
PIC.
> > You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or
at
{Quote hidden}

I hope it isn't BIG TROUBLE. Make sure your customer understands the
implications of trying to do submillisecond hard real-time on an operating
system where you'd be lucky to manage 50 milliseconds.

Or alternately, make sure that you don't get the blame when the thing
doesn't work very well.

Watch out!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]:build problem with PIC16F877 - bank2'
2000\11\08@214809 by Bob Ammerman

picon face
I'm not a "C" guy on the PIC (tho' I do tons of it on other platforms), and
this got me to thinking.

given, on a '87x

typedef bank0 unsigned short us_0;
typedef bank1 unsigned short us_1;
typedef bank2 unsigned short us_2;

us_0    my_0;
us_1    my_1;
us_2    my_2;

void myfunc(us_0 *arg)
{
   <code>
}

I am guessing that:

   myfunc(&my_0);

will work.

And that:

   myfunc(&my_1);
   myfunc(&my_2);

should get compile time errors.

And that:

   myfunc((us_0 *) &my_1);

should work.

But that:

   myfunc((us_0 *) &my_2);

will break at runtime.


The difference between the cases for &my_1 and &my_2 is that the pointer is
loaded into FSR and the STATUS,IRP is set or cleared appropriately.

Since bank0 and bank1 are both accessed with IRP clear:

   (us_0 *) &my_1

will work.

Did I guess this right?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




'[PIC]: PIC16F877 and 186 solenoids'
2000\11\08@223036 by Olin Lathrop

flavicon
face
> My client wants no more than a maximum of
> 250us variation in the delay from instruction issued till event
> happening.

This is simply not possible with Windows.  I've measured NT 4 on quite a
fast Pentium going out to lunch for well over 100mS on occasion for no
apparent reason.  I could greatly increase the frequency of these NT
lunchtimes by just moving the mouse.  I've seen similar issues with Windows
95/98, but have never tried to carefully measure them.

The bottom line is that Windows is not a real time system.  To be fair to
Microsoft, they have never claimed Windows to be real time.  If you truly
need 250uS response from when a decision is made to open a valve until the
valve is commanded to open, then you need a real time OS.

Just out of curiosity, how fast do these valves respond?  Do they really
fast enough so that 250uS makes a relevant difference?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinspam_OUTspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\09@040620 by Alan B. Pearce

face picon face
>A control byte is recognised by bit 6 being 1, and an address byte
>is recognised by bit 6 being 0. Either byte is identified as being
>sent by bit 7 toggling. (The PC does this in software, inverting bit 7
>each time it writes anything out). Bit 7 is decoded by a simple gate
>circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
>the PC can send either byte in just 1 I/O write (1.5us), and can turn
>on any valve on any board with just 2 I/O writes (3us).


This has the advantage that you could set the port up as a generic text only
printer, and print characters to the port as an initial "get you going" scheme
as you do not worry about the handshake lines on the port. I like it.

Later when you need the speed you can worry about bypassing the underlying code
and access the port direct.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@041721 by Alan B. Pearce

face picon face
>Have been talking to my client since recent postings, and we have
>decide to try out EPP mode on the parallel port. Sounds like you
>can send or receive 8, 16 or 32 bits in one PC instruction, and the
>EPP port takes care of all the handshaking. We will knock up a
>test board to try it out in 16 bit mode. I have a max of 10us
>between bytes before the EPP port times out. That's 50
>instructions with a 20MHz clock right? What am I letting myself in
>for...

Is it worth checking out the parallel port interface on some pics to see if it
will interface to an EPP. The 16F87x family has this port with the handshake
lines as one of its features. Have not looked at it myself, just a thought.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@050957 by Brent Brown

picon face
Thanks everyone for the replies. I'll pass these comments about
Windoze on to my client. He does have an existing product
working though, driving the valves directly from an ISA card. Makes
me wonder how good it actually works. I can see that variations of
several milliseconds would cause imperfect operation of the
machine.

I know that a solenoid valve won't respond in 250us, but I guess the
idea we are working on here is trying to keep all the variables at
least one order of magnitude below that where they start causing
concern. I'll ask a few more questions.

The EPP port looks quite cool now (a bit scary at first), lots of good
web sites around for info. At first look the PSP port doesn't seem
to have the right kind of logic to make it suitable for this use. I
wondered about just an 8 bit port and an interrupt line, but I'm not
sure if handling nested interrupts is feasible on the PIC (eg.
allowing for EPP interrupt to occur during a timer interrupt or MSSP
interrupt). I'll persist with the PSP a bit more.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spam_OUTbrent.brownspamTakeThisOuTclear.net.nz

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@064039 by mike

flavicon
face
On Wed, 8 Nov 2000 21:51:48 -0500, you wrote:

>> My client wants no more than a maximum of
>> 250us variation in the delay from instruction issued till event
>> happening.
>
>This is simply not possible with Windows.  I've measured NT 4 on quite a
>fast Pentium going out to lunch for well over 100mS on occasion for no
>apparent reason.  I could greatly increase the frequency of these NT
>lunchtimes by just moving the mouse.  I've seen similar issues with Windows
>95/98, but have never tried to carefully measure them.
>
>The bottom line is that Windows is not a real time system.  To be fair to
>Microsoft, they have never claimed Windows to be real time.  If you truly
>need 250uS response from when a decision is made to open a valve until the
>valve is commanded to open, then you need a real time OS.
>
>Just out of curiosity, how fast do these valves respond?  Do they really
>fast enough so that 250uS makes a relevant difference?
One other option would be to make the PIC more responsible for timing
- the PIC keeps a 'master clock' and you send it timestamped data in
advance- e.g. 'turn on device x at time t for duration y'. The PC
would then only need to keep 'loose' synchronisation with the PIC, and
as long as you could send data long enough in advance (e.g. a second
or two) momentary time glitches on the PC would not affect overall
system timing accuracy. The only possible problem here is you might
not have enough RAM in the PIC to hold enough queued requests.
To get millisecond-scale timing on the PC you would certainly have to
do much of it under interrupts. If you have more data than the PIC
could store, It may be possible to implement the above event-queueing
type system on the PC as a timer interrupt task and get reasonable
accuracy, or maybe use a hybrid of the two systems - say a 100mS PC
interrupt that sends all the required changes for the next 100mS
period to the PIC, and the PIC then schedules the events within that
100mS window.  Obviously this all hinges on how far in advance the PC knows it will
need to operate the outputs.
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@065320 by Alan B. Pearce

face picon face
The more of see of this thread, the more I get the feeling that the project
should really be done with PLC's, but any further comment along this line will
need to be done as [OT]:

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@074442 by Bob Ammerman

picon face
----- Original Message -----
From: Alan B. Pearce <.....A.B.Pearce.....spamRemoveMERL.AC.UK>
To: <spam_OUTPICLISTTakeThisOuTspamEraseMEMITVMA.MIT.EDU>
Sent: Thursday, November 09, 2000 4:06 AM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> >A control byte is recognised by bit 6 being 1, and an address byte
> >is recognised by bit 6 being 0. Either byte is identified as being
> >sent by bit 7 toggling. (The PC does this in software, inverting bit 7
> >each time it writes anything out). Bit 7 is decoded by a simple gate
> >circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
> >the PC can send either byte in just 1 I/O write (1.5us), and can turn
> >on any valve on any board with just 2 I/O writes (3us).
>
>
> This has the advantage that you could set the port up as a generic text
only
> printer, and print characters to the port as an initial "get you going"
scheme
> as you do not worry about the handshake lines on the port. I like it.

This will not work unless his device returns 'acks' to the PC.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

>
> Later when you need the speed you can worry about bypassing the underlying
code
> and access the port direct.
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>
>
>
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@081842 by Alan B. Pearce

face picon face
>This will not work unless his device returns 'acks' to the PC.

Probably not hard to do from my memory of looking at the described waveforms
from many cheap printers. some form of one shot signal derived from the strobe
line would probably do it, and it could probably be done with a CMOS dual one
shot that could raid its power from the port. Hide it all inside the plug.

This would rely on the port being used in basic mode, not EPP or ECP, or any of
the other fancy modes. The handshake signals then may get more stringent.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@084744 by mike

flavicon
face
On Thu, 9 Nov 2000 23:09:45 +1300, you wrote:

>Thanks everyone for the replies. I'll pass these comments about
>Windoze on to my client. He does have an existing product
>working though, driving the valves directly from an ISA card. Makes
>me wonder how good it actually works. I can see that variations of
>several milliseconds would cause imperfect operation of the
>machine.
>
>I know that a solenoid valve won't respond in 250us, but I guess the
>idea we are working on here is trying to keep all the variables at
>least one order of magnitude below that where they start causing
>concern. I'll ask a few more questions.
>
>The EPP port looks quite cool now (a bit scary at first), lots of good
>web sites around for info. At first look the PSP port doesn't seem
>to have the right kind of logic to make it suitable for this use. I
>wondered about just an 8 bit port and an interrupt line, but I'm not
>sure if handling nested interrupts is feasible on the PIC (eg.
>allowing for EPP interrupt to occur during a timer interrupt or MSSP
>interrupt). I'll persist with the PSP a bit more.
You can't do nested ints, but you don't really need to. It seems you
basically have 2 tasks - pc comms and timed operation of the
solenoids. Only one of these tasks (the most time-critical) needs to
run on ints - probably the PC comms. The timer stuff can run polled in
the foreground - the few microseconds' jitter caused by doing this
should not be an issue in this appliction.
If you can make your interface look like a printer to the PC this will
certainly simplify things - this can be easily done on the PIC with an
interrupt line from /strobe. I believe one feature of the various
enhanced parallel ports on PCs is a transmit FIFO - if you pretend to
be a printer you can make use of this functionality to ease the timing
burden on the PC. It would also allow more hardware flexibility, and
be likely to work on different PCs.  
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




'[PIC]:build problem with PIC16F877 - bank2'
2000\11\09@114859 by Sam Linder

flavicon
face
Pretty good guess. Only Hi-Tech C causes link-time errors instead of
run-time errors with     myfunc((us_0 *) &my_2);


{Original Message removed}

'[PIC]: PIC16F877 and 186 solenoids'
2000\11\09@115102 by jamesnewton

face picon face
Please let me know if you learn anything about ECP or EPP operation of the
PC Parallel port. I'm keenly interested in this and have not been able to
get anything to work correctly under MS Windows.... in DOS, simple tests
seem to work, but not under Windows. I have a page of info at
http://www.piclist.com/../io/parallel/port.htm
which describes all the signals and how they are used in various modes with
links to documents about the modes themselves. Please don't hesitate to fill
out the little form so you can post questions, ideas or comments directly to
these pages.

To my knowledge, there is no open source documentation of this
functionality. You would be opening new ground if you release what you
discover.

---
James Newton (PICList Admin #3)
EraseMEjamesnewtonspamBeGonespamKILLspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\11\09@200545 by Harold M Hallikainen

picon face
On Thu, 9 Nov 2000 08:49:23 -0800 James Newton <RemoveMEjamesnewtonspamBeGonespamspamPICLIST.COM>
writes:
> Please let me know if you learn anything about ECP or EPP operation
> of the
> PC Parallel port. I'm keenly interested in this and have not been
> able to
> get anything to work correctly under MS Windows.... in DOS, simple
> tests
> seem to work, but not under Windows. I have a page of info at
> http://www.piclist.com/../io/parallel/port.htm
> which describes all the signals and how they are used in various
> modes with
> links to documents about the modes themselves.


       This page is very nice! I did a product
(http://www.dovesystems.com/starport.htm) that uses the parallel port
running under DOS. The application is written in C and twiddles the bits
of the parallel port directly. The StarPort originally used the 16c74 but
was recently changed to the 18c452 when I needed more RAM (the Dallas
DS1380 RamPort I had been using wes discontinued). The product page has a
link to a page that describes the parallel port interface. I used a
modification of the standard parallel port write, using a 1 wire
handshake (the pin changes state to acknowledge reception of the last
byte). The PIC picks up the 8 bit data using PSP mode. Data from the
StarPort back to the host uses nibble mode.
       I'm thinking of changing the interface to have it look more like a
generic printer (do they exist anymore???  My Windoze 98 doesn't have
anything for a plain text printer). Instead of having to write drivers,
it seems as though there should be a default driver where we can just
send data to it and pick data up from it (using nibble, ECP, EPP, or
whatever).

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\10@103947 by jamesnewton

face picon face
Having a generic driver that would allow one to send ECP or EPP data to a
hardware device from Windows AND pick up a result via any of the reverse
modes would be a great thing for PICListers and other device makers. But...
I haven't seen one. Let me know if you do run over one...

---
James Newton @spam@jamesnewtonspamspamgeocities.com 1-619-652-0593


{Original Message removed}

2000\11\10@183341 by Brent Brown

picon face
As there were so many comments about the speed of Windoze 95
for this job, I asked my client about it (he has written the PC
application).

He says he has watched his program execution time carefully, and
has not observed any major problems. The scan time of the
program is 0.6ms and he logs any exceptions to this. I don't know
how extensive this testing has been, but for example after 1 hour of
operation there were no exceptions reported.

The PC has no mouse and no keyboard, and no other applications
running, factors which no doubt reduce the number of reasons why
Windows might decide to wander off for a while.

Timing in this project is important, but not critical, in that several
crazy solenoid operations in every 500 or 1000 or so operations
wont do any harm and their effect would be insignificant in the
overall process.

I got the go-ahead to design the PIC based solution for the solenoid
driver board yesterday. Hopefully I'll be able to report in the next
week or two about our attempts at interfacing the PIC to an EPP
port.

We intend to use both address and data writes to the peripheral
(PIC board). Each PIC board will have a two bit address selectable
by hardware links, so we can have up to 4 identical boards on the
one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
driver outputs. Now that there can be up to 288 solenoids I'll have to change
the subject line for this thread!

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  TakeThisOuTbrent.brownKILLspamspam@spam@clear.net.nz

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\11@070809 by mike

flavicon
face
>We intend to use both address and data writes to the peripheral
>(PIC board). Each PIC board will have a two bit address selectable
>by hardware links, so we can have up to 4 identical boards on the
>one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
>driver outputs. Now that there can be up to 288 solenoids I'll have to change
>the subject line for this thread!
With that number of outputs, you might want to include some fault
detection - e.g. simple current sensing on the driver commons. I
wouldn't like to try manually finding one bad connection or dead coil
out of 288!

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservRemoveMEspammitvma.mit.edu?bodyT%20PICList%20DIGEST




'[OT]: Re: [PIC]: PIC16F877 and 186 solenoids'
2000\11\11@074124 by Alan B. Pearce

face picon face
>Now that there can be up to 288 solenoids I'll have to change
>the subject line for this thread!

Hmm, you have gone beyond 286, but not yet made 386. Still the next iteration
might skip that and become 486...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use KILLspamlistservspamTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\11@232951 by Brent Brown

picon face
> >Now that there can be up to 288 solenoids I'll have to change
> >the subject line for this thread!
>
> Hmm, you have gone beyond 286, but not yet made 386. Still the next iteration
> might skip that and become 486...

True, but the valves are wired in groups of 9 and the power drivers
have 8 outputs per chip, so 360, 432, 504 & 576 are the next
logical steps. Intel really made life difficult by not thinking out their
chip numbers properly - I mean, Pentium - how on earth are you
supposed to figure out how many valves that can drive?...

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  TakeThisOuTbrent.brownspamspam_OUTclear.net.nz

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservspamspamSTOPspammitvma.mit.edu?body=SET%20PICList%20DIGEST




'[PIC]: PIC16F877 and 186 solenoids'
2000\11\12@023719 by Brent Brown

picon face
> >We intend to use both address and data writes to the peripheral
> >(PIC board). Each PIC board will have a two bit address selectable
> >by hardware links, so we can have up to 4 identical boards on the
> >one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
> >driver outputs. Now that there can be up to 288 solenoids I'll have to change
> >the subject line for this thread!
> With that number of outputs, you might want to include some fault
> detection - e.g. simple current sensing on the driver commons. I
> wouldn't like to try manually finding one bad connection or dead coil
> out of 288!

Me neither! The idea at the moment is to have a self test button
that makes the PIC step through all 72 valves in sequence, one at
a time. All 72 open drain power driver outputs are connected to 1
ADC input through an array of 72 diodes + 1 pull up resistor. I'm
taking advantage of the fact that the output drivers have 1 ohm on
resistance and I'm using them like current shunts. Nicer if I could
monitor current & voltage for each output individually, but hey, this
is the simplest/tidiest method I could think of... and I'm the one
that has to do the board layout!

I did think about measuring the ground current at a common point,
but these TPIC6A595's have logic and power circuit in one chip,
and I didn't want to introduce any voltage difference between logic
and power grounds. According to the application notes they are
already sensitive enough to things like poor layout.

The 72 valves are arranged in 4 banks of 18, so I use another ADC
input to monitor the circuit breaker (or polyfuse) protected +24V
feed to each bank. That way I can tell if the breaker has operated.

If any valve fails and starts to draw more or less current than
normal it should be picked up by this self test. The self test will
probably run only at power up, but the PC will have full control over
this, and can read each test result. In operation I'll just measure
the +24V to each bank occasionally to see if there are any faults
present, then if necessary do a full self test to locate the fault.

A reverse connected valve is a likely fault, during assembly, and
when this happens the built in inverse parallel diodes will conduct.

I am making the assumption (and hoping) that the TPIC6A595
drivers, which are claimed to be short circuit protected, will not be
a common cause or victim of a fault.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  .....brent.brownEraseMEspamclear.net.nz

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu




'[OT]: Re: [PIC]: PIC16F877 and 186 solenoids'
2000\11\13@061104 by ArthurBrown

flavicon
face
Why not go the ole hog and get a PIII or go for a AMD ATHLON 1Ghz
How come the subject changed from PIC16F877 to 286 the all the INTEL chips
I'm going out for a beer.

Regards Art.

{Original Message removed}


'[PIC]: PIC16F877 anyone??'
2000\12\07@095220 by Henry Low
flavicon
face
Good Day to one and all,
   I am currentlu using PIC16F877 for controlling a simple obstacle
avoidance autonomous robot. Anybody has done anything similar before and is
willing to share his/her experience with me?? You may email directly to me
so that others will not get frustrated over our discussion. But of course,
open discussion is beneficial to all and that's what this discussion list is
all about.

Cheers,
Henry

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestEraseMEspammitvma.mit.edu


'[OT]: Robotics with PIC16F877 anyone??'
2000\12\07@112351 by Dan Michaels

flavicon
face
Henry Low wrote:
>Good Day to one and all,
>    I am currentlu using PIC16F877 for controlling a simple obstacle
>avoidance autonomous robot. Anybody has done anything similar before and is
>willing to share his/her experience with me?? You may email directly to me
>so that others will not get frustrated over our discussion. But of course,
>open discussion is beneficial to all and that's what this discussion list is
>all about.
>

Hello Henry,

Robotics is not too alien a topic for piclist. In november, there
was a lot of discussion of this in the thread called "How to control
a motor" -[threads don't always stay on the "original" issue].

Plus there are a few of us who have at least a passing interest in
robotics, and a strong interest in autonomous vehicles - me, for one.
I am currently designing a botboard SBC based around a PIC40 - 74/77/..

You should, however, change the topic to [OT]: to keep the hardcore
[PIC]:+purists happy.

How "autonomous" is your robot? Finding the '877 adequate to the
task?

best regards,
- Dan Michaels
Oricom Technologies
http://www.oricomtech.com
=========================

--
http://www.piclist.com hint: To leave the PICList
spampiclist-unsubscribe-requestspam_OUTspam@spam@mitvma.mit.edu


2000\12\07@124152 by Henry Low

flavicon
face
> Hello Henry,
>
> Robotics is not too alien a topic for piclist. In november, there
> was a lot of discussion of this in the thread called "How to control
> a motor" -[threads don't always stay on the "original" issue].
>
> Plus there are a few of us who have at least a passing interest in
> robotics, and a strong interest in autonomous vehicles - me, for one.
> I am currently designing a botboard SBC based around a PIC40 - 74/77/..
>
> You should, however, change the topic to [OT]: to keep the hardcore
> [PIC]:+purists happy.
>
> How "autonomous" is your robot? Finding the '877 adequate to the
> task?

hi Michaels,
   I have been surfing the net for similar robotic applications using the
PIC16F877 but I just could not find any useful materials. My robot is really
simple, its sole objective is obstacle avoidance and being able to move
around the room without getting stuck. After I have achieved that, I might
add on a mapping feature to it or a "seeking warmest object task".
Anyway, why did u ask "Finding the '877 adequate to the task?", isn't 877
quite sufficient for my application?? It has got PWM output, and sufficient
I/O lines for me i think. Actually, I am a real newbie in programming this
chip, in fact this is my first time working with microcontroller. I wonder
if source code of other PIC chips are useable for 877?? I hope to get some
relevant source code of similar nature (like motor control, sensor
interface) for reference so that I may pick up the fun faster.
   Hope to hear from you soon.

Regards,
Henry

--
http://www.piclist.com hint: To leave the PICList
spampiclist-unsubscribe-request@spam@spamSTOPspammitvma.mit.edu


2000\12\07@125553 by jamesnewton

face picon face
If you are new to microcontrollers, I would recommend
http://www.piclist.com/piclist/begin

---
James Newton (PICList Admin #3)
spamBeGonejamesnewtonspamBeGonespam@spam@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\12\07@130211 by rchock, Steve

flavicon
face
Henry,

I am doing a project that is exactly like yours. I am using a PIC16F873
running at 4MHz. I am using 2 dual H-BRIDGE ckts to drive my motors. I am
using two DC motors for movement. My vehicle uses a set of tank tracks.
Using
this set-up I am able to move FWD, RVS, CCW (slow), CCW (fast), CW (slow)
and
CW (fast). I am using 4 optic reflective sensors to tell the MCU that there
is something by the robot (not quite perfected yet, some materials don't
reflect
very well!!). The optic sensors are interfaced to the PIC using
a quad comparator (LM339). It has 7 LEDs (3 green, 4 red) to display
different
patterns, depending on it's "behavior". I just started writing the code,
this
will be the "fun" part. It is going to be a XMAS present for my son, working

like crazy to get it done in time. Talk about a DEADLINE ................

Once everything is finished I will put all the info on my webpage. Until
then,
I hope this helps!!

Best regards,
Steven


Steven Kosmerchock
Radio Frequency Systems
Phoenix,  Arizona  USA
(WORK) http://www.rfsamericas.com

http://www.geocities.com/researchtriangle/lab/6584

"Great spirits have always encountered violent
oppposition from mediocre minds."--A.Einstein

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestRemoveMEspamRemoveMEmitvma.mit.edu


2000\12\07@142451 by Dan Michaels

flavicon
face
Henry Low wrote:
.......
>hi Michaels,
>    I have been surfing the net for similar robotic applications using the
>PIC16F877 but I just could not find any useful materials.


Yes, I have searched the web a lot voer the past several weeks myself,
and found that the vast majority of available boards use the 68HC11
processor, no doubt stemming from those originally developed at MIT
- course 6.270. There appear to be few PIC-based boards available
- so being a PIC enthusiast, I decided to produce my own :).

Being a "premier" hacker, I have put up a lot of links dealing
especially with robo-hacking on my site, including links to 68HC11
controller boards/etc:

http://www.oricomtech.com/emerge5.htm#Hobby2
================

My robot is really
>simple, its sole objective is obstacle avoidance and being able to move
>around the room without getting stuck. After I have achieved that, I might
>add on a mapping feature to it or a "seeking warmest object task".
>Anyway, why did u ask "Finding the '877 adequate to the task?", isn't 877
>quite sufficient for my application?? It has got PWM output, and sufficient
>I/O lines for me i think.


I just asking since I wasn't too sure how far along the project you were
[and also fishing for some MotHC11 user to comment]. And yes, I think
the '877 chips have plenty of capability for this type of project.
================

Actually, I am a real newbie in programming this
>chip, in fact this is my first time working with microcontroller. I wonder
>if source code of other PIC chips are useable for 877?? I hope to get some
>relevant source code of similar nature (like motor control, sensor
>interface) for reference so that I may pick up the fun faster.
>    Hope to hear from you soon.
>

Yes, all of the 2nd generation-PIC source is pretty much interchangeable
between processors - although you do have to take into account the
different pinouts and memory mapping as the chip resources grow.

I haven't written any source for this project yet, but am currently
working on design of a pcb that will include motor control, IR and
ultrasonic sensors, general digital I/O, 40-pin PIC, etc. It will
be a small board with L293D chips for direct control of a couple
of small motors.

best regards,
- Dan Michaels
==============

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu


2000\12\07@155915 by Robert C. Gates

flavicon
face
I would like to find out what you are using for drive train and track.  I
have been looking for a suitable platform but have been cursed with wanting
to do it as small as possible.  Any input would be appreciated.

Thanks,

Rob

{Original Message removed}

2000\12\07@165656 by rchock, Steve

flavicon
face
Rob:

I am using 2 "Tracked Vehicle Chasis" from TAMIYA (http://www.tamiya.com/).
as the mobile platform. I found a better hackable one at http://www.robotstore.com

3-354 - Bulldozer Kit - $37.95

Or you can buy just the motor:

3-709 - Twin Motor Gear Box Kit - $19.95

The tread on the kit I am using can be made small or large (connect
together).
This way I could make the kit very small, depending on what I want. I hope
this helps.

Best regards,
Steve

Steven Kosmerchock
Radio Frequency Systems
Phoenix,  Arizona  USA
(WORK) http://www.rfsamericas.com

http://www.geocities.com/researchtriangle/lab/6584

"Great spirits have always encountered violent
oppposition from mediocre minds."--A.Einstein

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-request@spam@spammitvma.mit.edu


2000\12\07@173025 by Dan Michaels

flavicon
face
Robert Gates wrote:
>I would like to find out what you are using for drive train and track.  I
>have been looking for a suitable platform but have been cursed with wanting
>to do it as small as possible.  Any input would be appreciated.
>

Rob, to answer your question for Steve [as if it were intended for
me - he, he], I am planning to use the Tamiya dual-motor geartrain,
about $15. I believe it is the same as used in some of the hobby
tanks for sale - possibly Radio Shack's:

http://www.sinerobotics.com/twinmotor.html

The Tamiya site has a list of states with local dealers. Several
carry this motor in my area:

http://www.tamiya.com/america/ta.htm

- danM

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspam_OUTspammitvma.mit.edu


2000\12\07@220734 by Dan Michaels

flavicon
face
Steven Kosmerchock wrote:
>Rob:
>
>I am using 2 "Tracked Vehicle Chasis" from TAMIYA (http://www.tamiya.com/).
>as the mobile platform. I found a better hackable one at http://www.robotstore.com
>
>3-354 - Bulldozer Kit - $37.95
>
>Or you can buy just the motor:
>
>3-709 - Twin Motor Gear Box Kit - $19.95
>

Hi Steve, as you are using the exact motor system I have been
planning to buy, and as they never seem to publish the info I
want, can you tell me about how much current the motors draw in
various loading situations?

I want to use the L293D H-bridge chips, which are rated for 600mA
tops [ie, with good heat sinking]. Did you need to use an H-bridge
rated greater than this?

thanks,
- dan michaels
==============

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu


2000\12\07@234718 by Tom Handley

picon face
  Steve, Dan and I are also building PIC-based robots and have looked at
the TAMIYA gearbox. My main concerns with using it is the torque and the
ability to hack a tach onto each motor. Right now I'm hacking a Radio SHack
R/C car and replaced the motor with decent results but it's just a test-bed
until I build a decent platform with dual motors. I've tested both optical
and Hall-Effect sensors for the tach with the latter using a fraction of the
current of optical versions. I used 1/8" rare-earth magnets from Radio
Shack. The problem is that it requires more space than an optical wheel.
Anyway, can you give us a rough idea how powerful that gearbox/motor set is
in it's lowest gear ratio? I'm looking at a platform at least 8" long and
6-8" wide. I'm also favoring sealed lead-acid batteries over nicads so there
will be some weight there.

  As far as IR sensors, I lost the link but there's a simple design using a
PIC12C508, two IR LEDs pointing front-left and right, and a typical Sharp IR
receiver. You can adjust the sensitivity via software by changing the
modulation frequency. The code is trivial and can be used with any PIC.
Also, look into simple bumper switches which will tell you when you actually
hit something. There are dozens of ways to make them. Check the following
links which should point the way to the IR receiver:

     Portland Area Robotics Society
     http://www.rdrop.com/~marvin/

     Seattle Area Robotics Society
     http://www.seattlerobotics.org/

     Robotics Magazine
     http://www.robotmag.com/default.htm

  - Tom

At 04:54 PM 12/7/00 -0500, Steve Kosmerchock wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamRemoveMEmitvma.mit.edu


2000\12\08@003303 by Roman Black

flavicon
face
Dan Michaels wrote:
{Quote hidden}

Dan, there are two very cheap, common and good motor driver
chips, the BA6209 and BA6219. These are the same size as
L293 and are good for 1.2A and 2.0A respectively. We use them
all the time in VCRs. They have direction/speed control with
two input pins. Speed control is analogue. They are about
$1.50 to $2 US if you shop around.

I have full datasheets if you are interested, or you can get
datasheets at
http://www.rohm.com/products/databook/motor/pdf/

These are a great cheap little chip.
:o)
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\08@010037 by Dan Michaels

flavicon
face
Tom Handley wrote:
>   Steve, Dan and I are also building PIC-based robots and have looked at
>the TAMIYA gearbox. My main concerns with using it is the torque and the
>ability to hack a tach onto each motor.


Hello again, Tom,

I was wondering if you were still going this route, or whether the
flame had sputtered. Well, you're building, I'm still dreaming, in
betweenst <-- :) --> all the other projects. I am however designing
my own botboard based upon a PIC74/77, and hope to send away for pcbs
in a week or so. Most available boards use the 68HC11 chips.
Preliminary info:

http://www.oricomtech.com/projects.htm

I have been researching various motor options and plan to use the
Tamiya twin-motor set on my initial effort. Not wanting to do a lot
of mechanical fabs, I plan to build it using a couple of "spare"
AOL CDROMs for the body. I figure 9 drilled holes will do the whole
thing.

Once I know a little more about motor current reqs, I can design
the motor drive on my SBC. Hopefully the L293D chip @ 600 mA will
handle the small motors for a small bot - but probably not for a
larger one.
====================

.............>
>   As far as IR sensors, I lost the link but there's a simple design using a
>PIC12C508, two IR LEDs pointing front-left and right, and a typical Sharp IR
>receiver. You can adjust the sensitivity via software by changing the
>modulation frequency.


I put up a lot of robo-hack links on my page, with special emphasis
to sites with motor control and IR sensor stuff. There are also some
ultrasonic sensor systems and cool bat detectors. K.Leang has some
good all-around info.

http://www.oricomtech.com/emerge5.htm#Hobby2
http://www.leang.com/robotics/info/roboinfo.html

best regards,
- Dan Michaels
Oricom Technologies
===================

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\08@050458 by Simon Nield

flavicon
face
tom:
>and Hall-Effect sensors for the tach with the latter using a fraction of the
>current of optical versions. I used 1/8" rare-earth magnets from Radio
>Shack. The problem is that it requires more space than an optical wheel.


just curious about this tom, but how have you assembled your magnetic sensor ?
i always assumed that the way this would be done would be to have a hall sensor pointing at the edge
of a metal gear, with a small permanent magnet the other side of the sensor from the gear... is this
how it works or do you have the magnet fixed to the rotating parts, a little like a digital odometer
for a bicycle ?

regards,
Simon

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\08@124456 by Dan Michaels

flavicon
face
Roman Black wrote:

>Dan, there are two very cheap, common and good motor driver
>chips, the BA6209 and BA6219. These are the same size as
>L293 and are good for 1.2A and 2.0A respectively. We use them
>all the time in VCRs. They have direction/speed control with
>two input pins. Speed control is analogue. They are about
>$1.50 to $2 US if you shop around.
>
>I have full datasheets if you are interested, or you can get
>datasheets at
>http://www.rohm.com/products/databook/motor/pdf/
>
>These are a great cheap little chip.


Thanks Roman, I'll check these chips out. Probably need
a big heat sink and external clamping diodes, I would imagine.

How much trouble have you seen with motor noise getting back
through this kind of chip to the uC pins? I imagine the problem
is worse at the higher currents. Are you using any specific
filters to deal with this? I was thinking it might be good idea
to put RC filters between PIC and the L293 control pins to be safe.

- danM

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\08@230513 by Roman Black

flavicon
face
Dan Michaels wrote:
{Quote hidden}

Dan, I haven't used these in a project but I work with them
all the time in VCRs. They usually drive a small motor about
200mA with no heatsinking (just the built in tag on the chip)
and they don't get that warm. I have seen them used to drive
much larger motors in older VCRs with a small heatsink. As
they are a flatpack heatsinking is easy, you can even bolt
them to the case.

The datasheet recommends that they be used with a series
resistor to the power rail and a large filter cap close to
the power pin of the chip. I think this would kill a lot
of the noise. It is always a good idea to put a cap across
the dc motor pins on the motor and a snubber at the chip
across the motor connections. I wouldn't expect these chips
to make the RF that a L293 makes. By the way, the L298 is
a 2A version of the L293 (1A).

-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\09@080457 by Duane Brantley

flavicon
face
Does anyone make a bridge that will handle, say, in the order of 15 - 20
amps peak (stall)?  I haven't done a full load test on the gear head motors
that I'm going to use, but I know they can easily pull 12 Amps.

Happy Holidays,

Duane

{Original Message removed}

2000\12\09@125225 by Dan Michaels

flavicon
face
Duane Brantley wrote:
>Does anyone make a bridge that will handle, say, in the order of 15 - 20
>amps peak (stall)?  I haven't done a full load test on the gear head motors
>that I'm going to use, but I know they can easily pull 12 Amps.
>

I have a feeling that Duane Brantley makes this type of
a circuit.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\09@132701 by Dan Michaels

flavicon
face
Tom Handley wrote:
>   Steve, Dan and I are also building PIC-based robots and have looked at
>the TAMIYA gearbox. My main concerns with using it is the torque and the
>ability to hack a tach onto each motor. Right now I'm hacking a Radio SHack
>R/C car and replaced the motor with decent results but it's just a test-bed
>until I build a decent platform with dual motors.
................


Hi Tom,

Got some follow-up info --> good stuff available NO-wheres else that
I could ever find. Went down and got the Tamiya twin-motor gear-train
[$11.50 at one of the local hobby shops]. They use the "130" motors,
apparently identical to the bantam weight FA130RA2270 shown in the
Jameco catalog. Spec'ed at 1.5-3v, 200mA, 9100RPM, $0.99.

Set it up for the slower 203:1 gearing, uses 4 gearsets with about
4:1 reduction each. It is actually quite torque-y, and hard to stall
by squeezing the output shaft. You cannot move the motor shaft by
trying to hand-turn the final "gear".

Runs well at ~2.0v on the motor, drawing ~500mA @ 48RPM output
--> motor doing about 9700RPM. 3v on the motor is a little much,
drawing ~1000mA.

All in all, looks pretty good for my first project, using "free" AOL
CDROMs for the body, and running off a couple of L293D H-bridges
and 3-4 AA's. Got enough info now to go ahead and design my new SBC.

Ever get your car to run "slow" enough?

best regards,
- Dan Michaels
Oricom Technologies
http://www.oricomtech.com
=========================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\09@161623 by Duane Brantley

flavicon
face
I'm beginning to think he does to....

-----Original Message-----
From: Dan Michaels [spam_OUToricomRemoveMEspam.....USWEST.NET]
Sent: Saturday, December 09, 2000 11:52 AM
To: spamPICLISTKILLspamspamKILLspamMITVMA.MIT.EDU
Subject: Re: [OT]: Robotics with PIC16F877 anyone??


Duane Brantley wrote:
>Does anyone make a bridge that will handle, say, in the order of 15 - 20
>amps peak (stall)?  I haven't done a full load test on the gear head motors
>that I'm going to use, but I know they can easily pull 12 Amps.
>

I have a feeling that Duane Brantley makes this type of
a circuit.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\10@010702 by dre Domingos F. Souza

flavicon
face
>Got some follow-up info --> good stuff available NO-wheres else that
>I could ever find. Went down and got the Tamiya twin-motor gear-train
>[$11.50 at one of the local hobby shops]. They use the "130" motors,
>apparently identical to the bantam weight FA130RA2270 shown in the
>Jameco catalog. Spec'ed at 1.5-3v, 200mA, 9100RPM, $0.99.

       Where can I find it? No local hobby shops uses to sell tamya merchandise!


--------------8<-------Corte aqui-------8<--------------

       All the best!!!
       Alexandre Souza
       spamxandinhospam_OUTspaminterlink.com.br
       Linux User #85093

--------------8<-------Corte aqui-------8<--------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@052910 by Roman Black

flavicon
face
Dan Michaels wrote:
{Quote hidden}

Hi Dan, use some light machine oil on the bronze motor bearings,
will extend motor life a lot. Also see if you can get some
"super-grease" for the multiple gear gearbox, it will make it
quieter and reduce wear. This super sticky grease will even
help a bit with backlash. If you can enclose around the gears
with anything this is even better, just fill it with a couple
cc's of grease. You can get good long term results from these toy
motors with some professional lubing.
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@140624 by Dan Michaels

flavicon
face
Roman Black wrote:
>
>Hi Dan, use some light machine oil on the bronze motor bearings,
>will extend motor life a lot. Also see if you can get some
>"super-grease" for the multiple gear gearbox, it will make it
>quieter and reduce wear. This super sticky grease will even
>help a bit with backlash. If you can enclose around the gears
>with anything this is even better, just fill it with a couple
>cc's of grease. You can get good long term results from these toy
>motors with some professional lubing.
>-Roman
>

Tamiya includes some grease with the geartrain. Haven't used
it yet. Don't know how super it is. So far tried w/o same, and
very noisy. The way the cage is built, it would be quite easy
to enclose. All in all, the Tamiya dual-motor is a nice system
for the price.

best regards,
- Dan Michaels
===============

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@140633 by Dan Michaels

flavicon
face
Roman Black wrote:
>>
..........
>The datasheet recommends that they be used with a series
>resistor to the power rail and a large filter cap close to
>the power pin of the chip. I think this would kill a lot
>of the noise. It is always a good idea to put a cap across
>the dc motor pins on the motor and a snubber at the chip
>across the motor connections. I wouldn't expect these chips
>to make the RF that a L293 makes. By the way, the L298 is
>a 2A version of the L293 (1A).
>


Roman, thanks for the info. I'll breadboard the L293D to Tamiya
motor/geartrain to the PIC this week, and see what kind of
noise I get. And how hot the L293's run.

The L298's would probably be better, but not as convenient
for a small pcb. Seems to me, however, for high power, if you
simply run the 4 outputs of the L293 out separately, rather
than tying them together 2-by-2, you could directly drive an
external H-bridge made up of nothing more than 2 hi-current
PMOSFETs and 2 hi-current NMOSFETs. The L293's can handle
the hi-voltages, and PWMing its outputs should work with the
2nd H-bridge.

At least this is my perception. And maybe a more flexible
route than worrying about putting a high-current H-bridge
on the small pcb from the get-go.

best regards,
- Dan Michaels
==============

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@140635 by Dan Michaels

flavicon
face
Alexandre Souza wrote:
>>Got some follow-up info --> good stuff available NO-wheres else that
>>I could ever find. Went down and got the Tamiya twin-motor gear-train
>>[$11.50 at one of the local hobby shops]. They use the "130" motors,
>>apparently identical to the bantam weight FA130RA2270 shown in the
>>Jameco catalog. Spec'ed at 1.5-3v, 200mA, 9100RPM, $0.99.
>
>        Where can I find it? No local hobby shops uses to sell tamya
merchandise!
>

Check the websites. Tamiya has a list of dealers in the US by state,
maybe for other countries. The 130 motor is Jameco P/N 166676, but
Jameco does NOT sell the twin-motor geartrain.

http://www.tamiya.com
http://www.jameco.com

- danM

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@154046 by Bob Blick

face
flavicon
face
get it at http://www.towerhobbies.com. They also have a neat tracked vehicle
chassis kit. The search function works, but the part numbers are:

Tower#   Tamiya#
LXHA15   70097 TWIN MOTOR GEAR BOX 10.59
LXGZ87   70108 TRCKD VEHICLE CHASSIS KT 15.19

Cheers,

Bob

At 02:06 PM 12/10/2000 -0500, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@155059 by Dan Michaels

flavicon
face
Bob Blick wrote:
>get it at http://www.towerhobbies.com. They also have a neat tracked vehicle
>chassis kit. The search function works, but the part numbers are:
>
>Tower#   Tamiya#
>LXHA15   70097 TWIN MOTOR GEAR BOX 10.59
>LXGZ87   70108 TRCKD VEHICLE CHASSIS KT 15.19
>

There are also 2 other Tamiya tracked chassis -[note - HWVTech shipping
costs to US are prohibitive].

http://www.hvwtech.com/gearsets.htm

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@184128 by Mitchell D. Miller

picon face
Who makes the L293 and 298?  Ie: Where can I find data sheets?

-- Mitch

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@190713 by dre Domingos F. Souza

flavicon
face
>Who makes the L293 and 298?  Ie: Where can I find data sheets?

       ST comes to mind...


--------------8<-------Corte aqui-------8<--------------

       All the best!!!
       Alexandre Souza
       STOPspamxandinhospam_OUTspamspamBeGoneinterlink.com.br
       Linux User #85093

--------------8<-------Corte aqui-------8<--------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\10@210954 by Dan Michaels

flavicon
face
Mitchell D. Miller wrote:
>Who makes the L293 and 298?  Ie: Where can I find data sheets?
>

ST and Unitrode. Also, TI has same pinout - SN754410.

http://www.us.st.com/stonline/products/selector/58.htm

I have some links to boards [Handyboard ....] and ckts using them:

http://www.oricomtech.com/emerge5.htm#Hobby2

Also, Roman gave a link other day to Rohm H-bridge chips.

- dan michaels

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\11@000751 by Tom Handley

picon face
  Simon, in my `hack' I glued two 1/8" rare-earth magnets on opposite sides
of a gear shaft on the motor. Normally, I would mount several around a disk
for this application. I'm using Panasonic DN6852As available from Digi-Key.
These are unidirectional with all the signal conditioning in the sensor. The
output is open-collector. The package is a small 3-lead SIP. It operates
from 3.6 to 16V with a supply current of around 5.5ma.

  - Tom

At 10:02 AM 12/8/00 +0000, Simon Nield wrote:
>tom:
>>and Hall-Effect sensors for the tach with the latter using a fraction of the
>>current of optical versions. I used 1/8" rare-earth magnets from Radio
>>Shack. The problem is that it requires more space than an optical wheel.
>
>
>just curious about this tom, but how have you assembled your magnetic
sensor ?
>i always assumed that the way this would be done would be to have a hall
sensor pointing at the edge
>of a metal gear, with a small permanent magnet the other side of the
sensor from the gear... is this
>how it works or do you have the magnet fixed to the rotating parts, a
little like a digital odometer
>for a bicycle ?
>
>regards,
>Simon


------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@000759 by Tom Handley

picon face
  Dan, well I'm working on it in spare time but I really want to wait for a
dual motor platform instead of spending much more time on this R/C car. I've
got various things bolted onto it for testing. I finally hacked an RC servo
to control the steering but I have not done much code for a crude AI. Right
now the speed control works and if it bumps into something, it backs up,
turns for a second or two, and tries again. There's not much else to do with
a typical car chassis other than using the IR sensor (or Ultrasonic) to
detect objects and try to avoid them. If there is no path inbetween, then
stop and backup again. I'm running the car in reverse to provide front-wheel
drive and rear-wheel steering but two motors with an idler wheel are the way
to go for my application.

  I noticed Roman mentioned the BA6209/6219. When I tore apart an old VCR
looking for motors and gears, I found a BA6209 and could'nt find anything on
the chip. I had forgot about R-Ohm. (Thanks Roman!). I want to take a look
at those chips.

  I'm using multiprocessing with a 16F876 for testing, 12C508 for the IR
detector, 12C671 as a dual RC servo controller (I needed the TMR0
interrupt), and a 16F84 as a dual H-Bridge controller. I plan on another
12C508 for the Ultrasonic detector. They all talk over a serial interface.
The whole idea is to keep it modular with a standard interface so I can
easily add or remove modules (kind of like Leggo's system). The 16F876's
Port B goes to a standard 74x30 8-Input NAND gate used to expand the
interrupts to 7 channels with the output going to RB0/INT. Since I'm
planning on adding other goodies such as a Vector 2X compass, I'll
definitely be using a 16F877. If I can just pin down the platform... I'm
real interested to hear your experiences with that TAMIYA gearbox!

  The CDROM's are a good idea. I save them for coasters ;-) You know, they
might make good wheels if you could find a way to add a rubber O-ring or
something around the edge. Maybe glue 2-3 CDs together. You could easily
drill holes or mount magnets on them to count revoloutions. It would'nt be
practical for a tach but you could sense how far you traveled. I haven't got
that far yet on my hack.

  - Tom

At 01:00 AM 12/8/00 -0500, Dan Michaels wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@002127 by Roman Black

flavicon
face
Dan Michaels wrote:
{Quote hidden}

Cool. Shame Tamiya is so expensive here in Aust. :o(
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@004033 by David Duffy

flavicon
face
>Roman Black wrote:
>Cool. Shame Tamiya is so expensive here in Aust. :o(
>-Roman

I've been following this thread with interest as my son is keen
(OK, me too !) to make something that zips about the room.
I have a pile of used CD spindle motors,etc and a couple of
steppers from 5.25" drives. Is it worth trying to use the stepper
motors as 1:1 direct drive? (wheel on motor shaft) I suspect
that there may not be enough torque to drive it along. I was
thinking of a platform about 150mm (6") x 200mm (8") made
from 2mm (3mm?) sheet aluminium. The biggest problem is
making it carry around the battery pack & all the other bits
that will probably get tacked on as the project progresses.
Jaycar have some motors & a gearbox that I've ordered to
play around with. Looks like a never ending kind of project!
Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@011615 by Roman Black

flavicon
face
David Duffy wrote:
>
> >Roman Black wrote:
> >Cool. Shame Tamiya is so expensive here in Aust. :o(
> >-Roman
>
> I've been following this thread with interest as my son is keen
> (OK, me too !) to make something that zips about the room.
> I have a pile of used CD spindle motors,etc and a couple of
> steppers from 5.25" drives. Is it worth trying to use the stepper
> motors as 1:1 direct drive? (wheel on motor shaft) I suspect
> that there may not be enough torque to drive it along. I was
> thinking of a platform about 150mm (6") x 200mm (8") made
> from 2mm (3mm?) sheet aluminium. The biggest problem is
> making it carry around the battery pack & all the other bits
> that will probably get tacked on as the project progresses.
> Jaycar have some motors & a gearbox that I've ordered to
> play around with. Looks like a never ending kind of project!
> Regards...

David, ask around for an old fax or check local garage sales
and flea markets. You can get old faxes for a couple of bucks
or even free. They usually have two matched motors with small
simple gearboxes attached, about 7:1 is typical. There are
also rubber rollers that you can cut into wheels and tyres.
I have a little desk robot made from two of these motors,
only problem you need about 16v to get decent torque so you
need a few NiCds, my little robot positions in about 0.25mm
steps, and makes the coolest mechanical whine from the
steppers, just like a real robot. I drive the motors with
ULN2003 chips.

If you want to use your own steppers, check dick smith
stores, (also altronics/jaycar) they have small plastic
gear sets and stuff for hobby robot use. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservEraseMEspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@015607 by Roman Black

flavicon
face
Duane Brantley wrote:
>
> Does anyone make a bridge that will handle, say, in the order of 15 - 20
> amps peak (stall)?  I haven't done a full load test on the gear head motors
> that I'm going to use, but I know they can easily pull 12 Amps.
>
> Happy Holidays,
>
> Duane


Hi Duane, do you have a solution for this? I often need
high power drivers and usually design from scratch.

The main problem with high power h-bridge chips is the
barbaric saturation voltages. They try and sell a chip
as a 2amp h-bridge when it has 4v saturation at 1A!!
This disgusts me, I build h-bridges from junk bipolar
transistors I find lying around, with 0.2v sat per device
even that is only 0.4v total saturation. It's disgusting
that a high-tech h-bridge chip has 10 times worse
performance than something I built from junk.

Now if you can tell me about a 2A to 10A h-bridge with
good sat voltage I would be *very* happy!! I have been
looking for something like this for a long time. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservTakeThisOuTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@080016 by rchock, Steve

flavicon
face
Dan:

Looking at the motors, they were drawing about 400mA (MAX) EA continous.
Not sure of the exact amount,... doing this from memory after 3 days off.
My robot is at home, but I can check tonight, and let you know tomorrow.

Steve


Steven Kosmerchock
Radio Frequency Systems
Phoenix,  Arizona  USA
(WORK) http://www.rfsamericas.com

http://www.geocities.com/researchtriangle/lab/6584

"Great spirits have always encountered violent oppposition from mediocre
minds."--A.Einstein

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@080227 by rchock, Steve

flavicon
face
Tom:

I check tonight and let you know how much my robot weighs and
the dimensions. My robot weighs at least a couple of pounds, seems
to go pretty fast. I will let you know tomorrow.

Steve

Steven Kosmerchock
Radio Frequency Systems
Phoenix,  Arizona  USA
(WORK) http://www.rfsamericas.com

http://www.geocities.com/researchtriangle/lab/6584

"Great spirits have always encountered violent oppposition from mediocre
minds."--A.Einstein

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservSTOPspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@081712 by rchock, Steve

flavicon
face
Dan:

Great to hear that it will be working for you.
The price of those TAMIYA kits are well worth what you get.

Steve

--

Hi Tom,

Got some follow-up info --> good stuff available NO-wheres else that
I could ever find. Went down and got the Tamiya twin-motor gear-train
[$11.50 at one of the local hobby shops]. They use the "130" motors,
apparently identical to the bantam weight FA130RA2270 shown in the
Jameco catalog. Spec'ed at 1.5-3v, 200mA, 9100RPM, $0.99.

Set it up for the slower 203:1 gearing, uses 4 gearsets with about
4:1 reduction each. It is actually quite torque-y, and hard to stall
by squeezing the output shaft. You cannot move the motor shaft by
trying to hand-turn the final "gear".

Runs well at ~2.0v on the motor, drawing ~500mA @ 48RPM output
--> motor doing about 9700RPM. 3v on the motor is a little much,
drawing ~1000mA.

All in all, looks pretty good for my first project, using "free" AOL
CDROMs for the body, and running off a couple of L293D H-bridges
and 3-4 AA's. Got enough info now to go ahead and design my new SBC.

Ever get your car to run "slow" enough?

best regards,
- Dan Michaels
Oricom Technologies
http://www.oricomtech.com
=========================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservTakeThisOuTspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@090848 by Henry Low

flavicon
face
hey guys, I tot this was suppose to be a thread abt the PIC16F877?? hahahah
It's ok though, just that I always thought that help is coming until I read
the full mail.....

{Original Message removed}

2000\12\11@100651 by Roman Black

flavicon
face
Sorry Henry, just to answer your question I do think the
F877 is an *excellent* chip to run a small robot. I bought
a few just for that purpose. If you post a specific question
re the robot you are building I'm sure that either I can help,
or the really smart PIC people here can help.

I think many people here are pretty comfortable with making
our PICs do whatever we want so the topics turn to the things
we attach to our PICs, hope that makes sense. :o)
-Roman




Henry Low wrote:
>
> hey guys, I tot this was suppose to be a thread abt the PIC16F877?? hahahah
> It's ok though, just that I always thought that help is coming until I read
> the full mail.....
>
> {Original Message removed}

2000\12\11@101719 by Henry Low

flavicon
face
yeah.....finally....I did post one before...but only a few replied....
anyway, I just want to use a single PIC chip (16F877) to control an
autonomous wheeled robot. So the I/Os here will only be the sensors input
and output control to drive the motor.
Very possibly I will also buy those ready-made expensive wheel encoders for
my speed feedback so I will need to have velocity control of both motors
(one motor for each wheel, my robot is only 2 wheel-drive). I would want to
make sure I know how to use the encoders before I buy them. (I need 2 for
the 2 motors). I know I will need a quadrature decoder but the details I am
not sure....furthermore, I am also not sure how to bring out PWM output from
this PIC and how to adjust the duty cycle. Can I use PWM to vary the
direction of the motor rotation??

Regards,
Henry

{Original Message removed}

2000\12\11@104413 by Roman Black

flavicon
face
Henry Low wrote:
>
> yeah.....finally....I did post one before...but only a few replied....
> anyway, I just want to use a single PIC chip (16F877) to control an
> autonomous wheeled robot. So the I/Os here will only be the sensors input
> and output control to drive the motor.

Hi Henry, I changed the topic to EE as the "EE only" engineers
might want to help too. :o)


> Very possibly I will also buy those ready-made expensive wheel encoders for
> my speed feedback so I will need to have velocity control of both motors
> (one motor for each wheel, my robot is only 2 wheel-drive). I would want to
> make sure I know how to use the encoders before I buy them. (I need 2 for
> the 2 motors). I know I will need a quadrature decoder but the details I am
> not sure....

OK, encoders do not have to be expensive. If you are starting
out with a first PIC robot I would suggest you stay away from
expensive encoders and look at all the other options. This robot
will be a real learning experience and by the time it is trundling
around on your floor there will be a *huge* list of things that you
wished you did differently!

About the first thing I suggest is to start collecting VCRs, FAX
machines and any printers you can get, especially heavy old
dot-matrix printers you can get for under $5 at garage sales.
These are chock full of great motors and sensors and chips, and
many times the robot you build will be from an idea sparked
by the two *perfect* motors you just got out of some old printer.

Re the encoders, sounds like you have decided on DC motors and
optical encoders. This is probably not the best system for a
first robot, there are many complex braking, resonance etc issues
that will make life difficult. What I would suggest is to get
two small 12v stepper motors from a fax machine, or from any
of those "disposal" type places that sell them for a couple of
bucks each. The steppers are perfect for what you need, simple
to drive. You can use a cheap ULN2003 chip to drive each motor,
for small frame steppers these are perfect. You need four wires
only from the PIC to ULN chip, and can make the motor go either
direction at any speed, with absolute position accuracy because
you TOLD it how many steps to turn. Once you are confident with
the PIC and coordinate/speed systems you might want to go to
DC motors/encoders to squeeze more performance.

If you must use DC motors, you can get optical encoders from
just about any modern VCR. It is standard on the new middrive
VCRs to use a interrupt encoder on both spools, so one dead
VCR will get you two matched opto encoders. You can use any
disk with some holes or slots cut in it to go on the shaft
for the encoder to sense. My suggestion is to use the steppers.

> furthermore, I am also not sure how to bring out PWM output from
> this PIC and how to adjust the duty cycle. Can I use PWM to vary the
> direction of the motor rotation??

If you use the steppers you won't need PWM for motor control,
you have four wires for the stepper and activate each in turn (1234)
to give motor rotation. If you activate them backwards (4321) the
motor goes backwards. You will probably run the windings in pairs
(2-on) to give more power.

If you use DC motors you will need PWM. This controls the amount
of voltage to the motor, but motor speed will still depend largely
on the amount of physical load on the motor. You will have to
monitor the motor speed by checking the encoder and then adjust
PWM voltage to try to change motor speed. Then you have overshoot
and braking and stuff to deal with. PWM won't make the motor
run backwards, you will need a relay or h-bridge to connect the
motor the other way around. See why I suggest the steppers?
Many people are afraid of steppers, but for robots they make
a lot of sense and are easy to use.

I have a little desk-bot made from two fax machine steppers and
driven by a PIC brain, I can email you a photo if you like.
It moves with a precise mechanical grace and sounds just like
a little industrial robot. Looks like nuts and bolts but impresses
people when they see it in motion. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@113732 by Dan Michaels

flavicon
face
David Duffy wrote:

Is it worth trying to use the stepper
>motors as 1:1 direct drive? (wheel on motor shaft) I suspect
>that there may not be enough torque to drive it along.

David,

If you are wondering about torque, try firing up the stepper
and seeing how difficult it is to stall it by squeezing the
shaft. As I mentioned last time, with the little Tamiya drive
set for 200:1 reduction, I have to exert quite a bit of force
to slow down the motor. Difficult to stall. And I cannot even
budge the motor by trying to turn the final gear [not the shaft].

A very common robo-hack is to take model airplane servo motors, eg
S-148 and HS300, and convert them for full rotation. Apparently,
they have enuf torque for minibots. However, even the cheapo
servos are expensive, $15 min apiece. I have some links to
servo and stepper motor robohacking:

http://www.oricomtech.com/emerge5.htm#Hobby2

best regards,
- Dan Michaels
Oricom Technologies
===================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv.....spam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@122937 by Dan Larson

flavicon
face
On Sun, 10 Dec 2000 22:13:05 -0200, Alexandre Domingos F. Souza wrote:

>>Who makes the L293 and 298?  Ie: Where can I find data sheets?
>
>        ST comes to mind...
>
>

And Mouser is one place that sells them.  The L293D is $2.00 Qty 1.

Dan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@124201 by Bob Blick

face
flavicon
face
> >>Who makes the L293 and 298?  Ie: Where can I find data sheets?
> >
> >        ST comes to mind...
> >
> And Mouser is one place that sells them.  The L293D is $2.00 Qty 1.

Remember that the L293D consumes 80 milliamps when idling. In a robot that
spends a lot of time not moving, this can kill your batteries in a hurry.

Bridges made by Rohm, and also my design, do not have this problem, draw
nothing when idle:

http://www.bobblick.com/bob/projects/hbridge/index.html

Cheerful regards,

Bob Blick

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistserv.....spammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@131104 by Dan Michaels

flavicon
face
Henry Low wrote:
>hey guys, I tot this was suppose to be a thread abt the PIC16F877??
.............


To inject some PIC back into this thread ..... here is a rough
sketch of my PICoBotboard plans:

- modify my existing PIC40 SBC for use as a botboard. This board can
 use '74/77/etc:

    http://www.oricomtech.com/sbc40.htm

- new layout - remove SRAM and add cktry for motor control, plus
 sound, IR, ultrasonic, and bumper sensors:

         --------+       bank of 8 uncommitted LEDs + series-Rs
                 |
                 |  1 A/D
                 |<---/-- 4-input R-divider [input from bumper sw,
                 |                       output to PIC A/D channel]
                 | 2 DI/O
                 |<---/--> IR LED + QSE156QT optologic detector
           PIC40 |
                 |  2 A/D
                 |<---/--- LM324 [4 opamps - setup as 2-stage hi-gain AC-
                 |            coupled amps for mike and ultrasonic rcvr]
                 | 10 DI/O
                 |---/----> L293D [2 ea - setup as H-bridges]
                 |   2 PWM [motor speed - to enable inputs]
         --------+   8 DI/O [control signal inputs]

- LEDs can be jumpered to provide visual indication of subsystem operation.

- The L293D chips can be setup as 2 H-bridges to drive the Tamiya
 twin-motors. For other apps, the channels can be separated to drive
 up to 8 individual motors.

- Still working out sensor details. For IR object detector, can
 drive IR LED directly off PIC pin at 20-40Khz, and pickup using a
 QSE156QT optologic sensor --> straight to PIC. This sensor could
 also pickup up signals from a TV remote or Palm.

- For long-range ultrasonics, I have a transducer set from Jameco, but
 minimal spec data is available [Jameco doesn't even know the name of
 the maufacturer!!]. However, plan to use BJT inverter to drive xmtr,
 and run rcvr --> 1st LM324 2-stage amp --> integrator --> PIC A/D.

- For sound pickup, electret --> 2nd LM324 2-stage amp --> PIC A/D.

- For bumpers, 4 microswitches --> 4-input R-divider --> PIC A/D.

I figure I can squeeze this all onto my SBC40 form-factor, 2.5"x3.6",
and still have plenty of pins left over for RS-232, an I2C serial
EEPROM chip, up to 5 more A/D channels, and up to 6-8 digital I/O
channels.

so much for now,
- Dan Michaels
Oricom Technologies
===================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@141924 by Dan Michaels

flavicon
face
Bob Blick wrote:
>Remember that the L293D consumes 80 milliamps when idling. In a robot that
>spends a lot of time not moving, this can kill your batteries in a hurry.
>

Good point - this might kill my project too - hadn't gotten to
breadboarding it yet. No wonder those MIT Handyboards with the L293's
have a hi-current battery charger built right in :o).
=============

>Bridges made by Rohm, and also my design, do not have this problem, draw
>nothing when idle:
>
>http://www.bobblick.com/bob/projects/hbridge/index.html

You've got some nice hot [big, not smoky] motors there too.

- danM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@144045 by Dan Michaels

flavicon
face
Bob Blick wrote:
>
>http://www.bobblick.com/bob/projects/hbridge/index.html


Bob, I was looking at your H-bridge and you mention that
separate free-wheeling diodes are not required since the TIP
transistors have diodes internally. Are these really robust enough
to handle the inductive surges?

BTW, it looks like your ckt could almost handle the currents
Duane Brantley is requiring. Can you possibly parallel the
TIP's to get more drive? Tried power MOSFETs?

thanks,
- dan michaels
==============

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@161654 by Bob Blick

face
flavicon
face
> >www.bobblick.com/bob/projects/hbridge/index.html
> > Bob, I was looking at your H-bridge and you mention that
> separate free-wheeling diodes are not required since the TIP
> transistors have diodes internally. Are these really robust enough
> to handle the inductive surges?

Yes, the internal diodes are rated for full current. The circuit is very
inexpensive and relatively simple because of this.

> BTW, it looks like your ckt could almost handle the currents
> Duane Brantley is requiring. Can you possibly parallel the
> TIP's to get more drive? Tried power MOSFETs?

You can use TIP14x instead of TIP12x and have double the ratings. The
drawback is that these are Darlington transistors and produce a bit of
heat.

Someday when I get inspired I'll do a circuit with MOSFETs and also put
current limiting in it, but MOSFETs really add to the complexity unless
you use P-Channel MOSFETs in the upper rail, which I am loathe to do as I
am a cheapskate.

Cheers,

Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv@spam@spam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@192448 by Byron A Jeff

face picon face
>
> Bob Blick wrote:
> >
> >http://www.bobblick.com/bob/projects/hbridge/index.html
>
>
> Bob, I was looking at your H-bridge and you mention that
> separate free-wheeling diodes are not required since the TIP
> transistors have diodes internally. Are these really robust enough
> to handle the inductive surges?
>
> BTW, it looks like your ckt could almost handle the currents
> Duane Brantley is requiring. Can you possibly parallel the
> TIP's to get more drive? Tried power MOSFETs?

Probably easier to just get bigger TIPs. the TIP14X series handles twice
the current of the TIP12X series. You can then go up to 10 amps.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\11@205354 by Henry Low

flavicon
face
Hi Roman,
   You have been helpful, thanks a lot. Actually, I am not dead sure in
using DC motor, I will be testing DC, Stepper and Servo as well and choose
the best and easiest to control for my robot. As for the control part of the
stepper, I would still need some form of feedback rite?? Did you use
encoders for your stepper?? I have frens telling me stepper motor-driven
robots/vehicles are jerky sometimes(because of the steps maybe), I do not
know how true.
You mentioned you have a robot controlled by a PIC brain, what chip is it??
Actually besides the hardware aspect, I have to tackle the software aspect
as this is really my first robot, PIC robot to be specific. Could you share
your code with me so that I may learn from it?? What language did u use?? C
or assembly?? Email me direct if u think some private discussion is
required....

Regards,
Henry

{Original Message removed}

2000\12\11@221805 by Dan Michaels

flavicon
face
Tom Handley wrote:
>   Dan, well I'm working on it in spare time but I really want to wait for a
>dual motor platform instead of spending much more time on this R/C car.

Still interested in that Radio Shack tank? I wonder if it has the
Tamiya twin-motor in it. [you could buy one and tell me].
===============

>   I'm using multiprocessing with a 16F876 for testing, 12C508 for the IR
>detector, 12C671 as a dual RC servo controller (I needed the TMR0
>interrupt), and a 16F84 as a dual H-Bridge controller. I plan on another
>12C508 for the Ultrasonic detector. They all talk over a serial interface.

You connecting all the chips to the same RS-232 channel? How are you
doing this? Ever think of using just a single PIC40 for the whole
thing? But, I guess, servo control would be a problem if you have to
keep feeding signals to it.
===============


>The whole idea is to keep it modular with a standard interface so I can
>easily add or remove modules (kind of like Leggo's system).

I'm thinking along the same lines, but with several stacked PIC40
boards. Lowest one would do most of low-level processing, as I
described earlier in the day. Next one up would have a 32KB SRAM
and be used to store real-time "mapping" data obtained by the
low-level board as the beastie runs around the room. Basically
build up an internal representation of the environment - would
need some kind of external landmarks for this - IR beacons or
something.
=====================

 The 16F876's
>Port B goes to a standard 74x30 8-Input NAND gate used to expand the
>interrupts to 7 channels with the output going to RB0/INT.

Why do you need all these interrupts? I figure my thing wouldn't
be moving very fast, so I can poll the sensor ports. Also, with the
L293 chips controlled by dedicated I/O pins and the 2 PWM channels
used for speed control, it wouldn't require any processor cycles
for real-time control over the motors.

The bot will either run very slowly or else run a few inches, and
stop and take sensor readings. Slow-lane robotics here.
===============

Since I'm
>planning on adding other goodies such as a Vector 2X compass, I'll
>definitely be using a 16F877. If I can just pin down the platform... I'm
>real interested to hear your experiences with that TAMIYA gearbox!
>

Maybe GPS, too?  BTW, the latest/greatest GPS apps I have heard
about are: a) herding cows, and b) finding free spots in parking
lots. a) works by "cow whispering", b) works by having a satellite
photograph the parking lot from space, and downloading a map
to the computer in your Cadillac SUV. A traveling salesman
algorithm routes you to the open space before any other cars
can get to it - Cadillacs rule [what a gas].

Re Tamiya, will breadboard a PIC, L293 and Tamiya together
this week. Look for possible motor noise/heating/etc problems.
===================

>   The CDROM's are a good idea. I save them for coasters ;-) You know, they
>might make good wheels if you could find a way to add a rubber O-ring or
>something around the edge. Maybe glue 2-3 CDs together. You could easily
>drill holes or mount magnets on them to count revoloutions. It would'nt be
>practical for a tach but you could sense how far you traveled. I haven't got
>that far yet on my hack.
>

Nice thing, for a botbody, you can stack any #of AOL disks [I
must have millions] till you have it as rigid as you want. For
wheels, CDs are too big, I think. I bought some 1.75" rubber
airplane wheels for the Tamiya. Friction, plus small size for
good torque.

Also, with CDs, you can easily build a multi-level bot.

For distance measurements, I'll probably just relie on
"no"-slippage initially.
=============

BTW, Walgreens is advertising 3 little RC cars for $12
altogether. Heckuva deal for radio links - if can get different
frequencies. This way one xmtr-rcvr in bot, another in
base station --> 2-way comm. Slow, but that's probably ok
if the bot has some minimal brains.

best regards,
- Dan Michaels
Oricom Technologies
http://www.oricomtech.com
=========================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...