The new database format as well as the new socket module interface made me rethink the data handling API in libdax. I have rewritten the three "raw" reading and writing functions (I've also renamed them). They are dax_read(), dax_write() and dax_mask(). They are the functions that actually get called to read/write raw data to/from the server. They make no assumptions about the underlying datatype. It is assumed that the module will send the data to these functions in the same format that they exist on the server. The dax_mask() function is a writing function that also includes a bit mask. The server will only change the bits in the database that are set in the mask.
I also wrote three new functions that closely match the "raw" functions. They are dax_read_tag(), dax_write_tag() and dax_mask_tag(). These functions look them same but they are passed the data type of the data. Then they make the proper conversions from the module's data format to the servers data format and then call the "raw" functions to send the data. These functions do not check that the tag that is being written to or read from is, in fact, of that data type.
Before I made these changes there were several "bit" manipulation functions. These were used for reading and writing individual bits (or arrays of bits) in the database. They are very broken at the moment because tag handles no longer represent binary offsets within the database, they are simply indexes into an array. I can't decide whether or not I want to mess with these at this point. One of the data types is a DAX_BOOL and I go to great lengths to get those right in the library routines, so the only reason that these would exist is for modules to manipulate individual bits within other datatypes. If I decide to remove them from the API then the modbus module will be seriously broken. I am beginning to think that its interface is flawed as well. That'll have to wait for another post.
The data manipulation functions seem to work but I have not thoroughly tested them yet. I'm am mostly concerned with the DAX_BOOL handling parts and the error conditions.