Ambilight

[sowa]

Hello.

Some time ago xbmc has support for ambilight v1 with smartxx modchips. This version is old now, and on official releases there is no longer support for it but maybe there will be some option to add?

Not for smartxx only but... We have there i2c, would be it useful? It may be to slow and I don't know if xbmc can acces it but we can try...

I can bulid ambilight board with some avr uc and write app for it but I need some outputs in xbmc.

Is some chance to add support for it in next release? PM me or mail: perpuchaty*@*gmail dot com please if someone would be ready for help. Regards, Kamil

[xman]

Can you do LCD boards by chance. That and ambilight would be nice additives on the same board. There is a lot of demand for LCDs displaying the XBMC info and ambilight would be icing on the cake.

[sowa]

then we need to use some cpld. Hm, would be nice but first, I would like to make ambilight project. LCD could be too hard for me at the moment.. but I will look at LPC bus specification.. I never do it before

Another option if we couldn't use i2c: http://www.ftdichip.com/Products/ICs/FT232BM.htm . Any options to add support for it in xbmc? Witch option would be better for xbmc, what do you think?

Maybe python could do that? I saw some scripts for xbmc for pc's, I will look on it too.

So, if someone would be able to do this in xbmc sources, I will do board project

Regards, Kamil

[professor_jonny]

there is sample code for clpd to talk to the lcpbus freely available from latice semiconductor.
but not as such for micros or avr's that i can find and in most cases they are not fast enough to capture packet data as it is running at 33mhz faster than run of the mill micros.

i have no idea when it comes to verilog or the other popular one (vhdl ?) i cant remember its name used for coding programmabl logic chips such as the xlinx and latice clpd's.

if you went this way the support is already in xbmc.

the lcp bus spec is freely available from intel also and coding would be made simplier in the fact that you can reverse engineer from xbmc4xbox code.

the bus logic and packet data is rather simple in its format and header details, but i dont know if they use dma transfers i have not looked that far but it does not look like it.

i have a clpd development board and a jtag programing cable but no idea on programming for it.

[professor_jonny]

Another option if we couldn't use i2c: http://www.ftdichip.com/Products/ICs/FT232BM.htm . Any options to add support for it in xbmc?

this way you are looking at writing a usb driver forxbmc4xbox to ass a ttl or other such data port you still need something to proform the logic device to spit out to the lcd to interface or low level logic with this.

this is what you would use to interface a micro to a usb host interface this way is getting even harded than i2c.
as you have to write two protocols and a usb driver in xbmc.

[ldotsfan]

There's very old i2c code in xbmc4xbox: https://svn.exotica.org.uk:8443/xbmc4xb ... xbmc/xbox/

HalWriteSMBusValue
HalReadSMBusValue

[sowa]

there is sample code for clpd to talk to the lcpbus freely available from latice semiconductor.
but not as such for micros or avr's that i can find and in most cases they are not fast enough to capture packet data as it is running at 33mhz faster than run of the mill micros.

i have no idea when it comes to verilog or the other popular one (vhdl ?) i cant remember its name used for coding programmabl logic chips such as the xlinx and latice clpd's.

Yeah, avr's are pretty slow, but stm32 can run even at 72mhz. And now they are even cheaper than any atmega. I quickly saw the lpc code for lattice clpd. It's in vhdl. I think that if uC will be fast enough, it should be possible to talk with lpc. I'm not sure of it because I 've done only few projects on altera's clpd, and this was some time ago so I don't have big expirience and don't know vhdl very well.. I will check it exactly anyway.

this is what you would use to interface a micro to a usb host interface this way is getting even harded than i2c.

Yup, my bad, i2c can do that same thing and we have implemented it already

HalWriteSMBusValue
HalReadSMBusValue

Thanks! I think I have to get some xdk and find my old atmega test board and test if this one is fast enough .

I'm going to have fun with ambilight first. Messing around with lpc bus will be next

[BuZz]

ignoring the i2c stuff, there is a patchset on our bugtracker related to ambilight. I'd have to check to see what it got to. I recall I think some code changes might have been needed for acceptance, but I could be wrong. I don't have a machine to test however. I could do a build with the patch if you were willing to test for example.

