Felfüggesztem ezt a vonalat. Semmi értelme, csak bele gabajodni, mert lassan nem tudom honnan indultam, és mi volt már és mi nem.

Megrendelem az összes alkatrészt ami kelleni fog. Alapszinten összerakom, hogy tesztelni lehessen a kommunikációt 20MHzn sorba kötve. Ha nem lesz késés akkor nem kínlódok, ha lesz akkor agyalok tovább.

A kérdés még
1., az, hogy 2 pic 1-1 lábát szabad-e direktbe üsszekötni.(kaqkk ötlete alapján küldő a jelet a másik picből aktiválni)
2., Honnan tudom mekkora ellenállást tegyek egy 2 lábú termisztor és a +5V közé. Ha jól értettem a régebbi hsz-eket, a termisztor és az ellenállás közös pontjára kell a lábat kötnöm.(nincs adatlapom a termisztorról) Mérjem meg 25C-on az ellenállást? Vagy 100C-on?

Teljes megakadás...

A program 250ms intervallumon belül 50ms-onként kellene adatot fogadni. Vagyis az első 50ms-ban az első a második 50ms ban a 2. és és így tovább.
A LCD 250ms ban frissít, így az alatt mindig új adat érkezne be egyenként a pic-ektől.

A 877es fogadja a KMH és RPM változó adatait.
Számlálóval leválasztva. Vagy is 50ms-ig csak az első pictől érkező adatot kellene fogadnia, amit RPM változóként meg kellene jegyeznie.
A második ugyan így KMH változóként jön és kellene megjegyezni.

Eredmény:
628/1 Lásd, bejön 250ms alatt 8 jel akkor 8 az RPM értéke amit elküld a 877nek
628/2 számláló 1mpenként léptet és KMH változó adata annyi amennyi éppen.
877 A felső sorba kell kijelezni az RPM értéket legalsóba a KMH-t.

Ar RPM adatait ki írja az alsó sorba.

A rossz hogy ez így nem jó.
A jó, hogy legalább van valamiféle Kommunikáció.(Eddig az se volt csak egyszer véletlenül.)

Inkabb olvassal

Akor azt kell irni, nem ACK-t.

Az előbbi "választ"(?), az emberi kommunikációdra tudnám ugyanígy elmondani.
Nem akarom folytatni...vettem három nagy levegőt...
Nem az I2C kommunikációról volt szó pillanatnyilag, hanem a három PIC-ek között próbálunk UART segítségével adatforgalmat létrehozni.
A Parsic Uart moduljainál lévő ACK-ról van szó, pontosabban ott ACT- nek van rövíditve...

Bocs,, hogy én is beleszólok, de olvass már vissza mielőtt leugatsz valakit. Egyáltalán nem I2C-ről volt szó.

Mar bocsanat hogy belevau, de ha nem ismered a I2C kommunikacio alapjait, akkor inkabb ne beszelj rola. I2C doku 15. oldalt (ne csak azt) olvasd el legyszives. Vilagosan leirja, hogy az slave altal vett byte-ot az "ACK"-val nyugtazza a masternak, ugyanigy a master nyugtazza a slave altal kuldott adatot az "ACK" bit segitsegevel. Az SW I2C megoldasoknal nagyon figyelni kell erre, mert kulonben elakad a kommunikacio, es varhatsz napestig a slave valaszara.

Ha megnézed a gyári példaprogramokat, akkor ott is látod, hogy Pl: a vételnél be van iktatva az ACK lábra egy 20ms késleltetés.
Ettől eltérni nem célszerű.
Ebből is látszik, hogy az ACK az nem az ellenállomásnak szól, (hogyan is szólhatna így)hanem a programban lehet használni segédletként.
Nézd meg a gyári segédprogramokat is az Uart-hoz.
A 2ms és a 100ms között 50x-es eltérés, ez idő alatt sok mindent meg lehet csináltatni a PIC-el.
Nyilván az 1s az nem komfortos, csak példaként említettem. az adott mondatban.

Na eljutottam odáig, hogy a mester kommunikál az 1es pic-el, párhuzamos kötés esetén.

Igaz nagyon-nagyon lassan, sok késéssel.

A másodikkal is kellene kommunikálnia, ha az elv jó.
Ha jól sejtem a probléma az adat vissza igazolással van.

Vagyis mikor a mester kiküldi az adatot, amit mind a kettőnek értelmeznie kellene, csak az egyik értelmezi. A másik lehet meg se kapja, mert az első gyorsabb kicsit és leigazolja a fogadást mielőtt a második meg kapja.

