The good news is that my IR Toy v2 gets successfully enumerated as /dev/ttyACM0 on Linux and I also managed to update its firmware to v22. When I execute screen `/dev/ttyACM0 115200` and type "s", "S01" appears and when I point my remote towards the IR Toy v2 and press a button the LED flickers and gibberish gets displayed on the screen.
The bad news is that when I execute `irtoy -d /dev/ttyACM0` it displays "Opening IR Toy on /dev/ttyACM0 at 115200bps..." and gets stuck there. Also, when I execute `irrecord -n -H irman -d /dev/ttyACM0 RemoteXXX.conf` it displays "Hold down an arbitrary button.", then I hold down a button, then it displays "irrecord: gap not found, can't continue" and gets stuck there.
I have a Bus Pirate v3 and using 38400 baud 8N1 UART with RX and TX interconnected. I'd expect in Bus Pirate this scenario to echo the bytes on RX that I send on TX but when live display is enabled it shows:
READ: -f 0x00 READ: -f 0x00 ...
without me sending anything. Is this normal? How should I echo bytes?
So far it seems that IR Toy 2 recognizes the signals that are sent by a remote control of mine because its LED blinks upon pressing remote control buttons and /dev/ttyACM0 outputs some gibberish, but sending back that stream doesn't make it re-emit the code.
Also when typing "minicom -D /dev/ttyACM0" and typing "t" for the test mode all I can see is gibberish. I cannot even see the "t" properly echoed.
I was very satisfied with the Bus Pirate and with the Open Logic Sniffer regarding Linux support but my experience with the IR Toy 2 was disappointing so far. Anyone has made it working on Linux? I'd love to be able to receive IR signals from remote controls, analyze them and play them back.
def send(string): global file print string, file.write(string)
file = open('/dev/ttyUSB0', 'w')
while True: for byte in ['0x00', '0xff']: for y in range(8): send('a 0xb%i 0x00 0x10 A ' % (y,)) sleep(0.25) for x in range(128): send(byte + ' ') send("n")
If I don't use sleep() in the drawing code then issues arise. Namely several lines are not drawn and the LCD gets disabled eventually.
Please let me know whether this slowness is due to Bus Pirate and how could I improve it. I could drive the LCD directly with AVR but I'd like to save type on prototyping and if you tell me that this LCD is that slow then I'll choose another one. (I know that buffered writing can much faster but full refersh is miserable.)
The case has a very serious usability problem: The LEDs cannot be seen.
How about providing a translucent case instead of the opaque case? The LEDs could be seen and the vision of the PCB is pure geek porn. The injection mold must be already ready for the case, so it's a matter of using a different plastic which shouldn't cost a dime manufacturing-wise, right?
Just as the subject says. I ordered this BPv3a from Seeed and "SEP 2009" is printed on the PCB. I tried to get it working by following the instructions in the blog posts of Mike Szczys.
Minicom detects if I plug out the Bus Pirate because it reports me that it cannot access /dev/buspirate in this case. The power LED is on when the Bus Pirate is plugged in. My minicom status line is CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.3 | VT102 | Offline