Az USART jó erre a célra, csak ki kell egészíteni egy soros vonalmeghajtó egységgel, ami a távolságtól függően RS232, vagy RS485 lehet. Az RS 232 nem zárja ki a címezhetőséget, csak a megfelelő Master-Slave viszonyokat meg kell teremteni a protokollban.
Master kér, minden Slave veszi a kérést, majd a megcímzett Slave válaszol.
A Protokollt magad is megtervezheted, sokszor egyszerűbb, mint kész protokollt leprogramozni.
Ha nincs ötleted adhatunk, vagy nézelődhetsz kész protokollokat példának(pl a modbus doksi az oldalamon is fenn van, ha jól emlékszem).
A hibakezelést is meg kell oldani, amire szintén sok megoldás van, pl. ez egyik legegyszerűbb az, ha kétszer küldöd el a csomagot, és ha mindkettő megérkezik és egyforma, akkor lehet feldolgozni. Ez csak akkor jó, ha kevés az adat és nem okoz sebességbeli problémákat.
A másik megoldás a CRC. Erről is akad infó az oldalamon.

Azért azt tudni kell, hogy az EEPROM-ok véges számú írást viselnek el. Ha ez egy folyamatosan működő kütyü lenne, másodpercenként 4-szeri írással, akkor nem javasolnám EEPROM-ban tárolni az adatokat, az EEPROM-ot ugyanis nem erre találták ki, hanem inkább a ritkán változó, de el nem felejtendő (pl. konfigurációs, kalibrációs) értékek tárolására.

Ilyesmire valamilyen statikus RAM lenne a megfelelőbb, esetlegesen háttérteleppel megsegítve, hogy tápfeszültség hiányában se felejtsen, esetleg léteznek ún. zero-power RAM-ok, amik egy lítium elemes háttértáplálással együtt vannak tokozva.

E felett valahogy elsiklottam! Jogos!

Köszönöm!!!!!!!!
Megpróbálom remélem sikerül működésre birni.

Na igen, ebbe én sem gondoltam bele mélyebben. Köszi a figyelmeztetést!

Watt, újra köszi!

Tudnátok nekem linkelni egy egyszerűbb statikus ram adatlapját, ami Magyarországon is elérhető?

Watt!

Közben gondolkodtam és talán nem is fontos eeprom-ba beírni, ha mondjuk a gyűjtő PIC programjában nyolc darab változóban tárolom az éppen megfigyelt lábak értékeit és ezeket a változókat kérdezem le a fő PIC-el. Ez így működhet ugye?

Müködik az LCD kijelzés.Csak állitani nem tudom,a gombokra nem reagál semmit.Az alarm led folyamatosan világit.

Persze.
Kérdés, hogy le tudod e kérdezni a PIC-eket úgy, hogy ne legyen adatvesztés, valamint a több egységtől lekérdezett adatokat el tudod e tárolni. Hol akarod tárolni ezt az adat tömeget? Egyáltalán tárolni akarod, vagy feldolgozás után eldobni?
Hány Slave lesz? Az adatok mit fognak befolyásolni?

Azt hiszem nem is beszeltem errol De ICSP-n keresztul tudod irni es olvasni a masik PIC Flash (program memoria) es EEPROM tartalmat is.

Microchip egyebkent sokszor keveri ezeket a fogalmakat es pl megnezed a 41191D.PDF-et, annak az a cime, hogy PIC12F629/675/PIC16F630/676 Memory Programming. Ha jol emlekszem a Microchip oldalan egyenesen EEPROM Memory Programming -kent talalhato meg.



Pontosan, en is ezt irtam, hogy szerintem nem PIC programozo megvalositassal kellene ezt megoldani

Nem fogom tárolni, miután feldolgoztam már nem lesz rájuk szükségem. Egyelőre csak egy slave eszközről beszélek. Az áthidalandó távolság elhanyagolhatóan kicsi. Egyébként Nigel's PIC tutorial oldala szerint már építettem és programoztam olyan eszközt, ami a PIC-ről a PC-nek küld adatokat, de ez még csak most jutott eszembe. ÉS persze itt az I2C-re is van példa, meg a külső EEPROM-ra is. Nem is tudom miért nem jutott ez idáig eszembe. Vagyis ha két PIC-et rs232-vel összekötök, akkor meg is oldódott a problémám. Ugye?

Igen.
De akkor javasolnék egy új protokollt.
Mivel az adatok feldolgozásra kerülnek, ezért a Slave végül is egy mérő távadó szereppel lesz ellátva. Így nincs is szükséged tárolni az adatokat.
A jó megoldás szerintem itt az lenne, hogy a Master a megcímzett Slave-től kér egy mérést, majd fogadja, feldolgozza. Így nem kell a méréseket és a kiolvasásokat szinkronizálni, valamint nem történik felesleges adattárolás sem.

Én csak azt nem értettem, hogy a kérdésben eeprom szerepelt, Te meg flash programmemóriákról kezdtél el hosszasan beszélni. NAgyon ritka, hogy ezt a gyártó másként nevezi, de ők is hibáznak, tudnék példákat, mennyi hiba van az adatlapokban...
Közben láthatod, hogy itt teljesen máshová lyukadunk ki, mint ami az eredeti kérdésben volt, így a zavar a kédésből is fakadhatott, mert nem volt egyértelmű, hogy mi is a feladat...

Szamold ki, hgy mukodhet-e a dolog:

A 8 digitalis bemenet az ugye 1 byte. 1 mp-kent 4 adatgyujtes, azaz 4 RAM hely 1 mp-et tarol, 8 RAM hely mar 2 mp. Csupan azt kell biztositanod, hogy 2mp-enkent mindenkepp kerdezd le a fo PIC-kel, hogy mi az abra, kulonben nem fogod tudni hova tarolni a meres eredmenyeket. Ezt a kepletet meg az is befolyasolja, hogy mikozben kuldod a meresgyujtorol az adatokat, kozben meg merned is kell, es igy ha pl tul keson jo a kerelem, hogy lokd az adatokat, akkor mar a kuldesi folyamat ugyan elindult de meg nem ert veget es meg a buffered nem szabadult fel, tehat jon a meres ideje es megintcsak nincs hova tarolni az uj adatot.

A lenyeg mindig az, hogy a buffered gyorsabban tudd atkuldeni mint ahogy beerkezik. Masik amit szoktak alkalmazni, hogy mindig van egy kis tartalek a bufferben, ami a "specifikacion felul van", egy un overlapping terulet. Ennek megfelelo meretunek kell lennie ahhoz, hogy a fent emlitett problemat at tudd hidalni, tehat, hogy a kerelem mar bejott de a kommunikacio meg nem ert veget - szoval, hogy legyen hova pakolni az adatokat.

Namost mikor a kommunikacio befejezodott, az overlapping teruletet a buffer elejere kell mozgatni nyilvan valoan, es minden folytatodik tovabb. Pl fel masodpercig tart a kommunikacio, akkor meg 2 RAM helyet tartasz fenn overlapping-nak. Bejon a kerelem a 2mp idoszelet legvegen, az ujabb meresek mar az overlappingra mennek, kozben elkuldod a 8 byte-ot a bufferbol, es mikor ennek vege van mar ott van az ujabb 2 meres az overlappingba, amit a buffer elejere tolsz, es ugye a kovetkezo meres mar a 3. byte-tol kerul letarolasra...

Es ha mar igy elbonyolitottuk, akkor jon a kovetkezo tenyezo, az adat meres pontossaga. Ugyanis ha 250ms-enkent meregetsz - gondolom egy interrupt megszakitas segitsegevel idozitve ezt - akkor a kommunikacio miatt ez az idoszelet kisse torzulhat (pl epp a soros vonali kommunikacio okozott egy megszakitast tehat a 250ms kitolodik 251ms-re - most ezek csak hasrautes szeru szamok). Kerdes mekkora lehet a maximalis torzulas es mekkora az elfogadhato?

