Van egy láb, amin kivezethető a belső órajel, ezt tudod beállítani, hogy kijöjjön, vagy ne. A hozzá tartozó láb vagy oszci kimenet, vagy normál I/O láb lesz a beállítástól függően.

Ez most nem teljesen világos . Feltennéd a "progi"részletet ?

Elnézést tévedtem! Kitöröltem egy cursor blokkot! Mindegy, hogy beleírod közvetlenül, vagy konstansból veszi. Kivéve, ha egy szöveget többször is felhasználsz, de még ebben sem vagyok biztos, mert lehet, hogy figyeli, ha azonosság van, nem teszi le kétszer, bár ebben szkeptikus vagyok, meg kell néznem!

Érteeem, ö, valami. Hazudtam nem értem ez igy gyors de remélem felfogom idövel, szoval az hogy internal vagy external az azt jelenti hogy kiküldi vagy nem?

Akkor a kurzor blokk a helyigényes ??

Viszont csináltam gyorsan a tanulmányaim alapján egy kicsi progit, szerrintetek ezzel 256 lépésben tudok mérni egy impulzus jelet?

Nem, csak kitöröltem és azt hittem az optimalizáció miatt csökkent a kód, de a törlés miatt volt.
Viszont érdekes dolgot tapasztaltam, inteligens a fordító. Hiába tettem ki constansba több helyen használt szöveget és azokat jelenítettem meg a direkt beírás helyett, nem csökkent a kód mérete.

Bár most esik le, hogy ha mindenhová befordítja így is, akkor lehet, hogy nem is azért nem csökkent, mert már korábban is csak egyszer tette le! Ezt meg kell néznem az asm forrásban, hányszor van meg benne egy adott menü szöveg!

Nem, az external külső oszci, az internal belső. Az internal utáni opciókról kérdeztél és én arra válaszoltam!

Jó igy már értem, különben ez a külsö, belsö dolog is érthetetlen volt de már vágom mi az a beállitás.
Ismét okultam. Kilépés de nekem egy km.

Ez okés, de ez itt off, mert semmi köze a Flow-hoz. Ilyen kérdéseket a PIC kezdők kiemelt topicban tegyél fel, ott biztosan kapsz rá választ sok embertől, türelmesebbektől, mint én!

Na kiderítettem! Mindegy, hogy constas-ból, vagy direkt szövegből töltöm fel a kijelző blokkot, mindenféleképpen befordítja annyiszor, ahányszor előfordul. Ez hihetetlenül pazarolja a memóriát. A Constans igazából nem is tárolódik le a memóriában, az csak a fordítónak él, hogy be tudja fordítani mindenhová. Nagyon sok ilyen kényelmes megoldás van a fordítóban, ami csökkenti az értékét az egésznek. Na de ez van...

Bocsi hogy bele vau-vau de nem érné meg becsatolni egy ngyobb memoriát esetleg egy SD kártyát? Ezt mint laikus kérdem. A másik viszont az hogyha flowból csinálok C file-t akkor tele van sallangal, azokat is leforditja hex-be, vagy csak a program segit megérteni hogy miért is csinálja amit csinál.

En nem mondtam hogy a C mindenhato. Viszont meg lehet benne irni mindent es megfeleo trukkokkel lehet csokkenteni a kodmereteket. Nem muszaly a beepitett fvenyeket hasznalni, mert azok altalaban eleg szoszatyarok. Pl jo pelda erre a printf() fveny. Masik dolog pedig a float valtozok kerulese. Egesz szamokkal is lehet szamolni, valamint irni sajat fvenyt a kijelzesre. Igy hirtelen meg tudsz takaritani 50-60 % programhelyet. Persze ehhez kell egy kieves gyakorlat (mondjuk nem keves). Megfelelo programszervezesse, es jo utemezessel azert jo es bombabiztos programot lehet irni C-ben. Biztos gyorsabb a FC-ben osszedobalni a modulokat, de ugyanezt meg lehet csinalni C-ben is, ha hasznalod a sok beepitett fvenyt. Csak ugye ilyenkor 1-2 szammal nagyobb meretu PIC-et (uC-t) kell valasztani, ami ugye penzben is szamithat sorozatgyartasnal, Valamint a leforditott programok futasi ideje, bonyolultsaga is jelentosen megno. Nekem pl egy 16F690-be belefert a homersekletszabalyzo, ami 8 merest atlagol, 5 programmemoria van, allithato a P erosites, es egyebb kenyelmi dolgokkal meg van tuzdelve. Itt az a fo gond ahogy elnezem, hogy a kedves kezdo PIC-ezonek teljesen mindegy mit adsz a kezebe, mert azt olvasta a forumon, hogy ezzel a FC-vel, vagy a Parsic-kal milyen egyszeru programot irni, es elkezdi, de hianyzik a programozoi szemlelet, a gyakorlat es csak kinlodni fog a programozassal igy is, ugy is. Ahelyett hogy elkezdene az ASM es utana a C programozast az alapoktol nagy-nagy turelemmel. En is igy kezdtem a programozast anno, vagy meg igyebben, mert meg nem volt internet, meg sokfele fordito. Elso probalkozasaim ( egy par basic program az ABC-80 gepre) utan, gepi kodban (hexaban) valo programiras a I8085 procira. Utana mar a PC-s idokben ASM-ben irtam RS232 drivert a XT-re. Persze sok turelemmel, mert ugye elsore nem sikerulhet minden. Persze a mai vilag egy kicsit porgobb, de azert egy fiatalnak is be kell latni, hogy ezt a szakmat csak kitartassal lehet csinalni. Irtak itt olyat, hogy ok kis gyakorlattal sokkal gyorsabban megirnak egy programot mint mas C-ben. Ez lehetseges, csak ezt a programot en nem raknam be egy ipari folyamatba. Az asztalon protoboardon jo jatszani, de komolyabb termekben ezek alkalmatlanok. Oda komoly gyakorlat, es megfelelo tudas kell, valamint komoly fejlesztoi rendszer, amit nem oktatasra, hanem munkara keszitettek.

