I found myself writing an abstraction 
(http://forum.monome.org/topic/707) for Max that makes LEDs blink 
instead of just stay on or off.

By doing this, I have also found that setting the blink speed to about 
8ms substantially lowers the brightness.

Would this be a safe hack to enable multiple brightnesses within a 
single patch?

More specifically, might there be any abnormal wear and tear on the LEDs 
if they were told to blink every 8ms for a prolonged period of time?

kevin wrote:
> I found myself writing an abstraction
> (_blink) for Max that makes LEDs blink
> instead of just stay on or off.
> 
> By doing this, I have also found that setting the blink speed to about
> 8ms substantially lowers the brightness.
> 
> Would this be a safe hack to enable multiple brightnesses within a
> single patch?
> 
> More specifically, might there be any abnormal wear and tear on the LEDs
> if they were told to blink every 8ms for a prolonged period of time?

i doubt wear and tear is an issue. the way they're updated is a scan 
routine, so they get flickered at some incredible rate that your eye 
can't see.

this would be even better implemented as a firmware hack. anyone up for 
it?

no help really, just agreeing with you that making led's blink is alot 
of times more useful than turning the led off, especially when you have 
off buttons do nothing, or 2 differant meanings of off, or whatever. 
actually, i rpefer blinking to indicate on often, like having blinkng 
mean a channel is on, and solid green means muted, or a tristate thing 
where blinking, on and off all show differant states.

It would be cool for Ableton Live if you could make the currentlly 
playing clip full brightness and any triggered but not yet playing clips 
at lower intensity.

yeah. same with mlr trigger-to position with low quantize values.

does ableton split its midi messages to indicate this? it'd be easy to 
have a flash for triggered, solid for playing.

I don't know enough about it yet.

I know that when just using serialXP if I had one loop running and 
assigned to a button and another loop below it in Live and on the 40h 
(with triggering set to 4bar) when I pressed the second button it would 
light and they would both be lit untill the second loop started. (when 
the first would shut off)  with Monogrid that isn't the case; the pushed 
button stays dark until it's corrosponding loop fires (tho I'm not sure 
that monogrid is working 100% correct cause I don't have the hold the 
bottom row for another 8 grids function)  if everything is running 
properly, that means to me that there is different info sent for each 
function.  But that is a total guess.

serialXP is just a basic midi router, it spits out midi for presses and 
lights leds for incoming midi.  monogrid is alot more sophisticated in 
terms of midi and ableton processing.

ableton DOES send some differant midi depending on what is coming backm, 
i think the first time it opays a clip it sends a 127, then a 126 for 
sustaining and 1 for looparound (dont quote me, that could be wrong, but 
its something like that).  and, of course, it sends a 0 for off!

Turning LEDs on/off really quickly to change their brightness will not 
hurt them, the only thing that hurts them is too much current or being 
wired backwards.  The signal you're creating is called PWM (pulse width 
modulation).

Check this...  Put 3 LEDs next to each other, Red, Green, and Blue. 
Modulate each LED at different intensities and you can get a variety of 
colors.  Sparkfun sells an LED with 3 LEDs under one lens just for this. 
There are 4 leads, 1 for red, 1 for green, 1 for blue, 1 for a common 
ground between 
them.\http://www.sparkfun.com/commerce/product_info.php?products_id=105

I don't have a monome yet but plan on making max/msp code for LED 
intensity, then move on to make a color version (non USB powered).

again, this would be a better firmware hack, rather than try to pwm over 
the serial line. consider the overhead of high speed pwm. whereas i 
think it should actually look pretty good if executed correctly in 
firmware.

Interesting.  I don't have one to hack on yet so I'm not familiar with 
the coordination of data.  The idea I've been thinking of would involve 
a Maxim chip for each LED color and have the uC parse the data to each 
Maxim chip.  Then use 2 unused bits in the data structure to say which 
Maxim IC the message is intended for.

I'm not sure about the high overhead of pwm, it's only 8mS and slower, 
8mS is forver with a 16MHz Xtal.  This is something I'd have to 
experiment with, but I trust your judgment.  Actually to hit 192 LEDs 
every 8mS turns out to be a 24kHz clock 1/(8ms/[64*3]), I think.

I'm all talk at this point, can't wait to get one and start hacking.

tehn wrote:
> it should actually look pretty good if executed correctly in firmware.

