Multiple different strobe patterns using hardware only?

Thread Starter

picotrain

Joined Apr 12, 2013
32
I am working on a project where I want to have have an LED with a few different strobe patterns, as opposed to the same strobe pattern, just at different speeds.

Currently I have a 555 timer acting as a latch via tactile switch to turn the device on and off, and a second 555 driving a third, so I get a 4Hz signal on for 1 second and of for 1 second.

Is it possible to do multiple strobe patterns using only hardware, or would this be a job for a microcontroller?
 

ian field

Joined Oct 27, 2012
6,536
I am working on a project where I want to have have an LED with a few different strobe patterns, as opposed to the same strobe pattern, just at different speeds.

Currently I have a 555 timer acting as a latch via tactile switch to turn the device on and off, and a second 555 driving a third, so I get a 4Hz signal on for 1 second and of for 1 second.

Is it possible to do multiple strobe patterns using only hardware, or would this be a job for a microcontroller?
There's a half way house of sequencing the address to patterns in a ROM.

AFAICR: there were 1 bit SRAMS, but you'd have to have a permanent retention supply. FLASH ROM is probably getting hard to find as small as 8 bit, but that doesn't stop it being do able.
 

WBahn

Joined Mar 31, 2012
29,979
A microcontroller (or FPGA) would almost certainly be the easiest way to accomplish that goal, but it certainly can be done with basic hardware logic. A lot would depend on the details -- how many patterns, do they have any relationship to each other, are they arbitrary, are they fixed or do you want to be able to change them easily?

The more constrained things are, the more feasible a pure hardware solution would be.
 

Thread Starter

picotrain

Joined Apr 12, 2013
32
I apologise for my tardiness in replying, I just finished finals.

The more constrained things are, the more feasible a pure hardware solution would be.
So I currently have a strobe pattern that pulses at about 4Hz for 1.5sec, then of for 1.5 sec.
I would like to add :
A 1Hz blinking pattern
A pattern that pulses once then a short delay (0.5sec or so) then pulses twice then starts again.
Of course I'm completely open to changing those patterns, it's just an idea of what it might do.

I would like to use the current tactile switch to cycle between the patterns and the off state.
 

Thread Starter

picotrain

Joined Apr 12, 2013
32
There's a half way house of sequencing the address to patterns in a ROM.

AFAICR: there were 1 bit SRAMS, but you'd have to have a permanent retention supply. FLASH ROM is probably getting hard to find as small as 8 bit, but that doesn't stop it being do able.
I feel like this might be making the project extra complicated, but I really don't know as I have no experience writing to ROMs.
The project is LiPo battery powered so having a permanent retention supply would be no problem provided the current drain was very small.
 

WBahn

Joined Mar 31, 2012
29,979
Of course I'm completely open to changing those patterns, it's just an idea of what it might do.
And this is a major decision point. If you want to change the patterns after you implement them, then many of the approaches will result in completely redoing the hardware design. If you know you are going to possible change the patterns, then you want a design that, at the expense of additional complexity, allows such changes to be made without changing much, if any, of the design.

But if you are willing to freeze the patterns before the design of the hardware and never change it afterward, then some approaches become more reasonable.

I would like to use the current tactile switch to cycle between the patterns and the off state.
Could you explain why you don't want to use an MCU or and FPGA in this design? It will likely be simpler, cheaper, and quicker to get up and going. Not to mention extremely more flexible allowing you to make almost unlimited changes to the patterns later.
 

Thread Starter

picotrain

Joined Apr 12, 2013
32
But if you are willing to freeze the patterns before the design of the hardware and never change it afterward, then some approaches become more reasonable.
That was pretty much my plan.

Could you explain why you don't want to use an MCU or and FPGA in this design? It will likely be simpler, cheaper, and quicker to get up and going. Not to mention extremely more flexible allowing you to make almost unlimited changes to the patterns later.
I did a class this past semester on entrepreneurship in which I designed a bicycle lighting strobe. I figured if I kept developing it to eventually become a product, dedicated hardware would be more cost effective and easier to manufacture than using a microcontroller.
 

WBahn

Joined Mar 31, 2012
29,979
I did a class this past semester on entrepreneurship in which I designed a bicycle lighting strobe. I figured if I kept developing it to eventually become a product, dedicated hardware would be more cost effective and easier to manufacture than using a microcontroller.
I'm glad I asked and that you answered.

If you are developing a product, then you almost certainly WANT to use a microcontroller. An MCU suitable for what you are trying to do here is going to run you something on the order of half a dollar even in fairly small quantities and you can probably get it to somewhere around half that price in moderate volume. It also gives you smaller circuit boards, smaller overall form factor, fewer parts to be stocked and assembled, lower power consumption from your battery.

On top of that, it will give the flexibility to make your product have more features or to have multiple products that use the same circuit as their basis.

By "dedicated hardware" you need to be thinking more along the lines of an ASIC -- application specific integrated circuit. That CAN give you the lowest parts costs, but the NRE (non-recurring engineering) costs can be prohibitive. You can easily spend several million dollars before you have a part and it is going to be very difficult to spend less than a few tens of thousands of dollars just to get the first five to ten parts for evaluation. You need to be on the path -- and have the development budget for -- very large volumes to make that worthwhile. S0 until you have a game plan that is headed toward tens of millions of units, this is probably not a viable path for you. Even if you ARE looking for that kind of volume, the difference between what you can do with a 30 cent MCU and what you can do with a custom ASIC is probably unlikely to shave more than 5 to 10 cents per unit off your BOM (bill of materials), so even if it only costs you $100k to get your ASIC stood up, you could easily be looking at having to sell a couple million units before you break even.

So I would recommend coming up to speed on PIC MCUs. There are other families that could be suitable, but keep in mind that what you want requires very little in the way of features and capabilities. You don't need much in the way of pin count, you don't need very much memory, you don't need much in the way of speed, and you want very low power and very low cost.
 

Thread Starter

picotrain

Joined Apr 12, 2013
32
So I would recommend coming up to speed on PIC MCUs. There are other families that could be suitable, but keep in mind that what you want requires very little in the way of features and capabilities. You don't need much in the way of pin count, you don't need very much memory, you don't need much in the way of speed, and you want very low power and very low cost.
Thanks for the advice, I really appreciate it.
I'm currently playing around with an Arduino that I had tucked away to get a few different strobe patterns set up. I figure that I can get a hex file from that, unless there is a better way to go?

Since the device is to be battery powered, I don't want a uC to be constantly polling the switch that will be used to switch between the different strobe patterns and the off state. I was thinking then that I should have the uC sleeping most of the time and then use the switch on an interrupt to wake up the uC. Does that seem reasonable?
 

WBahn

Joined Mar 31, 2012
29,979
You can use an Arduino for proof-of-concept development, but I don't know how well using it to get the final hex file will work out. I've never used Arduino so I don't know how well designs translate to using the bare MCU in a design. But once you have the design concept working in an Arduino, it should be a fairly straight matter to port the code over to your final MCU.

I would definitely make the design interrupt driven. Depending on the speed of things, you might even be able to toggle a pin to turn an LED on or off and then go to sleep until a timer expires and wakes up the MCU for it to toggle the pin(s) again.
 

Thread Starter

picotrain

Joined Apr 12, 2013
32
I would definitely make the design interrupt driven. Depending on the speed of things, you might even be able to toggle a pin to turn an LED on or off and then go to sleep until a timer expires and wakes up the MCU for it to toggle the pin(s) again.
Thats a great idea, certainly will make it more power efficient.

I did a PIC project for an assignment a few years back. I'm currently downloading MPLABX.
I have a proof of concept running on an Arduino currently.

Thank you for your help, I'll post back here as I progress.
 
Top