Old Dog, New Tricks: 555 Timer in the trash

Go To Last Post
37 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's nice to have a simple victory once in a while :)

A quickie project needed a 14 Hz square wave, with a true 50% duty cycle. No exact tolerances available, but "good"...

In the old days I would have pulled out a 555 timer and spent hours tweaking the R & C values to get both the right frequency and the 50% duty cycle. Some combinations seem harder than others to configure, leading to an additional flip-flop to get the duty cycle right.

A Tiny13 had it done in a couple of minutes, code included, tweaked in a timing loop to better than I can read on a scope.

It's nice to have a simple victory once in a while :)

JC

Last Edited: Wed. Apr 8, 2009 - 04:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the world is surely tilting on its axis! Slowly, steadily. Just as it did when transistors replaced many vacuum tubes and when ICs began displacing discretes. This one has maybe been a bit more gradual but it steadily creeps along.

However, I am constantly amazed at the number of requests on a SPICE list I receive for spice models for '555 timers. I don't think they will totally die, any more than the '741 op-amps.

I wonder about a possible "nifty project" Imagine an AVR with a couple of ADC inputs and a PWM output. Use one ADC input to set the frequency and another to set the duty cycle. Maybe a couple of pins to set the frequency decade. Internal oscillator. Almost a drop-in for a '555!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent, I also used an obsolete micro to act as a variable sqr wave generator. A pot was read by the ADC to adjust the freq, bang on 50:50 as well; it's useful bit of test kit to have around :)

<º))))><

I am only one lab accident away from becoming a super villain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An interesting observation.

I suppose chips like the 555 will always come in handy when you have a piece of equipment that has a supply voltage greater than 5 volts and you want to generate a square wave of like voltage.

And when the xmega replaces the mega (maybe the fourth millennium? :)), change the 5 volts to 3 volts.

Last Edited: Wed. Apr 8, 2009 - 12:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using a micro seems overkill initially, especially to an old-timer like myself but realistically, a $1 micro is just so much more flexible. The saving grace for the old 555 is that it can be deemed more reliable as it is a simple analog device and isn't subject to 'going off the rails' with suspect code or transients. Something to think of when you need an interlock for a critical control circuit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Using a micro seems overkill initially, especially to an old-timer like myself but realistically, a $1 micro is just so much more flexible. The saving grace for the old 555 is that it can be deemed more reliable as it is a simple analog device and isn't subject to 'going off the rails' with suspect code or transients. Something to think of when you need an interlock for a critical control circuit.
I don't want to start an argument but I've found 555s to be hard to adjust and prone to drift and generally going haywire. I did a project recently with an ATiny in place of a 555 and considering external components - it was cheaper. It seems to me a micro would be less likely to drift or go flaky than a 555? Anybody else have any experience with this?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with Smiley (well it had to happen one day). 555s drift and aren't 50:50, I know it 'feels' wrong to use a micro to emulate a timer, but it makes sense :)

<º))))><

I am only one lab accident away from becoming a super villain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But a 555 has nice strong output capable of sinking/sourcing 200mA. That might be a critical point in some apps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure, that drive could be useful. I don't think '555s will ever go away, any more than '741s have. Or, plain 74xxx (no bloody L, LS, S, C, HC, etc).

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I wonder about a possible "nifty project" Imagine an AVR with a couple of ADC inputs and a PWM output. Use one ADC input to set the frequency and another to set the duty cycle. Maybe a couple of pins to set the frequency decade. Internal oscillator. Almost a drop-in for a '555!

Jim

Could probably use a QFN-form AVR and a couple MOSFETs and make it into a drop-in DIP replacement for 555's, with better brains, and probably better drive/sink... ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My point in favour of the 555 was for critical systems - not an application where you require frequency and duty cycle accuracy. By critical systems I mean a system that if it fails may cause death and/or destruction. In these applications, the humble microcontroller needs a little help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a block of 556's I may never use

The largest known prime number: 282589933-1

