Jump to content

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    gordon got a reaction from fj604 in The portable LaunchPad   
    No, really. The portable LaunchPad .
     
    Some time back I inherited a big pile of used, impractical-to-reuse DAT tapes. They've been lying around not doing much useful, but the arrival of the LaunchPad triggered an idea: their cases are ideal containers for small stuff.
     
    I keep an LP and a separate box of assorted random junk in my backpack all the time; they are safe (the cases are quite sturdy and close well), and are always at hand, should some time for a hacking session be found.
     

    Add a third one with one of these tiny breadboards and a couple of flexible jumper wires, and you have a full-fledged lab-on-the-go in space less than two packs of cigarettes .
     
    The cases also make nice storage for components in general -- a bit hard to fish things out of them (definitely harder than these storage units with drawers), on the plus side it's also much harder to spill half a million stingy beasts on the carpet.
  2. Like
    gordon got a reaction from gatesphere in The portable LaunchPad   
    No, really. The portable LaunchPad .
     
    Some time back I inherited a big pile of used, impractical-to-reuse DAT tapes. They've been lying around not doing much useful, but the arrival of the LaunchPad triggered an idea: their cases are ideal containers for small stuff.
     
    I keep an LP and a separate box of assorted random junk in my backpack all the time; they are safe (the cases are quite sturdy and close well), and are always at hand, should some time for a hacking session be found.
     

    Add a third one with one of these tiny breadboards and a couple of flexible jumper wires, and you have a full-fledged lab-on-the-go in space less than two packs of cigarettes .
     
    The cases also make nice storage for components in general -- a bit hard to fish things out of them (definitely harder than these storage units with drawers), on the plus side it's also much harder to spill half a million stingy beasts on the carpet.
  3. Like
    gordon got a reaction from sukr4m in MSPGCC to IAR   
    MSPGCC4 as such does not support any JTAG, it's a compiler (well, toolchain) to compile your things and produce binaries from source.
     
    Uploading the binary to the MSP430 and debugging is a different matter. MSPDebug claims support for the JTAG-TINY (assuming we all mean the Olimex one), and works on Windows (check their FAQ).
     
    The error you are having is one of the differences between MSPGCC and IAR (IAR uses pragmas for this kind of thing). I remember having bumped into quite some sites that explain the differences (usually in the other way around, though), but - as I was not particularly interested myself - I didn't bookmark any. I'm sure google will find some, though.
     
    Next time, try less screenshots please.
  4. Like
    gordon got a reaction from zeke in MSP430 data acquisition from multiple sensors   
    Are you saying you have tried, did not succeed and gave up on Blinky, everyone's best friend?
     
    You really have to do this. Everything starts with Blinky. A simple output is Blinky. Making it blink are timers. Timers are clocks. Making Blinky glow is PWM. Add a simple button and/or a pot -- inputs, interrupts, ADC.
     
    Without a strong command of these facilities any microcontroller project (not just MSP430, these are general concepts) is a quick way down. You really have to begin at the beginning. There are no shortcuts at this stage. For me, it took the Davies book, a LaunchPad, MSPGCC4, mspdebug and about three weeks to start getting the big picture. There really is no way around this.
     
    Blinky is the alphabet and the times table of it all.
  5. Like
    gordon reacted to zeke in MSP430 data acquisition from multiple sensors   
    You may need to step back from the details of your project for a little bit because you sound like you're drowning in the details.
     
    Oh, and stop hyperventilating. As Douglas Adams said, Don't Panic!
     
    I think you should take a tour of the MSP430 to get a feel for how things are done with it. Normally, folks try out the blinking LED sample program.
     
    I think you should also take a look at this thread. It's a collection of notes for MSP430 Beginner's. It will point out some resources that you can use to help you get up to speed. Take special note of the Davies book. It's the best one out there.
     
    Once you sort out how to drive the MSP430 then you can begin to design your system.
     
    I'll give you my approach and you can see if it might work for you. I may have to use some analogies to paint a picture in your mind. Compare those images to your situation to see if they might work.
     
    You've been asked to create a data logger. It has multiple sensors. Each sensor has it's own particular language. In the analogy, let's call them gears in a transmission. Temperature = 1st gear, Accelerometer (X,Y,Z) = 2nd gear, Time = 3rd gear and so on.
     
    The MSP430 is the engine. It spins the transmission. So, you have to get the engine running first.
     
    First, get the MSP430 running off of the 32kHz crystal. Solder on the little crystal that comes with the Launchpad.
    Then program the MSP430 to use that crystal. Your code should use interrupts. Generate an timer interrupt once a second. This is the engine speed. You will be able to change the RPM of the engine later, as needed.
     
    Then, you have to make the transmission work. This is where you would design a routine to blink a LED, or read a push button, or read the accelerometer, or write a byte to the SD card. The key is that you would do one thing at a time.
     
    So, as a test, write a blink LED routine. Then, make it blink in time with the 1 second interrupt. If you can turn the LED off or on then do that inside the interrupt routine. Just one thing though - on or off.
     
    After that, you have to add in each routine so that it will do its operation once every revolution of the timer.
     
    What you are building here is a state machine. The 1 second timer is the driving force of the state machine. The sub-routines are the individual states. You transition from state to state using time or input signals as triggers.
     
     
    Are you starting to see the big picture yet?
     
    Summary:
    Design your project as a state machine.
    Use the timer to run the state machine.
    Switch states using time intervals or input signals.
    Design each state to be a single operation that can complete in a short amount of time.
    Start small and simple.
    Design on paper first. I can't stress this enough. Know what you're doing before you begin coding.
     
    And, ask questions. There's a lot of smart and experienced people lurking here!
  6. Like
    gordon got a reaction from NatureTM in Value Line series easy DCO setting library   
    Just bumped into tinyos-msp430 (which is apparently not the same as the MSP430 support in mainline TinyOS).
     
    Relevance to this thread, notice "calibrate-dco" in the "featured downloads" section -- appears to be a quite beefed-up DCO calibration app, with goodies on the side (taking silicon errata into account for various devices when calibrating).
  7. Like
    gordon got a reaction from bluehash in Value Line series easy DCO setting library   
    Just bumped into tinyos-msp430 (which is apparently not the same as the MSP430 support in mainline TinyOS).
     
    Relevance to this thread, notice "calibrate-dco" in the "featured downloads" section -- appears to be a quite beefed-up DCO calibration app, with goodies on the side (taking silicon errata into account for various devices when calibrating).
  8. Like
    gordon reacted to RobG in HS-47 equivalent circuit   
    After quick look at your links I think all you need to do is put 4k7 or bit smaller (2k2) resistor between mic and gnd.
  9. Like
    gordon reacted to oPossum in HS-47 equivalent circuit   
    The spec says the mic bias voltage must be above 700 mV and less than 1750 mV for a headset.
     
    Try a shunt made from two 1N4148 or similar diodes in series connected to the mic line.
  10. Like
    gordon got a reaction from jsolarski in Guidelines for the Use of the C Language   
    If you program (or plan to program) in C, MISRA (Wikipedia) sells a document titled Guidelines for the Use of the C Language in Critical Systems (Wikipedia).
     
    I found that to be a well-though-out source of information for general secure coding techniques. It focuses on embedded usage, but most of the principles apply generally. The document includes the guidelines themselves, rationale and example code as well.
     
    What included are really things that should be natural and evident for all C programmers (embedded or not), but (in my experience) sadly courses or books dealing with security stuff are either few and far between or are too focused on one particular system/environment (certainly not embedded). This is a very condensed representation of the whys and hows of the pitfalls and the way to avoid them all of us should have been taught in school (or should be in a new edition of K&R at the very least). It will not make you an expert overnight, but it will be eye-opening.
     
    If you are a C beginner, some of the items may be overwhelming (or outright scary); if you are a seasoned veteran, there still might be angles you have not thought of before. Some of it is definitely an overkill for a hobbyist, but following the general principle might help one not burning the barn or irrigating a new Lake Victoria in the back yard .
     
    The current version (MISRA C2) deals with C89 only; MISRA C3 (which will include C99 constructs as well) is said to come later this year, so blackmailing Santa might be a good idea .
     
    I am not a frequent standards buyer, but I figure that GBP10 (+tax, if applies), for which you get a 100+ page PDF document (watermarked to your name) borders on impulse buying for a document of this kind.
     
    (Apart from having bought it, not affiliated with them.)
  11. Like
    gordon got a reaction from gatesphere in Guidelines for the Use of the C Language   
    If you program (or plan to program) in C, MISRA (Wikipedia) sells a document titled Guidelines for the Use of the C Language in Critical Systems (Wikipedia).
     
    I found that to be a well-though-out source of information for general secure coding techniques. It focuses on embedded usage, but most of the principles apply generally. The document includes the guidelines themselves, rationale and example code as well.
     
    What included are really things that should be natural and evident for all C programmers (embedded or not), but (in my experience) sadly courses or books dealing with security stuff are either few and far between or are too focused on one particular system/environment (certainly not embedded). This is a very condensed representation of the whys and hows of the pitfalls and the way to avoid them all of us should have been taught in school (or should be in a new edition of K&R at the very least). It will not make you an expert overnight, but it will be eye-opening.
     
    If you are a C beginner, some of the items may be overwhelming (or outright scary); if you are a seasoned veteran, there still might be angles you have not thought of before. Some of it is definitely an overkill for a hobbyist, but following the general principle might help one not burning the barn or irrigating a new Lake Victoria in the back yard .
     
    The current version (MISRA C2) deals with C89 only; MISRA C3 (which will include C99 constructs as well) is said to come later this year, so blackmailing Santa might be a good idea .
     
    I am not a frequent standards buyer, but I figure that GBP10 (+tax, if applies), for which you get a 100+ page PDF document (watermarked to your name) borders on impulse buying for a document of this kind.
     
    (Apart from having bought it, not affiliated with them.)
  12. Like
    gordon got a reaction from bluehash in Guidelines for the Use of the C Language   
    If you program (or plan to program) in C, MISRA (Wikipedia) sells a document titled Guidelines for the Use of the C Language in Critical Systems (Wikipedia).
     
    I found that to be a well-though-out source of information for general secure coding techniques. It focuses on embedded usage, but most of the principles apply generally. The document includes the guidelines themselves, rationale and example code as well.
     
    What included are really things that should be natural and evident for all C programmers (embedded or not), but (in my experience) sadly courses or books dealing with security stuff are either few and far between or are too focused on one particular system/environment (certainly not embedded). This is a very condensed representation of the whys and hows of the pitfalls and the way to avoid them all of us should have been taught in school (or should be in a new edition of K&R at the very least). It will not make you an expert overnight, but it will be eye-opening.
     
    If you are a C beginner, some of the items may be overwhelming (or outright scary); if you are a seasoned veteran, there still might be angles you have not thought of before. Some of it is definitely an overkill for a hobbyist, but following the general principle might help one not burning the barn or irrigating a new Lake Victoria in the back yard .
     
    The current version (MISRA C2) deals with C89 only; MISRA C3 (which will include C99 constructs as well) is said to come later this year, so blackmailing Santa might be a good idea .
     
    I am not a frequent standards buyer, but I figure that GBP10 (+tax, if applies), for which you get a 100+ page PDF document (watermarked to your name) borders on impulse buying for a document of this kind.
     
    (Apart from having bought it, not affiliated with them.)
  13. Like
    gordon got a reaction from C_Coffie in MSP430 LaunchPad Book?   
    To a considerable extent, you will be able to use other tutorials.
     
    Certain things will vary, of course, but - for example - I was able to follow John Davies' book (which is written using the Olimex starter kit with an MSP430F1121A) using the LaunchPad quite well. The basics - like I/O, lighting a LED, reading a button, using timers, getting familiar with the clocks, using the ADC, using interrupts, the power modes - will be pretty much the same. You may have to use different pins on the LaunchPad chips, sometimes you have only one Feature X on the LaunchPad chips while the F1121A may have more than one Feature X, but accounting for these is fairly straightforward.
     
    I (as apparently quite several other people here) have found the Davies book to be an excellent introduction and resource. At the price tag of a dozen LaunchPads, it is a bit pricey, but to me it was every penny well spent.
     
    This really goes for many (probably any) other MSP430 tutorials you may find. A little bit of common sense is enough to use them with the LaunchPad.
  14. Like
    gordon reacted to EngIP in Active high input?   
    Sorry if the point of this thread has sailed over my head, but does this page explain things better?
  15. Like
    gordon reacted to RobG in Active high input?   
    There are two settings for internal resistor when PxDIR is 0 (input) and PxREN is 1 (enabled)
    PxOUT = 0, resistor pulls down, input is active high
    PxOUT = 1, resistor pulls up, input is active low
     
    When PxDIR is 0 (input) and PxREN is 0 (disabled,) input will be floating and must be pulled externally or connected to push-pull output.
    When PxDIR is 0, PxOUT has no effect on output, just the resistor.
     
    PxDIR = 0, PxREN = 1, PxOUT = 1, input is active low

     
    PxDIR = 0, PxREN = 1, PxOUT = 0, input is active high

×
×
  • Create New...