Milyen adatbázisra gondolsz? Pl. MySQL vagy egyszerű táblázat, amiben lehet keresni?

Olyan kell amibe lehet keresni ill, módosítani. Excellre gondoltam, de úgy néz ki nem lesz jó.

Üdv

A neten van pár megoldás, de amit találtam az csv, vagy Epromra ír. Mondjuk az Epromos megoldás áll a legközelebb szerintem.

Az 'Adatbázis' legegyszerűbb módja, hogy fix byte hosszúságú rekordokat készítesz. (struktúra)

pl.: Int Id, int adat1, char szoveg[10] Ez pl egy 'Sor' ( bár nem kell soremelés karakter egyáltalán a fájlba)
Így, mikor beírsz a binárisan megnyitott fájlba, akkor minden esetben előre tudod annak mekkora a mérete byte-ban. Miért jó ez? Egyszerű, mert pl könnyen lekérdezheted a fájl méretet. Abból egy sima osztással megtudod mennyi rekord van benne, mert a fájlmáretet byte-ban elosztod a rekord méretével.

Keresés:
Sima intervallumos keresést készíthetsz, ha az egyik oszlop (nem csak az ID) folyton nő, pl ha az idő. Ennek nézz utána, nem bonyolult.

Mindezt az teszi lehetővé, hogy a seek() parancs segítségével a fájlban a megadott helyre ugorhatsz, és onnantól olvashatod ki a rekordot.

Pl, ha egy rekord 10 byte, és a fájlméret 500 byte, akkor 50 rekord van benne. A 25. rekordhoz ugrást a seek() paranccsal meg tudod oldani, mert a 24*10=240. byte utáni pozícióra ugrasz. Onnan kiolvasod a rekordot, ami a 25. lesz.

Ez könnyű ám, a hibakezelés lesz a bonyolultabb. Pl, ha az időpontokat is elmented, akkor arra figyelni kell, hogy az utolsó rekordnál nagyobb legyen. Ez fontos lehet a keresésben.

De lesz előre megírt könyvtár is. Bár szerintem szép megoldás lenne, ha sikerülne megírnod magad.

Kis függvényeket kellene írni, amik meghatározzák a következőket:
-Fájl mérete.
-Fájl megvan-e nyitva
-Rekordok száma
-Minimum id
-Maximum id
-Udate(adott rekord felülírása)
-Beszúrás (fájl végére írás)
-Lekérdezés (adott helyen lévő rekord kiolvasása)
-Keresés

Ha jól fel van építve a fájl, és az adatok helyesek, akkor könnyen kereshetővé válhat minden. A függvények szerintem nem is annyira bonyolultak.

Csináltam egy kis txt-t. Igaz ebben a számok szövegként vannak tárolva, és soremelés karaktereket is tartalmaz.

Ha megnézed wordpad-ban és hex-ben, akkor látszik, hogy hol vannak a soremelés karakterek. Cr és Lf.

Csak példa, hogy lehetne szövegként is tárolni soronként, de kicsit macerásabb, mert a seek()-hez hozzá kell venni a soremelés 2byte-ját is. No meg csak ASCII karakterek lehetnek benne.

A txt fájlban 3 rekord van. Mindegyik 19 byte hosszú. 3 byte(szövegként tárolva) az ID, utána betűk, meg utána a dátum. Ha megnézed ez 57 byte. Azonban a tárhelyen 61 byteot foglal el. Ezek éppen a 2db Cr és Lf karakterek, azaz 4 byte. Az utolsó sorban nem ütöttem entert, ezért csak kettő soremelés van. Arduino ban lehet a soremelés csak 1 karakter, meg lehet EOF karakter is. Ezeket figyelembe kell venni. De nem kell bele soremelés egyáltalán, de ha szövegként tárolsz mindent, akkor az jobb lehet, mert pc-n is megnézheted. Soremelésekkel szebb lesz... De seek()-nél ezt figyelembe kell venni, illetve a szövegként tárolt számokat folyton át kell majd alakítgatnod az arduino-ban.

