Clock is 4 times faster

[SpoonBilly]

I am using PCWHD version 4.134 and MPLAB ICD3. What puzzles me is that the clock seems to work 4 times faster. Let say if I am using baudrate 9600, I can only receive what I want at the computer at baudrate 38400 (4 x 9600). The following code should work at 23.5Hz, but it works at 94Hz (as if the crystal is 80MHz, 4 x 20MHz). What went wrong? help please~

[Ttelmah]

This is down to a new chip architecture, and will probably take CCS a while to catch up with....
If (for example), you look at the clock sources for the timer1 module (fig 21-1), you will see that the module can be clocked internally from 'Fosc', or from 'Fosc/4'. This differs from all the traditional PIC's, where the peripherals always run from Fosc/4. Similarly with the UART, the master clock feeding into the BRG (Figure 26-1), is Fosc, rather than Fosc/4.....
The CPU itself still performs instructions at the Fosc/4 rate, but all the peripheral stuff will clock at 4* the expected rate.....

Best Wishes

[SpoonBilly]

and I can't use delay_us(). Is this a related issue?

[asmboy]

From hard experience I can attest that extended compiler,
high level function support is still quite weak for 16F15xx, 16f19xx and 16f18xx parts.

Be prepared to do some patching as you go.....

The issues you list can be solved with a bit of creative programming.
an alternative is to just use an older part if you can.

[SpoonBilly]

I can live with the faster clock, but what can I do to replace delay_us()?

[Ttelmah]

Depends what delays you want.

I must admit, I can't find a single one of my programs, that uses 'delay_us'....

For short delays, use 'delay_cycles'. For longer delays, have a timer 'tick' interrupt, and run a countdown clock in this.
The delay problem, applies to quite a few chips, and if I remember correctly, does work OK, with shorter delays.

Best Wishes

[asmboy]

for your two cited issues

[nailuy]