operazione su rtc con pic 16F88

itivo, allore spegni

una istruzione

fortunato? perch=E8? .....ho paura a pensare che si possa piantare anche quello.... =E8 bastato leggere una app note che spiegava come funzionava l'i2c e quindi scrivere (in qualche sera di lavoro, dopo il lavoro) il programma che lo fa andare. l'unica cosa =E8 che non ho inserito un timeout per gli ack che potrebbero non arrivare. ma per ora funziona. (mi sento fortunato allora :) ) solo che casco poi su un banale confronto.

come mi ha fatto notare due di picche, che ringrazio, non avevo previsto niente! gran pirla che sono. allora ho posto rimedio riscrivendo il tutto. swappo intanto i nibble come mi avevano gi=E0 consigliato qui in questa discussione e quindi opero prima su decine e poi su unit=E0. (tanto il risultato non mi interessa, mi interessa solo il segno). controllo sia lo stato di Z e C senza pi=F9 resettarli e senza effettuare cambi di banco inutili. eppure, =E8 come se il risultato, secondo C e Z, sia sempre diverso da 0 e sempre maggiore di 0. anche quando sottraggo due cifre identiche o due cifre che devono darmi un risultato negativo. (la matematica non =E8 un'opinione).... qui sbaglio qualcosa....e mi sento un p=F2 pirla.mi manca solo questo confronto per far andare il tutto. se posto il codice, che =E8 lungo, mi potreste dare una mano?

voi come fareste?

grazie mille per eventuali altri consigli

matteo

Reply to
Matteo
Loading thread data ...

No, a me sembra abbastanza logico che invece debba funzionare comunque, se le decine sono sul nibble più significativo. Penso sia facile convincersi che se hai due numeri BCD uno maggiore dell'altro, allora lo saranno anche nella loro rappresentazione binaria (non so se mi sono capito). Il trucco di guardare il bit più significativo invece non funziona. Infatti se hai 91-1=90 il bit più significativo è ancora ad 1 nonostante

1
Reply to
Pasu

=F9

tante

Il

bhe, nel mio caso penso sia necessario controllare anche il flag di zero. spiego le mie ragioni (confutabilissime): se parto col confrontare l'anno (mettiamo anzi tutto che oggi siano le 20.30 del 28

09 09 e che la data impostata da me siano le 22.30 del 28 09 09) per vedere se la mia data impostata ha passato o no la data dell'rtc far=F2 09-09 (anno rtc - anno eerom). se il risultato fosse positivo, la mia data sarebbe stata gi=E0 passata. se fosse negativo la mia data =E8 maggiore di 10 e quindi interrompo il ciclo pena l'errore. se =E8 zero (come =E8 in questa ipotesi) devo continuare a controllare i mesi, i gg le ore etc... perch=E8 se =E8 0 con gli anni, significa che c'=E8 la possibilit=E0 che i mesi o i gg o le ore o i minuti corrispondano. quindi devo continuare a controllare. se ipoteticamente i risultati sono tutti 0, =E8 l'ora x e l'allareme scatta lo stesso. giusto?

se faccio lo stesso discorso in modo autonomo prima sulle decine, e poi sulle unit=E0, non ci sar=E0 errore perch=E8 in caso di risultato sulle decine negativo mi fermo. in caso zero continuo con le unit=E0 e in caso positivo do l'allarme.

=E8 che non mi va un tubo.scatta sempre. come se il risultato fosse sempre positivo. ma che c....

