How to add new programs to Octolively
  • Sorry about the double post... Not sure why it happened...

    Howdy, It's me again. I'm back, but I now have my octolively array built! Hurray!  But now I've been looking into the code, and I have two questions for anyone who can help.

    The first is how to add additional modes.  Essentially, I want to be able to add programs without deleting the other ones.  I want to swtich the display to work in a binary fashion when switching programs (thus allowing for a total of 256 programs, but in reality I only want a max of 16 [plus I noticed that #define MAX_PROGRAMS 16 so that seems good for me]).  So here's what I understand so far.  I have a basic knowledge of programming, but this is way over my head.

    I assume that the ledHandler ledHandlers[] portion at the top designates what program is assigned to what number?  That portion also confuses me with with the net + fade programs are for.  BUT moving on, I also understand how the programs change using changeProgram().  I assume I would simply have to change the if statement to read "if (netConfig == 0 && program >= 16){".  But what I don't understand is where in the code it actually runs the designated program.  Or basically where it says if program 0 run basic_fade.  I feel once that is answered, adding programs should be very simple.
    Then after that, it's just simply changing the LED program interface.  That, I cannot seem to find anywhere.  So a point in the right direction would be very helpful.  I assume a simple case or if/else statement would work in turning on the appropriate LEDs there.  But that brings me to my next question of:

    Is it possible to set certain leds to certain programs?  Say for example, I want my 9th program to run so that the left half of the LEDs run quick_fade and the right half of the LEDs run inv_fade.  Is this possible?  I have no clue where I would start with this one.  Are certain LEDs given a reference number, or is there a way to tell one led to turn on whenever I want?  This code is way above my head!

    As a side note, I've been using the July 12 version of the octolively.c file.

    Thanks for any help!  I've got to say, I'm already impressed by the Octolively the way it is out of box!  But where's the fun in default?
  • 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.
  • Back again.  This time I'm having troubles with installing the program.  I keep getting

    avrdude -p m164p -c avrispmkII  -P  -v -e -B 4 -U lfuse:w:0xC2:m -U hfuse:w:0xD9:m -U efuse:w:0xFD:m -U flash:w:octolively.hex
    avrdude: ser_open(): can't open device "-v": The system cannot find the file specified.


    avrdude done.  Thank you.

    make: *** [install] Error 1

    I have edited the make file with the appropriate usb port number, but left the rest the same since I am using a USBtiny and the MHV AVR Tools.  I can only assume that avrispmkII is not the appropriate programmer, but I do not know which one is correct for me.  There didn't seem to be something there for the MHV AVR Tools.
  • Allow me to suggest that you use the makefile that we include with the source code.   

    The *only* thing that you should need to change is to remove the '#' sign from in front of PROGRAMMER = usbtiny and add a '#' sign in front of PROGRAMMER=avrispmkII.

    As you have it configured right now, it's assuming that you do what to use an avrispmkii, and you have actually removed the USB port, which it does actually need.  So revert, and just change which programmer line is commented out.
  • Perfect, now it seems to be working (I think), but I still get this at the end of it all:

    avrdude: Device signature = 0xffff00
    avrdude: Expected signature for ATMEGA164P is 1E 94 0A
             Double check chip, or use -F to override this check.

    avrdude done.  Thank you.

    make: *** [install] Error 1

    Is this alright?
  • Yup, that doesn't look good.  Are you using the ATmega164P?  If so, it should read and detect that correctly.  Try changing the -B 4 to a -B 1, to slow it down. 
  • I don't think so, I'm using the soldering kit version of Octolively.
  • Try changing the speed; that or bad connections are the most likely cause of the issue. 
  • that didn't make a difference, I'll check the connections.  The board does do a flash every time I attempt to install new code.  So it makes it seem like it's getting some sort of input, but now all of the LEDs flash the same duration.