tvbegone firmware

[kscharf]

I've downloaded the firmware to see how this thing works. I used to work for Niles Audio, and they had made some products that controlled IR devices, their IR controller used a small ARM7, so I wondered how it might be done in an avr-tiny.

Were the codes used in the tvbegone adapted from published pronto codes? Strange as it seems, I'd like to use the basic code to build a control box for my home theater. Since the IR codes for most devices can be downloaded in pronto (hex) form it should be possible to take the basic IR generator used in the tvbegone and adapt it for use to control specific devices. Where it gets tricky is in the repeat code logic (that you don't have to provide for the tvbegone application). The repeat code logic is needed for things like channel up/down, volume up/down etc.

Building a learning remote is more tricky, since you have to extract the carrier signal (if used) to find the outline waveform timing. However, if you can start with published codes in pronto or some other standard form then building a programmable remote is just a matter of having the IR engine logic.

BTW, what circuitry is required to connect a serial terminal to the power led for the debug output?

[adafruit]

an FTDI cable can be used to 'listen' to the DEBUG led

[rct]

Building a learning remote is more tricky, since you have to extract the carrier signal (if used) to find the outline waveform timing. However, if you can start with published codes in pronto or some other standard form then building a programmable remote is just a matter of having the IR engine logic.

BTW, what circuitry is required to connect a serial terminal to the power led for the debug output?

You might want to take a look at the USB IR Toy from Dangerous Prototypes (sorry for pointing to a non-Adafruit project, though I'm hoping it could be an adafruit kit one day). It's a PIC based IR emitter & receiver. It's firmware has different modes, one of them It is IRman compatible so it can be used with LIRC (linux infrared remote control), or be used as a logic analyzer for IR signals. See:

http://dangerousprototypes.com/2010/01/ ... ansmitter/

lirc.org has a lot of remote control related info. It may not be very well organized but there is a lot there.

That reminders me, I've been meaning to post that I think the TV-B-Gone design doc is a great IR tutorial. http://www.ladyada.net/make/tvbgone/design.html

I'm interested in a more capable home IR controller. Both the USB IR Toy and the TV-B-Gone hardware are designed to be very small. I'm thinking about an IR controller based on the Arduino Mega (1280) in order to have lots of lines for IR sensors and IR emitters. I'd like to have an open source, fully programmable IR controllers that could be used instead of some of the IR repeater systems made by Niles, Xantech, etc. Currently I have an old Nirvis Slink-e, http://nirvis.com/, that I'm using for some IR control. The Slink-e is no longer manufactured. The schematic is published, but the PIC code was closed. My goal is to replace the slink-e with greatly extended capabilities.

The TV-B-Gone firmware has been ported to Arduino. See http://forums.adafruit.com/viewtopic.php?f=23&t=12223 and http://www.arcfn.com/2009/12/tv-b-gone-for-arduino.html

There are a number of IR libraries for the Arduino: http://www.arcfn.com/2009/09/arduino-un ... d-and.html

Ideally I'd like to be able to stay with the Arduino to make it easier to program and upgrade (in circuit). I don't know yet what sort of limitations of the arduino platform I might run into. The PIC code for the USB IR Toy appears to be more advanced given the feature list.

Right now I'm still just thinking about it, I should probably start a separate thread for it.

Hope This Helps,
--Rob

[fazjaxton]

Building a learning remote is more tricky, since you have to extract the carrier signal (if used) to find the outline waveform timing.

A lot of IR receiver modules do this for you. One example. You just get a digital output instead of having to filter the carrier yourself.

[chrisknight]

an FTDI cable can be used to 'listen' to the DEBUG led

Is there an example anywhere of how to wire this up?

[adafruit]

no, just connect ground to black and then the output of the LED to the RX pin of the ftdi cable (its either orange or yellow)

[opossum]

Wiring for serial debug..

[chrisknight]

Wiring for serial debug..

Thank you. Do I need to make any code changes to switch to DEBUG mode, or does it co-exist nicely with the normal flash functions that use this LED?

I've wired up my FTDI Friend as per the schematic, and the RX LED on the FTDI Friend lights up corresponding to activity on D5 on the tvbgone, but I am not getting anything in my serial monitor.



-Chris

[opossum]

Make sure the bit rate is 19200, 8 bits, no parity.

[chrisknight]

Make sure the bit rate is 19200, 8 bits, no parity.

I am set at 19200,8,N,1 and I tried it both with and without RTS/CTS

-Chris

[adafruit]

try 9600?

[opossum]

Do I need to make any code changes to switch to DEBUG mode, or does it co-exist nicely with the normal flash functions that use this LED?

I don't know what firmware is shipped with the kits. The source does show debugging disabled. You may have to edit, build and reprogram to get debugging working.

Code: Select all

In main.h...

// set define to 0 to turn off debug output
#define DEBUG 0
#define DEBUGP(x) if (DEBUG == 1) { x ; }

Code: Select all

Util.c ...

#if (DEBUG == 1)

#define SERIALDELAY 57  // to make 19200 baud
void serialdelay(void) {
  uint16_t timer;
  for (timer=0; timer <= SERIALDELAY; timer++) {
    NOP;
  }
}


void uart_putchar(char d) {
  int i;
  cli();  // turn off interrupts, make it nice & kleen

  TXPORT &= ~_BV(TX);
  serialdelay();
  for (i=0; i< 8; i++) {
    if (d & 0x1) {
      TXPORT |= _BV(TX);
    } else {
      TXPORT &= ~_BV(TX);
    }
    serialdelay();
    d >>= 1;
  }
  TXPORT |= _BV(TX);
  sei();   // turn on interrupts
  serialdelay();
} 

[chrisknight]

Do I need to make any code changes to switch to DEBUG mode, or does it co-exist nicely with the normal flash functions that use this LED?

I don't know what firmware is shipped with the kits. The source does show debugging disabled. You may have to edit, build and reprogram to get debugging working.

Thank you. It will be a little while before I can verify that this works, because with debug enabled the compiled result is too big:

Code: Select all

Linking: tvbgone.elf
avr-gcc -mmcu=attiny85 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -DF_CPU=8000000 -Wa,-adhlns=main.o  -std=gnu99 -DEU_CODES -DNA_CODES main.o WORLDcodes.o util.o   --output tvbgone.elf -Wl,-Map=tvbgone.map,--cref -lm
/opt/local/lib/gcc/avr/4.0.2/../../../../avr/bin/ld: tvbgone.elf section `.text' will not fit in region `text'
/opt/local/lib/gcc/avr/4.0.2/../../../../avr/bin/ld: region `text' overflowed by 656 bytes
make: *** [tvbgone.elf] Error 1

I'm now reading through the design notes so that I can make sure I am safely trimming out remote codes without stumbling into breaking something else.

[chrisknight]

I'm now reading through the design notes so that I can make sure I am safely trimming out remote codes without stumbling into breaking something else.

Of course, it is never that easy... Trimming out remote codes doesn't have an effect on the overflow, but dropping lines from main.c does.

Has anyone successfully run a tvbgone 1.2 in debug mode without stripping out half the program?

[chrisknight]

I don't know what firmware is shipped with the kits. The source does show debugging disabled. You may have to edit, build and reprogram to get debugging working.

Once I stripped out the code for the EU codes, I was able to get v1.2 to compile with the DEBUG functions enabled. At 9600, 19200, 38400, 57600, all I get is garbage. To be on the safe side, I also commented out all the LED blink calls, in case they were interfering with the debug output. No dice.

I would love to hear from someone who has debug output working on a tv-b-gone 1.2.

-Chris