Pushbutton help?

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

OK, let me remind you that I am a newbie and now need more help. I was wondering if it possiable to pushbutton on PORTA pin 0 to able to do two different functions. If the pusbutton was pressed for 1 or 2 seconds, it would change the led chaser pattern, but if it was longer than 2 seconds, it would shut off and goto sleep mode. How can I hook up the button on the mega128 and the code is in C.

Shane

Thanks
Shane

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

A solution that is equally quick and dirty.

#define BUTTON (1<<0)

int main(void)
{
	uint16_t Pressed = 0;
	while(1)
	{
		while (PINA & ~BUTTON)
			Pressed++;
		if (Pressed > 10000)
			sleep();	// this probably isnt the right
					// name for the sleep function
		else
			dosomething();
		Pressed = 0;
	}
}
Last Edited: Thu. Oct 26, 2006 - 03:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hook up the button:
Pullup resistor, say 10Kohms, PORTA-0 to Vcc.
N.O., S.P.S.T. PORTA-0 to GND.
Capacitor 100nF PORTS-0 to GND if you like.

The rest is software. What you describe is an event persistence timer. Pressing the button causes PARTA-0 to go low. This is the start of the event. Releasing the button allows PORTS-0 to go high, marking the end of the event. The time between (how long the condition persists) can be measured by counting the number of times through the loop waiting for the end of the event.

If your program is a bit more elegant, you can couint interrupt driven "ticks" or internal timers to measure the time of the event.

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

AS you are driving leds in a pattern you will be using at least one hardware timer.

SSet up a switch monitor routine such that if the required switch is not pressed it clears a global variable lets call it sw_time.

In the hardware interrupt function increase the value of sw_time.

While the switch is not pressed the value will not get very high between resets by the swicth monitor function. If it is pressed then it will not be reset so count up to a point at which it rolls over.

n the change led pattern function set a flag to indicate it has been changed and clear flag when switch released. Do not change the pattern if the flag is set.

main()
{
init_ports();
init_timer();
for(;;)
{
test_switches();
if(sw_time>sleep_time)
go_to_sleep();
else if(sw_time>change_led_time)
change_led_pattern();
}

}

Keep it simple it will not bite as hard

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

Following an universal key debouncing routine for up to 8 keys with four sample debouncing, long or short press detection or repeat function:

Peter

Attachment(s): 

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

Sorry, when you mean by a hardware timer, r you talking about a built-in timer in the avr?

sutton wrote:
AS you are driving leds in a pattern you will be using at least one hardware timer.

SSet up a switch monitor routine such that if the required switch is not pressed it clears a global variable lets call it sw_time.

In the hardware interrupt function increase the value of sw_time.

While the switch is not pressed the value will not get very high between resets by the swicth monitor function. If it is pressed then it will not be reset so count up to a point at which it rolls over.

n the change led pattern function set a flag to indicate it has been changed and clear flag when switch released. Do not change the pattern if the flag is set.

main()
{
init_ports();
init_timer();
for(;;)
{
test_switches();
if(sw_time>sleep_time)
go_to_sleep();
else if(sw_time>change_led_time)
change_led_pattern();
}

}

Thanks
Shane

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

I have a slightly different problem with a pushbutton, i'm also a total newbie :)
Ive connected 8pushbuttons to gnd through PORTC pins, wrote software to turn leds on when the pushbutons are pressed. but the leds stay on whatever i do... where is the problem? i beliece in the wiring, brcause avr studio simulatet it exactly as I wanted itto be...
anyone knows the answer?

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

DelNet,

Are you reading PINC or PORTC? Is PORTC set to be an input with pullups?

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

Yes madcitysw I do mean the built in timer.
Do get into the habit of useing them in preferance to a software loop. It may seem hard at this point but it is good to learn how to use them. Just try the simple overflow interrupt at this point.

DelNet HIJACKING A THREAD IS BAD MANNERS!! yes I have just shouted.

Keep it simple it will not bite as hard

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

DelNet, don't worry about hijacking my topic, it fine with me if you had the same question. It keeps thing in order to me.

sutton wrote:
Yes madcitysw I do mean the built in timer.
Do get into the habit of useing them in preferance to a software loop. It may seem hard at this point but it is good to learn how to use them. Just try the simple overflow interrupt at this point.

DelNet HIJACKING A THREAD IS BAD MANNERS!! yes I have just shouted.

Thanks
Shane

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

DelNet - do some reading on 'switch bounce'. Switches aren't perfect - when you turn them on or off, they 'bounce' - creating multiple ons and offs before they settle. This is solved in software by sampling the inputs a few times and deciding if it is on or off or bouncing. So one button press without debouncing could register as 5! This is what your simulation misses!

As others have mentioned here, a common technique is to have a timer setup to create an interrupt at a fixed rate - say every 10mS. We can sample the switch inputs and add logic to see if the switch has been on for the last ,say, 5 samples then set/reset a variable to say if the switch is on or off. The main line code can read this variable and do whatever is required.

You can also count how long the switch is pressed in this interrupt code.

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

Well I try something like what you had and I don't understand what it suppose to do. I can't even get it to overflow

danni wrote:
Following an universal key debouncing routine for up to 8 keys with four sample debouncing, long or short press detection or repeat function:

Peter

Thanks
Shane

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

Well I try something like what you had and I don't understand what it suppose to do. I can't even get it to overflow

EDIT

I did finally get the timer to work...

EDIT AGAIN

Well when the timer is turned on, the main loop stops and can not go on til the timer is turned back off. I know that seems wrong. What's up with that?

danni wrote:
Following an universal key debouncing routine for up to 8 keys with four sample debouncing, long or short press detection or repeat function:

Peter

Thanks
Shane

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

Madcitysw
Post your code as it stand so it can be looked at and enable others to point you in the right direction.

Keep it simple it will not bite as hard

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

madcitysw wrote:

Well when the timer is turned on, the main loop stops and can not go on til the timer is turned back off. I know that seems wrong. What's up with that?

To help, we must know:

- which AVR derivate was used
- which derivate was selected to compile
- which compatibility mode was set on the fuse bits
- your complete source code

Peter

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

danni wrote:
madcitysw wrote:

Well when the timer is turned on, the main loop stops and can not go on til the timer is turned back off. I know that seems wrong. What's up with that?

To help, we must know:

- which AVR derivate was used
- which derivate was selected to compile
- which compatibility mode was set on the fuse bits
- your complete source code

Peter

	/*
	
	Chip: Atmega128
	Compiler: C / AVR Studio
	Fuses: OCDEN, JTAGEN, CKOPT, SUT0
	*/
	
	#include 
	#include 
	
	#define LED_OFF 0
	#define LED_ON 1
	
	#define STATUS_LED PA0
	#define STATUS_LED_PORT PORTA
	
	#define STATUS_LED_DDR DDA0 
	#define STATUS_LED_DDR_PORT DDRA
	#define STATUS_LED_DIRECTION 0x01
	
	#define STATUS_BUTTON PA1
	#define STATUS_BUTTON_PORT PORTA

	#define STATUS_BUTTON_DDR DDA1 
	#define STATUS_BUTTON_DDR_PORT DDRA 
	#define STATUS_BUTTON_DIRECTION 0x00
	
	#define LED_COUNT 5
	
	char leds[LED_COUNT];
	
	//char	pattern_button;
	int		pattern_mode = 0;

	void pattern_1(void);
	void pattern_2(void);
	
	void delnms(unsigned int n) {
		//delay n ms
		unsigned int x;

  	while(n--){
    	x=2600;       //empirically determined fudge factor 16mhz
    	while(x--);
  	}
	}

	void init() {
		STATUS_LED_DDR_PORT = (STATUS_LED_DDR_PORT | STATUS_LED_DIRECTION << STATUS_LED_DDR);
		
		STATUS_BUTTON_DDR_PORT = (STATUS_BUTTON_DDR_PORT | STATUS_BUTTON_DIRECTION << STATUS_BUTTON_DDR); 
		
		
		STATUS_BUTTON_DDR_PORT = (STATUS_BUTTON_DDR_PORT | STATUS_LED_DIRECTION << DDA2); 	
	}

	void testleds() {
		int i = 1;
		
		for (i = 1; i <= LED_COUNT; i++) {
			PORTA = (1<<leds[i]);
		}

		delnms(1000);

		for (i = 1; i <= LED_COUNT; i++) {
			PORTA = (0<<leds[i]);
		}
	}

	SIGNAL (SIG_OVERFLOW0) {
		STATUS_LED_PORT ^= (LED_ON << STATUS_LED);
		delnms(300);
		STATUS_LED_PORT ^= (LED_OFF << STATUS_LED);
		delnms(100);

		TCCR0 = 0<<CS02;
	}

	/*SIGNAL (SIG_OVERFLOW2) {
		STATUS_LED_PORT ^= (LED_ON << PA2);
		delnms(200);
		STATUS_LED_PORT ^= (LED_OFF << PA2);
		delnms(100);
	}*/
	
	int main() {
		//DDRD = (0<<DDD0);
		init();
		TCCR0 = 1<<CS02;

		//TCCR2 = 1<<CS02^1<<CS00;

		TIMSK = (1<<TOIE0);
		
		sei();
				
		for(;;){
			
		STATUS_LED_PORT ^= (LED_ON << PA2);
		delnms(200);
		STATUS_LED_PORT ^= (LED_OFF << PA2);
		delnms(100);
			
			//PORTA = (1<<PA2);
			//PORTA = (PIND0<<PA0);
			/*switch(pattern_mode) {
				case 0:
					pattern_1();
				break;

				case 1:
					pattern_2();
				break;
			}*/
		}
	}

	void pattern_1(void) {
		PORTA = (0<<PA0)|(1<<PA1);
		delnms(600);
		PORTA = (1<<PA0)|(0<<PA1);
		delnms(100);
	}

	void pattern_2(void) {
		PORTA = (0<<PA0)|(1<<PA1);
		delnms(40);
		PORTA = (1<<PA0)|(0<<PA1);
		delnms(40);
	}

Thanks
Shane

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

Errors:

1) (and this is the biggy!) 'pattern_mode' is set in the ISR and used in main(). Unless you are building with no optimisation (that is -O0) then the main() code will not "see" changes made to the variable in the ISR. You must add "volatile" to the start of the pattern_mode variable definition. This tells the compiler that the ISR and the main() both need to "see" changes to the variable. This bites everyone which is why it is entry number 1 in the avr-libc FAQ!

2) SIGNAL() is deprecated. Use ISR() instead. Also the vector names are deprecated. Use TIMER0_OVF_vect instead of SIG_OVERFLOW0

3) You have HUGE delays in your ISRs (like 0.3s and 0.1s). This is NEVER a good idea (while in the ISR interrupts remain disabled so any other interrupts while you are in those delays will be lost). ISR() should always be quick in, quick out. If a "long job" is needed as the result of an interrupt then set a flag in the ISR() and have the long work done in main()

4) I'll bet PORTA = (0<<PA0)|(1<<PA1); doesn't do what you think it does! Suggest you read the "101" thread in the tutorial forum:

https://www.avrfreaks.net/index.p...

5) Equally "STATUS_LED_PORT ^= (LED_ON << PA2); " and "STATUS_LED_PORT ^= (LED_OFF << STATUS_LED);" don't do what the words seem to imply. The Xor operator will toggle the given bits that are 1. In (LED_ON << PA2); that is bit 2. In (LED_OFF << STATUS_LED) there is no bit specified to toggle. See (4) !!

For 4 and 5 the important things is to set bit N of PORT use "PORT |= (1<<N)" and to clear bit N of PORT use "PORT &= ~(1<<N)". The 101 thread explains this!

Cliff

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

The long delays in the ISP was just a test anyway to see if the timer was working. But while the timer is running, the main loop in the main() stops and stays stopped, this is where the real delays will be located as that where it changes the leds around and etc. The ISP was really for checking for input buttons to see if the button was pressed short or long. I know that this is very bugging and all, but I just a newbie who got to learn some AVRs matters ;)

clawson wrote:
Errors:

1) (and this is the biggy!) 'pattern_mode' is set in the ISR and used in main(). Unless you are building with no optimisation (that is -O0) then the main() code will not "see" changes made to the variable in the ISR. You must add "volatile" to the start of the pattern_mode variable definition. This tells the compiler that the ISR and the main() both need to "see" changes to the variable. This bites everyone which is why it is entry number 1 in the avr-libc FAQ!

2) SIGNAL() is deprecated. Use ISR() instead. Also the vector names are deprecated. Use TIMER0_OVF_vect instead of SIG_OVERFLOW0

3) You have HUGE delays in your ISRs (like 0.3s and 0.1s). This is NEVER a good idea (while in the ISR interrupts remain disabled so any other interrupts while you are in those delays will be lost). ISR() should always be quick in, quick out. If a "long job" is needed as the result of an interrupt then set a flag in the ISR() and have the long work done in main()

4) I'll bet PORTA = (0<<PA0)|(1<<PA1); doesn't do what you think it does! Suggest you read the "101" thread in the tutorial forum:

https://www.avrfreaks.net/index.p...

5) Equally "STATUS_LED_PORT ^= (LED_ON << PA2); " and "STATUS_LED_PORT ^= (LED_OFF << STATUS_LED);" don't do what the words seem to imply. The Xor operator will toggle the given bits that are 1. In (LED_ON << PA2); that is bit 2. In (LED_OFF << STATUS_LED) there is no bit specified to toggle. See (4) !!

For 4 and 5 the important things is to set bit N of PORT use "PORT |= (1<<N)" and to clear bit N of PORT use "PORT &= ~(1<<N)". The 101 thread explains this!

Cliff

Thanks
Shane

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

@madcitysw,

if you post code, then remove all useless lines, e.g. which are commented out or never used variables.

If you try to make the work especially hard for the viewer, then please expect no answer.

Nevertheless you answered not my questions, which derivate was compiled and was the M103 mode selected ?

Typically crashing a call was a sign for wrong derivate compiling.

Peter

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

A: I did answer your questions if you looked at the comment out at the first lines of code. It answers which compiler I used and which programming bits were selected and I didn't try to make it harder for the viewers to able to help. I just posting the full code as many had requested in the past. Don't forget that I a newbie, so please don't get all upset over it. I can not use the M103 mode because then the chip won't run with it on. I not too sure whatr you mean by the last statement as it goes crashing a call sign :? Anyway I do like to thank you for helping out anyway :)

danni wrote:
@madcitysw,

if you post code, then remove all useless lines, e.g. which are commented out or never used variables.

If you try to make the work especially hard for the viewer, then please expect no answer.

Nevertheless you answered not my questions, which derivate was compiled and was the M103 mode selected ?

Typically crashing a call was a sign for wrong derivate compiling.

Peter

Thanks
Shane

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

I'd like to get some concensus on switch bounce... somtimes its a problem and sometimes it can be ignored. You usually cant peck a button faster than about 10ms contact closure every 200ms or so, but when the contacts do close, they bounce a couple times within a few ms of the closure. So if the program just reads the switch every pass and does something like turn on a light when the switch is closed, then it probably doesnt need to be debounced. If you are unlucky enough to read it while it is bounced up, no prob, it will just get read again next pass of the prog. If the program is running 10 passes a sec or up to about 50 passes a sec, the program will catch even the fastest key press or switch flip. Places where bounce is a problem would be like entering text and its a pain when the key bounces and you get three BBBs in a row. Next chapter will try to decide if it is better to debounce the key while waiting in a tight loop, or keep running the program, and how do you decide when the key is valid? On the first press, or the release or three passes with no release or ??