speaking of this, have you any good references or resources for reading 
about this kind of firmware coding in c++?  i'm mildly familiar with 
verilog and other development environments (well, mostly just Xilinx ISE 
for their Spartan FPGA....), and i'm comfortable with assembly, but i'm 
having some difficulty understanding how this is all working in C++. 
probably mostly because i haven't invested a solid day reading the code 
and trying to figure it out.

i suppose joe would probably be a better person to ask about this?

Start reading here:
http://www.atmel.com/dyn/products/product_card.asp?family_id=607&family_name=AVR+8%2DBit+RISC+&part_id=2014
I print these things out to take to boring meetings at work, I read and 
take notes and it looks like I'm paying attention.

If you can do verilog and assembly, C is simple.

I've programmed in C before, but it's been a while, and i've definitely 
had a look at the spec sheet for the mega32.

My confusion comes up with applying C to a microcontorller. I haven't 
looked at the Application Notes yet, but I'd imagine those would be 
particularly useful..

even still, the tutorial for the optical encoder hack mentiones avarice, 
which the Atmel site doesn't. perhaps i should start reading the avarice 
documentation.

or maybe i will try to convince a professor at my school to go over some 
of this stuff with me. at least one of them should be familiar with the 
ATmega32.

I've done PIC and Motorola 68HC16 programming, with those it was all 
about reading and writing to/from registers.

Suppose the UART registers are 3 bytes at the addresses inside the 
chip's physical registers:
0x01 <--- status/command register
0x02 <--- data in register
0x03 <--- data out register

You assign variables as pointers the registers, it's all one big memory 
map.  You read and write to the variables to monitor the UART, send it 
data, detect when it reads a byte etc.

Suppose UART_CONTROL is a pointer to 0x01 and the first bit =1 when 
there's incoming data ready to be processed, it =0 when there's not.
if (UART_CONTROL | 0b11111110) then New_DATA = 0x02
which stores the new data in the UART to the variable New_DATA.


I'm not a monome owner yet and I haven't done any Atmega32 coding, just 
my $0.02.
This is a GREAT opportunity to learn all this, the only way to learn 
programming is to do projcets.

why would 0b11111110 mean New_DATA = x02?

would 0b10010110  (i.e. 0b1-----10, where - is don't care) also mean 
New_DATA = x02, so you're only concerned with the MSB and 2 LSB's?

I've worked on a 68HC11 (and actually tutor a lab on that now), but all 
of the projects in the lab deal with keyboard input or switch input 
only, and use a provided GETCHAR functions that i never got too familiar 
with, as it was beyond the scope of the class.

we're using gcc with avr-lib. easiest way to be relieved at how simple 
it is would be to check out the firmware code itself. do it!

also i'm impressed your guys both got into fpga's.

kevin - don't worry about it, it wasn't the best example.  The uC has 
registers (memory) in it that it uses to set its modes of operation, 
transfer data and control data.  These registers are one big memory 
space.  If you're at a university ask a professor I'm should they'd love 
to hear that you're interested in this stuff.

tehn - that's what I do for a living, hardware engineer (EE), nice to 
apply it for fun. ;)

tehn wrote:
> also i'm impressed your guys both got into fpga's

yeah, at this point, one of the things i am more and more wanting to do 
is open up the 40h (maybe also get a new enclosure) and put in an fpga 
after the button stage wired so that you could do jtag programming 
through the usb port.

this would probably be a better hack for the 100h, as it's got it's own 
independent power and i have no idea how much power an fpga consumes

i think that making the logic for this app pLayer that i am working on 
would be far far easier as a finite state machine on an fpga. maybe the 
same could even be said for mlr.

I *think* jtag via USB would be pretty difficult, you'd need another 
FTDI chip to deserialise the USB then a chip (uC or FPGA) to pick off 
the JTAG signals.  On the PC end you'd have to modify the JTAG software 
to use the USB port, ones I've used (Altera, Xilinx, TI) only recognise 
COM ports for JTAG programming.

In the end using an FPGA would mean coding the structures already in the 
Atmega32 (UART and data ports, counters etc).

Maybe just put a DSUB connector into the side of the case and make the 
pinouts match up.  Maybe put the connector on the bottom so it's more 
hidden.