De mindez csak rendezett adatsoron működik, azaz az intervallum felezéses keresés, más néven bináris, vagy logaritmikus keresés. Ez azért gondot okozhat...

Engem inkább az zavar ebben a játékban, ha nem a végére, hanem valahová közben kell beszúrni adatot. Mert ekkor ugye helyet kell csinálni az új elemnek. Vagy a törlés. Nem esett szó arról, hogy ez a bizonyos adatbázis milyen műveleteket kell hogy támogasson, tehát az írást igénylő feladatokat nagyon át kell gondolni! Merevlemez esetén ezek úgy mentek, hogy a fat táblában pár bejegyzést át kellett írni és kész. Nade sdkártyán? Pláne eepromban? Azért itt nagyobb lesz a falat! Konkretizálni kellene az elvárásokat, és akkor könnyebb célt is érni! Amúgy érdekes feladatnak tűnik, van benne kihívás
szerk.: Tudom nem te vagy a kérdező, de közben átúsztam a msáik válaszra bocs..

Esetleg át is lehet ugorni az sd kártyát és közvetlenül xls-be menteni az adatokat pl: calc + arduino

Sok-sok évvel ezelőtt próbálkoztam hasonlóval, egy már akkor is harmatgyenge de kis fogyasztású EEPC-re tettem fel linux-ot + calc-ot (xls-ben is tud menteni) és arduino-ról tudtam menteni az adatokat közvetlenül xls-be, és txt-be.

Sőt, ha már kiszabadultunk a hardverből, én futtatnék egy php+sql kombót egy free szerveren, és neki adnám oda az adatbáziskezelés nyűgjeit! Az arduino meg foglalkozzon az adat előállításával, és küldje fel a szervernek. Egy esp megoldja. Sima liba!

Itt megoldottak valamit, bár lassú lehet az insert, meg a törlés. Bár nem tudom azok mennyire kellhetnek. De ok, feladom nem ez kell neki, már látom.

Bővebben: Link

Szia

Fontos lenne az SD kártya, mivel akár több száz rekordról lehet szó, meg kell adni a lehetőséget az adatok mentésére, ami egyszerűsítené a dolgot, nem kell felülírni, ill megúszható lenne 1 oszloppal (max sorszám miatt 2)
Köszi az eddigi segítséget, szépen összefoglaltad, mondjuk nem sokat értek belőle, de azért köszi

Ha még nem érted?
Itt van egy jó példa: Bővebben: Link

Ezt már tesztelheted is.
Ha részletesen le írnád mit szeretnél? Könnyebb lenne segíteni!

Ha már komolyabban bele merülsz?
Itt van egy cikk sorozat, különböző adatbázisok létrehozására, és azok ofice vagy exszel-ben való megjelenítésére akár táblázatos formában.

Fájlkezelési szempontból nem különbözik egymástól a hdd és az sd kártya. Önmagában mindkettő csak szektorok írására és olvasására alkalmas, a fájlokat már az operációs rendszernek, vagy mikrovezérlő esetén a fájlrendszer kezelő függvényeknek kell biztosítania. Fájl közepébe beszúrni tudtommal sehogy nem lehet, ha belenyúlsz a fájlkezelő eljárásokba, akkor is csak kerek n*cluster méretű darabokat szúrhatsz be az n*cluster pozícióba (fat12, fat16, fat32 esetén). A fájl végéhez már nyilván tudsz hozzáírni. Az adatbázisoknál is úgy szokták csinálni, hogy az új rekordot a fájl végéhez írják, törlés esetén pedig csak a rekord bejegyzésnél egy "deleted" jelzőt állítanak át igaz értékre. Ha rendezett táblázatra van szükség, akkor a sorrendet pedig egy adatrekordoktól független "index" táblázatban szokták nyilván tartani. Az is megoldható, hogy az új rekordot egy törölt rekord helyére írjuk (beleírni bele lehet a fájl közepébe, csak beletoldani nem). Ha pedig nagyon sok a törölt rekord, akkor szokták még az adatbázist "tömöríteni". Ezt a nem törölt rekordok másik fájlba történő másolásával szokták megoldani, majd a másolás végén törlik az eredeti adatbázis fájlt, a másolatot pedig átnevezik a törölt fájl nevére.

