Jump to content

mbeals

Members
  • Content Count

    347
  • Joined

  • Last visited


Reputation Activity

  1. Like
    mbeals got a reaction from juani_c in Custom EzFet Lite   
    Yes you can. That's what I'm doing with mine. I just made the icsp programming header for the MCU match the pinout on the launchpad.
     
    As for a single sided board, in sure it's possible but it's going to be tough. The QFN footprint would not be fun to home etch
  2. Like
    mbeals got a reaction from greeeg in Custom EzFet Lite   
    At least the latest revision of the g launchpad can.
  3. Like
    mbeals reacted to enl in Quadrature encoders and interrupts   
    I would guess at bounce issue as well. Simplest solution is an RC filter. Several ways to do it, but I tend to avoid the simplest, which is putting a cap directly across the contacts, unless I know that it is a very limited use device, as this method tends to destroy the contacts quickly. A three resistor solution is better, and properly tuned generally satisfactory. (see attached MSpaint sketch) Adjust the cap as needed. The Tc as shown is about 1ms, which is my usual starting point.
     
    This is not the best way to go for production devices, but is quick and simple for a one off, and a good check for bounce issues.
     
    A better solution is to disable the interrupt for a while after the first one. Figure the first one will be the true, unbounced read for the other line. How long to disable? Depends on rate you expect the control to be turned at. If it is a 16posn unit, and figure maybe 2 rev per sec at breakneck speed (32 motions per sec), disable interrupt for 25ms  and you will catch the next.
     
    ANY debounce scheme can be sensitive to the half-step issue. Half way to the next click, then back. Is it counted? If the knob is held near half step, does it continually retrigger?
     
    I tend to prefer a state machine approach to reading quad encoders. Both lines to interrupt inputs, and set the interrupt enables based upon current state. That way, all bounce does is go back and forth between to adjacent states, until settling occurs to the final state. With mechanical switching, I still usually put an RC in if I can, as that reduces the need for quick response to the interrupts due to switch bounce, but the RC Tc can be short enough (maybe 20us, depending on circumstances) that the cap can be very small, sometimes lead capacitance being enough if the resistors are at the switches.

  4. Like
    mbeals got a reaction from bluehash in Debugging USB power problem   
    so it appears I somehow reversed the USB connector.... which is odd since I don't even remember modifying the connector used in the TI reference docs.  I've flipped it back around and am no longer having the same issue with current draw, but I think running it reversed might have blown out the USB transceiver on the micro, as I can't get any computer to recognize it as a USB device.
     
    On another odd note... I programmed a simple "LED blink" script to test if I could program the MCU.  It works when I run it in the debugger, but if I just apply power, the firmware doesn't load.  I'm wondering if I hosed the boot loader or something when I flashed it.
  5. Like
    mbeals got a reaction from tripwire in What are you working on today/this week?   
    I won't get to any serious development this week, but I'm at least thinking about how I want to approach it.
     
    This is a LFM (linear fm) TDM (time division multiplex) MIMO (multiple input/output) S-band phased array radar that I built as part of an MIT summer course.  The current iteration is using an ATmega dev board to drive the transmitter, process the return and transmit it over USB to the host processing software.  The problem is that the MCU is somewhat under powered which is impacting the PRF.  The data transmission operation is blocking, so there is a fair amount of dead time that could be used for continuous pulsing.
     
    So my goal is to replace the "brain" with something that has a little more horse power.  Right now I'm weighing my options between something with a Tiva series chip or a beagle bone black.  I'm also considering a DSP chip, but haven't looked very far into what my options are and how the DSP specific logic would benefit me since all the FFT's are done off board.


  6. Like
    mbeals reacted to enl in What are you working on today/this week?   
    @simpleavr: This is actually a hard problem. I played with it years ago for a directional  phase-array microphone, which is actually easier... direction is determined by calibrated delay in each channel.
     
    Your mics look to have a separation of about 100mm. This is the wavelength corresponding to, roughly, 4Khz from the side aliasing to straight ahead, or about 40Khz from 6 degrees off center line.
     
    (I was going to go into a long explanation/analysis, but I will keep it short: My current project calls and it will take a while to formulate a clear explanation)
     
    Short form: you need the inputs matched very, very closely, both for phase shift and other delays (like ADC). 25microsec corresponds to on centerline looking like 6 degrees off, or 45 degrees off centerline looking like 35 or a bit more than 60 degrees (depending on orientation)
     
    You need good high freq response to measure impulse timing, such as a book hitting the floor or a clap. Certainly better than 20KHz. The fast rise time is the key issue. The better the balance between channels, the lower the frequency cutoff can be, buy be careful of unequal phase shifts.  Probably can do it with a G-series. Might want to but a compressor in the front end and look for the gain change.
     
    Best bet is cw detection and detect phase difference at the two mics at several frequencies. Why more than one? To reduce aliasing and increase resolution. Higher frequencies give better resolution as the phase shift can be more precisely determined at a given ADC resolution and sample rate. The lower frequencies give a good baseline timing (anything below 2Khz will be immune to aliasing at 100mm) for refinement if there will be aliasing at higher frequency. Not likely to be practical with a G-series MSP430, due to memory limitations (easiest to grab a sample and FFT), but probably doable.
  7. Like
    mbeals got a reaction from cry_viem in Interrupt works on for one button but not the other?   
    I'm in the process of figuring out how interrupts and timers work on this board, so I wrote a short program to adjust the brightness of the blue led by clicking on either button.  The left button trips the interrupt just fine and does what it is supposed to....but the right button will not, even though it is configured identically.  I even tried a simpler version of the code in which would only interrupt pin 0 or pin 4, and even then it will not interrupt on pin 0.  I also tried clearing both interrupts right before entering the main loop, and it didn't help.
     
    It has to be something stupid simple, but I can't see it.  The code is below
    #include "inc/hw_types.h" #include "inc/hw_memmap.h" #include "inc/hw_ints.h" #include "driverlib/sysctl.h" #include "driverlib/gpio.h" #include "driverlib/timer.h" #include "driverlib/pin_map.h" #include "driverlib/interrupt.h" volatile unsigned long ulPeriod = 1000; volatile unsigned long dutyCycle = 250; int main(void) { // 40 MHz system clock SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN); /*Pwm the blue LED*/ // Configure PF2 as T1CCP0 SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); GPIOPinConfigure(GPIO_PF2_T1CCP0); GPIOPinTypeTimer(GPIO_PORTF_BASE, GPIO_PIN_2); // Configure timer SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1); TimerConfigure(TIMER1_BASE, TIMER_CFG_SPLIT_PAIR|TIMER_CFG_A_PWM); TimerLoadSet(TIMER1_BASE, TIMER_A, ulPeriod -1); TimerMatchSet(TIMER1_BASE, TIMER_A, dutyCycle); // PWM TimerEnable(TIMER1_BASE, TIMER_A); /* Configure buttons for input */ GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4); GPIOPadConfigSet(GPIO_PORTF_BASE,GPIO_PIN_0|GPIO_PIN_4,GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_STD_WPU); GPIOIntTypeSet(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4, GPIO_FALLING_EDGE); GPIOPinIntEnable(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4); /* Configure interrupt for buttons */ IntEnable(INT_GPIOF); IntMasterEnable(); while(1){} } void IntGPIOF(void) { if (GPIOPinIntStatus(GPIO_PORTF_BASE, GPIO_PIN_0) & GPIO_PIN_0) { GPIOPinIntClear(GPIO_PORTF_BASE, GPIO_PIN_0); TimerMatchSet(TIMER1_BASE, TIMER_A, dutyCycle+=100); if(dutyCycle >= ulPeriod - 1) dutyCycle = 0; }else{ GPIOPinIntClear(GPIO_PORTF_BASE, GPIO_PIN_4); TimerMatchSet(TIMER1_BASE, TIMER_A, dutyCycle-=100); if(dutyCycle < 100 ) dutyCycle = ulPeriod - 1; } }
  8. Like
    mbeals reacted to greeeg in Custom EzFet Lite   
    You're right it's not needed for programming. I am under the impression it's used / was used for some kind of debugging when TI were designing the eZFET-lite.
     
    Only because if you look at the eZFET-lite on the 5529LP, you can see SBW_NC brought out onto the 0.1" header. The target side isn't connected to anything though.

     
    I just copied it across when I transposed the schematic, on my board the net doesn't have a trace on the board.
  9. Like
    mbeals got a reaction from bluehash in LaunchFET: Tag connect for launchpad   
    I like them enough to start integrating them into my own projects.  The cables are solid quality and I have yet to have an issue with one (or know someone who has had an issue with one).  I would say the reliability of the cable/footprint is much better than the reliability of using a pin header.
     
    If you are planning on doing a lot of programming/debugging, then I would just buy two cables... with and without legs.  Use the leg cable for debugging to keep it in place, then switch to the NL cable when it's time to mass program boards. 
  10. Like
    mbeals got a reaction from GeekDoc in Quadcopter BoosterPack   
    Another option would be to integrate the MCU and keep the headers....turn the entire thing into a launchpad-like platform that you can stack with new/existing booster packs to extend the functionality.  
  11. Like
    mbeals reacted to bluehash in can bus?   
    @@spirilis can totally help you out with this.
  12. Like
    mbeals got a reaction from bluehash in Listen/spy/sniff UART comunication using MSP430   
    If you want to sniff all traffic sent from device 1 to device 2, all you need to do is connect that line to the RX pin on the launchpad.  When device 1 transmits a bit, both devices (device 2 and your sniffer) will read it.
     
    I'm not an energia user, so I can't give specific code advice there, but the easiest way to pull this off would be to use the hardware UART peripheral and an interrupt.  When the launchpad receives (sniffs) a new byte on the line, the interrupt fires and does something with it.  Maybe pop it onto an array, or display it on a screen, or flash the LED....  There are lots of tutorials about interrupts on the MSP430 and lots of code examples on this site.  There should be a good write up in the two documents you referenced.
     
    If you want to monitor both sides of the conversation (1--->2 and 2--->1) at the same time, things get more interesting.  Since a single UART module just has an RX/TX pair, to get two RX channels, you need two UARTs.  There are chips with dual UART, but the 2553 on the launchpad is not one of them.  You can, however, implement a timer based serial (which does exist already in Energia) to listen to the other line.  The same workflow would apply...use an interrupt to read the the incoming byte and then do something with it.
     
    One word of caution.... UART lines are totem driven.  That means the transmitter asserts high and low by actively driving the line to Vcc or GND.  If you put two transmitters on the same line (sort of sounds like you did that in your description), if one tries to send a 1 while the other is still idle (0), the first transmitter will be pulling the UART line to ground while the idle transmitter tries to hold the line up.  This is called bus contention and creates a short-circuit condition that can potentially burn out the transmitter on the MCU or the entire MCU itself if it pulls enough current.  
     
    The RX side is high impedance, and safe to do this as long as you aren't attempting to connect a ton of receivers in parallel. 
  13. Like
    mbeals got a reaction from Taggsladder in Listen/spy/sniff UART comunication using MSP430   
    If you want to sniff all traffic sent from device 1 to device 2, all you need to do is connect that line to the RX pin on the launchpad.  When device 1 transmits a bit, both devices (device 2 and your sniffer) will read it.
     
    I'm not an energia user, so I can't give specific code advice there, but the easiest way to pull this off would be to use the hardware UART peripheral and an interrupt.  When the launchpad receives (sniffs) a new byte on the line, the interrupt fires and does something with it.  Maybe pop it onto an array, or display it on a screen, or flash the LED....  There are lots of tutorials about interrupts on the MSP430 and lots of code examples on this site.  There should be a good write up in the two documents you referenced.
     
    If you want to monitor both sides of the conversation (1--->2 and 2--->1) at the same time, things get more interesting.  Since a single UART module just has an RX/TX pair, to get two RX channels, you need two UARTs.  There are chips with dual UART, but the 2553 on the launchpad is not one of them.  You can, however, implement a timer based serial (which does exist already in Energia) to listen to the other line.  The same workflow would apply...use an interrupt to read the the incoming byte and then do something with it.
     
    One word of caution.... UART lines are totem driven.  That means the transmitter asserts high and low by actively driving the line to Vcc or GND.  If you put two transmitters on the same line (sort of sounds like you did that in your description), if one tries to send a 1 while the other is still idle (0), the first transmitter will be pulling the UART line to ground while the idle transmitter tries to hold the line up.  This is called bus contention and creates a short-circuit condition that can potentially burn out the transmitter on the MCU or the entire MCU itself if it pulls enough current.  
     
    The RX side is high impedance, and safe to do this as long as you aren't attempting to connect a ton of receivers in parallel. 
  14. Like
    mbeals got a reaction from Fred in LaunchFET: Tag connect for launchpad   
    yes and no.  The extra holes required for the legs make it impossible to route traces to all the pads and stay within the specs supported by the low cost board houses (you have to use 6 mil traces and be <15mil from the drills).  I've also found that the legs are really stiff and difficult to get to [dis]engage without the help of needle nose...and they require you leave enough space surrounding the pad to get your fingers/tool on the cable to get it free.
     
    As an alternative, there is this guy: http://www.tag-connect.com/TC2030-CLIP which secures the no-legs cable to the board from behind, eliminating the hassle of the legs.  I haven't used it yet, but it appears to be a better solution (at least for what I do).
  15. Like
    mbeals reacted to tripwire in checking a character string in a buffer   
    If Line is an array of char, then the reason this won't work is a bit more subtle than that.
     
    C and C++ don't support equality comparison of native arrays. That means that (Line == "[start config]") doesn't compare each element of Line with the corresponding elements of the "[start config]" string literal. Instead, Line and "[start config]" both decay to pointers to their first elements. Then the values of those pointers are compared. The two arrays are at different locations in memory, so the two pointers will never match.
  16. Like
    mbeals got a reaction from bluehash in LaunchFET: Tag connect for launchpad   
    I've never liked populating a board with a 4 x .1" header to make it simple to program with the launchpad...and the official TI JTAG header is even worse, so I made a board to breakout the launchpad to a tag connect cable, which takes up much less room on the target board.
     
    I chose to use the 6 pin cable  designed for the Microchip ICD because I already have one, and because the 6 pin format works well with the 6 pins on the .05" header on the emulation side of the launchpad.
     
    I threw together 3 different boards:
     
       TAG-connect:        Basic 6 pin .05" header to RJ12 (for the tag connect cable)
       TAG-connect-iso:  Same board but with galvanic isolation.  If the target board is independently powered, pulling the jumpers will isolate the FET from the target.
       LaunchFET-iso:    Same isolation as the TAG-connect-iso, but without the RJ12.
     
    The isolated boards have what I'm calling a safe-MSP header on the target side.  This is the standard 6pin .05" header with the top two pins (Vcc and Rx) offset by an extra .025".  This makes the header uni-directional and will make it harder to accidentally cross Vcc and Gnd.
     
    I also put together an eagle library with 4 and 6 pin versions (with and without the RX/TX lines) of the headers as well as the tag-connect footprints.  There are two versions of the cable; one with retainer clips and one without, so there are two versions of the footprint...one with extra holes and one without.  I will warn you that to get signal lines to the footprint with the retainer holes, you will need to use 6mil traces and you will violate the 15mil from drills rule that OSHpark has.  It's right on the edge though, so I'm not sure if it is really a problem or not.
     
     
    Everything is up on my github and I've attached a static copy to this post.  I haven't ordered or built these yet, so there is a chance that I mixed something up.  I'll keep things up to date on the github though.
     
    github.com/mjbeals/LaunchFET
     
     
     
    LaunchFET.zip
  17. Like
    mbeals reacted to t0mpr1c3 in source for low cost small run PCBs?   
    OSHpark quality is first class. For small boards, or if you only want 3 of something, they are best. Shipping is free to USA.
     
    There are several Chinese outfits that will do 10 50x50mm PCBs for $10 plus postage. I recommend Elecrow. Elecrow allow a colour option for free and have the most transparent shipping charges. In my limited experience their customer service is more responsive than Seeedstudio.
  18. Like
    mbeals reacted to spirilis in Help in interfacing cc2541 BLE sensortag with msp430   
    Yeah I know about that one. Don't have any sub1GHz stuff atm though. An msp430+BLE or zigbee would be cool.
     
    Sent from my Galaxy Note II with Tapatalk 4
     
     
  19. Like
    mbeals got a reaction from Kras4ooo in Bluetooth and MSP430G2   
    Simplify the problem a bit.  Just make the loop write a single char (I like U...) and see if you can read it in a serial program.  I would consider using realTerm over putty for debugging uart issues as well.  It has a lot of good features for digging down to the raw byte stream, including a nice indicator light that tells you when there are framing errors.
  20. Like
    mbeals got a reaction from alibaba in sensor interface with launchpad msp430 using energia   
    Okay.  So it sounds like you want to interface with a generic serial terminal (Putty, minicom, etc) and not write a custom piece of software for the computer side of things.  It also sounds like a fairly low update rate to the MSP (if the user is hand typing things in).   In this case just do the string conversion on the MSP.   You might be able to use the implementation of atoi() in stdlib...if not it is a simple enough function to write.  Then you just need some code to buffer the incoming characters.  There are lots of examples here on this forum if you look, but the basic flow is to create a global array then use the UART rx interrupt to push incoming chars into the array.  Have it watch for the line term char ('\n') and set a flag when it sees it.  Your main loop looks for the flag on every loop and if it sees it, processes the buffer as a new pressure value and clears the flag.
  21. Like
    mbeals got a reaction from alibaba in sensor interface with launchpad msp430 using energia   
    ASCII is a method to transmit text strings.  Each character (including numbers) has a coresponding 8 bit value.  So if you want to transmit the number 255 over uart via ASCII encoding, you send the btye string:  0x32 0x35 0x35 0x0D where 0xD is the line term char...it tells the receiving software that you are done sending chars and to process everything it just received as one blob of text.
     
    If you send the number as an ascii string, the MSP will just have a four element buffer, which the control logic can't really use.  You have to write code (usually an atoi() function ) to decompose the ascii chars back into numbers and assemble them into a single number.    What I'm suggesting is to skip the ASCII conversion all together and just send the 8bit number the control loop needs over the UART as it is.  It eliminates all the conversion code on the MSP as well as the RX buffer and processing code...saves lots of valuable ticks.   For the LCD, just convert the number to ASCII on the MSP430 for display.  As long as your refresh rate on the LCD is less than the recieve rate of the updates, you will come out on top. (comverting every 5th or every tenth number as opposed to every number).
     
    Let me ask you this.... what is sending the pressure data to the MSP430?  Is it software you wrote?
  22. Like
    mbeals got a reaction from alibaba in sensor interface with launchpad msp430 using energia   
    Are you planning on interfacing with the device through a terminal (like putty), or programatically (labview, python, etc).  If you don't require a user friendly CLI, you don't have to mess with ascii at all.  The serial line is just transmitting single bytes at a time.  The translation to ascii characters and line termination is just one way of interpreting that byte data.  If all you are sending the unit is an 8 bit update to the pressure, then just write that byte straight to the UART.  This also lets you update faster, as using ascii encoding, you would need 4 bytes (3 digits plus termination) to represent a single byte of data.  The only downside is that you won't have a friendly terminal to watch or interact with...although there are terminal programs (I like realTerm) that let you change to formatting and read/write in raw hex/dec/binary as well as ASCII
  23. Like
    mbeals got a reaction from alibaba in sensor interface with launchpad msp430 using energia   
    Do you need to maintain galvanic isolation between the sensor and the launchpad?  Instead of attempting to level shift, it might be worth just adding an isolated ADC to the sensor package.  The analog side would accept the 5V supply and read 0 to 5V (assuming rail to rail) while the digital side would be powered from the launchpad's 3.3V supply.  Instead of using the ADC on the MSP430, you would read theis chip over I2C or SPI.  It's likely a simpler package (circuit-wise) and will likely have better performance than the ADC built into the MSP430.
  24. Like
    mbeals got a reaction from grahamf72 in sensor interface with launchpad msp430 using energia   
    Do you need to maintain galvanic isolation between the sensor and the launchpad?  Instead of attempting to level shift, it might be worth just adding an isolated ADC to the sensor package.  The analog side would accept the 5V supply and read 0 to 5V (assuming rail to rail) while the digital side would be powered from the launchpad's 3.3V supply.  Instead of using the ADC on the MSP430, you would read theis chip over I2C or SPI.  It's likely a simpler package (circuit-wise) and will likely have better performance than the ADC built into the MSP430.
  25. Like
    mbeals reacted to KatiePier in External crystal load capacitance   
    Hi @@mbeals!
     
    The effective load capacitance (1pf) value is really the impact on the effective load, the impact that is coming from the 2pF that is on each pin - so the two notes are really describing the same thing. Basically, there's 2pF on each pin, which is 1pF when taken as a whole for the crystal (it's how the value comes out depending on which side of the equation you put it on - on the side where you are plugging in per-pin values, or the side where you're getting your effective load capacitance).
     
    If you haven't seen it yet, a good resource is the MSP430 32kHz crystal oscillators app note: www.ti.com/lit/pdf/slaa322
    Section 2.1 includes an example of how to calculate your required capacitance. If you use this equation, the Cparasitic is referring to the per pin (2pF) value, so that's what you'd plug in.
     
×
×
  • Create New...