next »

[ultrajosh]

You might be looking for this: http://soundwidgets.com/smf/index.php?topic=167.msg624#msg624

older:

I implemented a minor change to the firmware to provide similar functionality to that of _stribe_faders.mxb, but it works a bit better.  Now, in cursor mode, you still get a cursor with trails but now it leaves an indicator at the last place touched when you let go.  It works great with _stribe_cc.mxb.  I replaced default cursor mode with this since it is much more useful.  The mode is ON by default but can be toggled off in _stribe_io.mxb by turning off "firmware cursor".

http://www.soundwidgets.com/stribe/code/stribe_04v.pde

Note that adjacent LEDs on the same grid will flicker when on.  There is still no smart-updating of the display going on.

[bantri]

Sorry for my ignorance but...

In this scheme... using usbmod and an arduino stamp...

Can you send firmware directly over USB in your circuit? (without any programming knowledge or extra equipment, just by using some program specialized to do that)

[ultrajosh]

Yes!

How to Work on the firmware

Read the above for details, but the short version is you install the Arduino IDE onto your machine, download SimpleMessageSystem library and compile it, then you can load up the latest "sketch" (firmware code) from /stribe/code/*.pde, compile it, and upload it to the Arduino stamp via the USB.  The MINI and the USB stamps are wired together with a reset switch on the stribe, so you just hit the reset switch and then click the "upload" button in the IDE and watch the status leds flash and voila, new firmware.

[bantri]

ok, thanks a lot

[ultrajosh]

The new fader mode was really a hack that sort of started working before I expected it to.  So one thing I'm noticing is after awhile it stops clearing the display, esp if you let it sit with no activity for awhile.  Then sometimes it spontaneously clears when you touch it and it goes back to it's old behavior.  Just curious if anyone else is seeing this.

[tk]

I'm not able to test your firmware, but I've some debugging skills
Assumed, that loop() is called each mS, and assumed that the signed integer range of your C compiler is -32768 to +32767, the clearAll counter will get negative after ca. 33 seconds so long at least one sensor is touched. Once the overrun took place, there will be a timeframe of ca. 33 seconds where touch states will be ignored (because clearAll <= trails) and the LEDs won't be cleared, followed by a 33 second timeframe where it will work again.

It makes sense to saturate the counter at 32767 (for ca. 33 seconds) - and maybe also to use unsigned instead of signed variables to double the max delay to ca. 66 seconds

In general, I see a lot of signed variables in your firmware at many places where the negative values are not really required. Signed operations can seriously slow down the code execution, and therefore should be ommited

Best Regards, Thorsten.

P.S.: I'm confused about the comment "only clear if touch[]=0", because the LEDs will only be cleared if at least one member of touch[] is != 0"... so parts of my assumptions above could be wrong. But I think that you got the point...

[ultrajosh]

I just been reading-up on signed vs unsigned ints; and you're right there's also a logic error I need to correct.

Thanks! 

[tk]

I would propose to store the touch state of the 8 sensors into a single byte (-> "unsigned char"). This saves some RAM (int touch[8] consumes 16 bytes), and improves the performance on logical checks.

To set a flag, use:
   touched |= (1 << stribe);
To clear a flag, use:
   touched &= ~(1 << stribe);

Check if any sensor is touched:
   if( touched ) { ...

Check if no sensor is touched:
  if( !touched ) { ...

Check if an individual sensor is touched:
  if( touched & (1 << stribe) ) { ...
or
  if( touched & and_mask[stribe] ) { ...

where and_mask is globally defined as: "const unsigned char and_mask[8] = { 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f };"


touched could also be declared as an aggregate (union):

Code:

typedef union {
  struct {
    unsigned ALL:8;
  };
  struct {
    unsigned SENSOR1:1;
    unsigned SENSOR2:1;
    unsigned SENSOR3:1;
    unsigned SENSOR4:1;
    unsigned SENSOR5:1;
    unsigned SENSOR6:1;
    unsigned SENSOR7:1;
    unsigned SENSOR8:1;
  };
} touched_t;

touched_t touched;

...which not only improves the readability:
  if( touched.ALL ) { ...
  if( !touched.ALL ) { ...
  if( touched.SENSOR1 ) { ...
  if( !touched.SENSOR2 ) { ...

but also the performance (again... single flag checks result into a single assembler instruction)

Best Regards, Thorsten.

[ultrajosh]

Wow, that is some good stuff!      Much food for thought.

BTW: here is a slightly updated firmware with the climbing value fixed and most ints converted to unsigned:

http://soundwidgets.com/stribe/code/stribe_04w.pde

[ultrajosh]

I rolled-in kid sputnik's changes (marked 'DB')

http://soundwidgets.com/stribe/code/stribe_04x.pde

There is also an .exe for watching the messages go by but i couldn't get it to run on my XP box.  Maybe someone else can: http://soundwidgets.com/stribe/code/kidsputnik/