Bocsi! A linket elfelejtettem be szúrni:
Bővebben: SD kártya kezelése.

És egy rekord mennyi adatot tartalmaz?
Adatok későbbi feldolgozása hol, hogyan történik?

Kártyás beléptetőt akarok csinálni, kb mint ha IP címeket kellene tárolni.
Köszi a példákat, ezeket már átnyálaztam.
Itt ami elvárás lenne, bármikor új rekord hozzáadása, keresés rekordok között, törlés, kb ennyi

Serial EEPROM I2C (pl:24Cxx), soros adatátvilel PC és Arduino között?
PC-n meg sima szövefájlban, spéci elválasztó karakterekkel...

Miért nem jó a .csv ? Excel megnyitja, szerkesztheted.

Ez egyszerű, de a titkostás belekavarhat.

Én azt tenném, hogy excelben megcsinálnék 1000-2000 előre gyártott kártyaszámot, de úgy, hogy pl az első 4-5 karakter számokat tartalmaz. Ez fontos, mert ez alapján növekvő sorrendbe lehet tenni az excelben, ami az ardu kereséséhez fontos. Ez a 6-7 karakter is véletlenszámból lenne generálva excelben, de ez alapján sorba lehet rendezni. Utána akár sok-sok számból és karakterekből álló kód. Így állna elő a kártyákban a számkód, azt sorrende lehet tenni. Utána egy deleted mező, mindenhol 1-el kezdetben.
Így pl egy rekord így nézne ki:

Id Véletlen Véletlen
számok
számok és szöveg Deleted 1 karakter
6 karakter pl 14
0001;123456A78DFG8877h467;1

Ez 27 karakter hosszú. Mikor felveszel egyet, akkor a deleted 0-ra. A keresést a seek-el megoldható, sokkal gyorsabb, mintha egyesével végigmennél rajta. A fájlt, mivel akár 2000 elemet is tartalmaz, igen ritkán kell írni. Gondolom olyan gyorsan nem változnak a belépők.... Excelben is módosíthatod.

Szóval rendezett lenne, mert a kártyakód 6 karakterként tárolt száma alapján növekvő sorrendbe lenne téve. Beszúrni nem kell, csak aktiválni. Az adott kártyát törölni meg a deleted 1-re, és kész. Azaz a kis kártyákat az excel megfelelő generált kódjával kell feltölteni. Bár kérdés mit enged meg.

Ehhez lehet Arduino kódokat írni, nem ír sokszor, ráadásul könnye írhatsz Ardu-ban olyan kis kódokat, amik felvesznek újat, vagy törölnek. Vagy épp megírja akártyát, egy szabadon felhasználható kártyaszámmal...

Így előre gyártva sokkal könnyebb lehet.

nekem nagyon jó volna a csv, de már ott elakadok, hogy ugrok pl a végére, ha mondjuk egy új rekordot akarok felvinni?

A csv az alapesetben sima szövegfájl, a problémája az, hogy a rekordok mérete nem kötött, ezért navigálni csak az elejéről történő keresett elemig történő végigolvasással lehetséges. Bár ha nem tervezel más programmal belenyúlni az adatbázisba (excel, szövegszerkesztő, stb.), akkor meg tudod csinálni, hogy minden rekord ugyanannyi karakter legyen. Így tudsz bináris keresést is csinálni benne rendezett adatbázis esetén. Törölhetsz is, ha raksz bele egy "deleted" mezőt. A végére ugrást a seek utasítással tudod megtenni, a konkrét paraméterezését az általad használt fájlkezelő könyvtár leírásában keresd meg, mert sajnos ez nincs teljesen egységesítve.

Ez jó ötletnek tűnik.
Most ezzel próbálkozom: Bővebben: Link

Hali én biztos hogy adatbázist nem kezelnék sdkártyán, már csak a sebesség miatt sem. Gyanús nekem, hogy rövid időn belül "szétírod" az sdkártyát, ami korlátozott számban írható, aaról nem is beszélve, ha sd hiba van, halott az egész. Akkora kontroller választanék, ami ramjába elfér az egész hóbelevanc. Az tud gyors lenni keresésben, módosításban,törlésben, aztán időnként lehet szinkronizálni, kiírni esetleg dátum szerint a kártyára, ellenőrizni a mentést, kártyahiba esetén hibátjelezni.

Még most egyenlőre csak infot gyüjtök, hogy merre induljak ki, sd kártya azért lenne optimális, mert le tudom menteni az adatokat könnyen + ez van itthon.
Az eeprom se komálja a sok újraírást, sőt, úgy tudom a sd kártya flash memóriás, ezért jobban. Egyébként se lesz sűrű írás, inkább olvasás.

Arról nem volt szó, hogy elérhető-e wifi? Mert ha igen, akkor semmiféle korlát nem marad, szabadon lehet garázdálkodni!

Nem tudom pontosan mi a cél/kimenet, én gyüjtöttem adatot (esp8266)... Wifi weboldalba javascript, ami felkapja a kontrollerből a tömböt, és feldolgozza, (gyönyörű grafikont rajzol). Az előnye hogy a macerás, erőforrásigényes végső feldolgozás, megjelenítés a böngészőben történik, nem a mikrogépen, ráadásul oprendszer/program független, a böngészőből menteni is lehet bármi háttértárolóra...

Ezt net nélkülire kell megcsinálni

Akkor soory, megyünk a másik úton

Mondjuk a 24LC64 eeprom 1000000 írási ciklust ígér magáról... Nálunk a gyári megoldás is valami ilyesmi jószágot tartalmaz, lassan 20 éve, hogy fent van a falon és még nem döglött bele, a kódokat ugyan úgy kezeli, az eeprom tartalmat ugyan úgy olvassa.

Ne misztifikáld túl a dolgot, egy ilyen kártyaolvasós megoldás nem agysebészet A gyári megoldás mindössze annyit tud, hogy van egy kódtáblázata az érvényes kódokról, amikkel nyitni, meg amikkel riasztani lehet és kész. Ezen kívül elvileg tudná tárolni, hogy melyik kód mikor lett beütve, de ezt még az életben nem olvasták ki nálunk...

A kártyaolvasódnak nem vagyok benne biztos, hogy tudnia kell, melyik kártya kihez tartozik, azt érdemes ott kezelni, ahol könnyű (számítógépen egy excel táblában elfér), a kártyaolvasós megoldásba elég csak az érvényes kódokat beletenni.

Üdv mesterek!
Találtam a neten egy akku töltő kapcsolást ami Arduino nano-val működik és PC-vel kell az egészet irányítani.
Itt található az oldal:
http://lygte-info.dk/project/Charger%20UK.html
A következő gondom lenne a lenti progival állandó hibaüzenetet dob az IDE program a könyvtárak hozzá vannak adva.
Ha valaki találkozott már ilyennel kérem ossza meg mi lehet a hiba.
Köszönöm!

Nekem csak ennyi "hibát" dobot forditás közben:


De leforditotta:
A vázlat 25024 bájt (81%)-ot használ a program tárhelyből. A maximum 30720 bájt.
A globális változók 1503 bájt (73%)-ot használnak a dinamikus memóriából, 545 bájtot hagyva a helyi változóknak. A maximum 2048 bájt.