A DS3231-ben nincs SRAM.

Két dolgot fogok elvetni:
- nem lesznek változó hosszúságú logok, így könnyen címezhetek
- nem lesz időtömörítés (2 byte-os deltát tároltam 4 byte helyett).

Minthogy minden log 4 byte-os időbélyeget tartalmaz, adott helyen van, így akár bináris algoritmussal kikereshető a maximális időbélyeg. Onnan lehet folytatni. Mondjuk az óraátállításnál gond lesz, de az nem kifejezetten érdekel.

Ha nem a local idot tarolod, hanem az UTC-t, akkor nincs vele semmi gond. Ha negy byte egy timestamp, az gyanoitom, hogy UNIX time formatumu.

Sajnálom ebben pl. van:
Bővebben: DS1307

(Ezért jó: Ha elöbb tervezünk, aztán építkezünk!)

Tervezési fázisban vagyok. Semmiből nem áll rendelni egyet az ebay-en.

Viszont nem biztos, hogy annyira tuti a RAM írás. Minden loggolás után ki kell menni egy SRAM frissítésnek is, ami majdnem dupla időbe telik.

56Byte nem felejtő ramba, akár logolni is lehet 5 * 8 Bytet és a végén 1*re irni az EEPROM-ba?

Szerintem itt az EEPROM kimélés lenne a fő cél nem a sebbesség!
Tulajdonképen mennyi ídőközönként akarsz logolni?

Nincs sok log, de néha egyszerre jönnek a logok (főleg indulásnál ugrik meg).

Automata öntözőrendszert csinálok, web-ről vezérelve. Indulásnál csinál is valamit, vagy ha RC távirányítóval elindítok egy öntöző programot.

Letölti az időjárás előrejelzést a netről, hogy kell-e locsolni, ütemez, web-en keresztül lehet majd konfigurálni.

Méri a szivattyú áramát, túlterhelés/üresjárás esetén lekapcsol, emellett nézi, hogy a mágnesszelepek áram alatt vannak-e. Nem szeretném, ha elszakad egy vezeték, a szelep lezár, a szivattyú meg továbbra is pumpálja a vizet.

Nem véletlenül áll a kód 90%-on, sok ez egy nano-nak. A web-szervert az esp-link (ESP8266) biztosítja egyik patchemmel (jófej volt a fejlesztő, mert elfogadta).

Web-szerver videó itt: https://www.youtube.com/watch?v=d8byiqnbxRk

Ha a mágnesszelep lezár, és a szivattyú tovább pumpál, ott szerintem már áramemelkedés (túlterhelés) van, amit ha jól belőssz, felesleges a mágnesszelepek állapotát is figyelni egy plusz lábon (persze ha van elég pin, akkor lehet)...

Elég jól állsz már a projectel!

Viszont mégis eljönni látszik az a pillanat mikor kinövöd a HW lehetőségeit!

Csak kevés tanulásba került volna!
És ezzel nem lenne ilyen gondod: Bővebben: Link flash 64k! Szemben a mostani 16K-val

Bővebben: STM32F103C8

A szivattyú árammérés a legkevesebb. Veszek 6 db 3A-es schottky diódát. 3 egyirányba, vele 3 párhuzamosan a másik irányba. A három diódán esik 1.5V feszültség, függetlenül attól, hogy milyen fázisban van.

Erre rákötök egy 2 irányú optó-ellenállás combo-t és máris látom, hogy megy-e a szelepeken áram.
A hátulütője, hogy amikor a 24VAC nullátmenetben van, akkor nincs áram.

És persze tekercsről van szó, tehát indulásnál sincs áram. Időbe telik, míg a mágneses tér feláll.

Nyilván nem egy mérés alapján kell dönteni, hanem több mérést átlagolva...
De én nem is ezt vitattam, hanem arra tippeltem, hogy ezzel akár megspórolható a szelepek figyelése is...

Elmondom, hogy mi a bajom az STM-mel. Nem kívánok magányos partizánként fejleszteni rá.

Az Arduino-t letöltöm, felrakom a szükséges lib-et, ha megy örülök, ha nem megy újraírom.
Az Arduino megy a legtöbb AVR alatt és az ESP8266-ot is jól támogatja.

Az elvem az, hogy ha valaki egyszer feltalálta a kereket, akkor nem szeretném újra feltalálni. Ami létezik a web-en és elérhető, azt nem fogom újra megcsinálni megfelelő indok nélkül.

Az Arduino nagyon sok kérdőjeles minőségű lib-et összegyűjt, installálom, vagy megy, vagy nem. Ha nem, akkor másik libet kipróbálok. A nagy projektet legóként összerakom, ha valahol gond van, akkor cserélem / újraírom.

Ha valaki egyszer megírt egy programot, ami nagyrészt használható, akkor abba integrálom a munkámat, ahogy az esp-linknél is történt. Megírták, hogy megnyomom a gombot, az ESP meg frissíti az Arduino szoftverét. Ezt sem kellett megírnom. Többé-kevésbé megy, ha baj van, a foltot elküldöm a fejlesztőnek.

Az STM-mel pont az a baj, hogy nincs mögötte közösségi támogatás. Egyedül nekilendülsz, csinálsz valamit, 10-szer több munka folyamatosan feltalálni a kereket, össze kapcsolni más fejlesztésekkel, mintha más mikrovezérlőt használnál. Arduino alatt készen van egy felület, hogy web-en keresztül programozzam, STM alatt megírhatom ugyanezt magamnak.

Nem szeretnék magányos partizánként harcolni a dzsungelben. Ez addig nem változik, amíg millióan nem kezdenek el STM-re fejleszteni és nem válik Arduino alatt ténylegesen élő platformmá.

Bocsi, szerintem nem tudod pontosan miről beszélsz az STM-el kapcsolatban. Hatalmas fóruma, és közössége van. Arduino alatt nem is fog egyhamar megjelenni, mert nem arra való. Ne keverd szerintem a szezont a fazonnal. Az arduino kis projektekre, művészbarkácsolásokra való, az ARM architektúrát és az STM-et sem erre hozták létre. FSMC, DMA, SDIO, HDMI, ... ezek egyhamar nem lesznek összekattintgathatók. Nem is lehet az alkalmazásoknál elpazarolni az erőforrást ezernyi rétegnyi shellre.

Szerintem a témát felesleges tovább boncolni, egyrészt OFF-ba megyünk, másrészt nem ugyan az a pálya egy 16MHz-es 8-bites, meg egy 400MHz-es 32-bites ARM... Tök felesleges összehasonlítani, mert egyszerűen nincs összehasonlítási alap, nincs egyetlen egy olyan periféria vagy közös nevező ami alapján összehasonlítható lenne. Igen van mindegyikben 16-bites timer. Csak nem mindegy, hogy az oda van kötve egy IO-ra, vagy IO-kezelő matrix köti oda, és Te választod ki, hogy Neked melyik IO-ra a legkényelmesebb kitenni az USART-ot, vagy melyik timer hw-es kimenetet tudod könnyebben behúzni a nyákon, azon a lábon hozod ki a periféria kimenetét. Másról, nagyon másról szól.

ARM-al nem kell partizánkodni, eszetlen dolog olyat állítani, hogy nincs közössége, főleg úgy, hogy minden okostelefonban, minden routerben, minden beágyazott cuccban, minden modern TV-ben, stb... ARM csücsül, úgy azt állítani, hogy egyedül vagy vele az erdőben, kicsit meggondolatlan. Főleg úgy, hogy az általad védett ESP8266-ban lévő Tensilica Xtensa mag is inkább ARM struktúrájú.

Részemről befejezettnek tekintem ezt a meddő vitát, illetve innentől az OFF-ok törlésre fognak kerülni.

