PWM LEDs for Rotary Encoder Position

[Spandex]

Hi.  About to start building a MIDIBox64e (together with a monome in a single enclosure :)).  Hoping somebody can answer some questions.  I've hunted round the Wiki/Forums so I really hope I'm not asking RTFM questions.

Like this thread, I see lots of references to PWM LED control with DOUT but not much concrete anywhere.

I'd like to use a single LED for each rotary encoder, using brightness to represent position.  Will probably have 24 encoders.

As I understand it, there's no simple builtin PWM in MIOS.  So my questions are:

1) Can I do this for 24 LEDs using just DOUT boards?

2) If so, what sort of refresh rate would I get?

3) Does MIOS support this in any way or would I have to write some additional software?

I'm comfortable with the software bit (have done PWM for servo control in Motorola 68k ASM before) but scared of departing from the standard DOUT kit because I'm no electronics expert.

Ideally, I'd like to be able to have 24 LEDS with at least 128 diff brightnesses and no flicker.  Am I going to struggle?  Why has this chap made a hardware mod to drive the LEDs?  Is it just about supplying them with more current for brightness?  I couldn't see anything that looked like dedicated PWM in his hardware schematic or the software changes.

My next question is probably going to be "What about 48 or 72 LEDS for bicolor or RGB" :)

Any help greatly appreciated.

[TK.]

Why do I have this deja vu two times today?

-> http://www.midibox.org/forum/index.php/topic,10911.0.html

Best Regards, Thorsten.

[Spandex]

Twice today? I reckon that makes this Question a Frequently Asked one :)

I'd read that thread and found it useful but also confusing.  Mostly it seems to suggest that I'd need hardware and software mods, although the last post seems to suggest just a software mod.  All YOUR posts say it's not possible without overloading the core.. so I'm going to assume that's the correct answer.

Thanks.

[TK.]

The conclusion is: if you want to generate PWM with a satisfying resolution, you need additional hardware components which are doing this job. And these components can be easily controlled from the PIC.

It's a similar approach you already know from Monome. It uses a MAX7221 to control a 8x8 LED matrix. This unloads the CPU, and it saves you from adding LED drivers. There are also chips which allow you to control LEDs with PWM instead.

Sorry, that I cannot give you more details, because I haven't worked on such topics yet (and I'm not planning to do this) - but it would be great if some people could just colaborate together here. The implementation is very straightforward at the software side, and at the hardware side you only need to find chips which are available in low quantities (without ordering >= 1000 pieces)

Best Regards, Thorsten.

[stryd_one]

Twice today? I reckon that makes this Question a Frequently Asked one :)

I reckon it makes this question an infrequently searched one!

[Spandex]

Hmmm... well something isn't matching up here because I *did* search and read a *lot*.  Before I posted, I considered all sorts of solutions.  I'd found and read Ralf Suckow's page, I'd considered using Arduino instead etc... but there are several posts in these forums that talk about driving PWM LED matrixes using standard DOUT on MIDIBox, so I thought this might be the way to go. e.g.

http://www.midibox.org/forum/index.php/topic,8224.0.html

http://www.midibox.org/forum/index.php/topic,9711.0.html

You probably read those threads and (because you know all this stuff inside out, and you know who's who) you know which posts to pay most attention to.  For me, I just see a load of posts with some people saying "yeah that should be possible" and other people saying "no you can't".  Imagine you're new to all this for a moment!

Anyway, rather than gripe about it, I thought I'd be proactive and I added it to the FAQ on the Wiki.  Hope this is appropriate.  It would have saved me a few hours if this had been there.

http://www.midibox.org/dokuwiki/questions_and_answers#can_i_use_pwm_to_control_led_brightness

So, my two options now are to maybe use an LED bar graph instead (much easier but takes up more panel space), or to start looking at adding dedicated LED driver ICs (e.g. PCA9635 or ST2226a).

[stryd_one]

You probably read those threads and (because you know all this stuff inside out, and you know who's who) you know which posts to pay most attention to.  For me, I just see a load of posts with some people saying "yeah that should be possible" and other people saying "no you can't".  Imagine you're new to all this for a moment!

What? LOL you think too much, especially about me. Next time you think you have me figured out, think again ;) I'm not talking just about you. I'm talking about everyone.

Anyway, rather than gripe about it

You mean, in addition to griping about it...

I thought I'd be proactive and I added it to the FAQ on the Wiki.

Now you're talking :D Thanks!!

[Spandex]

You mean, in addition to griping about it...

Heheh.. yes :) Sorry.

[stryd_one]

Don't be sorry - griping is important :D

(at least, it is to me.... anything less would usually amount to complacency ;) )

[TK.]

