Manual Settings in RM

Mark Pierson · Post by **Mark Pierson** » Sat Oct 18, 2003 9:24 am

In another post, johnsfine wrote:RM's protocols.ini file is a simple text file, so when you want to use RM for a custom protocol, you can just create an entry in its protocols.ini file and specify any translation you like between OBC and hex command.

RM's protocols.ini syntax can be quite intimidating. Since Greg seems to be very good at wrapping thing up in the UI, maybe he can add a "Manual Settings" capability to RM where the user selects all these details via checkboxes and dropdowns, along with the ability to import p-code from sources like protocol-builder. All this detail would then be saved in the .rmdu file so that a), future versions of protocols.ini don't overwrite custom user entries, and b), the data is available to anyone who uses the upgrade file.

gfb107 · Post by **gfb107** » Sun Oct 19, 2003 5:09 pm

I'll take a look at what KM does for the "Manual Settings" protocol, and see if I can't throw something together.

In KM, the Signal Sytle value determines both the Device N to Fixed Data calculation and the OBC to Hex calculation. Is that same behavior appropriate for RM?

I could use an explanation of what the Bits/Dev and Bits/Cmd fields are supposed to do.

jon_armstrong · Post by **jon_armstrong** » Sun Oct 19, 2003 6:44 pm

Greg,

Since I just tested this feature in KM Master, I'll start and hopefully Mark and John will correct me if I get it wrong or over-generalize.

In LSB it really doesn't matter because when you define a field width in a protocol because it always starts from the left and in LSB that IS the least significant bit.

If your protocol is MSB and less then 8-bits, then you want to shift the bits 8-n to the left (where n is the number of bits in a byte). A simple example is a 4-bit MSB byte. If the real value is 0x1 then it becomes 0x1X where the nibble X can be any value, except for some protocols where the unused bits act as control bits. The complements are just subtracting the byte from FF.

gfb107 · Post by **gfb107** » Sun Oct 19, 2003 7:14 pm

OK, but what about more than 8 bits? KM allows up to 15 bits.

Mark Pierson · Post by **Mark Pierson** » Mon Oct 20, 2003 3:58 am

gfb107 wrote:KM allows up to 15 bits.

Not anymore. The next release will limit them to 8 each.

gfb107 · Post by **gfb107** » Mon Oct 20, 2003 6:30 am

Mark Pierson wrote:Not anymore. The next release will limit them to 8 each.

Ok, that makes things easier. Let's see what I can come up with.

johnsfine · Post by **johnsfine** » Mon Oct 20, 2003 6:42 am

jon_armstrong wrote: In LSB it really doesn't matter because when you define a field width in a protocol because it always starts from the left and in LSB that IS the least significant bit.

That length might not matter much for LSB, but for simplicity and clarity we can pretend it does.
That length is the "bits" value documented as the second argument of a "Translator" definition in protocols.ini

The length does matter a little even in LSB:

In LSB, if the OBC were 50 then a length of 6, 7 or 8 would all do the same thing, but if the OBC were 64 a length of 6 would treat the OBC like 0, while 7 or 8 would encode the 64.

jon_armstrong wrote:If your protocol is MSB and less then 8-bits, then you want to shift the bits 8-n to the left

The "Translator" class in RM already knows all that processing. Just specify the index and length, and whether it's msb or lsb and whether or not it's comp and the processing is already there.

I didn't really follow (in KM or) in this thread, what is desired for multiple bytes. I expect a Translator is required for each byte and the msboffset argument of Translator must be 8 times the index (meaning the bytes in fixed data go in exactly the same sequence as they do in the device GUI).