frecvente de lucru

[bogdan_]

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...

[Vizitator 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.

[bogdan_]

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.

[one]

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.

[bogdan_]

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.

[Vizitator 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.

[bogdan_]

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.