DIALIN-BUG-S63

RESOLVED

RESOLVED

RESOLVED

RESOLVED

DIALIN-BUG-S63
DIALIN-BUG-S63
Overall the use of this file is a bit funny. If this is ran within a Squish test, maybe we should rename/move the file (Ex: system_env_BAT.py) to be more coherent as it currently implies that it is...

Overall the use of this file is a bit funny. If this is ran within a Squish test, maybe we should rename/move the file (Ex: system_env_BAT.py) to be more coherent as it currently implies that it is unit testing something in this folder when it is testing the ENV and CAN.

Totally in favor of the workaround.

Totally in favor of the workaround.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

Fixed.

Fixed.

That is correct and I have something in mind to improve the code. But I believe this is more related to Dialin bugs: 1 - First one which we talked about that Dialin creates all the objects even it...

That is correct and I have something in mind to improve the code.

But I believe this is more related to Dialin bugs:
1 - First one which we talked about that Dialin creates all the objects even it is not being used in the _init_.py files which cause different use-cases of the API to be not compatible together and can't be used together.
2 - the other issue is that the Dialin as an API should by nature be a passive code and just have the capabilities to be extended those observers have to be removed from Dialin.

For now, I'll put a workaround for this, and later we should discuss the better implementation of the Dialin API.

Separate functions have been created to keep the string representations clearer. It is not safe to use something like "b" or "B" since anyone can even but something like "hello" which probably does...

Separate functions have been created to keep the string representations clearer.
It is not safe to use something like "b" or "B" since anyone can even but something like "hello" which probably doesn't mean anything and is an error.
to overcome this flow the different functions implemented here have to be used.

Also since the intention of the function here is clear the length has been calculated regarding the type conversion in each function.
which helps have a lot of clearer code.
Please refer to the usage in:
d9b45e5b52db2540a79cbc8795d82dda4fd3984b on dialin develop branch.

the code has changed from:

        major = struct.unpack('B', bytearray(
            message['message'][self.START_POS_MAJOR:self.END_POS_MAJOR]))
        minor = struct.unpack('B', bytearray(
            message['message'][self.START_POS_MINOR:self.END_POS_MINOR]))
        micro = struct.unpack('B', bytearray(
            message['message'][self.START_POS_MICRO:self.END_POS_MICRO]))
        build = struct.unpack('H', bytearray(
            message['message'][self.START_POS_BUILD:self.END_POS_BUILD]))
        compatibility = struct.unpack('H', bytearray(
            message['message'][self.START_POS_COMPAT:self.END_POS_COMPAT]))

which was so error-prone to the following code:

        major, index = bytearray_to_byte(payload, index, False)
        minor, index = bytearray_to_byte(payload, index, False)
        micro, index = bytearray_to_byte(payload, index, False)
        build, index = bytearray_to_short(payload, index, False)
        compt, index = bytearray_to_integer(payload, index, False)
I don't think that is a good idea to get a hug class like logging to be involved in here. It would be better to use the logging in the class which using these very basic functions.

I don't think that is a good idea to get a hug class like logging to be involved in here.
It would be better to use the logging in the class which using these very basic functions.

Mode 4 for the HD is Treatment parameters. Every time this is called the UI will flicker to the Patient ID screen then back to Home. Is that what we want?

Mode 4 for the HD is Treatment parameters. Every time this is called the UI will flicker to the Patient ID screen then back to Home. Is that what we want?

I don't think we should have a default for the packing in this case. I think the packing type should be provided, like I need 'i' I will provide 'i' and if someone else wants 'I' then it should be ...

I don't think we should have a default for the packing in this case. I think the packing type should be provided, like I need 'i' I will provide 'i' and if someone else wants 'I' then it should be provided. Although the number of bytes of b and B are the same, but it should be up to the developer to provide which of they want. Also, for safety we should add the '<' to make sure the little endianness is definitely enforced. For instance it is '<i" and not just 'i'.

For this kind of logging, I think we should use the logger class.

For this kind of logging, I think we should use the logger class.