Jump to content
43oh

DrMag

Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    DrMag got a reaction from lunakid in Flashing the missing DCO calibration constants   
    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.
  2. Like
    DrMag got a reaction from bluehash in MSP430F5438 Experimenter's Board   
    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!
  3. Like
    DrMag got a reaction from spirilis in KickSat -- Your personal spacecraft in space!   
    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. 
  4. Like
    DrMag got a reaction from khwatch in Reading multiple channel using ADC10, DTC, G2553 and launchp   
    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.
  5. Like
    DrMag got a reaction from jp430bb in LaunchPad's UART at more than 9600 baud ?   
    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

  6. Like
    DrMag got a reaction from jsolarski in Flashing the missing DCO calibration constants   
    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!
  7. Like
    DrMag reacted to oPossum in Software async serial tx/rx without timer   
    Had some requests for this in IRC so here it is. This is an improved version of the serial tx previously posted and new serial rx code. Both tx and rx are blocking and interrupts should be disabled before calling.
     
    C code to show how to use the serial_setup(), putc(), puts(), and getc() functions.
    This will receive a character, increment it and echo it back. So if you type 'A', then 'B' will be echoed.

    // test.c #include "msp430g2211.h" // Functions in serial.asm (this really should be in a header file) void serial_setup(unsigned out_mask, unsigned in_mask, unsigned duration); void putc(unsigned); void puts(char *); unsigned getc(void); void main(void) { char c; // Disable watchdog WDTCTL = WDTPW + WDTHOLD; // Use 1 MHz DCO factory calibration DCOCTL = 0; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; // Setup the serial port // Serial out: P1.1 (BIT1) // Serial in: P1.2 (BIT2) // Bit rate: 9600 (CPU freq / bit rate) serial_setup(BIT1, BIT2, 1000000 / 9600); // Send a string puts("\r\nRunning...\r\n"); for(; { // Do forever c = getc(); // Get a char ++c; // Increment it putc(c); // Echo it back } }
     
    The serial tx/rx code. Just add this as a new source file in your CCS project and it will be callable from your C code.

    ; serial.asm .cdecls C, LIST, "msp430g2231.h" .bss in_bit_mask, 2 ; Serial in pin .bss out_bit_mask, 2 ; Serial out pin .bss bit_dur, 2 ; Bit duration in cycles .bss half_dur, 2 ; Half bit duration in cycles ; .text ; .def serial_setup ; void serial_setup(unsigned out_mask, unsigned in_mask, unsigned bit_duration); .def putc ; void putc(unsigned c); .def puts ; void puts(char *s); .def getc ; unsigned getc(void); ; ; serial_setup ; - Setup serial I/O bitmasks and bit duration (32 minimum) mov R12, &out_bit_mask ; Save serial output bitmask mov R13, &in_bit_mask ; Save serial input bitmask bis.b R12, &P1DIR ; Setup output pin bis.b R12, &P1OUT ; bic.b R13, &P1DIR ; Setup input pin or R13, R12 ; bic.b R12, &P1SEL ; Setup peripheral select mov R14, R12 ; sub #16, R14 ; Adjust count for loop overhead rla R14 ; Multiply by 2 because NOP is two bytes mov R14, &bit_dur ; Save bit duration sub #32, R12 ; Adjust count for loop overhead mov R12, &half_dur ; Save half bit duration ret ; Return ; ; - Send a single char putc ; Char to tx in R12 ; R12, R13, R14, R15 trashed mov &out_bit_mask, R15 ; Serial output bitmask mov &bit_dur, R14 ; Bit duration or #0x0300, R12 ; Stop bit(s) jmp bit_low ; Send start bit... ; tx_bit mov R14, R13 ; Get bit duration tx_delay nop ; 4 cycle loop sub #8, R13 ; jc tx_delay ; subc R13, PC ; 0 to 3 cycle delay nop ; 3 nop ; 2 nop ; 1 ; rra R12 ; Get bit to tx, test for zero jc bit_high ; If high... bit_low bic.b R15, &P1OUT ; Send zero bit jmp tx_bit ; Next bit... bit_high bis.b R15, &P1OUT ; Send one bit jnz tx_bit ; If tx data is not zero, then there are more bits to send... ; ret ; Return when all bits sent ; ; ; - Send a NULL terminated string puts ; Tx string using putc push R11 ; mov R12, R11 ; String pointer in R12, copy to R11 putsloop ; mov.b @R11+, R12 ; Get a byte, inc pointer tst.b R12 ; Test if end of string jz putsx ; Yes, exit... call #putc ; Call putc jmp putsloop ; putsx pop R11 ; ret ; ; getc ; - Get a char mov &bit_dur, R14 ; Bit duration mov &in_bit_mask, R13 ; Input bitmask mov #0x01FF, R12 ; 9 bits - 8 data + stop ; rx_start ; Wait for start bit mov.b &P1IN, R15 ; Get serial input and R13, R15 ; Mask and test bit jc rx_start ; Wait for low... ; mov &half_dur, R13 ; Wait for 1/2 bit time ; rx_delay nop ; Bit delay sub #8, R13 ; jc rx_delay ; subc R13, PC ; 0 to 3 cycle delay nop ; 3 nop ; 2 nop ; 1 ; mov.b &P1IN, R15 ; Get serial input and &in_bit_mask, R15 ; rrc R12 ; Shift in a bit ; mov R14, R13 ; Setup bit timer jc rx_delay ; Next bit... ; rla R12 ; Move stop bit to carry swpb R12 ; Move rx byte to lower byte, start bit in msb ret ; Return with rx char and start bit in R12, stop bit in carry ; .end ;
  8. Like
    DrMag reacted to RobG in New chips shipping with the LaunchPad?   
    1. As jim940 mentioned already, male headers are easier to damage.
    2. Affecting hundreds of users by soldering headers just to make presenters life easier, crazy.
    3. There is a simple solution that will make everyone happy: pre-soldered female headers with F-F adapters
     


  9. Like
    DrMag reacted to bluehash in New chips shipping with the LaunchPad?   
    Alright. TI came back with a response(Thanks for replying back, TI):
     
  10. Like
    DrMag reacted to zeke in New chips shipping with the LaunchPad?   
    I agree with TI on this one. This is not an Arduino.
     
    If you have a job as an EE then you should be familiar with this choice.
     
    Male pins in the LP is technically the best choice:
    - Protects daughter boards from ESD zaps
    - Protects daughter boards from messy lab benches
    - Gives the ability to wire-wrap between male pins
    - Gives the ability to connect ribbon IDC cables to male pins
    - Standardizes board to board connector set - you won't have to guess what is there.
     
    Sure, it hurts a little to have your freedom of choice taken away from you but don't let that demoralize you. It's only a bloody dev board that you buy for $4.30! Make your own if you're so personally offended by TI.
     
    I do agree that desoldering those pins are a pain for people without the right tools but it builds character and skill to figure out how to do that.
     
    I can remove those male pins from the LP in about 10 minutes with a soldering iron and a plier. I'll write up a how-to for anyone who wants it.
     
    How long did you take to figure out how to write interrupt driven I2C code?
     
    This is just a tempest in a teapot.
  11. Like
    DrMag reacted to pine in New chips shipping with the LaunchPad?   
    Sure
     

     

     

  12. Like
    DrMag reacted to pine in New chips shipping with the LaunchPad?   
    Some pics for the comparison, on the Left is the classic LP, the right is the new LP
     

     
     
    And the back...

     
    The box of the new LP

  13. Like
    DrMag reacted to bluehash in Questions about program ROM. Vs. RAM usage.   
    Credit:

  14. Like
    DrMag got a reaction from bluehash in LaunchPad's UART at more than 9600 baud ?   
    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

  15. Like
    DrMag got a reaction from bluehash in Internal temperature sensor calibration?   
    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. The information is pretty sparse on TLV, unfortunately; the only ADC calibrations listed are for ADC12. I would suspect, though, that the same standard calibrations would be used for ADC10.
     
    In any case, calibrating the temperature sensor would require three things: an accurate voltage reference to be used whenever using it (could be the internal 2.5 or 1.5 V, or the on-board 3.3 provided by the USB connection, which likely isn't very accurate), and then stable temperature environments at two points. (TI does calibrations at both 2.5 V and 1.5 V reference, 30 and 85 deg C each, in the ADC12 example listed.) In theory, any two temperatures should work, since the ADC10 is fairly linear. Could make an interesting experiment for my blog to test that... no promises just yet, though. :think:
  16. Like
    DrMag got a reaction from bluehash in Booster Pack Breadboard   
    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
  17. Like
    DrMag reacted to bolton in Anaren TI CC110L RF AIR Booster Pack   
    Just wanted to let everyone know, TI sees to have a new booster pack, which isn't easily found through the main page.
    Here's the TI Estore link to it:
    Estore CC110L RF AIR Booster Pack
  18. Like
    DrMag reacted to xpg in Eclipse plugin for mspdebug and msp430-gcc   
    Hi guys,

    I've finally hacked together a plugin for Eclipse that allows the msp430-gcc toolchain to be used from within Eclipse more easily.
    I must warn you that this is by no means finished, but I wanted to get it out there to get some opinions before I spend too much time on it.

    Features and Limitations:

    - Supports msp430-gcc macro and include directory discovery (though msp430-gcc must be in your PATH).
    - Extracts list of supportet MCUs from msp430-gcc, and allows target MCU to be easily selected and changed.
    - Use mspdebug to upload to target (only Launchpad is supported and the device is autodetected).
    - Only Linux and Windows are supported at this point.
    - Binary toolchains are provided for Linux and Windows, in order to ease installation.

    Changelog:
    1.0.5.1

    -Added Windows support.
    -Added dependency on "Target Management Terminal".
    -Add .cpp as C++ extension.
    -Support for FRAM board (by using a newer version of mspdebug).
    -Fix a bug: mspdebug fails to startup successfully for debugging session.
    -Group MCU List to make selection easier.
    -Remove usage of stdbuf.
    -Simplify tool selection by adding an "Activate"-button to the tool manager.
    -Add support for static libraries (project type).
    -Kill mspdebug when debugger is stopped.
    -"tilib" to the mspdebug driver selection.
     
    1.0.4.1
    -gcc, gdb, and mspdebug are no longer distributed as an eclipse plugin, but as a separate download package. This allows the tools to be installed in a user select location, rather than trying to install into the eclipse directory.
    -MSP430 C/C++ projects can now be created.
    -The protocol (SBW, JTAG) used by MSPDebug can now be selected.
     
    Installation:
    Add http://eclipse.xpg.dk as a software source in Eclipse, and install the Msp430Eclipse plugin.
    Currently, only Indigo is supported, but the plugin might work with Helios and Juno as well.

    If your system does not have up-to-date version of msp430-gcc, msp430-gdb, and mspdebug, you can download one of the following tool-packages:

    Linux 64-bit: msp430-toolchain-linux-amd64-3.0.tar.bz2
    Linux 32-bit: msp430-toolchain-linux-i386-2.1.tar.bz2
    Windows 32-bit: msp430-toolchain-win-x86-3.0.zip
    Mac OS X: msp430-toolchain-mac_os_x-x86_64-2.2.tar.bz2

    Extract the package in an appropriate location ($HOME, for instance), and go to Eclipse (with the MSP430Eclipse plugin installed), and from the menu select MSP430->Tool Manager. Click the "Add..."-button, and browse to the tool-package directory. Select the tool-chain and press the "Activate"-button in order to tell Eclipse to use it.

    You can verify that the right tool-package is used by going to the Eclipse preference and select "MSP430". Here you will be able to see and choose what tools are used from which package.

    For windows, you will need to install USB-drivers as described in the MSPDebug FAQ.

    Getting Started:
    In order to use the MSP430 features, you have to create a new C project and choose "Empty Project" from the "MSP430 Cross Target Application" group. It is possible to select the target MCU from the wizard, but this does currently not work.

    After having created the project, right click on it and select properties. In the "MSP430"-setting it is possible to select the target MCU. Remember to press "Apply" in order for the selection to take effect.

    After having added some source files and compiled the project, you can upload it to the MSP430 by choosing the MSP430-menu, and selecting the "Upload to target action"

    Using the Debugger
    In order to debug your program, go to the "Debug Configuration"-dialog, and create a new configuration in the "MPS430 Debug"-group (by right-clicking it). Having that new configurations elected, simply click "Debug".
     
    For people interested in hacking on the source code of msp430Eclipse, it is available at gitorious: https://gitorious.org/msp430eclipse
     

    Updated September 3rd: New version released (1.0.5.1), updated description
    Updated April 23rd 2013: Links to toolchains updated.
    Updated April 25th 2013: Added link to gitorious project.
  19. Like
    DrMag got a reaction from bluehash in Flashing the missing DCO calibration constants   
    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!
  20. Like
    DrMag got a reaction from oPossum in Flashing the missing DCO calibration constants   
    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!
  21. Like
    DrMag got a reaction from bluehash in Comparator input not floating?   
    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. Like
    DrMag got a reaction from gordon in Comparator input not floating?   
    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.
  23. Like
    DrMag reacted to RobG in Comparator input not floating?   
    I bet your Rx & Tx shorting blocks are in, remove them.
  24. Like
    DrMag reacted to nobody in Flashing the missing DCO calibration constants   
    IMHO it's not good idea, erase full segment A. There is probably stored more device-depended constants, not only DCO calibration. (Look at page 644 in slau144.pdf - "SegmentA structure"). Better idea is simply write those 3 missing constants (for 8, 12 and 16MHz) into the empty space (empty space contains 0xFFFF, is writable...).
     
    And more important info: You thinking about data integrity in segment A? Write the correct info into 0x10F6 (TAG_DCO_30 and length of DCO table)? Recalculate (and write) new checksum for segment A?
     
    For those, who want correctly change DCO constants:
    - Save full contents from segment A into RAM.
    - Change (in RAM) what You want, compute new checksum, etc...
    - And then write full block into erased segment A.
     
    I suggest You: look at page 649 and 650 in slau144.pdf.
     
    btw: the last version is slau144f.pdf
×
×
  • Create New...