Blueskying ideas... waiting to order a kit... :(  Monomes please please 
please!!

hmmm... i guess now is the time to get familiar with the ATmega32 then.

bingo:

http://ccrma.stanford.edu/courses/250a/lectures/programming/

Very cool man, thanks for the link!!

When I get mine I'll also be learning the Atmega, good to know I won't 
be alone. Thanks for figuring out the 8mS blink time, that's definitely 
something I want to pursue.  It'll be cool to learn a new chipset, the 
Atmega32 seems like a popular uC too.

For now I'm on day 8 of the MAX/MSP trial, that will be fun with a 40h. 
Good to see you also all over that.

FWIW this is a better description of REGISTERs on the Atmega32
http://ccrma.stanford.edu/courses/250a/lectures/programming/node16.html

ah yeah, i'm just reading the whole thing =P


now i'm thinking about hacking it to add an LCD screen and 2 optical 
encoders... or one encoder and an accelerometer..

LOL!  How about a cowbell attachment?

Accelerometer seems cool, or IR beam
http://www.sparkfun.com/commerce/product_info.php?products_id=242
or faders up the side of the device, or...

This is worse than waiting for Xmas...

tonedeft wrote:
> faders up the side

oooh,, one of these would be siiiiick
http://www.pennyandgiles.com/products/products.asp?strAreaNo=402_6&intElement=1170&intIndustry=3

it would definitely limit your variable "cable orientation" to two 
though.. unless you want a horizontal fader...

cool ideas. you have me thinking about trying out the var intensity hack 
myself!

with the atmega32, i'm not sure if this was clear, but we're using a usb 
jtag programmer and the port is included on the logic board.

first rev of the kit is finished. going to get the final proto then 
order the production run. coming quick.

USB JTAG!!  Cool!!  I'm liking this Atmel chip more and more, I had no 
idea, nice design work monomes!!

Kevin - awesome call on Penny and Giles, quality gear, check out their 
joysticks with the built in encoder.


Tehn and company - Thanks for working on this over the holiday weekend.

tehn wrote:
> we're using a usb jtag programmer and the port is included on the
> logic board.

yeah, i remember reading that in the tutorial. i wonder, is there any 
way to make
the ftdi and jtag interfaces use the same physical port?

that seems like it'd be slightly complicated. better off writing a 
bootloader.

also we don't use UART on the atmega32. the ftdi245 we use is a parallel 
fifo. it is absolutely my favorite chip at the moment, except that it's 
a pain to solder.

> bingo:

> http://ccrma.stanford.edu/courses/250a/lectures/programming/

thanks for this link, kevin!

that was me above!  when will i learn - on a differant computer from my 
opwn, sign in damnit!

> we're using a usb jtag programmer and the port is included on the
> logic board.

what does this mean?
I can plug another USB cable to this included on-board "port" and get on 
with reprogramming the Atmel?
This is a bit abstract for me at the moment ... it's been a while!
-h

atmel jtag is a 2x5 (10 pin) connector. the programmer is a dongle-ish 
thing that uses usb, and has a 2x5 female on it.

Mesmer -  There's a pic of that setup here
http://monome.org/40h/process/8/

If you look closely you can see that there's a ribbon cable between the 
grey box and the 40h logic board, that cable ends in 2x5 connectors, 
very easy to use and make.

^that was me, FWIW

thanks! you're on top of it.

Anyone working on this (firmware hack for dimming leds by blinking)?

not me, in the short term.

note that it'd require reworking the serial protocol a bit.

adding a single message would probably do the trick.

id = brightness (next number in line)
brightness (maybe 2 bit?)
x
y


that way the rest of the protocol would be compatible. on/off etc.

and then there's monomeserial to mod... though that's a case where 
modding 40h_serial.mxb would be a much better choice.

How difficult is it to get a JTAG programmer ?

I think I have the C skills to do that. I do not commit to do it, but I 
could have a look to see if it requires lots of work.

EDIT: would this one under linux with avrice ? 
http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=330162638795

Is it sufficient to have the label "works with avr studio"?

I have the "feeling" that most of this devices are supported under linux 
but not sure.

Julien

that seems like it'd work.

setting up the toolchain (gcc, avr-lib, avarice, etc) is a bit tricky, 
but once it's set up everything is very easy to work with.

all of this stuff is absolutely supported under linux. i really don't 
like avr-studio and ide's in general. (that's just my opinion of 
course.)

go for it!

Ok Looked a bit into the code. It is not much work.

However the question is: how many people will benefit from that? Only 
those with a jtag programmer I am afraid...

Anyway, I thinks I'll try to do it.

Julien

Ok I ordered the JTAG programmer. I'll post back if I manage and have 
time to do it.

Julien