Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    tripwire reacted to Fred in RandomElectrons LP10062   
    That looks nice, but there a lot of unused space down one end of the board. If you can't think of anything specific to fill it, maybe a prototyping area? Some LEDs? They're always useful for very simple debugging.
  2. Like
    tripwire reacted to pabigot in USCI_B0 in SPI mode   
    A frequent issue with I2C/SPI on the Launchpad is that P1.6 (MISO/SCL) is wired to the green LED. On at least some LP revisions you have to remove the jumper, or the USCI signals don't work work properly. FWIW, you also generally don't have to set PxDIR when in peripheral mode: the PxSEL setting has that effect (but check the port schematic pages in the data sheet because it's not true for every peripheral function).
  3. Like
    tripwire reacted to enl in CCSv6 DS18B20 - return value gets lost   
    Make temperature a volitile. It may be getting optimized out as it is never used
  4. Like
    tripwire reacted to OppaErich in CCSv6 DS18B20 - return value gets lost   
    That was the problem. temperature was declared AND initialized before main(). I've set it to 0.0 inside of main() and now it resides at 0x0200 and shows sane values.


  5. Like
    tripwire reacted to spirilis in Code Composer Studio v6 now officially released   
    FYI- Anyone looking to use the new msp430-elf-gcc, note that their msp430.h has an error in it:
     
    C:\ti\ccsv6\ccs_base\msp430\include_gcc\msp430.h has a bunch of checks for crap like __MSP430XGENERIC__ that got stuck in the "middle" of the file, before a bunch of other F5xxx/F6xxx/FRxxx part#'s, not at the end where those sort of "last-ditch" checks should occur:
    #elif defined (__MSP430F6659__) #include "msp430f6659.h" #elif defined (__MSP430L092__) #include "msp430l092.h" #elif defined (__MSP430C091__) #include "msp430c091.h" #elif defined (__MSP430C092__) #include "msp430c092.h" #elif defined (__MSP430XGENERIC__) #include "msp430xgeneric.h" #elif defined (__MSP430F5XX_6XXGENERIC__) #include "msp430f5xx_6xxgeneric.h" #elif defined (__MSP430FR5XX_6XXGENERIC__) #include "msp430fr5xx_6xxgeneric.h" #elif defined (__MSP430FR57XXGENERIC__) #include "msp430fr57xxgeneric.h" #elif defined (__MSP430F5131__) #include "msp430f5131.h" #elif defined (__MSP430F5151__) #include "msp430f5151.h" #elif defined (__MSP430F5171__) #include "msp430f5171.h" #elif defined (__MSP430F5132__) #include "msp430f5132.h" Comment those "generic" checks out, e.g.:
    #elif defined (__MSP430F6659__) #include "msp430f6659.h" #elif defined (__MSP430L092__) #include "msp430l092.h" #elif defined (__MSP430C091__) #include "msp430c091.h" #elif defined (__MSP430C092__) #include "msp430c092.h" /* #elif defined (__MSP430XGENERIC__) #warning "Using __MSP430XGENERIC__" #include "msp430xgeneric.h" #elif defined (__MSP430F5XX_6XXGENERIC__) #warning "Using __MSP430F5XX_6XXGENERIC__" #include "msp430f5xx_6xxgeneric.h" #elif defined (__MSP430FR5XX_6XXGENERIC__) #warning "Using __MSP430FR5XX_6XXGENERIC__" #include "msp430fr5xx_6xxgeneric.h" #elif defined (__MSP430FR57XXGENERIC__) #warning "Using __MSP430FR57XXGENERIC__" #include "msp430fr57xxgeneric.h" */ #elif defined (__MSP430F5131__) #include "msp430f5131.h" #elif defined (__MSP430F5151__) #include "msp430f5151.h" #elif defined (__MSP430F5171__) #include "msp430f5171.h" #elif defined (__MSP430F5132__) #include "msp430f5132.h" The reason we see this is that by default, CCS's project generator uses "-mmcu=<ISA>" instead of the old "-mmcu=<MSP430 part#>", in the case of Wolverine, that's "-mmcu=msp430X".  So __MSP430XGENERIC__ gets implicitly #define'd by the compiler.  I believe that is the "new way" GCC is behaving going forward; no longer specifying the full part# in -mmcu but just the ISA/architecture.  Makes it easier for the GCC maintainers since they don't have to keep updating the codebase with new part#'s as TI produces them.
     
    The CCS project generator correctly adds -D__MSP430FR5969__ so that msp430.h identifies the correct chip and includes the msp430fr5969.h file, but not if it catches #elif defined(__MSP430XGENERIC__) first.
     
    I reported it on E2E as a bug, but if anyone is impatient to play until an update is provided just open your msp430.h and comment out that junk.
     
    edit: or I can be a nice guy and include a fixed copy  msp430_h_fixed_ccsv6.zip
  6. Like
    tripwire reacted to spirilis in Alternatives to MSP430FET   
    TI's MSP430.DLL software (used by CCS with their native flasher tools) only acknowledges the ability to program MSP430G2xxx chips from the original MSP430G2 launchpad (and maybe F2xxx? Not sure) but the open-source mspdebug program can program just about any MSP430 that uses Spy-Bi-Wire using the old launchpad, using the "rf2500" driver. The new F5529 LaunchPad supports programming all MSP430 (SBW) devices through TI's MSP430.DLL using mspdebug (using the "tilib" driver) or TI's CCS tools.
     
    Sent from my Galaxy Note II with Tapatalk 4
  7. Like
    tripwire reacted to oPossum in Newbie general C code question   
    When the max value is less than 2^8 (256): uint_fast8_t
    When the max value is less than 2^16 (65536): uint_fast16_t
    When the max value is less than 2^32 (4,294,967,296): uint_fast32_t
    When the max value is less than 2^64 (aprox 1.8E19): uint_fast64_t
     
    These fast variants will be promoted to the best suitable integer type. That will typically be an integer multiple of the register width. So on the MSP430, uint_fast8_t becomes unsigned [16 bit]. On x86 it would be 16, 32 or 64 bits depending on target operating mode. This doesn't matter much on the MSP430, but it does on some others such as 16 bit PIC.
  8. Like
    tripwire got a reaction from bluehash in Error in code composer studio   
    The highlighted part means that the compiler can't find your main function (ie it doesn't know where the program starts). Do you have another file in the project that defines main?
     
    Edit: By the way, if you're going to post code it's best to use the syntax highlighter (the button that looks like this: <>). Sometimes the forum software messes up the formatting or turns your punctuation into emoticons if you don't
  9. Like
    tripwire reacted to spirilis in What is new in the new value line?   
    Value Line is a specific lineup of chips.  Most of the Value Line chips come in different packages; DIP being the popular one that works with MSP430G2 LaunchPad.  All those same chips available in DIP are available in a TSSOP (surface mount 0.65mm pin pitch) and QFN variations.
     
    My understanding is of course the Value Line isn't just for hobbyists, it's meant to be an affordable option for TI's professional customers too, and many probably do use them in small gadgets & toys and such.  Last year TI released an expansion of the Value Line, but only offers the chips in surface mount (TSSOP, QFN) variations of the package, no DIP so they won't work with the MSP430G2 LaunchPad without installing the chip on a separate carrier board.  These chips have notably expanded memory (flash & SRAM) and are much more comfortable to code for since you're far less constrained--the chips' resources are closer to what Arduino has been using for years (and exceeds it, in the case of the MSP430G2955).  But TI doesn't have any easy LaunchPad-style boards for them, so a couple of us have built our own.  That said, it all became a somewhat moot point when TI released the MSP430F5529 LaunchPad, whose resources far exceed even the highest of the new Value Line chips.  So enthusiasm for the higher-end Value Line chips (e.g. MSP430G2955) has waned a bit.  I personally feel there's a place for them in my projects though.
  10. Like
    tripwire reacted to pabigot in Newbie general C code question   
    I see that happening more and more; I blame it on injudicious application of MISRA rule 6.3.
     
    It's absolutely the case that types with specific sizes should be used when the range is potentially beyond the native word size of the processor or data is exchanged over a communication link, including via a file.
     
    I have yet to see a cogent argument why specific-size types should be used in preference to "int" and "unsigned int" for indexes and offsets where the native word size is appropriate, or when you're manipulating a processor peripheral that is known to be that native word size.
     
    On one hand, you might select a type that's too large for a target processor, impacting portability. TI did this recently to the CC3000 host interface, changing it so every parameter is a uint32_t even if its value range is less than one octet. This unnecessarily bloats code and hampers performance on the MSP430. Sure, when it goes out over SPI it needs to be 4 octets: but that's an encoding issue and should not propagate up to the library API.
     
    Or you might go too small, and select uint8_t. Two problems: (1) it's a pain if you wrote code to index over an array, and somebody increases the array size above 255. (2) A uint8_t value will promote to the signed type int when used in expression calculations. I've got some discussion of this on my blog; the non-C++ stuff related to uint8_t is at the end. tl;dr: -x doesn't mean what you probably think it does.
     
    The advice @@roadrunner84 gave is better, though if the "appropriate type" argument is applied consistently one should use size_t for all variables used as indexes as well as sizes. Which will hurt you badly on the MSP430 if you're using a memory model that supports objects larger than 64 kiBy, so I prefer unsigned int there too.
     
    Note: If you are going to use the size-specific types, get in the habit of explicitly including either <inttypes.h> or its lesser cousin <stdint.h>. Yes, for MSP430 and ARM the vendor headers provide it for you, but if you don't remember that it comes from the C library, not the C language, you'll be confused when you graduate to host platforms where it's not part of the null context.
  11. Like
    tripwire reacted to JWoodrell in cutting launchpad for standalone programmer *helpful hint*   
    hey guys I decided to cut down a launchpad to send just the programmer piece to a customer to load a program into a product with.  and i was getting annoyed that the cutboard refused to talk to or download to a processor, while a full launchpad worked just fine.  I knew you could cut the board at the dotted line, so i was frustrated.
     
    after some research it turns out the communication trace going to the RST (and maybe the TST) one as well actually is routed down between the two rows of pins on the 10 pin jtag header between the two sides of the launchpad board...  if you follow the dotted line all the way through and bisect that header, you end up cutting the communications line.  so i soldered some replacement lines in and poof it works fine...
     
    so just a note if you want to cut a launchpad down, cut on the far side of the header retaining all 10 pins, or atleast through the pin holes on the bottom.  Don't follow the dotted line, to make sure you retain the programming lines...
     
    just thought I would share
     

  12. Like
    tripwire reacted to bi0tech in advice on mounting a launchpad?   
    This seems relevant so Ill throw in a few pics of my msp430 franken'pad.
     
    I wanted a zif and drop in breadboard capability, so I picked up a few knockoff texttool 28 pin zifs (largest size I saw in narrow format, the extra pins don't pose an issue and allow use with a few other chips).  Desoldering the carrier socket was moderately painful, but doable with just some braid/fine tip.  (full disclosure I'm not the worlds worst at soldering, now 2nd worst is still to be determined).  Added in stacker headers in place of the carrier to give me drop in breadboarding and to clear the board surface level / leave room for the crystal.  A little hot glue to keep things in place (and hold a flywire from where I lifted a pad) and a 5 minute router job with some scrap wood as a puck stand.
     

  13. Like
    tripwire reacted to Gulam in Project f-Spell: Now you can type even without Keyboard!   
    It all started with an aim of improving communication between speech & hearing impaired and normal people. But it has now almost become an alternative input device for any computing device!
     
    So what is it all about? It's a cyber glove that recognizes sign language gestures and convert them into ASCII. Voila! We can throw away our keyboards and start using this glove. Right? After all, our keyboard does the same thing.
     
    Don't try too hard to visualize this peculiar device! This is how it will be!!
     

    And Technically it will be something like this
     
    And more technically the flow of data will be like this

     
     
    Got a overall picture? Okay. Let's see how this is implemented. The sensor boards which are mounted on the finger tips is a custom PCB (see attachements schema_acc_board.png & pcb_footprint_acc_board.pdf) which houses the accelerometer (in our case MMA7361L). Those accelerometers will be connected MSP430 Launchpad and Launchpad will then be connected to Bluetooth Module as shown below. (BT boosterpack from iTeadStudio is used here)
     

     
    Wondering why not all axes of accelerometers are utilized? Well we have to do some trade-off between resolution and no. of ADC channels available :-( 
     
    That's all. Find the code as attachment (code.zip)
     
    Here are few pics of the setup & output...
     
     
     



     
    Attempts have been made to miniaturize the whole setup into one glove. The FET Debugger is not able to recognize the custom board. But I'm not sure whether the problem is with Schema or PCB footprint.  I've attached the unverified schema and footprint also with this post. Interested are welcome to give a try! If you come up with a better design you are welcome to share it with me at any time ;-)
     
     
    pcb_footprint_acc_board.pdf

    code.zip
    pcb_1_NOT_VERIFIED.pdf
    pcb_2_NOT_VERIFIED.pdf
    pcb_3_NOT_VERIFIED.pdf
    schema_NOT_VERIFIED.pdf
  14. Like
    tripwire got a reaction from pine in Read a line of input from the Code Composer Studio (CCS) console using an MSP430   
    This turned out to be an interesting one, and you're probably going to kick yourself when you see why fgets wasn't working for you...
     
    Initially my gut feeling was that there was no support for reading from the console window on the target*. Having dug a little further I found that the CIO system does support reading from the target side, so I set up a test program to try it out. It didn't work. I noticed that you'd mentioned setting the heap size, so I set mine. That fixed printf but not fgets.
     
    Stepping into the library code revealed that the problem was with allocating the stream buffer for stdin. I'd set the heap to 512 bytes, and each stream requires 256 bytes buffer space plus 32 bytes of header. The printf call was allocating a buffer for stdout and then the heap had insufficient space to allocate a buffer for stdin. While printf causes the program to exit when it fails to initialise the buffer, fgets and getc just return immediately.
     
    Setting the heap size greater than 576 bytes fixed the issue for me.
     

    * Mainly because I've never seen anyone else even try it - stdio.h is commonly regarded as being a bit "heavyweight" for MSP430. The default stream buffer size is bigger than the ram on the msp430g2553! Most example code I've seen uses the UART backchannel instead, or at least a very cut-down printf implementation with a much smaller buffer.
  15. Like
    tripwire got a reaction from bluehash in Read a line of input from the Code Composer Studio (CCS) console using an MSP430   
    This turned out to be an interesting one, and you're probably going to kick yourself when you see why fgets wasn't working for you...
     
    Initially my gut feeling was that there was no support for reading from the console window on the target*. Having dug a little further I found that the CIO system does support reading from the target side, so I set up a test program to try it out. It didn't work. I noticed that you'd mentioned setting the heap size, so I set mine. That fixed printf but not fgets.
     
    Stepping into the library code revealed that the problem was with allocating the stream buffer for stdin. I'd set the heap to 512 bytes, and each stream requires 256 bytes buffer space plus 32 bytes of header. The printf call was allocating a buffer for stdout and then the heap had insufficient space to allocate a buffer for stdin. While printf causes the program to exit when it fails to initialise the buffer, fgets and getc just return immediately.
     
    Setting the heap size greater than 576 bytes fixed the issue for me.
     

    * Mainly because I've never seen anyone else even try it - stdio.h is commonly regarded as being a bit "heavyweight" for MSP430. The default stream buffer size is bigger than the ram on the msp430g2553! Most example code I've seen uses the UART backchannel instead, or at least a very cut-down printf implementation with a much smaller buffer.
  16. Like
    tripwire got a reaction from MrP in Read a line of input from the Code Composer Studio (CCS) console using an MSP430   
    This turned out to be an interesting one, and you're probably going to kick yourself when you see why fgets wasn't working for you...
     
    Initially my gut feeling was that there was no support for reading from the console window on the target*. Having dug a little further I found that the CIO system does support reading from the target side, so I set up a test program to try it out. It didn't work. I noticed that you'd mentioned setting the heap size, so I set mine. That fixed printf but not fgets.
     
    Stepping into the library code revealed that the problem was with allocating the stream buffer for stdin. I'd set the heap to 512 bytes, and each stream requires 256 bytes buffer space plus 32 bytes of header. The printf call was allocating a buffer for stdout and then the heap had insufficient space to allocate a buffer for stdin. While printf causes the program to exit when it fails to initialise the buffer, fgets and getc just return immediately.
     
    Setting the heap size greater than 576 bytes fixed the issue for me.
     

    * Mainly because I've never seen anyone else even try it - stdio.h is commonly regarded as being a bit "heavyweight" for MSP430. The default stream buffer size is bigger than the ram on the msp430g2553! Most example code I've seen uses the UART backchannel instead, or at least a very cut-down printf implementation with a much smaller buffer.
  17. Like
    tripwire got a reaction from oPossum in Read a line of input from the Code Composer Studio (CCS) console using an MSP430   
    This turned out to be an interesting one, and you're probably going to kick yourself when you see why fgets wasn't working for you...
     
    Initially my gut feeling was that there was no support for reading from the console window on the target*. Having dug a little further I found that the CIO system does support reading from the target side, so I set up a test program to try it out. It didn't work. I noticed that you'd mentioned setting the heap size, so I set mine. That fixed printf but not fgets.
     
    Stepping into the library code revealed that the problem was with allocating the stream buffer for stdin. I'd set the heap to 512 bytes, and each stream requires 256 bytes buffer space plus 32 bytes of header. The printf call was allocating a buffer for stdout and then the heap had insufficient space to allocate a buffer for stdin. While printf causes the program to exit when it fails to initialise the buffer, fgets and getc just return immediately.
     
    Setting the heap size greater than 576 bytes fixed the issue for me.
     

    * Mainly because I've never seen anyone else even try it - stdio.h is commonly regarded as being a bit "heavyweight" for MSP430. The default stream buffer size is bigger than the ram on the msp430g2553! Most example code I've seen uses the UART backchannel instead, or at least a very cut-down printf implementation with a much smaller buffer.
  18. Like
    tripwire reacted to cubeberg in Write Data to Flash   
    I've dealt with writing to flash a bit myself lately - it can absolutely be done in C.  Quick question - GCC or CCS?  I use CCS, but I believe the concepts cross both.
     
    This example is helpful: http://forum.43oh.com/topic/412-saving-data-to-flash-on-power-down/#entry3669 - this bit in particular.
     
    Flash is erased in 16-byte blocks (That's the reference to ERASE and the "= 0" assignment above) and then written to which can be a bit tricky if you've got several values that will fit in one block.  There are a couple of "INFO" segments that are specifically reserved for storing a few values (there are constants containing the locations of those blocks).  Info A is for calibration - so don't mess with it.  I believe the others are available for use.  If you need more space than that - you can use the linker file to reserve some of the flash that would normally be used for code for other purposes.
     
    This article might be helpful as well: http://cyroforge.wordpress.com/2013/01/01/using-flash-memory-in-msp430/
  19. Like
    tripwire reacted to MrP in Read a line of input from the Code Composer Studio (CCS) console using an MSP430   
    I want to read a line of input from the Code Composer Studio (CCS) console using an MSP430

     

    I am able to get printf(
  20. Like
    tripwire reacted to RobG in MEMORY ORGANIZATION IN MSP340FR5969 - WOLVERINE   
    If you use CCS, [your_project_name].map will tell you how your memory is allocated.
    You can also tell CCS to create flash image and see what and where will be loaded to memory.
    Finally, you could just declare a constant ( const char myMem[0x3100] = {0, }; ) and get it's address (&myMem)
  21. Like
    tripwire reacted to Foghorn in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
     
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
     
    http://www.ganssle.com/debouncing.htm
     
    The rest of the documentation can be found inside of the header files within the zipped file below. 
     
    EDIT:
     
    Updated the button debouncer to revision 1.1.
     
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
     
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  22. Like
    tripwire reacted to chicken in Products using MSP430   
    MSP430F5435A and CC2560 in the remote control of the new Amazon Fire TV

    http://www.ifixit.com/Teardown/Amazon+Fire+TV+Teardown/23856#s61356
  23. Like
    tripwire reacted to jpnorair in How slow can MSP430 run?   
    The quick and dirty way to do it is to use the highest clock speed supported by the lowest core voltage.  This information is always in the datasheet.
     
    A lot of it comes down to minimizing on-time of peripherals, which tend to have flatter power vs. clock than the CPU has.  Edit: in particular, powering the Flash memory.
  24. Like
    tripwire reacted to pabigot in How slow can MSP430 run?   
    Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally.
     
    It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  25. Like
    tripwire reacted to rockets4kids in Reversing the LED? i.e. sinking it to MCU?   
    At this point it is worth noting that the forward voltage drop of blue (and phosphor-colored LEDs driven by blue or UV elements) is typically close to that of the operating voltage of the msp430.  When you factor in the voltage droop of loaded MSP430 pins, you'll get some some degree of current limiting even when connecting one of these LEDs without a resistor.
     
    But again, just because this works (and you may find other people doing it) doesn't mean you should do it unless you fully understand what is going on.
×
×
  • Create New...