Ha a saját tápját fogja méregetni, akkor tényleg nem kell. Csak a belső vref használatához a táptfeszt le kell osztani mondjuk a felére, az 2x15 ellenállat.
Szóval akkor kell 14 uC, 2x14 opto, ellenállat és a kalibrlás, meg ugye a sallangok.

Ez szinte már túl egyszerű az opamp-os megoldáshoz képest, ami ugye 4 jobb quad opa + 45 ellenállat + kalibrálás...

Lehet, hogy elsiklottál felette, de kell neki balansz áramkör is. Az plusz mégegyszer ugyanennyi (hiszterézissel még több). uC-rel pedig csak a fet, soros ellenállás és teljesítmény ellenállás kell. Kalibrálni uC-nél nem is annyira lényeges, elég megmérni a belső Vref-et, de abban sem szokott túl nagy szórás lenni.

Csak nem tudtam működésre bírni a font konvertert, úgy döntöttem, manuálisan adom hozzá az ékezetes karaktereket, ebben kérnék egy kis segítséget.
Szóval van ez a fájl:

Ebben vannak a karakterek bitmapjai és az ASCII hozzárendelési táblázat. Az a baj, hogy 127-160-ig nincs benne a megjelenítendő karakter és a hozzárendelési tábla is a szóköz karakterre(32) irányít.
Arra gondoltam, hogy egyesével veszem a karaktereket, átrajzolom, beillesztem a megfelelő helyre és átírom a jump table megfelelő részét.
Pl. veszem az a betűt, ami a 97-es, átrajzolom- Itt az első probléma, hogy mivel? Van a kockás papír módszernél jobb alternatíva?- ,ebből lesz a 160-as á, berakom a font data rész megfelelő helyére és átírom a jump table hozzátartozó részét. Itt jön a következő kérdés, hogy mi alapján vannak ezek összepárosítva?
Itt ír valami ezzel kapcsolatosat a lib készítője, de nem igazán értem, hogy mi a problémája vele, és miért hagyta ki ezeket a karaktereket.

Üdvözletem, újabb kérdés az arduinos BMS -emmel kapcsolatban.
Szóval ha jól tudom, az attiny85 belső referenciája 1.1V, és mintha úgy rémlene, ennél a feszültségnél nem lehet nagyobb a mérendő feszültség az analóg bemeneten. Szóval az IC1 kapcsolási elrendezése, miszerint a tápfesz direkt bevezetése az analóg mérőlábra nem jó megoldás, igazam van?
Akkor jól gondolom, hogy a megoldás az összes IC-n a feszültségosztó használata mint az IC2 -őn? Egyébként mivel a tápfesz 4.2-2.8V közt változik, az ugye nem befolyásolja a mérés pontosságát?

Másik mérési módszer, ami megoldja ezt a saját tápfesz mérését ellenállásosztók nélkül azt itt olvastam.: uP saját tápfeszültség mérése...

Mivel a readVcc() függvény (amit igazából egyáltalán nem értek mert direkt portmanipuláció) minden más előtt van, eszerint ez csak a bekapcsoláskor méri a tápfeszt, programfutás közben nem? Mondjuk ha ezt a kódot beteszem a void loop() fügvénybe, akkor ott is működne a dolog, tehát folyamatos mérési eredményt kapnék?

Köszönöm, hibátlanul működik!

A saját tápfesz mérése egy saccográf. Csak egy trükk, amikor meg tudnak olyan dolgot oldani, amire nagyon kevés ember gondol, de nem 10biten kapod a feszültséget, hanem jó, ha 8-on.
Kell két ellenállás, lehetőleg 0.1%-os, plusz meg kell mérned a Vref lábon az 1.1V-ot olyan pontosan, amennyire tudod, ezt a kódodban felhasználva a mért eredményem olyan pontos lesz, mint amennyire pontosan lemérted a Vref-et, plusz a két ellenállás hibája, ami elenyésző.

Élvezettel olvasom soraitok, mert sokat lehet tanulni belőle. De kérdezném, nincs egy kicsit túllihegve ez a téma? 10 mV-okról beszéltek, miközben a multi, amivel majd beállítod, simán tévedhet 100 mV-ot is akár.

Kössz az érdeklődést, de én nem beszélek itt mV -okról,
az én kérdésem tulajdonképpen csak a kapcsolástechnikára vonatkozott...

Azt nem vágom, ha 10 bites az ADC akkor miért csak 8 bites eredményem lesz? Egyébként jut eszembe, ha jól tudom, 2.56V -os belső referenciája is van az attiny85 -nek, azzal pontosabb eredményt kapok jól sejtem? Mivel tágabb a mérési tartomány, (át kell méreteznem a feszosztót)...

Ne haragudj, de 100mV-ot hibázó multi 20V-os állásban, az kukába való. Nekem van kb. 5 multim, azok 0.01V pontosságra ugyanazt mérik 20V-os állásban.
Ez a tápfeszültség mérése külső alkatrészek nélkül, nem korrekt megoldás.
Először 2.56 voltos referencia feszültséggel megméri a belső hőmérő szenzor feszültségét (50-150 érték az 1024-ből), majd 5V-ra állítva a ref-t, megismétli a mérést (fele ADC értéket kap kb). Ebből a maximálisan 200 értékből kiszámolja az 5V-2.56V különbségét (a 2.56V nem pontos!), majd ezt hozzáadja a 2.56V-hoz (ismét pontatlanság). Ez fából vaskarika. A korábban saccolt 8bit elérhetetlen. Olyan, mintha megmérnéd egy focilabda kerületét (kb-re ismert hány centi) 1m hosszú cérnával, aztán egy nagyon hosszúval, és a kettő különbsége alapján saccolnád az ismeretlen hosszú cérnát... Valami hasonló az elv.

20 V-nál 100 mV az 0,5%-os pontosságot jelent. Nézd meg a multik adatlapját mennyi %-ot adnak meg. Egyébként az, hogy 5 multi hajszálra pontosan ugyanazt mutatja, nem mond semmit. Honnan tudod, hogy pontosak? Az egyik etalon?

Nincs etalon, teljesen különböző típusú, márkájú eszközök, mind gyárilag "kalibrálva". Ha mind ugyanazt mutatja, akkor talán pontosak. Egyébként nem érdekel a pontosságuk, mutassa ugyanazt a multi, mint az LCD kijelző, nekem ennyi elég, elhiszem nekik a mutatott értéket. Ha további problémád van a multimétered pontosságával, menj át a megfelelő topicba (azt hiszem pont ugyanez a címe is).

Kösz, nincs velük problémám, jártak a kalibráló laborba. Munkahelyi ártalom

Nagyon jó ez a link a tavir.hu-ról, ennek hasznát veszem hamarosan szerintem. Köszi hogy megosztottad.

Elnézést, nem követem usec pontosan a dolgot, de miért is nem jó az egész cucchoz valami BMS IC? Texas-nál benéztem, I2C-s 15-ös BMS minden földi jóval 14-bites ADC-vel stb. $4-5 kiskerben legyen $10/1db. Igaz, legalább 70-100 oldal pdf és csak a regiszterek felsorolása 5 oldal...de mindent tud. Olcsóbb, mint ha mindenhova betennénk egy INAxxx nagyfesz differenciálerősítőt (o.k., van ami tud 100V-ot is és tényleg jók, csak hát a darabszám). A kvázi-szinteltolású méréshez lehet csinálni kapcsolt kapacitású áramkört nagyfesz analóg multiplexerekkel, de azok iszonyat drágák. Szóval ha ilyen sok helyen kell mérni és erre van kész IC, ami gyors/nagyobb felbontású/tele van HW védelemmel, akkor itt 10-100mV-okon agyalunk meg soros kommunikáción?

Egészségedre. Bár én még nemigazán vágom, hogy is működik az a tápfeszmérés...

Eddig kb háromszor olvastam, hogy van erre cél IC, de még egy típusszámot nem láttam.
Egyébként sehová nem akarok betenni semmilyen differenciálerősítőt, én eddig még az eredeti tervemnél tartok, miszerint egy cella / egy uP és két opto. Ebből a felállásból lesz 15...

Sziasztok!
A FastLED.h-t használom neopixel beállításához.
Aminációk leírását szeretném tárolni.

Erre ki is találtam egy jó struktúrát, de dinamikus értékekkel nem tudom megcsinálni.

Ez lenne egy szín leírója:
typedef struct {
uint8_t stepID;
uint16_t wait; //Mennyi millisecundum várakozás a következő lépésig
CRGB color;
uint16_t leds; //Melyik ledekre kell alkalmazni az adott színt (bitenként)
uint8_t ledB; //A hátsó két kék led fényereje 0-255
} eyeAnimStep;

Egy animáció ebből tetszőleges ilyen struktúrát kellene hogy tároljon, de csak akkor működik, ha fixen lefoglalom, hogy 20 lépésből állhat egy ilyen animáció leírás:
typedef struct {
eyeAnimStep Steps[20];
} eyeAnim;

Ráadásul több animáció leírást kéne tárolni.

eyeAnim leiras = {
{
{0, 2000, 0x8A2BE2, 0b1010001000110011, 0},
{1, 2000, 0x8A2BE3, 0b1011111000110011, 0}
}
};

Ez így működik, de :
- eyeAnimStep Steps[20]; helyett nem írhatok eyeAnimStep Steps[];-t, hogy csak 2 fázisból áll egy animáció akkor csak 18 további felesleges tárolás ne legyen.
- eyeAnim leiras = { helyett nem írhatok eyeAnim leiras[] = { -t, hogy több különálló animáció leírását tudjam tárolni.

Mi a megoldás, mert szeretném minél kevesebb memóriával megoldani.

Előre is köszi.
Zoli

Így már egy fokkal jobb, de még mindidg nem tudom hogy tudnám megcsinálni, hogy ne kelljen a 20-as tömböt lefoglalni, mert nem minden effekt fog 20 lépésből állni:

Szerintem túl bonyolítottad.
Egyetlen tömböt minek struktúrába rakni?


Ebböl csinálhatsz bármenyit.

Egy ötlet:

Még kel 1 tömbb a méretek adatait tárolni:

Igy tudnád indexelni a tömbböt:

> Texas-nál benéztem, I2C-s 15-ös BMS minden földi jóval 14-bites ADC-vel
Segítenél egy típusszámmal? Én max 6 csatornásat láttam náluk Li-ion-hoz.

gyors gugli keresés után innen a BQ76940 az egyetlen..

Bocsánat a késésért:
TI_battery
Csak belelapoztam 1-2 pdf-be, szóval nem vagyok császár a témában, de lehet válogatni, no meg applikációknál okos dolgok is vannak.

Jónak tűnik, apró hiba, hogy csak három cella hőmérsékletét képes mérni.
Valamint nemnagyon találni hozzá semmilyen projektet, ahonnan el lehetne lesni a kommunikációt.
Persze tudom az adatlapban benne van, de működés közben jobban érteném...

Én is úgy voltam vele sokáig, hogy ha nincs lib vagy mintakód, akkor nem foglalkozom vele. Aztán egyszer muszály volt adatlabpól drivert írni. Nem is olyan nagy dolog. Azóta nem izgulok. Ami fontos: Egyáltalán nem szükséges minden funkciót és minden lehetőséget implementálnod. Tehát ha mondjuk szoftveresen kapcsolható, hogy hány cellával működjön, akkor nem kell írnod egy általános, cellaszám beállító függvényt, hanem egyszerűen az elején, a setupban elküldöd neki, hogy 15, és kész is vagy.

Köszi.
Sajna este fáradtan nagyon leegyszerűsítettem a példát.

Nem csak egy struktúra van benne.
A működése, hogy
ex[] tömbben lennének az egyes animációk.
Azon belül vannak az animáció lépései.
Tehát egy lépésben mit kell megcsinálni, és a következő lépés mennyi idő múlva következik.
És ezen belül van maga a 16 Neopixel led beállítása. Tehát van egy szín, és meg van adva, hogy az mely pixelekre alkalmazandó, aztán a második szín és az mely ledekre, stb.

Tehát a teljes struktúra kb így nézne ki (most nem ellenőriztem le a fordítóval).


Csak ebben az esetben akkor is 16-os tömb van fölöslegesen lefoglalva, ha az adott lépésben csak azt csinálom, hogy mind a 16 ledet egy színre állítom. Holott ekkor éppen elég lenne egy egydimenziós tömb. (azért 16, mert ha minden led más színű, akkor max 16 szín lehet)

Illetve fixen 20 lépés tárolható, és annak van lefoglalva a meódia, ha az adott animáció csak 2 lépésből áll. (azért 20, hogy akár egy 20 lépésből álló animáció is elférjen)

Tehát nekem az lenne a jó, ha a sc_u[16] és a in_u[20] tömb dinamikus lehetne.

Segítségeteket előre is köszönöm.

Zoli

Néztem amit írtál, hogy mutatókkal összerakni egy struktúrává a dolgot.
De ha belül is van egy kisebb struktúra, akkor gondolom tudnám használni a módszert szintén (főleg ha kihagyom nextAnim-ot és a nextAnimWait amit közben rájöttem kéne még), de a végén nem a kód lesz túl nagy ami leírja mondjuk a 20 különböző animációt?




Segítségeteket előre is köszönöm.

Zoli