Forum Replies Created
-
Posts
-
Generally, you can replace any of those LED colors with blue or white, and it will still work, and be safe. If it is using a low voltage to drive the LEDs (say, 3 V), the LEDs will not light, but that’s at least a safe failure mode.
Shouldn’t be so bad, but learn to do that desoldering first on something not-so-critical.
The risk of not changing resistors is that you can potentially end up with an overdriven LED that could burn out.Step 1 is correct.
The ZIF socket is for ATmega48/88/168/328 and ATtiny25/48/85 (with one wire added). For other AVRs, you need an external target board.The correct process to use for programming depends on what environment you’re using. We use AVR-GCC/Avrdude straight from the command line. If you’re using a hacked version of Arduino instead (as I’m guessing you’re referring to), then you need to follow the appropriate directions for that environment. Standard versions of Arduino do not support the ‘2313/’4313.Yes, of course. The ISP Shield can be used to program any AVR microcontroller that has an ISP interface.
We don’t advertise it, but there actually *are* 16 “built in” modes in the default firmware, rather than 8, and so there actually is already a built-in “GUI” (if we dare call it that) for selecting between 16 modes.
The additional 8 modes are officially undocumented and unsupported, but they are available for you to either use, or to replace with custom programs. These modes, (8-15) are called the “network modes” because they can share information over the edge connectors.To enable these modes, hold down the button for a long log time, to get to a selection menu that will let you pick between the network modes and the non-network modes. (IIRC, there’s a center square, to indicate local modes only, and a circulating pattern, to indicate network modes enabled.) When enabled, there are 16 possible selections, rather than 8. The second 8 are indicated by blinking LEDs instead of steady.The response functions are given by the “ledhandler”:ledHandler ledHandlers[] = {
basic_fade, // 0
slow_fade, // 1
quick_fade, // 2
sine_fade, // 3
sparkle_fade, // 4
heat_fade, // 5
inv_fade, // 6
flash_fade, // 7
// net + fade
basic_fade, // 8 — all boards
slow_fade, // 9 — all boards
basic_fade, // 10 — no decay
basic_fade, // 11 — decay
basic_fade, // 12 — no decay, larger radius
sparkle_fade, // 13 — decay
sine_fade,
flash_fade
};
Each “handler” is independent, and the LEDs act individually. If you look at how these are called (dispatched) you may be able to see how to make individual LEDs use different handlers.For a different approach, check out our Interactive Game of Life code, which does not have grayscale, but does have good networking.Thanks– fixed!
There is indeed a software issue that can prevent this from working. The bootloader that shipped on kits with on Alpha Clock Five firmware v. 1.0 had a programming rate of 38400 baud, while the default bootloader baud rate for version 2.0 is 57600. (This rate is the default for the new version of Sanguino that we are using.)
Since the bootloader baud rate can *only* be changed through an ISP programmer, you need to reconfigure your Arduino installation to upload firmware at 38400 baud, rather than 57600. Instructions on how to do this are a little further down on our page about the version 2.0 firmware:Hi Mike,
You might start with our “basics” article on serial communication with AVR microcontrollers:Use the avr fuse calculator to pick appropriate fuse values. Test the actual clock speed, if you have a chance, by counting down the clock to give you a 1 Hz blink on an LED, and make sure that it’s what it’s supposed to be.JP5 is a jumper that short-circuits across the power switch. It’s there for you to “hotwire” the circuit permanently on, for example if you do not install the power switch. If the circuit is not working without a jumper there, then it would certainly appear that the power switch is *not* working correctly, or has a bad connection.
Unless there is a scratch in the circuit board at just the right place, I don’t see any other way for this to be the case.Fantastic– I’m glad to hear that there’s a good explanation for what went wrong, too!
The solution is to reprogram the Peggy 2, such that it does not try to light up the unpopulated rows of LEDs. To do this, open up the Peggy2.cpp file from the library. Find the two sections that contain a “while (j < 25)” part, and change those to skip the rows that you’ve left unpopulated. The best method would be to make it so that it needs fewer total trips through that loop– doing so can actually make the display brighter.
Ah– I was able to see the source code of your comment there, where you linked to a youtube video. Do I understand correctly that you’ve left several rows unpopulated there?
Yes, that’s the correct default setting.
Now, I’m not sure what “The top line of green part was brighter than other row ” means.Assuming that you have the current version of Peggy 2 (2.3), there are four option jumpers on the circuit board that select how the matrix is wired up, the option jumpers shown on page 3 of the instructions.
Is your Peggy 2 built with the “SER” option or the “P2” option? If the “SER” option, you’ll need to edit the one line of your PeggyProgram to use the correct library. If not, see if the same thing happens with the Peggy2 sample programs.
