You probably know these EL tee-shirts like this: http://www.t-qualizershirt.com/

Anyone know if you can buy the ink/paint somewhere and DIY?

If you are still stuck, I will give you everything I use: exact avrdude commands, fuse bit files, and boot rom.  You can try it to see if it works.

Just to fill out an old thread with another answer:

If you are doing this in a file that is NOT your main one, then add the same #include to your main file (the one with loop in it).  Amazingly the include file suddenly is found in all files.  Total guess but I think that the Arduino IDE is trying to be helpful by scanning your sketch and automatically adding -I lines to the compile.  But its not doing so for all .c and .h in your sketch so it ends up outsmarting itself and confusing mere mortals like you and I.  :-)

@MikeMc -- are you saying the M5451 works EXACTLY the same as the 595 (ignoring the physical differences of course)?  That would be interesting because it would mean that my arduino M5451 library would also work with the 595s...

Its probably too late, since you said you only have 2 days left, but I've had good luck with the M5451 chip, which does 35 constant current switches each.  Each chip can handle 1 watt total so that sounds like it might meet your power requirements.  Actually, you could probably put a heat sink on the chip to drive it even higher :-).  

See my blog:
http://effluviaofascatteredmind.blogspot.com/2009/02/arduino-and-m5451-control-35-leds.html

and also a conversation in exhibition:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235795499

Heh... check out http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1270564546/0.  I did mine Mar 19, you did your Apr 03.  Before that no bootloaders were under source control!  BTW, check out the poll... 58% of the people (not many so far) don't know what a code repo even is :-(.  Bummer for us!  Hope you don't mind if I dig into how you slimmed yours down and incorporate some changes!  You are welcome to take my "pin 13 fades while waiting for DL" or my "double click reset for extra long DL" features if they will help you!

thanks!  Totally fascinating that after no bootloaders in the repo, there are now 2.  I created my project Mar 19, he created his Apr 03!  Wow.  

Please send me the links if you can dig them up -- I did a quick google search for "small arduino bootloader" and got nothing.

Thx!

Interesting...I'll see if I can merge it in!

Good idea, I'll put a link in the playground.  And of course if other people have created bootloader variants -- in my digging I ran into some cool stuff -- I'd be happy to give you svn access and you can put it up there with mine.  Of course, its not hard to create your own repository either... but as cr0sh says it might be nice to have them all in one place.

Do most people here know what a code repository is?

Hi everyone,

I needed to flash my own bootloaders a few months ago and I quickly realised that its a pain to find what is out there.  It seemed like Adaboot never got into a repository and then it was modified and people just had links to tarballs on their web sites.

So I finally found what I thought was the "latest" and was using that.  But a few weeks ago I decided to make some modifications.  So I threw it into a google code repository for better tracking:

http://code.google.com/p/toastedboot/

You can either get the source from there, or you can grab a prebuilt 328 image.  I needed to build both 16 and 20 mhz versions for my Lightuino LED Driver board so I threw them up there for all to use.

The major modifications I made are mostly useful for clones that require you to press the reset button to upload:

1. PWM fade the pin 13 LED while waiting for a download.  This way you know when you missed the window.
2. Reset double-click.  If you double click the reset button it waits for a download for a LOOONG time.  This is really convenient when the board is not right next to the computer.
3. A lot of code refactoring for size.
4. All the Adaboot fixes and features of course.

Regards,
Andrew

Any possibility that some high voltage (like the raw VIN voltage from the wall wart) got on the 5v line?

Sorry to exhume an old topic, but I had the same issue and instead of using an LDO regulator, I just used a red LED in series since it drops 1.7 volts.  On the breadboard it works.  Anyone see any problem with this solution?

@grumpy_mike:

