Show Posts
Pages: [1] 2 3 ... 5
1  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: arduino svn compile bug on: July 10, 2008, 03:36:05 pm
It's working, now -

There are some bugs in the Gentoo ebuilds of the avr libs. A few quick tweaks fixed it and everything runs just fine.
2  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: arduino svn compile bug on: July 08, 2008, 10:55:15 pm
Quote
If you're having trouble installing avr-libc on your distribution, I'd look for support from the package maintainer.  I don't know anything about it.  
Ok...I'll poke around there.

Quote
The repository does unfortunately have a few very large files in it, so it takes a while to check out.  If you're only interested in running Arduino, you should be able to just download the Linux version from the software page.
I'm running an amd64, hence finding this thread...it doesn't work out of the box.
3  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: arduino svn compile bug on: July 08, 2008, 09:02:01 pm
I'm having trouble getting this to work on my system. I've followed the instructions to the letter.

running
Code:
crossdev -t avr -s4
returns
Code:
--------------------------------------------------------------------------------
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   *
 * Target System:         avr
 * Stage:                 4 (C/C++ compiler)

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * libc:                  avr-libc-[latest]

 * PORTDIR_OVERLAY:       /usr/portage
 * PORT_LOGDIR:           /var/log/portage
 * PKGDIR:                /usr/portage/packages/cross/avr
 * PORTAGE_TMPDIR:        /var/tmp/cross/avr
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  
 * Using sys-devel/binutils from /usr/portage instead of /usr/portage
 * Using sys-devel/gcc from /usr/portage instead of /usr/portage
 * Using dev-embedded/avr-libc from /usr/portage instead of /usr/portage
 * Using sys-devel/gdb from /usr/portage instead of /usr/portage
 * Using dev-util/insight from /usr/portage instead of /usr/portage
 * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ...     [ ok ]
 * Log: /var/log/portage/cross-avr-binutils.log
 * Emerging cross-binutils ...                                            [ ok ]
 * Log: /var/log/portage/cross-avr-avr-libc-headers.log
 * Emerging cross-avr-libc-headers ...

 * avr-libc failed :(
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-avr-info.log
 * /var/log/portage/cross-avr-avr-libc-headers.log

The log files, as noted read:
Code:
/var/log/portage/cross-avr-info.log

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

Code:
/var/log/portage/cross-avr-avr-libc-headers.log

>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) cross-avr/avr-libc-1.6.2 to /
 * avr-libc-1.6.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                 [ ok ]
 * avr-libc-manpages-1.6.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...        [ ok ]
 * checking ebuild checksums ;-) ...                                      [ ok ]
 * checking auxfile checksums ;-) ...                                     [ ok ]
 * checking miscfile checksums ;-) ...                                    [ ok ]
 * checking avr-libc-1.6.2.tar.bz2 ;-) ...                                [ ok ]
 * checking avr-libc-manpages-1.6.2.tar.bz2 ;-) ...                       [ ok ]
 * Checking for avr-gcc ...
  [ !! ]
 *
 * Failed to locate 'avr-gcc' in $PATH. You can install an AVR toolchain using:
 *   $ crossdev -t avr
 *
 *
 * ERROR: cross-avr/avr-libc-1.6.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called pkg_setup
 *   avr-libc-1.6.2.ebuild, line   40:  Called die
 * The specific snippet of code:
 *               die "AVR toolchain not found"
 *  The die message:
 *   AVR toolchain not found
 *
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/temp/die.env'.
 * This ebuild used the following eclasses from overlays:
 *   /usr/portage/eclass/flag-o-matic.eclass
 *   /usr/portage/eclass/eutils.eclass
 *   /usr/portage/eclass/multilib.eclass
 *   /usr/portage/eclass/toolchain-funcs.eclass
 *   /usr/portage/eclass/portability.eclass
 *

 * Messages for package cross-avr/avr-libc-1.6.2:

 *
 * Failed to locate 'avr-gcc' in $PATH. You can install an AVR toolchain using:
 *   $ crossdev -t avr
 *
 *
 * ERROR: cross-avr/avr-libc-1.6.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called pkg_setup
 *   avr-libc-1.6.2.ebuild, line   40:  Called die
 * The specific snippet of code:
 *               die "AVR toolchain not found"
 *  The die message:
 *   AVR toolchain not found
 *
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/temp/die.env'.
 * This ebuild used the following eclasses from overlays:
 *   /usr/portage/eclass/flag-o-matic.eclass
 *   /usr/portage/eclass/eutils.eclass
 *   /usr/portage/eclass/multilib.eclass
 *   /usr/portage/eclass/toolchain-funcs.eclass
 *   /usr/portage/eclass/portability.eclass
 *

It looks like a recursive error...it says it needs the avr toolchain, and to use crossdev to build it....but that's what I'm doing, isn't it?

Also, checking out the svn repo is proving troublesome. Is it always incredibly slow?
4  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 16, 2010, 06:49:24 pm
WOW. Well done, Joe! I love it!

Where's the code? smiley-wink

Do you have any close-ups of the individual cells? It looks like you have the LEDs mounted to the sides of the boxes, rather than the bottom.

Something like this has been on tap for me, for a while now...I just need the time and resources to do it.

Excellent craftsmanship, as well as programming!

EDIT: Hang on...how many TLCs are you using? you said 7 TLCs, which is 112 LEDs max. But there are 112 cells in your table, which should be 336 LEDs, and 21 TLCs. Are you multi/charlieplexing them?
5  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: December 30, 2009, 10:18:33 pm
Quote
has anyone used the tlc5940 with i2c at the same time.  im trying to and getting corrupt data when receiving.  Serial works just fine at speeds of 115200 but i2c does not work.
I'm having the same problem.

I'm running I2C between two arduinos, and the Master_Send and Slave_receive examples work perfectly. That is, until I add the slave_receive code to my Arduino running the TLC...

I commented out everything related to the TLC, and it worked. Adding things back in one at a time (headers, global variables, etc.) worked until I hit Tlc.init(); At which point I2C died.

Could you find a solution, joe? (or anyone?)
6  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: May 29, 2009, 09:45:49 am
First off...I must say that your 8x11 matrix is one beautiful ratsnest of wires. I love seeing stuff like that smiley-wink

Second, this couldn't have come at a more opportune time! I'm currently in the process of building a larger version of Tinkerlog's 64pixels to mount on my newly made satchel/man-purse. But to have a full color matrix rather than one-color...now you're cookin' with gas!

Do you have a schematic for that setup? It looks like you have some transistors in there, as well as some current regulators.
7  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: April 21, 2009, 11:38:50 am
Thanks, AC! This came just in time smiley-wink

I'll give it a whirl tonight!
8  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: March 19, 2009, 11:17:57 am
Has anyone had an issue with "long-term" running of fades?

I have 4 RGB LEDs hooked up to the TLC, set to fade every 15 seconds to a randomly selected color. When I power the circuit up (I have the arduino set up as a stand-alone, on a PCB) everything runs fine. But when I came back to the board after a day or so, the whole thing was "frozen", and nothing worked -- no fades, and my inputs weren't responding.

I double-checked my code, and I don't see anything that might cause an issue. The only thing I could think of is the "old" millis issue where it rolls back to 0 after a while. So if X is the millis rollover point, and your timer was looking for X+10, you would never actually hit that point.

I found a post from this year saying that the rollover occurs after 55 days, as opposed to 9 hours (which was what I was familiar with). Maybe I'm using an old bootloader? I'm using Arduino 0012, and my chip I bought in July 2008.
9  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 16, 2009, 04:01:28 pm
#1 -- That interrupt/sli() code worked perfectly. Thanks, AC!

#2 -- If anyone else was interested, this library works PERFECTLY with the Mega168's internal clock, and running on 3.3V.

...at least it does in my scenario smiley-grin
10  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 12, 2009, 09:38:39 am
As an aside:

HTINK is probably using your library for a workshop smiley-grin
http://blog.makezine.com/archive/2009/02/electronics_workshops_at_nycs_htink.html?CMP=OTC-0D6B48984890
11  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 11, 2009, 09:33:47 am
so, something like...
Code:
void myInterruptFunction(void)
{
    sei();
    delay(debounceDelay);
    //make state changes
}
...would work? I'm still not 100% sure how exactly it's supposed to work.

Or, should I just keep it simple:
Code:
void myInterruptFunction(void)
{
    if(lastInterrupt + 10 > millis())
    {
        //make state changes
        lastInterrupt = millis();
    }
    else
    {
        //do nothing
    }
}
12  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 10, 2009, 10:18:35 pm
Quote
You can turn on interrupts, etc (so millis and serial will work) in an interrupt vector with
Code:
sei();

Is that run inside the interrupt? I'm trying to search around for more info on how it's used, but the most I can find is sei() enables interrupts (already there by default) and cli() disables them.

They apparently work at a deeper level than the attach/detachInterrupt() functions.
13  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 10, 2009, 04:11:09 pm
I think that's exactly the case -- millis() will always return the same value. As a result, delay() doesn't work, because the timer has stopped.
14  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 09, 2009, 09:32:06 pm
Okay...this is crazy...

either I'm doing something horribly wrong, or....I'm doing something horribly wrong.

Here's my interrupt code:

Code:
void changeMode(void)
{
  detachInterrupt(0);
  debounce = 1;
  Serial.println(repeater++);
  setMode = !setMode;
}
...and the middle of the delays where my issue was...
Code:
while(tlc_updateFades()) {
      if (setMode == 0) { return 0; }
    }
    for(int i=0;i<delayTime/10;i++)
    {
      if (setMode == 0) { return 0; }
      delay(10);
    }
...and then back at the beginning of loop() once it all starts back up again
Code:
if(debounce == 0)
  {
      //do nothing
  }
  else
  {
    delay(50);
    attachInterrupt(0, changeMode, FALLING);
    debounce = 0;
  }
So, what it should be doing is
  • triggering the interrupt
  • turning off the interrupt
  • changing setMode to 0 and making debouncer = 1
  • returning to the current function
  • catch setMode being switched back to 0
  • return to the beginning of loop()
  • reactivate the interrupt after 50ms
But somehow, I still see 2-3 bounces, and it still locks up after a couple of button presses.

EDIT:
Never mind...I found a couple of good examples of how folks were debouncing their interrupts, and I'll give them a whirl tonight.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1223543716/
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1216607685/1#1
15  Forum 2005-2010 (read only) / Development / Re: Library for TLC5940 16-channel PWM chip on: February 09, 2009, 02:23:12 pm
1. Aha! I should have thought of that. I merely added a 10ms delay into the interrupt function, but for whatever reason, it locked everything up (even going as low as 1ms, too!)

2. I figured as much.


Also, is there any sort of "limit" to the interrupts? For whatever reason, I could only push the button 3-4 times before the entire system locked up. It was almost like the Arduino was getting angry someone "ringing the doorbell" all the time. Initially, it seemed like I could hit it 30-40 times without a problem, but then it only allowed me to do it a tiny handful of times. This is between resets and reprogrammings, too.

Could it be that I'm pushing too much information into memory? I have a quite a few ints and integer arrays

16 ints for pin mappings
3 1x7 integer arrays for color maps
4 1x3 integer arrays for color settings
4 longs for millis()

plus a few more for random other things, but those above are global (they're used in quite a few functions; I'm not just lazy). Should I use #define for them instead? The pin maps and color arrays are static.

Edit: the final size of the sketch burned is about 6k, if that helps at all.
Pages: [1] 2 3 ... 5