Jump to content

Recommended Posts

Having trouble with the UART Recieve program included with the SourceBoost IDE. It pretty much doesn't work.

 

The putc() or puts() functions dont seem to work, even when i call them directly from main() or from the interrupt service routine. I also tried to get an LED to blink whenever it enters the ISR but it seems like the interrupt is in-operative. This is pretty basic code here, could something be wrong with my EZ-Controller Turbo?

 

EDIT: Ok, i've figured this out quite by accident - it appears to be a baud rate issue. Long story short, i've got a USB adapter configured at 19200 baud and the only way i can get it to work is with the PIC set at 9600 baud (Fosc = 20MHz, BRGH = 1, SYNC = 0 so SPBRG = 129 decimal).

Edited by toolrocket

Share this post


Link to post
Share on other sites

Does anybody have any insight as to why these bauds arent matching up (see above)? Also, has anybody been able to get the Auto Baud Rate detection feature working?

Share this post


Link to post
Share on other sites

(bump) Can anyone explain this baud discrepancy? The getc() function is still in-op also, presumably due to bad baud rate.

Share this post


Link to post
Share on other sites

Slowly figuring this out -- I always feel a little foolish after posting problems which are mostly due to my ignorance, but i'm getting better. I've figured out the baud rate thing (it actually works perfectly, i misinterpreted my BRGH and BRGH16 bits and was looking on the wrong page of the datasheet for the SPBRG setting).

 

In any case here's my interrupt service routine for interrupts caused by the UART RxFlag (pir1).

void interrupt( void )						 // Called function on interrupts
{	
if( ( pir1&0x20 ) == 0x20 )		  // If Rxflag = 1 then ----->
{
	puts("You pressed ");  // Send the string "You pressed "
	putc( getc() );			// Call getc function then put the character pressed
	putc(0x0d);	// Carriage Return
	putc(0x0a);	// Line Feed
}
}

 

The PIC will correctly return the "You pressed " string to my Visual Basic terminal window but it wont add the actual character i pressed. This is stock C code from the sample supplied with the SourceBoost installation, so presumably it works properly, and the error is my fault.

 

The only hypothesis i can come up with is in the transmitting sequence i wrote in VB. I use an FTDI usb/serial module and the associated API calls that it came with. The datatype of the transmitted characters is a VisualBasic string, so i'm thinking perhaps VB is trying to 'help' me by converting to something other than ASCII and the PIC winds up recieving something it cant understand so it returns a null instead of the character i pressed. Does this make sense? or can somebody elucidate on what maybe going on here? Thanks in advance.

Share this post


Link to post
Share on other sites

More information about my problem with the getc() function. I seem to be getting a Recieve error.

 

char getc(void)	  // Getc function loop until a character is pressed
{
latb = 0x00;	 // Turn off LED
while( ( pir1&0x20 ) != 0x20 ); // Loop until Rxflag = 1

if(rcsta.4 == 1)	// If Error flag CREN is set...
{
 latb = 0xFF;	// Turn on LED, indicates error
}
return rcreg;	 // Return rcreg
}

 

The CREN bit is set in rcsta indicates an Rx failure, and i turn on an LED to verify that. What could cause a Recieve error? I'm respectfully requesting some input on this, please advise (read: I'm desperate )

Share this post


Link to post
Share on other sites

CREN is not an error bit but a Continuous Recieve Enable bit set or cleared by software.

 

CREN should be set if you intend to receive serial data.

 

FERR and OERR are error bits.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Reynard: Thanks for the reply, and right you are. I was incorrect about the CREN bit, i misread the datasheet.

 

So, I've rigged the code to turn on an LED when OERR or FERR is set, and i get the FERR every time. The datasheet says to reset the CREN bit, so i do that but continue to get Framing Errors. The datasheet says to play around with the OSCTUNE register because framing errors are caused by too high of a clock freq. So i tuned down the oscillator but still no luck. Any suggestions welcome.

Share this post


Link to post
Share on other sites

You say you are using an EZ Controller Turbo running at 20MHz. Looking at the schematic it only has a 10MHz crystal so it can only run at 10MHz or 40MHz using the 4x PLL.

 

Check your chip silicon version number. A good programmer should tell you this if it is not printed on the package. The 18F2520 has a bug list as long as your arm. Read all the errata sheets, they make scary reading.

 

Your boot loader is obviously working if you can download your program so the UART must be working correctly.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Mr. Reynard-

 

I originally got the 20MHz from the regular EZ controller fact sheet- another stupid mistake on my part. That was originally the cause of all my troubles, and the reason I came here for help. I downloaded the correct datasheet (EZ turbo) which says 40MHz.

 

I'll try fooling around with the spbrg values for both 10 and 40 Mhz when i get home tonight. I did not realize however, that there was a configuration register associated with the internal clock. The PIC datasheet says that in order to get 40 Mhz working, i'd have to change the CONFIG1H register - since the EZ Turbo datasheet advertises 40Mhz clock, is this already done? Hopefully it is, because writing to those flash memory tables looks like it's over my head. If that's the case, i'll just settle for the 10MHz internal clock. My (bad) assumption is that it's already set up for 40MHz because those are the spbrg values in the datasheet table that seem to work.

 

