Jump to content
43oh

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    gordon got a reaction from bluehash in How to use GDB with MSPDebug on Linux?   
    I do it like this:
     
    In your project directory (where your sources and binary are), have a file called .gdbinit with the following contents:

    target remote localhost:2000 monitor reset halt load
     
    On one terminal, start MSPDebug like so:

    mspdebug rf2500 gdb
    This starts up MSPDebug in GDB proxy mode -- on one end, there is a GDB server (by default on port 2000, see help gdb); on the other end, it is attached to your FET (change rf2500 to the actual FET driver you are using).
     
    On an other terminal, assuming you are in your project's directory and your binary is called main.elf, start up msp430-gdb like so:

    msp430-gdb main.elf
    I like CGDB as a friont-end to GDB, so I do

    cgdb -d msp430-gdb main.elf
     
    Much of this can be automated from your Makefiles (I have not yet figured out how to reliable handle starting and killing the GDB proxy, then again, it doesn't bother me enough to spend time on it...).
  2. Like
    gordon got a reaction from advaneharshal in LP Booster Pack Eagle footprints   
    (OK, I have no idea where to put this. BH, feel free to move it around.)
     
    Continuing from viewtopic.php?f=9&t=1348&start=40#p11369
     
    This is the final version; I don't think it can be made any better as well as generic at the same time.
     
    All variants verified against the TI LaunchPad Eagle files.
     
    Thanks to SugarAddict for the corrections.
     
    Pro tip: make your References layer yellow (or any other unused bright color) while placing your components.
     
    Addendum: DipTrace users look here: viewtopic.php?f=35&t=2972
    TI_launchpad.zip
  3. Like
    gordon got a reaction from yyrkoon in Efficient micro mathematics   
    Tripped over this by accident while watching one of Travis Goodspeed's talks:
     
    Efficient Micro Mathematics
  4. Like
    gordon got a reaction from pimmel in Makefile for MSPGCC   
    Rickta59 says this might be of interest to others, so here's the Makefile I've been using for MSPGCC.
     

    TARGETMCU ?= msp430g2211 CROSS := msp430- CC := $(CROSS)gcc CXX := $(CROSS)g++ OBJDUMP := $(CROSS)objdump SIZE := $(CROSS)size LD := $(CC) MSPDEBUG := mspdebug LDFLAGS := -mmcu=$(TARGETMCU) CFLAGS := -Os -Wall -W -Wextra -Werror -g -mmcu=$(TARGETMCU) ifneq ($(WITH_CXX),) CC := $(CXX) LD := $(CC) endif ifneq ($(DEBUG),) ifeq ($(WITH_CXX),) CFLAGS += -Wstrict-prototypes -Wmissing-prototypes -Wbad-function-cast CFLAGS += -Werror-implicit-function-declaration -Wdeclaration-after-statement CFLAGS += -Wnested-externs -Wold-style-definition CFLAGS += -finline-functions endif CFLAGS += -Wmissing-declarations -Winit-self -Winline -Wredundant-decls CFLAGS += -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -Wformat=2 CFLAGS += -Wfloat-equal -Wmissing-field-initializers CFLAGS += -Wmissing-include-dirs -Wswitch-default -Wpacked CFLAGS += -Wpacked -Wlarger-than-65500 -Wunknown-pragmas CFLAGS += -Wmissing-format-attribute -Wmissing-noreturn CFLAGS += -Wstrict-aliasing=2 -Wswitch-enum -Wundef -Wunreachable-code CFLAGS += -Wunsafe-loop-optimizations -Wwrite-strings -Wcast-align CFLAGS += -Wformat-nonliteral -Wformat-security -Waggregate-return CFLAGS += -fno-common -Wp,-D_FORTIFY_SOURCE=2 endif SRCS := main.c PROG := $(firstword $(SRCS:.c=)) OBJS := $(SRCS:.c=.o) all: $(PROG).elf $(PROG).lst $(PROG).elf: $(OBJS) $(LD) $(LDFLAGS) -o $(PROG).elf $(OBJS) %.o: %.c $(CC) $(CFLAGS) -c $< %.lst: %.elf $(OBJDUMP) -DS $< > $@ $(SIZE) $< clean: -rm -f $(PROG).elf $(PROG).lst $(OBJS) install: $(PROG).elf $(MSPDEBUG) -n rf2500 "prog $(PROG).elf"
     
    I don't know what half of the CFLAGs mean anymore (some of them most likely don't even have any real meaning in the MSP430 context), I have collected them during the years, the result is considerably anal about code quality, though.
     
    roxfan notes,
     
    Well, I got used to objdump's output, that's about it.
     
    It's GNU make, don't even try with others, really. Also don't forget to expand spaces to tabs.
  5. Like
    gordon reacted to oPossum in [S]IV-18 VFD Clock Booster Pack   
    Got a few inductors from cubeberg and tested them:
     

    Small 67 uH 0.23 Q 1.94 DCR Large 1 64 uH 0.38 Q 1.34 DCR Large 2 63 uH 0.34 Q 1.30 DCR
     
    So they are all the value that is marked. The problem must be saturation due to the small core size.
  6. Like
    gordon got a reaction from jsolarski in Welcome!   
    Just remember... no killy jsolarski... no killy jsolarski... again...
  7. Like
    gordon got a reaction from Jack Caster in A simple shell, step by step [eZ430 - RF5000]   
    This is opening up a whole can of worms you unlikely to want open.
     
    The terminal emulator will send codes according to what it's been configured as -- let's, for simplicity's sake, assume that it is VT100.
     
    To make sense of this, you will need to write a parser for the VT100 terminal codes (multi-byte and traditionally timing-dependant things). Useful to have indeed, but not something I'd want to write for the '2553 .
     
    http://vt100.net/ will get you started.
  8. Like
    gordon reacted to cde in Dumbing the interface down?   
    On the very bottom footer, there is a mark community read option. Use that on the forum index page, everything will be cleared out. As for Active Topics, new content with the "last week" filters is essentially the same thing.

    http://forum.43oh.com/index.php?app=core&module=search&do=viewNewContent&search_app=forums&period=week
  9. Like
    gordon got a reaction from bluehash in Need a challenge question that a visitor may know, to keep off spam   
    ... and make an array of three radio buttons to choose from: Microchip, Atmel, Renesas.
     
    Those who complain, pass.
     

  10. Like
    gordon got a reaction from rebeltaz in Code Composer Studio on Linux? no USB FET...   
    You can use MSPDebug (I think it can be integrated into CCS, but if not, you can use it separately). No USB FET support in Linux CCS, this fact is noted (I was going to say "prominently" but now I can't find it, so perhaps not that prominently ) in the release notes. Or on the TI wiki. Or someplace else. Anyway, case in point, no TI support, yes MSPDebug support.
  11. Like
    gordon got a reaction from retnuH in Problem with interrupts on P1 and a timer   
    This was working a couple of days back... Load on a LaunchPad, poke button. Scratch that, I didn't notice the Energia part. You could still adapt, though.
     

    #include #include #include #define LED BIT6 #define BUTTON BIT3 #define DEBUG #undef DEBUG #ifdef DEBUG #define DEBUGLED BIT0 #endif void __attribute__((interrupt (PORT1_VECTOR))) port1_isr(void); void __attribute__((interrupt (WDT_VECTOR))) wdt_isr(void); #define PWM_PERIOD 128 static const uint16_t brightness_levels[] = { 0, 6, 23, 56, PWM_PERIOD }; #define n_brightness_levels ( sizeof( brightness_levels ) / sizeof( brightness_levels[0] ) ) static volatile uint8_t cur_brightness = 0; static volatile uint8_t debounce_ctr = 0; /* /3 -- WDT_ADLY_250 assumes LFXTCLK @ 32KiHz, VLO is ~12KHz */ #define POWEROFF_TIMER (2400 / 3) /* 10m @ 250ms */ #if 0 #undef POWEROFF_TIMER #define POWEROFF_TIMER (40 / 3) /* TEST: 10 seconds */ #endif static volatile uint32_t poweroff_timer = POWEROFF_TIMER; static volatile bool poweroff = false; void main(void) { WDTCTL = WDT_ADLY_250; /* 750ms if running on VLO */ BCSCTL2 |= SELM_3 | SELS; /* MCLK to LFXTCLK, SMCLK to LFXTCLK */ BCSCTL3 |= LFXT1S_2; /* LFXT1 to VLO */ IE1 |= WDTIE; IFG1 &= ~WDTIFG; P1DIR |= LED; CCR0 = PWM_PERIOD; CCTL1 = OUTMOD_7; TACTL = TASSEL_1; P1DIR &= ~BUTTON; P1IE |= BUTTON; P1REN |= BUTTON; P1IFG &= ~BUTTON; P1OUT |= BUTTON; #ifdef DEBUG P1DIR |= DEBUGLED; P1OUT &= ~DEBUGLED; #endif __eint(); while( 1 ) { if( poweroff || cur_brightness == 0 ) { TACTL |= MC_0; CCR1 = 0; P1SEL &= ~LED; P1OUT &= ~LED; __bis_status_register( debounce_ctr == 0 ? LPM4_bits : LPM3_bits ); } else { TACTL |= MC_0; if( cur_brightness == n_brightness_levels - 1 ) { P1SEL &= ~LED; P1OUT |= LED; } else { P1SEL |= LED; CCR1 = brightness_levels[ cur_brightness ]; TACTL |= MC_1; } __bis_status_register( LPM3_bits ); } } WDTCTL = 0xDEAD; } void __attribute__((interrupt (PORT1_VECTOR))) port1_isr(void) { P1IE &= ~BUTTON; debounce_ctr = 1; if( !poweroff && ( ++cur_brightness >= n_brightness_levels ) ) { cur_brightness = 0; } poweroff_timer = 0; poweroff = false; P1IFG &= ~BUTTON; __bic_status_register_on_exit( LPM4_bits ); } void __attribute__((interrupt (WDT_VECTOR))) wdt_isr(void) { #ifdef DEBUG P1OUT ^= DEBUGLED; #endif /* Decrement debounce_ctr iff > 0, else WDT timer will keep * it on for one more loop, causing a delay in poweroff */ if( debounce_ctr > 0 && --debounce_ctr == 0 ) { P1IFG &= ~BUTTON; P1IE |= BUTTON; } if( ++poweroff_timer == POWEROFF_TIMER ) { poweroff = true; } IFG1 &= ~WDTIFG; __bic_status_register_on_exit( LPM4_bits ); }
  12. Like
    gordon reacted to oPossum in [Group Buy-7]IV-18 VFD Clock - $20   
    To estimate switch and inductor current:
     
    (Output Voltage / Input Voltage) * Output Current * 2
     
    That will give a reasonable derated value.
     
    The size of the inductor does not determine the current - the core material and wire does.
  13. Like
    gordon reacted to abecedarian in Magnetic rotary position sensors   
    I posted this on stellarisity.com too.
     
    In the quest to find a way to add crankshaft position sensing (more accurately, crankshaft position changes- the ECU would interpolate the position) to my EFI project (on stellerisity), I came across this:
    http://www.ams.com/e...osition-Sensors
    Put a bi-polar magnet on the end of a shaft, mount a chip close enough to the magnet and spin the shaft.
    Various ones output sine/cosine, absolute position, incremental pulses (one pulse per X degree), and PWM.
     
    If you find one (or two or three) you like, they offer samples of many of their products. I may have been lucky since I have a company-related email address and used that so I can't say any email address could be used, but who knows?
     
    On Oct. 20, I requested these:
    AS5140H-ASSU - up to 10,000 rpm per datasheet
    AS5232-HSST - up to 72,900 rpm per datasheet
    AS5048B-HTSB - no mention of rpm on datasheet but I imagine that'd be left to sampling the output waveforms and interpolating.
    ... and had a confirmation email the next day the order was accepted and another email Oct. 22 they were shipped FedEx from Vienna, Austria, no charge. They were supposed to arrive at my house on the 24'th but apparently FedEx is scared if someone is working on the roof of your home.
     
     
    Good luck.
  14. Like
    gordon reacted to RobG in 2.2" Color LCD Booster Pack with Touch   
    Looks like the controller chip might not be necessary. Software touch works pretty good, just needs some filtering.
    The only thing, software touch uses P1.1-P1.4 and P2.1, so forget about UART. Hardware touch uses P1.4, P2.0, and P2.2.
     


  15. Like
    gordon reacted to JWoodrell in first PCB back from fab and semi-populated :)   
    well I am proud of this so I wanted to show it off, even though I don't have all the bits to make it functional yet (and the Army is kicking me to a month long training thing on Thursday so it will have to wait till I get back...
     
    but anyway, I had my little USB prototype V1.2 sent to a fab place (Osh Park) and they had them done and to me yesterday, even though I ordered them a week and a half later than the seeed ones (still waiting on them)... I ordered these on the 4th, and got them on the 22nd, oh and it only cost me $5.00 per square inch of board (you get 3 copies of the board) mine are smaller than a square inch so I only paid $3.10 to have these made
     
    anyway, so this is my first PCB, and my first attempt at re-flow soldering, the YZP, and YZV parts are ridiculously tiny, but i got them placed and they stuck properly. (4 point ball grid array, and 6 point BGA, .5mm pitch, the overall chip is only 1mm square, or 1 x 1.5mm for the YZP...
     
    anyway here is what it looks like, I know there is a bridge on the 6 legged chip, I am not sure if I used too much solder paste, or not enough to generate the tension to pull that down?... but I can fix that by hand pretty easy



     
    code wise I am pretty close to being able to receive properly. I have it syncing correctly, and am working on the NRZI and bit destuffing code (in a month when I get back from training)
  16. Like
    gordon reacted to pabigot in USB dev (CCS code to GCC) issues   
    FWIW, DMA0DA and DMA0SA are declared so that the compiler knows they're 20-bit values (at least if you're using the mspgcc that's 20-bit aware). No particular cast should be necessary for mspgcc. In fact passing the value through (unsigned long) might result in an unnecessary (and very expensive) up-cast to a 32-bit value before truncating back down to the 20-bit value that will be stored.
     
    See also http://sourceforge.net/apps/mediawiki/m ... te___a20__
  17. Like
    gordon got a reaction from Nytblade in Better MSPDebug integration   
    Fresh find: http://mspdebug.git.sourceforge.net/git ... 94b110f07e
     
    ...and a group bow towards Daniel's general direction!
  18. Like
    gordon reacted to pabigot in Different Duty Cycle Clocks   
    And viewtopic.php?f=10&t=2274, just for completeness. The referenced bug in mspgcc has long been fixed.
  19. Like
    gordon reacted to pabigot in Over-engineered PWM solution   
    I'm a little reluctant to post this since I'm not sure how useful it will be, but I'm done working on it for now so what the heck.
     
    Inspired by opossum's PWM code, I decided to design a similar system based on my own needs, which would involve indicating subsystem states by the duration of LED flashes.
     
    I was also motivated to try this because I report most of the bugs against mspgcc, and projects like this tend to find them. This one revealed a bug I'd fixed in November wasn't quite as dead as I'd thought.
     
    Below is the header from the module. The complete source is in the test430 git repository under the demos/launchpad/pwm directory. It includes a unit test to verify manipulation of the data structures, and a demonstration application using an MSP430G2553-loaded launchpad that configures several PWMs (including the LEDs) and allows the user to validate them by cross-connecting the outputs to TA1.0 configured in capture mode. The demonstration allows the overall period and the source clock to be configured at build-time.
     
    I do not intend to make any real comparison of this against other PWM implementations; it was simply an exercise. However, as people are likely to be interested:
     
    * This probably takes more code space than opossum's version, because I wanted extra features including the ability to use a period other than 65536, and a callback at the end of the cycle (for potential synchronous reconfiguration of the widths). This one takes 882 bytes for the ISR and the support routines.
     
    * Although the technique could reduce RAM size too as no pointers are needed, I don't know if this demonstration does, since I'm using a full 16 bits for the widths. RAM size could be reduced by changing pwm_period_t to an 8-bit value and adding a scaling shift.
     
    * The code not only requires the development version of mspgcc to run, but the unit test evokes a bug for which the fix has not yet been pushed. (The test runs correctly, but after exiting improperly restarts itself at which point it appears to fail.)
     
    * Take this as an example: there are too many design decisions in something like this for it to be generally usable.
     
    Students of software development might find it interesting to read through the git logs to see how the project evolved.
     
    An example of output from the demonstration program:

    Connect to P2.0 to measure pulses based on ACLK: P1.0 PWM 2500 of 10000 cycles P1.3 PWM 100 of 10000 cycles P1.4 PWM 200 of 10000 cycles P1.5 PWM 1000 of 10000 cycles P1.6 PWM 7500 of 10000 cycles PWM at 3 of 9, cb 0xc3fe 0: mask=0079 dwell=100 ; total 100 1: mask=0008 dwell=100 ; total 200 2: mask=0010 dwell=800 ; total 1000 3: mask=0020 dwell=1500 ; total 2500 4: mask=0001 dwell=5000 ; total 7500 5: mask=0040 dwell=2500 ; total 10000 6: mask=0000 dwell=0 ; total 10000 7: mask=0000 dwell=0 ; total 10000 8: mask=0000 dwell=0 ; total 10000 Callback 4424 with pwm 0x218, last cycle duration 10000 3 captures: CCTL 0000 CCR 2382 TA1R 2ac9 high for 201 cycles low for 9799 cycles
     
    The header, including the vision document/rationale:

    #ifndef _PWM_H_ #define _PWM_H_ /* Copyright (c) 2012, Peter A. Bigot 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 the software 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 HOLDER 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. */ /** Inspired by http://www.43oh.com/forum/viewtopic.php?f=10&t=2260 * * This module provides pulse-width-modulation capability using a * single capture-compare-register (CCR) of a pre-configured timer. * The following assumptions are made: * * + A timer is externally configured in continuous mode with some * source. The PWM infrastructure must not interfere with other * uses of the timer. To simplify satisfying this requirement, it * is assumed that the PWM owns the CCR0 register of the timer along * with its dedicated interrupt vector. This assumption could be * removed by converting the hard interrupt handler to a function * invoked from an external source. * * + The cycle of the PWM is the complete sequence stages, where the * first stage enables all active pins and subsequent stages disable * them. The duration of a PWM cycle is the PWM period, which is * the number of underlying timer ticks within which individual * pulse widths vary. The period is configured when the PWM is * reset. * * + The pulse widths may be reconfigured frequently during execution * of the application so that a static machine transition array is * not appropriate, but not so frequently that changes impact the * execution of the transitions. * * + Changes in pulse width take effect at the start of the following * period. * * + The clock source and pulse width timing must not be so tight that * the CCR handler cannot complete its work before the next state * change. The caller is responsible for ensuring this. * * + The application is responsible for configuring PxDIR and PxSEL * for the pins to be used. * * + The PWM should be friendly to low-power-mode applications. * * + To support the potential for multiple PWMs driven by different * interrupts, the PWM state is encapsulated in a structure, but the * current implementation retains an internal reference to that * structure while the PWM is active so it can be located from the * CCR handler interrupt. */ #include /* Forward declaration */ struct pwm_t; /** Number of pins supported by the PWM. This must be consistent with * the pwm_pinbit_t typedef. */ #define PWM_PIN_COUNT 8 /** Type used to represent zero or more PWM pins as a bit mask. This * must be consistent with PWM_PIN_COUNT. */ typedef unsigned char pwm_pinbit_t; /** Type used to represent the period of the PWM, or the width of a * pin controlled by the PWM. */ typedef unsigned int pwm_period_t; /** Type used to define a callback executed from the timer interrupt * at period rollovers. * * @note The function is invoked from the CCR interrupt handler. To * reduce glitches, active pins are set before the callback is * enabled. Be aware of the implications of this in terms of glitches * that might occur if the pins are reconfigured by the callback. * * @param pwm the PWM configuration associated with the CCR handler. * * @return The callback should return a nonzero value if the timer * interrupt should exit low-power mode on return */ typedef int (* pwm_callback_fn) (struct pwm_t* pwm); /** Configuration and state used by the PWM infrastructure. * * The PWM begins a cycle by turning on all active pins. It then sets * the CCR to be woken at the appropriate time to disable the pin(s) * with the shortest width. */ typedef struct pwm_t { /** An optional callback to be invoked prior to starting the next * cycle. The value is not affected by pwm_reset(). */ pwm_callback_fn post_cycle_callback; /** The index into the ccr_delta and pin_mask array for the next * stage to execute. Initialized by pwm_release(), value ranges * from 0 to PWM_PIN_COUNT+1. A value of zero is transient, * occurring only during the CCR handler; the value of * PWM_PIN_COUNT+1 indicates the last stage of the cycle is in * progress. */ uint8_t stage_index; /** Delta between wake-ups to change the pulse width. * * A value of zero denotes a cell that is not in use. All unused * cells are placed at the end of the array. Note that if all pins * are active there are no unused cells. * * Used cells begin with the first element. The sum of the values * of used cells must equal the period of the PWM. */ pwm_period_t ccr_delta[PWM_PIN_COUNT+1]; /** Bits denoting pins to be changed at the corresponding stage. * * For the first stage (executed at the start of the cycle), the * corresponding pins will be set. For subsequent stages, the * corresponding pins will be cleared. */ pwm_pinbit_t pin_mask[PWM_PIN_COUNT+1]; } pwm_t; /** Return the duration of a PWM cycle in ticks of the underlying clock. */ pwm_period_t pwm_period (const pwm_t *pwm); /** Reset a PWM * * If the PWM is currently associated with the CCR handler, the * previously active pins are cleared and the pwm is dissociated from * the handler. * * The PWM internal state is cleared: no pins are enabled, and the PWM * itself remains disabled until pwm_release() is invoked to start it * running. * * @param pwm the PWM configuration to be cleared. * * @param period the period for PWM activities. A zero value may be * used when the PWM is being disabled permanently. * * @param post_cycle_callback an optional callback to be invoked from * the CCR handler at the end of each cycle. Pass a null pointer if * no callback is required. * * @return * @li -EINVAL if the pwm is invalid ; * @li 0 in the normal case */ int pwm_reset (pwm_t *pwm, pwm_period_t period, pwm_callback_fn post_cycle_callback); /** Start a configure PWM running. * * @param pwm the PWM to start. A reference to this structure will be * retained by the PWM internal state, so it must remain valid as long * as the PWM is active. * * @note Start of a PWM is effected by simulating the completion of a * cycle, causing the CCR handler to execute the corresponding restart * code including an invocation of pwm->post_cycle_callback. If * pwm_release() is invoked while interrupts are disabled, the start * will not occur until they are enabled, which may result in bad * output widths for the first period. * * @return * @li -EINVAL if the pwm is not invalid ; * @li -EBUSY if the timer interrupt is already associated with * another PWM instance ; * @li -EALREADY if the pwm is already running * @li 0 if the pwm is successfully released */ int pwm_release (pwm_t *pwm); /** Read the set of active pins managed by the PWM. */ pwm_pinbit_t pwm_active_pins (const pwm_t *pwm); /** Change the configuration for a pin within the PWM. * * @note This routine does not update PxDIR and PxSEL as pins are * enabled and disabled. Only PxOUT is controlled by the PWM. * * @note It is safe to invoke this while the PWM is running. Changes * will take effect at the start of the following cycle. * * @param pwm the PWM state * * @param pin the pin to be changed, as an index from 0 to PWM_PIN_COUNT-1. * * @param the new width for the pin. A positive value causes the pin * to be on for width ticks after the start of the period; if the * value meets or exceeds the PWM period, the pin is never turned off * by the PWM, but is turned on at the start of each cycle. A zero * value removes the pin from PWM management. * * @return * @li -EINVAL if the pwm or pin parameters are invalid. * @li 0 if the pin is no longer managed by the PWM. * @li 1 if the pin remains managed by the PWM. */ int pwm_configure_pin (pwm_t *pwm, unsigned int pin, pwm_period_t width); #endif /* _PWM_H_ */
  20. Like
    gordon got a reaction from xpg in Better MSPDebug integration   
    Fresh find: http://mspdebug.git.sourceforge.net/git ... 94b110f07e
     
    ...and a group bow towards Daniel's general direction!
  21. Like
    gordon got a reaction from bluehash in MS430G2452 REV1.5 Issues   
    P1REN |= BUTTON;
    Also, make blink volatile.
  22. Like
    gordon got a reaction from bluehash in Posted by in "Forum Recent Topics"   
    I mean search.php?search_id=active_topics
  23. Like
    gordon got a reaction from jsolarski-backup in Hello guys   
    viewtopic.php?f=8&t=449
  24. Like
    gordon got a reaction from ZelAlex in Hello guys   
    viewtopic.php?f=8&t=449
  25. Like
    gordon reacted to spirilis in [S]Nordic nRF24L01+ RF BoosterPack   
    Now available in the 43oh Store.
     
    Anyone interested in such a beast? The modules are available dirty cheap on ebay, less than $3/module for the cheap PCB antenna trace versions...

    They run in the 2.4GHz ISM band at 250Kbps, 1Mbps or 2Mbps with configurable transmit power (-18, -12, -6, 0dBm) and 125 available channels, and the chip has on-board protocol support so that the MCU utilizing it can think in terms of <=32-byte packets with 3, 4 or 5-byte addresses, and it handles all the OTA stuff including CRC checking and auto-acknowledgement. The chip communicates over SPI, maximum 10MHz. I've written a library for the MSP430 value line here: https://github.com/spirilis/msprf24
    Wiki documentation for the library here: https://github.com/s...is/msprf24/wiki


    Anyway for my current project (grill/smoker thermocouple monitor) I've designed a BoosterPack that is meant for a base station; it includes the 8-pin rectangular pinout used by most of the cheap modules on ebay (ITead Studios carries modules with this same pinout -- http://imall.iteadst...m120606002.html -- although FYI the current/RF power specs listed are wrong on that page) and an FTDI cable pinout for using a 3.3V-level FTDI cable for faster serial I/O. If there is interest I might design one that is more general-purpose and look to get it produced.

    The pinout requires the use of 3 GPIO lines in addition to the SPI lines, one interruptable (the IRQ line) so it can be used with LPM modes.

    The boosterpack I created for this project looks like this (for MSP430G2553 fyi):
    (top)

    (bottom)

    This particular board includes support for an LM2936 LDO (3.3V 50mA) so the base station can be supported by a single USB connection (the FTDI cable, which provides 5V Vcc...) although while this supports most nRF24 boards with PCB trace or WiFi-style RP-SMA antennas, it wouldn't support the amplified board ITead carries since that can draw upwards of 115mA during TX. So I'd redesign that if interest for the FTDI pinout feature is high. Then again there's a thread around here about tricking the LP's TUSB chip into running at higher speeds so FTDI support might not be necessary.

    Another idea that might make more sense is a boosterpack that places the nRF24 pinout further out to the right or bottom of the LP headers, so it's stackable and lets you add nRF24L01+ support to your project while putting an LCD or touchscreen on top. PCB cost goes up with surface area though.
×
×
  • Create New...