Jump to content

veryalive

Members
  • Content Count

    139
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by veryalive


  1. a clarification:

    - if you use energia : just wire up an async FTDI module to the LP 'backchannel' then use your favourite async sw (putty)

    - if you use CCS : as above; plus write your own async driver.  ccs printf() can be made to send characters to the async port -or- write a 'tiny printf()' - there's a good one somewhere on this forum as I recall (by opossum).


  2. this is a known problem with the 2355 launchpad emulator section.  (FR2433 as well).  The output from the emulator to the PC is delayed many seconds in time , OR, comes out quickly when the emulator buffer contains 64 characters.

    TI will not fix it any time soon.   It has been reported on the e2e forum as well.

    A workaround is to either wait that time for the characters, or write your own async driver, then wire the launchpad async port directly to an off-board module like an FTDI-type.   This may be a bit complex if you've never done it before.

    I wish there were better news, but that's it !!


  3. Yes, the new FR2433 LP is a nice one; and good value-for-money.   The I/O is generous and handy.

    I'm curious why TI configured it's internals the way they did. What is the end-user application(s)?  Why the HW 32 bit MPY (yes 32), only a 10 bit ADC, CRC, small FRAM, large SRAM; etcetera.

    Thoughts?

     


  4. I have used the nRF24L01 Spirilis  library both on Energia and CCS; both worked well.

    I used it point-to-point.  My target was '2553.

    My only wish is that I would have more time to dig into this library and this excellent, low cost nRF further; alas, not to happen soon.

    cheers,


  5. Ah, OK.    I see you are not using the SPI however.          I don't have a CC3200 -  I'll try this on a 2553 / 5529, E17 for interest, this weekend, just to see what happens.

    I use the SPI / I2C / etc on Energia to quickly try things, so your observation is of interest to me.

    Maybe someone else on this forum has more experience with your exact configuration....

     


  6. Yep, a great application.

    May I inquire :   are you muxing the LED array one digit  -or-  one SEGMENT per digit at a time ?   Any the 'ON' time ?   Just curious how much current the IO pins can supply, it sounds like there's no series limiting resistance, which is perfectly OK.

    Cheers.

     

     

     


  7. May I recommend that you consider buying a cheap (sub $10), 8-bit, low speed (eg 24 MHz), logic analyser sooner than later ?

    That, plus experience with the MSP430 'register page' of the CCS IDE 'Debugger' will be good friends to help you sort out the programming of MSP430 family peripherals.

    Welcome to the forum!


  8.  

    Its definitely possible to program the 2553 / 28 pin device with the Launchpad - especially with CCS.  So, likely there's a PCB / wiring issue on your proto.

    Looking at your schematic....      the capacitor C2 / 0.1 uF   --  not needed.     Reset needs a +- 30K pullup / 1nF to ground but this may already be provided - depending on where exactly you wired your jumper onto the Launchpad.

    Can we assume that you've got +3volt / GND connected?    Anything else on the schematic we should know about?

    And I would start with the CCS 'blink' example (toggles P1.0 - often connected to an LED), just to check the communication via Spy By Wire.

     

    Keep going - it'll work !!

     

     


  9. Hi,

     

    I've been following your bit-bang I2C efforts.

    If you are making a custom version, perhaps using direct port I/O would be useful?

     

    As follows:

     

    P1DIR |= BIT7 + BIT6;       // make these outputs

    P1OUT |= BIT7 + BIT6;     // make them simultaneously go hi

    P1OUT &= ~(BIT7+BIT6);  //  ditto, but go low

     

    The only thing is that it departs from energia statements.

     

    I suspect you must have a scope / logic analyser or you wouldn't have known / measured the delay between the two PinMode statements you tried? 

     

    Is this OK for your app?

     

    Cheers,


  10. Thank you @@Fmilburn

     

    Your article got me interested, again, in driverlib.   In fact, I was not able to get it working when I first tried some months ago, and I'm having the same problem as I did on my first attempt.

     

    Here's an open question to you or the forum  -----> 

     

    When I try driverlib, I can't get CCS to find it in my computer's file system; likely a path problem; despite trying, I've been unable to solve it  ---   any ideas, folks?

     

    Here's Frank's simple 'blink' which I tried today and the CCS error output......   (I underlined the offending line.

     

     

     


    **** Build of configuration Debug for project test-5229-drvlib-1 ****
    "C:\\ti\\ccsv6\\utils\\bin\\gmake" -k all
    'Building file: ../main.c'
    'Invoking: MSP430 Compiler'
    "C:/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/bin/cl430" -vmspx --data_model=restricted --use_hw_mpy=F5 --include_path="C:/ti/ccsv6/ccs_base/msp430/include" --include_path="C:/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/include" --advice:power=all -g --define=__MSP430F5529__ --diag_warning=225 --diag_wrap=off --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="main.d"  "../main.c"
    >> Compilation failure
    subdir_rules.mk:7: recipe for target 'main.obj' failed
    "../main.c", line 2: fatal error #1965: cannot open source file "driverlib.h"
    1 catastrophic error detected in the compilation of "../main.c".
    Compilation terminated.
    gmake: *** [main.obj] Error 1
    gmake: Target 'all' not remade because of errors.
    **** Build Finished ****

     

     

    and the code...

    #include <msp430.h> 
    #include "driverlib.h"
    #define  DELAY_CYCLES  1045000
    
    /*
     * main.c
     */
    int main(void) {
    
    
       WDT_A_hold(WDT_A_BASE);
       GPIO_setAsOutputPin(RED_LED);
       for(; {
          GPIO_setOutputHighOnPin(GPIO_PORT_P1,GPIO_PIN0);
          _delay_cycles(DELAY_CYCLES);
          GPIO_setOutputLowOnPin(GPIO_PORT_P1,GPIO_PIN0);
          _delay_cycles(DELAY_CYCLES);
       }
    }  WDTCTL = WDTPW | WDTHOLD;	// Stop watchdog timer
    	
    	return 0;
    }
    
    

  11. You're clearly deep into this, so I don't know if this fits.....

    What about programming an MSP to do that protocol in real time, then have it communicate up to the Linux box as required?

    As I've never heard of that 16/24 bit scheme you mentioned, I'd be absolutely no use progressing this idea further!

    Cheers,


  12. hi - although I'm a bit late to this thread...

     

     

    Regarding +5 volt operation on the LM4F120 I/O pins...    Specifically the LM4F on the 'old' Stellaris Launchpad.....

     

    I have followed the data sheet explicitly where it states that certain of the I/O pins are 5volt tolerant on input. I have not damaged anything by reading 5volt input signals to the chip.  I cannot measure anything to confirm it is true, however; I just trusted the data sheet.

     

    The data sheet I'm using is  :   DS-LM4F120H5QR-13200.2535  SPMS294G, starting in Chapter 10.

     

    And, in section 10.1 :

    All GPIO signals are 5-V tolerant when configured as inputs
    except for PD4, PD5, PB0 and PB1, which are limited to 3.6 V

     

    I'd be very curious if someone else has successfully used this for I2C which uses pull-up resistors (+-3 K ohms) to a +5volt bus.

     

     

    Cheers..

×