M52233demo board + interniche

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

M52233demo board + interniche

3,178 Views
m52233demuser
Contributor I
Hi,
 
How do I send data to uart#1?  I know #0 is the console port, and it works fine.  But, when I send a byte to uart#1, say,  by doing  
 
uart_putc(1,'A');
 
 
 to send an 'A', the system seems to lock up, that is,  no console port reponse any more.  What am I doing wrong?  please help.
 
Thanks.
 
stuck
Labels (1)
0 Kudos
5 Replies

467 Views
Kremer
Contributor I
Did you initialized the uart1?
If yes, a code snippet may point something more specific.
 
 
0 Kudos

467 Views
m52233demuser
Contributor I
Hi Kremer,
 
Thanks for the response.  Yes.  I think init happens to uart0 & uart1 upon power up.  What is funny is that as long as there is no acitvity on uart0, I can do;
 
uart_putc(1,'A');
 
all I want and it won't lock up.  But, it seems to lock when there are activities on both uart0 and uart1.  Somethimes, it works for a while before the lock.
 
I would do something like;
 
printf("Test line......\n");
uart_putc(1,'A');
 
And I can see a few (maybe 5 - 10 lines) of Test line....on my HyperTerminal connected to uart0 before the program locks.
 
I keep checking, but, if you have more suggestions, I would appreciate it.
 
 
StillStuck
0 Kudos

467 Views
Kremer
Contributor I
 Are you using the Coldfire_Lite example or did you develop your own?
 Maybe printf is messing things up.
 
 Try this instead of using printf:
 
 static char test_string[15];
 unsigned short i;
 
 strcpy(test_string,"Test Uart0\n");
 for(i=0;i<strlen(test_string);i++)
  uart_putc(0,test_string[i];
 uart_putc(1,'A');
 
 If this works without lock, then printf is the villain.


Message Edited by Kremer on 2007-06-26 05:35 PM
0 Kudos

467 Views
m52233demuser
Contributor I
I am using Coldfire_Lite as is.  I tried your suggestion, but, it seems that the result is the same.
 
What I do see while I am floundering around the ColdFire_Lite codes is that it seems uart ports are interrupt driven and both ports 0 and 1 are calling the same service routine uart_isr().  I was wondering if ports are stepping on each other while being serviced by the interrupt routine.  So, what I tried is to put some forced time delay between using port0 and port1, and it seems to work much better.
 
I think, I need to disable one port interrupt before using the other.  Does it sound reasonable?
 
Thank you for your interest.
 
 
 
0 Kudos

467 Views
Kremer
Contributor I
 This Coldfire_Lite example isn´t a perfect serial example. On iuart.c, as you saw, they share the same isr for RX and TX, so when you print a string on uart 0 and try to print on the second the problem can happen. Adding a delay as you did can help on printing short strings on fast serial speed, but it will reduce the system perfomance and can´t be enough for long strings. Also, take a look on those uarts interrupt priorities and levels (on uart_init routine). You can set them up to avoid those crashings you mentioned.
 But, there´s nothing like build your own application.
0 Kudos