Have you considered a Schmitt Trigger oscillator based on a single gate chip?
Something as this: SN74AHC1G14, 2-5.5V, SOT23 so not incredibly small to hand solder.
Yes. I did consider using a separate IC for the Schmitt Trigger for my first attempt, but I didn't have one on hand. :} I thought I'd start out using a couple of CPLD pins due to the integrated optional Schmitt Triggers on inputs. That really didn't turn out well, so going back to a single-gate Schmitt trigger could make it more workable. I could pop a SN74AHC1G14 on a small breakout, solder the resistor and cap directly on top, and probably avoid most of the breadboard-related issues I'm running into. The big plus is that I can control the layout of a separate IC, as opposed to in the CPLD where I can't help that there are either going to be wires (when breadboarding) or traces (when on a PCB) that are going to be positioned fairly close to what I imagine to be a very low current signal coming in. Thanks for the suggestion.
At about 10 cent apiece even in smallish quantities (in EU e.g. on RS, don't know in AU), you just need to add a couple of passives (possibly three, if we include a decoupling cap)..
Mostly around 30c or so in smallish quantities, which seems to be the price point of a lot of the simpler ICs.
Of course, if the problem is signal integrity, this might not be the right cure.
I could well run into similar problems as my first attempt, and I'd be diagnosing them blind until I can get my hands on an oscilloscope. Or it could work perfectly. I'll likely get one to experiment with.
you don't describe the timeout you're trying to detect,
Sorry about that.
The driving need is an emergency reset, which is for when the attached components (including MCU) get into an unrecoverable state. The idea is that you hold down all of the buttons for a few seconds, and it forces a reset. The "few seconds" bit is driving the need. My thinking was that it would also be useful for controlling anything else that requires long presses, timeouts, or similar.
On the other hand, when the MCU is working fine, which it will be most of the time, all of this logic except the emergency reset can be done far more easily on the MCU. So on the other side of the equation is me questioning how essential this functionality even is, and if I should drop it, and just say that if things are so bad and the MCU is so messed up that it is stuck and even the watchdog isn't kicking in, then it's time to open the case and short reset to ground or plug in the debug cable.
Have you considered any of the microprocessor supervisor ICs, commonly called watchdogs? ... but you might be able to directly apply a watchdog chip. They are the classic implementation for detecting wonky micros...
A very quick search found STWD100 from ST - this comes in a few (fixed) timing varieties, but more interestingly has a mode where you can have it constantly re-triggering which could give you a single part low frequency oscillator. Just an idea and probably not fully baked..
Not the cheapest solution probably though at about $1, but I'm sure there are many other options..
It's an interesting idea with additional benefits. I like the idea of cheating and using the reset signal as a clock source, that is very clever.
Thanks for that.
Another idea: If your design needs a real time clock, many RTC chips have a 1Hz output option.
That's something I was considering as well, but the price was an issue. Unfortunately I would have no use for an RTC chip in this case as the MCU I am using has one included. On the other hand, if the MCU did not include one, this would be a superb addition as an RTC clock is a neat thing to include and such an IC would give me that plus a 1Hz signal. Thanks for that.
I agree. That would be, what I would have suggested too. If a buffered output is required, then there's a two gate variant, which doesn't take up much more room and only costs a little more.
I agree. That would be, what I would have suggested too. If a buffered output is required, then there's a two gate variant, which doesn't take up much more room and only costs a little more.
https://assets.nexperia.com/documents/data-sheet/74HC_HCT2G14.pdf
Neat.
I will assume you have good quality decoupling.
I believe so. The CPLD and MCU in my design are on breakouts, but every power input has a cap soldered directly onto the board and attached to the closest ground. Every IC in the breadboard itself has a cap physically adjacent to the power in and a wire cut to the right length to go over the top and end adjacent to the ground.
If you are using solderless breadboards, then it is traditional that you will spend more time debugging the breadboard than your circuit.
That seems to be the general rule.
The period (1s) is almost irrelevant from a signal integrity PoV. What does matter is the rise/fall time, which is probably 1ns or so.
To get a 1s period I'm using some fairly large resistors (470k+), and I've tended to associate them with pending trouble when using them with breadboards, even if I don't completely understand the cause.
If I'm understanding correctly, the rise and fall time for the first solution I used should be very slow and for the second, at least when simulated, it has a slightly weird but slowish rise time (a very rounded corner), but a very fast fall time.
Realise that a traditional rule-of-thumb is BW=0.35/tr, and you will start to understand.
Back of envelope calculations...
Work out the capacitance, C, that an output is driving through voltage V. Work out the transition time, t. The current required to charge/discharge the capacitor is i = CV/t (from C V = Q = i t, ignoring exponential voltage rise)
Wires are inductors; assume 1nH/mm and work out the inductance in a ground or Vcc lead, L.
The voltage induced by the current spike charging/discharging the capacitor is v = Li/t (from v= Ldi/dt). That voltage appears in series with the signals on inputs.
Don't forget that you will probably be having several outputs changing simultaneously, which increases i and v
Much of this is beyond my current understanding, but I'll do some reading and try to gain enough knowledge to put this to use. Many thanks for your thoughts on this one.
...
Now, a few additional comments.
Firstly, I was somewhat tired yesterday and not firing on all cylinders, so I just wanted to add a few things to previous comments:
evb149: Thanks for all of the detail in your post, it has given me many leads to follow. I may have written off some of your chip suggestions a bit quickly as I had thought I could get a 555 for about the same price, but it turned out I was basing this on the 4.5V+ 555, which I can't use.
Old Don: Thanks for the interesting suggestion. Whilst it might not I cannot use in this case, sometimes these sorts of suggestions can lead to creative solutions.
Brumby: Thanks for all of the information on the 555 IC. I do have one buried away somewhere, and whilst I can't use it directly for this problem, I can set up a 5V playground and experiment with it, and get a 3.3V variant if I do decide I want to add it
I also ran into some interesting low-cost ICs while looking around:
TI CD4151B: An low-cost oscillator IC that uses two resistors and a capacitor to produce a basic signal, and then feeds that into a configurable on-chip counter (up to 16-bit) to produce the output signal. Downside is the large voltage range, size, weird startup conditions, and it's not really designed for lower voltages specifically, even if it supports them.
Micrel PL611-01: A low-cost programmable clock generator that can use a crystal or other input signal and from the looks of it *effectively* has a 13-bit counter. With a 32.768KHz crystal I could get a very accurate 4Hz signal, which is really close to what I'm after. Downside is combined cost of parts, I'm not sure it actually supports a 32.768KHz crystal, and I can't seem to find any information as to how you perform its initial programming.
This discussion has given me a lot of leads to follow and a whole bunch of information that I can use in the future, which I greatly appreciate. Thankyou to everyone who has shared their thoughts. I think the problem was a little harder and expensive (resources, parts, time) than I realised. When held up against the benefit it provides, it is hard to justify including, at least in the short-term. In the medium-term, and especially when I get some proper tools (ie. an oscilloscope), I'd like to experiment with some of the parts mentioned here, and perhaps there will be a way to integrate the results into my design.