Jól sejtem ez lehet a baj....
(most 50ms 100ms és 250ms és 500ms és 1sec frissítésen próbáltam, mindegyiknél csak az 1es pic-el kommunikált, nagyobb idő alatt, nagyobb eltérések adódtak csak, de volt kommunikáció)

Ha rá rugok a gázpedálra akkor a motor felpörög 3000ig és vissza esik 1000re 1.2sec alatt.

Ha 1sec a mérési idő, lényegében meg se fog moccanni a fordulatszám mérő.
Ha pl. utcán haladok és kiforgatom 6200ig, és felváltok egy sebességet, mire vissza esne a fordulat, már 1000el megint feljebb van.
Ez alacsony fordulaton nem gond, de váltás határon már 1sec 250-300fordulat, a szelep becsörgést jelentheti, ami töréshez és motor széteséshez vezethet.

Az 1sec teljesen jó, egy számítógépbe, ahol 99% statikusan állandó a fordulatszám. De egy autóba 100ms az ideális.
A 250ms már darabos de kompromisszumos megoldás.

De ettől függetlenül jó a program, lényegében ha jól látom a programot a 250ms leosztását(2ms x125 =250ms) vetted le róla. A többi ugyan az.
RBx - számláló - tároló, amit a frissítési idő vált 0 vagy 1re és a 1nél kiküldi.

Ez van nekem is, mert ebből és egy másikból loptam az időmérést, a frissítés nálam 250ms.
Az LCD-n is ha kell, de mégsem kommunikál 3 pic párhuzamosan.

2db egymással 2ms on is jól kommunikál eddig azon volt.
3pic csak sorosan de már késnek.(1200nál még csak 1000 mutat, bár ez orvoslódik 20MHz val. Most 4Mhz)

Nincs ötletem a párhuzamosan kötött picek hogy tudnának kommunikálni.

És most nem a sebességről van szó. Mert ha 1mp el léptetek egy számlálót mind a kettőben, akkor sem kommunikálnak.

Két dolgot csinálnék másképpen, így első ránézésre.
A 2ms az nagyon rövid idő, azt mindenképpen nagyságrendekkel megnövelném, ennyi idő alatt nem fog kommunikáció lefutni...
Régebben egy freki mérőnek vagy fordulatszám mérőnek simán elég volt 100ms időalap (vagy még 1s is!) maradjunk egyenlőre 100ms-nál, de lehet akár 200ms is. ehhez próbáld alakítani a mérésed feldolgozását.
A mérésbe mindenképpen kell egy átmeneti tároló, ne az aktuálisan töltődő számláló pillanatnyi értéke kerüljön ki a kijelzőre. erre tettem fel régebben példát.
A kommunikáció előtt miért van az "és kapu" és ráadásul azzal a rövid időalappal...
A Parsic rajz sok mindent elbír, de gondoljuk csak végig
mi történi a processzorban, nem biztos, hogy ezt vártuk töle. Főleg ha több "határt" is átlépünk egyszerre.
És csak az egyik (628A) Pic-el foglalkoztam...
Ehhez hasonló méréssel próbálkozz.

Örülök neki...
Egyébként ha megnézed, van ott egy gombóc is valahol pluszban...

ACT=Aktív
Magas szinten van amíg az adás vagy vétel folyamatban van. PARSIC helpjében is leírja.

dcsabi, kaqukk, többiek...

A párhuzamosan kötött adatátvitelt nem sikerült megoldani.

Az elv a következő volt a teszt során.
A szolga pic-ekben 50ms-onként kéri a KIMENET változó adatait.

Ha ennek a változónak értéke =10 el akkor az első szolga pic elküldi 2ms os frissítéssel a RPM értékét.
Ha 20al akkor az első nem csinál semmit hanem a második küldi el a KMH értékét.

A mester picben lévő számláló 50ms-onként elküldte a KIMENET értékét, amit az én logikám szerint mind a két pic megkapott és feldolgozott. Ugyan akkor mikor elküldte, és a kimenet értéke 10el vagy 20al volt egyenlő ugyan így 2ms os frissítéssel fogadta a RPM vagy KMH adatot.

Sajnos nem találtam példa programot erre. Az uart modul ACT( visszaigazoló láb) működésére nem jöttem rá. Fórumot is vissza olvastam de nem találtam rá... (Lehet sok száz hsz. közt elvesztem)

Valakinek ha van magyarázata leírása az ACT láb használatáról lehet sokat segítene.

628_RXTX és 628_RXTy a két szolga pic külön külön programja.
877_RXTX a mester pic programja.

4MHzra cserélve minden, mert az egyik 628as csak azon megy...

Én nemrég építettem egy hőmérőt, be is linkeltem ide. Ott 6db kijelző van hajtva, egyáltalán nem villog, a fényerő is jó, pedig még mást is csinál a pic. A lényeg, hogy a multiplexelést ne a parsic-al csináljátok, hanem egy include fájlban legyen, amit mainprogramként hívogat a parsic. Ha kell majd felteszem ide.

Ilyen sok kijelző egyidejű meghajtását villogásmentesen szerintem kemény feladat lesz megoldani, főleg ha a mikrovezérlőnek mást is kell csinálni a kiíráson kívűl.
Akármilyen is a program, ha ASM-ben van megírva 1db kijelző legfeljebb az időegység 1/40-ed részéig aktív. Ha sikerül is egy nagyon optimális programot írni és a mikrovezérlőt 20MHz-el hajtani, a villogás eltűnhet de a kis fényerő problémája akkor is fennáll.
Én megfontolnám a helyedben minden kijelző elé egy tárolós BCD/7szegmenses dekóder beiktatását pl:CD4543
Ez tuti villogásmentes akár több ezer kijelzővel is
3db 4067-es alkalmazásával pedig nem kell kettő PIC sőt egy 18-as lábszámú is bőven elegendő.

Én már csináltam azzal egy projektet, ahol 7*4 volt és tökéletes, csak nekem most kB 20 kellene! ill. 2*20 és arra gondoltam 2 16f877 menne bele smd kivitelben. De még kitalálás alatt van.

Nekem ez alapján volt megcsinálva. 4x7 szegmens és nem villogott.
Ettől függetlenül, lehet ha több szegmens van akkor villog.

Hol a te példád, mert az is érdekelne.
mert ha nem bírja a több szegmenst akkor valamit majd ki kell találnom mert 8x10 ledet kell villogtatnom majd.

A parsicos 7 szegmens kijelző ha már nem magában állt áll a programban szemmel láthatóan villog használjátok az általam feltett példát az garantáltan jól működik

Ezt vágom! Nem is a bekötés érdekel, hanem az, hogy mennyire marad jó a kijelzés, ha sok kijelzőt használok, illetve programban hogy lehet mondjuk 20 kijelzőt le kezelni?

1 db 7 szegmenseshez 8 láb kell minimum.
2db 7 szegmenseshez 9
3db hoz 10

1db esetén 7 szegmens negatívja 7 láb és egy pozitív a 8. láb.

2db esetén 7 szegmens párhuzamosan kötve
és az első szegmens pozitívja 1 lábra a második szegmens pozitívja másik lábra.

Amelyik pozitívon megy ki áram az a kijelző világít.
Gyors egymás urtáni váltogatással, folyamatos kijelzést lát a SZEM.

Ban példaprogram parsic könyvtárában.

lenne egy kérdésem! Mennyi az a maximális 7 szegmenses kijelző amit 1 picel meg lehet hajtani? 2*20 as LCDvel akartam megoldani egy projektet, de nem jó, mert kocsiba menne, és csak szemből jó oldalról már alig látszanak a számok! Egyébként egy fekete alapon zöld kijelzésű LCD nagyon jól néz ki, csak szemből. ):

Nem értem! Ha jól látom csak a timer1 et vetted vissza 250 ms-re. már tegnap este óta megy gyönyörűen!

Nem tudom, hogy működött-e, mert nem kommunikált 20MHz-n.

Naturba saját magát a működést nem próbáltam, de szerintem nem fog menni.... de aztán lehet, hogy mégis.

köszi a választ akkor megyek és megveszem azt az 1 darabot ami a boltban van!

A 16f628 04/p 4 MHz feletti mukodese nem garantalt !! Adatlap olvasasa sokat segit. A Trabant mennyit fogyaszt 200 km/h nal ?

Üdv. mindenkinek

kkrisz75 szeretném megkérdezni hogy a 16f628 04/p az csak 20mhz-n nem komunikált neked vagy egyáltalán nem? válaszod elöre is köszi

Csak ennyit...

Mit módosítottál ezen a progin? Már vagy 3-4 perce megy lefagyás nélkül!

Szerintem nem megy az I2C kommunikáció rendesen...
Nálam hetekig ment mikor megírtam, aztán átalakítottam egy Ricoh RTC óra Ic olvasási tesztre...
Az analóg szenzor teljesen máshogy müködik itt az Lm75-höz viszonyítva.
Kipróbáltad az általam lefordítottat is?
Próbáld meg ezt is...