12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

PIC16F88 at 4mhz internal osc.

Is serial a real problem with the internal osc ?

I'm just getting garbage back from hyperterminal, am I going to have
to stick a crystal on it to make it more stable?

Would it work better if I used the hardware serial support with the
internal osc instead of the software routines?
(no doubt would save me some code space...)

just wondered if anyone fancies a guess before I start again lol.

--
Lez

http://groups.google.com/group/recycled_citroen_uk/



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

In practice you can't use internal or RC osc for serial coms because it
isn't accurate enough.
For proper USART operation the clock frequency must be stable,
and within something like 5% of target value.
If the oscillator was off by more than 1% I'd be uncomfortable with
it...
so this means x-tal or resonator...no RC!

E.K
Lez wrote:

> PIC16F88 at 4mhz internal osc.
>
> Is serial a real problem with the internal osc ?
>
> I'm just getting garbage back from hyperterminal, am I going to have
> to stick a crystal on it to make it more stable?
>
> Would it work better if I used the hardware serial support with the
> internal osc instead of the software routines?
> (no doubt would save me some code space...)
>
> just wondered if anyone fancies a guess before I start again lol.
>
> --
> Lez
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I've had perfectly good luck running serial comms with the internal RC
osc. on the 12C508 and 12F629 parts from 2400 baud to 9600. I was
bit-banging which is more forgiving than the hardware UARTs though.

DLC

Eirik Karlsen wrote:
> In practice you can't use internal or RC osc for serial coms because it
> isn't accurate enough.
> For proper USART operation the clock frequency must be stable,
> and within something like 5% of target value.
> If the oscillator was off by more than 1% I'd be uncomfortable with it...
> so this means x-tal or resonator...no RC!
>
> E.K
>
>
> Lez wrote:
>
>> PIC16F88 at 4mhz internal osc.
>>
>> Is serial a real problem with the internal osc ?
>>
>> I'm just getting garbage back from hyperterminal, am I going to have
>> to stick a crystal on it to make it more stable?
>>
>> Would it work better if I used the hardware serial support with the
>> internal osc instead of the software routines?
>> (no doubt would save me some code space...)
>>
>> just wondered if anyone fancies a guess before I start again lol.
>>
>> --
>> Lez
>>
> --
> *******************************************
> VISIT MY HOME PAGE:
>
> LAST UPDATED: 23/08/2003
> *******************************************
> Regards
> Eirik Karlsen
>

--
-------------------------------------------------
Dennis Clark TTT Enterprises
www.techtoystoday.com
-------------------------------------------------



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi,

We had to put a XTAL on an 18F4620 project, and I've seen one on an
16F84 bit-banged project.

Alan KM6VV

dlc wrote:
> I've had perfectly good luck running serial comms with the internal RC
> osc. on the 12C508 and 12F629 parts from 2400 baud to 9600. I was
> bit-banging which is more forgiving than the hardware UARTs though.
>
> DLC
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I have had good luck with the serial hardware running with the
internal oscillator. I have basically run it at room temperatures
at 9600 and 19.2K baud without a problem. I've passed large amounts
of data (for an EEPROM programmer) and verified the data to/from
the PC (running in linux) after being sent.

Please note the following:
1. Hyperterminal can get screwed up. If the characters from the
PIC are coming out one right after the other, and the hyperterminal
can't determine the true start bit, then there will be garbage on
the screen. I suggest that you "hack up" your program and try
sending out a single character, wait a second and repeat. Make
sure that the stop bit is there (a low voltage signal) during the
stop bit (and intercharacter time). Also, if the PIC comes out
of its break condition during startup, with some data right away,
then it can screw up hyperterminal.

2. Make sure you have the right baud rate. This too can give you
garbage on the hyperterminal screen.

3. You do realize that the TX data out of the pic has to be
inverted? Good! Just trying to cover all the bases. "True" RS232
spec has both negative (below ground) and positive voltage levels.
I believe that it's *SUPPOSED* to be -5V and +5V levels or better
up to about +- 15V or so. This is not really an issue with many
many "serial" ports. Although claiming to be "RS232", I have
driven them with 0 and +5 voltage limits. I typically use an open
collector NPN transistor switch circuit. Seems to work just fine
in all the PCs that I've hooked it up to.

4. Make sure that parity and number of data bits are correct. This
too can generate garbage. Most of us use 8 data bits no parity
and one stop bit. YMMV.

5. If you send too many characters to fast to hyperterminal,
and it gets to the "high water" mark on its input buffer, then
hyperterminal can try to throttle the character stream by either
sending an XOFF character or by hardware. This is called flow
control. When hyperterminal determines that it can start
receiving characters again, it will either send an XON character
back to the PIC or reassert the hardware flow control. If this
is not followed, then characters sent by the PIC could be lost.

Just some of the gotchhas that you might want to look at with a
way of finding out some information with the "hack" mentioned. If you
indeed worry about parity, might I suggest you also use your little
hacked program with a different character being sent with opposite
parity to the original one.

Hope this helps!

Cheers,

Rich S.
--- In p...@yahoogroups.com, Lez wrote:
>
> PIC16F88 at 4mhz internal osc.
>
> Is serial a real problem with the internal osc ?
>
> I'm just getting garbage back from hyperterminal, am I going to have
> to stick a crystal on it to make it more stable?
>
> Would it work better if I used the hardware serial support with the
> internal osc instead of the software routines?
> (no doubt would save me some code space...)
>
> just wondered if anyone fancies a guess before I start again lol.
>
> --
> Lez
>
> http://groups.google.com/group/recycled_citroen_uk/
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

On 14/06/07, rj_satterlee wrote:
> I have had good luck with the serial hardware running with the
> internal oscillator. I have basically run it at room temperatures
> at 9600 and 19.2K baud without a problem.
Yes I think luck is now a variable not taken into account in my
software, I think I may need to add a Luck=TRUE somewhere.......

> Please note the following:
> 1. Hyperterminal can get screwed up. If the characters from the
> PIC are coming out one right after the other, and the hyperterminal

Ahh maybe...

> can't determine the true start bit, then there will be garbage on
> the screen. I suggest that you "hack up" your program and try
> sending out a single character, wait a second and repeat. Make

> of its break condition during startup, with some data right away,
> then it can screw up hyperterminal.

I set a few variables then send an ''hello world'',10,13

I get garbage..

> 2. Make sure you have the right baud rate. This too can give you
> garbage on the hyperterminal screen.

nice and slow 1200 8 n 1

> 3. You do realize that the TX data out of the pic has to be
> inverted? Good! Just trying to cover all the bases. "True" RS232

I send it twice, inverted and normal, as I thought that was it too.

> spec has both negative (below ground) and positive voltage levels.
> I believe that it's *SUPPOSED* to be -5V and +5V levels or better

I'm sending into a little bored pl2303 to up the levels, i just stuck
2 wires on it, ground and data in, it works on my nearest device to
hand, my cable modems diag pins, at 115000

>
> Just some of the gotchhas that you might want to look at with a

Yup I think my pic (F88) is just not stable on its internal osc etc,
will add a 4mhz something to it from the junk box and see how it goes,
may be a faulty pic, already had one this week that would not program
right, cant even write to the eeprom area correctly, and wont even
erase properly! (same batch so......)



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Were you writing in a high level language like C or Basic? My code was
all in assembly, which _might_ explain it.

DLC

> Hi,
>
> We had to put a XTAL on an 18F4620 project, and I've seen one on an
> 16F84 bit-banged project.
>
> Alan KM6VV
>
> dlc wrote:
>> I've had perfectly good luck running serial comms with the internal RC
>> osc. on the 12C508 and 12F629 parts from 2400 baud to 9600. I was
>> bit-banging which is more forgiving than the hardware UARTs though.
>>
>> DLC
>>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions
> Yahoo! Groups Links



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

On 14/06/07, d...@frii.com wrote:
> Were you writing in a high level language like C or Basic? My code was
> all in assembly, which _might_ explain it.

