Akkor félreértettem.

Ebben az esetben valószínűleg az a gond, hogy a kontroller előbb kezdi (kezdené) vezérelni a kijelzőt, mint ahogy az észhez tért volna. Bekpacsoláskor legyen pl. egy másodpercnyi késleltetés, mielőtt a kijelzővel valamit is csinál az UNO.

Ez már be van építve a progiba. Van egy késleltetés és utána egy 1 mp-es reset jel és újabb késleltetés.
Olyasmire emlékeztet a jelenség, mintha valahol lenne benne egy kondi ami nagy értékű ellenálláson keresztül csak lassan tud kisülni is meg feltöltődni is.

Logikai analizátorral kell ellenőrizni a vezérlőlábakat, mi történik bekapcsoláskor. Konkrétabbat nem tudok mondani, egyszer-kétszer foglalkoztam ilyen kijelzővel de elengedtem, nekem nem jöttek be.

Azért köszönöm.
Egy nem túl elegáns megoldás lenne. Monostabil időzítővel késleltetve adni egy reset jelet magának a kontrollernek, hogy egyetlen egyszer induljon újra néhány másodperc elteltével, csak hát....

Hogy van bekötve, milyen libet használsz, hogy néz ki setup, enélkül...

Tényleg látni kellene a kódot, de legalább a Setup-részt.
Szerintem a hosszú idejű kikapcsoláskor a vezérlő memóriája szeméttel lesz teli és nincs rendesen inicializálva a setup-nál. A kód többi részénél lehet, hogy van olyan utasítás, ami megteszi esetleg, de nem frissül a képernyő. Gyors újraindításkor pedig már azzal frissül, ami a vezérlő memóriájában van.

Ez csak tipp, de ilyen fura bug -is lehet. A másik pedig, hogy az 1 sec késleltetés hol van? A vezérlő nem jelez vissza.

De csak 1x olvastam a leírását, és lehet nem ez a gond, mert azt írja, hogy auto reset van, mikor bekapcsol. (csak átfutottam)

De ami a leírásból kijött még, hogy 8 és 4 bites módja van az írásnak. Melyiket használod?
Ha négyet, akkor a szabadon lévő lábak mire vannak kötve?

Van ott busy flag is, meg sok minden ebben a vezérlőben, szóval lehet sok minden. Gondolom valamilyen lib-et használsz.
Ha nem lebegnek a lábak sehol sem, és a táp is stabil, akkor a lib-ben lehet hiba, vagy a lib-nek nincs meghívva valamelyik függvénye tisztességesen.

Bár nem Arduino-nál, de nálam okozott sok meglepetést az, hogy nem bírta a táp sem meghajtani az összes eszközt, illetve a közös GND hiánya is okozott már meglepetést.

No de mindez csak találgatás, több infó kellene, mint ahogy a többi fórumtárs már említette.

Vagy tényleg kondi + ellenállás hiba van valahol, mint ahogy mondod, de akkor meg a kapcsolás kellene + táp.

Ez egy korábban készült program. Annyi különbség a setup-ban, hogy ebből hiányzik az 1 sec display setup.
Ugyan úgy zavaros a kijelző hosszabb kikapcsolás után.
A program eleje a loop-ig:

#include <Arduino.h>
#include <SoftwareSerial.h>
#include <pcf8574.h>
#include <U8g2lib.h>
#include <SPI.h>

U8G2_ST7920_128X64_1_HW_SPI u8g2(U8G2_R2, /* CS=*/ 10, /* reset=*/ 8);

PCF8574 ex1(0x39);

const byte interruptPin = 3; // Gomb
const byte rxtxPin = 6; // Bekapcsolás első lépés
const byte pttPin = 9; // Bekapcsolás második lépés
volatile bool buttonPressed = false; // Gomb állapotának jelzője
volatile bool processNeeded = false; // Indikálja a folyamat indítását
unsigned long processStartTime = 0; // Időzítéshez
bool turningOn = false; // Bekapcsolási vagy kikapcsolási folyamat
bool catError = false;
bool modPin = 3;
bool Flag1 = 0;
bool Flag2 = 0;
const int monitoredPin = 3;
bool lastState = HIGH;

SoftwareSerial CATSerial(2, 4); // RX, TX

unsigned long lastRequestTime = 0; // Előző lekérdezés időpontja
const unsigned long requestInterval = 1000; // 1 másodperces intervallum
float frequency; // Az aktuális frekvencia
float previousFrequency = 0; // Az előző frekvencia
int summa;
String band = "Unknown"; // Globális változó a sáv tárolására
String onair;
String data;
//int lastState = HIGH; // Kezdeti állapot
bool risingEdgeDetected = false;
bool fallingEdgeDetected = false;
bool flagCATEnabled = false; // A CAT engedélyezés vezérléséhez

void setup() {

pinMode(7, OUTPUT);
digitalWrite(7, LOW); // 12V switch
pinMode(interruptPin, INPUT_PULLUP); // Gomb alapállapota HIGH
pinMode(rxtxPin, OUTPUT);
pinMode(pttPin, OUTPUT);

digitalWrite(rxtxPin, LOW); // Kezdeti állapot
digitalWrite(pttPin, LOW);
delay(1000);
digitalWrite(7, HIGH); // 12V ON
pinMode(monitoredPin, INPUT);
CATSerial.begin(4800);

attachInterrupt(digitalPinToInterrupt(interruptPin), handleButtonPress, CHANGE); // Gomb megszakítás
u8g2.begin();
u8g2.initDisplay();
u8g2.clearBuffer();

u8g2.firstPage();
do {
u8g2.setFont(u8g2_font_9x15B_tf); // choose a suitable font
u8g2.drawStr(1, 16, "DIPLEXER BLOCK");
u8g2.setFont(u8g2_font_8x13_tf);
u8g2.drawStr(6, 32, " CONTROLLER");
u8g2.setFont(u8g2_font_5x8_tf);
u8g2.drawStr(6, 46, " MADE BY HA4PL");
u8g2.setFont(u8g2_font_5x8_tf);
u8g2.drawStr(1, 63, "IS A CAT CABLE CONNECTED?");

} while ( u8g2.nextPage() );

delay(5000); //

}

Ok, köszi!

Szerintem már sokan nézik nem csak én.
Tegnap elfelejtettem részletezni, hogy a busy láb nem lenne jobb? Azaz nem 1s fix figyelés, hanem egy while ciklussal figyelni ezt a lábat, mert az fordított logikával nézi, hogy foglalt-e az eszköz.

Nézegetem most kicsit.

Elsőként pár dolgot próbálnék ki.

Nekem nem tetszenek a szoftveres megoldások a serial-ra, de mehet.
Sok az include, amibe nem látok bele, mert azt is át kellene futni.
De:
u8g2.begin();
u8g2.initDisplay();
u8g2.clearBuffer();

Itt nem ártana ha a busy flag-re építve lenne a várakozás. De nem feltétlenül ez a hiba, mert a hívott függvényekben lehet késleltetés is, de nem látom. Az utasítások halmozódhatnak, az első fel sem lett dolgozva, már jön a másik. Ez okozhatja a gyors egymásutáni indításkori problémát, mert lehet, hogy a kijelző vezérlő elvégezte a korábbit.. Nem tudom, csak ötlet.

A várakozás nem jó. A delay megállít mindent, még a megszakításokat is, ha jól emlékszem. Készíts saját kis .h késleltető, várakozó fájlt micros-ra építve, és úgy várj, ha nem használod a busy pin-t. (de lehet nem is erre jó az a pin, csak átfutottam a leírást)
A CAT serial 4800 jó? Mármint a használt órajel frekihez ez mekkora hibaszázalékot ad?

Ez mire kell pontosan?
float frequency; // Az aktuális frekvencia
float previousFrequency = 0; // Az előző frekvencia

Nem szereti az Arduino a Float-okat, de a String-eket sem nagyon. Jelentősen lassítja a float, az biztos, meg lehet, hogy máshol a típusváltás problémás lehet.
Int nem elég?
SPI és a többinek menne kell, mert anélkül semmi eredmény nem lenne. Én az utasítások után egy 100-150us-et várnék, a saját kis micros-ra épülő kódommal, majd megnézném ezt a busy flag pint is.
Persze nem biztos, hogy az a gond, de utána mennék tovább.

Főleg:

digitalWrite(7, HIGH); // 12V ON

Gondolom ez ad tápot a kijelzőnek. Ide tetted gondolom a korábbi 1 sec delay-t. Itt kellene szerintem várni, míg feléled a lelkem.
Az utasítások után is várni kellene szerintem.

Elsőnek ennyi jutott eszembe, nem tuti megoldások, de gondolatébresztésre lehet elegendőek lesznek.

Köszönöm mindenkinek a segítségnyújtást.
A probléma megoldva.
A kijelző eddig levegőben lógó DB0 - DB7 lábait lehúztam GND-re és ettől meggyógyult.
Még egyszer köszönöm a hozzámállást.

Amúgy a bemásolt program egy amatőr rádió által aktuálisan használt frekvenciát kérdezi le, és ehhez meghatározza a megfelelő diplexert (adószűrő) és azt beiktatja az adó kimenete és az antenna közé.
A 4800-as átviteli sebesség megfelelő, mivel a rádió alapból ennyin kommunikál.
Delay csak a setup részben van, mert a loop-ban ütközne a millis időzítéssel a megszakításokban.
Üdv.

float frequency; // Az aktuális frekvencia
float previousFrequency = 0; // Az előző frekvencia

0 nem elég több mikrokontrollernél. 0.0 kell, mert túlcsordulást okozhat, ami bizonyos regiszterekben jelző flag-ként meg is jelenik szerintem, és lehet bezavar az interruptokba is. Ezt nem tudom 100%-ban, mert ugyan volt ilyesmi interruptos hibám is, amit nem tudtam felderíteni pontosan, de túlcsordulás hibát okozott az biztos. Arduino IDE lehet ezt kiküszöböli automatikusan, nem tudom.
Az aktuális frekvencia meg SEMMILYEN kezdőértéket nem kap, nem feltétlenül hiba, de ha az IDE-ben épp ez bug-os rész, akkor nem javítja esetleg.

A float-ot kerülném. Használnék sima int-et, max long int-et és 10,100,1000 el megszorozva az értéket, ha számolni kell vele.

Kijelzéskor pedig az egész részét venném a megfelelő osztással, majd kivonnám az eredetiből az így kapott érték megfelelő értékkel vett szorzatát. Az így kapott eredmény a tizedesek. kijelzéskor egy pontot tennék a kettő közé.

Freki= 55123 jelenti a 551.23Hz-et
Freki_egesz=int (55123/100)=551
Freki_tizedes =Freki-(Freki_egesz*100)= 55123-55100=23

És a kijelzés. Valami ilyesmire gondoltam. Természetesen lehet neked ez nem jó ide, mert a többi kódodba nem lehet betenni, csak gondoltam leírom.

Ok, ezt fejből írtam, lehet nem pontosan így kell, de ha lehet akkor mellőzném a float-ot.

Erre már utaltam, a lebegéssel.

Igen. Ezt próbáltam az imént megköszönni.
Üdvözlettel,
Laci

RTC_írás-olvasás

Sziasztok! Segítséget kérek: RTC-s kütyüt építettem, de az óra késik!
Infra távirányítóval lehet beállítani, ez működik.
A késés korrekció nagyon furcsán viselkedik. Ha engedélyezem a clock.setTime() -t a másodperc teljesen felborul. RTC olvasása után ill. a program más részében a soros portra kiküldve a másodperc 30-90-el eltolva ( és 3-al előre-hátra ugrál).
Ha ez a sor nincs engedélyezve, minden rendben van. (természetesen ekkor nincs korrekció)
Ebbe a blokkba, elvileg, csak "0:0:0"-kor léphet be.
Ugyanez a sor az RTC beállítás programrészben hibátlanul működik.

Lehet a számokat át kell váltani binárisból BCD-re, vagy vissza

Csak akkor romlik el a dolog, ha be van írva a "clock.setTimes()" sor a késés korrekciós részbe!

Szia!

Nem pontosan értem, hogy miért kellene működnie.
Ha a github-on lévő "DS1307.h"-t nézem, ott van néhány dolog.
- uint8_t változókkal kell a set time és a set date-et meghívni.

Ráadásul kétszer, mert az egyik a set time, a másik a set date.

Ennek az AktIdo[] tömbnek uint8 típusnak, vagy azzal egyenértékűnek kell lennie az Arduino-ban.

AktIdo[4]=(clock.hour);
AktIdo[5]=(clock.minute);
AktIdo[6]=(clock.second);

clock.setTime(AktIdo[4],AktIdo[5],AktIdo[6]);//write time to the RTC chip

Itt is hasonlóan:
setDate(uint8_t date, uint8_t mon, uint16_t year);

De mint látom, te valami
clock.fillByHMS
-t használsz, azt nem értem hogyan működik sajnos, de ebben az esetben is kellene valami érték a clock.setTime() függvénynek gondolom, mivel hogy kapna pontosan értéket ez a függvény?

De nem 100% amit írok, csak átnéztem, nem tudom kipróbálni.

A pontosabb megértéshez szerintem tudni kellene pontosan melyik "DS1307.h" fájlt használod. Abba kellene belekukkantani, hogy melyik függvény mit és milyen változó típussal kér. Esetleg milyen struktúrával.

Ezeket a file-kat használom. A tömb változóknak "byte" és "uint8_t" is próbáltam. Teljesen mindegy volt ugyanazt csinálta.
Azt nem értem, hogy tud elromlani a másodperc kezelés attól, hogy beírok egy sort "clock.setTimes()" egy olyan részbe amibe csak naponta 1x, éjfélkor, léphetne be.

Ok, most már látom, hogy teljesen más .h és cpp fájlt használsz, így amit előzőleg írtam nem is jó. Bocsánat érte!

De amit rögtön láttam az az, hogy ebben az esetben több típus van. Más, mikor kiolvasod és más mikor be kell állítani. Nézd meg a .h fájlban a függvényeket mit is kérnek.

Azaz lehet, hogy az AktIdo[] tömb típusa sem jó, nem tudom milyen. Figyelni kell mert például a year az 16 bites ha jól láttam, mikor a fillByYMD()-t kell használni, de a getTime() 8 bites számmal tér vissza.
A másik, hogy ha megnézed a .h fájlban ezt:

void DS1307::fillByYMD(uint16_t _year, uint8_t _month, uint8_t _day) {
year = _year - 2000;
month = _month;
dayOfMonth = _day;
}

Akkor látszik, hogy kivon belőle 2000-t. Szóval ha 8 bites lenne a tömb, akkor eleve hibás minden. De ami a legfontosabb:

clock.fillByYMD(AktIdo[0]+2000, AktIdo[1], AktIdo[2]);

Azaz hozzá kell adni 2000-t, ha csak az utolsó két évet tárolod a tömbben, ami ekkor lehet 8 bites is. És tényleg lehet, hogy mikor kiolvasod a get_time-al, akkor csak az utolsó két számjegy lesz tárolva, és ekkor a sima uint_8 lehet jó tömbnek, de ekkor figyelni kell, hogy 2000-t hozzá kell adni a clock.fillByYMD()-ben, mert ott meg 16 bitest kér.... Ha nem, akkor nem kell hozzáadni, hanem egy 16 bites előjel nélküli egészben tárolva maradhat, de akkor a tömb milyen típus is?

De a tömböt felejtsd el, adj mindennek megfelelő változót.
uint_16 ev=clock.year; //Ez már eleve megvan
De a year lehet csak uint_8, mikor a gettime()-al kiolvasod!!!

uint_8 honap=clock.month;
uint_8 nap=clock.dayOfMonth; //hónap napja
uint_8 het_napja= clock.dayOfWeek; //hét napja
uint_8 ora=(clock.hour);
uint_8 perc=(clock.minute);
uint_8 masodperc=(clock.second);

(úgy definiáld a változókat ahogy az Arduino kéri)
Ha ki tudtad olvasni, akkor serial-al írasd ki, hogy lásd minden rendben van-e velük. Addig nem is kell továbbmenni.

Ha a serial-al kiírt RTC-ből kiolvasott értékek jónak tűnnek, akkor lehet tovább menni szerintem.
(setup-ban lehet az RTC-nek valami kezdő értéket megadni, de ott lesz a hiba megint, mert ott is settime()-ot kell használni.)

( Ekkor eldől a year -t hogyan is kell kezelni pontosan, mert ha két számjegyű pl. 25 lesz csak, akkor 2000-t hozzá kell adni. Vagy eleve készítesz egy új változót: uint_16 ev_hosszan=ev+2000;
és ekkor clock.fillByYMD(ev_hosszan, honap, nap); )

És akkor:

clock.fillByYMD(ev, honap, nap);
clock.fillByHMS(ora,perc,sec); // Ahol a sec az az uint8 amiben a jó érték van
clock.setTime();//write time to the RTC chip

A kódod többi részét nem látom, ezért nem tudom eldönteni hogy miért hívódik ez meg többször is egymás után esetleg. Az if feltételnek minden esetben eleget tehet, mert minden kezdőérték 0 mikor indul a rendszer, azaz lehet folyton meghívódik ez a kódrészlet.
Vagy azért hívódik meg, mert a tömb elemei nullák, hiszen nem tudjuk milyen típusúak, amikbe beletenne a függvény uint_8-akat.

Mindenekelőtt a serial.print-el a tömbelemeinek értékadása után írasd ki azokat, gyanítom, hogy nullákkal lesz teli, ezért is lehet a feltétel mindig igaz! És csak ezek után amiket mondtam.
Bocs, elfáradtam mára, holnap ránézek még, mert lehet teljes zöldség amit írtam.

Szóval itt:

Még valami eszembe jutott.

Ha a tömb elemei nem is nullák, akkor is lehet hiba! Abban az esetben, ha a tömb elemei 16 bitesek, akkor a 8 bitnyi infó az alsó nyolc bitre kerülnek. Serial print-nél jó minden esetleg. De!

Ezután jön ez:
clock.fillByHMS(AktIdo[4],AktIdo[5],sec);
ok, de ez a függvény 8 bitet ír csak ki minden változóból, de elképzelhető, hogy épp csak azt a 8 bitet, ami csupa nulla, így valójában az RTC folyton nulla óra nulla perc, nulla másodpercre áll be.
Persze nem tudom ellenőrizni, de ilyen hibákba már futottam bele.

Az RTC folyamatosan megy. A loop() úgy indul, hogy kiolvasom az aktuális időt, és Serial.print...- idáig minden rendben. (Az évet is jól kezeli). Rögtön utána jön a késés korrekciós rész amit elvileg át kell ugrania. Ha belemenne "Serial.println("korrigálási idő van");" sor miatt látnám. A menu aktuális állapotát az else miatt nyomon tudom követni. Teljesen mindegy, hogy mennyi az idő ha ide a "// clock.setTime()" így van írva jól működik, de ha kiveszem a "//" azonnal meghülyül a másodperc. (VFD-n kint van az idő ill. év,hó,nap stb hőmérséklet is futófényként kijelezhető.)

Üdv!

Akkor sajnos nincs ötletem, nem tudom leellenőrizni sem, mert nekem 1302-es RTC-m van csak itthon.

Ha nem gond akkor a teljes kódot minden libbel ide tehetnéd egy zip-ben hátha valaki rájön mi a gond.

Az alábbi programrészlettel megoldódott. (Az eredeti helyen levő "clock.setTime();" törlésével)
Az már csak hab a tortán, hogy az "IdoMod"-ot jól kezeli, de a soros monitoron az aktuális másodpercet írja ki. (Az ehhez hasonló bug-ok miatt nem kedvencem az arduino. )