Erre a problémára írtam a (#258723) hozzászólásomat. Másodpercenként 4x le kell kérdezni a "távadót" és nincs szinkronizációs probléma.

Igazandibol nem a Flash -rol beszeltem, hanem az EEPROM-rol, minthogy annak a tartalmat is lehet irni es olvasni ICSP-n keresztul, de ezen mar ne vesszunk ossze Valoban a feladat kisse mas kepet alkot most mar, amit jol el is kezdtem bonyolitani a fejemben

Ja értem. Jó bonyi megoldás, de lehet, az kétségtelen. De itt bejön a probléma, hogy távoli felhasználás esetében az ICSP vonalat is erősíteni kell. De tényleg hagyjuk, mert másképp alakulnak a dolgok, és szerintem a jó irányba.

Feszültségmérővel végigméregetted, hihetőek a jelszintek? A hőérzékelőnél is normális érték mérhető, a kalibrációs potmétert is próbáltad? Az alarm LED egyébként mit kellene, hogy jelentsen ebben a kapcsolásban, azt nem tudod?

Hiába állitok bármit.Amikor feszültséget kap akkor kijelzi az aktuális hőfokot.Olyan mintha a bekapcsolásnál beolvasná az adatokat,de valamiért lefagyna.Szerintem a hőmérö résszel nincs gond mert közelitőleg pontos hőfokot mutat.Lehet az LCD inicializálásával van gond mint ahogy az előzőekben irtad.Eredetileg LTN211-es modul-lal van tervezve.Csak ilyet már nem találtam sehol.
A lLED-nek a szerepe amikor eléri a beállitott hőfokot bekapcsol a led,persze ezt egy optocsatolóval meghajtható egy relé.

Nézd, én (és mások is itt, a fórumon) nagyon szívesen segítek, ha tudok.

Viszont az áramkört Te látod, Te tudsz rajta mérni, Te tudod leírni pontosan, hogy mit csinál vagy mit nem csinál, illetve Neked kellene azt is tudni, hogy mit kellene csinálnia. A múltkor linkelt oldalra én bepillantottam, de nem mélyedtem el a tanulmányozásában. Amit azonnal láttam, hogy nem kóser (ti. config nélküli a forrás és a hex is, de a szövegben sem említi sehol, hogy milyen config kellene a PIC-be), arra válaszoltam, úgy tűnik, lett is eredménye, mert azért már legalább elindul a cucc.

Ha ilyen, PIC-es áramkört építesz után, ahhoz azért érdemes tisztában lenni a működésével. Itt még a forráskód is meg van adva, abba ha belenézel, ott akár csak a kommentek alapján is lehetne látni, hogy más is van ott, pl. üdvözlőszöveg, meg a második sorba is írkálnia kellene valamit. Én most biztosan nem fogok nekiállni építeni egy ugyanolyat hirtelen, hogy lássam, mit csinál, de ha nagyon fontos, és végképp nem mész semmire, akkor juttasd el hozzám és megnézem - de ez megint egy másik történet.

Szóval azt gondolom, hogy kicsit lehetnél kreatívabb Te is, mert így marha nehéz segíteni, és ezt nem bántásképp mondom.

Köszi hogy segiteni próbálsz!
Leirom mit produkál ez a szerkentyü.Amikor feszkót kap bejön az üdvözlő szöveg verzioszám stb. 1 kép. majd bejön a hömérséklet kijelzés.2.kép. Na innentől nem történik semmi.Bármilyen beállitási próbálkozásra nem reagál.( setup menüben lehet megadni a min., max feszülség értékeket aminél kapcsoljon az eszköz.Valamint a hangjelzést letiltani vagy engedélyezni.)Az aktuális hőmérsékletet is csak akkor jezi amikor ujrainditom, az üzemközben lévő áramkör a sem a hőmérséklet változásra sem a beállitó potira nem reagál.
Azért gondoltam amikor elindul beolvassa az adatokat aztán megáll az egész.

Sziasztok!

Egy kis segítségre lenne szükségem, remélem itt kapok. Egy pic 18f4550-nél hiába nézegetem az adatlapot nem tudom egyértelműen eldönteni, hogy a belső oszcillátor csak az usb órajelének használható, vagy az egész kontrollernek adhat órajelet.
Én szeretném beüzemelni az usb-t is, bár még nem használtam, most tartok a paneltervezési szakasznál, és nem tudom, hogy tegyek-e külső oszcillátort vagy ne.

A segítségeket előre is köszönöm.

USB-hez mindenképpen kvarcpontosságú oszcillátor kell, a belső oszcillátor az usb modul számára nem megfelelő. Igazából nemtudom, hogy hol látod, hogy az usb számára lehetne a belső oszcillátorról órajelet vezetni, mert ilyenről nincs szó az adatlapban. Figure 2-1

Csatlakozva potyohoz meg csak annyit, hogy panelt csak akkor allj neki tervezni ha mar az aramkorod megtervezted es a proba panelen mukodik az aramkor. Kesobb ha kiderul valami nem stimmel akkor maceras a panelt ujra tervezni - probara ezert talaltak ki a lyukacsosokat meg mindenfele csikos paneleket ill a dugdososakat.

Meg annyi, USB-hez nezd meg a PicKit2 forrasat ill a Microchip oldalan van jopar AppNote amik mindenfele USB eszkozoket valositanak meg, ott aramkor is van tervezve es a foirmware is keszen van tobbnyire a Microcip USB frameworkre tamaszkodva. Ezeket noha nemi fenntartassal kell szemlelni mindenkepp jo tampont lehet.

Kicsit elnagyoltan olvastam az idevonatkozó részt az adatlapban, most már látom hogy van itt info rendesen. Holnap pihentebb fejjel átolvasom, és ha még lesz kérdésem akkor majd itt felteszem.

Köszi a válaszokat.

István

Sziasztok!

Lehet láma kérdés, de érdekelne hogy az F628 és az F628A között mi a lényegi különbség? Nézegetem az adatlapokat de én nem látok egetverő különbségeket (mondjuk ez semmit nem jelent.. ) A chipcadnél nincsen TSSOP tokozású 628A tipus csak sima 628. Az "A" tipusra várni kéne 3 hetet. Betehetem a 628 at a 628A helyére mindenféle programváltoztatás nélkül szerintetek?

PIC16F62X → PIC16F627A/628A/648A Migration

Köszönöm !

Hello!
Mint kezdő PIC-fan szeretnék pár kérdést feltenni ezzel a témával kapcsolatban. Nagyon sok ötletem van, hogy pic-el mit szeretnék megvalósítani, csak az a gondom, hogy néha az áramköri ismereteim nem éppen a legmegfelelőbbek. Ilyen tisztázatlan dolog, például a legtöbb kapcsolásban a GND azaz földpont. Persze tudom mit jelent és miaz csak szeretnék csinálni pickel egy sebességmérőt ami elemmel működik, csak a probléma az, hogy hát hogy lesz az elem (-)-ból GND? Vagy ha simán rákötöm a (-)-t a jó helyre akkor nem lesz semmi baja a picknek illetve más IC-nek? Illetve 9v-os elemről táplálást mennyire egyszerűen lehetne megoldani? gondolom fesz stabilizátor IC-vel nem lesz nehéz a dolog, de a PRO-k remélem többet tudnak mondani, hogy mit és hogyan
Másik ilyen kérdésem, hogy LCD vezérlést mennyire nehéz megírni picre és mit kell figyelembe venni (meghajtók illesztés stb.)?
(bocsi, hogy máshol is feltettem csak remélem, hogy így minél több szem látja )

Addig jó, hogy sok ötlet van, amit pic-el lehetne megvalósítani, viszont a továbbiakban nem így kellene hozzáállnod. Először is olvasd el ezt a topikot az ELEJÉTŐL A VÉGÉIG, így egy csomó kérdést megspórolsz magadnak is és nekünk is. Olvasd el Topi cikkeit is itt az oldalon, Nullától a robotokig, vagy valami ilyesmi a címük. Ha végeztél ezekkel, akkor olvasd végig ezeket a témákat is: Link és Link