lol yes I'm a basic die hard believer that one day basic will become
the language of choice, or cobol, I like that too.....



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Dlc,

The 18F project was in C, the F84 was in asm.

Trying a 4 Mhz xtal is easy enough, then when after you're working, you can
switch to the internal RC osc. Sometimes there is a calibration for the osc
that could bring it in. But for production, we didn't want to have to tweak
anything.

Alan KM6VV

>
> Were you writing in a high level language like C or Basic? My code was
> all in assembly, which _might_ explain it.
>
> DLC
>
> > Hi,
> >
> > We had to put a XTAL on an 18F4620 project, and I've seen one on an
> > 16F84 bit-banged project.
> >
> > Alan KM6VV
> >



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, Lez wrote:
>
> On 14/06/07, dlc@... wrote:
> >
> >
> >
> >
> >
> >
> > Were you writing in a high level language like C or Basic? My
code was
> > all in assembly, which _might_ explain it.
>
> lol yes I'm a basic die hard believer that one day basic will become
> the language of choice, or cobol, I like that too.....
>

You really can't use MOVE CORRESPONDING to control a USART!

One of the all time great computer scientists (C.A.R Hoare) is quoted
as saying he didn't know what the computer language of choice in 2000
would look like but it would be called Fortran.

Richard



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> On 14/06/07, d...@frii.com wrote:
>>
>> Were you writing in a high level language like C or Basic? My code was
>> all in assembly, which _might_ explain it.
>
> lol yes I'm a basic die hard believer that one day basic will become
> the language of choice, or cobol, I like that too.....

I write in C, Basic, Java, assembler and other weird variants, so I
don't criticise language choices. In this case where the bit-bang is
VERY timing critical, higher level languages will not work well. In the
PIC I count cycles and do timing that is very precise, in assembly.

have fun,
DLC

>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions
> Yahoo! Groups Links
>
> .
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> --- In p...@yahoogroups.com, Lez wrote:
>>
>> On 14/06/07, dlc@... wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> > Were you writing in a high level language like C or Basic? My
> code was
>> > all in assembly, which _might_ explain it.
>>
>> lol yes I'm a basic die hard believer that one day basic will become
>> the language of choice, or cobol, I like that too.....
>> You really can't use MOVE CORRESPONDING to control a USART!
>
> One of the all time great computer scientists (C.A.R Hoare) is quoted
> as saying he didn't know what the computer language of choice in 2000
> would look like but it would be called Fortran.

True. If you are having problems with the USART, it won't matter how
you coded the program. More study will be needed to see what is going
wrong. It could be that you need to tweak the internal OSC, but where
precision is needed in a production environment, you can't beat a
crystal or resonator.

DLC

> Richard



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I've been running a 16F88 on the internal at 9600 for ages into Hyperterm and capturing the input for data logging for months. Never had a problem - not a single bad byte. Are you sure you've set the correct values into the BRG? That's the one that usually catches me out.

Derek.

----- Original Message -----
From: Lez
To: p...@yahoogroups.com
Sent: Wednesday, June 13, 2007 8:56 PM
Subject: [piclist] software serial and internal osc
PIC16F88 at 4mhz internal osc.

Is serial a real problem with the internal osc ?

I'm just getting garbage back from hyperterminal, am I going to have
to stick a crystal on it to make it more stable?

Would it work better if I used the hardware serial support with the
internal osc instead of the software routines?
(no doubt would save me some code space...)

just wondered if anyone fancies a guess before I start again lol.

--
Lez

http://groups.google.com/group/recycled_citroen_uk/

------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 13/06/2007 12:50



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi,

its may be you had put a transistor on the TX line of your pic. if so that
will invert the signal and make whole thing an garbage like charactors over
serial comms. once this happen to myself and take two days to pintedout the
issue. just to keep in mind not to invert the signal outputs from pic( or
invert it twise)

hopes this helps you

