I plan to experiment with the IR Toy more in the future, but as for now there's something that I like to comment on that I find very disturbing:
Why does the IR Toy use a binary protocol by default?
I'm asking this because a textual, command line-like interface like the one that the Bus Pirate uses could make experimenting so much easier than sending binary codes to the device.
Thanks for your through reply, I really appreciate it. Unfortunately I couldn't make it work besides having some gibberish displayed inside minicom / GtkTerm upon remote control IR reception. When I face IRT towards a blank sheet of paper and press "t" in the terminal nothing seems to be echoed. The terminal settings look correct according to what you wrote.
That's how far I got. As for your "raw" notes, I think nothing can be too raw. Everything is better than nothing and what I've achieved so far is pretty much nothing. :)
I've tried GtkTerm in the meantime and haven't made any further progress with it. Do you have any specific suggestions as to which command line settings / configuration options should I use with it in order to make the IR Toy work?
You've suggested to me using a terminal emulator but according to my understanding minicom is a terminal emulator, isn't it? Should I use another application?
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.
I also agree that operational costs are a non-issue and are constantly declining as time goes by.
Also, I wouldn't worry at all about USB.org giving away MCS's VID. What would they tell to its new owner? - "Sir, that VID actually had been given to another company that may have sold its PIDs to hundreads of companies but you can just sue them if you don't like this situation." - LOL!
Sjaak: Now I'm really confused. I assumed that MCS Electronics's VID is not about to be reissued. It'd be an unresponsible move on the part of USB.org to do that. I'd like to know what's the situation about this one but not sure who to ask. USB.org could tell me that this VID is about to be reissued just to screw MCS Electronics.
rsdio: It's an interesting option that you've just revealed, I've certainly misunderstood you before. If wonder whether Atmel offers PIDs for manufactueres. If so, I'd be interested about their conditions and requirements.
I consider buying a PID a better solution than picking up one from your MCU manfacturer's range. I guess small companies shouldn't worry about it too much but if you grow big then it's probably a good idea to buy a VID to avoid any potential legal shitstorms coming from USB.org.
On a related note, I have a question for you Ian.
A friend of mine and I are thinking about creating a company who sells open source electornics consumer products. The problem is paying a lot for various certificates like CE and FCC. I know that there's a "kits and development boards" (or something similar) category that doesn't require such certificates. I'm interested that under what circumstances can we label our products as "kits and development boards".
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.)