Searching \ for '[PIC] USART async comms with PC running hypertermi' 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/ios.htm?key=usart
Search entire site for: 'USART async comms with PC running hypertermi'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] USART async comms with PC running hypertermi'
2005\05\02@055026 by Dave Turner

picon face
part 1 1034 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable)

Hi,

I am having problems with my PIC16F87 USART.  I am using async comms
with it, and it seems to be doing something right, as it keeps sending
something, at the correct interval.  Unfortuneately, in hyperterminal,
it only comes up with a lot of hearts and spaces.  I check out the
capture file in hex, and it says the data is all 03hs and 0FFhs.  I
think something is going wrong with the code, so the clock is going
correctly, but the actual data line isn't working.  I am trying to
send the letter A (ascii 65).  I am running the PIC on a PICDem 4
board, which included a "RS232 level shifting IC".  Also, I am using
an MPLAB ICD2 for programming and debugging.  I have attached a copy
of the asm file, with many comments.

BTW, I am trying to use a baud rate of 9600, and I think the clock is
a 20MHz one, but I'm not sure.  The osc config bit is EXTRC-OSC2 as
clock out.

Thanks soo much for any help.


BTW2, for some reason a smily face also just apeared in hyperterm


part 2 1915 bytes content-type:application/octet-stream; name="serialUSART.asm" (decode)

part 3 65 bytes content-type:text/plain; name="capture.txt"
(decoded base64)


part 4 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\05\02@060425 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :


> I am having problems with my PIC16F87 USART.  I am using async comms
> with it, and it seems to be doing something right, as it keeps sending
> something, at the correct interval.  Unfortuneately, in hyperterminal,
> it only comes up with a lot of hearts and spaces.

If you actualy have a baud rate problem, that could look like that.

> I have attached a copy
> of the asm file, with many comments.

Where are all __CONFIG directives ?
And the "list p=xxxx" ?
And the "include p16f87.inc" ?
Why do you set up symbols for the SFR:s ? They are all
in the device specific include file anyway.

> I think the clock is a 20MHz one, but I'm not sure.

:-)
Just send me the board and I'll check that for you.
:-)

> The osc config bit is EXTRC-OSC2 as clock out.

Show the __CONFIG directive so that can be checked.

> BTW2, for some reason a smily face also just apeared in hyperterm

I can understand that... ;-)

Regards,
Jan-Erik.



2005\05\02@062724 by Dave Turner

picon face
Hi,

Firsties, thanks for the quick response - most mailing lists i use
take about 4 years average response.

Second, the config is all saved in the mplab project.  In the
configure menu, and the config bits part.  I prefer to use this than
specify it in the code, because it's much clearer.

The config bits are as follows: osc is extrc-osc2 as clock out.  WD is
off.  Power up is on.  MCLR is on.  brown out detect is on.  low
voltage program is disabled - the ICD2 tells me to do this.  all code
protection related stuff is off.

The list and include are all included in my custum include file.  I
made it so I don't have to keep defining friendly names for things in
every project.

I setup my own custom names for some of the SFRs, because at the time,
my resorce only showed me the addresses for the SFRs, not the actual
names.

About the PICdem 4 osc, it has some sort of real time clock stuff on
it, and I'm not absolutely sure what it does, which is one reason I'm
so worried about the baud rate.  It says it has an RC osc, about 2MHz,
and a 32Khz on timer1.  I am using the external RC osc, because my
ICD2 says I have to, although I think it might be possible to set it
up with an internal osc.  I'm not sure what internal osc the 16F87 has
either.

Finally, do you know if my method of bank switching is correct.

On 5/2/05, Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com> wrote:
{Quote hidden}

> -

2005\05\02@064959 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> Firsties, thanks for the quick response - most mailing lists i use
> take about 4 years average response.

:-)

> Second, the config is all saved in the mplab project.  In the
> configure menu, and the config bits part.  I prefer to use this than
> specify it in the code, because it's much clearer.

Not for us.

> The config bits are as follows: osc is extrc-osc2 as clock out.  WD is
> off.  Power up is on.  MCLR is on.  brown out detect is on.  low
> voltage program is disabled - the ICD2 tells me to do this.  all code
> protection related stuff is off.

Well, you say so. That doesn't *prove* anything... :-)
No offence, it's just that most here likes to *know* how things
are setup. What would you say if you in a day or two find out
that some of the settings actualy wasn't as you *thought* ?

> The list and include are all included in my custum include file.  I
> made it so I don't have to keep defining friendly names for things in
> every project.
>
> I setup my own custom names for some of the SFRs, because at the time,
> my resorce only showed me the addresses for the SFRs, not the actual
> names.

I don't rely understand what's you problem here.
And I have never heard a resonable reason to *not* use the
INC files included in MPLAB. What if you have made an error in
your own defines of the SFR symbols ?

>
> About the PICdem 4 osc, it has some sort of real time clock stuff on
> it, and I'm not absolutely sure what it does, which is one reason I'm
> so worried about the baud rate.  It says it has an RC osc, about 2MHz,
> and a 32Khz on timer1.  I am using the external RC osc, because my
> ICD2 says I have to,...

