Joep, You have my okay to change it as needed to match jallib guidelines. About disabling the interrupts, I never even thought about doing that. I guess it was because when I was playing around with it I was vision restricted to the purpose at hand. I see where including it in another project that used interrupts could cause a malfunction of the library and disabling interrupts at the beginning of the procedure and then re- enabling them would be a good idea. Worst case scenario on transmitting is sending a command that consists of all 1's to an address of all 1's and this comes to about 24 milliseconds, on reception I would speculate 2 to 2.5 times this or 50 to 75 milliseconds.
Mike On Dec 4, 3:03 am, Joep Suijs <[email protected]> wrote: > Hi Mike, > > 2010/12/4 MikeReynolds <[email protected]>:> Matt, the SIRC protocol defines a > "1" as 1.2 milliseonds of carrier > > followed by 600 microseconds of no carrier and a "0" as 600 > > microseconds of no carrier followed by 1.2 milliseconds of carrier. > > The code you reference is for transmission and really should not be > > interrupted by anything else. > > I guess you should disable interrupts (like serial_software does) to > be more robust. > > > As far as blocking delays the entire > > library is full of blocking delays > > So is the serial_software library which is part of jallib from the start... > > > if you can figure out a way of > > doing it without them then by all means go ahead. I would welcome the > > education this would give me. > > You'd have to use a fixed interval ISR. Reception could be done with > the same fixed interval ISR or with interrupt on change pins. > The downside of such a sollution is that with use of the library, you > include 'background activity' which is not obvious to the average > user. > Until now, most jallib libraries are pretty straight-forward (which is > not necessarily simple or easy). From here, there will probably more > complex ones (like the servo library, and remote control ones). They > either impact on the existing code (like blocking functions with > interupts disabled) or require specific setup, like a 200 or 300us > delay interval in your case. In either case, it will reduce the > posibility to mix libraries and probably also the chips certain > combinations can be used with. > I thought of a 'framework-like' sollution, eg a fixed interval ISR of > say 100us to base these kind of libraries on. This is however probably > sub-optimal for most cases and quite expensive for a single sollution. > Bottom line is I doubt it would be better for TX. I did not dig into > RX, but if it can be polled and is only blocking when there is an > actual IR signal, I guess this is the best for a basic library too. > > > As far as having the library for jallib, the link I posted has the > > library formatted to jallib standards at the time it was written. I > > actually thought I had submitted it back then to someone for approval > > and inclusion but must not have ever sent it. Anyone that would like > > to run a check on it for jallib standards and style can do so and > > adapt it as needed for inclusion so long as my original header with > > copyright notice is included. > > A quick check learned that the the TX file is pretty close. A few > capitals and some remarks on the header. Would it be okay to change > the header to comply with jallib format as long as we keep all info in > your header? > > Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
