• @LawrenceGrif, np, urvw. Since the division is always by 32768 and the raw value is config dependent, I did not see any value in delivering the raw value...

    Ports from Arduino have their challenges: it is a very good start. In this case, I have the feeling that not all things made it through - first functionl, and second Espruino typical / spirit. The code is in an intermediary stage. For usage different from defaults, only gain made it.

    For me, Espruino typical is taking advantage of JavaScript's dynamics / no compile and easy to use (litteral) object-orientation. For that I expect to pass optionally a config (modifying) object at setup time as well as at read / conversion time. The current code looks like a lot of compile language with all the symbols in the CONFIG object - which are just space-eat-aways in Espruino. Yes, it can make the code very readable and its usage 'simpler', but for quite a high price. For keeping both - frugal resource use under constraint and easy config under no constraints - and applying either only one or both depending the situation, splitting the code into two modules ADS1x15 and ADS1x5Cfg a good solution:

    1. ADS1x15 module is bare metal operation code wit optional acceptance of a config value in masked config register format: {cfg:0x####, msk:0x####}. cfg includes the bits to set msk is the (combined) mask.
    2. ADS1x15 module provides code to easily (and safely) create the config object from scratch or applies changes on the retrievable register object.

    I can see applications where changing gain between readings of the very same channel makes sense: 1st read is to find the value range, second read is for more digits for that channel's final read... assuming that the value is slow changin / time does not play that a signifcant role.

    Example code for passing config or config modification information at connect time - adjusting default created registry object with 4096 (= 0x0200) gain:

    // var ads = new ADS1x15(i2c,0x48,{cfg:0x0200, msk:0x0E00});
    var ads = ADS1x15Mod.connect(i2c,0x48,{cfg:0x0200,­ msk:0x0E00});
    // var ads = require("ADS1x15").connect(i2c,0x48,{cfg­:0x0200, msk:0x0E00});
    

    Example code for passing config or config modification information at conversion time - adjusting default created registry object with 2048 (= 0x0200) - back to default - gain:

    ads.getADC(1,function(v){ console.log("CH1: " + v + "V"); },{cfg:0x0400, msk:0x0E00});
    

    Example code for bare operations module (0x8583 sets defaults):

    .
    ..
    ...
    var ADS1x15 = function(i2c,addr,cfg) {
      this.i2c = i2c;
      this.addr = addr;
      this.reg = 0x8583;
      if (cfg) { this.cfg(cfg); }
    }, p = ADS1x15.prototype;
    
    p.cfg = function(cfg) {
      this.reg = (this.reg  & (0xFFFF ^ cfg.msk)) || (cfg.cfg & cfg.msk);
    };
    
    p.writeReg = function(reg, val) {
      this.i2c.writeTo(this.addr, reg, val>>8, val);  
    };
    
    p.readReg = function(reg) {
      this.i2c.writeTo(this.addr, reg);  
      var d = this.i2c.readFrom(this.addr, 2);
      return (d[0] << 8) | d[1];  
    };
    
    p.getADC = function(channel, callback,cfg) {
      if (cfg) { this.cfg(cfg); }
      this.writeReg(1, this.cfg || (channel << 12)));
      var _this = this;
      setTimeout(function(){ callback(_this.readReg(0)/32768); }, 8);
    };
    
    ADS1x15xMod = 
    { connect: function(i2c,addr,cfg) { 
        return new ADS1x1x(i2c,addr,cfg);
      }
    }
    // export(ADS1x15Mod);
    ...
    ..
    .
    

    Btw, noticed that there is no need to do bit shifting on result for AD10XX series. The read raw value hast just a less fine granulation (resolution)... smart choice from TI: ADS1x1x are pin compatible with the ADS101x series being just less accurate...

    As mentioned earlier, I'd have a gain config for each channel (gain flexibility saves hardware...). Therefore, gain may be a thing to handle differently from passing other config values.

    Since sequencing is predictable by design of the app - assuming all of the design is controllable - busy checking and other more sophisticate things to make operation safe would only bloat the bare metal module.

    The config helper / support module may show as a separate post...

    PS: Code only partially verified... have no ADS1x1x at hand... :( ... :)

About

Avatar for allObjects @allObjects started