Szia! Ezért mondjuk mindig, hogy proteussal kell tesztelni.

Elég nekem egy is ebből!
Ennek ellenére hasznosnak tartom, megmondom miért!
Régen nem készítettem folyamat tervet egy programhoz, lusta voltam rajzolni, sokat radírozni, stb, inkább nekiálltam(C, asm), aztán olyan lett ami belefért a fejembe.
Most azt hiszem arra fogom használni a Flow-t, hogy ilyen terveket készítsek. Például nagyon jó menürendszert lehet vele készíteni, amit könnyen át lehet látni és utána át lehet ültetni más nyelvre! Tényleg hasznos, annak is ajánlom, aki nem használja a Flow-t igazi programozásra! Valószínű én sem fogom, csak a háttérben esetleg, vagy egy gyors LCD-s tesztelős témához és valójában lesni is lehet a C fordításokból! pl. Egy jó kis kirándulás volt, sok haszonnal!

Szia még vagyok egy kicsit. A flowcode alap cuccok között volt egy egyvezetékes megoldás de ott teljesen más a felépitése ami ráadásul nem müködik, A héten megprobálok eljutni addig hogy felprogramozzam a te megoldásod és reménykedek hogy menni fog.

Szia !
Még hozzá tartozik, hogy a LED...gomb..stb makrókat el kell felejteni és csak az I/O-at használni. Jártam úgy gomd makróval, hogy fordítás után egy logikai változónak 2 értéket adott vissza 1 helyett

Van neki fóruma, vagy legalább valami magyar nyelvű ismertetője? Feltelepítettem, de ez nekem kínai.

De azért nem hagysz el bennünket?!

Itt van neki a fóruma És a Matrix multimedia oldalon (angol nyelven)

Proteusra gondoltam.

A gondolatolvasás nekem még csak közelről megy , sajnos a távolság gyengíti a képességeimet . Egyébként a proteus nak is van itt témája

Valószínűleg nem!

Azt írja a típus deklarálás fájlban, hogy platform függően MX_UINT8, azaz unsigned char típust használ boolean-nak, azaz egy egész bájtot foglal le egy bit helyett. Egyszerűbb kezelni, de nem túl szép dolog egy PIC-el szemben, aminek mondjuk 82 bájt RAM-ja van!

Ez az egyvezetékes cucc mit csinál hogy ekkora helyet foglal? Lehet hogy maradok az LM335-nél, kicsit kevesebb helyet foglal beolvasásra. Vagy ha több ds-t rakok egy bemenetre akkor kevesebbet foglal?

Sziasztok! Elakadtam, nem veszem észre, hol rontom el... Hátha több szem, többet lát. Egy PIC kommunikál RS232-ön keresztül GSM modullal. A PIC-ből tudom az AT+ parancsokat szépen küldeni a GSM modulnak. Az teszi is a dolgát, ahogyan kell. Válaszol is, a végrehajtott parancsok után. Ezt a kommunikációt egy MAX3232 modullal és ClearTerminal-lal látom is! Viszont a válaszokat valamiért nem olvassa a PIC, pedig azokat is szeretném feldolgozni! Nem értem, miért nem? A tesztpanelemben nem lehet a hiba, mert egy másik PIC-et téve bele, akkor jól kommunikál egymással a két eszköz, s azt az adatfolyamot is látom. Tehát valahol a programomban a string olvasással és időzítéssel van hiba... (A GSM modul kb. 50-60 ms késéssel válaszol.) Boldog Karácsonyt Mindenkinek! Üdv! fatti

Igen, ha többet használsz egy vezetéken, akkor kevesebb helyet foglal, mint ha külön lábakon használnád.

Egyszerűen lemaradsz róla az 1sec várakozásal! Ha tudod, hogy venni kell valamit, akkor vagy várakozol a vételig(működik, de rossz megközelítés a legtöbb esetben), vagy RX megszakításban kezeled le a vételt.

Köszönöm az ötletet! Várakozok a vételig: Nem működik, hiába írok az első paraméterbe 0-át és nincs várakozás. A string üres maradt. Vagy növelem a méretét, ki tudja meddig azért a pár karakterért. Mint ahogy írtad, "rossz megközelítés..." RX megszakítás: Így minden választ le kell kezelni (string műveletek az RX megszakításban?), pedig csak 3-4 parancs válasza lesz fontos, a többi hulladék. A programban lesz később egy TMR0 megszakítás is. E kettő nem fog összeveszni? Ezért a delay utasításokat is próbáltam már kiváltani, mert az meg a TMR0 megszakítást nem viseli. Vagy elhagyom a TMR0-át is és helyére mással (GSM_DELAY makró) üttetem el az időt a CPU-val. Szóval kezd kicsit elbonyolódni a helyzet! Azért próbálkoztam azzal, amit mondtál, de amit a terminál ablak így mutat, az egy kész káosz. Karácsony van... Mára unom már az agyalást! Üdv! fatti

A megszakítások nem ütköznek, ha csak kevés időt tölt benne a program. Várakozni tilos megszakításban. Vételnél mindent venni kell és csak azt feldolgozni, ami érdekes. Ha stringbe veszed, nem okoz gondot. A timeout értékét ha jól határozod meg, még azt sem kell tudnod hány karakter fog jönni, feltéve, ha a két csomag között nagyobb az idő, mint a timeout. Nem kell semmivel időt elütni, ennek működnie kell úgy, hogy még egy csomó minden másra is jut idő.

Köszönöm a iránymutatást! Megyek abba az irányba... Ha leküzdöttem egy-egy mérföldkövet, akkor szívesen megosztom a tapasztalatokat, s persze a végeredményt is. (Ami néhányunknak fog alapot és fejlődési irányt mutatni!) Ahogyan ígértem! De azért ne menj nagyon messze, mert a tanulás útja kicsit göröngyös szokott lenni, s egy-egy pánikhelyzetben jól jönnek biztató, oktató szavaid! Üdv! fatti

Láthatod, hogy ha nekiálltam volna mindent kifejteni, könyv lett volna. Ettől függetlenül szerintem meg lehet érteni a feladatot, a megoldásokat pedig ahogy írod, lépésenként. Ha lesz konkrét kérdésed, akkor tedd fel! Ha lesz kis időm összedobok egy RS kommunikációt...

Itt van egy példa 18F2550-re, de bármelyik PIC-en működnie kell. A gomb kezelése csak teszt, korábban tettünk fel jó példákat, abból érdemes kiindulni.
A Timer1 csak akkor működik jól, ha kikapcsolod a külső oszciját, amit hibásan bekapcsolva hagytak a fejlesztők. Ezt a C-kód szerkesztésében is meg lehet tenni( cr_bit(t1con, T1OSCEN); ), vagy véglegesen a 18F2550.fcd fájlban(Illetve a kiválasztott PIC hasonló fájljában)!

Szia! Köszi a jó példákat... Nekiláttam kérdezni a google-t. Mit mondanak erre a "szoftvercégnél" + akárhol? EB066, EB463, EB647, és CD ROM230. Ezek a gyári oktatócsomagok és hardverek. Sajnos az egész Cd-t nem találtam sehol! (Gondolom ezt azok kaphatják meg, akik beülnek az órákra ...$... Ha valakinek megvan, ne kíméljen!) De azért összejött a témával kapcsolatosan egy 20MB-nyi pdf meg fcf. Ezek közül a legígéretesebb kettő példát ide teszem mindenki számára, aki neki akar menni egy SIM900-nak! Amire rájöttem magamtól is, az ezekben benne van. Viszont, itt az RX adatokat karakterenként szedik össze, nem pedig egyből stringbe olvassa, ha jól látom. Ha meg várni kell valamire, akkor mintha az adatok olvasásával töltetné az időt?!? Ez már majdnem egy kész GSM telefon! Kár, hogy hiányos. Ebből részleteket másutt is leltem, olyat amiben egyben lenne minden, olyat nem. Üdv! fatti

Nem hiszem, hogy fogsz találni kész programot, nincs két egyforma, így olyan se lesz ami neked kell. Abból amit küldtem meg kellene tudnod oldani a feladatot, miután a szükséges adatcsomagot be tudja olvasni, utána csak kezelni kell.
Mindegy mibe teszed, karakter (string), vagy byte tömbbe, csak a lekezelése változik, az értékek ugyanúgy ott vannak. A módszer működik a példa szerint, teheted bájt tömmbe is, csak akkor másik blokkot kell válassz és le kell kezelned a bájtok számát is, azaz indexet kell használnod.

Azt, hogy a GSM modul mit szeretne, azt neked kell tudnod, úgy kell tenni, ahogy az adatlapban le van írva, de ez nem Flow kérdéskör.
Itt a hogyanról lehet szó, de hogy mit kell kivinni, beolvasni, az nem Flow téma.

De ha már itt tartunk... A FlowCode v5-ben az "általános" legördülő fülben van egy olyan elem, hogy "GSM". Ez gondolom egy GSM telefont akar szimbolizálni. A megjelenő komponens makróban meg szinte az összes szükséges parancs előre elkészítve ott van. A csatlakozása az már más. CTS és RTS vonalakon megy. A kérdés meg az, (itt ezzel összehasonlítva az előbb említett RS232 kommunikációt) hogy ez miben különbözik attól, amivel én birkózom? Nem lenne még egyszerűbb ezzel az elemmel megoldani ezt? Üdv! fatti

Szia! A CRC egy kiszámolt érték, ami ebben az esetben 8 bites, azaz egy bájtos. Létezik 16bites, ezt pl. a MODBUS használja és több bites is, az adatok méretétől és mennyiségétől függően. Arra jó, hogy egy átvitt adatcsomagról meg tudd állapítani, hogy sérült-e, azaz egy hőmérő esetében ilyenkor nem érdemes a kiolvasott értéket kiírni, használni, várni kell a következőre.

Nem használtam még a GSM blokkot, eszembe se jutott, hogy van. Nem tudom, hogy illeszkedik-e a modulodhoz, ezt te tudod kipróbálni.

Szia! Igen... Ezt említettem az előbb. Ez az EB066. A kapcsolási rajzától kezdve a leírása, minden ott van. Sokat tanultam belőle! Gondolom ehhez találták ki az előbb említett GSM blokkot a FlowCode újabb kiadásaiban. A kapcsolási rajzot nézve ott a CTS RTS vonalak is be vannak kötve. Azt nem értem vele kapcsolatban, hogy amikor a Flow-ban csatlakoztatni szeretném a PIC-hez, engedi, hogy ezeket a vonalakat bárhova is kössem. Kikerülve az adott pic USART- portját. (Ez azt súgja nekem, hogy szoftveres lesz az USART... RX-TX??? Az talán nem is kell neki?) Vagy... Értelemszerűen a megfelelő lábakat a megfelelő lábakhoz, ahogyan azt az adott-vett adatok iránya adja? Ha ezt el tudnánk dönteni, én kipróbálom! 5 percembe sem kerül pic-be írni egy két parancsot s a terminal ablak mutatja mi történik... Üdv! fatti

Érdekes, hogy úgy akarsz soros kommunikációra programot írni, hogy nem ismered a működését! A CTS, RTS vonalaknak közvetlenül semmi köze nincs a TX, RX vonalakhoz, azokat kiegészítik, úgynevezett kézfogásos kommunikációt megvalósítva. Biztosan felkészültél ilyen bonyolult feladat megoldására?

Igen! Ezt tudom! De azt nem, hogy látszatra miért akar 4 vezetéken kommunikálni, amikor ehhez kettő is elég lenne? RX-TX. OK ennek a blokknak 4 kell. Egy próbát megér... Üdv! fatti

Hello
Vannak valakinek tapasztalai Flowcode-ban irt programmal ami pic18f4550 és USB közti kommunikációt tesz lehetővé, esetleg valami példa program?