- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Az NVIDIA ipari AI-felhőt épít a németeknek, együtt az OpenAI és a Google
- Két új Ryzen közül választhatnak a kézikonzolok
-
PROHARDVER!
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
#16900
razorbenke92
őstag
Undoroid
#16899
válasz
Undoroid
#16899
üzenetére
Az irány jó amerre indultál. Vagy csinálj egy void color2(...) eljárást, vagy a color(...)-t változtasd meg úgy, hogy a két(x3) kimenetekre más értéket tehess.
Gyomláld ki a hibákat amiket kapsz - ezek valószínűleg azért keletkeznek mert:
- nem tehetsz a kódba kétszer ugyanazon névvel void-ot, a másik legyen color2
- ha az argumentumokon változtatsz, akkor mindenütt, ahol meghívod a void-ot, ott bővítened kell az argumentumok számát, hogy megfeleljen a deklaráltnak.void color (unsigned char red, unsigned char green, unsigned char blue)// the color generating function
{
analogWrite(redPin, 255-red); // PWM signal output
analogWrite(greenPin, 255-green); // PWM signal output
analogWrite(bluePin, 255-blue); // PWM signal output
}
void color2 (unsigned char red, unsigned char green, unsigned char blue)// the color generating function
{
analogWrite(red2Pin, 255-red); // PWM signal output
analogWrite(green2Pin, 255-green); // PWM signal output
analogWrite(blue2Pin, 255-blue); // PWM signal output
} -
Undoroid
őstag
válasz
Undoroid
#16856
üzenetére
Sziasztok!
Nos, elakadtam és ismét kérdeznék.
A példafeladatot módosítva idáig jutottam el:
/***********************************************************File name: 09_rgbLed.inoDescription:Control the RGB LED emitting red, green, blue, yellow,white and purple light, then the RGB LED will be off,each state continues 1s, after repeating the aboveprocedure.Website: www.adeept.comE-mail: support@adeept.comAuthor: TomDate: 2015/05/02*************************************************************/int redPin = 11; // R petal on RGB LED module connected to digital pin 11int greenPin = 10; // G petal on RGB LED module connected to digital pin 9int bluePin = 9; // B petal on RGB LED module connected to digital pin 10int red2Pin = 6; // R petal on RGB LED module connected to digital pin 6int green2Pin = 5; // G petal on RGB LED module connected to digital pin 5int blue2Pin = 3; // B petal on RGB LED module connected to digital pin 3void setup(){pinMode(redPin, OUTPUT); // sets the redPin to be an outputpinMode(greenPin, OUTPUT); // sets the greenPin to be an outputpinMode(bluePin, OUTPUT); // sets the bluePin to be an outputpinMode(red2Pin, OUTPUT); // sets the redPin to be an outputpinMode(green2Pin, OUTPUT); // sets the greenPin to be an outputpinMode(blue2Pin, OUTPUT); // sets the bluePin to be an output}void loop() // run over and over again{// Basic colors:color(255, 0, 0); // turn the RGB LED reddelay(1000); // delay for 1 secondcolor(0,255, 0); // turn the RGB LED greendelay(1000); // delay for 1 secondcolor(0, 0, 255); // turn the RGB LED bluedelay(1000); // delay for 1 second// Example blended colors:color(255,255,0); // turn the RGB LED yellowdelay(1000); // delay for 1 secondcolor(255,255,255); // turn the RGB LED whitedelay(1000); // delay for 1 secondcolor(128,0,255); // turn the RGB LED purpledelay(1000); // delay for 1 secondcolor(0,0,0); // turn the RGB LED offdelay(1000); // delay for 1 second}void color (unsigned char red, unsigned char green, unsigned char blue)// the color generating function{analogWrite(redPin, 255-red); // PWM signal outputanalogWrite(greenPin, 255-green); // PWM signal outputanalogWrite(bluePin, 255-blue); // PWM signal outputanalogWrite(red2Pin, 255-red); // PWM signal outputanalogWrite(green2Pin, 255-green); // PWM signal outputanalogWrite(blue2Pin, 255-blue); // PWM signal output}Annyit tettem, hogy lemásoltam / megdupláztam a megfelelő parancssorokat és más neveket is adtam nekik. Ekkor a 9-10-11-es kimenet és a 3-5-6-os kimenet pontosan ugyanazokat a jeleket produkálták. Amikor ezt a sort (
void color (unsigned char red, unsigned char green, unsigned char blue)// the color generating function{) kezdtem el ugyanúgy lemásolni / módosítani, akkor viszont megannyi hibaüzenet fogadott feltöltés közben. Megpróbáltam kiegészíteni ilyenre is:void color (unsigned char red, unsigned char green, unsigned char blue, unsigned char red2, unsigned char green2, unsigned char blue2)// the color generating function
Erre szintén újabb hibaüzenettel gazdagodtam...
A feladatom az lenne, hogy a 3-5-6-os kimeneten és a 9-10-11-es kimeneten egyidőben, de különböző jeleket (sima RGB-LED-es színkeveréseket és villogásokat) szeretnék futtatni. A nagy kérdés pedig az, hogy hogyan?
A színek létrehozása, keverése, átúsztatása (a color - delay párossal) "megy" , de nem a legszebb- és a legjobb tárhelyhasználattal, de működik!
A fő problémám az, hogy nem tudom külön-külön kezelni a két kimenetet. Nem tudok olyan parancssort létrehozni, ami ezt megoldaná.Remélem, hogy tudtok segíteni?!
-
Tomika86
senior tag
Sziasztok
Pár kérdésem lenne:
1. Fordítaskor kiírja az arduino ide hogy az egyik library nem kompatibilis esp32 platforma, működik, de esetleg okozhat gondot?
2. Nagyon lassan fordít le, ha másodszor is fordítom már sokkal gyorsabb
3. Reset és gpio0 10kohm-al felhúzva 3,3vra. Ha a kapcsolóhoz kondenzátort teszek akkor boot módba lép tápfeszültség megjelenésekor, 100nF és 1uFal is próbáltam, kisebb kell? 1nF?
Usbs újraindítás nincs, csak a kettő gomb.Köszönöm
-
And
veterán
Egy aktív kapcsolat nélküli AP kizárólag beacon frame-eket sugároz, abban pedig legjobb tudomásom szerint nincs abszolút / RTC-időkód. Csak egy mikroszekundum alapú, a bekapcsolástól számított időzítőt (timestamp) tartalmaz, ami az egyes állomások közötti szinkronizálást segíti.
-
-
JozsBiker
aktív tag
válasz
Janos250
#16889
üzenetére
Köszi szépen mindkettőtöknek, ez működik is szépen. A fenti kód azért tetszett volna ha működött volna, mert nem szükséges hozzá SSID, így kitágította volna a lehetőségeket :-). Én ennyire nem vagyok mélyén a programozásnak ezért megkérdezem: ki lehet valahogy javítani az általam hivatkozott kódot hogy rendesen működjön ( ne reseteljen folyton ) ?
-
Janos250
őstag
válasz
JozsBiker
#16879
üzenetére
Az ESP32-nek van saját time.h-ja, az jól működik, ahogy weiss is írta.
Itt jobban kirészletezve:
https://lastminuteengineers.com/esp32-ntp-server-date-time-tutorial/Vagy maga a program:
#include <WiFi.h>
#include "time.h"
const char* ssid = "xxxxx";
const char* password = "xxxxxxxx";
const char* ntpServer = "pool.ntp.org";
const long gmtOffset_sec = 3600;
const int daylightOffset_sec = 3600;
void printLocalTime()
{
struct tm timeinfo;
if(!getLocalTime(&timeinfo)){
Serial.println("Failed to obtain time");
return;
}
Serial.println(&timeinfo, "%A, %B %d %Y %H:%M:%S");
}
void setup()
{
Serial.begin(115200);
//connect to WiFi
Serial.printf("Connecting to %s ", ssid);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println(" CONNECTED");
//init and get the time
configTime(gmtOffset_sec, daylightOffset_sec, ntpServer);
printLocalTime();
}
void loop()
{
delay(1000);
printLocalTime();
} -
#16888
Gergosz2
veterán
tonermagus
#16885
Gergosz2
veterán
válasz
tonermagus
#16885
üzenetére
Az okosabb soros port usb illesztők is tudják. Amúgy meg tényleg egy scope vagy logikai analizátor
-
#16887
gyapo11
őstag
tonermagus
#16885
gyapo11
őstag
válasz
tonermagus
#16885
üzenetére
Logikai állapot analizátorral. Csak rá kell bírni hogy adni akarjon.
-
#16886
Janos250
őstag
tonermagus
#16885
Janos250
őstag
válasz
tonermagus
#16885
üzenetére
Itt írnak róla, én még nem próbáltam.
Vagy Google arduino autobaudhttps://forum.arduino.cc/t/auto-serial-baudrate-detector-selector/38256
-
#16885
tonermagus
aktív tag
tonermagus
aktív tag
Sziasztok!
Van arra valami mód, hogy lecsekkoljam, hogy egy Arduinora dugott eszköz mekkora baud rate-re van állítva?
Hogy miért kell ez? Van egy Arduino-m illetve egy szenzorom ami UART-on kommunikál egymással. Sajnos rajtunk kívülálló okok miatt ezek a szenzorok nem egyformák és eltérő baud rate értéken kommunikálnak. Igazából kétfajta érték fordul elő: 9600 és 38400.
Mivel ezekkel a szenzorokkal kétirányú kommunikációt végzek (néha az AVR is küld neki adatot) és rossz baud rate-en szólítom meg akkor kifagy az egész.
Itt működhet aif(Serial.available() > 0) ??
Vagy ez a feltétel akkor is teljesül ha nem értelmezhető adatot kap az eltérő baud rate miatt? -
JozsBiker
aktív tag
Sziasztok !
Ennek szerintetek kellene működni ESP32 -n ?
/**************************************************************
* Local Time Stamp with ESP32
* Developed by Marcelo Rovai - 8 September 2017
**************************************************************/
#include <NTPClient.h>
#include <WiFi.h>
#include <WiFiUdp.h>
#define NTP_OFFSET -3 * 60 * 60 // In seconds
#define NTP_INTERVAL 60 * 1000 // In miliseconds
#define NTP_ADDRESS "0.europe.pool.ntp.org"
WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, NTP_ADDRESS, NTP_OFFSET, NTP_INTERVAL);
void setup()
{
Serial.begin(115200);
timeClient.begin();
}
void loop()
{
timeClient.update();
String formattedTime = timeClient.getFormattedTime();
Serial.println(formattedTime);
delay(1000);
} -
Janos250
őstag
-
And
veterán
válasz
ekkold
#16866
üzenetére
Használtuk régebben mindkét félét. Először persze nem voltunk tisztában vele, hogy egyáltalán többféle mechanikai osztással is létezik
. A megoldás az lett, hogy nem tettünk különbséget a kódban a rotary típusa szerint. Itt eleve többféle értelmezés is lehetséges, a korábban említett csupán két él figyelése szerintem például nem teljesen korrekt. A teljes és egyértelmű kapcsolási periódus mindenképp négy élből áll, csupán kettőt figyelembe véve félútról visszatekerhető az encoder, ami helyzettől és ízléstől függően furcsán hathat (mivel ekkor az általad 'dupla lépésesnek' nevezett kivitel anélkül ad egy-egy teljes oda-vissza jelzést, hogy akár egyszer is fix mechanikai állapotba lépett volna). A tapasztalat viszont az volt, hogy ha mind a 4 él meglétéhez kötöttünk egy lépést, akkor viszonylag gyakran hibázott, ezért kompromisszumként három éllel megelégedtünk. A hibázás (lépés kihagyása) ekkor elhanyagolható lett, és elmaradt a téves előre-hátra működés is. Persze hardverből is rásegítettünk, ahogy írtad, RC-szűrést (2,7k / 1nF) kialakítva. Gyári készülékeken sem mindig tökéletes a rotary, a mi megoldásunk sem lett annál rosszabb, egész nagy tekerési sebességig használható maradt. -
#16868
razorbenke92
őstag
ekkold
#16865
válasz
ekkold
#16865
üzenetére
Ebben az esetben beletennék a kódba egy flaget, és amíg az nincs igazra téve, addig a az enkóder süket.
Amíg a flag hamis, addig azt figyelném, hogy az 11 állapot fennáll e egy általad meghatározott ideig egy meghatározott időn belül.
Mivel az egyik enkóder stabil állapotban csak 00 lehet, ott ez biztos hogy nem fog előfordulni könnyen.
Indulás után vársz 2 másodpercet az egyik stabil állapotban, és utána elfordítod egyel, és ott is vársz 2 másodpercet. Ha egyikben sincs 11 állapot stabilan (a kettő között észre tudod venni hogy már megtörtént a mozgás) akkor tudod, hogy melyik tipus. -
ekkold
Topikgazda
válasz
Gergosz2
#16864
üzenetére
Elég régen vettem ezeket az enkódereket, sem típust sem adatlapot nem tudok prezentálni, de sima kommersz kétfázisú rotációs enkóderekről van szó. Aki már dolgozott ilyennel az ismeri. Nem nagy probléma MCU-val kezelni, viszont MCU-val hibamentesen kezelni már jóval nehezebb.
-
ekkold
Topikgazda
A legtöbb olcsó, kétfázisú rotációs enkóder egy "zajgenerátor", összevissza prellegnek tekerés közben. Nem az enkóder kezelése a nehéz szoftveresen, hanem a prellezés kiszűrése, hogy ne hibázzon tekeréskor, és irányváltáskor sem. Vagy hardveresen kell RC szűrőt hozzáépíteni. A két enkóder mondhatni csak a mechanikai poziciók számában különbözik.
-
#16865
ekkold
Topikgazda
razorbenke92
#16861
ekkold
Topikgazda
válasz
razorbenke92
#16861
üzenetére
Jól érted. Bár másképp programoztam le, de a lényege ugyanez. Tehát nem az a probléma, hogy nem kezeli jól a szoftver. Mindkét enkóder jól működik, csak az egyikhez ki kell kommenteznem egy részt a szoftverben, a másikhoz meg nem. A kérdés arra irányult, hogy ehetne-e univerzális megoldást készíteni, vagy valahogy automatikusan felismerni és aszerint kezelni az enkódert. Ha nem akkor marad az, hogy egy menüpontban állíthatóvá kell tenni...
-
Esetleg, ha van szkópod nézd meg, látható-e szabálytalanság a négyszög jelben a stabil pontoknál! Arra gondolok, hogy a mechanika behúzza a helyére a stabil állapotnál, kifelé pedig nehezebben engedi, tehát a kettő közt látszódnia kellene valami különbségnek, lassú tekerésnél legalábbis.
-
válasz
ekkold
#16860
üzenetére
Ja, hogy ez mechanikailag stabil állapot?
Én pont fordítva fognék hozzá: szimpla lépésesként kezelném, aztán pár beolvasás után megnézném, hogy a stabil állapotok többsége páros szám, vagyis ha legtöbbször 2 lépésenként stabilizálódik, akkor dupla lépéses. Kell egy treshold, mondjuk 75% fölött egyik, alatta a másik, és ezt addig tologatod, amíg megbízhatóan nem tud jósolni az algoritmus.
De ezt nehéz így látatlanban megoldani, kéne tudni, mire használod. Pontosan milyen feladat az, ahol nem tudod előre, hogy melyik kerül az áramkörbe? -
#16861
razorbenke92
őstag
ekkold
#16860
válasz
ekkold
#16860
üzenetére
Ahogy értem, ez mind a kettő inkrementális AB enkóder.
A feldolgozási logika mindkettőnél ugyanaz, csak a mechanikája az egyiknek egyszeres felbontásra van stabilizálva, a másiknak pedig kétszeresre.
Az elsőnek az a logikája hogy az A jelre "rising" interruptot teszel. Tehát amikor a jel 0->1 átmeneten halad át, akkor hajtasz végre feladatot.
A feladat az, hogy ellenőrzöd B-t. Ha B=1, akkor pozitív irányba történt fordítás, ha B=0 akkor negatívba.
A másodiknak annyival bővül a logikája, hogy az A jelre "falling" interruptot is teszel (a kettő együtt "changing" interrupt).
A logika pedig:
- Ha A=1 és B=1 -> előre fordult
- Ha A=1 és B=0 -> vissza fordult
- Ha A=0 és B=0 -> előre fordult
- Ha A=0 és B=1 -> vissza fordulttovább egyszerűsítve akár a fentit, akár a lentit:
Ha az interrupt eseményben A és B értéke egyezik -> előre fordult, ellenkező esetben hátra.(négyszeres felbontás esetén pedig a B váltásait is lehet figyelni, és eljárni A értéke szerint)
-
ekkold
Topikgazda
Kétféle enkóder kapható.
Az állapotok jobbra forgatva
dupla lépéses enkóder esetén pl.
00 ; 01 11 10 00 ; 01 11 10 00 ; 01 11 10 00 ;
pontosvesszővel jelöltem az enkóder stabil állapotait.
szimpla lépéses enkóder esetén ugyanez:
00 ; 01 11 ; 10 00 ; 01 11 ; 10 00 ; 01 11 ; 10 00 ;Tehát az egyik típusnak van 11 és 00 stabil állapota is, míg a dupla lépéses kettőt lép egyszerre a másikhoz képest, azaz stabil állapotban mindkét érintkező nyitott.
A szoftverben ha nem megfelelően van kezelve akkor vagy kettesével lép, vagy minden második lépést kihagyja...
Történetesen kétféle enkódert találtam itthon és a kettő ebből a szempontból is kétféle... A különbségre úgy is tekinthetünk, hogy ugyanaz az enkóder fele annyi helyen áll meg stabilan, vagy dupla annyi helyen a másikhoz képest.
-
ekkold
Topikgazda
Enkóder kezeléssel kísérletezek. Van-e arra valamilyen egyszerű algoritmus, amivel a dupla lépéses és a szimpla lépéses enkódert felismerheti ill. megkülönböztetheti a program?
Egyelőre azzal próbálkoztam, hogy dupla lépésesként kezeli a szoftver, de ha olyan állapotban áll hosszabb ideig az enkóder, ahol a dupla lépéses nem állhatna, akkor átvált szimpla lépésesre. Ez működik is, de tudom szándékosan úgy tekerni a dupla lépéses enkódert, hogy a program szimpla lépésesnek vegye.
Tehát, létezik erre valami ügyesebb megoldás? -
Undoroid
őstag
Szia!
Sajnos nincs meg, de nem gond! (Csak az upgrade-kat találtam meg ott, illetve a már Gergosz2-által említett AVRdude is ott szerepelt)
A programot majd ismét
megíromelkövetem már az újabb verzióban!
Első körben -az elgondolásom szerint- fogok próbálkozni a másik három PWM-es kimenet aktiválásával és egyidejű használatával. Ha elakadok, akkor jelentkezek és kérdezek!
-
Undoroid
őstag
Szia!
Jó szokásomhoz híven el voltam veszve, ahogyan most is...
1.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Az igen az rendben is lenne, de a hogyan lenne az érdekes!
2. Ettől féltem...Visszatérve a példára: nagyon amatőr kérdés, de a már felprogramozott (és nem elmentett) programot hogyan tudom letölteni a mikrovezérlőből?
Ez a lépés sajnos kimaradt legutóbb... -
-
Tankblock
aktív tag
Hello,
lastbrightState is állítsd be a setupba,State Machine -nak (Állapotgép) nézz utána, a jövőben hasznos lesz.....
Adott az alábbi kód, melynek lényege az lenne, hogyha a D0 pin-en nincs jel, akkor folyamatosan "25-ös" erősségen világít a led, ha pedig van jel, akkor fel kell erősödnie a fényerőnek "150-re",
Ennek a követelményednek a kódod pont ellentétét csinálja a setupban.
Sőt pont az ellentétjét mint a loopban....vagy a jelszintek nem ott vannak ahol gondolom.
if (digitalRead(inPin) == HIGH) {FastLED.setBrightness(25); // Jel esetén 150FastLED.show(); }else {FastLED.setBrightness(150); // nincs jel esetén 25FastLED.show(); }}//ehelyett#define HIGHLEDSTATE 150#define LOWLEDSTATE 25lastbrightState = digitalRead(inPin);if (lastbrightState == HIGH) {FastLED.setBrightness(HIGHLEDSTATE ); // Jel esetén 150}else {FastLED.setBrightness(LOWLEDSTATE ); // nincs jel esetén 25}FastLED.show(); -
Sanki
addikt
Upsz, akkor ezen példa alapján kiegészítettem: State Change Detection (Edge Detection) for pushbuttons
Most menet közben jó, még a starton kell csiszolni, ha "HIGH" D0-val kapcsol be, akkor ugyanolyan fadedown-nal megy le a 25-ös értékre.
Ha LOW, akkor viszont fix 150-en kapcsol be.#include "FastLED.h"#define NUM_LEDB1 3#define NUM_LEDB2 3#define LED_TYPE WS2812#define COLOR_ORDER GBRCRGB leds1[NUM_LEDB1];CRGB leds2[NUM_LEDB2];#define LEDB1 D2#define LEDB2 D8#define inPin D0#define BRIGHTNESS25 25#define BRIGHTNESS150 150int brightState = 0;int lastbrightState = 0;void setup() {pinMode(inPin, INPUT_PULLUP);pinMode(LEDB1, OUTPUT);pinMode(LEDB2, OUTPUT);FastLED.addLeds<LED_TYPE, LEDB1, COLOR_ORDER>(leds1, NUM_LEDB1).setCorrection(TypicalLEDStrip);FastLED.addLeds<LED_TYPE, LEDB2, COLOR_ORDER>(leds2, NUM_LEDB2).setCorrection(TypicalLEDStrip);FastLED.clear();for (int i = 0; i < NUM_LEDB1; i++ ) {leds1[i] = CRGB::White; }for (int i = 0; i < NUM_LEDB2; i++ ) {leds2[i] = CRGB::White; }if (digitalRead(inPin) == HIGH) {FastLED.setBrightness(25);FastLED.show(); }else {FastLED.setBrightness(150);FastLED.show(); }}void loop() {brightState = digitalRead(inPin);if (brightState != lastbrightState) {if (brightState == HIGH) {fadedown25();}else {fadeup150();}}lastbrightState = brightState;}// ------------------------------------void fadeup150() {for (int j = BRIGHTNESS25; j < BRIGHTNESS150; j ++) {FastLED.setBrightness(j);FastLED.show();delay(10);}}// ------------------------------------void fadedown25() {for (int j = BRIGHTNESS150; j >= BRIGHTNESS25; j --) {FastLED.setBrightness(j);FastLED.show();delay(10);}} -
Sanki
addikt
Sziasztok.
Adott az alábbi kód, melynek lényege az lenne, hogyha a D0 pin-en nincs jel, akkor folyamatosan "25-ös" erősségen világít a led, ha pedig van jel, akkor fel kell erősödnie a fényerőnek "150-re", ha ez a jel megszűnik, akkor pedig visszahalványul "25-re". (Program indulásakor nem fix melyik eset van, hogy van e jel vagy nincs.)Na addig eljutottam, hogy a jel jelenlétének/hiányának az állapotára nő/csökken a fényerő, viszont ez folyamatosan történik és nem áll meg a végén, visszaugrik a kezdeti állapotra (és vagy 150-ről csökken 25-re folyamatosan ciklusban, vagy fordítva, növekszik a fényerő 25-ről 150-re folyamatosan).
Szerintetek mi lehet a probléma?
#include "FastLED.h"#define NUM_LEDB1 3#define NUM_LEDB2 3#define LED_TYPE WS2812#define COLOR_ORDER GBRCRGB leds1[NUM_LEDB1];CRGB leds2[NUM_LEDB2];#define LEDB1 D2#define LEDB2 D8#define inPin D0#define BRIGHTNESS25 25#define BRIGHTNESS150 150void setup() {pinMode(inPin, INPUT_PULLUP);pinMode(LEDB1, OUTPUT);pinMode(LEDB2, OUTPUT);FastLED.addLeds<LED_TYPE, LEDB1, COLOR_ORDER>(leds1, NUM_LEDB1).setCorrection(TypicalLEDStrip);FastLED.addLeds<LED_TYPE, LEDB2, COLOR_ORDER>(leds2, NUM_LEDB2).setCorrection(TypicalLEDStrip);// FastLED.setBrightness(25);for (int i = 0; i < NUM_LEDB1; i++ ) {leds1[i] = CRGB::White;}for (int i = 0; i < NUM_LEDB2; i++ ) {leds2[i] = CRGB::White;}// FastLED.clear();// FastLED.show();}void loop() {if (digitalRead(inPin) == LOW) {fadedown25();}if (digitalRead(inPin) == HIGH) {fadeup150();}}// ------------------------------------void fadeup150(){for (int j = BRIGHTNESS25; j < BRIGHTNESS150; j ++) {FastLED.setBrightness(j);FastLED.show();delay(10);}}// ------------------------------------void fadedown25(){for (int j = BRIGHTNESS150; j >= BRIGHTNESS25; j --) {FastLED.setBrightness(j);FastLED.show();delay(10);}} -
#16845
razorbenke92
őstag
Sebiferi
#16844
-
Sebiferi
tag
válasz
razorbenke92
#16843
üzenetére
Köszönöm szépen a leírást!
Erre én is gondoltam de azt hittem (és olvastam is talán), hogy ilyen esetben nagy áram esetén olyan nagy feszültség generálódik, hogy a szekunder oldal át is üthet. Ha nem így van, akkor az nagyon jó hír.
Esetleg tudnál valami linket adni ahol erről írnak? Jó lenne kiokosodnom a témában. -
#16843
razorbenke92
őstag
Sebiferi
#16835
válasz
Sebiferi
#16835
üzenetére
Az áramváltós és a hall-effektes mérők tudtommal nem tudnak ilyen kis áramokat mérni.
Ez igaz, de sokkal könnyebben meg tudod emelni a rajtuk keresztül folyó áramot, mint hinnéd.
Mondok egy példát:
Veszel egy 5A-es lakatot ami 5mA-re vált. Teszel rá egy terhelőt, ami az 5mA-ből 5V-ot csinál (1kOhm).
Ezt az 5V-ot 1024 felé tudod bontani, azaz az 5A-t is. Az már 4,8mA felbontás.
Ha viszont a vezetékedet 4x viszed át a hurokban (ügyelve az azonos áramirányra) akkor 4x olyan érzékeny lesz, azaz 1,2mA felbontást kapsz.
Ezekben az áramváltókban a vasmag szaturációja a névleges értékre van belőve, afölött nem - vagy nem sokkal nagyobb - feszültség/áram nyerhető belőlük, így amikor a valós 10 amperes fogyasztás megérkezik, nem fog túlfeszültséget okozni a mérő oldalon. (Illetve amit okoz, azt simán elviszed egy ellenirányú 5V-os zenerrel).
A közös nullpont azt hiszem nem lesz gond, ennek (is) utánajártam. Pl. a sonoff cuccok is ilyenek és jól működnek.
A Sonoff cuccokban az ESP-k nem az AC vonallal közösítenek nullát, hanem a dedikált energiamonitorozó chippel (HLW8012). A schematicon ne keverd össze az Earth és a GND pontokat, mert azok nincsenek közösítve. -
válasz
Sebiferi
#16839
üzenetére
Hát igen, ez jó kérdés
Hobby elektronika topikban lehet fejből mondanak valamit. -
Sebiferi
tag
-
Sebiferi
tag
válasz
Gergosz2
#16836
üzenetére
Köszönöm a választ!
1, kompenzált hall elemes áramérő. Ilyennel tudsz mérni DCt is ha esetleg megkívája, szőt még leválaszt is. Pl LEM.
Csak AC 230V mérés kell. Ez a kompenzált hall elemes cucc nekem új, vagy csak más néven találkoztam vele.
Az adatlap szerint az INA181 max. 26V-ig jó. Már ha jól értelmezem.
-
Gergosz2
veterán
válasz
Sebiferi
#16834
üzenetére
Amit csinálhatsz:
1, kompenzált hall elemes áramérő. Ilyennel tudsz mérni DCt is ha esetleg megkívája, szőt még leválaszt is. Pl LEM.
2, sönterősítő kapcsolás . Most hasraütésszerűen amit már használtam : https://www.ti.com/lit/ds/symlink/ina181.pdf?ts=1642093565364&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FINA18120-21 oldal. Kell egy sönt ellenállás, ez az erősítő + egy feszültség referencia. Ha az arduinod ADC refje is 5 V, akkor pl egy 2.5V os referencia is tökéletes, de bármi egyéb is jó lehet az erősítések függvényében.
-
Sebiferi
tag
válasz
razorbenke92
#16832
üzenetére
Az indukción alapuló mérés semmiképp nem megfelelő?
Az áramváltós és a hall-effektes mérők tudtommal nem tudnak ilyen kis áramokat mérni. A max áram 10-12A lehet az alkalmazásban.DIY esetben a galvanikus leválasztás nem csak az érintésvédelem miatt fontos, hanem mert ha valami zárlatba megy, akkor a hálózati feszültségből elég energia nyerhető a tűzeset kiváltásához. Söntös árammérésnél pedig sorosan kell kapcsolódnod a hálózati feszültségre, ami az egyébként jól működő védelmek egy részét kizárja. Már maga a közös nullapont kialakítása egy DC mikrokontroller és egy hozzá képest lebegő AC között megfelelő elektronikai ismereteket igényel.
Természetesen biztosíték be lesz építve. A közös nullpont azt hiszem nem lesz gond, ennek (is) utánajártam. Pl. a sonoff cuccok is ilyenek és jól működnek.Ha egy Arduinoval mész, az 1024 értékre tud skálázni. Ez azt jelenti, hogy 2mA felbontáshoz a max mérhető érték 2A körüli (ha a kvantálás szabályait betartod és valóban 2mA pontosságot szeretnél, akkor persze a mérést 1mA-es, vagy még inkább 0.5mA-es küszöbbel kell végezni, akkor már csak 1A illetve 0.5A körül alakulhat az áram (100-200W körüli fogyasztóra elég).
A 0.5mA-es küszöb persze jobb lenne de az áram 10-12A max lesz. Ezért írtam a kérdésben, hogy 100mA felett már nem akarom mérni az áramot (nem is számít, hogy mennyi) csak ne menjen tönkre az áramkör.
Vannak persze olyan perverz gondolataim, hogy betehetnél egy digitális potmétert a rendszerbe. Ha a potméteren mért feszültség a szélső 20%-ok felé jár, akkor programatikusan állítasz az ellenállásosztáson. Ezt a kódban ismerve megvan a dinamikus szorzó a pontos érték visszaszámításához.
Hasonló nekem is eszembe jutott de mi van akkor ha lefagy az arduino? Füst, robbanás?
-
#16832
razorbenke92
őstag
Sebiferi
#16831
válasz
Sebiferi
#16831
üzenetére
Az indukción alapuló mérés semmiképp nem megfelelő? DIY esetben a galvanikus leválasztás nem csak az érintésvédelem miatt fontos, hanem mert ha valami zárlatba megy, akkor a hálózati feszültségből elég energia nyerhető a tűzeset kiváltásához. Söntös árammérésnél pedig sorosan kell kapcsolódnod a hálózati feszültségre, ami az egyébként jól működő védelmek egy részét kizárja. Már maga a közös nullapont kialakítása egy DC mikrokontroller és egy hozzá képest lebegő AC között megfelelő elektronikai ismereteket igényel.
Ha egy Arduinoval mész, az 1024 értékre tud skálázni. Ez azt jelenti, hogy 2mA felbontáshoz a max mérhető érték 2A körüli (ha a kvantálás szabályait betartod és valóban 2mA pontosságot szeretnél, akkor persze a mérést 1mA-es, vagy még inkább 0.5mA-es küszöbbel kell végezni, akkor már csak 1A illetve 0.5A körül alakulhat az áram (100-200W körüli fogyasztóra elég).Vannak persze olyan perverz gondolataim, hogy betehetnél egy digitális potmétert a rendszerbe. Ha a potméteren mért feszültség a szélső 20%-ok felé jár, akkor programatikusan állítasz az ellenállásosztáson. Ezt a kódban ismerve megvan a dinamikus szorzó a pontos érték visszaszámításához.
-
Sebiferi
tag
Sziasztok!
Kérdeztem már hasonlót de sajnos megint előjött a probléma és még nincs megoldva.
230V AC-n szeretnék áramot mérni shunt ellenálással és arduinón mérni a shunt-ön eső feszültséget. A probléma az, hogy nagyon kicsi áramokat szeretnék mérni (2-100mA) A 2mA-es lépcső már megfelel. A 100mA feletti áram "nem számít" - nem érdekes, hogy mennyi ha 100mA felett van, csak ne menjen tönkre az áramkör. Tudom, hogy ez galvanikusan nincs leválasztva de az egész áramkör egy zárt dobozban lesz és RF jellel kommunikál a külvilággal.
Ha valaki futott már bele hasonló problémába és tudna használható linkeket küldeni - azt megköszönném! Kész megoldásnak persze jobban örülnék mert a hajam már hullik ettől. -
válasz
Undoroid
#16829
üzenetére
Boldog új évet neked is! (Hol voltál 9 napig?!
)1. Igen.
2. Ezt csak empirikusan fogod tudni megállapítani. Ha a két modul egy gyártótól származik, akkor van rá esély, hogy a két library bizonyos mértékig kompatibilis egymással, és ha nem akarsz olyan parancsokat küldeni, amit a másik modul nem ért, akkor elvileg működhet. Ha mégsem, akkor a megfelelő lib beszerzése és a kód megfelelő sorainak a javítása lesz a megoldás. Ha ez sem működik, akkor sajnos marad a reverse engineering: bele kell nézni mindkét library-be, és átírni az egész programot.
-
Undoroid
őstag
válasz
Undoroid
#16790
üzenetére
Sziasztok & Boldog Újévet minden szakinak!
Újabb két kérdéssel fordulnék hozzátok:
1: A korábbi példával kapcsolatban szeretnék kérdezni. Az UNO másik három (3, 5, 6 pin) PWM-es kimenetet szeretném aktiválni és teljesen más jeleket produkálni úgy, hogy egyszerre fussanak le (9, 10, 11 pin) és ne várjanak egymásra! Van egy halvány elképzelésem, de ez is a "fix értékekkel" működő, tárhelypocsékolós megoldás lenne...
2: Van ez a kapcsolás és a kapcsolási rajzon szereplő rádió modul (SI4730) és a kódban szereplő ( #include <Si4735.h> ) hivatkozás különbözik. Vajon ezek menni fognak? Az Si4735 adatlapján a másik is meg van említve...nyilván a 4735 'többet tud' a táblázat szerint és ezért másképpen kell a kódban kezelni, vagy annyira kompatibilis egymással a kettő, hogy simán menni fog? Szerintetek?
Köszi a válaszokat!
-
Dißnäëß
nagyúr
Köszi a tippeket. Lesz OLED 256x64 SPI, és 1db RGB LED is. Áram alatt csak a pici trafó, nem az egész, standby-ban. Csôfoglalatokat (3 típus = 3 szenzor) és a ház 3-4 pontján belül, mérem DS18B20-akkal.
Lehet kap 1-1 kisebb 12V ventit is, 5V-ról csendes. A legnagyobb nyári melegben behúzom ôket, de amúgy default soha. -
válasz
Dißnäëß
#16819
üzenetére
Most volt időm végigolvasni ez a hosszú hozzászólást
Eddig abban a hitben voltam, hogy egy graceful shutdown után áramtalanítani is szeretnéd minden alkalommal az eszközt (magamból indultam ki). Ha tervezetten mindig áram alatt lesz, és csak az esetleges áramszünetekre kell a backup megoldás, akkor valóban inkább valami elemet kellene használni, pl 2db CR2032.
A számláló nullázására én megint más metódust használnék
Ha nem lesz kijelző, akkor lehetne 3db RGB led (vagy egyszerűen csak 3db led) mint állapot visszajelző, olcsó és hatékony megoldás.
Érdemes lenne a csövek hőfokának mérését is bevenni a projektbe, ahogy írtad, elég fontos paramétere a működésnek. Vagy külön termisztorral, vagy esetleg a fűtőszál ellenállásának a változásával, ahogy a forrasztópákáknál szokás. -
#16826
Aryes
nagyúr
razorbenke92
#16822
válasz
razorbenke92
#16822
üzenetére
sima load-balancera gondolsz
Igen, doktor úr, ez a pontos kifejezés!
-
#16825
Dißnäëß
nagyúr
razorbenke92
#16824
Dißnäëß
nagyúr
válasz
razorbenke92
#16824
üzenetére
Rendes Tôletek, nagyon köszönöm !
Jelzek, ha feladtam valamivel, valahol -
#16824
razorbenke92
őstag
Dißnäëß
#16823
-
#16823
Dißnäëß
nagyúr
razorbenke92
#16822
Dißnäëß
nagyúr
válasz
razorbenke92
#16822
üzenetére
Bevezetek erre is egy számlálót és egy limitet, hmm ?
-
#16822
razorbenke92
őstag
Aryes
#16807
Távolról sem kell 3byte wear counter
Ha valós wear-counter van, akkor hogyan számolod 100.000-ig, hogy hányszor írtad azt az adatcsomagot
? Vagy csak sima load-balancera gondolsz? Mert persze, akkor elég csomagonként egy bit, ami jelzi hogy hol írtál legutoljára. Csak a kolléga mindent IS számolni szeretne, pont egy ilyen kritikus dolgot ne tartana számon? -
Dißnäëß
nagyúr
válasz
Dißnäëß
#16820
üzenetére
Ja, az ábrámon rossz helyen a kiolvasás (bekapcsoláskor, a legelső ciklus lefutásakor). Na, szóval mondom, még készülget, de valami ilyesmit rakosgatok össze. Aztán ha kész és jónak találom, WAF is pipa, leprogramozom.
Lesz még egy A4-es oldal amúgy, alfolyamat(ok)nak majd, amibe átlépek innen, és vissza. -
Dißnäëß
nagyúr
bekapcsoláskor a timer 0-ról indul, elmegy mondjuk egy zenehallgatás alatt 234567-ig, ezt elmented. Következő bekapcskor ismét nullárol indul, de te hozzáadod a tárolt értéket, így igazából 234567-től 876543-ig fog mondjuk menni, és így tovább, nem kell naptár
Én is így képzelem. Számolhatnám 0-tól is és csak a végén hozzáadom az EEPROM-ban lévő értékhez, és ezek gyűlnek itt, de azt ki is kell olvastatnom vele már a legelején, amolyan bekapcsolás előtti check-ekhez felhasználva. Öreg csővel nem engedem beindulni.cső1 cserélve 23214-kor utoljára, cső2 cserélve 65487-kor utoljára stb. mikor egy csövet cserélsz, csak azt tárolod el, amikor cserélted, így ahány paramétert figyelsz, annyi érték + 1 az időbélyeg amit tárolni ekll az epromban.
Leragadtatok nagyon ennél a percenkénti írásnál
Ezek a változók léptetődnének percenként eggyel, míg áram alatt az erősítő (nem csak az MCU). Az MCU-ban, nem az EEPROM-ban !!!1. Indításkor EEPROM-ból kiolvasok régi értéket
2. Ennek mentén döntök, szabad-e indulnia, és míg működik, nem haladhatom meg vele ezt a határértéket. (Ha meghaladja, mert mondjuk bekapcsolva hagyom 1 hétre véletlenül, akkor lelövi az erősítőt, amint eléri az életkor limitet, és nyilván ezt megteszi 1 héttel előtte is, bármikor, akár indítás után 2 órával is).
3. Áramszünet vagy gomb nyomásra, tehát tökmindegy, hogy graceful, vagy erőltetett, az percenként 1-el léptetett változók értékeit (az MCU-ból) beírom az EEPROM-ba.Tehát: bekapcskor 1 kiolvasás lépés, kikapcskor 1 írás lépés. Előtte-utána és mindeközben az EEPROM nyugiban, nincs használva.
-
Dißnäëß
nagyúr
Nemár, hogy a ph legjobbarc topic-jában tényleg azon gondolkozzon bárki is, hogy leírja, vagy ne, a javaslatait. Hogyafenébene, érdekel
Ami bennem van mindeközben:
1. hűbasszus, túlspirázzuk amit nem kéne
2. na, ezeknek most adtam jó kis feladatot, én dedóban megoldom a logikát, de hogy x ember törpöljön még ezen, inkább nem teszem ki őket ennek ..
3. huh, rommá szofisztikálni lehet még ezt, úgy látom, be is indult az agyalás, érdemes ? Persze lehet. Vagy csak élvezik. Ki tudja
4. Ejjha, néha olyanokat írnak, hogy uhh csak lesek, felét sem értem, lehet jobb lenne az alapoknál maradni, mert több éjszaka kellene ahhoz, hogy felfogjam, amit írtak.. aztán ha később megjöttek az ismereteim, max átprogramozom vagy ilyesmi.. Csináltam egy folyamatábrát. Ez életem második ilyenje.
MÉG NINCS KÉSZ - fenntartással kezeljétek légyszi. Nem is túl profi. Kommentelni sem kell feltétlen, bár nincs ellenemre, csak így hogy értsétek, miben vagyok. Már most van jópár áthuzalozási ötletem rá, a kijelző még benne sincs (nem is igen lesz), most alapfunkciókra gyúrunk és azt is high-level szinten, ez még nem programkód alap, max egy gyenge váz, csak már annyi minden volt a fejemben, gyorsan kiszórtam a cache-ből "papírra" ...Nekem ez egy szigorúan tanuló projekt, de ha ügyes leszek vele, sok-sok évig elkísér és szeretni fogom, mint egy kiscicát.
Olvasok még ennek az órának meg eeprom-nak a használatáról, mielőtt Titeket molesztálnálak vele.
Alapvetően jó, amit kitaláltál, és működni is fog, de kérdés, mennyire biztonságos a tápelvétel utánra tenni az adatok mentését,
Lehet én fogalmaztam rosszul eredetileg: központi táp elvétel. Az erősítőt úgy csinálom, hogy a 230V input a fenekén ugye, itt egy kapcsoló is, ez a főkapcsoló. Ha ez 0, akkor SEMMI, fázis és nulla is szaggatva van. Ha 1, akkor is csak a pici nyák trafó kerül áram alá, a másik 4 toroid trafó (2 fűtés, 2 anódfesz) be van kötve ide, de "NO" relével vezérelt a trafók primer oldalán, magyarul nem működnek még. Így tudom azt elérni, mint kamaszkorom gyári erősítője, hogy standby mód, azaz főkapcsoló felkapcsolva, és akkor MCU áram alatt, lehet LED-em, kijelzőm, vagy akár nem is, tökmindegy, értitek ... de ekkor már figyelve van az előlapi egy szem gomb. És ezzel szépen a be-kikapcsot, illetve bizonyos alap funkciókat (és a "kérdésekre" adott válaszokat) le tudom kódolni, ez monostabil, tehát benyomom és visszarugózik, lehet vele "morzézni" persze nem fog kelleni, csak na. Ez ilyen. Tápelvétel = relék OFF-ba, és mivel az MCU trafó nem relén van, hanem a hátsó kapcsoló 1-es állásában mindig áram alatt, ő még él. Magyarul, normál üzem esetén, amikor ON és STANDBY között vagyok, az MCU mindig él, a nap 24 órájában. (Azaz nem, mert a fenekén is kikapcsolom, ha elutazunk, stb).
Viszont gondolnom kell:
- rendes áramszünetre is, amikor fél napot hallgattam a kütyüt, belement 8 óra, és egyszercsak elszáll minden. Persze, nem világvége, ha 8 óra most nem kerül be az üzemidőkbe, de szeretnék precíz "kilométerórát" - Meg arra is, hogy ISTEN MENTS, hogy mikor az áram visszajön, az egész erősítő felébredne, ez kifejezetten káros, ezt kezelnem kell, és vagy csőfoglalat hőmérsékletet figyeltetek vele, vagy egy plussz biten eltárolnám, hogy ha áramszünet volt (saját trafójának fesze beesik 5.5V alá), akkor 1 a bit értéke, amúgy meg 0.. vagy ezek kombója .. még ezt kiagyalom ..
illetve mennyire kényelmes hosszú távon az erősítő biztonságos kikapcsolására figyelni.
Kényelmetlen, de ezek a kényes jószágok ilyenek. Kikapcsolás nem téma, ki is ránthatom a fenekéből a kábelt. Az újra-ráindítás már nagy gond lenne.Eleve a bekapcsolása 15 perc, mármint az eredeti tervező (ez egy DIY-barát erősítő) ajánlása alapján 15 percig be se kapcsoljuk az anódfeszeket, míg fel nem melegedtek kellő mértékben a csövek. Ezt tök egyszerűen elérem MCU + relékkel. Az életet bonyolítja, igen, de ezek az "öreg" design-os, múltszázadi "csotrogányok" már csak ilyenek.
És elfogadjuk. Mint egy régi veterán autónál, kb, amit restaurálnak, urambocsá, újként megépítenek. -
biker
nagyúr
válasz
Dißnäëß
#16815
üzenetére
bekapcsoláskor a timer 0-ról indul, elmegy mondjuk egy zenehallgatás alatt 234567-ig, ezt elmented. Következő bekapcskor ismét nullárol indul, de te hozzáadod a tárolt értéket, így igazából 234567-től 876543-ig fog mondjuk menni, és így tovább, nem kell naptár
Változók:
cső1, cső2, cső3, kondi1, kondi2, kondi_n+1cső1 cserélve 23214-kor utoljára, cső2 cserélve 65487-kor utoljára stb. mikor egy csövet cserélsz, csak azt tárolod el, amikor cserélted, így ahány paramétert figyelsz, annyi érték + 1 az időbélyeg amit tárolni ekll az epromban.
Teljesen felesleges az eltelt időt tárolni, és percenként írni, mikor elmented mikor lett cserélve, az idő meg telik, és kivonással bármikor megvan az eredmény
-
válasz
Dißnäëß
#16816
üzenetére
Csak megy a brainstorming az általad kitalált feladatra, alternatív módszerek tekintetében, hátha van jobb/biztonságosabb, ami esetleg nem jutott eszedbe, vagy nem tudtál róla, hogy ilyet lehet.
(Magam részéről ezt egy rejtvénynek tekintem, amit meg kell oldani. Szeretem a rejtvényeket )
Alapvetően jó, amit kitaláltál, és működni is fog, de kérdés, mennyire biztonságos a tápelvétel utánra tenni az adatok mentését, illetve mennyire kényelmes hosszú távon az erősítő biztonságos kikapcsolására figyelni. Erre írtam, hogy az igazán hülyebiztos módszer a számláló folyamatos mentése lenne, plusz biker kolléga ötlete alapján kitaláltam egy még hatékonyabb módszert, de csak akkor írom le, ha érdekel. -
Dißnäëß
nagyúr
válasz
Dißnäëß
#16815
üzenetére
Tehát: bekapcsolásonként lenne 1 eeprom írás. 3 + N darab értékkel, N még képlékeny, úgy 3-6 körül lenne kb, majd összeszámolom.
Ez szerintem nem sok, naponta 2x-3x használom, de néha elutazok, stb.. legyen napi 3 bekapcs (pesszimista becslés az eeprom kopásra) és akkor ez évente hasra gyorsan ~ 1000 bekapcs (ennél valszeg kevesebb lehet), 80 évre az ~80ezer eeprom írás, ha addigra nem ette meg a rozsda.
De majd lelakkozom a lábait vagy nem tudom..
Menni fog, vagy aggódjak ?
Én tuti bírni fogom, ízületes leszek addigra, meg csak 10k-ig hallok, de majd emelem a limiteket a duplájára, addigra a rommà használt csô is kiváló lesz. Látjátok, gondolok mindenre. -
Dißnäëß
nagyúr
Hubazz Urak, én ezt nem értem, azaz még felfogom.
Én komplikálom túl, vagy Ti ? 10 darab csô, ebbôl 2 egyforma (input duál-triódák), 4 egyforma (meghajtó pentódák) és 4 egyforma (végfok triódák). És mivel úgyis párban/quad-ban cserélem az egyformákat, elég 3 változó, a 3 eltérô típusra, mivel nagykönyv szerint egyszerre öregszenek az azonos fajták.
3 fajta csô = 3 számláló.
Meg ha elko-kat is figyelek, akkor +3-4 változó még az azonos típusokra, eltérô üzemidôvel (van sima, long life, meg amúgyis szórnak adatlap szerint).
Maradjunk csak a 3 csônél..A csere idôpontja (pláne fullos naptáras RTC-vel) jó lehetne, csakhogy nem 7/24 mennek, hanem épp amikor olyan kedvem van. Tehát naptárhoz nem köthetô, és mint ilyen, nem mérvadó az, hogy mikor volt utoljára cserélve. Legalábbis az én logikámban.
Tegnap éjjel 1-ig rajzoltam egy egyszerû folyamatábrát, amiben felvázoltam a dolgot a leendô programra.
- Bekapcsoláskor kiolvassa az EEPROM-ból a korábban eltárolt perceket, 3 érték. Ezt már most meg kell tenni, mert ha valamelyik a limiten túl van, amennyiben 1.2x-en belül megy túl, csak figyelmeztet, egyébként meg be sem engedi kapcsolni az eszközt. Szóval hülyebiztosra tervezném (gyerek, accon)..
- még egy kis fesz méricske itt-ott stb..
- ha minden feltétel ok, 3 pin HIGH-ba, relék zárnak, fûtések indulnak, elindul a számláló, és percenként növeli a 3 változó mindegyikét, amik értelemszerûen a bekapcskor kiolvasott értékekrôl indulnak, nem nulláról. Ennyi percet a sima integer elbír
- Áramszünet vagy tudatos kikapcsolás esetén a 3 perc-értéket beírja az EEPROM-ba és ennyivót.
- Ha a bekapcsológombot, ami OFF-(ON) típusú nyomógomb, <= 3mp nyomjuk, fenti folyamat megy le.
- Ha a bekapcsológombot > 3mp-ig nyomva tartjuk (kondival simítom a kontaktzajt, és/vagy debounce-al kódban), akkor indul a kijelzôn a "szerviz mód", ahol ezen egyetlen gomb nyomkodásával nem csak nullázni lehet az egyes számlálókat (egyenként vagy mindet), hanem állítani is a limiteken, 1000-órás lépésekben, 1000h és 20000h között, hogy ha esetleg csôcserekor más márkât tennék be, mert kapar a hifibogár, vagy mittomén, és annak eltérô a service life paramétere, hozzá tudjam lôni a limitet is, amihez mér az elektronika.
- beállítások után visszatér a normál standby állapotba, azaz gomb figyelés és ha megnyomom minimum 1x, ami 3mp alattig tart, indul a bekapcsoló folyamat.
Kb. De még finomítom, már kiagyaltam a folyamatot az egyes csövek kiválasztására és a limitek átállítására is, anélkül, hogy kellene több gombot, rotary encoder-t, bármi egyebet használnom.
Jó lesz ez, majd az EEPROM alacsony szintû olvasás-írást kell még megértenem, gyanítom, nem egy print lesz
Wear-leveling témához: ez tök valid, amiket mondtok, de ezt nekünk kell kezelni tényleg ? Szóval nem annyi, hogy "tárold el: ....." aztán beteszi, ahova jónak látja ?
(Életemben nem dolgoztam még eeprom-al). 
-
gyapo11
őstag
válasz
Janos250
#16813
üzenetére
Jaja, itt is jó a teleírás, bár a page write nem tudom hogy szól ebbe bele, de parciális írást is emleget az adatlap. Szukcesszív approximációval nagyon gyorsan meg lehet találni a szabad hely kezdetét.
És 1 M írásciklus. Még azzal is lehet rövidíteni a kiírandót, hogy minden olyan percben, ami nem egész óra csak a percet írnám ki meg ehhez egy jelzőbitet, amiből lehet tudni, hogy az óra változatlan. Aztán a hatvanadiknál megint kiírnám az órát is. Végig kell gondolni, hogy az órák az elején többet foglalnak mint a percek, a végén viszont a percek foglalnak többet.
Vagy 17408 óráig el lehet számolni úgy, hogy egy byte-ot inkrementálni minden percben, 255 perc után a következő byte-ot kezdeni. Áramszünet után megkeresni az eddig használt byte-okat, egy szorzással megvan a percek száma. Használat előtt 00-át kell írni minden byte-ba, minden használt byte-ban van legalább egy 1-es. Ha a 0-zással 256 írás egy kör, akkor 3906 kört bír a chip, ami 68 millió óra, csak valahova föl kell írni a körök számát is. -
-
#16807
Aryes
nagyúr
razorbenke92
#16804
válasz
razorbenke92
#16804
üzenetére
Távolról sem kell 3byte wear counter, elég egyetlen bit minden adatcsomag mellé.
A számlálókat is lehet 2byte-on ábrázolni, a 3.byte-ból úgyis csak az alsó 3bit lenne használva, összesen 8byte-ra lehet tömöríteni, az már több mint 24 évnyi üzemidő, napi 8 óra használattal is 73 évig elég lesz.
De számoljunk akkor csak 5 percenként, úgy elég 17 bit a 10000 órához! 3 számláló helyett pedig 5tel.
5 számláló = 10byte, + az 5 számláló legfelső (17.) bitje + wear leveling bit, és még marad 2 szabad bit tetszőleges felhasználásra, összesen 11byte. Ha jól számolom, 88 év jön így ki.De nem értem amúgy miért nem elég 1 számláló, elvileg mind3 cső együtt öregszik a többivel, nem?
-
#16806
Dißnäëß
nagyúr
razorbenke92
#16804
Dißnäëß
nagyúr
válasz
razorbenke92
#16804
üzenetére
42 éves vagyok. Ha öregkoromig nem rohad szét a cucc, akkor addig szolgál, szóval még van 78 éve.
Uh, jó, hogy mondod: elkók. Basszus, tényleg. Ezt is nézni akartam vele.
Így már 5 számláló párhuzamosan.
(Kétféle üzemórásom van, adatlapok szerint, ahogy eddig láttam). -
#16805
Dißnäëß
nagyúr
razorbenke92
#16802
Dißnäëß
nagyúr
válasz
razorbenke92
#16802
üzenetére
Oh bocs.
Ok. -
#16804
razorbenke92
őstag
Aryes
#16803
Wear levelinggel valóban több, de messze nem örörkélet (persze lehet, hogy rosszul számolok):
10.000 órát percalapon tárolva kell 3bájt, és ő akar 3 számlálót párhuzamosan az 9.
A wear-leveling miatt minden ilyen 9 bájtos blokknak kell egy - jól optimált esetben 3bájtos wear-counter.1024 / 12 az cca. 85. Beszorozva ezt az 1666 órával kb. 16 év jön ki. Tiszta üzemórának véve ez már van olyan sok, hogy cserélni kelljen a kapacitorokat is, de reálisan rövid ahhoz, hogy szem előtt legyen tartva.
A kérdés, hogy mi a projekt tervezett élettartama, és hogy 10+ év távlatban mi a fenntarthatóbb: A uC cseréje, esetleg egy külső EEPROM cseréje, vagy a kondenzátoroké. -
#16803
Aryes
nagyúr
razorbenke92
#16800
válasz
razorbenke92
#16800
üzenetére
Percenként írva az eeepromot - aminek 100k körül van az írási ciklusa - 1666 órára elég.
Nem úgy van az! Ha pl. 1kbyte eeprom áll rendelkezésre, akkor az kb. 195 év.
Wear leveling, már volt róla szó itt a topikban.
Sőt, mivel az egyes bitekre vonatkozik a max írási ciklus, létezik arra is módszer, hogy még az egyes bitek közt is egyenletesebben legyen elosztva az elhasználódás (ugye egy számlálónál a 0. bit íródik a leggyakrabban), amivel a 100k max írási ciklus is növelhető. -
#16802
razorbenke92
őstag
Dißnäëß
#16801
-
#16801
Dißnäëß
nagyúr
razorbenke92
#16800
Dißnäëß
nagyúr
válasz
razorbenke92
#16800
üzenetére
Nem percenként írnék bele, hanem csak kikapcsoláskor és/vagy áramszünetkor. Ez szobai erősítő, ergo egyetlen bekapcsolással elmegy 1-4 órát, mikor milyen kedvem van, szóval az írás gyakorisága nagyon kicsi szerintem. Amíg működik, nem tárolnám le benne mindig az újabb +1 percet.
Amit idéztél, ott hülyeséget írtam. Frissítettem is magam.
Közben megtaláltam a rendes gyártót és adatlapot, még Arduino felhasználási segédletet is, ezzel elleszek most egy ideig.
. A megoldás az lett, hogy nem tettünk különbséget a kódban a rotary típusa szerint. Itt eleve többféle értelmezés is lehetséges, a korábban említett csupán két él figyelése szerintem például nem teljesen korrekt. A teljes és egyértelmű kapcsolási periódus mindenképp négy élből áll, csupán kettőt figyelembe véve félútról visszatekerhető az encoder, ami helyzettől és ízléstől függően furcsán hathat (mivel ekkor az általad 'dupla lépésesnek' nevezett kivitel anélkül ad egy-egy teljes oda-vissza jelzést, hogy akár egyszer is fix mechanikai állapotba lépett volna). A tapasztalat viszont az volt, hogy ha mind a 4 él meglétéhez kötöttünk egy lépést, akkor viszonylag gyakran hibázott, ezért kompromisszumként három éllel megelégedtünk. A hibázás (lépés kihagyása) ekkor elhanyagolható lett, és elmaradt a téves előre-hátra működés is. Persze hardverből is rásegítettünk, ahogy írtad, RC-szűrést (2,7k / 1nF) kialakítva. Gyári készülékeken sem mindig tökéletes a rotary, a mi megoldásunk sem lett annál rosszabb, egész nagy tekerési sebességig használható maradt.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az igen az rendben is lenne, de a hogyan lenne az érdekes!
Ez a lépés sajnos kimaradt legutóbb... 
)
? Vagy csak sima load-balancera gondolsz? Mert persze, akkor elég csomagonként egy bit, ami jelzi hogy hol írtál legutoljára. Csak a kolléga mindent IS számolni szeretne, pont egy ilyen kritikus dolgot ne tartana számon? 
Új hozzászólás Aktív témák
Hirdetés
- OTP Bank topic
- Milyen okostelefont vegyek?
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Milyen videókártyát?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Vezetékes FEJhallgatók
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- E-roller topik
- Facebook és Messenger
- További aktív témák...
- HP Elitebook 840 G3 laptop (15,6FHD/I5-G8/8GB/256SSD/Magyar/Win11)
- AMD Ryzen 5 5500 - GTX 1080Ti 11Gb - MSI B450 Max
- HP Zbook 15 G3 laptop (15,6FHD/I7-G6/16GB/256SSD/AMD2GB/MagyarVilágítós/Win11)
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS ROG Zephyrus GA403UV Gamer notebook - R9 8945HS 16GB RAM 1TB SSD RTX 4060 8GB WIN11
- AKCIÓ! Gigabyte B760M i5 14600KF 32GB DDR4 512GB SSD RX 6800XT 16GB Rampage SHIVA CM 750W
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged