JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IRP Specification
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Jan 26, 2010 7:31 am    Post subject: IRP Specification Reply with quote

The current version of IRP Notation, sometimes called New IRP Notation, originated with a series of postings by John Fine in March 2003 on the old JP1 forums in Yahoo Groups. Partial descriptions have appeared in the current JP1 forum in response to various queries but it is all very scattered, which makes it difficult for anyone wanting to learn the notation to find a decent account of it. Moreover none of these, including John's original postings, make clear just what is, and what is not, permitted in the notation. This makes it difficult for anyone writing an automated parser to be sure that they have not missed some permitted construction, or for that matter that they have not gone to some effort to cover a construction that is actually not permitted.

I have gone back to John's original postings and trawled for any later additions. The only addition I have found that has been approved by John is the use of a prefix "p" to denote times expressed in terms of cycles of the carrier frequency. That comes from this thread from 2005.

I have attempted to put everything together in a first draft of an IRP Specification. I have made a best guess at what is, and what is not, permitted where I have found this to be unclear. The document concludes with two suggestions for extensions to the notation.

Please post your comments on this attempt.
__________________
Graham
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Tue Jan 26, 2010 9:54 am    Post subject: Reply with quote

I'm really glad you did that. I'm still studying it to see if I have any comments.

For example,

At the end of section 6.3, I thought a clarification was required. That clarification was stated very well in your discussion of the Grundig16 example. Maybe you want a note at the end of 6.3 "See Grundig16 example below for clarification".

I'll keep studying.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Tue Jan 26, 2010 1:45 pm    Post subject: Reply with quote

Amazing doc Graham. I haven't finished reading it yet, I've just got as far as page 7, but I do have a feel for the technical nature of the doc and it's definitely on a par with an IBM syntax manual. It doesn't look like there are any cases which are not covered in here. When it's near to being the final version, I think it could use either an index or a table of contents, to help it serve as a reference manual.

However, I think that we may also need a simpler, less technical doc, as a general guide to IRP (an "IRP For Dummies", perhaps), because (a) some folks won't take the time to read a 20 page doc and (b) many wouldn't understand it if they did.

Regarding the rules themselves, I would like to propose a change to one of the rules, so I guess this is a question for John. I would like "lsb" to be considered a valid value for the "order item". Sometimes people like to document values, even if they are the default value, and this would let them document that a protocol is lsb, without requiring people to know that "lsb" is the default.

Couple of minor items...

1) In the Introduction, I would change the word "burst" to "burst pair".

2) Just before the "2. The GeneralSpec section", "There is no semantics at this level" should be "There are no semantics at this level".

I'll be back with more once I've finished the doc, but great job.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Jan 26, 2010 3:22 pm    Post subject: Reply with quote

The Robman wrote:

However, I think that we may also need a simpler, less technical doc, as a general guide to IRP (an "IRP For Dummies", perhaps), because (a) some folks won't take the time to read a 20 page doc and (b) many wouldn't understand it if they did.

Seems to me that Vicky's Infrared Protocol Primer may be a little long, but I think it is pretty understandable. If it isn't quite suited to "Dummies", I imagine that it would be a good starting point.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Jan 26, 2010 4:29 pm    Post subject: Reply with quote

The Robman wrote:
Amazing doc Graham ... it's definitely on a par with an IBM syntax manual

Very Happy Very Happy Very Happy I wondered if anyone would say something like that! Very Happy Amongst the various side activities I've had while being an academic mathematican, I've been the editor of a dozen or so ISO standards documents. I thought that would show through! Unfortunately they were all part of the ill-fated OSI (Open Systems Interconnection) series that got overtaken by events as the IETF de facto standards of the internet, aided by Java, pushed out the ISO ones, so they are all now obsolete.

Quote:
"There is no semantics at this level" should be "There are no semantics at this level".

Believe it or not, I anguished over that one. Webster's Dictionary says "noun plural but usually singular in constructions." I'm happy to regard it as plural and make the correction. Smile

Quote:
I would like "lsb" to be considered a valid value for the "order item".

