EDS to/from protobuffer conversion

[nimrof]

Solution uses AutoMapper that is a mapper solution, not the greatest and newest, but it works on .net framework without to much changes.
It solves mapping by itself if the names and mostly equal and imho one of its best features is that the test will fail if there is something that is not mapped or ignored. So you need to have 100% coverage and if will fail if you add new members/fields that are not mapped.

Going forward i think it is best to make own classes that does the mapping to separate the mapping from other stuff related to the format, so that is why the file and class is named [type]Mapping

Before i convert from draft i need more test

[CANopenNode]

AutoMapper seems nice solution to me.

Probably EDSsharp class will be simplified in some parts, as its sole purpose will be to read and write EDS file. Is that so?

[nimrof]

Probably EDSsharp class will be simplified in some parts, as its sole purpose will be to read and write EDS file. Is that so?

Yes, but no plan to remove anything in EDSSharp until protobuffer has replaced EDSSharp

[nimrof]

Hi @CANopenNode & @trojanobelix,

Need a little help here with the eds access types:

Does this look correct?

EDSsharp.AccessType.rw == OdSubObject.Types.AccessPDO.Tr & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.ro == OdSubObject.Types.AccessPDO.T & OdSubObject.Types.AccessSDO.Ro
EDSsharp.AccessType.wo == OdSubObject.Types.AccessPDO.R & OdSubObject.Types.AccessSDO.Wo
EDSsharp.AccessType.rwr == OdSubObject.Types.AccessPDO.T & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.rww == OdSubObject.Types.AccessPDO.R & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.@const == OdSubObject.Types.AccessPDO.R & OdSubObject.Types.AccessSDO.Ro
EDSsharp.AccessType.UNKNOWN == OdSubObject.Types.AccessPDO.No & OdSubObject.Types.AccessSDO.No

[CANopenNode]

From standard:

The value indicates the access type for this object, represented by the following strings („ro“ - read only, „wo“ - write only, „rw“ - read/write, „rwr“ - read/write on process input, „rww“ - read/write on process output, „const“ - constant value) . The “rwr” indicates that the related object is read or is written using SDO, but is only mapped to TPDO. The “rww” indicates that the related object is read and is written using SDO, but is only mapped to a RPDO.`

I would use (not sure for const):

EDSsharp.AccessType.ro == OdSubObject.Types.AccessSDO.Ro
EDSsharp.AccessType.wo == OdSubObject.Types.AccessSDO.Wo
EDSsharp.AccessType.rwr == OdSubObject.Types.AccessPDO.T & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.rww == OdSubObject.Types.AccessPDO.R & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.rw == (OdSubObject.Types.AccessPDO.Tr or No) & OdSubObject.Types.AccessSDO.Rw
EDSsharp.AccessType.UNKNOWN == OdSubObject.Types.AccessSDO.No

[nimrof]

Sorry for the delay, but its now its ready for review not.
Not sure if i have got all of the mapping correct so please check it

[CANopenNode]

EDSsharp class has a lot of members...

MapToProtobuffer:
In proto definition I used "Alias" instead of "Denotation" (We could change that keyword in proto file). Change "opt.Ignore()" to something like:
.ForMember(dest => dest.Alias, opt => opt.MapFrom(src => src.Denotation))
and
.ForMember(dest => dest.FlagsPDO, opt => src.prop.CO_flagsPDO)

(I also suggest to remove FlagsPDO from CANopen.proto file and use it as non-standard key & value inside it. In another PR)

[CANopenNode]

EDSsharp class has a lot of members...

I don't like that. What if we make a new class, similar to EDSsharp and use inside it only members specified by the standard. It would be much easier to discuss MapFromProtobuffer function then.

[nimrof]

EDSsharp class has a lot of members...

I don't like that. What if we make a new class, similar to EDSsharp and use inside it only members specified by the standard. It would be much easier to discuss MapFromProtobuffer function then.

Agree, but not sure how its best to solve it, it its very integrated in the gui and all formats.
Could we ignore it until the new gui is up and running and then remove parts of it that is no longer needed?

But by all means feel free to change it now if you got the time

[CANopenNode]

EDSsharp class has a lot of members...

I don't like that. What if we make a new class, similar to EDSsharp and use inside it only members specified by the standard. It would be much easier to discuss MapFromProtobuffer function then.

Agree, but not sure how its best to solve it, it its very integrated in the gui and all formats. Could we ignore it until the new gui is up and running and then remove parts of it that is no longer needed?

But by all means feel free to change it now if you got the time

You are right, it is certainly not good idea to remove parts from existing EDSsharp class.

One option would be to make new independent class (copy of EDSsharp ?) linked only to this new convertor. But feel free to proceed as you prefer.