Yep, I fixed the decimal point problem too-- we were using too much ram as well as flash space, when compiled with the new compiler.

See - I just gotta learn more! (and while I agree with what you said on the documentation thread, I *did* find some good books via google books that I've asked Santa about...

Anyway, you da man! I'll be trying tonight.

Thanks for your help!


Kevin

Oh - forgot to ask: what would be the impact of storing the strings in Flash, other than the 10k cycle limit?


Kevin

Windell - it works (mbr 2.1, avr toolchain dec 08)! Thanks so very much.

Now I have to put my geek hat on and learn the details so I know why!


Kevin

Quote by: q209

Oh - forgot to ask: what would be the impact of storing the strings in Flash, other than the 10k cycle limit?

The 10k limit doesn't really apply here-- you can read from flash as many times as you like, it's just that you can't go change the flash contents all the time without it failing.

So, in theory, one could use much longer and/or more strings... assuming you could keep someone's interest in reading longer strings.

A subject for experimentation... add a counter that would increment strings after 5 - 10 times, add .... hmmm.

8D


Kevin

You can also change it to use one *very long* string by incrementing the string number after each one finishes.

Hmmmm... a problem I noticed last night. Even though pin 8 isn't grounded, all I get is string set 2. If I tie 8 to the high rail with a 10k resistor on startup, it works (reads bit_is_clear as 'no'. I've checked with my VOM; pin 8 on the breadboard is floating. Suggestions?

By the way: a good source of AVR (and GCC) reference material: http://users.rcn.com/rneswold/avr/


Kevin

It's sometimes possible that a *weak* connection to the pin is enough to pull it down-- dirt, flux, and fingers can all work. I haven't seen an example of the problem that wasn't actually due to external influence.

As far as the voltmeter goes, that's not a useful test unless you've made some changes to the firmware: It should go high for something of order one microsecond total.

In your case, I bet that it's the *breadboard* that's causing the problem. Breadboards have a lot of capacitance, probably too much for that pin to get all the way high in one microsecond.

Where it says in the code

Try changing that to about 5 or 10 lines of the same instruction-- up to the limits of your memory. See if that makes a difference.

Trying to let it stabilize with nop's doesn't seem to work (used 'shortdelay'. Then again, my breadboards are decades old! My newer ones currently have other micros living on 'em. To be honest, though, I don't think I've ever had a stable tri-state pin without a pulldown or a pullup...

I intend to solder in a switch (once I pick up some 20 pin sockets) to flip between the display modes. I'll probably install a dpst, so I can always put in a 10k resistor if needed. No biggie.

If you don't mind, what does this do:

PORTD |= _BV(PD4); // D4 High

I should say "why", rather.

Thanks for all your help!


Kevin

Breadboards are hell.
http://www.national.com/rap/Story/0,1562,8,00.html

>PORTD |= _BV(PD4); // D4 High

That sets pin D4 to be high. Since pin D4 was defined as an input when that line executes, it actually enables the internal pull-up resistor, which is a weak 10k resistor to the positive voltage rail. This pulls D4 high *if* it would otherwise be floating, but is too weak to pull it high if it's (for example) hooked with a wire to ground.

My. My! Didn't know they were *that* bad - it would explain some problems I've run into before!

Well, heck, they're still good for low freq analog...

So I guess the internal pullup will be good enough when off the breadboard, and all I'll need is a spst for string switching.

Thanks again!


Kevin

Kevin, just in case you are still interested in old WinAVR - get it from http://sourceforge.net/project/downloading.php?group_id=68108&filename=WinAVR-20070122-install.exe&a=36802473