I agree.

Other points also taken on board but those are the ones I felt like commenting on.
_______________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Tue Jan 26, 2010 5:03 pm    Post subject: Reply with quote

mathdon wrote:
The Robman wrote:
Amazing doc Graham ... it's definitely on a par with an IBM syntax manual

Very Happy Very Happy Very Happy I wondered if anyone would say something like that! Very Happy

I'm a COBOL programmer by trade, so I am quite familiar with the IBM manuals, and while they are not great as "beginner" docs, they're excellent reference manuals. I love their syntax breakdowns where they show every permutation possible.

mathdon wrote:
The Robman wrote:
"There is no semantics at this level" should be "There are no semantics at this level".

Believe it or not, I anguished over that one. Webster's Dictionary says "noun plural but usually singular in constructions." I'm happy to regard it as plural and make the correction. Smile

As it's unlike you to make grammar mistakes, I actually looked it up in my dictionary (the American Heritage Dictionary) first myself and it lists the noun "semantic" rather than "semantics". I guess it does get used as singular though, in sentences like "That's just semantics".
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Tue Jan 26, 2010 5:15 pm    Post subject: Reply with quote

I'm a bit scared of that whole mechanism for changing variable values on the fly, but I'm not saying I disagree with it. The first/middle/last pattern is certainly common, so I understand making that the directly supported form. But the semantics for your support of toggle per keypress feel strange. I can guess what you might do for toggle per frame (which also exists) but that also feels ugly.

I can't tell whether you want to drop A:B:C and A::C notation from expressions, or whether you just wanted to demonstrate there is an alternate way of getting the same values. I think the use of that syntax for two related but different meanings inside/outside of expressions works well. When specifying which bit fields contribute where to any complex checksum, I think that notation is much clearer than dividing and masking.

I don't know if it would ever get used, but I was hoping for a bit more recursive similarity between defining the body of an irstream and defining values in a bit spec. I do realize I made it quite hard for a traditional parser to distinguish an expression from an IRstream. I hope I didn't make it too hard and maybe allowing either in Bitspec item would make it too hard.

I had something different in mind for when you convert bit sequences to duration sequences, which I think might be unambiguous across some stranger uses. I would convert from bits to durations every time you get enough bits. Imagine something silly such as:

<1,-1|2,-1|3,-1|4,-1>(<A:3|B:3>(F:5),D:7,1,^999)

The boundaries are all strange, but unambiguous. Each bit of F turns into 3 bits of the outer spec. Whenever you have two bits of the outer spec you can convert them to durations. So even numbered bits of F end with a left over outer bit. F generates 7 outer bit pairs with a bit left over. Since D has an odd number of bits, it all works out.

If you hit a duration instead of a bit when you have part of a multi-bit left over, that would be an error. When the spec for a multi bit goes out of scope, it would be an error for part of a multi bit to be left over. But otherwise the partial multi bit should just set across various scope endings until it can be consumed.

Also, I don't think we should require the power of two in the bit spec. If you gave only 10 bitspec items, then you are grouping 4 bits. Using any of the 6 missing bit patterns would be the error. Simply defining the bitspec with ten items should not be.

When I think about program rather than person understanding IRP, I think primarily about an IR transmitter. There is then a close association between the meaning of ()* or ()+ and the button or other control used to send the signal. If you were generating a signal to send barely ahead of real time and you had a button (or button-like press/release messages from another system) and you hit the do it again or not choice in ()+, you would make that choice based on whether the button has been released yet.

Your first/middle/last system complicates that a little, but can be fit in (if last is unique then repeat one more time as part of deciding to stop).

Maybe I misunderstood but some semantics you wrote seemed to be demanding more of a top down approach to "repeat or not" rather than on the fly.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Jan 27, 2010 12:56 pm    Post subject: Reply with quote

johnsfine wrote:
I'm a bit scared of that whole mechanism for changing variable values on the fly, but I'm not saying I disagree with it. The first/middle/last pattern is certainly common, so I understand making that the directly supported form. But the semantics for your support of toggle per keypress feel strange. I can guess what you might do for toggle per frame (which also exists) but that also feels ugly.

