Simple question. I'm trying to use some pins for lights but ran out due to the LCD taking up most of the pins on the left. Can I use Pin 1 (reset) PC6 for an LED? Same question for pins 2 (PD0) and 14 (PB0) I remember reading somewhere that the chip becomes inoperable if a specific pin setting is changed.... ?

Also, if that should happen, is there a way to hard reset the chip to default (no bootstrap)?

Thanks

Al

The reset pin cannot be used without modifying fuse settings. Modifying fuse settings cannot be done via a bootloader. To do it, you would have to have either an ISP or High Voltage programmer. Once this fuse setting is done, the reset pin will no longer function as reset and thus the ISP method of programming will not work to change it back. Only high voltage programming can reset the fuses after that. Bootloader programming Via the NK bootloader would most likely still work as described in the guide. CHANGING THE RESET PIN FUNCTION IS NOT RECOMMENDED

Pins two and three are used for serial communications. If your program does not need serial communications, then you can use those pins freely for other tasks. Keep in mind though, if you want to transfer a program you may have to disconnect the circuitry connected to those pins during the transfer.

Rick

Pin 14... forgot that one... It can be used like 2 and 3. However, depending on what is connected to it you may have issues with the bootloader. For instance if the circuitry you connected pulled the pin low, the chip would boot into program mode instead of running your program.

Rick

Ok, so to keep my designs simple I should stay away from pins 1 and 14. No problem at all.

If I can use pins 2 and 3 (RX TX) for other functions (say, an LED light low to high), once I pull the chip out of the socket and try to re-program it, wouldn't the communications functions not work? Just verifying. My project needs every pin possible.

Thank you again for your excellent and quick responses.

Al

Hi amartinez,

Pins 2 and 3 are taken over by the UART module when you turn it on (which the bootloader does). In your code you can explicitly turn the UART module off which will allow you use the pins as normal I/O pins. This will not affect the bootloader in any way, it activates the module when it starts up. Like Rick pointed out, any circuitry you have connected to the pins will affect programming.

Humberto

As always. Much appreciated. I have to tell you that you guys have the absolute best learning system here. I'm a very happy camper.

Al

Al, also some people have used 14 (PB0) without problems. I have had problems trying to use it but then again I really do not know what I am doing I am not that experienced as a programmer.

There are a lot of neat functionality on Pin 14 like a built in button debounce routine which might be handy.

So I would try using Pin 14 PB0 also.

And then of course if you need a lot of input and output you can look at using I2C. Here is Rick's I2C LCD project using a port expander and here is Inino's io_expander project. And you can talk with Noter about using multiple mcus so you would have lots of pins available.

So what are you doing that you need a lot of pins?

Ralph

Hello Ralph,

Button debounce? Button as in a pushbutton? I have to look in to that. I see Pin 14 has CLK0 and ICP1. (and I thought EE and IT was acronym hell.... ooh the pain) :)

I'm not at the I2C level yet, isnt' that in the Marquee project? I'm still trying to grasp this hardware communication with my other MCU but I keep seeing the I2C as a solution so thank you for pointing me to a great video and some code. Very much appreciated. I will be using this as well. As Humberto says, "one step at a time". Thankfully I have about 3 hours a day to devote to this.

What I'm doing is putting the Atmega 168 through all its paces so that I can learn this new world of electronic design. I love programming and electronics and this is a shoe in for me but I've been out of the EE design phase for quite a while so it's taking me time to get back on track, plus, this is a steep learning curve for me. As they say "it's not your Granfather's C".

I'm working on an LED voltmeter utilizing large LEDs to produce numbers. I know I can use other conventional LED sets that look more like your standard LED readout but I like to make unconventional looking stuff. I purchased more 168s and got some 328s on back order. My next challenge is bootloading and I know Rick put out an excellent post on how to do that.

Thanks for your help. As always, much appreciated.

Al

On "built-in button debounce", it will take code to implement debounce in software no matter which pin is used for button input. You can use ICP1 to get a timer value but that alone doesn't debounce, it still takes extra code.

There are several forum threads that talk about debouncing a button. Search on "debounce" and you'll find them. One references a hardware debounce using a capacitor and resistor which I think is a good way to go about it because it requires no additional code to debounce.

Well according to the friendly manual there is automatic filtering available, at least for a 4 successive equal value count on PB0 pin 14 ICP1

15.11.2 TCCR1B – Timer/Counter1 Control Register B
Bit 76543210  (0x81)    TCCR1B

Read/Write  R/W R/W R   R/W R/W R/W R/W R/W InitialValue 0 0 0 0 0 0 0 0

 •  Bit 7 – ICNC1: Input Capture Noise Canceler
 Setting this bit (to one) activates the Input Capture Noise Canceler. When the noise canceler is activated, 
 the input from the Input Capture pin (ICP1) is filtered. The filter function requires four successive equal 
 valued samples of the ICP1 pin for changing its output. The Input Capture is therefore delayed by four 
 Oscillator cycles when the noise canceler is enabled.

Now that might not be enough filtering but it is a good place to start.

Also if I2C was used with a port expander in input mode because the interrupt is trigged on the first high

wouldn't that negate having to debounce the switch.

And optical encoders do not have to be debounced.

Of course debouncing switches has been hashed around so much in every programing forum on the Internet it really isn't that difficult to find a method to ones liking.

Ralph

Hey Ralph, that is interesting, please post your code when you get an automatic debounce working on pin 14.

Here is where it was discussed, also there is words of wisdom from Mike about using PIN 14 in this thread.

I was using a photo transistor to generate the pulses using huzbum's modified code.

There has been a few discussions about ICP1 here in the Nerdkit's forums also.

I need to get back to my Weather Station project, it started out as just wind speed and has morphed in to a full weather station complete with I2C EEPROM data logging thanks to you.

So I "should" be revisiting my RPM code in a couple of weeks or at least that is the plan. I am intending to use the ICP1 filtering. I might not strictly need it, I do not believe there is any bounce from the photo transistor. I was also going to add a hall effect sensor just to learn how they work but the hall effect sensors I got do not make any sense or at least I could not make any sense out of their output. Of course now I have my oscilloscope so I might be able to look at the output and maybe figure out what is going on. I could not find any specsheets for the hall effect sensors so I did not have much luck with them.

Of course I had problems using Pin 14 but Mike says that it should be usable as long as you do not pull the pine low at startup.

Ralph

Ok, thanks.

I think if I was going to use pin14 for other than a simple test I would modify the bootloader to use a different pin for the programming switch so I wouldn't have to worry about it at startup. Or not use the bootloader at all.

BTW, some of the hall effect sensors are open collector and need a pull-up resistor on the output pin. Maybe that is giving you some trouble with readings.

Yeah, if I did not use the bootloader than my program ran without error but if I had the bootloader working it would not run which is why I said in the thread that Pin14 could not be used. That was obviously corrected by Mike. My pulse from the photo transistor was making a high at startup so it should have worked. Or maybe because the photo detector and the mcu were being powered on at the same time that Pin14 was pulled low.

I thought about modifying the bootloader that would make sense. There seems to be a lot of native functionality available on Pin14 and it seems a waste to not be able to use it. But then again we should be able to use it even with the bootloader installed.

Hopefully I'll be able to play around with Pin14 in a couple of weeks when I am working on my wind speed measure.

I'll play with the hall effect sensors again sometime.

Ralph

Ralph, anyone,

I need more pins. I'm now ready for the next step. I2C / TWI. The last pins on the Atmega 168 can control a separate chip. All I want to do is control more led lights to go on and off. What's the best chip for that? Pin count should be at least 14. I've done some research and looked at some chips but now I'm crosseyed. I need help.

From what I gather the 168 is able to send commands to the slave chip through the TWI interface. I read the posts on this forum but they go off to a tangent I cannot follow as it does not apply to my little project thus far.

This is why I originally asked about programming pins 1, 2 and 14. I just need more ding dang pins...

Thank you

Al

Al you should look at Inino's io_expander I2C code.

You would need a port expander ic. One port expander gives you 16 input or output pins plus I believe you can have eight of them

giving 128 pins.

Ralph

An alternative to the port expander is to use another ATmega and let it supply the extra pin functionality. Additional mcu's will give greater capability and flexibility too. For example, if you decided you needed an extra ADC or PWM pin you'd have it if you use an extra mcu. The trade off is that you do have to program the additional mcu to provide the functionality needed. You can get started with this I2C master/slave example if you want to give it a try. Or you could use SPI instead of I2C/TWI and start with this SPI master/slave example.

Noter, I really like your idea. I may implement it.

It's been a while and I have been doing a lot of research off line and found that using another Atmega 168 would be better for my particular application. Ralph, thank you for the great info too. I'm working on other projects which will take me in to this realm eventually.

Just having fun here. Got the time.

Thank you all

Al

Hi Al, I think using another mcu would be a fabulous thing to learn how to do. The utility of having another programmable device is awesome. Noter has done a great job of documenting setting up the I2C and SPI Master/Slave. Currently I am doing everything using I2C but I can see where SPI might have it's advantages.

Keep us posted.

Ralph

Will do Ralph, at present I am working on getting the LCD out of the way. I posted another thread entitled "Writing to hyperterminal". I'm posting my findings there. Good stuff.

I wish there was a way I can view my posts rather than searching. Not a big problem, just lots to keep track of.

Thanks again

Al

[quote]I wish there was a way I can view my posts rather than searching. [/quote]

Yeah this forum app is kinda lacking in certain respects, like not having "quotes".

When you are viewing a thread there is a "Manage all my subscriptions buttons" that way you can see all of your threads as long as you subscribed to them. I think subscribing is a option. You have to be viewing another thread which is kinda dumb. It would be nice to have that option at the top of the forum page but at least it is there.

Ralph

That worked. Thanks Ralph.

I really appreciate this forum and your help as well.

Al

As I have said before, the reason I am here is because of the forum.

Ralph