Jump to content
43oh

grodius

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by grodius

  1. 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. I bought a few of these for experimenting. They are quite easy and straight forward to read raw values using plain I2C, but the DMP was a dark art of no manufacturer support. Things might have changed with unofficial progress but knowing the manufacturer was obfuscating a main selling feature was disappointing.

     

    Edit: it looks like there has been improvement in the manufacturer documentation and libraries so my information is probably old. :)

  3. 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.

  4. Off topic I suppose, and shows my background isn't EE, but why are MSP430s restricted to 16-25 MHz? Why aren't there 50 MHz MSP430s or faster?

    I am guessing, but the ARM Cortex M0+ Instruction pipeline has two stages and seems a lot of devices clocked around 48MHz. The Cortex M3 and M4 have a three stage pipeline and 50-168MHz seems common.

     

    The Cortex R7 has 11 pipeline stages to achieve very high clock frequencies. I would guess that the MSP430 has less pipelining potential due to being a low electrical power device.

  5. 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.

  6. 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.

  7. One alternative you have is to use a cheap fixed camera mounted external to the mower wirelessly communicating absolute position.  There are some cheap <$10 2 and 3 MPixel modules that could be used quite effectively if mounted with a relatively high aspect and using quite simple aspect correction/compensation.  I think the most novel design would be to use 2 linear photo diode arrays with 1 dimensional cylindrical lenses arranged perpindicularly as a cross for the 2 position dimensions.  A humble launchpad can handle arrays more easily than 2d camera sensor information.

     

    Another alternative is to use triangulation (rather than trilateration) using 3 or more fixed external vertical lines or beacons and using  an accelerometer and linear photo diode arrays or camera  module/s.    In a non-messy environment this can be the best option, but maybe harder in a mowing environment.

  8. The wolverine launchpad is exciting but surely it will be branded as a logically new board rather than Launchpad version 1.7 as suggested previously?  I will be gobsmacked if it released as a minor version sub increment, for continuity and support reasons.  In any event, thank you for the pictures of it, as this is much more exciting than the price rise :)

     

    Surely, surely they will go large and advertise it as Launchpad: Wolverine or some such.

  9. I bought up majorly back at $4.30.  Not as an investment, just knowing that was as good as things get and might be ephemeral, so bought about 40 of them.  That low price always felt subsidised and temporary to me.  Personally I agree with others that slower and combined shipping options would be a better way to control costs.

     

    In slightly more general areas, I worry for TI.  I was following the OMAP 5 saga only to watch them effectively abandon the tablet/high end MCU market.  The lucrative handheld calculator sector is also being decimated by tablets and computers.  I highly doubt graphical calculators will survive a further 2-3 generations.  TI are too big a name to simply disappear, but they are being rapidly marginalized in the consumer electronic space and the embedded market is tightening already low margins.

  10. Hmmm.  I really don't think it was a glancing mistake and watched it several times again. He seems very non-technical.  I watched his body language repeatedly and I think he is reciting numbers that are practically meaningless to him.  I like the way he even says "lines of software code"...which is tautological.

     

    This isn't meant to be a huge mockery of him personally, more mild amusement at the decision to use non-technical bureaucrats to head extremely technical projects, and the predictable and repeating software dramas that result.  He even seems like a nice guy...just has never programmed in his lifetime, and has been tasked with stepping in to fix the ailing, bug plagued project.

     

     

     ABC is Australia's national, non-commercial boadcaster. 31:45 is where the fun starts

     

    http://www.abc.net.au/4corners/stories/2013/02/18/3690317.htm

  11. 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?"
     

  12. If you really want to (relatively) stabilize your readings you need to switch your ADC reference source away from the general supply.  Keep in mind your VCC will itself be waivering according to load. The ADC itself is also consuming power and changing the reference voltage itself.  That said, I don't really see a problem with a single least significant bit...keep in mind the actual value falls between the 2 numbers and is being rounded + multiple sources of noise.

     

    Keep in mind also that your potentiometer is very, very likely to be more inaccurate from true than the ADC.  Many pots are accurate to 5% or worse and deviate from linearity as standard. 

  13. I confess to not following the link due to not following unsolicited URLs, but I will presume it's an HC-05 or HC-06 that you are using.

     

    I'm a bit concerned that you haven't wired the key pin for configuration.  I suggect you wire a free wire to the key pin and get to know the terminal based admin.  Connect the bluetooth module directly to a ttl <-> rs232 convertor and then use a terminal emulator program such as hyperterminal to configure the module.  For the 05 module make sure you are appending /r/n within the terminal setup or it will behave very weirdly.

     

    Find the AT+ command list for your model, I think the main two commands are AT+ROLE=0 for slave (probably default anyway) and AT+CMODE=1 to accept all incoming connections.  Armed with the key pin, the AT command list and the console you won't be flying blind any longer.

     

    I apologize in advance if the model isn't what I am describing but many modules will have a parallel or similar setup to this.  Good luck and when it's working you will wonder why you didn't do it sooner.  I sure did.  I curse myself for not switching sooner, accelerometers and gyros are 100% more fun wireless.

  14. 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.

  15. (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 :smile:

  16. 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.

  17. 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.

  18. It was for your updated i2c explorer, code only imported into a bare 2452 CCS5.3 project.  It compiled OK by just updating the 2452 include so that was simple enough...

    but the hyperterminal experience was wacky.  I got better success with HT set to 1 start bit, 7 data bits and 1 stop bit before delving into the UART code (to see it was trying  8 data bits).  I made some other tiny changes to improve timings but none of true consequence.  Try that full wait after the start bit and I think you will get the UART part fully interactive and confidence inspiring. It's enough to get an ADXL345 90% working with the issues being i2c repeatability flakiness, not UART related.

     

    Anyhow this will fix the described problem and I will have completely overachieved my 'noob class' pigeon-hole, or can I Doogie Howser straight to leet haxxor on the back of this? Just kidding, but thanks for the work on the explorer and hopefully I might be of some use in a 2553 USCI port.

  19. 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...