UART and Hyperterminal

sandeepa said:

"BTW, why do you have memory write enabled?."

Click to expand...

No particular reason...it wont really cause any harm,will it?

Click to expand...

Not as far as I know?.

unless you have the default radix set as hexadecimal.

Click to expand...

Where is this setting done?I havent particularly done any such setting.Though I didnt get any error message regarding this.

Click to expand...

You can set it in various places, one is in the source code - see the MPASM helpfile, this will over ride any settings elsewhere. If it's not set in the source file it will use the default settings of the assembler, which you can set on radio buttons in MPASM.

Presumably MPLAB has access to the default radix settings as well?, but I never use it.

The help file does say the default base is hex and the implicit base integers take that base.

So would __config 3F7A be actually treated the same way as __config 0x3F7A?

I hope thast not the case because the program satarted functioning correctly afre I changed the config word.

sandeepa said:

Hello everyone

The configuration word had been accidently set to 3F7A instead of 0x3F7A!!! :shock:

Anyway,thanks a lot everyone esp. Pommie and Nigel Goodwin.
Thanks

Click to expand...

Glad you finally got it working.

The only way I can see that this could happen (3F7A instead of 0x3F7A!) and not give an error is if you turned error messages off. Is this what happened?

Mike.

I had set the errorlevel to 2,to display only the errors.
I checked again without any setting(and config 37fa),still didnt get any error messages.
Does MPLAB certainly flag off an error for such a thing?

Just a update,because things are I think now making some sense.
I tried the code that worked yesterday with __config 3F7A,i.e. without the 0x.
And it still worked....and I almost got spooked out.

So went back to my first post in the thread where I had posted my complete first piece of code.The config value set there is 3F79,which sets the oscillator to XT.(3F7A sets it to HS).Burned it on the chip(i.e. config set to 3F79),and things started behaving as before i.e. display after power switched off.Changed the setting to 3F7A and all was fine again.

So the mistake really was not,not specifying the base(which makes no difference),but setting the wrong oscillator bits.(I need to set it to HS as I am using 8MHz crystal).

JUst thought I should pt in the final update here.
Thanks.

sandeepa said:

So the mistake really was not,not specifying the base(which makes no difference),but setting the wrong oscillator bits.(I need to set it to HS as I am using 8MHz crystal).

Click to expand...

That's VERY interesting!. There's no actual transition point given for switching from XT to HS, but generally 4MHz is condidered XT and 20MHz as HS - with the change 'somewhere' in between.

Personally I've never found it to make any difference?, I've used either (by accident) with both 4MHz and 20MHz crystals - and all have always worked fine. Perhaps it's a characteristic of your particular crystal sample?.

I too have used the options interchangably,and its worked,even where I have used the hardware modules like SPI.But its certainly not working for this one,I have checked a few.
However,the datasheet does specify 8Mhz as HS,so I guess fair enough.
I got the crystal fom a local vendor,dont really know what type it is.