153.khz from 6MHz? - Page 1
Forum section: electronics / projects

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 05, 2022, 06:39:48 pm
content: Please could someone suggest a cheap, SMD way to divide 6MHz (or 12 or 24) down to 153.6kHz?I need to generate a 9600 baud rate (x16) for a MC6850 ACIA and would like to use the 6MHz output from my FT232RLThanks in advancePSDivide by 39 is pretty close to 9600 baud

author: oPossum
author_rank: Super Contributor
timestamp: February 05, 2022, 06:58:11 pm
content: 74HC4040 and 74HC30If you are using the FT232 with the MC6850, then you don't need to run at a standard bit rate. The FT232 can do 3M / N bps perfectly. Pick any output of the 74HC4040 and the FT232 will have no problem with that bit rate.

author: Benta
author_rank: Super Contributor
timestamp: February 05, 2022, 08:56:12 pm
content: 6 MHz divided by 153.6 kHz gives a 39.0625 division ratio.Now, I agree that 153.6 doesn't have to be 100% exact, but there's no way in h*ll you're going to get even close to a 39 division ratio with a 4040.The CD74HC40103 is 100% programmable and will do a divide-by-39.This will give 153.85 kHz. Should be close enough.

author: Someone
author_rank: Super Contributor
timestamp: February 05, 2022, 09:14:20 pm
content: Quote from: evb149 on February 05, 2022, 09:09:00 pmYes, most of these how to get x frequency from y frequency where both are below 10MHz end up with a MCU as the cheapest solution.Want more precision? add some dither!

author: Benta
author_rank: Super Contributor
timestamp: February 05, 2022, 09:25:37 pm
content: Quote from: evb149 on February 05, 2022, 09:09:00 pmPlus devboard, plus SW, plus programmer. Are those available for $1.06 ? At least the programmer is not free.Just curious.

author: oPossum
author_rank: Super Contributor
timestamp: February 05, 2022, 10:04:56 pm
content: Quote from: Benta on February 05, 2022, 08:56:12 pmThat is what the 74HC30 is for. It resets the 74HC4040 when the max count is reached. There is no need to test the zeros on an up count.

author: Kleinstein
author_rank: Super Contributor
timestamp: February 05, 2022, 10:06:04 pm
content: There are µCs with an essentially free programmer, as a bootloader from RS232. If you still have an old computer with LPT port a simple 2 resistor AVR programmer is possible.Once you have a µC - the questions is if it still takes a 6850 ACIA.2 x HC193 could also make a programmable divider.If the FT232 does not need a standard rate, a simpler divider like /32 would be possible.

author: Benta
author_rank: Super Contributor
timestamp: February 05, 2022, 10:56:02 pm
content: Quote from: oPossum on February 05, 2022, 10:04:56 pmThat STILL doesn't give a ratio of 39. Please post your circuit suggestion.

author: Benta
author_rank: Super Contributor
timestamp: February 05, 2022, 10:57:55 pm
content: Quote from: Kleinstein on February 05, 2022, 10:06:04 pmSo why would you use two ICs instead of one?

author: oPossum
author_rank: Super Contributor
timestamp: February 06, 2022, 01:38:55 am
content: Quote from: Benta on February 05, 2022, 10:56:02 pmfalstad simulation:https://tinyurl.com/y96c5o3b

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 06, 2022, 06:32:51 am
content: Quote from: evb149 on February 05, 2022, 09:09:00 pmrecently working with attiny10... as a quick exercise before i leave, its 8MHz mcu and divide by 52 is needed to get 153.846KHz. we can program in fast PWM mode (timer prescaler of 1) and set OCR0A or ICR0 to 51 (page 83). we can further tune clock calibration (OSCCAL register, page 28) to get even closer to 153.6KHz.. the knock off AVR ISP Mk2 programmer is $20, i just downloaded Microchip Studio 7 for free, much better than the old AVR Studio 4 that i used to use. it sounds more expensive than dedicated ICs but imho it can save in long run from ordering 100 parts for 100 projects. a single order of few bunch of attiny10 pretty much can cover anything that you want to do... and its small 3mm x 3mm footprint too, compared to DIP16 etc, people can mistakenly think its a tiny smd transistor that can do anything.

author: MK14
author_rank: Super Contributor
timestamp: February 06, 2022, 07:07:13 am
content: Quote from: oPossum on February 05, 2022, 06:58:11 pmI'd be worried doing it that way. Because the 74HC4040 is a ripple counter (synchronous would be a lot better, but not always immune from the issues), there would be a risk of a race hazard, causing it to sometimes falsely trigger the reset back to zero counts, BEFORE 39 total divide counts.With some values, e.g. binary 100101, as it turns into 100110, it may temporarily appear to be 100111, while it is in the middle ofripplingthrough the counting sequence. That may cause the 74HC30, to send a runt/glitch pulse (i.e. unwanted pulse) to the divider, resetting it prematurely.N.B. I haven't necessarily chosen the best example values that are problematic, and it may work 99.99% of time, but not at different temperatures, voltages, luck etc.It's difficult to predict, if you would have such a problem or not.You might be able to fix it, by connecting the clock signal, to another of the AND gates inputs, as the clock is active on a low going pulse. By the time the clock signal is high, the binary counter should have had enough time to stabilize all its outputs. It's still not necessarily perfect, but might be enough to fix it in practice for low end hobby work.Also, I'm puzzled, because your simulation link seems to show an AND gate, but the chip number seems to be a NAND gate.EDIT: Silly typo

author: oPossum
author_rank: Super Contributor
timestamp: February 06, 2022, 07:28:50 am
content: Quote from: MK14 on February 06, 2022, 07:07:13 amI think it will briefly be 100100 because Q0 must go low before Q1 will go high. So the 'glitches' will always be lower numbers.QuoteI incorrectly assumed the '4040 was active low reset. It isn't. So an AND gate must be used instead of NAND.

author: MK14
author_rank: Super Contributor
timestamp: February 06, 2022, 07:44:39 am
content: Quote from: oPossum on February 06, 2022, 07:28:50 amWhat you said is somewhat right, but there could be a rare race-hazard risk.The Q0 output getting to the AND (or NAND) gate, has to go through any output buffering and logic, as part of that binary divider (74HC4040), plus until it gets close enough to what the 74HC30, is interpreting as a logic '0' voltage.So, in a worst case scenario (and hence the term race-hazard), the flip-flops of the divider, may have reacted enough to set Q1 to appear to be a logic '1', yet Q0 has not filtered through the extra (external) logic, buffering and physical wiring (capacitance) delays, and time to reach a low enough voltage to be classed as a logic '0'. Hence a small runt/glitch unwanted pulse, may appear long enough to potentially activate the reset line.tl;drInternal flip-flops may switch states rapidly, but actual Q0 output, could be slower, because of additional logic, buffering and external capacitance delays, plus differences between the 74HC30's interpretation of what voltage exactly is logic '0', and the internal flip flops, which may be somewhat different.EDIT: Silly typo

author: Benta
author_rank: Super Contributor
timestamp: February 06, 2022, 08:10:55 pm
content: In the projects I've worked on, gating the outputs of ripple counters was an absolute no-go, and would result in a serious talk with the project manager.It's simply bad design.Ripple counters were fine for simple 2-to-the power-of-N dividers, but forbidden for everything else.For real counting and division, synchronous design was mandatory.I was taught that principle and support it 100%. Gating ripple counter outputs may get you by until you get the next batch of counters/gates, or until it has to operate at extreme temperatures.It's bad digital engineering.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 07, 2022, 07:27:00 am
content: It is just... wrong. The fact it might work by accident is bad excuse.With a flip-flop to make it synchronous logic, then it's just fine.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 07, 2022, 01:58:12 pm
content: Thanks for all the interest...I do seem to have a number of obvious options...1) Use a XTAL... 74HC4040 would be fine combined with a 4.9152MHz2) Use a uP...http://www.leapsecond.com/pic/picdiv.htmseems like a tempting pattern to follow... PIC12F675T-I/SN should be available around March 2023!

author: Benta
author_rank: Super Contributor
timestamp: February 07, 2022, 07:22:36 pm
content: Quote from: Siwastaja on February 07, 2022, 07:27:00 amSo now we're at three ICs instead of just one?

author: Benta
author_rank: Super Contributor
timestamp: February 07, 2022, 07:25:51 pm
content: Quote from: NivagSwerdna on February 07, 2022, 01:58:12 pm74HC40103 is available now:https://www.digikey.com/en/products/base-product/texas-instruments/296/74HC40103/13011

author: Someone
author_rank: Super Contributor
timestamp: February 08, 2022, 12:59:39 am
content: Quote from: Benta on February 07, 2022, 07:25:51 pmBy your same stupid logic:OMG DIGIKEY DONT HAVE 74HC40103D IN STOX WORST IDEA EVAR!Are cheap 8 pin surface mount PIC12F models in stock? yep, and cheaper than the logic option.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 08, 2022, 08:22:25 am
content: Maybe 20 years ago the threshold of doing a microcontroller project was higher, there really were lots of people who were experienced in electronics but didn't have the necessary hardware or experience to write even a simple MCU project without it becoming a huge task. Many would have preferred even a 10-IC logic solution!Eventually, almost everyone bit the bullet and once you get into the habit of solving problems with microcontrollers, it just becomes easy enough to do a clock divider with it, for example.

