Funkcjonowanie RTC PCF8563 bez baterii: czy 100nF wystarczy do stabilności?

Mon Feb 24, 2014 10:34 am   

W dniu 2014-02-24 10:24, Marek pisze:

W celach edukacyjnych :)

--
pozdrawiam
MD

Mon Feb 24, 2014 10:44 am   

W dniu 2014-02-24 10:11, Elektrolot pisze:


Ok, jeszcze doczytam, ale wygląda że masz u mnie browara ;)

Pozdrawiam

DD

Mon Feb 24, 2014 11:29 am   

Wybrałem ten chip, gdyż miał najwięcej pamieci FLASH i RAMu.
Żałowałem, że nie było większych w obudowie TQFP.
Jeżeli będziemy szukać teraz mikrokontrolorów, w których jest najmniej
wszystkiego, to trudno znaleźć.
A mnie to zupełnie nie przeszkadza, że są 3 UARTY, operacje MAC i inne fajne
dodatki.
Mało tego - w ogóle mnie to nie przeraża. Chętnie bym się tym wszystkim
pobawi, ale jak?
Datasheet ma 256 str., przy czym przy każdym dziale jest informacja:
"Note 1: This data sheet summarizes the features
of the PIC32MX5XX/6XX/7XX family of
devices. It is not intended to be a
comprehensive reference source. To
complement the information in this data
sheet, refer to"
Co się mniej więcej tłumaczy na polski: tutaj niemal nic nie ma - poczytaj
sobie tamto,
to dopiero Ci oko zbieleje!

Ale jest jedna wada.
Niektóre uK miały domyślnie ustawione np. 8 pinów jako podłączone do
przetwornika A/C.
Trzeba było pamiętać, aby przy starcie programu pozamieniać je na cyfrowe.
S.

Mon Feb 24, 2014 11:35 am   

W dniu 2014-02-24 10:24, Marek pisze:


Tak swoją drogą zastanawiam się czy faktycznie jest sens stosowania
jakiegokolwiek RTC w projekcie stacji pogodowej. Koncepcja zrodziła się
jakiś czas temu, gdy planowałem wysyłać dane paczkami przez HTTP POST,
już po zebraniu całego kompletu. Przy takim podejściu oznaczenie
dokładnej sekundy pomiaru miało jakiś sens.

Teraz jednak zastanawiam się, czy przypadkiem nie zrobić tego inaczej -
natychmiast forwardując do serwera wynik odczytu w pakiecie UDP. W tym
przypadku równie dobrze mogę przypisywać czas w momencie ładowania
wartości do bazy danych.

Mon Feb 24, 2014 11:46 am   

W dniu 2014-02-24 08:46, Sylwester Łazar pisze:

obsługi RTC jakiś niewspółmiernie wielki układ, 15 razy droższy od PCFa
Ja bym wziął któregoś STM32F407 lub F107 i nie patrzył nawet na ATmegę.
Atlantis wybrał ATmegę i jemu to wystarcza oprócz RTC. A RTC w takim
przypadku już wg gustu. Rozwiązanie z PCF ma jedną wadę - dodatkowy
układ. Tracenie chociażby jednego timera na odmierzanie czasu nie wydaje
mi się złe szczególnie, że ten sam timer można wykorzystać do
odmierzania przedziałów czasowych. No chyba że kwarc rzeczywiście jakiś
'głupi' to PCF wydaje się być przyjazny.

--
Michał

Mon Feb 24, 2014 12:13 pm   

W przypadku temperatury dokładny czas nie będzie miał znaczenia,
ale trzeba zaznaczyć, że w ten sposób zarejestrowany czas będzie czasem
zapisu do bazy,
a nie czasem pomiaru.
Jednak w samolocie już mogłoby to mieć znaczenie
S.

Mon Feb 24, 2014 12:21 pm   

W dniu 2014-02-24 10:14, Elektrolot pisze:

Co więcej! Poszukaj w sklepach stm32f0discovery - za 40-50zł brutto masz
płytkę z mikrokontrolerem i jtagiem, który możesz wykorzystać _także_ do
programowania i _debugowania_ _swoich_ płytek.
Najtańszy 'odpowiednik' ATmega328 to chyba STM32F030K6T6 za ~5zł brutto.
Dla niektórych wadą jest brak wersji DIP. Masz TQFP 0,8mm lub TSSOP
0,65mm, możesz użyć adaptera. Dla innych wadą jest brak firmowego
środowiska, ale od tego jest GCC i tutorial FreddieChopina (polski), czy
też darmowe CooCox. Może brak EEPROMu też jest wadą, chociaż ST daje
kody do symulowania EEPROM we FLASHu, a STM32L1 ma EEPROM.
Za to zapomnisz o bardzo niewygodnym odwoływaniem się do stałych
zapisanych we flash. Wystarczy const int table[1000]={...}, a w kodzie
nie rozróżniasz czy dane są w RAM czy Flash. Jeden sprintf czy cokolwiek
innego. To naprawdę 'miodzik' po przesiadce z AVR.

PS.
Nie pracuję dla STM, chociaż z mojej wypowiedzi sam bym taki wniosek
wysunął ;)

--
Michał

Mon Feb 24, 2014 12:24 pm   

W dniu 2014-02-24 08:46, Sylwester Łazar pisze:

A, i ominąłeś moje pytanko:


Z ciekawości - jaki model, gdzie można kupić?



--
Michał

Mon Feb 24, 2014 12:28 pm   

W dniu 2014-02-24 12:13, Sylwester Łazar pisze:


Tyle tylko, że w tym przypadku nie powinno to mieć żadnego znaczenia. Na
dobrą sprawę nic nie stoi na przeszkodzie, żeby zaimplementować RTC na
jednym z timerów ATmegi i co jakiś czas robić synchronizację z NTP.
Wtedy będę mógł mimo wszystko oznaczyć czas pomiaru, przesyłanego w
pakiecie UDP. Tylko tylko, że wartość ta w większości przypadków będzie
się pokrywała z czasem odebrania informacji przez serwer. Mówię
oczywiście o sytuacji, kiedy ograniczę się do dokładności do jednej
sekundy. W stacji pogodowej większej nie będę przecież potrzebował.

Mon Feb 24, 2014 12:30 pm   

On Mon, 24 Feb 2014 11:29:30 +0100, Sylwester Łazar<info@alpro.pl>
wrote:

Powiedzenia w próbie ogarnięcia tego programując pic32 w asm....



Na codzień programuję pic32 i pic18, przywykłem do obszerności ich
dokumentacji.



Nie tylko jedna, pozostając w temacie rtc to np. brak pinu do batt
rtc.




Standard w pic.

--
Marek

Mon Feb 24, 2014 12:35 pm   

W dniu 2014-02-24 12:13, Sylwester Łazar pisze:

Chyba dla Macierewicza. W Tu154 odczyty danych były co 0,5 s a kompresja
i zapis w pamięci ATM-QAR trwały 2 sekundy.


--
pozdrawiam
MD

Mon Feb 24, 2014 12:37 pm   

On Mon, 24 Feb 2014 11:35:18 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Też buduje serwerek do stacji m.in. zbierającej dane z różnych
czujników i prezentowania ich po http. Zastanawiam się, po co Ci rtc,
jeśli masz stos tcp to powinieneś mieć ntp. U mnie stos korzysta z
ntp do synchronizacji czasu, nie potrzebny w ogóle rtc... z tego co
pamiętam u mnie uklad co 30min koryguje timer używany do timestampu i
odczuty czasu z ntp. Problem jest tylko w momencie startu gdy układ z
jakiś powodów nie ma dostępu do sieci.

--
Marek

Mon Feb 24, 2014 12:46 pm   

Ja zdaje się użyłem tego:
KWH043ST12-F03 V.2
Natomiast kupiłem to w opakowaniu, jako monitor cofania do samochodu.
Coś ok. 130 zł/szt.
Przy okazji podłączyłem do Video i sprawdziłem, czy działa
S.

Mon Feb 24, 2014 12:55 pm   

S.

#SPRAWDZENIE KLAWIATURY
KEYCHECK:
LW KBREADA2,0x6190(BF88S6) #odczyt klawiszy i maskowanie
ORI KBREADA2,KBREADA2,KBMASK #jeśli nic nie wciśnięto, to
#KBREADA2=0x0000FFff
ORI TEMPS1,zero,0xFFff
BNE KBREADA2,TEMPS1,PRESSED #Czy klawisz wciśnięty ?
ANDI TEMPS1,FLAGST6,bKPRESS
BEQZ TEMPS1,KBEND #Czy był wciśnięty wcześniej?
NOP #1-TAK 0-NIE
OTHKEY:
ANDI FLAGST6,FLAGST6,(1<<16-1)-bKPRESS-bKBAUTO #zaznacz: klawisz zwolniony
J KBEND
PRESSED:
BEQZ TEMPS1,FIRSTK #Czy był wciśnięty wcześniej?
NOP
BNE KBFIRSTA3,KBREADA2,OTHKEY #Czy ten sam klawisz co za pierwszym razem ?
ADDIU KBCOUNTT7,KBCOUNTT7,-1
BNEZ KBCOUNTT7,KBEND #Czy już odczekano ustalony czas?
ANDI TEMPS1,FLAGST6,bKBDEB
BEQZ TEMPS1,KEYDOWN #Czy już zatwierdzono naciśnięcie klawisza?
XORI TEMPS1,KBREADA2,#kTWO
ORI FLAGST6,FLAGST6,bKBAUTO #od teraz samopowtarzanie klawiszy
ORI KBCOUNTT7,zero,KBNEXT #skróć czas oczekiwania
SETCODE:
ADDIU KBCODES2,KBREADA2,0 #zapamiętaj odczytany klawisz
J KBEND
KEYDOWN:
BNEZ TEMPS1,WREP #Czy naciśnięto równocześnie UP i DOWN?
ANDI TEMPS1,FLAGST6,bKBUD
BNEZ TEMPS1,WREP #Czy zainicjowano już odliczanie czasu dla UP+DOWN?
ORI KBCOUNTT7,zero,KBUD
ORI FLAGST6,FLAGST6,bKBUD #czekamy na podtrzymanie UP+DOWN
J KBEND
WREP:
ORI KBCOUNTT7,zero,KBAUTO #czekamy na samopowtarzanie
ORI FLAGST6,FLAGST6,bKBDEB
J SETCODE
FIRSTK:
ORI FLAGST6,FLAGST6,bKPRESS #naciśnięto klawisz o raz pierwszy
ANDI FLAGST6,FLAGST6,((1<<16-1)-bKBDEB-bKBUD) #nie wiadomo czy 2 na raz
ORI KBCOUNTT7,zero,KBPRESS #ustaw czas potrzebny do odczekania
ADDIU KBFIRSTA3,KBREADA2,0 #nadaj wartość pierwszemu odczytowi klawisza
KBEND:
J GENMAIN
NOP

Mon Feb 24, 2014 1:01 pm   

On Mon, 24 Feb 2014 12:55:39 +0100, Sylwester Łazar<info@alpro.pl>
wrote:

?

--
Marek