TLC59116 Driver - Who can build one and how much will you charge me?
chris_bfs
Posts: 38
in Propeller 1
Hi all -
I have a project, for which I have qty 2 TLC59116 chips with qty 16 white LEDs attached to each of said chips (see screenshot of schematic). I don't have the skills or time to develop a driver to control these LED, so I'm looking for someone to create a driver for me.
Here are some more details about the project:
Purpose:
Control of backlighting LEDs for switches in scientific equipment being used at night. The switches are arranged in (generally) orthogonal and regular grid array; as such, individual "backlights" may be used for other feedback to the user. Battery level indication and WiFi connection progress are examples.
Hardware (reference attached screenshot):
1x Prop
2x TLC59116 LED Driver chips connected to Prop via I2C
32x total white led chips spread across the two TLC59116 driver chips, which handle qty 16 LEDs apiece
solid 3.3V supply for chips
SDAP - connected to Prop pin 42/P1
SCLP - connected to Prop pin 41/P0
Software/driver:
Objects/calls sought:
BL_LEDS_ALL_ON
BL_LEDS_ALL_OFF
BL_LEDS_ALL_LEVEL(X), where X is a whole number, 0-100 with 0 off and 100 full on
BL_LED_LEVEL(X,Y), where X is number of LED from 1-32, Y is 0-100 with 0 off and 100 full on - intention is to individually control LED X to Y intensity value.
BL_BREATHE_ALL(X,L,H), where X is a frequency of breathing from low intensity value L to high intensity value H.
BL_BREATHE_LED(N,X,L,H), same as above but for a single LED at position N
Cogs:
All LED activity must be controlled via a single cog. Ex: 32 individual BL_BREATHE_LED operations must be maintained by a single cog. Ex2: A BL_LEDS_ALL_ON cancels any breathing and turns all LEDs on.
The single cog is devoted to the BL_LED activity. No other code is active on the BL_LED cog.
Other functionality / specs:
Perpetual/sustained control of an individual LED during breathing of other LEDs. This would apply to multiple individual LEDs. Ex: calling BL_BREATHE_ALL then calling BL_LED_LEVEL to set LEDs 1 through 10 to level 100 would result in breathing for all but LEDs 1-10, which retain their intensity status until another control call.
Prefer full resolution of LED driver, but open to arguments why it might be overkill for backlighting. Note: LEDs will probably serve other purposes in overall system (other than backlighting). Perhaps related to the resolution comment, the speed of "pixel" updates are not critical, save for a human-perceived continuous/contiguous breathing function. Said another way, lighting intensity resolution can be sacrificed in order to achieve a "smooth" breathing function.
Logistics / arrangements:
I'm looking for someone to develop this driver for me, for which I'm prepared to pay a fee. Additionally, I would like to donate the developed driver to the Propeller world, open-software style, so that anyone can use it. So, ideally I'd find someone of like mind to do the coding.
Anyone interested in this development (or see issues with the specs), please let me know, either as a reply or a PM. Please let me know how much you would charge me for this endeavor.
thanks very much in advance,
Chris
I have a project, for which I have qty 2 TLC59116 chips with qty 16 white LEDs attached to each of said chips (see screenshot of schematic). I don't have the skills or time to develop a driver to control these LED, so I'm looking for someone to create a driver for me.
Here are some more details about the project:
Purpose:
Control of backlighting LEDs for switches in scientific equipment being used at night. The switches are arranged in (generally) orthogonal and regular grid array; as such, individual "backlights" may be used for other feedback to the user. Battery level indication and WiFi connection progress are examples.
Hardware (reference attached screenshot):
1x Prop
2x TLC59116 LED Driver chips connected to Prop via I2C
32x total white led chips spread across the two TLC59116 driver chips, which handle qty 16 LEDs apiece
solid 3.3V supply for chips
SDAP - connected to Prop pin 42/P1
SCLP - connected to Prop pin 41/P0
Software/driver:
Objects/calls sought:
BL_LEDS_ALL_ON
BL_LEDS_ALL_OFF
BL_LEDS_ALL_LEVEL(X), where X is a whole number, 0-100 with 0 off and 100 full on
BL_LED_LEVEL(X,Y), where X is number of LED from 1-32, Y is 0-100 with 0 off and 100 full on - intention is to individually control LED X to Y intensity value.
BL_BREATHE_ALL(X,L,H), where X is a frequency of breathing from low intensity value L to high intensity value H.
BL_BREATHE_LED(N,X,L,H), same as above but for a single LED at position N
Cogs:
All LED activity must be controlled via a single cog. Ex: 32 individual BL_BREATHE_LED operations must be maintained by a single cog. Ex2: A BL_LEDS_ALL_ON cancels any breathing and turns all LEDs on.
The single cog is devoted to the BL_LED activity. No other code is active on the BL_LED cog.
Other functionality / specs:
Perpetual/sustained control of an individual LED during breathing of other LEDs. This would apply to multiple individual LEDs. Ex: calling BL_BREATHE_ALL then calling BL_LED_LEVEL to set LEDs 1 through 10 to level 100 would result in breathing for all but LEDs 1-10, which retain their intensity status until another control call.
Prefer full resolution of LED driver, but open to arguments why it might be overkill for backlighting. Note: LEDs will probably serve other purposes in overall system (other than backlighting). Perhaps related to the resolution comment, the speed of "pixel" updates are not critical, save for a human-perceived continuous/contiguous breathing function. Said another way, lighting intensity resolution can be sacrificed in order to achieve a "smooth" breathing function.
Logistics / arrangements:
I'm looking for someone to develop this driver for me, for which I'm prepared to pay a fee. Additionally, I would like to donate the developed driver to the Propeller world, open-software style, so that anyone can use it. So, ideally I'd find someone of like mind to do the coding.
Anyone interested in this development (or see issues with the specs), please let me know, either as a reply or a PM. Please let me know how much you would charge me for this endeavor.
thanks very much in advance,
Chris
1466 x 655 - 305K
Comments
From what I get from the OP, he just needs the software driver written.
2. Could you explain a bit more about BREATHE?
3. Why the RC networks between the LEDs and ground?
4. Do you have prototype hardware (or alternately a 59116 mounted on a DIP breakout board)?
5. The mapping of OUTn to Dn appears a bit aukward. Is it fixed?
each led in series with a 22pf capacitor?
The data sheet indicates-
ah well cant post image-!!!
Dave
thanks for the interest and apologies for the delayed response.
tomcrawford - thanks for the great questions
1) The rest of the schematic isn't related to the backlighting (I promise) ; the only things missing are the pin assignments for the I2C, which I included in the text description. Is there something specific you want to see?
2) Breathe: the best example I can think of off-hand is the white "standby" light on a macbook from ~8-10 years ago (do they still do that?) A slow repeat cycling of light output from 0 to 255 back to 0.
3) RC network: Those are there to quiet any ringing on the PWM pulse edges. Note that the LED is directly wired to the TLC driver chip, the RC pair is not in series with the LED drive current.
4) Yes, I have a built board on which I can do testing. However, I was hoping to find someone who also has hardware, so that I'm not in the testing loop (or, at least, not right away.) I know that may be a long shot.
5) mapping: yes, agreed that it looks weird and I'm sure it complicates things on the driver side. The numbering/mapping matches an arrangement of hall-effect switches which are located in close proximity to the backlight LEDs, and the arrangement of those "buttons" is purposeful / not arbitrary.
TChap and Publison - correct, I have the hardware reflected in the schematic and I just need a software driver for the LED control chip created.
w8an - yes, I agree; unfortunately, the EE who did this for me is not available to correct that so I'm stuck with it for now. We're working on a new version (same circuit with regard to backlighting) and I hope to post from that schematic soon.
tritonium - the diagram is the schematic of a board we've fabricated. NOTE: the LEDs are not in-series with the RC pairs. It's not the easiest to read, but the drive/channel signals are designated as numbers, 01 through 32. Those signals are attached above the RC pair (in the schematic); so, between the R-C pair and the LED. The datasheet reference schematic does not include the RC pair, which is included in my schematic for noise-suppression purposes.
JonnyMac - (hello again!) - good point about the gamma, but I think that's okay; I don't think we need to be "human eye linear" (for lack of a better term). Re: breathing, I agree, seems that individual breathing would be tricky. I was hoping some clever person could come up with a scheme wherein each individual LED has, say, intensity, direction and function states, which are stored and updated between cog cycles. now that I write that, I think I may just be saying the obvious (ie, yeah Chris, that's what a state machine does!).
If the individual LED breathing requirement were dropped, but breathing across all LEDs at-once (ie, they're all synchronous) were retained, would the driver become easy? That is, if the function I called "BL_BREATHE_LED(N,X,L,H)" were removed?
thanks to everyone for the questions!
Chris
2. I would be able to write the code, but would absolutely require hardware to test debug it on. I am in California and would return the material upon completion.
3. I have most every USB cable known as well as a PropPlug. And, of course, a PC and PropTools and logic analyzer.
4. I think it would take a couple of days. If it took more than a week I would be amazed.
5. I would write it almost entirely in PASM with a very small spin wrapper. I would use the Dave Hein I2C primitives, which means keeping the MIT license.
6. My pension effectively prevents me from receiving earned income. I would ask you to make a 3-digit contribution to a charity to be agreed on.