poorttijd veranderen

Je vraagstelling is wel heel vaag. Geef eens wat meer context. Je deelt 100MHz door 256, dan houd je ongeveer 390kHz over. Dat is dan vast geen sinus meer. Hoe deel je dat en waar bied je dat aan op de ATMega. Wat wil je ermee doen. Waarop doel je met poorttijd, de clock frequentie van de ATMega?

ik ben een frequentie counter aan het maken,
het signaal gaat eerst door een prescaler en dan timer1 in.
De atmega8 wordt geprogrammeerd met Bascom, deze zet een poort 10uS open en telt dan hoeveel bits hij in die sinus kan krijgen, bij 390KHz duurt een sinus korter dan 10uS dus snapt het prgramma het niet meer

Ik heb geen idee hoe denkt dat die counter zou moeten werken, maar meestal laat je een timer/counter extern klokken door het externe signaal wat je wilt meten. Je cleared de timer, wacht bijv. 0.1 seconde en leest de counter uit. De frequentie is dan 10 * de inhoud van de timer.
De wachttijd (gate tijd) kan je verkorten en verlengen, een langere gate tijd geeft een grotere nauwkeurigheid.
Een ATmega kan honderden kiloHertz aan, een PIC kan tellen tot 35 MHz. (Bij een Atmega wordt de timer gesampled, in de PIC telt ie rechtstreeks, dat verklaart het snelheidsverschil).
Maar hoe je met een gate-tijd van 10usec een signaal denkt te meten is mij onduidelijk.

Op 14 oktober 2005 17:30:07 schreef JoWi:
De wachttijd (gate tijd) kan je verkorten en verlengen, een langere gate tijd geeft een grotere nauwkeurigheid.
Een ATmega kan honderden kiloHertz aan, een PIC kan tellen tot 35 MHz. (Bij een Atmega wordt de timer gesampled, in de PIC telt ie rechtstreeks, dat verklaart het snelheidsverschil).

De datasheets van AVRs raden aan een externe (counter) clock niet sneller te laten lopen dan klokfrequentie/2,5. Dat kan dus wel meer zijn dan een paar honderd kHz maar het wordt inderdaad gesampled.

Ik programmeer met bascom, met dit programma laat ik doormiddel van het commando pulsein de atmel tellen.
Pulsein zet 10us een poort open en telt dan hoeveel bitjes hij in een sinus krijgt. Wanneer de ingang 1 is totdat de ingang weer 1 is.
Het getal wat eruit komt gooi ik door een berekening en dan krijg ik de freq in beeld van het lcd.
Maar nu het probleem:
wanneer je bij ongeveer 400 KHz komt kan de atmel het niet meer volgen omdat een sinus dan korter duurt dan 10us.
Hij is dus aan het tellen maar vindt geen einde.
Die 10us zou ik graag willen veranderen.
of kan iemand mij vertellen hoe ik hem sinusen laat meten in een bepaalde periode.

Mocht dit niet kunnen is het dan ook mogelijk om een pic te laten communiceren met de atmega8 ??
dus wanneer de pic de freq wil laten zien op het lcd dat hij dit dan stuurt naar de atmel en dat die het dan op t lcd gooit?

Op 14 oktober 2005 17:13:17 schreef muissie:
ik ben een frequentie counter aan het maken,
het signaal gaat eerst door een prescaler en dan timer1 in.
De atmega8 wordt geprogrammeerd met Bascom, deze zet een poort 10uS open en telt dan hoeveel bits hij in die sinus kan krijgen, bij 390KHz duurt een sinus korter dan 10uS dus snapt het prgramma het niet meer

Bij die 100Mhz is de periodetijd toch nog veel korter ?
Je moet het aantal perioden laten tellen door de counter in je AVR, bij die 390kHz krijg je dus in 10uS 39 periodes binnen.
Als ik het zo lees moet je even je frequentieteller-theorie ophalen

muissie: leg eens uit hoe je de frequentie wil meten ?
Wil je de lengte van een (1) periode meten ? Dat is dus niet de goede methode, afgezien van het feit dat dat nogal onnauwkeurig is. Eerder in deze draad hebben anderen al vermeld hoe het wel moet. Ook met een ATmega kan dat maar je moet de frequentie verder terugdelen dan op een PIC, maar voor de rest blijft de methodiek dezelfde.

Op 17 oktober 2005 16:33:24 schreef gradtje:
[...]

Bij die 100Mhz is de periodetijd toch nog veel korter ?
Je moet het aantal perioden laten tellen door de counter in je AVR, bij die 390kHz krijg je dus in 10uS 39 periodes binnen.
Als ik het zo lees moet je even je frequentieteller-theorie ophalen

ik denk dat je veel beter een hardware counter bouwt.

ten eerste is die software timing veel te onnauwkeurig. en met prescalers vergroot je je fout.
mak gewoon een 24 bit counter met een reset , een clock deler ( vanui t een 10Mhz kristal bijvoorbeeld ). laat die coutner gedurende 1 seconde tellen , lees de waarde uit , reset de counter en we zijn weer weg ...
tkan in de kleinse fpga van altera ( of xilinx, altera heeft voordeel dat je schematje kan maten met ttl ic's en dat erin pleuren )

Op 17 oktober 2005 16:45:44 schreef free_electron:
[...]
ten eerste is die software timing veel te onnauwkeurig. en met prescalers vergroot je je fout.

Dat hangt gewoon van de nauwkeurigheid van je klok van de micro af, dus je kristal (al dan niet met oven). En de prescaler moet je gewoon uitlezen na afloop van de gate tijd.

Op 14 oktober 2005 17:30:07 schreef JoWi:
Ik heb geen idee hoe denkt dat die counter zou moeten werken, maar meestal laat je een timer/counter extern klokken door het externe signaal wat je wilt meten. Je cleared de timer, wacht bijv. 0.1 seconde en leest de counter uit. De frequentie is dan 10 * de inhoud van de timer.
De wachttijd (gate tijd) kan je verkorten en verlengen, een langere gate tijd geeft een grotere nauwkeurigheid.
Een ATmega kan honderden kiloHertz aan, een PIC kan tellen tot 35 MHz. (Bij een Atmega wordt de timer gesampled, in de PIC telt ie rechtstreeks, dat verklaart het snelheidsverschil).
Maar hoe je met een gate-tijd van 10usec een signaal denkt te meten is mij onduidelijk.

Hoe pak ik dit dan aan, sorry ben nog niet zo'n ster in uC.
Met een appart ic of.....