On Sunday 21 October 2007, Christoph Bartelmus wrote:
> Mike Frysinger "vapier@..." wrote:
> >> In your code, change the line "lirc_buffer_write_1(buf, code);" to
> >> "lirc_buffer_write_n(buf, code, 2);".
> >> But this probably will not work anyway.
> > so my buf should be of type (lirc_t*) rather than (unsigned char*) ? t=
> > prototypes confuse me as they indicate i should be passing up bytes of
> > data rather than lirc_t stuff ... perhaps the prototypes should actually
> > be (void*) ?
> Yes, void* would probably make more sense. It depends on the mode, what
> data type is actually used. You should use lirc_t.
i'll send a patch then against cvs head once i get my driver finished up :)
could you explain a little why .code_length has to be sizeof(lirc_t)*8 ? t=
references to .code_length being in terms of bits confuses me ... or is tha=
not relevant when operating in MODE2 ?
> >> What will happen with the last pulse in a stream? lirc expects to see
> >> the last pulse and after that the gap to the next pulse, which in this
> >> case can be a really long time.
> > when i looked at the signal coming out of the IR sensor, the signal was
> > idling high, so there was a rising edge after the last pulse in the
> > stream ... since my timer is triggering on rising edges, this seemed to
> > be ok. is there a standard for whether the signal will idle high or id=
> > low ?
> All receivers I know are active low.
> > seems like in theory, you cannot measure the last part if the signal
> > is idling low ...
> How about the first pulse then. What will be the period length in this
the behavior i saw was that it would be active high and then go low for a=20
fixed time before starting to transmit real data. since that first pulse=20
would be crazy long compared to normal data, i added "clamp" variables to=20
throw out samples that had a pulse larger than 5000usecs.
> >> You have to write the data from your interrupt handler as well. I can't
> >> see a call to gptimer_add_to_buf anywhere.
> > it was my understanding that the workqueue provides a call back
> > interface. i tell lirc_dev to sleep on the queue passed back the
> > .get_queue member of the lirc_plugin and my interrupt handler wakes up
> > the queue when more data comes in. then lirc_dev would call into my
> > driver via the .add_to_buf member. a quick scan of lirc_dev seems to
> > indicate this as well ...
> This is only done when you use polling.
> It wouldn't work otherwise because there is no way to guarantee that
> lirc_dev picks up your data before the next interrupt comes in.
do you mean that while my analysis is correct for the behavior of the drive=
it would only work in practice when using polling due to the overhead ? if=
had a buffer for my irq handler to spit into, it wouldnt be a problem ... b=
the behavior i'm seeing matches the comments in the lirc_dev header. the=20
lirc_dev is sleeping on my queue, waiting for my interrupt handler to wake =
up, and then calling the add_to_buf function to get the values. but you're=
right that this is much too slow to prevent missing samples. i have the=20
driver working now where mode2 is spitting out pulse/space values that my i=
handler is capturing. but since the mechanism is too slow overall, i'll=20
convert it to manage .rbuf myself.
thanks for your help!