Controlling and Resetting 16 bit Counter

Howdy!

I have two CD4040BC modulo-12 counters cascaded to give me a moulo 16 counter to address an AM29F010 Flash. I'm wondering about the best way to reset the counter once full count is reached. I'm thinking of doing it with 2 8 input Nand Gates fed into an OR gate but I'm not sure if this is the most efficient way.

Also, I'm trying to find the best way to start and stop the counter. Right now the best I can think to do is the start and stop the clock signal.

Any tips would be great!!!
Thanks,

Joe

Joster said:

Howdy!

I have two CD4040BC modulo-12 counters cascaded to give me a moulo 16 counter to address an AM29F010 Flash. I'm wondering about the best way to reset the counter once full count is reached. I'm thinking of doing it with 2 8 input Nand Gates fed into an OR gate but I'm not sure if this is the most efficient way.

Also, I'm trying to find the best way to start and stop the counter. Right now the best I can think to do is the start and stop the clock signal.

Any tips would be great!!!
Thanks,

Joe

Click to expand...

We need more info about your circuit and application. Otherwise you will get a long list of non-applicable suggestions or no suggestions.

Show the rest of your circuit, a schematic is best - easier to append something to it than to start a new sub-assembly.

Also, let us know the application and general functionality.

There are thousands of ways to skin this problem. Hopefully we can find an easy one.

Cheers.

My suggestion without knowing the details would be to scrap your counter and all the parts you will use to make it work and replace it with your favorite inexpensive micro controller, like maybe a PIC. This depends on what you like to do, I personally like to solve most problems with a similar general approach, which is something programmable.

When full count (2^12 - 1) is reached the 4040 counter will automatically roll over to 0 on the next clock. Or did you have some other sort of resetting in mind?

Just use the RESET input. Or am I missing something?

Joster said:

Howdy!

I have two CD4040BC modulo-12 counters cascaded to give me a moulo 16 counter to address an AM29F010 Flash. I'm wondering about the best way to reset the counter once full count is reached. I'm thinking of doing it with 2 8 input Nand Gates fed into an OR gate but I'm not sure if this is the most efficient way.

Also, I'm trying to find the best way to start and stop the counter. Right now the best I can think to do is the start and stop the clock signal.

Any tips would be great!!!
Thanks,

Joe

Click to expand...

Depends what you are trying to do.. if this is part of the project you had in your other thread on how to create a 'stand alone' kick drum voice, then it is probably best to let the counter run until the next significant bit after your flash memory address limit goes high, and use that to inhibit the clock.

If you have the clock and the counter resets connected together, then just trigger your 'new' sequence by taking the resets high momentarily.
That way, you have a simple trigger that will always reset the replay from the the beginning , with an 'instant' re-trigger as often as you need (whether the previous count is complete or not).

In the past, I have used a 4017 to sequence a device of this type. That way you can use a decent D/A, and latch the data bits separately from the memory address increments, time wise. Using that approach, with a high sampling rate and noise shaped dither, and you can get very good quality from 8 bit audio. It's also easy to use the counter to inhibit the 4017 (take pin 13 high with the first unused address line). That stops the device until the new 'reset hi' trigger pulse starts the whole sequence again...

Thanks for all the help!!!

ROG:

Yes I'm getting deeper into this project...I made a quick video to clarify my understanding somewhat

http://youtu.be/mnGx-KQSWYI

Joster said:

Thanks for all the help!!!

ROG:

Yes I'm getting deeper into this project...I made a quick video to clarify my understanding somewhat

http://youtu.be/mnGx-KQSWYI

Click to expand...

OK, I've seen the video... time to take one step back....

I've attached a sketch of the logic sequence I was trying to explain....only the bare essentials ... (a fuller schematic of my test rig is on my second attachment).

As you can see, it uses a 4017 to act as a sequence controller. This serves 2 purposes. It lets you separate the counter advance from the data latch on the DAC, which helps to keep the noise out, and it also allows for a convenient clock inhibit.

You ask in your video why not simply use a simple R/2R resistor ladder for the DAC?.... The answer is noise and accuracy

Using an DAC like the TLC7524 .. (which includes an internal and accurate R/2R ladder, and is not too expensive)....allows you to maximise the accuracy of the 8 bit decoding, and also uses data latches to let you store the data independently of the flash memory counter advance. The result is quite a lot quieter... which can be important in the quest to improve the quality of an 8 bit signal!

In my full schematic, the pin configuration from the DAC I have used may seem a bit weird. I have found it's a quieter way of connecting it for audio use, than the configuration suggested on the data sheet is (Long story.. I can elaborate?...)

The second purpose for the 4017 sequencer is to allow the counter clock to be stopped.

The VCO oscillator from the 4046 PLL runs all the time, and in my test configuration can be made variable.... (typically between 400KHz and 1MHz).....that clock is connected to the clock input pin (pin 14) of the 4017.

Taking the memory counter clock from pin 6 (Q7) divides that frequency by 10 to give to you a clock speed between 40KHz and 100KHz... the kind of range you should be looking at for high quality 8 bit sampling.

The counter itself runs A0 to A16 to address the Flash memory. When A17 goes high, it inhibits the 4017 clock via pin 13, and stops the counter advancing any more. (On my schematic, I have allowed for 1Mb, 2Mb and 4Mb flash chips....so I take my inhibit from A19)

A momentary 'hi' trigger applied simultaneously to the MR (master reset) pins of both 4040 counters (pin11) and the 4017 sequencer (pin15) will start the process from the first count.
Instantly. Even if the previous 'count' is still running, a new trigger starts the whole thing again from the start... which is exactly what you need.
No latency, no lag, no MIDI.. just instant restart.

(The actual trigger circuit on the full schematic includes a monostable pulse generator,to act as both switch de-bounce and a fixed reset pulse time ..regardless of how long you hold the trigger).

I'll do a separate post on the noise shaping and the dither part of the project...... it's this that makes the use of 8 bit acceptable. The original 8 bit drum machines.... like the LinnDrum in the 1980s...made some very clever 'tweaks' to their limited sampling rates and memory size, to try and make the noisy samples acceptable. With much larger memory 'chips' , using higher clock rates and noise shaped dither can make things much better these days.
There is a lot of hype about 'top end' audio formats.... have a read through this: http://xiph.org/~xiphmont/demo/neil-young.html it's most enlightening....

You might be surprised just how good 8 bit samples can sound... I'll try and include something in my next post....

Adding to the above......You ask about noise shaping and dither in the video.....
These two processes are clever tricks to improve the quality of digital audio, without increasing bit depth or sampling rates. The maths are horrible for a simple guy like me, but it's all out there if you Google 'audio dither'...

Basically, lower level signals are more difficult to encode accurately where digitising audio signals are involved. This is especially true at lower bit depths..like 8 bit.
As the process becomes less accurate, you get noise, harmonic distortion and 'aliasing' which can really mess your signal up.
To try and improve the situation, the deliberate introduction of a small amount of white noise into the signal will cause these inaccuracies to become much more random, and thus less objectionable. The 'shaping' of this introduced noise can improve the situation more.
As I say, there's lots of information out there which explains it much better than I can...

To hear what I mean, there are 4 short audio samples from the links below (only about 1Mb each). These are wav files, so as not to allow any other processing (like converting to mp3) from changing the anomolies.

All files were derived from the first file, recorded at a deliberately low level of -30dB, to illustrate the problem better.

This first file is a 16 bit swept sine wave, sampled at 48KHz

16 bit 48KHz

Simply re-sampling that same file as an 8 bit file shows the distortion and aliasing problems pretty well:

8 bit 48KHz

Taking that same 8 bit file, and adding a small amount of 'dither' noise shows how the distortion and aliasing are much improved, at the expense of adding some noise:

8 bit dither 48KHz

By doubling the sampling rate to 96KHz, and adding 'shaped' dither noise, the dither process moves most of the noise outside of the audible spectrum, and the sound becomes more like the original. Not perfect, but quite close!... and only 8 bit hardware is required!:

8 bit dither 96KHz

And remember these files are deliberately chosen to be difficult, so you might expect even better results from a higher level signal....

I've attached a spectrum analysis of a sample of each waveform around 1KHz below. You'll see how most of the introduced noise is shifted above 20KHz in the last sample.
(The title letters A -B -C-D obviously mimic the audio file order)

So using 8 bit audio, suitably modified, can produce quite good results... especially for a project like this one

Wow! this is awesome! thanks so much!

He is another video....

http://youtu.be/w-Ex3ArTtQE

OK Joe, I've watched episode 2 of the TV series......

A little background...... I have been involved with using solid state media for audio recording for a number of years, mostly in the area of recording spoken information messages, rather than anything musical.

Mostly using EPROMS for storage, and analogue circuitry to optimise the 8 bit formats - I've also used mostly custom built hardware recorders and EPROM programmers, rather than commercial EPROM programmers.

The new 'test' rig schematic I posted was drawn to allow me to build a 'one off' new replay system that allow me to try FLASH memory, higher clock rates and digital manipulation of the data (noise shaping), and also to try out a cheap Flash programmer I've bought.
I'm actually in the process of building that schematic at the moment.

I need to say at this stage that I'm very much a simple hardware guy.... I have very little knowledge of software controlled systems.
There are some very smart guys in that area...including some on this board... so I leave that side of things to them (you can't teach an old dog new tricks!)

To your points on the video......Flash 'pages'.?.... not really of any interest in this instance.... the trigger will allow the counter to access all locations in the Flash sequentially.. the system logic has no knowledge of what any of the data is, nor does it care where it is in the sequence process.
And that's fine for this purpose..... simple is good (IMHO!).
What is important is how the sample is prepared, and I'll detail how I go about that later.

What is also important is what you do with the unused memory locations. Obviously you put the sample at the beginning, to trigger it instantly, but the unused locations should not just be left empty. If you just leave them unprogrammed with FF then you'll end up with horrendous 'clicks' all over the place. To keep the system silent when not actually playing sample data, fill ALL unused memory locations with 80.
(As I say, I'll detail more of that later).

So... you apply the trigger, the Flash locations are addressed sequentially, and the sample is 'replayed'. After that, the counter continues, but only silence is outputted.
If you re-trigger before A17 goes high, then the whole thing just starts again from to beginning, immediately, regardless of where it actually is in the count. ...
If A17 does go high, it STAYS HIGH, and inhibits the clock until a new trigger is applied.
So the device doesn't care whether it's running or not. If it's not actually replaying the sample data, the output is always silent....regardless of the counter status.

The DAC latch is quite simple. The 4017 is a decade counter that outputs one of ten outputs sequentially. We only need two of them... Q3 and Q7 seem a suitable choice (pins 7 and 6 respectively)...probably best not to choose adjacent output numbers... like, say, Q3 and Q4... but the actual choice is not too critical.

If the clock input on pin 14 is set at 500KHz, then pin 7 (Q3) will supply a series of 'go hi' output pulses at a rate of 50 KHz. This output is inverted (it uses one of the 4093 NAND gates wired as an inverter on my full schematic) and that 'go lo' output is fed to the DAC pin 13 'write enable', which is active low.
This simply latches the data present on the Flash data bus at that time cleanly, in a known stable state, to prevent any 'glitch' noise.

A few microseconds later, pin 6 (Q7) will go high, and advance the counter. This will present new data to the Flash data bus, but will not update the DAC until Q3 goes high again. This process just keeps the data updates clean, by not allowing any 'dirty' data glitches during the address change to appear at the op amp input...

You'll find details of the op-amp I'm using at present (LM358) on my full schematic.
Not a particularly low noise device, but as there is no gain involved that's not really important, and it's a cheap device that works with a single 5V supply!

With regard to the chip selection, I would use '74HC4000' series rather than the standard 4000 series, if you are buying devices specially.
The 4000 series should work OK, but if you have the choice?......
Do NOT use 74HCT series.
The choice of using a 4046 (or preferably a 74HC4046, for better results ) as the master oscillator is arbitrary. I find the VCO output from that chip useful as an easily controllable oscillator.
There are hundreds of alternative oscillator circuits out there (4000 series, 555, etc, etc...) You may have a favourite of your own?....
You may also need to double check the oscillator resistor and capacitor values, to get exactly the right range. The values presently on my schematic are nominal at the moment (the value of the capacitor between pins 6 and 7 may be better as 470pF, for example?)....

Preparing the samples:

As I mentioned, in the past I have always designed and used hardware based recording and programming systems, so this is a new venture for me.

It is best to do all the preparation of your chosen audio sample in an audio editor, at 16 bit resolution (I use Cool Edit myself).
Optimise the level to approx -2dB, to allow for the addition of dither noise without any clipping.
Locate the sample audio ALMOST at the beginning of the file. Allow for 3 or 4 samples of silence at the beginning... (and add that as 'silence', not just as the lowest volume setting).
Make sure your actual sample starts at a zero crossing point, and ends on one as well. After the end of the sample, add 2 or 3 seconds of 'silence' again (or more if you're using a 4Mb flash)...... in other words, more silence than the whole 'length' of the remaining memory replay time.

THEN add noise shaped dither and re-sample the edited file to 8 bit, as the final part of the procedure.
Most audio editors will set up the dither and noise shaping automatically -- (see attached .jpg for an example in Cool Edit)

Save the file as an 8 bit wave file.

To get that file into a format that a flash programmer will understand, just change the extension from '.wav' to '.bin' and open it in a hex editor (I use the freebie'frhed' ).

Then simply lop off the first 11 bytes of the file data (the wav header) and make sure the first few bytes of the remaing file have the value of 80 ... Again, the exact number of bytes is not critical... we are talking microseconds here!

That should give you a file that most Flash programmers will understand........