Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything 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 li
  2. On this thread the Invensense documentation is available. You've got me back interested, so thanks, but unfortunately it'll be a little while before I try. http://www.i2cdevlib.com/forums/topic/153-official-dmp-documentation-is-released-by-invensense/page-3
  3. 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.
  4. 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 pi
  5. 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.
  6. 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.
  7. 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 ligh
  8. 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.
  9. 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 alterna
  10. 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.
  11. 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 graphica
  12. 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 program
  13. 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 t
  14. 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 ac
  15. 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
  16. 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. (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 f
  18. 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 vol
  19. grodius

    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 0x3
  20. 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%
  21. 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...