Imagecraft compiler user

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

Quote:

they bounce a couple times within a few ms of the closure

"Few" is a relative term here. This will depend on the switch type, the phase of the moon, etc.
Quote:

Places where bounce is a problem would be like entering text and its a pain when the key bounces and you get three BBBs in a row.

Yes, that would be a pin. But it is even more painFUL when your industrial app takes erratic action due to switch/input bounce.

Quote:

Next chapter will try to decide if it is better to debounce the key while waiting in a tight loop, or keep running the program, and how do you decide when the key is valid? On the first press, or the release or three passes with no release or ??

That's actually quite a few chapters.

We debounce all of our switches, and nearly all the digital inputs, in our industrial production apps.

None sit in a loop and wait.

Our scheme is very close to the one that danni has posted several times. I typically require 3 to 5 repetitions of the same value to consider it "made" or "open". The samples are at my system timer tick frequency. I've used 2.5ms, 5ms, and 10ms as well as a few values between.

The debounce scheme easily works in parallel. I usually have 8 or 16 or even more inputs and switches debounced in parallel. Each pass newly-confirmed rising & falling edges are easily made available. The whole debounce thing takes only a few microseconds.

I pop it into each new app as a matter of course, adjusting the timing and number of passes and width as needed.

Signals where each edge is important (e.g., quadrature encoder) have external filtering & Schmitt trigger buffers.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

madcitysw wrote:
I can not use the M103 mode because then the chip won't run with it on.

This is not the question.

Again, the question is, if the target work as mega128 or as mega103 ?

This was selected by the M103 fuse, so you must check this fuse !

The second question: which target was set to compile on your make file ?

The compiler down't know, which target you want, you must select it.

A complete code means, the code must be compileable and must still contain the problem.

It means not the code must be as big as possible and contain lots of crazy things and dead statements, which has abolutely nothing to do with the problem.

Its a sign of courtesy to make the code to your question as small and readable as possible.

Peter

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

Oh I see a little. The chip is set to run in mega128 mode and yes the compiler is also set to Atmega128 as well the programmer. Anyway I was able to get a pushbutton to work in the INT0 statement, but looks like I have to switch it to a timer instead in order to find out how long the button was pressed for, or is there a function that returns the cycle clock? In other words, how long the chip has been running.

PS: A friend has told me it would be better to write code in asm instead of C as you can get more program in asm in a chip. But it looks like asm is hard to learn. Is there a place where it lists all functions and what they do?

danni wrote:
madcitysw wrote:
I can not use the M103 mode because then the chip won't run with it on.

This is not the question.

Again, the question is, if the target work as mega128 or as mega103 ?

This was selected by the M103 fuse, so you must check this fuse !

The second question: which target was set to compile on your make file ?

The compiler down't know, which target you want, you must select it.

A complete code means, the code must be compileable and must still contain the problem.

It means not the code must be as big as possible and contain lots of crazy things and dead statements, which has abolutely nothing to do with the problem.

Its a sign of courtesy to make the code to your question as small and readable as possible.

Peter

Thanks
Shane

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

theusch wrote:
The debounce scheme easily works in parallel. I usually have 8 or 16 or even more inputs and switches debounced in parallel. Each pass newly-confirmed rising & falling edges are easily made available. The whole debounce thing takes only a few microseconds.

Hmmm, that does not seem to be many clock cycles. 3us = 48 clocks at 16MHz.

I can see that reading an entire port is fast, but then what? What logic are you using to determine if a pin changed state?

Read the port every 10mS then:

AND'ing the last 3 or 5 readings with each other? That will show which pins stayed high the whole time. How do you tell which ones transitioned high this time? AND this result with the inverse of the previous multi-AND result?

AND'ing the last 3-5 bit-flipped readings with each other might show which pins stayed low the whole time. How do you tell which ones transitioned low this time? Same idea as the other way?

-Tony

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

There have been very extensive threads on debouncing in the past. I've posted my code; so has danni. Here is one incarnation:

IOSCAN:	; GET AND DEBOUNCE STATE OF PORT C SWITCHES (6)
	MOV	TMPB,PCX2	; GET 3x PENDING CHANGES
	MOV	PCX2,PCX1	; GET 2x PENDING CHANGES
	IN	PCX1,PINC	; GET ACTUAL PORT C INPUTS
	LDI	TMPC, PCMASK	; LOAD THE INVERT MASK--ACTIVE LOW
	EOR	PCX1,TMPC	; INVERT SELECTED INPUTS
	EOR	PCX1,PCS	; GET CHANGES ONLY
	AND	TMPB,PCX1	; AND 3X WITH 1X
	AND	TMPB,PCX2	; AND RESULT WITH 2X
	EOR	PCS,TMPB	; MAKE 3X CHANGES
	EOR	PCX1,TMPB	; REMOVE 3X CHANGES FROM PENDING
	EOR	PCX2,TMPB	; REMOVE 3X CHANGES
	AND	TMPB,PCS	; GET ON STATE CHANGES ONLY
	OR	PCE,TMPB	; SET ACTIVE EDGE TRIGGERS

Edges & internmediate states are in registers. Yes, it is much less than 48 cycles-- 13? In fact, it is a few microseconds at 3.6864MHz.

Even in the generic case with 16 items and non-register intermediates it is still only a "few" microseconds--much less than any hanging around or ISR servicing overhead.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

madcitysw wrote:
PS: A friend has told me it would be better to write code in asm instead of C as you can get more program in asm in a chip.

Crikey, I'm surprised you got away with saying that!

That assertion has been subject to a LOT of discussion here in the past. Not everyone believes it to be 100% accurate!

Cliff

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

theusch wrote:
Here is one incarnation:
Lee

Thanks! I am not very versed in ASM, but this seems to be pretty clear. Except the PCMASK. WHat is that?

Also, I am not sure what PCS is.

It seems that this code gives a byte in which a "1" corresponds to a pin that is newly transitioned to high?

I presume there would need to be a matching routine to determine the pins that transitioned to low? Would this be most efficiently handled by doing the same routine on the value NOT PINC?

-Tony

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

In this particular app, some pins are active high and others active low. The PCMASK holds the needed inversion of the raw pin states for this app.

PCS holds the "current" debounced state of the inputs. PCE has the rising edges. If falling edges are needed it is one more step/holding register.

Nearly all my apps have one or more incarnations of this scheme, mostly straight C code. Some 8-bits wide; some 16. Sometimes more than one incarnation. Sometimes different rates or intermediate states.

The point is that it really only takes less than 1% of AVR processor to debounce a reasonable number of inputs in parallel using polling. Yes, it really can be done in a "few" microseconds every 10ms or so.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

LOL, you a funny guy 8), am I going to jail now heh? Well I started trying to write it in ASM, and it just very slower to get it written, that maybe because I never done asm. Do you believe that the statement is true or false?

clawson wrote:
madcitysw wrote:
PS: A friend has told me it would be better to write code in asm instead of C as you can get more program in asm in a chip.

Crikey, I'm surprised you got away with saying that!

That assertion has been subject to a LOT of discussion here in the past. Not everyone believes it to be 100% accurate!

Cliff

Thanks
Shane

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

As you are not a red hot asm programmer then stick to C, and learn about the micro. This ( learning the micro),is more important than the language you use. If in future you find yourself stuck for space then look at asm coding.

Keep it simple it will not bite as hard

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

i still can't get the pushbuttons to work.. connected the pushbuttons through 10kohm resistor to 5v.
Only one of the leds is lit when I push one of the pushbuttons, two are all the time off and other ones are all the time on, only one of the leds turns on while i keep the pusbutton pressed... What could be the reason?

Attachment(s):