#Iwrite lua on iphone driver#

With a read lenght of 1, my results are as follows: 0x08: table: 0x2000BE18 (value alternates, which is not expected) With no read length specified I seem to reliably get the msb of the regisers and my print outs are as follows: 0x05: 193 (up to 200 if I cook the sensor) Return update() - run immediately before starting to reschedule Return update, 1000 - reschedules the loop Local i2c_bus = i2c:get_device(0,MCP9808_ADDR_0)įunction update() - this is the loop which periodically runs My minimal script is as follows: local MCP9808_ADDR_0 = 0x18 of the data sheet specifies some other registers with expected values, the expected values are as follows:Ġx05 -> variable (this is where we expect to find the 16 bit temperature)

The device is definitely streaming, the readings stay stable and when I blast it with a heat-gun they do go up, but the reading does not change as much as it should and I’m getting very unlikely values. It’s very similar to the MCP9600 wich you already support.

#Iwrite lua on iphone driver#

I’m trying to write a lua driver for an MCP9808 temperature sensor. Hi I’m having a little trouble with i2c multi byte read. PORTB |= (1<0b10000000) // link I2C busses with PCA9534 pin 7 (unused alternative)

I2C_write(0x01) // link I2C busses with PCA9534 pin 7 (unused alternative) I2C_write(0x00) // DEBUG: to check for ACK on logic analyzer trace (successful address change) _delay_ms(10) // wait for sensor to get ready I2C_write(xshut_pins_set) // enable next sensor I2C_write(~xshut_pins_mask) // enable outputs on P6,4,2,1,0 (active low) #define ADDR_PCA9534 (0x20 slave reads the bit #define I2C_SCL_LOW() DDRB |= (1 pulled LOW by MCU #define I2C_SCL_HIGH() DDRB &= ~(1 pulled HIGH by resistor #define I2C_SDA_LOW() DDRB |= (1 pulled LOW by MCU #define I2C_SDA_HIGH() DDRB &= ~(1 pulled HIGH by resistor #define I2C_LINK PB0 // controls the MOSFETs that link the I2C busses

Clockspeed: 8 MHz internal, clockdiv 8 How can those be (ab)used in LUA?īitcraze_multiranger_initializer 1210×386 69.6 KB // +-/-+ There are write_register16 functions in AP_RangeFinder_VL53L0X and AP_RangeFinder_VL53L1X (confusingly with different signature - (uint8_t reg, uint16_t value) for the L0X, (uint16_t reg, uint16_t value) for the L1X), that would send 3 or 4 bytes respectively. Unfortunately, I don’t think that’s practical for inclusion as a PR at the moment for the reasons provided in the linked topic. If you’re willing to build your own firmware, you could write a custom binding to transfer 3 bytes. Though even an attiny10 (6 pin SOT23-6 package) should be able to do it, I’d still have to “split” the I2C bus with all the support circuitry, while I’d rather have the flight controller do the work. That’s what I wanted to avoid since I’m literally one byte away from a solution. Otherwise you may be stuck using an intermediate microcontroller to interpret scripted messages and send sensor values back. Unfortunately it is stored in volatile memory only. If the address is stored in non-volatile memory, you might try connecting it to another device like an Arduino or ESP board, writing the address, and then using it with your script. I tried that already, but as expected it does not work. At the moment, I don’t think you can send three consecutive bytes like that (though maybe two consecutive writeregister calls may be interpreted by the device that way - I kind of doubt it).