NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.
Support Forum » atmega168 PD4 (pin 6) dead?
December 29, 2012 by keith712 |
here's my latest problem... i received my original nerdkit back from a friend with the comment 'it broke'... i rewired the kit including a brand new LCD... i compiled and uploaded a version of initialload that i've modified to blink an LED along with the 'congrats' message... in run mode the LED blinks but the message does not display... the new LCD shows a quick flash but no message appears... i then wired up my original LCD to the kit... it displays two black bars in both the program and run modes... i'm convinced my code is OK so i thought of a way to test my kit: i disconnected the LCD and put six LEDs on PD2-7 (pins 4,5,6,11,12,13)... i then wrote a test routine which set PD2-7 to output and then turned the LEDs on and off in a pattern... it turns out that PD4's LED wouldn't light up... i double checked the LED's polarity and i swapped LEDs around but it's always PD4 that's dead... i'm pretty sure that this problem is unfixable but i'd welcome any comments/suggestions... plus i wanted to pass on my crude but seemingly effective hardware testing technique... keith |
---|---|
December 29, 2012 by pcbolt |
Keith - That is a good test. I would go one step further and jam the leg of the LED into the same breadboard hole as the MCU PD4 pin. I've had breadboards that are finicky that way. You could try using PORTC instead of PORTD for the LCD. You'd have to revise the "lcd.c" file in the "libnerkits" directory just make sure you make a copy of the original. |
December 29, 2012 by keith712 |
thank you thank you... i would never have thought of either of those two test... i'm going to try right now... later, k |
December 29, 2012 by keith712 |
i managed to jam the leads of two LEDs into PD4 (pin 6) and PD3 (pin 5) with the same results... pd3 is alive and pd4 is dead... i've started translating PDx pins into PCx and PBx pins to modify lcd.c... i may have drank too much wine for this but here goes... k |
December 29, 2012 by keith712 |
update: i rewired my kit to drive the lcd with PC0-5 pins... i rewrote lcd.c to use the PCx pins instead of PDx pins... initialload and the new lcd.c compiled on the first try!!! sometimes i surprise myself... the output was just as expected on one of my lcds... my other two lcds are broke... one only displays two black bars no matter the mode and the other shows two black bars in program mode but is blank in run mode... if anybody's interrested in my rewrite of lcd.c i'll post it... anybody know anything about fixing lcds or is it better to put them out to pasture and buy new ones? |
December 29, 2012 by keith712 |
i forgot... how about my broken atmega168?... is there a fix for dead pins or do i just work around it? thanks... k |
December 29, 2012 by Ralphxyz |
I have been fighting with the two black bars scenario for a couple of months now so I'd appreciate seeing your rewrite of lcd.c. re your "broken" atmega 168 I would start from scratch completely strip the breadboard and try to load the initialload project as directed in the Nerdkits User Guide. Ralph |
December 29, 2012 by Noter |
There is no fix for a dead pin on the mcu. Probably you will want to get another chip because PCx is the ADC and you will not be able to do the adc projects with your display on that side. It's a good idea to have a few extra chips anyway just in case you accidentally fry one. And sometimes its good to swap the chip to be sure it's not a problem in the breadboard or some other unexpected thing. If your display's are broken for sure might as well dissect and then pitch them. If you're not sure then hold on for a while until you have another setup to test them with. I've also found that different makes of displays typically need a different contrast resistor so maybe the one that looks blank needs a contrast adjustment. |
December 29, 2012 by keith712 |
below is my modified lcd.c... this didn't fix the two bar lcd or the blank lcd but it allowed me to check my lcds and that led me to the dead PD4 pin on my mcu... do you think i should try increasing or decreasing the resistance of the contrast resistor? thank you guys for keeping an eye out for me!!!
|
December 29, 2012 by Noter |
Decrease the contrast resistor. For a quick test, leave it out and go straight to GND if it's still blank then contrast is not the problem. Your change to lcd.c looks good. It would be useful to fix it to where any mcu pin can be used for any lcd pin instead of restricting to a single port. |
December 29, 2012 by pcbolt |
Sounds like you're throwing down the gauntlet, Noter :-) |
December 30, 2012 by keith712 |
i thought about using a mix of PCx and PBx pins but by staying in one port i can take advantage of setting or clearing several bits in one register in one line... i'm going to take up the challenge and generalize the code for any combination of pins... maybe i could do something like this:
i assume that lcdn and DDR+get_register() will be string types... so i need to find out how c evaluates a string expression to a value for the compiler... let me know what you think... |
December 30, 2012 by keith712 |
its getting late... i screwed up the examples of bit setting and clearing... it should be something like:
|
December 30, 2012 by Noter |
Didn't mean to challenge in any way but rather just give some ideas that will be useful in the future as well as a opportunity to learn more about the avr and programming in c. I reference the AVR Libc site quite often as it is full of good information and in the FAQ there is an example of passing an I/O port to a function - How do I pass an IO port as a parameter to a function?. Not only will it be convenient to move a pin at a time but you will really appreciate the flexibility if/when you move to another chip, maybe like the ATmega32U4. And until then you could just clean up the ratsnest on the nerdkit which can help with loose wires/black bars and such in the long run. |
December 30, 2012 by keith712 |
i was saying challenge with tongue-in-cheek... i need to use emoticons more... but you're right... this is an excellent opportunity to get more familiar with c and atmega168 io... i may not look at your links until after i have code that compiles, runs and does what i expect and then compare my amateur hack with the library's solution... by-the-by... the above won't work unless i write an eval routine for c... which i'm not capable of plus i'm guessing would use more memory then the whole nerdkit's library... i'm spoiled by avoiding c and working in "higher level languages" (lol)... |
December 30, 2012 by Noter |
Great! You'll like c once you get up to speed with it. One thing to think about is because the pins remain fixed a dynamic type eval in code is not needed. C has preprocessor directives that do nicely in this situation so all the work is done by the compiler and renders a single instruction for manipulating bits at runtime. |
December 30, 2012 by keith712 |
i have a lot to learn... i don't know anything about fixed vs dynamic typing and i know just enough to get in big trouble with makefiles... your comment about compiler directives confirms my suspicion that my code will be a brute force effort and that i might come up with a much more sophisticated algorythm once i understand more... i've been having fun this morning... here's what i've come up with so far... i haven't dared try to insert the following into a copy of lcd.c, modifify lcd.c to use it and compile... i'm hoping you or anyone else who's interrested have some time in the next few days to scan this for blunders or worse...
|
December 30, 2012 by Noter |
It looks like it will work but you should test it before putting it into lcd.c. Make a little test program that uses these new routines to blink an led on some otherwise unused pin. Then if it works as expected you can make the mods to lcd.c and feel pretty confident about it working. |
December 30, 2012 by JimFrederickson |
One thing that I don't think has been mentioned in this thread is "save often". I would recommend against just "Continuous/Timed saves", (i.e. Continuous saves of every iteration of any file that is changed, or Timed saves of any file at specific time/interval.) The chief problem with saves of that nature is that you are NEVER making all of your changes simultaneously. Often, especially with Libraries, you need to make multiple changes in multiple files for a specific purpose. So if your saves are "Continuous" you will need to sort out "which files need to go together for that purpose"... (Potentially a huge problem, and just an added difficulty that can be avoided.) What generally works best, long term, is treating your program development as a series of steps/plateaus, (whichever metaphor works best or you.) Make sure to take time to test at each step/plateau well too. Steps/Plateaus should be ONLY known working code, not necessarily code that has all of the desired functionality but code that does reliably run. That way if you are adding a new function/capability to your code and run into a problem you can save your current source directory as a "failed" or "bad" source directory and then restore from the last known good step/plateaus. Then you can slowly re-add the portions of the code you changed that are problematic to the known good step. For me the "saves" that I make are not truly "Versions" as I treat a "Version" as a special case of a step where the code is complete enough to go into production/use on my project. I, personally, would test/develop your new LCD.c code on a circuit wired as required by the Nerdkit LCD.C Library with a known good Micronctroller too. That way you have "known working code" that can be written to the Microcontroller in case something in your code doesn't work. As it is now, as you are developing your new LCD.c code you potentially will not be sure if a problem is in your new LCD.c code, in the Microcontroller, or the Wiring/Components of your circuit. |
December 31, 2012 by keith712 |
thanks... i'm glad i held back... i keep a separate folder with all the original source code that i downloaded from the nerdkits people... i also keep a 'diary' of dates and changes i've made to files but most of the entries are changes to makefile... i've never kept copies of my intermediate attempts... i've always just kept fixing code, optimizing and adding comments until i'm satisfied with the output and how the code would 'read' to somebody other than me... i think this is exactly what you're warning me against... is this procedure a solution:
so i'm off to write an led_blink routine that uses the functions above and set up a project folder to keep this stuff in... i better write a read_me file to explain all this stuff to myself... |
Please log in to post a reply.
Did you know that an electroluminescent backlight for an LCD panel requires hundreds of volts AC to run? Learn more...
|