Munkához olyan rendszert használni, amit a hobbisták is csak kínok árán ledvillogtatásra használnak érdekes összevetés. Jó munkát!

Nagyon tévedsz, ha azt hiszed, hogy a PARSIC-ot nem kell megtanulni!

Mindamellett csak igen korlátozottan alkalmazható, a megtanulására fordított idő/munka pedig nem térül meg más területen, ha majd tovább kell lépni. Ettől függetlenül nem mondom, hogy ne csináld, csak jeleztem, hogy egyik zsákutcából a másikba léptél.

Ha mar munkarol es nem hobby-rol van szo:

Tulajdonkepp ez egy osszetett dolog. Az egyik oldalrol ott vannak a fejlesztesi koltsegek, a masikrol pedig a gyartasi koltsegek. Sokszor a gyartasi koltsegeken lehet faragni egy jol atgondolt, alapos tervezesen, ami persze tobb ido (tehat penz) -- azonban a gyartas soran a befektetett fejlesztes megterul. Ezt a megterulest csak es kizarolag koltseg elemzesel lehet megallapitani, abbol derulhet csak ki, hogy hol van az optimalis befektetes/megterules arany.

Minderre ratelepszik meg a varhato megterules ideje, de lehetnek egyeb ido szorito tenyezok is amelyek a raforditott fejlesztesi es gyartasi idoket befolyasolhatjak (pl. kokurencia elott ki kell hozni a termeket, vagy meg a nagy karacsonyi laz elott stb stb stb). Emiatt gyakran ez a befektetes/megterules arany nem optimalis termeszetesen, de ennek ellenere torekedni kell a kozelitesehez.

Namost, ha egy fejlesztesnel uj dolgot kell megtanulni vagy uj fejlesztesi eszkozoket kezdesz hasznalni, akkor mindenkeppen ki fog tolodni a fejlesztesi ido. Abban tokeletesen igazad van, hogy vannak olyan fejlesztesi eszkozok, amelyeknek a tanulasi fazisa rovidebb, mint a masiknak. De ez nem minden, mert ha egy nagyon konnyen elsajatithato rendszerben nem lehet megcsinalni valamit, vagy nagyon szukosek a rendelkezesre allo tamogatasok (felhasznaloi forumok, konzultansok stb), akkor nem biztos, hogy jo valasztas az a bizonyos termek.

Ekkor jon az a bizonyos "vodorbe" eset, amit icserny mester emlegetett...

Helló.
Amúgy a számítógépben tehet valami kárt ha mondjuk hibás az ic? (Mert akkor nem biztos, hogy az itthon működő egyetlen géphez fogom elsőnek hozzákötni.)

Hello,

PIC18F46J11 MCU-ra írok programot. Az MCU idejének 99%-át mély álomban (deep sleep) tölti, amely állapotból többek között RTC alarm ébresztheti fel, amennyiben az alarm időpontot eléri a valós idő. A gondom a nap átfordulással van. Pl, ha valós időnek 2011.01.26. 23:59:50-et állítok be, majd alarm időnek 9 másodperccel későbbi időt (23:59:59), akkor még triggerelődik az ébresztés rendben. Viszont, ha 10 vagy több másodpercet (már másnap), akkor nem.

Belefutott már valaki hasonló problémába?

Üdv, Lado

Ennyire nem akartam belemenni .
Tény hogy egy éjszaka eljutottam egyedül a 0 ról odáig , hogy bármelyik bemenetről be tudom kapcsolni bármelyik kimenetet egy kis időzítéssel.
Ebbe beletartozik a program keresése is a neten.
A másik nyelvekről fogalmam sincs .
Én vizuális típus vagyok , egyben szeretem látni a programot. A szöveges programozásnál sokat kell fejben tartani , amit ötven sorral odébb írtál.
Én a programot használom , nem akarom megérteni.
A logikai alapokkal tisztában vagyok azt már megtanultam, éppen elég a feladat megoldásával foglakozni , nem még a szintaktikával!
A parsic használatát kell megismernem és nem a nyelvét.
Egy telefonnál is a használatát kell megismerned nem pedig a hardveres és szoftveres dolgait.

De azért köszönöm.
mezga

Ebben a pic-ben van valós idejű óra? Ha nincs akkor esetleg a külső óra típusa többet segítene.
A másik, esetleg a napot nem felejtetted el módosítani az ébresztésnél? (esetleg a dátumot ,vagy egy mindennapos programot választani. )

Igen tehet, de előtte le tudod ellenőrizni, hogy jó-e, vagy nem? (Javaslom a PIC égetők topicot ha égetőélesztésről akarsz kérdezni! Bővebben: Link)

Konkrétan mit állítasz be? 01.27. 00:00:10-et? (Az Alarm az éveket nem kezeli, ezt biztos tudod...) A napot is be kell állítani...
Milyen értéket írtál az ALRMMNTH és ALRMDAY regbe?

Jut eszembe a ALRMWD reg is!

Szia!

Az idő regiszterekben az értéket BCD -ben kell megadni...

Hali
Ez a "legkisebb, legolcsobb" megoldas, a parsic-osok szerint, hogy ha nem tudom beleprogramozni 1 PIC-be, majd sosros vonalon osszekotok 2-3 PIC-et, es mar jo is. Mi itt ugy csinaljuk, hogy ha nem fer bele, veszunk nagyobb PIC-et. A parsic, egy a PIC16C5x sorozatra fejlesztett program, aminek az utolso modositasa meg a 16F877 idejeben keszult. Mar nem fognak fejleszteni rajta. A fejleszto meg is szuntette a parsic oldalt mar vagy 3 eve. Viszont a MCHP fejleszto programjai mindig naprakeszek. Vannak peldak arra, hogy a parsic-ban kezdok komolyabb keszulekeknel rajottek, hogy nem lehet megcsinalni annyi a korlat. Utana megprobaltak mas nyelvjarast, viszont az ottan elsajatitott szemleletmod akadalyozta a rendes programiras tanulasat. Ezet ha rank halgatsz, az alapoktol kezded a PIC tanulast, es gyorsabban fog celt erni.

Ha meg tudta jeleníteni, akkor gondolom ezt tudja...

Mint elobb is leirtam: A PIC programozast (es mas uC-t is ) a HW ismerkedessel kell kezdeni! Anelkul hamarosan el fogsz akadni. Olvass vissza itt es rajossz mirol beszelek.

Hp41C: Persze, BCD-t használok.

proba: Van benne RTC, a belső 32K-s T1OSC-t használja.

watt: Tudom, hogy az éveket nem kezeli. Unixtime-ot (másodperc alapú) használok, azt konvertálom át BCD-vé. A beállítással nincs gond, értem ez alatt azt, hogy a megfelelő regiszterekbe, a megfelelő értékek kerülnek, mert ha visszaolvasom akár a valós- vagy az alarm időt, azt kapom, amit beállítottam (év, hó, nap, óra, stb).

Szemléletesebben, hogy mi is a gond:

1.) ez még jó (23:59:59-kor wakeup van)
valós időnek állítom: 2011.01.26. 23:59:50
alarm időnek állítom: 2011.01.26. 23:59:59

2.) ez már nem jó, nem ébred
valós időnek állítom: 2011.01.26. 23:59:50
alarm időnek állítom: 2011.01.27. 00:00:00

Tehát, ha nap eltérés van a beállított valós és alarm idő között, akkor nem ébred. Hm.

(Megj.: napváltásra triggerelődő repeat period maszk beállítása megoldja a problémát, de a kétféle alarm metódust nem szeretném keverni.)

Engem még az érdekelne, hogy sleep mode kikapcsolásával ad-e jól megszakítást, mert ha ad, akkor a sleep környékén kellene körülnézni, ha meg nem, akkor tényleg az alarm beállításával van a baj.

Deep sleep-ben van. Ebből ébresztheti impulzus (int0) és alarm irq. Impulzus ébreszti, alarm is ébreszti (kivéve, ha a fent leírt nap váltás van).

Oké, de nem látom mi van az ALRMWD regiszterben? Ebben a hét napjai vannak. Ebben is a következő nap van beállítva(értéke 0-6 között lehet)?

Tegnap feladtam a ticketet a Microchipnél, ma jött rá válasz:



