Searching \ for '[PIC:] Beginner with RS232 and Programming questio' 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/begin.htm?key=programming
Search entire site for: 'Beginner with RS232 and Programming questio'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Beginner with RS232 and Programming questio'
2004\10\25@234814 by Barton Hodges

flavicon
face
Hi,

I'm new to the list and PIC programming.  I purchased a DHMicro
Breadboard-18 and some PIC16F87 microcontrollers.  I'm using a JDM
Programmer with WinPIC and HI-Tech C.  I can successfully program the
chip to utilize the LEDs and buttons on the Breadboard-18.  I have a
few questions that I'm hoping someone can answer.

Is the PIC16F870 the same as the PIC16F87?  Both IC-Prog and HI-Tech C
have the PIC16F870 listed, but not the PIC16F87.

I can't seem to get IC-Prog to program a chip without "Verify failed
at 0000h !" errors, although WinPIC works just fine.  I've
double-checked that the hardware settings are correct, and verified
that they match the "settings for supported programmers" from the
website.  Is there something I'm missing?

Finally, I'm trying to utilize the RS232 port on the Breadboard-18
with the UART that is built into the PIC16F87 (I don't want to use
bit-banging).  I've connected RB5 to the TxD on the User I/O, and I've
tried several different code samples that I've found on the Internet.
I have tried many different baud rates, and although there is
definitely data reaching the transmit pin on the DB9, all that happens
in my terminal program is that the cursor blinks erratically.  No
characters are ever displayed.  It's as if the timing is off somehow.


Does anyone have a Breadboard-18 and some verified code (C or ASM)
that I can plug into my PIC to help narrow down the problem?

Thank you for any help,

Barton



____________________________________________

2004\10\26@060206 by Jan-Erik Soderholm

face picon face
Barton Hodges wrote :

>
> Is the PIC16F870 the same as the PIC16F87?

No.

>  Both IC-Prog and HI-Tech C
> have the PIC16F870 listed, but not the PIC16F87.

Quite different.

> I can't seem to get IC-Prog to program a chip without "Verify failed
> at 0000h !" errors, although WinPIC works just fine.

Use tools that specificialy supports the PIC(s) you are using.

>  I've
> double-checked that the hardware settings are correct, and verified
> that they match the "settings for supported programmers" from the
> website.  Is there something I'm missing?

You just said that your tools did *not* list the F87, didn't you ?

Could you be a little nore explicit about what tool and what PIC
your are susing in each case ? You have mentioned two
different tools and two different PICs...

Jan-Erik.

____________________________________________

2004\10\26@091759 by Barton Hodges

flavicon
face
piclist-bounces@mit.edu wrote:
> Barton Hodges wrote :
>> Is the PIC16F870 the same as the PIC16F87?
>
> No.
>
>>  Both IC-Prog and HI-Tech C
>> have the PIC16F870 listed, but not the PIC16F87.
>
> Quite different.
>
>> I can't seem to get IC-Prog to program a chip without "Verify
failed
{Quote hidden}

I am using the PIC16F87, not the PIC16F870.  I'll order a different
PIC today, probably in the same 16F7X series.  Can you recommend one
that is popular with an AUSART that I can use for learning purposes?
Perhaps a PIC16F873A?



____________________________________________

2004\10\26@102744 by Ian Smith-Heisters

flavicon
face
Barton Hodges wrote:

>[snip!]
>
>Finally, I'm trying to utilize the RS232 port on the Breadboard-18
>with the UART that is built into the PIC16F87 (I don't want to use
>bit-banging).  I've connected RB5 to the TxD on the User I/O, and I've
>tried several different code samples that I've found on the Internet.
>I have tried many different baud rates, and although there is
>definitely data reaching the transmit pin on the DB9, all that happens
>in my terminal program is that the cursor blinks erratically.  No
>characters are ever displayed.  It's as if the timing is off somehow.
>
>
>  
>
It looks like you have some other issues to work out first, but when you
get back to this...

