Küldeni nem fogok megszakításban! 500ms-onként kijelez és adatokat küld. A küldés a főprogramban történik. Ha épp a küldés közben jön adat akkor a küldés addig félbemarad, a fogadás után pedig folytatódik. Ez azt a PIC-et amelyik fogadja a jelünket nem zavarja, nem is nagyon fog tudni róla hogy két bájt közt nagyobb szünet lett mint ami szokott lenni. Nézd meg legutóbb amit írtam, ott minden érkezett bájt után vár hogy jött-e következő bájt. Ha nem jött akkor megkérdezi hogy jött-e következő bájt. Ha nem jött akkor megkérdezi hogy jött--e következő bájt. Ha nem jött akkor megkérdezi hogy jött-e következő bájt.... Ha viszont jött, akkor azt is elmenti majd megint megkérdezi hogy jött-e következő bájt...

Az én szótáramban a "P" betűnél nem szerepel olyan hogy próbapanel. Én olyat nem szoktam csinálni, hamarabb legyártok egy nyákot és beültetem mint összedugdosom egy próbapanelon aztán egy halom vezetékkel összekötözgetem az alkatrészeket... Tőlem soha nem is láthattatok olyan képet amin próbapanel meg drótdzsungel van. A drótokat utálom!

Otthon azért nincs semmi műszerem mert a munkahelyemen sokkal többet tudok az elektronikával foglalkozni, forrasztgatni stb. Meg benn a melóhelyen jobban el is férnek.

Akkor tudod mit, csináld úgy ahogy akarod, ha rám hallgatsz! ...

De miért nincs idő rá hogy a megszakításban megvárjuk hogy beérkezzenek az adatok? Kb nagyon maximum 10ms lesz ez az idő. Ezt miért nem lehet megszakításban tölteni?

Koncepcionálisan rosszul gondolod ezeket a dolgokat. A vevő interruptnak pontosan annyi byte-ot kell kiolvasni, ahány jött. Ami nem jött meg, arra nem várunk az interrupt rutinban! Azért nem, mert lehet, hogy sose jön meg. Akkor pedig beragad a CPU, és csak a reset hozza ki onnan. Várni interruptban csak olyanra szabad, ami garantáltan megjön előre meghatározható időn belül (azaz kb. előre ismert hardver esemény), vagy pár ciklus után feladjuk a várakozást. Jelen esetben ahogy kiszámoltam, 1302 utasítást kéne várni minden egyes várakozás után, ami rettentő sok CPU idő. Ha az interruptba belépés-kilépéshez képest nagyságrendileg több idő lenne a várakozás, akkor igazából értelme sincs.
A helyes megoldás, hogy az interrupt rutin egy pufferba pakolja a byte-okat, és a főprogram értelmezi a bejött adatokat. Neki kell pl. checksumot számolnia, ha az nem jó, akkor kuka az egész üzenet - addig fel sem szabad dolgozni, így logikusan a főprogramnak kell a feldolgozást is csinálnia. A továbbküldésnél is fontos, hogy legyen kimeneti puffer: amikor a kiküldendő bytehalmaz összeállt, ki kell számolni a checksumot, utána, miközben megy a küldés, nem változhatnak a byte-ok - tehát a közben bejövő újabb üzenetet el kell tudni tárolni máshova.
A próbapanel márpedig nagyon jó dolog. Nagyon jókat lehet mérni, tesztelni, 2 perc alatt. A "csináljunk neki panelt" jó játék, csak órákban mérhető. És ha elrontottad, ugyanúgy jön kaparászás, beleforrasztgatás. Faterom még a 80-as években csinált magának forrasztós próbapanelt (DIP foglalatok, lábak kivezetve szép, nagy forrasztható pogácsákra), akkoriban ezek a dugdosós cuccok nem is voltak mifelénk.
Az optocsatolót első körben nem így kell nézni, ahogy itt írták. Fogsz egy PIC-et, az egyik kimenetére adott bitsebességgel 0-1-eket küldesz (CCP modul, 50% kitöltés). Rákötöd az optocsatolóra, a túloldalt meg nézed oszcilloszkóppal. Érdemes terhelésnek egy 100pF-ot is berakni a tranzisztor számára. Addig játszol az ellenállásokkal, míg a fel-lefutó élek értelmesek nem lesznek, és a kitöltés kb. elfogadható lesz. A nem Darlingtonos optocsatolókra simán 5-10mA-t számoljál a dióda áramának, az ellenállásokat meg úgy kell belőni, hogy pont ne nagyon menjen telítésbe a tranzisztor. Ha már jó a szkópon a kép, akkor jó lesz a kommunikáció is.

Szia!
- A bufferelt uart kezelésről már péntek délután írtam Neked.
- 6N138 -cal működik 300 kbit/s -es kapcsolatom is.

- Hurok kezelés: Nézd meg a HP-IL leírását. A hurok önmagát felderíti:
Legyen egy speciális távirat, ami közli a vevőjével a címét. Amíg ezt a táviratot nem kapja meg az egység nem vesz és nem ad taviratokat. Bekapcsolás (újrakonfigurálás) után a mester elküldi ezt a speciális táviratot 1 címmel. Aki veszi ezt a táviratot, beállítja a címét a táviratban levőre, és tovább küldi a táviratot egyel növelt címmel. Amikor a távirat visszaér a masterhez, a benne levő címből a master tudja, hány berendezés van a hurkon.
Ezután címzetten küld azonosítást kérő táviratokat az egyes eszközöknek. Ha ezzel is végzett, az összes berendezés típusa és a címe is ismert.

Másik megoldás: Az egységek úgyis csatlakoznak valahogy egymáshoz vagy a masterhez. A csatalkozón a táp és jelvezetékek mellett legyenek pozíciót megadó fix jelek, amik a különböző csatlakozási lehetőségeknél eltérően vannak beállítva. Az egység induláskor beolvassa a pozíciót és már tudja is a címét...

Csak az utolsó pár oldalt olvastam el, de szerintem túl van lihegve (és így elbonyolítva) ez a kérdés. Ha csak az kell, hogy a mérőáramkör a 4 független, egy dobozban lévő táp paramétereit kijelezze, akkor szerintem kell:
- 1db PICösszesen, a tápegysége pedig független mindegyik tápról
- a PIC földjét, ill. a mérendő jelet egy-egy digitális kapcsólóval a mérendő tápegységre kell kötni a mérés idejére, így a mérés során mindig csak 1 tápegységgel van galvanikus kapcsolatban

Szerintem ez a legolcsóbb, leghatékonyabb és a legegyszerűbb megoldás.

A digitális kapcsoló esetén elektronikus analóg kacsolót értettem (tehát nem relét, azaz mechanikus kapcsolót).

Sajnos az nem működik, amit szeretnél. Csak fizikai relével lehet független tápok között kapcsolgatni mérőáramkört, mivel az analóg kapcsoló nem galvanikusan független a tápjaitól (ergó az összes kimenete és bemenete és a tápja összefügg).

Igen, ezt is leírtam már hogy ne ajánljatok nekem teljesen más mérési elvet vagy mérési konstrukciót mert azzal elvész az áramkör jelenleg univerzitása. Erről itt írtam bővebben: Bővebben: Link
Az analóg kapcsoló nem jó, mert azzal galvanikusan nem lesz független a négy (vagy kettő vagy három) labortáp egymástól. Ezt például relével lehetne megoldani de az kerregne folyamatosan mint az őrűlt, ráadásul egyszerre csak egyet tudna a PIC mérni. A mechanikus relé kiváltására tudok egy nagyon jó és garantáltan működő szilárdtest-relés megoldást amit Skori barátom használ pontosan ilyen célra és szuperül működik is neki. De mondom, ezzel az áramkör specifikusabb lenne, elvesztené az univerzitását, amiről az imént belinkelt hozzászólásomban részletesen írtam.

Szerintem 1 pic labortáponként ez optóval leválasztva és jumperrel állítható címmel a legjobb megoldás. (Az én készülő labortápomban is így lesz megoldva a vezérlés)
Az az user, aki egy jumpert nem tud használni/beállítani rajta egy címet leírás alapján az ne csináljon ilyen dolgokat! Annak ez nem való!
Így én is azt vallom ennyire tényleg nem éri meg túllihegni a dolgot!