I take it you mean the RC5 example of toggle per keypress:

{36k,msb,889}<1,-1|-1,1>(T=T^1,(1:1,~F:1:6,T:1,D:5,F:6,^114m)+)

One can use T=T+1 instead of T=T^1, and indeed this better reflects the behaviour of the IR engine. Even T+=1 if we allow that C++ notation. Are these any better? I can't actually see any strangeness in the logic, only in the notation. Toggle per frame would be

{36k,msb,889}<1,-1|-1,1>(T+=1,1:1,~F:1:6,T:1,D:5,F:6,^114m)+

or whatever notation one prefers for the incrementation.

Quote:
I can't tell whether you want to drop A:B:C and A::C notation from expressions, or whether you just wanted to demonstrate there is an alternate way of getting the same values. I think the use of that syntax for two related but different meanings inside/outside of expressions works well. When specifying which bit fields contribute where to any complex checksum, I think that notation is much clearer than dividing and masking.

I do want to drop the A:B:C and A::C notation from expressions. Your 2003 postings offered A::3 as an alternative to A>>3 but A*8 as an alternative to A<<3. Not exactly symmetrical, which is why I suggested A/8 and A*8 for these expressions. I dislike A:B:C and A::C for several reasons. One is that I think it difficult enough anyway to get across the concept that these are bit sequences, not numbers, in IRstreams without then having to say that after all, they sometimes are numbers. And presumably they can be both in the same item, for instance the bitfield F: (X:2) in an IRstream (I don't mean the space after the first colon, but without it the system turns it into a smiley!). Artificial, perhaps, but it would be valid notation and meaning something totally different from F:X:2. On top of all this, I see a potential ambiguity. What is the value of 11:3 when the protocol has default lsb ordering? 11 in binary is 1011, so is the binary value 110 (as the bit sequence would be 1 1 0) or 011 (the value that we converted into a bit sequence)?

What is my preferred resolution? To allow the << and >> shift operators. I don't know why you are opposed to them, or at least were so in 2003.

Quote:
I don't know if it would ever get used, but I was hoping for a bit more recursive similarity between defining the body of an irstream and defining values in a bit spec. I do realize I made it quite hard for a traditional parser to distinguish an expression from an IRstream. I hope I didn't make it too hard and maybe allowing either in Bitspec item would make it too hard.

I agree with you in principle, and I started out with that idea, if I understand you correctly. But whenever I tried to write a formal syntax it finished up allowing things like

<1,-2,<3,-4|5,-6>(D:2)+|7,-8>

which horrified me, and would still do so even without the repeat! Is it just the way the syntax is expressed that you would like to look more recursive, or are there constructions you want to allow that currently my syntax doesn't allow?

Quote:
I had something different in mind for when you convert bit sequences to duration sequences, which I think might be unambiguous across some stranger uses. I would convert from bits to durations every time you get enough bits. Imagine something silly such as:

<1,-1|2,-1|3,-1|4,-1>(<A:3|B:3>(F:5),D:7,1,^999)

The boundaries are all strange, but unambiguous. Each bit of F turns into 3 bits of the outer spec. Whenever you have two bits of the outer spec you can convert them to durations. So even numbered bits of F end with a left over outer bit. F generates 7 outer bit pairs with a bit left over. Since D has an odd number of bits, it all works out.

If you hit a duration instead of a bit when you have part of a multi-bit left over, that would be an error. When the spec for a multi bit goes out of scope, it would be an error for part of a multi bit to be left over. But otherwise the partial multi bit should just set across various scope endings until it can be consumed.

Yes, I quite like it. At present I have the semantics working from the outside inward in translating the content of bitspecs and from the inside outward when translating that of IRstreams. This makes it more consistent, everything going from the inside outward. To make sure I understand, if F:5 is the bit sequence 1 1 0 0 1, you apply the <A:3|B:3> without first evaluating its elements, so the whole thing becomes

<1,-1|2,-1|3,-1|4,-1>(B:3,B:3,A:3,A:3,B:3,D:7,1,^999)

which gives 22 bits to translate by the outer bitspec.

Quote:
Also, I don't think we should require the power of two in the bit spec. If you gave only 10 bitspec items, then you are grouping 4 bits. Using any of the 6 missing bit patterns would be the error. Simply defining the bitspec with ten items should not be.

I wondered about that. I presume the assumption is that it is the last ones that are missing. When I thought about it, I tried to think of a way of indicating invalid bit combinations, so one could have, say, the first 3 and last 3 of the 8 groups of 3 bits allowed but the two middle ones invalid. I gave up on that and decided to say you have to give them all, but I'm happy to go along with it being the last ones presumed missing.

Quote:
When I think about program rather than person understanding IRP, I think primarily about an IR transmitter. There is then a close association between the meaning of ()* or ()+ and the button or other control used to send the signal. If you were generating a signal to send barely ahead of real time and you had a button (or button-like press/release messages from another system) and you hit the do it again or not choice in ()+, you would make that choice based on whether the button has been released yet.

Your first/middle/last system complicates that a little, but can be fit in (if last is unique then repeat one more time as part of deciding to stop).

Maybe I misunderstood but some semantics you wrote seemed to be demanding more of a top down approach to "repeat or not" rather than on the fly.

I didn't intend more of a top-down approach, I intended it as you have described it. I thought at the time that the wording wasn't entirely clear on that, but it was the best I could do at the time. I don't think my difficulty in finding the right wording indicates any problem with my proposals, such as that they actually do demand more of a top-down approach. I'll see if I can describe this part better.

A question for you, John. Should there be a restriction that only one indefinite repeat is allowed? I can't see that two IRstreams both with + markers would have any use, but I think the behaviour is unambiguous. The first would repeat until the button is released, the second would occur exactly once (or whatever the minimum repeat number was). So it's pointless to do it, but making it invalid just adds one more thing for the parser to check.
__________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Wed Jan 27, 2010 1:33 pm    Post subject: Reply with quote

mathdon wrote:
And presumably they can be both in the same item, for instance the bitfield F: (X:2) in an IRstream (I don't mean the space after the first colon, but without it the system turns it into a smiley!).

Just FYI, you can check the "Disable Smiles in this post" to fix problems like that, see...

F:(X:2)
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Wed Jan 27, 2010 2:25 pm    Post subject: Reply with quote

mathdon wrote:
I can't actually see any strangeness in the logic, only in the notation.


I was bothered by the ambiguity in the meaning of persistence of variables beyond the generation of one signal. But I guess I'm OK with your design.

Quote:
I do want to drop the A:B:C and A::C notation from expressions.


We seem to have a pretty strong disagreement there.

Quote:
And presumably they can be both in the same item, for instance the bitfield F:(X:2)


Why not?
There is a difficult problem (maybe even a design flaw) in IRP notation around the question of whether () surround an expression or an IRstream. I gave that some thought when I started and deciding against using some other characters, such as [] for IRstreams. Maybe I was wrong.

But I think the : operator isn't the only reason you need to know whether something is an expression vs. and IRstream. Your specific example isn't even hard. in F:(X:2) it is syntactically impossible for the (X:2) to be an IRstream, so it must be an expression.

Quote:
it would be valid notation and meaning something totally different from F:X:2.


Absolutely.

Quote:
What is the value of 11:3 when the protocol has default lsb ordering? 11 in binary is 1011, so is the binary value 110 (as the bit sequence would be 1 1 0)


If you think about it, I think you'll see there is no ambiguity nor question. You are mixing in some assumptions that don't belong: The fact that we write numbers in msb sequence does not mean numbers are inherently msb.

The expression (11:3) is unambiguously (11&7). The lsb or msb settings never matter outside of the task of interpreting bit sequences (and there, as you understand, they apply to both taking sequential bits from each field and using sequential bits in a multi bit translation).

As an expression (11:-3) would reverse the bit sequence. There was some protocol (I forget which) where we reversed msb vs. lsb creating an illogical set of OBC numbers, because that seemed less messy than saying a checksum was something like (F:-4)+(F:-4:4)+(D:-4)
But I would prefer IRP notation to be able to specify silly checksums like that.

Quote:
To allow the << and >> shift operators. I don't know why you are opposed to them, or at least were so in 2003.


I don't remember why either. So I think I don't object to adding them. But I still object to taking : away from the expression syntax.

Quote:
whenever I tried to write a formal syntax it finished up allowing things like

<1,-2,<3,-4|5,-6>(D:2)+|7,-8>

which horrified me, and would still do so even without the repeat!


Writing senseless code is possible in any powerful language.

I don't generally object to semantic limits that can't be reasonably expressed in BNF. So I don't object to the BNF allowing the syntax when the semantics are wrong.

In this example, the semantics aren't necessarily "wrong". Maybe they would be harder to implement than is worthwhile for a feature no one wants. But if they happen to be easy enough to implement, why reject it? If you have a good mechanism for forwarding work between the scopes of bitspecs, this case might not even be hard.

Too many ()+ is a generic issue not specific to this usage. See below.

Quote:
are there constructions you want to allow that currently my syntax doesn't allow?


I have a feeling there would be such constructions if I gave the matter enough thought.

Quote:
To make sure I understand, if F:5 is the bit sequence 1 1 0 0 1, you apply the <A:3|B:3> without first evaluating its elements, so the whole thing becomes

<1,-1|2,-1|3,-1|4,-1>(B:3,B:3,A:3,A:3,B:3,D:7,1,^999)

which gives 22 bits to translate by the outer bitspec.


If I were coding it, I would have executable access to all pending bitspecs available all the time they were pending. So the IRspec-like things B:3 and A:3 would be defined in a scope where they know which bitspec they use. When B:3 and A:3 are used they could execute the correct bitspec even though a nested bitspec is also active.

But I think all that has the same result as you described. Your version also is a bit more understandable on the question of when a duration issued by a bitspec forces some other bitspec to be properly aligned. Consider:


<1,-1|2,-1|3,-1|4,-1>(<A:3,-2|B:3>(F:5),D:7,1,^999)

I think that should be syntactically valid, but likely to fail as soon as F has a 0 in an even bit position.

Quote:
Should there be a restriction that only one indefinite repeat is allowed? I can't see that two IRstreams both with + markers would have any use, but I think the behaviour is unambiguous. The first would repeat until the button is released, the second would occur exactly once (or whatever the minimum repeat number was). So it's pointless to do it, but making it invalid just adds one more thing for the parser to check.


I think that is a behavior best punted up to some layer outside of IR generation. For any reasonable such layer, the net effect would be ignoring all but the first ()* or ()+.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Jan 27, 2010 5:25 pm    Post subject: Reply with quote

johnsfine wrote:
But I think the : operator isn't the only reason you need to know whether something is an expression vs. and IRstream. Your specific example isn't even hard. in F:(X:2) it is syntactically impossible for the (X:2) to be an IRstream, so it must be an expression.

I realised that, but I still thought it ugly and confusing. Never mind, I'm not going to argue about it. If you realise things like that become possible then I'm happy to include them.
Quote:
If you think about it, I think you'll see there is no ambiguity nor question. You are mixing in some assumptions that don't belong: The fact that we write numbers in msb sequence does not mean numbers are inherently msb.

You may have noticed that I have tried very carefully, though I may not have succeeded, in avoiding use of msb and lsb in any context other than a sequence in time. I did realise what you are saying, it's just that I think it a potential source of confusion for others. But again, I'll go along with it.
Quote:
As an expression (11:-3) would reverse the bit sequence. There was some protocol (I forget which) where we reversed msb vs. lsb creating an illogical set of OBC numbers, because that seemed less messy than saying a checksum was something like (F:-4)+(F:-4:4)+(D:-4)
But I would prefer IRP notation to be able to specify silly checksums like that.

Now this one really has me stumped. I thought that in an expression you were saying that F:4 was the value before we convert it to a bit sequence. The hyphen-minus in F:-4 only concerns the conversion to a bit sequence, so in an expression I would have expected F:4 and F:-4 to mean the same thing. Are you saying that the "-" acts on the binary digits of the value but the msb/lsb of the GenSpec acts on the conversion to a bit sequence? If so, I see that it can be made unambiguous but it doesn't stop me find it rather weird.
Quote:
In this example, the semantics aren't necessarily "wrong". Maybe they would be harder to implement than is worthwhile for a feature no one wants. But if they happen to be easy enough to implement, why reject it? If you have a good mechanism for forwarding work between the scopes of bitspecs, this case might not even be hard.

After I posted my message I realised that our newly agreed "inside outwards" way of interpreting bitspecs makes my example perfectly comprehensible.

So apart from the issue of the meaning of (F:-4) and similar in an expression, I think I can write a second draft that meets your points.
______________
Graham
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Wed Jan 27, 2010 5:59 pm    Post subject: Reply with quote

Wherever you have A:B:C or A:-B:C you take the value of A and throw away the least significant C bits (shifting the rest to the right); Then keep just the least significant B bits; Then if there was a -, reverse the sequence of the bits.

If this all happens in an expression, you're done.

If this all happens directly in an IRstream, you then use the global LSB or MSB setting to split the value into a sequence of bits; Then you use the global LSB or MSB setting again to group the bits together into the size of index required by the current bitspec. That splitting and regrouping may cross boundaries so that the last bits split from one field may be grouped with the first bits split from the next field.

The B and/or :C are optional (The - cannot be used without B). But if this is directly in an IRstream (not an expression) then B is required.

An expression can occur in an IRsteam. In that case, any A:B:C in that expression is not "directly in an IRstream.

We have the obvious place where we need to distinguish an IRsteam from an expression

(-3,(A:B),-3)

Is (A:B) an IRstream or an expression? I think it should be an IRstream. But I don't know the syntax rule that makes that decision.

In (3,-(A:B),3) The ambiguous looking part is an expression because it can't be an IRstream.

I haven't thought through the other cases where expression/IRstream is ambiguous.

A parser might need to look pretty far before knowing the difference:
(3,((A*7+33):9:2)+1))
Until you see the red 1 you don't know whether that much earlier ( started an expression or an IRspec.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Jan 28, 2010 4:48 am    Post subject: Reply with quote

johnsfine wrote:
We have the obvious place where we need to distinguish an IRsteam from an expression

(-3,(A:B),-3)

Is (A:B) an IRstream or an expression? I think it should be an IRstream. But I don't know the syntax rule that makes that decision.

In (3,-(A:B),3) The ambiguous looking part is an expression because it can't be an IRstream.

As I have things at present, you cannot use an expression in a duration. If you need to do so, you have to assign an internal name to it and use that name, so there is nothing lost by this restriction. This makes your first (A:B) be an IRstream and the second one be syntactically invalid.

In your 2003 postings you said about the situation in this second example "so if we decide to allow it to mean anything then the (A:B) must be an expression". You never resolved the "if we decide" so I took it upon myself not to allow it. It seemed more consistent to say that you needed to use an internal name if you want to put an expression in a duration.

Are you happy with keeping it that way?
__________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Jan 28, 2010 2:11 pm    Post subject: xirp: irp in xml (sort-of) Reply with quote

Graham's great work inspired me to present some work I did some time ago, but never got the time (yet!) to really finish it. I have somewhat reluctantly decided to use this thread, however, it this is considered off-topic, I ask a moderator to split it off to a separate thread. (I hate "theadnapping" myself.)

This is an xml-based file format for describing IR-Signals, considered as a mapping from a few numbers (device-number, command-number/OBC/function-number, subdevice-number?, toggle? etc) to an IR signal. It is quite "inspired" by irp, but does not try to mimic it to 100%. (One reason being that, at that time, Graham's specs did not exist.) I have implemented some stuff that definitely can be used (actually, I use it daily) at least for the cases and for the protocols I have chosen to implement. The focus has not been on covering all possible present and future cases. However, I am fairly confident that all realistic deficiencies can be quite easily fixed by straightforward extensions. Java-classes both for parsing and for rendering, for API-, commandline, and GUI-usage are available; download links at the end of the article. The xml-format presently uses a DTD as its definition; however, a migration to scheme is on my to-do-list. (The reason is simply that I am pretty fluent in DTD-construction, unfortunately not yet on schemes.)

XML offers some advantages compared to the irp-format. You do not need to write the parser yourself; you get a validating parser by using some available package (for example included in Java >= 1.5). The DTD/Schema defines the syntax, so there is (at least in principle) no need to waste time writing manual documentation. (Of course, the semantics still needs manual documenation; however, there are tools available to help.) A number of well understood tools exist.

I will not attempt to give a full description here. Rather, I will present the flavor. Consider my xirp-implementation of the nec1-protocol, in irp-notation known as
Code:
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78,(16,-4,1,-173)*)

It reads
Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE irprotocol PUBLIC "-//bengt-martensson.de//irprotocols//en"
 "../dtds/irprotocols.dtd">
<irprotocol name="nec1" id="nec1">
  <jp1data>
    <protocol number="00 5A" name="NEC1"/>
    <tohex function="reverse_complement" bits="8"/>
  </jp1data>
  <cooked-ccf-string format="900A 006D 0000 0001 %02x%02x %02x%02x">
    <parameterref parameter="deviceno"/>
    <parameterref parameter="subdevice"/>
    <parameterref parameter="cmdno"/>
    <complement bits="8">
      <parameterref parameter="cmdno"/>
    </complement>
  </cooked-ccf-string>
  <parameters>
    <parameter id="deviceno" bits="8"/>
    <parameter id="subdevice" bits="8">
      <default>
        <complement bits="8">
     <parameterref parameter="deviceno"/>
        </complement>
      </default>
    </parameter>
    <parameter id="cmdno" bits="8"/>
  </parameters>
  <frequency value="38400"/>
  <irpnotation-new>
protocol={38.4k,564}&lt;1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78,(16,-4,1,-173)*)
user=d,Device
user=s,Subdevice
user=f,Function
  </irpnotation-new>
  <body>
    <timings>
      <timing id="t1" cycles="21"/>
      <timing id="t3" cycles="63"/>
      <timing id="t16" cycles="336"/>
      <timing id="t8" cycles="168"/>
      <timing id="t78" cycles="1638"/>
      <timing id="t4" cycles="84"/>
      <timing id="t173" cycles="3633"/>
    </timings>
    <pairs>
      <pair id="p0">
        <one timing="t1"/>
        <zero timing="t1"/>
      </pair>
      <pair id="p1">
        <one timing="t1"/>
        <zero timing="t3"/>
      </pair>
    </pairs>
    <intro>
      <one timing="t16"/>
      <zero timing="t8"/>
      <coded_number direction="lsb" zero="p0" one="p1" bits="8">
   <parameterref parameter="deviceno"/>
      </coded_number>
      <coded_number direction="lsb" zero="p0" one="p1" bits="8">
   <parameterref parameter="subdevice"/>
      </coded_number>
      <coded_number direction="lsb" zero="p0" one="p1" bits="8">
   <parameterref parameter="cmdno"/>
      </coded_number>
      <coded_number direction="lsb" zero="p0" one="p1" bits="8">
        <complement bits="8">
     <parameterref parameter="cmdno"/>
        </complement>
      </coded_number>
      <one timing="t1"/>
      <zero timing="t78"/>
    </intro>
    <repeat>
      <one timing="t16"/>
      <zero timing="t4"/>
      <one timing="t1"/>
      <zero timing="t173"/>
    </repeat>
  </body>
