Jump to content
43oh

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    gordon got a reaction from nuetron in Converting a 3-Digit Number to Characters for a LCD Display   
    Slightly uh, no. This will take a pointer to a char array; you probably mean the right thing, but string[4] is very bad parlance, because
     
     
    Very uh, no . blah[4] is one single char, the last element in something that was presumably declared as char blah[4]; basically, this passes literally one byte worth of storage to the function to work with; to the function that doesn't check its arguments (which might, might be explainable in a constrained environment but also means you have to be very, very, very careful not to make these kinds of mistakes) and will happily overwrite whatever is next to this in memory.
  2. Like
    gordon got a reaction from RobG in [ ENDED ] Aug-Sep 2011 - 43oh Project of the Month Contest   
    Just call it "every time I press one of these black controls, labelled in black on a black background, a little black light lights up black to let me know I've done it." (with deep apologies to DNA) .
     
    I for one am strongly of the opinion that software-only projects are no lesser of a project than things that involve hardware, and would definitely like to see this entered the POTM.
  3. Like
    gordon got a reaction from nuetron in [ ENDED ] Aug-Sep 2011 - 43oh Project of the Month Contest   
    Just call it "every time I press one of these black controls, labelled in black on a black background, a little black light lights up black to let me know I've done it." (with deep apologies to DNA) .
     
    I for one am strongly of the opinion that software-only projects are no lesser of a project than things that involve hardware, and would definitely like to see this entered the POTM.
  4. Like
    gordon got a reaction from bluehash in RGB driver?   
    I have used the MAX6957 (SPI; I2C version is MAX6956, haven't used it myself). Found it a bit awkward at first, but generally made peace with it.
     
    There's also the TLC5940/TLC5945 you'll find plenty examples of around here (though these are not available in DIP, i think; the Maxims are).
  5. Like
    gordon got a reaction from bluehash in UART and compiling errors   
    The One Book.
  6. Like
    gordon reacted to Rickta59 in Full-duplex software UART for launchpad   
    So this code snippet springs forth from my desire to use a terminal emulator ( I like putty best ) with my launchpad via the built-in COM port. Simple I think, someone must have already done this by now, no? Well, trying to find a working example for the launchpad led me down a lot of dead ends with nothing that worked well. I did find examples that were half-duplex and ones that required more Timer features than you find on the msp430g2231. Unfortunately, none of them fit my requirements.
     
    My goal was to find something that would allow me to use higher DCO clock speeds such as 16MHZ. I also wanted to be able to run reliably with 115k baud rates, so that I can connect a serial to TCP proxy and make my launchpad web enabled.
     
    I've implemented something here that meets both of those goals. Well sort of. I discovered that the COM port on the launchpad will only work up to 9600 baud. However, you can disconnect the jumpers and plug your RX/TX lines into an FT232RL device and get higher speeds. It also works well if your goal is to interface to some other device via TTL level RS232, say a GPS device.
     
    You can find the code here:
     
    https://github.com/RickKimball/msp430softserial
     
    Because everything is better with pictures, I took a snapshot of the RX line receiving the character 'U' at 9600 baud. 'U' is unique in that it forms a perfect clock wave 0 10101010 1 when you add the stop and start bits. The green line is the RX line, the red line is me toggling a debug pin inside of the RX ISR routine. I used a program called Soundcard Oscilloscope that helped me dial in the proper timing so that I was sampling in the center of each data bit. http://www.zeitnitz.de/Christian/scope_en
     

     
    In the picture above, you'll notice that the first red crossing takes longer than the other samplings, that is because we just ignore the value of the start bit and start sampling in the center of the first data bit.
     
    To use and test the code, download it from github and bring it into CCS. Once it is running figure out which COM port your launchpad is using and connect to it with a terminal emulator like putty or minicom using 9600 baud. The default configuration expects you to have soldered a 32.768k crystal to the launchpad board. It uses the crystal to calibrate the DCO for a higher MHZ speed. Don't worry, I don't write it to flash, I just calibrate it and use it. However, you can edit the config.h to modify the baud rate and MCLK speed. You can even run it at the default MCLK speed. See the config.h file comments for more information.
     
    I think I've commented the code fairly well. However, this is actually my first published project with the MSP430 launchpad so comments are welcome. So enjoy!
     
    -rick
  7. Like
    gordon got a reaction from gwdeveloper in OpenSource or Free 8051 compiler?   
    My general first choice would be SDCC.
     
    There are a couple of links on 8051projects, but interestingly, (free) C compilers don't seem to be growing on trees .
  8. Like
    gordon got a reaction from bluehash in Setting up PWM on launchpad   
    Take a quick peek at [tipdf]SLAU144[/tipdf] section 12.2.5.113.2.5.1.
  9. Like
    gordon reacted to bluehash in LS Research zigbee?   
    Hello Kenemon,
    I'm willing to sponsor a batch of 10PCBs from Seeed, otherwise what good are the adverts. Currently Hyland Savior is also trying to make one here which will also be getting sponsored. That is for the chip itself, whereas this one uses the LS Research. Both are good to have in my opinion.
     
    If you are interested, let me know.
  10. Like
    gordon reacted to xmob in Camera Intervalometer   
    Hello all
     
    This is my first MSP430 project. I'm an AVR person, but I'm trying to switch to MSP430 because TI really seem to be trying with some excellent support and a brilliant product line up. That, and I also seem to have Launchpads taking over my den.
     
    Anyway, this originally started out as a simple IR based shutter remote for Nikon cameras. I then upgraded it to an intervalometer. I then added 7 segment displays.
     
    I built it using the "build then do schematics later" method. I'll get some schematics drawn up and tidy the code. Once that's done, I'll publish it all here.
     
    Currently:


    MSP430G2231
    IR LED driven by 2N2222 transistor
    2 x 7 segment displays driven by 2 74HC595 shift registers
    Has shutter override so the external trigger sources can be implemented (lightning detector etc)

     
    To do:


    Add extra input to configure shutter interval without doing it in code
    Support more cameras
    Shutter control using Chronos (hmmm :think: )
    Anything else I might think of

     
    Sorry about the quality of the video. I filmed it with a Sony Bloggie which is great for outdoor stuff but useless inside.



  11. Like
    gordon got a reaction from gwdeveloper in Question about Structs and Pointers   
    Grouping the four floats into a struct and transmitting that in one go is OK. The following (with some pseudocode sprinkled in, since i do not know SimpliciTI)
     

    struct sensors_struct { float thermistor; float relativeHumidity; float gyroRoll; float gyroPitch; }; sensors_struct sensor; sensor.thermistor = ReadThermistor(); sensor.relativeHumidity = ReadHumidity(); sensor.gyroRoll = ReadRoll(); sensor.gyroPitch = ReadPitch(); Transmit(&sensor, sizeof(sensor));
    will do just that.
    Yes. It is basically a shorthand for

    struct sensors_struct { float thermistor; float relativeHumidity; float gyroRoll; float gyroPitch; }; struct sensors_struct sensor_data[16];
  12. Like
    gordon got a reaction from smiffy in msp430-gcc: delay loops optimised out   
    Quickstart: viewtopic.php?f=5&t=1402#p9193. I am standing by my earlier opinion that if your OS has Uniarch packages, use those, if it doesn't, poke the vendor to have them. In the meantime, you can use the script attached there (check for patches that might have appeared since), or a number of other Uniarch build scripts/instructions floating around even in this forum.
     
    There's a SF wiki page too for a bit of a background information and whatnot.
  13. Like
    gordon got a reaction from oPossum in Low Power Mode Help? :)   
    This is supposed wake up about every 16 seconds alrite.
     
    Put two LEDs to two pins, toggle one from the timer interrupt and the other from the sleep loop, let's see what happens.
     
    Here's the reduced example of what you should be doing (for the LaunchPad and a 'g2553 as I only have this on me at the moment):
     

    #include void __attribute__((interrupt (TIMER0_A0_VECTOR))) t_isr(void); int main(void) { WDTCTL = WDTPW | WDTHOLD; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; BCSCTL2 = SELM_0 | DIVS_0; BCSCTL3 |= LFXT1S0; P1DIR |= BIT0|BIT6; P1OUT &= ~(BIT0|BIT6); TACTL |= TACLR; TACTL = TASSEL_1 | MC_1 | ID_3; TACCR0 = 65535; TACCTL0 |= CCIE; while(1) { P1OUT ^= BIT6; __bis_status_register(LPM3_bits|GIE); } } void __attribute__((interrupt (TIMER0_A0_VECTOR))) t_isr(void) { P1OUT ^= BIT0; __bic_status_register_on_exit(LPM3_bits); }
     
    Adapt this to your hardware and to IAR. Also, when I say this is what you should try, I mean this is what you should try. Throw out the rest of your app, start the bare minimum, and work your way up to when it fails.
     
    With this, until you get the two LEDs blinking at about 1/32 Hz in opposite phase, you have a hardware problem.
  14. Like
    gordon got a reaction from Butterfly13078 in Low Power Mode Help? :)   
    This is supposed wake up about every 16 seconds alrite.
     
    Put two LEDs to two pins, toggle one from the timer interrupt and the other from the sleep loop, let's see what happens.
     
    Here's the reduced example of what you should be doing (for the LaunchPad and a 'g2553 as I only have this on me at the moment):
     

    #include void __attribute__((interrupt (TIMER0_A0_VECTOR))) t_isr(void); int main(void) { WDTCTL = WDTPW | WDTHOLD; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; BCSCTL2 = SELM_0 | DIVS_0; BCSCTL3 |= LFXT1S0; P1DIR |= BIT0|BIT6; P1OUT &= ~(BIT0|BIT6); TACTL |= TACLR; TACTL = TASSEL_1 | MC_1 | ID_3; TACCR0 = 65535; TACCTL0 |= CCIE; while(1) { P1OUT ^= BIT6; __bis_status_register(LPM3_bits|GIE); } } void __attribute__((interrupt (TIMER0_A0_VECTOR))) t_isr(void) { P1OUT ^= BIT0; __bic_status_register_on_exit(LPM3_bits); }
     
    Adapt this to your hardware and to IAR. Also, when I say this is what you should try, I mean this is what you should try. Throw out the rest of your app, start the bare minimum, and work your way up to when it fails.
     
    With this, until you get the two LEDs blinking at about 1/32 Hz in opposite phase, you have a hardware problem.
  15. Like
    gordon got a reaction from Butterfly13078 in Low Power Mode Help? :)   
    That way it should be sleeping and waking up regularly. However, I think 5000 counts are low enough so that basically what you are measuring is an average current consumption as the wake-ups are frequent (though I have not looked up default clock settings for this part).
     
    If you just want to measure current for LPM3, the simplest way to enter it is

    int main() { __disable_interrupts(); _BIS_SR(LPM3_bits); }
    This is guaranteed to be asleep indefinitely, regardless of, err, anything.
  16. Like
    gordon got a reaction from Butterfly13078 in Low Power Mode Help? :)   
    It doesn't loop as such, it restarts (probably -- behavior on falling out of main() seems to be compiler-dependent).
     
    Start with this:

    int main() { /* Do other work here */ TACTL = TASSEL_1 + MC_2 + TACLR + ID_3; //Switch to ACLK, prescaler = 8, reset clock WDTCTL = WDTPW + WDTHOLD; // Stop WDT TACCTL0 = CCIE; //interrupt enabled TACCR0 = 5000; while(1) { _BIS_SR(LPM3_bits|GIE); } } #pragma vector=TIMERA0_VECTOR __interrupt void Timer_A (void) { _BIC_SR_IRQ(LPM3_bits); // Clear LPM3 bits }
    (I hope this is the correct IAR syntax.)
  17. Like
    gordon got a reaction from smiffy in msp430afe253 TSSOP on a Schmartboard   
    Try the attached diff (against mspdebug git master HEAD).
     
    If it still doesn't work (properly), do as advised sniffing the USB traffic on Windows with CCS or IAR, then send the results in to Daniel.
    msp430afe253.diff.gz
  18. Like
    gordon got a reaction from Rickta59 in How to install/use mspgcc   
    You are best off using packages provided by your OS. If they don't have any, poke them with a stick until they do.
     
    That said, attached is the script I use for building MSPGCC myself. It is known to work on Linux and FreeBSD (with considerably good chances of working on other BSDs as well). You need to figure out and install the dependencies yourself (look at the top of the script -- they will be numerous), I am not able to help with that in any way, shape or form (can't be familiar with every *x incarnation around, nor want to be).
     
    This may sound inappropriate or even rude, but I really, really, really would like to avoid a backlash of "but it doesn't work". Building the GNU toolchain is (can be) tricky with lots of (direct and indirect) dependencies and hidden traps. I am not in the position to try and debug anyone's particular system through this. This script has been in use for quite a while now, and it does work. If it doesn't work for you, it's 99.99% because of a missing dependency, not a script problem. If you feel uncomfortable with this (which would be quite understandable), poke your OS vendor to build and package the MSP430 toolchain for you. At the very least FreeBSD, Ubuntu, Debian, OpenBSD and Arch have Uniarch by now, so it's not like uncharted territory for anyone.
     
    Edit: thanks to the incredibly utter stupidity the FSF people handled some license-violation-or-whatnot in their products, the script no longer works as-is, and I will not fix it up. YHBW.
    build-mspgcc.gz
  19. Like
    gordon reacted to RobG in TI MSP430 Family Eagle library   
    I was little annoyed by the existing MSP430 libraries so I decided to modify them and create my own.
    Here's my first version of it. Let me know what you think.

    Updated May 7 2012
    Added 2210 & 2230

    Updated May 16 2012
    Added FR5739 (TSSOP 38)

    Updated June 20 2012
    Fixed two 14 pin devices. Pin 8 was assigned to pin 10 and vice versa.
    Affected devices: MSP430G2X31-14PW14 and MSP430G2X21-14PW14
     
    Updated March 26 2013
    Added:
    G2x55 TSSOP 38 DA
    G2x44 TSSOP 38 DA
    G2x44 PDIP 40 N

     
     
    ti_msp430.lbr
  20. Like
    gordon reacted to RobG in Misc Display Eagle Library   
    UPDATE: This library now contains other displays as well
     
    Compatible displays:
    Common Anode
    MSQ6111C
    MSQ6411C
    MSQ6911C
    TOF-5461BMRL-B
    HS-5461B
    KW4-561ABB
    KW4-561AGB
    KW4-561APGB
    KW4-561ASB
    KW4-561AWB
    LTC-5623G
    LTC-5623E
    LTC-5623HR
    LTC-5623P
    LTC-5623Y
    LTC-5653G
    LTC-5653B
    LTC-5653C
    LTC-5653E
     
    Common Cathode
    MSQ6141C
    MSQ6441C
    MSQ6941C
    HS-5461A
    HS-5461AS2
    KW4-561CBB
    KW4-561CGB
    KW4-561CPGB
    KW4-561CSB
    KW4-561CWB
     
    Clock displays:
    KW4-566XXX
    LTC-5630XX
    LTC-5660XX
     
    Many other from Lite-On
     
    More will be added later.
     
    Original post
    Here is my NFD-5641 Four Digit Seven-Segment LED Display Eagle library.
    NFD-5641 is the display sold by futurlec as part numbers 7FR5641xx.
    So far, the library has two displays:
    7FR5641AS Four Hi-Red 0.56" CC 7-Segment LED Display
    7FR5641BS Four Hi-Red 0.56" CA 7-Segment LED Display
     


     

     
    Updated to v1.2 with alternate symbols and square pin #1.
    Updated to v1.3 with new display, LTP-747E.
    display-misc.lbr.zip
  21. Like
    gordon got a reaction from pine in Android phone replacing SD card   
    With the obvious hack value and the portability angle set aside for a moment, does this really matter? It's not like you are compiling Qt or LibreOffice, you are compiling a couple-of-KiB application that (with a bit of an exaggeration) fits inside the L2 cache of a P2. What's the point?
     
    On the portability note however, if you are working on the field a lot, mspdebug as a portable programmer could really be useful (maybe mspgcc as well, to some extent, but I'm hazarding a guess if you need to "quickly" "fix" something typing on a phone, you'll just make it worse ).
  22. Like
    gordon got a reaction from jsolarski in SD16 Help   
    For others' reference, as I told jsolarski, I strongly believe -mendup-at=main should not ever be used. There's room for a nasty surprise if, for example, your setup code runs again when you don't expect it.
  23. Like
    gordon got a reaction from jsolarski in Makefile for MSPGCC   
    Following up on viewtopic.php?f=10&t=1228#p8163, I made some tweaks to the Makefile. It now has simple heuristics to detect whether you are running Windows (I'm not much of a Windows person, so it is kind of a shot in the dark, please test), and if yes, it uses MSP430Flasher for installing.
     
    It is also possible to have only one central instance of this "master" Makefile, with per-project Makefiles only referencing this one, possibly overriding some settings.
     
    Per-project Makefile:

    TARGETMCU := msp430g2211 include ../Makefile
    (I really don't recommend symlinking the master Makefile in project directories, you'll surely shoot yourself in the foot sooner or later.)
     
    Master Makefile:

    TARGETMCU ?= msp430g2231 SRCS ?= main.c CROSS := msp430- CC := $(CROSS)gcc CXX := $(CROSS)g++ OBJDUMP := $(CROSS)objdump OBJCOPY := $(CROSS)objcopy SIZE := $(CROSS)size LD := $(CC) MSPDEBUG := mspdebug MSP430FLASHER := C:\\bin\\MSP430Flasher LDFLAGS := -mmcu=$(TARGETMCU) CFLAGS := -Os -Wall -W -Wextra -Werror -std=gnu99 -g -mmcu=$(TARGETMCU) ifneq ($(WITH_CXX),) CC := $(CXX) LD := $(CC) endif 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 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 CFLAGS += -finline-functions CXXFLAGS := $(CFLAGS) PROG := $(firstword $(SRCS:.c=)) OBJS := $(SRCS:.c=.o) all: $(PROG).elf $(PROG).hex $(PROG).lst %.elf: $(OBJS) $(LD) $(LDFLAGS) -o $(PROG).elf $(OBJS) $(SIZE) $< %.o: %.c $(CC) $(CFLAGS) -c $< %.lst: %.elf $(OBJDUMP) -DS $< > $@ %.hex: %.elf $(OBJCOPY) -O ihex $< $@ clean: -rm -f $(PROG).elf $(PROG).lst $(PROG).hex $(OBJS) install: $(PROG).elf $(PROG).hex ifeq ($(OS),Windows_NT) $(MSP430FLASHER) -n $(TARGETMCU) -e ERASE_MAIN -w $< else $(MSPDEBUG) -n rf2500 "prog $<" endif erase: $(MSPDEBUG) -n rf2500 erase .PHONY: all clean install erase .PRECIOUS: %.o
     
    I don't know what options does MSP430Flasher take, I just sort of guessed.
  24. Like
    gordon reacted to bluehash in tidoc button   
    Should be good now.
  25. Like
    gordon reacted to oPossum in another launchpad programming question   
    This link: http://focus.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slau157&fileType=pdf will be the latest version.
×
×
  • Create New...