Author Topic: 555 - or something else  (Read 4523 times)

0 Members and 1 Guest are viewing this topic.

Offline TantalTopic starter

  • Contributor
  • Posts: 31
  • Country: nz
555 - or something else
« on: June 05, 2015, 11:45:51 pm »
I would like to generate a signal like this (sector shown is 2 seconds long):



My first idea was to use two 555s and an AND gate and create the signal as a combination of those two signals:



I also thought about using one of those old SN76489 sound chips (used in Sega consoles) that have three square wave tone generators, but I don't think they can produce such low frequencies - and not sure about syncing the tone generators (this is crucial here).

Do you have some better ideas on how to create this signal (I've never worked with 555s before - I'm an absolute beginner)?
 

Offline Seekonk

  • Super Contributor
  • ***
  • Posts: 1938
  • Country: us
Re: 555 - or something else
« Reply #1 on: June 06, 2015, 12:03:10 am »
You won't want to hear this, but I use those $3 (like the quality better than the $2 ones) mini328 boards for things like this.  Last thing I needed was random width pulses between 4 and 14% duty cycle.  It was just a couple lines of code and it comes with its own breadboard.  I've given up slapping chips together.
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12856
Re: 555 - or something else
« Reply #2 on: June 06, 2015, 12:59:54 am »
It depends - Whatever 8 pin MCU you have the tools to program and a decent C compiler for, or a possibly multi-chip LSI solution.   Its worth noting at this point that you don't need an AND gate,  Simply use a 556 dual timer (or 2x 555) and  have the slow oscillator hold the fast one in reset.

The MCU solution requires a supply in the 2V-5V rage. Over 5V it needs a regulator and if the required pulse amplitude is also over 5V it will need a level shifting output stage.

The  556 and similar solutions will happily run form supplies in the 5 to 15V range, delivering far more output current without needing an external output stage, but will need precision timing components or very careful adjustment.  Long term stability is not likely to be good.

If you are familiar with the toolchain, and have the MCU in stock, you can breadboard it and program it for a sequence that simple in under an hour.   It could easily take you twice that long futzing around sourcing non-standard cap and resistor values to get the timing right for the 556 version, or scoping it and tweaking presets.



 

Offline TantalTopic starter

  • Contributor
  • Posts: 31
  • Country: nz
Re: 555 - or something else
« Reply #3 on: June 06, 2015, 02:31:44 am »
You won't want to hear this, but I use those $3 (like the quality better than the $2 ones) mini328 boards for things like this.

I already use a 328 (for other things in this project), but because I can't multithread with it (or at least not in a simple way) I thought I outsource this pulse generation functionality to a simple. external circuitry.

Actually, you gave me an idea: Why not let this external circuitry be a second 328?

Strange, now it seems so obvious. It's just: I never used two (or more) of those in one project. I guess I need more "thinking outside the box"  ;)
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12856
Re: 555 - or something else
« Reply #4 on: June 06, 2015, 02:55:05 am »
Who needs multithreading for simple waveform generation in the background?   

Its slow enough that you could simply use a timer interrupt, but if you have other interrupts you need to service, a 16 bit free running timer with output compare modules to drive the pin with hardware edge timing means the ISR doesn't have any critical timing as long as it updates the compare register before the next edge by adding the time between edges to it. And yes, I've checked, a ATmega328 does have the right hardware to do that.

I mostly use Microchip PICs, and on them, such an approach is easily capable of generating four channels of Futaba RC servo control waveforms (50hz 1ms to 2ms variable duty cycle pulse), jitter-free with better than 1us resolution while concurrently running an interrupt driven USB stack,+ whatever foreground task is needed.
 

Offline Seekonk

  • Super Contributor
  • ***
  • Posts: 1938
  • Country: us
Re: 555 - or something else
« Reply #5 on: June 07, 2015, 10:09:28 am »
I encourage neophyte programmers to write what I call single line code, each line stands on its own no matter where they put it in the program and not to do ay branching. That produces a program loop that is fairly uniform in timing. On non critical timing that is relatively slow I just count the program loops and reset counter after so many. Generally the program is so fast that the delay routine has to be used
to slow it down. This is a little clunky but adjusting the delay controls the loop time. I don't know if your loop time is consistent (a number of serial prints can throw it way off), but this explanation may help someone.  Most of my programs include a status indicator using the on board LED.  The following is an example.



