Jump to content


  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    cyberman_ff reacted to RobG in 2.2" 320x240 Color LCD Booster Pack   
    @@cyberman_ff, back in stock.
  2. Like
    cyberman_ff reacted to oPossum in "Dumb" question, 2 seperate boards with the same code   
    TI MSP430 Flasher http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer
    Elprotronic FET-Pro430 Lite  http://www.elprotronic.com/download.html
    MSPFET http://kurt.on.ufanet.ru/
  3. Like
    cyberman_ff got a reaction from Holck in Yet another UART issue. :)   
    The only reliable method I've found to wait until something is transmitted is
    main_loop: bit.b #UCA0STAT, &UCBUSY jz main_loop That guarentees that it's not transmitting before you transmit. Although TI seems to extensively abuse the IFG flags DON'T use it for serial comm (of ANY KIND) that is NOT what it's intended for. The UCBUSY flag IS intended to indicate when serial com is occuring. So use that instead. I had to fix TI's code several times if I changed the processor frequency because of the use of the IFG flag, (in summary). Use UCBUSY it is specifically their just for what you are doing.
    You may also want to change a
    mov.w #0x0068, &UCA0BR  
    2 stage loading of UCABR0/UCABR1, I use the 16 bit load all the time. Apart from being shorter and using less memory, it's also more obvious what you are doing.
    It's not necessary however (LOL).
    Last but not least UCA0CTL1 probably should be more like
    mov.b #UCSSEL_2|UCSWRST, UCA0CTL1 As this clearly configures the register, ORing it with random bits after reset has always lead to trouble for me.
    You probably should read carefully the baud rate information also. I can't tell you if the number you choose is right off hand (just in case).
    I hope this helps. If I missed something I'm sure someone else will point it out.
  4. Like
    cyberman_ff reacted to rebeltaz in Coffee Pot Fish Tank   
    I knew I liked this forum for some reason
  5. Like
    cyberman_ff reacted to spirilis in MSP430F5172 LaunchPad XL   
    Ok this is kinda strange, but noteworthy. The FT230X seems to have reversed the behavior of the TXLED# and RXLED# functions in the CBUS pins relative to the FT232R -- They now make correct sense, IMO.
    Wording from FT230X datasheet:
    TXLED# CBUS0, CBUS1, CBUS2, CBUS3 Transmit data LED drive
  6. Like
    cyberman_ff got a reaction from spirilis in MSP430F5172 LaunchPad XL   
    Well you could reconfigure the behavior of the pins by using the internal MTP memory on it. I also noticed it had an option to act as a USB charger 'facilitator' using external logic (hmm nifty).,
    Anyhow  ...
  7. Like
    cyberman_ff got a reaction from spirilis in MSP430F5172 LaunchPad XL   
    Hmmm the TUSB3410 can be added the only difficulty is adding a msp430F1612 to the board with the correct firmware to put the FET on board.
    I believe TI has software to both program the TUSB4310 EEPROM and program the msp430F1612 (via a BSL) so it might be possible to actually add the FET to the board.
    Thought I would mention this, as many a person has theroughly KILLED their TUSB4310 (due to the LDO being shorted from the board and causing a glitch response to 3.640V ahem).
    Anyhow I would suggest powering the board with a seperate LDO than the FET devices and using a 3.3V regulator for those. This will prevent some "idiot" when they short VDD to ground from blowing the LDO or killing the TUSB3410.  You will want to use the same old translator, and possibly use a current limiting switch for power to the processor as well. (things I wish that TI did to make it more robust).
    That's all I can think of anyhow
  • Create New...