Gafly!
Köszönöm, hogy beleolvastál a doksiba!


Ez nem azt jelenti, hogy áramgenerátoros védett kimenete van?

Ros-Co

A gond csupán elektronikai lehet, a hibás adat "hasznos jel" és arra következteti a vevőt, hogy más is beleszólt a folyamba, ami ütközést jelent, tehát megáll és kis idő múlva újra próbálkozik(kb ezt csinálja az ethernet)

Az adatlap ezt irja:

The driver is designed to handle loads up
to 60 mA of sink or source current. The
driver features positive and negative
current-limiting and thermal shutdown for
protection from line fault conditions.

Szamomra ez egyertelmuen azt jelenti
hogy nem illik ket kimenetet szembeforgatni,
meg ha nem is megy tole tonkre (rogton).

Tessek szepen egyszerre csak egy kimenetet
engedelyezni. A "party-line'-is ugy ertik
szerintem hogy sokan figyelnek, de mindig
csak egy ad...

Gond nélkül azért nem lehet "szembe" beszélni, mert akkor hibás lesz az adat. Alapállapotban, amikor nem monitorozol, akkor így van értelme a HiZ -nek, így a vevők nem terhelnek (de ebben én sem vagyok biztos)

+kéne nézni, hogy van-e az IC kimenetén áramkorlát, és mekkora max. áramot enged meg. Asszem +-60mA-rel hajt, de hogy mi van ha szembe kötsz 2-őt? Szerintem próbáld ki. Megéri 200Ft elfüstölését.

Viszont ezzel lehet a vonalon lévő forgalmat monitorozni, ütközést figyelni(ha a kimenetek támogatnák). (ami kimegy annak kell bejönnie)


Hát éppen ez a lényeg szerintem. Minek HiZ-be húzni, ha minden gond nélkül szembe lehet beszélni egymásal? Semmi értelmét nem látnám a dolognak a TX oldalon. Jelenleg úgy használom, hogy csak egyet engedélyezek.


Az SN75176 esetében nem vagyok meggyőződve a dologról. A doksiban nem találtam erre utaló jeleket. Ezért kérném, hogy ha valaki aki lát benne erre utaló részt, legyen szíves jelezze!

Másként fogalmazok: Olyantól hallottam, aki ipari elektronikát is épített már.
Az engedéylező láb azért van hogy ha pl- a vevőnél vársz egy megszakításra, a saját adód ezt ne indítsa el. Az adó nem engedélyezés pedig a lábakat nayg impedanciás állapotba húzza.

Ez a vélemény és az üzemszerű használat között van talán egy kis különbség. Engem az engedélyező lábak léte zavar egy kicsit, mert ha minden gond nélkül lehet belebeszélni, akkor minek engedélyező láb? A sok kimenet párhuzamosan biztosan terhel, hacsak nem open kollektorosak a kimenetek, belül. Ez sem derült ki a számomra a doksiból. Nagyon úgy néz ki, hogy a kimenetek mindkét szintje aktív, akkor meg nehéz elképzelni, hogy szembe köthetőek üzemszerűen. Az ethernet vezérlők biztosan openesek, ezért nincs is rajtuk engedélyező láb szerintem, de igazából még nem foglalkoztam ilyen vezérlőkkel. MAjd körülnézek, mert kezd érdekelni a dolog..

Szerintem semmi baja nem lesz ha több adó szólal meg. Ezt hardveresen detektálni nem lehet, erre alkalmatlan az IC. De sztem nem is kell. Ha van CRC az adatokban, és belepofázik valaki az adásba, akkor kiderül. Mehet az újra kérés.

Lehetne RS422-t is használni, ez gyakorlatilag ugyanaz, csak az adásra -vételre külön vonalat használ. Bár itt is megvan az egyszerre adás lehetősége.

Ros-Co.
Ahhoz, hogy a vonalak kiosztásra kerüljenek, a buszmeghajtóknak biztosítani kellene a közös megszólalláshoz szükséges áramköri megoldást. A SN75176 nem biztos, hogy szereti, ha egyszerre több kimenet szólal meg a vonalon. De lehet, hogy csak én nem értettem meg a doksiját. Jó lenne, ha valaki olvasni tudó ránézne, hogy mi az ábra!

Strukturált hálózatot nem illik házvezérlésre használni. Már pár száz periféria esetén is rengeteg switc-re vagy hub-ra lenne szükség.

Persze vannak ezirányú törekvések, van is egy ipari szabvány, ami ethernet vezérlést használ.

RS485-ön inkább időszeleteket szoktak kiosztani, és minden eszköz csak az ő időszeletében pofázhat (elöl-hátul kisebb ráhagyással) A probléma az első induláskor van, hogy ki melyik időszeletet kapja meg. Először lesz ütközés, de pl. ha egy véletlenszám-generátort is teszel a dologba, akkor jó eséllyel az egyes eszközök más-más időszeletet kapnak.
RS485-ön is lehetne az ethernet algoritmust használni, csak nem szokás, mert relatíve kicsi a sávszélesség, tehát a csomagok hossza nem túl rövid.
Emiatt jobb az itt említett megoldás.

Mondjak valamit, én sem! Azt tudom róla, hogy bármelyik egység bármikor beleugathat a vonalba, majd az adó(aki először vélte úgy, hogy szabad a vonal) eldönti, hogy mindvégig az volt e a vonalon, amit küldött, vagy közben más is belekotyogott. Itt az áramköri megoldás ami számodra érdekes, nem a protokoll. Szóval érdemes lenne a meghajtó IC-k körül keresgélni, hátha lehet kapni itthon. Esetleg egy PCI-os ethernet csatolókártyát vezérelgetni?!

Bevallom, az ethernet -et nem igazán ismerem , mármint olyan szinten, hogy a kommunikációt és üközéskezelést, perifériaillesztést hogy oldják meg.

A soros ellenállással az is a baj, hogy a vezeték kapacitása és induktivitása okozta átviteli sebesség(freki) függő impedanciája osztót képezne(alacsony átviteli sebesség az eredmény). Én megfontolt szándékkal nem mentem bele az ethernet típusú áramköri megoldásokba(drága), mert ide nem szükséges, hogy bármelyik egység bele tudjon szólni a vonalba. Maradok az autós példánál, ahol a központ szólítgatja a perifériáit.
A nyitott kollektoros megoldás meg azért gázos, mert a csavart érpár elveszti a jelentőségét, ill. eldobjuk a legnagyobb előnyét, a zavarmentességet!
Ha mindenáron ilyen kommunikációt akarsz, akkor az ethernet áramköröket ajánlom figyelmedbe.