author: Circlotron
author_rank: Super Contributor
timestamp: February 08, 2022, 09:25:14 am
content: Quote from: MK14 on February 06, 2022, 07:07:13 amYep, the clock ANDed with the sum of all the other ANDs. If the Q outputs have settled by the time the falling edge clock goes high again then all will be good.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 08, 2022, 10:44:36 am
content: Quote from: Siwastaja on February 08, 2022, 08:22:25 amagree. what i dont understand is why people still want to stick to pic 8 bit mcu esp with the archaic Fosc/4 system clock logic. i was in love with pic10f206 because of the footprint size, i still have a few in stock. when i got and programmed the attiny10, i dont have reason for the pic10f206 anymore except... to clear up my stock... if someone in love with soic8, there are tiny13 or tiny85 that can run 8 times faster, faster means less jitter which suited this particular case of clock division (esp for fancy app using software division). (edit: checking digikey... attiny10 soic8 is available too for $0.74, $0.43 for sot23-6)

author: Siwastaja
author_rank: Super Contributor
timestamp: February 08, 2022, 11:02:12 am
content: I think "PIC12F" in this case is a code name for "any cheap and small microcontroller you are most comfortable working with".

author: Ian.M
author_rank: Super Contributor
timestamp: February 08, 2022, 11:22:13 am
content: @Mechatrommer,IMHO a cycle accurate simulator and extremely predictable interrupt latency were a large part of the historical popularity of Microchip PICs. Unfortunately, Microchip lost the plot and let core teams disperse without adequate knowledge transfer, leading to their decision to retire MPLAB 8 as unmaintainable and go with Netbeans for MPLAB X. As a consequence of this changeover basically scrapping the simulator codebase, it took several years before the MPLAB X simulator became equally trustworthy, causing many formerly loyal users to seriously look at competing MCU manufacturers.Quote from: Siwastaja on February 08, 2022, 11:02:12 am... and that has either a cycle accurate simulator, or that makes it easy to code in assembly language so the execution time between output edges can be accurately controlled. Of course there is always the option of throwing more capable hardware at the problem, e.g a MCU with a cycle accurate output compare module.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 08, 2022, 02:07:33 pm
content: Quote from: Ian.M on February 08, 2022, 11:22:13 ami recently upgraded to Microchip Studio 7 (was AVR Studio 7) from AVR Studio 4 because ver4 cant program TPI for tiny10. the transition was a wonderful experience, with very little code change and i can reuse my library without modification, and the IDE GUI is much much better and not so bloated. i wonder why they dont combine all their pic and avr line using only one IDE, they have XC8 lib/compiler for AVR, sounds like MPLAB X (for pic), but for avr mcus, we have to pay to get optimized/pro version, so i'm not sure whats the point since i can still select free GCC compiler that i'm familiar with. looks like they've put their effort on something that is less useful. if they can combine all their mcu lines in one IDE, it should theoretically much more easy to maintain by smaller team and better experience for users. afa simulator is concern, i wish there is simulator inside studio7 to simulate random interrupts entry inside the code, because thats the hardest and time consuming to solve. such as my recent code with 2 interrupt vectors, i thought both will be triggered/called even if waiting for the first interrupt to be served, how wrong was i after many hours of debugging at HW level, not described or hinted in the datasheetQuote from: Ian.M on February 08, 2022, 11:22:13 amare you serious? i had to manually switch banks in asm to access some registers in PIC, i thought what kind of abomination is this? coupled with Fosc/4 i thought this architecture should deserve its place in some museum, but... ymmv.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 08, 2022, 03:43:09 pm
content: Quote from: Ian.M on February 08, 2022, 11:22:13 amCome on, it's so small a problem it doesn't need to be elegant or repeatable across compiler versions etc. You can just write it in C and adjust with oscilloscope until it works. Might take even 5 minutes. 5 lines of code.No one would throw a Cortex-M7 at this problem anyway.

author: ve7xen
author_rank: Super Contributor
timestamp: February 08, 2022, 06:41:44 pm
content: Quote from: Siwastaja on February 08, 2022, 03:43:09 pmOr just use a timer output, which even in the smallest of micros can do arbitrary integer clock division easily. You can even generally sleep the core permanently once you set it up, unless you need an divide by N/N+1 or something. The whole idea of cycle-counted delay loops for timing is a bit absurd these days. I guess the time-nuts have an idea that the simpler the core logic, the better for timing purposes (less state transitions causing power fluctuations or whatever), but I can't imagine even a PIC core is less logic than a timer peripheral in an AVR or ARM. Wonder if anyone's tested the jitter performance of such dividers...

author: electronsandstuff
author_rank: Newbie
timestamp: February 08, 2022, 11:21:02 pm
content: Quote from: MK14 on February 06, 2022, 07:44:39 amWhat he said is right and his suggested circuit is in fact an example of basic ripple counter decoding which I can assure you, in both theory and practice, is perfectly robust. The specified Qn-to-Qn+1 propagation delays for a relatively slow ripple counter chip such as the 74HC4040 are large, accumulative, do not behave as you have imagined, and practically guarantee glitch-free decoding for all binary valuesbelowthe terminal count. The ripple counter delays with this type of decoderwillcause decoding glitches for the decoded pattern of 1s in binary valuesabovethe terminal count, but in this circuit the counter is reset at the terminal count so that is of no consequence.I've applied this exact kind of decoding to ripple counter outputs literally hundreds of times where appropriate (with designs duplicated in the thousands) and learnt what is bad and what isn't back in the day, in part, from studying this type of asynchronous decoding applied in commercial electronics (both in the classroom and self-study), examples of which were manufactured in the freaking millions and did not just "work by fluke"Competent logic designers back in the day did not waste board space and use an excessive number of costly IC packages to implement complex synchronous logic where it wasn't strictly required.

author: MK14
author_rank: Super Contributor
timestamp: February 08, 2022, 11:37:04 pm
content: I'm sorry, IDON'Tagree.So, fine. As I'd stated, it happened to work out for you. That one or more times.That doesn't mean across various logic device series, component variations, etc. It is a robust and 100% reliable method to design circuits with.I want my circuits to work with as close to 100% reliability and consistency, as reasonable viable. Not circuits that work until it rains on a day with a full moon.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 12:01:32 am
content: Quote from: electronsandstuff on February 08, 2022, 11:21:02 pmWow!First post, and a chip on the shoulder the size of a log.My suggestion: listen a bit to the discussions here first, before going in with blazing guns. This is not Telegram, but an electronics engineering site.Synchronous designs are normally not more complicated than 1980s ripple counter hobby designs. But they do need a bit more thinking about. (You know: brain).

author: electronsandstuff
author_rank: Newbie
timestamp: February 09, 2022, 12:02:57 am
content: Quote from: MK14 on February 08, 2022, 11:37:04 pmOne or more times? Did you read what I wrote - 100 of designs and 1000s of times/duplications for myself and millions of duplications for commercial designs not of my own (think early arcade machines and some computers video generation circuitry before CRT controller chips came along).QuoteIt is perfectly robust in specific, properly designed instances. The circuit under discussion here is one such example. I basically explained why. Do a timing analysis.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 12:45:18 am
content: Quote from: electronsandstuff on February 09, 2022, 12:02:57 amHow would you know if it has worked or not ?If it sometimes glitches and flashes white (or the wrong colour, or goes dark or even latches up completely) in places on the arcade machine, when it shouldn't, how would you know ?What if the next time, your circuit idea was used in a nuclear power plant, and it exploded and caused terrible damage.It is NOT recommended to use (i.e. rely on) ripple counters, while they are rippling through their counting sequence. To avoid the risk of race hazards, Metastability if the signals get fed back into flip-flops, etc.With the (already mentioned) exception, of using them as ...Quote from: Benta on February 06, 2022, 08:10:55 pmThey also can be rather noisy, electrically speaking.Electronics has various rules of thumb and things to avoid doing. If you want to bend the rules, don't come crying to me, with your failed manufactured units.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 01:09:25 am
content: Quote from: electronsandstuff on February 09, 2022, 12:02:57 amI ignored the unsourced figures you supplied, on purpose. I (where applicable) try and go by official information sources, such as datasheets, books. Not because someone on a forum says to do something, and they have tried it hundreds of times.That way, if there are troubles, further down the line. It can be shown, how/why the design decisions were made.(Hypothetically) saying to a boss/customer/etc, sorry the design overloaded and let the magic smoke out. But a very low post count user on a forum, said they had tried it a number of times (or a million times, if you like), it is fine.May not protect ones livelihood and/or hobby, reputation etc.If a device demonstratively doesn't meet the agreed/published datasheet(s), then one might have recourse/claims against the supplier(s) and manufactures.

author: Someone
author_rank: Super Contributor
timestamp: February 09, 2022, 01:19:32 am
content: Quote from: MK14 on February 09, 2022, 01:09:25 amThis should be all that matters, if you can find a ripple counter with specified min and max propagation delays then its possible an async design could be made without glitches. But when they only list maximums..... here be dragons.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 02:14:40 am
content: Quote from: electronsandstuff on February 09, 2022, 12:02:57 amActually, I've found another source, apparently in agreement with me. See here:https://www.onsemi.com/pdf/datasheet/mc74hc4040a-d.pdfQuoteWhich I would take that to mean, that you should not just simply hang gates onto the counter, as they may cause "decoding spikes", which I was referring to as a race hazard.

author: electronsandstuff
author_rank: Newbie
timestamp: February 09, 2022, 03:01:13 am
content: Quote from: MK14 on February 09, 2022, 02:14:40 amI said nothing whatsoever to contradict what you have just posted in the general sense. What you don't appear to understand is that the simple (N)AND gate decoder for implementing a terminal count (which only partially decodes the ripple counter output by sensing when some required bits are high) is not susceptible to decoding spikes for binary values from the counter less than the binary value partially decoded, which is all we need to care about. The internal propagation delays of the ripple counter actually help to make this reliably so!And BTW, the OP's project with the MC6850 ACIA sounds more like a one-off hobby computing thing, not some safety-critical design to be integrated into the control room of a nuclear power station that we all need to be concerned about.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 03:35:08 am
content: Quote from: electronsandstuff on February 09, 2022, 03:01:13 amI very much agree with my original statements.If you look at this datasheet:https://www.ti.com/lit/gpn/CD74HC4040It actually seems to show that there is a pair of buffers, after the flip-flops. Also the datasheet would appear, to show, that Q1 can arrive later than Q2, assuming that there is enough output capacitance variation.I.e. That Q2 can appear in as little as 4ns (or less) after Q1 (I mean internal state of Q1, but it still has to get through the pair of buffers, which have to overcome any extra capacitance, Q1 might have over Q2, circuit/PCB layout etc, dependent). Yet Q1 can be delayed by an extra 13ns, depending on the output capacitance.tl;drA quick, back of the envelope, timing analysis. Would appear to show that connecting multiple gate pins to the Q pins, while ignoring the clock signal. Can cause a race hazard.

author: electronsandstuff
author_rank: Newbie
timestamp: February 09, 2022, 06:25:49 am
content: Quote from: MK14 on February 09, 2022, 03:35:08 amThe huge amount of difference in Q-pin capacitive loading that would be required to cause a runt pulse of any significance to propagate through the decoding gates is not representative of the circuit under discussion.IMO, you are reading the datasheet pessimistically. The datasheet gives the maximum (worst case) delay for 50pF loading and the typical delay for 15pF loading. So this total spread in delay over the specified range of load capacitance is between a typical performing part and a worst case performing part. Any individual part will exhibit less delay variation.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 02:37:51 pm
content: Quote from: electronsandstuff on February 09, 2022, 06:25:49 amYou're right, I agree!On the other hand, you seem to be admitting, that designing it 'your way', is relying on the parts behaving in ways which are not guaranteed by the datasheet. Which is what I have issue with. I (ideally) want deigns to work with all (datasheet passing) parts, at the full temperature range, voltage variations, reasonable PCB and other circuit variations (such as capacitive loading). Etc.Because it (usually) results in reliable, robust designs/items, which work well for long periods of time. Rather than something which keeps on rebooting or crashing, for unknown reasons, every few hours. Along with all the other possible symptoms, of things, designed, not quite correctly.EDIT: I'm not necessarily saying it won't work and/or you are wrong, as such. More that for a real large scale production task, they can put the extensive design effort, test work and contact with the component manufacturers application engineers (product volume dependent). To squeeze the last ounce of performance the datasheet (and the manufacturer may agree to), out of the components.But for a (I presume) somewhat quick hobby project. Contact with the manufacturer, extensive test work and extensive research/calculations and stuff with the datasheets, probably is not worth the extensive effort. So, quicker rules of thumb, assuming the timing will be anywhere between 0ns and the maximum datasheet values, makes the design task, much quicker. It should also then produce reliable, rather than flaky/inconsistent results.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 06:02:16 pm
content: Why don't we put some facts and figures on this?From the data sheet you linked to (CD74HC4040), the delay at 4.5 V from Qn to Qn+1 is 15 ns max. at 25 C.The Q load capacitance willnotchange that.So worst case, if you're using all the outputsandgating them. the delay from Q1 to Q12 is 165 ns, which will result in a runt pulse that's so fat that you'll see it in the next county. And if you operate over a wider temperature range it gets worse.Bad design indeed. I'd not sleep well at night putting something like that on the market.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 07:32:02 pm
content: I don't think using a ripple counter, was as bad as I originally made out, especially if the clock signal goes to another AND input pin, to make it wait until the ripple counter finishes counting. But a properly designed synchronous circuit, would still probably be a lot better, especially if it ever goes into production.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 08:52:38 pm
content: Quote from: MK14 on February 09, 2022, 07:32:02 pmHow would gating the clock to the sack of potatoes being spilled on the floor (=Qn outputs) help? An output flip-flop might do the job. And then the circuit is again more complicated than using synchronous counters.BTW: 165 ns ~ 3 MHz half period. I'm certain that the subsequent logic will react to that.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 09:08:48 pm
content: Quote from: Benta on February 09, 2022, 08:52:38 pmBecause dividing by 39, seems to involve the first 6 stages. Taking the same datasheet you are referring to, would seem to be, (Q2 .. Q6) 5 lots of 15ns (max, at room temp), plus the initial clock pulse to flip flop output (Q1) which is 28ns (at room temp, max).divide by 39 = 6 flip-flops = Q1 .. Q6 = 28 + 5 x 15 = 103ns (at room temp).Which is below the 165ns, you mentioned.EDIT: But it also needs time for the Reset pulse to be safely asserted, de-asserted by the AND gate, and time for the counter to cope with coming out of reset. A quick look at those times, seems to be rather/too tight, for proper reliable operation.So you're right, it probably wouldn't work or not very well (as regards the datasheets, at least).103ns + Reset-Pulse-width + And-Gate-De-assertion_time + Reset-Removal-Time103ns + 16 + Total-Gate-Delays(propagation+transition) + 10 = 129 + 26 + 15 = 170ns = Too long!, especially as that was at room temperature.https://assets.nexperia.com/documents/data-sheet/74HC_HCT30.pdfAlso, original posts gave part number for NAND gate, but it would need to be an AND gate, or have an inverter added to it.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 09:39:13 pm
content: You refer to this specific design.I'm referring to the folly of gating the outputs of ripple countersgenerally.And your timing analysis is off. The first delay to Q1 is unimportant (Unless you want to gate the clock to the output gates, which makes no sense anyway). The output-to-output delay is what matters.So in this case it's "only" 75 ns, a 6.7 MHz half-pulse. Now, it's in no way certain that the worst case runt pulse will ever happen. Mostly it's some edge "noise" on the gate output edges or output serration, but this has to be analyzed on a case-by-case basis and will depend on the specific gating. The magnitude of the "noise" is also dependent on the environment (temperature, voltage, batch).It's still just bad design.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 09:50:32 pm
content: Quote from: Benta on February 09, 2022, 09:39:13 pmI didn't realize you were referring to the general case, in your latest posts. Sorry for my misunderstanding.Until someone draws an actual completed schematic, with actual part numbers, and specific frequencies. I'm just going round in circles, trying to calculate the timings for it.So I wouldn't be surprised at all, if the timing calculation I've done above, is wrong, perhaps in a number of places.tl;drWithout a bolted down schematic and specific parts, there is lots of room for ambiguity.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 10:51:06 pm
content: Well, if you want schematics, here are two put quickly together. Both 100% synchronous designs and thus trouble-free.File names are SSSD39_x for "simple synchronous schematics for dividing by 39".But they'll divide by anything between 2 and 254 if you like. Just change the inputs.Cheers.EDIT: the 2nd schematic had an error. Corrected now. Sorry.

