Jump to content

enl

Members
  • Content Count

    341
  • Joined

  • Last visited

  • Days Won

    22

Reputation Activity

  1. Like
    enl got a reaction from tripwire in Optimization Problem   
    Without volatile: The compiler recognises that the loop has no net effect and that the end result will be that b==0. Therefore, the loop is replaced with an assignment.
     
    With volatile: the compiler presumes that, even if it can't see it, something, somewhere, may be looking at the value of b other than the code in the loop. Therefore, it a.) compiles the code exactly as written, with b.) no optimizations, and c.) not using a register for the variable (it will always be in RAM, with the associated time penalty for access)
  2. Like
    enl got a reaction from abecedarian in Optimization Problem   
    Without volatile: The compiler recognises that the loop has no net effect and that the end result will be that b==0. Therefore, the loop is replaced with an assignment.
     
    With volatile: the compiler presumes that, even if it can't see it, something, somewhere, may be looking at the value of b other than the code in the loop. Therefore, it a.) compiles the code exactly as written, with b.) no optimizations, and c.) not using a register for the variable (it will always be in RAM, with the associated time penalty for access)
  3. Like
    enl got a reaction from Fred in Optimization Problem   
    Without volatile: The compiler recognises that the loop has no net effect and that the end result will be that b==0. Therefore, the loop is replaced with an assignment.
     
    With volatile: the compiler presumes that, even if it can't see it, something, somewhere, may be looking at the value of b other than the code in the loop. Therefore, it a.) compiles the code exactly as written, with b.) no optimizations, and c.) not using a register for the variable (it will always be in RAM, with the associated time penalty for access)
  4. Like
    enl got a reaction from spirilis in Optimization Problem   
    Without volatile: The compiler recognises that the loop has no net effect and that the end result will be that b==0. Therefore, the loop is replaced with an assignment.
     
    With volatile: the compiler presumes that, even if it can't see it, something, somewhere, may be looking at the value of b other than the code in the loop. Therefore, it a.) compiles the code exactly as written, with b.) no optimizations, and c.) not using a register for the variable (it will always be in RAM, with the associated time penalty for access)
  5. Like
    enl got a reaction from tripwire in Add sample rate on msp430g2553   
    Short overview:
     
    There are several things that come into play with the timing
     
    a.) the internal ADC clock rate and ADC hardware, which limits you to a practical guarenteed sample rate of about 200KHz. This is due to the required number of clock cycles for an ADC conversion, the tolerance on the internal ADC clock, and the analog circuitry properties.
     
    b.) How often YOU request the ADC do a conversion.
     
     
    To sample at a given low rate, the structure I would use is, roughly:
     
    Set up a timer to interrupt at the desired sample rate. The interrupt handler requests the ADC to do a single conversion.
    Set up the ADC to do single conversion on the desired input channel and interrupt when complete
    The ADC handler gets he converted value and does whatever is needed to get your main loop to handle it (sets a flag; takes the device out of LPM; whatever)
     
    The main loop actually handles the data. The interrupts do minimal work: initiate a reading in the timed interrupt and get the data/signal the main to deal with it in the ADC handler.
     
     
    There will be little jitter on the acquisitions, as the interrupt latency for the timed interrupt is the principal issue, and is typically less than a dozen clocks. If there isn't a lot of processing to do, you might even get away with 32KHz xtal for your main clock, rather than the DCO, and keep power low while avoiding the wake up latency from LPM. Probably not needed for this application, as the timing isn'y likely to be that critical.
  6. Like
    enl got a reaction from DeepBlueSky in Low power Geiger counter with MSP430G2553 (Last updated: May 07, 2015)   
    don' bother float.... If the value won't overflow (less than about 650*10^6 decimal), mult by 3 than divide by 100. The mult by three can be done as `(i<<1)+i'. This will give an int value truncated.
     
     
    You can avoid the div by 100 completely. After the sprintf, insert a decimal point before the last two digits. This requires that the value is >= 100 decimal, or there won't BE anything before the last two digits. This can be handled by forcing leading zeroes for 3 dig if value is <100 (using a condition and two sprintf's... one for each case)
  7. Like
    enl got a reaction from cubeberg in Low power Geiger counter with MSP430G2553 (Last updated: May 07, 2015)   
    Use long int (or long unsigned) and use `ld'  (lowercase ell d )instead of `d' in the format string for sprintf. `d' is standart int. `ld' is long int.
     
     
    The only info sprintf has about the type is from the format string, so if you spec standard int, whatever the param is, even if it is a long, will be interpreted as a standard int.
  8. Like
    enl got a reaction from DeepBlueSky in Low power Geiger counter with MSP430G2553 (Last updated: May 07, 2015)   
    Use long int (or long unsigned) and use `ld'  (lowercase ell d )instead of `d' in the format string for sprintf. `d' is standart int. `ld' is long int.
     
     
    The only info sprintf has about the type is from the format string, so if you spec standard int, whatever the param is, even if it is a long, will be interpreted as a standard int.
  9. Like
    enl got a reaction from mfpek in LaunchPad, DC Motor, PWM   
    @mfpek: Could you please give a bit more detail? What do ou mean 'control it with buttons'? With a microcontroller? If so, MSP430 or a different one?  No microcontroller? I don't think anyone can really provide an answer without more information.
     
    Is this for a school assignment? (if so, it is good practice tosay so and to tell us what school/course/level) Also, is English not your primary language? Again, that is something worth mentioning before you get the 'sounds like homework, ask your teacher' response.
  10. Like
    enl got a reaction from mfpek in LaunchPad, DC Motor, PWM   
    Any pin you want to use that is not already in use will work  if you don't use interrupts. If you do use interrupts, then the pin must support that, which should include the unused P1 pins.
     
    If you don't need the start-stop function, you could re purpose the existing buttons for increase forward/decrease reverse and increase reverse/decrease forward. If you need to keep the existing function, add two more. In and case, with the run forward and run reverse as it is, I would put in code to protect from changing direction while the motor is running, including a delay to insure that the motor is stopped before restart.
  11. Like
    enl got a reaction from spirilis in Happy Thanksgiving,   
    Just finished watching WKRP turkey drop episode.
     
     
    Happy Thanksgiving
  12. Like
    enl got a reaction from abecedarian in Happy Thanksgiving,   
    Just finished watching WKRP turkey drop episode.
     
     
    Happy Thanksgiving
  13. Like
    enl got a reaction from JuliaJose in Maximum input frequency detectable by MSP430g2553   
    Pusle width of pulses in pulse train? That doesn't sound analog to me, either.
     
    So, in the interest of getting a meaningful answer, please clarify what the input signal is and what you want to know about it.
     
    Is it analog? Digital?
    Do you want frequency? Pulse width of individul pulses? Period of the periodic signal?
     
     
    Addressing a couple options:
    I believe Pulsein() will get the width of a digital pulse (I think it is the '1' state time), and is the appropriate tool if that is what you want. This would be appropriate when you are decoding a PWM signal.
    You can also measure the period (time from rising edge to the next rising edge), though I don't know how in Energia. This can be used to derive the frequency. For example, if the period is 32microseconds, the frequency is 1/0.000032 = 31250Hz. The timing precision can be a real issue measuring single cycles/pulses.
    You can also measure frequency directly but counting pulses (rising edges) for a fixed time. The simplest case is count for 1sec. Counting for a shorter time is obviousl faster, but reduces precision.
     
    If the signal is analog, you need to tell us more about the signal and what you are trying to do.
  14. Like
    enl got a reaction from JuliaJose in Maximum input frequency detectable by MSP430g2553   
    Well, simple, but not very useful, answer is fastest conversion the unit can do is a bit over 2uSec, for a bit fewer than 500000 conversions per sec, giving a max frequency that can be properly sampled of about 250Khz (Nyquist limit).
     
    This is presuming that max allowable ADC clock rate of 6.3MHz and a way to store samples at this rate.
     
    If you are using the internal ADC clock, the clock is not a precision device, allowing for significant variation with power supply voltage, temp, and manufacturing. This means we should really look at the max that is guarenteed achievable, which would be the lowest rate, or about 6uSec/sample, for about 170000 sampes/sec, and a max frequenc to be sampled of about 80Khz, again, presuming that you have a way to store and process the samples.
     
    In reality, with all of the other issues involved, I would say audio (20KHz) is the practical high end.
     
    Remember, there isn't a lot of RAM on these devices (512 bytes), so you won't be able to store very many samples before you run out. Maybe 200, maybe fewer, given that some of the RAM is needed for other things (variables, stack, etc). If the data is being shipped rght off device, there is no practical limit, as you can ship it out faster than you can read it at top processor speed.
     
    See SLAS735J, P39 for timing of ADC
  15. Like
    enl reacted to RobG in halloween 2014   
    My 2014 Halloween project, Enderman. 
     
    It's still not finished, at least not the way I wanted. My wife told me this morning that we are going to Halloween parade, so I had to scramble and finish it by 6pm today. Meaning lots of duct tape. When finished properly, the entire head will be covered.
     
    Each eye has 12 WS2812 LEDs, MSP430G2553 control, powered from 4 x AA.
    At full brightness, eyes were perfect in the evening, but once it got dark, they were little too bright (on the bright side, they could see what candy is in the basket )
    I think I will have to add light sensor or at least brightness switch/pot.
    Light boxes should also be taller. I added extra 0.25" on top and bottom so that LEDs are not visible, but they still are, especially when head is tilted.
     
     

  16. Like
    enl got a reaction from pabigot in Convert char to integer issue   
    This thread is now required reading for my intro programming students. And now I also understand (or at least think I do)  more about how Python strings work, as well as the character and string encodings in modern practice.
  17. Like
    enl got a reaction from spirilis in Convert char to integer issue   
    This thread is now required reading for my intro programming students. And now I also understand (or at least think I do)  more about how Python strings work, as well as the character and string encodings in modern practice.
  18. Like
    enl reacted to pabigot in Convert char to integer issue   
    That depends on the level you're working at. Yes, at the bottom it's all bytes (or bits, or transistor states, or whatever). In C, you're nominally limited to text that can be expressed as ASCII characters, and the side comment that led us down this rabbit hole was prompted by the OP's confusion between text strings and sequences of characters and NUL-terminated sequences of characters: three distinct concepts.
     
    Even if it's not necessary to completely understand a specific subtlety at a particular stage of development, I do think it's worth a hic sunt dracones (i.e., "by the way, you're making an assumption here that won't always work out for you").
     
    Back to the lecture.
     
    Unlike C, in Python unicode strings are a first-class data type. You can operate on them (calculate length, extract substrings, sort, catenate) with complete disregard for how the text is represented as a sequence of characters, and how each character is represented. Similarly you can do this with C++11 with wide character support. In practice, these systems generally use UCS-16 or UCS-32 underneath, but to the developer it's just text of some arbitrary language.
     
    In these environments, you can certainly manipulate and display ??????? without caring how that string is encoded in memory or by the I/O subsystem (which might translate for you from the internal representation to the encoding specified by the environment, e.g. the LANG variable or a previous invocation of setlocale(3)). In an embedded environment, you are more likely to need to know that the display you're writing to requires a specific byte to represent a specific character (extended ASCII), or that you must do the translation from characters to glyph bitmaps yourself.
     
    Here's an example Python program to play with. It works in both Python 2 (2.6+?) and Python 3.
    # -*- coding: utf-8 -*- from __future__ import unicode_literals; import binascii te = 'text' de = te.encode('utf-8') print(type(te)) print(type(de)) print(te) print(binascii.hexlify(te)) print(de) print(binascii.hexlify(de)) print(te == de) tr = '???????' dr = tr.encode('utf-8') print(tr) print(binascii.hexlify(tr)) print(dr) print(binascii.hexlify(dr)) print(tr == dr) In Python 2, the t* values have type unicode and the d* values have type str. (Without the "from __future__" line the t* values would also have type str because Python 2 failed to distinguish sequences of (ASCII) characters from sequences of bytes.) 
    In Python 3, the t* values have type str and the d* values have type bytes.
     
    The output from this under Python 2 is:

    llc[49]$ python /tmp/x.py <type 'unicode'> <type 'str'> text 74657874 text 74657874 True ??????? Traceback (most recent call last): File "/tmp/x.py", line 20, in <module> print(binascii.hexlify(tr)) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-6: ordinal not in range(128) In the first block, you see that the text and encoded versions have the same bit representation and compare equal, even though they have different types. 
    The second block blows chunks, because binascii.hexlify() can't operate on strings that have non-ASCII characters. If you comment out that line, you get a warning and the two strings are not equal.
     
    Under Python 3.4.2 you have to comment out the hex conversion of the text versions because it doesn't know how to convert Unicode to bytes, but doing that you get:

    llc[50]$ /usr/local/python-3.4.2/bin/python /tmp/x.py <class 'str'> <class 'bytes'> text b'text' b'74657874' False ??????? b'\xd1\x8d\xd0\xbd\xd0\xb5\xd1\x80\xd0\xb3\xd0\xb8\xd1\x8f' b'd18dd0bdd0b5d180d0b3d0b8d18f' False Even for the strings that are entirely ASCII, the text and the UTF-8 encoded text are not equal, because Python 3 distinguishes them by type. 
    This is why, in unit tests where I was checking whether the XML was right, it was necessary to know whether the XML was text or had been encoded in some way, e.g. for storage on disk. This arose in part because Python's standard library for converting Document Object Model (DOM) representations of XML into "XML" produces encoded text ready to be transferred to another system, not Unicode strings suitable for use in the application.
  19. Like
    enl reacted to pabigot in Convert char to integer issue   
    I'm gonna have to object, mostly because your statements on XML and programming for Unicode are unclear in a way that obscures my main point. So I'm going to expand on that main point and try to clarify XML along the way.
     
    There is a strict conceptual difference between text and representations of text by encoding schemes such as ASCII and Unicode, just as there's a difference between integers and representations of integers as two's complement, one's complement, or sign-magnitude. I'm trying to express two points: first, be aware of that difference; and second, take into account the possibility of alternative representations.
     
    UTF-8 only uses single-byte encodings for characters that are in the ASCII character set (U+0000 through U+007F). The representation of character U+0080 (integer value 0x80 = 128) in UTF-8 is a two-byte sequence hex "C2 80".
     
    The only time ASCIIZ and UTF-8 representations are equivalent is when the encoded text is ASCII and the UTF-8 indicates text length by a terminating null. While any standard ASCII C string is bitwise equivalent to its null-terminated UTF-8 encoded representation, many UTF-8 encoded strings cannot be expressed as ASCII strings.
     
    This means that "the content of a is ASCIIZ" tells you something very different about how a can be used than what you're told by "the content of a is null-terminated UTF-8". My original point: clearly document your data objects so the reader knows what they contain.
     
    XML (which I selected only as an example) by definition uses characters from Unicode. If you're using a language that has a Unicode text data type (unicode in Python 2, str in Python 3, std::wstring in C++ 11) then you will operate on XML text as Unicode characters, using length, copy, catenation, and other functions that manipulate Unicode data and that are distinct from the corresponding narrow-character C functions. You would not operate on them as text in their encoded form with those narrow-character C functions.
     
    Encoding comes into play when you need to transfer the text to another system (via storing in a file or sending it over a network). Then you can encode it as UTF-8, UTF-16, UTF-32, shift_jis, or whatever. This representation is not text: it is a sequence of integral values representing code points. If the values are not 8-bit then you also need to know byte ordering before you can treat it as a sequence of octets. For XML, absence of an encoding declaration requires that the content be UTF-8 or UTF-16. (This may be what you meant by "disagree on storing xml text being different from storing xml UTF-8 encoded...the default text encoding is UTF-8".)
     
    My whole point was: In early PyXB I mistakenly assumed text and data were identical, because by chance that happened that everything I encountered was the ASCII subset of Unicode. This was an error, demonstrated when somebody used PyXB for (non-romaji) Japanese; I certainly never intended PyXB to only support English. After a fair amount of gratuitous rework, PyXB is very robust for languages where text can't be represented in ASCII. The lesson: Unless you know absolutely that you're dealing only with ASCII text in C, keep in mind from the beginning that text and the representation of text as data are two distinct things.
     
    I don't know what Windows does, but in modern POSIX systems like Linux the default text encoding is specified by the "C" or "POSIX" locale which uses the POSIX portable character set which is a subset of ASCII. UTF-8 is what POSIX calls a "state-dependent encoding", and is not the default. On my Linux systems I have to specifically override the environment variable LANG to en_US.UTF-8 to enable UTF-8 encoding to see non-ASCII content.
  20. Like
    enl reacted to veryalive in A buffer?   
    A very handy buffer IC, and often under utilized, is the CMOS 4050 (MC14050, CD4050, etc...     also in HC ).
    This is a cheap way to protect AND translate high voltages (up to 15v) down to the low voltages (+-3.6) tolerable by the MSP430.
     
     
    With this buffer, you can safely input digital signals into the MSP430 which have a HIGHER voltage than the MSP430 supply !
     
     
    Connect the 4050 supply voltage (Vdd) and ground (Vss) to the MSP430 supply & ground, and the 4050 buffer output(s) to the 430 input pin(s) ----  then 'external world' digital signals go to the respective 4050 inputs.
     
     
     
    Please refer to the 4050 - type datasheet and read it a few times and then get a few parts, they are very cheap.
  21. Like
    enl got a reaction from abc in A buffer?   
    buffers are used for protection even by the pro's to protect the expensive parts.
     
    Key words are: the expensive parts. Expensive in direct cost, or in down time and repair.
     
    If you are using the Gseries LP, the buffer costs almost as much as the microcontroller (between the IC, board space, etc), and limits you to only digital I/O, as well as requiring extra work to set up the buffer for input or output as needed, which costs time, complexity, and probably I/O pins.
     
    With most microcontrollers, most or all pins serve more than one potential purpose, such as digital I/O, A/D input, PWM output, and edge trigger digital input. In many designs, they same pin mightserve morethan one purpose at different times. For a system designed for beginners/prototyping, each pin must beable to serve all of its design purposes. This pretty much prohibits designing buffers/isolaters in. When I can buy a dozen 430s for under $1.50 each, the board space and extra component cost for buffers just isn't worth it in general.
     
    There is no way to protect a newbie from all mistakes. Or an experienced designer, for that matter. They occur. The best you can do is pick methods based on the applicaion to minimize the risk of damage due to abnormal events that you can anticipate, such as reversing a connector (back in the days of RS232 that was part of the spec), putting a connector on wrong (a concern with unkeyed headers), ground faults, and the like.
     
    In a design for motor control, Itend to use driver ICs where I can, and isolation resistors as well. With direct drive to a transistor, ALWAYS use resistors to limit current and diodes to shunt flyback/back EMF. For digital lines used only for a single purpose, buffers are a good idea, but you still need to be sure nofault will occur during startup or reset.
     
    Connector configuration is an art. Many comon specs are not very good, such as the spec for model servo connectors (keying is optional) where damage can occurif the connector is reversed. Power connectors and combined power/I/O connectors are even more critical. Back in the day, it was common to find discount cables for floppy drives and hard drives without the key plug, or connectors without the removed key pin. Put the cable on backwards, or one pin off, and damage was certain, due to the pin layout. Some connectors (the 20 pin HD data line used prior to IDE, for example) were not keyed at all, and very pricey damage was not unusual.
     
    General rules for connectors are to make best effort to use symmetry to prevent damage from reversal, and to try to prevent damage from one-pin-over if that is possible. I generally put groud at the outside, symmertically, and, if there is power, do the same, so reversal isn't an issue there. I try, when I can, to keep signal lines symmetric for reversal as well. Input to input, output to output.
     
    Better yet, use keyed connectors, like a D-type, or a keyed header. Not always possible. The launchpad, for example, is unkeyed. The most annoying feature of the Arduino (the half-space header) has the positive effect of keying the connector, IF all pins are present. Many boards don't include unused pins (like the analog ones if no analog inputs) and can be forced in the wrong way.
     
    What you are asking in your last line is, unfortunately, not something that can be generally done. Back in the day when low power was watts, a fuse or lightbulb, or other device was the answer. Today, when milli or microwats can cause damage, there isn't a lot to do. Fortunately, the MSP430 devices are pretty tolerant of many common failures. The outputs will drive a short to ground or power with little risk of damage. Sligh overvoltage on an input is generally ok. Many other devives (PIC, for example) are a lot less tolerant, and in an educational environment, tend to be replaced often due to student mistakes.
  22. Like
    enl got a reaction from MORA99 in A buffer?   
    buffers are used for protection even by the pro's to protect the expensive parts.
     
    Key words are: the expensive parts. Expensive in direct cost, or in down time and repair.
     
    If you are using the Gseries LP, the buffer costs almost as much as the microcontroller (between the IC, board space, etc), and limits you to only digital I/O, as well as requiring extra work to set up the buffer for input or output as needed, which costs time, complexity, and probably I/O pins.
     
    With most microcontrollers, most or all pins serve more than one potential purpose, such as digital I/O, A/D input, PWM output, and edge trigger digital input. In many designs, they same pin mightserve morethan one purpose at different times. For a system designed for beginners/prototyping, each pin must beable to serve all of its design purposes. This pretty much prohibits designing buffers/isolaters in. When I can buy a dozen 430s for under $1.50 each, the board space and extra component cost for buffers just isn't worth it in general.
     
    There is no way to protect a newbie from all mistakes. Or an experienced designer, for that matter. They occur. The best you can do is pick methods based on the applicaion to minimize the risk of damage due to abnormal events that you can anticipate, such as reversing a connector (back in the days of RS232 that was part of the spec), putting a connector on wrong (a concern with unkeyed headers), ground faults, and the like.
     
    In a design for motor control, Itend to use driver ICs where I can, and isolation resistors as well. With direct drive to a transistor, ALWAYS use resistors to limit current and diodes to shunt flyback/back EMF. For digital lines used only for a single purpose, buffers are a good idea, but you still need to be sure nofault will occur during startup or reset.
     
    Connector configuration is an art. Many comon specs are not very good, such as the spec for model servo connectors (keying is optional) where damage can occurif the connector is reversed. Power connectors and combined power/I/O connectors are even more critical. Back in the day, it was common to find discount cables for floppy drives and hard drives without the key plug, or connectors without the removed key pin. Put the cable on backwards, or one pin off, and damage was certain, due to the pin layout. Some connectors (the 20 pin HD data line used prior to IDE, for example) were not keyed at all, and very pricey damage was not unusual.
     
    General rules for connectors are to make best effort to use symmetry to prevent damage from reversal, and to try to prevent damage from one-pin-over if that is possible. I generally put groud at the outside, symmertically, and, if there is power, do the same, so reversal isn't an issue there. I try, when I can, to keep signal lines symmetric for reversal as well. Input to input, output to output.
     
    Better yet, use keyed connectors, like a D-type, or a keyed header. Not always possible. The launchpad, for example, is unkeyed. The most annoying feature of the Arduino (the half-space header) has the positive effect of keying the connector, IF all pins are present. Many boards don't include unused pins (like the analog ones if no analog inputs) and can be forced in the wrong way.
     
    What you are asking in your last line is, unfortunately, not something that can be generally done. Back in the day when low power was watts, a fuse or lightbulb, or other device was the answer. Today, when milli or microwats can cause damage, there isn't a lot to do. Fortunately, the MSP430 devices are pretty tolerant of many common failures. The outputs will drive a short to ground or power with little risk of damage. Sligh overvoltage on an input is generally ok. Many other devives (PIC, for example) are a lot less tolerant, and in an educational environment, tend to be replaced often due to student mistakes.
  23. Like
    enl got a reaction from igor in A buffer?   
    buffers are used for protection even by the pro's to protect the expensive parts.
     
    Key words are: the expensive parts. Expensive in direct cost, or in down time and repair.
     
    If you are using the Gseries LP, the buffer costs almost as much as the microcontroller (between the IC, board space, etc), and limits you to only digital I/O, as well as requiring extra work to set up the buffer for input or output as needed, which costs time, complexity, and probably I/O pins.
     
    With most microcontrollers, most or all pins serve more than one potential purpose, such as digital I/O, A/D input, PWM output, and edge trigger digital input. In many designs, they same pin mightserve morethan one purpose at different times. For a system designed for beginners/prototyping, each pin must beable to serve all of its design purposes. This pretty much prohibits designing buffers/isolaters in. When I can buy a dozen 430s for under $1.50 each, the board space and extra component cost for buffers just isn't worth it in general.
     
    There is no way to protect a newbie from all mistakes. Or an experienced designer, for that matter. They occur. The best you can do is pick methods based on the applicaion to minimize the risk of damage due to abnormal events that you can anticipate, such as reversing a connector (back in the days of RS232 that was part of the spec), putting a connector on wrong (a concern with unkeyed headers), ground faults, and the like.
     
    In a design for motor control, Itend to use driver ICs where I can, and isolation resistors as well. With direct drive to a transistor, ALWAYS use resistors to limit current and diodes to shunt flyback/back EMF. For digital lines used only for a single purpose, buffers are a good idea, but you still need to be sure nofault will occur during startup or reset.
     
    Connector configuration is an art. Many comon specs are not very good, such as the spec for model servo connectors (keying is optional) where damage can occurif the connector is reversed. Power connectors and combined power/I/O connectors are even more critical. Back in the day, it was common to find discount cables for floppy drives and hard drives without the key plug, or connectors without the removed key pin. Put the cable on backwards, or one pin off, and damage was certain, due to the pin layout. Some connectors (the 20 pin HD data line used prior to IDE, for example) were not keyed at all, and very pricey damage was not unusual.
     
    General rules for connectors are to make best effort to use symmetry to prevent damage from reversal, and to try to prevent damage from one-pin-over if that is possible. I generally put groud at the outside, symmertically, and, if there is power, do the same, so reversal isn't an issue there. I try, when I can, to keep signal lines symmetric for reversal as well. Input to input, output to output.
     
    Better yet, use keyed connectors, like a D-type, or a keyed header. Not always possible. The launchpad, for example, is unkeyed. The most annoying feature of the Arduino (the half-space header) has the positive effect of keying the connector, IF all pins are present. Many boards don't include unused pins (like the analog ones if no analog inputs) and can be forced in the wrong way.
     
    What you are asking in your last line is, unfortunately, not something that can be generally done. Back in the day when low power was watts, a fuse or lightbulb, or other device was the answer. Today, when milli or microwats can cause damage, there isn't a lot to do. Fortunately, the MSP430 devices are pretty tolerant of many common failures. The outputs will drive a short to ground or power with little risk of damage. Sligh overvoltage on an input is generally ok. Many other devives (PIC, for example) are a lot less tolerant, and in an educational environment, tend to be replaced often due to student mistakes.
  24. Like
    enl got a reaction from abc in Embedded for a 10 year old?   
    not yet there other than special uses.
     
    Pricey, high resistance, not environmentally tolerant enough
  25. Like
    enl got a reaction from abecedarian in Embedded for a 10 year old?   
    not yet there other than special uses.
     
    Pricey, high resistance, not environmentally tolerant enough
×
×
  • Create New...