Megtömöm a Bug reports témát.

Sziasztok
Valaki találkozott már olyannal Flowcode-5.... ban hogy a lábkiosztás el van csúszva?
Jelenleg 18F47J13-at tesztelgetek és egy lábbal el van csúszva. Nálam van a hiba vagy a PIC-ben?

Megtaláltam a megfejtést: a chip nézeten a QFN-t mutatja ami más kiosztású mint a TQFP.

Üdv Uraim! Egy gyors kérdés, nokia 3310 LCD-t tudok kezelni a programmal, mert megtaláltam a grafikus kijelzőt, de ha jól látom az RGB. Köszönöm a válaszokat.

A nokia3310 kijelzője minden csak nem rgb. Sima mono lcd. talán i2c soros buszos

Hello, nem azt írtam hogy a nokia 3310 LCD RGB. Hanem a kimenetek közt RGB grafikus LCD-t találtam meg. Arra vagyok kíváncsi, hogy simán mono LCD-t hogy tudom kezelni.

Akkor jól értem, hogy nem értem a kérdés lényegét. Mid van és mit szeretnél pontosan?

@Georgee: Esetleg javaslom "?" és a "." jeleket a megfelelő helyen használni! Általános iskola...

Nokia 3310 LCD-m, de a makrók között csak RGB grafikus LCD-t találtam.

Kifejezetten ehhez a kijelzőhöz pedig nagyon sok projekt van. De i2c-s megoldásokat keress. Ilyesmit például.. Itt van demo kód is. C-ben és hexában. Vagy kifejezetten flowcode kell? ESetleg itt találsz kódot is.

Igen, Flowcode-al tervezem. Azért kérdeztem, mik a lehetőségek.

Sziasztok .Megcsináltam egy kódzár programot .Véleményezné valaki a programot .Lehetne még javítani rajta? Csatolom a programot . Köszönöm előre is a segítséget és a véleményeket.

Érdemes a programot eleve egy késletetéssel indítani, így ez idő alatt biztosan normalizálódik a tápfeszültség és tutira felébred a kijelző. Az első szám kiírása után a kijelző kurzora automatikusan a következő karakterre ugrik, tehát a másodiktól kezdve nem kell azt külön beállítani. A kijelző törlés és a kijelző indítása parancs a 0,0 koordinátára viszi a kurzort, nem kell azt külön megadni törlés/indítás parancs után.

Üdvözlet mindenkinek

Kb egy éve érdeklődtem hogy az LCD kijelzőm valami oknál fogva mindenféle krix kraxot jelez ki. Megszületett az eredmény hogy mi okozta: nem megfelelő tápellátás. Ha más is beleesik ebbe a hibába akkor ez a megfejtés.

Megnyugtató, hogy előbb-utóbb minden problémára születik megoldás.

Valóban az

Sziasztok!

Régóta foglalkozok a flowcod-dal, kisebb nagyobb programokat megírtam benne, de van egy visszatérő állandó problémám a megszakítással. A programjaimban kerülöm a delay-t, mindent késleltetést, idő alapú dolgot tmr0-val oldok meg, hogy a program ne tudjon lemaradni semmilyen külső eseményről (input változás). Számomra ez azért fontos, mert mindig elváltozást kezelek, amit mindig szoftveresen szűrnöm kell, hogy a bejövő jelek esetleges zavartságát kiszűrjem (10-50ms).
A megszakítás engedélyezésnél beállított Hz alapján kiszámolt ütemezés a való életben soha nem úgy ütemez, mint ahogy gondolom. Mindig arra kényszerülök, hogy beállítok egy stopperrel és emberi ésszel felfogható időintervallumot (pontosabban nagy számú megszakítás db számot), majd azt stopperrel megmérem és visszaszámolok. Nem egy tudományos módszer.
A Flowcode példaprogramjaiban lévő 1s késleltetés példa is ugyan ezen az elven működik, csak annyi a különbség, hogy én nem a megszakításban figyelem az elérendő megszakítások számát, hanem a főprogramban. Megszakításban, nekem csak a változó=változó + 1 van, a hozzá tartozó engedély feltétellel.

Valaki össze tudná foglalni azt, hogy miért kínlódik mindenki ezzel?

Mutass egy példát és egy konkrét hibaleírást. Nem tudom, én nem kínlódom ezekkel...

Szia!

Közben pont kerestem egyet:

Ennek a lényege az lenne, hogy RA1-re beérkező jelet szoftveresen szűrje egy minimum ideig és a An0 bemeneten keresztül beadott analóg jel (piher poti) által arányosított maximum ideig.
Le és felfutó élt is szűri. Ha a jel stabil akkor a kimeneten (RA5) húzza a relét.

Az idő beállítás úgy nézne ki, hogy
INTERNAL_TIME_MS = 200ms (belső, fix minimum idő)
EXTERNAL_TIME_SCALE_MS = 1800ms (külső, potival állítható idő)

CALCULACIO = EXTERNAL_TIME_SCALE_MS * EXTERNAL_TIME_AI
EXTERNAL_SCALE_TIME_MS = CALCULACIO / 1023
FILTER_TIME_TMR0 = (INTERNAL_TIME_MS + EXTERNAL_SCALE_TIME_MS) / (1000 / TMRO_HZ)

Gyakorlatilag itt azt szeretném kiszámítani, hogy a megszakítás HZ-ből visszaszámolva, hogy mennyi megszakítás (FILTER_TIME_TMR0 (darab)) alatt hajtódik végre, a fix + külső poti által beadott értékű idő.

Ha kiszámolom számológéppel, hogy ha a timer másodpercenként 25-ször fut le, akkor az kb. 40ms. Ha a fix idő 200ms, akkor 5 megszakítás alatt telik ennyi idő. Ha a poti teljesen fel van tekerve (200+1800ms), akkor az 2 sec, azaz 50 megszakítási ütem.

A belinkelt programban látszik, hogy a valóságos helyzetben, ezekkel a számokkal működik az időzítés kb. úgy, mint ahogy szeretném.
Ill. ez sem jó, de nagyjából közelít.

Azzal tisztában vagyok, hogy ha a megszakításban túl sok a futtatandó kód és/vagy túl sok a megszakítások száma akkor a kígyó előbb utóbb beleharap a saját farkába.

Az ADC kezelését eredetileg a főprogramban kezeltem, hogy a tmr0 ne legyen túl sok, de az meg feleslegesen sok analóg portfigyelés.

Szóval nem értem, biztos nem látom a fátol az erdőt, de már nem először futok ebbe a hibába. itt nem a Flowcode-ra gondolok, hanem magamra, hogy valamilyen tényezőt nem veszek figyelembe.

A konfiguráció eleve hibás, így biztosan nem lesz jó semmilyen időzítés. Belső órajelet használsz, de a Flowcode-ban nem írtad át a frekvenciát. Most 3 276 800 Hz-hez vannak számítva az adatok, de a belső oszcillátor ilyen sebességgel nem tud futni.

Build menü -> Projekt opciók... -> Órajel sebesség (Hz)

Itt kell beírni a valós órajel frekvenciát, amit az osccon regiszterrel lehet beállítani.

Az analog portra azért van szükség, mert a helyszínen nem tudok égetni és nem tudom megbecsülni előre azt az időt, hogy mekkora szűrési időre van szükség. Ezért az elektronikában oldottam meg azt, hogy ha szükséges tudjam növelni az időt.

Tegnap reggeltől 18 példányban élesben működik a panel, talán teszi a dolgát, de zavar, hogy nem tudom a megszakítást előre beállítani.

Van egy másik panelem, ami több hónapja működik 40 példányban, ott ugyanezekkel a problémákkal küzdöttem, azaz szoftveres filter idejével és egyéb késleltetéssel. Szintén nem túl tudományosan beállítottam (stopper, visszaszámol stb.).

Utána kell nézzek. Nem értem akkor az adatlapot.

Pár egyéb hiba:

A konfigurációban a PLL be van kapcsolva. Az adatlap szerint ez csak akkor használható, ha 8 MHz-es belső órajelet használsz. Igaz, így, ebben a formában mindegy a PLL kapcsoló állapota.
A konfigurációban a Low-Voltage Programming engedélyezve van. Ha az áramkörben nincs ICSP csatlakozó, akkor ezt inkább kapcsold ki.

A programban használsz Boolean (logikai) változót. Flowcode-ban nem túl szerencsés, hibákhoz vezethet, javaslom a byte típust. A program elején beállítasz pár változót. Ezt a lépést el lehet hagyni, ha a "Változók" részen eleve ezeket a kezdőértékeket adod meg. Kezdőértéknek 16 * 18 helyett egyszerűbb a 288 használata. Pl. az "EXTERNAL_TIME_SCALE_MS" változót 2500 alapértékkel hozod létre, de az első adandó alkalommal átírod 288-ra. "CALCULACIO" változónak nincs kezdőértéke. Igaz, ez nem nagy probléma, elvileg nullára áll be. "RED_LIGHT_MS" konstans csak egy helyen van használva, egyszerűbb, ha eleve értéket adsz meg a számításnál, felesleges ilyen esetben a konstans. Ha minden igaz, a fordító felismeri és egyszerűen behelyettesíti neked, tehát elvileg nem foglal extra helyet.
A programot érdemes egy kis késleltetéssel kezdeni, újraprogramozáskor könnyebb így vele bánni.

