Mechanikai hiba.


Mégiscsak kelene bele egy hibakezelés. Pl. egy flag hatására kilépne a beragadt beolvasás rutinból. A Flag-et az impulzus megszakítás állítaná be, ha abba a megszakításba, a soros megszakításból érkezik a program(ezt egy másik flag jelezné), mert az azt jelenti, hogy beragadt a beolvasásba. Ha ez flag érvényes a beolvasásban, akkor kiléptetni onnan. A következőkben tiszta lappal indulna a kör. Elszórt hibákat észre sem lehetne venni.

A sebességet aztán sikerült fokozatosan állítani? A Delphi programba sikerült beleintegrálni a soros rutint? Abból próbáljátok?

Hi!

Mukodik a dolog, csak meg nemi finomitgatas kell hozza.
1) A PIC egy ido utan kihal. Nemtudom mitol lehet.
kb 10-20 erteket kuldunk ki 1 mp alaatt, tehat elvileg nem lehet gond. Egy darabig megy, aztan beragad egy RX_OK -nal, ha jol emlexem a 3.-nal.
Porbaljuk magasabb baudrate-el.
2) Ha jobbra kormanyzok, es vissza kozepre, majd balra , vissza kozepre, akkor a kozep e ket esetben nem ugyanaz lesz. Nem huzza vissza teljesen kozepre, ha balrol ter vissza, kicsit balra all, ha jobbrol ter vissza, kicsit jobra all.

A hiba az ADCON1 regiszter beallitasaval volt. nemkell bele a sok 0.

Én is.

kuldtem levelet

Pesten vagy? (ha igen akkor én 50Km-re vagyok. Vonat?)

nincs autom check priv mail pls

Nálam miért nincs gond vele?

Van autód? Nem kéne összefutnunk? Nem hiszem, hogy így menni fog....

hat ha az irogep mukodik, akkor el. atraktam masik gepre, ott is ugyanezt mutatta.

Már kérdeztem, de nem válszoltál lacc: a hardverrel minden ok? Biztos elmegy a soros portról az adat a PIC - ig?

osszefoglalva, mukodik, ha

van. ilyenkor soros nem. Ha retfiet kiszedem, es helyette

akkor kerek oldalrahuz. (vb mindaket esetben kiirja a ket sort)

irogeprogival minden rendben, ott vilagit a led, ahol szeretnem.

szerintem evvel a high-low cuccal lesz gond nem? ha sorosat highre rakom, akkor vb progi sem mukodik. pedig a 82-t kene akkor is kuldje nem?

Ez "természetes" mivel eddig is a periódust előállító programrész küldözgette szorgalmasan a 82-őket. A VB progi nem tudja, hogy mit küldenek és honnan, csak veszi és kiírja amit kap akkor, amikor a gombot megnyomod.
Nézted már a VB progi forrását? Abból minden kiderül!

A HTerminalos próba során a LED kigyullad? Nem értem, hogy hogyan működhet az írógép progi, mikor ez meg nem fut be a megszakításba!? Itt valami nagy árulás lesz.
Küldjél a PIC-be valamit a HT-ből és nézd meg a ledet a megszakításba! Mi történt? *** lekéstem látom már válaszoltál)

Viszont akkor lövésem nincs, hogy miért nem okoz megszakítást egy elküldött adat. Nézd át a megszakítás beállításokat, jobbat nem tudok. Próbáld ki újból az írógép progit, de most LED-et is tegyél "bele".

kiszedtem a timer1 megszakitasat, meg kikommenteztem a high-ben levo timer1 kezeleset. msot nem csinal semmit vb progi.
megjegyzem, mikor nincs bedugva a taviranyito, vagy kikapcs, akkor sem csinal semit.
Ha csak a mianbol szedem ki a timer1 megszakitas engedelyezest, akkor sem csinal semmit vb progi

berakom a soros megszakitast high prioritashoz, ipr1,5 - 1 be, es igysem csinal semmit. hipertrm sem.