Egy kész áramkörnél, ahol a kommunikációra van 2 láb és nincs több(jumperre), egyalán nem túllihegés egy ilyen megoldás keresése. A megoldás szerintem meg is van(legalább is úgy érzem nálam már igen), mással van a baj, amin nem segíthetünk...

A megoldást én is jónak találom és meg is fogom valósítani ez egészen biztos. Csak a helyzet az hogy ez a projekt egy egész pici szelete csak, mellette számos más dolgot is meg kell oldanom melyek közt van olyan amihez a jelenlegi prototípus nyáktervének módosítása szükséges. Előbb ezzel kell foglalkoznom (nyáktervezés) aztán a panelt le kell gyártanom, beültetnem, kipróbálnom hogy az összes többi funkciója a panelmérőnek működik rendesen (nem ugrál, mér rendesen stb.) és utána jöhet az hogy na akkor kommunikáljunk. Ráadásul mindezek előtt a labortápom hatásfokát fogom megmérni...
Azt akarom csak mondani hogy az elgondolás valóban rendben van az én szememben is, csak azért nem írok semmit mert a dolgot kibeszéltük teljesen, ennél tovább csak akkor tudok lépni ha megvan a prototípus áramkör (ráadásul minimum kettő), ami viszont nem lesz egyhamar sajnos.

Hello!

Az lenne a kérdésem, hogy egy RTCC modult, mivel lenne jobb a PIC-hez illeszteni. I2C vagy SPI. Én az SPI mellett szavaznék, mert van kivezetés bőven, de kváncsi vagyok a véleményetekre. Az a vicc, hogy ha lenne a nyamvadt PIC-nek Vbat kivezetése akkor nem lenne rá szükség,de így sajnos muszáj, mert az elemnek nem mindegy, hogy az RTCC 1-5uA-t vagy a PIC24F 25-30uA-t nyel el tőle. Mondjuk még nem számoltam ki, hogy egy CR2025 meddig bírja 30uA terheléssel ami lehet, hogy kicsit több is, csak az adatlap szerint 22uA, de valószínűleg több. Hozzátenném, hogy DFC modul is lesz rajta, csak nem tudom a térerő nevű jelenség mennyire fordul elő itt a környéken, ezért nem árt ha ketyeg az RTCC.

Mindkettő jó, de ha van elég láb és csak egy eszközt kell használni, akkor könnyebb kezelni az SPI-t.

Még egy kérdés az RTCC-vel kapcsolatban. Mire jó a Unique ID?

Unique= egyedi, különleges. ID valószínűleg az azonosító rövidítése. Olyan szám, ami még egy ilyen eszközben nem forul elő.
Ezt jól tudná hasznosítani Attila86.

Köszi, angolul én is tudok , de nem a jelentése érdekel. Mire tudom használni, ráadásul egy RTCC-ben?

Miben van?
Az RTCC tartalmazza? Nem kell egyedi beprogramozással foglalkozni, hanem a szoftver rendelkezésére áll egy szám, amivel azonosítani lehet a hardvert, vagy a szoftvert, vagy azok egy részét.

Ez nem az RTCC azonosítója, hanem az RTCC tárolja pl. egy készülék egyedi azonosítóját (MAC address, vagy bármi más).

Tehát, ha van egy MAC-em a PIC-ben ethernethez, de mondjuk valamiért akarok még egy ethernetet ami el van választva a másiktól, de annak nincs MAC-je a PICben akkor az RTCC tud egyet tárolni neki, vagy egyéb eszközazonosítót, ami belefér abba a regiszterbe?

Egyiknek sincs. A PIC-ben nincs egyedi azonosító, azt valahogy külsőleg kell megoldanod. Pl. lehet a belső vagy egy külső EEPROM-ba egyedi azonosítót égetni, ezzel csak az kellemetlen, hogy minden egyes darabbal foglalkozni kell külön-külön. Ezért kényelmesebb egy külső chipbe már a gyárban beprogramozott egyedi azonosítót használni.

Az I2C kevesebb kivezetés, viszont bonyolultabb használni. Ha már van SPI használatban, lehet, hogy arra könnyebb rámultiplexelni, ha van I2C használatban, akkor meg arra könnyebb valamit pluszben rákötni. A legolcsóbb Microchip RTCC I2C-s - van, akinél ez a szempont.

A HEStore 165mAh-t mond, az kb. 5500 óra, azaz még egy év sincs. 2032-vel kb. egy év.

IC-je válogatja. Az MCP7952X/MCP7951X adatlapja például azt mondja, hogy egy 128 bites számot tárol, ami blank lehet vagy előre programozott. Utóbbi esetben az első 64 bit tartalmaz(hat) egy EUI-48/68 MAC címet. Az RTCC pedig nagy ívben tesz rá, hogy mi ez a 128 bit...

Ok. Minden világos. Mindenkinek köszönöm a felvilágosítást.

Szia mindenkinek! Sok éve vagyok itt, csak még nem írkáltam. Régóta pic-ezem, évek óta C-ben már. Sok bonyolult progin túl vagyok már, most mégis tanácsot kérnék. Új project indítása miatt a Chipcad-al történt egyeztetés után A dsPIC33EP512MU810 tok mellett döntöttem. A célom: 1 tokon belül AC motor PWM helyzet azaz szegmens vezérlés, (AC servo) encoder jel feldolgozás, és Step- dir feldolgozás. Már az MPLABX-et használom, tanfolyamon is voltam, szóval megy a dolog. Gondolom. Szimulátor szinten a PWM a 3 fázist vezérli is mint annak rendje módja. A QEI modult ( qadaratura encoder, azaz a 2 fázisújelfeldolgozó, plusz home, inex) eddig még nem sikerült elindítanom. Ennek a toknak elég bonyolult a periféria-láb hozzárendelése, de szerintem ezt is megoldottam. A szimulátoron mégsem látom hogy menne, pedig a stimulussal megadom a jeleket. Van valakinek tapasztalata? Tudom hogy egyedi, de háta.... Eddig olyan gondokat is megoldottunk, amit a CHIP.....nél sem tudtak,csak időőőőőőő! + szenvedés. Ha valaki ott van a szeren, Please help!!! Angol nyelvű anyag is jöhet, angol nem gond. Szép estét: famester. Kösz

Nekem egy tök általános tapasztalatom van: a szimulátor szép és jó, de sem az nem jelent semmit, ha a szimulátorban valami működik, sem az, ha nem. A szimulátor már csak ilyen, én elég régen leszoktam róla. Ki kell próbálni az IC-vel is, mert simán lehet, hogy szimulátorban van a hiba.

Üdv mindenkinek.
Egy kis segítséget szeretnék kérni. Bajlódok én egy PIC24F08KM202 tip. mikrovezérlővel. Az a nagy ötletem támadt, hogy szeretnék 2 UART-ot kezelni. A problémám az, hogy van egy régi kommunikátorom és egy új riasztóközpontom, a kettő kommunikációs formátuma annyiban tér el, hogy a záró karakterek nem #10#13 hanem #47, ezt meg is oldottam egyszer egy delphiben írt programocskával, utána java-ban raspberry pi -vel (a beépített UART-al + egy MCP2200-val), de mégis csak PIC-el lenne az igazi. Az a baj, hogy a PIC programban nem tudom, hogyan kezdjek neki. Ha valaki tudna egy kicsit segíteni, megköszönném.

"Már az MPLABX-et használom, tanfolyamon is voltam"

Hol van ilyen tanfolyam?
Én is belevágtam az MPLAB-ba de komolyabb dolgot nem tudtam vele összehozni, viszont az MPIDE-vel már jobban boldogulok de az meg kicsit csak korlátos.

Sziasztok!
Egy C-vel kapcsolatos kérdésem lenne. Ugyebár van olyan, hogy void * , ami egy pointer "valamire". Nem tudjuk milyen típusú változóra mutat. A kérdés az, hogy ennek mintájára van-e ugyanilyen általános függvény poniter is. Ami egy olyan függvényre mutat, aminek nem ismerjük sem a visszatérési értékét sem az argumentumainak típusát. (Az argumentumok számát előre tudom)
Most úgy oldottam meg, hogy a függvény pointer is egy void *, amit később átkasztolok valami függvény pointerré.

Nem probaltam ki, de szerintem igy:



A parametereket is pointerrel kell atadni, anelkul nem fog menni a kulonfele tipusok atadasa.

Nincs ilyen. Vagy tudod a függvény signature-t pontosan, vagy használhatsz akármit, castolni fog kelleni.