Találtam hozzá online könyvet is. Le is mentettem. De paritásbitet itt sem látom hol lehet állítani.

Köszi a programokat, megkaptam. A Mikrobasic programot ismerem. Fel is van telepítve az otthoni gépemre. Van egy pascalos verziója is. Asszem csak a szokásos 2k bytos korlátozás benne. Nem igazán nézegettem még a tudását, de most már megnézem. Tegnap a Portmon-nal tanulmányozgattam tovább a Logomanager és a mobil közötti kommunikációt. Én is arra jutottam hogy nem lehet figyelmen kívűl hagyni a mobil válaszát. Sőt amikor ACK üzenettel kell válaszolni, akkor a sorszámra is szükség van. A mikrovezérlőnek ki kell számítania a mobil által küldött üzenet ellenőrzőösszegét és ebből tudja hogy az üzenetnek vége. No és persze ott vannak az üzenetek közötti késleltetések, amit csak saccolni lehet. Állítólag max. 1/2s. Egy külföldi fórumon olvastam.

A Mikrobasic-ben, meg akármilyen más fejlesztő környezetben megírt programot le tudod szimulálni a Picsimulator-ban, bár szerintem már rájöttél.
Azthiszem az újabb Nokia-k ismerik az AT parancsokat. De hogy milyen buszhoz csatlakoznak!?

Az üzenetek közötti késleltetéssel annyira nem kell foglalkoznunk. Bejövőnél figyelni kell mikor jönnek olyan byte-ok, amik 1E-vel vagy 1F-el kezdődnek, protokoltól függően. Ha küldünk, akkor meg legfeljebb belerakunk még valami delay-t.
Az ellenörző összeges dolog nekem nem világos teljesen, szerintem nem abból tudja a PIC hogy vége az üzenetnek. Mert szerintem az ellenörző összeg lehet két külömböző hoszú üzenetnél is egyforma. Az nem jó megoldás, hogy jönnek a bytok, azokat XOR-olod egy reg.-be és ha olyan jön byte jön következőnek, ami pont a XOR regiszteredben van akkor vége az üzenetnek. Mert lehet az üzenet kellős közepén is olyan byte és akkor nem jó úgy.
Szerintem ezt valahogy az üzenet hosszából kell számolni.
Szerinted egy előre megírt sms-küldő framet lehet használni? Vagy abban is van sorszám és az is minden sms küldésnél változik? Láttam a neten valami gnokii nevű projektet. Belenézek hátha van benne használható infó. Meg nekiállok egy nagyobb PIC-el megcsinálni a kapcsolást.

Igazad van az ellenőrző összeggel kapcsolatban. Lépésről-lépésre kellene felépíteni a programot. pl:Elküldeni egy D1-es mobil info lekérő parancsot és figyelni egy Pc-és monitorozó programmal hogy mindig úa. a sorszámú választ küldi-e vissza. Azt hiszem ezen a szálon indulok el. Közben az ellenőrző összeggel kapcsolatban eszembe jutott. Mégis csak hasznos. Annak, hogy frame közepén találunk egy olyan értéket, ami mégsem az ellenőrző érték annak kicsi az esélye, bár nem kizárható. Szóval jó lenne egyértelműen behatárolni a bejővő üzenetet. Na mindenesetre először az első egyszerűbb verzióval próbálkozok. Tegnap kicsit a LookRS 232 programmal ingereltem a mobilom. D0-ás és D1-es parancsú frameket küldtem neki, de nem reagált semmit. Úgy tünik 16 bytos csomagokban küldi ki az adatokat, ami nem tetszik a mobilnak.

Nézegettem már néhányszor én is a gnokii forrását, de nem igazán tudtam belőle értelmeset kihozni. C-ben írta, ami nekem magas.

Ja meg C++6-ban be akartam fordítani a forrását, de hiányolt egy file-t, így az exe-be fordítás nem sikerült.

3-mal feljebbi hozzászólásomat módosítom. Nem 16 byte , csak 16 bit.

Én szerintem az FBUS vonalon fogok haladni. Jóval egyszerűbb, mert jobban hasonlít a szabványos soros kommunikációra, azonkívül full Basicben lehet írni. Csak egy teljes verziós mikorBasicet kell keresnem. Amúgy a Lookrs 232-vel én sem tudtam MBUS-on keresztül megszólaltatni a mobilt.
Megcsináltam a 3 Byte féle égetőt a 16F877-esnek (40 láb) és működik is rendesen. Abban legalább van hely a progrmnak. Délután összehozok egy max232-es kapcsolást is 20 MHz-en, hogy tudjam tesztelni a pic programot a telóval. Aztán majd nekilátok az FBUS parancsokkal és framekkel szarozni.

Kész lettem a hardware USART-al de valahogy nem akarja azt csinálni amit én mondok neki.

Tegnap alaposan áttanulmányoztam a mikropascal-t meg a mikrobasicet de szerintem itt sincs lehetőség a paritás beállítására. Általában nincs is szükség a paritásbitre. A miénk az egy különleges eset. A LookRS232 valamelyik menüjében sikerült beállítanom az egyszerre elküldött byte-ok számát, átírtam 30-ra. A Portmon regisztrálta is hogy a frame küldés folyamatos. A mobil még sem válaszolt. A microbasic RS232 moduljából is próbálkoztam frame kiküldéssel de a Win98 súlyos védelmi hibával válaszolt.3-szor próbálkoztam, aztán feladtam. Belefogtam én is végre a program írásába, de még egyenlőre nem tudok eredményt felmutatni. Túl sok időt elcsesztem a Mikrobasic tanulmányozásával. Ja a Pic16f877-ben van hely bőven csak egy kicsit nagydarab. A kisebbik tesója, a Pic16f876, negyed akkora. Igaz kevesebb portja van, mint a 16f877-nek. De a 16f627,628-nak is van hardveres USART-ja. Én azért tettem le ezek mellett a voksot mert méretileg is aprók.
Köszi az anyagot. Majd csak a meló után tudom átnézni. Engem is érdekel az FBus kommunikáció is. Csak az MBus-t könnyebb megfigyelni. Utánna meg jöhet majd a gyorsabb FBus. Ámbár eddig még minden működött a valóságban is, ami jó volt a szimuláláskor.

Én azért egy 16F877-essel csinálom, mert volt itthon elfekvőben egy elrontott ICD2-ből. De ha majd kész lesz a program át lehet rakni akármelyikbe. Viszont nem igazán értem a HW USART miért nem akar működni.

Rájöttem mi a rossz, de fogalmam sincs hogy lehet kijavítani. A HW UART 115200 helyett csak közelítő értéket tud előállítani, de ezzel nem akar igazán működni a dolog. He elküldök egy karakter, és a PIC-el vsszaküldetem akkor rossz karakterek jönnek vissza.
Pedig a neten is mindenhol ezeket a beállításokat lehet látni. Úgy tudnám megoldani ha 20Mhz- helyett 20,735Mhz lenne, de nem hiszem hogy van ilyen kristály.

Hát ez nem túl jó hír. Ez a külöbség túl nagy ahhoz hogy el lehessen hangolni. Esetleg CMos IC-ből kellene megpróbálnod összerakni valamilyen oszcillátort, de ennek nem lesz túl stabil a frekvenciája. De egy próbát megér. PL.4011-essel v. 4001-essel. Nincs jobb ötletem.

Hát...mindenre van megoldás. Lehet kapni olan kristályt, amivel tökéletesen pontosan 115200 lesz a baud rate mikorBasic-el. Vettem is 3 félét, kb 400 Ft-ból.

Ezek azok:
11,059200 Mhz
14.745600 Mhz
18,432000 Mhz

Mind simán kapható akármelyik elektronikai boltban, mert ezek direkt ilyen mikrokontrolleres baudrate generáláshoz vannak kiszámolva.

Hááát erről még nem hallottam.

Király, a 11 Mhz-essel tökéletesen működik

Csináltam egy excell táblázatot én is FBUS-hoz. Benne van egy általános FBUS fram-nek a leírása, potmon-al megfigyelt kommunikáció a LogoManager és a teló közt üresjáratban, 2 db sms küldés, mindkét küldés framjei kirészletezve, és az ACK parancs generálásának részletei.
Szóval nagyjából minden amit tudok az FBUS frame-kről. Az sms frame nálunk máshogy van összepakolva, mint a belinkelt embedronics weblapon. Pár dolgot nem sikerült még kibányásznom belőle. Elküldöm e-mail-ben. Elég szép munkát végeztem, büszke vagyok magamra

Gratulálok ! Érdekel az FBus is. Több kommunikációs progit is loggoztam portmonnal és más-más eszközszámokat küldenek. Klassz anyagot küldtél. Ráismertem az MBus kábel kapcsolásomra az egyik képen. Csak a következő változtatásokkal:
Tx,Rx láb 270 ohmos ellenállásokkal bekötve. Telefon becsatlakozásnál 2,7V zener. És hogy működjön meg kellett táplálnom 7V-al.
Klasszak az FBus/MBus leírások is. Most esett le hogy FBusnál nincsen paritás, így elvileg mikrobasic-ben is írhatod. Nem találtam meg, hogy mennyi lehet a maximális baudrate-je.
Az FbusV2 protocol.html-ben hangsúlyozza a szerző a sorszámozás fontosságát. FBus-nál 40-47 terjed a PC által küldött üzenet a telefon válaszüzenete meg 0-7-ig. Ilyen fajta logikában 40->00;41->01...Az MBus-nál kicsit más a logika, de az is valami hasonló. Még nem értem pontosan. Legalábbis az értékhatárait nem.
Küldtem neked hasznosságokat. Ajánlom figyelmedbe a 16f62x.pdf 74.oldalán a baudrate hibaarányokról való
részt. Egyébként tegnap a TXSTA regisztert molyoltam. Hátha így könnyen letudom a basic progi módosítását. Muszály megoldanom ezt a paritás kérdést. Még szerencse hogy a Microchip gondolt erre és az úgynevezett 9. bitet fenntartotta erre a célra.
Találtam egy gyanússágot a Picsimulator hardveres USART-jában. Léptetve futtattam végig a programot és
a MOVWF TXSTA utasítást a felső ellenőrző ablakban MOVWF 0x18-nak jeleníti meg a MOVWF 0x98 helyet.
A 0x18 az a RCSTA regiszter. Nem tudom hova tenni a dolgot. A baloldali regiszter ablakba már jól
mutatja az érték változásokat.

Hi!
A sorszámozás a tök világos nekem. A táblázatból jól látszik a szabály. Meg az első oldalon az általános fbus frame leírásnál is odaírtam. Egyébként meg olvastam egy angol fórumon, hogy általában az is működik, ha a telefontól kapott sorszámot küldöd vissza, mert a telefon ugye eleve jót küld neked.
Meg szerintem az ellenörző összegekkel sincs gond ha előre rögzített üenetet küldessz, mert az üzenet elejére előre kiszámolod a két ellenörzőt, aztán mikor a sorszám megvan, akkor azzal módosítod a páros ellenörződ, ami egy darab 8bites XOR művelet lesz, nem kell az összeset végig xorolni.
Aztán van még az ACK üzenet, ami a leírásomból megint tök világos. A bejövő üzenetet pedig nem az ellenörző összeggel kell figyelni, hanem a frame elején ott van az üzenet hossza, ezt kell számolni, és az utolsó byte pedig 0x01 (páratlan hossz esetén 0x01 0x00) ezt is lehet figyelni ellenörzésnek. Ha pedig az ellenörzők is jól jönnek ki, akkor biztosan jó volt a vétel.

(Nem tudom hogy ennél az adatátviteli sebességnél mennyi idő van számolgatni, lehet hogy inkább egy 18 Mhz-es órajelet használok majd)

Találtam egy anyagot neked, azt hiszem van benne leírás erről a 9.bitről, meg paritás dolgokról, előkeresem.

Ja a gnokii c forrását megnéztem és a cheqsum, a seq number ott is így van kiszámolva. Majd még nézegetem, hátha egy két parancsot ki tudok bányászni belőle, mert a neten nincs normálisan leírva sehol.

Hi! Van egy jó hyrem. Tudom hogy kell HW USART-al paritásbitekkel kommunikálni. És mikroBasic-ben simán lehet írni. Annyi az egész, hogy a TXSTA.6 bitjét kell 1-be állítani, ami a 9 bites kommunikációt engedélyezi. Utána Pedig a TXSTA.0 bitbe beírni a 9. bitet. (Lényeg hogy még mielőtt a küldendő adatod a TXREG-be írnád ez megtörténjen.)Ezután mehet az usart_init() basicben. Persze előtte paritást kell számolni, de azt gondolom tudod hogy kell.
Kiolvasással még nem szaroztam de a pdf-ben amit küldtem benne van az is. Ezt is onnét szültem ki.

Jössz egy sörrel

Előbb-utóbb csak összejön ez a progi.A paritás problémát Picsimulator forrásában a TXSTA register manipulálásával próbálom megoldani, oly módon hogy minden karakter előtt maszkolom. Még nem próbáltam ki a Pic-ben. Majd délután.
Az MBus-nál kicsit zavarosabb a sorszámozás mint az FBus-nál, de nem lesz gond megoldanom.

Amint látom ugyanarra az eredményre jutottunk. Amitől tartok hogy ez kihatással lesz a baudrate pontosságára és ráadással minél nagyobb a baudrate annál nagyobb a pontatlanság. Majd délután kiderül.

Ja a pdf-ben olvastam én is. Valahol ott mutatja az alkalmazott kvarcok és baudrate hibatáblázatát is.

Kónya féle pdf-ben pedig RS232-Pic-re klassz hardveres megoldásokat.

Nem értem miért akarod te a paritáshoz maszkolni a txsta-t. Csak ennyi az egész paritás téma, páratlan paritásra nagyvonalakban (pl egy darab "N"=0x4E küldésére).
CHAR = 0x4E //N karakter kódja
PARY =1 //páratlan paritás miatt
for i=0 to 7 do (
if CHAR.i=1 then PARY=PARY+1
i=i+1) //megszámolja az egyeseket
TXSTA.6=1 //9 bites mód
TXSTA.0=PARY.0 //9.bit a paritás
INIT UART(9600) //inicializálás
WRITE UART(0x4E) //küldés

Tehát ha először kiszámolsz mindent, a küldés sebeségét nem befolyásolja.
Csak a 9 bit küldése kell hogy adott baud rate-en történjen. A karakterek közt várhatsz akármennyit elviekben, mert akkor a a stopbit 1-ben van és a következő karakter adását úgyis majd a 0-ás stratbithez igazítja majd az uart.
Másrészt 9600 b/s nem olyan hú de gyors hogy ne legyen idő pl egy 18 Mhz-es órajellel kiszámolgatni mindent.

Én assemlyben gondolkodtam, manuális módszerrel.

MOVLW B"01000001"
IORWF TXSTA,1
MOVLW 0x41 ;"A" karakter
CALL HS01
MOVLW B"01000000"
IORWF TXSTA,1
MOVLW 0x43 ;"C" karakter
CALL HS01

Mindkét módszert kipróbálom.

Megnétem az MBUS log file-odat mégegyszer.
A rózsíszínnel jelölt csíkod az sms küldő parancs, csak rosszul van beállítva a portmon programod, és nem logolja az egészet. Állítsd át legközelebb a Max Output Bytes-t mondjuk 1024-re. Akkor mind a 60-70 hex karakteredet logolja.