Without adult supervision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
My point in favour of the 555 was for critical systems - not an application where you require frequency and duty cycle accuracy. By critical systems I mean a system that if it fails may cause death and/or destruction. In these applications, the humble microcontroller needs a little help.
No offense, but this is kind of scary. I don't have a lot of experience with 555s, but I do remember one my Profs who often muttered that 555s were 'dangerously flaky pieces of shit' - his words, not mine. So if I were tasked with a life critical system, I research long and hard before I'd use either a 555 or a microcontroller. IIRC correctly, every datasheet I've ever seen has a statement at the end that the device must not be used in life critical systems, so I think everybody is skittery about that kind of application. Which brings me to a near non-sequitor in that I know too much about electronics and microcontrollers to ever feel safe on a fly-by-wire aircraft.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hydraulic lines, steel cables or wires that snap, the effect is the same. No airliner of any reasonable size can do without some form of assistance. Hydraulic actuators can also lock up, leak, break etc. Sometimes just due to a piece of debris invisible to the naked eye.

I've seen a lot of Aircraft Investigation episodes, and electronics failure is not a very common cause of crashes. If it is, it's usually fire caused by wiring.

Most crashes are either pilot error or mechanical or structural failures. Or maintenance procedures not followed corrected; the life of many literally can depend on a simple row of rivets or the proper type of screw used to hold a windscreen for example.

Writing aviation certified software is very difficult, literally every line of code or change has to be checked, explained, documented and certified. Cannot be compared to the quality of everyday firmware you'll find in common devices.

I don't feel unsafe in a fly by wire aircraft because of the electronics on board. There are so many other points of failure than just the electronics.

I always wonder where medical equipment manufacturers get their ICs from as every datasheet I've seen has a 'not for life-critical or life-sustaining applications' disclaimer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I worked for BAe Military Aircraft our fly-by wire aircraft had three flight control systems, programmed by different teams, using different hardware.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recall working on equipment that attached to the mil-std-1553 bus, also known as the SAE 1553 bus. That's the "wire" that some military aircraft fly by. I don't know about non-military aircraft.

I think it's a twisted pair inside a braided shield. The military uses two redundant busses and can switch between them quickly.

I still prefer ground transportation. Travel by horseback sounds good.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think they use fibre-optic cables now - much lighter than copper and not affected by EMP. They use multiple cables, of course, in case one fails or is damaged.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do they (still) run those cables as a group or over different parts of the plane?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like the micro approach to the OP's solution better than the '555 as well. smiley was spot on regarding drift, and aging of the components. also the cost of board space for the externals is also an expense as well.

Nice job to the OP. In order to be competitive, one must look at both the reliability, and the cost to succede.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Do they (still) run those cables as a group or over different parts of the plane?

I don't know. I wondered about that myself. I left that project before it got installed and I never got near an aircraft. Each device, at least the critical ones, have to be connected to each bus so I suppose the two cables need to get close together occasionally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Most crashes are either pilot error or mechanical or structural failures.
Or insufficient altitude . . .

Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or the wrong altitude, or lack of fuel,or misunderstandings between the control tower and crew.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any chance you could post the code/explanation for newbies like myself to experiment with? It may be easy for most you guys but not so simple for the novice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello rfb2000,

Welcome to the forum.

Be sure to look at the Sticky Thread for beginners, and at the Tutorials section.

This Thread wasn't really about the project, just about my transition from "the old fashioned way" of generating this signal to the "new way", which was much easier and much, much faster.

That said, here is the schematic and Bascom (Basic) code to flash the LED at 14 Hz, 50%-ish duty cycle.

Part of the schematic with the original load was removed, as it isn't pertinent to this disucssion.

Even this program can be shortened, but this method allows one to tweak each half of the duty cycle separately.

The Period of a 14 Hz Square wave is 71.4 mSec. Each half of the period, one half high, one half low, will be 71.4/2 = 35.7 mSec; hence the values in the code.

JC

'File Name:  Tmp.bas   4/09   JEC    Bascom AVR

'Purpose: Flash an LED at 14 Hz, 50% duty cycle, (Square Wave).
'Additional Load and function deleted from post.

'Uses ATTiny13 with Internal RC OSC, Clock is +/- 10%!!
'It has ONLY 64 BYTES of SRAM.
'Initial setup on STK500 with Std LED.
'ATTiny13 Clock choices: 9.6 MHz, 4.8MHz, 128KHz; all Internal.
'Decrease the "Default" HWStack, SWStack, & Framesize for
'the Tiny13, given its miniscule SRAM size.