Ezek szerint tudták reprodukálni, elismerték, hogy nem így kellene viselkednie, és remélhetjük, hogy valamelyik következő verzióban javítva lesz. Lehet, hogy érdemes lenne a többi, felfedezett anomáliáról is indítani ticketeket.

Egyértelműen igen. Köszönjük a közbenjárást!

Igazad lehet. Viszont azt nem értem, hogy első induláskor 2010.01.01. 00:00:00 péntek (5) kerül beállításra. Majd amikor szinkronizálok egy velem kooperáló eszközhöz, átállítom a valós időmet és az alarm időmet is ugyanarra a napra (alarm idő mindig néhány másodperccel/perccel több). Ilyenkor semmi gond, pedig alrmwd-t nem állítom. Viszont a két idő egy napra esik. Akkor van baj, ha különböző a két nap.
Már csak azt nem tudom, hogy honnan fogom megtudni, hogy az adott nap a hét melyik napja...

Nagyon köszönöm, sokat segítettél!

Az R2025X-ben a 0 a vasárnap.

Nincs külső RTC.
Megpróbálom eggyel inkrementálni alrmwd-t az alarm time esetén, ha nap váltás van. Ha nem működik, akkor szoftveres date_to_wday-t kell írnom. :/

Ez tokeletesen ertheto, es ameddig nem kell bonyoult dolgot csinalnod addig nincs is ezzel gond. Vannak olyan dolgok amiket ezzel nem lehet megoldani, de valoszinuleg nem is olyan feladatokra talaltak ki a parisc-et.

A telefonos hasonlat amugy kicsit santit, mert ott nem keszitesz valamit, hanem hasznalsz. A PIC-et azonban nem hasznaljuk, hanem abbol az alkatreszbol (es par masikbol) epitunk egy aramkort. Epiteni pedig csak ugy lehet, ha ismerjuk a csinjat-binjat -- pl. hiaba tudjuk hogyan kell kezelni a darut, ha nem tudjuk hogyan kell toronyhazat epiteni...

Tudom, csak azt írtam, hogy abban ez van.
Egyébként majdnem tök mindegy melyik a vasárnap, miután te döntöd el, melyik mit jelentsen.

Sziasztok! Egy rövid kérdésem lenne.
Ha a PIC programom egy táblázatból fog adatokat venni, annak a táblázatnak az elemeit a program memóriába, vagy EEPROM-ba mentsem? És, ha a felhasználó működési paramétereket tud változtatni futás közben ezeket hova mentse a program?

Köszi

Szia!

Az ALRMCFG AMASK bitjeiven nem lehet letiltani a hét napjának figyelését?

0101 = Every hour
0110 = Once a day
0111 = Once a week
1000 = Once a month

Szia!

A nem módosítható táblázatokat a program memóriába, az olyan táblázatokat, amiket a felhasználó megváltoztathat, az adat eeprom memóriában célszerű elhelyezni.
Nem mindegyik kontroller tudja a program memóriáját átírni, vannak olyan típusok is, aminél a program memória írási száma alacsony (~ 1000). Némelyik blokkosan töröl, blokkosan ír. Az ilyen kontrollreknél a program memória módosításánál a törlési blokknak megfelelő mennyiségű adatot a ram -ba kell másolni, ott módosítani, törölni a blokkot és visszaírni.

Én a PIC24FJ... kontrollert néztem ki magamnak először, de abban nincs EEPROM. Ha a dsPIC30... lesz a választásom akkor az miben fog még eltérni a másiktól? Az eltérést úgy értem, hogy milyen újdonságokba botlok a programozás során, ugyanis 24FJ-t már programoztam dsPIC-et még nem. Adódhatnak nehézségek?

Kicsit hosszú lenne a lista, de a dsPIC30 Family Reference Manual sok mindent elmond erről a családról.

Mindenestre ez még az FCY = FOSC/4 kategória, tehát az oszcillátor frekvenciájának a negyede, s FOSC=120 MHz a csúcs. Nagy különbség a DSP egység és utasításkészlet, ami a PIC24-nél nyilvánvalóan nincs.

A dsPIC30 család 5V-ig megy és az I/O vonalak 25 mA-rel terhelhetők.

Hasonlóság:

Az alap utasításkészlet és a fordító viszont ugyanaz, sőt, a Programmer"s Reference Manual is ugyanaz.