[professor_jonny]

There's very old i2c code in xbmc4xbox: https://svn.exotica.org.uk:8443/xbmc4xb ... xbmc/xbox/

HalWriteSMBusValue
HalReadSMBusValue

that makes things a lot easier !!! thinking about it xbmc can read the eprom details and change screen modes so it must have acces to the smbus/i2c.

an atmega shuld do?

this is quite simple would need like an lm298 or something as a driver for bigger leds but would do for playing around ?
im not game enough to start soldering to my trusty board to wire up this but i might buy a 2nd xbox and try to play.

here is sample code for i2c slave but you would have to test for the last available device on the chain and give it a address it will drop data to the
BUFLEN_TRAN variable.
we just need to know what address to read and what to throw out then convert this into a nubmer representing a percentage of each colour and pwm the led's.

does the amber light data get send to i2c or lpc?

Code: Select all

#i2cslave.c
#include <util/twi.h>
#define SET(x,y) (x|=(1<<y))
#define CLR(x,y) (x&=(~(1<<y)))
#define CHK(x,y) (x&(1<<y)) 
#define TOG(x,y) (x^=(1<<y))
 
//global variables
#define BUFLEN_RECV 12
uint8_t r_index =0;
uint8_t recv[BUFLEN_RECV]; //buffer to store received bytes
 
#define BUFLEN_TRAN 3
uint8_t t_index=0;
//test bytes to transmit
uint8_t tran[BUFLEN_TRAN] = {0x12, 0x34, 0x56}; 
 
//variable to indicate if something went horribly wrong
 uint8_t reset=0 
 
 //prototypes
void handleI2C();
 
//---------------MAIN---------------------------------------------
int main(){
  //load slave address
 TWAR = (0x01<<1); //we're using address 0x01 
 //enable I2C hardware
  TWCR = (1<<TWEN)|(1<<TWEA);
 
 while(1){
  handleI2C();
 }
}
//-----------END MAIN---------------------------------------------
 
//setup the I2C hardware to ACK the next transmission
//and indicate that we've handled the last one.
#define TWACK (TWCR=(1<<TWINT)|(1<<TWEN)|(1<<TWEA))
//setup the I2C hardware to NACK the next transmission
#define TWNACK (TWCR=(1<<TWINT)|(1<<TWEN))
//reset the I2C hardware (used when the bus is in a illegal state)
#define TWRESET (TWCR=(1<<TWINT)|(1<<TWEN)|(1<<TWSTO)|(1<<TWEA))
void handleI2C(){
  //check if we need to do any software actions
  if(CHK(TWCR,TWINT)){
    switch(TW_STATUS){
//--------------Slave receiver------------------------------------
    //SLA_W received and acked, prepare for data receiving
		case 0x60:  
      TWACK;
      r_index =0;
      break;
    case 0x80:  //a byte was received, store it and 
                //setup the buffer to recieve another
      recv[r_index] = TWDR;
      r_index++;
      //don't ack next data if buffer is full
      if(r_index >= BUFLEN_RECV){
        TWNACK;
      }else {
    TWACK;
   }
   break;
    case 0x68://adressed as slave while in master mode.
              //should never happen, better reset;
      reset=1;
    case 0xA0: //Stop or rep start, reset state machine
      TWACK;
      break;
//-------------- error recovery ----------------------------------
    case 0x88: //data received  but not acked
      //should not happen if the master is behaving as expected
      //switch to not adressed mode
      TWACK;
      break;
//---------------Slave Transmitter--------------------------------
    case 0xA8:  //SLA R received, prep for transmission
		            //and load first data
      t_index=1;
      TWDR = tran[0];
      TWACK;
      break;
    case 0xB8:  //data transmitted and acked by master, load next
      TWDR = tran[t_index];
      t_index++;
      //designate last byte if we're at the end of the buffer
      if(t_index >= BUFLEN_ACC_DATA) TWNACK;
      else TWACK;
      break;
    case 0xC8: //last byte send and acked by master
    //last bytes should not be acked, ignore till start/stop
      //reset=1;
    case 0xC0: //last byte send and nacked by master 
		//(as should be)
      TWACK;
      break;
//--------------------- bus error---------------------------------
    //illegal start or stop received, reset the I2C hardware
		case 0x00: 
      TWRESET;
      break;
    }
  }
}