'Programming Notes:
'On STK500:
'ATTiny13 goes in Blue Socket ...D1
'PE5 RST is tied to PB5, (The Reset\ Signal for programming).
'As the micro is using its internal clock, one does not have to
'connect the STK's Clk to the micro's Clk.

'With a sample of one chip, at room temperature, the following
'gives a 14.0 Hz 50% pulse train.
'Note: The Freq will change with chip and temperature!
'Could use interrupts, but it would still be inaccurate based
'upon the internal RC Osc Clock and its drift.

'Hardware Definition:

'Port B: LEDs and ISP Programming
'Bit 0   =  MOIS
'Bit 1   =  MISO
'Bit 2   =  SCK
'Bit 3   =  LED High = On
'Bit 4   =  External LOAD
'Bit 5   =  Reset\
'Bit 6   =  N/A
'Bit 7   =  N/A

'-----------------------------------------------------------------------------------------

$regfile = "attiny13.dat"                                   'Specify the used micro
$crystal = 9600000                                          'Specifiy Micros Clock Frequency

$hwstack = 8                                                'Default is 32 for the hardware stack
$swstack = 8                                                'Default is 10 for the SW stack
$framesize = 24                                             'Default is 40 for the frame space

'Now Configure the Port's Pins for Input or Output mode.
'0 = Input, 1 = Output
   Config Portb = &B00011000                                'Now Config PORT Input/Output

   Waitms 200                                               'Start Up Delay

Main:
   Do
      Set Portb.3                                           'Set Port B Bit 3 High
      Set Portb.4                                           'Set Port B Bit 3 High
      Waitms 36	                                          '36 mSec Delay
      Waitus 450                                            '450 uSec Delay  
      Reset Portb.3
      Reset Portb.4
      Waitms 36
   Loop                                                     'Forever

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't disagree with using an AVR for this app, but the 555 is still reasonable hardware.

For the OP app a 555 at 28 hz with a divide by 2 would have handled the problem -- instant symmetrical square wave.

The 555 has a bad rep, but it was actually the 556 that caused most of the problems -- basically because of false triggering. Also, the oscillator app is dead reliable ( vs a triggered one shot).

But, just as I've gotten used to op amps replacing transistors, I can see microps doing simple tasks. I just don't have the familiarity to do such things quickly.

On the other hand I can easily make a transistorized eccles jordan astable multivibrator :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks JC. Much appreciated. It will only take me a week to get through that code! But, it will be worth it.

I have been lurking around for a while looking through tutorials and the beginners stuff. What seems second nature for most of you guys has a pretty time consuming learning curve. This example helps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the intention of my comments got lost in the mire! Whilst at first glance it seems perfectly reasonable to replace something simple like 555 with a microcontroller, there can be a number of hidden gotchas. If the application is just flashing a led, the implication of a failure is very little. However, if the device under control is a little more dangerous, say a heating boiler, failure could be a little more serious. With a simple device the failure modes are usually easy to predict, on something like a microcontroller - not so easy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doc JC,

I have been trying to teach myself C and didn't know you could use BASIC for the AVR. I looked at your code, was puzzled and then realized it was in BASIC. I downloaded the Bascom compiler/programmer and managed to get the circuit working on a breadboard after loading the compiled code into the ATTiny. I was surprised at being as excited as I was to get an LED flashing!

I am really glad I asked you for the example because I am much more comfortable in BASIC. I ordered a book on it for the AVR microcontroller.

This seems easier for me than hassling with a bunch of resistors and capacitors. Never mind that you can change the frequency with software.

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rfb2000,

You are very welcome!

I am glad you are off to a good start!

The ATTiny13 is very small and limited compared to several other chips which cost just a bit more.

This Atmel web page: AVR 8-Bit RISC Devices lists all of the AVRs. At the top is a clickable link to a Parametric Product Table, which shows the key features in a tabular format.

Pick a bigger chip to further your learning and experience. The Mega168 is a good choice, but six different people will give you six different recommendations. This will give you more features to experiment with, and help keep you from running out of program space to quickly.

