Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

problem with ATMEGA 32 serial communication

Status
Not open for further replies.
R

Rcario

Newbie level 4
Joined
Apr 7, 2012
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,332
Hello everyone, I'm trying to send signals to ATMEGA32 using serial port in order to control motors connected with any port, probably PORTA. The problem is my sample code runs in simulation but doesn't work in real time hardware. Can anybody help me what are the issues associated with this kind of problem and how can i overcome this. I've tested that the data sending procedure with serial port via MATLAB is 100% working and I've a doubt that if i'm missing something important on my codes. Please help. serial_comm_schematic dig.JPG
My code goes like this:

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

#include <avr/io.h>
#include <util/delay.h>
 
 
#define baud 9600
#define my_ubbr F_CPU/16/baud-1
 
void usart_init(uint16_t ubrr);
char usart_getchar( void ); 
void usart_putchar(char data);
void usart_pstr(char *s);
 
int main(void)
{
    DDRA=0x07;      // set port PA0, PA1 and PA2 as output
    // fire up the usart
    usart_init (my_ubbr);       // set serial communication 
    char receive;
    while(1)
    {
        receive=usart_getchar();
        switch (receive) {
            case 'a':
                PORTA=0x01;                // Turn On PA0 bit
                break;
            case 'b':
                PORTA=0x02;                // Turn On PA1 bit
                break;
            case 'c':
                PORTA=0x04;                // Turn On PA2 bit
                break;
        }
        _delay_ms(10); 
    }
}
 
void usart_init( uint16_t ubrr) {
    // Set baud rate
    UBRRH = (uint8_t)(ubrr>>8);
    UBRRL = (uint8_t)ubrr;
    // Enable receiver and transmitter
    UCSRB = (1<<RXEN)|(1<<TXEN);
    // Set frame format: 8data, 2stop bit
    UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
}
 
char usart_getchar(void) {
    // Wait for incoming data
    while ( !(UCSRA & (_BV(RXC))) );
    // Return the data
    return UDR;
}
 
Last edited by a moderator:

In simulation, you can simply use the virtual terminal directly. In practice you must use the RS232 interface using MAX232. Did you design that? Are you using it?

**broken link removed**
 

Did you connect the motors directly to the ports?
better define F_CPU in your code (like #define F_CPU 8000000 for 8 Mhz crystal).
 

Besides the lack of a RS-232 transceiver that Tahmid mentioned and the missing System Clock Frequency (F_CPU) that sriblue7 mentioned.

There is an apparent lack of current limiting resistors for the three LEDs. The lack of current limiting resistors can quickly result in damaged LEDs, AVR or both.

If you've replaced the LEDs with motors in the Real Hardware version and are driving them directly with the AVR, then they are most likely the issue.

Do you have an updated version of the schematic for the Real Hardware?

Bottom line is there are numerous differences between a Simulation and Real Hardware, without seeing a true representative schematic of the Real Hardware design, it is difficult to determine the Real issue.

BigDog
 

Thank you everyone for your valuable concern.

Exactly according to Tahmid, I'm doing so on real hardware. But it is not working. Actually during simulation, i receive a message [AVR USART] RX frame error even thought the LEDs get high and I have a doubt if there is any problem with the frame format.

And for ths sriblue7's recommendation, i tried doing so by defining 12MHZ crystal, as i'm using it on hardware too. Also, I've set fuse bits as CKOPT=0 CKSEL3..1=110 during burning process. But it didn't work out on real scenario. Is there any setting that i can't ignore besides these.

And i totally agree with the bigdogguru's statement about numerous differences between a simulation and real hardware, and I've a strong intuition about that kind of error on my case. I've connected current limiting resistors on the real scenario for protection. I'm extremely sorry that i haven't updated my hardware with the motors since the test with the LEDs is not working out, so the above fig is almost equivalent to my current hardware configurations. I'm not catching the error since several days. Is there any mistake in defining the frame format and can you please help me to find out every considerations about frame format. I guess that might be my error since i get '[AVR USART] RX frame error' message during simulation.

Thank you so much everyone for your helpful information :) , i felt like i've got experienced and helpful hands to overcome my difficulties.

- - - Updated - - -
 

Incorrect baud rate a likely cause. Recheck setup (clock rates,divisors for baud rate generator, format). Also make sure that your RS232 interface is working properly.

The framing error is caused when the UART hardware sees a logic "0" where the stop bit(s) should be (logic "1").
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top