- 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
-
tvamos
nagyúr
válasz
Teasüti
#3395
üzenetére
A MCU-k világában már inkább software-es a prellmentesítés. (En speciel ritkán nem teszek fel legalább egy kis kerámia kondit.) Régen, amikor még kevés volt a program memória, (pl. fél kByte-nál is kevesebb,) meg amikor kapukból építettük a logikát, akkor az volt, amit a kolléga írt.
-
Teasüti
nagyúr
Nyitáskapcsolóhoz miért kell a CHANGE?
Miért nem egyszerűbb egy eseményt figyelni kettő helyett?
Az ilyen state = !state féle váltók amúgy se túl praktikusak ilyen exakt dolgokra, ahol azt kell figyelni, h mikor történik meg egy esemény. Ez szvsz inkább ott használatos, ahol az on/off állapotoknak semmi jelentőségük (akarom mondani felcserélhetők), mint egy LED villogtatása. De azért egy biztonsági kapcsolót nem így kezelnék.Nem macerás egyáltalán, ha megnézed a linken - amit a prell-nél raktam ide - mi történik a jelszinttel kapcsolás közben, akkor láthatod, hogy itt nem egy és nem is kettő megszakítás történik, de minden tüske felfutásánál és lecsengésénél lesz egy CHANGE állapotváltozás. Ezt írták feljebb, hogy ha épp páros számú megszakítás érkezik, akkor ebből te nem veszel észre semmit, mintha mi sem történt volna.
-
Zahze
csendes tag
válasz
Teasüti
#3385
üzenetére
"mint az őrült azt a ledet" - Hogy kéne írnom ?
Amúgy ez csak egy egyszerű példa lenne rá, hogy valami nem kóser a megszakításkezeléssel egy ekkora programba se. (Lehetőség szerint, kizárni a programozási hibát...)
Amúgy ez egy riasztórendszerhez kéne, szebb lett volna így megoldani, ha már van benne ilyen lehetőség hogy megszakításokat használjak. Eddig amúgy a loop-ba volt simán if(digitalRead(2)) - el megoldva, az működött...
Kapcsolási hibát... hát, ennél egyszerűbben nem tudnék semmit összekapcsolni
Szóval szerintem nem ott a hiba.A kapcsolást is és a képet is az Elektromanoid-ról szedtem. Annyi változtatás van az én kapcsolásomban hogy egy NC-s nyitásérzékelővel működik.
Ennyire macerás/instabil ez a jelszint váltás elkapása az arduino számára ?
-
gyapo11
őstag
válasz
Gergosz2
#3392
üzenetére
A hardware-es a legtutibb, a kondi is jó lehet, ha jól el van találva a kapacitása, de lehet akár két nand kapuból váltókapcsolóval, az holtbiztosan egyet billen a lenyomásra és vissza a felengedésre. Vagy lehet hiszterézises hall cella egy mágnessel, vagy valami optokapu stb.
-
zka67
őstag
válasz
Teasüti
#3390
üzenetére
Jaja, rossz a megközelítés. Én 100ms-es timer megszakítással szoktam lekérdezni a nyomógombokat, így simán ki lehet szűrni a prelleket, és a megszakítás alatt még azt is lehet ellenőrizni, hogy a gomb most lett lenyomva, vagy már le volt nyomva stb, stb... és egy inkey() rutinnak átadni a paramétert. Én úgy szoktam, hogy ha az inkey() 0 értékkel tér vissza, akkor nem volt gombnyomás, különben a gomb értékét adom vissza.
-
-
tibi-d
tag
Sziasztok!
Nekem is kellett olyan feladatot megoldani, hogy egy nyomógomb megnyomására csak egyszer hajtson végre egy műveletet. Úgy oldottam meg, hogy egy időzített megszakítás minden 100ms alatt 1X lefut, és ez alatt a ciklus alatt figyeltem a gomb állapotát. Ha eltért az alaphelyzettől, egy segédváltozót 1-be állítok, és elvégeztetem a feladatot(kat), és a segédváltozót csak azután állítom vissza, ha minden végrehajtódott. Addig nem is figyelem a gomb állapotát. Ez akkor hasznos, ha a köztes időben is tudni kell, hogy meg lett nyomva a gomb, és így nincs korlátozva az egyéb feladat végrehajtása sem. Természetesen az időzítés mértéke szabadon állítható. -
gyapo11
őstag
válasz
Teasüti
#3387
üzenetére
A te megoldásod se jó, ha van prell. A prell ugyanis pont olyan, mint a nyomógomb rendes működése, csak gyorsan történik. Tehát ha nincs a beolvasásban időzítés, hanem rábízzuk a sebességet a processzorra, akkor az olyan gyors, hogy simán feldolgozza a ms nagyságrendű prellt is, és lekezeli mint gyors gombnyomkodást.
Kis késleltetés (10 ms körüli) megoldja, persze nem elegáns delay-jel, hanem millis-sel, hogy közben azért a program futhasson. Az interruptos megoldásnál meg az kell, hogy amikor beérkezik az első állapotváltás, akkor egy időzítést indítani, és ezt figyelni az interrupt függvényben, ha az időzítés még nem járt le, akkor figyelmen kívül kell hagyni az állapotváltásokat, mert azok a prell miatt vannak. Ha lejárt az időzítő, akkor megint ki lehet szolgálni a következő 1 db állapotváltást. Az interrupt függvényben ugyan nem működik a millis, de a meghíváskori állapota is megfelelő.
És lehet azt is csinálni, hogy két állapotváltás közötti időt mérni, és ha az kisebb egy adott értéknél, akkor figyelmen kívül hagyni. Pl. 20 ms-en belül ember nem tudja megnyomni kétszer, a prell meg ez idő alatt lecseng. -
Teasüti
nagyúr
válasz
gyapo11
#3386
üzenetére
Gombnyomásra én ezt alkottam:
//button press
if (digitalRead(8) == HIGH && !button) {
button = true;
Serial.println("Pressed");
}
else if (digitalRead(8) == LOW) button = false;Loop-ban fut természetesen és fogalmam sem volt eddig ilyen pergés effektről.
Sosem aktivál egynél többször; ezért merem ajánlani a kollégának.
Felengedésre ír vmit az else if-be és voilá!
Nem volt róla szó milyen gombról van szó.
Talán akkor a pergésmentesítéssel jobban jár, ami a linket van.Vagy lehet olyat, hogy egy lábra két megszakítást kapcsolok?
LOW és RISING? -
gyapo11
őstag
válasz
Teasüti
#3385
üzenetére
Nem az lehet a gond, hogy a gombnak prellje van, és egy nyomás vagy fölengedés valójában n db change, és ezeket a gyors interrupt kiszolgálás mind meg is csinálja? Ha páratlan számú, akkor jól működik, ha páros, akkor viszont látszólag nem történik semmi, valójában annyiszor váltott, csak ezt nem lehet látni.
-
Teasüti
nagyúr
-
Zahze
csendes tag
Sziasztok.
Kérnék egy kis segítséget a megszakításkezeléssel kapcsolatban.
Ami leírást találtam róla így első körbe, az alapján leírtam ezt a kódot.int led = 9;
volatile int state = LOW;
void setup() {
pinMode(led,OUTPUT);
attachInterrupt(0,blink,CHANGE);
}
void loop() {
digitalWrite(led,state);
}
void blink() {
state = !state;
}Nah most annyi lenne a bajom, hogy nem működik stabilan a Led ki/bekapcsolása amikor lenyomom a gombocskámat, amit a Mega 2-es lábára kapcsoltam, persze felhúzó ellenállást használva.
Ez mitől lehet ? A leírásokból úgy vettem ki hogy a CHANGE-el, akkor is változnia kéne a Led állapotának amikor lenyomom a gombot, és akkor is amikor felengedem a gombot. Ugyanakkor, van amikor nem veszi figyelembe valamelyik eseményt...
Ez mitől lehet ? -
quint
aktív tag
Felraktam egy viszonylag tömör megoldást az általad használt bekötéssel (a szegmensek hivatalos elnevezését használtam, a bekötés pontosan megegyezik a tiéddel). Közös anódos kijelzőhöz készült (a tiéd is), közös katódoshoz a 12.-18. sorokból ki kell venni a negálást.
Először bökj a "Code Editor" gombra, ott majd meg tudod nyitni a "Serial Monitort", aztán mehet a szimuláció (a soros monitoron írhatod be a megjeleníteni kívánt számjegyet).
A 25. sorban a 0-9 tartományon kívül eső számok esetén minden szegmens törlődik.
A 31. és 32. sorban nincs korrekt hibakezelés, de annyit láthatsz belőle, hogy a soros vonalról jövő ASCII kódot ("0" - 48 ... "9" - 57) át kell alakítani a megfelelő számjeggyé (ez nálad hiányzott).A tizedespont kezelésével nem foglalkoztam. Ha libraryt akarsz készíteni belőle, akkor valószínűleg nem fog különösebb gondot okozni.
-
Sokimm
senior tag
válasz
Janos250
#3380
üzenetére
Igen igen, a következő lett az eredmény (csak konzolról nem tudom beolvasni az értéket... A switch case-ig nem jut a beolvasott érték. :\)
sevensegment.ino
#include "sevensegment.h"
sevensegment kijelzo(7, 9, 11, 8, 10, 6, 12, 13);
void setup()
{
Serial.begin(9600);
Serial.println("csak 1-9 kozotti erteket adj meg!");
}
void loop()
{
kijelzo.kiir(Serial.read());
delay(500);
}sevensegment.h
#ifndef sevensegment_h
#define sevensegment_h
#include <Arduino.h>
class sevensegment
{
private:
byte _f; byte _k; byte _a; byte _bf; byte _ba; byte _jf; byte _ja; byte _p;
public:
byte szam;
sevensegment(byte f, byte k, byte a, byte bf, byte ba, byte jf, byte ja, byte p);
void kiir(byte szam);
};
#endifsevensegment.cpp
#include "Arduino.h"
#include "sevensegment.h"
#include "pins_arduino.h"
sevensegment::sevensegment(byte f, byte k, byte a, byte bf, byte ba, byte jf, byte ja, byte p)
{
pinMode(f, OUTPUT);
_f = f;
pinMode(k, OUTPUT);
_k = k;
pinMode(a, OUTPUT);
_a = a;
pinMode(bf, OUTPUT);
_bf = bf;
pinMode(ba, OUTPUT);
_ba = ba;
pinMode(jf, OUTPUT);
_jf = jf;
pinMode(ja, OUTPUT);
_ja = ja;
pinMode(p, OUTPUT);
_p = p;
}
void sevensegment::kiir(byte szam)//
{
switch (szam) {
case 0:
Serial.println("nulla");
break;
case 1:
digitalWrite(_jf, LOW);//1
digitalWrite(_ja, LOW);
digitalWrite(_f, HIGH);
digitalWrite(_bf, HIGH);
digitalWrite(_k, HIGH);
digitalWrite(_a, HIGH);
digitalWrite(_ba, HIGH);
break;
case 2:
digitalWrite(_jf, LOW);//2
digitalWrite(_ja, HIGH);
digitalWrite(_f, LOW);
digitalWrite(_bf, HIGH);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, LOW);
break;
case 3:
digitalWrite(_jf, LOW);//3
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, HIGH);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, HIGH);
break;
case 4:
digitalWrite(_jf, LOW);//4
digitalWrite(_ja, LOW);
digitalWrite(_f, HIGH);
digitalWrite(_bf, LOW);
digitalWrite(_k, LOW);
digitalWrite(_a, HIGH);
digitalWrite(_ba, HIGH);
break;
case 5:
digitalWrite(_jf, HIGH);//5
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, LOW);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, HIGH);
break;
case 6:
digitalWrite(_jf, HIGH);// 6
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, LOW);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, LOW);
break;
case 7:
digitalWrite(_jf, LOW);//7
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, HIGH);
digitalWrite(_k, HIGH);
digitalWrite(_a, HIGH);
digitalWrite(_ba, HIGH);
break;
case 8:
digitalWrite(_jf, LOW);//8
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, LOW);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, LOW);
break;
case 9:
digitalWrite(_jf, LOW);// 9
digitalWrite(_ja, LOW);
digitalWrite(_f, LOW);
digitalWrite(_bf, LOW);
digitalWrite(_k, LOW);
digitalWrite(_a, LOW);
digitalWrite(_ba, HIGH);
break;
default:
break;
}
} -
Sokimm
senior tag
Sziasztok guruk!
Nem látom a hibám, kérlek segítsetek.
A hiba az inu-ban, kommentezve.
Jah ez egy 7 szegmenses kijelző vezérlése lenne, de nem tudok tovább jutni. :\sevensegment.inu:
#include "sevensegment.h"
void setup()
{
sevensegment kijelzo(7, 9, 11, 8, 10, 6, 12, 13);
}
void loop()
{
sevensegment.kiir(); // expected unqualified-id before '.' token
}sevensegment.cpp:
#include "Arduino.h"
#include "sevensegment.h"
#include "pins_arduino.h"
sevensegment::sevensegment(byte f, byte k, byte a, byte bf, byte ba, byte jf, byte ja, byte p)
{
pinMode(f, OUTPUT);
pinMode(k, OUTPUT);
pinMode(a, OUTPUT);
pinMode(bf, OUTPUT);
pinMode(ba, OUTPUT);
pinMode(jf, OUTPUT);
pinMode(ja, OUTPUT);
pinMode(p, OUTPUT);
}
void sevensegment::kiir(byte szam)
{
switch (szam) {
case 0:
Serial.println("anyad");
break;
default:
break;
}
}sevensegment.h:
#ifndef sevensegment_h
#define sevensegment_h
#include <Arduino.h>
class sevensegment
{
private:
public:
//byte f, k, a, bf, ba, jf, ja, p;
sevensegment(byte f, byte k, byte a, byte bf, byte ba, byte jf, byte ja, byte p);
void kiir(byte szam);
};
#endif -
tvamos
nagyúr
válasz
Teasüti
#3377
üzenetére
Szerintem nem megoldhatatlan ez a probléma. Ha nem sikerül kiküszöbölni 1-1 byte elvesztését, akkor azt kell megoldani, hogy a vevő tudja, hogy ott elveszett valami, és a küldő újra küldje a csomagot.
(#3375) Janos250 válasza gyapo11 (#3373) üzenetére
Persze... ez az professzionális alkalmazás lesz... -
Teasüti
nagyúr
válasz
Janos250
#3375
üzenetére
Érthető, hisz utóbbi úgy indul, h képezd ki magad cnc-ből és forgácsolásból. Majd vegyél cnc gépet.
Persze átvitt értelemben, de akár szó szerint is.
Ha meg szakembert bízok meg vele és gépet bérlek, akkor meg nem DIY.(#3363) gyapo11
Nem hiszem el, h ezt az arduino közösség még nem oldotta meg.
Elég alapvető igénynek tűnik, h parancsot lehessen küldeni az MCU-nak. -
gyapo11
őstag
válasz
Janos250
#3369
üzenetére
Köszi, akkor most már ezt is láttam.
Nem mondom, hogy mindent értek benne, de nyilvánvalóan nem assembly, tehát ez még csak egy utasítássorozat a fordítónak.
De a lényege a dolognak az, hogy ha megy a byte-ok kifütyülése (vegy beolvasása), és jön egy megszakítás, mert ki akarom szolgálni a távirányítót pl., akkor ezt hogy kezeli le a program, és hogy kezeli le az én programom, amiben meghívtam a soros portkezelő függvényt. És hogyan tudom kitalálni, hogy ha elveszett valami, akkor az miért történt?
Olyan ez, mint az állatorvos, aki nem tud átlépni a kerítésen, és bent van a beteg ló.
Az, hogy a c, c++ forrás elveszi előlünk a gépi kódot egyszer előny a könnyű használhatóságban, máskor hátrány a hibakeresésben.
Ezért van az, hogy ha hibába ütközik valaki, és föltesz egy kérdést, akkor a próbáld másik libbel, tölts le másik sku-t, próbáld másik IDE-vel tanácsok jönnek. Észre kell venni, hogy ez nem informatikai szakmunka hanem legozás, próbálgatás. -
gyapo11
őstag
válasz
Janos250
#3368
üzenetére
Mint ahogy írta valaki megvette az Atmelt.
De egyébként is az várható, hogy mindenféle mikrovezérlő meg fog jelenni arduino kompatibilisen lapon. Ez a nagy dolog az arduinoban. Amit szidok a debugolás hiánya, az pont előny abban, hogy ugyanazt a forrást le lehet fordítani a világ összes processzorára. És nem az a lényeg, hogy atmel ketyegjen rajta, hanem hogy működjön, az összes hobbista velem együtt ezért szereti. -
Janos250
őstag
válasz
gyapo11
#3366
üzenetére
"én pl. még nem láttam azt a kódot, ami akkor fog lefutni, amikor ezt a sort hajtja végre és küldi ki a soros portra a byte-okat"
Tessék:
size_t HardwareSerial::write(uint8_t c)
{
_written = true;
// If the buffer and the data register is empty, just write the byte
// to the data register and be done. This shortcut helps
// significantly improve the effective datarate at high (>
// 500kbit/s) bitrates, where interrupt overhead becomes a slowdown.
if (_tx_buffer_head == _tx_buffer_tail && bit_is_set(*_ucsra, UDRE0)) {
*_udr = c;
sbi(*_ucsra, TXC0);
return 1;
}
tx_buffer_index_t i = (_tx_buffer_head + 1) % SERIAL_TX_BUFFER_SIZE;// If the output buffer is full, there's nothing for it other than to
// wait for the interrupt handler to empty it a bit
while (i == _tx_buffer_tail) {
if (bit_is_clear(SREG, SREG_I)) {
// Interrupts are disabled, so we'll have to poll the data
// register empty flag ourselves. If it is set, pretend an
// interrupt has happened and call the handler to free up
// space for us.
if(bit_is_set(*_ucsra, UDRE0))
_tx_udr_empty_irq();
} else {
// nop, the interrupt handler will free up space for us
}
}_tx_buffer[_tx_buffer_head] = c;
_tx_buffer_head = i;sbi(*_ucsrb, UDRIE0);
return 1;
}Nem gondolom, hogy az Arduinot használók között túl sokan vannak, akik az assembly kódot akarják bogarászni. Aki mégis, az meg azt is tudja, hogyan kell a fordítót paraméterezni, hogy legyen egy közbülső assembly kódod is.
-
Janos250
őstag
Egy "amatőr" cég [Microchip
] honlapjáról egy ajánlás:"chipKIT Development Platforms Professional Tools Inspired by Arduino"
"Simple code development with the official Arduino IDE (v1.6.7 or later);
compatible with most Arduino functions and libraries"[link]
http://ww1.microchip.com/downloads/en/DeviceDoc/00001423C.pdfMár a Microchip saját oldalának ajánlatai között is szerepel Arduino?
-
gyapo11
őstag
Ha én írok minden utasítást, amit a processzor végrehajt, akkor ez igaz. A megszakításokat, a soros port kezelést, és mindent. És még ez sem pontos, hiszen egy a=5; programsor valójában lesz vagy 20 gépi kódú utasítás, és ha hibát/időzítést kell keresni, akkor nem az a=5; és társai sorokban kell, hanem a gépi kódban.
Rágen, még a dosos időkben volt a turbo pascal meg a turbo debugger. A debuggerbe betöltve a pascal forrást, mellette mutatta a forrásból fordított gépi kódot, a futási időket, na az hibakeresés volt. Az arduinon a beszúrt sorokkal led villogtatás vagy soros portra írás, az nem hibakeresés, csak annak egy nagyon halvány lenyomata.
Arduinonál írok egy programot, amibe belinkelek egy halom libraryt, van egy bootloader. A soros portot nem bitenként billegtetem időzítve, hanem serial.print, én pl. még nem láttam azt a kódot, ami akkor fog lefutni, amikor ezt a sort hajtja végre és küldi ki a soros portra a byte-okat. Ha nem láttam, akkor hogy tudnék benne hibát keresni? Ha nem tudok hibát keresni, akkor honnan tudnám megmondani, hogy miért vesznek el adatok?
Vagyis amikor kiírom a soros portra hogy hello, akkor nem tudom mit csinál a processzor.
Ha a hex file-t visszafordítanám assemblyre, ugyanezt a libekkel is meg a bootloaderrel is, akkor láthatnám, hogy mit csinál a processzor, de addig nem. -
zka67
őstag
válasz
gyapo11
#3363
üzenetére
Szia, bocs, hogy beleszólok, de
Amíg nem tudjuk pontosan, hogy bármely pillanatban mit csinál a processzor
az elég komoly probléma, elég gyenge programozóra vall.
Nem a processzor programoz minket, hanem mi programozzuk a processzort, az pedig végre kell hogy hajtsa az utasításainkat. Nem mást, hanem azt, amit leírunk neki. Ha tudjuk, hogy mit írunk le, akkor tudni fogjuk azt is, hogy melyik pillanatban mit csinál a processzor. Szerintem...
-
Janos250
őstag
válasz
Teasüti
#3361
üzenetére
Az okát jól leírta gyapo11.
Amatőr megoldás a problémára:
1. Az öregecske 328-as proci helyett egy korszerűbb. Nem drágább pl. egy ARM, ami sokkal gyorsabb, nagyobb a memóriája, korszerűbb. A megírt arduino program úgyanúgy (általában) fut rajta.
2. Multiprocesszor amatőr megoldása, hogy ha ragaszkodsz a 328-as procihoz, hogy egy picike külön 328-as Arduino panel (5-600 Ft), ami semmi mást nem csinál, csak a soros portot kezeli, ha lehet/szükséges előfeldolgozást végez, és akkor küldi át a ténylegesen dolgos procinak, amikor az kéri. -
gyapo11
őstag
válasz
Teasüti
#3361
üzenetére
A program feltöltése közben a mikrovezérlőn nem fut a kód, resettel kezdődik a feltöltés. Tehát minden figyelmét a soros porton érkező byte-okra fordítja.
Amikor viszont fut a kód, akkor ugrálnia kell a kód és a soros port etetése között, és itt bejöhet időzítési probléma, akadozás, ami adatvesztést eredményez. Sokszor elég egy kis delay, de a pontos megoldás mélyebb ismereteket igényel mind a mikrovezérlő működése mind a librarykban található kódot illetően.
Amíg nem tudjuk pontosan, hogy bármely pillanatban mit csinál a processzor, addig nem tudhatjuk az okot se a hibajelenségre. Ezért nem annyira alkalmas az arduino rendszer profi feladatmegoldásra, nincs megfelelő szintű debug, léptetés, regiszterek kiíratása, amivel meg lehetne találni a hibát. -
#3362
gyapo11
őstag
Daszkalosz19
#3360
gyapo11
őstag
válasz
Daszkalosz19
#3360
üzenetére
A Relay változó nem a relé állapotát tárolja, hanem a port számát (4).
Ezt hiába vizsgálod az ifben, hogy HIGH-e az értéke.
Ezért kell egy másik változó, ami a port állapotát tartalmazza, ahogy írtam a kódban (rel). És ebbe a változóba be kell írni az aktuális állapotot, amit kivettél a kódból. -
Teasüti
nagyúr
válasz
gyapo11
#3354
üzenetére
Ez egy remekül összeszedett eszmefuttatás!
Amúgy mi az oka annak, h elvesznek bájtok a soros porton?
Én is küzdök ezzel a problémával és most már csak széttárom a karjaim.
De csak serial monitorból érkező adatok vesznek el, a küldött az hibátlan és a program feltöltés se hibázik. -
#3360
Daszkalosz19
aktív tag
gyapo11
#3359
Daszkalosz19
aktív tag
válasz
gyapo11
#3359
üzenetére
Szia!
Jelenleg így néz ki a dolog. kiírja,hogy off,de a relé állapotváltozásra nem reagál#include "DHT.h"
#define DHTPIN 2 // what pin we're connected to
#define DHTTYPE DHT22 // DHT 22 (AM2302)
#define Relay 4
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 20, 4);
byte e1[8] = {B10,B100,B1110,B10001,B11111,B10000,B1110}; // Ez az é betű
byte o1[8] = {B100,B100,B0,B1110,B10001,B10001,B1110}; // Ez a hosszú ó betű
byte o2[8] = {B1010,B0,B1110,B10001,B10001,B10001,B1110}; // Ez a rövid ö betű
byte o3[8] = {B1010,B1010,B0,B1110,B10001,B10001,B1110}; // Ez a hosszú ő betű
byte a1[8] = {B10,B100,B1110,B1,B1111,B10001,B1111}; // Ez az á betű
byte u2[8] = {B1010,B0,B0,B10001,B10001,B10011,B1101}; // Ez a rövid ü betű
byte u3[8] = {B1010,B1010,B0,B10001,B10001,B10011,B1101}; // Ez a hosszú ű betű
byte i1[8] = {B10,B100,B0,B1110,B100,B100,B1110}; // Ez a hosszú í betű
int maxHum = 80;
int maxTemp = 33;
DHT dht(DHTPIN, DHTTYPE);
void setup() {
pinMode(Relay, OUTPUT);
Serial.begin(9600);
Wire.begin();
dht.begin();
lcd.begin(20, 4);
lcd.backlight();
{
lcd.setCursor(2, 0);
lcd.print("Kelteto vezerles");
lcd.setCursor(8, 0);
lcd.write(4);
lcd.setCursor(13, 0);
lcd.write(1);
lcd.setCursor(16, 0);
lcd.write(1);
lcd.setCursor(3, 1);
lcd.print(" By:Daszkalosz ");
lcd.setCursor(4, 2);
lcd.println(" 2016.07.26 ");
delay(3000);
lcd.clear();
}
lcd.createChar(1, e1); // Ez az é betű
lcd.createChar(2, a1); // Ez az á betű
lcd.createChar(3, o1); // Ez a hosszú ó betű
lcd.createChar(4, o3); // Ez a hosszú ő betű
lcd.createChar(6, u2); // Ez a rövid ü betű
lcd.createChar(7, u3); // Ez a hosszú ű betű
lcd.createChar(0, i1); // Ez a hosszú í betű
}
void loop() {
// Wait a few seconds between measurements.
delay(2000);
// Reading temperature or humidity takes about 250 milliseconds!
// Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
float h = dht.readHumidity();
// Read temperature as Celsius
float t = dht.readTemperature();
// Check if any reads failed and exit early (to try again).
if (isnan(h) || isnan(t)) {
lcd.println("Szenzor ERROR!");
return;
}
if(h > maxHum || t > maxTemp) {
digitalWrite(4, HIGH);
} else {
digitalWrite(4, LOW);
}
// Hőmérséklet.
lcd.setCursor(0, 0);
lcd.print("Homerseklet: ");
lcd.setCursor(1, 0); //Kurzor 3. sor 2. karakternél
lcd.write(4); //Átírjuk az o betüt ő-re
lcd.setCursor(3, 0); //Kurzor 3. sor 4-es karakternél
lcd.write(1); //Átírjuk az e betüt é-re
lcd.setCursor(6, 0); //Kurzor 3. sor 7-es karakternél
lcd.write(1); //Átírjuk az e betüt é-re
lcd.setCursor(13, 0); //Kurzor 3. sor 14-es karakternél
lcd.print(t); //Hőmérséklet érték kiírása
lcd.print((char)223); //Fokjel előhívása memoriából
lcd.print("C");
// Páratartalom.
lcd.setCursor(0, 1);
lcd.print("Paratartalom: ");
lcd.setCursor(1, 1);
lcd.write(2); //Átírjuk az a betüt á-re
lcd.setCursor(14, 1); // A páratartalom kijelzés a 14.sortól kezdődik
lcd.print(h);
lcd.print("%");
delay(200);
//Vízmelegítő.
lcd.setCursor(0, 2);
lcd.print("Vizmelegito :");
lcd.setCursor(1 ,2);
lcd.write(0);
lcd.setCursor(8 ,2);
lcd.write(0);
lcd.setCursor(10 ,2);
lcd.write(4);
if(Relay == HIGH)
{
lcd.setCursor(13,2);
lcd.print(" ON ");
}
else
{
lcd.setCursor(13,2);
lcd.print(" OFF ");
}
} -
#3359
gyapo11
őstag
Daszkalosz19
#3358
gyapo11
őstag
válasz
Daszkalosz19
#3358
üzenetére
Akkor a vízmelegítő kiíratása után állitsd be a kurzort a kívánt helyre, és oda tedd a kiíratást.
Változót (rel) gondolom deklaráltad a megfelelő helyen. -
#3355
gyapo11
őstag
Daszkalosz19
#3352
gyapo11
őstag
válasz
Daszkalosz19
#3352
üzenetére
Kicsit átformáztam a kódot:
if(h > maxHum || t > maxTemp) {digitalWrite(Relay, HIGH); rel="be";}
else {digitalWrite(Relay, LOW); rel="ki";}és ide az if után:
lcd.println(rel); -
gyapo11
őstag
válasz
Teasüti
#3351
üzenetére
Valójában a villogás nem a megfelelő szó, jobb az akadozás. Simán el tudom képzelni, hogy valaki megírja az animációt, valaki más a távirányító kezelését, és a kettőt összeeresztve akadozni kezd, mert pont akkor nyomok rá a távirányítóra, amikor léptetni kellene az animációt, és a processzor egyszerre csak egy dologgal tud foglalkozni, a szem meg érzékeny az akadozásra. Ilyenkor jön az, hogy meg kellene találni az okát, de ezt idegen kódban és nem profi programozási tudással elég nehéz. Ha meg profi a tudás, akkor nem kell netről vadászni a kódot, hanem meg kell írni az első byte-tól úgy, hogy az infrát is le tudja kezelni a legkisebb akadás nélkül.
A megszakítás jó dolog, de nem tud csodát. Vagy az eredeti kód fut, vagy a megszakítást szolgálja ki, de addig az eredeti kód áll. Ahhoz több processzormag, közös memóriakezelés stb. kellene, hogy egy beérkező megszakítás ne állítsa meg az egyik magon futó kódot, és a másik magon azonnal futhasson a megszakítás.
Egy távirányítóról érkező parancs kiszolgálása persze elég rövid idő, de ha nem jól van megírva a kód vagy a library, akkor akár látható nagyságú idő is elmehet, és gond van.
Nem beszélünk konkrét számokról, mert ahhoz kellene a kód, és még akkor sem könnyű összeszámolni a szükséges órajel ciklusokat. Ehelyett ha írunk egy kis ciklust, az kb. 100 ezer/s, ha csinál is valamit, akkor legyen 10 ezer/s, ez 100 μs, ha pl. hangfrekis hullámformát generálunk, és egy megszakítás elvesz ennyi időt, akkor az már hallható lesz.
Sokszor láttuk már itt a fórumon is, meg más forráskódokban is a delay(1)-et vagy hasonlót, mert különben elvesznek byte-ok a soros vagy egyéb csatornán. Pedig a processzor 16 MHz-en pörög, és az ehhez képest rettentő lassú soros porton is el tud veszni adat, ha nem állítjuk meg egy ms-ig a futást.
Már egy ilyen kis processzorocska is annyi mindent csinál, hogy nem elemezzük órajel szinten. Ráadásul mi c++ forráskódódot látunk, de a processzorba egy ebből generált bináris kód megy, nem tudjuk, hogy melyik arduino utasításból milyen bináris kódot generál, így nem tudjuk az időigényeket se. Ráadásul ott vannak a libek, amiknek még a forráskódját se nézzük, hanem csak include-oljuk és reménykedünk benne, hogy működik és nem ütközik semmivel.
Ezért mondom, hogy ez hobbyra van kitalálva, mert pillanatok alatt tud bárki működő programot futtatni. Amint bonyolódik a program, mindenféle korlátokba ütközünk, az időzítést is nehéz kézbentartani, a libek minősége ismeretlen, a szigorú tesztelése időigényes. Mindezek elkerülése meg oda vezet, hogy elhagyjuk az arduino hw-t és sw-t is, és magát a mikrovezérlőt programozzuk profi eszközzel, debuggal, teszteléssel.
Vannak komoly házvezérlések, és egyéb bonyolultabb projectek, tehát sikerülhet a dolog, de erre nem lehet építeni, nem lehet megélhetést alapozni rá. -
#3353
norbert1998
nagyúr
norbert1998
nagyúr
üdv
érdeklődnék, hogy egy win xp-t futtató gépre mennyi macerával jár egy már grbl-t futtató arduino-t csatlakoztatni, hogy utána offline működjön végre az a kramanc?
-
#3352
Daszkalosz19
aktív tag
Daszkalosz19
aktív tag
Sziasztok!
egy relay állapotát hogyan tudom kiiratni lcd-re
kezdőként itt küszködök vele
ez lenne a kódom:köszönöm a segítséget!
#include "DHT.h"
#define DHTPIN 2
#define DHTTYPE DHT22 // DHT 22 (AM2302)
#define Relay 4
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 20, 4);
byte e1[8] = {B10,B100,B1110,B10001,B11111,B10000,B1110}; // Ez az é betű
byte o1[8] = {B100,B100,B0,B1110,B10001,B10001,B1110}; // Ez a hosszú ó betű
byte o2[8] = {B1010,B0,B1110,B10001,B10001,B10001,B1110}; // Ez a rövid ö betű
byte o3[8] = {B1010,B1010,B0,B1110,B10001,B10001,B1110}; // Ez a hosszú ő betű
byte a1[8] = {B10,B100,B1110,B1,B1111,B10001,B1111}; // Ez az á betű
byte u1[8] = {B10,B100,B10001,B10001,B10001,B10011,B1101}; // Ez a hosszú ú betű
byte u2[8] = {B1010,B0,B0,B10001,B10001,B10011,B1101}; // Ez a rövid ü betű
byte u3[8] = {B1010,B1010,B0,B10001,B10001,B10011,B1101}; // Ez a hosszú ű betű
byte i1[8] = {B10,B100,B0,B1110,B100,B100,B1110}; // Ez a hosszú í betű
int maxHum = 95;
int maxTemp = 29;
DHT dht(DHTPIN, DHTTYPE);
void setup() {
pinMode(Relay, OUTPUT);
Serial.begin(9600);
Wire.begin();
dht.begin();
lcd.begin(20, 4);
lcd.backlight();
lcd.createChar(1, e1); // Ez az é betű
lcd.createChar(2, a1); // Ez az á betű
lcd.createChar(3, o1); // Ez a hosszú ó betű
lcd.createChar(4, o3); // Ez a hosszú ő betű
lcd.createChar(5, u1); // Ez a hosszú ú betű
lcd.createChar(6, u2); // Ez a rövid ü betű
lcd.createChar(7, u3); // Ez a hosszú ű betű
lcd.createChar(0, i1); // Ez a hosszú í betű
}
void loop() {
delay(2000);
float h = dht.readHumidity();
// Read temperature as Celsius
float t = dht.readTemperature();
// Check if any reads failed and exit early (to try again).
if (isnan(h) || isnan(t)) {
lcd.println("Szenzor ERROR!");
return;
}
if(h > maxHum || t > maxTemp) {
digitalWrite(Relay, HIGH);
} else {
digitalWrite(Relay, LOW);
}
// Hőmérséklet.
lcd.setCursor(0, 0);
lcd.print("Homerseklet: ");
lcd.setCursor(1, 0); //Kurzor 3. sor 2. karakternél
lcd.write(4); //Átírjuk az o betüt ő-re
lcd.setCursor(3, 0); //Kurzor 3. sor 4-es karakternél
lcd.write(1); //Átírjuk az e betüt é-re
lcd.setCursor(6, 0); //Kurzor 3. sor 7-es karakternél
lcd.write(1); //Átírjuk az e betüt é-re
lcd.setCursor(13, 0); //Kurzor 3. sor 14-es karakternél
lcd.print(t); //Hőmérséklet érték kiírása
lcd.print((char)223); //Fokjel előhívása memoriából
lcd.print("C");
// Páratartalom.
lcd.setCursor(0, 1);
lcd.print("Paratartalom: ");
lcd.setCursor(1, 1);
lcd.write(2); //Átírjuk az a betüt á-re
lcd.setCursor(14, 1); // A páratartalom kijelzés a 14.sortól kezdődik
lcd.print(h);
lcd.print("%");
delay(200);
//Vízmelegítő.
lcd.setCursor(0, 2);
lcd.print("Vizmelegito:");
lcd.setCursor(1 ,2);
lcd.write(0);
lcd.setCursor(8 ,2);
lcd.write(0);
lcd.setCursor(10 ,2);
lcd.write(4);
} -
Teasüti
nagyúr
válasz
gyapo11
#3336
üzenetére
Villogni kezd?
Az animáció?
Ezért lehet érdemes grafikus futószalag elvén megírni, ahol minden egyes loop() ciklus egy képkockát generál.
A parancsokat megszakítással veszi és polling-gal rakja össze a pufferből. Annyi, hogy amíg a LED frissítése zajlik, arra a rövid időre kikapcsolom a megszakítást. (BAAAAZDMEG lehet ezért veszik el egy-egy vezérlőbájtom a BT átvitel során??
Há Móóónika! Megyek dolgom van! 
)
Így nálam bármilyen fps mellett működőképes marad minden egyéb funkció.
És persze a LED-ek sem villognak, hisz a PWM vezérlő sample&hold elven működik, legfeljebb az animáció akadozik, ha nagyon beesik az fps, de itt csak 120 ledről (meg pár paletta, ami mi is pontosan?) beszélünk és az animáció erőforrásigénye se óriási. Egy 8 bites Atmel328p vígan elviszi a tapasztalataim alapján több száz fps-el.(#3334) printpro
Azt hiszem tudok segíteni neked, viszont határozatlan időre tudnám csak vállalni a feladatot. Hetekig tartana ráérő szabadidőmben. Nem számolva a posta idejével, amíg megérkeznek a kellékek hozzá ebay-ről. -
Janos250
őstag
válasz
printpro
#3334
üzenetére
Saját szórakoztatásomra tököltem vele egy órát. Simán össze lehet rakni, és a kombinálás se gond. Pénzes melót nem vállalok, nem azért írom, de saját szórakozásra meg fogom csinálni, ha néhány nap múlva visszajövök vidékről, mert megtetszett a dolog, ahogy felváltva egyik, majd másik "műsor megy", változtatott fényerővel. A hue, saturation változtatás valószínűleg még élvezetesebbé teszi, de azt még nem próbáltam, mert képletekkel kell átszámítani az RGB-t, változtatni, majd vissza. :-)
-
whYz
őstag
Sziasztok
Irtam egy egyszeru wifi shield ellenorzo kodot ami tokeletesen mukodik uno-val, viszont 101-al csak a "Testing..." reszig jutok el es ott megakad.
A wifi shield nincs csatlakoztatva, nem is ez lenne a lenyeg, csak a kod mukodjon es ismerje fel, hogy nincs wifi shield.
Mi lehet a problema? Legujabb libraryk vannak fent de regebbiekkel is probaltam, nem sok sikerrel. Probaltam kulonbozo usb-vel, serial helyet led-el, barrel jack-el stb...
#include <SPI.h>
#include <WiFi101.h>
void setup() {
Serial.begin(9600);
while (!Serial) {
;
}
Serial.println("WiFi101 check.");
Serial.println();
Serial.println("Testing...");
WiFi.status();
Serial.println("Done");
}
void loop() {
}Ezzel szenvedek mar 2 napja, mar mindent ujraraktam es nem jutok elorebb.
-
Pubszon
veterán
-
Janos250
őstag
válasz
soldi3r
#3337
üzenetére
Természetesen!
Az egy C++-ról lefordított program. Sőt, ha ARM-ra, PIC-re fordítod, ott is megy, persze ha nem alap szinten kezeled a hardware-t. Ha úgy tartja úri kedved, akár az Arduino bootloadere nélkül is betöltheted.
A framework tartalmazza minden illesztett procira egy fájlban, hogy az adott, C++-ban (C-ben) megírt kódot, "hogyan kell fordítani". (Pongyolán fogalmazva. Aki precízen akarja, utána olvashat. ) Például, hogyan kell fordítani azt, hogy a programban 2-es lábnak nevezett lábat emelje fel, vagy tegye le, és melyik lesz a "2-es" láb. -
gyapo11
őstag
válasz
soldi3r
#3337
üzenetére
Kell neki táp, kvarc és szerintem megy. Esetleg reset, aref hidegítés.
Az IDE lefordítja a forrást hexára és azt égeti be. Ugyanezt csinálja bármi más programozó megoldás is akármilyen nyelvről.
Persze ha magában van a chip, akkor nincs usb csatlakozás, ki kell vezetni a programozó lábakat tüskékre és úgy lehet programozni. Vagy ha van benne bootloader, akkor soros porton. -
gyapo11
őstag
válasz
printpro
#3334
üzenetére
Pontosan. Egy-egy valamit könnyen le lehet szedni a netről, több valamit összerakni már gondot okozhat, és bejön még a távirányító kezelése, időzítési gondok lehetnek, villogni kezd, és könnyen beleszalad sok munkaóra a keresésbe, esetleg másik lib írása, vagy lib nélkül megírni, esetleg assembly betétekkel a sebesség miatt. Ha az ember magának csinál valamit, akkor ezek az idők nem pénzt jelentenek, hanem szórakozást. De ha pénzért megy, akkor nagyon alacsonyra tud leszaladni az órabér, ha menet közben feladja, akkor meg 0-ra.
-
gyapo11
őstag
válasz
Janos250
#3330
üzenetére
Az arduino is mikrovezérlő, csak a saját IDE-vel használva adja azt a kényelmes módot, amire ki van találva.
Szerintem aki pénzt keres ilyen mikrovezérlős modullal és a rá írt alkalmazással, az nem az arduinot választja. Mert sok esetben egyszerűbb panel is megfelel -> olcsóbb, sokszor meg kell még más hw is, sok minden van arduinohoz is, de lehetnek olyan igények, amire nincs kapható modul -> egyedi tervezés kell.
De lehet, hogy a hw-val ellentétben a sw még erősebb érv, hogy ne arduiot akarjon használni. El lehet érni a processzort, akár assemblyben is meg lehet írni a programot, de ez nem kényelmes. A legtöbben a c-t választották, az IDE nyelve nem ez. Ha meg hex kódot kell letölteni, akkor az arduino kényelmes bootloaderes megoldása nem játszik. A másik a libek. Ha valaki már kidolgozta a c függvényeit, akkor neki nem haladós a libeket megismerni. Lesz valami korlát, akkor meg kellene tanulnia libet írni vagy módosítani. Sokszor hibák is vannak a libekben, lelkes amatőrök írják. Sokszor ütköznek a libek, mert ugyanarra a pinre írták, megint tudni kell módosítani. És elég hamar el tud fogyni a memória, nem tudom, de szerintem a c tömörebb kódot generál, nagyobb program is elfér így. De ha nem, akkor könnyen át lehet állni egy nagyobb memóriás chipre, attól a programozás ugyanaz marad. Arduino esetén ott van a mega meg lehet még más nagyobb modell is, de az már nem olyan olcsó.
Szóval szerintem ezek miatt nincs az, hogy lépten-nyomon arduinora fejlesztő profikkal találkoznánk, és egy ilyen igényre, mint ez a fényvezérlés nem ugranak 10-en rá, hogy szívesen megcsinálják. Mint ahogy írtam is, egyedi fejlesztéssel, szintén mikrovezérlővel, saját sw-rel biztosan találni rá embert, de nem olcsó, mert nem tömegtermék, tehát az összes fejlesztési időt ennek az egy példánynak kell kitermelnie. -
Gergosz2
veterán
válasz
Janos250
#3330
üzenetére
"Mikrovezérlővel igen"
Az Arduino nem mikrovezérlő? (Atmel, ARM, ESP, Microchip PIC, stb. ezeken fut az Arduino kód.)Te néha visszaolvasod amiket írsz?
Az arduino egy framework az, hogy mit támogat a hivatalos fejlesztőitől és Arduino esetén nem kis mértékben a közösségtől is függ. Az arduino maga nagyon jó dolog, mert kezdésnek nagyon jó, de ha valaki valami komolyabb projectet akar végigvinni az hamar észreveszi a hiányosságit és tér át egy másik Frameworkre MCU-val együtt. -
Janos250
őstag
válasz
printpro
#3329
üzenetére
A sokféle vélemény kíváncsivá tett!
A kezem ügyében lévő cuccokból (Uno + led szalag) összeütöttem egy próbát.
Sokat nem tököltem vele, de az adott minták közül a "Ripple"-t próbáltam.
Minden gond nélkül működik.
Majd egyszer kipróbálom a többit is, de ma már hamarosan aludni fogok, holnap meg valószínűleg strand.
Majd valamikor a jövő héten.
Úgy látom, itt most az lett a jelszó, hogy ha nem elég bonyolult az életünk, akkor igyekezzünk feleslegesen elbonyolítani. Az én elvem ezzel szemben az, hogy ember segíts magadon, Isten is csak akkor segít!
A vezérlés sem egy ördöngősség. Én - mint általában - a WiFi megoldást javasolom, bár ezért többen visszaszednék rólam a keresztvizet.
A WiFi előnye szerintem (többeknek különbözik a véleménye):
1. egyszerű programozni, html lapot írsz.
2. böngészővel (Firefox, stb) kezeled, ezért paltform független, megy iPhonon, Androidon, Windowson, Linuxon, telefonon, tableten PC-n egyaránt, ami épp a használó keze ügyében van.
3. minden bizonnyal 10 év múlva is ismerni fogják a böngészők a html-t, ezért hiába jön mindenféle verzió váltás, nem avul el. -
Janos250
őstag
válasz
gyapo11
#3328
üzenetére
"Mikrovezérlővel igen"
Az Arduino nem mikrovezérlő? (Atmel, ARM, ESP, Microchip PIC, stb. ezeken fut az Arduino kód.)
"netről levadászott kódok"
Nem kell a netről vadászottat használni, írhatsz sajátot.
"általában C-ben"
Ha nem tetszik a C++ , Arduinora is írhatsz C-ben is.
"Ennek megfelelően az ára is több 10-ezer lehet egy ilyen egyedi fejlesztésnek."
Üzleti oldalához nem tudok hozzászólni.Az igaz, hogy hardverközeli program írása esetén csak azon az (általában) egyetlen kontrolleren fog hibátlanul futni, amire írtad, de egy ilyen LED vezérlés egyetlen (!) láb le-föl mozgatásából áll, megfelelő időzítéssel, de adott esetben elég nagy toleranciával. Ez nem egy egetrengető feladat.
Ketten más szemszögből nézzük a dolgokat.
-
-
gyapo11
őstag
-
gyapo11
őstag
válasz
printpro
#3324
üzenetére
Arduinoval nem tudom készít-e valaki terméket, nem arra való. Mikrovezérlővel igen, de ott nincs lib meg netről levadászott kódok, hanem 0-ről saját fejlesztés általában C-ben. Ennek megfelelően az ára is több 10-ezer lehet egy ilyen egyedi fejlesztésnek. Javaslom az teslás elektro levelezőlistát, ha nem akarsz ezért föliratkozni, akkor szívesen továbbítom a kérdést az elérhetőségeddel.
-
printpro
csendes tag
sigh, bonyolítsuk még, az arduino kód sincs a fasorban sem, és akkor még legyen egy androidos progi is, amihez szintén nem értek.
Az egész azzal indul hogy kirakatba kellett pár dekoráció CNC-vel (ehhez legalább értek) Amit sima olcsó buta ledek világítottak meg. Namost az olcsó buta led, pont olyan rossz mint amilyen olcsó. A megrendelő pedig látott pár szép animációt programozható ledre. Innentől kezdve pedig az én bajom megoldani. (mint a munka része) Úgyhogy, ha legalább arra tud valaki válaszolni, hogy hol keressek embert erre a feladatra, már az is segítség.
-
printpro
csendes tag
válasz
Teasüti
#3321
üzenetére
Jogos, végülis, van egy full windowsos tablet (desktop win 10 fut rajta) De ahhoz kell egy külön software ami kezeli. Nem tudom, van-e erre kész megoldás? Vagy külön appot kell írni rá? Nem dobná az meg a fejlesztési időt / költségeket?
Első ránézésre erre gondoltam mint lehetséges távirányító kiosztást:[link]
Igazából nem ragaszkodom infrához. .Ha jobb / egyszerűbb valami okos eszközről vezérelni legyen. Csak az tart vissza hogy mennyire bonyolítja ez meg a projectet.
-
Teasüti
nagyúr
válasz
printpro
#3320
üzenetére
Mondjuk egy telefon vagy tablet?
Távirányító nekem azért nem szimpi, mert nem tudsz paramétert átadni, csak vezérlő gombok vannak.
Igaz lehet csökkenteni meg növelni is a paramétereket a gombokkal...
De azért ebbe belegondolva szerintem annál bonyolultabb lenne a program, minél kevesebb gombot szeretnél használni és azokhoz menüt készíteni, vagy vmi state machine-t.
És itt azért nem egy szalagról van csak szó. Rögtön kettő meg még egyéb extrák is.
Ehhez elég okosan kéne megírni a távírányítást, vagy sok gomb kell. -
Teasüti
nagyúr
válasz
printpro
#3318
üzenetére
Infra feltétlen muszáj?
Bluetooth esetleg?
Amúgy rövid keresgélés után én nem látom indokoltnak a plusz hardvert a dekódoláshoz.
Olybá tűnik egyszerű, mint az 1x1.
Persze vki ügyesen megírt library-jével.A LED részével el lehet pepecselni, míg azt kapod, amit szeretnél.
Én pár hónapja foglalkozok ráérő szabadidőmben WS2812 ledsor animálásával. Rengeteg munkaóra benne van, mire egyáltalán kitaláltam mit is szeretnék és azt hogy lehet megcsinálni.
Sztem pár hét alatt össze lehet hozni, ha napi szinten foglalkozol vele. -
printpro
csendes tag
Üdvözletem,
Arduino programozóra lenne szükségem. Természetesen nem ingyen. Ez volna a feladat:
2db különálló rgb led szalagot kellene vezérelni (ws2812b) 2x 1m 60 led. (kirakat világítása)
Minden funkció külön vezérelhető legyen a két szalagon, Illetve egyben is. (pl: szalag 1 fényerő, szalag 2 fényerő, illetve mind2 szalag fényerő)Animációtól függetlenül legyen állítható:
fényerő
hueAnimációk: (source code van video leírásban)
tűz: https://www.youtube.com/watch?v=-2hk6rxlrGA
Ripple: https://www.youtube.com/watch?v=IrMzopUe8F4
Sparkle:https://www.youtube.com/watch?v=ou8_pI-8FZU
6db statikus paletta, némileg animált pixelekkel (kb mint tűz, csak pixelek színe egyenként van megadva)Irányítás:
Infra távirányítóval,Hardware: (Ha debrecen közelében vagy el tudom vinni fejlesztéshez)
2db arduino Uno (Több forum szerint 1db arduino kell az infra jel dekódolásához, ami aztán tovább küldi a jelet egy másik ardunak.)
2db 1m 60led ws2812b szalag
Olcsó ebay infra vevő / távirányító (részletek később)Namost, egyáltalán lehetséges-e ez? Ha igen, kb mennyi idő / költség lenne összehozni egy ilyen programot? Igazából, fogalmam sincs hol keressek rá embert. Az alapvető arduino ismeretek megvan, illetve elektronika részét is össze tudom rakni. Szóval nem kell feltétlenül készre szerelni. De a mélyebb programozásához nem értek.
-
gyapo11
őstag
válasz
Gergosz2
#3316
üzenetére
Nem tartom száraznak, csak ha valaki elkezdi tanulni, akkor sokára kap választ a kérdésére.
Olyan, mint ha egy közgazdasági kérdésem lenne mondjuk valami kamatról, és azt mondanák, hogy ott a könyvtár meg a net tanuld meg. Az nekem nem megy, vagyis nem találom meg a választ.
Az elektronika sem megy mindenkinek, de mint ahogy én is bánok pénzzel, van háztartási költségvetésem, úgy mások is bütykölnek elektronikát. Lehet, hogy fogalma sincs a hidegítésről, de látta valahol, hogy kell egy rövidlábú 100 nF a betápra. Tesz oda egy 100 μF-ot, és nem érti miért nem működik, hiszen ez sokkal nagyobb kapacitás, jobban kellene hidegítenie. Mire az elektronika tanulásában eljut a válaszig, az nem kevés idő. A való életben viszont könnyen találkozhat a problémával, különösen a kapcsolóüzemű tápok és mikroprocesszorok világában.
Néha egy könnyű elméleti dolgot nehéz megcsinálni a gyakorlatban, pl. szinuszgenerátor.
Néha meg egy könnyű gyakorlati megfigyelésre nehéz elméleti magyarázatot adni, pl. ciklotron.
Az elméletek mindig a rend felé húznak, hogy egyszerű képletekkel minden pontosan kijöjjön. A gyakorlat meg pont a káosz felé, véletlenek, apró eltérések, zavarjelek, amiket képletekkel nagyon nehéz leírni.
Ezért van az, hogy a szakember szavai nehezen érthetők a laikus számára, mert 1000 dologról fogalma sincs, amit a szakember beszámít, mert ismeri. Marad az, hogy tedd oda ezt a kondit és jó lesz, csak ez hal a horgászbot helyett. Holnap megint éhes lesz. -
Gergosz2
veterán
Nem értem miért tartja itt sok ember "száraznak" villamosságtan/elektronika könyveket. Legjobb tárgyaim közé sorolom a mai napig őket.
De én is azt ajánlom, hogy csak akkor nyúljon bármihez is ha kellő alapismeretekkel rendelkezik, mert ilyenkor szokott az lenni, hogy egy program minden sorára rákérdez, vagy az , hogy gondol egyet és csinál egy áramkört amivel magára gyújtja a házat.
-
gyapo11
őstag
Az ic-k, pláne a processzorok működését már nem olyan könnyű megérteni, az már kevésbé elektronika, inkább logikai egységek milliói, esetleg tranzisztorok milliárdjai. Egészen másképp kell kezelni, mnt azt az elektronikát, amiben ellenállást kell számolni. Nem is az arduino működéséről volt szó, hanem az elektonikai kapcsolásokról.
Hogy mivel akarok villogtatni ledet, az már érdekes kérdés. Sok szempont van, ár, fejlesztési idő, szükséges eszközök, ismeretek, méret, fogyasztás, későbbi változtatás módja stb. Sok esetben már egyszerűbb egy arduino szintű vezérlővel megoldani olyan feladatokat is, amik korábban még klasszikus elektronikai feladatok voltak.
De én elektronikából jöttem a processzorok felé, nekem könnyű egy powerledet meghajtani. Aki viszont a programozás felől jött, azt simán el tudom képzelni, hogy nem tud egy nullátmenetes triakvezérlést kapásból lerajzolni, és ha talál a neten egy rajzot, akkor nem érti hogy működik. Nem tud módosítani rajta.Ugyanezt láthatjuk programozással is, ezen a fórumon sok esetben megvan a forrás a netről, de módosítani kellene, és az már nem megy, mert nem érti a program működését. Mondhatjuk neki, hogy irány a net, ez gyakorlatilag semmi. Irány a könyvtár, kevés olyan ember van, aki könyveket tanul meg, hogy egy programot módosítani tudjon.
Viszont az is igaz, hogy hiába mondja meg valaki hogy mit kell módosítani, legközelebb ugyanúgy nem fogja tudni, mert nem érti.
Szóval nem egyszerű ez. -
Sokimm
senior tag
válasz
gyapo11
#3313
üzenetére
IDE->wiring->sketch->assembly->logikai értékek-elektronikai alkatrészek működése... (a felsorolás pongyola)
Hogyan villog a led? IDE szinten úgy, hogy HIGH-LOW... Elektronikai rétegben (arduino környezetben (flash-kiolvas, kódsor(IDE->assembly), cpu (regiszterek) feldolgozás, lábakon való billegtetés....eredmény:villogás) irtó sok dolog van, ha tényleg bele akar menni az ember és félek, el menne a kedve a lelkes tanulóknak.Az arduino is ezeken a lépcsőkön illeszkedik a világhoz, csak mivel bonyolultabb a vezérlés (egy 555 ic hez képest), még inkább elrettenne bárki, ha "szeretné megérteni" a működést. Ha elektronikai villogást akarunk, akkor meg kerüljük el az arduino-t, mert felesleges bonyolításnak látom a programozást (és minden megértési szükségletét). "Sima" elektronikával, vagy programozással akarok villogtatni ledet? (költői kérdés) Ez alapján mertem azt írni, hogy ne menjen senki (kezdő szintnél) az IDE alá.
Ez egy magánvélemény, no offens. A hibás felsorolásokért felelősséget vállalok!
-
#3312
gyapo11
őstag
FireKeeper
#3307
gyapo11
őstag
válasz
FireKeeper
#3307
üzenetére
Pontosabban nem is itt, ez a fórum nem az alapok megbeszélésére szolgál. Az arduino önmagában sok mindent nem tud megcsinálni, tehát kell valamennyi elektronika hozzá, de hogy egy monostabil multivibrátor hogy működik, az már offtopic itt.
-
#3311
tvamos
nagyúr
FireKeeper
#3304
tvamos
nagyúr
válasz
FireKeeper
#3304
üzenetére
---
-
Sokimm
senior tag
válasz
gyapo11
#3306
üzenetére
"De aki érteni is szeretné..."
Ki ne szeretné? Viszont az Arduino IDE felépítése alá ne nagyon menjen senki (regisztercímzés, inculde fájlok tartalma, sketch), mert beleborzad... (elsőre). Osztom a véleményed azon részét, hogy pár ezer forint füstölés hasznos(abb) lehet, HA:
-tudjuk mért füstölt el... Elektronikai alapok? Kicsit több annál, mivel az alkatrészek működése (felfutó élek, tüskék, túlfutások, hibatűrő határok) elég komplex, tekintettel, hogy millió egyféle cucc van a piacon.Konkrétan amikor kérdeztem az elektronika labor tanáromat, (tételezzük fel, hogy életemben először fogtam akkor kondenzátort), hogy mik ezek a számok a kondin, akkor azt mondta: "nézd meg neten..."
Aztán amikor láttam, hogy van kerek, lapos, kerámia, fém, műanyag, vastag, kicsi, sok lábú, két lábú, stb stb kondi, elment az étvágyam... Érteni? Képtelenség szerintem, ha nincs egy (és itt megint igazat adok neked) segítőkész szakember mögötted, aki terelget... A net sokszor hasznos (PWM diagramm, tranzisztorkapitány, stb), sőt túlmutatnak a tanári lehetőségeken (mivel 80 oldalról közelítik meg az értelmezést), de sokszor meg nagyok a hézagok...
(pl: volt egy léptetőmotorom, ami 1.4A 1.7V on üzemelt (egy tekercs tartása), és ugye ez alapján egy 2.38W közeli tápot kerestem... Volt itthon egy, ami hasonló (+-0.05) teljesítményű, de tök más amper/volt arányú... Mért nem használhattam vele? A net nem segített annó, egy türelmes ember többet jelentett volna...
)Egy szó mint száz: Ez nem "szeretné-nem szeretné" kérdése... Vannak dolgok, amiket nagyon meg kell érteni (alapok), és vannak dolgok, amiket nem kell ahhoz, hogy kimondhassuk: "elég ha működik". A kérdést mindenki magában válaszolja meg... Az alapok 70%-t a netről le lehet szívni, de a maradék 30%-ot szerintem csak egy szakemberrel. Márpedig az a 30% hiány pont elég, hogy ne tudd magadtól megépíteni a kívánt áramköröd. (ötlet megvan, kreativitás megvan, gyakorló füstölésre szánt ellenállások megvannak, de miért füstöl?) (buta példa, elismerem...)
-
#3307
FireKeeper
nagyúr
gyapo11
#3306
FireKeeper
nagyúr
válasz
gyapo11
#3306
üzenetére
illetve ha itt épp nem kap választ a kolléga, akkor érdemes benézni a Hobby elektronika topikba is.
-
gyapo11
őstag
válasz
ghostie
#3305
üzenetére
A kész modulok összedugdosása, lib és forrás letöltése gyorsan ad sikerélményt, de nem érteni belőle semmit. Ez sok embernek elég, működik a cucc, OK.
De aki érteni is szeretné, hogy miért kell oda ez vagy az az alkatrész, és miért pont az, annak más út kell.
Lehet a könyvekkel kezdeni, lassú, sok időt és kitartást igénylő, száraz.
Lehet szimulátorprogrammal, virtuális műszereket figyelni, ez már jobb, olcsó és sokkal élvezetesebb, meg lehet ismerni az alkatrészek működését, határait. De kicsit olyan, mint papíron tanulni a programozást számítógép helyett.
Ha van rá valakinek 1-2 ezer Ft-ja, akkor füstöljön el pár ellenállást, tranzisztort, nyomozza ki, hogy miért történt, ezzel sokkal többet tanul közben. A Rádiótechnika cikkeiben sok magyarázat van, hogy hogy működik az áramkör, az évkönyvekben rengeteg hasznos kapcsolás, ami ötletet is adhat és elég könnyű összeforrasztani. Olyat kell keresni, ami még diszkrét alkatrészekből készült. Exponáló óra, féklámpa villogtató, feszültségvezérelt oszcillátor, szinuszgenerátor, ezekre még emlékszem hogy csináltam.
Én is így kezdtem, utána szétszedtem az áramköröket, mert nem volt pénzem több alkatrészre, a végén már szinte ismertem mindegyiket.
De a legjobb lenne találni valakit, aki ismeri az elektronikát, és van ideje magyarázni (személyesen), ez a leggyorsabb és legkönnyebb tanulás.
És persze vannak a fórumok, mint ez is, ahol lehet kérdezgetni, de nem mindig jön válasz, nem mindig olyan, amilyet szeretnénk, és sokszor többféle nem teljesen egyező is lehet, ami zavaró. -
#3304
FireKeeper
nagyúr
Janos250
#3303
FireKeeper
nagyúr
válasz
Janos250
#3303
üzenetére
valóban, az arduinonál, meg úgy általában kommersz elektronikában elég sok dolog ilyen "tapasztalati" alapon megy, meg "hát ez volt írva az application note-ba". a kolléga előismereteire csak azért kérdeztem rá, mert azért szép és jó, hogy ez így van, lehet tanulgatni, de néhány nagyon alap elméleti dologgal nem árt rendelkezni, teszem azt Ohm-törvény, csomóponti törvények, vagy akár ilyen úri huncutságok, mint váltakozó áramú rendszerek. persze nyilván nem a Maxwell egyenleteknek kell nekiesni rögtön.
én amondó lennék, legyen akármilyen uncsi/száraz, meg kéne próbálni néhány egyetemi alapozó tárgy jegyzeteit letölteni valahonnan a netről. pl BME-s jelek és rendszerek 1-2, elektronika 1-2. már így hirtelen pár év távlatából nem emlékszem pontosan, hogy az ezekhez a tárgyakhoz készült segédanyagok mennyire emészthetők és használhatók, illetve azt látatlanban garantálom hogy lesz bennük felesleges bullsh*t, de emellett egy csomó hasznos ismeret is.
-
Janos250
őstag
válasz
ghostie
#3300
üzenetére
Én Sokimm válaszához csatlakozom. Az Arduino egy lego, amit csinálni kell. A neten rengeteg példa van, szinte mindenre. Ha led és ellenállás van benne, akkor azt is odaírják, hogy mekkora ellenállást tegyél oda. Majd, ha már sok mindent megcsináltál, közben megtanulod, hogyan számold ki azt az ellenállást.
Fiatal koromban, amikor elkezdtem elektronikával foglalkozni, megkérdeztem egy villanymérnök kollégát, hogy a Z80-as panel egyik TTL IC-jéhez mekkora hidegítő kondit tegyek. Hát, az nem olyan egyszerű, azt meg kell méretezni, mondta. Aztán láttam, hogy az ő paneljaira hasonló helyre mindenhova 100nF kondit tesz. Megkérdeztem, miért? Ekkorát szoktunk, mondta. Utána én is olyat tettem.
Ha arra vártam volna, hogy megméretezze nekem, ma sem tartanék sehol. Az Arduinoban az a jó, hogy akár alapismeretek nélkül is lehet kezdeni, és az ismereteket közben bővíteni. Ha csak az elektronikai alapismeretekkel kezded, egy idő után megunod és abbahagyod. Tapasztalatból tudom, hogy 15-20 óra alatt pl. el lehet jutni elektronikai alapismeretekkel nem rendelkező srácokkal oda, hogy a saját mobiltelefonjukról kapcsolják ki-be az ESP8266-hoz kötött ledet (vagy készülék fűtést).
Ez persze az én szubjektív véleményem és tapasztalatom, nem akarom cáfolni az ellenkező véleményen állókat. Mindenkinek saját magának kell döntenie. -
lappy
őstag
válasz
ghostie
#3300
üzenetére
Szia!
Én amit tudok neked tanácsolni léteznek nagyon jó szimulációs programok amiken lehet sok alap elektronikai kapcsolást összerakni mindenféle veszély nélkül. Sőt van olyan amiben arduino is van és sok kiegészítőt lehet mellé tenni. Ennek az előnye hogy nem kell eszköz, hátránya hogy nem mindig úgy működik a valóságban. De alapnak kezdésnek szerintem jó. Érdemes ezzel kezdeni ha nem ismered az elektronokat -
Sokimm
senior tag
válasz
ghostie
#3300
üzenetére
Jogos a meglátásod, hogy mélyebbre szeretnél menni (jómagam is ez irányba törekszem), de tartom magam ahhoz a véleményemhez, hogy arduniozni nem kell elektronikai tudás. A neten (vagy középiskolás tankönyvekben) van egy képlet, kiszámolod mekkora ellenállás kell a led elé (nem kell nagyon tudni miért kell, csak így működik), és megy a móka. Ha mélyebbre akarsz menni (áramkörtervezés, 555ic, időzítők, stb), akkor meg amúgy is felesleges az arduino.
(értsd jól, a ló másik végét ragadtam meg )A kettő együtt, túl nagy falat. Mondok példát: Szétszedtem egy kínai ledes övet, aminek kíváncsi voltam, milyen elektronikai háttere volt. Van benne egy atmel eeprom, amit egy felirat mentes ic hajt meg, és 3 nyomógomb. Nah akkor most (arduino vs elektronika) menjek tovább? Ha arduinozni akarok, az eeprom használatát megnézem más hogy csinálja a neten, és máris külső memóriaként tudom használni ezt az atmel ic-t (az arduinomhoz). Ha elektronikailag akarok tovább menni, akkor a határ (áramköri szinten lefele), a csillagos ég.
Tehát az arduino-hoz nem feltétlen kell bármilyen npn-pnp tranyókkal szenvedni, csak ha van rá lelki erőd. Ez esetben pedig a pdf-je tényleg többet mond minden próbálkozásnál (nyitófesz, átviteli értékek), aztán ha használni akarod a tranyót (veszel egyet, amit már datasheet szinten ismersz, és beépíed a dugdosós panelba, amihez nem kell arduinó, csak táp...)
Szerintem a kettő nem olyan szoros családtag (elektronika-arduino) mint amennyire annak látszik (a programozása sem regiszterszinten megy (assembly), hanem egy "butított" felsőbb nyelv, amit a fordító szépen átdolgoz... Buta egy jószág (egy bizonyos belépő szintig) az arduino (ezért szeretem annyira), de az analóg elektronikai rész, a nyúl végtelen ürege (az arduino-hoz képest). A véleményem teljesen szubjektív, nem kell vele egyetérteni.
Elnézést, ha nem tudtam tanácsot adni, hogy hol vegyél KIT-et, nem láttam ilyet még sehol.
Há Móóónika! Megyek dolgom van! 
)
Új hozzászólás Aktív témák
Hirdetés
ekkold- Tőzsde és gazdaság
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Kerékpárosok, bringások ide!
- 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
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- 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
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
- Telefon felvásárlás!! Apple Watch SE/Apple Watch SE 2 (2022)
- BESZÁMÍTÁS! 32GB (2x16) G.Skill Trident Z RGB 6600MHz DDR5 memória garanciával hibátlan működéssel
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest