Ez azért van, mert csak 2 byte a soros porti buffer hossza. Az első két byte beérkezik, amit nem olvasol ki rögtön és bedugul a soros portod, mivel overrun hibával leáll, ha tele lesz mindkét buffere. Ilyenkor resetelni kell a soros port hardverét.

Én ezt úgy csináltam, hogy megszakításosan kezeltem a soros portot.
Tehát, ha beesik egy byte, akkor jön egy megszakítás és kiolvastam a byte-ot és átmásoltam egy tetszőlegesen hosszú bufferbe.
Minden <LF> beérkezése esetén megvizsgáltam, hogy hány byte van a tetszőleges hosszúságú bufferben. Ha több, mint 2, akkor a lezáró <LF> jött és ki lehet elemezni a beérkezett szöveget.
(Egyébként a <CR>, <LF> karaktereket kidobtam és le sem raktam a tetszőlegesen hosszú bufferbe, mert bonyolította az elemzést. Az elemzés után a tetszőleges hosszúságú buffer tele lett írva 0x00-val, hogy tudjam hol van vége a következő beérkező szövegnek)

Itt a kód:

Ha gépről küldtem neki hogy 0D 0A 52 49 4E 47 akkor a kijelzőn az jelent meg amit a csatolt képen látsz. De ha megcsörgetem a gsm modult akkor semmi nem érkezik be pedig kicsöng.

Rosszul írtam előbb mert GSM ről a képen látható "jelek" érkeznek.

a GSM modulénak nem két soros portja van véletlenül?
A számítógépen megnézted már a GSM module átküldött karaktereit?

Megnéztem ott ez jön CR LF RING CR LF. Ha gépről küldök adatot a picnek tökéletes. Látszik az előzőleg csatolt képen. A fura karakter a CR aztán már új sorba van a RING. De ha a GSM modult csörgetem meg akkor az a pár hülye karakter jön. Ha terminál programba nézem a GSM et akkor újsor RING újsor RING és így tovább. Tehát jó adatot küld.

Gondolom, hogy a GSM module 3V-ról megy, a PIC pedig 5V-ról. Lehet, hogy szintillesztést kellene alkalmazni?
Az RS232 kábel valószinüleg áthidalta a problémát eddig.

3.3V os PIC-et használok. Ha jól tudom ilyenkor nem kell szintillesztés. A GSM is 3.3V on megy ahogy írtad. Nem a 9 pólusú csatin kommunikálok a GSM el hanem a Tx Rx tüskéken ami ki van vezetve a modulból. Van egy USB soros átalakítóm ami tud 3.3V os UARTot azzal néztem a bejövő adatot mikor géphez kötöttem. Amúgy amit küldtem program az jó szerinted? Végülis egy ccs-es példaprogi.

Sziasztok!
Gondoltam, hogy közreadom az egyik nemrég megírt programom, mivel hasonlóval nem találkoztam eddig (nem jelenti, hogy nem is létezik...). A program lényege a Timer2 modul beállításának a segítése. Olyan programmal már találkoztam, hogy megadjuk az előosztást, utó osztást és a túlcsordulások számát majd a program kiszámolja, hogy ez milyen időközönként jelent megszakítást, de a fordítottjával még nem találkoztam, vagyis, hogy mi adjuk meg a kívánt megszakítások számát és a program meg megállapítja a leghatékonyabb timer beállítást. Ez a program mind a két változatra képes. Ha kérdésetek van vele kapcsolatban, akkor szóljatok. Még annyit, hogy .Net Framework 3.5 kell a futtatásához.

Köszi hogy közzétetted!

A használat közben észrevettem egy hibát, amit javítok, hogy ha ti adjátok meg a kívánt osztásokat és a program csak a frekvenciát számolja, akkor hibásan írja ki alul a szükséges kódrészletet, erre figyeljetek. Ha bárkinek van valami észrevétele a programmal, akkor írjátok meg. A javított verziót nemsokára közzéteszem.

Épp a CCSC-vel nyitogatok új projekt wizard-ot, ennek kiszotyizására, köszi. Nem lenne mód a többi timert kalkuláló megodlásra?

Ezért nem adtam még közre a javított verziót ebből, mert éppen a több timeres programon dolgozom. Még körülbelül 1 óra és közreadom a következő verziót, persze ha rendben fog futni.

Ahogy elnézem majdnem letelt az ígért 1 óra, így közzéteszem az újabb programot, amely már az összes (Timer0, Timer1 és Timer2) Timert kezelni tudja. Igyekeztem a program kibővített tudása mellett is megőrizni a kezelhetőségét. Ha bármi kérdés vagy kérés merülne fel a program használatával kapcsolatban, vagy valami hibát fedeznétek fel a működésében, azt nyugodtan megírhatjátok. Szeretném megjegyezni, hogy a Timer1 fordított számítása lassabb gépeken több időt vehet igénybe, mivel a programnak rengeteg opció közül kell a legoptimálisabbat kiválasztani.

Hasznos lenne még, ha a Timer2 mindjárt PWM frekvenciát is tudna számolni én konkrétan arra használnám, meg még sokan mások is szerintem. Valamint, ha átnyomod kereső módba, majd vissza a manuális beállításra, akkora keresésnél megmaradnak a keresett értékek, azok ilyenkor törlődhetnének, mert félrevezető is lehet akár.

Szia!
Köszönöm szépen az észrevételed. A keresett értékeket már átírtam, hogy ha üzemmódot változtatsz, akkor törölje a program. A PWM frekvenciát már csak holnap fogom beleírni, mára eléggé belefáradtam. (Holnap, azaz majd ha felkeltem ma reggel )

Hadd szóljon, én örülnék neki, akkor nem kéne a CCSC varázslójával szotyiznom.

Szuper. Én úgyis lusta vagyok számolgatni

Sziasztok!
Úgy gondoltam, belinkelem a program letöltési helyét és ha frissül, akkor is ugyan erről a linkről letölthetitek.
PROGRAM LETÖLTHETŐ INNEN
Ebben a verzióban helyet kapott a PWM frekvenciájának a számítása is, továbbá kivettem az előzőekben tárgyalt számolt értékeket. Továbbra is várom az észrevételeteket illetve a kívánságokat...

Na ez így már baba, most aztán tényleg nem kell szotyiznom a CCSC warázslóval, köszi.

Örülök, hogy tetszik a program, nagyon szívesen!
Amit még mindenképpen megszeretnék oldani, hogy átdolgozom az algoritmust, ami alapján keresi a lehetőségeket, mivel jelen állapotában ~520MB RAM-ra van szüksége (Ennyi számítást végez el, a program amikor megnyomjátok a keresés gombot...)

Űha most nézem, hogy csak a programot elindítva is benyel 1GB-ot

A hibát már javítottam, mellesleg ha minden rendben van a gépeden, akkor elindítva csak ~7MB RAM-ot szabad lefoglalnia.

Igen, de előtte volt keresve és azóta nem volt semmi ramigényes dolog indítva és ilyenkor újra tölti. Restart után nem lenne ilyen gondolom. De akkor már a javított van feltöltve?

Sziasztok!
Én is feltöltöm akkor a kis PIC-es segédprogramomat, igaz nem CCS-hez írtam, hanem C18-hoz és van benne elég sok plusz funkció, amit CCS-ben nem éri meg használni, de a timer számításokhoz jól jöhet. Amúgy egy USB-s PIC-hez csatlakoztatva (igazából 18F4550-hez készült) a program felismeri a kontrollert és képes is azt real-timeban vezérleni (Timerek, PWM, Interruptok, Portok) és monitorozni (ADC, Portok), tehát kb. egy futás idejű programozást valósítok meg vele, nem kell állandóan fordítgatni és beégetni a módosításokat.
Kétféle számítás van a timereknél: vagy a preload regiszterek alapján számol frekvenciát és periódusidőt, vagy fordítva; a frekvenciából, illetve a periódusidőből számolja ki a preload regiszterek értékét (a prescalert kézzel kell bekattintgatni). A jobb alsó sarokban mutatja a freki és a periódus minimum és maximum értékét, amik értelemszerűen a prescalerektől is függenek.

Szia! Miben írtad a programot?

Sziasztok!

Hasonlót én is készítettem Mplab X alá, egy timer kalkulátort és egy bit konvertert.
Telepítése: Mplab X elindít -> Tools -> Plugins majd a Downloaded fülön az Add Plugins..
gombra kattintva megadni a kicsomagolt nbm kiterjesztésű fájlt.

Szia! Microsoft Visual C#-ban.

Kösz!

Sziasztok!

Szeretnék segítséget kérni egy kód részlet megértésében. Dempsey feltett 14.-én egy programot amit nézegettem és ez a rész nem világos számomra:
#define bkbhit (next_in!=next_out)

BYTE bgetc() {
BYTE c;

while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
Megkérhetek valakit hogy kommentezze vagy magyarázza el az egyes sorokat.
Köszönöm.

Szia!
1. #define bkbhit (next_in!next_out)
Egyszerű definíció bkbhit ezentúl egyenlő (next_in!=next_out) szöveggel
2. while ciklusból csak akkor van kilépés, ha nem igaz bkbhit ,azaz ha next_in =next_out-al. Itt kettős tagadás van.(next_in valahol globális változó)
3. C változó felveszi a bufferből a next_out értékének megfelelő számot. (next_out egy tömbelem mutató)
4. Ezután a tömbelem mutató felveszi a következő hely címét, majd eloszódik a tömb méretével, és annak a maradékát veszi fel értéknek. Magyarul mindegy mekkora a tömb, amikor a végére ér, kezdi a címzést elölről.
üdv.: Foxi
5. A függvény visszatér a tömb valamelyik elemével.