Thanks Rct, that definitely sheds some light. and I was thinking the same thing, we should find another way to get user input for ending the program. the canonical mode is much neater to deal with so we want to read the input buffer, and continue if there is nothing. i just did a search but didnt find much. any ideas?
Anyway some progress on the freezing terminal issue. I was following the program through with no options, it pretty much runs print_usage and quits, but this one bit of code runs before that
#ifndef _WIN32 //just to get the display need required on linux tcgetattr(0, &orig); new = orig; new.c_lflag &= ~ICANON; new.c_lflag &= ~ECHO; new.c_lflag &= ~ISIG; new.c_cc[VMIN] = 1; new.c_cc[VTIME] = 0; tcsetattr(0, TCSANOW, &new);
#endif
commenting out the line "tcsetattr(0, TCSANOW, &new);" stops the unresponsive terminal behaviour.. so.. what does that section of code do? and why does it make the terminal freeze?
I dont have a great understanding of classes and objects, so keep that in mind when explaining
edit: reading through the termios man page now. im guessing it was implemented to detect keypresses? ie, in place of kbhit
edit2, the problem is not freezing as I thought it was originally. the terminal simply seems to have been reconfigured by the terminos mumbojumbo. in fact what happens is any keypresses are not printed on screen, but still get executed if return is pressed.. and the line-end from pressing return is not printed either. interesting. from the man page there is an ECHO value in the local mode flag. if i set this to true everything seems to run as normal it was set to false in the above code fragment I suppose if we dont want keypresses echoed while the program is running we should set it to false, then set it to true as the program exits.. so now it sorta works.. the "kbhit" behaviour is still not quite right, seems to take a long time to recognise a key hit. I'll play around with it a bit. also found this, which seems to be basically whats implemented in the irtoy code http://cboard.cprogramming.com/faq-boar ... -unix.html
yes, please post what your working on. I'd love to help. and have hardware to test it with in fact I plan to put a irtoy into my linux mythtv system to tun on the TV and amp and receive IR commands.
I got v0.5 compiled under code:base 10.05 as mentioned before, but had the strange freezes, have you encountered this? you mentioned sleep and kbhit, are these windows system functions? Where are you at so far? got it compiling and running properly? as I said, changing a few lines got v0.5 compiled and it does work with the hardware before freezing up the terminal
Quote
I must admit, i am not a linux user so I must relay on them to make better bug free apps for linux.
actually it was 0.5 i was playing with, not 0.4. has it been compiled under linux before? if so, what compiler? im using g++ it looks like the code has two parts which are selected by ifdef's, one for windows and one for linux, which probably hasnt been compiled. are the main differences just to do with the serial device? i guess i should be asking Jamz
there is a line in main.c that looks like its to sort the capital BOOL thing for linux #ifndef _WIN32
typedef bool BOOL; #endif but its not in bin.c or txt.c. also putting an #include "stdint.h" in ols.c clears up the uint16_t thing
I used Code:Blocks to built the IR TOY Recorder/Player utility v0.3 under Ubuntu. ([s:]v0.4[/s:] v0.5 has a lot of compile errors which appear to be mistakes in code!? see the end of my post) I installed codeblocks, libncurses and build-essential packages to get it compiling. When I run the binary it seems to freeze my bash prompt with or without options after the command (happens in a gnome terminal as well as virtual terminals ie: ctrl+alt+f1) apart from this it appears to work
IR TOY Recorder/Player utility v0.3 (CC-0) http://dangerousprototypes.com
------------------------------------------------------------------------- Opening IR Toy on /dev/ttyACM0 at 115200bps... Entering IR sample mode .... IR Toy Protocol version: S 0 1 � % & % B & - & - & - & - & � � % & % B & - & - & - & Recording started..... Press a button on the remote.
Waiting..any key to exit.. Creating file: outputfile1_000.bin IR Toy said: 11 00 18 00 11 00 2D 00 26 00 18 FF FF writing outputfile1_000.bin
Waiting..any key to exit..
Recording ends..
Thank you for playing with the IRToy. jarrod@study:~/programs/irtoy03$
in the above command output the last prompt is unresponsive.. the file "outputfile1_000.bin" is actually created and contains data
as for [s:]v0.4[/s:] V0.5 not compiling, all occurrences of BOOL should be bool and "uint16_t" should be "unsigned int". the differences may be a windows thing? after fixing these the code compiled successfully but has the same runtime problems as above
It appears that you guys lack linux testers? can I be of help?
Thanks Ian. yeh im using a 2455 with custom board. i was just going to solder on an LED and resistor to the appropriate pin, would it be the same pin as on the IRtoy?
The situation as I understand it is that Uome wants to control his receiver from his PC using an IRtoy from another room (as he said "I would like to control it via eventghost") so he would be sending IR from the irtoy, which would have a carrier as its intended to drive the LED
Actually just had an idea, you could actually use the on board ir decoder instead of a LPF to demodulate the signal (just make sure the IR led's light is making it to the IR receiver soldered next to it) then you would have the raw signal on one of the pins that can be fed into the control socket on the receiver (over a long cable if needed)
you could use only the IRtoy, get rid of the carrier signal with an appropriate low pass filter. this would leave you with only demodulated signal. althouh a LPF may deform the data waveform a bit too much. could work though. you could also just put the IR led on a long cable to get it to the other room, telephone wire or something
fyi "accept and transmit an unmodulated IR signal" - unmodulated is not the right term, this would imply you only have a 40khz carrier, with no actual signal.. just nitpicking
The 2455 compile seems to work. I burned the firmware to the chip with no bootloader (as i couldn't find a binary for the 2455 and couldn't compile it either) i tested it with winLIRC and could receive IR. haven't tried sending yet is there a tutorial on setting it up as a IR blaster under linux?
Thanks Ian. that fixed it. now i just need to work out how to compile for the 2455. I noticed in hardwareprofile.h you have some modifications to work with HAD_USBIRC to change interrupts.. so i suppose you are working on it. simply changing the chip type in the compiler wont work i see (complains about chip type being different in source files, yet i don't know where this is defined). maybe I'll leave it to you im not much good with "low-level" pic stuff.
so comment out that line in usb_config.h? These new files you mention are already in the project folder, except for hal_lin_m which I can not find. unless you mean they actually need to be included in the source
anyway after commenting out that line i get this error
and the tree of the entire library folder (J:Microchip Solutions v2010-08-04).. this one is long, so i put it in a txt file (J: instead of "C:" is my root drive for some stupid reason)
My aim here is to compile the code for a 18F2455, as it is so similar to the 2550 i expected this to be 'easy' after installing the latest MPLAB IDE, C18 lite compiler and the sources for USB (from 'Microchip Application Libraries v2010-08-04 Installer.exe') and copying the usb_descriptors.c source to the project directory... The files for USB don't seem to be in the same directory hierarchy as expected.. the compiler looks for files in ./USBStack i found the files it was looking for in J:Microchip Solutions v2010-08-04MicrochipUSB so i renamed the folder to USBStack and moved it into the project directory. now it gets stuck at linking
and yes i did modify the 'library search path' to the correct MCC18 directory