Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    tripwire reacted to cubeberg in Why are the pins on the board naked?   
    It's so boards can be added on the bottom too. When you have more than one it can come in handy or whenot one is the 20 pin format and another is 40 pin. It would be nice if it sat flat though. They have added stand offs to a few so far.
     
    I'd be interested to hear if anyone has a solution. I usually strap mine to a breadboard with a rubber band which keeps things still.
  2. Like
    tripwire reacted to chicken in WISP energy harvesting sensor node based on MSP430   
    Hackaday today featured a sensor node which runs on harvested RF energy.
    http://hackaday.com/2016/05/01/wisp-needs-no-battery-or-cable/
     
    As the article mentions a 16bit CPU, I wondered if someone put an MSP430 to good low-power use. And yes, digging into the WISP5 project finds that it uses an MSP430FR5969.
     
    Project wiki with links to source code and schematics here:
    http://wisp5.wikispaces.com/WISP+Home
  3. Like
    tripwire reacted to curtis63 in Time for another ENERGIA RELEASE !   
    Good morning,
     
    This probably belongs in the suggestions section, but I couldn't find that so I'm posting it here.  Moderators, please move this to the appropriate place...
     
    Anyway, I would like to suggest that the powers that be PLEASE release a new version of ENERGIA.
     
    There are 2 huge glaring problems in the current release.
     
    1.  I2C Scanner doesn't work for MSP430G2553
    2.  There is no support for 28 pin versions of the MSP430G2553
     
    Both of these issues have been addressed and fixed in various GitHub code.  However, it has not been merged into Energia and applied to a new release of Energia.
     
    I have downloaded energia and applied the above 2 patches and am running just fine.  However, it seems like 4 months since the last release of code is a very long code cycle.
     
    Please release an updated version with all the fixes to date included, so that it works well right off the shelf without having to hack it to death.
     
    By the way, ENERGIA IS AWESOME !!!!!!!!!!!!!!!!!!!!!!!!!!!!!  I really love it..  Let's just update it and so new users will love it as much as I do, without having the hassle of having to manually patch parts of it.
     
    Thanks,
    Curtis
     
  4. Like
    tripwire reacted to cde in Detecting msp430g2553 package (28/20 pins)   
    Use bootstrapping. By that, I mean a single high value resistor tied to a spare pin, high or low. Any project where the 28 pin device is used, the resistor should tie the line high, your code reads it on boot, then ignores it the rest of the time it is running code. The 20 pin would have a resistor tied to ground. Or you could skip the resistor and tie the pins directly to vcc/gnd as long as you are sure you never set that pin as an output. (The resistors provide some level of idiot-proofing).
     
    This works on spare gpio pins, and can even be used later as an output (with the resistor!), an led output (again with the resistor), or a button input (again, with the resistor). Of course, this is a hardware level runtime method of defining boot options, not a compile-time or programming level.
  5. Like
    tripwire reacted to roadrunner84 in Detecting msp430g2553 package (28/20 pins)   
    You'll need to wire the pin to detect it. But you could wire it to (for example) the Rx pin on the debugger's UART, then you would be able to detect it when using a script. If the UART pin is space (1) the line will report it to be idle, when the line is mark (0) for at least 10 bit times the line will report frame error. So you could upload one firmware for a frame error, and the other for an idle line.
    For such a script, use anything like, bash, power shell or python. This script will first upload the "set a pin" firmware, then read the Rx UART line and then flash a conditional firmware using the command line tools provided by TI.
  6. Like
    tripwire reacted to greeeg in T-962 Reflow Oven   
    I find mine is quicker than my particular toaster oven was.
     
    and I set and forget mine. The profile I have runs for 7 Minutes.
     
    My workflow goes like this:
    Apply Solder paste to 4 PCBs PnP components for 1 PCB (manually with vacuum pickup tool, and tape laid out flat) Place PCB in Oven, run cycle Continue to (2) if more PCBs remaining.  
    The vacuum pickup tool has halved my manual placement time. Highly recommend over tweezers.
     
    Note the temperature of IR heating elements isn't ideal for PCB reflow*. Because it's Radiation heating vs Convection heating. The thermocouples generally don't track well with the PCB temperature.
    Once you've tweaked the profile for your PCBs it works great.
     
     
    *IR / Radiation heating for PCBs is bad because the temperature rise of the PCB will be related to the emissivity of the PCB. ie a black soldermask PCB will heat more quickly than a green one.
  7. Like
    tripwire reacted to Lgbeno in T-962 Reflow Oven   
    After a few years with the toaster ovens, I recently upgraded to this T-962 Reflow oven that I picked up on eBay for $184.
     
    Not sure why I waited so long, I baked my first 3 boards printed with stencils from OSH Stencil and they turned out great. Highly recommended!
     
     

  8. Like
    tripwire reacted to ak96 in Trying to alternate blinking of two LEDs   
    @@cubeberg
     
    Yep, that's right. After I set all pins to 0 it started working. The bits are assigned random states every time I run it, and whenever the two LEDs start with the same state it works fine, but when they start with different states they blink synchronously. 
     
    Thanks!
  9. Like
    tripwire reacted to cubeberg in Trying to alternate blinking of two LEDs   
    My guess would be because you're not setting the initial state - you should set them explicitly instead of assuming state when your code executes.  Try P1OUT = 0x00; when you set P1DIR. or instead of P1OUT ^= 0x01, use P1OUT = 0x01;
  10. Like
    tripwire reacted to Lgbeno in MSP430G2553 with NRF24L01 Wireless   
    Ahh good old nrf24. The radio is capable of transmitting 32bytes of data so you might as well fill'er up before sending.
     
    If curious there is also a fork of enrf24 for energia and g2553 that also will transmit BLE beacons:
    https://github.com/analog-io/analog_io_lib
     
     
     
    Sent from my iPhone using Tapatalk
  11. Like
    tripwire reacted to cubeberg in Having trouble installing Code Composer.   
    Just "MSP ultra low power MCU" is what you need for the MSP430.  You can leave the rest of the options at their default (the normal debugger option is usually greyed out - you don't need any of the optional debuggers).  
    You don't have to install any of the app center tools - if anything seems interesting you can install - but you can always install those later as well.  
  12. Like
    tripwire reacted to B@tto in MSP432 and SWD   
    Hi,
     
    I designed a custom board with an MSP432, and when I did it, I thought I could use the J103 header on the MSP432 LP to program it. But after my uploads failed, I made some investigations and found that LP use a full JTAG and not SWD to program the embeded MSP432. I finally found how to change the XDS110 mode to SWD in CCS :
     

    (on the right, "JTAG/SWD/cJTAG Mode")
     
    But how to do it in Energia IDE ? The MSP432 file organization is completely different from msp430 and I simply don't know at all where it could be changed ...
     
    Thanks
  13. Like
    tripwire reacted to USWaterRockets in Have feedback for TI? Please share here.   
    It seems like an awful lot of work went into designing the MSP432 and integrating it into the MSP430-centric ecosystem. Migration documentation and tools and all of that take a lot of effort to produce. It seems to me like there must be a reason for all of that effort, and somehow all that work had to be justified. So, perhaps there is a method to their madness, and ultimately it will all make perfect sense when the scope of the plan has been revealed?
  14. Like
    tripwire reacted to Fmilburn in EXP5969 supply voltage   
    VCC is 3.6V measured on my sample as well. The schematic on Page 39 of the LaunchPad Development Kit User's Guide (SLAU535B) shows power coming from a TLV70036DSEwhich is a 3.6V LDO.  So the pin maps or any other documentation showing 3.3V are incorrect.
  15. Like
    tripwire reacted to Adnan in EXP5969 supply voltage   
    Hi,
    Yes, it's accurate ans also I checked more than one kit, all of the produce the same Vcc (3.62) and at the same time I measured the voltage on exp5529 it gives 3.3 V.
  16. Like
    tripwire reacted to kassovik in Underwater clock OLED.   
    My first project. Underwater clock. Used msp430g2553.

  17. Like
    tripwire got a reaction from yyrkoon in MSP430G2553 SPI Slave mode behaviour   
    That bug only happens with UCCKPH=1, which isn't the case in the slave code shown. I suspect the problem might just be a mismatch between the Raspberry Pi's SPI mode and the one selected on the g2553. That can manifest as a one-bit offset in one direction or the other.
     
    You can use ioctl(fd, SPI_IOC_WR_MODE, &mode) to set the mode on the raspi end. Doing that means you can avoid setting UCCKPH=1 on the g2553 and not have to worry about the USCI40 problem. The bad news is that the arduino slave code will need changing to match.
     
    I think that setting SPI_MODE_3 on the raspi will match what you've selected on the g2553, and will let you remove the bit shift workaround.
  18. Like
    tripwire got a reaction from himanshubdave1426459935 in MSP430G2553 SPI Slave mode behaviour   
    That bug only happens with UCCKPH=1, which isn't the case in the slave code shown. I suspect the problem might just be a mismatch between the Raspberry Pi's SPI mode and the one selected on the g2553. That can manifest as a one-bit offset in one direction or the other.
     
    You can use ioctl(fd, SPI_IOC_WR_MODE, &mode) to set the mode on the raspi end. Doing that means you can avoid setting UCCKPH=1 on the g2553 and not have to worry about the USCI40 problem. The bad news is that the arduino slave code will need changing to match.
     
    I think that setting SPI_MODE_3 on the raspi will match what you've selected on the g2553, and will let you remove the bit shift workaround.
  19. Like
    tripwire got a reaction from dubnet in MSP430G2553 SPI Slave mode behaviour   
    That bug only happens with UCCKPH=1, which isn't the case in the slave code shown. I suspect the problem might just be a mismatch between the Raspberry Pi's SPI mode and the one selected on the g2553. That can manifest as a one-bit offset in one direction or the other.
     
    You can use ioctl(fd, SPI_IOC_WR_MODE, &mode) to set the mode on the raspi end. Doing that means you can avoid setting UCCKPH=1 on the g2553 and not have to worry about the USCI40 problem. The bad news is that the arduino slave code will need changing to match.
     
    I think that setting SPI_MODE_3 on the raspi will match what you've selected on the g2553, and will let you remove the bit shift workaround.
  20. Like
    tripwire reacted to chicken in msp430g2553 / msp430x2xx pinmux   
    The table on Page 43 tells you, that as long as ICHx is set to 0, the pin can be used for other things.
     
    If you really want to dig into the details, the "flow charts" (actually a simplified schematic of an individual pin) will tell you, that ICHx controls, whether the pin is connected to the ADC. That 2nd butterfly symbol from the top seems to be a switch controlled by ICHx.
  21. Like
    tripwire reacted to dubnet in msp430g2553 / msp430x2xx pinmux   
    If I read it correctly the table below each flow chart shows the configuration setup bits for those particular pins in the chart. Given this shows each pin is configurable individually it would seem to be the written proof that you would need to support your answer of "yes". Could also point out that this behavior is inferred in Energia as you can assign one pin as analog in, and others as digital I/O.
  22. Like
    tripwire reacted to veryalive in Have feedback for TI? Please share here.   
    Shipping in The Netherlands is (only) $7 USD.
     
    But I think TI's Euro disti hub is in this country.
  23. Like
    tripwire reacted to USWaterRockets in Have feedback for TI? Please share here.   
    A couple of quick comments.
     
    1) Loved the $4.30 Original Launchpad/ Too bad it had to go up in price. I guess I can understand why.
     
    2) I wish there was some kind of roadmap for MSP432. It looks like they made one part a year ago and then abandoned the idea. I like the part a lot and wish there were other variations.
     
    3) The wireless stuff is great, but the software and tutorials for the wireless are a mess. I got the CC2650 sensortag a year ago and a debugger devpack. Code samples didn't build, and putting the original firmware back in caused features (accelerometer) to quit working. A super part with a lot of promise left a really bad customer experience. I put it in a drawer out of frustration.
     
    4) CCS is great, and having a real debugger is awesome. Should find a way to make this work completely with Energia, or find ways to steer Energia users to CCS for the debug facilities.
     
    5) TI should make a 3D Printer control board reference design, with all of their fancy parts on it, and all the right software. Maybe a Tiva or MSP432 for the CPU, or a AM335x with PRU assist for realtime stuff. Competitors have gotten footholds in 3D printers and quadrotors and TI could really get a lot of smart people using their stuff by introducing reference designs to build upon.
  24. Like
    tripwire reacted to dubnet in Have feedback for TI? Please share here.   
    I agree with bluehash in that TI is unusual in its commitment to the enthusiast community. Even though it is a marketing effort at it's heart, it is one that is difficult to directly measure in terms of ROI and therefore reflects a corporate culture truly committed to the effort. I highly value both TI and this forum. As a result TI is my first choice, not only for MCUs, but for other semiconductors as well.
     
    As good as things are I do have some suggestions.  Based on the forum activity it seems that lately a fair number of people are migrating from the Arduino camp to Launchpads using Energia.  I realize Energia has been an effort that has grown organically, probably taking a boat load of man hours to create and maintain. It is a valuable and very useful tool. However, given the number of installation related questions on the forum perhaps an installation wrapper could be developed.  I envision this wrapper installing Energia to a consistent directory path which would eliminate path issues (e,g, spaces, invalid characters, overall path length). Also, the wrapper could install the Launchpad drivers (either all the current models or specific models chosen by the user at installation).  Improving the documentation is another area that would ease the migration of both Arduino users, and new users, into the TI camp.  I understand that these suggestions would take resources to implement, but I feel that the ROI in terms of increased adoption of the TI product could be worth it.
     
    The other area, a minor one, is the TI store.  I fully understand why TI incorporated a shipping charge (and a reasonable one at that) after offering free shipping for so long. In fact, I often wondered how they could sustain free two day Fedex shipping.  However, a significant number of companies offer free shipping above a certain dollar threshold. Perhaps TI could do this as well. An order, somewhat independent of size, has an internal processing cost to the company. A free shipping threshold could encourage orders with a larger dollar value which could benefit both TI and the purchaser.  TI in that the average dollar value per order would increase and the purchaser who would save shipping charges.
     
    @bluehash  Appreciate everything you do. This continues to be a great forum.
  25. Like
    tripwire reacted to pine in Salvaging and re-purposing a 5529LP with lost USB hub function to run Forth   
    Since my only 5529LP was confirmed no longer functioning properly and the likely cause is the USB hub module, there have been some thoughts going through my mind to salvage the core 5529 device on the LP for some good use. And this weekend I have decided to give it a try.
     
    As the USB host part is confirmed not functioning, the first step is to verify the F5529 is still good. The easiest way is to try program it and check if it can run new program.
     
    With a good F5529 LP (the new replacement board ordered after the old one retired), I removed all the jumpers between the ez-FET and the target device, and then wired the GND, 5V, 3V3, RXD, TXD, SBW RST, and SBW TST from the good ez-FET to the 5529 side of the old LP. This will also power up the old board from the new one as the USB host on the old board is dead and no longer powering it.
     

     
    Soon after an example Energia sketch of SerialCallResponseASCII is uploaded through the new, good board, the good news is displayed on the Serial console confirming the 5529 device is still working flawlessly. At this point, I came into realization that this board can no longer be a handy development board as it once was but only good for deployment, possibly permanently, to some project because I have to rely on that good LP every time for programming.
     
    But wait, I recall recently from the forum there are some posts mentioning Forth interpreter for MSP430, one of which by monsonite with comprehensive information on various Forth offerings. However, a common requirement for Forth is serial communication for the console that my old LP is no longer capable to provide with a dead USB hub.
     
    Even though I don't have serial to usb converter to bypass the on-board hub for direct serial connection, I remember there is an old Arduino Pro Mini laying around without much used. Combining these two, I could probably build a utility development board that
    provide ad hoc programming capability (in Forth) on the 5529LP provide the console access required by Forth on the 5529LP via the Arduino Pro Mini (forward the serial communication from the Arduino UART to the 5529LP TX/RX) power the 5529LP via the 5V and 3V3 pin from the Arduino Pro Mini All in all, the goal is to take the Arduino Pro Mini as the controller or programmer of the 5529LP that is programmed to run Forth only. I picked the Mecrisp as it provided out of the box support for the 5529LP and pre-compiled hex file.
     
    So the build begin by first flashing the Forth hex file to the 5529LP. Again it required a good 5529LP and I used the latest MSPFlasher for the job. The following is the command line (for Windows).
    MSP430Flasher.exe -w "forth-mecrisp-5529.hex" -v -g -z [VCC]
     
    For a more decent looking of this utility development board, the Pro Mini is mounted to a medium sized breadboard on one end, and with four metal pins (pulled from left over connectors), the 5529LP is somehow "mounted" to the other end. This is enough for some structural support for the 5529LP
     

     
    Now for the Arduino side. Since there is only one set of UART on the Pro Mini, the program on it make use of the SoftSerial library that will emulate another serial port by two digital pins to relay the serial messages from the real UART to the 5529LP.
     

     
    Finally the moment of truth, the serial console to the Arduino is opened for a test. Apart from the line feed being weird, the expression run (1 2 + .<cr>) is successful, so is the programming of the blinky program
     

     
    Moving forward, the Arduino can be programmed in such a way that not only merely relaying serial message, but parse special commands to initiate specific Forth programming to the 5529LP (the Forth programs themselves stored as program in the Arduino). Hopefully this will make the whole package more versatile and practical.
×
×
  • Create New...