ElectroYou

Salve a tutti
Ho programmato un frequenzimetro utilizzando l'ATMega32
Ho riscritto i fuse perche uso un cristallo di quarzo esterno da 16MHz.

Ho collegato il mio frequenzimentro ad un generatore di segnale e visualizzo su un LCD la frequenza perfettamente (sbaglia solo di 1hz)

il problema e' che oltre 32.7khz si blocca tutto e non misura piu.
ho programmato i fuse cosi per avere startup time 16K CK + 65ms


quello che mi suno familiare e' il valore di questa frequenza "limite" che e' molto vicina alla frequenza che leggo a pag 27 del datasheet (Low-frequency Crystal Oscillator 32.768Khz)...\
eppure usando avr fuse calculator ho scelto il settaggio giusto per un "ext. crystal high frequency"

i miei fuse ora sono hfuse: 0xFF lfuse:0xC9
(JTAG disabilitato e CKOPT programmed)


qualcuno sa aiutarmi?

Non conosco avr fuse calculator ma se tu dici che è giusto suppongo che avrai letto il datasheet.

A quale modulo interno hai collegato il segnale del generatore di funzioni? Il datasheet dice qualcosa di più riguardo alla frequenza di 32768 Hz.

Ciao

sobrano ha scritto:il problema e' che oltre 32.7khz si blocca tutto e non misura piu.
....

quello che mi suno familiare e' il valore di questa frequenza "limite" che e' molto vicina alla frequenza che leggo a

A me suona molto più familiare pensando al massimo valore positivo che può assumere un signed integer a 16 bit.

ciao e grazie per le risposte. In effetti potrebbe essere un limite numerico ma non riesco a capire perche le mie variabili sono int quindi a 32 bit

L'unica cosa che mi viene in mente e' che i dati all'LCD vengono inviati tramite gli 8pin di dati quindi forse posso passargli al massimo un numero a 8bit ma qui effettivamente il limite sembra essere un 16bit

qui sotto c e il mio programma, potreste dargli uno sguardo? e' molto corto per voi dovrebbe essere semplicissimo

#define F_CPU 16000000UL

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "lcd_stefano.h"

static volatile int signal_overflow = 0;
static volatile int frequenza = 0;

int main(void)
{
LCD8_Initialization();

DDRB &= ~(1<<PINB0);
TCCR0 |= 1<<CS02 | 1<<CS01 | 1<<CS00;
TCCR1B |= 1<<WGM12;
TIMSK |= 1<<TOIE0;
TIMSK |= 1<<OCIE1A;

OCR1A = 62500;

SendString("frequenza");
SetCursorPosition(1,10); SendString("Hz");
SetCursorPosition(1,0);

sei();

while (1)
{}
return 0;
}


ISR(TIMER0_OVF_vect)
{
signal_overflow++;
}
ISR(TIMER1_COMPA_vect)
{
frequenza = (signal_overflow*256+TCNT0);
TCNT0 = 0;
signal_overflow = 0;

SendInteger(frequenza,8);
SendString(" ");
SetCursorPosition(1,0);

}

Non mettere nel service di interrupt le funzioni di aggiornamento del display!!!
Così il refresh del display dipende dalla frequenza misurata, e oltre una certa frequenza ammazzi la CPU!
Programma un service di interrupt che si aggiorni una volta o due volte al secondo e usa quella per il refresh.

Poi, non bisognerebbe mai scrivere TCNT, potresti generare dei false compare match (cfr datasheet)
Inoltre, dovresti mettere TCNT=0 alla fine del service, altrimenti il contatore comincerà a contare prima che tu faccia delle lunghe operazioni sul display e questo fa si che tu abbia un errore di conteggio.

Poi, non fare così per misurare la frequenza.

Usa l'ICP, quando hai un fronte in salita memorizzi il valore del contatore, quando hai il fronte in discesa memorizzi nuovamente il valore del contatore e al nuovo fronte in salita memorizzi in una variabile il nuovo valore. Così hai anche il duty cycle gratis facendo le varie somme e sottrazioni.

Non gestire gli overflow del contatore ma cambia il tempo di conteggio, in modo da creare un tempo di GATE.
In pratica comincia con un contatore molto rapido, se quando va in overflow le variabili sono ancora nulle (oppure con una piccola differenza fra loro) allora aumenta il tempo di conteggio.
Aumenta il tempo di conteggio il più possibile e avrai una misura soddisfacente.
Facendo così farai anche l'autoranging a costo quasi nullo.

Mi aspetto però che la massima frequenza di conteggio non sia molto alta, però.
Se vorrai (dopo aver fatto quanto sopra e verificato il funzionamento) per aumentare il range puoi mettere avanti all'ingresso dell'ICP dei divisori digitali (ce ne sono che possono andare a frequenze enormi) il cui valore di divisione è pilotato dall'autorange del microcontrollore. A questo punto avrai diviso la frequenza in ingresso per una costante nota e quindi potrai scrivere il valore corretto sul display.

Ci sono poi dei nice to have interessanti da aggiungere, tipo il periodimetro, il contatore fronte in salita o in discesa per fare voltmetri a integrazione ecc... ma ne parliamo eventualmente poi.
Se io dovessi progettare un frequenzimetro la prima cosa che farei sarebbe quella di cercare di sapere tutto sui frequenzimetri

Ciao,
Pietro.

PietroBaima ha scritto:...Se io dovessi progettare un frequenzimetro la prima cosa che farei sarebbe quella di cercare di sapere tutto sui frequenzimetri

Il punto è proprio questo!
Bisogna sapere come funziona un frequenzimetro.
Con il micro in questione non è difficile fare un frequenzimetro che misuri frequenze anche superiori a 20MHz.
Lo diventa se non si ha idea di come funzioni un frequenzimetro.

ciao Pietro grazie tantissimo per i consigli, ho letto varie volte la tua risposta e ho riflettuto un po sul dafarsi:

1.per il primo punto dovrei essere a posto perche nel mio programma l aggiornamento del display non avviene in dipendenza dalla frequenza che sto misurando ma 1 volta al secondo. Infatti entro nella
ISR(TIMER1_COMPA_vect) solo quando il contatore TCNT1 diventa uguale all'OCR1A, ovvero quando e' passato 1s.

2. "Poi, non bisognerebbe mai scrivere TCNT" questo non l ho capito chiedo scusa... le uniche volte che lo chiamo, uso TCNT0 che mi serve per calcolare il valore della frequenza e poi lo azzero... che significa che non lo devo scrivere?

3.ho pensato molto quando azzerare il contatore TCNT0=0 se prima o dopo il refresh.
Alla fine avevo scelto di riazzerare il contatore e la variablile degli overflow immediatamente dopo averli usati. altrimenti se si eseguno istruzioni prima di riazzerarlo il contatore continua ad incrementarsi e quando finalmente lo riazzeriamo ci perdiamo dei conteggi che invece appartenevano gia alla misura successiva ...(forse qua mi sbaglio?)

4. se ho capito bene tu mi consigli, invece di fissare una finestra temporale (in questo caso 1s) in cui contare gli impulsi e calcolare la frequenza, di contare gli impulsi fino ad avere l'overflow. Cioe' invece di misurare la frequenza una volta al secondo, misurarla tante e tante volte e refreshare comunque il display 1 volta al secondo...( ho capito bene)

5. e' assolutamente vero che non so molto sui frequenzimetri ma sono ai primi progetti e lo sto facendo piu per didattica che per reale bisogno di un frequenzimetro quindi mi sento di favorire piu la realizzazione pratica di programmazione dell mcu piu che approfondire tanto tanto la teoria del frequenzimetro.

a parte tutto questo sono secondo voi lontano dal poter risolvere il problema originario di questo strano limite di conteggio a ~32.7Khz?

comunque GRAZIE di cuore per l aiuto che mi date

Prego figurati.

Il discorso è che aggiornando il display dentro il service di interrupt fai pedere tempo fra le misure.
Ti conviene utilizzare un altro timer che abbia un refresh costante.

il TCNT lo scrivi... nel momento in cui lo poni forzatamente a zero. Questa pratica non è consigliabile perché, sebbene tu ne abbia l'accesso in scrittura, anche l'hardware del micro lo scrive e questo può generare guai. E' tutto scritto sul datasheet.

Ho capito il tuo algoritmo, però, più che migliorarlo, io lo riscriverei nella direzione di catturare degli ICP.
In questo modo puoi lasciar contare il contatore fino al suo overflow "naturale" e regoli la velocità di conteggio del contatore in funzione della frequenza che stai misurando, in modo da andare avanti per approssimazioni successive fino a trovare la finestra ottima.
E' un metodo molto usato per fare gli autoranging nei frequenzimetri.

Una cosa fondamentale è tenere separate le lettura della frequenza e le scritture sul display. Non usare lo stesso interrupt.

Ciao,
Pietro.