</irprotocol>

Most definitely much longer! I think the semantics should be reasonably clear, however, some comments are in order:
-- The original file, available in the download link, is perfectly indented; however the BB-software mutilates it.
-- Numbers are not used directly, but referred through the element timing, and called by its ID ("name").
-- Ditto for "bursts"/"burst pairs", here represented by the element "pair".
-- The element jp1data carries the jp1-name and the mapping from OBCs to hex values.
-- The reader familiar with the "short form CCF" will understand the element "cooked-ccf-string", others can ignore it.
-- I have not used the multiplicity indicators of irp, but instead the pronto notion of "intro" and "repeat".
-- The element "irpnotation-new" is, at least presently, purely of comment character.
-- The "function" should be thought of as a mapping from the numbers defined as "parameter"-elements.
-- The treatment of toggle differs from irp (learned this just by Gordon's docs): I consider the toggle value as an input parameter to a memorlyless (= stateless) function, in irp it seems like the function is considered to be statefull, and toggle to be considered an internal state.

Here is the rc5-implementation:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE irprotocol PUBLIC "-//bengt-martensson.de//irprotocols//en"
 "../dtds/irprotocols.dtd">
<irprotocol name="rc5" id="rc5">
  <jp1data>
    <protocol number="00 E8" name="RC5"/>
    <tohex function="jp1_00e8" bits="8"/>
  </jp1data>
  <cooked-ccf-string format="5000 0073 0000 0001 %04x %04x">
    <parameterref parameter="deviceno"/>
    <parameterref parameter="cmdno"/>
  </cooked-ccf-string>
  <parameters>
    <parameter id="deviceno" bits="5"/><!-- Philips: system -->
    <parameter id="cmdno" bits="7"/>
    <parameter id="toggle" bits="1"/>
  </parameters>
  <frequency value="36000"/>
  <irpnotation-new>
protocol={36k,889,msb}&lt;1,-1|-1,1>(1:1,~F:1:6,T:1,D:5,F:6,^128)+
user=d,Device
user=f,Function
user=t,Toggle
  </irpnotation-new>
  <body>
    <timings>
      <timing id="t1" cycles="32"/>
      <timing id="ttotal" cycles="4096"/>
    </timings>
    <pairs>
      <pair id="p0">
        <one timing="t1"/>
        <zero timing="t1"/>
      </pair>
      <pair id="p1">
        <zero timing="t1"/>
        <one timing="t1"/>
      </pair>
    </pairs>
    <intro/>
    <repeat>
      <coded_number direction="msb" zero="p0" one="p1" bits="1">
   <constant value="1"/>
      </coded_number>
      <coded_number direction="msb" zero="p0" one="p1" bits="1">
   <complement bits="1">
     <mask mask="64" shift="-6">
       <parameterref parameter="cmdno"/>
     </mask>
   </complement>
      </coded_number>
      <coded_number direction="msb" zero="p0" one="p1" bits="1">
   <parameterref parameter="toggle"/>
      </coded_number>
      <coded_number direction="msb" zero="p0" one="p1" bits="5">
   <parameterref parameter="deviceno"/>
      </coded_number>
      <coded_number direction="msb" zero="p0" one="p1" bits="6">
   <parameterref parameter="cmdno"/>
      </coded_number>
      <zeropadding timing="ttotal"/>
    </repeat>
  </body>
</irprotocol>

The whole package, called harc-0.5.0, is GLP3 and is described (somewhat) here and downloadable here. Therein is also a new other implemented protocols, the corresponging DTD (irprotocols.dtd) as well as java classes operating on these protocols.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Feb 04, 2010 10:55 am    Post subject: Reply with quote

I have now posted a second draft of the IRP Specification. I believe it meets all of John's comments on the first draft.

One of John's comments was
Quote:
I don't know if it would ever get used, but I was hoping for a bit more recursive similarity between defining the body of an irstream and defining values in a bit spec.

This is now included. In John's original postings of March 2003 he referred to it as an "IRP Language", though it has since commonly been referred to as IRP Notation and has been used only in a very basic form. Now that I have put in this level of generality that John originally intended, I feel that it is worthy of being called a language (though I haven't done this in the document). Any comments?

This second draft includes, in addition to the formal syntax, an execution model. This is intended to remove any ambiguity in the descriptive sections on the language semantics but it could also form the basis of an implementation.

More comments please!
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control