You probably read those threads and (because you know all this stuff inside out, and you know who's who) you know which posts to pay most attention to.  For me, I just see a load of posts with some people saying "yeah that should be possible" and other people saying "no you can't".  Imagine you're new to all this for a moment!

You are absolutely right, but you should also see it from my point of view. I can be very helpful to people who want to realize a HW and/or SW project and share it with the community. I'm especially willing to give them the right hints at the beginning before they are starting with an approach which won't be flexible and powerful enough at the end. I'm just a little bit bored from people who expect that a ready made and perfectly working solution is available, so that they only need to tweak on some parameters (like "number of LEDs", "PWM resolution") w/o spending some own thoughts on the topic (or document their findings in the Wiki).

You are not one of those guys (thanks for pro-actively starting a FAQ!), this was hard to estimate after your first posting. Therefore some more infos.

It depends on your design targets, which approach fits your needs.

E.g. you can easily generate PWM with the common MIOS approach (updating a SRIO chain each mS in background of the main application), but experiments have shown, that this doesn't work flicker-free with more than 3bit resolution.

And than more LEDs should be PWM controlled, than higher the CPU load, than less tasks can be handled in parallel.

For 24 LEDs it should work, but only at 3bit resolution - this doesn't fit your requirements, and I know that 7bit is important for your plans, therefore simple answer: it does not work this way.

Another solution could be to control the DOUTs in a seperate chain with higher update rate. E.g., in previous (pre-MIOS) projects I used MBHP_CORE:J7 as alternative port for independently controlled DOUTs

The usage of this port is not natively supported by MIOS (there are too different usage models), but it's easy to control it from the application.

Problem here: you might be able to increase the update rate by factor 2 or 4 (250 uS), but by doing so, there wouldn't be enough compute power anymore for handling 24 encoders in parallel without loosing "ticks".

So - this solution works for people who only want to fade 24 LEDs, but it doesn't work for your intentions.

Next possibility: instead of using a background timer, just control the LEDs in the main task (MIOS: USER_Tick).

Thats basically the same approach like known from most Adruino projects.

Pro: very straightfoward approach, easy to understand, easy implementation.

Con: you will run into troubles once multiple tasks have to be handled in parallel. E.g., receiving and parsing incoming MIDI data, reacting on asynchronous events e.g. rotary encoder movements or high MIDI traffic, outputing LCD messages, etc...

Easy to understand effect: with such a straightforward approach, LEDs would flicker. I don't think that this is acceptable from your side. ;)

Concepts need to be changed once "multitasking" is required. And these are the concepts which went into MIOS. They make the implementation a bit more complicated, maybe also a bit more expensive (if additional HW components have to be added), but at the end it gives you more flexibility and a certain guarantee, that your project won't end into a half-working tinkering solution with a lot of compromisses.

So, what to do: you could simply "outsource" the PWM task to a "slave" PIC, controlling the DOUT chain and waiting for "commands" from the "master" PIC. The master could send LED brightness in form of MIDI events to the slave, or it could be connected to the IIC bus as known from MBHP_IIC_MIDI and MBHP_IIC_SPEAKJET (in such a case, you could also use an inexpensive low-cost PIC derivative)

If the maximum PWM update frequency for handling 24 LEDs from a single PIC is not sufficient, just use two or three PIC16F88, and control them all from the master core.

Another advantage: serial registers (74HC595) are not required anymore. Just connect LEDs directly to the IO pins.

This probably also saves you from using LED drivers.

Disadvantage: more programming skills are required, and everybody who wants to recreate the project needs a PIC burner to program the firmware into the PIC16F88

So - at the end I came to the conclusion, that the easiest and most powerful way for generating high-resolution PWM is the usage of ready made PWM chips.

TLC5940 is a good choice btw.

Too bad, that this topic is continued in another thread. I really hope that users starting to collect more implementation details in the Wiki so that the final conclusions won't get lost

Best Regards, Thorsten.

[Spandex]

I see your point entirely, if you answered every query in this depth it'd be a full time job!  Big thanks.

I've ordered a few TLC5940s and I'll start trying to connect stuff soon (have only just ordered my MidiBox Core too).

[Narwhal]

Check out these chips for LED PWM purposes:

PCA9635

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=568-4067-1-ND

They use I2C and each chip can update 16 LEDs.

[TK.]

PCA9635 is only available in TSSOP package (=SMD), whereas TLC5940 is available as PDIP variant which simplifies soldering and/or prototyping on a breadboard. And you can easily order free samples from TI for evaluation purposes :)

But you are right, PCA9635 is an attractive solution as well.

Best Regards, Thorsten.

[Spandex]

There's some good beginner stuff and example code for interfacing this chip (TLC5940) to Arduino here:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1204292903/6

http://www.arduino.cc/playground/Learning/TLC5940

This (along with the datasheet, obviously) should help in interfacing it to midibox.

There are several packages and the DIP variant seems to be the TLC5940NT.

[Narwhal]

PCA9635 is only available in TSSOP package (=SMD)

I know I have 25 of them sitting at home waiting for my next big adventure  :P