Segítségként mellékletben egy javított változtat. Konfiguráció javítva, órajel beállítva 4 MHz-re (C kód a program elején). Mivel így már a Timer0 nem fog egész frekvenciás megszakításokat generálni, beállítottam a Timer2 -t 25 Hz-re. Így kb. minden marad a régiben (a programot nem nagyon látom át) de a megszakítás pontos lesz.

Még egy kis segítség a mellékletben ahhoz, hogy érthető legyen, hogyan lehet beállítani az órajelet az osccon segítségével. A 0b az elején csupán azt jelenti, hogy az adat binárisan van megadva, tehát bitenként el kell zongorázni az értékeket (majd egy pontosvessző a végére). A kép a kontroller adatlapjáról van.

Ezzel a projektel (is) a legnagyobb probléma, hogy 1-2 nap alatt kell összehozni nyáktervvel mindennel együtt. Mindenféle tesztelés és fejlesztés nélkül, úgy, hogy csak ugatom a témát.

Az első válaszod szerint a belső oszcillátor nem tud ekkora sebességgel menni, az adatlap szerint sincs ilyen beállítás. De 4Mhz mehetne igaz? És arra kiszámítani az értékeket.

ICSP egyetlen nyákomon sincs, mert mindegyik már meglévő helyre kell beférjen, THT panelek, mert nincs lehetőségem (szerszám, kézügyesség) SMD-zni. Kikapcsolom a LVP-t.

Azt nem tudtam, hogy a Flowcode nem szereti a Boolean változót, bár feltétel kiértékelésnél már én is észrevettem, de nem értettem időnként furcsaságokat.

16*18 az már egy kínlódás miatti hülyeség, meg a kezdőértékben bennmaradt 2500-as alapérték. (Eredendően a fix értéket 500ms-ra, a változtathatót 2500-ra állítottam. Későbbiekben csökkentettem az értékeket, mert az eredeti rendszert oly mértékben lassítaná, hogy a kezelő emberek munkáját ellehetetleníti. A max. 2 másodperc is. Most kb. 0,3 secen mennek a panelek.)
A CALCULÁCIÓ változó is utólagosan került a rendszerbe, mert kapkodás közepette elkövettem olyan elemi hibákat ami tipikusak: egész számok halmazán beosztok egy számot, majd megszorzom (a maradék az osztáskor elveszik, és a kialakult hiányosságot még megnövelem egy szorzással, ami még nagyobb aránytalansághoz vezet.) Ráadásul úgy, hogy a helytelen változó méret kiválasztással túlcsordulást is okoztam.) Saját hülyeségemet kellett a szimulátorban megkeresnem, ezért az amúgy egyben megírt képletet szétbontottam.)

Ha ilyen jellegű programot írok, akkor a konstansba szoktam tenni azokat az értékeket, amik a tesztelés alkalmával módosulhatnak ( késleltetési idők, működési idők, stb). Könnyebb őket egy nagyobb forráskódnál megváltoztatni így, mit keresgélni és ellenőrizni, hogy mindenhol megváltoztattam-e.
Általában a teszt, vagy éles alkalmazás közben derül ki az, hogy ami időt, késleltetést, a "tervezéskor" megsaccol az ember, a valóságban nem működik.
Ennél a projektnél még ez is kaotikusra sikeredett.

Ez mit jelent?

A kapkodás a selejt szülőanyja! Ha nem adnak rá több időt, ne vállald el, mert a hibás működésű eszköz rosszabb a semminél!

Egy javított változatot feltöltöttem, próbáld ki azt. Az órajel beállításához is az előző hozzászólásomban ott a segítség.

A késleltetéshez: HP41C fórumtárs leírta a lényeget: Bővebben: Link. Ha késletetéssel kezdődik a program, a programozónak van ideje megszólítani a kontrollert, mielőtt a program esetlegesen megakadályozná a programozást.

Közben értelmezem a változásokat.

Nem tűnt fel, hogy a Flowcode ezt nem állítja be helyettem.

Egy a lényeg: Mindegy, hogy a konfigurációval és/vagy a regiszterekkel milyen órajelet állítasz be, azt a Flowcode-nak külön meg kell mondani minden esetben.