problem with labview

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi
in serial connection between avr and labview,when i write something in the string box its repeat on lcd.but its ok in codvision terminal.what should i have done?
tanks a lot.

#include 
#include   
#include 
#include 
#include 
char data,get;
interrupt [USART_TXC] void USART_TX_Complete(void)
{


}


interrupt [USART_RXC] void USART_RX_Complete(void)
{
  data=UDR;
   get=toascii(data); 
           if(get==8)
           {
           delay_ms(100);
           lcd_clear();
           }
           lcd_putchar(data);
}








// Declare your global variables here


void main(void)
{
DDRB=0;
UCSRA=0x00;
UCSRB=0x18; 
UCSRB=(1<<RXCIE)|(1<<TXCIE)|(1<<RXEN)|(1<<TXEN);
/*                               
UCSRC=0x86;
*/
UBRRH=0x00;
UBRRL=0x67;
 #asm("sei");
lcd_init(16);


PORTB=0b111;
  


 
lcd_gotoxy(0,0);
while (1)
      {       
            
         
           
         


      }
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely this is a support question for the Labview people? If one PC terminal (Codevision) works and one doesn't (LabView) then it's nothing to do with the AVR. It's the configuration of Labview isn't it?

(my guess is that you have not switched off hardware flow control in fact!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah its true
its said default value of flow control is none and i sets
that on none.but...
i connect with NI support.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your program 'design' is crap.

Let the CodeWizard write your interrupt-driven USART.

Then you can write to the LCD in your foreground loop:

     while (1) {
         if (rx_counter0 != 0) {  // available char
              c = getchar();      // fetch from buffer
              lcd_putchar(c);
         }
         ...
     }

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi David
thanks for your code but i think there is no problem with code(i dont use CodeWizard) .however could you tell me about your code specially "rx_counter0"
thanks a lot

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If God made a CodeWizard, surely it is wise to use it?

Bear in mind that it generates accurate code. Most examples of interrupt-driven USART on this site are appalling!

The "rx_counter" is the volatile variable that tells you how many bytes are available in the circular RX buffer.

e.g. if rx_counter == 0 then there is nothing to do.

Quote:
but i think there is no problem with code

where do you want me to start ?

Incidentally, I think that the evaluation CV may not produce interrupt code in the Wizard.

In which case, you copy-paste a proven set of functions and use them according to their documentation. e.g. my own code uses "kbhit()" to signify whether bytes are available.

You won't have to look far to find Wizard generated code that you could paste.

OTOH, the ability to use the full Wizard and a full set of libraries will easily be worth the cost of the licence.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh dear your absolutely right.
this part of code run when something receive,is it right?

interrupt [USART_RXC] void USART_RX_Complete(void) 
{ 
  data=UDR; 
   get=toascii(data); 
           if(get==8) 
           { 
           delay_ms(100); 
           lcd_clear(); 
           } 
           lcd_putchar(data); 
}

if its true.in transmitter(labview) string repeatedly send via USART.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code design is not great. How long is that ISR going to take? What happens if it's longer than the time between characters or, worse two characters arrive before it finishes the initial service?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should never put delays or slow function calls inside an ISR()

However, it is perfectly acceptable to use 'rx_counter' in the foreground code. Or to put any delays that your heart desires.

With any problem, you should sit down with pencil and paper. Then draw out your design. Hand-trace the logic. When you are happy, you write the C code.

The writing of the code is 1% of the solution. Your brainwork is 99% involved in designing the solution.

If you are wise, you look at proven solutions first. After all, you are never the first person with this problem. Why not benefit from others' experience?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot people
code god or not its correctly work in codvision terminal the problem is the labview program.is anybody here can help me about labview

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ask the nice people at LabView.

Mind you, I would not expect much from them if your attitude is negative.

I would correct your program design first. Then see if you still have a problem.

Yes, a terminal should behave consistently whoever it comes from. In other words, you must select the same COM port, baud rate, format, handshaking, ...

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Experiments:Labview , RS232
and Discovery board

Attachment(s):