Jump to content

xpg

Members
  • Content Count

    425
  • Joined

  • Last visited

  • Days Won

    10

Reputation Activity

  1. Like
    xpg got a reaction from gsutton in programming a MSP430G2955?   
    Just programmed jazz' file using mspdebug with a small patch to enable MSP430G2955. It works just fine. Unfortunately, the forum software won't allow me to attach the patch. Patch attached.
    msp430g2955-patch.zip
  2. Like
    xpg got a reaction from gsutton in MSP430G2955 Launchpad Development   
    I just played a bit around with Rob's board and the MSP430G2955 and discovered that only P1 and P2 have interrupts on the MSP430G2955. According to the LaunchPad/BoosterPack standard only two pins are required to be interrupt capable: P1.3 and XOUT on the MSP430-launchpad (A5 and B3 according the BoosterPack Interface spec). I really wasn't aware of that requirement until now, I just figured that most pins had interrupt capabilities anyways.
  3. Like
    xpg got a reaction from bluehash in Eclipse plugin for mspdebug and msp430-gcc   
    Hi,
     
    I'm not quite sure. It haven't used the plugin myself for a long time myself.
    It has generally been far too long since I've had time to do anything with an MSP430 chip (which is also why I haven't really been active in here).
     
    But if you try it out please let me know how it goes.
  4. Like
    xpg reacted to pabigot in The Datasheet "Book Club"   
    Today's research is on Cortex-M sleep modes and interrupt handling. I'm still digesting the bulk of it, but the short form is there are three common operational modes (RUN, SLEEP, DEEP SLEEP) that are implemented through Cortex-M instructions WFI/WFE and bits in the SCR. (Anything lower than DEEP SLEEP, like "hibernate" or EM3/EM4, is probably vendor-specific). Based on a sample size of two (TM4C and EFM32), RUN and SLEEP are simple, but DEEP SLEEP can reconfigure your processor and peripheral clocks back to their power-up defaults. PRIMASK plays an important role in this too, if you want to be sure all interrupts are handled before you commit to sleeping. (Which you probably do, if what your interrupts do includes assumptions that the clocks are configured in a particular way.)
     
    The "book-club" relevant part is that section 5.2.6 "System Control" of the TM4C123GH6PM datasheet clearly specifies that software must confirm the EEPROM is not busy prior to entering either SLEEP or DEEP SLEEP. TivaWare's ROM_SysCtl*Sleep and CPUwfi() don't do this explicitly, though many of the EEPROM_* commands do check EEPROM.EEDONE before returning. Keep this in mind if you happen to be mucking with the EEPROM just before going to sleep, say, maybe to save some state in non-volatile memory.
  5. Like
    xpg reacted to pabigot in MSP debug stack no longer open source   
    Just a heads up for those concerned with software licensing: although TI has open-sourced the MSP Debug Stack, in fact it now contains material that is not open-source, related to an Energy Trace facility. That facility and the change in licensing appeared in June 2013 in slac460f, prior to which this package was entirely BSD.
     
    I've confirmed that objects derived from the sources with the TI TSPA license (displayed below) are present in libmsp430.so, which appears to bring the licensing below into effect. There is a single API header which is BSD-3-Clause, but to use it would explicitly invoke material that is restricted.
     
    Anybody using the MSP debug stack who has not reviewed the license on each new release should be made aware of the change and consult qualified legal counsel as appropriate.
     

    /* * EnergyTraceProcessor.h * * Copyright (c) 2007 - 2013 Texas Instruments Incorporated - http://www.ti.com/ * * All rights reserved not granted herein. * Limited License. * * Texas Instruments Incorporated grants a world-wide, royalty-free, * non-exclusive license under copyrights and patents it now or hereafter * owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") * this software subject to the terms herein. With respect to the foregoing patent * license, such license is granted solely to the extent that any such patent is necessary * to Utilize the software alone. The patent license shall not apply to any combinations which * include this software, other than combinations with devices manufactured by or for TI (<93>TI Devices<94>). * No hardware patent is licensed hereunder. * * Redistributions must preserve existing copyright notices and reproduce this license (including the * above copyright notice and the disclaimer and (if applicable) source code license limitations below) * in the documentation and/or other materials provided with the distribution * * Redistribution and use in binary form, without modification, are permitted provided that the following * conditions are met: * * * No reverse engineering, decompilation, or disassembly of this software is permitted with respect to any * software provided in binary form. * * any redistribution and use are licensed by TI for use only with TI Devices. * * Nothing shall obligate TI to provide you with source code for the software licensed and provided to you in object code. * * If software source code is provided to you, modification and redistribution of the source code are permitted * provided that the following conditions are met: * * * any redistribution and use of the source code, including any resulting derivative works, are licensed by * TI for use only with TI Devices. * * any redistribution and use of any object code compiled from the source code and any resulting derivative * works, are licensed by TI for use only with TI Devices. * * Neither the name of Texas Instruments Incorporated nor the names of its suppliers may be used to endorse or * promote products derived from this software without specific prior written permission. * * DISCLAIMER. * * THIS SOFTWARE IS PROVIDED BY TI AND TI<92>S LICENSORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, * BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL TI AND TI<92>S LICENSORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, * OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */
  6. Like
    xpg reacted to Fred in Optimising math   
    Lots of interesting stuff, but you're forgetting one thing. Do you NEED to optimize? For example, if you're checking altitude 5 times a second and your non-optimised code takes a (relatively) very slow millisecond to do the calculation then you are very far from needing to optimize.
     
    It's very relevant to consider performance on an embedded device. However, optimised code tends to be less readable, less maintainable and more likely to have bugs. If your "improved" code is quicker but causes you to trip up later on a subtle bug, is it really better?
     
    Don't take this it mean that you shouldn't have asked or that I'm not interested in the answers! My view may be tainted by the fact I spend a lot of my day job (as a C#/Java developer) working with convoluted buggy code where people were trying to prove they were clever when really they didn't need to.
  7. Like
    xpg reacted to username in MSP430 WiFi Smart Scale   
    Hey all,
     
    *Quick Reflow Oven Update
     
    Sorry you haven't heard much from me in awhile, work has been keeping me very busy. First off, I apologize for not being able to keep up with the reflow oven kit demand. My new job has been abit demanding and the displays I was using appeared to have gone off the market so it would require a redesign. In addition, I ran out of code size on the msp430 while many features still needed to be implemented. I'm working on a new one but it won't involve a msp430.
     
    *Onto the project
     
    So with my new job and all i've spent abit too much time sitting around. Consequently I needed a little motivator to get out to the gym. Basically I wanted to log my weight data and view it in a graphical form. Apparently these already exist in the form of a "smart scale". Anyhow, didn't really know that going into the project nor would I feel like paying 100USD+ for one.
     
    Step 1:
    First I bought the worlds crappiest weight scale at walmart for less than 20usd

    http://www.walmart.com/ip/Healthometer-LED-Split-Mat-Bath-Scale/10264542
     
    Step 2:
    Then I opened it up and attempted to hack the internal control board. Acourse it was one of those black blobs which meant it was a system on chip. Sadly the analog lines were feeding directly into the micro which presumably had its own differential amplifier. Sadly there were no outgoing lines from this micro that had a voltage or pulse width proportional to the weight. Long story short, there was no easy way to get the weight from the prebuilt electronics so I scraped it.

     
    Step 3:
    So next step was to determine how to build the electronics required for the weight scale. Weight scales use a sensor called a load cell which are generally just strain gauges. Strain gauges are sensors that have a very very very small change in resistance with respect to weight. Consequently, a wheat stone bridge configuration is generally used to read them. In addition, one uses multiple strain gauges in order to avoid temperature fluctuation and drift. This weight scale used load cells similar to ones on sparkfun:

    https://www.sparkfun.com/products/10245
     
    So in the scale, there are 4 load cells. Each load cell is a half wheat stone bridge. With clever wiring, you can make 1 wheat stone bridge consisting of 4 half wheat stone bridges, see picture below:

     
    Step 4:
    ...Time to go to work so i'll post more on this later. Basically I used a instrumentation op amp to read the Wheatstone bridge. Then I built a board with dorkbot pcb and populated it. As for the 802.11 support, ages ago I bought a wizfi210 from bluehash so I used that. Also used one of my few remaining 2.2" lcd displays.

     

     
    Step 5:
    write the code stuff and make it upload to xivley:
    https://xively.com/feeds/1844651192
     
    Step 6: (ongoing)
    WIP is getting this to not drift and give consistant repeatable measurements.... i'm getting there.
     
     
    and yea.. i'm off to work. I'll get more of a writeup on this latter.
  8. Like
    xpg got a reaction from hongphuc6789 in Web browser controlled 16x16 Bi-Color LED-Matrix   
    This is my somewhat crazy networked controlled bi-color LED matrix build:
     

     

     
    It’s build around the TI TLC59281 as current sink column controller and a shift-register and PNP transistors as row controllers (and current source). I am using two TLC59281s one for red and one for green. Each sink controls two 8x8 LED matrix displays such that the rows of the two matrices are common. An NXP LPC1114 controls these two displays and is itself controlled via a simple SPI-protocol. The LPC1114 is running at 50MHz and updates the two led-matrices completely around 50 times a second and has 6-bit color depth per color (i.e 12-bit colors). It receives commands from the SPI bus at 1MHz, and allows the SPI bus to be shared amongst multiple display controllers. Each controller is assigned an area of the total “screen space” and simply ignores draw operations outside of this space.

    In the video above I have two LPC1114s and one Stellaris Launchpad:
     


    The Stellaris Launchpad runs lwIP and has a simple web server that accepts simple draw commands (put single pixel, put multiple pixels, clear). I’ve written a simple JavaScript HTML page that allows the LED matrix to be controlled from a web browser. Currently, the web-page is not served by the Stellaris Launchpad, but I'm working on that one (should be quite straight forward). I am supplying my LED Matrix PCB with 5V directly from an USB power adapter. Unfortunately, the PNPs on the PCB feed the matrix the same voltage as the TLC59281s and the 74HC595, so the ICs are running off 5V as well, which wasn't the plan at all :-)
  9. Like
    xpg got a reaction from Rickta59 in Black Magic Probe for Stellaris Launchpad   
    I got a bit tired of not being able to debug on the NXP LPC1114, which supports SWD only (no JTAG). I discovered Black Magic Probe (http://www.blacksphere.co.nz/main/blackmagic), which is an open source project that uses an STM32 to export a GDB server via an USB serial device. It support both JTAG and SWD and should support a wide range of Cortex-M0, M3, and M4 targets. It can be used both for debugging and flashing of the target device.
    There is dedicated hardware for this, and it can be run on the F4-discovery boards as well. Unfortunately, I do not have any F4-discovery boards lying around. But I do have a couple of Stellaris Launchpads that do nothing but sit in their box. So I added the necessary code to allow the Black Magic Probe firmware to be flashed on the Stellarpad (which really wasn’t that much).
     
    Currently, UART0 on the LM4F is used, which is connected to the on-board debugger module that exports it via USB as a CDC ACM serial device.
     
    The pinout is as follows:


    JTAG TMS / SWD IO  - PB5
    JTAG TCK / SWD CLK - PB0
    JTAG TDI           - PB1
    JTAG TDO           - PE4
    TRST               - PA5
    SRST               - PA6

    IDLE LED           - PF2 / Blue LED
    ERROR LED          - PF3 / Green LED


    You can grab the code from GitHub and try it out yourself: https://github.com/xpgdk/blackmagic/tree/stellaris_launchpad
     
    Please try it out, and let me know if there are any issues.
     
    The quick build instructions (for Linux) are:


    src$ git clone https://github.com/xpgdk/blackmagic.git
    Cloning into 'blackmagic'...
    remote: Counting objects: 1858, done.
    remote: Compressing objects: 100% (763/763), done.
    remote: Total 1858 (delta 1230), reused 1704 (delta 1084)
    Receiving objects: 100% (1858/1858), 610.80 KiB | 324 KiB/s, done.
    Resolving deltas: 100% (1230/1230), done.
    src$ cd blackmagic
    src/blackmagic$ git checkout stellaris_launchpad
    Branch stellaris_launchpad set up to track remote branch stellaris_launchpad from origin.
    Switched to a new branch 'stellaris_launchpad'
    src/blackmagic$ git submodule init
    Submodule 'libopencm3' (https://github.com/xpgdk/libopencm3.git) registered for path 'libopencm3'
    src/blackmagic$ git submodule update
    Cloning into 'libopencm3'...
    remote: Counting objects: 12626, done.
    remote: Compressing objects: 100% (6494/6494), done.
    remote: Total 12626 (delta 6511), reused 11757 (delta 5726)
    Receiving objects: 100% (12626/12626), 3.25 MiB | 733 KiB/s, done.
    Resolving deltas: 100% (6511/6511), done.
    Submodule path 'libopencm3': checked out 'f5c15fe74e438dc9cceac6543d2c180957a3dd9b'
    src/blackmagic$ cd libopencm3
    src/blackmagic/libopencm3$ make

    src/blackmagic/libopencm3$ cd ../src
    src/blackmagic/src$ make PROBE_HOST=stellaris-launchpad

    src/blackmagic/src$ lm4flash blackmagic.bin


    Now, you should be able to connect to the GDB server:


    $ arm-none-eabi-gdb
    (gdb) target extended-remote /dev/ttyACM0
    (gdb) monitor swdp_scan
    Target voltage: not supported
    Available Targets:
    No. Att Driver
     1      lpc11xx
    (gdb) attach 1
    Attached to Remote target
    0x00001066 in ?? ()

  10. Like
    xpg reacted to jpnorair in Ideal RF PCB stackup   
    There are many ways to get a good result, but components cannot be inside the board, and vias add reactances, so we need to find ways to put the traces on the outer layers.  Fortunately, there are ways!  ST has a nice app note, I think it covers pretty much everything.  
    http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00065838.pdf
     
    The main thing you need to think about is the fact that the traces on the board can act as antennas if you do not design properly.  They can also cause impedance mismatch, causing less power to go to your antenna if you don't do them the right way.  This becomes a bigger and bigger problem as MHz gets higher.  For example, at 434 MHz, you don't run into too many issues.  900 MHz, still not too bad, but getting to the point transmission line behavior is important.  1575, 1850, 2450... things get serious.
     
    To design the traces "the right way" you should design them as coplanar waveguides or microstrip transmission lines, tuned to 50 Ohms.  The problem with a 2-layer board is that the transmission line traces need to be really wide to allow 50 Ohm impedance.
     
    I searched on google and I found this website with transmission line calculators for coplanar waveguide, microstrip, and slot (you probably don't need the slot part).  I can also tell you a "magic number" -- at 434 MHz on normal FR4, with 0.16mm spacing, with 4-layers, with a ground plane directly below, and with a ground plane around the trace -- the magic trace width is 0.47mm.
    Microstrip Line Calculator
    Coplanar Waveguide Calculator
    Slot Line Calculator
  11. Like
    xpg reacted to JWoodrell in [POTM] Audible Alarm player.   
    well, here is what has gone on with this project so far.
     
    here are the test units actually mounted to the equipment at the factory.


     
    had to cut the boxes speaker grills by hand with a dremel but it came out well for the 4 test units, the 100 will be cnc routed and all nice and spiffy.

    the 4 test units worked well for them and now they have ordered 100 units of one type and 15 of another i need to redesign slightly
    here are the test boards assembled


    I had to split the circuit board on one of the two versions because the speaker interfered with the heatsink, and I had planned on the smaller speaker when designing these initial test boards.
     
    I got a cubic butt ton of parts sitting in my room right now waiting to be sent to the assembler.
    120 SD cards

    enough parts to build 120 units

     
    There are now 3 speaker versions of this project, one up to 87 dB, one up to about 100dB, and the third around 110, and I'm working on a fourth to take it up to about 120ish i hope but well see.
     
    Figured out the LDO overheating problem I was having and why I had to have a sizeable heatsink to-220 package for the 24V to 3.6v regulator.  the sd card slot has a card detect switch, and although neither pin on the switch is connected to the case (ground), when it is soldered down, and a card is inserted there is about 17 ohms resistance to ground.  I had the switch wired as positive switching. im not sure why, and don't really care to figure out the fine details, needless to say this was pulling about 300 mA from the regulator and dropping from 24 down to 3.6v, was dissipating about 6 watts hence roasted sot23. so i am changing to an open drain setup where the switch will ground the line, and it will have a pullup resistor...  anyway problem found.
     
    have coding changes in place to read 16bit files, as well as stereo.  (so either every other data is valid, or one out of four, it just ignores the other samples) fine tuned the timing and sampling so quality is basically full now, I would say CD quality but I;m a bad judge of audio.  it can do 44 k samples/sec files without dropping any samples and no  static or glitches that I can hear.
     
    anyway I am going to let you know how it goes from here
  12. Like
    xpg got a reaction from PTB in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    This is an amazing project. Thanks for sharing!
  13. Like
    xpg reacted to PTB in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  14. Like
    xpg reacted to bluehash in Members will now be warned for incorrect post content format.   
    Hello Everyone,
     
    Since the community is growing to larger numbers, it becomes difficult for moderators to keep editing posts that don't follow correct post etiquette.
     
    So far, there are only two major rules to follow about post content.
    1. Do NOT use dropbox, imgur or any other thirdparty links, if you care about this community. These links die off after a few years/months. Look around the major forums. Images dating back to 2010 are dead and the posts are useless. So please upload to 43oh.
     
    2. Please use the code tag to display code. It is much easier to read and you will most probably get an answer as members will at least try to browse through code. It is the "<>" button in your edit bar.
     
    The warning points makes it easier for us to let you know instead of spending alot of time everyday downloading and re-uploading images and editing posts. Warning points hold no value, they will not harm you. It is just to let you know. You must acknowledge the warning to continue posting.
     
    Thanks! Any concerns, please list them below.
  15. Like
    xpg reacted to brainwash in Eclipse plugin for mspdebug and msp430-gcc   
    I don't know how relevant this is but TI has brought mspgcc support to their IDE: http://www.ti.com/tool/msp430-3p-gcc-mspgcc-tpde
    While it's still not a clean Eclipse installation it allows usage of GCC code and probably easy Energia integration.
    Also: http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/12/09/you-beta-believe-it-gcc-and-ccsv6.aspx
     
    If an IDE is what you are looking for, GCC is now integrated in the recent BETA release of Code Composer Studio 6 as well. This means that if the size and speed and optimization support offered by the TI compiler are unnecessary for your application, you can choose to compile with GCC and use Code Composer Studio for free, without any code size limitation!
     
  16. Like
    xpg reacted to moisesesc in TIVA C Launch Pad Fails at below 0 C and above 40 C temperatures   
    Hello forum members
     
    We have an update on the issues posted here.
     
    After reading all your great suggestions and going back 
     
    and trying to do as suggested, we finally after several hours
     
    of debug and test we were able to ping point the trouble piece of code.
     
    For the low temperature issues it turns out that our equation calculating
     
    fault temperatures was off by factor of 10 as a results when the temperature
     
    return back by ADC at temperatures below 0 was causing our equation to blow up
     
    and trick our code that a temperature fault had occurred on the board and PWM
     
    and motor needed to be shutdown.  Why we did not catch this before, was for two reasons
     
    1) I am a monkey, and failed miserably to code the right equation for the temperature fault.
     
    2) I fail to keep the temperature fault flag longer then a few seconds to allow me to see 
    what had cause the temperature fault.  Now I set up a sticky fault to allow me to see
    what had cause the temperature fault.
     
    Now I am doing more freezer testing and High temperature testing just to make sure I did not guff again.
     
    Thank you so much for all of you that took that time to respond and make great suggestions to try out
     
    and get to a resolution.
  17. Like
    xpg reacted to roadrunner84 in 43oh just crossed 20,000 members!   
    Yay!
     
    On a little investigation:
    0 posts: 18199 1 post: 607 2-9 posts: 883 10-99 posts: 326 100+ posts: 62 To describe a bit of the actual usage of the forum. I do understand that a lot of folks come by just to ask a single question and maybe a follow-up (1-9 posts), but I am surprised to see that over 90% of the members have never posted at all!
    The core users (10+ posts) consist of a mere 2% of the members.
  18. Like
    xpg got a reaction from spirilis in 43oh just crossed 20,000 members!   
    Congrats -- to all of us. And thank you 43oh team, you have done a very good job!
     
    This is really the most friendly and helpful forum I have ever had the pleasure to participate in. Now, if I just could get some more spare time in the coming year to actually be active in here... 
  19. Like
    xpg reacted to juani_c in Killing Zombies with the Launchpad   
    Well, this is my entry for the November 2010 Project of the Month Contest. It is very simple and far less usefull than the others projects. The truth is that I wasn't participating until I saw the Chronos .So i had to come up with something easy and fast to develop. I was plaiyng arround with some leds and photodiodes in front of my pc monitor and I thought that cold be interesting to interact with the screen with the photodiodes or some other ligth sensor. that idea eventually ended up being a shooting game. I wasn't too sure what to shoot at but then i realized that the option was obvious; ZOMBIESS!!!. everybody like killing zombies.The circuit is very simple. the LDR is in a voltage divider with a 10K potentiometer. moving the potentiometer will help with the calibration.It has also a capacitor to stabilize the analog signal. the trigger is a switch in series with a resistor and a capacitor for debouncing. this swicth is in fact in parallel with S2 in the Launchpad so you could just use that one an reduce the number of needed parts. I just use my hand for the gun so I didn't have to make one (it also makes a great human machine interface ).The source code for the MSP430 is basically the same as the "Snake game". every time you pull the trigger the ADC takes 16 samples and send the avarage to the computer. The analog signal is provided by the LDR. the LDR has a different response depending on the wavelength of the incident light (that`s the reason for the funky colors). it isn't very accurate, variations on the ambient light or in screen distance will lead to a misunderstanding between the zombies. Every time you pull the trigger and hit one of them you'll hear a shot and a zombie scream because, well, even zombies don
    LaunchPad-Zombies.rar
  20. Like
    xpg reacted to petertux in Remote controlled power socket   
    I had a lot of fun with these RC switches. I have a few permanently set up in my house for easy control of power distribution.
    all of those I use are the 'Intertechno' kind since they are readily available in electronic stores here. they work at 433.92 MHz and support about 272 separate devices in one household. apart from controlling 220V mains and light dimmers some are used for 12-24V switching or motor control. even the doorbell is controlled by one of these puppies.
     
    for those interested I have reverse-engineered the protocol so you can easily control any device from a uC. here are some links:
     
    manufacturer:
    http://www.intertechno.at/
     
    libraries for msp430/arduino
    https://github.com/rodan/reference_libs_msp430f5x
    https://github.com/rodan/intertechno
     
    EZ430-Chronos 433MHz fork
    https://github.com/rodan/openchronos-rfsw
     
    compatible TX module
    http://www.seeedstudio.com/depot/grove-433mhz-simple-rf-link-kit-p-1062.html?cPath=19_22
     
    or TX hack of the remote control (signals from a uC are sent via the remote)
    https://plus.google.com/photos/106706955427383613204/albums/5812212126326845953
     
    implementation idea (control of APC ups-es)
    https://plus.google.com/photos/106706955427383613204/albums/5716081356871198257
     
    sorry for reopening old threads, but I slowly catch up with the forum. plus maybe someone will be interested in some of this stuff.
  21. Like
    xpg reacted to rockets4kids in FET vs EEM   
    The use of the word "emulation" is archaic and is in no way appropriate to the way MCUs are used today.  TI should have dropped the term a decade ago, as it serves only to confuse just about everyone who wasn't using microcontrollers well over ten years ago.
     
    Historically, re-programmable memory was very expensive so most chips used either ROMs that were masked directly onto the chip or one time programmable memories.  Even silicon was very expensive, so any debugging hardware at all was never included on the chips.  Development and debugging was done on dedicated boards that that either implemented the processor with discrete components or emulated it with a more advanced processor.  The program ROM was also typically emulated in RAM.  Because these development systems were very complex and only produced in relatively small volumes, they were typically very expensive.  Even at the very tail end of their use they still cost more than $1000.
     
    However, new processes and technologies have made both FLASH memory and silicon cheap, and the cost to implement the hooks required to enable debugging on the chip itself add so little to the overall cost that just about all modern microcontrollers include them.  The MSP430FET is merely a communications bridge between the host and the on-chip debug hardware.
  22. Like
    xpg reacted to PedroDaGr8 in 40 Male->Female jumpers - $3.99   
    But of course!









  23. Like
    xpg got a reaction from hongphuc6789 in Web browser controlled 16x16 Bi-Color LED-Matrix   
    "shortly" turned out to be 7 months, and I haven't made any of the planned "cleanups". However, the code is now available at github. Stellaris code is at https://github.com/xpgdk/networked-led-matrix-controller, while the LPC code is at https://github.com/xpgdk/lpc-led-matrix-controller
     
    Questions and comments regarding the code are welcome. I still have plans to do quite a bit of cleanup, but I just don't have the time for it currently.
    Thanks to @@hongphuc6789 for reminding me of releasing the code.
  24. Like
    xpg reacted to zeke in Does anyone work as an embedded engineer?   
    I have always wanted to be an embedded systems engineer. I got my tech diploma first, worked as a board level troubleshooter/repair then I went back to university and got my EE degree. I have since worked for others and now I work for myself.
     
    What I realize from all of that experience is that the definition of Embedded Engineer is inside your head and heart. If you want to do it then it doesn't matter how much training you have or who you work for. If the thought of doing all of this EE like stuff consumes your thoughts, emotions and spare time then you are an Embedded Engineer.
     
    The "world" needs definitions and metrics to measure economic compensation and progress therefore you will be judged by the academic accolades behind your name. It's a fact of life. Don't let that get you down. There are some hurdles worth climbing over. Like strategically getting that degree or diploma that let's you pass the gatekeepers (HR department).
     
    Concerning the work itself, nothing is impossible to accomplish when you have knowledge, skills and abilities. You can learn the unknowns. You can practice the skills. If you don't have the abilities then you are screwed. 
     
    An example of an (dis)ability would be color blindness. If you cannot distinguish all the colors of the resistor codes then you are at a disadvantage.  If you cannot see with your eyes then you cannot code very fluidly. If you cannot hold your hand steady then you cannot hand place 0603 resistors very easily. If you do not believe in yourself then you will be gripped by fear and never take a risk to achieve your goals.
     
    I have been working in this electronics industry since 1988. I am constantly learning. I am constantly being judged by the work of my hands and my mind by peers, employers and, now, clients. I could create a very large list of important knowledge, skills and abilities that I consider as prerequisites to succeed in the electronics industry. That list would be only for me though. Your list will be different.
     
    I came across a speech by Arnold Schwarzenegger this week on youtube. I took notes since the speech is 25 minutes long unedited. Here is the sensationalized TL;DR version. Here's what I wrote down:
     
    1. Trust yourself:
    - What do you want to be?
    - What makes you happy?
     
    2. Break the rules
    - Don't follow society's rules and traditions blindly
     
    3. Don't be afraid to fail
    - Do NOT be paralyzed by fear or you will never make a decision
     
    4. Don't listen to the Naysayers
    - IT CAN BE DONE
     
    5. Work your butt off!
    - Leave no stone unturned aka: Network! Network! Network!
    - No pain No gain
    - There is no way around hard work
    (This next one is my favorite)
    - You cannot climb the ladder of success with your hands in your pockets!
     
    6. Give back
    - You have to help others around you
    - Pay it forward, Pay it back
    - Be generous to and with others
     
    In my opinion, YES, you can do it! You can be the Embedded Engineer that you see in your mind. You can make bluetooth peripherals work. You can do everything that you set your mind to do.
     
    Yes, it will be hard work learning how something works.
    Yes, it will be challenging learning how to craft code.
    Yes, you will have to ask for help.
    Yes, you will have obstacles.
    Yes, you will overcome them.
    Yes, you will succeed.
     
    Jack Ganssle did it. So can you.
     
     
     
     
  25. Like
    xpg reacted to Fred in Animated Darth Vader build monitor   
    At work we use Continuous Integration to build and test our code as we check it in. It helps catch problems early and ensures we keep code standards up. We were using CruiseControl.NET but have now moved to TeamCity. Anyway, this is no use unless people take notice of broken builds and this was starting to slip. I decided that something fairly visible (but not too annoying) was needed. After spotting a Lego Dath Vader toy torch it seemed like a good solution.
     
    The standard toy has a button on his chest that is used to switch on some while LEDs in his feet. There was also a red LED and a AAA battery in his lightsaber so it could be switched on. The plan was to add a servo to his arm so he could wave the lightsaber around and replace the red LED with a RGB one so that the colours could change. All of this under PC control of course.
     
    Rather than describe in in boring detail exactly what I did, I hope some photos of the progress will sum it up. First I had to get a servo in place operating his right arm. It required cutting away the battery compartment, filing the joint to make it a little easier to move and hot-gluing the servo in place.
     
     
     
    The front just involved making a bit more room to glue the servo in. The a slot needed to be carefully added for the servo horn to drive the arm. The horn was later screwed to the servo. The connection between the servo horn and teh shoulder joint is just a push fit.
     
     
     
    For the lightsaber, the battery, connectors, original PCB and LED had to be removed. The switch was glued in place as it wasn't to be used but needed to fill the hole. As ther was no PCB to locate the new LED, it was glued into place. Running the 4 wires from the RGB LED involved carefully drilling a path through the side of the lightsaber, the hand, arm and shoulder joint. I had to be careful that the wires coming out of the shoulder didn't limit the servo movement.
     
     
      
     
     
    The next step was putting all this under PC control. I decided that the recently release MSP430F5529 Launchpad would make be ideal due to the built-in USB functionality. It could easily handle a few PWM channels. All that was required was to connect ground, 5V and a PWM signal to the servo and 3 PWM signals to the channels of the LED. I wasn't going to drive the LED directly from the MSP430 pins, but to use a P channel MOSFET and a NPN transistor as a high side switch (for the common cathode LED). However it seems that the F5549 can handle a little more than the spec sheet says. I was lazy and just drive them via some 100 ohm resistors. The photo also shows the clear acrylic base (cut using a 40W CO2 laser cutter) and a 3D printed enclosure for the Launchpad.
     
     
     
     
    A small home etched PCB is underway so that it will just need a USB cable to his back rather than the bulky external Launchpad. Whether this phase 2 gets overtaken by other projects or not though - that's a good question.
     
    The connection between the device and the PC is using a USB serial port. The code is adapted from the sample CDC COM port code for the Launchpad. I used TA0.2 to TA0.4 for the LED PWM as these are easily accessible on the Launchpad. I used TA2.1 for the servo as this was conveniently close to the 5V supply needed for the servo.
     
     
    As far as what controls Darth Vader, I tried a number of options. Initial control was done from an ASP.NET MVC web page. Anyone in the office could control him with simple URLs like fredpc/Vader/Colour/Blue or fredpc/Vader/Position/0. The connection to TeamCity proved a little more difficult. I started work on a Java plug-in for TeamCity that woudl call these URLs, but it was a pain to get the plug-in installed and working in TeamCity. All the documentation I could find was out of date and incosistent - as is often the case with Java. I ended up going with a Windows service that polls TeamCity (using Rest APIs) every 10 minutes.
     
    I you'd like to see it working, here are a couple of videos of it in action.


     
     
    Well, I'm entering this is the Halloween contest - you can even see 43oh in the background in the second video. I hope it's Halloweeny enough, because strictly speaking it's a project that I did to use at work. It's in action right now monitoring our TeamCity build server. In fact the MD of the company wandered past my desk this afternoon to ask why Darth Vader was red. It's a bit scary being under that sort of pressure to fix any broken unit tests, but that was kind of the point...
     

    /* --COPYRIGHT--,BSD * Copyright (c) 2013, Texas Instruments Incorporated * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * * Neither the name of Texas Instruments Incorporated nor the names of * its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * --/COPYRIGHT--*/ /* * ======== main.c ======== * Darth vader control: * * This code has been adapted from TI's cample CDC COM port code * ---------------------------------------------------------------------------*/ #include <string.h> #include "inc/hw_memmap.h" #include "gpio.h" #include "wdt_a.h" #include "ucs.h" #include "pmm.h" #include "sfr.h" #include "timer_a.h" #include "USB_config/descriptors.h" #include "USB_API/USB_Common/device.h" #include "USB_API/USB_Common/types.h" // Basic Type declarations #include "USB_API/USB_Common/usb.h" // USB-specific functions #include "USB_API/USB_CDC_API/UsbCdc.h" #include "USB_app/usbConstructs.h" /* * NOTE: Modify hal.h to select a specific evaluation board and customize for * your own board. */ #include "hal.h" // Function declarations BYTE retInString (char* string); // Global flags set by events volatile BYTE bCDCDataReceived_event = FALSE; // Indicates data has been rx'ed // without an open rx operation #define MAX_STR_LENGTH 64 char wholeString[MAX_STR_LENGTH] = ""; // Entire input str from last 'return' BYTE wildcardMatch (char* string, char* match); void send(const char* message); void initServo(void); void stopServo(void); void setServo(unsigned char duty); void parseAndSetServoPosition(char positionText); void setServoOffTimer(void); void initRgbLed(void); void setRgbLed(unsigned char red, unsigned char green, unsigned char blue); void parseAndSetColour(char* colourText); void vaderTest(void); unsigned char getHexDigit(char text); const unsigned int ServoPeriod = 655; // = 32768 / 50 = 20ms; const unsigned int positions[] = {30,34,38,42,46,50,54,58,62,66}; // 0.9 to 2.1ms /* * ======== main ======== */ VOID main (VOID) { WDT_A_hold(WDT_A_BASE); // Stop watchdog timer // Minumum Vcore setting required for the USB API is PMM_CORE_LEVEL_2 . PMM_setVCore(PMM_BASE, PMM_CORE_LEVEL_2); initPorts(); // Config GPIOS for low-power (output low) initClocks(8000000); // Config clocks. MCLK=SMCLK=FLL=8MHz; ACLK=REFO=32kHz USB_setup(TRUE, TRUE); // Init USB & events; if a host is present, connect initRgbLed(); initServo(); // Setup servo PWM __enable_interrupt(); // Enable interrupts globally while (1) { BYTE i; // Check the USB state and directly main loop accordingly switch (USB_connectionState()) { // This case is executed while your device is enumerated on the // USB host case ST_ENUM_ACTIVE: // Enter LPM0 (can't do LPM3 when active) __bis_SR_register(LPM0_bits + GIE); _NOP(); // Exit LPM on USB receive and perform a receive operation // If true, some data is in the buffer; begin receiving a cmd if (bCDCDataReceived_event){ // Holds the new addition to the string char pieceOfString[MAX_STR_LENGTH] = ""; // Holds the outgoing string char outString[MAX_STR_LENGTH] = ""; // Add bytes in USB buffer to the string cdcReceiveDataInBuffer((BYTE*)pieceOfString, MAX_STR_LENGTH, CDC0_INTFNUM); // Get the next piece of the string // Append new piece to the whole strcat(wholeString,pieceOfString); // Echo back the characters received cdcSendDataInBackground((BYTE*)pieceOfString, strlen(pieceOfString),CDC0_INTFNUM,0); // Has the user pressed return yet? if (retInString(wholeString)){ if (!(strcmp(wholeString, "TEST"))) { vaderTest(); } else if(wildcardMatch(wholeString,"POSITION ?")) { parseAndSetServoPosition(wholeString[9]); } else if(wildcardMatch(wholeString,"COLOUR #???")) { parseAndSetColour(wholeString+8); } else if(wildcardMatch(wholeString,"ALL ?#???")) { parseAndSetServoPosition(wholeString[4]); parseAndSetColour(wholeString+6); // Handle other } else { // Prepare the outgoing string strcpy(outString,"\r\nNo such command!\r\n\r\n"); // Send the response over USB cdcSendDataInBackground((BYTE*)outString, strlen(outString),CDC0_INTFNUM,0); } // Clear the string in preparation for the next one for (i = 0; i < MAX_STR_LENGTH; i++){ wholeString[i] = 0x00; } } bCDCDataReceived_event = FALSE; } break; // These cases are executed while your device is disconnected from // the host (meaning, not enumerated); enumerated but suspended // by the host, or connected to a powered hub without a USB host // present. case ST_PHYS_DISCONNECTED: case ST_ENUM_SUSPENDED: case ST_PHYS_CONNECTED_NOENUM_SUSP: //Turn off LED P1.0 GPIO_setOutputLowOnPin(LED_PORT, LED_PIN); __bis_SR_register(LPM3_bits + GIE); _NOP(); break; // The default is executed for the momentary state // ST_ENUM_IN_PROGRESS. Usually, this state only last a few // seconds. Be sure not to enter LPM3 in this state; USB // communication is taking place here, and therefore the mode must // be LPM0 or active-CPU. case ST_ENUM_IN_PROGRESS: default:; } } // while(1) } // main() /* * ======== UNMI_ISR ======== */ #pragma vector = UNMI_VECTOR __interrupt VOID UNMI_ISR (VOID) { switch (__even_in_range(SYSUNIV, SYSUNIV_BUSIFG)) { case SYSUNIV_NONE: __no_operation(); break; case SYSUNIV_NMIIFG: __no_operation(); break; case SYSUNIV_OFIFG: UCS_clearFaultFlag(UCS_BASE, UCS_XT2OFFG); UCS_clearFaultFlag(UCS_BASE, UCS_DCOFFG); SFR_clearInterrupt(SFR_BASE, SFR_OSCILLATOR_FAULT_INTERRUPT); break; case SYSUNIV_ACCVIFG: __no_operation(); break; case SYSUNIV_BUSIFG: // If the CPU accesses USB memory while the USB module is // suspended, a "bus error" can occur. This generates an NMI. If // USB is automatically disconnecting in your software, set a // breakpoint here and see if execution hits it. See the // Programmer's Guide for more information. SYSBERRIV = 0; //clear bus error flag USB_disable(); //Disable } } BYTE wildcardMatch (char* string, char* match) { char s; char m; BYTE i; for (i=0; i < MAX_STR_LENGTH; i++) { s = string[i]; m = match[i]; // No match if (s != m && m != '?') return(FALSE); // Reached the end if (s == 0 || m == 0) { // of both? return (s == m); } } // Catch any overrun return (FALSE); } /* * ======== retInString ======== */ // This function returns true if there's an 0x0D character in the string; and if // so, it trims the 0x0D and anything that had followed it. BYTE retInString (char* string) { BYTE retPos = 0,i,len; char tempStr[MAX_STR_LENGTH] = ""; strncpy(tempStr,string,strlen(string)); // Make a copy of the string len = strlen(tempStr); // Find 0x0D; if not found, retPos ends up at len while ((tempStr[retPos] != 0x0A) && (tempStr[retPos] != 0x0D) && (retPos++ < len)) ; // If 0x0D was actually found... if ((retPos < len) && (tempStr[retPos] == 0x0D)){ for (i = 0; i < MAX_STR_LENGTH; i++){ // Empty the buffer string[i] = 0x00; } //...trim the input string to just before 0x0D strncpy(string,tempStr,retPos); //...and tell the calling function that we did so return ( TRUE) ; // If 0x0D was actually found... } else if ((retPos < len) && (tempStr[retPos] == 0x0A)){ // Empty the buffer for (i = 0; i < MAX_STR_LENGTH; i++){ string[i] = 0x00; } //...trim the input string to just before 0x0D strncpy(string,tempStr,retPos); //...and tell the calling function that we did so return ( TRUE) ; } else if (tempStr[retPos] == 0x0D){ for (i = 0; i < MAX_STR_LENGTH; i++){ // Empty the buffer string[i] = 0x00; } // ...trim the input string to just before 0x0D strncpy(string,tempStr,retPos); // ...and tell the calling function that we did so return ( TRUE) ; } else if (retPos < len){ for (i = 0; i < MAX_STR_LENGTH; i++){ // Empty the buffer string[i] = 0x00; } //...trim the input string to just before 0x0D strncpy(string,tempStr,retPos); //...and tell the calling function that we did so return ( TRUE) ; } return ( FALSE) ; // Otherwise, it wasn't found } /* * Switch the servo off after it's settled to stop the hum */ void setServoOffTimer(void) { // Use Timer A1 for a one-shot interrupt TA1CCTL0 = CCIE; // CCR1 interrupt enabled TA1CCR0 = 32768; // About 1s TA1CTL = TASSEL_1 + MC_1 + TACLR; // ACLK, up mode, clear TAR } // Timer0 A1 interrupt service routine #pragma vector=TIMER1_A0_VECTOR __interrupt void TIMER1_A0_ISR(void) { // Stop servo TA2CCR1 = 0; // Stop timer TA1CTL = TASSEL_0 + MC_1 + TACLR; } void parseAndSetServoPosition(char positionText) { if (positionText < '0' || positionText >'9') { stopServo(); send("\r\nArm servo off\r\n\r\n"); return; } setServo(positionText - '0'); send("\r\nArm servo position set\r\n\r\n"); } void initServo(void) { GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_P2, GPIO_PIN4); TIMER_A_clearTimerInterruptFlag(TIMER_A2_BASE); //Generate PWM - Timer runs in Up-Down mode TIMER_A_generatePWM(TIMER_A2_BASE, TIMER_A_CLOCKSOURCE_ACLK, TIMER_A_CLOCKSOURCE_DIVIDER_1, ServoPeriod, TIMER_A_CAPTURECOMPARE_REGISTER_1, TIMER_A_OUTPUTMODE_RESET_SET, 0); } void stopServo(void) { TA2CCR1 = 0; } void setServo(unsigned char position) { if (position > 9) { stopServo(); } else { TA2CCR1 = positions[position]; setServoOffTimer(); } } /* * Uses Timer A0 for 3PWM output * Chosen as these are accessible on LaunchPad * TA0.2 on P1.3 * TA0.3 on P1.4 * TA0.4 on P1.5 */ void initRgbLed(void) { P1DIR |= BIT3 + BIT4 + BIT5; // P1.3, P1.4 and P1.5 output P1SEL |= BIT3 + BIT4 + BIT5; // P1.3, P1.4 and P1.5 options select TA0CCR0 = 0xFE; // PWM Period TA0CCTL2 = OUTMOD_7; // CCR2 reset/set TA0CCR2 = 0; // CCR2 PWM duty cycle initially 0 TA0CCTL3 = OUTMOD_7; TA0CCR3 = 0; TA0CCTL4 = OUTMOD_7; TA0CCR4 = 0; TA0CTL = TASSEL_1 + MC_1 + TACLR; // ACLK, up mode, clear TAR } void setRgbLed(unsigned char red, unsigned char green, unsigned char blue) { // Set PWM registers TA0CCR2 = red; TA0CCR3 = green; TA0CCR4 = blue; } void parseAndSetColour(char* colourText) { unsigned char red = getHexDigit(colourText[0]); unsigned char green = getHexDigit(colourText[1]); unsigned char blue = getHexDigit(colourText[2]); if (red == 255 || green == 255 || blue == 255) { send("\r\nUnrecognised colour"); return; } red *= 0x11; green *= 0x11; blue *= 0x11; // Set PWM registers setRgbLed(red, green, blue); send ("\r\nColour set\r\n"); } void vaderTest() { setServo(0); unsigned char x; // red for (x=0; x < 255; x++) { setRgbLed(x, 0, 0); __delay_cycles(50000); } setServo(1); // --> yellow for (x=0; x < 255; x++) { setRgbLed(255, x, 0); __delay_cycles(50000); } setServo(2); // --> green for (x=255; x; x--) { setRgbLed(x, 255, 0); __delay_cycles(50000); } setServo(3); // --> green/blue for (x=0; x < 255; x++) { setRgbLed(0, 255, x); __delay_cycles(50000); } setServo(4); // --> blue for (x=255; x; x--) { setRgbLed(0, x, 255); __delay_cycles(50000); } setServo(5); // --> purple for (x=0; x < 255; x++) { setRgbLed(x, 0, 255); __delay_cycles(50000); } setServo(6); // --> red for (x=255; x; x--) { setRgbLed(255, 0, x); __delay_cycles(50000); } setServo(7); // --> off for (x=255; x; x--) { setRgbLed(x, 0, 0); __delay_cycles(50000); } setServo(0); setRgbLed(0,0xFF,0); __delay_cycles(5000000); setServo(9); setRgbLed(0xFF,0,0); __delay_cycles(5000000); setServo(0); setRgbLed(0,0,0); } unsigned char getHexDigit(char text) { if ((text >= '0') && (text <= '9')) return (text-'0'); if ((text >= 'A') && (text <= 'F')) return (10 + text-'A'); if ((text >= 'a') && (text <= 'f')) return (10 + text-'a'); return 255; } void send(const char* message) { /* // Holds the outgoing string char out[MAX_STR_LENGTH] = ""; // Prepare the outgoing string strcpy(out, message); // Send the response over USB cdcSendDataInBackground((BYTE*)out, strlen(out),CDC0_INTFNUM,0); */ } //Released_Version_4_00_00  
×
×
  • Create New...