Szia!
Érzékelni kell az elem jelenlétét és ha az elem nincs jelen, azonnal sleep módba váltani, amennyiben ez megengedhető, ha nem, akkor az IDLE mód is jobb, mint ha tovább futna a program. Sleep módban is oda kell figyelni a fogyasztásra. Ne legyenek lebegő nagy impedanciás lábak, a fölösleges IO lábakat célszerű kimenetnek beállítani, és egy fix értéket (0 vagy 1) kiadni rajtuk. Az elem hiányát lehet mechanikusan érzékelni egy érintkezővel, amit az elem zár össze, vagy az elem és a backup kondi közé egy alacsony nyitófeszültségű diódát tenni, és a dióda elem felőli lábát egy bemenetre bevezetni.

Megmondom őszintén: nem irígyellek, ha a hardware már készen van, "csak" nem akarja a jót...

Amit én terveztem egyszer, RTC-t igénylő kapcsolást, ott volt egy rövid vacillálás, hogy hogyan csináljam meg, hogy minél kevesebb komponens menjen az elemről, hogy minél tovább bírja, aztán némi gondolkodás után bedobtam egy kb. bruttó 200 forintos MCP7940N-et a kapcsolásba, és hatalmas megelégedéssel üzemel azóta is. Ezzel semmi teendő nincs, elemről eszik 1uA-t (örök élet + 1 nap), és nem kell azon izmozni, hogy érzékelni, amikor elmegy/megjön az áram, fel/lekapcsolgatni a perifériákat, szórakozni azzal, hogy hogyan legyenek elszeparálva a kívül rákötött komponensek, hogy amikor nincs kívül áram, véletlenül se adjunk valami kimeneten magas szintet (ugye a szomszédos CMOS áramkör bemeneti védődiódáján keresztül simán megtáplálná a lekapcsolt tápot), de amint megjön az áram, akkor meg ne maradjanak a kimenetek meghajtás nélkül, stb.

Sikerült már valakinek üzenetet küldeni CAN buson PIC18F + MCP2551 kombinációval? Egyszerűen megőrülök tőle. Két hete keresgélek a neten, bújom az adatlapokat és erratákat, de nem tudok rájönni, miért nem megy. Szereztem egy micochipes demoboardot (MCP2515DM), ez két azonos áramkörből áll, egy egyszerű CAN-hálózatot alkotnak. Megy is minden szépen, a két board kommunikál egymással, én meg USB-n figyelhetem. Rákötöm a buszra a saját áramkörömet (PIC18F2480+MCP2551), és ő is szépen fogadja a CAN-csomagokat, soha nincs semmi hiba, tehát az időzítések rendben vannak. Viszont nem hajlandó küldeni. Arra gondoltam, hátha az MCP2551 rossz, ezért megnéztem szkóppal a PIC CANTX lábát, mi megy ki. Hát a nagy semmi. A PIC nem küld semmit. Kiszedtem minden felesleges sallangot, csak a minimális kódot hagytam, és így sem.



Elvileg ennek hatására ki kéne mennie egy 1 adatbájtot (0x55) tartalmazó CAN-üzenetnek, és a TXB1CONbits.TXREQ bitnek törlődnie kéne, jelezve, hogy az üzenet elment. Ez akkor nem szokott sikerülni, ha nem jön vissza ACK jel, mert akkor újra és újra próbálja küldeni. De itt egy működő hálózat van, tehát ez nem lehet a gond.

Arra gondoltam, kipróbálom loopback módban. Ilyenkor a PIC nem küld ki semmit a lábra, hanem belül átküldi a CANTX-et a CANRX-re. Vagyis ami "kimegy", azt olvashatom is azonnal. Ennek mindenképpen mennie kell, mert ehhez nem kell működő CAN bus, hiszen a PIC-en belül zajlik minden. És így sem megy!!! Miért? Érti valaki? Próbáltam más pufferrel is (TXB0 és TXB2), sőt, másik PIC-kel is, hátha ez bedöglött. Minden ugyanaz, a PIC fogadja a csomagokat, de küldeni nem tud se normál módban (ténylegesen a buszra), se loopback módban (belső tesztelés). Bármit csinálok, a TXREQ bit nem törlődik (azaz a csomag nem megy el).

Nézted már az adatlapban a példákat? Nem látom, hogy be kell-e állítani a TXREQ-t, azt csak figyelni kell. Nem lehet minden regiszert bankváltás nélkül elérni, ez is fontos lehet!

Az adatlapban van egy érdekes megjegyzés: "Setting the TXREQ bit does not initiate a message transmission; it merely flags a message buffer as ready for transmission. Transmission will start when the device detects that the bus is available."

Nem értek a CAN modulhoz, de meg kellene nézni, hogy mitől kell(ene), hogy úgy érezze, hogy a busz rendelkezésre áll.

Valami olyasmi van, hogy adott számú bitnyi (talán 6) ideig recesszívnek kell lennie a busznak. Ezzel nincs gond, mert csak ő küldene, így a busz biztos, hogy szabad.

Ebben biztos voltam. A kérdésem csupán arra irányult, hogy a PIC (amelyik nem közvetlenül csatlakozik a buszra) honnan szerez erről tudomást?

A CANTX lábon folyamatosan látja a buszt. Gyakorlatilag mondhatni, hogy közvetlenül csatlakozik, hiszen a 2551 csak kb. egy Schmitt-trigger a busztól a PIC felé.

Ami engem leginkább aggaszt, hogy loopback módban miért nem megy, mert ott teljesen mindegy, mi van a buszon. Ha ott menne, akkor lehetne nyomozni, hogy az MCP rossz, vagy a lábakkal van gond, de így teljesen tanácstalan vagyok. Egy csomó példaprogramot megpróbáltam átnézni, de úgy tűnik, szinte mindenki a microchipes példát másolja, vagy beépített függvényt használ, pl. a Mikroelektronika C-fordítójával. Feltettem azt is kíváncsiságból, beégettem a gyári CAN-buszos példát, de az sem küld semmit.

És nem kell arra a CAN-buszra valami fel/lehúzó ellenállás? Mint az I2C-nél? Mert annak a hiánya elég indok lehet arra, hogy ne érzékelje szabadnak a buszt...

Az MCP-ben van felhúzó ellenállás, és ráadásul először úgy próbáltam, hogy működő buszra tettem, tehát ha fel vagy le kell húzni, a microchipes demo boardok biztos megtették. Ráadásul loopback módban kikapcsol a CANTX láb, és ami a buszra menne az egyből meg a PIC-en belül a CANRX lábra.

Akkor logikus módon az maradhat még, hogy a csillió regiszterben valami szükségeset még nem állítottál be.
Ha az adott eszközre írt Microchip-féle CAN mintapéldák sem mennek, akkor mondjuk ez sem hangzik reálisan.
Persze lehet maga az IC is defektes, sőt, lehet az egész IC-típus problémás (Errata)...

Keresgéltem de nem találtam arról információt hogy mely típusú PIC-eknek van CTMU modulja. Sehol nem lehet erre rászűrni sem a Microchip oldalain. 12F-es vagy esetleg 16F-es PIC-ekben nincs CTMU?

MAPS

Ja hogy az a CTMU lenne? Végül is érintésérzékelésre is lehet használni az tény.

Bocs kissé benéztem, neked igazából ez kell! (sajnos csak pic18-tól kezdődően)

Ez mindjárt más, köszi!

Szia!
Köszönöm, hogy foglalkoztál a problémámmal, de több napi lamentálás után arra jutottam, hogy valószínűleg _vl_ javaslatát alkalmazom. Ezzel biztosan elkerülöm a PICnek a 2V-os halálcsapdába jutását. Az a baj, hogy ha a felhasználó kiveszi az elemet mondjuk IDLE módban, és a PIC nem is ébred fel, de sajnos ha nem aznap tesz bele másikat (mert mondjuk elviszi a piacra másnap megmutatni hogy "ilyet kérek"....) szóval érted. Jobb, ha az 1 uA-t figyasztó RTC-nek van egy saját backupja.
Köszönöm!

Köszönöm a tanácsot! Megfogadom. Viszonylag szerencsésen is jön ki a dolog, mivel sajnos mindenféleképpen új panelt kell terveznem, mivel megszűnt a gyártása az egyik alkatrésznek amit beleterveztem... pedig múlt héten még tobzódott a Farnellnél és nem kockáztatok, hogy 4 év múlva nem lehet már majd kapni, 1000 db. ot meg nem veszek meg előre
Köszönöm!

Sziasztok!

Biztosan nem a leg megfelelőbb fórumba írok, mégis valahol segítséget kell kérnem, mert amire szükségem van arra nem találtam sehol egy konkrét megoldást. ****************Elnézést ha ezzel offoltam az épp aktuális topic témát.

Előre is köszönöm!

A topicban tilos hirdetni. Ott van az apróhirdetési felület. -- moderátor

Sziasztok
Valaki valami egyszeru es ertheto leirast tudna adni, hogy hogyan tudnek irni programot PIC-re?

Igen. Nézelődj a PIC kezdőknek topicban. Többször volt már linkelve 1-2 könyv és weboldal.

Sziasztok!
PIC18F4520 Cseréltem PIC18F46K22 mondván, hogy a sokkal több memória gyorsabb és még olcsóbb is és elméletileg PICKKIT 2 is viszi.
PICKIT2 v2.61, Alapból nem de egy microchip oldaláról letöltött 1.62 frissítéssel igen.

Gyári PICKIT 2 programozóm van.
A bökkenő, hogy gyakorlatban csak a proci EEPROM ját sikerült írni. Próbáltam, hogy csak a config biteket átírom minden fél hex nélkül és az tegye bele de az se megy.

Valaki esetleg írt PICKIT 2 vel ilyen procit??

Az Mplab v8.88 meg nem is viszi.

Esetleg valami más progi ???

Az Mplab v8.88 meg nem is viszi.

Esetleg valami más progi ???

Szia!
18F46K22:
- Fordítás MpLab -bal, programozás PICKit2 saját programjával, nincs lehetőség nyomkövetésre.
- Fordítás, programozás, nyomkövetés MpLab -bal és PICKit3 -mal vagy ICD3 -mal.

Van a PIC -eknek olyan belső védelme, ami nem csak a program kiolvasását akadályozza meg, hanem a törlést és újraprogramozást is letiltja?
Konkrétan pl. a PIC18F25K80

Tenyleg ne haragudj meg erte, nem kotozkodes, csak gondoltam segitek helyere tenni a fogalmakat. A PIC chipek nem procik / processzorok, hanem mikrokontrollerek. Oriasi a kulonbseg, nem erdemes keverni a kettot. Egy processzornak sem EEPROM-ja, sem program memoriaja, sem pedig RAM-ja nincsen...

Nincs. Esetleg ha kifurod a PGD/PGC labakat es beragasztod a helyet. De mechanikailag akkor is lehet ELVILEG visszacsinalni. Az mas kerdes, hogy nem fognak nekiallni.
Esetlegesen ezeket a labakat ki lehetne valahogyan egetni (valami eros nagyfeszimpulzussal), de nem tudjuk, hogy ez a tobbi resz mukodesere milyen hatassal lenne.

OK! Lényeg hogy nem tudom bele írni a programot a mikrokontrollerbe / proci rövidebb de tényleg nem azt jelenti /

Kösz a gond hogy a saját 2.61 1.62 Update -es programjával csak az EEPROM -ot tudtam írni de program memóriát nem még config biteket se állítja át.

Neked működöt az általad leírt módon????

Szia!

Nálam gond nélkül működik a programozása (pic18f46k22, pic18lf46k22) pickit2-vel.

Kösz! Nálam az MCLR RE3 bemenetnek használt ezért +5V van húzva nálad hogy áll???
Hát ha ez a gondom.

Ill. PIC Táp ott kap vagy csak az PICKIT 2 hajtja íráskor de ez mindek éppen jó hír, hogy biztos megy

Nálam táp nélkül felse ismeri

Az enyém 18F46K22