Dha.
-----Original Message-----
From: p...@yahoogroups.com [mailto:p...@yahoogroups.com]On Behalf Of
Lez
Sent: Thursday, June 14, 2007 1:32 PM
To: p...@yahoogroups.com
Subject: Re: [piclist] Re: software serial and internal osc
On 14/06/07, rj_satterlee wrote:
>
>
>
>
>
>
> I have had good luck with the serial hardware running with the
> internal oscillator. I have basically run it at room temperatures
> at 9600 and 19.2K baud without a problem.

Yes I think luck is now a variable not taken into account in my
software, I think I may need to add a Luck=TRUE somewhere.......

> Please note the following:
> 1. Hyperterminal can get screwed up. If the characters from the
> PIC are coming out one right after the other, and the hyperterminal

Ahh maybe...

> can't determine the true start bit, then there will be garbage on
> the screen. I suggest that you "hack up" your program and try
> sending out a single character, wait a second and repeat. Make

> of its break condition during startup, with some data right away,
> then it can screw up hyperterminal.

I set a few variables then send an ''hello world'',10,13

I get garbage..

> 2. Make sure you have the right baud rate. This too can give you
> garbage on the hyperterminal screen.

nice and slow 1200 8 n 1

> 3. You do realize that the TX data out of the pic has to be
> inverted? Good! Just trying to cover all the bases. "True" RS232

I send it twice, inverted and normal, as I thought that was it too.

> spec has both negative (below ground) and positive voltage levels.
> I believe that it's *SUPPOSED* to be -5V and +5V levels or better

I'm sending into a little bored pl2303 to up the levels, i just stuck
2 wires on it, ground and data in, it works on my nearest device to
hand, my cable modems diag pins, at 115000

>
> Just some of the gotchhas that you might want to look at with a

Yup I think my pic (F88) is just not stable on its internal osc etc,
will add a 4mhz something to it from the junk box and see how it goes,
may be a faulty pic, already had one this week that would not program
right, cant even write to the eeprom area correctly, and wont even
erase properly! (same batch so......)



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I have done adaptive baud rate systems before but it needs the other end to send a code for it to measure. So unless you are making 100's or 1000's of these i would just bang in a crystal.

----- Original Message ----
From: Eirik Karlsen
To: p...@yahoogroups.com
Sent: Wednesday, 13 June, 2007 11:36:10 PM
Subject: Re: [piclist] software serial and internal osc

In practice you can't use internal or RC osc for serial coms because it
isn't accurate enough.

For proper USART operation the clock frequency must be stable,

and within something like 5% of target value.

If the oscillator was off by more than 1% I'd be uncomfortable with
it...

so this means x-tal or resonator... no RC!

E.K

Lez wrote:
PIC16F88 at 4mhz internal osc.
Is serial a real problem with the internal osc ?

I'm just getting garbage back from hyperterminal, am I going to have

to stick a crystal on it to make it more stable?

Would it work better if I used the hardware serial support with the

internal osc instead of the software routines?

(no doubt would save me some code space...)

just wondered if anyone fancies a guess before I start again lol.

--

Lez

--

************ ********* ********* ********* ****

VISIT MY HOME PAGE:



LAST UPDATED: 23/08/2003

************ ********* ********* ********* ****

Regards

Eirik Karlsen



___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

You need to investigate why you are getting garbage, it could be one of a hundred reasons.

I would first look at the output data on a scope.
See how far a bit width is out.

After that it could be an osc timing problem.
It could wrong number of bits, buffer overrun, parity problems.

----- Original Message ----
From: Lez
To: p...@yahoogroups.com
Sent: Wednesday, 13 June, 2007 8:56:59 PM
Subject: [piclist] software serial and internal osc

PIC16F88 at 4mhz internal osc.

Is serial a real problem with the internal osc ?

I'm just getting garbage back from hyperterminal, am I going to have

to stick a crystal on it to make it more stable?

Would it work better if I used the hardware serial support with the

internal osc instead of the software routines?

(no doubt would save me some code space...)

just wondered if anyone fancies a guess before I start again lol.

--

Lez

http://groups. google.com/ group/recycled_ citroen_uk/



___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )