@Kortuk Oh? Is there a reference for that? I don't understand why a normal SRAM variable should be treated differently than register variable for the purposes of access/update.
@angelatlarge Registers should be volatile because their value can change outside of normal program execution. Internal SRAM is only accessed via code, so it can be non-volatile.... the exception that comes to mind is variables accessed in an interrupt - those need to be volatile as well.
What does the register keyword do in C? I have read that it is used for optimizing but is not clearly defined in any standard. Is it still relevant and if so, when would you use it?
@W5VO But in any case, I found some other problems with my code (stray leftover break from when I had a switch(), so I might be wrong on this volatile thing.
The point of register is to suggest to the compiler that it should optimize the use of that variable. The volatile keyword makes sure that reads and writes to a variable are not optimized out
I think you guys are talking about two kinds of registers. The register keyword means to keep a variable in quickly-accessible location rather than in main memory. There's no reason this kind of variable needs to also be volatile. When @Kortuk said all register variables should be volatile, I think he's talking about peripheral control registers and things like that, which might be changed by the hardware outside of the control of your code.
@ThePhoton Here some TJ's beers are Unibrowe (which is fantastic) - they are based out of Montreal. But this is for higher-end beers. I but the $4/sixpack kind :)
@W5VO I suspect not everyone will agree with you on that. I imagine a few people might prefer -4 votes, closed question in 10 mins, plus a couple of Mr T-style comments.
@angelatlarge fyi, you can go back and edit your posts here for a minute or so after you post. Click near the left of your post for the drop-down menu.
@angelatlarge no, he is asking the close migration button have sites on it. wait, let me check, maybe I misread.
They asked for me to pull the same stats as before again.
@angelatlarge look at the picture he shows of another site, that is the close menu.
I think the flag, this is off topic should migrate to... xxxx is a good idea, you can select anything, then we can compile stats on how often the community suggests it.
so i definitely missed the flagging part, that is an issue with me never seeing the flag menu, sorry about that @angelatlarge and thanks for clarifying.
@Rick_2047 No, I had a friend come over and the work calls started not long after that. I meant to get the time from chat but never got to it with people over and such.
@Rick_2047 it was only maybe 10 or 15 people away at 11am.
it had enough net members, it just needed 10 or 15 more with at least 200 rep on network.
@Rick_2047 I think people believe I hate the site or something. I just think it is a duplicate and will be bad for this site and not be that different, but I also dont think I am always right, we all make errors, and luckily I dont have to be the one under the gun on this decision.
@Rick_2047 but I assume it is more complicated then that. How do you really decide if it is duplicate, and then would removing it really just move the community over. Dunno, I like leaving things like that for the SE team to decide.
@Rick_2047 my written skills always need help. I am a very sociable person, I like talking to new people and generally become friends with people all over, but expressing a technical point clearly can be much harder from my perspective.
Can anyone tell me what am I doing that's stoopid? Why are my LED drivers only producing output when I hold the BLANK line in my hand: not when it is LOW (like it is supposed to be to NOT blank), nor when HIGH (that's one's expected). What am I missing?
@Kortuk YOu think the led driver might need a decoupling cap? I don't get why would my body capacitance help
@PeterJ Yeah, the clocking of that thing is a PITA. I set a fuse on my AVR to output it's internal clock on a pin, and that is how GSCLK is driven
@PeterJ Or should be... I am double-checking all the pins one by one, about to check the GSCLK
Yeah it is connected to ATmega328 pin 14, CLKO
Maybe I should mention that this is actually 3 TLC5940s. The BLANK line is shared. In fact all the lines are shared except for SIN, which is daisychained.
And they all turn on when I fondle (@Kortuk) the BLANK line
@angelatlarge Do you have a scope to see what those clock lines look like? I had a vague idea that the CLKO had something odd about it, although looking at the datasheet it doesn't seem to back it up, maybe I'm thinking of another processor
@angelatlarge, I'm thinking of something I did years ago, but I can't remember if now if it was an AVR or something else and possibly I was using one side of the XTAL oscillator not CLKOUT. Looking further for the ATmega328 it looks like it's all buffered just like any other I/O line.
@angelatlarge Here is some unsolicited advice: Separate the problems. In this context, that means drive the TLC parts slooooowly using some separate code, injected by any means you can, since the TLC can be run at slow clock speeds. See if the issue exists / persists. Then get back to your high speed code.
@angelatlarge Try separating the problems nevertheless. Divide down all relevant clocks if you must, after the isolated testing. That way a bus pirate can help you diagnose if there still is a problem.
Then, bring the clock and data speeds back up, see if there's some interference, coupling etc happening due to signal toggle speed. Also, decouple each chip heavily close to its Vcc / Gnd. If you have LEDs hooked up, a turn-on is bound to dip the chip's power noticeably.
@angelatlarge Assumption is the mother of invention - not!
@angelatlarge touch = go implies decoupling as first thing to check. Both Vcc decoupling, and caps on the lines that aren't supposed to switch around. They could perhaps pick up noise.
@PeterJ My reasoning for avoiding Timer0 is, many third party libraries default to the first timer, so I prefer to leave that for something that comes up later.
@PeterJ It's not arduino-specific, I use the same rationale for any MCU - don't use the first available resource if the second / third / n'th would serve my purpose, thus saving effort later if I want to use someone else's code that hasn't been so considerate :-)
@PeterJ Friday 13th, I don't even understand why people consider it special. Full moon, different story - it's my favorite night of the lunar cycle for night photography (Google my name, you'll understand the context).
@PeterJ I've posted a couple of moon images shot with 500 mm lenses, but it's not images of the moon that interest me, so much as images in moonlight. I specialize in available-light photography, both for my commercial work, and for my exhibition imagery.
@AnindoGhosh, love some of your artistic work. I catalog my photos about as well as I comment source code but here is about my best attempt at a moon shot I could spot, not as crisp as yours... i46.tinypic.com/6rn2o9.jpg
@PeterJ nice. The moon naturally looks a bit more yellow, I hate what digital camera AWB does to it. One of the few situations where I still prefer film.
I've used film before but at that stage growing up given the cost of developing wasn't really into photography much other than the usual holiday snaps. Agree though even with new DSLRs AWB (and all other auto things) aren't so good so as I learn more try and do everything as much manually as I can.
I've got great respect for film photographers. It's nothing now to fire off a few thousand shots for a handful of 'keepers'. Guess now it costs $10 (shutter actuations etc) not the thousands before it would have taken to try
@CamilStaps thermal runaway is when two diodes (eg. LED's) are in parallel. One takes a little more current than the other and heats up a little. Due to that the current will increase and it will heat up a bit more. So one diode is 'stealing' current from the other one and the balance gets worse and worse and worse ...