Ezt miért nekem írod? Vagy kifelé beszélsz? És nincs mindenben igazad. Mellesleg ha visszaolvasol, ezeket a dolgokat már átkínlódtuk itt, azaz átoffoltuk, nem kéne újból kezdeni.
Még egy dolgot nem értek. Mit keresel itt? Egy hozzászólásod nem szólt a Flowcode-ról. Folyamatosan C-zel. Azért jársz ide, hogy rosszul érezd magad a sok "hülyétől", aki Flowcode-t használ?

Nem próbáltam még. Hová kell ezt beírni? A szokásos helyeken nem történik semmi. (Compiler, Linker...)

Alapból be van kapcsolva az optimalizáció. Ha kikapcsolom ( -o0), akkor a kód mérete 29158 bájt. Ha visszakapcsolom( -o2), akkor 20286, mint alapból is.
De jó ötlet volt, érdemes volt megnézni! Köszi!

Nem azert irok ide, hanem megprobalok segiteni bizonyos problemak athidalasaban. Ha visszaolvasol, azert talasz eleg sok segito hozzaszolasomat is ebben a temaban (persze masban is). Mellesleg pont Te voltal az aki sok hibara mutattal ra ebben a "kivalo" programban.

A Fordító beállítások / Link/Assebler-nél kell beírni a végére, hogy -o0

Folyamatosan találok hibákat benne, amit meg is beszélünk és ha tudjuk kezeljük, vagy együtt élünk vele.

Mert benne van a bootloader.

Tényleg kicsi A RAM-ot 92%, a program memóriát 127%-ban foglalnám. Úgyis megcsinálom, hogy beleférjen.

Én nem! A Te ötleteden "lovagolok".

Én figyelek!

Nem lehetne a konstansokat EEPROMba tölteni és futtatáskor csak kiolvasni onnan?

Ráadásul a String változók deklarálásakor alapból 20karakter hosszúságot állít be. Ezt le is foglalja. Ha tudod milyen hosszú lesz a változód, érdemes azt a hosszt lefoglalni.

A bootloader 1000bájt, a PIC 32K-s. Hol a többi?

Nem.

Az nem zavarna egy constansnál, az inkább, hogy nem csak egyszer fordítja bele a memóriába. Most szenvedek, hogy a Flow által fordított C-t beletuszkoljam C18-ba. Kíváncsi vagyok mennyivel fordít kisebb kódot...

Kettős érzelmeim vannak. A Flowcode optimalizációja figyelemre méltó, miután 29k ról 20k köré nyomja le a hex-et. Mondom ezt azért, mert átgyúrtam C18-ra a nyers C forrást, amit a Flow fordított az ábrából, nagy nehezen sikerült mindent módosítani, amiben síkítozott, majd le is fordult, viszont nem fér bele a memóriába a fordítás.
Következtetés: Nincs sok értelme más fordítóval próbálkozni, mert a Flow eszement C forrását, csak hasonlóan eszement fordító tudja a legkisebb, de ettől föggetlenül hatalmas méretre fordítani.

Rövid kérdésem lenne TMR 2 vagy 1 el érdemes próbálkozni.

Átalakítom az óracsoport időmérését kíváncsiságból, és felajzott PJG mutatós ötlete.
Pár szóban felvilágosítana valaki, hogy flow hogyan kezeli a TMR2 vagy az 1 et.
(miből lehet kis léptető motort szerezni? floppy, CDrom? melyik a jobb, vagy mi van még)

Előosztó és "utóosztó"? beállítás után az adott Hz-en fog a makró számolni?

Azért érdekel, mert a 100ms os mérés lednél jó, de léptetőmotornál nagy ugrások lennének.

Viszont előbb meg kellene tudnom mérni mennyi fogú jeladó kerék kell, hogy 10ms alatt is értékelhető és számolható jel jöjjön be.
mert:
100ms esetén 30 fogú kell ahhoz, hogy 20 f/perc es léptetés legyen
ez 10ms alatt 200 f/perc lesz a lépésköz vagyis hiába tud kicsit lépni a mutató a jelek száma miatt nagyot fog ugrani így nem lesz folyamatos a mozgás