Lastly, i read bits and pieces of the erratas - i seem to recall a lot of problems with the auto-baud rate detect and some other stuff. I figured since i'm only trying to do basic UART stuff i should be in the clear - also like you said, the bootloader works so the uart must work. Please pardon my ignorance with a lot of this, i'm a novice. If i cant get this working, i may have to try something a little easier.

Share this post


Link to post
Share on other sites

allcon-

I've got my UART working, it turns out i had to change a jumper on my PIC module. However, when i Tx a character down the line, the Uart replies with a different character. For example, i send a lower case 'a' and get back an upper case 'O'. The characters are the same every time, as per the table below, so at least it's something consistent. I mapped out the character codes for each tx/rx pair but can't find any recognizable pattern. Suggestions welcome.

 

 

Tx Rx

a O

b '

c N

d

e M

f &

g L

h "

i K

j %

k J

l

m I

n $

o H

p

q G

r #

s F

t

u E

w D

x

y C

z !

A _

B /

C ^

D

E ]

F .

G \

I [

J -

K Z

L

M Y

N ,

O X

P

Q W

R +

S V

T

U U

V *

W T

Y S

Z )

1 g

2 3

3 f

4

5 e

6 2

7 d

8

9 c

0

- i

= a

! o

@

# n

$

% m

^ (

& 6

* 5

) k

_ P

+ j

) k

Share this post


Link to post
Share on other sites
allcon-

I've got my UART working, it turns out i had to change a jumper on my PIC module. However, when i Tx a character down the line, the Uart replies with a different character. For example, i send a lower case 'a' and get back an upper case 'O'. The characters are the same every time, as per the table below, so at least it's something consistent. I mapped out the character codes for each tx/rx pair but can't find any recognizable pattern. Suggestions welcome.

Tx/Rx Lines inverted.

Take ascii value of 'a' (97), invert all the bits, ignore the first (lsb) bit because its gobbled up as a start bit and you get 79 (the ascii code of '0').

 

Same applies to 'b', except this time we ignore the first two bits before we see what looks like a start bit.

 

Nice Question - made me think for a couple of minutes ;-)

 

Regards

Dave

Share this post


Link to post
Share on other sites

Do you have both links on the controller board set for RS232 ?

 

If you have one set for RS232 and the other set for TTL, you will get an invertion in one of the signals.

 

Also check BAUDCON is not set to invert RX data and you are not set for 9 bits.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Thanks Dave and thanks Reynard-

 

I cant seem to get my little Serial>USB module talking to the PIC module with the jumpers in any configuration other than TX2/3 and Rx5/6. i tired fooling with baudcon and changed bits 4 and 5 to invert the Tx and Rx, but that appears not to work in any combination. it seems like i've got to invert the Tx from my little usb/serial converter. Does that sound reasonable? it's got a setting i can change (if i can figure it out) but if i mess that up, could i use a hex inverter or something? thanks for all the input. I'll post a pic of my robot if i ever get it working...

 

Edit: I've tried inverting tx and rx with the baudcon register, and no luck.

Edited by toolrocket

Share this post


Link to post
Share on other sites

I am running out of ideas here dude.

 

The docs say RS232 should be TX1/2 and RX5/6. The UART registers should work with most bits in the default (reset) state.

 

The bootloader according to the docs does not use the UART. Must be bit-banging through port B bits 0 and 3.

 

Try using a PC with a real serial port and something like HyperTerminal. An oscilloscope would be helpful to see exactly what is going on down at pin level.

 

Good luck.

 

Reynard

Share this post


Link to post
Share on other sites

I just want you to know how much i appreciate all of your help. Especially when this is probably something trivial and i'm so thoroughly blowing it. I was so good at this in college with a Motorolla HC11 - I guess it WAS so easy in a controlled setting with all those teaching assistants, equipment and tools available.

 

It's curious how it only seems to work when the Tx block is configured inward (5V) and the Rx block outward (RS232). Works like a charm though (save the inversion), i'll just fiddle with it and do some bit shifting to get it turned around.

 

I program using the bootloader, and leave the programming cable connected to the little db9 programming terminal all the time. Think that might dork it up?

Share this post


Link to post
Share on other sites

Moderator, please close and delete this thread. I had the UART on my USB/Serial thinger configured for 3V. there's 2 weeks of embarrassment and wasted time i wish i had back. thanks again, for all the help.

Share this post


Link to post
Share on other sites

toolrocket,

Moderator, please close and delete this thread. I had the UART on my USB/Serial thinger configured for 3V. there's 2 weeks of embarrassment and wasted time i wish i had back. thanks again, for all the help.
We won't delete this thread, someone else may make the same mistake or a similar mistake and find the information useful ;-)

 

Regards

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...