- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Garmin topik
- Külföldi SIM-ek itthon
- Azonnali mobilos kérdések órája
- One mobilszolgáltatások
- CMF Phone 2 Pro - a százezer forintos kérdés
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Netfone
- Mobil flották
- Xiaomi 15 - kicsi telefon nagy energiával
-
Mobilarena
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
-
Tankblock
aktív tag
válasz
Teasüti
#8520
üzenetére
Aha,
W2813 a W2812 helyett?? [link]
Én még mindig felfűzném 2v4 pl index kört egybe. Praktikusabbnak tűnik a kód is lehet egyszerűbb is. PL vészvillogó megoldása 1 állapotgéppel.....
remélem gondoltál a biztonságra is, HW & SW watchdog mindenképpen legyen, én ugyanazt a kódot is futtatnáma 2 külön magon és nézném h ugyanazt számolják-e......
Mire kell a RF (Wifi, BT) része?a másik vége h ez nem legális.....
-
-
tvamos
nagyúr
válasz
Teasüti
#8480
üzenetére
Nalunk a szomszed gyerek folyton errol beszel. Valmi mBlock-ot tanulnak, de rohadjak meg, ha meg olyat is veszek feleslegesen. Ebben van bluetooth is, ha jol latom. Enyem viszont egyaltalan nem erdekli. A HC-06-ot 30 sec bekotni, azt a fiam is megcsinalta, sot egyutt irtunk olyan progit, ami a HC-06-rol jovo karaktereket visszakuldi soroson. Hogy oruljek... es bekenhagyjam xboxozni.
Mondjuk azota javultak a Google skilljei... szoval megerte nyegtetni. -
ZTE_luky
aktív tag
válasz
Teasüti
#8463
üzenetére
köszi a választ!
a kontroller okés ,lecheckoltam, haha emlékszel rám ez nem a végleges táp, úgy találtam itthon, de képzeld azt a rendszert kipróbáltam a mobiltöltővel és szuperül működik. uhh jó h mondod, erre odafigyelek, akkor nem használom, portról is simán elég hogy rájöjjek a mikrofon titkára igazából csak próbálgatok egy hangvezérlést végre összehozni, hogy mire kész lesz az a rács test, futhasson rajta több animáció is, és hát na őszintén elég király lenne egy hangvezérelt kis rendszert elecsempészni, és mire nekiállo ka szerkezetnek tudjam hogy mikrofont vagy egy jackportot is forrasszak bele, egy másik outra és akkro lehet feltöltögetni mást is a boardra -
Teasüti
nagyúr
válasz
Teasüti
#8448
üzenetére
Közben kikerestem a partíciós táblát, meg a boards.txt-t.
Nos, eléggé benéztem azt a 131 KB-ot, egy nulla lemaradt a végéről.
Vagyis nem hogy megvan a tárhely, de még jócskán több is, mint volt annó.
A programom foglal egy nagyságrenddel több helyet, mint korábban.
Na most ezt nem értem hogy, de mindegy.szerk: oké, emlékeim mégis csak csalnak.
A BT könyvtár eszi meg a program tárhely nagy részét, a BLE több mint 1 MB!!!
Viszont most nézem, hogy implementálva van a Classic Bluetooth az Arduino Core-ban!
Végre működik a bluetooth serial mindenféle hack nélkül!
És kevesebb helyet is foglal, az alapértelmezett partíció 75%-át foglalja csak el.
-
válasz
Teasüti
#8394
üzenetére
Röviden: gyakorlat.
Láttátok korábbi hozzászólásaimban a szenvedésemet, az 56 LED-es szalag nem megfelelő működéséről.
Vettem egy step-down áramkört, hátha azzal megjavul, de ugyanez volt a helyzet.Egy külföldi fórumon (már meg nem mondom melyiken) egy srác is küzdött és ott javasolták neki, hogy tegyen vékonyabb vezetéket és egy ellenállást a kontroller és a szalag közé. Én is így tettem, és hirtelen minden megjavult, csak annyi LED világít amennyi kell, és úgy ahogy azt a forráskódban leírtam.
Most azzal küzdök, hogy a wifi-re felcsatlakoztattam az eszközt, csináltam rá egy webszervert, hogy ki és be tudjam kapcsolni. (igazából ez csak teszt, mert a színeket akarom csak variálni wifi-n keresztül) De valamiért 2 LED folyamatosan világít a szalagon. Talán az lehet a gond, hogy a webszerver és a LED vezérlést is ugyanaz a CPU mag csinálja és emiatt az időzítések/órajelek megcsúsznak a szalagon, legalábbis ezt olvastam. Szét kell választanom, hogy külön CPU feleljen a vezérlésért, vagy a led vezérlésnek kell úgy emlékszem DMA-t engedélyezni. Ez utóbbit viszont nem tud az AdafruitNeopixel library, csak a FastLED, ami viszont nem támogatott ESP32-őn. (Rövid távon valószínűleg jobban jártam volna egy sima Arduino-val, mert arra minden van.)
-
gyapo11
őstag
válasz
Teasüti
#8276
üzenetére
Nagyobb valószínűségűnek gondolod a bedugáskori tönkremenetelt mint a folyamatos üzemben elfáradást? Még ha így is van, bedugva megvan a tűz esélye, kihúzva nincs. Ha akkor durran el amikor éppen bedugom, akkor ott vagyok akcióra készen. Ha otthagyom bedugva, akkor nincs esélyem intézkedni, ha gond van.
És sajnos sok hírt láttunk már, hogy alvó emberek megfulladnak, nem ébrednek föl füsttől, gáztól. -
válasz
Teasüti
#8221
üzenetére
Kipróbáltam a kapcsolást.
Bekötöttem egy 2200mikrós kondit,és annyi változott, hogy ha hozzáérek az LM1084 hűtőbordájához, akkor nem változik meg a ledek színe.Ha az ellenállást is bekötöm, akkor nem kapcsolnak be a ledek.
Ha a forráskódban 10 db a ledek mennyisége, akkor az első és a tizenegyedik zölden világít a többi narancssárga.
Az segít, ha linekelek egy fényképet a ledszalagról?
Janos250 : megcsináltam, beletettem a kódba az interuptos rész is, de nincs változás. 10 db címzek, 11 világít, első és utolsó zöld.
-
Tankblock
aktív tag
válasz
Teasüti
#8236
üzenetére
Open source ....
Pont ez a szituáció minden ilyenteljesen megírt könyvtárral.Általános megoldás, és nem használja ki feltétlen a microcontroller képességeit, figyelmen kívül hagyja HW részeket. Az ESP32 ebből a szempontból kilóg a sorból, máshol nem nagyon van több mint 1 mag és HW megoldások egy csomó mindenbe beépítve. Nem AVR ahol örülsz h van 3 timer meg HWes PWM aztán nagyából minden kötött a pinekhez.....
Inkább a magam által írt / nevezzük a nevén: kotyvasztott kódot szeretem. Olvasni kell a példákat/ HW leírásokat és a ide leírását, esetenként a GitHubon nézelődni és tanulni a kész kódokból - Youtube is ide tartozhat..... Sokkal több mindent ki lehet így hozni az eszközeinkből.....
-
válasz
Teasüti
#8225
üzenetére
Láttam ezt a cikket, de azt hittem ez csak Arduinora vonatkozik. ESP32-nél nem láttam ilyen megoldásokat.
De egy nagyobb kondit (asszem 1500-as van itthon) akkor még bekötök. Tegnap este én is erre jutottam, csak még a kivitelezést nem tudtam megcsinálni.JozsBiker: igen, próbáltam 400kHz-en is, de nincs változás.
Kb 13 éve (még a fősulin) programoztam utoljára C-ben (Akkor egész jól ment, addig amíg be nem kavartak az objetumokkal). Ismerős környezet amibe kódolni kell, de soha nem tanultam kontrollert programozni. Ezt most kb 1 hónapja találtam ki, így nekem egyelőre bőven megfelel a gyári csili-vili könyvtárak használata. Majd ha már legalább a saját kódom parancsait érteni fogom, akkor hanyagolom a gyári könyvtárakat, de egyelőre azon küzdök a hardver és a szoftver úgy működjön ahogy azt szeretném, és egy 10 soros kódot nem 2 heti guglizással kelljen összeraknom.
-
Janos250
őstag
válasz
Teasüti
#8228
üzenetére
UNO-nál nem tudom.
ESP32-n én így oldottam meg:
A union nem tartozik a lényegéhez, de nem volt most kedvem átberhelni, csak bekopiztam.typedef union konv {
uint64_t v64bit = 0 ;
struct {
uint32_t low32bit ;
uint32_t hi32bit ;
} s32bit;
struct {
uint16_t low32bit_low16bit ;
uint16_t low32bit_hi16bit ;
uint16_t hi32bit_low16bit ;
uint16_t hi32bit_hi16bit ;
} s16bit;
uint8_t v8bit[8];
};
uint64_t getCycleCount64() {
static uint32_t CycleCount32 = 0 ;
static konv CycleCount64 ;
static uint32_t ccount;
__asm__ __volatile__("esync; rsr %0,ccount":"=a" (ccount));
CycleCount32 = ccount ;
if (CycleCount64.s32bit.low32bit > CycleCount32 ) {
CycleCount64.s32bit.hi32bit++ ;
};
CycleCount64.s32bit.low32bit = CycleCount32 ;
return CycleCount64.v64bit ;
} ; -
tibi-d
tag
válasz
Teasüti
#8211
üzenetére
A PIR-ek működési elvüknél fogva lassúak. Ezek hőtömeget érzékelnek. Ha egy ember elhalad előtte, az néhány másodpercig tart. Ezt folyamatosan érzi. Ha már nincs előtte a hőtömeg, kikapcsol. Lehet kapni "Függöny" lencsét az érzékelők elé, ez kb. 20-50cm-re szűkíti az érzékelési tartományt. Egy próbát megér.
-
tibi-d
tag
válasz
Teasüti
#8186
üzenetére
Szervusz!
Én egy századmásodperces stoppert készítettem két fénysorompóval. Az érzékelők tükörreflexiós lézerrel működtek. Ha az egyik érzékelő lézerét megszakították, akkor elindult a stopper, ha a másik lézert szakították meg, akkor megállt. Mivel strapabíró, megbizható érzékelés kellett, a lézerek ipari kivitelüek voltak. Ebből következik, hogy a projekt legdrágább komponensei voltak. -
_q
addikt
válasz
Teasüti
#8061
üzenetére
I2C megfelelő konfigurálására és a címzésre kell figyelni, illetve utána kéne nézni a távolsággal kapcsolatban, hogy mekkorát támogat. Nekem úgy rémlik 10 cm körül mint az SPI, ha 1 métereset szeretnél akkor szerintem kelleni fog közbeiktatva pár ellenállás, hog meg legyen a jelszint az utolsó szenzornál is. Gondolom "kicsi távon kezdenéd tesztelni". Nézd meg 10cm vagy kisebb vezetékkel 2 eszközzel, ha az megy próbáld meg mekkora vezetéknél működik még. Majd bővítsd tovább a bus-t. Ha 3v3 minden eszköz akkor nem hiszem hogy kell védelem, ha nagyobb feszültségen dolgozik valamelyik eszköz akkor kell valamilyen galvanikus leválasztás.
(#8063) Janos250
Tök jó, viszont ez ha jól értem csak érdekesség képpen készül, nem azért mert csak így tudsz megvalósítani valamit?Update:
Pár találat alapján vannak I2C buffer IC-k, lehet ilyen fog kelleni neked, mert sima ellenállásokkal nem lesz meg a jelszint 1 méteren. -
Janos250
őstag
válasz
Teasüti
#8053
üzenetére
Köszi, ezek C++ kiírások, csak azt nem tudtam, hova megy. Úgy látszik, hogy ha megnyitjuk a Serial-t, akkor oda. Ez azért továbbra sem tiszta, hogy tudom máshova áttenni, meg ilyesmik.
Így viszont a Serial ablakba ír://#include <stdio.h>
#include <iostream>
using namespace std;void setup() {
Serial.begin(115200) ;
delay(2000);
cout << "proba kiiras ";
std::cout << std::endl;
uint8_t i = 5 ;
std::cout << "i: " ;
// std::cout << i ;
std::cout << std::endl;
cout << "proba kiiras2 ";
std::cout << std::endl;
}void loop() {
} -
-
Janos250
őstag
válasz
Teasüti
#8016
üzenetére
"A másik érdekes dolog meg a ledek sorba fűzése lesz. Mondjuk nem fizikailag, hanem leprogramozni a random helyeken lévő pixelek animációját"
Azt megoldotta, beszámozta a ledeket a feltett rajzán, és ha hullámot akar, akkor az jó, egyetlen jelvezetékről lehet meghajtani mindhárom ágat.Kiváncsiságból belenéztem a FABled dolgaiba. Annak a használata valóban egyszerű.
-
-
-
Janos250
őstag
válasz
Teasüti
#7970
üzenetére
Ezekkel a megoldásokkal itt foglalkoznak sokan:
https://prohardver.hu/tema/okos_otthon_smart_home/friss.html
Ami a 32-n megy, az - ha nincsenek benne túl extrém dolgok, pl. RMT - akkor a 8266-on is megy. A wifi kezelés ugyanaz. Ezeknél az okosotthonos megoldásoknál általában kell valami központi szerver, ami vagy helyben mondjuk egy PI, vagy valami távoli. Én azt várnám, hogy valaki csinálja már meg a MOSQUITTO megfelelőjét ESP32-re. -
válasz
Teasüti
#7832
üzenetére
ÁÁÁ, köszi, igen, ezt benéztem. Bocsi.
ESP8266 - ez a wifi modul, futtat egy http szervert a színbeállításokhoz
Arduino Uno - ő vezérli a ledeket:
- a szín beállításokat az ESP8266 kapja
- fényerőt nyomogombokkal állítomSzalagonként 3 db IRL540N (mert ezt találtam a hestore.hu-n) pedig a ledeket hajtja.
A ledszalag pedig WS2812. Ha jól értelmeztem, akkor ezt led chipenként lehet címezni, nekem biztos hogy kell ez?1 led szaleg megy az asztal aljára, 1 az asztallap széléhez a fal mellé vagy a monitor mögé, 1 pedig asztali lámpa és headset tartó (plexiből hajtogatott izébigyó) megvilágítása lesz. (bár ha nagyon belejövök csinálok egy infinity mirror kreációt is egy negyedik szalagból, ugyanerről az arduino-ról)
Egyébként csak azért akarok Arduino-t mert látszólag nagyon népszerű most és sok leírás van hozzá. Az ESP32-ről nem tudom még micsoda.
A v-tac céget ajánlotta nekem a kollégám. Ezt néztem ki náluk, de a kép szerinte nem jó a leírás meg nem tartalmazza, hogy milyen a cucc:
[link] -
gyapo11
őstag
válasz
Teasüti
#7824
üzenetére
Egyszer keresgéltem szimulátorokat, találtam is ezt-azt, de mélyebben nem mentem bele:
http://emulare.sourceforge.net/
https://blocklyduino.github.io/BlocklyDuino/blockly/apps/blocklyduino/
https://www.sites.google.com/site/unoardusim/services
http://virtronics.com.au/Simulator-for-Arduino.html -
-
Janos250
őstag
válasz
Teasüti
#7805
üzenetére
"Hogy mi? Ezt most látom először.
Akkor ezért nem működik egy csomó RTOS parancs?
Itt is vmi jogosultsági rendszer van? Meg kell szerezni a root jogot, vagy mi a szösz?"
Csak a WDT regiszter írásához kell a jelszó, de azt a rendszer elvileg csinálja.
Tehát a hardver WDT etetése a leírás szerint így működik:#define TIMG_WDT_WKEY_VALUE 0x50D83AA1 // ez a "jelszó"
TIMERG0.wdt_wprotect=TIMG_WDT_WKEY_VALUE;
TIMERG0.wdt_feed=1;
TIMERG0.wdt_wprotect=0;Az esp_task_wdt_feed() meg az esp_task_wdt.h ban van, kifejtve meg a libesp32.a-ban, vagyis nem tudjuk, hogyan működik.
"Ezt a scheduler-t a mai napig nem értem."
Én sem!
Néztem régebben szkóppal: 1 millisec-enként szakít meg - ha nem fut a magon tőlem semmi - akkor kb 3 microsecre. Valamit az alatt a 3 alatt csinál, de nem tudom mit. A millist biztosan növelgeti szoftverből -
Tankblock
aktív tag
válasz
Teasüti
#7805
üzenetére
Hello
Low priority numbers denote low priority tasks. The idle task has priority zero (tskIDLE_PRIORITY).
Nincs Root jog, csak szerintem az van, hogy ha nem hagyjuk a schedulert futni a magon akkor a watchdog feltételezi, hogy valami nem működik jól és resetel....
Gondolom az is közrejátszik még, hogy 2 magon fut a FreeRTOS-t meg 1 magra találták ki... Ezért nincs minden funkcionalítása leimplementálva. (Mi van olyankor ha az egyit task az egyik magon a másik magon lévő tasktól függ pl....)
Lehet szép SW watchdogot írni akár állapotgépre is... pl minden task lefutott-e adott időn belül, ha nem akkor még mindig eldönthetem h reset vagy figyelmen kívül hagyom az egészet....
-
Janos250
őstag
válasz
Teasüti
#7779
üzenetére
Egy kis kiegészítés az ESP32 soros portjaihoz:
Van UART0, UART1,UART2
Mindháromnak van RXD,TXD,CTS,RTS, de DSR és DTR csak az UART0-nak. Én eddig még csak az RXD,TXD-t használtam.
Az ESP periféria kezelése kétféleképp történik:
1. "GPIO matrix":
Ezzel bármelyik periféria kapcsolható bármelyik lábhoz, egy un. GPIO matrixon keresztül. Ezt úgy kell elképzelni, mint pl. a klaviatúra mátrixát.
Tehát a mátrixnak vannak sorai, ami a perifériák jelei. Vannak oszlopai, ami a 34 láb ("GPIO pad"), amik sajnos nem folytonos számozásúak: (0-19, 21-23, 25-27, 32-39).
Ha a megfelelő jel és a láb (pad) kereszteződésébe teszel egy pöttyöt, akkor a jel és a láb hardveresen össze lesz kapcsolva.
2. "IO_MUX":
Ezzel 5 gyors jel (Ethernet, SDIO, SPI, JTAG, UART) közvetlenül (bypass) kapcsolható a lábakhoz, de itt előre definiált, hogy melyik jel melyik lábhoz kapcsolódik.
Ez gyors, mert elkerüli (bypass) a GPIO matrixot.Mi következik nekünk ebből az UARTokra vonatkozóan?
Ha az UARTok példányosításánal nem adunk meg lábat, akkor a gyors bypass szerinti láb rendelődik hozzá az alábbiak szerint:
U0TXD -> GPIO1
U0RXD -> GPIO3U1TXD -> GPI010
U1RXD -> GPIO9U2TXD -> GPI017
U2RXD -> GPI016
Ezzel a következő a bajunk:
A mai lapokon az ESP-WROOM-32 fémházas hibrid áramkör van (ne is vegyen senki meg olyat, amin nem ez van), tartalmazza többek között az ESP32-t és plusz memóriát.
Ennek a plusz memóriának a címzéséhez használja többek között a GPIO9-et, és a GPIO10-et.
Ezért az UART1 soros portot más lábakra kell rakni, a másik kettő meg maradhat a hardveres kiosztáson.
Ezért kell megadni a soros1-hez a felhasználni kívánt lábakat:
pl: Serial1.begin(57600, SERIAL_8N1, Serial1_RXPIN, Serial1_TXPIN) ; -
Janos250
őstag
válasz
Teasüti
#7779
üzenetére
Ja, értem.
A panelon persze van USB, az a sima serial.
Most sietnem kell, de gyorsan kerestem egy régebbi programomból egy részletet, amit bemásolok.#define Serial1_RXPIN 26
#define Serial1_TXPIN 27HardwareSerial Serial1(1);
HardwareSerial Serial2(2);void setup() {
pinMode(Serial1_RXPIN,INPUT_PULLUP);
pinMode(Serial1_TXPIN,OUTPUT);
Serial.begin(115200) ; // TX0, RX0
Serial1.begin(57600, SERIAL_8N1, Serial1_RXPIN, Serial1_TXPIN) ;
Serial2.begin(57600); // pin 16=RX2, pin 17=TX2pinMode(2, OUTPUT) ; // BUILTIN_LED = 2
while (! Serial);
while (! Serial1);
while (! Serial2);
delay(500);loopban ilyesmik vannak:
while (!Serial1.available()) {} ;
xA1 = Serial1.read() ;
Serial2.print("A1 hex = ") ; Serial2.printf("%02X",xA1) ; Serial2.println() ;Ez meg az info soros portra megy (nálam debug jelleggel):
Serial.println("megvan A0, A1") ; -
csubuka
addikt
válasz
Teasüti
#7714
üzenetére
Köszi! Sajnos nem nagyon találtam ilyen relé-félét.
Hmm, végülis az is lehetséges igen. Azért gondoltam erre a CT-re mert akkor nem kell belenyálni a kábelezésbe. Azt szerettem volna elkerülni.Van B megoldás amúgy. A vezérlőbox egy piros LED-et felvilant, ha éppen rákapcsolja az áramot a fűtőeszközre. Akár azt a LED-et is figyelhetném. Bár ugye az nem közvetlen bizonyítéka, hogy valóban folyik ott áram, hanem a vezérlőboxon belül a kapcsolás ismeretének hiányában nem tudom épp mitől függ közvetlenül a felkapcsolása. Tehát ennek a LED-nek a felkapcsolt állapotját kéne figyelni és abból lehetne a fogyasztásra következtetni.
-
csubuka
addikt
válasz
Teasüti
#7712
üzenetére
A ki-be kapcsolgatást egy automatika végzi, TRIAC-al, nullátmenetnél kapcsol le, hogy minimális kihatása legyen a hálózatra. Szóval azt nem nekem kell intézni. Nekem csak azt kell nézni, hogy megy-e éppen.
A mechnaikus eszközöket kihagynám inkább. De a relé az akkor kellene amúgy ha én akarnám kikapcsolni, nem monitorozni az állapotát, nem?
-
gyapo11
őstag
válasz
Teasüti
#7701
üzenetére
A kettős szigetelésű cuccoknak galvanikusan nincs köze a 230-as hálózathoz. Ezért lehet fogdosni a róla táplált eszközöket vizes kövön mezítláb áramütés nélkül.
Egy mérendő áramkör, ami ilyen tápról megy, meg a notebook, amin a szkóp van szintén, akkor össze kell kötni a két gnd-t, hogy mérni lehessen. Amikor a szkópzsinór test csipeszét rácsíptetjük valamire, akkor ez történik, a szkóp földje és a mérendő áramkör földje összekötődik.
Ha régebbi számítógépen lenne a szkóp, amibe 3 eres földelt vezeték megy, akkor annak adott a földje. Ezt meg azért lehet fogdosni, mert a földelő vezeték a vizes kővel azonos potenciálon van.
Ha az áramkör is földelt tápból kapná a delejt, és össze van kötve az elektronika testje a táp földjével, akkor már minden OK, lehet mérni, mert a testpontok közös potenciálon vannak, a ház (mint épület és mint tápegységek és számítógép háza) földjén. Ilyenkor elvileg nem is kellene szkóp test zsinórját használni, de persze zavarjelek miatt ilyenkor is kell. -
brickm
őstag
válasz
Teasüti
#7701
üzenetére
NEm igazán értem a kérdést, de egy közös potenciálnak lenni kell mindenképp, hiszen ahhoz képest állapítható meg az összes többi.
HA egy konvertered vagy MCU-d nincs letéve testre, mint "referencia" akkor ahhoz képest a kiemenete sem lesz sehol. (vagyis de, de nyilván mérés szempontjából nem)Ha konkrétabbat tudnál róla mondani egyszerűbb lenne megválaszolni.,
Egyébként megcsinálod a kötést és egy GND ponthoz képest mérj feszültséget ahol épp kérdéses, hogy kell e kötni GND-t vagy sem. -
Janos250
őstag
válasz
Teasüti
#7622
üzenetére
Nálam általában nem volt jeltorzulás. Az utána következő ledek jól működtek.
Egy szalagnál úgy tűnt, hogy egy hullámot "elnyelt", így az utána következők színe torzult aszerint.
Ha a bit utáni részt elég hosszúra vettem (pl. 2 microsec periódusidő), akkor egyáltalán nem tapasztaltam hibát. 6-7 microsec periódusidőig jól mentek, afölött viszont resetelt, tehát csak az első led világított valamit. -
gyapo11
őstag
válasz
Teasüti
#7574
üzenetére
Ki van találva. Kb. úgy néz ki, hogy a gép exponál, indítja a vakut, méri a fényt (integrálja), és amikor elég, akkor szól a vakunak, hogy fejezze be a villanást. Kb. ezt csinálja az ún. tirisztoros automata vaku is, csak nem az objektíven át méri a fényt, hanem a vakun levő szenzorral. Objektíven át mérni persze sokkal jobb, szűrőt beleméri, az objektívre beállított blendét is.
Az eggyel gyengébb rendszer meg elővillant egy gyengébbet, ezzel megméri a szükséges fényt, ezt beállítja a vakun és pár ms késéssel exponál. Mivel a villanócsöves vaku 1-2 ms alatt elvillan, a gépek meg 5 ms körüli időt tudnak exponálni teljesen nyitott zárlemezekkel, a vaku mindig gyorsabb mint a gép, tehát nem az expozíció hossza számít, hanem hogy a vaku mennyi fényt nyom ki.
A ledes témánál más a helyzet, az folyamatos fény, gyengébb, ezért akkor jó, ha a téma mozdulatlan, és akkor meg nem a led világítási idejével szabályoznak, hanem a záridővel. Jellemzően makróra jó, virág, étel stb. -
gyapo11
őstag
válasz
Teasüti
#7570
üzenetére
Erősebb hw nyilván jobb. De lehet az arduino is elég, nem tudom, talán írni kellene egy kis programocskát, és mérni az egyes stringek beolvasásának idejét, de nincs rádiós modulom. Azt sem tudom, hogy az egyes rádiós modulokon mennyi idő alatt megy át a string. A rádióhullámok fénysebességgel mennek, ezzel nincs gond, és talán elég primitív az elektronikájuk ahhoz, hogy gyors legyen.
Az arduinonak polloznia kell, legalábbis én ilyen megoldásról tudok, ez a ledvillogtatásnál még 0.007 ms ciklusidővel ment neki, de ki tudja milyen kód van a rádiós modulról olvasásnál és írásnál. Meg kell mérni. -
távcsőves
senior tag
válasz
Teasüti
#7570
üzenetére
Az átvivő közeg gyorsasága inkább számít szerintem. Ezt talán wifi kapcsolaton oldanám meg. Amíg a vezérlés paramétereit és a modell fényt használja, nem kritikus az idő. Expo esetén viszont nagyon az, de ha előre megkapta a vakuvezérlő a villanás paramétereit, akkor szerintem belefér egy vezérlőbájt vétele/feldolgozása/pin állapot változása néhány mikró másodpercbe. Azt viszont nem tudom, hogy működik a váz fénymérése, mennyi időt hagy a között, hogy elküldi a vakunak az értékeket és expot végrehajtja.
-
Janos250
őstag
válasz
Teasüti
#7546
üzenetére
"Ezt olvastad?" Mostmár igen
Kösz.
Egyébként a helyzet az, hogy mivel itt vannak már az olcsó, gyors, viszonylag sok memóriával rendelkező kontrollerek, én egyszerűen nem akarok már AVR-el foglalkozni. Annak idején számos rutint sok munkával megcsináltam Z80-ra, és elöntött a hú milyen jó érzése. Viszont pár év múlva jöttek a jobb procik, és a sok munka egyszerűen hamuvá vált. Ennek tapasztalatai alapján nem nagyon akarom már nyakatekert megoldásokkal kissé feljebb tornászni a proci teljesítményét, inkább használok jobbat. Most pl. ESP32-t, mint rajtam kívül még sokan mások.A leírt időzítéses dolgok viszont tanulságosak, érdemes elolvasni!
Azt, hogy az 1 bitet meddig szabad magasan tartani, ki fogom próbálni, mert ez érdekes. Mivel nekem semmi konkrét célom nincs ezekkel a ledekkel, csak játszom velük, így azokat a dolgokat próbálom ki, ami számomra érdekes, szórakoztató.
Más:
Mondjátok, Ti honnan a csudából tudjátok egy kínai led szalagról, hogy az most éppen melyik típus? Ráírva semmi info nincs erről, a kis kínai meg felsorolja majdnem az összes típust, hogy keresésnél minél többen megtalálják.
Én egyszerűen játszottam az időzítésekkel, hogy mi válik be legjobban, de fogalmam sincs, hogy éppen melyik típus van a kezemben. -
Janos250
őstag
válasz
Teasüti
#7523
üzenetére
"Ha szerencsés vagy, akkor üzembiztos lesz. Ha nem, akkor sorra jönnek elő a pixelhibák aktív használat közben"
Van valakinek pixelhibás led szalagja? Ki tudná próbálni, hogy ha a 0 bit hosszát lényegesen lecsökkenti (mondjuk 0.25, vagy 0.2 microsecre), nem szűnik-e meg a hiba? Két szalagot próbáltam, az egyikben egy, a másikban két olyan pixel volt, ami gyakran hibázott egy idő után. Levittem a 0 bit hosszát, és megszűnt a pixelhiba. -
Janos250
őstag
válasz
Teasüti
#7523
üzenetére
Mivel nem ismertem a WS2813-at, rákerestem.
"250us or more of reset time, it won’t cause wrong reset while interruption, it work on the lower frequency and inexpensive MCU."
Ez egy fontos szempont lehet, ha nem akar az ember nyűglődni az interrupt letiltásával. Próbára rendelek is egyet!Smart home:
Vannak már rá példák. Én is ki akarom próbálni, de még nem jutottam odáig. Pl. Sonoff cuccok jól illeszthetők. -
vargalex
félisten
válasz
Teasüti
#7523
üzenetére
A ws2813-at a pixelhibák miatt javaslod (ugye itt csak a hibás led nem fog működni, a mögötte lévőket nem befolyásolja)?
Elsőre egy hyperion-t (ambilight) próbálnék ki. Ehhez 60 led/m szalagot javasolnál, vagy kevesebbet?
Illetve lehet, hogy a gyerekeknek valami ébresztő napfelkelte "szimulátort" csinálok majd. -
pigster
senior tag
válasz
Teasüti
#7494
üzenetére
a 3,3V úgy van, ahogy meg van írva, 1kOhm és 2kOhm ellenállással, multiméterrel megmértem, 3,3V van a lábon.
A program:#include <SoftwareSerial.h>
SoftwareSerial mySerial(10,11); // RX, TX
char betu;
const int LEDPIN = 2;
void setup() {
pinMode(LEDPIN, OUTPUT);
Serial.begin (9600);
mySerial.begin (115200);
}
void loop() {
if (mySerial.available()){
betu = mySerial.read();
Serial.print("betu: ");
Serial.println(betu);
}
if (betu == '1'){
digitalWrite(LEDPIN, HIGH);
}
else{
digitalWrite(LEDPIN, LOW);
}
delay(100);
}Amint írtam, tegnapelőtt teljesen jól ment, most meg behülyült.
-
Janos250
őstag
válasz
Teasüti
#7485
üzenetére
Nem könyvtárat írok hozzá, csak játszom vele, próbálgatom. Változtatgattam az időzítéseket, hogy mire hogyan reagál. Először azt hittem, hogy a Saleae8-as dobta fel a talpát és badarságot mér, de egy másik példánnyal is ugyanezt adta. Akkor az a ritka eset következett be, hogy a Saleae8-as helyett elővettem a 16-ost, de azzal is ugyanazokat a pulzus időket adta. Mivel nem RMT-vel csináltam, 0.18 microsec volt a legrövidebb idő, amit be tudtam állítani, de azzal még stabilan ment. Majd megpróbálom RMT-vel rövidebb idővel is. A netes 0.35 -nél az egyik szalagon egy led, a másikon kettő nagyon gyakran hibázott. 0.3-nál már kevesebbet, 0.25-nél meg teljesen stabil minden led. 0.4-nél baromságokat csinál.
-
fpeter84
senior tag
válasz
Teasüti
#7455
üzenetére
és @vargalex
Azért utána matekozva, normál esetben nem tűnik akkora problémának... 3.3V-os környezetben ha pl egy 10K normál és 10K NTC alkot feszosztót, akkor amikor alsó szélső értéken van az NTC akkor is csak 0.33mA folyik, vagyis úgy 1.1mW fűti. Problémává max akkor válhat, ha autós 12-14V-os környezetben egy 1K+1K NTC dolgozik, mert az már egészen számottevő 0.2W-ot fűtene el, de ha felvesszük az értékét annak is 20-100K-ra akkor az is elhanyagolható tartományba esik... Tehát tervezői "hibát" kell véteni ahhoz hogy problémát okozzon a dolog...
@vargalex
A doksija szerint a standby current max 1uA, viszont utána sehol nem találom részletezését hogy hogyan kell standby-ba tenni... Vagy csak annyi hogyha nem kérdezel tőle akkor alszik és gyakorlatilag nulla készenléti árammal várakozik?
-
-
-
ngabor2
nagyúr
válasz
Teasüti
#7406
üzenetére
Mivel (még) nincs topikgazda, ezért biztos, hogy nem lesz kirúgás
Viszont az ötlet jó, amennyiben érez valaki elég lelki erőt és időt erre a feladatra. Sőt, téma összefoglalót is lehetne gyártani, de ehhez én már régóta kicsi vagyok.gyapo11: kicsit kiegészítve jó lesz, köszi
vargalex: van lehetőség kulcsszavak megadására, most már pl. az ESP-32-re, vagy az mcu-ra is megtalálja a topikot. -
Janos250
őstag
válasz
Teasüti
#7383
üzenetére
"Példánál maradva:"
Ha ugyanabból a
hardware\espressif\esp32\cores\esp32\esp32-hal-gpio.c
fájlból a pinMode-ot idézed, még szembetűnőbb a dolog. A 77. sortól a 165-ig tart!
Na, ezekért választom én is az Arduinot. Persze azért fél szemmel lesem azt is, hogy freeRTOS-ben mi van mögötte, illetve, hogy a freeRTOS mögött mi van regiszter szinten. -
Tankblock
aktív tag
válasz
Teasüti
#7383
üzenetére
Hello,
Akkor én felvállalom hogy több mint 1 van ebben az értelemben.
Arduino defacto programozási nyelv --> azaz szépen eltünteti a felhasználó elöl hogy mit is használ, aztán meg ha véletlenül 2 könyvtár ugyanazt az erőforrást használja akkor jön a probléma.
Ugyanaz mint amikor a WS2812 könyvtár RMT használja, meg mondjuk lehetne még használni IR adó vevőnek ugyanezt az erőforrást mert 8 csatornája van ha jól emlékszem,
Én ezért fogtam bele az ESP-IDF be és igen nincs minden dokumentálva, és néha nagyot lehet mellényúlni.
A másik oldalról, meg a fejlesztők ESP-IDF c++ kompatibilis és eclipse alatt lehet c++ is programozni. Akár Arduinos könyvtárat is behúzni / átírni....Vagy csak kevés időmben is mazoista vagyok...
Nem szólnám le ezt sem. Ez mellett szeretem az Arduino-t. Szeretem, hogy kész dolgokat kell csak összerakni és fut. Ezzel spórolhatok időt és az összes ESP8266 home automation erre épül.
Mindegyiknek megvan a szépsége.
-
_q
addikt
válasz
Teasüti
#7383
üzenetére
Köszi a részletes leírást. Tetszett a fogalmazási stílus, 1-2 mondaton jól felmosolyogtam, természetesen jó értelemben
és tudtam azonosulni azzal amiket írtál.STM32-t, TI launchpadokkal van kevéske tapasztalatom, de azt látom, hogy egyre jobban jönnek fel a mindent függvénnyel, illetve arduino módszerrel (nem tudom ennek mi a pontos neve, tehát hogy ne kelljen mély C tudás, említett példa: digitalRead() ) programozzunk lehetőségek és nekem ez tetszik is. Vannak területek ahol fontos a minél kisebb kód, és optimalizált megoldás, de a mikrovezérlők teljesítmény növekedésével egyre kevésbé fontos, így szerencsére mindenki meg tudja találni a maga számára elegendő C tudást igénylő kontrollert. Emellett STM32-t se zárom ki, nekem az is tetszett, de most kicsit az arduino jellegű programozás foglalkoztat.
Egy a nehéz, projektet kitaláljak magamnak ami hasznos is, esetleg kicsit tanulni is lehetne belőle, de még is nem annyira nehéz, hogy fogjam a fejem, hogy most ez mi Erre neten szerencsére vannak ötletek.Szóval még egyszer köszi, maradok a topicnál, sok jó dolgot lehet is olvasni és jó látni, hogy sok a segítőkész fórumtárs
-
-
Tankblock
aktív tag
válasz
Teasüti
#7329
üzenetére
Hello,
Tasknál, ha van a végén vTaskDelete( xHandle ); és megfelelően magasra állítod a priorítását akkor nem tudod megölni sem...
ha csak meghívod 1000x akkor el fog fogyni a stack / memória akkor a xTaskCreate() fvg visszatér egy szép hibával:
errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY
Értem, így pont nem használod ki a HW képességeit. Ha az RTM használod erre akkor nem kellene delayel szórakozni....
Egy Queue ba bedobálni a mintákat az meg a RTM rakja a mintát.....
Bár nem ismerem a feladat részleteit.....
így már érthető a kevés gpio. Egyébként miért ezt a tervezőt használod?
a kontroller okés ,lecheckoltam, haha emlékszel rám 
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Remek áron Lenovo Flex 5 14 laptop/2in1/Touch/Ryzen i5-1135G7/8GB/512 GB SSD/14"/Gari
- Exclusive ajánlat! Dobozos új LG GRAM /13. gen i7-1360P/32GB RAM/512GB SSD/14"COL/FHD+/IPS/Garancia/
- Pénztárcakímélő áron eladó HP Pavilion laptop/I5-1135G7 8GB 256SSD 13" FHD IPS Gari
- Samsung Galaxy Book 3 /i5-1335u/8GB/512SSD/FHD/Garancia/ 6 napot ment eddig összesen
- Xiaomi Redmi Note 14 Pro Plus 12/512GB Újszerű,Dobozos,Kétkártyás 1év Garanciával!
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RX 9070 16GB GAMER PC termékbeszámítással
- Iphone 15 Plus 128GB Pink Dobozos 12 Hónap Garancia
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- Samsung Galaxy S25 Ultra 1TB, Kártyafüggetlen, 1 Év Garanciával
- Turbózd fel géped a jövő RAM-jával!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest