Thank you for your suggestion re bash... It is good to know that it is possible to build
custom applications... I don't consider that effort to be worthwhile for this platform on which
I do not intend to spend any ongoing time - just enough to bolt a workable system together
I have started monkeying around with writing values into /tmp/regfile
I don't quite understand the nuances of this mechanism
The wiki shows an example of dumping a date in ASCII format into the /tmp/regfile.
That makes zero sense to me at all since reconstructing the date from a bunch of
ASCII fragments would be onerous/clunky
If I just ignore that and use the binary tools to write simple values into the file and then read them in the modbus master "window" I get values which do not match what I write...
Does anyone know what word-order / byte order is required to write values recognized as 32bit ints
- so I can converge more quickly than testing all the permutations:
1,2,3,4 3,4,1,2 4,3,2,1 2,1,4,3 ?
I plan to just prepare 3 variants of the le32 code above to test them all
I have already optimized the above code by making $1 the output file and then arguments $2, $3, $4... the values to write
I noticed that when I write the value 1, I get a large 8 digit value...
It just occurred to me that could occur if the one-bit is written 1,2,3,4 when the system is expecting 4,3,2,1
Aha... I just worked it out in excel... writing a single bit will be 256^0, 256^1, 256^2, 256^3 depending on the variant
that is 1, 256, 65536, and 16777216 - which I recognize from my testing
le16 () { # big endian 16 bit; 1st param: integer to 2nd param: file
v=`awk -v n=$2 'BEGIN{printf "%04X", n;}'`
echo -n -e "\\x${v:0:2}\\x${v:2:2}" >> $1
}
be32 () { # 32 bit version of big-endian
v=`awk -v n=$1 'BEGIN{printf "%08X", n;}'`
echo -n -e "\\x${v:0:2}\\x${v:2:2}\\x${v:4:2}\\x${v:6:2}" >> $2
}