Device ID direct access function

[johntalton]

first pass addition of i2c_smbus_deviceid (tested on rpi with fujitsu mb85 fram (http://www.fujitsu.com/global/documents/products/devices/semiconductor/fram/lineup/MB85RC256V-DS501-00017-5v1-E.pdf) on address 0x50, outputting 0xA510 [aka correct value for device])

top level issues / request for comment:

• naming (Id vs ID etc)
• should deviceId be similar to i2c-func (that is, should it be named i2c_deviceId in a file name i2cdeviceid.h/cc) (software reset would follow the same pattern)
• returns full 24bit packed int. should this be split into Manufacture / Product (in cc or js?)
• Table 4 of the spec lists "standard" manufactures, encode this some place for convenience
• move F8/F9 (7C address) magic to defines
• error checking / byte conversion etc validation
• currently missing sync call

[fivdi]

@johntalton very nice :smile:

top level issues / request for comment:

• naming (Id vs ID etc)
  • Id
• should deviceId be similar to i2c-func (that is, should it be named i2c_deviceId in a file name i2cdeviceid.h/cc) (software reset would follow the same pattern)
  • Call it DeviceId in a file named deviceid.h/.cc (the naming in the PR code looks good to me)
• returns full 24bit packed int. should this be split into Manufacture / Product (in cc or js?)
  • Yes, it should be split in JS
• Table 4 of the spec lists "standard" manufactures, encode this some place for convenience
  • Sounds like a good idea to me
• move F8/F9 (7C address) magic to defines
  • Yes
• error checking / byte conversion etc validation
  • Do error checking and conversions in JS where possible
• currently missing sync call
  • It's there in C++ but it's not there in JS yet

Additional Stuff:

• Documentation in the README is needed

[johntalton]

for the parseId method of deviceId*, i am not sure if the return type of an object is "right" for this lib. maybe the callback should take (err, man, prod, name) or just (err, man, prod) and externalize the "enum" list?

also used (ret > 0) in C-code for ioctl return checking (Zero is a valid return). This is slightly different from the other implicit if(ioctl..) call which casts the int to boolean.

I have NOT included the other I2C method (SoftwareReset and ReloadAddress) as they both can be implemented on-top of the existing api. thus at best they should live in the JS code (or just not included at all an left for the higher level implementor). Your call.

Please feel free to rewrite the README - it likely would "sound" better in your "voice" (you would be surprised how far consistency in docs goes :) )

[fivdi]

for the parseId method of deviceId*, i am not sure if the return type of an object is "right" for this lib. maybe the callback should take (err, man, prod, name) or just (err, man, prod) and externalize the "enum" list?

I prefer return type object. deviceId is a bit like i2cFuncs.

Please feel free to rewrite the README - it likely would "sound" better in your "voice" (you would be surprised how far consistency in docs goes :) )

Ok :)