author: BrianHG
author_rank: Super Contributor
timestamp: February 09, 2022, 11:24:14 pm
content: Ok, I think we done enough with the approximate 153khz.Ok, now lets see a 153.00000000000000KHz, dead perfect output solutions.No stepped missing cycle jitter.

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 11:35:02 pm
content: Quote from: BrianHG on February 09, 2022, 11:24:14 pmActually 153.6 kHz is the desired output.

author: BrianHG
author_rank: Super Contributor
timestamp: February 09, 2022, 11:37:17 pm
content: Quote from: Benta on February 09, 2022, 11:35:02 pmOk, an exact 153.600000000000000000000KHz.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 11:43:08 pm
content: Quote from: Benta on February 09, 2022, 10:51:06 pmThanks, those schematics look very educational for people. I was happy with the first schematic, but thought you may have slightly slipped up on the ENT pin on U1, on the second one (as it prevents the final output (Tc), if you are not careful). But I've now seen you have updated (edited) your post, while I was looking at it. So, I'll assume it's fixed now.Synchronous is the way to go. Especially if you want authentic vintage like, computer projects.The small pin count MCUs, are tempting as well (if vintage equipment projects, don't bar it, which it would for some people). Especially if any spare pin(s)/functionality left over, can do anything useful. But then that would complicate the simplistic timing loop technique.

author: MK14
author_rank: Super Contributor
timestamp: February 09, 2022, 11:46:39 pm
content: Quote from: BrianHG on February 09, 2022, 11:37:17 pmI think I deserve the "Over-engineering an engineering thread, way past its successful/useful solutions point" award.But, at least I had an excuse, with that new poster...

author: Benta
author_rank: Super Contributor
timestamp: February 09, 2022, 11:54:04 pm
content: Quote from: MK14 on February 09, 2022, 11:43:08 pmYes, it's fixed and the schematic is now good. There's an unfortunate issue with KiCAD 5.1, in that it sometimes randomly (it seems) puts junctions on connections when moving a block.I proof-read as best as possible to correct this, but slipped this time. Sorry.Thanks for your feedback.

author: Benta
author_rank: Super Contributor
timestamp: February 10, 2022, 12:04:16 am
content: Quote from: BrianHG on February 09, 2022, 11:37:17 pmThen, allow me to be autistic as well:It's "kHz",not"KHz". Apart from that, do you have a constructive input?Or just had a bad day?

author: ve7xen
author_rank: Super Contributor
timestamp: February 10, 2022, 01:15:06 am
content: Quote from: BrianHG on February 09, 2022, 11:24:14 pmI guess the least components/cheapest approach is again to use a typical microcontroller with PLL. Clock the PLL from the input, multiply by 8 to get a 48MHz clock into the timer, then divide by 312500.Same approach would be pretty straightforward with a 4046 and divider chain.

author: BrianHG
author_rank: Super Contributor
timestamp: February 10, 2022, 02:08:17 am
content: Quote from: ve7xen on February 10, 2022, 01:15:06 amSee, this was all that I was almost looking for...You would need to divide 48000000/312=153.8kHz. Still not there.I guess I should ask if it is feasibly even possible.The cleanest multiple is 153600*25=3840000You would need to multiply 6000000x64=384000000, then divide by 2500.Or, divide 6mhz by 25 to 240khz, then multiply by 16 to get 3.84mhz, then divide by 25, an exact 153.600000000000000000000KHz.A little tricky, but with some logic gates and a 74HC4046 pll, going the 100% discrete logic route, this can be done, though I would change the /25 to /50 for the exact 50/50 duty cycle output from the dividers and the multiply would need to change to 64.

author: rfclown
author_rank: Frequent Contributor
timestamp: February 10, 2022, 07:08:07 am
content: Like Mechatrommer my goto uCs are the AVR family. If I wanted SMT, I'd guess I'd use a tiny10, but I keep a pile of tiny85 DIP8s around for breadboarding and one offs. Really doesn't matter what uC you use. The one you already know and can just bang something out is probably the best. The point is that if you learn how to use them, they greatly simplify many tasks.So I'm imagining if I had a MC6850 and I wanted a clock for to do 9600 baud and there was a FT232RL there also. Since I'm not immediately thinking of something I can do with a single logic chip that I might have in my stash, I'd pull out a tiny85 (that I'd switch to a tiny10 if I was going to build more than one and wanted SMT). The FT232RL clock is just an RC, so I wouldn't think using that would be any better than the RC clock in the uC. Without getting fancy, since I can't divide the 8MHz RC of the AVR exactly with an integer to get a multiple of 9600, I'd feed the clock to the MC6850 in 1x mode (9600) so that my 125nsec granularity would be less of an impact. I usually write code in C, but for something this trivial I'd use assembler. Write a simple loop and use an online calculator for delays:http://darcy.rsgc.on.ca/ACES/TEI4M/AVRdelay.htmlAssemble with gcc (free). Upload with USBisp (<$20 Digikey, about $3 Chinese eBay) and avrdude (free). For grins I did just that with a tiny85 in a solderless breadboard and looked at the output with my scope. Did it for 9600 x1 and x16. No arguing that both are off due to the 125nsec granularity of keeping it simple, but I'm just saying what I would do so solve the problem. I could dither or whatever, but it isn't needed.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2022, 11:38:15 am
content: Quote from: rfclown on February 10, 2022, 07:08:07 amthe key to further fine tune the output frequency after the code is polished is OSCCAL register, i remember pic12f line also have that frequency tuning register. both soft (asm) and hard (pwm) method can use this way... with hard pwm feature, there is possibility we set the mcu clock slower say 1MHz or put to sleep while pwm output is running to save more power after setting up appropriate prescalers, top pwm counting and compare values etc.

author: BrianHG
author_rank: Super Contributor
timestamp: February 10, 2022, 11:48:36 am
content: Place a 15.36mhz crystal on your MCU & software lock onto the 6mhz reference for time framing allowing you to generate the perfect 153.6000000000khz clock.Note that TI has a PLL clock generator IC with I2C setup and built in eeprom to store your setup for repeat powerup with enough range and dividers to make the exact 153.6000000khz clock. Part number : CDCE913 .https://www.ti.com/lit/gpn/cdce913

author: rfclown
author_rank: Frequent Contributor
timestamp: February 10, 2022, 03:22:38 pm
content: Quote from: Mechatrommer on February 10, 2022, 11:38:15 amIn the 90s I used PICs because there was a Microchip rep that would just shower me with parts/programmers/etc. I was working for Moto and told him that nothing was every going to get into product since we always used our own controllers (like HC11) and I was only going to use the stuff for hobby projects (and I'm an RF guy who didn't do uC stuff for products). He kept giving me stuff. I remember tweaking the RC cal register on the PIC. Each line of code that did a bank switch usually had the comment "; I hate bank switching". When Arduino exploded it just seemed to make AVR so easy and I abandoned PIC for which I'd only used assembler. I usually do really simple stuff with controllers, so I have a pile of tiny85 dips and Arduino pro minis depending on how many io pins I need. I actually put something in a product at my current job. I was reviewing someone's schematic which had a attiny44A in it and I found problems. I offered to help change the circuit, and while doing so there was feature creep which caused more io needs, so I changed to a atmega328p so I could use a pro mini to breadboard the circuit and test.For the specific problem of the OP I just answered with what I'd do if it was a one-off for myself. If it was for a product I would think about it longer. I certainly wouldn't want to be tweeking a cal register on every unit.

author: basinstreetdesign
author_rank: Frequent Contributor
timestamp: February 10, 2022, 09:19:36 pm
content: Just my 2 cents about an issue not mentioned here...Once when programming a uC to produce EIA-232 data stream at a given baud rate I did it and it worked within correct rate +/- 0.1%Unfortunately the baud rate was 0.1% high. This meant that the receiver, which was working at the correct baud rate +/-0.0001% would sample the data 0.1% later after each bit. So after a few contiguous bytes the sampler missed the data and was corrupted.The solution was to adjust my data rate to be 0.1% LOW not HIGH. Then the receiver would always have to wait that extra smidgen to start sampling the next byte and always got every byte.So if you are going to have a baud rate that's out by a smidgen, let it be slow by that smidgen not high.Just my 2 centsAnd BTW: synchronous logic is always safer than non-synchronous logic but that's just me.

author: Ian.M
author_rank: Super Contributor
timestamp: February 10, 2022, 10:07:29 pm
content: That receiver was *broken*. It should have accepted a stop bit that was up to half a bit time shorter than it was set for. i.e. started looking for the next start bit from the middle of the previous character's stop bit 'timeslot'.

author: Benta
author_rank: Super Contributor
timestamp: February 10, 2022, 10:13:11 pm
content: Well, if you want it 100% exact:6,000,000 / 625 = 9,600.9,600 x 16 = 153,600.Means 625 divider followed by x16 PLL frequency synthesizer.@basinstreetdesign: must have been a lousy design without flow control (HW or X-on/X-off). RS-232 is never synchronous, nor does it need precise timing. The timing within a symbol is important (8...11 bits), but that's all. And even +/- 1% wouldn't make a difference at all there.

author: Ian.M
author_rank: Super Contributor
timestamp: February 10, 2022, 10:44:35 pm
content: Another approach that *would* work with crappy receivers like the above is to allow the x16 baud clock period and mark/space ratio to jitter slightly, but maintain exactly 9600 baud. Divide by 39, toggling the output on overflow and a count of 20, but every 16th output cycle divide by 40, not 39 That gives a total division ratio for one bit period of 625, which multiplied by 9600 is exactly 6000000, so the average x16 clock frequency (over a whole bit) is exactly the requested 153.6 KHz. Its trivial to do in any single cycle per instruction low pin count MCU Unfortunately, if you are locked into PICs, as 8 bit PICs take four cycles per instruction, you'll have to use an Enhanced Midrange part (as baseline and 'classic' Midrange are only specced to operate up to 20MHz) and either crank up the FTDI clock out to 24MHz , or select a PIC with a x4 PLL.I'll leave designing a asynch muntzed LSI logic implementation to those that *enjoy* calcuating their race condition margins.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 15, 2022, 10:13:58 am
content: Haven't been back to this thread for a while... it's come on a way since I started it!Thanks for the responses. My priorities have shifted to another project for the time being but the synchronous counter design is nice.

author: electronsandstuff
author_rank: Newbie
timestamp: March 29, 2023, 10:38:51 am
content: Quote from: MK14 on February 09, 2022, 02:37:51 pmIf you say so. BTW, it is not "my way". It is "a way".I've attached a waveform diagram of a 4-stage ripple counter with exaggerated delay - 30nS per stage for 90nS total delay Q0 to Q3. A terminal count is decoded for 13 by NANDing Q0, Q2 and Q3. Anyone looking at this diagram should be able to instantly visualize how sufficient ripple delay can actually mitigate if not completely eliminate the prospect of runt/unwanted pulse generation at the output of the NAND gate below the terminal count value.If you need to latch an action at a count of 13, in this example, it is perfectly reasonable and safe to trigger off the output of the NAND gate asynchronously. This is only averybasic example. It depends entirely on the nature of the decoding required, but a logic designer with a brain can often make the accumulated ripple delays of non-synchronous ripple counters work to his or her advantage when arranging decoding logic.I spent the first 10 years of my career analyzing the commercial work of such people, back when the stuff I worked on still sported logic boards harboring dozens if not one or two hundred 74XX chips. I could elaborate much further and proffer examples, but I'm not sure that it is worth the aggravation. Maybe if I'm bored again in another year or so.

author: MK14
author_rank: Super Contributor
timestamp: March 29, 2023, 04:47:01 pm
content: Quote from: electronsandstuff link=topic=311165.msg4784684#msg4784684To check my understanding. You are basically saying that your clients (or whatever the relationship was), thoroughly analysed the component(s), themselves. So much so, that they were confident, to take responsibility of testing and confirming that the design(s) were going to be robust and reliable, in the future.I've heard about it (going beyond the datasheet specifications), by testing and in effect handling your own version, of what you think the specification is.Part of the main difference, is that if things go wrong. You can't start blaming the original manufacturer or their datasheet(s).