From my experience with the 18F452, which may or may not apply in this
case, the UART on the PIC outputs its messages with regular binary
logic, and RS-232 requires inverted logic, ie. all the 1s are low, all
the 0s are high. Secondly, most computers use +-12v for RS232. I'm not
sure on this next part, but I think the UART also uses one start bit and
one stop bit and RS-232 can use 1, 1.5, or 2 stop bits, but doesn't have
a start bit (is there any way to change this?).

I think the best way to translate between the two is to use a MAX232,
which I just picked up from glitchbuster.com for $0.69 USD each.
Otherwise, I have gotten it to work by writing the transmission routines
by hand, and thereby being able to send it with inverted logic and no
start bit.

However, your C compiler may do that for you, depending on its
transmission routines.

Hope that helps, and I also hope it has some truth in it, like I said,
I'm just learning this stuff too.

Cheers,
Ian

>Does anyone have a Breadboard-18 and some verified code (C or ASM)
>that I can plug into my PIC to help narrow down the problem?
>
>Thank you for any help,
>
>Barton
>
>
>
>_____________________________________________

2004\10\26@110135 by olin_piclist

face picon face
Ian Smith-Heisters wrote:
> I'm not
> sure on this next part, but I think the UART also uses one start bit and
> one stop bit and RS-232 can use 1, 1.5, or 2 stop bits, but doesn't have
> a start bit (is there any way to change this?).

RS-232 always has a start bit.  The leading edge of the start bit provides
the zero time reference for the rest of the byte.  The number of stop bits
must be at least one or some UARTs will detect a framing error.  Any number
greater than 1 works fine for transmission, since after one stop bit the
receiving UART is looking for the next start bit, which can come at any
time.

Nowadays, everyone pretty much uses 1 stop bit in full speed transmission.
Some old mechanical equipment of years ago required more stop bits for the
mechanism to reset, but that is not an issue today with everything
interpreted by digital logic.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\26@111635 by Barton Hodges

flavicon
face
piclist-bounces@mit.edu wrote:
> It looks like you have some other issues to work out first,
> but when you
> get back to this...
>
>  From my experience with the 18F452, which may or may not
> apply in this
> case, the UART on the PIC outputs its messages with regular binary
> logic, and RS-232 requires inverted logic, ie. all the 1s are
> low, all
> the 0s are high. Secondly, most computers use +-12v for
> RS232. I'm not
> sure on this next part, but I think the UART also uses one
> start bit and
> one stop bit and RS-232 can use 1, 1.5, or 2 stop bits, but
> doesn't have
> a start bit (is there any way to change this?).
>
> I think the best way to translate between the two is to use a
MAX232,
> which I just picked up from glitchbuster.com for $0.69 USD each.
> Otherwise, I have gotten it to work by writing the
> transmission routines
> by hand, and thereby being able to send it with inverted logic and
no
> start bit.

Thankfully, the Breadboard-18 (http://www.dhmicro.com/product.html)
already has an RS232 driver chip (mine has an SP232A which is
compatible with a MAX232), so this is not the issue.  

> However, your C compiler may do that for you, depending on its
> transmission routines.

I'm beginning to think that the problem might be that the compiler
does not support my PIC16F87 chip.  I have it configured to use the
PIC16F870, and it compiles properly and works for all other I/O that I
have tried.  Perhaps there is something different with the UARTs
between the two chips.  I'm going to order another chip to try, and
I'm considering a PIC16F873A.  Do you have any suggestions?



____________________________________________

2004\10\26@120203 by Ian Smith-Heisters

flavicon
face
Barton Hodges wrote:

>[snip]
>I'm beginning to think that the problem might be that the compiler
>does not support my PIC16F87 chip.  I have it configured to use the
>PIC16F870, and it compiles properly and works for all other I/O that I
>have tried.  Perhaps there is something different with the UARTs
>between the two chips.  I'm going to order another chip to try, and
>I'm considering a PIC16F873A.  Do you have any suggestions?
>
>  
>
I've only ever used the 18F452, so I can't be of much help. It's a great
chip and has several advantages over the 16F, and I would strongly
recommend it, but I don't have any experience to compare it to, so my
recommendation is worthless from a logical point of view ;)

>
>_____________________________________________

2004\10\26@120648 by Ian Smith-Heisters

flavicon
face
Olin Lathrop wrote:

{Quote hidden}

That's all really helpful, the bit about mechanical devices makes
everything much more clear. Thanks.

-Ian

>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>_____________________________________________

2004\10\26@121646 by Jan-Erik Soderholm

face picon face
Barton Hodges wrote :

> I'm beginning to think that the problem might be that the compiler
> does not support my PIC16F87 chip.  I have it configured to use the
> PIC16F870,...

But that's not the PIC your are using, right ?

> and it compiles properly...

Of course it does ! The compiler *thinks* you have a 16F870 !

> and works for all other I/O that I have tried...

Pure luck... :-)

> Perhaps there is something different with the UARTs
> between the two chips.

Check the data sheets...
Those PICs are from two different generations.

> I'm going to order another chip to try, and
> I'm considering a PIC16F873A.  Do you have any suggestions?

No, I don't know your hardware and tools you are using.
I'd suggest that you read : http://www.voti.nl/swp/index.html.
It might not help, but it gives some insight.

Best Regards,
Jan-Erik.

____________________________________________

2004\10\26@122751 by Bob Ammerman

picon face
>>RS-232 always has a start bit.  The leading edge of the start bit provides
>>the zero time reference for the rest of the byte.  The number of stop bits
>>must be at least one or some UARTs will detect a framing error.  Any
>>number
>>greater than 1 works fine for transmission, since after one stop bit the
>>receiving UART is looking for the next start bit, which can come at any
>>time.

To be pedantic, RS232 does _not_ always have a start bit. RS232 can be used
to send synchronous transmissions, in which case there are neither start nor
stop bits.

Bob Ammerman
RAm Systems

____________________________________________

2004\10\26@132144 by olin_piclist

face picon face
Bob Ammerman wrote:
> To be pedantic, RS232 does _not_ always have a start bit. RS232 can be
> used to send synchronous transmissions, in which case there are neither
> start nor stop bits.

But then there has to be a clock.  I didn't realize the RS-232 "spec"
included a synchronous mode.

To not confuse the OP however, we should point out that a standard PC serial
port definitely uses the asynchronous mode that most people associate
directly with RS-232.  It is also by definition the mode used by a UART (=
Univeral Asynchronous Receiver Transmitter).


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\26@140809 by Bob Ammerman

picon face
> Bob Ammerman wrote:
>> To be pedantic, RS232 does _not_ always have a start bit. RS232 can be
>> used to send synchronous transmissions, in which case there are neither
>> start nor stop bits.
>
> But then there has to be a clock.  I didn't realize the RS-232 "spec"
> included a synchronous mode.

Yep, it defines several pins for clocks, as well as a couple of alternative
ways for clocks to be generated/supplied for the send and receive bit
streams (ie whether they come from DTE or DCE).

Bob Ammerman
RAm Systems

____________________________________________

2004\10\26@145718 by Support - KF4HAZ

flavicon
face
In the late 70's - early 80's synchronous communication was the hobbyists best friend,
not so hard to "bit-bang" and timing was not critical.
Simply make the data available then clock it in.
Parallel required 8 data lines, a strobe and a status line,
synchronous serial only 1 data line and 1 clock (to strobe in the data) and a status line.
3 lines and a common vs. 10 and a common.

KF4HAZ - Lonnie

----- From: "Bob Ammerman" <rammerman@
{Quote hidden}

____________________________________________

2004\10\26@155028 by Brent Brown

picon face
On 26 Oct 2004 at 10:16, Barton Hodges wrote:

> I'm beginning to think that the problem might be that the compiler
> does not support my PIC16F87 chip.  I have it configured to use the
> PIC16F870, and it compiles properly and works for all other I/O that I
> have tried.  Perhaps there is something different with the UARTs
> between the two chips.  I'm going to order another chip to try, and
> I'm considering a PIC16F873A.  Do you have any suggestions?

As far as the I can tell at least the last couple of releases of Hi-Tech PICC
(v8.02 & v8.05) have included support for the PIC16F87. If you need to,
update the compiler to support the chip you want/need to use. The problems
you are experiencing seem to be coding issues and not related to the chip or
compiler. Getting started with serial comms can be a bit of a mission, but
getting over that hurdle is part of the learning.

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


____________________________________________

2004\10\27@003914 by William Chops Westfield

face picon face

On Oct 26, 2004, at 11:58 AM, Falcon Wireless Tech Support - KF4HAZ
wrote:

> In the late 70's - early 80's synchronous communication was the
> hobbyists
> best friend, not so hard to "bit-bang" and timing was not critical.

It still is, in the form of SPI, I2C, and other protocols.  But Bob was
talking about synchronous rs232 serial communications, which are
considerably more complex, involving CRCs, poorly documented packet
formats, bit stuffing
and synch characters during idle, and a bunch of other things you really
don't want to do on a small microcontroller.

Having a serial background, I tend to think of SPI/etc more as one-bit
wide parallel ports than actual serial ports.  Sort of like BBN1822 :-)
Serial ports (to me) are things that deliver BYTES serially; part of the
power of SPI/etc is that it doesn't have an inherent byte size...

BillW

____________________________________________

2004\10\27@012628 by William Chops Westfield

face picon face
>
According to the microchip web site, both the 16F87 and 16f870 have
"AUSART"
style uarts, but the 87 is an 18 pin device while the 870 is a 28 pin
device.
While the UART code itself might be OK, the UART i/o pins are
multiplexed
with different signals on the two parts, so the code to enable the uart
(instead of alternate pin functions) must almost certainly be different.

BillW

____________________________________________

2004\10\27@042637 by Alan B. Pearce

face picon face
> I'm going to order another chip to try, and
> I'm considering a PIC16F873A.  Do you have any suggestions?

I think you would find the 16F876 a better device to work with, pin
compatible to the F873, but more memory and ram.

____________________________________________

2004\10\27@043240 by Alan B. Pearce

face picon face
>But Bob was talking about synchronous rs232 serial
>communications, which are considerably more complex,
>involving CRCs, poorly documented packet formats,
>bit stuffing and synch characters during idle, and a
>bunch of other things you really don't want to do
>on a small microcontroller.

Ahh the nostalgic days of half duplex 2780 IBM protocol ...
____________________________________________


'[PIC:] Beginner with RS232 and Programming questio'
2004\11\10@001329 by Barton Hodges
flavicon
face

Hey everyone, thank you for all the assistance with the RS232 problem
I wrote about earlier.  The RS232 problem was determined to be a
timing issue, and I was experiencing erratic behavior in a simple LED
flashing routine.  The LED would blink erratically unless I placed my
hand near the development board, or grounded it.

The problem turned out to be the that the default settings in WinPIC
for the 16F87 chip has the "Low Voltage Prog" bit enabled.  Since I am
quite a newbie at this, I incorrectly assumed that the defaults chosen
for the device would be proper in all circumstances.

>From the data sheet:

"While in Low-Voltage ICSP mode (LVP = 1), the RB3 pin can no longer
be used as a general purpose I/O pin.  When using Low-Voltage ICSP
Programming (LVP) and the pull-ups on PORTB are enabled, bit 3 in the
TRISB register must be cleared to disable the pull-up on RB3 and
ensure the proper operation of the device.  RB3 should not be allowed
to float if LVP is enabled. An external pull-down device should be
used to default the device to normal operating mode. If RB3 floats
high, the PIC16F87/88 device will enter Programming mode.  LVP mode is
enabled by default on all devices shipped from Microchip. It can be
disabled by clearing the LVP bit in the CONFIG register.  Disabling
LVP will provide maximum compatibility to other PIC16CXXX devices."

After reading this, I placed a resistor between RB3 and ground, and it
solved the problem when the LVP bit is enabled.  The problem is also
solved when the LVP bit is disabled.

Again, thanks for the help.

Barton



____________________________________________

2004\11\10@073748 by Byron A Jeff

face picon face
On Tue, Nov 09, 2004 at 11:13:26PM -0600, Barton Hodges wrote:
{Quote hidden}

That's how it works. One last thing: Whenever you program a LVP capable part,
the LVP pin should be grounded even when you are HVP. The erasure process
causes the parts to briefly be in LVP mode and could cause it to lock up.

BAJ
____________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...