You're right that the hertz can be lower.  But don't forget that old-style CRT TVs had a phosphor that glowed for longer than the beam illuminated it.  So maybe the duty cycle was quite large.  In fact given that when the TV is off you can STILL see the phosphor glowing a little bit, the duty cycle on a CRT TV is very analog -- its never completely off.   I think that this would make a big difference.  From my experiments, as the duty cycle goes down, the hz must go up because its a lot easier to perceive blinking at 10% duty cycle than at 90%.  

BTW, I heard that 200 number as a minimum from an architect specializing in LED lighting... so its just hearsay.


WRT cycle counting... nope I didn't count them.  Its pretty hard nowadays with pipelining and all... and its boring.  But because you spend so many hours helping us all out, I'm going to reciprocate and give a little rough counting a try! :-)  Here's digitalWrite:


void digitalWrite(uint8_t pin, uint8_t val)    // Fn call + 2 vars = 3
{
        uint8_t timer = digitalPinToTimer(pin);  // macro so only push,add, and mem ref = 3
        uint8_t bit = digitalPinToBitMask(pin);   // = 3
        uint8_t port = digitalPinToPort(pin);     // = 3
        volatile uint8_t *out;  // push = 1

        if (port == NOT_A_PIN) return;  // test and jump = 2

        // If the pin that support PWM output, we need to turn it off
        // before doing a digital write.
        if (timer != NOT_ON_TIMER) turnOffPWM(timer);  // test not taken = 2

        out = portOutputRegister(port);  // add and assign = 2

        if (val == LOW) *out &= ~bit;  // if, deref, read, not, and, assign = 6
        else *out |= bit;
}  // return: pop, jump = 2

So adding all of this up we get a count of 26.

Let me guess a single clock and data cycle is CLK_HIGH, DATA HI OR LOW, CLK_LOW.  So that is a total of 26*3 = 78 counts.  I feel that this is very conservative because I am assuming that conditions, jumps, memory access, etc are all one cycle AND because I didn't dig into all those macros that carefully and gave the compiler the benefit of the doubt.  For example, there is some data type casting in there which could result in a unnecessary copy.

So if the OP uses register access the cycle count is 3 instead of 78 to clock one bit in  (Actually if the clock is in the same register as the data, you could reduce the count to 2).


Now, if the OP switches from chained 595s to parallel then he's clocking in 8 of these at a time.  So instead of 78*8 = 624 counts he is doing 3.

Let's say the OP uses all 16 digital outputs.  15 for the data and 1 for the clock.  So instead of 78*15 or 1170 counts, he is doing 4.

Now let's unroll the final outer loop.  So I'm guessing it looks something like:

for (i=0;i<NUMSHIFTS;i++)
{
   ClockItOut();
}

So that loop itself does a test, add, and jump (say count 3) and NUMSHIFTS is for a 64 by 16 matrix or 80.  So that's another 240 counts.  So lets add that to the 80 bits * the 78 count is 6480 clocks.

Now that 64 x 16 matrix is 8 x 2 chips.  So we can simultaneously clock 10 chips.  And we need to do that 8 times.  So that would look something like:

CLK_HIGH and write 2 registers = 2 counts
CLK_LOW = 1 count
(and cut and paste that 8 times)

So you get a total of 24 counts.

So the back of the envelope calculation shows a speed up of 270 times.

Sure that's on the low side of my estimate.  But we haven't even really dug into the ugliness... for example a quick look at shiftout() shows this gem within the 0-7 for loop:

                if (bitOrder == LSBFIRST)
                        digitalWrite(dataPin, !!(val & (1 << i)));
                else
                        digitalWrite(dataPin, !!(val & (1 << (7 - i))));

Now I don't know about the AVR but back when I was counting cycles a decade ago, lots of uCs handled the bit shift operation in 1 bit shift per clock (1<<7 takes 7 clocks).  Ergo, this if statement and all that val munging adds a LOT more cycles than my estimation.

But, you know, I didn't think all of this thru before posting.  It was simply apparent by comparing what the OP said his matrix was doing with what I'm getting out of my M5451 library.