dunque, il valore della data che imposto io varia di volta in volta a seconda delle esigenze. e per non riprogrammare sempre la memoria di programma (1000 scritture circa come "limite") scrivo i dati che cambio ogni volta nella eerom, che regge meglio le ripetute scritture che dovr=F2 eseguire (nell'ordine delle centinaia). all'accensione c'=E8 una routine che prende data, mese, gg, hh e minuti e li carica in uno spazio ram dedicato, in modo che sia pi=F9 veloce il loro smistamento e li debba caricare una volta sola all'accensione. ricapitolando, non essendo una costante ma una variabile nella ram, penso vada bene MOVF.

Reply to
Matteo

Matteo ha scritto:

Hai tenuto conto che nei PIC il flag C durante sottrazione si comporta=20 al contrario di tutti gli altri micri e cpu di questo e probabilmente=20 altri pianeti?

5 - 2 Z=3D0 C=3D1 5 - 5 Z=3D1 C=3D1 5 - 6 Z=3D0 C=3D0

ciao Claudio_F

Reply to
Claudio_F

=E8

si, grazie comunque. i conti tornano, sulla carta.... mi dimentico probabilmente qualcosa di banale.

matteo

Reply to
Matteo

Matteo ha scritto:

Hai testato il tuo confronto con dati certi e non ricavati dall'rtc+eeprom? Magari si corre dietro ad un problema che non c'e'... o meglio, non e' dove si crede che sia.

Reply to
Claudio_F

mmmmm......stasera provo con un impostazione manuale. sono certo per=F2 dei dati che utilizza per le operazioni, uno lo imposto a mano (e per vedere se lo leggeva correttamente, l'ho fatto leggere e risalvare su eerom in un altro posto) e l'altro dell'rtc lo legge e lo salva sempre sulla eerom (fatto anche quello per vedere se funzionava, teneva la data\ora e il dato =E8 corretto).

ciao grazie

matteo

Reply to
Matteo

Rieccomi, scusa il ritardo. In caso tu non abbia ancora risolto...

[Pasu] >> Tra l'altro non capisco la tua necessità di controllare il flag di zero >> e quello di carry... Se vuoi sapere se A>B fai B-A e controlli se il >> carry è 1. Se vuoi sapere se B>A fai A-B e controlli se il carry è 1. Il >> flag zero lo guardi solo se vuoi due numeri uguali, amenochè non sia >> svantaggioso caricare in accumulatore uno dei due operandi. [Matteo] > bhe, nel mio caso penso sia necessario controllare anche il flag di > zero. spiego le mie ragioni (confutabilissime): se parto col > confrontare l'anno (mettiamo anzi tutto che oggi siano le 20.30 del 28 > 09 09 e che la data impostata da me siano le 22.30 del 28 09 09) per > vedere se la mia data impostata ha passato o no la data dell'rtc farò > 09-09 (anno rtc - anno eerom). se il risultato fosse positivo, la mia > data sarebbe stata già passata. se fosse negativo la mia data è > maggiore di 10 e quindi interrompo il ciclo pena l'errore. se è zero > (come è in questa ipotesi) devo continuare a controllare i mesi, i gg > le ore etc... perchè se è 0 con gli anni, significa che c'è la > possibilità che i mesi o i gg o le ore o i minuti corrispondano. > quindi devo continuare a controllare. se ipoteticamente i risultati > sono tutti 0, è l'ora x e l'allareme scatta lo stesso. > giusto?

Se ho capito bene il relè deve scattare quando data>=dataRom (che equivale a dire (NOT data goto Loop (Sì => STATUS.c=0) Mese-MeseRom Sì -> goto Loop Gior-GiorRom Sì -> goto Loop ... Seco-SecoRom Sì -> goto Loop Loop2: call accendi_rele goto Loop2

Come vedi si può fare anche senza il flag di zero.

[...] > ricapitolando, non essendo una costante ma una variabile nella ram, > penso vada bene MOVF.

Assolutamente. Volevo solo esserne certo. Scusa, non volevo risultare offensivo (era un errore che io facevo spesso :-p )

Ciao

Pasu

Reply to
Pasu

ancora no.... :(

i zero

l

=E8 1. Il

sia

28

=F2

a

ro

gg

prover=F2 anche cos=EC. ti faccio sapere come =E8 andata appena ho provato...

certo, assolutamente non sei risultato offensivo. siamo qui apposta per parlare di queste cose! ogni domanda =E8 costruttiva! :)

ciao

grazie mille ancora per l'interessamento

matteo

Reply to
Matteo

aggiornamento:

=E8 l'rtc che fa il bastardo. alla seconda lettura della data (dall'accensione) restituisce una data A CASO, che a volte risulta composta da tutti 00 00 00 00 00 (mm hh gg MM AA) e a volte =E8 superiore facendo scattare l'allarme.

sapete come mai? rispetto i protocolli di noack e stop (ricordo che =E8 il ds1307 che dialoga in i2c) e non capisco come mai alla seconda lettura mi da una data fasulla. sto bastardo.

grazie per eventuali dritte.

ps: ho provato anche a mettere un ritardo di 5 secondi tra una lettura e un'altra, ma continua a dare questo tipo di errore.

grazie

Reply to
Matteo

FINALMENTE HO RISOLTO: vi spiego cosa era, cos=EC potrete bastonarmi a dovere....

il programma funge, era, come ho detto prima, l'rtc che dopo la prima lettura mi dava valori 000000..... e quindi cosa era? era il puntatore al registro del rtc, che alla prima accensione va da solo alla posizione 00h per poter leggere fin da subito i dati di data e ora. se la trasmissione viene troncata subito dal master dopo aver letto i dati provenienti dall'rtc (che =E8 slave), il puntatore rimane dove =E8 stata interrotta la lettura. subito dopo i banchi di data e ora, ci sono quelli della nvram a disposizione (56 byte). =E8 li che il pic leggeva tutti quei simpatici

  1. risolto con una piccola routine che mi rimette a 00h il puntatore prima di ogni lettura.

come al solito =E8 stato un errore umano, da parte mia.

vi ringrazio del tempo che mi avete dedicato e mi scuso se vi ho fatto perdere del tempo.

grazie

matteo

ps: se qualcuno fosse interessato a qualche routine, non ha che da scrivermi.

Reply to
Matteo

Evviva! :-)

Ma ora puoi dirci cos'è l'applicazione? ;-)

Io dico un porcellino salvadanaio. Ci sono andato vicino? :-p

Ciao!

Pasu

Reply to
Pasu

applicazione: stacca un timer 24 ore meccanico di controllo accensione luci a una data prefissata,e, ad altre date stabilite, ne attiva e ne stacca altri. i timer 24 ore fanno parte di un gruppo di timer vecchissimi, e l'amico per il quale ho fatto tale pazzia, non intende comprarsene di pi=F9 "evoluti". di conseguenza questo =E8 un timer che controlla l'inibizione di altri timer. verr=E0 posto dove prima cera un interruttore manuale\automatico.

vicinissimo!

ciao e grazie ancora!!

matteo

Reply to
Matteo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.