Mindkettőnek kell a csökkentett tápfesz , de azt is megoldhatod hogy az egész kütyü folyamatosan
megkapja a tápot ,de ha az egyik szabad lábra feszt adsz
csak akkor indul be minden funkció addíg csak az óra "él"
A kondi nem túl jó megoldás , egy akksi tuti hogy kibírja ha mondjuk egy hétig nem indítod el a mocit , viszont a kondi valszeg lemerül .

Ilyenkor a PIC-nek is kell aza feszültség, meg a 4060nak is? Kondenzátor nem teszi meg? Félfarad körüli

szerk:

elnéztem, nem is annyi az értéke. 0,047F

beépítesz egy "memória akksit " 3,6v csak a brovn out detect legyen kikapcsolva

Jó lesz szerintem a 4060. az a kérdés, hogy hogyan kel megoldani, az áramtalanítás után, tehát elfordítom a kulcsot, nem kap áramot a ,,műszerfal,, de az óra számolását folytassa?

Ha a heti 1 perc nem rettent el akkor ne is használj külső időalapot ! Az én kísérleti órám saját időalappal 4Mhz-s kaviccsal kb ennyit tudott .

4060asra én is gondoltam, és a heti 1perc, az nem sok. Úgyis lehet ctrimerrel állítani nem?

Vicceltem , de ha megelégszel egy ,mondjuk heti 1perces
pontossággal, akkor nem is kell külső időalap , Vagy mondjuk egy 4060 as ic 32768 khz-s kvarccal

Nem pazarlás az?

tegyél be még egy picet 3276800 Hz -s kvarccal

A projektembe belebigygesztenék egy Órát, viszont nem tudom még honnan vegyem az 1Hz-et. Nem kell olyan, ami a szökőéveket is számolja (ds1302), hanem csak egy sima kapcsolás, ami pontos 1Hz-et ad. Mit ajánlotok?

"utána meg sírtok mindenütt" Ezt miért mondod ?
tudsz rá példát mondani ? Fejtsd ki bővebben légyszives mire gondolsz .

És szerinted mit kellene tennem? Azért nem rakom egy PIC-be, mert a parsic csak egy alap kezdőprogram, nem érkezik minden adatot fogadni, azért osszuk külön PIC-ekbe.

Jo. Csak utana meg sirtok mindenutt, hogy az asztalon jo volt, de mikor a motorba raktam minden meghulyult.

Szevasz. Hogy miért nem rakunk egy PIC-be mindent? Mert ,,túl sok,, adatot kell feldolgoznia, és így az egyik üti a másikat, elcsúsznak az időértékek, stb. Nem egy profi programozó program, de kezdésnek jó.

Miota tag vagyok csak igy irok. Nem csak ide, hanem tobb mas forumra is. Eddig meg egy modi sem sirt az irasom miatt. Amugy ez a Ti jatekotok nagyon erdekes. Egy egyszeru adatgyujto, feldolgozo, kijelzo keszulekhez minden funkciohoz kulon PIC-et rendelni, majd osszekinlodni hozza valami soros atvitelt azert tulzas. Nem lenne egyszerubb egy PIC-be belerakni mindent? Gondolom RS485 PHY keresztul. Mert aki ipari kornyezetben RS232-vel visz messzire adatokat arrol megvan a velemenyem. Foleg egy komoly gepnel.
Csa Vili

Biztosan nem örülnek a moderátorok ennek az ékezet nélküli hozzászólásnak...
Az adatátvitelt biztosan azért választotta a fórumtársunk, mert ezzel a programmal tud PIC-et programozni, és ennek ezek a lehetőségei illetve korlátai.
Nagyon sok ember ezzel a programmal tudta először életre kelteni a PIC-et, lehet az esztergályos vagy pék esetleg régi rádióamatőr...stb, nem kell ahhoz villamérnöki karra járnia.
A 18-as PIC szerintem ebben a topic-ban nem fog szerepelni, mert a Parsic nem támogatja.
Egyébként használtunk CNC vezérlésű marógépek között ipari környezetben sima rs232 kapcsolatot minden probléma nélkül 15-20m-es (nem árnyékolt) kábellel.
Hagyjuk meg a társunk fejlesztési ötletében rejlő siker lehtőségét.
Egyébként optocsatoló közbeiktatásával is át lehet vinni ezt a sebességet.

Hali
Csak egy eszrevetel. A gepjarmuvekben nem illik hasznalni ezt a soros adatatvitel, mert nagyon zavarerzekeny. Esetleg RS485, vagy CAN busz. Az RS485 sodrott erparon elmegy par szaz metert is zavarmentesen. A CAN busz kimondottan eros zavaru ipari kornyezetre talaltak ki, de az alkalmazasahoz specialis meghajtok szuksegesek. A gepjarmuvekben az ECU es a periferiak kozott altalaban CAN buszt hasznalnak (nem mindenutt), mert ezzel tudjak biztositani a zavarmentes adatatvitelt. Amugy van a 18-as PIC-ek kozott CAN buszos.
Vili

Sziasztok!
Tudom, hogy jelen témához nem illik, de megkérdezem:
Foglalkozott valaki paraméterezhető véletlenszám előállításával Parsic-ben?
A paraméterezhető alatt, azt értem, hogy a 0-tól, xxxx
-ig, határ beállítható, és közel igazi RND függvény alapján dolgozik a progi.
Üdv:
Zsolt

Hello!
Így van, ez is egy "huzalozott" VAGY kapcsolat. Csak kérdés, hogy zavarvédettsége megfelel-e, egy gépkocsiban történő adatátvitelhez?
üdv! proli007

Csak egy gondolat erejéig.

A program 1es lapján van amit a mesterbe tennék. A 2. lapján a szolgákba beillesztendő programrészlet van.

Lényegében egy számláló, aminek az értékét megszorozza 10el. Így "KIMENET" értéke 10 - 20 - 30 stb...

Ezt elküldi mindegyik picnek.
Amelyik picben "KIMENET" értéke 10el egyezik, az elküldi a RPM adatot a mesternek. Ugyan ekkor a többi is vizsgálja az adatokat, de azok nem küldik el a sajátjukat, csak ha a nekik megfelelő feltétel tejesül.

A szolgákban csak az RX állandó 50ms os frissítésüek. Ami megegyezik a mester RX-TX frissítésével.
A szolgák TX-en csak a feltétel teljesülésekor adnak ki jelet.

Most nem érek rá megírni a progit, de az alapelv az, hogy a mester kiküld egy Byte sorozatot a Tx>Rx-re
és ezen byte-ok Pl: 4 Db 101, 101, 101, 1, ez pl azt jelenti ha az egyes szolga vevője veszi a Byte-okat ezek passzolnak egy összehasonlító modul rendszerrel és csak akkor indítja az adást a szolga.
A kettes szolgának a címe Pl: 102,102,102,2, ...
azért kell több byte-s cím, mert így bíztosan nem fordul elő ez az adatsor máshogyan a rendszerben.
keresd az Uart-al kapcsolatos régebbi hozzászólásaimat.
Minden modul minden paraméterrel nem illeszthető egymáshoz össze, vagy ha igen, ne várjuk el tőle, amit nem lehet.
A 2ms-os timer az miért fontos? ez valószínű bezavarja a kommunikációt. Ha lehet válassz nagyságrendekkel nagyobbat.
Proli007-nek: az Rx az "bemenet" a Tx az "kimenet" és ezek ezen elv szerint mindig azok is maradnak, a szolgák Tx-ét lehet diódával kötni a mesterhez, akkor meglesz a logikai szint.
Mindig csak egy szolga ad.

De csak akkor kaphat fals jelet ha hiányzik vagy rosz egy pic , tehát normál üzem közben nem jöhet elő ilyen hiba .
Ha nincs jel a szolga bemenetén akkor is ad adatot , 00000000-

Ok, vissza néztem, csak nem úgy értelmeztem a programot. A lábak nem voltak elnevezve, csak SX.X

A baj viszont az lenne azzal, ha mindig kéri az összes adatot, de csak 1et kap akkor, a többire is kidobál fals értéket.

Az első próbámnál, ha kivettem az egyik szolga(KMH) pic-et, és az nem küldött adatot, csak az RPM szolga küldte az RPM adatot akkor a KMH is kijelzett össze-visszaságot.

Mennyire igazad van... lesz 4 szabad láb a 877esen.

Azt összekötöm minden egyes másik pic 1-1 lábával. Amin ha jel van akkor az UART kap egy engedélyező bitet.

Lényegében a program a rámegy a 877esben a bit-byte konverter után az UART DATA (receive RPM) és egy kimenet felé, RC.1, az ACT lépteti a számlálót.
Aztán a második esetén az RC.2 és UART DATA(Recieve KMH) és ACT láb lépteti ismét a számlálót.

És így tovább a 4. pic-ig ahol kezdődik elölről.

Mivel a pic-ek ben 250ms a frissítési idő. Itt meg 50ms onként kér, mire végig ér a 4*50, még mindig az első frissítés után tart a többiben a számláló. Lehet elég lesz a 80ms frissítés is az LCDre és ezekre a műveletekre. És akkor mindig új adatot kaphat.

Na már csak kell még 2 628A-t szereznem.
Most vettem észre, hogy az egyik 628asom nem A hanem 04/p(4MHz-es)

Én nem így gondoltam a dolgot !
hanem hogy a mester pic három külön lábon küldi ki az adásindító jelet a szolgáknak . Tehát ha 3 szolga van akkor mindhárom kap egymás után lekérdező jelet
ami a szolgában indítja az adást . Tulajdonképpen simpi is ezt írta csak másképp fogalmazta meg . És ha jobban belegondolunk proli ezt fejelte meg az rs ic vel

Hello!
Igen, de kimeneteket nem lehet összekötni. Ha pedig ezt ellenállásokon keresztül teszed meg, akkor a vevő bemenetén nem lesz meg a logikai jelszint, hiszen az ellenállások feszültségosztóként fognak működni. Tehát megoldás lehet egy háromállapotú meghajtó használata, amit adás idejére aktiválni kell, vagy nyitott-kollektoros tranyó (Fet) meghajtók összekötése, ahol a vevő bemenetén van a kollektor ellenállás. (Mint ahogy ezt az I2C és egyéb buszok is alkalmazzák.) Korrekt megoldás, egy RS485-ös meghajtók és egy vevő lenne. (De annak adatátvitelét is vezérelni kell.)
üdv! proli007

Pedig lejjebb dacsbi lényegében párhuzamosan kötött pic ről ír.

A tippedet átdolgoztam. Így az első frissítésre olvassa az elsőt, aminek a visszaigazolása olvassa a másodikat.

Ez szép... de honnan tudja a Szolga, vagyis az adó, hogy mikor kell adnia?

És azt hogyan hangolom össze?

Hello!
Azt is tegyük hozzá, hogy a mester-szolga kapcsolat hardver részét is ki kell dolgozni, hiszen több kimenet nem kapcsolható össze, a Parsic-ban pedig nem lehet a kimenetet váltani, még nagy-impedanciás szintre sem..
üdv! proli007

Én valahogy úgy próbálnám , hogy a mester indítaná az átvitelt , és az ack jel egy számlálót léptetne a mesterben ami indítaná
a következő szolga lekérdezését . Minden szolga kapna a mestertől egy egy lábon lekérdezés indítójelet . Valahogy így