Zaslal: so září 29 2007, 20:23 Předmět: Rychlost debuggeru v mplab
Dobrý den,chtěl bych se zeptat jestli jde něčím zrychlit debugger v MPLABu.Používám simulátor a ladim program pro čítač,kterej má 1s časovač a když spustim debugger(ne animaci) tak to trvá asi 8s.Zatížení
C2D je 50%(asi celí 1jádro naplno).Mě se to zdá nějaký pomalí když PIC by to provedl za 1s.Nevíte co se dá nastavit pro zrychlení?Mám puštěný akorát hodiny ze stimulusu na 1 pin.Díky.
No ale na co mi ta simulace potom bude?Já potřebuju vyladit tu 1s (přesně na 4999872 cyklů).A taky v tý smyčce hlídám přetečení TMR0 a potřebuju vědět jestli nemůže dojít k přetečení který nestihnu zpracovat(je
tam na konci docela dlouhá procedůra na kalibraci +/-128cyklů).Nezdá se mi že by PC 2GHz nestihlo simulovat PIC 5MIPS rychlejc než v reálným čase(aspoň 100x).
POZOR vyladit presne na jednu sekundu softwarovo neznamena, ze ti to bude robit presne jednu sekundu aj hardwarovo!!! Dalsia vec je - co pre teba znamena presne 1s? Totiz aj krystal ma urcitu toleranciu - niekolko ppm. A tiez jeho frekvencia je zavisla od napajacieho napatia a teploty /aj ked minimalne ale je/... Tu sekundu mozes mat len taku presnu a aku presnu budes mat frekvenciu z krystala...
Proto tam je přece kalibrace - hrubá +/-128 cyklů a jemná x 0,00000002 - 0,00000255.A když bude potřeba dá se ještě zpřesnit.Pravděpodobně udělám i hlídání teploty.Ale nejdřív to musim vyladit - a čekat pokaždý 10s je vopruz.Nemáte někdo zkušenost s PIC18 Simulator IDE?Nebo jinej debuger pro PIC?Jde nějak v MPLAB nasimulovat LCD displej?Zatim díky za reakce.
Teď to ladim pro 16f676 a napájení bude společný pro LCD takže 4,5-5V.
Zajímavý je že v MPLABu se to chová uplně jinak než ve skutečným procesoru.Mám použitý jenom PORTB na komunikaci s LCD(jenom výstupy) a jedinej vstup je T0CKI.V MPLABu sou v registrech správný čísla a ve skutečnosti místo nuly ukazuje blbost a začne ukazovat až od 1KHz.Jedna věc mi neni uplně jasná v 16f505 se měl STATUS,C nastavit
při záporným přenosu u SUBWF na 0.U 676 sem to v manuálu nenašel ale podle MPLAB se nastavý na 1 jako u ADDWF.Du tomu zas chvilku dát snad na něco přijdu.
Ten MPLAB bude nejspíš nějakej vadnej produkt, protože ty máš jak zmiňuješ, pochopitelně vše správně. Však jsi taky nějakej Programovač! Až budeš mít ten MPLAB vychytanej, dej vědět. Jinak u 16F676 má bit Carry/not Borrow naprosto stejnou funkci, jako u ostatních PIC, ostatně je to přesně popsáno v manuálu 16F676.
Díky moc za super radu,ale já nikde nepsal že mám všechno správně.Kdybych to věděl tak bych se neptal.Rada typu "máš to rozbitý,protože MPLAB je bez chyb" je mi na nic.To že de něco udělat špatně ví každej kdo někdy ladil program.Spíš bych potřeboval vědět kde ta chyba je.A nepsal sem že MPLAB je vadnej,ale ptal sem se jestli nejde zrychlit debugger.
Zrychlit simulátor opravdu nejspíš nejde, simulace jednou osminou rychlosti procesoru se mi zdá přiměřená. A proč ti to nesimuluje jak má, by ti na základě poskytnutých informací možná řekl jasnovidec. Ovšem vyslovit přesvědčení, že chyba je na 95% u tebe, dovedu i já.
S tim že je chyba asi u mě souhlasim.Ta rychlost se mi ale nějak nezdá.Když se simuluje PIC na 20MHz na PC 2GHz 8x pomaleji tak má PC na každý takt PICu 3200 taktů(a instrukcí snad zvládne ještě víc).Samozdřejmě netušim co všechno se při tý simulaci děje,ale simuluje se přece jednoduchej procesor s pár periférijema.No a o tom co vlastně simuluju sem nenapsal nic takže maximálně mohl někdo říct :"v simulaci TMR0 je chyba ta a ta",nebo "žádná chyba tam nemůže být,protože jsem to skoušel a v reálu se to chovalo stejně jako v simulaci.
No a k tomu co vlastně ladim: chci udělat čítač kterej nepotřebuje vnější součástky a umí čítat co největší frekvenci za co nejkratší dobu na 7míst.Jestli sem to pochopil správně tak TMR0 počítá max. do frekvence cyklů,ale předdělič má omezení jenom 10nS na každej stav(takže skoro do 50MHz?).Když zapnu dělení 16-ti tak se 16x prodlouží doba měření.
Takže se pokoušim vyladit program kterej by přečetl předdělič.Na konci čítání přepnu čítání ze vstupu T0CKI na CLKOUT a potom počítám počet cyklů do doby než přeteče předdělič(inkrementuje se čítač).Program je v MPLABU už odladěnej a rozlišuje i nejnižší byte kterej by měl být v předděličce.Ve skutečnosti program funguje jinak(vypadá to jako kdyby se nejnižší byte neměnil - nejnižší změna je možná těch 256,ale nejsem si jistej nemám přesnej generátor) - to by ukazovalo na to že se předdělička při přepnutí z T0CKI na CLKOUT ve skutečnost resetuje.Je samozdřejmě možné že je chyba v programu nebo někde jinde.
Zkoušel jsem simulovat v MPLABu smyčku 1s. Když vypnu i tracing, tak to Pentium 1,6GHz zvládá v "reálném čase".
Nezapomínáš ve svém programu, že prescaler se nuluje při zápisu do registru TMR0?
Docela by mě zajímalo. jak měříš dobu do přetečení předděličky. Kmitočet Fosc/4 je docela hodně na rozumné rozlišení. A s tím souvisí otázka, proč nepoužíváš předděličku celou.
Super konečně trochu pokrok.Taky sem vypnul trace all a program projel do 2s.To už se dá.Díky za typ.Co to trace vůbec dělá?Nevyřadí to simulaci nějakých periferií?Jinak TMR0 jenom čtu - to by snad nemělo mít vliv,akorát na začátku ho nuluju,ale to by nemělo vadit protože předdělič mám nastavenej na /256(doufám že zablokování na 2 cykly se předděličky netýká - ale i to by snad šlo kompenzovat jestli to trvá pokaždý stejnou dobu).Na konci počítání nastavim v OPTIONREG,T0CS na 0 - to by mělo přepnout TMR0(i s děličkou) na CLK/4.Čas za kterej přeteče předdělička měřim v TMR1(taky připojenej na CLK/4).Problém byl akorát v tom že test jestli se inkrementoval TMR1 trvá 3 cykly,takže abych zjistil hodnotu předděličky přesně na bit ,testuju třikrát a každej test je posunutej o takt a to nejmenší číslo je správnej výsledek(potom ještě pár korekcí aby se vyrovnali zpoždění).Simulace v MPLABu vypadá jako že to chodí správně.Jenom nevim jak na vstup předděličky dát větší kmitočet než CLK/8.Ale registr na nejnižší číslo(to co je v předděličce) ukazuju na bit přesně.
Časy uváděny v GMT + 1 hodina Jdi na stránku 1, 2Další
Strana 1 z 2
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.
FAQ
Hledat
Uživatelské skupiny
Profil
Soukromé zprávy
Přihlášení
