ATmega64 | AtmelStudio | incorrect return from function

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

Hello,

I'm testing UART communication, have problem with function usage.

 


#define F_CPU 1843200UL// Clock Speed
#define BAUD 115200UL
#define MYUBRR ((F_CPU/(16*BAUD))-1)
#include <avr/io.h>
#include <util/delay.h>
#include <stdlib.h>

void USART0_Transmit(unsigned char wejscie)
{
	while ( !( UCSR0A & 0x20) );
	UDR0 = wejscie;
	return;
}
void USART0_Init(unsigned int);
void uart_puts(char * );

int main(void)
{
		/* Set baud rate */
		UBRR0H = (unsigned char)(MYUBRR>>8);
		UBRR0L = (unsigned char)MYUBRR;
		/* Enable receiver and transmitter */
		UCSR0B = 0x18;
		/* Set frame format: 8data, 1stop bit, no parity */
		UCSR0C = 0x06;
//	USART0_Init ( MYUBRR );
    while (1) 
    {
		while ( !( UCSR0A & 0x20) );
		UDR0 = 0x31;
		while ( !( UCSR0A & 0x20) );
		UDR0 = 0x32;
		USART0_Transmit(0x33);
		   	_delay_ms(1000);
    }
}

 

In console i receive 123, and no delay. If  I comment:

 

//USART0_Transmit(0x33);

i receive 12 and 1 second delay. I noticed similar problems yesterday with external interrupt - they didnt returned to last point.

This topic has a solution.
Last Edited: Fri. Aug 2, 2019 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not sure what the problem is....

your basic code, will transmit 123 then wait 1 second and do it again... 1 second wait ..........

 

if you leave out the transmit you should indeed see 12 + delay + 12..........

 

Now are you sure that you are actually checking the right register flag?

instead of the "0x20" use the bit flag name you want to check. this is a lot clearer for you in the future and for others as now we have to go take the datasheet and see if the check is correct.

 

as a tip... you can write MYUBRR directly to the 'UBRR0' register

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

M103C

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I should have a FAQ#6 "if m64/128 won't return from CALL disable M103C"

 

Seems like almost everyone who uses a mega64/mega128 the first time is caught by the fact that the chips start life as a mega103.

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

I would love to know who the "important M103 customer" was when the M128 was released.

 

I suspect the "purchasing manager" would never buy the improved chip.   So every M128 (and M64) has left the factory ready-crippled since 2005 (or whenever the M128 appeared).

 

Much like the Hi-Fi buffs that demand gold speaker wires.

 

David.

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

There must've have been a few design-ins for the M103. I did a couple of them. It was nice the M128 was a drop-in replacement. I did, however, modify the code and fuses to suit the M128.