Voting resources, early voting, and poll worker information - VOTE. ... Adafruit is open and shipping.
0

OCRA0
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

OCRA0

by stinkbutt on Tue Jun 01, 2010 4:43 pm

OK, so I've assembled the clock, I've successfully installed the light sensor and I've played around with a couple of the other firmwares. Now I'm looking to actually, ya know, understand what I'm looking at in the firmware instead of just changing a couple of defaults and then recompiling. So I have a couple of questions.

1. What is OCR0A? From what I can tell, the PWM on pin 12 (or is it PD6? Or is it both?) is controlling the duty cycle of the boost converter. Higher duty cycle means 1/(1-D) gets bigger and the voltage coming out of the boost converter (thus the brightness of the display) increases. But it just seems like magic in the code. Some random variable that's never been declared gets set and somehow the microcontroller seems to understand exactly what to do about it. Coming from an AVR newb who is trying to learn from examining the code, undeclared variables make the baby Jesus cry.

2. Why is it set eleventy gagillion times? The code appears to jump through a lot of hoops to avoid actually setting the OCR0A variable directly from a program variable. Instead, it looks at the program variable and sets OCR0A by hard code. Is there a reason you don't want to write stuff like:

Code: Select all | TOGGLE FULL SIZE
OCR0A = brightness;

or
Code: Select all | TOGGLE FULL SIZE
OCR0A = ( brightness - (brightness % 5) );


...instead of what's in the stock firmware? (see iv.c, lines 976-1002 1341-1367) There's quite a bit of hardcoded testing here that looks like it's accomplishing very little beyond making the .hex file bigger.

3. Why, for that matter, is there so much attention paid in the code to hedging against brightness being anything but a multiple of 5? I'm not asking why we wouldn't want that. There are good and proper reasons to ensure when someone changes the brightness of the clock it doesn't change infinitesimally. But why are you worried it might somehow end up as something other than a multiple of 5. There appears to be no way for the code to accomplish that. It's being stored and reloaded in EEPROM. Is EEPROM somehow untrustworthy under certain circumstances?

This might not be the appropriate forum for these questions. I considered putting them in the AVR Programming forum, but you don't really have one. It doesn't seem appropriate for the Arduino forum.
Red M&M, Blue M&M: They all wind up the same color

stinkbutt
 
Posts: 593
Joined: Wed Feb 17, 2010 2:40 am

Re: OCRA0

by adafruit on Tue Jun 01, 2010 4:54 pm

the only thing to watch for is that the brightness must be high enough to be visible or its impossible to fix

adafruit
 
Posts: 12151
Joined: Thu Apr 06, 2006 4:21 pm
Location: nyc

Re: OCRA0

by stinkbutt on Tue Jun 01, 2010 5:46 pm

adafruit wrote:the only thing to watch for is that the brightness must be high enough to be visible or its impossible to fix


Well sure. If the brightness goes too low you can't see the menu to change the brightness.

But why is OCRA0 changing the PWM to the boost converter to the voltage to the brightness?
Red M&M, Blue M&M: They all wind up the same color

stinkbutt
 
Posts: 593
Joined: Wed Feb 17, 2010 2:40 am

Re: OCRA0

by adafruit on Tue Jun 01, 2010 6:05 pm


adafruit
 
Posts: 12151
Joined: Thu Apr 06, 2006 4:21 pm
Location: nyc

Please be positive and constructive with your questions and comments.