Jump to content

enl

Members
  • Content Count

    341
  • Joined

  • Last visited

  • Days Won

    22

Reputation Activity

  1. Like
    enl got a reaction from dubnet in Cheap solar battery + wireless IoT node   
    The options are 1) a complete sealed setup, using the appropriate sealed penetration connectors, capable of holding against the pressure inside and out due to temp changes, 2) run the containment at a slight positive pressure,  3) ensure that moisture can get out before condensing, OR 4) pot that sucker up
     
    I have been involved in option 1 a couple of times, and it is expensive to do well. An ammo can is a decent containment, as long as the gasket is good and the temp changes arn't too great. It will breathe under great enough temp change.
     
    Option 2 is what communications providers often use on trunk lines. They may pressurize with nitrogen and seal it, or use a compressor and air drier. The second of these is why you see some of the little green lights on the boxes on telephone poles. Those are small compressor/driers, and pressure monitors. They alarm if pressure can't be maintained, and provide a small volume of dry air to make up miniscule leaks. I don't know what the pressure is, but I would guess a few inches of water (24 inches of water is about 1PSI; 1 inch of water is about 2mmHg, or about 2.6millibar. Residential gas is about 10 inches in the US)
     
    Option 3 I have used a number of times. Enough ventilation is needed low and high that temperature changes will induce air to move, the electronics are protected from direct impingement, but will follow temp changes fairly quickly so as to not get condensation, and the electronics want to be the warmest thing in the containment. One technique I have used a double roof model: slight overhang with vent at the top, open bottom, like a small garden shed, and the electronics in a box inside with bottom vents, but no top vents. Drip loops on wires entering are a must. Direct solar exposure to the containment is a no-no, as that is asking for after a rain, at the most humid time, the electronics lagging behind the dew point and inducing condensation.
     
    Option 4 is common in automotive and ruggedized gear. Pot it solid. Gotta do it right so moisture can't get in where leads enter the potting. Can be done with wax, silicone, some petro-based rubbers and plastics, or many other materials. The antique auto guys still use pitch for some things, both for insulation and moisture protection. Goes in hot, so moisture is removed and can't get back.
     
    One other option, used by the tool and gun guys, is not appropriate here, due to practical requirements: a small heater. Raises the dew point to prevent condensation, but takes a bit of power as well as running the electronics hotter than needed.
     
    I would use option 3 or 4. Even a low power device, in a small enclosure, running at a few milliwatts, will produce enough heat to keep the containment a degree or two above ambient. As long as no liquid can blow in, and the space around it is generally below the dew point, there isn't an issue, as the electronics will usually be at or above the temp of the surround except during the most extreme rises.
  2. Like
    enl got a reaction from xyiii in ADC MSP430 delay(20)   
    First, theory: The wikipedia page on aliasing isn't bad. ANY sample rate that is not a sub-multiple of your sine wave frequency (without considering phase) will give you data that looks like a sine wave at some frequency or another. The RMS and offset will be the same as the wave you are sampling, but the frequency will not.
     
    The original wave can be reconstructed from undersampled data in some cases IF there is other information available. This is how many oscilloscopes used to handle very high frequencies, and some still do, using low speed D/A converters. The TIMING of the samples on a 1ns scope is held to less than 1ns jitter, but the samples might be done very precisely at 500ns or more apart, timed at successively larger delays (1ns more per trigger) from the (repeating) trigger event. For a repetitive waveform, the waveform can be reproduced from samples spread over a large number of repetitions, as long as the max frequency is less than the 1ns (and a few other conditions are met.)
     
    Essentially, this is what you are doing, but in a free running way. If you know it is a stable sine wave, then all you need is the upper and lower peak to get RMS and offset. It does not matter which cycle you measure the peaks on. If you are trying to do true-RMS calculation, then you need more data, but, again, if the signal is stable and repetitive, it doesn't matter if all samples come from the same cycle. In fact, for these tasks, clock jitter and frequency aren't critical either.
     
    If you were trying to reproduce the waveform, not analyze  the basic properties, these would matter.
  3. Like
    enl got a reaction from xyiii in ADC MSP430 delay(20)   
    As @@bluehash said, to sample he input so as to get sufficient information to reproduce it, the sample rate needs to be greater than twice the maximum frequency in the signal.
     
    First, I messed up units in my post above. I intermingles 50 microseconds and 50 milliseconds. The concept still applies and content is correct otherwise...
     
    Second, we really need to know what you are trying to do for anyone to give a better response. Are you trying to synchronise to the input? Sample it like a digital oscillloscope? other? What development tools are you using (I presume from your post that the toolset you are using implements delay() as a millisecond delay, not microsecond)? What clock rate is your processor running at (if using  Energia, this is probably 16MHz+/- a few percent. If CCS, unless you change it, it is the processor default of 1MHz uncalibrated.) What is YOUR background (so we can go to the appropriate level of explanation)
     
    Short form: Nyquist demonstrated that to gain sufficient information about a sampled signal to reproduce it without aliasing (shifting frequency components to the wrong frequency), the sample rate must  be GREATER than twice the maximum frequency present in the input. (It is often stated that it must be EQUAL OR GREATER, but equal fails, as the sampled data then becomes phase dependent for the highest frequencies). It is better to sample at a minimum of 4 to 10 times the max frequency, as this reduces the need to interpolate and filter to get information, such as peak, power, frequency spectrum, and phase, and reduces the time required to gather enough samples to get this information (as there will be much less modulation due to interference between the sample frequency and the signal than if the sample rate is barely greater than the max frequency in the signal)
     
    The BEST way to do sampling is a stable clock (crystal controlled) and a sampling system with no jitter. This can be approximated on the MSP430 quite well by using interrupts and the hardware timers to control the process. In brief, you set a timer to interrupt at your sample rate, and the interrupt handler starts the next ADC cycle, giving a fairly well synchronized sample point. Having the ADC interrupt at the end of the conversion allows immediate handling of the result. This is not simple, but it isn't that complicated, either. To tell you more, we need to know more about what you are trying to do.
  4. Like
    enl got a reaction from MSPLife in Prevent reading code   
    You need to explicitly request the fuse be blown (or the flash equivalent on those without the physical fuse). I don't have a MSP-FET, and have never done it on these processors, but I have seen it in the documentation, and done it with other families.
     
    Blowing the fuse is like blowing a fuse in your electrical box: blown is blown. Once the fuse is blown, the JTAG interface is disabled on the device. Forever. It can never be re-enabled, even by reflashing the device via BSL.There is no going back. (see, for example, SLAS722g, page 36, `JTAG Fuse', note (1)-- this is for MSP430g2X12/2X52, but others with the fuse are similar)
     
    In the devices with no fuse (that use an enable code in flash instead), the status is checked at powerup, and the JTAG hardware not enabled unless the status (in flash) is correct. On reprogram  (via BSL), this can be reset.
     
    Again, the device can still be accessed via BSL, so you need to SET THE PASSWORD (32 bytes) to prevent the device memory from unauthorized reads. See SLAU319I, sec 2.7 for details (password is interrupt vector space; any that are not in use can be set freely) This also explains how to enable/disable the automatic memory wipe on incorrect password and/or disable BSL entirely.
     
    Edit: add ref to SLAS722
    Edit 2: ref SLAU319
  5. Like
    enl got a reaction from bluehash in ADC MSP430 delay(20)   
    As @@bluehash said, to sample he input so as to get sufficient information to reproduce it, the sample rate needs to be greater than twice the maximum frequency in the signal.
     
    First, I messed up units in my post above. I intermingles 50 microseconds and 50 milliseconds. The concept still applies and content is correct otherwise...
     
    Second, we really need to know what you are trying to do for anyone to give a better response. Are you trying to synchronise to the input? Sample it like a digital oscillloscope? other? What development tools are you using (I presume from your post that the toolset you are using implements delay() as a millisecond delay, not microsecond)? What clock rate is your processor running at (if using  Energia, this is probably 16MHz+/- a few percent. If CCS, unless you change it, it is the processor default of 1MHz uncalibrated.) What is YOUR background (so we can go to the appropriate level of explanation)
     
    Short form: Nyquist demonstrated that to gain sufficient information about a sampled signal to reproduce it without aliasing (shifting frequency components to the wrong frequency), the sample rate must  be GREATER than twice the maximum frequency present in the input. (It is often stated that it must be EQUAL OR GREATER, but equal fails, as the sampled data then becomes phase dependent for the highest frequencies). It is better to sample at a minimum of 4 to 10 times the max frequency, as this reduces the need to interpolate and filter to get information, such as peak, power, frequency spectrum, and phase, and reduces the time required to gather enough samples to get this information (as there will be much less modulation due to interference between the sample frequency and the signal than if the sample rate is barely greater than the max frequency in the signal)
     
    The BEST way to do sampling is a stable clock (crystal controlled) and a sampling system with no jitter. This can be approximated on the MSP430 quite well by using interrupts and the hardware timers to control the process. In brief, you set a timer to interrupt at your sample rate, and the interrupt handler starts the next ADC cycle, giving a fairly well synchronized sample point. Having the ADC interrupt at the end of the conversion allows immediate handling of the result. This is not simple, but it isn't that complicated, either. To tell you more, we need to know more about what you are trying to do.
  6. Like
    enl got a reaction from xyiii in ADC MSP430 delay(20)   
    In addition to undersampling the signal leading to loss of proper representation, the clock on the processor is NOT as accurate or as precise as a crystal oscillator. If the timing in your code was nominally perfect, it would still likely not match the real-world waveform timing, and not read at exactly the same point on the real world waveform each time, even if the real world wave had no error, which is unlikely. Undersampling IS used for a number of practical applications, but great care is needed to do it properly.
     
    Another issue, that again would affect you even with perfect clock, is that the delay(20) puts a 20 microsecond delay BETWEEN the instructions before it and after it. The 20microsec does not account for a) the time required to do the function calls and ADC conversion, the time to save the value to the variable ADCvalue, c) the time to copy the value into the array element, d) the loop overhead. Depending on the processor clock speed, the overhead will be a couple microseconds at 16MHz to maybe 100 microsec or more at 1MHz.
  7. Like
    enl reacted to KatiePier in Prevent reading code   
    Hi @@MSPLife,
     
    @@enl's summary above is spot on.
     
    One or two more additions about BSL - with the BSL password protection, as @@enl mentioned you cannot read out the part unless you provide the correct 32-byte BSL password. Now, if you provide an incorrect password, the part will do a mass erase which should get rid of the code in the part - that is to try to help against someone brute-forcing your password. After your code is erased, there's not anything for them to read anymore of value. This should all be described in www.ti.com/lit/pdf/slau319
     
    The other point I wanted to make was, that only some parts in the G2xx family have a BSL in hardware - G2xx3/4/5 do, but the earlier G2xx1/2 don't I believe. Make sure to check your device datasheet if you want to use BSL. If you still need to do firmware updates, but also want to blow the JTAG fuse on a G2xx1/2 that does not have BSL, you could look into doing a main/info memory bootloader like discussed in the MSP-BOOT app note SLAA600, or potentially the tiny G2xx loader mentioned at the end of SLAA450.
     
    But as @@enl and others have mentioned, there's not one way to make sure you are 100% safe if someone really has the resources time and motivation trying to break in with some fancy tools - this is true of any IC. But you do what you can to make it harder for someone to do it - it's like locking the door on your car.
     
    Regards,
    Katie
  8. Like
    enl got a reaction from KatiePier in Prevent reading code   
    docs are the references above from TI. Google for SLAU319 and 320. This is really not a 30 second, one paragraph thing to answer. The protection is provided via a number of options using the same interfaces that are used for programming.
     
    The option with BSL is to set the password (32 bytes, which is a 256bit password) that will be required for the read command to be used to read the code memory, either via JTAG or BSL. Disabling JTAG reduces the risk of several possible exploits that can get information without an explicit read (see the docs on the CCC website for more info).
     
    NOTHING can provide absolute security. I could decap the IC an use several methods to directly read the code memory if I wanted it bad enough (well, I personally couldn't at this time, but some of my former students could, and I could have when I was still in university, and, now that I think about it, maybe I could now, but I would need several samples to work with, and I wouldn't bet my house on it). More work than in the old days of mask programmed ROM, where you could pretty much read the data with an optical microscope, but still not a major challenge with appropriate gear. ANY security you use can be broken, and the issue is whether it is some guy in his basement, or if it requires equipment that only someone with enough money to reproduce you work from the ground up anyway will have.
     
    Edit: 32*8 is 256 bit password, not 512. I have become too used to working with 16bit words over the last few years....
  9. Like
    enl reacted to roadrunner84 in Prevent reading code   
    Depending on how hard you want to make stuff and your scale of production, just clipping/cutting/drilling off the TEST pin after programming might be enough for you...
  10. Like
    enl got a reaction from MSPLife in Prevent reading code   
    docs are the references above from TI. Google for SLAU319 and 320. This is really not a 30 second, one paragraph thing to answer. The protection is provided via a number of options using the same interfaces that are used for programming.
     
    The option with BSL is to set the password (32 bytes, which is a 256bit password) that will be required for the read command to be used to read the code memory, either via JTAG or BSL. Disabling JTAG reduces the risk of several possible exploits that can get information without an explicit read (see the docs on the CCC website for more info).
     
    NOTHING can provide absolute security. I could decap the IC an use several methods to directly read the code memory if I wanted it bad enough (well, I personally couldn't at this time, but some of my former students could, and I could have when I was still in university, and, now that I think about it, maybe I could now, but I would need several samples to work with, and I wouldn't bet my house on it). More work than in the old days of mask programmed ROM, where you could pretty much read the data with an optical microscope, but still not a major challenge with appropriate gear. ANY security you use can be broken, and the issue is whether it is some guy in his basement, or if it requires equipment that only someone with enough money to reproduce you work from the ground up anyway will have.
     
    Edit: 32*8 is 256 bit password, not 512. I have become too used to working with 16bit words over the last few years....
  11. Like
    enl got a reaction from tripwire in Prevent reading code   
    docs are the references above from TI. Google for SLAU319 and 320. This is really not a 30 second, one paragraph thing to answer. The protection is provided via a number of options using the same interfaces that are used for programming.
     
    The option with BSL is to set the password (32 bytes, which is a 256bit password) that will be required for the read command to be used to read the code memory, either via JTAG or BSL. Disabling JTAG reduces the risk of several possible exploits that can get information without an explicit read (see the docs on the CCC website for more info).
     
    NOTHING can provide absolute security. I could decap the IC an use several methods to directly read the code memory if I wanted it bad enough (well, I personally couldn't at this time, but some of my former students could, and I could have when I was still in university, and, now that I think about it, maybe I could now, but I would need several samples to work with, and I wouldn't bet my house on it). More work than in the old days of mask programmed ROM, where you could pretty much read the data with an optical microscope, but still not a major challenge with appropriate gear. ANY security you use can be broken, and the issue is whether it is some guy in his basement, or if it requires equipment that only someone with enough money to reproduce you work from the ground up anyway will have.
     
    Edit: 32*8 is 256 bit password, not 512. I have become too used to working with 16bit words over the last few years....
  12. Like
    enl got a reaction from MSPLife in Prevent reading code   
    For information about the MSP430, see SLAU319, "Programming via the bootstrap loader", SLAU320, "Programming via the JTAG interface", and SLAU265, "MSP430 Memory programming" (outdated and superseded by the other two, but still useful)
     
    A summary: disable JTAG and password protect BSL access.
     
    If future access will be required for in circuit reprogramming, there are a variety of options, but the essence is that you set a password that prevents protected commands, like reading the program memory, via JTAG or BSL
  13. Like
    enl got a reaction from bluehash in Prevent reading code   
    For information about the MSP430, see SLAU319, "Programming via the bootstrap loader", SLAU320, "Programming via the JTAG interface", and SLAU265, "MSP430 Memory programming" (outdated and superseded by the other two, but still useful)
     
    A summary: disable JTAG and password protect BSL access.
     
    If future access will be required for in circuit reprogramming, there are a variety of options, but the essence is that you set a password that prevents protected commands, like reading the program memory, via JTAG or BSL
  14. Like
    enl got a reaction from dubnet in ADC MSP430 delay(20)   
    In addition to undersampling the signal leading to loss of proper representation, the clock on the processor is NOT as accurate or as precise as a crystal oscillator. If the timing in your code was nominally perfect, it would still likely not match the real-world waveform timing, and not read at exactly the same point on the real world waveform each time, even if the real world wave had no error, which is unlikely. Undersampling IS used for a number of practical applications, but great care is needed to do it properly.
     
    Another issue, that again would affect you even with perfect clock, is that the delay(20) puts a 20 microsecond delay BETWEEN the instructions before it and after it. The 20microsec does not account for a) the time required to do the function calls and ADC conversion, the time to save the value to the variable ADCvalue, c) the time to copy the value into the array element, d) the loop overhead. Depending on the processor clock speed, the overhead will be a couple microseconds at 16MHz to maybe 100 microsec or more at 1MHz.
  15. Like
    enl got a reaction from bluehash in ADC MSP430 delay(20)   
    In addition to undersampling the signal leading to loss of proper representation, the clock on the processor is NOT as accurate or as precise as a crystal oscillator. If the timing in your code was nominally perfect, it would still likely not match the real-world waveform timing, and not read at exactly the same point on the real world waveform each time, even if the real world wave had no error, which is unlikely. Undersampling IS used for a number of practical applications, but great care is needed to do it properly.
     
    Another issue, that again would affect you even with perfect clock, is that the delay(20) puts a 20 microsecond delay BETWEEN the instructions before it and after it. The 20microsec does not account for a) the time required to do the function calls and ADC conversion, the time to save the value to the variable ADCvalue, c) the time to copy the value into the array element, d) the loop overhead. Depending on the processor clock speed, the overhead will be a couple microseconds at 16MHz to maybe 100 microsec or more at 1MHz.
  16. Like
    enl got a reaction from spirilis in Voltage regulator 12vdc to 3.3vdc   
    Well, a lot of options, depending on application...
     
    What current? Is it relatively constant? Do you need 1/2amp?
     
    If the draw is below 25mA to 50mA average (over a time <1sec), the basic linear reg is a good choice here, as it is cheap and regulates well. At 50mA, you will be dumping about 500 to 600mW, which is into the range where you need to worry about rejecting the heat with a heatsink. Greater than 50mA, definitely a heatsink and other choices are likely better.
     
    Constant current (or fairly constant) up to the limit for the unit allows for the use of a series ballast power resistor to drop voltage and dissipate heat
     
    My choice would be a switching regulator rated for automotive conditions (buck configuration) to 3v3, OR a switching reg to 4.5V, followed by a 3v3 low drop out regulator, if I need silky clean output. I might even just modify a $5 phone charger to deliver the 3v3, if I had one around, as even the cheapies use a buck configuration switcher (caveat: there are some that go beyond cheap to the level of trash.... they are often scary)
  17. Like
    enl got a reaction from cde in Basic Control Register Control for LED Blink Issue   
    The first thing is that the numeric values, such as in the line `P1OUT = 01000000;' are treated as octal values due to the leading zero. Without a leading zero or base specified, numerics are treated as decimal. As you intend this to be binary, you can try `0b01000000'. Some compilers will accept this as binary, though it is not standard. The best way is use hexidecimal: `0x40', which all C compilers will accept.
  18. Like
    enl got a reaction from Fred in High torque gearmotor for upcoming project   
    Spent some time prepping for a new project, and realized I haven't seen the techniques I use shown, so I figured it is as good a time as any. There are likely people that could use the information, and I have a cat on my lap, so I have time.
     
    The project I am working on (to be disclosed if I get it done to m satisfaction) requires a pretty high torque, fairly fast drive. The requirement is to move about 10mm in 100mS, position withing 0.1mm, with a force of about 50N (3/8" motion to about 0.004", with a force of about 10Lbs, for those that are trapped in the world of imperial units). Not earth shaking, but beyond the cheap hobby servo.
     
    The cheapest, and one of the most convenient, moderate torque drive available is the battery screwdriver. Not the big gun shaped job, but the homeowner type. The good one are about $20US new, but I usually pay $0.50 to $1.00 at yard sales and swap meets. There are millions of them. Most with little to no use. People buy them for themselves or as gifts without realizing that this little bugger in not the same as the $150 Dewalt. After they sit in the drawer unused for a few months or years, I get them cheap. They have been around for at least 30 years, with 1/4" hex drive, planetary reduction, 180RPM nominal, and design voltages of 2.4 to 4.8V.
     
    The one I dissected this time tests out at about 250Ncm at 1V, with a no load speed of about 70RPM. The design voltage is 3.6V, and it will probably stall at close to 1000Ncm (10Nm) at that. If more is needed, then I can up the voltage for short bursts. I doubt that will be the case, as at 1V, I have much more torque than I need using a 15mm arm. For the output shafts and actuator levers, I use 1/4" allen wrenches, also yard sale grabs, preferably unhardened, so the cheapest sub-harbour-freight quality is fine. If they don't stay in place themselves,a little epoxy or gel CA does it.
     
    For this project, the first thing I did after ditching the battery end (should have been second) was mount screw terminals. There are no electronics. The switch presses contacts directly on the motor terminals, and the battery was mounted in the swivel handle. All gone, and nice big holes (12mm dia) through the body for mounting and reaction against torque.
     
     
    The first and last show the parts I used and the installed terminal. Clean and fairly neat. Last shows a sampling of the drivers in my junk box. All are black and Decker. Models are LI2000 (3.6V LIon, 330g as it sits), which is a current model,. I use this one for its intended purpose.  9078 (the one being remodeled here), which is 380g as it sits without battery or handle. Heavy. Metal gearcase. Next is a 9071, about 15 years old. 2.4V and 440g. Last is a 9018,, maybe made in 1985 or so. 2.4V and 250g. Only the first cost over $1
     
    Edit: fixed image



  19. Like
    enl got a reaction from JonnyBoats in High torque gearmotor for upcoming project   
    Spent some time prepping for a new project, and realized I haven't seen the techniques I use shown, so I figured it is as good a time as any. There are likely people that could use the information, and I have a cat on my lap, so I have time.
     
    The project I am working on (to be disclosed if I get it done to m satisfaction) requires a pretty high torque, fairly fast drive. The requirement is to move about 10mm in 100mS, position withing 0.1mm, with a force of about 50N (3/8" motion to about 0.004", with a force of about 10Lbs, for those that are trapped in the world of imperial units). Not earth shaking, but beyond the cheap hobby servo.
     
    The cheapest, and one of the most convenient, moderate torque drive available is the battery screwdriver. Not the big gun shaped job, but the homeowner type. The good one are about $20US new, but I usually pay $0.50 to $1.00 at yard sales and swap meets. There are millions of them. Most with little to no use. People buy them for themselves or as gifts without realizing that this little bugger in not the same as the $150 Dewalt. After they sit in the drawer unused for a few months or years, I get them cheap. They have been around for at least 30 years, with 1/4" hex drive, planetary reduction, 180RPM nominal, and design voltages of 2.4 to 4.8V.
     
    The one I dissected this time tests out at about 250Ncm at 1V, with a no load speed of about 70RPM. The design voltage is 3.6V, and it will probably stall at close to 1000Ncm (10Nm) at that. If more is needed, then I can up the voltage for short bursts. I doubt that will be the case, as at 1V, I have much more torque than I need using a 15mm arm. For the output shafts and actuator levers, I use 1/4" allen wrenches, also yard sale grabs, preferably unhardened, so the cheapest sub-harbour-freight quality is fine. If they don't stay in place themselves,a little epoxy or gel CA does it.
     
    For this project, the first thing I did after ditching the battery end (should have been second) was mount screw terminals. There are no electronics. The switch presses contacts directly on the motor terminals, and the battery was mounted in the swivel handle. All gone, and nice big holes (12mm dia) through the body for mounting and reaction against torque.
     
     
    The first and last show the parts I used and the installed terminal. Clean and fairly neat. Last shows a sampling of the drivers in my junk box. All are black and Decker. Models are LI2000 (3.6V LIon, 330g as it sits), which is a current model,. I use this one for its intended purpose.  9078 (the one being remodeled here), which is 380g as it sits without battery or handle. Heavy. Metal gearcase. Next is a 9071, about 15 years old. 2.4V and 440g. Last is a 9018,, maybe made in 1985 or so. 2.4V and 250g. Only the first cost over $1
     
    Edit: fixed image



  20. Like
    enl reacted to roadrunner84 in Use of Timer A interrupts   
    Yes, that'd do the trick as well.
     
    When using the __even_in_range intrinsic, make sure no odd (not-even) value or value above the set range could even occur! As you may have read, the __even_in_range intrinsic changes the if() else if() chain into an "add parameter to the program counter" and a jump look up table. Any value out of the set constraints will lead to undefined behaviour, and maybe even hang your process.
  21. Like
    enl got a reaction from Optronik in UART Clock Issue / Accuracy / DCO   
    DCO will generally be within 5% (max over operating range is 6%, but it is usually better) when properly calibrated. If the factory data has not been overwritten, then you can set the DCO to one of four calibrated frequencies, including 1MHz and 16MHz to keep within 5 or 6%.
     
    You can check the calibration against the 32kHz xtal and trim the numbers to get closer, either by modifying the DCO constants or the settings for the UART clock.
     
    If the 32KHz xtal is already there, then by using more advanced features of the UART clock, you can do a lot better using the baud rate modulator than with only the divider. See slau144, section 15 (in slau144i, it is page 430, and subsection 15.3.9) where one of the examples is specifically 9600baud using the 32kHz xtal.
  22. Like
    enl reacted to RobG in Analog Discovery   
    If you ever wanted to get logic analyzer, you should take a look at Digilent's Analog Discovery.
     
    Analog Discovery is a multifunction device developed by Digilent in cooperation with Analog Devices (AD is filled with chips from AD.)
    AD features analog and digital inputs and outputs, and can be used as an oscilloscope, function generator, logic analyzer, pattern generator, virtual I/O, voltmeter, spectrum analyzer, network analyzer, and even power supply. And the best part, it's affordable, especially for US students.
     
    I got my AD several days ago and let me tell you, AD is a true Swiss Army knife for geeks.
    To show you how useful AD can be, I used it to test new version of my audio analyzer BoosterPack.
    For my tests, I am using oscilloscope, logic analyzer, and waveform generator instruments (AD comes with software called WaveForms, which is a suite of virtual instruments.)
    Waveform generator provides 2 audio signals (via 3.5mm stereo jack) to BP's audio input. A simple tone or a sweep can be generated, so many options.
    Oscilloscope is connected via (optional) BNC Adapter Board and a probe to audio switch's output, so I can see which signal is fed to the EQ chip.
    Finally, logic analyzer is connected to LP's SPI output and displays sampled data.
     


     
    Analog Discovery's pinout

  23. Like
    enl reacted to dubnet in Radio Shack Store Closings   
    As some may know, Radio Shack is closing a significant number of their underperforming stores in an effort to survive. My understanding is that they will be closing these stores by the end of January.  
     
    If you have one of these stores nearby you may want to stop in since they are deeply discounting some of their inventory which includes their MCU oriented products. 
  24. Like
    enl reacted to RobLewis in Bitlash   
    I just discovered an impressive Arduino program called Bitlash in a video demo http://pinocc.io/blog/building-the-internet-of-things/preview-pinoccio-api/ (about the Pinoccio mesh networking module). 
     
    It lets you define and run tasks from a shell. 
     
    Has anyone tried porting it to the MSP430? 
  25. Like
    enl got a reaction from abecedarian in Other holiday cheer.   
    very nice. Temp depends on the solder being used (lead/tin, lead free silver bearing, antimony or cadmium silver bearing, etc) and the type of joint (large pad, surf mount small pads, wires, etc).  I don't havea temp gauge. Just adjust it til it is right for the job: heat the joint in a few seconds to flow temp. Hotter is generally better if there is a question, as, if the solder or paste is there, as it melts, it will control joint temp. Once melted and flowed, iron is away. Too low a temp leads to overheating components before the solder flows.
×
×
  • Create New...