Jump to content
ELFORUM - Forumul Electronistilor
Sign in to follow this  
bogdan_

frecvente de lucru

Recommended Posts

salut,am observat ceva ciudat la Atmeluri, mai exact la cele din seria ATMEGA(la restul nu m-am uitat).ideea e asa: pe datasheet la inceput spune frecventa de lucru pentru cel fara "L" la sfarsit: 0-16MHz.Dar, in datasheet, unde sunt date ratele Baud posibile pentru frecvente de ceas, sunt date pana la 20MHz. La fel si consumul procesorului functie de frecventa, tot pana la 20MHz.Deci stie cineva in ce conditii as putea rula sigur un Atmega 128 la 20MHz?Merge cu quartz, sau trebuie pus oscilator separat care sa ii dea 20MHz? Sau... nu merge deloc?vreau asta pentru ca trebuie sa scot o frecventa cat mai mare pe spi...

Share this post


Link to post
Share on other sites

Guest ltdor

Cel mai sigur functioneaza daca fabricantul garanteaza asta, dar nu o face. Se pare ca nucleul uC-ului functioneaza fara probleme la viteze mai mari decat cele specificate, rateurile aparand in primul rand la scrierea si citirea din eeprom. Se poate sa ai surpriza sa constati ca unele pot merge chiar si la 40Mhz atat timp cat nu folosesti eeprom-ul, iar cea mai mare parte vor functiona si la 20MHz. Avand in vedere insa ca fabricantul nu iti garanteaza decat 16MHz, nu iti recomand overclockingul pentru produse comerciale.Pe de alta parte, ruland chiar si la 16MHz, poti avea o frecventa de 4MHz pe SPI, adica un octet la fiecare 32 de cicli, ceea ce sincer nu cred ca vei obtine daca vrei ca uC-ul sa mai faca si alte lucruri. Ridicatul frecventei de la 16 la 20MHz nu este solutia corecta.

Share this post


Link to post
Share on other sites

de fapt, spi-ul poate merge pana la f/2, deci la 16Mhz pot merge cu 8MHz pe spi. motivul pentru care vreau sa fac acest overclocking este ca pe spi transfer date catre un ecran LCD color de mobil pe 16Biti. deocamdata tranfer la 4MHz si dureaza mai multe de 1 sec umplerea ecranului, de asta vreau sa fac un overclocking la procesor. aplicatia nu este comerciala, intr-un final cred ca o sa incerc ambele variante, si la 16Mhz si la 20MHz, sa vad diferenta. daca diferenta nu este sesizabila, atunci il las la 16MHz. Partea cu functionatul la frecvente mai mari este adevarata, eu am pus un PIC16F877 la 30MHz si a mers fara probl, dar cu tactul de ceas bagat extern. parca am crescut putin si tensiunea de alimentare, dar nu mai retin.

Share this post


Link to post
Share on other sites

Banuiesc ca acel tabel este intocmit la modul general, nu pt. un circuit anume, de aceea poate sa difere frecventa din tabel de cea a circuitului. Oricum tabelul este acelasi, daca apare maine o varianta cu Y in coada sau mai stiu eu cu ce, care merge la 25MHz.

Share this post


Link to post
Share on other sites

Nu stiu ce sa zic de general. eu ma mai uitam si la graficul care arata consumul in functie de frecventa de lucru si tensiunea de alimentare.de exemplu, pentru atmega 16 sunt duse pana la 20MHz, dar pentru atmega32 nu sunt duse decat paa la 16MHz, in schimb la ambele controllere tabelul cu ratele baud posibile sunt date pentru frecvente de pana la 20MHz.eu din graficul de mai jos(pentru atmega 128) inteleg ca frecventele pot fi atinse numai la o anumita tensiune de alimentare. deci alimetat la 5V as putea sa il duc la 20MHz./nu stiu ce sa mai cred.... oricum urmeaza sa experimentez cand se termina sesiunea.

Share this post


Link to post
Share on other sites

Guest ltdor

Faptul ca datasheet-ul iti arata grafice peste frecventa maxima nu inseamna nimic. Mai mult ca sigur au fost copiate din datasheet-ul preliminar cand se dorea realizarea cipurilor la 20MHz - dar n-au reusit. E foarte probabil ca 90% din uC-uri sa mearga fara probleme la 24MHz, dar probabil ca atmel preferea sa le marcheze la 16MHz , frecventa la care 99.99% din cipurile de pe wafer functioneaza. In felul asta nu mai este necesara sortarea individuala (cu inerente erori si preturi ) si instituirea unor preturi artificiale pentru diferite clase de viteza.De regula daca nu poti rezolva problema cu un clock de 16MHz, 25% in plus la viteza nu este o schimbare dramatica, iar raspunsul trebuie cautat la o clasa superioara, vezi ARM. Spun asta, pentru ca timpul de 1 secunda pentru fill-ul de la LCD este cam mare si nu cred ca viteza de transfer SPI te tine pe loc, ci altceva.La un ecran de 160x128x16bit, ai de transferat 40960 bytes, care la 4MHz dureaza 80ms, cu conditia sa poti alimenta registrul SPDR in ritmul asta, caci ai doar 32 de cicli pentru asta. Daca vrei doar sa stergi ecranul, e posibil. Daca insa vrei sa iei datele din exterior si sa ai si un protocol de comunicatie, deja e challanging. La 8MHz, ca sa pastrezi ritmul, nu se mai pune problema decat de procedura de sters ecranul, zic eu.In practica, in astfel de cazuri, se construieste un buget de timp al aplicatiei, la care se numara fiecare ciclu din fiecare intrerupere ca sa vezi cum stai.

Share this post


Link to post
Share on other sites

da, ai dreptate, am facut si eu calculul legat de timpul de tranfer pentru LCD. cel pe care il am eu e 132x176. o sa ma uit exact, rutinele de comanda sunt luate de pe internet. intr-adevar ar trebui sa dureze mult mai putin umplerea ecranului.spre ARM nu ma orientez inca, aplicatia nu necesita chiar asa de mult. in ceea ce priveste frecventele de operare, cred ca il las la 16MHz sa nu am probleme cu el. multumesc pentru sfaturi.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.