This must be a timing issue

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

I can't seem to get around to the main event of actually debugging my program because of some wierdness with the LEDs.

When I run avr studio's debugger I can watch my code put ddrc all high and then I can watch C_SETBIT turn on the respective pins

but when I dump it to my stk500 with the stk 501 attachment and a at128megal in it all the LEDs on the stk 500 are solid bright, and nevr go off

Maby the stk500(my newest toy) leds are different from the butterfly ones Ive used in previous projects.

Description:
	1. Takes an input from a temperature sensor
	2. Performs an analog to digital conversion
	3. Transmits the temp to a remote display

RF transmission is done via standard Manchester transmission outlines
The code also takes into account power saving techniques via:
		1 turns off tranciever once data has sent
		2 limits the frenquency of sending data


PORTS--------Type--------Description

PORTD:		Mixed		Pins for communicating with the RF transmitter
PORTC:		Output		LED outputs for status check and sending notification
PORTF:		Input		Pins for getting temp and performing ADC
*/

#define F_CPU 8000000
//#include
#include"delay_x.h"
#include

//code define pins
#define	RFTx 		PORTD ,2	//RF transmit pin
#define Led			PORTC ,3	//output LED
#define testled		PORTC, 2	//test led

// from AVR035: Efficient C Coding for AVR 
//quick pin value change macros
#ifndef _AVR035_H_ 
#define _AVR035_H_ 
#define SETBIT(ADDRESS,BIT) (ADDRESS |= (1<<BIT)) 
#define CLEARBIT(ADDRESS,BIT) (ADDRESS &= ~(1<<BIT)) 
#define FLIPBIT(ADDRESS,BIT) (ADDRESS ^= (1<<BIT)) 
#define CHECKBIT(ADDRESS,BIT) (ADDRESS & (1<<BIT)) 
#define SETBITMASK(x,y) (x |= (y)) 
#define CLEARBITMASK(x,y) (x &= (~y)) 
#define FLIPBITMASK(x,y) (x ^= (y)) 
#define CHECKBITMASK(x,y) (x & (y)) 
#define VARFROMCOMB(x, y) x 
#define BITFROMCOMB(x, y) y 
#define C_SETBIT(comb) SETBIT(VARFROMCOMB(comb), BITFROMCOMB(comb)) 
#define C_CLEARBIT(comb) CLEARBIT(VARFROMCOMB(comb), BITFROMCOMB(comb)) 
#define C_FLIPBIT(comb) FLIPBIT(VARFROMCOMB(comb), BITFROMCOMB(comb)) 
#define C_CHECKBIT(comb) CHECKBIT(VARFROMCOMB(comb), BITFROMCOMB(comb)) 
#endif 


//global varibles
int ReceivedData[4];			//receiver buffer, last byte is checksum
int Txdata[3];					//buffer for transmission
int Recv_error_flag;			//receive data error flag, no cofigureable data
int recvtimeout; 				//receiver timeout variable, no configurable data
int MAX_RESEND=3;				//max number of times data is resent

/*
This function localizes all data direction register assginments
*/
void Port_reg_setup(){
	DDRC=0xFF;							//sets port C pins 1-8 to output
	DDRD=0x0F;							//sets port D pin 1-4 to output
}


/*
Init loop is used for sending sync. pulse, must call before sending data
*/
void txinit()
{
	int i;
	for(i = 0; i <= 40; i++)					//send lot of hi/lo transistion pulse to ack. the receiver
	{
		C_CLEARBIT(RFTx);
		_delay_us(300);
		C_SETBIT(RFTx);
		_delay_us(300);
	}
	C_CLEARBIT(RFTx);						//2ms low bits as sync. pulse
	_delay_ms(2);
}//txinit

/*
end loop is called after sending data, to turn off the transmitter
*/
void txend()
{
	C_CLEARBIT(RFTx);							//low pulse to terminate the tx.
	_delay_ms(20);
}//txend

/* Write data
send the individual 8 bits of 1 byte(data) to the transmitter for sending
the pulse duty cycle uses the manchester encoding technique
*/
void txwrite(int data)			
{
	int j;											//loop counter
	int Result;										//for storing bits of the data

	for(j = 0; j <= 7; j++)							//sends 8 bits out to the tx with MSB being transmitted first
	{
		Result = data & 0b10000000;					//get the MSB of data and store in result
		if(Result == 0)								//if the tested bit is 0
		{
			C_SETBIT(RFTx);							//generate duty cycle
			_delay_us(300);
			C_CLEARBIT(RFTx);
			_delay_us(700);
		}//if
		else										//if the tested bit is 1
		{
			C_SETBIT(RFTx);							//generate duty cycle
			_delay_us(700);
			C_CLEARBIT(RFTx);
			_delay_us(300);
		}//else
		data=data<<1;								//bit shifts next bit to the MSB 
	}//for
}//txwrite


/*
Transmits data to reciever using manchester encoding technique
for checksum generation

Current tranfer size = 4 bytes = 24 bits
*/
void RF_Transmit()
{
	int i,j;
	int checksum;
	checksum = Txdata[0];
	for(i = 1; i < 3; i++)
	{
		checksum = Txdata[i] ^ checksum;
	}//for
	for(j = 0 ; j <5; j++)
	{
		txinit();
		txwrite(Txdata[0]);
		txwrite(Txdata[1]);
		txwrite(Txdata[2]);
		txwrite(checksum);
		txend();
	}//for
}//RF_Transmit

/*
Gets the temperature from the sensor and loads it into Txdata
Currently Temp is sent as a 16 bit number (Its mad big for how accurate it is
but the device likes to send a 20-40 bit string anyway so I sent a standard C int 
byte style
*/
void Get_Temp(){
	int temp=75;//?? gotta spec the temp reader (for debugging purposes ill set it to a known value :75)
	Txdata[0]=temp & 0x00FF;
	Txdata[1]=(temp & 0xFF00) >> 8;
	Txdata[2]=0;						//ensures for a proper checkbit
}//Get_Temp


//txdata is 4 long(just a note for remembering)
int main()
{
	Port_reg_setup();
	
	int i=0;							//resend counter
// 	_delay_ms(1000);					//ititial delay to get things initialized
	for(i = 0; i <= 2; i++)				//init to make the reciever aware
	{
		Txdata[i] = 0xAA;
	}//for
	RF_Transmit();
	C_SETBIT(Led);
	while(1)
  	{
		C_SETBIT(testled);
		txinit();
		Get_Temp();
		for(i = 0; i <= MAX_RESEND; i++)
		{
			RF_Transmit();
		}//for
//		_delay_ms(500);					//wait awhile to send another update (saves battery)
  	}//while
	

}//main

I guess the only pertinent parts to my problem are

void Port_reg_setup(){
DDRC=0xFF;							//sets port C pins 1-8 to output
DDRD=0x0F;							//sets port D pin 1-4 to output
}

and

C_SETBIT(Led);
C_SETBIT(testled)

This would work on a butterfly for turning on and off leds I believe...but who knows ( maby you hopefully :P )

BUT!!! If the LED calls are right then maby I have some wierd timing issue where the program operates fine in the debugger and odd in the uP

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

I FIGURED IT OUT!!!!!!!

AT103 compatibility mode was checked

NASTY LITTLE ATMEL BUG!

Make sure to turn it off when programming your atmega 128...i wasted 4 hours figuring it out

dont repeat my blunders

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

Quote:
NASTY LITTLE ATMEL BUG!

No, not a bug, it is a feature. But one that is no longer a desirable one (at least for the vast majority of people).

Regards,
Steve A.

The Board helps those that help themselves.

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

Quote:

NASTY LITTLE ATMEL BUG!

Thats really weird. You are actually named after a silicon IC company?!? :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Hey, here's an idea that Atmel could use to avoid this kind of "BUG" in future. They ought to write down a complete and accurate description of exactly what the chip does and how it's configured when it's delivered from the factory and maybe call this a "datasheet" or something?

Oh,....

.... wait a minute, ...

.... they already do.

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

point taken....i was just frustrated with a new dev board, and its corresponding dev suite defaulting to a legacy option that throws a monkey wrench in my project...