Szimulátorban nézd meg, hogy az 500ms az biztosan 500ms?

Igen a delay-ok jónak tűnnek,mert ha nagyobbra állítom pl.5másodpercre akkor kivárja és utána megy magasba a kimenet.

Kapcsolási rajzot mutatnál? Hogy vannak bekötve a LED-ek?

Igazából a kapcsolást most a picsimulatoride program helyettesíti,de ezt kell elképzelni egy 877-essel 4mhz-es kvarccal.

Nade először nincs is Delay, akkor mit vár ki? Pont fordítva kéne, 5sec után kéne elaludjon!
Próbáld meg While(1)-el inkább a for helyett!

Jó, akkor ezt képzelem el. A HEX fájlt csatold már be. Ha van lista fájl, akkor azt is.

A nulla az bármilyen számrendszerben nulla. De a nullától különböző értékeket sem kötelező hexadecimálisan megadni, csak többnyire áttekinthetőbbnek tartjuk.

Ez már while-al van.

void main()
{
TRISB = 0x00 ; // set PORTB as OUTPUT

while(1) // forever
{
PORTB = 0xff ; // turn all LEDs ON
Delay_ms(500) ; // wait 500 ms
PORTB = 0 ; // turn all LEDs OFF
Delay_ms(500) ; // wait 500 ms
}
}

Az általad küldött HEX tökéletesen működik MPLAB IDE alatt. Csak szimulációhoz nem érdemes ilyen hosszú időzítéseket használni, ahhoz 50-100 us (nem ms!) is bőven elég volna! Ha ahhoz az utasításhoz tettem a töréspontot, ahol nullába állítja vissza a B portot, akkor 500008 utasítás után állt le először, majd 1000000 utasításonként került oda ismét. Ezt írtad elő a programban is, tehát azt csinálja, amit kell.

Lehet, hogy csak türelmetlen voltál, és nem vártad ki az 500009. utasítást, ami nullába állítja a B portot?

Sajnos nem pedig frankón meg van írva.
Nekem úgy tűnik mintha,csak egyszer hajtaná végre a ciklust.Az összes kimenet állva maradt.

Igen már látom, nem vártam ki eleget.
De akkor hogy lehet elérni,hogy a simulátoron a valós 1 másodpercenkénti villogás legyen?
Pontosan erről a prg-ről lenne szó:pic.simulator.ide.6.73.

Nem tudom, hogy mi ez a PIC Simulator IDE, de szerintem egyik szimulátornak sem célja, hogy az időzítést valósághűen jelenítse meg. Sokkal inkább az a cél, hogy a regiszterekben történő adatáramlás helyesen legyen szimulálva, a program utasításainak megfelelően, s hogy a folyamat megállítható, ellenőrizhető és szükség esetén felülbírálható (pl. valamelyik regiszter átírásával) legyen.

Igazad lehet.
Most egyébként ha a pic-ben próbáltam volna ki (nem pedig a szimulátorban), akkor 500ms-onként villogott volna?
Tehát,ha szimulátoron nézem akkor us-os tartomány,ha pic-be égetem akkor ms-os?
A mikroc a valós értékeket fordítja a pic számra?

Nem 500 ms-onként villog, hanem 500 ms-onként vált állapotot (tehát 1000 ms után kerül azonos állapotba, magyarul másodpercenként villog).
Ha jól adod meg a PIC órajel generátorának afrekvenciáját, akkor kiszámolja, hogy a megadott késleltetéshez hány utasításciklust kell beiktatnia. Ha az órajel 4 MHz, akkor az utasításciklus 1 us, így a szimulátorban mért 500 000 utasításciklus valóban 500 ms-nak felel meg.
Hacsak nem akarod, hogy kinőjön a szakállad, s teleírja a fél winchestert a nyomkövetési adatokkal, akkor igen, célszerű rövidre venni!

A PIC-be meg tizedmásodperces (100 ms nagyságrendű) késleltetések kellenek a LED villogtatásához, hogy a szemünkkel követni tudjuk a változásokat.

Neked hogy fordult le? Nekem egy órát kellett szenvednem(mivel nem értek a HI-Tech C-hez) mire egyáltalán lefordult! Egy halom olyan dolog volt amibe belekötött a fordító!

Ez nekem nem fordult le, csatoltam ami már igen...

Kicsit keveredés volt, mert azt hittem Te csatoltad a forrását a programodnak! Mindegy, nézd meg amit csatoltam annak működnie kell! (Feltéve, hogy Hi-Tech C-ben dolgoztál...)

Szerintem itt található a becsatolt HEX forrása, és úgy tudom, hogy MikroC-vel fordult, s az MPLAB szimulátora szerint működik az is.

Simpi Hi-Tech C forrást csatolt(ami mellesleg lefordíthatatlan volt), user hex-et, én meg összekevertem, hogy ki mit csatolt.

user! Feltettem azt a hex-et, ami elvileg jól kéne működjön, legalább a kapcsolásodat letesztelheted.

Csak ijesztgetésképpen: JAL nyelven meg így néz ki ugyanez a program.

A nyelv szintaktikája ugyanaz, de nem lehet egy az egyben átültetni. Ha viszont asm-ben meg tudsz oldani kisebb-nagyobb dolgokat, és ismered a C-t, akkor a kettőt már nem nehéz összeházasítani és kontrolleren használni.

Feltétlenül.

Ha a könyv példáit szeretnéd kipróbálni, arra ott van az ingyenes Dev-Cpp fejlesztői környezet és fordító, ha jól emlékszem a könyv is ezt ajánlja.

Ezt a forrásból másoltam ki:

Jobban jársz, ha olyan nyelvet tanulsz meg, amit támogat a gyár, és sokan hasznáják. A Hi-Tech-C nagyon hasonló és jó user manualja van!

Az előző becsatoláskor nem mellékelted az internals.h állományt, ami a Flowcode tartozéka lehet, azért nem fordult le.

- Itt - csatoltam azt a forrást, ami a tiedből lett. Van néhány dolog, ami más, mint amit a Flowcode gyártott. Ne is akarjuk, hogy egyforma legyen, csak legközelebb ha ilyen segítséget adsz, add meg az infót, hogy milyen fordítóval készítetted.

Bocs, most kerültem gépközelbe és látom, mivel szenvedtél... Szimulációnál láthatod, hogy mennyi idő telt el ( a szimulátor alapján ,ha jól van beállítva az órajel sebessége ) és azt vedd alapul, ne a valós időt!

Steve

Köszönöm mindenkinek a segítséget a tegnapi témában.
Most nézem ezt az lcd példát,de sajnos hasonló jelenséget produkál.Az eszköz mikroc-ben és a szimulátorban is egy 16f877 (4mhz xt).A kód le is fordul szépen,de szimulátor lcd-jén semmi nem jelenik meg.
Az látszik hogy a b portra küldki adatot,de a kijelző nem reagál.
Az időzítésekkel lehet a baj?

pont a lényeg nem látszik a programban, hogy mi van az lcd_init-ben. 4v.8bit .... szerintem itt lesz a kutya elásva, valahogy tuti lehet konfigurálni