Congrats on getting your system up and running!

Kartman,

Your point is well taken. For this particular project, it was a quickie, and non mission critical. I had it designed, breadboarded, coded, programmed, and running in less time than it would have taken to get a 555 even close to what I wanted/needed. Redundancy is always indicated on a mission critical application.

Quote:
555 at 28 hz with a divide by 2

Ford2Go,
As I mentioned in my origianl post, I've often resorted to adding a flip flop to get a 50% duty cycle from the 555 in the past. That solution works well, and saves hours of tinkering with R & C values and starring at the scope. For this project, however, one Tiny 8 pin dip met my needs, saving a chip and space, and Lots of Time.

Quote:
Do they (still) run those cables as a group or over different parts of the plane?

JayJay, wasn't it a Trident crash where the post accident investigation revealed that it was a failure in the middle engine, (located at the base of the rudder), that sent shrapnel to the electrical (?) / Hydraulic (?) lines for engines 1 & 3, which ran along each side of the central engine. The single failure in the central engine then knocked out the other two engines. I think this particular accident was one of the factors leading to the change in airframe systems routing.

I bet it would rattle of lot of cages to discuss relacing an equally old ledgend, the NE567 Tone Decoder, with an AVR and the Goertzel algorithm!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doc - I think it was a DC10 where the tail engine knocked out the hydraulics. The pilot managed to land it by spiraling down to earth.
http://en.wikipedia.org/wiki/McD...

You would use the goertzle algorithm for multiple ne567s! otherwise you could emulate the pll digitally. Similarly, you can use a triac or solid state relay to replace the classic old mechanical relay. For the most part it works and works well, however, triacs can fail in a half wave mode thus causing big problems for inductive loads! Then you probably want voltage protection and current protection - doing this adequately can make the humble old relay quite simple in comparison. That is not to say "never use a triac" but understand the limitations of what you're using. Just like it is to write software that behaves as you expect with ideal inputs - the real world is far from ideal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman,

Quote:
Doc - I think it was a DC10

Right you are! I still can't find the specific NTSB report I'm thinking of, although I can picture it in my mind...

Maybe, to steal from another thread, Ross's Iron Triangle should be: Analog - Digital - Software!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Hi Kartman,
Quote:
Doc - I think it was a DC10

Right you are! I still can't find the specific NTSB report I'm thinking of, although I can picture it in my mind...


Perhaps:
http://libraryonline.erau.edu/on...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I was writing "trusted" firmware, it had to be "fail-safe". That usually involved multiple hardware components checking each other. The important thing was that a single failure wouldn't do any harm even if the system didn't operate, and the status of the system had to be obvious. I tended to use 74x123 retriggerable monos rather than 555s as back-stop watchdogs to catch if an event had not happened - but the idea is the same. The timing from MCUs is better but you feel better with a different technology monitor.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that I would trust the reliability of a single 8 leg microcontroller with external components of one ceramic capacitor, above the minimum components of a 555. Vcc, GND, o/p is all that is required.

I suspect the long term stability of the Tiny RC clock would be better than the RC of a 555 in possibly a humid atmosphere.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thinking it will be more reliable is not really a good argument if you need to defend your design in front of a certification committee :D How do you prove it?

Fact is that a uC has a lot more failure points, just a single bit that's flipped by whatever cause can wreck its functionality. A watchdog is really a bit of kludge.

MISRA for example recommends to regularly check port direction bits, and if necessary rewrite them.

The smaller geometries of an AVR make it likely more susceptible to radiation effects. Unless a modern 555 is also manufactured in modern small scale geometries, I don't know.

It would be an interesting experiment to have MTBF figures of both.

If you need 50% duty cycle, a 4060 works nicely too and won't have the initial longer cycle on startup.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was working on the basis that most failures are at the external connection level rather than inside a chip.

On the other hand a serious over-voltage would probably kill the Tiny first.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I heard from several sources that interconnects are indeed a (major) problem. IIRC the Apollo flight computer was wired wrapped then potted in epoxy.

RoHS make things worse too; BGAs that simply fall off and tin whiskers that grow between pins :D