Sziasztok,

Esetleg valaki tudja hogy lehet a BIGAVR6 ot használni ATMEL-ICE BASIC debuggerrel?
A board on 8 pin tüske van, de a debugger kábelének csatlakozóján csak 6 lyuk van.
Kell még közbe valami?

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

Érdekes, az adatlapon 6, meg 10 pines csatlakozó van. Ezekről van szó?
BIGAVR6
ATMEL-ICE Debugger
A 10 pólusu AVRISP-n sok GND van, a 6-oson csak 1.
Átalakító: Bővebben: Link, de ha a kábelt szétszeded elemi szálakra (vagy csinálsz egy olyan programozó kábelt), akkor mindenre rádughatod, nem csak szabványos bekötésű csatlakozóra, ha tudod hova mi van kivezetve.

6-pin ISP és 10-pin JTAG van a board-on és az ICE-on is.

Helló,
Ezzel azt akarod mondani hogy az ISP re rádughatom az ATMEL-ICE-t mindenféle adapter nélkül?

Kaptál már korrekt választ a Freaks-on! Egyébként én sem értem, hogy AT90CAN-hez miért kell ilyen drága board, ráadásul MCU nélkül.

Ja igen. Láttam olcsóbbat is, de ezt kell használjam.

Értem. Akkor az van, amit a fórumon is írtak. ISP-vel rá tudsz csatlakozni, ha debug is kell (JTAG), akkor szükséged lesz egy 50-100 mil adapterre:
Bővebben: Link
Kell egy MCU card is, amire rá kell forrasztanod a chip-et, mivel CAN-el nem kapható.
Bővebben: Link
Miért nem jó az Olimex? Oda csak egy adapter kell.

Szia,
Az Olimex-et nem ismerem, másrészt jelenleg nem azt kell használni. Sajnos egyenlőre meg van szabva mit kell használjak.
Igen vettem üres MCU board ot meg AT90CAN128 at, rá kell forrasszam, vagy forrasztassam. Forrasztógép nincs nekem, jó esetben ügyes kezem.

Sziasztok!
Röpke kérdésem volna, mert ilyet még nem tapasztaltam.
AtMega88PA-t használok egy panelban. Az egyik panel felprogramozás és ismételt táp bekapcsolás után kb. 1/2 - 1/3 órajellel dolgozik a LED-ek állapotváltásait figyelve.
Ha a táp bekapcsolás után aktiválom a reset lábat, akkor "megtáltosodik" és úgy működik, ahogyan az a nagy könyvben meg van írva, na meg az összes többi panel is szokott.
Szerencsétlen IC-t vettem?
Vagy van valami, amit még sosem állítottam be és most kellene?
Üdv!

Én a leírtakból arra tippelek, hogy a tápod lassan áll fel és/vagy az órajel-beállításoknál túl kicsi várakozást adtál meg. Bővebben: 26-ik oldaltól. Bár én eddig kivétel nélkül a legnagyobb várakozással indítottam.

Nem lehet tápegység gond, mert normál kapcsoló van a táp ráadásakor, valamint 3 különböző tápnál is próbálkoztam.
Elsőre én is ilyet tippeltem, de nem segített egyik verzió sem, amit felkínál a Dragon.

Ugyanebből az IC sorozatból (vagyis azonos időben vásároltam) beültettem másik panelt is. A helyzet megismétlődött. Van lehetőség tehát nézelődni a programban, milyen apróságot követtem el.
Azóta kicsit kutakodtam a programomba.
Az Adc időzítőjét használom valós idejű idő mérésre, azt tippelem, hogy lesz valami bibi. (Tudom nem a legpontosabb, de nem is az volt a cél jelen esetben. A többi timer máshoz kellett.)

Igazad volt, az Atmega328P nem elég erős kerti locsolós projekthez. Ha most 90%-on áll a program, akkor elég nagy a gond, mert nincs további fejlődési potenciál a projektben.

Megcserélem a két IC-t, az AVR IO port lesz, az ESP8266 meg mester.

Néha olcsóbb újraírni a dolgokat, mint addig ütni a lovat, amíg megdöglik. Alapvető tervezési hiba volt, hogy a gyengébb IC-be került a logika, az erősebbik meg nem csinált jóformán semmit. Igazából nem voltam tisztában azzal, hogy mennyire bonyolult egy ESP-t felprogramozni. Egyáltalán nem nehéz komplex web-es alkalmazást írni rá, szóval tisztázódott, hogy kinek mi a dolga.

Miután fejben összeáll minden, néha le kell vonni a következtetést, ha eddig zsákutcában voltam és újra kell értékelni mindent.

Természetesen elég erős hozzá (ha egy komplett CNC vezérlés belefér[GRBL projekt], akkor a kerti locsolás nem jelenthet gondot). Persze ha Arduino-ban programozod, akkor nem csoda ha nem fér bele.

Wifi kapcsolat + automatikus ütemezés + ADC teljesítmény mérés + szelep kapcsolat ellenőrzése + loggolás + időjárás előrejelzés letöltése a netről + ütemezett kerti lámpa felkapcsolás + RC rádiójel hallgatás + RTC time + idő letöltése a netről NTP protokollal + web felület kiszolgálása.

Ami sok, az a WEB kiszolgálás, netes hülyéskedés és a loggolás is 40% körül lehet.

Meg lehet írni rövidebben assembly-ben, de a 32k-s chip méreten ez sem fog max 20%-ot segíteni, cserébe meg hónapokig lehet vele szórakozni. Az Arduino overhead-je nem lehet több 10%-nál.

Kicsi a chip, nem erre lett kitalálva.

Az arduino overheadjét nagyon alábecsülöd, ennél sokkal nagyobb. Assemblyvel pár speciális résztől eltekintve nem érdemes vesződni. A modern C fordítok a legtöbb embernél sokkal jobb assemblyt generálnak.

Vannak opciók, amiket beállítva 10%-kal kisebb kódot kapsz. A lib-ek minősége már nagyobb gond, a tapasztalat az, hogy 50% újraírás kell.

Mindenféle minőségi ellenőrzés nélkül beletolnak mindent. Utána meg bámulok, hogy egy wifi kliens miért blokkol, amíg nem jön válasz. Soha ésszel senki át nem gondolta, hogy esetleg fél percig is megakaszthat mindent, azt nézel, mert értelmes magyarázat erre nincs. Újra kell írni.

Érezhető fejlődés azért van, vannak kimagasló minőségű kódok, de még mindig sok az egyéb is.

Sziasztok urak
Valaki használta már az AT90CANXXX mikrovezérlők CAN perifériáját? Konkrétan 2 ilyen proceszort kötöttem össze CAN buszon keresztül (egyik adó, másik vevő). A problémám a vevőnél van, nem tudom törölni a flag bitet(RXOK) a CANSTMOB regiszterben. Az adatátvitel működik, csak így hogy nem törlődik a flag bit, folyamatosan kéri a megszakításokat a vevő.
Az adatlap szerint "read-modify-write software routine" kell alkalmazni, viszont nem tudom hogy ez mit is jelent, a neten pedig nem találtam róla semmit... mindenesetre a klasszikus "törléshez ráirok 1-est" ebben az esetben nem működik.

A read-modify-write azt jelenti, hogy olvasod, valtoztatod, (vissza)irod. Valoszinu, hogy ez lesz a megoldas:

CANSTMOB &= ~(1 << RXOK);


Lehet, hogy nem kell az 1 <<, csak az RXOK, nem tudom, hogy pontosan mi az RXOK definicioja.

A lenyeg, hogy egyszeruen kiolvasod a regisztert, letorlod benne az RXOK bitet es visszairod.