[sowa]

ignoring the i2c stuff, there is a patchset on our bugtracker related to ambilight. I'd have to check to see what it got to. I recall I think some code changes might have been needed for acceptance, but I could be wrong. I don't have a machine to test however. I could do a build with the patch if you were willing to test for example.

http://trac.xbmc.org/ticket/4551 did you think about this? I saw it long time ago, and tried to put it in xbmc source but won't compile. Lot of code has changed i guess:)

There is some nice code but there are few problems:
- This would work only with smartxx modchips because there is 3xPWM output.
- Because data is sended to the chip, this will travel over lpc bus
- This is ambilight v1. That mean there is only one channel. I though to bulid board with 8 channels (3 for up, 2 for left, 2 for right, 1 for bottom). It's called ambilight v2 iirc.
Would be nice if you could add output over i2c bus. Then I can try it into my xbox. Would you? we need 600bps. Don't know how much traffic is there on the bus if xbox is working but 600 bytes is not a lot.

that makes things a lot easier !!! thinking about it xbmc can read the eprom details and change screen modes so it must have acces to the smbus/i2c.

an atmega shuld do?

this is quite simple would need like an lm298 or something as a driver for bigger leds but would do for playing around ?
im not game enough to start soldering to my trusty board to wire up this but i might buy a 2nd xbox and try to play.

Yes, atmega 16 is enough, even atmega 8 should be ok Leds can be drivered by some strong transistors too. Whatever you like This is needed because atmega can't get you lot of current at output.

I will make pcb for it soon

[professor_jonny]

[There is some nice code but there are few problems:
- This would work only with smartxx modchips because there is 3xPWM output.

the atmega 168 has the ability to have 6 pwm outputs on pins 3,5,6 and 11 with 8 bit resolution and pins 9and 10 with 16 bit resolution because of the timers on those pins i know it is not 8 but it shuld be more than enough, 3 colours for left and right each stero amberlight output?

it is sort of getting beyond me but here is the link for sample code:
http://narobo.com/articles/squarewave.html

an irf520 on each output shuld be able to drive a fairly big string of led's of the output.

[sowa]

the atmega 168 has the ability to have 6 pwm outputs on pins 3,5,6 and 11 with 8 bit resolution and pins 9and 10 with 16 bit resolution because of the timers on those pins i know it is not 8 but it shuld be more than enough, 3 colours for left and right each stero amberlight output?

it is sort of getting beyond me but here is the link for sample code:
http://narobo.com/articles/squarewave.html

an irf520 on each output shuld be able to drive a fairly big string of led's of the output.

There are hardware pwm, we can make software pwm on every pins we would like using only one timer so we can get 8 chanels with this Today i will upload schematic and pcb layout for this with rs232, it would be good for debuging. Then I'm going to take rest on vacation, so I'll not be here in next week.

[professor_jonny]

I modded this a bit for stereo and added driver fets and will drive 10 amps per led channel up to 100v
if people decide to make this if the device does not include a bootloader they wont be able to program it hence why i stuck with an lpt programmer but yes connection via rs232 would make it easier to debug.

[sowa]

http://www.sendspace.com/file/fo5u77

There is PCB, Schematic, and pcb layout for ambilight with 7 channels. RS232 for debuging included.

I'm going to take a rest in vacation, so I'll be back in next week

Regards, Sowa

[professor_jonny]

When you said 8 channel i thaught you ment 8 outputs, you ment 8 outputs of the three primary colours or 24 outputs total.

I'm thinking amberlight was designed as a background colour for your tv behind it and you would at most have top bottom left right lighting behind the tv.

Do you plan to have two strings each side to devide the screen into quadrants? or do you have other plans a knight rider display on the front of the xbox maybe .

[professor_jonny]

This will be handy :
http://sourcecodebrowser.com/libxbox/0.1/files.html