I know nothing about the IDC2, but I *do* know that an RC-osc
will have a hard time to give you any relailable serial communication.
You need *some* crystal (or maybe resonator) based osc to be able
to use the UASRT (or maybe the prec internal osc block on newer devices).

> although I think it might be possible to set it
> up with an internal osc.  I'm not sure what internal osc the 16F87 has
> either.

Doesn't the data sheet tell you that ?
My copy does...

This is fairly modern device with nanoWatt and the 8Mhz
internal osc block, so it should have all options you need.

> Finally, do you know if my method of bank switching is correct.

Think so...
Run the SIMulator on it and you'd be able to see the bank bits changing.

Regards,
Jan-Erik.



2005\05\02@070344 by Wouter van Ooijen

face picon face
> Second, the config is all saved in the mplab project.  In the
> configure menu, and the config bits part.  I prefer to use this than
> specify it in the code, because it's much clearer.

Bad idea IMHO, the source should specify everthing. But if you want it
this way you should include the project file(s) to we can check.

> The config bits are as follows: osc is extrc-osc2 as clock out.

You use an external RC oscillator and expect it to be accurate enough to
do serial communications? This is a bad idea, no IMHO qualification
needed.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\05\02@070656 by Dave Turner

picon face
> > Second, the config is all saved in the mplab project.  In the
> > configure menu, and the config bits part.  I prefer to use this than
> > specify it in the code, because it's much clearer.
>
> Not for us.

Sorry.  I learned to do it that way, and don't have a clue how to do
it in the source.

> I don't rely understand what's you problem here.
> And I have never heard a resonable reason to *not* use the
> INC files included in MPLAB. What if you have made an error in
> your own defines of the SFR symbols ?

Well, what I meant is that my own custom include file, does actually
include the MPLAB include file, so it does end up in the final file.
My include file adds friendlier names, like LED1, LED2, etc.  which I
find makes code clearer (well, for me anyway)
{Quote hidden}

So, if I setup the config bits to use internal osc, and output it so
the ICD2 can use it, that should work?  Also, I am very unsure about
setting up the baud rate - in the 16F87 datasheet, it does have a lot
of tables and forulae to work out what number to use, but this totally
baffled me.

I looked at the tables, and used the high speeed baud rate mode, for
the INTRC 8MHz table, and it said to use 51 for 9600.  So I used 51 in
spbrg, and set the osc in the config bits to INTRC, clock out on osc2,
and now nothing happens at all.  The hyperterm display stays blank.

2005\05\02@071154 by Dave Turner

picon face
<gulp>

Well, I did only compile my first "led on" program a week ago.

Ok, well 2 weeks then.

So, should the "INTRC" be accurate enough?

Attached a zip of the entire project folder.

On 5/2/05, Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl> wrote:
{Quote hidden}

> -

2005\05\02@071328 by Dave Turner

picon face
part 1 1445 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable)

Oops.  Forgot to attach the file.  Here it is:

On 5/2/05, Dave Turner <dave.w.turnerspamKILLspamgmail.com> wrote:
{Quote hidden}

2005\05\02@073042 by Jan-Erik Soderholm

face picon face
To have the configs in the source, look at the end of the
device include file (P16F87.INC). There is a cut-n-pasteable
example there.

> Well, what I meant is that my own custom include file, does actually
> include the MPLAB include file, so it does end up in the final file.

But if so, why do you have lines like these in your source : ????

> rcsta        equ        18h
> txreg        equ        19h
> txsta        equ        98h        ; my own definitions of some key USART locations
> spbrg        equ        99h

They are already defined in P16F87.INC.
Don't you get any warnings about "multiply defined symbols"
Have you disabled "case sensitivity" in MPALB. Recomended, IMHO...

> Also, I am very unsure about
> setting up the baud rate - in the 16F87 datasheet, it does have a lot
> of tables and forulae to work out what number to use, but this totally
> baffled me.

One thing you *definitly* have to know, is the speed your
PIC is running at. Knowing that, you can calculate the value
for the baud rate register as described in the data sheet.

> I looked at the tables, and used the high speeed baud rate mode, for
> the INTRC 8MHz table, and it said to use 51 for 9600.

Note that the values i the tabes i the data sheet are in *decimal*.
If you use them as-is, make sure that you specify them as decimal
constants, not hexadecimal. (As far as I can see, that is not any
problem in your code, but anyway...)

Jan-Erik.





2005\05\02@074149 by Russell McMahon

face
flavicon
face
> I know nothing about the IDC2, but I *do* know that an RC-osc
> will have a hard time to give you any relailable serial
> communication.
> You need *some* crystal (or maybe resonator) based osc to be able
> to use the UASRT (or maybe the prec internal osc block on newer
> devices).

You need about 50/N% clock stability overall for async operation.
better is better.
So for 1+8+1=10 bits you need 50/10%=5% accuracy.