Ilyen probléma nekem is szokott lenni, pont a következő projectnél is töröm a fejem, hogy kéne megoldani. A probléma ugyebár az, hogy a PIC egyik lábát kimenetként és bemenetként is használni szeretnénk, viszont úgy kellene illeszteni valamilyen illesztővel, hogy ha kimenet, akkor kibírjon egy olyan esetet, mikor pl. a buszon H szint van, ő pedig L szintet akar adni ill. fordítva és nem hátrány, ha valamilyen olcsó megoldást néz az ember.
A nyitott kollektros kimenet is csak akkor jó, ha minden eszköz ilyen a buszon.
A sima soros ellenállás beiktatáson gondolkozom, csak az én esetemben néhány mA fogyasztás is lesz kimenet esetén és igy esik a feszültség az ellenálláson. Sima bemenet esetén olyan pici áram folyik, hogy elhanyagolható a feszültségesés.
Ez jó téma - csak nagyon esetfüggő ,hogy hova mit érdemes, de kiváncsi vagyok a véleményekre.

Egyetértek!



Nem fix időkeretes amit íram és nem is igazi időosztásos, bár a dolgok egymás után történnek, ez igaz. Az adatcsere próbálkozás elhúzódhat, de max addig amit egy egységnek hibával együtt szánok, mielőtt azt mondanám rá, hogy hibás. Ezután jön a következő egység. Jó esetben hiba nélkül a kör villlám gyorsan lefut és kezdi előlről. Hiba esetén a kommunikációs kör megtorpan egy slaven, amíg sikerül a kommunikáció, vagy amíg eltelik a rászánt idő(a beállított max átviteli türelmi időtől és ismétlések számátólfüggően.)
E miatt egy új egység beillesztése semmiféle zavart nem okoz, csupán a köridőt(körbeérési időt) növeli meg. Rossz esetben egy egység lekezelése hibával együtt kb. 10msec. Így másodpercenként kb 100 egységet lehet körbekérdezni. Jelenleg ez alatt az 1 sec alatt 4-5000 bájt átmehet, de ennyi nem fog, mert kb. 500bájt lesz az adatáramlás egy kör alatt. 15-30 egység lesz max., ezért a köridő jó esetben rövidebb mint fél sec. De nem baj, ha 1sec lesz, mert ezek a feladatok(távoli villany be-ki, ébresztő, új hőfok alapjel bevitele, hőfok és állapot regiszterek kiolvasása stb.) nem időkritikus. A központ(master, 18F458) a riasztásokat megszakításból kezeli közvetlenül, ezért az időkritikus dolgok azonnal történnek. Addig a többi kényelmi kiszolgáló ráér. Alap koncepcióm az volt, hogy biztonsági dolgokat nem végzek soros vonalon keresztül, és ez megoldható könnyen egy kis szervezéssel, átgondolással.

Az ütközés figyeléshez olyan hadver kéne, ami független a soros áramköröktől, mert ha a PIC valami miatt vakvágányra téved, akkor nem érzékeli a vonalon folyó forgalmat. Ez bonyolítaná az áramkört és nem is lenne egyszerű a dolog(igaz még nem gondoltam át teljesen).
Alap felállás az, hogy a Slavek csak akkor válaszolnak, ha meg lettek szólítva. Ha ütközés figyelés is lenne, akkor meg lehetne oldani az ethernethez hasonló forgalmat, ahol mindegyik egység adás közben is figyeli a vonalat, hogy amit ad, az van e rajta, ha nem az, akkor ütközés van. Ugyanis egy bizonyos kábelhossz után, ha két egység egy időben kezd adni, akkor nem veszik észre, hogy a másik is ad, csak egy idő elteltével. Szóval azért ez az ütközés figyelés nem olyan egyszerű.

Az én esetemben pláne nehéz lenne, mert az SN75176 nem tudom, hogy mit szólna, ha szembe dumáltatnám a kimeneteiket(lehet semmit ). Erről nem olvastam infót a doksiban, tudsz erről valamit?

Watt:
Átolvastam, amit írtál. Nyilván millió részlet van, ami miatt nem könnyű kivülállónak átlátni a rendszered, de tetszik. Nyilván én sem úgy gondoltam, hogy koppintani kell az autókat, csak használnak ott is jó ötleteket, amiből meríteni lehet.
A hibakezelést jól leírtad, ez nagyjából összeállt.
A busz megosztásánál az időosztásos megoldás is jó, viszont szerintem figyelni kell arra, hogy könnyen bővíteni lehessen. Ha a meglévő időkeretet osztod szét a betervezett eszközök között, akkor ha újabb eszközt szeretnél a buszra felfűzni, akkor a többieket mind újra kell konfigurálni és mivel úgy látom, hogy a picbe égetett kód fogja ezt ellátni, igy elég komplikált lehet újabb eszköz beiktatása. Meg lehet úgy is oldani, hogy előre kihagysz időszeletet az eszközöknek, de ez sem túl hatékony.
Nekem az ütközésdetektálásos megoldás tetszik a legjobban és ennek a leprogramozása is az egyik legkönnyebb. Optimistán kiindul az eszköz abból, hogy csak ő fog egyedül beszélni a buszon, de figyeli a buszt, hogy biztosan csak ő ad rajta. Normál esetben nem lesz probléma és az egyszerű kód rendben lefut, ha viszont hibát észlel, más is belebeszélt a kommunikációba, akkor mintegy kivételkezelést, vagy megszakításnak tekintve az esetet egy kifejezetten erre az esetre írt kód rendet tesz és eldönti, hogy ki beszélhet. (mely lehet akár időosztásos is, vagy ha a teljes lekérdezés nem tart sokáig, akkor az talán még jobb) Tudom, ez nagyon általános, de annyira nem látom át a rendszered, hogy konkrét dologat tudjak írni, de szerintem ez egy könnyen lekódolható, gyors és szép megoldás és a bővítés is könnyebb, mint csak időosztásos esetben. Viszont fontos, hogy csak akkor célszerű ezt választani, ha várhatóan ritkán lesz ütközés.

Ne haragudjatok, de ez a stroboszkópos dolog megérne egy új topikot.

De most mi kell pontossan?
Vezérlő? vevő?
Az egyik elektorban volt egy dmx-es dimmer leírása.
Vezérlőnek nem érdemes nekiállni, vegyél egyet, egyszerűbb és lehet, hogy olcsóbb is lesz.
Pl http://www.behringer.com/LC2412/index.cfm?lang=ENG ez a vezérlő 55.000ft-ba kerül, neked az alkatrész hozzá többe lenne...
Pc-s lpt-s, com-s, sőt nekem van egy önnálló kártyás cucc is, azt szivessen odaadom, de ezekhez meg kell irni a programot pc-re...
Van egy komplett scanner doksim, egy megépített elektronikával együtt, (4 léptető, 2 micromotor) Van egy füstgépvezérlésem, két relét kapcsol, van egy triakos nullátmenetvezérlős switchpack-om, mindegyik megépített elektronikával persze nem ingyen...
Ha a strobi féyerejét is dmx-ről akarod szabályozni, akkor a strobi teljes elektronikáját meg kell építened, vagy elektronikus potit használni egy meglévőhöz.

Említésre kerültek a hibák.
Sok ellentmondást, de inkább úgy mondanám nehézséget látok a korrekt hibakezelésben, főleg úgy, hogy a sebesség kárára ne menjen jelentősen.
Nézzük milyen hibák lehetnek.
master küld slave-nek:
1. átmegy minden küldött bájt, de a CRC hibás, vagy más hibajelző jelez hibát(pl nem értelmezhető az egyik parancs, pedig a crc jó. lehet hibás parancsot is küldeni véletlenül, de ez talán nem történhet meg.).
2. Várunk n adatot, de valahol hiba miatt elakad a folyam. Ilyen lehetséges, ha erős zavarjel stop bitet szimulál, vagy az adó hagyja abba az adás, valami fontos dolog miatt(megszakítás). (mondjuk ez utóbbi nem jellemző, mert 1 bájt egészben el tud menni megszakítás esetén is, mivel hardveres a küldés, ha már a TXREG-be be lett téve a bájt.)

1. esetben a kezelés egyszerűnek látszik. Válaszként hibát jelzünk.
Az adást megismételjük, ha hibajel jött vissza.
De mi van, ha a hiba jelzése se ér vissza.
Az egyik megoldás, hogy minden bájt elküldéséhez megadott minimum időtartamot rendelünk a vevőben. Ha ezen időn belül nem érkezik meg a következő bájt, akkor hiba van.
Ilyen esetben a küldést-fogadást ismételni kell.
De ilyenkor előállhat az, hogy egyáltalán nem jön adat, vagy válasz. Ekkor nem ismételhetünk akárhányszor, mert más is vár a vonalra. Tehát az ismétlések számát is korlátozni kell. Ha a korlátot átláptük, akkor végzetes hibajelzéssel kivonjuk a forgalomból a slavet. Én 2-4 ismétlést engedélyezek a tervek szerint(a hibakezelést a végén írom). Ez elvileg elegendő, ha nincs valami áramköri hiba, akkor az adatoknak át kell érniük. (megjegyzem, hogy hibakezelés nélkül eddig csak nagyon ritkán állt le a forgalom.)

A 2. hibakör kezelésére hasonló módon az adatfogadás időkorlát megoldás látszik jónak. A PIC-ben ez egyszerű, mert mindenképpen vizsgálni kell, hogy az RXREG megtelt-e, mielőtt kiolvasom. Ekkor lehet bizonyos ciklus elteltével kilépést generálni hibajellel. Minden bájt vételekor meg kell ezt tenni. Ha nem érkezik meg a megfelelő számú bájt, akkor válaszként hibát küldünk. Kérdés, mikor lehet választ küldeni? Mi van akkor ha a master úgy dönt, hogy közben már másik slave-vel foglalkozik, mert ezt hibásnak tekinti és ez meg belekotyog a folyamba. Úgy gondolom, hogy ezt is időzíteni lehet, mert a bejövő adatok max. számát lehet tudni, és a hozzá szükséges időt is. Ennyit várni kell egy hiba esetén és utána küldeni a hibajelzést. Ez elég kényes szinkront kíván (rossz esetben belekotyogna egy másik slave adatcseréjébe). (Lehetne ütközés figyelést is csinálni, de ez egy külön kategória a protokollok között is. Ezt most nem szeretném ) A master is vár a válaszra, tehát elvileg szinkront lehet teremteni. Ezek az idők nagyon rövidek(ms nagyságrend) tehát nem túlzottan tartana tovább egy hibás adatátvitel lekezelése, mint ha simán átmenne. Ami rabolja az időt az, hogy meg kell ismételni, főleg ha nem is egyszer. 50K-s sebességgel kb 5000 hasznos bájt tud átmenni. Ez az én esetemben elegendőnek tűnik bő tartalékkal a hibák lekezeléséhez is, de majd kiderül a próbáknál.

Ma csinálok még néhány slave egységet(most csak kettő van), aztán felfűzöm őket és kiderül mennyi idő mindent körbekérdezni, eseménykiszolgálás, közvetlen parancsküldözgetés(PC-ről) közben.

Tényleg örülök, ha valaki foglalkozik mélyebben is a dolgokkal, mert így jönnek elő a jó ötletek! Tehát köszönöm mégegyszer!

Ok, csak azért írtam be az autosat, mert azt olvastam kicsivel korábban, hogy probléma volt, de ha már müködik, akkor rendben.

Gafly
A fürdőszobában elvileg lehetne páratartalmat, vagy páralecsapódást mérni, és arra szabályozni.
A WC-ben meg talán elegendő, ha egy mozgás(mozgásérzékelő, esetleg infra kapu) bekapcsolná a szellőztetést és onnan adott ideig szellőztetne. Esetleg ammóniát mérni, de azt nem tudom hogyan lehetne!


Hát nem tudom ezt hogy éreted, a WC-zést nem lehetne központilag vezérelni az tuti , de a kiszolgálást igen, vagy nem?

Netter
Nem akartam a spanyolviaszt föltalálni! Ezenkívűl nem csak a kommunikációt kellett "kitalálni", hanem az eszközöket is megtalálni hozzá(az eszközöktől függ a kommunikációs protokoll is részben). Különben amit leírtál jó és ismerem, de nem alkalmazható az én esetemben fizikai felépítésből adódóan, meg azért sem mert nem bájt alapú.
Nekem annyiból más a kommunikáció, hogy a címzés 8bites és a 9.bit jelzi, hogy címet, vagy vége jelet küldtem. Az is több, hogy nem csak egy parancs megy ki, hanem kettő. Az első a főparancs, a második a másodparancs. (pl. fő: villany, szelep; másod: be-ki, nyit, zár stb) Ezután jön hogy hány adatot küldök, majd az adatok(már ha vannak). A kommunikáció tisztán bájt alapú, de a Slavek mindig tudják, hogy mikor megy cím, vagy adat(9. bit jelzi) A kimenő irány 9, a viszirány 8 bites szervezésű, mivel a Slavek nem címezhetnek. Az adatok után jön két CRC bájt és a vége jel(ennél is él a 9. bit).
Egy parancsra kapott válaszban benne van a slave állapotregisztere(lehet tudni, hogy végrehajtotta e a parancsot és még sok mindent), hiba regisztere, majd a saját címe jön, hogy biztosan ő válaszolt-e, végül a CRC-k.
Slavektől az összes adatot le lehet kérni külön is(hőfok, állapotok, hibák), és lehet tudni, hogy hány adatra várunk, ezért ez is biztonságot növeli.
Jelenleg 50K-val hibamentesen működik a kommunikáció, feltekert 100m-es UTP-n keresztül úgy, hogy a páka trafóm benne van a tekercs közepén. A vezetéken mérhető zavarjel 1V körüli.
Lehet, hogy szerinted feleslegesen törtem a fejem, de én úgy érzem jobb rendszert sikerült kreálnom, mint a KWP, de a CAN-os dolog is csak a hardweres hibakezelésében jobb, amit itt erőből simán meg lehet oldani. Itt nincs szükség a Slavek közötti azonnali reakció időre, de az autónál sem a soros vonalon keresztül vezérlik a motort, és a kritikus részek (ABS, Motorvezérlők) külön áramköröket kapnak, vagy megszakításos vezértlést. Meg lehet nézni, hogy amit sorosan elküldenek, az milyen feladattal bír. A mérőegységek készenlétben vannak, csak lekérdezésre várnak, nem ők mondják meg mi legyen, hanem a központ kéri le tőlük az infót, ami nem igényel várakozást, vagy kommunikációs ütközést. Egy autóban azért nem kritikus az adatforgalom, mert előre számítható az irány és a rendelkezésre állás. Csupán csak a megfelelő sávszélesség(sebesség) és a hibakezelés ami fontos. Egyébként a CAN sem valami gyors, és az is látható, hogy a KWP 10K-val is jól működik.

Végül fontosnak tartom megjegyezni, hogy nem téged szekállak, csak próbáltam vázolni, hogy a gyári megoldásoknál lehet jobbat kitalálni bizonyos területekre. Sokszor azért szerencsétlen némelyik megoldás, mert rá akarnak húzni egy meglévő, de nem arra kitalált protokollt.
Köszönöm, hogy foglalkoztál a témával!

Rég olvastam a topicot, látom, a kommunikáción dolgozol.
Remélem, nem szófecsérlés, de mióta megépítettem az analizátort, elkezdtem autók kommunikációjának az elemzését és azt kell mondanom, hogy nagyon jól ki van találva a dolog. Nem véletlenül ISO szabvány és az összes autómárka használja. A KWP2000/KWP1281 protokolról írnék, szerintem érdemes meggondolni, hiszen a 2000 kölüli évjáratú autókban tipustól függően kb. ~70 db kontroller ül a buszon és ha az autókban rá merik bízni az eszközöket, akkor neked sincs mitől tartanod.
A CAN buszt az újabb autók használják főként sebességnövelési céllal, hisz egyre inkább szériatartozák lesz a GPS, internet, CD tár, stb.
A KWP protokolok viszont egyszerű aszinkron soros kommunikációk, mint pl. a RS232, vagy RS485 - ezért ezt ecsetelném.

Kommunikáció half duplex módon az egy darab K-line nevű vezetéken történik. (máris 1 nagy előny, elég 1 vezeték)
Az eszközöket nevezzük ECU -nak. (electronical control unit)(egyesek csak a motorvezérlőt nevezik ECU -nak, de most ez lényegtelen)
Tehát az ECU -k a k-line -ra vannak felfűzve. Amikor az egyik ecu üzenetet szeretne küldeni a másiknak, akkor az üzenet a következő részekből áll:
Cím, parancs, adat, crc. (az adat opcionális)
A címet, ami (most VW -ről beszélek) 1 byte, mely 7 bites címet tartalmaz + 1 bit a páratlan paritás. Fontos, hogy 5 baud -os sebességgel küldik át a címet, ami azért nagyon jó ötlet, mert nyugodtan lehet energiatakarékos sleep üzemmódban az ECU, ezzel a sebességel nyugodtan fel lehet ébreszteni a picet és nem lesz időrabló sem, hiszen csak 1 byte átviteléig tart az állapot.
Utána jön az parancs és adat. Itt átváltanak magasabb sebességre. (~10,4 kbaud autóknál általában, de lehet más is)
Ennél, mivel eszközfüggő, hogy hány bájtot szeretnénk átvinni, először a length byte megy át. Ezt követik a valós adatokbájtok.
Utána pedig következik a crc.

Még egy jó ötlet, hogy mikor az adó ECU átküldött egy bájtot, akkor a vevő ECU minden egyes bájt után visszaküldi annak a bájtnak a negáltját. Ezt nevezik nack -nak. (negativ acknowledge, azaz negativ nyugtázás) Ezt nagyon könnyű leprogramozni (picek első komplemens utásítása, comf) és igy menetközben könnyen lehet detektálni a hibát. Hiba esetén az ECU nem hajtja végre a parancsot, újrakezdi a kommunikációt előlről.

Fontos, hogy a kommunikációt folyamatosan fentartják, azaz amikor nincs mit mondaniuk az ECU ill. diagnosztikai eszközöknek, akkor ack blokkot küldenek, ezzel ellenőrizve, hogy a ECU üzemkész. Az ack blokk címet és ack parancsot tartalmaz, adatot nem. A megcímzett ecu nack válasza egyértelműen üzemkész állapotról tanuskodik. Érdekes még, hogy a blokkokat számozzák, ezzel biztosítva, hogy nem "veszhet" el egy blokk (üzenet, egyes szakirodalmakban telegramm) sem.

Tömören ennyi, de hogy átláthatóbb legyen, írok egy példát egy Skoda Octavia inicializálása igy néz ki. (Hexa számokat használok az első és második oszlopban.) A második oszlopban vannak a nackok, ahova nem írtam kommentet.



A block számláló folyamatosan inkrementálódik nem törödve a túlcsordulással.
Szerintem ez nagyon jól ki van találva, gondoltak a címzésre, adatátvitelre, hibadetektálásra, korrekcióra, ..., és mindez 1 vezetéket igényel, ami ráadásul még a zavarokkal szemben is ellenáll, sőt az illeszőknek a buszvezeték mind föld mind tápfelé történő zárlatát is ki kell bírniuk, szóval nem kell a spanyol viaszt feltalálni, tökéletes ez lakásvezérlésre is.

NickE

Ay ay igazság, hogy nem nagyon akarok tökölni a programmal, most kivételesen egy előre elkészített, működő cuccot szeretnék felhasználni idő hiányában

Lenne 4..5 olyan fogyasztó amit ki-be kell csak kapcsolni, sztán egy strobi, ezt úgy állítólag szokták hogy 2 csatornát használ (fényerő, sebesség), meg egy színes izzósor, ami meg dimmelhető lesz. (P-S-Z, mondjuk 3 szín)

Először saját protokollt akartam írni, és szintén RS-485-tel lett volna, de ha itt ez a szabvány, akkor tartani kéne, és akkor ha befut egy gyári eszköz, azt sem gond vezérelni.

Rajz nem nagyon kell hozzá kell egy sima RS485 illesztő ic meg egy mikrovezérlő.
A program meg attól függ mit akarsz csinálni vele...

Bocsi hogy ide piszkítok, egy kérdésem lenne: DMX512 vezérlés kellene (ez ugyebár RS485-öt és PIC-et használ, ezért írtam ide)
Korrekt működő rajz és forrás kellene, mert nem találok....
Ha van ilyen fórum, lécci dobjatok meg a linkkel

thx.

Szia Watt,

furdoszoba/WC szelloztetest nem akarod automatizalni?
Ugye azert jo, mert nem csapodik le a para, bla, bla, bla...
Alapvetoen ugy szoktak csinalni hogy a villannyal egyutt
kapcsol ki es be ventillator. Csucsmegoldas eseten
meg utana van egy idozito...

Nos en ennel okosabbat szeretnek. Ami kezeli azt
is amikor pl. furdoszobaban teregetik a mosott ruhat....

A WC szelloztetes meg egyertelmu. De hogy erzekeled?

Mondjuk egyik sem olyan amit kozpontilag kellene
vezerelni ))

No, hogy ne hagyjam nyitva a feltett kérdésemet, megoldottam a "100méteres" problémát. A hiba kereséshez levittem a BaudRate-t 3600-ra, majd felvettem a PC-re hangként, és a SounForge-val vizsgáltam(régi bevált módszer hangfrekire tárolós szkóp helyett ). Láttam, hogy a visszaküldött jelben a központnál mérve van egy hamis lefutó él, ami hamis start jelet generál. A valós startjel kb 0.6ms után jött. Megnéztem a Slave oldalán is("100m-el odébb") és ott a feladott jelben nem volt nyoma az impulzusnak. Rájöttem, hogy a kábel kapacitása tárolja az utolsó jelszintet(nem ürül ki) ezért amikor a központ(vevő) engedélyezi a vételt, akkor a töltés legenerálja a hibás jelet.
Ezt a problémát csak úgy lehetett megoldani, hogy a vétel engedélyezését 0,6msec után teszem meg. A kommunikáció innentől fogva hibamentes lett. A kipróbált átviteli sebeség jelenleg 50k baud, de szerintem lehetne jóval több is, majd kipróbálom, ha szükség lenne rá, de már így is kb. 5000 bájt mehet át másodpercenként, ami ide bőven sok.
A rendszer kezd kerekedni. Ha lesz valami érdemleges jelzem.

Szia atta!
A legfontosabbat biztosan nem mondtam, hogy az érzékelőket hagyományos, egyben szerintem a legbiztonságosabb módon, közvetlenül a központba kötöm be optocsatolókon keresztül. A kommunikáció inkább a vzérlést látja el, ami azt jelenti, hogy a riasztás mindenképpen megtörténik a telefonon keresztül és a hangjelzés is, mivel ezeket a központi PIC kezeli.
A kommunikáció a beállításokat, új alapjeleket, üzemmód kiválasztásokat, kényelmi szolgáltatásokat látja majd el.

Gyakorlatilag egyetértek a véleményeiddel, hasonló megoldásokban gondolkodom. Nem fontos túl sűrűn lekérdezni a kört, de 1-2sec periódust legalább szeretnék, ami szerintem simán megoldható.

Most inkább csak azt kéne kitalálnom, hogy 9600baud-al forgalmazva 30m kábelnél tökéletesen működő viszirány miért sérül 100m-es kábel esetén úgy, hogy az első bájt nem valós értéket ad, de notorikusan egyformán hibázik az egyik bit. Az előremenő ág hibátlan bármely adathossznál, de a visszatérő ág nem. Azt érdemes tudni, hogy a tápot is a kábelen keresztül viszem ki a Slave-hez.

Szia Watt

Ma volt egy kis időm, úgyhogy átolvastam a "lemaradásom"
Erre a problémára tökéletes megoldás a CAN busz, ott ugyanis különböző ID - val lehet üzenetet küldeni ugyanazon a buszon - adat ütközés hardveresen kiküszöbölve. Nagy megbízhatóságú rendszereknél (pl. forgalomirányítás - ahol 100ms időd van arra, hogy észrevedd, ha egy izzó hibás vagy hamis feszültségen van) CAN buszt használnak. Ugyancsak ezekben a rendszerekben az összes periféria kártyát figyelik, egy ún. életjel segítségével (pollozás). Ha nem jön életjel egy adott ideig, akkor a rendszer hibát jelez, és lekapcsolja a feszültséget az izzókról/vagy sárga villogóra vált.

Viszont te nem akarsz CAN buszt használni . Ebben az esetben is meg lehet oldani (Pl. RS485 - tel). El kell döntsd, mennyi idő alatt akarod lereagálni, ha meghibásodik valamelyik érzékelőd. Ennek az időnek az egyharmadával küldesz "életjeleket". PL. az érzékelő által küldött adatcsomag így néz ki: IDIDIDJJJJEEEECRC ahol ID az azonosító, pl. első mozgásérzékelő ID 0xAA50, második mozgásérzékelő ID 0xAA51, stb. Hőérzékelő:0xBB50, stb. JJJJ - életjel, ami lehet egy folyamatosan növekvő szám 0 - tól 64 - ig (vagy ahány bit rendelkezésre áll) - így tudod hogy működik a rendszer + tudod hányszor hibázott. Ha három egymást követő ciklusban nem növekszik a szám, vagy túl nagyot ugrott, vagy bármi rendellenesség van, akkor tudod, hogy az érzékelő "elromlott" (levágták vagy akármi ). EEEE - esemény , CRC - CRC. Ha többször jelez az esemény, akkor lehet riasztani, bár ez ugyancsak elég nehéz ügy. Egyik ismerősöm cégénél 2 naponta riasztott a riasztó, amíg megtalálták a pókot, amelyik állandóan le/fel huzogatta magát a hálóján a mozgásérzékelő előtt Azóta takarítónőt cseréltek

atta

Most egy picit off leszek.
Eddig ez a topic elkerülte a figyelmemet! De végigolvasva nekem a Reszkessetek betörõk címû klasszikus film jutott eszembe.
Hamár eljutottak az ajtóig akkor kegyetlenül meg kell keseríteni a rablók a dolgák. Pl.: egy tesla tekercset elhelyezni a bejáratnál aztán hadd szikrázon a fazon vagy fûtõszálat a kilincsbe... ha igény van rá akkor még sorolom
on:
itt ajánlották a kültéri szürkület kapcsolót. Azzal csak egy baj van. Ha a környéken sok a háziállat, akkor azokat le kell szoktatni róla, hogy kapcsolgassák. (nálunk a macskák már simán elmennek, ugy hogy nem kapcsol fel)

Babinyo
Kösz az oldalt! Jó kis rendszer. Kíváncsi lennék az árakra.
Kicsit kevésnek tartom a NODE-ok max számát és túlzottnak egy NODE portjainak számát. Igaz ezzel szinte mindenre fel vannak készítve, de egyben túl költségesek is. Nálam egy Slave ára max 2e Ft körül van(önköltségi ár). A felhasznált feladatnak megfelelően speciális Slave-ket alakítok ki, ami több törődést igényel ugyan, de jelentősen olcsóbb, ha az egészet nézem. A CAN busz tetszik, de az eszközeim nem támogatják, viszont az RS485 legalább annyira bizalomgerjesztő(elvi 2,5Km, 250Slave stb.), csak a hibakezelést erőből kell megoldani. A valóság jelenleg az, hogy vannak gondok a kommunikációval, ezen dolgozok. Érdekes, hogy a központtól elküldött bájtok megérkeznek tökéletesen, de amit a Slave visszaküld annak az első bájtja hibás. A többi nem. 30m kábelnél még nem 100m kábelnél viszont jelentkezik a hiba. ölet????????

sziasztok
nemtudja véletlenül valaki hogy egy siemens m35 telo hány mAh-t vesz fel hivaskor vagy fogadáskor
elöre is köszönöm
üdv

Helló!

Keresgettem a neten és ezt az oldalt találtam, ami témába vág, ha már ismert akkor bocs az ismétlésért.
http://www.silex.hu/html/FreeDome/freedome.htm

További fejlemények:
A kommunikáció 100m-es próbája is jó eredménnyel zárult. A feltekert 100m-es sima CAT5-ös UTP kábeltekercs közepébe beletette a pákám trafóját. Semmi negatív jelenség, vagy hiba.
Jelenleg a PC->Központ->Slave parancskiküldési módszeren dolgozok. Már majdnem kész. A keret egyforma, bármelyik Slave egységet meg lehet szólítani, parancsot, és ha van, adatot küldeni, róla beolvasni adatokat, ha a parancs ezt kéri stb. A Slavek szobai egységei képesek az önnáló működésre(hőfokszabályzás), csak az alapjelet kell átadni nekik. Az ébresztés és riasztás esetén a Slavek kapcsolják be a megfelelő hozzájuk tartozó hangszórókat és a villanykapcsolás + hangnyugtázás is megoldva egy, vagy több párhuzamos nyomógombbal ami akár a villanykapcsoló is lehet. A Slavek saját hőmérőiről be lehet olvasni a hőfokokat a központba, majd az adatgyűjtéshez. Hiba és állapotregiszterek tartalmát szintén át tudja adni a Slave egység.

Sajnos nem csak ezzel tudok foglalkozni, ezért húzódik a dolog, de mindenesetre érdekes és jó móka egy ilyen rendszer felépítése, életre keltése. Ha valamelyikőtöket érdekelnék a részletek szívesen megtárgyalom!
Ha van további ötletetek, ne kíméljetek!

Sziasztok!
Elteltek az ünnepek és a fényfüggöny project után ismét a lakásriasztó számítógép központ lett a fő kérdés a szabadidőmben.
Elkészült néhány próbanyák, és a kommunikáció már részben működik(csak a CRC rész nincs még beprogramozva) Tudok Slaveket kiválasztani és parancsokat végrehajtatni velük. Csináltam néhány képet a próba áramkörökről. A képen nem biztos hogy kivehető minden, ezért néhány szóban elmondanám, hogy mi van rajta. A két nagy PIC közül a nyákhoz képest keresztben és bal oldalon lévő PIC egy 18F458, ő a központ. A másik hossz irányban lévő egy 18F4320 ő a Taszt egység, rajta egy LCD kijelzővel. A kiálló nyákok 75176-os RS485 vonalmeghajtó IC-k. Jelenleg otthon 9m S-UTP kábelem volt ezért nagyobb távolságot még nem sikerült kipróbálnom, de 9m-ig már biztosan működik. A lógó ellenállások 1,5k-sak ezek a soros vonal szinteket stabilizálják.
A központ a PC-hez is csatlakozik egy 74125-ön keresztül. A soros kommunikácó irányát ki tudom választani (PC(RS232), PIC(RS485), és később majd mobiltelcsit is(RS232)), mindezt a PIC USART portjának felhasználásával.
Akkor a képek:
www.wattmep.tvn.hu/public/DSCF0001.JPG
www.wattmep.tvn.hu/public/DSCF0002.JPG
www.wattmep.tvn.hu/public/DSCF0003.JPG
www.wattmep.tvn.hu/public/DSCF0004.JPG

Várom a további ötleteket is! Köszönöm!

CCD-t valószínûleg jó drágán adogatják boltban, de inkább a számítógépes webkamerák terén kell nézelõdni. Régen állítólag memóriaIC "skalpolásával" csináltak kamerát.
Üvegszálat viszonylag olcsón is lehet keríteni, ha nem kell csúcsminõség. Iskolai célokra pár éve valami 60Ft/m volt, de már nem emléxem hogy hol.
Esetleg az agenda.hu-n nézz szét - ott találtam most néhány optikai kábelt.

Erre van szükségem!


Igen van és másokat is bátorítok, hogy engedjék el a fantáziájukat!

Az központi óra ötlet annyira jó, hogy gyakorlatilag már majdnem működik. Minden szobában van(lesz) egy Slave amin van egy-két nyomógomb, meg LED-es számkijelző. A gombok az ágyaknál, foteleknél lesznek(vagy ahol jó). Alap helyzetben villanykapcsoló is, de ha az előre és "névre" programozott időpont szerint megszólal az adott szobában lévő hangszóró, akkor azt is ezzel lehet nyugtázni. Több ébresztési időpont beállítható, naptól napszaktól függően, és "talán" még egyedi hangokat is tudok az ébresztéshez rendelni. (Ébresztő hétalvó, 11:30 ! )

A fűtés dologban nem tudtok meggyőzni, de ez ne zavarjon benneteket. A szigetelés dologban egyetértek, és csak megjegyzem, hogy egy 5cm-es hugarocel "dobozban" lakom De tényleg azt gondoljátok, hogy pl. a fürdőszoba külön fűtése értelmetlen? Miért?

CCD-kről tudsz valami infót? Lehet külön kapni? (hol?)

A nagyfeszt le lehet vezetni, és a kábeleket falban kell vinni védőcsőben. Persze lehet falat bontani meg minden, de nem egy bankot akarok védeni! Az optós leválasztás indokolt.
Üvegszálas átvitel? Nem rossz!!

Sziasztok!

Sajnos csak elméleti síkon vannak ötleteim, melyekhez nem sok gyakorlati megvalósitási tanácsot tudok adni:

Az időzített redőnyfelhúzás/leengedés nem lenne rossz

A fűtéssel kapcsolatban szerintem (s)nincs értelme túlzott bonyolításnak/elaprózásnak. Gondoljuk acsak végig, hogy hol veszik el a sok energia : falak, ablakok, légmozgás, tetőszerkezet, padló, stb. Én inkább amire fordítanám az időt : szigetelés, levegő előmelegítés, napkollektor (és annak a PIC-es vezérlése:)

Mozgásérzékelésre CCD-t vagy valami hasonlót használnék. (nem kell nagy felbontás) Gondolom, hogy egy PIC-el össze lehetne kötni. A program maga elvileg egyszerű, hiszen egy letárolt képhez kell hasonlítani a pillanatnyi mintát és x% eltérés esetén riasztás.

Ha betörő lennék, akkor csináltatnék valami nagyfesz kütyüt (pl. 10KV), majd ezt pl. a hálózatba/riasztó vezetékébe vezetném, miáltal feltételezem elszállna minden elektronika -> épp ezért optokapus megoldást alkalmaznék. Távolabbi pontok adatátvitelére sem lenne szerintem rossz ötlet az infra (esetleg üvegszálas??) átvitel...

A nappalikban általában többféle és többféle erősségű fényforrást illik használni attól függően, hogy éppen mit akar az ember csinálni -> programozható kapcsoló?? pl. gyengébb/erősebb háttér világítás + olvasólámpa, stb.

Az egyik "nagy" fogyasztó a hűtőgép. A nyitogatások és bepakolt cucc mennyiségétől függő hőfokszabályozás, amit megspékelnék megfelelő időzítéssel (kiiktatva a bimetálos megoldást a sajátom esetében).
Esetleg jöhetne még egy reggeli automatikus kávéfőzés:)

A lakás több pontján is lehessen zenét hallgatni és vezérelni.

Ha jól tom, akkor van valami ózonos légtisztító kütyü. Ezt jól lehetne hasznosítani téli időszakokban, vagy ha valaki beteg , ha mindennap bekapcsolna x percre.

Nálam állandó probléma, hogy ahány óra van a lakásban, annyi különböző időt mutat. Nem lenne rossz egy "globális" időmérő csoda. ( a szobai slave-ek a mastertől kapják a jelet.)

Egyelőre ennyi jutott az eszembe. Remélem lesz valami használható is hosszúra nyúlt álmodozásomban.

bye

Mindenkinek Boldog Új Évet Kívánok!
Jól leült ez a topic, alig találtam meg! Továbbra is kérem, és várom nagyszerű ötleteiteket! Mit tudjon egy házvezérlő számítógép? Mit mérjen, mit mondjon, mit regisztráljon, mikor szóljon, milyen érzékelőket érdemes használni, források stb.

vlezlee
Jelenleg is pont egy érzékelő van, és attól függően, hogy merről fúj a szél(nagy szél), az egyik szobában meg lehet gyulladni, a másikban pedig hűvös van. Az is elég gáz, hogy amikor este 6kor a fürdéshez készülve az asszony felemeli a termosztátot, akkor mindenhol meg lehet fulladni a melegtől 8-ig. Ez egyrészt kelemetlen, másrészt haszontalan. Szóval nem érzem, hogy tólbonyolítanám a dolgot, és nem hiszem, hogy a Slavenként ~1000Ft ne fizetődne meg egy év alatt a gáz árából!


Maximálisan egyetértek, és köszönöm a linket. Amiket hirtelen felsoroltál, már részben működnek, és ami nem az folyamatban van, csak most fényfüggönyt kell csinálnom karácsonyra, ezért csúszik a project.

Watt, mivel cirkós központifűtésed van, szerintem teljesen felesleges és agyonbonyolított dolog, hogy szobánként mérd a hőmérsékletet, bár ekkor valóban nem tudod, hogy szobánként milyen a hőmérséklet.
A központ doboz közelében elhelyezel 1 hőérzékelőt és ezzel meg lehet oldani szvsz nincs agyonbonyolítva és egy csomó slave cuccot megspórolsz!

Esetleg a www.paradoxhun.com címen nézd meg az új digiplex központokat, olvasd el 1-nek a gépkönyvét, rengeteg hasznos infó van benne (címzett vagy relés érzékelők , dupla EOL: 2 vezetéken risztási és szabotázs állapot, rengeteg eseményre programozható kimenetek, teljes körű pc-s felügyelet és távprogramozás a helyszínen vagy telefonvonalon keresztül, grafikus lcd kijelző is van hozzá ...stb).
Szerintem a te igényeidet is ki lehetne elégíteni ezzel a központtal ha nem akarnál építeni, bár a saját tervezést én is jobb 5letnek tartom (tanulni mindig kell).
Ezzel egyidejűleg szerintem érdemes megnézni 1-2 , kifejezetten ilyen célokra tervezett profi cucc tudását is!

Ui: ha a doksikat csak felhasználónév és jelszó párossal lehet letölteni, akkor szintén ezen az oldalon vagy a www.paradox.ca címen ingyen tudod regisztrálni magad.

Netter
Értelek és talán igazad is van, de azt mond meg, hogy akkor mi van, ha pl. a külső kapu egységet valaki levágja, hogyan fog beszólni, hogy baja van? Vagy egy Hőmérséklet beállításáért felelős egység meghibásodik, hogyan fog beszólni hogy már nem jó? A telefon levágása nem történhet meg, de tudom, hogy ezt nem ezért hoztad fel példának.

Szerintem az a 36000 nem olyan nagy szám! Hiba pedig ne legyen, és ha még is van, arról tudni szeretnék! Az a 0,1 sec csak a kritikus perifériáknál lehet fontos, a többit lehet ritkábban is. Nem érzem én ezt a polling-ot olyan vészesnek, viszont a megszakításos módszert igen, mert akkor mindenhonnan egy-egy vezetéket be kell hozni pluszban és erre lábat is kell áldozni, ami mindig kevés ugye! Esetleg a soros vonalon lehetne a megszakítást jelezni? Akkor ütközés figyelést és kezelést kéne írni. Fene tudja, lehet, hogy a kevésbé fontos slaveket eseménykezelté teszem, és az ellenőrzést időszakossá, majd meglátom.
Mindenesetre köszönöm, hogy elgondolkodtattál!

Watt!

CRC -vel kapcsolatban egyetértek. Itt jobb ez a választás.
Viszont a folyamatos lekérdezést (polling) meggondolnám. Egyrészt feleslegesen nagy forgalmat fogsz bonyolítani a buszon, hiszen csak 1 óra alatt 36000 lekérdezést jelent, ha 0,1 secenként szóra bírod a perifériákat amik rendszerint azt fogják mondani, hogy nem történt semmi. Másrészt ha mégis betörtek és lecsapták a telefont a buszról, akkor hiába látja a pic, hogy nem válaszol, nem tud riasztani. Nem akarlak lebeszélni a dologról, de én nagyon meggondolnám ezt a lekérdezéses módszert. Ráadásul az esetleges hibák valószinűsége is nagyságrenddekkel nagyobb, ha folyton beszélgetnek a cuccok. (tudom, erre kell a crc)

Eseményvezérelten nyugodtan aludhat a pic (sleep), majd szólnak neki, ha van valami újság. Ez az elterjedtebb technika és nem véletlenül, de biztos nem mondtam ezzel újat neked. Szerintem úgy kell kialakítani a rendszert, hogy ha történik valami, akkor azt biztosan érzékelje az arra a célra rendelt periféria és tudjon szólni a fő picnek.

NickE

Netter!
Köszi az ajánlatot, ha lesz konkrét kérdésem menni fog!

Nem tudom, hogy a telefon tud e jelet adni, ha SMS érkezett, ezért én lekérdezném időnként(kb. 0,1-1secenként ciklusidőtől függően.). Ez azért is jó, mert tudod, hogy a telcsi él. Én minden Slave egységet lekérdezek elég sűrűn, akkor is, ha nem akarok tőlük semmit. Ezt biztonság miatt gondolom szükségesnek.

A CRC - SUMM kérdés vérmérséklet kérdés is egyben. Nekem tetszik a táblázatos megoldás, és nem tartom bonyinak, viszont elismerten jobb, tehát nincs mit gondolkodnom. Nem vitatom, hogy mindkettő működhet, de ha távolabbra kell vinni egy biztonsági berendezés kommunikációs jeleit, akkor inkább a megnyugtattóbb megoldást választanám, főleg ha a megoldás nem túl macerás.

Most azzal vagyok elfoglalva, hogy miként oldjam meg, ha hibás küldés esetén meg kell ismételni egy csomagot. Rögtön ismételjem, vagy a következő ciklusban? Mi van akkor, ha a vége jel sem érkezik be. Mekkora csomagok legyenek, max. hogy ne teljen sok idő egy Slavvel, azaz meddig várjak egy csomag vége jelre? Meddig várjak egy válaszra? Szóval vannak eldöntendő szinkronizációs kérdések, hogy a rendszer mindenképpen jól működjön. Ezek inkább elviek, de alapvetően fontosak.

crc-ben ez a leírás az egyik favorit. Ez el is magyarázza, hogy mit csinálunk, ami nem árt.
http://www.geocities.com/SiliconValley/ ... 59/crc.htm

Sokféle crc számítási algo létezik. A xorolósat használják a leggyakrabban szerintem.
Volt egy hardverkulcsos projectem, ott használtam eddig csak hibadetektálást. Én checksum (ellenőrzőösszeg) számítást használtam, nem crc -t. A crc elvileg biztonságosabb, hiszen már 1 bit változása esetén nagyban fog különbözni a generált crc, de bonyolultabb, a checksum egyszerűbb és soha nem volt vele bajom.
Lehet, hogy primitiv megoldás, de én az átküldött bájtokat összeadtam (nem foglalkozva a túlcsordulással, hiszen a másik oldalon is túlcsordul majd) és hozzácsaptam az adatokhoz. +1byte
Tökéletesen müködik a kulcs, nem hibázott még soha.

Most olvastam át az egész témát. Miért hanyagoltam az utóbbi időben a fórumot?

Szóval pár éve csináltam DTMF kódos vezérlést az MT8870 -es ic-vel. Kódot kell beütni azonosításként, aztán a parancsot. Ma is használják valami pékségben kemencekapcsolásra. De ez itt más tészta, szerintem nem jó ide dtmf. Csináltam sms riasztót is, sőt most is fogok egyet. Még tervezési fázisban vagyok. Szintén Siemens a kedvenc, mint a többségnek. A korábbi verzió butácska, most pc -vel felprogramozhatót csinálok, amin mindent be lehetlesz állítani klikkelgetbe. Felhivjon vagy sem, sms szövege, telszám, töltés automatikusan, ...
Az sms küldés nem probléma, viszont az sms vezérlésnél nem tudom, hogy hogyan lehet detektálni picel, hogy sms érkezett? A pityegésre gondoltam, az megjelenik a headset csatlakozóinak a lábain, de talán van jobb ötlet is. Időnként ráolvasni elég macera, jobb az eseményvezérelt programozás. Szal a teló szóljon a picnek, de a pic kérdezze, hogy van valami újság?

Csak azért írom, hogy tudok segíteni, doksi, programozás, nyáktervezés, 5let, ...
CAN buszhoz még nem értek, pedig most autodiagnosztika is birizgálja a fantáziám és ott használják, szal neki fogok kezdeni ennek is.

Nektek is szántam, mert a mestereknek mit mondhatnék?
Majd igyekszem komolyabb példákkal is előjönni.

Helló Watt!

PIC ügyben minden érdekel, a honlapod pedig nagyon jól jött nekem, kezdőnek!

A téma ügyében: mostanában kaptam meg a 2005-ös Conrad katalógust, máris rengeteg hasznos cumót láttam a témába vágóan! Hamarosan összefoglalom!