Divisor for 8bit CAN Input

[RR213]

I'm receiving 8 steering wheel keypad button states via an 8bit CAN message.

Is there a reason the option to set a divisor for each key is greyed out for 8bit messages and not for 16bit?

I would prefer to work with a 0/1 value for all keys rather than 1 thru 128 depending on the bit position.

[NathanB]

Are you trying to put it in the keypad setup?

This is only really designed to be used for our motec/greyhill keypads.

You will receive each one in the CAN inputs section.

If you are receiving each button as a single bit (8 total) in a single byte, you select the correct address and byte, and then apply the according mask to select each bit.

The masks will be

80 hex
40 hex
20 hex
10 hex
08 hex
04 hex
02 hex
01 hex

[RR213]

Thanks for the reply Nathan. I have the key inputs setup under CAN Inputs.



I was just wondering what the reason is for not having a divisor option when Data Size: 8bit and if there is a workaround.

Currently the "On" state for each key would return the decimal value below.

In.CAN.SWP.Key0 = 00000001 = 1dec
In.CAN.SWP.Key1 = 00000010 = 2dec
In.CAN.SWP.Key2 = 00000100 = 4dec
In.CAN.SWP.Key3 = 00001000 = 8dec
In.CAN.SWP.Key4 = 00010000 = 16dec
In.CAN.SWP.Key5 = 00100000 = 32dec
In.CAN.SWP.Key6 = 01000000 = 64dec
In.CAN.SWP.Key7 = 10000000 = 128dec

My preference would be to use a divisor, for example 128 for Key7, so that each key returns a 0 (Off) or 1 (On) for easy use in functions. I take it that I would have to use a 16bit message for this.

[MikeD]

Hey RR213,
I don't have an answer to your initial question "what's the reason for not having the divider option available for 8 bit values" ... maybe the Motec guys will answer it.

Anyway when using those CAN inputs (the way you defined them using the respective mask) within functions then there is no problem at all and no need to make them actual 0 or 1 values, as most of the operators will only look for a TRUE or FALSE state and nothing more, any value different from 0 will be recognized as TRUE state...

Because of the fact that all your inputs will only be 0 (FALSE) or value x (TRUE) you will not need the GREATER or LESS or HYSTERESIS operators, as those are useless in such context. You rather just pick the TRUE or FALSE operator, or any of the others like AND, OR, XOR, FLASH, PULSE, SET/RESET, TOGGLE or the COUNTER function, and all of those will just work fine.

In conclusion you don't need to remember the decimal value when creating any of those conditions, true or false are the only states your key inputs will ever become, and rising or falling edge triggers will equally work as well...

Hope that's all you needed to start creating your functions...

[adrian]

The PDM is an 8bit device so the divisor was implemented to scale a 16bit channel down to a range the PDM can read. There was no need to scale an 8bit channel as the PDM could read the full 0 to 255 range.

As has been mentioned there is no need to scale switch channels as you should be using true/false not equal to or greater than etc. The PDM treats 0 as false and any other value as true.

If you really want to scale the channels change the offset to byte 1, set it to 16bit unsigned and then set the mask (it will be the same but with two leading zeros). You can then put in a divisor for each of the buttons. This will only work as long as the byte you are looking at has an offset of 1 or higher. The maximum divisor value you can put in is 255 so you need the byte you are interested in to be the low byte.

[RR213]

Thanks MikeD and Adrian. That all makes sense. I can work with True and False statements.