[Spandex]

I'm still waiting on my MIDIBox kit but a friend has posted me his (already built) so I'm going to start making the TLC5940s work with MIDIBox when that arrives.

Can I ask where people would suggest I start?  e.g. which pins might be best?  Should I replace the DOUT driver with one for the TLC5940 instead? (we won't be using DOUT but we will be using DIN with rotary encoders).

The minimum number of pins needed to drive the TLC5940 is 5... of which 3 are clock type signals (SCLK, GSCLK, BLANK), with GSCLK in particular being nice and fast as it's the PWM clock.  I'd like to use at least 6bits of the PWM so a GSCLK speed of 6.4KHz or above would be good.  The faster the better I guess.  I still have to shift 192 bits in for each update (actually 960 as I'm chaining 5 chips) and I'd like to update them every 20 ms or faster.

This list modified from http://www.arduino.cc/playground/Learning/TLC5940  .. a nice summary of the relevant datasheet stuff

# XLAT: to latch data after shifting.

# SCLK: clock for the serial in

# SIN: serial in to TLC5940

# GSCLK: clock for the PWM.

# BLANK: this marks the end of a PWM cycle in addition to blanking the output.

And there's some nice commented arduino code here

https://whatever.metalab.at/user/wizard23/tlc5940/arduino/TLC5940/

Which I've got working fine on a breadboard... if only the arduino had decent USB communication with low latency :)

If anyone could give me a pointer as to where I should start looking, I'd be grateful.  e.g. I'd be sad if I spent a week trying to plug it in where the DOUT module used to be, only to discover that it would have been loads easier to use the MotorFader stuff.  Also, iI'm interested to know if your immediate thought is "that sounds ok in C" or "I'd use ASM to get the performance".  I'm happier with C but I've done a little ASM before so I'm prepared to get my hands dirty.

I hope my questions are getting smarter, if not shorter :)  Thanks once again for allowing me to prevail upon your combined brainpower.

[stryd_one]

USB communication with low latency

Doesn't exist. Don't blame arduino. USB sucks. </broken_record>

If anyone could give me a pointer as to where I should start looking, I'd be grateful.  e.g. I'd be sad if I spent a week trying to plug it in where the DOUT module used to be,

Steal the PWM code from the MBSID. Don't use the DOUT pins cause it's likely that someone will want to use the DOUTs and TL's simultaneously. Check out the pin table on the wiki and figure out which is least likely to be required (motorfaders? SID?). Use C to prototype it and then optimise it in ASM. Be sure to post lots of pics and video :)

[Spandex]

Steal the PWM code from the MBSID. Don't use the DOUT pins cause it's likely that someone will want to use the DOUTs and TL's simultaneously. Check out the pin table on the wiki and figure out which is least likely to be required (motorfaders? SID?). Use C to prototype it and then optimise it in ASM.

Good point about the DOUT + LED Driver.  Hadn't occurred to me.  I'll start looking at SID (or maybe MF) as places to hook it then.

Be sure to post lots of pics and video :)

Will do.  I'll definitely write it up... we're actually building three units so I need to do this for my own sanity too :)

[TK.]

I created a driver for the MAX7221 - the code could be used as basis for PWM chips as well. It works in assembler and C programs :)

So, just tell me which chips you finally want to use, and I will add the appr. drivers to the project

Best Regards, Thorsten.

[Spandex]

That's great!  Looking at this code, it seems the only thing to add for the TLC5940 is PWM.  i.e. the actual PWM clock (GCLK) and also a BLANK signal which marks the end of each duty cycle.

[stryd_one]

Awesome, thanks TK!

[Spandex]

I created a driver for the MAX7221 - the code could be used as basis for PWM chips as well. It works in assembler and C programs :)

After a long patch of "Real Life" happening to me, I'm about to get back into this.. but the SVN link seems to be broken.  Has it moved in the meantime?

[TK.]

No, it has been temporary disabled to check, if the subversion web-frontend caused the server lags in the last weeks. The repository is still accessible with a SVN client (see Wiki)

Best Regards, Thorsten.

[Spandex]

No, it has been temporary disabled to check, if the subversion web-frontend caused the server lags in the last weeks. The repository is still accessible with a SVN client (see Wiki)

I can't get it via svn:// protocol either.  Tried under Debian (command line svn client) and Windows (Tortoise) from two different locations.

TortoiseSVN is giving me:

Error: Can't connect to host 'svnmios.midibox.org': No connection could be made because the target machine actively refused it.

I tried

svn://svnmios.midibox.org/mios/playground

svn://svnmios.midibox.org/mios/

svn://svnmios.midibox.org/

and

svn://svnmios.midibox.org/trunk/modules/max72xx/

[stryd_one]

Works fine here, even through work's firewall.... I suspect you're blocking the port on your firewall(s). IIRC it's port 3690, TCP and UDP.