Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  1. The ebay bid expired, but I'm still looking to sell this board if anyone is interested. Let me know, and we'll work something out for you!
  2. I also have a Stellaris LM4F120 LaunchPad, if anyone is interested and wants to make a generous donation to the cause.
  3. I just put a listing up on ebay; I should have thought to turn here first. I'm cleaning house somewhat and decided to sell an MSP-EXP430F5438 board I have. I've only opened the package and tested the board, so it's brand new. (The protective film is still on the LCD.) The money is going to a good cause--I'm getting married! If anyone is interested, the ebay link is here. I'm including a couple of extra chips for anyone who pays the full $150 I'm asking, and for 43oh members, I'll up that to 4 chips: either 4 MSP430F5438 or 2 MSP430F5438 and 2 MSP430F5438A. Just message me here if you purchase it. If a 43oh member wins the bid at less than the $150, I'll include the 2 chips of your choice. Thanks, guys!
  4. This launch brings up an interesting question I've had on my mind for some time... how well do we expect these things to perform in space? At the altitude and expected lifetimes for these little guys, I expect they'll be fine. I bring it up simply because I recall finding a report somewhere (I'll have to dig it up...) that a group did some cursory radiation testing of the MSP430, and found they are actually quite robust.. even without being designed to be rad-hard. If I ever get the chance, I'd love to throw a couple into a radiation test and do something a little more thorough. Maybe someday we'll get to land one on the moon.
  5. Hi all! It has been quite a while since I've been able to participate in this forum--sometimes life just gets in the way of itself. While I've been involved in things that have taken me away from my blog, it's been in the back of my mind and I've tried to keep up on developments in the MSP430 world. I recently received the new F5529 LaunchPad, and am looking forward to playing with that (and perhaps getting into the ARM world with a Tiva board). I've received a lot of thanks from many people for what I did on the MSPSCI blog, and would like to continue. What do you think, at this point, would be most beneficial? Particular topics that might be addressed? Re-vamp the whole site, updating code and links, or perhaps reformatting everything to be based off the F5529? Part of the reason I've thought that is that my original LaunchPads are early versions, and I believe people who purchase the regular LaunchPad are getting different chips than the G2211 and G2312 that came with mine. Is there any reason to think newcomers will opt for the bigger board leaving the G2 behind? Is there even anything more that type of website can contribute at this point? I have tons to do the next two months, getting out a couple of publications and presentations, so I'm planning on getting back in at the beginning of the year. Any thoughts for what to do?
  6. Kyle, The calibration constants should give you more exactly the specified frequency, as long as the temperature and voltage values are near where they were when the calibration happened. The idea we've been getting at in this thread is putting the standard 1, 8, 12, and 16 MHz calibrations into the value line devices (or correcting those values for specific operating conditions). The example I did on my blog did a calibration for a custom frequency, and you can use the method to get any frequency you like within the operating range of the DCO.
  7. DrMag

    ADC changing channels

    Is that the whole loop? Any chance when you write to U and I the ADC hasn't finished measuring yet? (Depends on your MCLK frequency; looks like you're using the internal ADC clock, ~ 5 MHz, but the sampling takes a few clock cycles If you're using ~1 MHz, you might reach the assignment statement before the ADC is done.) I've been using while(ADC10CTL1 & ADC10BUSY); to let the ADC finish measuring before writing the value.
  8. How are you only reading through P1.3? My understanding is that for ADC10, Sequence Mode reads each channel from Ax to A0 (x corresponds to INCH_x in ADC10CTL0), so if you've started it at P1.7, it will read all 8 channels for the ADC. If that's correct, it would explain the UART issue, since it's conflicting with your UART channels on P1.1 and P1.2. The good news is that you can do this, if you're willing to put software UART in. Use the timer output on P1.5 instead; I've just finished an experiment (using G2231) that will be posted to my blog in the next couple of days that gives an example of doing this-- I'm reading two channels in ADC10, which prevents me from using P1.1 for UART, so I moved the software UART to P1.5. It would be just as easy to change to the same on yours, using P1.4-P1.0 for the ADC channels. Or you could use TA1 on P2 instead.
  9. Hey everyone; been a while! I'm looking at a project that brought up a question I can't find an answer to. I've tried searching the forum here with no success, but perhaps someone knows the answer: In the device datasheets, it specifies the maximum current draw/sink at 48 mA for the GPIO. Is that per port, or per device? (ie. can I draw 40 mA from P1 AND 40 mA from P2?)
  10. When I first got started with MSP430's (two years ago now?) I thought long and hard about whether I should use female or male headers on my target board. I opted for female headers, because the rule of thumb in rockets is that any exposed pin should be unpowered if it shakes loose, lest you create shorts and sparks and other nasties. When the LaunchPad came out, I thought about it again, and came to the same conclusion. Of course, the Vcc/GND pins were pre-populated with male headers, so perhaps that rules out my line of thinking. I've certainly been very interested in the discussion here arguing both sides. One question about the male headers being easily damaged: doesn't that hold true for the new LP now? How is that better than having them on the daughter board? Does anyone know which Tx/Rx configuration corresponds to the previous design? When TI ran the poll, I preferred the option of just changing the order and not looking back; it's easy to change the software UART, swapping TA0 and TA1 for the Tx/Rx roles. (If I ever get around to it, the UART tutorial I'm finishing will show how. It does require a quick change in the interrupts since they behave differently, but it's really not hard to do.) I prefer not having to deal with "backwards compatibility" baggage, but I was obviously in the minority. Anyway, is the vertical configuration equivalent to the previous LP design, or the horizontal? Edit: Ah-- I see the answer to the second question now. The silkscreen shows a vertical configuration is for software UART (ie. P1.1 for Tx, P1.2 for Rx) and a horizontal configuration is for hardware UART (ie. vice-versa).
  11. I finally figured out why the linux behavior was weird (ie. getting 10 Gbit baud rates): the screen program transparently changes your requested rate to something it can do, usually the next lowest, but if you're out of range completely it defaults to 9600. Here's a list of the rates I confirmed work for the LaunchPad USB serial in Linux: 75 4800 110 9600 150 19200 200 38400 300 57600 600 115200 1200 230400 2400 460800
  12. That was my assessment after playing with software UART code-- the only way I could get software UART to work through the TUSB chip was at 9600 bps. Plugging an FTDI chip directly to the emulator side (that is, jumpers are removed so the target MSP is not attached to TX/RX), I was able to get the above results in linux which says otherwise. To add fuel to the fire, I've tried the test again in a Windows environment, using RealTerm. There, I was only able to get the 9600, 4800, 2400, and 1200 rates to work. No non-standard value in or out of that range work, and no standard values out of the range work. That may imply the driver in Windows itself cannot do anything but those four rates, but it doesn't explain why I can't get it to work with software UART from the MSP430 at those same rates. Edit: I looked through the code carefully again, and finding nothing wrong gave it one more try. Now the code works at 9600, 4800, and 2400. The phase of the moon must be more favorable. :roll: Not sure why it won't work at 1200, at least. I'm starting to favor the theory that the Windows driver for the LaunchPad is limited to those four rates.
  13. Another test: Looped the LP TX <--> RX. All baud rates work, clear down to 1 bps. :!!!: Edit: Something fishy on this test... somehow it works even at 1 Gbps. That can't be.
  14. Ok, I've done some more experimenting, and come up with even more peculiar results. Here's the setup I tested: FTDI FT232RL TX -> LP TX via the header between the emulation and target sides. Using two terminal windows (in linux), one connected to /dev/ttyUSB0 (FTDI), and the other to /dev/ttyACM0 (LP). I'm transmitting characters through the FTDI to the LP emulator, so the LP echoes the transmission back to the terminal. Standard baud rates between 1200 and 9600 work as advertised. Standard baud rates outside this range don't work at all. Non-standard baud rates work as far down as 16 bps (including rates that are only 1 off of standard, eg. 301 bps or 599 bps.) Non-standard baud rates work as high as 1,000,000 bps. (I didn't bother trying anything higher than that.) I swapped the roles of the two board, with LP RX -> FTDI RX, and the results are the same. This seems again different from your experience with this test, and it confuses me further why I'm unable to get software UART to work at anything other than 9600 bps. It can't be a clock inaccuracy, as I have a self-calibrated DCO, and at the very least I'd expect to get 4800 bps to work.
  15. I've had a lot of success with Linear's LT1763. It'll get you 500 mA at $2.79. There are fixed values including 3.3V and 5V too. Edit: The LT1963A seems to be a beefier version (1.5 A) at $3.57
  • Create New...