USART strange results

[ciseco]

Hi,

I'm just starting with SF so I've probably missed something really obvious. This is the 2nd thing after a sucessful blinky. I've just tried the byte in/byte out echo routine and I get a somewhat strange outcome. If I type the alphabet I get this echo'd back

abcdefghijklmnopqrstuvwxyz (I type these individually)
}zdefglmjklmnoxyz{tuvw|yz (these are the corresponding bytes echo'd back)

Here's the code

Code: Select all

Device = 18f25k22
Clock=64

Include "usart.bas"

SetBaudrate(br9600)
High (PORTB.6)
While true
   WriteByte(ReadByte)
Wend

Any ideas what I've missed?

Regards

Miles

[ciseco]

Getting closer still no cigar.

I did some searching on other forums and tried adding

ANSELC = 0

This has to a degree improved things but not cured them, from what was consistently wrong I now sometimes get the right byte echoed back and sometimes not.

so I thought I'd examine the data sheet in more detail and then added

TRISC.7 = 1
TRISC.6 = 0

Still lots of gibberish, so next I commented main code out out and did this

loophere:
USART.Write("Hello World")
delayms (500)
goto loophere

Result :{?r?l{?r?h{?r?l{?r?l{?r?h?r?l{?r?l{?r?l{?r?l{?r?l{?r?h{?v?h?r?h?v?h{?r?l{?r?h{?r?l{?r?h{?r?h{?r?h?v?h{?r?h{?r?l{?r?h{?v?h{?v?h?v?h{?v?h?v?h?r?h?v?h{?r?h?r?h{?r?h{?r?l{?r?l{?r?h{?r?h?v?h?v?

So issue 1 is sending, I'll tinker till this works then see if recieve is ok, if not tinker some more

Miles

[ciseco]

Getting somewhere quicker now, baudrate in code is set to 9600 but it is coming out at 38400 perfectly, so there's I suspect something I've misssed about the 4xPLL and setting the compiler to know what I'm doing.

[CharlieM]

What is your actual clock speed?

[ciseco]

Hi,

Thanks for the reply, it's a 16mhz xtal

Regards

Miles

[ciseco]

This is where I'm at, at the moment. I tried changing the baudrate but nothing happened, so I moved the line to before the ansel stuff and it decided to take notice. I thought I could frig it and set br2400 and what would come out was 9600, not quite, 4800 did come out as 19.2. I've tried FOSC in both modes makes no difference. I'd like to run at 64mhz but 16 and working would be almost as good.

Code: Select all

Device = 18f25k22       
Clock=16         
'Config FOSC = HSHP     
'Config FOSC = HSMP    

Include "usart.bas"
SetBaudrate(br9600)
ANSELC = 0
TRISC.7 = 1 
trisc.6 = 0
TRISA.4 = 0 
ANSELA.4 = 1 
TRISC.3 = 0 
ANSELC.3 = 1 
TRISC.4 = 1 
ANSELC.4 = 0 
TRISC.5 = 0 
ANSELC.5 = 1 
    
'High (PORTB.6)
'DelayMS (10)

While true           
   WriteByte(ReadByte)
Wend
   

[Jerry Messina]

Keep in mind that the "clock = " statement doesn't actually setup anything hardware-wise... it's purely so the compiler can know what speed you're running at so it can adjust software delays, timers, etc. It should be set to whatever freq you're actually running at, so if using the 4xPLL it'd be 64, not 16. You have to setup the CONFIG and OSCONx/OSCTUNE registers yourself, however, to actually get the chip running.

For the usart, you'll probably want to enable the 16-bit BRG (which is off by default).
Try

Code: Select all

#option USART_BRGH = true   
#option USART_BRG16 = true
include "usart.bas"

to get both the high-speed divisor and 16-bit BRG enabled

[ciseco]

Hi JM,

I'd started at 64 and gone back many times between 16 & 64 as it (16) was the only initial combination that I could get to work but had to run terminal at 4x

If I set 32 it was happy at 19200, setting 64 should in my mind have brought me to a proper 9600, but every time it was screwy, I'd started to wonder if I put in 63.9 or 64.1 I'd get any nearer (if you can even do such a thing)

Adding the two lines suggested as sorted it immediatly. Would I be right in thinking is was just a bit of maths that was out and enabling the 16-bit BRG makes it more accurate?

Many many thanks

Miles

[ciseco]

Yipee, now my wireless comms work. I might be able to remove some of the ansel lines, but here's what works at the moment. JM, a big thank you.

Miles

Code: Select all

'P0 - RC1/T1OSI/CCP2                15 - NOT CONNECTED
'P1 - RC2/CCP1/P1A                  14 - GND
'RST                                13 - RC3/SCK/SCL
'3V3                                12 - RC4/SDI/SDA
'5V                                 11 - RC5/SDO
'GND                                10 - RA5/AN4/SS/HLVDIN/C2OUT
'GND                                09 - RB7/KBI3/PGD
'VIN                                08 - RB6//KBI2/PGC -XRF/XBEE powerup
'
'A0 - RA0/AN0/C12IN0-               07 - RB5/KBI1/PGM
'A1 - RA1/AN1/C12IN1-               06 - RB4/KBI0/AN11/P1D
'A2 - RA2/AN2/VREF-/CVREF/C2IN+     05 - RB3/AN9/C12IN2-/CCP2
'A3 - RA3/AN3/VREF+/C1IN+           04 - RB2/INT2/AN8/P1B
'A4 - RA4/T0CKI/C1OUT               03 - RB1/INT1/AN10/C12IN3-/P1C
'A5 - RC0/T1OSO/T13CKI              02 - RB0/INT0/FLT0/AN12
'                                   01 - RC6/TX/CK
'                                   00 - RC7/RX/DT



Device = 18f25k22 
Clock=64     
#option USART_BRGH = true    
#option USART_BRG16 = true 

Include "usart.bas"
SetBaudrate(br9600)
ANSELC = 0
TRISC.7 = 1 
TRISC.6 = 0
TRISA.4 = 0 
ANSELA.4 = 1 
TRISC.3 = 0 
ANSELC.3 = 1 
TRISC.4 = 1 
ANSELC.4 = 0 
TRISC.5 = 0 
ANSELC.5 = 1 
    
High (PORTB.6)                   'turn on xino xrf powerup
DelayMS (2)                      'wait a while for xrf to settle
usart.write("started")           'send something
While true           
   WriteByte(ReadByte)           'echo back
Wend
   

[Jerry Messina]

The 16-bit BRG usually lets you get a lot more accurate baudrate. In some cases, it's not really an option because the combination of cpu clock and desired rate exceeds what the 8-bit one can do.

Usually, setting both those options gives the best result.

Glad you're up and running!

Jerry