Jump to content
43oh

grodius

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    grodius got a reaction from tripwire in Working with MPU6050 on MSP430   
    Just a discussion point, I think the motivation to pair an MSP430 with an MPU6050 is justified based on the Invensense hype and PR that all the heavy lifting would be handled by the magical DMP onboard coprocessor. In the real world, the gyro and acc data is very noisy and filter and calibration dependent. It's a really useful experiment to play with as it broke some of my theoretical idealism with the reality that sensors are super noisy. Getting the best and fastest possible orientation from this device will be a combination of filtering the raw data and combining data. It really felt like every 6050 was different, so the chances the filtering and IMU combination being optimal in the DMP feels iffy, but I would try and see.
     
    My personal recommendation is to fire up a 2452 launchpad with the terrific I2C explorer from this forum and have a play with what you can get back from the sensor documentation. I then modified the I2C explorer to a binary serial connection and did all my tinkering in a java app to get an understanding of the sensor under movement without constantly flashing a device.
  2. Like
    grodius got a reaction from abecedarian in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    I bought two of the Hercules RM57L launchpads. I wonder why these aren't popular? At 330 mhz they could almost emulate an MSP430 and they look pretty classy.
  3. Like
    grodius reacted to RobertWoodruff in Anyone tried to use AT+CLASS= on the HC-05 Bluetooth module?   
    Hi Roboticus,
     
    You are correct,  the parameter values to AT+CLASS= are hex numbers. There is a overview in the Bluetooth spec about formatting and interpreting the 32 bit class value (CoD). I am not going to learn all that now but have learned enough to carry forward with this application.
     
    Here is a translation between what is sent to the AT command and what is seen on the Android side
     
    /* Android Java code segment */
    BluetoothClass bluetoothClass = btDevice.getBluetoothClass();
    int deviceClass = bluetoothClass.getDeviceClass();
    int majorDeviceclass = bluetoothClass.getMajorDeviceClass();
     
    Apparently the default in the HC-05 is that lowest two bits of whatever hex value is sent to AT+CLASS= are set to 0 by the time it can be picked up on the Android side by deviceClass = bluetoothClass.getDeviceClass(); The majorDeviceclass is coming in at 0x100.
     
    Here are a few test cases I tried
     
    AT value(hex, binary)                deviceClass          majorDeviceClass  
    128, 0001 0010 1000      0x128          0x100
    129, 0001 0010 1001      0x128          0x100
    12A, 0001 0010 1010      0x128          0x100
    12B, 0001 0010 1011      0x128          0x100
    12C, 0001 0010 1100      0x12C          0x100
    12D, 0001 0010 1101      0x12C          0x100
     
    There are also web sites where you can enter the characteristics of your BT device and it will generate a CoD (class of device) hex number for you.
     
    Hope this info is useful to someone out there.
     
    Thank you,
  4. Like
    grodius reacted to Rickta59 in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    There is the openmsp430 implemention on FPGA chips. Some seem to go to 100MHz
     
    http://opencores.org/project,openmsp430,area%20and%20speed%20analysis
  5. Like
    grodius got a reaction from Fmilburn in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    I'll politely advocate for the architectural constraints If TI committed to pipelining the MSP, they would most likely need to rework the variable length instruction set and break backwards/forwards compatibility. Adding pipelining overhead to the chip would also draw considerably more power from a chip sold as being a leader in low power. In the end, it's cheaper for TI to just buy an ARM license with a mature instruction set and architectural design and continue with higher frequency Cortex architectures. I think if ARM were not a more attractive option, there would be higher clocked pipelined MSPs hitting the market.
  6. Like
    grodius got a reaction from greeeg in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    I'll politely advocate for the architectural constraints If TI committed to pipelining the MSP, they would most likely need to rework the variable length instruction set and break backwards/forwards compatibility. Adding pipelining overhead to the chip would also draw considerably more power from a chip sold as being a leader in low power. In the end, it's cheaper for TI to just buy an ARM license with a mature instruction set and architectural design and continue with higher frequency Cortex architectures. I think if ARM were not a more attractive option, there would be higher clocked pipelined MSPs hitting the market.
  7. Like
    grodius got a reaction from spirilis in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    I'll politely advocate for the architectural constraints If TI committed to pipelining the MSP, they would most likely need to rework the variable length instruction set and break backwards/forwards compatibility. Adding pipelining overhead to the chip would also draw considerably more power from a chip sold as being a leader in low power. In the end, it's cheaper for TI to just buy an ARM license with a mature instruction set and architectural design and continue with higher frequency Cortex architectures. I think if ARM were not a more attractive option, there would be higher clocked pipelined MSPs hitting the market.
  8. Like
    grodius reacted to spirilis in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    Almost way too overpowered, and the dev environment is a bit unconventionally restrictive - you have to use HALCoGen to generate projects and CCS for the coding/building/debugging.  Not too bad for folks already comfy with the CCS toolchain et al, but it's still quite esoteric.  Probably 99% of hobbyist projects have no need for the power too... although there's a "Jan Cumps" on twitter from Belgium who's adopted the Hercules as his pet MCU of choice for giggles.
     
    This is all mostly due to its "safety critical" nature, which shapes everything about how TI supports it.  TI's own TI-RTOS (aka SYS/BIOS aka DSP/BIOS) doesn't even support it, they include project generation for FreeRTOS for those who want an RTOS on the chip.  FreeRTOS does have safety critical "support" via their SafeRTOS variant.
     
    OTOH the fact they have an all-in-one project generation tool that supports all the peripherals including the fascinating custom-VLIW instruction set "HET" timer is a bit envy-worthy; most TI MCUs just don't have such an "all in one" configurator.
     
    Anyway I recommend you roll with it regardless!  There's probably a lot of cool stuff you can do with those with the right motivation.
  9. Like
    grodius got a reaction from spirilis in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    I bought two of the Hercules RM57L launchpads. I wonder why these aren't popular? At 330 mhz they could almost emulate an MSP430 and they look pretty classy.
  10. Like
    grodius got a reaction from tripwire in TI OPT8241 Time of flight QVGA 3D sensor   
    It's more complex, but not too far removed from the Tindie for the ADNS-9800 laser mouse. Some bright enterprising spark might put together a hyper breakout. I'm mainly pleased that the early models are already very fast and high res.
     
    I personally really wish micromouse competitions forced the pros to use ONLY visual recognition and/or new tech. Micromouse comps are over-ripe slotcars now where sensor development and experimentation might be fun.
     
    It's worth just thinking about devices like these. I like the thought that you might only need one array receiver and maybe multiple light sources in sequence to triangulate or for redundancy/data improvement.
  11. Like
    grodius got a reaction from chicken in TI OPT8241 Time of flight QVGA 3D sensor   
    This is a quite exciting new sensor. The development kit is prohibitively expensive and the chip driver is 256BGA, but at around $50 for the raw sensor capable of 150 fps of 320x240 with distance, this is cool.
     
    Time of flight pulses out light/IR and counts the sub nanoseconds it takes to bounce back.
     
    The specs are pretty impressive for an early model.
     
    http://www.ti.com/product/OPT8241
     
    Ideally I would prefer the device and driver chip were paired on a board, but hopefully these will be popular and warrant more integrated solutions.
  12. Like
    grodius got a reaction from pine in TI OPT8241 Time of flight QVGA 3D sensor   
    This is a quite exciting new sensor. The development kit is prohibitively expensive and the chip driver is 256BGA, but at around $50 for the raw sensor capable of 150 fps of 320x240 with distance, this is cool.
     
    Time of flight pulses out light/IR and counts the sub nanoseconds it takes to bounce back.
     
    The specs are pretty impressive for an early model.
     
    http://www.ti.com/product/OPT8241
     
    Ideally I would prefer the device and driver chip were paired on a board, but hopefully these will be popular and warrant more integrated solutions.
  13. Like
    grodius got a reaction from bluehash in TI OPT8241 Time of flight QVGA 3D sensor   
    This is a quite exciting new sensor. The development kit is prohibitively expensive and the chip driver is 256BGA, but at around $50 for the raw sensor capable of 150 fps of 320x240 with distance, this is cool.
     
    Time of flight pulses out light/IR and counts the sub nanoseconds it takes to bounce back.
     
    The specs are pretty impressive for an early model.
     
    http://www.ti.com/product/OPT8241
     
    Ideally I would prefer the device and driver chip were paired on a board, but hopefully these will be popular and warrant more integrated solutions.
  14. Like
    grodius got a reaction from tripwire in F35B JSF Software   
    Tonight on Australian TV there was an investigation into the beleaguered X35/F35B Fighter plane and I couldn't believe my ears at the words of one of the most senior US military officials involved.  The context was such that it wasn't simply an error of detail.  It shows he really has no idea about software development at all.  Whatsoever.
     
    The following is from the formal released transcript:
     
    "LT. GENERAL CHRIS BOGDAN: This is a very software-intensive airplane. There's over 10,000 lines of software code just on the airplane itself and there's another 10 million lines of code for all the off-board systems, the maintenance systems and the mission planning systems that go with it." (By off-board he was talking ground component.)
     
    I have a non-embedded banking software background, but that number is so wide of the mark for one of the most software dependent planes in existence that I laughed out loud.  This is circa a half trillion dollar project and the top military official directly involved doesn't understand software development at all.  I would be disappointed if a sidewinder missile didn't have 10,000 lines of code, let alone a new plane to be finally released 2018 ish.
     
    Some versions of the plane are capable of VTOL, thrust vectoring, entirely computerized console with what appears to be touch screen interface.
     
    PS The Stellaris Launchpad has 256kb flash so shelve those non ambitious, non Jet Fighter projects now. 
     
    Dennis Nedry from Jurassic Park:
     
    "Do you know anyone who can network 8 connection machines and debug 2 million lines of code for what I bid for this job?"
     
  15. Like
    grodius got a reaction from roadrunner84 in F35B JSF Software   
    Tonight on Australian TV there was an investigation into the beleaguered X35/F35B Fighter plane and I couldn't believe my ears at the words of one of the most senior US military officials involved.  The context was such that it wasn't simply an error of detail.  It shows he really has no idea about software development at all.  Whatsoever.
     
    The following is from the formal released transcript:
     
    "LT. GENERAL CHRIS BOGDAN: This is a very software-intensive airplane. There's over 10,000 lines of software code just on the airplane itself and there's another 10 million lines of code for all the off-board systems, the maintenance systems and the mission planning systems that go with it." (By off-board he was talking ground component.)
     
    I have a non-embedded banking software background, but that number is so wide of the mark for one of the most software dependent planes in existence that I laughed out loud.  This is circa a half trillion dollar project and the top military official directly involved doesn't understand software development at all.  I would be disappointed if a sidewinder missile didn't have 10,000 lines of code, let alone a new plane to be finally released 2018 ish.
     
    Some versions of the plane are capable of VTOL, thrust vectoring, entirely computerized console with what appears to be touch screen interface.
     
    PS The Stellaris Launchpad has 256kb flash so shelve those non ambitious, non Jet Fighter projects now. 
     
    Dennis Nedry from Jurassic Park:
     
    "Do you know anyone who can network 8 connection machines and debug 2 million lines of code for what I bid for this job?"
     
  16. Like
    grodius got a reaction from yyrkoon in DIY MSP430 wifi connectivity with retail router   
    The following is a slight tangent on this network theme, but I've been using Bluetooth HC-05 modules for wireless UART connectivity.  They are readily available for $5 shipped.  I have only used them up to 115,200 but they probably can achieve 1 megabit per second and allow for connection to desktops or direct to Android devices while using UART hardware so not much strain on the processor.
  17. Like
    grodius got a reaction from yyrkoon in Bounty: $20,- to solve a simple project (OPEN )   
    (First off, I'm not fishing for the bounty as I don't have a 2231)
     
    The send stop condition within the master i2c looks very much like the 'restart' posted elsewhere on this forum.  It seems like you are trying a:
     
    start -> write -> incomplete/partial stop -> restart. ( not start -> write -> stop )
     
    It looks like you commented out the actual stop code but this is likely leaving your state as started from the restart.  You should remove any restart code as it isn't necessary within the scope of this project.  You are leaving your I2C in a start as you leave and prepare for the next when you want to have stopped.
     
    I highly recommend printing/dumping your i2c state variable to see where things are finally stopping.  What you are hoping to do on the master side can be achieved entirely with a start, write and stop command.  Have faith in that and lift some existing code that is known to do that.
     
    (I would recommend removing the state machine altogether and have this project as a simple non-interrupt synchronous loop.  As a simple project it would be soooo much simpler, then build it up from there).  Some of the functions you have copied are blocking synchronous style where the majority and framework is interrupt based.  Some of the flags being blocked upon might be read or set by the interrupt handler.
     
    So what do I recommend:
     
    throw away the master  i2c code
    use cde's i2c code from the latest i2c explorer
    write your  I2CMaster_Transmit ( ) in terms of blocking start-write-write...write,stop with maybe some modest delays in-between.  I'm pretty sure that can be done with either no or minimal interrupts
     
    (For the master side I see no reason why the i2c_explorer itself wouldn't be the quickest way to test)
     
    then when that is working get fancy
  18. Like
    grodius got a reaction from jsolarski in Help! MMA8452Q accelerometer with Launchpad   
    1) if the accelerometer is on a breakout then you can commit to that device and get started.  If it's just a 20 pin QFN probably I recommend something on a breakout board while you experiment.
     
    2) I recommend CDE's I2C explorer found on this forum as a starting point.  Get that going on your microcontroller and serial terminal.  It would help to find out whether you will be using a 2452 or earlier 2231.
     
    I disabled all internal pullups within the code and made a UART change for it to work with the 2452.
     
    In general you will only need 4 wires to connect a device:
     
    - most 3.3 LDO voltage regulators provided on the cheap breakout boards seem to be happy with the 3.6v the launchpad provides
    - ground
    - SDA and SCL ( I pull these high with 4K7 ohm) SDA 1.7 SCL 1.6
     
    other broken out lines are generally used for addressing/chip select (which I do do) or slave initiated interrupts which will likely be of high interest in your freefall detection.
     
    In general, many devices will have:
     
    - a sleep/wake register you will write to to begin taking readings
    - a series of data registers you can read at your master initiated leisure
     
    - you will want to find the register/s to set a freefall interrupt on a pin if that suits.
     
    Often there is so much confusion on the internet that the datasheet is the simplest first place to look, but being lazy I usually look for an arduino sample and look for:
     
    - slave address
    - initiation register and value ( usually to wake from sleep mode )
    - data register
     
    (*devices will vary but accelerometers seem pretty similar for that at least)
     
    I will then use the I2C explorer with the search 's' command to confirm it is communicating.  It will display the 2 cooked slave addresses. Familiarize yourself with the I2C Slave address shifting semantics for R and W. [ SLAVE ADDRESS 7 bits (left shifted 1 bit)  ][ W:0 R:1 1 bit ].  Different modules and/or software will address this single byte differently.
     
    After that I would study the datasheet and find out range setting / power modes etc and, in the case of the Invensense MPU6050, lament why oh why such power must be deliberately obfuscated and withheld from the hobbyist community.   I should be preaching read the datasheet thoroughly first, but in reality once your I2C is up and running it is simple enough that you go straight to raw data reading and then backwards to modes etc from there.
  19. Like
    grodius got a reaction from bluehash in Help! MMA8452Q accelerometer with Launchpad   
    1) if the accelerometer is on a breakout then you can commit to that device and get started.  If it's just a 20 pin QFN probably I recommend something on a breakout board while you experiment.
     
    2) I recommend CDE's I2C explorer found on this forum as a starting point.  Get that going on your microcontroller and serial terminal.  It would help to find out whether you will be using a 2452 or earlier 2231.
     
    I disabled all internal pullups within the code and made a UART change for it to work with the 2452.
     
    In general you will only need 4 wires to connect a device:
     
    - most 3.3 LDO voltage regulators provided on the cheap breakout boards seem to be happy with the 3.6v the launchpad provides
    - ground
    - SDA and SCL ( I pull these high with 4K7 ohm) SDA 1.7 SCL 1.6
     
    other broken out lines are generally used for addressing/chip select (which I do do) or slave initiated interrupts which will likely be of high interest in your freefall detection.
     
    In general, many devices will have:
     
    - a sleep/wake register you will write to to begin taking readings
    - a series of data registers you can read at your master initiated leisure
     
    - you will want to find the register/s to set a freefall interrupt on a pin if that suits.
     
    Often there is so much confusion on the internet that the datasheet is the simplest first place to look, but being lazy I usually look for an arduino sample and look for:
     
    - slave address
    - initiation register and value ( usually to wake from sleep mode )
    - data register
     
    (*devices will vary but accelerometers seem pretty similar for that at least)
     
    I will then use the I2C explorer with the search 's' command to confirm it is communicating.  It will display the 2 cooked slave addresses. Familiarize yourself with the I2C Slave address shifting semantics for R and W. [ SLAVE ADDRESS 7 bits (left shifted 1 bit)  ][ W:0 R:1 1 bit ].  Different modules and/or software will address this single byte differently.
     
    After that I would study the datasheet and find out range setting / power modes etc and, in the case of the Invensense MPU6050, lament why oh why such power must be deliberately obfuscated and withheld from the hobbyist community.   I should be preaching read the datasheet thoroughly first, but in reality once your I2C is up and running it is simple enough that you go straight to raw data reading and then backwards to modes etc from there.
  20. Like
    grodius got a reaction from cde in i2c Explorer   
    I have added an I2C restart/repeated start command  to a local version that makes reads better fit the I2C spec:
     
    // i2c_restart
    void i2c_restart( void )
    {
      USICTL0 |= USIOE;
      USISRL = 0xFF;
      USICNT = 1;
      
      while ( ( USICTL1 & USIIFG ) != 0x01 );
      USICTL1 &= ~USIIFG; // likely not needed
      
      __delay_cycles( 100 );
      
      USISRL = 0x00;
      USICTL0 |= USIGE + USIOE;
      USICTL0 &= ~USIGE;
      
      __delay_cycles( 100 );
    }
     
    Some of it may be redundant and can be removed as it's in development.
     
    I have attached it to the '|' (pipe) on mine so usage looks like:
     
    [ 0xa6 0x32 | 0xa7 r r r r r n ]
     
    for a 6 byte read on the adxl345.
     
    PS if anyone is getting strange results on reads, be mindful that some devices are fussy as to whether they are ACKed or NACKed...in this case the ADXL345 wants it's final read before the stop NACKed, otherwise future reads will be affected.
     
    PPS as for features (not demands of the author, just as a discussion):
     
    - history caching commands / repeat last command - it currently junks the input buffer.  I will probably shortly at least add a cache of the last command or maybe a stack or assignable command array.  For me, maybe a rotational queue of 4 x 32 byte buffers with recall rather than one overwritten 64 byte input buffer.
    - binary UART interface - a dumb I2C <-> PC bridge has a lot of potential.
  21. Like
    grodius got a reaction from cde in Porting problem (g2231 to g2452)   
    I had to change the HALF_BIT_TIME within uart.c to double ( 2 * HALF_BIT_TIME ) (so actually BIT_TIME ) to get this to work without issues on the 2452:
     
    CCR0 += HALF_BIT_TIME; // Set time till first bit
     
    to:
     
    CCR0 += 2 * HALF_BIT_TIME; // Set time till first bit
     
    or:
     
    CCR0 += BIT_TIME; // Set time till first bit
×
×
  • Create New...