Scoring
  • Total Score
  • Product Performed to Expectations
  • Specifications were sufficient to design with
  • Demo Software was of good quality
  • Product was easy to use
  • Support materials were available
  • The price to performance ratio was good
Buy Now
Review - Details
RoadTests now Enrolling
Group Actions
  • Author Author: migration.user
  • Views 252 views
  • Likes 0 likes
  • Comments 4 comments

Review of MSP-EXP430FR5739

migration.user

Table of contents

RoadTest: MSP-EXP430FR5739

Author: migration.user

Creation date:

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: None.

What were the biggest problems encountered?: 1. Absence of filter on accelerometer. 2. Not a lot of examples available on the web. 3. Not supported on GRACE tool.

Detailed Review:

I wasn't sure if I was going to be selected for the review or not, so I went ahead and bought the kit anyway. Here's how I found it:

 

1.   I wanted to explore if the processor reboots due to watchdog timer expiring (in case of an exception), then would the controller being implemented on the processor be able to recover and keep control of the process under control? Two major factors that would contribute to effective recovery would be:

          a. Bootup time

          b. Writing status in real-time to the FRAM which would be use after bootup to start from the point where it left when the crash happened.

 

Well, I couldn't complete the test, because my oscilloscope finally broke down after 20 years of service!! So I don't have any quantitative data to share. However, qualitatively, I can make these comments. Bootup time is very fast, specially if you keep your application simple, and don't put in blinkies like they have in the example firmware that it comes with it. It is tempting to use the very bright oLED's that the board comes with to make your project look nice, but in my application, I simply didn't need that. Also, you can write to FRAM almost with the same speed as you can write to RAM. There is no comparison in speed writing to a Flash. I haven't tried it (I'll post the results when I get a new oscilloscope), but it amost looks possible.

 

2. 3-DOF Accelerometer does not have a low pass filter before the input is brought into the microcontroller ADC. This makes it almost impossible to control fast systems. You can attach a capacitor to P3.1-3, but that will have limited effect. Ideally, I'd like to put a low-pass butterworth filter in there. I tried it on a two-wheeled self balancing robot, but it didn't work. The noise level was too high. I've already balanced the robot using an accelerometer, so its not as if it can't be done. However, with this guy, I wasn't able to do it. Maybe I need to spend more time and implement a digital filter, but I didn't have time for that. Again, if I manage to do that, I'll post the results. ADC works perfectly for tilt measurement applications, though.

 

3. Its a new chip, so there aren't that many sample projects available to get from the web as a starting point. The core is the same as on other MSP430 controllers, so programming the peripherals is not a big deal. The only thing that is different is the FRAM, and that works just like a RAM. The sample project (downloadable from web) gives an example on how to do that. However, one thing that is indispensible is support on GRACE tool. Absense of this support is a big drawback. Even if you're familiar with MSP430 microcontrollers, and even if GRACE tool doesn't provide User/Advanced User GUI for all the peripherals, it is useful to have direct access to registers through this tool, so that you don't have to keep on referring to the datasheets while programming.

 

I know that this is just an eval kit, but it would have been useful to have an option to put in filters between the accelerometer outputs and ADC pins. In future, if TI is using accelerometers with analog output, I hope they will keep this in mind. Also, support on GRACE will help making this chip popular. It has a lot of potential not only in the application that I've described in 1. above, but also for black-box applications. Using Flash is not the best option, since it has a limited lifecycle. This chip can be used to keep a circular buffer to record critical data, which can be retrieved in case of a failure/crash, and can be used in post-mortem diagnostics to see what conditions led to the crash. This information is very important in recreating the crash, specially for real-time applications. In larger machines, you have the option to put in core-dump facility, but that is not an option for smaller, embedded systems due to restricted resources. This chip has the potential to solve that problem.

Anonymous
  • in reply to Former Member

    Hi,

     

    based on schematics (and my board) there are simple first order filters on accelerometer outputs. 100nF capacitors C16, C17 and C58 connected to P3.0, P3.1 and P3.2 in conjunction with internal ADXL335 32k resistors act as 50Hz low-pass filters. So in this configuration accelerometer isn't very fast.

  • in reply to Former Member

    Hi PK,

     

    Thanks for the clarification.  If your running average filter is not working, try reducing your sampling frequency.  That would slow down the updates, but it will add hysteresis to your balance control.  You may be able to use a combination of the simple filter and the lower sampling time to keep it in position.  Sometimes when you sample a lot, you get oscillations in the control function that makes the problem worse.  Sometimes less control is better.

     

    DAB

  • in reply to DAB

    DAB, sorry for the confusion. The accelerometer itself is not slow. What I meant was that in the current configration, it is not good enough to use with fast control applications. I'd prefer a low pass filter with a sharp cut-off to filter out high frequency noise, which you can't get with a simple capacitor. In accelerometers with digital output (I2C, SPI etc), normally filtering is already done before analog to digital conversion. But in this case, TI has used an accelerometer with analog output. I used 10-point moving average, but that didn't help too much. Unfortunately, the device doesn't have a lot of memory to implement complex filtering algorithms (16k FRAM, no FPU), so you might not have a choice to implement everything in digital domain. You have to be very careful with the resources while developing algorithms, and it would help to offload as much as you can into analog domain.

     

    Nevertheless, it is a very interesting device, and I'm quite sure that you'll have a lot of fun with it. I wonder if TI is considering using FRAM with more powerful CPU cores. If you can combine a larger flash to store permanent data (code section, for example) and use FRAM as non-volatile RAM, I can see a lot of potential here......

  • Good job PK.  You make me look forward to getting one of these boards.  I am not sure what you mean that the accelerometer was too slow without a filter.  Does that mean you implemented a software filter and it was too slow to process the data in real time?

    You might try a simple running average filter in the software, this will allow you to smooth the data change rate and still keep up with direction changes.  I have used this approach on a real time FLIR control for a helicopter and they worked quite fine, but I think your self balancing test may be too demanding for that approach.

     

    Thanks for peaking my interest.

    DAB