• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!


  • Content count

  • Joined

  • Last visited

  • Days Won

  1. Has anyone experienced issues with the msp430FR5739 experimenter board with the latest energia v 18? I can't seem to program it using the latest version on my windows 10, 7 or mac. I get the following error message: usbutil: unable to find a device matching 0451:f432 An error occurred while uploading the sketch Thanks!
  2. It would be nice to have something like analog_read(VCC2) to get the reading, similar to TEMPSENSOR.
  3. Hi! Is there a way to use the Vcc/2 source for the ADC on the msp430FR5969 chip using energia? Thanks!
  4. Yes, another issue with the OPT3001.cpp (or is it?) is that instead of using the calculation methods of the datasheet, they use a shortcut using bit shifting to approximate the exponent multiplication constant. This is probably to keep the data as a uint32_t instead of a float. To get the exact data as the OPT3001EVM, I replaced the opt3001::readResult() function on 146 of OPT3001.cpp (and the prototype in OPT3001.h to a float) to: float opt3001::readResult() { uint16_t exponent = 0; float result = 0; int16_t raw; raw = readRegister(RESULT_REG); /*Convert to LUX*/ //extract result & exponent data from raw readings result = raw&0x0FFF; exponent = (raw>>12)&0x000F; //convert raw readings to LUX switch(exponent){ case 0: //*0.015625 result = result*0.01; break; case 1: //*0.03125 result = result*0.02; break; case 2: //*0.0625 result = result*0.04; break; case 3: //*0.125 result = result*0.08; break; case 4: //*0.25 result = result*0.16; break; case 5: //*0.5 result = result*0.32; break; case 6: result = result*0.64; break; case 7: //*2 result = result*1.28; break; case 8: //*4 result = result*2.56; break; case 9: //*8 result = result*5.12; break; case 10: //*16 result = result*10.24; break; case 11: //*32 result = result*20.48; break; default: result = 0; } return result; }
  5. I think I have found the issue: In the energia opt3001.cpp code (line 77) the implementation for the register read readRegister(uint8_t registerName) declared the lsb, msb and result variables as int8_t. (line 79, OPT3001.cpp) int8_t lsb; int8_t msb; int16_t result; I changed this to unsigned, as they are supposed to be: uint8_t lsb; uint8_t msb; uint16_t result; The code now works. Thank you for sharing your library @@Rei Vilo, I was able to realize this by doing a side by side comparison with your code. I hope this will prevent any issues you may have with your project @@NurseBob!
  6. I know how you feel @@NurseBob, wow nursing instructor at day, developer at night? Thanks @@Rei Vilo, I downloaded the SensorsWeather_Library and hooked up my sensor to the CC3200 launchpad. It works without glitches now! There is still a NAK at the end of the wire transmission, but the CC3200 seems to have no problem getting the correct value. I am more convinced that it is some timing issue with the energia wire implementation.
  7. Thanks for sharing @BobNurse, it's interesting that it's a NAK instead of an ACK. I wonder if this has to do something with Energia's wire implementation? It's interesting that the USB messages also reflect 'missed' data reports. To see if the USB reporting had anything to interfere with the i2c, I tried an experiment where instead of reporting the received data on the USB after each i2c read, I had it so that the msp would log 10 data points, and then spit out the 10 readings via USB once the 10 i2c readings were completed. The results however still indicated that the data still was corrupted during the i2c reads (that technically had no USB interference). It really is an odd issue.
  8. Thanks Bob, I really appreciate the help! I took a look at the OPT3001EVM module: It looks like it's reading the configuration bit, waits 13ms, reads the value, then waits another 45ms for the next cycle. There is no signal on the interrupt bit. Here are the captured waveforms. Instead of my sensor I mounted 2k resistors on the OPT3001EVM daughter board SCL, SDA and INT pins, then connected it directly to the msp430 as you suggested - oddly I am seeing that the configuration bit and the value are correctly captured in the logic probe, but when doing a Serial.print to the captured values on the UART it seems that the first byte for both the configuration bit and the value is read as 0xFF. So although the sensor is properly sending out a proper configuration register value and raw value (0xC490 and 0x1EDB), the msp430 somehow misses the first byte (0xFF90 and 0xFFDB). I tried it on the TivaC as well, and see the same results.
  9. Thanks @@Rei Vilo, I am currently using the Energia OPT3001 library, and experiencing the same issues with the example code. I did purchase an educational boosterPack MK-II to make sure it's not a hardware issue, but so far the issue seems to be consistent on both the Wolverine and Tiva C launchpads with the energia library.
  10. Thanks for the insight @@NurseBob! Yes, I do recall reading about the transient response, and have done a side by side comparison with the OPT3001EVM evaluation kit. I have tried experiments where I swing a light across the sensor rapidly across both the evaluation module and my msp430 board. The msp430 board returns a corrupted value, while the evaluation module responds with no problems. I have tried checking the "Conversion Ready" field before making a read, but I still get corrupted values read on the msp430. Also, I have checked the sensor signal coming from a logic probe, and the values do seem to come out as un-corrupted values during rapid transitions. It's odd that they don't on the msp430.
  11. I tried various resistors (ranging from 1k-5k) but still no luck...under a scope it looks like the data is being sent correctly from the sensor, it just doesn't reflect the value read within the msp430 processor.
  12. I will give that a try!
  13. Hi, does anyone have experience with the OPT3001 sensor using custom hardware or interfacing to the msp430 launchpad? I have a sensor on the TI opt3001EVM daughter board, with the SDA pins and SCL pins connected to vdd via 10k resistor, for a msp430fr5969 wolverine launchpad - I am able to read the data from the sensor, but every time I rapidly change a test light source (flash a light on the sensor, or put my hand to cover it), I get a corrupted reading (it reads FFxx). I currently have it set to poll at 100ms, and at autoscale with no mask. The autoscale does work, it's just during transition periods the first byte is read 0xFF. The sensor works fine using the TI OPT3001EVM module. Thanks for any insight or help! The configuration register is set to the following value - 0b1100010000010000 - Automatic full scale setting mode - 100ms conversion time - Continuous conversion mode - Mask field disabled - latched mode enabled
  14. Just curious, has there been any progress on this matter? Has anyone tried packaging a usb_dev_serial.c type application for energia?