I sincerely hope not! I just got through recapping a Philco TV set from 1952. Replaced all capacitors and a few faulty tubes and it sprang back to life, good as new. (Most of the original carbon comp resistors are even in tolerance!)
Incidentially, I discovered that not all of the box shaped, dot- labelled capacitors are mica. The bigger ones (>1nF) are paper inside.
Tim
Because it works? OTOH, changing the timing in an analog circuit is difficult if it means modifying a lot of components on a lot of boards. If you go analog, you must be sure it is right before going into production. Which is not necessarely a bad thing because it forces you to really think about what you're doing.
I recall designing a device and using a GAL16V8 for some simple logic functions (including some timing). I used an extra 74HC14 to have schmit-trigger inputs for the RC timing networks. Having something programmable in a circuit can help to implement those last-minute changes some customers like to make.
But... using a PIC is a really bad idea. I never was a fan of PIC controllers based on what I've seen being made with PICs and the specs from Microchip. Unfortunately one of my customers has a product for which the PIC 16Fxxx firmware needs to be rewritten by me. Throwing out the stock is just too expensive. The PIC processor's architecture is even worse than I thought. Multiple memory banks, weak instruction set. I need to jump through a lot of hoops to write C code for it and work around the flaws in the hi-tech compiler. Can't even re-use existing C code because pointers don't work well with multiple memory banks. Having all data global is the most convenient. Altogether it costs a lot of extra development time (=money). I start to wish they had used an 8051! The PIC really is a dead-end around the next corner if you want to get some serious work done.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
More than 10 years seems to be okay if you don't mind minor changes (like from OTP to flash), at least for the simpler chips. I don't think they're any worse than any other part.
Tripot across Vdd-Vss and read it with a 10-bit ADC, you could have the range from 0.5 to 0.6 seconds or whatever you like.
I just stuck a low end micro (happened to be a PIC) in as a 5-second monostable to protect a sensor against idiotic^H^H^H^H buggy software. No external components (power gets cycled every time it operates). I think the code took less time than it would have to do a worst-case calculation of analog timer periods.
And low end dev kits capable of doing debugging cost less than a cheap PCB turn, so that's no longer an excuse. ;-)
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
The OP asked for minimal component count. A micro (PIC or whatever) is best for that
Dave.
-- ================================================ Check out my Electronics Engineering Video Blog & Podcast: http://www.alternatezone.com/eevblog/
You're comparing a PIC to a real CPU. This thread was comparing a PIC to
74-series logic. Do you actually need to use C (with pointers, relocatable code etc) to write the firmware for a quad monostable?
Tell that to the countless manufacturers who use PIC's in almost every conceivable embedded device on the market. They didn't make it to the #1 position in 8 bit micros at one stage for no reason.
Dave.
-- ================================================ Check out my Electronics Engineering Video Blog & Podcast: http://www.alternatezone.com/eevblog/
Well, it is a substantial compromise from using C++ with inheritance, constructors and destructors. ;-)
But seriously, even the tiniest 12-bit PIC architecture will handle this in assembly without having to fret and whine about diddling those few bits for bank switching. Something that takes up less than a page in PIC assembly is not much of a program (a page in APL could probably program the Apollo moon mission).
The 16-bit architectures (eg. PIC24/dsPIC30/33) are C-friendly. Maybe there's one that's pin compatible with that 16F?
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
I've had very little problem using C on the 16F series PIC's (using the HiTech compiler). IIRC it handled the bank switching and other issues automatically. IME, the perpetual PIC/C beat-up is a load of hot air.
Dave.
-- ================================================ Check out my Electronics Engineering Video Blog & Podcast: http://www.alternatezone.com/eevblog/
On a sunny day (Sun, 10 May 2009 23:12:58 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :
In the old (well very old for some) days NOS (at that time Dutch television network) used equipment from Fernsehn GMBH, nice plugins, LOADED with trimpots. Much analog, anything you could think of had a trimmer :-) Now to service such a thing requires, when replacing just a transistor, a lot of alignment. We need to design circuits so no trimming is needed. Sure for some state of the art stuff, trimmers are needed anyways. The old tek scopes had zillions of those, I have done QC for Tek ... But for normal stuff any adjustment point that can be avoided makes it cheaper. Competition.
With EEPROM and FLASH and digital, as in PIC, you can calibrate via a simple computer link, remotely if need be, I design that in all the time.
Well, if you are religious about that, there is no use to argue, I do not argue with Jehovah witnesses at the door either, but do have good conversation. Does it help them? I dunno.
So you know shit about PICs and blame it on the PIC? Most small micros have severe limitations in registers, instruction set, etc.
Well FYI I have done video on a PIC 12. In asm. But then my old Z80 experiences did make me learn to count instruction cycles, about timing.
Look, if you want to use gcc use an embedded module running Linux.
8051 / 8047 EPROM? Well I have used those, even wrote an assembler for it, designed my own development system, but ... PIC is simpler.Bull excrement.
I've hear they do not even have 'gas' in Almere.
Or filling the ROM with a BASIC interpreter and 3 lines of BASIC.
The 18-series can handle C without much trouble.
FSR/INDF addressing crosses page boundaries rather than wrapping, I/O registers are all in the access bank, you have MOVFF, and CALL and GOTO take 20-bit absolute addresses. The end result is that you should rarely have to deal with bank-switching even if you code in assembler.
If you're programming the 10/12/16-series chips, you really should be thinking about bank/page switching, even if you're programming in C. I.e. grouping related subroutines into the same page, grouping related variables into a common bank etc, rather than storing data and code in arbitrary locations then littering the code with STATUS/PCLATH changes as needed.
With 8086 DOS compilers, you had a choice of using the large/huge memory models which provided a flat address space at the expense of continually modifying segment registers, or using separate "near" and "far" pointers. The former was simpler, but the performance hit was quite noticable.
-- Retriggerable also. See page 9 of: http://www.onsemi.com/pub_link/Collateral/MC14538B-D.PDF JF
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.