Document/improve how data argument length/size is calculated

[follower]

It wasn't at all obvious to me how the size of data is calculated from supplied arguments and it turns out it's IMO non-obvious/non-intuitive. In some scenarios it also appears to work but causes CANopen errors which are not easily diagnose-able.

How data argument length/size is currently calculated

Specifically, the data length is calculated based on the length of the supplied string argument:

libcanopen/bin/rs-canopen-pdo-download.c

Lines 74 to 75 in 6e4758b

	data = strtol(argv[5], NULL, 16);
	len = strlen(argv[5])/2;

libcanopen/bin/rs-canopen-sdo-download.c

Lines 74 to 78 in 6e4758b

	len = strlen(argv[5])/2;
	if (argc == 7 && strcmp(argv[6], "SEG") == 0)
	{
	char *data_str = argv[5];

That is, it expects the data to be expressed as two ASCII characters per byte being the hexadecimal value of the byte without any 0x prefix. e.g.: 00 or 03e8

Issues with this method of size calculation

The approach currently used leads to issues in a number of situations, including when the value is 0 or is prefixed with 0x.

This is significant because there are a number of situations where a data value of 0 is required (e.g. TPDO/RPDO remapping).

If one naively uses 0 as the argument value it results in CANopen errors such as 0x06070010 "Data type does not match". (Or, rather it should result in this error number but the value is currently incorrect, see #7.)

Alternate approaches

Ideally, a more robust size calculation would be implemented but in the interim hopefully documenting this will clarify the situation.

Current correct approach for supplying data arguments

The correct format to use is two ASCII characters per byte being the hexadecimal value of the byte without any 0x prefix.

Here is a working example (remapping a TPDO for Node ID 0x30 a.k.a 48 & modifying the event timer) to clarify how the data should be specified:

rs-canopen-sdo-download can0 30 0x1800 1 800001b0
rs-canopen-sdo-download can0 30 0x1A00 0 00
rs-canopen-sdo-download can0 30 0x1A00 1 64010110
rs-canopen-sdo-download can0 30 0x1A00 0 02
rs-canopen-sdo-download can0 30 0x1800 1 000001b0
rs-canopen-sdo-download can0 30 0x1800 5 03e8