> Hi,
>
> I can't find a nice way to solve a problem. So if you have
> some ideas I would be greatfull.
>
> This is the problem.
>
> I can ask a bcmxcp ups what commands it support, if the
> firmware is after revision AE.
>
> I was thinking about to use this in the driver. For example
> ' a ups that don't support battery_test would not have this
> command enabled.'
>
> The hex responce look like this from a PW3105:
> 0c <-- first byte is the number of commands (12)
> 01 <-- How many bytes reported below for each command
> 31 <-- PW_ID_BLOCK_REQ
> 33 <-- PW_STATUS_REQ
> 34 <-- PW_METER_BLOCK_REQ
> 35 <-- PW_CUR_ALARM_REQ
> 36 <-- PW_CONFIG_BLOC_REQ
> 3c <-- PW_LIMIT_BLOCK_REQ
> 40 <-- PW_COMMAND_LIST_REQ (this command)
> 43 <-- PW_UPS_TOP_DATA_REQ
> 8a <-- PW_LOAD_OFF_RESTART
> 8b <-- PW_UPS_OFF
> a0 <-- PW_SET_REQ_ONLY_MODE
> cf <-- Autorisation command
>
> So this ups does not need to list unused functions like: batt_test
> sys_test
> set_config set_outlet e.t.c when you ask for possible commands.
> But if you connect a PW5125 it have all the commands listed in
> bcmxcp.h.
> It should be some more listed in the bcmxcp.h, like
> 0x32 (event history block).
>
> My plan was to use a struct and load it with the commands. Then
> loop it and set a bool in the struct if it is present or not.
> That could be done, but..........?
>
> Then it is the thing to read the bool from the struct in a nice way to
> enable or disable the use of a command.
>
> Any ideas to take my head out of 'spin lock' ?
If I understand correctly what you're trying to solve is already done by
NUT. You simply call 'dstate_addcmd()' only for commands that are
supported. By doing so, only those commands will be available. We do
something similar in the usbhid-ups driver (the structures are defined in
the subdriver).
Best regards, Arjen
--
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57