Na már jó! Vágom, erre gondoltam én is. A PIC mást sem küld mint 82-őket, ez van. Ha lenne VB felöl adás, akkor a PIC-ben megszakításnak kellene keletkeznie, ami a LED-es próba szerint nem keletkezik. Nehezen hiszem, hogy a PIC a hibás(remélem nem). Inkább a VB-re tippelnék. Aztán most már a fene tudja mi a baj. A végén majd úgy is kiderül, hogy valami nagyon egyszerű dolog szívat minket!
Mindenképpen ki kell próbálni, hogy a VB progi kelt e megszakítást a PIC-ben! Terminallal is kell próbálkozni. Addig le kell tiltani az impulzusokat is. Csak a soros kommunikációt hagyd meg.

nalam mukodik. probald kisbetuvel a vb.jpg-t. igy nekemsem ment
de ez van rajta:

ido PIC-tol:82,82
PIC-nek kuld: 1,2

A kiszolgálóddal valami gond van, mert nem működnek a linkek?!

Szerintem rosszul, mert ha lenne küldés akkor lenne megszakítást, és a válasz magától menne. A küldés biztosan jó, mivel a 82-ők jönnek.

nemtudom hol irtam
mind1. printscreen:
http://lacc.uw.hu/download/VB.JPG
Elvileg kikuldi amit beirok. csak vissza mar nemkapja, mert nemkelt megszakitast. Vagy rosszul gondolom?

Hol is írtad? Te azt írtad, hogy Veszi a 82-őket, de ebből nem derül ki, hogy ad-e bármit is ki.

Má mé? Beírsz két betüt egymás után és kész. Az AT parancsokat akkor hogy lehetne elküldeni mobilra?

Szerintem nem szerencsés nagyon megváltoztatni egy olyan programot, ami működik. Itt biztosan nem a PIC-el van a gond, ha az a LED amit írtál nem világított. Egyszerűen nem jön megszakítás, tehát nincs adás a PC-felől. A VB már megtréfált néhányszor, ezért szerintem írd meg azt a Delphi progit minél hamarabb, mert azzal működnie kell! Az írógép progiból indulj ki, ha azzal műkszik, akkor azt tovább lehet fejleszteni a kívánt protokoll szerint.

Azért a Hypterminalos próbára kíváncsi lennék!

a VB progi kuldene a valaszt! irtam. Csak eppen nem keletkezik vhogy megszakitas.
hipertrm-rol meg egyszerre 1 karakter tudnek kuldeni, vagy ha kettot is, gyorsba kell nyomjam. nemmukodik, probaltam mar...

betettem a

sorokat a high int kezeleshez, es ipr1,rcif -et 1-be raktam, hogy az is high legyen. bsf led-et beolvas-ba raktam. Led vilagit, pedig meg nem kuldtem ki semmit sorosra VB-bol. Ha pedig a pic kuld ki, akkor meg nem kellene hogy vilagitson. szimulatornal nem ugrik bele a soros vonal kezelesebe.

a link:
http://lacc.uw.hu/download/megszakit.asm


gyalog?
mint irtam, ugy mukodik, ha kiveszem a sorosat. inibe irkalom az ertekeket, es franko.

Ezek szerint a VB progi nem érzékeli a kérést és nem küld válasz, és nincs is megszakítás. Csak akkor azt nem értem, hogy ha kivetted onnan a teljes megszakítás letiltását, akkor az miért befolyásolta az egészet!?

Igen. Sajnos az a nagy baja, hogy nem csak a kívánt karaktereket küldi el, hanem azt hiszem hogy CRLF-et is(13,10). Ami most nem valami jó, de próbáld meg, hogy reszetálod a PIC-et és a VB progit nem indítod el, hanem a terminalból küldjél el két karaktert, aminek a ASCII kódja 40 körül van. Ekkor ki kéne gyúlnia a LED-nek, ha nem is futna esetleg végig a vétel.


Ezt honnan tudod, működik gyalog?

Nem jó a link, nincs mögötte fájl.

megszakitas mukodik 25-os baudrate-val. timer is van benne, az is mukodik.
http://lacc.uw.hu/megszakit.asm

iranynal D'18' a kozep, D'22' a sebessegnel a kozep.

ha iderakom, mar akkor sem gyul fel a led. Nemkeletkezik megszakitas.(?)
meg ugye az R betut az szorgalmasan kuldogeti, tehat "kuldo" kommunikacio az van.
Baudrate is jo, merthat R betut kuld, eshat az tenyleg D'82'. Ha atallitom hypertrm-ben a baudrate-t 9600-ra, akkor nem R betut kuld, hanem hulyesegeket. Hypertrm-et ismered? Itt az R betuk folyamatosan mennek.
VB progiban is, csak ott nem egyfolytaban ugye, hanem gombnyomasra.

Akkor ez kilőve.
Az órajel is jó elvileg, mert akkor nem működne az írógép. Próbáld meg az írógépet 19200-on is, hogy azt is kizárjuk!

Nézem a progit közben, de nem tudom mi a rák lehet. Minden okés elvileg eddig.
Az biztos, hogy a soros vétel rutinban akad el a program, mert nem érkezik be a három bájt amit a PC küld(ha elküldi egyáltalán).
Ez abból látszik, hogy a megszakítás letiltásakor a program nem tud impulzusokat sem gyártani, mert nem szabad megszakítást okoznia a timer1-nek. Amikor nem tiltod a megszakításokat, akkor a magasabb prioritású megszakítás végrehalytódik, hiába van az alacsonyabb megszakításban elkadva a program. Tehát azt kéne kideríteni, hogy miért ragad be a program a soros rutinba, és meddig jut el benne. (hibajelző ledet pakolgasd a vett bájtok után sorba, hogy hol akad el a vétel)

kabel jo, pc jo (irogep mukodik), orajel elvileg jo (8mhz, osccon reg 6-4 bit = 111), merni nemtudom (ezt hogylehet?).
Megszakitasokkal nem lehet gond?

Egyfolytában azt nyögöm, hogy a soros kommunikáció nem műküdik, és azt is, hogy e miatt nem megy semmi rendesen. A soros kommunikáci lehetséges hibái: Kábel, PC, BaudRate, PIC órajel eltérés és még ki tudja.
A asm-ot átnézem! Jelentkezem, ha megvan...

hmm. Talan megva a hiba!


Ha kiszedem a lov iterruptbol a sort, akkor tudom mind a ket erteket valtoztatni
De igy nincs soros.

ha az impulzus 10, akkor nemigazan mukodik a dolog. 20-nal mar megy, en 50-t hasznalok.
iletve ha bentvan a

sorok a low interruptban, akkor sem meg a dolog, de akkor semmi nem megy...

http://lacc.uw.hu/download/RC.asm
Az nemlehet hogy a configbitekkel van a gond?
Azt nem ertem, ha a sebesseget tudom mahinalni, akkor az iranyt miertnem? pedig ugyanugyvan...
Kiprobaltam, hogy csak 2 impulzust adok ki, kikommenteztem az egyik rcall impulzus sort. Ekkor a kerek kozepen alt, es a hatso meg mint az orult ment. ez ertheto, mert a masodik imp. ugyanugy az iranyhoz tartozott, ezt beallitotta gondolom, a harmadik hianyzott, eshat a kerek porgott, mintha fullra ki lenne tolva az uccso pulz.
Most nezem, ez csak akkor mukodik, ha az irany resznel levo sort kommentezem. Allitodik is szepen az irany, a sebesseg valtozo bealitasatol fuggoen.
Viszont, ha a VB progival szeretnem ekkor iranyitani (meg amugyis), nemveszi az adatokat.
Ma van az utolso hatarido, hogy mukodjon

Légyszi tedd fel azt a progit amit a 1320-ba fordítassz! Hátha látok rajta valamit...


Ezt csak azért írtam, hogy legyen valami összehasonlítási alapod, de nem szeretném ha a PC-ktől függne a dolog, mert ez enyhén szólva valószínűtlen, mivel MAX232-vel illeszted a soros portot, és én még olyat nem láttam, hogy ilyenkor ne menne minden gépen. Én most is valami eltérésre gondolok, ami a két PIC között van. Muszáj mennie! Ha nálam bizonytalan lenne a működés, akkor azt mondanám, hogy oké, de ez úgy megy mint a shafhausen! Nem tudod megmérni a baudratet? vagy az órajelet?

Ma kipróbálom egy másik PC-n is a dolgot. Kíváncsi vagyok! Te hány PC-n próbáltad?

A helyzet nagyjabol valtozatlan. az irany-t nem tudom allitani, sebesseget igen. Bar eddig csak elore, hatra, meg a stop ment, de betudom annak, hogy az irany nagyon ki van tolva, es bezavar. Mikor a potit meg anno tul kitekertem, akkoris begajdult az egesz...
Ha VB progibol akarom vezerelni, nemhat semmit. ugyanugy viselkedik.

ratettem, atirtam a picemhez a dolgoka, de nem megy. most meg se mozdul a kocsi, a soros meg annyira sem megy, mint a masikon...

hogyha kiveszem a
BCF ALL_INT_E_T
sort low prioritasbol, akkor a soros ua, mint eddig, viszont a vett ertekeket nem kuldi vissza.
vizsgalgatom meg...

Hi!
Megnezem. xp, 2000xp, gigabite alaplap, az NF7-et meg nem hoztak vissza garibol lassan masfel honapja

Ahogy ígértem, megnéztem mi lehet az oka annak, hogy a 82-ők jönnek vissza a válaszban(ahol az elküldött bájtoknak kéne), mikor 50 feletti értékeket küldök el mindkét értékben.
Ez azért volt, mert mikor a két impulzus össz ideje kezdett meghaladni egy határértéket, akkor elfogyott az idő a soros portnak az adatcseréhez. Mivel a soros lekérdezés megszakítása alacsony prioritású, ezért a magasabb priorítású timer1 megszakítást generált, lekezelte az impulzusokat, majd a végén beletolta a D'82'-őt a vonalba. Hogy elé vagy mögé, vagy minkét szám helyett, az attól függött, hogy mennyire volt kevés az idő a soros vonalnak.
Megjegyzem, hogy szerintem ez csak nálam volt ok! Nálad nem tudom mi okozza a teljes eltérést a nálam jól működőhöz képest. Azt neked kell még megtalálni!

Az én esetemben a megoldás az volt, hogy megmeltem a BaudRate értékét 19200-ra, így átérnek az adatok a rendelkezésre álló legrövidebb időn belül is. A hiba eltünt, tehát 0-60-ig egyesével tökéletesen lehet változtatni az impulzusok idejét minden mellékhiba nélkül. Ez azt jelenti, hogy nincs szakadás, vagy szinkron kiesés a vezérlőjelben. Ha én ezt most rátenném a kocsidra, biztos vagyok benne, hogy működne!

A VB progiban csak a BaudRate értékét módosítottam, meg az alap értékeket, amit felhoz a két textboxban. A többivel nem volt gond.

Lehet, hogy leírtam már a protokollt, de jobb kétszer, mint egyszer sem.
Tehát a PIC program soros vonal kiszolgáló része a következők szerint működik.
Adat beolvasásra elegendő idő a harmadik impulzus vége(ekkor van vége a timer1 megszakítás kezelésének) és a következő vezérlő impulzuscsomag első impulzusa között(ekkor kezdődik a megszakítás) van.
Tehát nem mindegy, hogy a PC mikor kezdi elküldeni az adatot. Ha rossz ütemben küldené(pl. az impulzusok közben) akkor az eleje lemaradna a vételnek, mivel a PC nem tudja, hogy a PIC vette-e az adást, vagy sem, ezért a küldést meg sem ismételné (hibakezelésre végképp nincs idő).
Ezért, hogy az adatok átérjenek, a fent említett timer1 megszakítás végénél kell a beolvasást kezdeményezni. Ilyen esemény másodpercenként ~66 szor adódik, de a PC jelzés nélkül nem tudhatja, hogy ez valójában mikor történik.
Ezért küldöm el a jelzést(D'82'), így a PC értesül a pillanatról.
A PC csak akkor válaszol, ha van mondanivalója, tehát van érvényes adat. Ezt jelen kezdetleges programomban a gomb megnyomásakor beállítódó jelző(boolean típusú váltotzó) jelzi. Ha a PC egy soros megszakításkor 82-őt olvas be és a jelző szabad, akkor azonnal elküldi az előkészített bájtokat, majd fogadja a választ(ha van Jó esetben mindig kell lennie!) Ezzel a kör lezárult.
Ha kocsit vezérlő programból akarod majd ezt a kérdést lekezelni, akkor először be kell állítanod a sebesség-irány változókat, majd az említett jelzőt szabaddá téve a megszakítás rutinod elküldi a csomagot szinte azonnal, mivel secenként 66szor jön kérdés, hogy van e új adat. A VB-ben az MSComm eseménykezelő objektummal nagyon egyszerűen lehet ezt lekezelni, de gondolom a Delphi is rendelkezik hasonló objektummal. Remélem, hogy nem okoz gondot megírnod majd! (Ha véletlenül igen, akkor már ezen ne múljon, megírom azt is, de akkor én is kérek egy diplomát ! )

Frissítettem a csomagot, nagyon remélem, hogy most már nem lesz vele gond!
www.wattmep.tvn.hu/public/RC_imp_ok.zip
Jól meg kell nézni, hogy a 2320 és a 1320 között mi az eltérés! Sajnos nekem nincs több 1320-am, nem tudok azzal próbálni, de meggyőződésem, hogy azzal is mennie kell. Én régi XP-n, Abit NF alaplapon, és AMD 2,5XP procin próbálom. Szerintem más gépen is mennie kell!

A baudrate értéke a főoszcitól is függ. Ha a freki nagyon eltér, akkor hiába írkálod be a 12-őt, nem lesz jó!


Ez a dolga! Alapból másodpercenként ~66 Chr$(82)-őt küld el. Fentebb részleteztem miért.

Igazad van az impulzussal kapcsolatban, de a 10-es érték jónak tűnik, sőt inkább csökkenteni kéne, ha már megy. Ez nem okozhat gondot.
Gondot olyan dolog okozhat, ami a 1320 és a 2320 eltéréséből, valamint az én órajelem és a Te órajeled közötti eltérésből, esetleg a két PC közötti eltérésből(COM1, alaplap, OPrendszer.) lehet, de ez utóbbinak nem szabadna megtörténnie.

az is fontos, hogy mekkora az impulzus.


ha mondjuk 50-re rakom, akkor mas a kozepertek is.

Termeszetesen probalom azt is, amit mondsasz! baudrate jonak kell legyen, atirtad 12-re, visszatettem a baud(D'9600')-as megoldast, es ugyis azt csinalja. Kuldi sorosra az R betuket!
Az irany nem megy, nemtudom hogy hogy van koze a baudratehoz, meg a soros porthoz, hogyha meg csak progibol sem tudom valtoztatni az erteket...

Nem szabad kivenni az entert. Az enter csak hibadetektálásnak kell a PIC-ben, de a visszaküldésnél fontosabb dolga van.
Megint hangsúlyozom, hogy nekem minden jól működött(lásd a wav-ot!!) Nem kéne ilyen helyeken belenyúlnod. Inkább azt kéne próbálnod amit kérek és nem össze vissza kísérletezni.
Biztosan jó a baud rate?


Programból úgy kell megoldani a kérdést, hogy amikor előáll az új érték, akkor egy jelzőt kell beállítani, ami engedi a választ elküldeni a PIC-nek, amikor az jelzi a vételi kézséget. Az elküldés után ezt a jelzőt törölni kell. A gomb ugyanezt csinálja. Nem akkor küldi el a gomb a bájtokat, amikor megnyomod, az csak egy jelet ad, hogy van mit küldeni. Ha nem szinkronizálnánk a kommunikációt, akkor sérülhetnek a bájtok átvitelkor, ami zavart okozna a pontos vezérlésben.
Ismét azt kérem, hogy próbáld megérteni a két program hogyan működik együtt. A basic rész nem bonyolult, simán megérted, ha Delphiben tudsz progizni!

Ma még megnézem a programot mégegyszer, és megpróbálom stabillá tenni a működését.

szerintem mostmar elkeszul, mivel mozog a kocsi, van jel, stb. kicsi gondok vannak meg, amit ma me'g meg kell oldajk!
az irany az elso ertek nem ugy egyeztunk? ez szerintem valojaban is igy van. iniben valtoztatgatom az ertekeket, es az irany erteket hiaba valtoztatom ott, es egetem ra ujbol a progit, nem mozdul a masodik impulz. viszont ha a sebesseget valtoztatom, akkor szepen latszik a szkopon, hogy arrebmaszik a 3. jel. tehat ez a sebesseg, es a masodik az irany!
En proballak nem vissza fogni teged, minden erommel, es szabadidommel rajta vagyok ezen a dolgon mar egy jo ideje.

nem tudommennyire valos az, hogy a soros miatt nem tudom allitani az elso impulzust, mert programba van irva (ini reszbe), es sorossal nem is foglalkozok meg. mennyen ez, majd aztan

a beolvas rutinban, mikor beolvassa a ket erteket, egy entert is varunk? es ha ez nincs, akkor a hibara ugrik? miert kell az enter? ha progibol kuuldjuk a ket adatot, akkor is kell az enter? szerintem nem, kivettem belole ezt a reszt, dehat igysem megy Nemlehet az, hogy nem akkor kuldom ki pont az adatot, mikor kellene, mikor kijott a 3. pulz is? Ezt a programodbol nehez lesz, mert gombot kell nyomni, eshat a 15ms eleg kicsi. Nemtom hogy csinaltad. vagy igy jonak kene lennie?

Az irány a második adat, ha jól sejtem. Lehet, hogy a második bájt már eltolódik a helytelen baud értéke miatt. Próbálkozni kell más értékekkel is, mint ami most van. Nézd át a 1320-as adatlapját, hogy biztosan minden a helyén van-e. Biztosan a soros kommunikáció miatt nem tudod mindkét értéket módosítani.
( Nem akarom magam sajnáltatni, de mostanában úgy érzem magam, mint amikor azt álmodja az ember, hogy futna, de minden sejtjét visszafogja valami. Remélem most már nem adod fel akkor sem, ha nem készül el határidőre! )

Hi! kocsi megy, es talan megtalaltam a sebesseg kozeperteket 0x15.
irany nem valtozik
Mint emlitettem, nem igazan tudom leolvasni, nincs rajta cursor.
De most talan megva. ugy nezem a 15 ms megvan kb. Pontosan nemtudom kurzor nelkul. sebesseg ~1,8ms megvan, kozepertek. irany-t nemtudom valtoztatni
jah, meg probalgattam a sebesseg kornyezetet is, es nemigazan mukodott a dolog, hogy lassabban mennyen mondjuk. Eddig elore, hatra, hangsulyozom szemre.

Milyen időket mérsz? (sorban add meg légyszi, balról jobbra az impulzusok közöttieket. A két fő impulzus közötti periódus idő is fontos!)

Hogy érted, hogy egymás alatt?

bocsi, az elobb lukesegeket beszeltem.

latom a 3 jelet. az utolso, sebesseget meg tologatni is tudom, tehat azt elvileg tudom vezerelni. Viszont a masodik impulzuset nem. az mindig fix. nemlatom miert lehet ez, hiszen ugyanazt csinalja mind a 2 esetben.
A kocsi nem mozdul

0-60 ig szerettem volna, csak 0x30-tol indulni, es kivonni belole 30-at. de mind1, egyenlore joigy. a lenyeg, hogy lemertem, es a harom jel egymas alatt van, nem egymas mellett. a kodot ertem szerintem, ertettem nagyjabol eddig is, csak a prog technikaval van gond ugye.

Gondolom hiába mondom azt el újra, hogy nálam minden jól ment. És azt is hiába mondom, hogy nálad is mennie kell(ene)! Tehát várom a fejleményeket, és kérem, hogy próbáld meg a programot megérteni, és esetleg saját Delphi rutint írni, mert lehet, hogy a VB progi egyik ocx-je másként működik mint az én verzióm, esetleg az XP SP2(?) tréfálkozik veled, ha az van fenn. Az is meg kell nézni, hogy a timer3 értékeit kiszámító rutin jól működik e, mert arra nem volt időm tegnap.
Azt nem pontosa értettem, hogy Te milyen tartományban akartál alapjeleket bevinni? 0-60? (én így gondoltam, de nem vagyok benne biztos) Na ez azért lehet érdekes, mert mint írtam 45 feletti érték esetében nekem is rossz adatokat küldött vissza. Én a számoló utinra gyanakszom, hogy nem jó értéket számol ki és ezért a timer3 tovább vár mint kéne. Igaz ennek jelét nem láttam a felvételen.