enl
-
Content Count
346 -
Joined
-
Last visited
-
Days Won
22
Posts posted by enl
-
-
-
greetings.
Do you have any particular plan for your flash controller? I am curious how you plan variable power, as I haven't dealt with that in a long time and only with pure analog.
-
I see. Schematic helps.
You don't have the LED's paralleled with a single limit resistor. You have the LED/limit resistor pairs paralleled.
What you did is correct.
ANY component will degrade with time/heat/use.... White LEDs degrade fairly quickly due to phosphor aging/burning, like the phosphors on an old CRT-type display, but higher quality ones hold up better.
-
-
White LEDs, as all components, vary in quality. Most white LEDs use a phosphor to produce a yellow that mixes with the blue emit by the LED forming whte. Thre are a number of different phosphors used, depending on the exact blue produced by the LED, and the cheaper ones tend to be single phosphor types. Over time, the phosphors may change properties due to heat or just age, even in high quality devices. Running the device cooler (lower peak current and lower average current) will reduce this. Read the data sheet carefully, and be conservative with design to reduce the risk of early failure.
Also, it is generally not good to parallel LEDs. It is done, but is bad practice due to the nonlinear V-I curve. Slight unequal sharing of current (which is inevitable) leads to the LED getting a littlemore current heating more, which shifts the curve in the direction that makes it worse. Same mechanism as thermal runaway for an IC, which is where the second breakpoint comes from on the safe operating region graph for most power IC's. LED brightness is determined primarily by current, so 'identical' units in series should be the same brightness, and the limit resistor provides a little negative feedback to keep things stable. Or, use a constant current source for each chain of LEDs, and the drop in the V-I curve will tend to reduce power dissipation and self heating as the devices get warmer.
Anothee possibility, if only one is going, it may have been borderline to begin with. A lot of the components that pop up on ebay, even from the more reliable supliers, and sometimes from reputable suppliers like digikey or Newark, are relabled seconds or are from less reliable manufacturers. The supplier may not know this, because substitutions can happen up the chain several steps.
Recently, there was an artical in IEEE Spectrum looking at this problem (specifically relabeled devices pulled from scrap and counterfiet devices), especially in the military supply chain. It happens a lot more in the commercial supply chain.
-
-
Back in the days of large cards covered with neat rows and columns of DIP IC's, mostly 7400 series and the occasional MSI or LSI (almost 50000 transistors! On one IC!!!), the card looked like little industrial cities when laying on the test bench, full of warehouses and factories. Power supplies were commonly pretty beefy-- my 5V bench supply is an old 30A Delta, with a big crowbar bolted to the outside (from the factory) and remote voltage sense lines-- and a failure could turn that nice clean postcard-picture factory city looking board into 1950's Pittsburgh in an instant. Stunk like crazy, but actually kinda neat seeing all of those little factories blasting smoke out of their roofs as turn silicon into slag.
No pics (pre digital cam era last time I saw this), just memories.
And we can't forget that when testing using a variac, plug the variac into the isolation transformer, not the bench outlet. Fortunately, GFCI for the bench, so no smoke, but it took me about an hour to figure out why hooking up the scope ground lead was popping the GFCI monday night. Bench computer was plugged into the iso tranformer outlet.....
-
Forgot two things:
Modes: on with occasional blink, fade in fade out, and hard on hard off.
Also, used phone crimps for connections (pic attached).... real handy, but only good for a few hundred mA
edit: third thing: eyeballs are epoxied in pairs to 12Ga bare wire to hold position. A little black paint and not visible. Used liquid electrical tape (again, black) to coat exposed joints. The crimps are watertight.
-
Took the challenge. Started monday when I got home from work.
Project is spooky eyes for the bushes. 8 channels, each of which will drive approx 3 amps, which is abou 110LEDs from the the 12V LED strip I used.
Cut the strip into three LED sections (the minimum for this type), soldered on 300mm lead sets (twisted pair from cat5 cable), and used epocy to ttach the leds to ping pong balls. bent the strip so the LEDs fit flush to the surface. The epoxy provides good coupling, so, before painting, the balls had a good bright red glow.
Masked pupils and painted the balls black with the cheapest spray I had on hand. Several coats to block waster light. The LEDs leak a lot to the side.
Threw the code together in about an hour. Three modes.
Interesting part of the code is the method for not caring about the timing. It dosen't much matter if a PWM tick is missed the start of the cycle, as if the LED is off, it stays off. If it is on, it makes dimmest setting one tick brighter. Therefore, I put the whole mess into the interrupt routine and counted the PWM myself, rather than use the timer features, so that I could run 8 PWM's off one interrupt with several modes. The trick is to build the NEXT PWM state during the tick, and set the outputs first thing on the interrupt. Also, only do the work for the PWM pulse length once per cycle, which may lengthen the first tick, but it will be consistant and not mess up the overall appearance in operation. Could've upped the clock to buy more cycles, but it won't look any better. for the uploaded program, the first tick of the cycle, when the updates are done, just misses over-running. If all outputs were set to mode 2 (more conditions), I think it does, but it looks fine in practice.
I used P2 for output so I could use the launchpad LEDs during testing, and was going to use the other pins for input to change modes. I got lazy. May do it later.
The drivers are TIP31's to ground. Simple, and I had them in the stockpile. Mounted on a scrap of vectorboard from an old S100 bus A/D from when I was working in the medical lab.
Pics are the eyeballs hanging to dry; channel schematic; shot of the launchpad, channel drivers (second piece not yet mounted), terminal strip, and power supply liberated from an old external hard drive that powers the mess; a couple shots of the eyes in the shrubs; code; and link to video of operation will follow when I upload it (youtube accound came from the Google+ name I got when I bought a nook. Didn't habe one, and the doofus at B&N made it for me without telling me without telling me. As you will see, he was quite creative in making up a name, seeing as how he had mine in front of him, as well as me standing there) The eyes are not visible, once twilight hits, unless they are on, nor are the twisted pairs from the cat5.
Video link will be posted when I get done with youtube. BTW: schematic not bad for MSpaint, no? Don't have good schematic software on this machine...
EDIT: link to video:
EDIT 2: revised code is attached as main-revised. Moved text of followup here. Left original main as I can not bury my sins in good conscience
-------------------------------------
Found an hour and made the code a bit more presentable.
Function control is in the main, and only the PWM setup is in the interupt routine. Also, bushbutton on launchpad acts as circuit test: Pushing it turns all channels on (well, mostly. The PWM interrup my shut off a channel for the duration of the interrupt routine) for checking the wireup.
Also, modified the structure for each function to allow a bit more user tuning: The length of each operation can be varied for each channel.
I didn't put the processor to sleep when the updates are completed. A few hundred microwatts for the processor when the LED's are using 10 or more watts (max without modification to code or hardare is about 250W) isn't really significant.\
This update is not really any more elegant than the original, but it is structured better.... I am less embarrassed by the code now.
-
Stilll don't have enough information.
Indoor plants in pots? Outdoor plants like rose bushes? Or heavy shrubs? Large number or only a few? Environvent (dry, moist, warm, cold?) Makes a difference between pints every couple days or gallons several times a day.
Also, what is water supply? City water? Well? Pond?
If outdoor and more than a maybe a couple of gallons a day, I second (third? forth?) the solenoid valve as best solution.
No pressurized water (drawing from a pond or equiv) need to know how much water and more about situation to make a suggestion, as pump sizing is important.
One or two small shubs or indoor, I would probably go with the suggested winshield pump. Might draw from a toilet tank for the source, but one lower than the outlets to prevent siphoning.
-
(duplicate post deleted... sorry)
-
I will second pabigot that the big concern is failure to allocate at some point when it is tough to identify.
Several reasons this can happen include too much active data for the available memory, memory leak from not freeing un-needed memory, memory leak from poor practice (allocating and than forgetting where the data is, allocating un-necissarily, etc), and leaks from un-anticipated events in event driven/interrupt driven code.
The extra code to handle these cases may make it not worth using a general purpose allocator due to both code size and execution speed considerations.
I will go on the presumption that you are using interrupt handlers, as it is almost impossible to do useful things with a microcontroller without, so if you really feel the need to malloc, some rules that help reduce the risk of a problem include:
To go farther than pabigot: DO NOT allocate or free memory in interrupt handlers, and take great care accessing allocated structures in interrupt routines. malloc and free are not re-enterant, and, though quick, are slow enough that they don't belong in interrupt routines. This is pretty much a restatement of the general interrupt-driven-code rule of call no functions in a handler, and minimize handler size. Accessing allocated structures in a handler risks an access during a structure update, and the unpredictable behaviour that can follow.
As pabigot said, consider an application specific allocator. You can write this yourself.
The simplest thing is avoid dynamic allocation altogether. If you are only allocating a single type of structure, it is often easier to allocate an array at startup. Rather than pointers, use aray indices. Benefits include ease of checking memory status, possible smaller footprint (if you can get by with a byte for the index, you save, and no block overhead foreach allocation). Possible drawbacks are speed of access if care isn't taken (array accesses by index arn't as fast as following a pointer) and the need to do it all yourself. You still have the concern about accessing linked structures in an interruopt handler.
Keep in mind htat this is a tried and true tool. Back in the day, this is how we did it in FORTRAN (Ok, I'm throwing that card out... Anyone else remember FORTRAN IV on cards?), though there are good reasons that by the 1970's, languages included allocators and pointers.
The attached file provides a (not error checked- thrown together to show concept) sketch of an array based allocator. You only need to build in what you need. Never free? don't include it. No danger of running out of elements? drop the check (or make the check provide debug info via your mechanism of choice). etc
-
The penalty of software floating point. The difference in code size suggests to me that the operations are optimized for sppeed, not code size. It is roughly 4 times as many primative operations for adouble multiply as for float, as when doing long multiplication by hand. It goes by the square of the number of digits. (really by n_log_n, but using 16 bit ints as the primative operation, it really doesn't make a difference) If optimized for code size, I would expect only a few percent difference, but a significant time cost to loop and conditional overhead.
I do not miss coding FP routines in software. Not at all.
-
No question that for most applications, in C or C++ or java, single precision is now the better option. The period from the early '80's to the early 2000's there were good reasons, on a general purpose processor, to use double unless there was a really good reason for single precision (memory usage was the best argument). Even the earliest DSP's handled single precision faster than double, and only hardcore modelling and utility tools are coded in C or C++ (I don't count java.... the floating point is too crippled to do the work where it would matter) where it would be significant for MOST purposes. 'Relics of the past' is a good summary, and if I didn't make it clear that was where I was going, I apolagise.
There wasn't enough real estate back in the day to handle both single and double with dedicated hardware, so gen purpose processor cores tended to be built for double.
The key things are that most applications don't do the types of calculation where the error accumulates enough to be a problem-- an error of 1 part in 100000 doesn't matter when your end result is 8 or 10 bits, and is barely there at 16 bits-- and modern processors tend toward efficient single precision, either by having an efficient single prec pipe (most general purpose processors... either dedicated or shared as double), or by using single prec hardware to do double prec (some DSP's, most if mot all GPU's, where the intended end result is an 8 or 10 bit channel intensity, etc) as needed.
I can't think of an application where the '430 would be the appropriate tool that would need double off the top of my head, but I'm sure that there are a few. I have built a few PID models where double was needed due to the relative magnitude of the inputs to the control signal, but in many cases, offsetting the control signal makes more sense if practical. (I much prefer a stardard tool, but sometimes ya gotta do what ya gotta do...)
Side note.... Matlab and Mathmatica do a good job for modeling. Python can be ok, but has some issues. (Anyone using Excel needs help.... major flaws, many of which are well documented. That doesn't stop people who should know beter from doing modelling in Excel, tho... Go figure.)
-
The rule of thumb comes from several places
1) Many general purpose processors (X86, motorola, etc), going back to the mainframe era, share hardware for single and double precision, so the only saving is accessing memory, which may or may not be a saving, depending on the details of the job and details of the memory architecture. The hardware was double prec, so why not use it? In some cases single precision was actually handled a little slower.
2) When I was involved with numerical/scientific computing (lots of integrating systems of differntial equations, etc) the more precision the better. Roundoff was a killer. Plenty of other things came in, as well, but that was a starting point in design.
3) K&R and Jon Bentley
These days, there are a ton of processors where single prec makes sense for many jobs, including most DSP's, some general purpose CPU's, and when using a GPU as a FP engine, as most GPU's support single prec only (often with some compromises, which can require extra code to deal with). More transistors and better fab techniques since the 1970's and 1980's has done a lot to eliminate some of the compromises we used to live with, just to get the FP in hardware at all. Over the last few years, I've been relearning some of the tools I used back when doing FP in software with the 8080, Z80, and 6502.
-
If you are trying to raise the output by using a diode on the ground terminal of the regulator, the diode will NOT see load current. Load current is returned to ground independantly of the regulator. The diode will see the quiescent current of the regulator.
The LE33C has an ill-specified quiescent current of something less than 0.5mA to 3mA, depending on load (ignoring the inhibit state, where the output is, for practical purposes, floating).
This is a pretty wide range (factor of 6) giving a variation of about 50mV for the diode drop (conservatively). The current is low enough that any diode that can handle 5mA is fine (pretty much any small signal diode). Power dissipation is about 2mW max.
If you need more stable output than approx 50mV, use a 1.5K resistor from the output to the ground lead, so you have an ADDITIONAL 2mA current through the diode. This will restrict the current variation to less than a factor of 2, giving you about 15mV max variation. Presumably, a given device will be more stable, but you can't count on it. The enemy of good design is ignoring the min and max values in the spec, and unspecified values (like the min quiescent current) really play hob with non-linear relationships like the voltage-current relation for a diode.
See crude MSpaint diagram. Might need to up the cap across the diode to 1uF. The data sheet isn't complete enough to know it there will be stability issues with this one. fc is about 100kHz with 0.1uF, which is well within the spec of the regulator for stability, but raising the cap to 1uF will bring the frequency down to about 10Khz.
-
It works. Put the filter caps to ground, not the the ref/ground pin of the regulator. As you have it, the filter caps can not source more current than the regulator quiescent current (due to the diode), and when the caps are sourcing, your diode drop will be very unstable, as the diaode current will vary.
You may also want a resistor from the output to the anode of the diode, if you use a more modern regulator, or need to tweak the diode current. With the '140 as is, you get about 6mA, and for a small sig diode (like the 1N914) you are in the zone. If needed, select the resistor to provide the appropriate bias current for the drop you need.
THis can also help stabilize the diode current, and drop, against the transient response of the regulator. I would also put a 0.1uF cap across the diode.
See the data sheep for inre info about using the '140 as an adjustable reg.
Edit: Also note that the diode does not see load current. It sees only the regulator quiescent current (about 6mA). A small sig diode is sufficient. DIssipation should be approx 4mW
-
The 'art store' mechanisms seem to be more consistant. Over several years, all I have bought are the same. About 240ohm coil, go back together easily and work well after installing leads, and consistantly drive with 10 to 50ms pulses at 1 to 3V. The full clock may be as good or better for use unmodified (I haven't tried to determine this, but some of the ones I have tried seem to be better build quality. In particular, the Staples clock with 'made in USA' mechanism) but don't have as consistant coil DC resistance, and are much more finicky about drive, and are tougher to get back together with all of the gear shafts properly seated.
-
(Code is for CCS)
Noting that the standard clock runs twelve hour cycles, and that there are 12 months in the year, I thought, "What if I use the hour hand for months? What can I do with this?"
The result looks like a clock, uses a standard single phase quartz movement from the art store (cheaper and more consistant than the full clocks from Wally-world or Target, plus, I get the fun of making the face), but the hour hand shows months and the minute and second hands indicate point in month, using the standard Sumerian system, with minute hand being 60ths and the second hand being residual 3600ths of the month.
To keep the month indication correct, the rate must be compensated for the length of the month. There are four month lengths (28, 29, 30, and 31 days), and the cycle is four years. Sorry, no compensation for the year divisible by 100 coming up. This will require manual intervention. Then, of course, the batteries will have to be changed roughly 10 times before then, so not a big deal. The months are 1-48 to cover the four year cycle, with the beginning of the cycle being the year following leap year (no special reason, but since this is 2013, it means that I didn't have to bang the button a lot during testing). The 32KHz crystal provides a timebase.
The interface is dirt simple, but in no way elegant. NO pushbuttons to ground with pullup resisters and capacitive debounce for setting each of the month, day of month, hour, and minute. Feedback is in binary on six LED's. Simple. I used the Launchpad LED lines for the clock drive to make debugging easy. The interface is interrupt driven and not optimized for power-- I used a dummy loop rather than going to sleep while in the set state-- since it is infrequently used and the LED's will take one or two orders of magnitude more power than the processor while in set mode. See comments in the code for details.
During run, the timer interrupts every 8sec on rollover (16 sec doesn't work evenly in a month with 29 or 31 days, increasing software burden. Energy usage not significantly more than for logic to alternate interval size) and the interupts are counted. When the count reaches 1/3600th of a month (12 min for a 30 day month, less for 29 and 28, more for 31... see the table in the code), the clock mechanism is ticked, the counter is reset, and, if hte last tick for the month has been done, the month is changed.
Lessons demonstrated for new programmers:
Tables are your best friend, if the memory is available. Const tables go in ROM, and need not initialization, so they take no time to set up. Saves a lot of computation during run time.
Don't worry about efficiency (within limits) for something you only do once. The time/date set uses multiplication and division, which the '430 generally doesn't do in hardware. THere are warnings galore on compile. Doesn't matter, since there is plenty of memory even the smallest '430's for the software, and the power and time issues are irrelevent since, to paraphrase Daffy Duck, you only gotta do it once.
Inherently floating point operations can often be done with integers. It is worth spending the time with pencil and paper. The initial setting for position in month requires, on first look, real number computation. By a we bit of algebra and appropriate sequence of operation, only the single divide is needed (note that there are 7200 half-seconds per hour...) The initial setting is within 8 sec (one timer cycle) of one minute, and could have been more accurate with another input for the second and precomputing the timer counter. In this case, it isn't worth it.
Simple input schemes can be used effectively.
Pushbuttons don't need debounce if they only get used once (the launchpad button on P1.3 for entering run)
Use #define as a way of building your test cases into code. #ifdef and #endif bracket the test cases to prevent compile into production code, but there are in the source for debugging later if needed, and for use if changes are made to re-feature/upgrade
Things that are open:
better interface
Self setting-- set the hands to 00:00, set the date/time, and the '430 steps the mechanism until it is in the appropriate location. May take a good part of 6 hours to synch (these mechanism's step at about 2/sec max)
In my case, much better shield for the programming interface. There is no pic for a reason. I built it from the junk pile. 4 mismatched buttons with loose, uninsulated wie all over.
If there are any questions or criticisms as to the software, let me know. It is not beautiful. I did not include a video, as it is quite boring to watch. About 12 min, tick, about 12 min, tick, etc.
-
New to forum, but not new to controllers and computing and doing things the hard way because I can.
Started with 8080, Z80, 6502, 8031, and IBM system 360 mainframes, doing software, then hardware and have only recently let myself drift to out-of-date. Wrote an IEEE floating point library for CPM on the 8080 (mumble mumble) years ago, did 44.1KHz ADC for Z80 systems (I stil have fond memories of the alternate register bank and non-memory I/O space), and have been teaching both hardware design and software for (mumble) decades. Used an original Basic Stamp as an ignition control for a bike back in the early 90's to replace the mechanical points. Still have one of the wire wrapped Z80 control boards I did for a job back in the 80's.
Picked up a handful of launchpads around newyears to play with. Done a few projects (8 channel temp monitoring/logger for the house to replace the industrial thermcouple sets I used to plan heating and AC -- attick, up, down, and basement, outside three sides, bathroom using DS18B20's; some clock projects; a few others), and have more on the table. I also spend time trying to convince my students that these are real computers, and are more powerful than what I used back in the day for word processing and computational work in engineering. I sideline as a welder/machinist and mechanic for an NBIC boiler shop. (not much of a machinist, but the job gets done)... ahhh. The joys of an undirected life and mis-spent youth.....
Project posting or two to come soon.
Vetinari's Clock
in Projects
Posted
migh be the next version....