Adding READ_WRITE option for meassurements

[damosvil]

Please, could it be possible to add READ_WRITE option to meassurements?

    /begin MEASUREMENT Signal1 "FreeRTOS"
      UBYTE FreeRTOS_ENUM_Signal1  0 0 0 1
      ECU_ADDRESS 4273875998
      READ_WRITE
      SYMBOL_LINK "Signal1 " 0
    /end MEASUREMENT

[DanielT]

I assume you mean you would want a way to create new measurements that are set to READ_WRITE, since READ_WRITE is not an issue during update and merging.

In principle this would not be difficult, but I'm not enthusiastic about adding a bunch of additional command line options to enable this for each different way of creating measurements. It also looks like tools consuming a2l files can easily convert existing measurements from read-only to read-write, so this would not be particularly valuable. As far as I know the quick conversion of existing measurements is the intended use-case of the READ_WRITE tag, while a CHARACTERISTIC should be used in all other cases.

Overall, I'm currently not inclined to do this.

How do you think this should work? What workflow requires you to create a writable measurement rather than a characteristic?

[damosvil]

I may have misunderstood characteristics and meassurements concepts. We are working in a project with CANoe where we have a lot of legacy a2l files. Those files have lots of meassurements configured for read write access. So the idea is to use characteristics instead meassurements? At this time we are using a script to add read write tags to meassurements, but I understood that it was better to have this feature in a2ltool.

[DanielT]

What you're doing is rather niche.

Usually you would expect to use measurements for values that are in the RAM of the controller you are connecting to, which are probably constantly changing. For example a sensor value, or a value calculated from it. Since it is being updated constantly on the controller, writing to it does not make sense. A characteristic is used for a tuning parameter, which is typically stored in flash. For example this could be a switch to enable a feature. In principle, characteristics don't just support writing values to the "live" controller (online calibration) but also writing values to a binary that can be flashed into a tuning area for offline calibration - at least if the required infrastructure for this is present in the target. Using measurements as a standard way to write values to your controller seems like an odd choice to me.

Anyway, back to your use case: I don't think it makes sense to add this functionality to a2ltool. It's just not worth the additional complexity. Not just purely in terms of code, but also in terms of needed command line options to describe what should be changed. The help message is already longer and more complicated than I would prefer; if it grows even more I think new users will just go "nope" and leave.

I would suggest you solve this issue with some kind of script:

• I see that there are a2l libraries for Python, though I can't say which of them is best
• Even a regex could do the trick
• I you would like to use rust, you can use the a2lfile crate, which contains the infrastructure for a2ltool