// FIRST BLINK - JUST TO SHOW THAT THE PROGRAM RUNNING
if (blinktime == 1)  digitalWrite(13, 1);       
// pin #13 is the on board LED, 1 is ON   
if (blinktime == 20) digitalWrite(13, 0);       
// turns the LED off so it blinks
   
// SECOND BLINK - IF DRIVE GREATER THAN 35
if (blinktime == 50 && PWM3 >= 35) digitalWrite(13, 1);                                 
if (blinktime == 60) digitalWrite(13, 0);     
// sets the LED off so it blinks
   
// THIRD BLINK - IF DRIVE GREATER THAN 70
if (blinktime == 90 && PWM3 >= 70) digitalWrite(13, 1);   
if (blinktime == 100) digitalWrite(13, 0);
   
if (blinktime == 200) blinktime = 0;   
//reset timing loop
blinktime = blinktime + 1;             
// increment loop counter

 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: 555 - or something else
« Reply #6 on: June 07, 2015, 03:29:20 pm »
I would prefer using an interrupt if possible.

Your method works fine if the rest of the program is deterministic but if not (some routines taking more cycles between the main loop) it will make the counter a bit erratic by delaying the blink when executing longer routines as you already mentioned as loop time not being consistent.

But of course you can throw that code into the interrupt, but I don't know if I would want to i/o writes within the interrupt itself depending on what the rest of the program does.

Also I find it peculiar that you use a bitwise and (&&) instead of the logic and (&), don't get me wrong, it will work since most compilers will use the same value for true so it will work fine but it's just odd to use it in that context.

As for timing, your code will loop faster when there is no digitalWrite performed which is fine for non critical timing or if you compensate for the timing difference somehow.
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12856
Re: 555 - or something else
« Reply #7 on: June 07, 2015, 03:34:07 pm »
The trick with the superloop approach is to make sure the worst case loop execution time is significantly less that the timing jitter you can tolerate, then add code at the end of the loop to wait for a hardware timer to timeout and reload it so that the total loop execution time becomes fixed.   That makes N passes of the loop a totally predictable interval.
 

Offline firehopper

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: us
Re: 555 - or something else
« Reply #8 on: June 07, 2015, 06:16:26 pm »
I could do this with a counter and couple nand gates I think
 

Offline max_torque

  • Super Contributor
  • ***
  • Posts: 1280
  • Country: gb
    • bitdynamics
Re: 555 - or something else
« Reply #9 on: June 07, 2015, 07:51:36 pm »
For this sort of thing these days i just use something like an AtTiny85 or similar.  They are incredibly cheap, and if you aren't making thousands of devices, just socket it on the application and program it with a STK500 or breadboard ISP etc.

Use the internal oscillator option, which you can calibrate, and they become a very simple go-to for all your pulse output requirements.  It's worth noting the internal osc does have a poor temperature stability, but so does any 555 timer circuit unless you pick your components very carefully!

 

Offline LukeW

  • Frequent Contributor
  • **
  • Posts: 686
Re: 555 - or something else
« Reply #10 on: June 08, 2015, 03:47:27 am »
Will the RC timing of a 555 provide enough precision for your application, or does it have to be, say, a crystal?

Maybe use a 556 instead of two separate 555s.

And if you can use the output of one to gate the output of the second timer (or just shut it down by pulling the reset input low when the first timer's output is low) then you might not need the AND gate - just one 14-pin chip, and a few discretes.
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: 555 - or something else
« Reply #11 on: June 08, 2015, 04:55:49 am »
555 4017 1n4148's.
 

Offline TantalTopic starter

  • Contributor
  • Posts: 31
  • Country: nz
Re: 555 - or something else
« Reply #12 on: June 08, 2015, 10:59:09 am »
Will the RC timing of a 555 provide enough precision for your application, or does it have to be, say, a crystal?

I have never used a 555 - so I don't know. But I assume that the precision of the 555 is sufficient. All I want to do is make 4 LEDs blink with this specific pattern. As long as the timing doesn't vary, say, 25%, it's OK for me.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf