Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
ephphatha
Dec 18, 2009




Nerobro posted:

I got a Christmas present from Kickstarter. My Digisparks showed up Monday. A full review will follow. So far.. I've run into two things. First, the documentation isn't immediately obvious, and you need a custom version of the IDE. But... that only set me back half an hour.

Mine arrived on tuesday, I pulled out my parts bin and found I have jack all in the way of useful components (plenty of resistors, capacitors, transistors and unlabelled LEDs of various colours and sizes, but no solid core wire to hook up any of it).

I've so far only bothered modifying the USB2LCD example to autoscroll (ie, move a complete line from the bottom to the top row and start writing on the bottom line) and haven't yet got a daemon running on my pc to send data to it. Eventually I think I'll try make it run standalone with an ethernet module and basic http stack so it can pull data from twitter and display tweets, since that's what all the cool kids seem to do. It'll be interesting to see if I can get that to fit on a digispark solo or if I need to use the eeprom module.

Adbot
ADBOT LOVES YOU

ephphatha
Dec 18, 2009




I've got a digispark pro (ATtiny167 based device) and I'm trying to read temp/humidity data from an AM2320. I can't get a proper read from it. The datasheet says the response should be a sequence of bytes confirming the instruction, the datagram length, the requested data, then a two byte CRC. What I'm actually getting back is the instruction confirmation, a zero byte, the expected length, then 0 bytes for the rest of the data.

I've got it hooked up to 5v and to the SDA/SCL pins on the pro (with 4.7k pullups) and the basic code I'm using is as follows:

code:
#include <Wire.h> //Actually refers to TinyWireM.h

#define AM2320_ADDRESS (0xB8 >> 1)
#define AM2320_READREG 0x03

void setup() {
  Wire.begin();
}

void loop() {
  //wake up the sensor
  Wire.beginTransmission(AM2320_ADDRESS);
  delay(1); //Need to wait 800us to 3ms before sending endTransmission.
  uint8_t retVal = Wire.endTransmission();

  //retVal is 0x01, no ACK on address  

  delay(2); //No wait necessary before triggering read?

  //tell the sensor we want the current readings
  Wire.beginTransmission(AM2320_ADDRESS);
  Wire.write(AM2320_READREG); //Read sensor data
  Wire.write(0x00); //Start from the first register
  Wire.write(4); //Read all registers (2 bytes per sensor, 2 sensors)
  retVal = Wire.endTransmission();

  //retVal is usually 0x01, no ACK on address - occasionally 0x02, no ACK on data on the first iteration

  delay(10); //Need to wait at least 1.5ms before requesting data.

  retVal = Wire.requestFrom(AM2320_ADDRESS, 8);

  //retVal is again 0x01, no ACK on address

  union {
    byte buffer[8];
    struct {
      byte instruction;
      byte length;
      unsigned short humidity;
      short temp;
      unsigned short crc;
    } data;
  } sensor;

  for (uint8_t i = 0; i < 8; ++i) {
    if (retVal = Wire.available()) {
      sensor.buffer[i] = Wire.read();
      //retVal counts down from 8 as expected.
      //sensor.buffer fills with 03:00:04:00:00:00:00:00, expected 03:04:hh:hl:th:tl:ch:cl
    } else {
      break;
    }
  }

  delay(2000);
}
I hadn't been checking the return codes of most of the wire calls when first testing since it seems to recognise the command and at least start to build a proper response, so I'm not sure if the no-acks are something I should be concerned about. I'm also getting a consistent response, the exact same sequence of bytes and (99.9% of the time) the same error codes for the endTransmission/requestFrom calls every time it executes.

As far as I can tell the timings in the USI_TWI_Master files are exactly what the sensor expects but I'm not confident enough to try change any of those values. I've also seen other code samples for this sensor put a delay between reads but with the tinywire library the requested data is prefetched when requestFrom is called so there's no point.

Any ideas what's loving up and how I can fix it?

ephphatha
Dec 18, 2009




Captain Cool posted:

You're not actually talking to the device. The device should ack its address. The response you're getting -- 03 00 04 00 ... -- is the same as the command you sent. I'm guessing the Wire library uses the same buffer for sending and receiving.

Welp, that seems so obvious in retrospect. Thanks, I'll see if I can get this thing to respond.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply