counter required to count to near 1 million

[Simon]

not really, i'll need to have a bit of pulse circuitry connected to the reset line so that when the reset is trigered it make the pulse fire a pulse, even if it is something like charging a capacitor with resistor in parallel with a comparator or opamp

[marmad]

At the moment I'm looking at a 4541 followed by any other counter that will finish it off right. As I'll have logic gates knocking around anyway I can use one or two to make the clock gen

Well, if you don't need the oscillator section of the 4541 - and can provide the 32768Hz clock signal from elsewhere - I would suggest using the 4541 as the last stage of the counter - as shown in the attached drawing. If you do it this way, you can set whether the output pulse every 30 seconds is positive or negative-going by just tying pin 9 on the 4541 high or low.

[marmad]

Hmm... just realized that the HEF4526B may not be the cheapest divide-by-n counter  - if so, you can substitute any divide-by-n 4-bit counter (dual or otherwise) - I haven't used any for awhile so I don't know which is currently the cheapest. You just want to divide by 15 before the 4541.

[marmad]

@Simon - BTW, I just breadboarded a 4541 clocked by a 32.768kHz crystal hooked to the built-in oscillator pins 1 and 3 (similar to the circuit shown in 4060 datasheets). As I thought, it's no problem at all getting it to work - I got a solid .5Hz output after tinkering with the load capacitor.

[Simon]

You mean it works ?

[marmad]

You mean it works ?

Yes, it worked fine - I got a perfect 500mHz square wave out at pin 8 of the 4541. Because you can basically hook up a crystal to any CMOS inverter or inverting gate (within the frequency limits of the device, of course). You're just biasing the inverter into it's linear region and using it like an amplifier with a feedback network that includes the crystal.

Edit: If you'd like, I'll draw the modified schematic including the crystal oscillator components - for the 33mHz output frequency.

[Rufus]

  Then I guess my suggestion of PIC10F200 is way the hell out! With 384 bytes ROM and 16 bytes RAM, I don't think you'd have much luck programming it in anything but assembly.

It's entirely feasible to do C on the 10F200 (using the non-free version of the microchip compiler).
If written carefully, efficiency isn't that far off assembler.
For something a simple as this, probably even the free version and sloppy coding would still do the job

Complete program for a PIC12F1822 which uses 4.1% of available program memory with the crappy free XC8 compiler (2.9% with the pro version). It pulses pin 5 high for 2 seconds in 30.

Code: [Select]

// PIC 12F1822 Timer project

#include <pic.h>

// Some Types
typedef unsigned long Dword;
typedef unsigned int Word;
typedef unsigned char Byte;
typedef signed char Char;       
typedef unsigned char Bool;
typedef bit Bit;

// PIC12F/LF1822 Configuration pragmas
 
// Oscillator Selection
// #pragma config FOSC=ECH      // External Clock, High Power Mode (4-32 MHz): device clock supplied to CLKIN pin
// #pragma config FOSC=ECM      // External Clock, Medium Power Mode (0.5-4 MHz): device clock supplied to CLKIN pin
// #pragma config FOSC=ECL      // External Clock, Low Power Mode (0-0.5 MHz): device clock supplied to CLKIN pin   
   #pragma config FOSC=INTOSC   // Internal Oscillator: I/O function on CLKIN pin
// #pragma config FOSC=EXTRC    // External Oscillator: External RC circuit connected to CLKIN pin
// #pragma config FOSC=HS       // High-Speed crystal/resonator connected between OSC1 and OSC2 pins
// #pragma config FOSC=XT       // Crystal/resonator connected between OSC1 and OSC2 pins
// #pragma config FOSC=LP       // Low-power crystal connected between OSC1 and OSC2 pins

// Watchdog Timer Enable
   #pragma config WDTE=ON       // Enabled
// #pragma config WDTE=NSLEEP   // Enabled while running and disabled in Sleep
// #pragma config WDTE=SWDTEN   // Controlled by the SWDTEN bit in the WDTCON register
// #pragma config WDTE=OFF      // Disabled

// Power-up Timer Enable
// #pragma config PWRTE=OFF     // Disabled       
   #pragma config PWRTE=ON      // Enabled

// MCLR Pin Function Select
   #pragma config MCLRE=ON      // MCLR/VPP pin function is MCLR
// #pragma config MCLRE=OFF     // MCLR/VPP pin function is digital input

// Flash Program Memory Code Protection
   #pragma config CP=OFF        // Disabled
// #pragma config CP=ON         // Enabled

// Data Memory Code Protection
   #pragma config CPD=OFF       // Disabled
// #pragma config CPD=ON        // Enabled

// Brown-out Reset Enable
   #pragma config BOREN=ON         // Enabled
// #pragma config BOREN=NSLEEP     // Enabled while running and disabled in Sleep
// #pragma config BOREN=SBODEN     // Controlled by the SBOREN bit in the BORCON register
// #pragma config BOREN=OFF        // Disabled

// Clock Out Enable
   #pragma config CLKOUTEN=OFF     // CLKOUT function is disabled. I/O or oscillator function on the CLKOUT pin
// #pragma config CLKOUTEN=ON      // CLKOUT function is enabled on the CLKOUT pin

// Internal/External Clock Switchover
// #pragma config IESO=ON          // Enabled
   #pragma config IESO=OFF         // Disabled

// Fail-Safe Clock Monitor
// #pragma config FCMEN=ON         // Enabled
   #pragma config FCMEN=OFF        // Disabled

// Flash Memory Self-Write Protection
   #pragma config WRT=OFF          // Write protection off                                                         
// #pragma config WRT=BOOT         // 000h to 1FFh write protected, 200h to 7FFh may be modified by EECON control
// #pragma config WRT=HALF         // 000h to 3FFh write protected, 400h to 7FFh may be modified by EECON control
// #pragma config WRT=ALL          // 000h to 7FFh write protected, no addresses may be modified by EECON control 

// X4 Clock PLL
// #pragma config PLLEN=ON         // Enabled 
  #pragma config PLLEN=OFF         // Disabled

// Stack Overflow/Underflow Reset
   #pragma config STVREN=ON        // Enabled 
// #pragma config STVREN=OFF       // Disabled

// Brown-out Reset Voltage Selection
// #pragma config BORV=LO          // Low trip point selected
   #pragma config BORV=HI          // High trip point selected

// Low-Voltage Programming
   #pragma config LVP=ON           // Enabled
// #pragma config LVP=OFF          // Disabled, high voltage on MCLR/VPP must be used for programming

// ID Location value assignment
#pragma config IDLOC0=0
#pragma config IDLOC1=0
#pragma config IDLOC2=0
#pragma config IDLOC3=0


// Counts down and kicks watchdog if not zero in timer interrupt
volatile Byte wd_interlock;


//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
// initialise - set up all hardware

void
initialise(void) {

    // OSCON Defaults to 500kHz for INTOSC

    LATA = 0x00;
    ANSELA = 0x00;          // All I/O digital
    TRISA = 0x00;           // All outputs

    WDTCONbits.WDTPS = 12;  // approx 4 second watchdog time out

    // Setup Timer 1 to use 32kHz external crystal and generate
    // a timer interrupt at 0.5Hz

    // Disable Gate function
    T1GCON = 0x00;

    // Select T1OSC crystal, prescale of 1, enable T1OSC, no sync with FOSC
    // Timer 1 disabled
    T1CON = 0x8C;

    // Wait for T1OSC stable
    while(!OSCSTATbits.T1OSCR) {
    };

    // Clear Timer 1 interrupt flag and enable Timer 1 interrupts
    TMR1IF = 0;
    TMR1IE = 1;

    // Enable general and peripheral ints
    INTCON = 0xC0;

    // Run timer
    T1CONbits.TMR1ON = 1;   
}



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
// Interrupt Service         
void interrupt
isr(void) {

    static Byte sec2 = 0;

    // Timer 1 interrupt at 0.5 Hz.
    if(TMR1IF) {
        TMR1IF = 0;

        // Handle watchdog and interlock
        if(wd_interlock) {
            wd_interlock--;
            CLRWDT();
        }

        // Count 15 interrupts in 30 seconds, set RA2 high for
        // 2 seconds
        sec2++;
        if(sec2 > 14) {
            sec2 = 0;
            LATAbits.LATA2 = 1;
        } else {
            LATAbits.LATA2 = 0;
        }
    }
}



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//
void
main(void) {     

    initialise();

    for(;;) {           // Loop forever
       
        wd_interlock = 10;
        SLEEP();
    }
}

The 12F1822 might be a bit overkill but I had a spare tube of them and they are still only 85p 1 off of in DIP8 from Farnell. It has a specific 32kHz low power oscillator functional in sleep mode, haven't looked if anything cheaper has that. Timing was about 150 ppm fast with just a junk box watch crystal plugged into a bread board. Pulled about 28uA running on 3.3v.

[marmad]

Do people even read previous messages posted in the threads here?

Without going back and re-reading, I'd estimate that Simon has stated between 5 - 10 times that he doesn't want to use an MCU.

[David_AVD]

Do people even read previous messages posted in the threads here?

Without going back and re-reading, I'd estimate that Simon has stated between 5 - 10 times that he doesn't want to use an MCU.

A MCU solution could help plenty of other people though.  Sometimes threads spawn some great ideas.

If Simon doesn't feel up to using a MCU, then he can still phaff around with the other methods and get there eventually.

[marmad]

A MCU solution could help plenty of other people though.  Sometimes threads spawn some great ideas.

That's true - although it would feel more like a real discussion - and that people were actually perusing the thread - if they mentioned that fact. When people don't bother to do that, you get multiple posts all saying the same thing - such as the 5 or 6 people who each suggested the 4060 chip - as if they were the first to do so.  Just saying... 

[robrenz]

Do people even read previous messages posted in the threads here?

Without going back and re-reading, I'd estimate that Simon has stated between 5 - 10 times that he doesn't want to use an MCU.

IMO only because he does not have the time for the learning curve at the moment. If presented with a canned solution that he could plug and play he may change his mind. I dont think the post is out of line

[TerminalJack505]

Here are a couple of ideas if your design isn't tied to a 32.768kHz crystal and really just require a pulse every 30 seconds...

Idea #1: Use a 74HC5555 and a 3.932160 MHz crystal.  Have the 74HC5555 divide by 2¹⁷.  This will give a pulse exactly every 30 seconds.

Idea #2: Use a 30.72kHz crystal with a simple Pierce oscillator and a divide by 1024 IC.  (Or 512? or 2048?  My brain's not working at the moment.)

[marmad]

Idea #1: Use a 74HC5555 and a 3.932160 MHz crystal.  Have the 74HC5555 divide by 2¹⁷.  This will give a pulse exactly every 30 seconds.

This will give a frequency of 30Hz (a period every 33mS) - not 33mHz (a period every 30 seconds).

Idea #2: Use a 30.72kHz crystal with a simple Pierce oscillator and a divide by 1024 IC.  (Or 512? or 2048?  My brain's not working at the moment.)

This also gives 30Hz - not 33mHz. It seems you're confused between frequency and period. It's not possible to get to the correct frequency using either of the crystal frequencies you mentioned and a single undecoded binary divider-chain.

[TerminalJack505]

Idea #1: Use a 74HC5555 and a 3.932160 MHz crystal.  Have the 74HC5555 divide by 2¹⁷.  This will give a pulse exactly every 30 seconds.

This will give a frequency of 30Hz (a period every 33mS) - not 33mHz (a period every 30 seconds).

Idea #2: Use a 30.72kHz crystal with a simple Pierce oscillator and a divide by 1024 IC.  (Or 512? or 2048?  My brain's not working at the moment.)

This also gives 30Hz - not 33mHz. It seems you're confused between frequency and period. It's not possible to get to the correct frequency using either of the crystal frequencies you mentioned and a single undecoded binary divider-chain.

Yep.  I stand corrected.

[David_AVD]

Use a PIC.   

[marmad]

@Simon - Here is a quickly revised schematic (sorry about the sloppiness) showing the entire circuit with crystal putting out a 33mHz frequency (30 sec period) in it's simplest form (plus a DSO image of the output of the 4541). I don't think there's an easier - or smaller package count - way to do this using discrete chips. If you wanted programmability, adding switches to the 4526 could allow you to change the period from 4 - 32 seconds in 2 second increments - and adding a switch to the 4541 could give you shorter periods, for example, 0.5 - 4 seconds in 0.25 second increments. Of course, as many have mentioned, with a few lines of code it's incredibly simple to do using an MCU - and more flexible in the long run - but sometimes the old-fashioned way is kind of fun 

Edit: Just did a quick check and it seems the 74HCT161 (another divide-by-n 4 bit counter) is perhaps a better buy than the HEF4526 - it just depends on what package size you need and if you plan on using higher CMOS voltages.

[Simon]

well I've got nothing against micro's I just had this row on the avr forum about the documentation of the libs. It seems that unless your a pro in programming mcu's take for ever so I'm going to give them a break, do some descrete stuff and play with the arduino for a bit.

[olsenn]

I can send you the code for my frequency counter if you'd like... you'll see just how easy using the built-in 16-bit counter of the atmega328 is. The best part is, if you have an Arduino, you already have the IC

[Simon]

sure why now, I'll have a look

[c4757p]

I can send you the code for my frequency counter if you'd like... you'll see just how easy using the built-in 16-bit counter of the atmega328 is. The best part is, if you have an Arduino, you already have the IC

Shhh... I was about to do a freq counter all in 7400s just for the fun of designing it. Stop tempting me with MCUs! 

(Oh well, I guess I'll at least need an external divider for the higher frequencies anyway...)

[Simon]

haha, I guess a discrete solution will end up needing a wall wart

[c4757p]

It seems that unless your a pro in programming mcu's take for ever

Programming and electronics intersect often, but they're definitely very different skills that each take a long time to master. I highly recommend anyone interested in either one to diversify and cross over into the other, but it's not easy. I sometimes forget that - I'll recommend a MCU for something as if it's "easy" to just bang out some code, but I've been programming since I was eight years old and it's as easy for me at this point to write "instructions" in C or assembly as to write them in English. I can forget that the process of going from "I want to do this" to finished code and an implementation is pretty daunting if you're not used to it.

I just had this row on the avr forum about the documentation of the libs

They're programmers. You can't tell them that their favorite stuff sucks, that's heresy. (AVR documentation in general does suck, and the library documentation sucks even harder. I'm with you there.)

[Thor-Arne]

Shhh... I was about to do a freq counter all in 7400s just for the fun of designing it. Stop tempting me with MCUs! 

(Oh well, I guess I'll at least need an external divider for the higher frequencies anyway...)

It's fun playing with counters, get on with it. 

I have one more or less compete sitting on a breadboard, just the control-timing left to do.
While waiting for parts for another project I got bored and slammed it together. 

[marmad]

I highly recommend anyone interested in either one to diversify and cross over into the other, but it's not easy. I sometimes forget that - I'll recommend a MCU for something as if it's "easy" to just bang out some code, but I've been programming since I was eight years old and it's as easy for me at this point to write "instructions" in C or assembly as to write them in English. I can forget that the process of going from "I want to do this" to finished code and an implementation is pretty daunting if you're not used to it.

In terms of super long-term reliability and ultra-low current, MCU's still have a way to go to prove themselves. I still have ~40-year old objects built from discrete logic continuing to run merrily along - and +20-year old objects built from discrete CMOS logic still running off the same battery cell.  In the same few decades, I've had numerous expired MCU-based objects due to lost bits from ROMs, PROMs, EPROMs, EEPROMs, Flash ROMs, etc. Of course, I know that they get continually better - but they can't yet compete against discrete logic's track record.

[Simon]

I just had this row on the avr forum about the documentation of the libs

They're programmers. You can't tell them that their favorite stuff sucks, that's heresy. (AVR documentation in general does suck, and the library documentation sucks even harder. I'm with you there.)

To be fair pics are equally confusing and lacking, people either try to explain what a digital signal is or how some function works without the bit in the middle, So I think it's a combination of me being very dense and people who can't be bothered to write proper instructions.