Search the Community

Showing results for tags 'msp430-elf-gcc'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks

Calendars

There are no results to display.


Found 3 results

  1. Here is some code to drive ws281x strips using DMA driven SPI for the msp430f5529. I hadn't seen any example code showing how to use DMA and SPI. The example also provides some code that shows how to use inline asm that will work with both msp430-gcc and msp430-elf-gcc. The code below was tested with a ws2811 strip and msp430-elf-gcc. https://gist.github.com/RickKimball/9761b8f5a89d46a53939 -rick
  2. Using the FRAM as though it were RAM on the msp430fr59xx chips can make it really easy to drive those ws281x chips even at a relatively slow MCU clock rate. The ws281x chips are great because you can get a boat load of leds for the cost of only one pin. Also, it doesn't hurt the price of these ws281x chips keeps falling and making them more and more attractive. I decided to see if I could take advantage of FRAM to help me drive some of those leds. I ended up with an extremely simple driver routine that works great even when you clock the FRAM MCU @ 6MHz. You couldn't really do this on a RAM limited msp430 chip as you would quickly run out of memory. ... I configured the FRAM chip for 6MHz and then configured the SPI to use a clock divisor of 1 the MOSI is selected for output and is wired to ws281x DIN pin. ... static const uint8_t frame_buffer[60*3*8] = {0}; /* provide an FRAM buffer for a strip of 60 leds */ /* * inline msp430-elf-gcc asm version */ void sendRGB(uint8_t * led_data, unsigned led_data_len) { const uint8_t *led_data_end = led_data+led_data_len; uint8_t *dest = const_cast<uint8_t *>(&frame_buffer[0]); uint8_t *frame = dest; do { unsigned color = *led_data++; register unsigned colormask = 0x80; do { *dest++ = (color & colormask) ? 0x78 : 0x60; colormask = colormask >> 1; } while (colormask); } while (led_data < led_data_end); // shift out bits in MSB order without much delay __asm__ __volatile__ ( "1:\n" " mov.b @%[led_data]+, %[TXBUF] ; 5 cycles\n" " jmp .+2 ; 2 cycles\n" " cmp %[led_data_end], %[led_data] ; 4 cycle\n" " jl 1b ; 2 cycles\n" :[led_data] "+&r" (frame) ,[led_data_end] "+r" (dest) :[TXBUF] "m" (UCB0TXBUF) : "cc" ); In the code above, I provided a function that expects an array of RGB data (well GRB data actually ) and I I looped through it and setup the FRAM buffer with proper SPI bits for ~333ns/~666ns and with a period of ~1500 ns. The wave it spews out looks really pretty on my scope. Best of all, the ws281x chips seem to like it. I encountered one wierd anomaly of the eUSCI periperal. It seems that if the high bit of the last thing you sent is high, then the MOSI pin floats high instead of leaving the value at the last bit set. This is why I'm using 0x78 (0b01111000) and 0x60 (0b01100000) instead if 0xF0 and 0xC0. I wasted a bunch of time trying to find out why my code wasn't working on that one. I never did find a tech note or errata about it. If you are using the SPI device as a normal SPI device instead of a shift register, it wouldn't matter. -rick
  3. So now that that CCS 6 includes a "released" msp430-elf-gcc, I thought I'd share my ultra small c-runtime startup code as an exported CCS project. This will be useful to those who want to use the free msp430-elf-gcc with the smaller chips like an msp430g2231. Also, it is an exercise to see if I can share exported CCS project files that will be usable in Windows even though I'm using CCS v6 on linux. Just download the attached zip file and then use the "Import Project" button on the "Getting Started" page in CCS. It should import the zip file into a new project in your workspace called "blink_g2231" (make sure you don't already have a project with that name in your workspace). Hopefully all my settings will stick and you can build and debug to generate a version of code that is only 92 bytes. The normal c-runtime produces a file that is about 498 bytes for this same main.c. With this project, the normal c-runtime is replaced with a handful of assembler instructions and checks a few settings in the link properties to disable the one supplied with msp430-elf-gcc. This code assumes you are using the latest msp430-elf-gcc Will Cooper just announced yesterday (8-14-2014). The new version is available on the App Center page in CCS. Just click on the "MSP430 GCC" badge and press the "Select" to and install software to update. In the attached project you will find three source files: main.c, _start.S and iomacros_fixed.h. _start.S takes the place of the normal c-runtime and just does the minimum to get ready before starting your main() function. The assembler code makes the assumption that your main function never returns to further reduce the c-runtime overhead code. The file iomacros_fixed.h provides a modified iomacros.h that defines the SFR macros so the the header can be included in msp430 assembler files. I've used the _start.S with the msp430fr5969 also. So it isn't limited to the msp430g series. If you want to have more control over your c-runtime this might be something you might take a look at. -rick [edit]: BTW I'm using an msp430f5529 launchpad as a programmer / debugger on linux. I used jumper wires to connect a version 1.4 msp430g2231 launchpad. This works great! blink_g2231.zip