enl
-
Content Count
346 -
Joined
-
Last visited
-
Days Won
22
Everything posted by enl
-
Hmm... an option I haven't considered. Need to try this with my old camera. May need to devote it to the shop if I can get good mag
-
If this is still an open question, a few points: Single lens per eye magnifiers will have distortion as the magnification goes up. It is an unavoidable issue. The better quality (more expensive) ones have less, but it will always be there. This is due to a number of basic physics principles. Better quality lenses are not spherical, and reduce the aberration, but at high mag, the region where the aberrations are unnoticeable or correctable by your eye is smaller, and it gets more difficult to keep your eye where the aberrations are minimal. Non-adjustable stereo (optivisor style) are the wo
-
I am not going to argue about opinion, but I will give a little of the background. Java was designed on essentially religious principles: To be a PURE OO language, 100% self consistant, no compromise. It didn't make it... even 1.0 had features that broke the paradigm. There are more now. The OO model is not ideal for everything. The purists worked from the belief that it is. For application where the model IS appropriate (there are many), and portability across platforms is needed, Java isn't a bad choice. For network delivered, heavyweight applications, Java is a pretty good fit, as t
-
Java has its place. The places the MSP430 is used wouldn't be it. Java is a pretty heavyweight language designed for portability and object security, which is really nice in a network delivery, dynamic load situation. Burdensome for a firmware, low RAM situation. It is impractical to fit JVM into the constraints of the MSP430. Performance would be abominable if it could be done. Most of the benefits of Java would be lost (good dynamic memory management; robust suite of classes; etc) due to the memory limitations and need for an efficient filesystem. Not to say Java couldn't
-
How precise do you need the timing? +/-6% doesn't need a crystal. You set the DCO clock to a calibrated frequency and go to town. Can you wait 1sec? Absolutely. Will it require a subroutine/interrupt? Maybe. Easier to do that way. I would go with the 1MHz calibrated DCO clock (internal... not external components needed, factory calibrated) to drive an internal timer module. Have the module periodically interrupt, and the interrupt routine keeps a time count. Each time the interrupt occurs, if the time count is the time for an event, do the event. THere are a number of ways to do th
-
Long day on a welding side job. River Horse Lager. It is adult bevie time.
-
what is the current draw? The other option, if the current draw is sufficient, would be an inductive pickup, or a hall effect pickup like the Allegro ACS710 or 712 series. Both the inductive and the current sensor IC are isolated. The IC is cheaper. The 5A version of the 712 is a couple bucks. Advantage to these is current measurement. Edit: just reread the intro. At 80mA, you should be able to go with current sense. A 5A sensor has resolution of 10mA at 10 bits(bipolar), which is about ok for 80mA (look for the periodic change). An inductive pickup with the appropriate ballast resistor is
-
See SLAS735 (MSP430G2X53 datasheet, or other device datasheets) for the graphs. SLAS735G, fig 6-9, "Typical characteristics, Outputs" shows the curent vs output potential vs supply potential. The MSP430 devices are pretty much symmetric with respect to sourcing and sinking. Driving at too high a current may not *immediately* damage an output, but driving an LED without a limiting resistor (or current limiting driver) will likely either smoke the LED or damage the I/O in the microcontroller eventually. The damage may not happen immediately, but the drive transistor will be dissipating power
-
Giveaway Winners: Pervasive Displays 1.44" Electronic Paper Booster Pack
enl replied to bluehash's topic in Announcements
Curses! Foiled again! Congrats, Igor -
measuring currents at the range used by these processors is not easy. Several things make it tough: the low end is very, very low when sleeping, and can be the dominant usage in systems where the processor sleeps most of the time; The active current can be orders of magnitude larger than the sleep current; and many applications have very short active bursts. If you are trying to tune code by power usage, you will have an..... interesting time. If you are running on a launchpad rather than a bare processor, the power used by the processor will likely be buried under all of the other draws o
-
Since I am procrastinating on a fat load of paperwork, I'll give some sample (UNTESTED!) code for lookup table in this application: // Preconditions: // ADCsine has 10 bit ADC measurement representing the sine of the angle, scaled and offset so that // 0x200=>10sin(0), 0x3ff=>1=sin(pi/2), 0x001=>-1=sin(-pi/2) (0, 90 and -90 degrees) // The exclusion of 0x000 if for symmetry. // ADCcos has the corresponding cosine value. // Result: // DACangle=> A value in the interval 0x0000 to 0x03ff, representing the angle, where 0x0000 is 0degrees, 0x0100 is 90 degrees 0x0200 // is 180 degr
-
Look up is quick, in general. Really quick. Time required is a couple compares, an add or subtract, and an array index operation, followed by adjustment for octant (a switch and an add or subtract, if the octant is coded as an integer [0..7]). Fast. The balance is time vs. size of code vs. needed accuracy. A few numbers, presuming that you are doing no other processing with the values, and that you are producing an integer value for the DAC that is of similar resolution to the input value from the ADC: If the result you need is a single byte and the inputs are 10 bit, and come prope
-
If the inputs are 10 bit (or 12 bit) ints, and they represent sine and cosine with fixed scaling, so the same angle always produces the same input values, I would do the following: Identify the octant the angle is in (0-45 deg, 45 to 90, etc) Use the smaller value (which will be the higher resolution value) as index, look up a reference angle between 0 and 45deg. Then correct the result for the appropriate quadrant. Requires a lookup table with about 720 values (for 10 bit input) If the table will be too big, Cut the number of entries by a factor of 4 or 8 (simple shift) a
-
Are you trying to recover that angle over all four quadrants? Or only the first? Or two quadrants? There are ways of doing this more efficiently than using inverse trig, in particular if you don't need perfect.
-
The question I would ask is: do you really WANT to do the trig function, or can you use something that will approximate the behaviour? On a device with at least mult and div in hardware, not a huge issue. FP support in hardware, not issue at all. On a device such as the G-series, often not the best way to go. If you are reading the ADC, applying func, then sending to DAC, I would presume some scaling is going on. The resolution is also limited by the hardware. If the goal is just compression, then I would probably use less costly (time and memory) method, such as an efficient cube root
-
I am guessing that you are using no other line connected supply? Or did you disconnect the output ground from earth ground?
-
For longer periods, where the divider still won't get you enough time, You can also use a counter in the interrupt routine. Initialize to the number interrupts you need in a cycle,, decrement each interrupt, and, if not zero, return. If it is zero, do your task and reset the counter. // counting interrupts example _interrupt void TIMER0_A0_ISR(void) { const unsigned cycle=24; // presuming 24 interrupts is a cycle static unsigned icount=cycle; // never reinitialized after program initialization if (--icount) return; P1OUT ^= 0x01; icount = cycle; return; } Your t
-
I forgot one (likely not relevant to you) solution: an integrated logic output button. The circuitry is in the button unit, with a clean logic output. These are not cheap, but some of them have near zero quiescent power. I have not purchased any in a number of years (the number being >15), and I would imagine that they are a) lower power than they used to be, and just as expensive. But, you never know. I once scored about 50 hall effect low power units surplus for about $0.20 each. With keycaps. They ran at about 100microamps at 5V, back in the 80's.
-
Debounce time depends on a bunch of things including button design, capacitance and pullup resistance, how it is pressed, etc. You can debounce either in hardware or software. For slow inputs, software is easier. Just disable the input for some period (a couple hundred ms is usually safe) before reenabling. For better response, at the expense of a little processing power, once the input (active) is detected, keep the interrupt disabled until a stable inactive is detected. Periodic monitoring of the input status is needed, and stable is usually determined as several readings in a r
-
Not really. Without a method of synching the clocks, either a common clock for asynch communication, a synchronous or self-clocking comm method, of a clock resynch method, you will have a tough time. If you MUST use the standard UART and may have excessive drift, you may want to use one of the supported synchronous methods. You will need an extra line for the clock. If you are willing to write some code, there are a wide variety of self-synchronizing methods. You could use the 1-wire protocol (Dallas Semi--- used on such things as the DS18B20 temp sensor), for which there is some suppo
-
If all components are at the same temp, drift shouldn't be too big an issue. If the components can be at radically different temps, there might be a concern. Other methods you can use: Generate a common clock to sync the devices for asynch UART communication. Uses an I/O (the Xin pin is good) Use a synchronous comm scheme clocked from one master device (or external clock) Determine max clock drift analytically (or by measuring samples) and, if worst case relative drift it is less than about 5% (depending on asynch data format.... RS232-format serial can tolerate about 5% maximu
-
As low as you want. General idea is: set up timer to provide periodic interrupt. If not low enough freq, count the interrupts and do what is needed every n interrupts. Put processor to sleep. On interrupt, or after n interrupts, start ADC conversion. Set for interrupt on completion. Let processor go back to sleep. When conversion is done, interrupt wakes it back up so you can read value and do what you will with it. I have a device that has been going for over a year on a set of AA batteries using a 32KHz crystal for moderately precise timing, waking up every 8sec (max that the
-
Still quite doable. Probably want linear response on a pot, So I would go with a table for the divisors. Either of the above methods will work, but to match the pulse width for the short pulse will be easier with the interrupts. As the cam turns at half crank, if it has one tooth for the sensor, that is divisor of 64, not 32. does it have 2 teeth? This range is great enough that I would handle the low rate pulse with an interrupt, even if the high rate is handled with hardware. Interrupt each rising edge of high speed, and keep a counter in the ISR. At 0x1f in the low bits (easy test with
-
Well, this is where things get interesting... The math lib likely uses a bit of RAM, but only functions you use should build in, so anywhere you can eliminate a function (floating point) you gain. RAM usage is a different matter. Pow will take a bit of workspace. Shouldn't be that much. Knock the buffer size down 4 bytes at a time to find the limit. I will guess at about 20 bytes (5 floats) but wouldn't be surprised at 64 bytes (16 floats). The mult and div also come in as functions but they should be fairly small, and are required for the power function anyway. Have you looked at the op
-
yes How precise do you want the rate and what characteristic do you want for the adjustment? Linear with resistance? More precision at one end or the other? How much resolution? Without the answers to these questions, I'll give a basic summary of one way to approach it. Connect the pot between Vcc and Gnd, and the wiper to a ADC input. This gives 1024 steps for freq selection. For (fairly) precise timing, you will need a crystal, but the standard clock system is pretty good, and will give greater resolution. At 5.5Hz, the higher speed osc will be 176Hz. At the low end, you are l
