| Author |
Message |
|
|
Posted: May 28, 2010 - 07:51 AM |
|


Joined: Jan 23, 2010
Posts: 840
Location: Edmonton, Alberta
|
|
| "8data, 1stop bit" (and no parity) is what each transmitted packet will contain - ASCII code is within the 8 data bits. Is Hyperterminal setup to receive this type of packet? All the relevant options need to be set: 9600 baud, 8 data bits, 1 stop bit, no parity, and no handshaking. Also remember to verify the correct COM port is being used. |
|
|
| |
|
|
|
|
|
Posted: Jun 01, 2010 - 02:36 PM |
|

Joined: May 17, 2010
Posts: 5
|
|
| Yes I have all of those setup correctly. How can I ensure that my atmega is running at 4mhz, which is what i used for all the calculations. |
|
|
| |
|
|
|
|
|
Posted: Jul 19, 2010 - 08:54 PM |
|

Joined: Mar 17, 2008
Posts: 249
|
|
I read this great tutorial several times, but am still having a strange problem. I am using a MAX232 in conjunction w/ Hyperterminal to try and receive some simple data from my AVR (MEGA168). The issue is that the ONLY thing I can get to show up in Hyperterminal, repeated over and over again, is the letter "p". The only values that appear to even generate this are when I load UDR0 with a byte of data containing some combination of F and 7 ONLY (i.e., 0xF7, 0x77, etc).
Settings:
Code:
#define FOSC 8000000 // Clock Speed
#define BAUD 9600
#define MYUBRR FOSC/16/BAUD-1
UBRR0H = (unsigned char)(MYUBRR>>8);
UBRR0L = (unsigned char)MYUBRR;
//Enable receiver and transmitter */
UCSR0B = 0x98; //Enable Rx/Tx, enable Rx interrupt
/* Set frame format: 8data, 1stop bit */
UCSR0C = 0x06; //8-bit, one stop, no parity, asynchronous
Is this some common ASCII characher for newline or something that's getting sent???
Hyperterminal is set for 9600 Baud, 8 data bits, no parity, one stop, and no Flow Control. |
|
|
| |
|
|
|
|
|
Posted: Jul 19, 2010 - 09:17 PM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
As it's a 168 have you cleared CKDIV8 or reprogrammed CLKPR to achieve the same effect?
Also how sure are you (apart from this) that the 8MHz clock source is enabled as the active clock source.
Finally, if you have a scope, if you sit in a loop attempting to send 'U' repeatedly does the scope show the bit widths to be 104us? |
_________________
|
| |
|
|
|
|
|
Posted: Jul 20, 2010 - 01:08 PM |
|

Joined: Mar 17, 2008
Posts: 249
|
|
I should have clarified: I am using an older ICE50 to emulate the MEGA168 in Studio. In the ICE50 options screen, I have verified in the platform options that CKDIV8 is not checked and also that I am definitely running at 8MHz.
On the scope, sending a "U", I get periodic groups of five pulses, 500uS in width, separated by 500uS. The groups are 18mS apart, which makes sense as my code strobes the message w/ this period. Still getting "p" in Hyperterminal.
Tried sending some other string chars (i.e., "B", "S") and the bit pattern on the scope changes, but I no longer get anything in Hyperterminal. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2010 - 04:26 PM |
|

Joined: Nov 17, 2004
Posts: 13844
Location: Vancouver, BC
|
|
|
Quote:
I get periodic groups of five pulses, 500uS in width, separated by 500uS.
That would seem to be 2000 baud, not 9600 baud. |
_________________ Regards,
Steve A.
The Board helps those that help themselves.
|
| |
|
|
|
|
|
Posted: Jul 20, 2010 - 06:49 PM |
|

Joined: Mar 17, 2008
Posts: 249
|
|
You are exactly right, there was a mistake in my macro. I have fixed it now and its working great.
One last question: I am loading hex data into my UART, and I would prefer getting that raw data instead of its ASCII equivalent. Is there a setting in Hyperterminal to allow this?
Thanks! |
|
|
| |
|
|
|
|
|
Posted: Jul 21, 2010 - 10:49 AM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Is there a setting in Hyperterminal to allow this?
Not HT - but other terminal programs such as Teraterm, Realterm and Brays offer this. |
_________________
|
| |
|
|
|
|
|
Posted: Aug 10, 2010 - 07:12 PM |
|


Joined: Jun 14, 2010
Posts: 18
Location: Riverside USA
|
|
|
|
|
|
|
Posted: Sep 29, 2010 - 07:42 AM |
|


Joined: Sep 28, 2010
Posts: 54
|
|
hai,
i am working with stk600 with atmega2560.
i am trying for serial communication using usart.
hardware connections:
TXD pin is connected to PORT-E PIN1
RXD pin is connected to PORT-E PIN0
with the following code, we could manage to blink LEDs with the given input,but it is not possible to transmit it to HYPERTERMINAL.......it is displaying some junk garbage values on to the hyperterminal.
my code is:
Code:
#define baud 9600
#define ubrr F_CPU/(16*baud)-1
void main()
{
usart_init(ubrr);
while(1)
usart_transmit('A');
}
usart_inint(uint16_t ubr)
{
UBRR0H=(unsigned char)(ubr>>Cool;
UBRR0L=(unsigned char)ubr;
UCSR0B=(1<<TXEN0)|(1<<RXEN0);
UCSR0C=(1<<UCSZ00)|(1<<UCSZ01)|(0<<UCSZ02)|(0<USBS0);
}
usart_transmit(unsigned char data)
{
while ( !( UCSR0A & (1<<UDRE0)) ) ;
UDR0 = data;
}
}
real frequency is 16000000hertz........spare RS232 of stk600 has got 4pins.....
RTS,CTS,TXD,RXD.
RTS-CTS shorted
TXD connected to PE1
RXD connected to PE0.
in the programmer part::
advanced tab:calibrate for frequency is 8MHz(no option to select other frequency)
fuses:
CKDIV8,JTAGEN,SPIEN are enabled
extended - 0xFF, high - 0x99, low - 0x62;
HW SETTINGS::
clock generator is 16.01MHz
in the simulator part::
if we give ubrr=103 directly then UBRR0H - 0x00,UBRR0L- 0x67; and nothing(not even the garbage values) will be displayed in the hyperterminal
but if we give ubrr after calculating it with (F_CPU/((baud*16)-1)) then UBRR0H - 0X00,UBRR0L-0x05.
;and some garbage values are displayed in the hyperterminal
this is what actually happening.
[[code] tags added - couldn't do anything about the indentation] |
|
|
| |
|
|
|
|
|
Posted: Sep 29, 2010 - 07:45 AM |
|


Joined: Jun 29, 2010
Posts: 78
|
|
why is the following code not transmitting any data through ATMEGA2560 - STK600......suggest me any changes
frequency : 16000000hz
baud :9600
PIN0 OF PORTE is connected to TXD pin of stk600
PIN1 OF PORTE is connected to RXD pin of stk600
suggest me any further changes required...
code:
Code:
Code:
//==================================================================================================//
// INCLUDING HEADER FILES & OTHER GLOBAL DECLARATIONS //
//==================================================================================================//
#include<avr/io.h> // including the input/output files of avr
#include<avr/interrupt.h> //including the interrupt files of avr
#include<avr/sfr_defs.h> //including the special function registers
#include<util/delay.h> //including the delay function from util directory
#define FOSC 16000000L //clock speed of 8MHz
#define BAUD 9600 //baud rate
#define MYUBRR ((FOSC/(16*BAUD))-1) //defnining the USART BAUD RATE REGISTER
void transmit(unsigned char ); // function for transmitting the at command to GSM for initialization
void start_commandat(); //declaration of the function which sends 'AT' command
void USART_Init(unsigned int); //declaration of the 'USART INITIALISATION' function
unsigned char m;
//unsigned char t;
int p=0;//declaration of the required variables
//**************************************************************************************************//
// MAIN PROGRAM //
//**************************************************************************************************//
int main( ) //start of the program
{
USART_Init(MYUBRR);//function call for the USART initialisation
// sei();//set the global interrupt
for(;;)
{
m='A';
while ( !( UCSR0A & (1<<UDRE0)) )
;
/* Put data into buffer, sends the data */
UDR0 =m;
_delay_ms(1);
//transmit(m);
}
}
//////////////////////////////////////////////////////////////////////////////////////////////////////
/// USART INITILISATION FUNCTION //
//////////////////////////////////////////////////////////////////////////////////////////////////////
void USART_Init(unsigned int ubrr)
{
UBRR0H =(unsigned char)(ubrr>>8);//setting the baud rate
UBRR0L =(unsigned char)ubrr;//setting the baud rate
UCSR0B = (1<<RXEN0)|(1<<TXEN0);//ENABLING THE TRANSMITTER AND RECEIVER
UCSR0C = (0<<UMSEL01)|(0<<UMSEL00)|(0<<USBS0)|(1<<UCSZ00)|(1<<UCSZ01)|(0<<UCSZ02);//SETTING THE FRAME FORMAT WITH 8 DATA AND 1 STOP BITS
UCSR0A = (1<<UDRE0);
}
//////////////////////////////////////////////////////////////////////////////////////////////////////
/// TRANSMIT FUNCTION //
//////////////////////////////////////////////////////////////////////////////////////////////////////
/*void transmit( unsigned char data )
{
while ( !( UCSR0A & (1<<UDRE0)) )
;
UDR0 = data;
}*/
in the programmer part::
advanced tab:calibrate for frequency is 8MHz(no option to select other frequency)
fuses:
CKDIV8,JTAGEN,SPIEN are enabled
extended - 0xFF, high - 0x99, low - 0x62;
HW SETTINGS::
clock generator is 16.01MHz
in the simulator part::
if we give ubrr=103 directly then UBRR0H - 0x00,UBRR0L- 0x67; and nothing(not even the garbage values) will be displayed in the hyperterminal
but if we give ubrr after calculating it with (F_CPU/((baud*16)-1)) then UBRR0H - 0X00,UBRR0L-0x05.
;and some garbage values are displayed in the hyperterminal
this is what actually happening.
[[code] tags added] |
|
|
| |
|
|
|
|
|
Posted: Sep 29, 2010 - 10:28 AM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| You people obviously haven't read the other 21 pages of this thread. Almost without exception the AVR is not being clocked at the frequency you think. Suggest you flash an LED at 0.2Hz (say) using <util/delay.h> and measure it with your watch - is it really 5 seconds or not? A common "gotcha" on modern AVRs is the state of the CKDIV8 fuse (which is enabled by default and sets CLKPR so that the AVR runs at 1/8th of the applied clock frequency) |
_________________
|
| |
|
|
|
|
|
Posted: Oct 12, 2010 - 01:12 AM |
|


Joined: Feb 23, 2007
Posts: 175
Location: East Central Iowa
|
|
Is there a bug in the simulator (II) or could my code do this? I am using an ATmega88 and testing USART transmit assembly code with the data register empty interrupt on the simulator. Everything seems normal on the simulator except the data register is *always* 0x00.
When it runs it transfers data to a buffer and then quickly executes two interrupts and then indicates the data register is not empty. It runs a long time and then executes another interrupt when the data register is empty. It goes on until everything in the buffer has been (presumably) loaded to the data register. It all seems just what it should be except there is *never* (that I notice) any thing displayed in the simulator data register (UDR0) except 0x00 (I'm loading in an ASKII string and a value and they are correct in the register used to load UDR0).
John |
|
|
| |
|
|
|
|
|
Posted: Oct 12, 2010 - 06:24 AM |
|

Joined: Nov 17, 2004
Posts: 13844
Location: Vancouver, BC
|
|
|
Quote:
except the data register is *always* 0x00.
But reading the usart data register will give you the last received byte, not the last transmitted byte. |
_________________ Regards,
Steve A.
The Board helps those that help themselves.
|
| |
|
|
|
|
|
Posted: Oct 12, 2010 - 09:43 AM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
But reading the usart data register will give you the last received byte, not the last transmitted byte.
To add to that - the simulator does not normally have a mechanism to simulate receiving characters so it would be fixed at 0x00. If, however, you run Sim1 (not 2) and download "Hapsim" and run it alongside AVR Studio then it has a simulated terminal feature which will feed charactes into the simulated UDR. |
_________________
|
| |
|
|
|
|
|
Posted: Oct 12, 2010 - 12:21 PM |
|


Joined: Feb 23, 2007
Posts: 175
Location: East Central Iowa
|
|
|
Quote:
But reading the usart data register will give you the last received byte, not the last transmitted byte.
From my point of view, I'm not reading UDR0, I'm just watching it! I can understand that as bits are shifted out, what's left in there would be difficult to present, but it would be nice to see what's in the UDR0 buffer register while the bottom (sending) register is not empty. The simulator works pretty good, and I appreciate it, but I have been hung up on this for a long time.
Clawson, I'm just interested in transmit for now, but Hapsim looks like a good idea when I add receive capability. Thanks for the tip. |
|
|
| |
|
|
|
|
|
Posted: Oct 12, 2010 - 12:50 PM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I'm just watching it!
Which one? Remember that UDR0 is two separate registers. One (write) is your access to the transmission hold shift register and the other (read) is the receiver register. The AVR Studio simulation only shows one of these and that is the transmit register. When you write to it you should see the byte you wrote there for 1 cycle then it is transferred internally to the non-accessible shift register.
If you are beating yourself up over some UART routine that doesn't work it's got nothing to do with whether the half-baked similar is working or not. There's a 99.9% chance the clock speed of your AVR is wrong (I think I read that somewhere? ) |
_________________
|
| |
|
|
|
|
|
Posted: Nov 19, 2010 - 04:27 PM |
|

Joined: Oct 13, 2006
Posts: 156
|
|
I posted a similar question somewhere else but I thought it might get more attention and possibly be helpful to others if I made it more generic and posted it here.
I am debugging a project in AVR Studio and I have a problem where random garbage gets sent out occasionally. It usually happens when I first load the project and then again when I stop the project. 90% of the time everything looks good but that other 10% of the time screws everything up. I can't settle for anything less than 100%. I am using an Xmega128a1 and everything is interrupt driven with RX and TX circular buffers so the code is quite long and slightly complicated but I would be happy to post it if someone thinks that would help OR if someone else would like to use it... even though it only works 90% of the time  |
|
|
| |
|
|
|
|
|
Posted: Dec 02, 2010 - 02:52 PM |
|


Joined: Nov 26, 2010
Posts: 15
Location: Junction City, KS
|
|
Hey all,
I have just started with AVR programming and was attempting to follow along with this tutorial and nearly went insane & bald trying to figure out what I was doing wrong. Then I sat down for a whole day and read through the entire datasheet from atmel and realized that the fuses are named in a different fashion from what is in the tut, eg: UCSRB in the tut == UCSRnB in the datasheet instead of the proposed UCSRBn.
Anyway, I thought I would share my code for a working USART Echo program so other developers may not experience the same hair pulling that I did. Below is my code, it is modified from the datasheet examples with additional comments and as of now, it works.
Oh, one issue that I did have with following along with the tut ( URSELn ) and the information in the datasheet ( UMSELn ). No matter which way I set it (async / sync), it would cause invalid characters to appear via ZTerm instead of the standard 'b' or 'bp'. All that would show up is a ',' and complete loss of terminal functionality.
Hardware:
-atmega168 from nerdkits.
-what i'm guessing is something like the max232 interface chip on an external board ( can't read the tiny writing ).
-USB to RS232 adapter from Prolific
Dev System:
-OS X 10.6.5 (MacBook13.1)
-CrossPack toolchain
-ZTerm terminal emulator
-vi
Code:
#include <avr/io.h>
#include <stdlib.h> // only included "free()" functionality
#define F_CPU 14745600 // Clock speed
#define BAUD 115200 // expexted transfer rate
#define MUBRR F_CPU/16/BAUD-1 // set baud rate register
void UsartInit(unsigned int ubrr){
UBRR0H = (unsigned char) (ubrr>>8); // set High bit to second bit of ubrr
UBRR0L = (unsigned char) ubrr; // set Low bit to first bit of ubrr
UCSR0B = (1<<RXEN0) | (1<<TXEN0); // enable Receive & Transmit circuits
UCSR0C = (1<<USBS0) | (3<<UCSZ00);// set 2bit stop, 8bit character size
}
void UsartSend(unsigned char data){
while ( !(UCSR0A & (1<<UDRE0))); // wait for send buffer to be empty
UDR0 = data; // send data
}
unsigned char UsartReceive(void){
while ( !(UCSR0A &(1<<RXC0))); // wait for data reception to be complete
unsigned char data = UDR0;
return data; // return received data to main()
}
void UsartFlush(void){
unsigned char dump; // store temp data
while (UCSR0A &(1<<RXC0))dump = UDR0;
// drop all incoming data to temp store until incoming data is null
free(&dump); // drop anything thats left by releasing the memory
}
int main(void){
UsartInit(MUBRR); // initialize USART for data transfer
unsigned char gigo; // storage for i/o of data
for(;;){ // never ending loop
if(DOR0){ // check for data overflow
UsartFlush(); // and flush it out
}
gigo = UsartReceive(); // put input to temp storage
UsartSend(gigo); // send output from storage
}
return 0; // end of program
}
|
|
|
| |
|
|
|
|
|
Posted: Dec 02, 2010 - 04:03 PM |
|


Joined: Jul 18, 2005
Posts: 62322
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
if(DOR0){ // check for data overflow
What's "DOR0" then? If I grep the header file used for mega168 it says:
Code:
iomx8.h:#define DOR0 3
so that line really says:
Code:
if(3){ // check for data overflow
the conditional test is therefore completely pointless as the condition is always true. So it always calls the flush function. |
_________________
|
| |
|
|
|
|
|