If your PC end crystal is approaching 0% in error then you get most of
that 5% at the microprocessor end. Some (but by no means all) RC
clocks will give you that sort of accuracy across voltage, temperature
and time.

But, as Jan-Erik says, something better than RC is a really good idea
if you can manage it. A resonator is fine.

If you aren't at all sure what your baud rate is then Murphy says it's
almost certainly wrong.
(If you ARE sure then Murphy says it may be wrong :-) ).

If you have a scope then the shortest bit length will tell you what
the baud rate is if you send anything with a 010 or 101 sequence in
it.

No scope?
Set data to, say, $00, with a good gap between bytes.
If you can send individual characters without CRLF it's ***MUCH***
easier to work out what's happening.
If you are sending slower than you think then the receiving routine
will see an $00 followed by a second character with b0xxxxxxx. ie
01111111 or 00111111 or 00011111 etc depending how slow. if reaaally
slow it will se several $00's followed by a b0xxxxxxx.
Having your PC end able to display the result of receiving $00 helps a
lot here :-)

So, if you send 1 character from the uP and see several characters,
odds are it's too slow. Double sending data rate and try again?
See $00 - it works.
Still see 2+ characters, double clock rate again.

If you are sending faster than you think the PC will see N 0's and M
1's / 1<=N<=7, M=8-N.
Decode the displayed character and you can see how much faster it is
than you expected.

Using a scope is much easier.




       RM

2005\05\02@074554 by Dave Turner

picon face
> But if so, why do you have lines like these in your source : ????
>
> > rcsta equ     18h
> > txreg equ     19h
> > txsta equ     98h     ; my own definitions of some key USART locations
> > spbrg equ     99h
>
> They are already defined in P16F87.INC.
> Don't you get any warnings about "multiply defined symbols"
> Have you disabled "case sensitivity" in MPALB. Recomended, IMHO...

I always have case sensetivity on.  I didn't know they were defined
earlier.  It still works, because i think the ones in P16F87.inc are
upper case.  Anyway, when I wrote this code, I didn't know it was all
already in the code.


{Quote hidden}

It's certainly decimal.  movlw  d'51'.    I'm extremely confused about
why my code woné even run with the internal osc.  The light that turns
on if the power is on does work though.

I just discovered whilst reading the datasheet that intrc isn't
actually the internal 8mhz osc, but an internal RC (well, duh, but I
didn't notice).  Does anyone know which config option to use for the
internal 8MHz osc?  (any __config source code versions are also
welcome)

2005\05\02@075201 by olin_piclist

face picon face
Dave Turner wrote:
> I am using async comms
> with it, and it seems to be doing something right, as it keeps sending
> something, at the correct interval.  Unfortuneately, in hyperterminal,
> it only comes up with a lot of hearts and spaces.

Sounds like a baud rate mismatch.

> BTW, I am trying to use a baud rate of 9600, and I think the clock is
> a 20MHz one, but I'm not sure.

Then get sure.  You need to know the clock frequency to set up the UART in
order to get the desired baud rate.

> The osc config bit is EXTRC-OSC2 as clock out.

Huh?  I haven't looked at this data sheet, but EXTRC usually means "external
R/C".  These don't go to 20MHz, at least not on an PIC I have looked at.  I
also find it unlikely that Microchip would have used this mode on one of
their development board.  They cost enough that $.50 for a crystal would be
irrelevant.

Once you know your oscillator frequency, take a look at my UART_xxx macros
in STD.INS.ASPIC.  These can be used to automatically compute the baud rate
setup and intialize the UART.


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

2005\05\02@075324 by Byron A Jeff

face picon face
On Mon, May 02, 2005 at 10:50:26AM +0100, Dave Turner wrote:
> Hi,
>
> I am having problems with my PIC16F87 USART.

With all things related to the PIC USART one should start with Fr. Thomas
McGahee's PICUART.ASM. You can find it here:

http://www.pic101.com/mcgahee

While you don't have to use it, the two things that it helps out with are:

1) It has a completely working tutorial program that you can just drop in
and test with.

2) The fully annotated code with all of the PICUSART gotchas often will
point out the item that you missed.

I use it as component code for serial, since I know that it's been well
tested and well documented. It just works.

Hope this helps,

BAJ

2005\05\02@075408 by Wouter van Ooijen

face picon face
> So, should the "INTRC" be accurate enough?

I doubt it. Check the datasheet, if it promises 1% accuracy it is OK.
But it will be much batter than an external RC oscillator.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\05\02@075632 by Dave Turner

picon face
Okays, well I would do this, except whatever I try to send, the
computer only recieves lots and lots of ones, which it decodes as 03h
(111), and FF (11111111).  I think there's probably some other problem
than the baud rate.

On 5/2/05, Russell McMahon <EraseMEapptechspam_OUTspamTakeThisOuTparadise.net.nz> wrote:
{Quote hidden}

> -

2005\05\02@075725 by Byron A Jeff

face picon face
On Mon, May 02, 2005 at 01:54:06PM +0200, Wouter van Ooijen wrote:
> > So, should the "INTRC" be accurate enough?
>
> I doubt it. Check the datasheet, if it promises 1% accuracy it is OK.
> But it will be much batter than an external RC oscillator.

Not a chance.

You simply can't do reliable serial at any resonable bit rate using RC.

We've had some debates about the accuracy of the nanowatt internal
oscillator, which is supposedly tuned to within 2%.

But the best thing to do is to test with a crystal or resonator.

The more variables you lock down (i.e. clock rate) the more likely you
can find your problem.

BAJ

2005\05\02@075948 by Byron A Jeff

face picon face
On Mon, May 02, 2005 at 12:56:31PM +0100, Dave Turner wrote:
> Okays, well I would do this, except whatever I try to send, the
> computer only recieves lots and lots of ones, which it decodes as 03h
> (111), and FF (11111111).  I think there's probably some other problem
> than the baud rate.

Can you take a minute and describe the entire setup please?

What is the clock source? Both type and speed?
What is the interface between the PIC and the PC?
How is hyperterm setup?

Then we'll get to the software...

BAJ

2005\05\02@080118 by olin_piclist

face picon face
Dave Turner wrote:
> Second, the config is all saved in the mplab project.  In the
> configure menu, and the config bits part.

Bad idea.  The config bits are part of the code since it won't run right
without the right config settings.  Imagine coming back to this project a
year later and wondering what the config settings need to be to make it
work.  It's also very useful to have everything that needs to be programmed
into the processor in the HEX file.

> I setup my own custom names for some of the SFRs, because at the time,
> my resorce only showed me the addresses for the SFRs, not the actual
> names.

Another bad idea.  Use the Microchip include files.  That's what they are
for.  If you don't like their SFR names, get over it and use them anyway.
You're not going to get much help here or anywhere else while without
including the Microchip files or using non-standard SFR names.  Think of
them as a standard that you have to adhere to in order to get support,
because that's pretty much the way it works.


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

2005\05\02@080809 by olin_piclist

face picon face
Dave Turner wrote:
> Sorry.  I learned to do it that way, and don't have a clue how to do
> it in the source.

Use the __CONFIG directive.  Not the two underscores.  This directive and
all the others are described in the MPASM, MPLIB, and MPLINK manual.

> Well, what I meant is that my own custom include file, does actually
> include the MPLAB include file, so it does end up in the final file.
> My include file adds friendlier names, like LED1, LED2, etc.  which I
> find makes code clearer (well, for me anyway)

That's fine.  Giving your own project-specific names to I/O pins is a good
idea.  I've taken this a step further in my PREPIC preprocessor with the
/INBIT and /OUTBIT commands.  PREPIC is part of my PIC development
environment, which is described at http://www.embedinc.com/pic.


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

2005\05\02@080824 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> > But if so, why do you have lines like these in your source : ????
> >
> > > rcsta equ     18h
> > > txreg equ     19h
> > > txsta equ     98h     ; my own definitions of some key
> USART locations
> > > spbrg equ     99h
> >
> > They are already defined in P16F87.INC.
> > Don't you get any warnings about "multiply defined symbols"
> > Have you disabled "case sensitivity" in MPALB. Recomended, IMHO...
>
> I always have case sensetivity on...

Why ?
Bad idea, if you ask me...

> I just discovered whilst reading the datasheet that intrc isn't
> actually the internal 8mhz osc, but an internal RC (well, duh, but I
> didn't notice)...

Some older PICs had a internal low prec RC osc. Some newer PICs
have a higher prec internal RC osc. Some PIC call the new
internal osc INTRC, some other INTOSC. Confusing ? Yes.

In the case of the 16F87, it's called INTRC.

> Does anyone know which config option to use for the
> internal 8MHz osc?  (any __config source code versions are also
> welcome)


Directly from P16F87.INC :

_INTRC_CLKOUT                EQU     H'3FFD'
_INTRC_IO                        EQU     H'3FFC'


Also read :
"18.3 DC Characteristics: Internal RC Accuracy"
in the data sheet !

Jan-Erik.



2005\05\02@081929 by olin_piclist

face picon face
Dave Turner wrote:
> I just discovered whilst reading the datasheet that intrc isn't
> actually the internal 8mhz osc, but an internal RC (well, duh, but I
> didn't notice).

They are the same thing.  The internal 8MHz oscillator is implemented as an
R/C oscillator.  I sortof remember (this means it's your job to check) that
this PIC has one of the new "precision internal oscillators".  If so, it
should be good enough to talk to Hyperterm on a PC, but only if it's
calibrated.  Again, I don't have the data sheet here, but on many PICs the
calibration value is stored somewhere special and your program has to fetch
it and write it to OSCCAL.  This may not apply to you.  In any case, read
the data sheet section on the internal oscillator carefully (actually, read
the whole thing carefully).


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

2005\05\02@082029 by Dave Turner

picon face
umm.. I am using the microchip include file for everything except the
labels defined in the code, and they are the same as the microchip
ones, except lower-case.  It looks like I didn't include the microchip
include file, because I included my own include file, which in turn
includes the microchip file.  So the microchip file is included, just
not directly.  My include file is just a load of stuff like:

#define   LED1   porta

(or something like that)

I have attached a copy if you don't believe me.

So, is INTRC actually an osc, or an RC??

If i use the config setup posted above, what speed will I then be
using?  And which crystal?  INTRC or INTOSC?

On 5/2/05, Olin Lathrop <olin_piclistspamspam_OUTembedinc.com> wrote:
{Quote hidden}

> -

2005\05\02@082758 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> Second, the config is all saved in the mplab project.  In the configure
>> menu, and the config bits part.  I prefer to use this than specify it
>> in the code, because it's much clearer.
>
> Bad idea IMHO, the source should specify everthing. But if you want it
> this way you should include the project file(s) to we can check.

Another reason (of the many) why this might be a bad idea is: Are you
really sure it is saved in the MPLAB _project_ file? MPLAB uses project
files and workspace files (and its global configuration), and it's not
really very obvious which configuration item gets stored where. It would
make sense to store the processor configuration bits in the project file,
but then, it would make sense to store the processor type in the project
file, too -- but that one is stored in the workspace file, and the
workspace file is binary, so it's not really easy to find out what's in
there.

So, unless you are intimately familiar with the way MPLAB works, you may
not want to rely on guesses where what gets stored. Besides, it's such a
good feeling to load a project from years ago and it just works, without
having to fiddle with the MPLAB configurations, and without having to try
to find out how that had to be set for this project to work... :)

Gerhard

2005\05\02@083015 by Dave Turner

picon face
Okays, osc in config bits is now set to INTRC,
put 51 in spbrg (8MHz, high speed, internalRC,9600 baud)

and when I fire up hyperterm and start the program, nothing happens.
At all.  Hyperterm stays blank.

On 5/2/05, Olin Lathrop <@spam@olin_piclistKILLspamspamembedinc.com> wrote:
{Quote hidden}

> -

2005\05\02@083035 by olin_piclist

face picon face
Byron A Jeff wrote:
>> I doubt it. Check the datasheet, if it promises 1% accuracy it is OK.
>> But it will be much batter than an external RC oscillator.
>
> Not a chance.
> You simply can't do reliable serial at any resonable bit rate using RC.

Why do you say that?  1% is 1% regardless of how it's derived, and 1% is
sufficient for reliable communcation with a PC.


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

2005\05\02@083344 by olin_piclist

face picon face
Olin Lathrop wrote:
> Use the __CONFIG directive.  Not the two underscores.

Oops.  I meant to type "NOTE the two underscores".

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

2005\05\02@083743 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> umm.. I am using the microchip include file for everything except the
> labels defined in the code,...

"labels" ? What "labels " ?

> and they are the same as the microchip
> ones, except lower-case.

Ah, you mean the symbols (rxsta and so on).
Again, do *not* define them yourself.
Use the P16F87.INC file.

> My include file is just a load of stuff like:
>
> #define   LED1   porta

That is wrong (or at least doesn't work). "porta" is an 8-bit port.
One single led should just use a single *pin* on that port.
Something like :

> #define   LED1   porta, 1

> So, is INTRC actually an osc, or an RC??

It's an internal RC-osc.

> If i use the config setup posted above, what speed will I then be
> using?

I'm not sure that "above" refers to.
If using the INTRC, it depends on other settings, see the
data sheet.

>  And which crystal?

Are you using a crystal ??

>  INTRC or INTOSC?

On *this* PIC, INTRC.
Some other PICs calles he same osc INTOSC...


Jan-Erik.



2005\05\02@084126 by Dave Turner

picon face
Hi again

On a whim, I decided to add some stuff into the program to turn an led
on and off whenever the program loops.  The LED takes about 30 secs to
toggle, when before it took about half a second.  Shouldn't it be a
lot faster, because now I'm (supposedly) using an 8mhz internal osc,
instead of the external 3MHz osc?



On 5/2/05, Olin Lathrop <KILLspamolin_piclistKILLspamspamembedinc.com> wrote:
{Quote hidden}

> -

2005\05\02@084351 by olin_piclist

face picon face
Dave Turner wrote:
> I am using the microchip include file for everything except the
> labels defined in the code, and they are the same as the microchip
> ones, except lower-case.

I think you are asking for a lot of hassles by doing that.  You're going to
have a lot of trouble keeping your include files up to date with the
Microchip ones.  At the very least, use their symbols to define your lower
case symbols instead of entering the number directly:

fsr equ FSR ;work around relgious aversion to case-insensitivity

I always run MPASM with case sensitivity disabled.

> So, is INTRC actually an osc, or an RC??

INTRC refers to the internal R/C oscillator.  What do you envision "RC"
being if it's not an oscillator?


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

2005\05\02@084946 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> Okays, osc in config bits is now set to INTRC,
> put 51 in spbrg (8MHz, high speed, internalRC,9600 baud)

Note that *some* changes in the configuration need to have
a power off/on to take effect.

> On a whim, I decided to add some stuff into the program to turn an led
> on and off whenever the program loops.  The LED takes about 30 secs to
> toggle, when before it took about half a second.  Shouldn't it be a
> lot faster, because now I'm (supposedly) using an 8mhz internal osc,
> instead of the external 3MHz osc?

Have you setup OSCCON correctly ?
I think that 31.25 Khz is the POR (power on) default.

Jan-Erik.



2005\05\02@085052 by olin_piclist

face picon face
Dave Turner wrote:
> On a whim, I decided to add some stuff into the program to turn an led
> on and off whenever the program loops.  The LED takes about 30 secs to
> toggle, when before it took about half a second.  Shouldn't it be a
> lot faster, because now I'm (supposedly) using an 8mhz internal osc,
> instead of the external 3MHz osc?

If that was the only change, yes.  However this proves that it wasn't the
only change or that something else is seriously different from the way you
think it is.

How about starting from scratch with a new project?  Disable case
insensitivity, use the Microchip include file, and don't define any of your
own SFR and bit name symbols.  Write code with a known number of cycles in a
delay loop and use that to blink an LED.  Proceed to the next project only
after the LED blinks at the expected rate.


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

2005\05\02@085140 by Russell McMahon

face
flavicon
face
> On Mon, May 02, 2005 at 12:56:31PM +0100, Dave Turner wrote:
>> Okays, well I would do this, except whatever I try to send, the
>> computer only recieves lots and lots of ones, which it decodes as
>> 03h
>> (111), and FF (11111111).  I think there's probably some other
>> problem
>> than the baud rate.

> Can you take a minute and describe the entire setup please?
>
> What is the clock source? Both type and speed?
> What is the interface between the PIC and the PC?
> How is hyperterm setup?
>
> Then we'll get to the software...

What he says.
But can you also tell us how you are determining that it is sending
all 1's or whatever?
Have you got an oscilloscope? and
Are you using it to look at the output? and
What do you see.

Also.

Are you sending single bytes, or strings terminated in CR + LF or ...
?


The more we know about what you are REALLY doing and REALLY seeing the
better we are liable to be able to help.
My questions tend to be following a slightly different track to those
relating to software settings.
Knowing the basics of your system is UTTERLY ESSENTIAL to getting
consistent results, so the software setting line of questioning takes
precedence to mine of you are after full understanding. My line of
questions may help you get going faster (maybe not) but then you'll
still have to go back and find out why it worked.

IF you have an oscilloscope you can work out clock speed either by
measuring clock output or by toggling a pin low/high/low and then
working out how low the toggle should take at a given clock speed.
But, working it all out properly is even better.

If you have a crystal or resonator available that could easily be used
to control the clock, now may be a good time to use it. You can always
go back to RC with all its joys once you get things going.

Always remember - this is fun you are having :-) !



       RM

2005\05\02@090023 by Jan-Erik Soderholm

face picon face
Russell McMahon wrote :

> My questions tend to be following a slightly different track to those
> relating to software settings.

Nothing wrong there.

But since Dave wrote :
"I am running the PIC on a PICDem 4
board, which included a "RS232 level shifting IC"."

I, at least, thought that the hardware was pretty given.
And since I don't know anything about the PICDem 4, I saw
no reason to comment on that.

Jan-Erik.



2005\05\02@090735 by Dave Turner

picon face
Ughh....  Now I'm even more confused.  I just changed my delay
function to be about 1 second with the external osc.  I change the
config bit to internal osc.  and it doesn't change anything.  It's
identical.  I am just retransmitting the byte 65 over and over again.
It isn't even sending lots of ones anymore.  One thing I have noticed
is that the curser in hyperterm seems to be flashing in sync with each
time it tries to send 65.  Also, occasionally, about 1 in 3 loops, the
curser flickers a bit.  It used to be sending all ones - I checked by
capturing text from hyperterminal, and opening it in a binary file
viewer.  But now it doesn't seem to be sending anything.

I can't check the actual clock speed - I'm just hoping it is what it
says it should be.  I haven't got any kind of scope.

On 5/2/05, Jan-Erik Soderholm <RemoveMEjan-erik.soderholmTakeThisOuTspamtelia.com> wrote:
{Quote hidden}

> -

2005\05\02@091505 by Jan-Erik Soderholm

face picon face
As othes have said, time to step back.
Make a LED blink at a known speed to verify
your osc settings. Then go forward to the uart code.
With the lack of tools (o-scope), it's har to do in
any other way.

Jan-Erik.



2005\05\02@100555 by Dave Turner

picon face
I have set the osc to INTRC-CLKOUT, which should be about 8MHz, but
with the MPLAB SIM, I have to set the processor speed to about 20Khz
to get near to the speed I'm using.  Am I setting up the clock
incorrectly?  All I changed was the __CONFIG.  Is there another place
to change the clock speed?

On 5/2/05, Jan-Erik Soderholm <spamBeGonejan-erik.soderholmspamBeGonespamtelia.com> wrote:
> As othes have said, time to step back.
> Make a LED blink at a known speed to verify
> your osc settings. Then go forward to the uart code.
> With the lack of tools (o-scope), it's har to do in
> any other way.
>
> Jan-Erik.
>
> -

2005\05\02@101439 by Byron A Jeff

face picon face
On Mon, May 02, 2005 at 08:30:45AM -0400, Olin Lathrop wrote:
> Byron A Jeff wrote:
> >>I doubt it. Check the datasheet, if it promises 1% accuracy it is OK.
> >>But it will be much batter than an external RC oscillator.
> >
> >Not a chance.
> >You simply can't do reliable serial at any resonable bit rate using RC.
>
> Why do you say that?  1% is 1% regardless of how it's derived, and 1% is
> sufficient for reliable communcation with a PC.

Because it isn't 1%. From the 16F88 datasheet it promise 2% at room temp (25C)
which is fine. However in the range of -10C to 85C it falls to 5% which is
outside the spec.

BAJ

2005\05\02@110705 by John J. McDonough

flavicon
face
Jan-Erik is on to something here.  Serial communications is easy once you
get it working, but getting it working can sometimes be tricky, and without
a scope it's tricky and you are blind.

Step 1 - Like J-E says, make a LED blink at a rate you can explain.

Step 2 - Set up your serial port for 300 baud, and send a 00 once every 10
seconds.  You should be able to see this with an analog meter or LED and
stay convinced that the timing is what you think it is (although you still
aren't confident of the baud rate).

Step 3 - Send 300 - 00's in rapid succession at 300 baud, then wait a long
time (20-30 seconds) before doing it again, one start bit, one stop bit.
The output line should go low for about 10 seconds each time, long enough
for you to measure with a LED or analog meter.  (10 bits per character, 3000
bits=10 seconds, OK, OK, one of the 10 bits will be high, but probably you
won't see that without a scope).  This gives you some confidence you are in
the ball park for baud rate.  Change your 00's to AA's and the LED should be
about half brightness or the meter about half voltage.

Step 4 - Hook up Hyperterm at 300 baud and see if you can make anything
sensible happen.  If you have trouble, then either your Hyperterm settings
are wrong, you have a problem in the cable, or the timing is off.  But at
least now you know it can only be a little off.

Step 5 - Now move to 9600

--McD

{Original Message removed}

2005\05\02@111148 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> I have set the osc to INTRC-CLKOUT, which should be about 8MHz, but
> with the MPLAB SIM, I have to set the processor speed to about 20Khz
> to get near to the speed I'm using.  Am I setting up the clock
> incorrectly?  All I changed was the __CONFIG.  Is there another place
> to change the clock speed?

And you don't think that the fact that "about 20Khz" happens to be quite
close to 31.25 Khz would ring a bell ??

As I wrote in another post :

--  Have you setup OSCCON correctly ?
--  I think that 31.25 Khz is the POR (power on) default.

Try to set SIM to (something closer to) 31.25 and see if you
don't get the same time as you see in your hardware.

Then setup OSCCON correctly to get 8Mhz.

And yes, this actualy means that the PIC will be running
slowly *until* you set OSCCON in the code. By changing
OSCON you can "gear" the PIC up and down in 8 steps
between 8 Mhz and 31.25 Khz as you like.

Jan-Erik.



2005\05\02@114417 by Lindy Mayfield

flavicon
face
I don't know if I'm being helpful here, but I did manage to get just what Dave is trying to do working quite nicely on the Pic Dem 4.  Here is from the doc:


{Original Message removed}

2005\05\02@114521 by Lindy Mayfield

flavicon
face
(Sorry)

I don't know if I'm being helpful here, but I did manage to get just what Dave is trying to do working quite nicely on the Pic Dem 4.  Here is from the doc:

A.6 OSCILLATOR OPTIONS
* RC oscillator (2 MHz approximately) supplied. This oscillator may be disabled by
removing jumper J14.
* Pads provided for user furnished crystal/resonator and two capacitors (Y3).
* Socket provided for a canned oscillator (Y1).
* 32.768 kHz (watch type) crystal for Timer1 (Y2). This oscillator can be disabled by
removing jumpers J7 and J9.



{Original Message removed}

2005\05\02@115255 by ThePicMan

flavicon
face
At 17.11 2005.05.02 +0200, you wrote:
{Quote hidden}

Cool, now if they only added a Reverse Idler bit in OSCCON.. :D

(Reverse Idler = Backaxel på Svenska)


>
>Jan-Erik.
>
>

2005\05\02@122618 by Dave Turner

picon face
Woooowww yayyy

I finally found about OSCCON, and setup my osc - it's now using the
INTRC, running at 8MHz, which matches with the SIM

UPDATE: whilst fiddling, whilst typing this, I changed some stuff
around, and now it works!!!  It outputs about 1 character a second,
and sends "Hello World", and a newline.

Thanks so much for the help with this guys.  Now just need to make
this work with recieveing aswell.....


BTW, does anyone know how fast it can send letters, i.e. how many
processor cycles between sending letters?

On 5/2/05, ThePicMan <TakeThisOuTthepicmanEraseMEspamspam_OUTinfinito.it> wrote:
{Quote hidden}

>

2005\05\02@124851 by phil B

picon face

--- Dave Turner <RemoveMEdave.w.turnerspamTakeThisOuTgmail.com> wrote:
> Hi again
>
> On a whim, I decided to add some stuff into the
> program to turn an led
> on and off whenever the program loops.  The LED
> takes about 30 secs to
> toggle, when before it took about half a second.
> Shouldn't it be a
> lot faster, because now I'm (supposedly) using an
> 8mhz internal osc,
> instead of the external 3MHz osc?

You've gotten a fair amount of advice (most good...)
but I haven't seen one obvious newbie error mentioned.
Have you turned off the WDT?  My first PIC program
was "working" but had some odd behavior.  Sure enough,
the chip the WDTwas going off causing the PIC to
restart every couple of seconds. Don't know if this is
your problem but worth checking out.

Phil

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005\05\02@125347 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

> BTW, does anyone know how fast it can send letters, i.e. how many
> processor cycles between sending letters?

Just do the math...

9600 baud (= bit/second)

8 bit data, 1 start bit, 2 stop bits = 11 bits.

9600 / 11 = (aprox) 870 char/sec.
(A little more if using 1 stop bit...)

8 Mhz = 2.000.000 cycles/second.
2.000.000 / 870 = (aprox) 23.000 cycles / character.

And guess what ?
This works, not only with letters, but any 8-bit character !! :-)

Jan-Erik.



2005\05\02@131146 by olin_piclist

face picon face
Dave Turner wrote:
> I have set the osc to INTRC-CLKOUT, which should be about 8MHz, but
> with the MPLAB SIM, I have to set the processor speed to about 20Khz
> to get near to the speed I'm using.

Huh?  I don't have a clue what you are doing or trying to say here.  If the
internal oscillator is running at 8MHz, then how is 20KHz nearer to the
speed you are using?

You should tell the simulator the correct clock speed.  It doesn't effect
performance one way or the other, but it does allow the stopwatch display to
be correct.  That's a useful way to check your blinking LED code to make
sure it is blinking at the expected speed.


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

2005\05\02@132148 by Dave Turner

picon face
hey thanks

Yes, I made certain I turned the wdt off - It's the first thing I do
with every program

On 5/2/05, Jan-Erik Soderholm <jan-erik.soderholmEraseMEspam.....telia.com> wrote:
{Quote hidden}

> -

2005\05\02@132547 by Dave Turner

picon face
I thought the internal clock was 8MHz, but I wasn't sure.  I changed
the sim setting around until it seemed to blink at the same speed as
on the chip, to check what speed it was running at.  It turned out to
be running at 31.25KHz, quite near to 20Hz.

I now fixed this - I didn't know to change OSCCON

all working now

On 5/2/05, Olin Lathrop <EraseMEolin_piclistspamembedinc.com> wrote:
{Quote hidden}

> -

2005\05\02@133221 by olin_piclist

face picon face
Dave Turner wrote:
> BTW, does anyone know how fast it can send letters, i.e. how many
> processor cycles between sending letters?

You can figure this out yourself.  Assuming you are using "normal" protocol,
there is a start bit, 8 data bits, and a stop bit per byte sent.  That makes
a total of 10 bits.  At 9600 baud you can transmit 960 bytes/second at
maximum rate.  At 8MHz oscillator you get 2MHz instruction rate.  (2M
cycles/sec) / (bytes/sec) = 2083 instructions per byte.


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

2005\05\02@142500 by Russell McMahon

face
flavicon
face
>> I have set the osc to INTRC-CLKOUT, which should be about 8MHz, but
>> with the MPLAB SIM, I have to set the processor speed to about
>> 20Khz
>> to get near to the speed I'm using.

> Huh?  I don't have a clue what you are doing or trying to say here.
> If the
> internal oscillator is running at 8MHz, then how is 20KHz nearer to
> the
> speed you are using?

> You should tell the simulator the correct clock speed.  It doesn't
> effect
> performance one way or the other, but it does allow the stopwatch
> display to
> be correct.  That's a useful way to check your blinking LED code to
> make
> sure it is blinking at the expected speed.

What he means is that for the stopwatch to match what he sees in real
time he needs to set the simulator to about 20 KHz. This points to his
clock actually being about 20 KHz - in fact it was 32 kHz because he
failed to ever transition from the startup mode to the internal 8MHz
RC mode.


       RM

2005\05\02@160034 by Dave Turner

picon face
Yep, exactly

On 5/2/05, Russell McMahon <RemoveMEapptechEraseMEspamEraseMEparadise.net.nz> wrote:
{Quote hidden}

> -

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