Jump to content
43oh

DrMag

Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by DrMag

  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 p
  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
  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
  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. 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 ex
  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 argu
  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 th
  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
  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
  16. When I was learning how to do the Flash programming for the tutorial I'm currently working through (see here), I noticed that the portion in SegA that should have any ADC calibrations, including the temperature sensor, appears to be completely blank. I believe a part of the segment is set aside for them, but no data is written in it. I'm guessing that, with the Value Line devices, the only factory calibration we get is the 1 MHz DCO. Looking through the TLV Structure chapter of the Family User's Guide, though, we may be able to piece together a good way to do the calibrations ourselves. Th
  17. I've been working with this a lot the past few weeks. In fact, I should be positing the software UART Transmitter tutorial on my blog in the next few days. I'm interested in how you got the lower rates to work, because I have yet to do so. Here's what I figured from all my testing and experimenting: In my experience, the LaunchPad can only do 9600 baud transmission. Note: It's not that it can transmit at up to 9600, it can only do 9600. I have yet to be successful at doing a lower rate, anyway. I suspect the reason for this is that the TX/RX pins are wired to the F1xx MSP430 on the p
  18. For anyone who is interested, I've completed the (3) tutorials on my blog about calibrating the DCO and writing to flash. I've done it in Segment B instead of Segment A and for a non-standard DCO of 7.3728 MHz (for UART). It also includes some information on the TLV formatting TI uses and the correct way to deal with the checksum. Hope these are helpful!
  19. As I understand it, your code is behaving just as it should for how you've written it. I think this is your problem: You've defined BTN_DOWN as !(BTN_IN & BTN). Since this is bit3, let's look at the logic. When The button is pressed, we have: !(0bxxxx0xxx & 0b00001000) = !(0b00000000) = 0b11111111. So if(BTN_DOWN) returns a true value, since BTN_DOWN is nonzero. When the button is released, we have: !(0bxxxx1xxx & 0b00001000) = !(0b00001000) = 0b11110111. In this case, if(BTN_DOWN) still returns a true value, since BTN_DOWN is still nonzero. The problem i
  20. DrMag

    HD44780 issues

    I recently finished a tutorial on my blog that uses a display just like this. I have (yet another) example of code for doing this there too, though I think the examples nobody and n1ksn posted here are in some aspects done better. In any case, there are links in the first tutorial that I found invaluable in learning how to use a display like this. You may find them useful.
  21. For those who are waiting, the post is now up. On to bigger and better things! I'm excited to start working on this again.
  22. RobG, you have officially earned my thanks and appreciation today. That was the exact issue. :clap: Thanks, I'll start writing up the official post tonight.
  23. Hi everyone, I'm working on reviving the mspsci blog, finally, and have coded up the next tutorial. Unfortunately, I'm finding a problem that doesn't make sense to me, and I'm not sure how to work with it. Has anyone got some experience with the comparator module? Here's what I'm seeing: CACTL1 = CAREF_1 + CARSEL; // 0.25 Vcc ref on - pin CACTL2 = P2CA4 + CAF; // Input CA1 (P1.1) on + pin, filter output. CAPD = BIT1; // disable digital I/O on P1.1 CACTL1 |= CAON //turn on comparator This should put the 1/4 Vcc reference on the - input and connect the +
  24. Quick question on the calculate_chksum() routine: unsigned int calculate_chksum(void) { unsigned char i; unsigned int sum=0; for(i=0;i sum = CAL_DATA[i]; return sum; } Shouldn't line 160 be sum ^= CAL_DATA[i] or am I completely misunderstanding the point of a chksum? EDIT: Not +=, changed to ^=. slau144 says the chksum is an XOR operation. chksum should be the two's complement of the cumulative XOR of the remaining words in the segment.
  25. I've been looking at the threads on putting the missing DCO calibrations into Segment A in the Information Memory. As I thought about it, I realized that I've never used any of the information memory in any project I've ever done... and I can't find any "information" that is stored by default in the segments other than the factory calibration constants in Segment A. It seems that this portion of my MSP430 has been, as yet, untapped and could be useful-- but I'm not sure just for what, yet. So here are my questions: (1) Is there anything stored by default in Segments B, C, or D?
×
×
  • Create New...