- Yettel topik
- Magyarított Android alkalmazások
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- iPhone topik
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Google Pixel topik
- Bemutatkozott a Poco X7 és X7 Pro
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
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 #7312 üzenetére
Hello,
Ha jól emlékszem, akkor külön task ID fog kapni és fog párhuzamosan futni n-szer is.
Amit leírtál az tervezést igényel.
SW megoldásként : a megszakításban kellene viszgálni, hogy mikor volt utoljára meghívva az interupt és ha az idő megfelelően nagy csak akkor végigfuttatni a megszakítás logikáját.
Vagy
Perlmentesíteni HW esen,
Delay miért kell? nem lehet másképpen megoldani? pl Queue v xEventGroup (ez nem tudom, h implementálva van-e ESP32 FreeRTOS ra.) Vagy Taskot suspendedbe tenni és felkelteni amikor kell....
-
Janos250
őstag
válasz
Teasüti #7320 üzenetére
Nem a számolással van gond, mert mint írtam rá az assembly sort, azzal le lehet kérdezni a számlálót, ami egy másodperc alatt 240 milliószor lép, tehát igen nagy felbontású. Ez az utasítás behelyezhető egy C++ programba egy utasításként, tehát kényelmes magas szintű nyelven is.
-
Janos250
őstag
válasz
Teasüti #7315 üzenetére
Na, de ha pl. egy 500 nanos jelet akarsz kiküldeni kézzel, akkor beállítod a pint 1-re, aztán figyeled az időt és 500 nano múlva átteszed 0-ba, de lehet, hogy közben megszakít, és akkor az már nem 500 nano lesz! Mivel gyors a proci, ezért menne így, kézzel is, ha biztosan nem lenne szaggatás. Elvileg persze le lehet tiltani a megszakítást, de hiába tiltottam le, akkor is közbejön néha egy pici szaggatás. Próbáltam az egyéb taskokat is leállítani, de nem jártam sikerrel. Tehát, ha valamire NAGYON GYORSAN kell válaszolnod, az nem biztos, hogy nagyon gyors lesz. Tudom, persze, használjunk RTM-et, PWM-et, vagy interruptot, de a kíváncsiság hajtott.
Elvileg "until"-os időzítés is van, de nekem azzal se jött össze. A priorításokat is hiába variáltam, gyakorlatilag mindegy volt, hogy 1-es, vagy 24-es (25 a max) volt. Még jó, hogy csak kíváncsiságból játszogattam vele, nem éles dologban.
-
Janos250
őstag
válasz
Teasüti #7312 üzenetére
Hát, ezt éppen nem próbáltam. Elég érdekes ez a két mag, több task rendszer. Azért pár dolgot leírok, nem Neked, hanem azoknak, akik még most kezdik. Automatikusan a core1-re megy a loop. Azt úgy lehet áttenni a core0-ra, ha megkeressük a main programot, és átírjuk benne 0-ra. Megy, bár lehetnek gondok, pl. mindkét magnak - úgy tűnik - külön számlálója van, ezért vigyázni kell az időzítésekkel. A számlálót ezzel lehet olvasni:
__asm__ __volatile__("esync; rsr %0,ccount":"=a" (CycleCount32));
Ez 240 MHz-el jár, de csak 32 bites, ezért tizen.. másodpercenként átfordul. Én csináltam hozza egy 64-bitest, az már az unokám életében sem fog átfordulni. Viszont, mivel gyors, finom időzítéseket lehet vele csinálni. Elvileg. Ugyanis hiába próbálunk mindent átrakni a core1-ről a 0-ra, akkor is szaggat valami. Talán a saját szoftver számlálója, amit az xTaskGetTickCount()-al lehet olvasni. A 240 MHz-es számlálót írni lehet, de ne írd, mert megbolondul az időzítés. Hogy pontosan mi hol fut, azt nem lehet tudni, mert a vTaskList nem működik. Meg a statisztika sem. A taskok számát le lehet kérdezni, de nem sokra mentem vele, hogy tudom, hogy nálam 7 task van, amiből háromról tudom, hogy mi, a többiről nem. A taskról információt akkor lehet lekérni, ha tudjuk a "nevét". Na, ezt nem tudjuk. Az IRAM-ba rakással is vigyázni kell, mert amit oda pakolunk, csak az egyik magon futtatható. Na, így egy szuszra ennyit.
Egyébként, ha a specialitásait nem akarja kihasználni az emberfia, akkor nagyon jó kis proci, ajánlom mindenkinek. Két mag, gyors, multitasking, de hiába freeRTOS, nem igazán RT (real time), a már említett okok miatt. Előbb-utóbb csak megoldja valaki, hogy a core1-en ne legyen szaggatás, de ezt még a neten is keresik.
Ha mondjuk egy UNO-n futó programot teszünk rá, akkor természetesen ilyen gondok nincsenek, csak annyit tapasztalunk, hogy megy mint a szélvész. Ajánlom is mindenkinek, hiszen alig drágább mint egy kínai UNO, az eredeti UNO árából meg féltucatot vehetünk.
Neked:
Kíváncsiságból megnéztem az RTM kezelést, de csak megnéztem, mert elég macerásnak tűnik első látásra, pedig nagyon jó lenne. Berakja az ember egy külön memória területre az adatokat (1 bit, hogy hi vagy low, és 15 bit a hossz, az időzítés), és utána elindítja, és a hardver sorra veszi ezeket a 16 bites (32= 2*16) adatsorokat és öntevékenyen kiküldi a "PWM" jelet.
Az eredeti kérdésedhez: a static változókra mindenképpen vigyázz, mert az közös! -
Janos250
őstag
válasz
Teasüti #7278 üzenetére
A Saleae tudja azt, már többször ajánlottuk:
https://www.ebay.com/itm/24MHz-8CH-USB-Logic-Analyzer-8-Channel-Logic-Analyzer-Compatible-to-Saleae/162134953459?hash=item25bfff0df3:g:Jz0AAOSwh2xYBDu5 -
dzz
aktív tag
válasz
Teasüti #7257 üzenetére
Nem értelek félre, hanem azt értem bele, hogy egyéb célokból van egy AP-m ami kezeli a fényképezőm (bár nem is tudom mikor használtam legutóbb), így még esetleg ezt hozzá csapni nem lehetetlen. Bár a legjobb lenne egy olyan eszköz ami beilleszthető a meglévő rendszerbe (mondjuk vakupapucsba) és onnantól el is lehetne felejteni a különböző rendszereket
Na jó, nem álmodozom
Ha megérkezett és eljutok valameddig, jelentkezem és minden bizonnyal érdeklődöm tovább.
-
Teasüti
nagyúr
válasz
Teasüti #7268 üzenetére
Mi a dolga ebben egy mikrovezérlőnek?
Mihez kell itt számítási kapacitás?
(A kérdésedből amúgy látszik, hogy helyre kellene tenni a mikrovezérlő definicióját is.)Ez egy analóg rendszer, esetleg van benne egy DAC is, ha van optika rajta.
Megkapja a bemeneten a hangot, azt erősíti, majd meghajtja a hangszóró(ka)t.
Van rajta egy analóg hangerőszabályzás, meg van benne egy tápegység.Ha ez tönkrement, akkor garancia, szerviz, vagy kuka.
Ezt a szerepet nem fogja betölteni egy mikrovezérlő.
Ellenben lehet kapni külön DIY erősítő modulokat, ha át akarod alakítani.
(Viszont ezt én nem ajánlanám a témában való jártasságodat figyelembe véve. Esetleg a Hobbi elektronika nevű topikban kérnék segítséget, hátha van egy hozzáértő a közeledben, aki elvállalná a javítást, vagy átalakítást. Már ha ér annyit egyáltalán az eszköz.) -
Janos250
őstag
válasz
Teasüti #7249 üzenetére
az esp32-hal-gpio.h-ban találod:
//GPIO FUNCTIONS
#define INPUT 0x01
#define OUTPUT 0x02
#define PULLUP 0x04
#define INPUT_PULLUP 0x05
#define PULLDOWN 0x08
#define INPUT_PULLDOWN 0x09
#define OPEN_DRAIN 0x10
#define OUTPUT_OPEN_DRAIN 0x12
#define SPECIAL 0xF0
#define FUNCTION_1 0x00
#define FUNCTION_2 0x20
#define FUNCTION_3 0x40
#define FUNCTION_4 0x60
#define FUNCTION_5 0x80
#define FUNCTION_6 0xA0
#define ANALOG 0xC0Látszik, hogy melyik bit mit jelent.
Ezt hogy lehetett volna úgy bevinni, hogy ne csússzanak el?
-
dzz
aktív tag
válasz
Teasüti #7255 üzenetére
A real-time nem feltétel, 1-2-3 másodperc sem számít, főleg ha állandó a késleltetés. Az AP-re gondoltam én is, kb. 100 méter körüli videóátvitelt már sikerült két telefon között létrehozni és egy AP segíthet megnövelni a távot. Most kezdésnek a technikai oldalt próbálom ki ha megérkezik a modul, aztán meglátjuk mennyire van szükség a többire.
-
válasz
Teasüti #7216 üzenetére
Köszönöm. Tegnap odáig jutottam, hogy letöröltem már mindent, a git-et, arduinót, pythont.Visszatettem telepítettem újra az Arduinót, meg amit linkeltél, illetve letöltöttem azt a zip-et amit a git szedne le. Látszik is az eszközök között az esp32, de nem képes rá feltenni a lefordított programot: exec: "C:\\Users\\viktor\\Documents\\Arduino\\hardware\\espressif\\esp32/tools/esptool.exe": file does not exist Hiba a(z) DOIT ESP32 DEVKIT V1 alaplapra fordításra. A get.exe nem csinál semmit, pedig admin joggal indítom. Már azt a zip fájlt is letöltöttem amit elvileg a get.exe töltene le, de abban nincs esptool.exe.
A lényeg akkor annyi lenne, hogy a C:/Users/[YOUR_USER_NAME]/Documents/Arduino/hardware/espressif/esp32 könyvtár megvan, itt le kéne futnia a get exe-nek, ami látszólag nem csinál semmit... Bár tegnap előtt mintha már lefutott volna egyszer 50 perc után, de akkor a program files mappa arduino könyvtárában volt az egész hóbelevanc. Az erőforrás kezelő szerint 35kb/s-mal tölt valamit, egyszer remélhetőleg kész lesz. Legalább valami tájlkoztató üzenetet kiírhatna, hogy dolgozik vagy hány %-nál tart...
A wemos d1 r2-vel is ennyi szívás lesz? -
Janos250
őstag
válasz
Teasüti #7208 üzenetére
"történt már veletek, hogy a watchdog reboot-ol, mert nincs etetve a Core 0-n?"
Igen :-(
Én megkerültem a problémát: A loopból hívom meg a taskot újra és újra, és amikor a task elvégezte a dolgát, kilép [vTaskDelete(NULL)].
Még nem igazán sikerült tisztán látnom kutya ügyében. Mindjárt az első, hogy ők hányan vannak: minden Core-nak, vagy minden tasknak van egy-egy? Aztán, hogy hogyan lehet törölni?
"Én eddig azt hittem az RTOS fel is tudja függeszteni az adott folyamatot, hogy cpu időt adjon a többi folyamatnak."
Én is azt hittem, de ez se igazán így van. Továbbá én korábban azt hittem, hogy a core1-en nincs megszaggatás, ott mehetnek a realtime dolgok. Na, ez se így van: ott is van interrupt.
Ezt írják:
"Also make sure you disable interrupt watchdog on CPU1 when not using RTOS" "(Also disable the tick interrupt app watchdog, as Ivan said, otherwise it'll complain.)" "A OS-Environment on CPU0,
and pure "undisturbed" power on CPU1."
Na, de ezt hogyan csinálom Arduino alatt? A szokásos Arduinos módszer még - úgy tűnik - nincs implementálva :-(
A PCNT_ENTER_CRITICAL használatában is vannak homályos dolgok. És még számos egyéb is."Amúgy nem gáz, hogy ezeket itt tárgyaljuk ki? Engem nem zavar, de nem tudom azoknak zavaró-e, akik a vanilla Arduino-n dolgoznak."
Miért nem? Szerintem azért, mert előbb-utóbb mások is áttérnek korszerűbb procikra az Arduino alatt, és így látják, mire térjenek át: ESP8266, ESP32, STM, stb.
Pl. ha én nem olvastam volna ezt a topicot, nem érdekelt volna a WS2812 led szalag. Azért kezdtem el kiváncsiskodni, mert itt olvastam. Vagy pl. Te se biztos, hogy ESP32-t használnál, ha nem olvastad volna ezt a topicot. Nekünk már volt belőle hasznunk. Reméljük másnak is.
Egyébként a topicnak van egy gazdája, ha nem akarja, hogy ilyesmiről itt szó essen, majd szól, hogy húzzunk el külön el topicba. Én így gondolom. -
Janos250
őstag
válasz
Teasüti #7191 üzenetére
Ugye nem a másik topicban tárgyalt áthallásos problémát akarod szoftveresen megoldani? Mert az nem fog menni! Ez az átka a nagy energiatakarékosságnak, hogy olyan pici áramok mennek, hogy akár a Kossuth rádió is bezavar. Muszáj ellenállással mesterségesen megterhelni. Én a soros átvitelnél tapasztaltam ugyanezt: kb 20 centis vezeték a két IC között, és a csomagok 10-20 százaléka CRC hibásan érkezett.
Mit akarsz variálni?
"Az ESP32-n a HardwareSerial.cpp fájlba kell belenyúlnod. (hardware\espressif\esp32\cores\esp32)"
"int HardwareSerial::read(void)
{
if(available()) {akarmi =uartRead(_uart);
Itt megcsinálod amit akarsz
return itt meg adod neki ami jó Neked!
}
return -1;
}"Az szerintem nem lesz egy ördöngősség! Egyszerűen az uartRead(_uart); rész után csinálsz valamit, nem azonnal adod a returnnek.
-
Janos250
őstag
válasz
Teasüti #7188 üzenetére
Mélyrehatóan nem, de valami:
Az ESP32-n a HardwareSerial.cpp fájlba kell belenyúlnod. (hardware\espressif\esp32\cores\esp32)
A Stream osztály virtuális függvényként megadja, hogy minden gyerekének (pl az egyes processzorok serialjei) kötelezően miket kell tartalmaznia,
ezzel nagyjából biztosít egy bizonyos kompatibilitást.
(class HardwareSerial: public Stream)int HardwareSerial::read(void)
{
if(available()) {
return uartRead(_uart);
}
return -1;
}}
size_t HardwareSerial::write(uint8_t c)
{
uartWrite(_uart, c);
return 1;
}Mint látható, használják az esp32-hal-uart.c fájlból az uartRead-et az meg a hardware\espressif\esp32\tools\sdk\lib\xQueueReceive.a assembly fájl tartalmát.
Érdemes még egy pillantást vetni a HardwareSerial.cpp fájl include-ok utáni első sorára: HardwareSerial Serial(0);
Itt példányosítja előre a mi beavatkozásunk nélkül "Serial" néven a 0-ás UART-hoz kapcsolva. Ezért nem kell őt nekünk példányosítani. -
Janos250
őstag
válasz
Teasüti #7140 üzenetére
Elnézve a macerát, kezd az az érzésem támadni, hogy igaza volt annak, aki megírta "gyalog" módszerrel a WS2812 RGB led szalag programozását az ESP32-re, mert az legalább egyszerű, és működik. Mivel nagy a sebesség, és van 2 mag, nem szorít az idő, hogy hardware alapon kezeljük a szalagot, bár kétségkívül az a szebb, ezért meg kellene próbálni, valami egyszerűbb, áttekinthetőbb megoldást találni rá.
-
Teasüti
nagyúr
válasz
Teasüti #7139 üzenetére
Hmm úgy néz ki itt vmi típushiba van, ahol ezt alkalmazni szerettem volna.
Más helyen aSTRANDS[i].numPixels
szintaktika működik.
Viszont változó deklarációnál nem veszi be:byte buffer1[(int)STRANDS[0].numPixels * 3] = {};
Erre dobja a hibát:
array bound is not an integer constant before ']' token -
-
-
Tankblock
aktív tag
válasz
Teasüti #7124 üzenetére
Muszáj, mert W2812b protokolja így néz ki:
https://cpldcpu.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/
szóval azokat RGB koordinátákat egy időbeni eltolásos protokollá kell traszferálni. A Remote Kontroll struktúrája pedig addr0 level [31] period [30:16], level [15], period [14:0] ábrázoással kell tárolni.
level bit 0v1
period hossza amíg ki kell tartani....ezt kombinálva 1 bitet 32 biten kell tárolni W2812b protokollja végett.
-
Tankblock
aktív tag
válasz
Teasüti #7122 üzenetére
Hello,
Ha jól értelmezem a kódot, akkor a
Ebben a structban csak a pixelek színkódjait tárolja:
pState->buf_data[0 + i * 3] = pStrand->pixels[i].g;
pState->buf_data[1 + i * 3] = pStrand->pixels[i].r;
pState->buf_data[2 + i * 3] = pStrand->pixels[i].b;Majd a library ban a
static void copyToRmtBlock_half(strand_t * pStrand);
másolja be a átváltás után HW memóriába:
RMTMEM.chan[pStrand->rmtChannel].data32[data32_idx].val = pState->pulsePairMap[bitval].val;
majd ezt frissíti az interruptban, ahogy kiküldte ameit kell.
-
Tankblock
aktív tag
válasz
Teasüti #7120 üzenetére
Hello,
Csak azért vannak a pointerek, mert a 8 csatornát másként teljesen általánosan kezelni nem egyszerű.
A mit miértért, meg javaslom, hogy nézd meg a esp32_technical_reference_manual_en -t. 14.2.1 RMT arcitecture elmagyarázza a HW működést a Remote Controller Peripheral nak. -
-
Janos250
őstag
válasz
Teasüti #7112 üzenetére
Nem okozol gondot.
Igen, az a deklaráció. Egy vektor, aminek minden eleme egy struktúra, ami tartalmazza az adott led paramétereit.
A pStrand az egy strand_t* típusú pointer:class Scannerer {
private:
strand_t * pStrand;strand_t STRANDS[] : a STRANDS[] egy vektor, aminek minden eleme strand_t típusú.
A strand_t egy struktúra, ezért adod meg neki így a kezdőértékeket, pl.: .rmtChannel = 1typedef struct {
int rmtChannel;
int gpioNum;
int ledType;
int brightLimit;
int numPixels;
pixelColor_t * pixels;
void * _stateVars;
} strand_t;tehát tartalmazza az adott ledsor paramétereit (esp32_digital_led_lib.h).
A ledType pedig ezek közül valamelyik:
enum led_types {
LED_WS2812_V1,
LED_WS2812B_V1,
LED_WS2812B_V2,
LED_WS2812B_V3,
LED_WS2813_V1,
LED_WS2813_V2,
LED_WS2813_V3,
LED_SK6812_V1,
LED_SK6812W_V1,
}; -
Janos250
őstag
válasz
Teasüti #7110 üzenetére
Hú, nehezet kérdeztél!
Én annak idején csak betöltöttem az elején pár demót, lefuttattam, hogy működnek-e, részletesebben nem foglalkoztam vele.Megnéztem ezt a demót és a libraryt.
A demó meglehetősen el van bonyolítva, de nem tűnik túlzottan vészesnek a library használata.
Persze, lehet, hogy a gyakorlat mást mutat. Majd megpróbálok valami nagyon egyszerű programocskát írni a használatára, de most azzal szívok, hogy az ESP32 mellé tettem a dobozba a kapcsoló üzemű táp panelt, és rendszeresen megbolondul, építhetem át.Persze, ha valaki már használta ezt a libraryt, akkor közösen várjuk az instrukciókat.
-
Janos250
őstag
válasz
Teasüti #7092 üzenetére
"ugyanazt a hardvert használja mindkét funkció?"
Nem tudom, nálam a WiFis dolgokat végzik.Én a flash frequencyt nem állítottam - gondolom - az a flash memória elérését szabályozza.
Én a CPU sebességét se állítottam, úgy tűnt, hogy 240-en megy.
Melegedés:
Nekem picit langyos. -
Janos250
őstag
válasz
Teasüti #7090 üzenetére
Téglásítani szerintem nem lehet.
Sebesség:
Nekem a 921600-on minden második harmadik feltöltés ki szokott akadni, ezért én
115200-on programozom, bár így tovább tart.
Nekem jelenleg a Node32S típus van beállítva, de használtam már Doit-ra állítva is.
Nem tapasztaltam lényegi különbséget. Ott nincs Flash Mode választási lehetőség.
Én a feltöltéseknél a "Q" (négyszeres) módot nem szoktam semmilyen lapnál használni, mindig csak a
"D" (dupla) módot használom, tulajdonképpen nem is tudom, melyik lapnál lehet, és melyiknél nemNéhány megjegyzés Neked is, és azoknak, akik ezután kezdik használni:
Az első teendők egyike: azonosítani kell, hogy a mi panelunkon melyik láb melyik GPIO, mert a panelokon többféleképpen van feliratozva.
Az ESP32 chipnek 34 GPIO lába van: (0-19, 21-23, 25-27, 32-39), de az Espressif ESP-WROOM-32 tokozásban a GPIO6, GPIO7, GPIO8, GPIO9, GPIO10, GPIO11 ki van ugyan vezetve a 17-22 lábakra, de nem használható, mert az a memóriát kezeli.
A panelok ezeket a lábakat általában nem is vezetik tüskére.
Mivel az 1-es soros port alapból a GPIO9, GPIO10 –et használja, ezért ezeket át kell irányítani, ha az 1-es soros portot használni akarjuk.
Pl.:
#define Serial1_RXPIN 26
#define Serial1_TXPIN 27
pinMode(Serial1_RXPIN,INPUT_PULLUP);
Serial1.begin(115200, SERIAL_8N1, Serial1_RXPIN, Serial1_TXPIN) ;A Serial2-t használat előtt példányosítani is kell , a Serial-t, Serial1-et nem, azok előre példányosítva vannak, mint pl. az UNO-nál a Serial.
Egy kis plusz infó:
esp32-hal-gpio.h:
//GPIO FUNCTIONS
#define INPUT 0x0100000001
#define OUTPUT 0x0200000010
#define PULLUP 0x0400000100
#define INPUT_PULLUP 0x0500000101
#define PULLDOWN 0x0800001000
#define INPUT_PULLDOWN 0x0900001001
#define OPEN_DRAIN 0x1000010000
#define OUTPUT_OPEN_DRAIN 0x1200010010
innen látható, melyik bit mit jelenttypedef enum {
WIFI_MODE_NULL = 0, /**< null mode */
WIFI_MODE_STA, /**< WiFi station mode */
WIFI_MODE_AP, /**< WiFi soft-AP mode */
WIFI_MODE_APSTA, /**< WiFi station + soft-AP mode */
WIFI_MODE_MAX
} wifi_mode_t;Melegedést én nem néztem, de ma még megnézem.
-
Teasüti
nagyúr
válasz
Teasüti #7088 üzenetére
A gombok bolondbiztossá tételéhez meg: a fenti kódomban a várakozás után a piros gombhoz tartozó változónak hamis értéket kell adni valamint nullázni a számlálót. Így nem fog azonnal vágni, hisz mindkét feltételt hamisnak állítottuk be, tökmindegy mi történt míg szünetelt.
Fordított esetben meg a nyissz megtörténte után fog csak szünetelni, szóval az úgy korrekt.Ui: mondjuk ezért nem használok gombhoz megszakítást... Van amikor nem akarunk tudomást venni egy gombnyomásról. Mint itt amíg szünetel a gép.
-
Tankblock
aktív tag
válasz
Teasüti #7069 üzenetére
Hello,
Én élvezem, hogy végre eclipse alatt tudok fordítani, és nem az Arduino IDE-be vagyok korlátozva. C nyelvet sem mostanság használtam, és van lehetőség C++ is.
Nem vagyunk egyformák, nekem a Win10 egy csalódás, és kacsingatok az új Ubuntu 17.10 után.
A dokumentáció hiányosságai okoznak fejfájást. Nem minden működik a leírtak szerint az ESP-IDF ben. Van még rajta mit csiszolni.
Az interrupt kezelést kellene megtanulnom, pont ez az ami idegesít, mert a leírtakból pont nem lehet megcsinálni amit szerettem volna --> ledc fade végén interruptban visszafele fadelni szeretném A technikai sheet szerint az összes channel tud a végén interruptot. A HW képességei lenyűgözőek. A tudásom meg igen kevés.
Feltűnö h az Arduino ideben írt villogtatás 65% lassabb --> túl nagy az overhead.
ESP-IDF ben ezek mennek eddig :
RTOS Task kezelés, Queue, Semaphore/Mutex - > binary semaphoret értem , de nem használtam
i2c scannert sikerül már írnom.
Led villogtatás is megy.
MQTT-re üzenet küldés. igaz ez kész library-t használva.
Most küzdök a ledc -vel.Lehet kellene egy ESP32 ESP-IDF topic, hogy ezt ne offoljuk szét.
-
Tankblock
aktív tag
válasz
Teasüti #7067 üzenetére
Hello,
Ez engem is érdekelne, amúgy se szeretném használi tovább az arduinot, és egy kicsit programozni.
Eddig csak annyit tudok amit a demokban leírtak, vagy amit a pcbreflux csatornáján lehet tanulni a youtubon.
Érzésre esp-idf is erősen fejlesztés alatt van. a esp32 forumja iszonyat lassú. A frissen regisztrálóknak a moderátor nézi és engedélyezi a hozzászólását.Referencia alapján kezdtem a küzdelmet.
-
válasz
Teasüti #6775 üzenetére
Volt ráérő kb. 5 percem, meg egy tippem, mi lehet a gond. 4 percen keresztül próbáltam megnyitni a linket, telefonon, mert hogy általában arról szoktam fent lenni, ha ráérek, de csak reklám jött be. Kizárólag.
A képről elkezdtem bepötyögni a címet, váltogatva telefonon két böngészőlap közt, de vagy elrontottam, vagy csak simán arra is reklám jött be, mindenesetre telefonon ezt sem túl kényelmes csinálni, ráadásul buszon voltam és mobilnetről. Itt már kb. a 10. percet töltöttem csak az oldal megnyitásával. Itt lett elegem. Kérek engedélyt meghunyászkodni. -
PHM
addikt
válasz
Teasüti #6725 üzenetére
Erről szívesen fogadnék egy linket, ha lehetséges.
Közben kicsit nyomoztam én is, konkrétan az Atmel Atmega328P
adatlapját nézegettem. Eddig nem találtam benne ajánlást a portok
párhuzamos kötésére, ami persze nem jelenti azt, hogy ezt ne
lehetne megtenni. Van viszont egy abszolút maximum áram a
VCC-GND vonatkozásában, s ez 200mA. Ennyi lehet az össz
bemenő áram...
Hobbiprojektnél ráadásul a párhuzamosan kötött portokkal pont a
duplájára növeljük a hibalehetőségek számát. Gondolok itt az elkufircolt
szoftverre, ami kezdőként valljuk be, óhatatlanul becsúszik.(#6726) aryes: Itt elsősorban hobbiprojektről van szó, ahol azért
inkább a biztonság a fontos. Nem?
Persze a szükség/spúrság nagy úr, én is láttam már gyári kapcsolásban
olyat, amitől a hajam is égnek állt. -
tvamos
nagyúr
válasz
Teasüti #6715 üzenetére
Igen, egy kis relet.
Biztosan mukodik ez a kapcsolas.
Nekem nem tetszik, mert ha a kimenet 5V, feltoltodik a kondi 4.3V-ra, es amikor a kimenet 0V-lesz, akkor a tranzisztor bazisa -4.3V, ami nem jo. De mondjuk kibirja, baja nem lesz.
Miert kell ez a hoka-moka? Ha elromlik a kapcsolas, ne vilagitson folyamatosan a feklampa?
-
PHM
addikt
válasz
Teasüti #6705 üzenetére
Nem pontosan. Kb úgy viselkedik, mint egy nyitóirányú dióda.
Kapcsoló üzemben egy bipoláris tranzisztor bázisára legalább
annyi áramot kell adni, mint a kollektoráram és az áramerősítés
hányadosa. A gyakorlatban ennél többet szoktak adni a
bázisra, hogy a tranzisztor biztosan "leüljön".
Tehát még egyszer:
A bipoláris tranzisztorok áramvezéreltek, fix feszültségű
meghajtás esetén fennáll a hőmegfutás, illetve a báziskör
megszakadásának veszélye. -
R̲e̲m̲
senior tag
válasz
Teasüti #6701 üzenetére
ha nem teszel bázisellenállást, lehúzhatja a kimenetedet földre, az adott io átmegy áramgenerátorba, és rosszabb esetben meghal. 5,6k 5V-on 0,89mA áramot húz ki az arduinodbol, de tehetsz 1k-t is, akkor 5mA fog kifolyni
adatlap szerint a bc337-nek valahol 100 és 630 közt van a β-ja, worst case is legalább 80mA-t tud kapcsolni azzal a bázisárammal, ami 5,6k-n folyik, nyilván belemehetünk a matekba, és lehet számolni a b-e, c-e feszekkel, de kapcsolóüzemben nem szoktam foglalkozni vele, a CE-áramot úgyis korlátozza a relé ellenállása.
tranyonal nem érdekes a baziskapacitas, mert nagyonhamar "kisül", a fetnél már érdekesebb a dolog, amikor a "millerkapacitás" miatt nem zár le a feted, miután elvetted a vezérlést...
nem csak a gate-ellenállás lényeges, hanem a gate-source is, ahol kisülhet a "kondi" a vezérlés megszűnése után.
Ez abbol is ered, hogy a fet nem áram, hanem feszültségvezérelt (térvezérelt), és gate-source irányban nem igazán folyik áram nem tud hol kisülni az a kapacitás. -
R̲e̲m̲
senior tag
válasz
Teasüti #6699 üzenetére
Az említett relé tekercse 71mA-t kajál, ha direktbe kötöd a kimenetre, vagy nem húz be, vagy túlterheli az adott i/o-t
tranyót meg nem kötünk soha bázisellenállás nélkül
diódának ilyen kis reléhez elég egy 1n4148 is
a kepen 12v-os relé van, de ez ebben az esetben nem számit, ha 5v-os a relé, akkor 5v-ra kell tenni
vannak komplett modulok is ezzel a relével, amin 3 pin van, 1 vezérlés, 1 táp és 1 gnd
azon rajta van minden ami kell -
Janos250
őstag
válasz
Teasüti #6659 üzenetére
Az arduino is a main.cpp-t futtatja, akkor is, ha az el van rejtve a szemeink elöl.
Viszont megtalálható, nálam a
C:\Arduino\arduino-1.8.2\hardware\espressif\esp32\cores\esp32
könyvtárban. Itt látható, hogy elvileg inkludolva vannak:
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "Arduino.h"
A gyakorlatban - nem tudom miért - nekem mégis néha inkludolnom kellett a könyvtár fájljait a programban.
C:\Arduino\arduino-1.8.2\hardware\espressif\esp32\tools\sdk\include\freertos\freertos
helyről.Itt van némi leírás:
https://techtutorialsx.com/2017/05/06/esp32-arduino-using-freertos-functions/Itt fel vannak sorolva a függvények, hogy melyik mit csinál.
http://www.freertos.org/a00125.htmlHa meg akarod nézni, itt van nekem egy próbálkozásom:
http://kkft.bme.hu/~johnny/ESP32mintaTobbTask-CoreKiirasBeallitas.inoValami itt van a BT-ről, de nem használtam, csak könyvjelzőztem
https://techtutorialsx.com/2017/07/17/esp32-bluetooth-advertising-a-spp-service-with-sdp/Mellesleg én a mobiltelefonnal is WiFin keresztül tartom a kapcsolatot,
internet megosztás módszerrel, és nem zavar semmit. -
-
Janos250
őstag
válasz
Teasüti #6647 üzenetére
Ez egy elég jó leírás egy csomó példával az ESP32 használatára:
http://www.instructables.com/id/IOT-Made-Simple-Playing-With-the-ESP32-on-Arduino-/
Van benne egy csomó dolog, digitális, analóg input, output, led trimmer, szervo , internet, stb.
Egyébként még sokan előnynek tartják, hogy akár WiFin keresztül is töltögetheted rá az új programokat. Én ezt a részét nem használtam, nekem ez nem volt szükséges eddig.
Szó van benne a hardver PWM-ről is, ami bizony jól jön számos helyen: led, szervo vezérlés, stb. Egészen más, ha a hardvert beállítom, és az önállóan dolgozik tovább amíg nem babrálom, mintha pl. egy szervonál folyamatosan szoftverből kell küldözgetni a jelet, mint egyes régebbi lapoknál. -
Janos250
őstag
válasz
Teasüti #6647 üzenetére
A WiFi használatára egy összefoglaló:
https://www.arduino.cc/en/Reference/WiFi
Az arduinonak épp az a lényege, hogy ha egy új processzort tartalmazó lapot beillesztenek a redszerbe,
akkor ugyanazokat az osztályokat, ugyanazzal a névvel, funkcióval, tagfüggvényekkel meg kell rá írni. Ez a portolás lényege.
AZ ESP32-re a gyártó illesztette a freeRTOS-t. Az arduinora portolás során gyakorlatilag azt tették, hogy az arduinonak megfelelő nevekkel,
paraméterekkel, stb. megírták az új osztályokat, amiben hivatkoznak - az egészen más nevű, logikájú - freeRTOS függvényeire.Célszerű a mintaprogramokat megnézni. Az ESP8266 WiFire sok példa van, gyakorlatilag ugyanazok mennek az ESP32-n is.
Viszont WEB szerverre célszerű az ESP8266 WEB szerverét használni, mert az jobban ki van dolgozva WEBre. Portolták as ESP32-re is:
http://www.fisch.lu/junk/ESP32-WebServer.zip
Itt már átírták a nevét 32-re, és pár dolgot módosítaniuk kellett benne.A BT-t nem tudom, nem használtam.
UI.: most látom, hogy a ESP8266 WEB szerver linkje nem él, de majd ha összefutok vele, felteszem
-
Janos250
őstag
válasz
Teasüti #6643 üzenetére
"Én teljesen abban voltam, hogy ez külön platform, mint a ARM"
Én az STM (ARM) procikat is jól tudtam/tudom használni Arduinoként. A spéci, hardverközeli libek persze nem mennek, de a hardverközeli részt megoldottam a regiszterek közvetlen írásával (pl PWM). Annak szerencsére a regiszterekről egészen jó leírása van, ami az ESP32-ről egyelőre még nem mondható el. Viszont amit az emberfia nem tud egyszerűen megoldani, akkor ott van a freeRTOS rengeteg függvénye. Mint korábban írtam, az ESP32 arduinoja a freeRTOSra van ráültetve. -
Janos250
őstag
válasz
Teasüti #6643 üzenetére
Azért a kompatibilitás csak a C++ -ra érvényes, a hardverközeliekre természetesen nem!
pl. Serial (hardver) 3 db. van rajta, de alapból a puffert az Arduino 256-ra állítja, én egyből átírtam 2048-ra, mert néha az ESP8266-on megtelt, így itt már kapásból magasabbra raktam. UNO-n meg a kis sebesség miatt nem is tudnám a programomat használni.
A sebességekre egy összehasonlítás. Az STM32F7 sorozat persze gyorsabb, de az méregdrága. Persze az ESP32 kettő magját kihasználva, azért ezen lehet gyorsítani.
https://hilo90mhz.com/arduino-esp32-esp8266-101-speed-test-comparison-chart/ -
Janos250
őstag
válasz
Teasüti #6639 üzenetére
"Milyen IDE-ben dolgozol vele?"
Ugyanabban az Arduino IDE-ben, mint a többi lappal.
Minden ugyanúgy megy, mintha mondjuk UNO lenne, csak nem UNO-t, hanem a NodeMCU-32S-et választom ki.
"Gondolok itt arra, hogy ha vmit elkészítenek Arduino-ra, akkor találok alternatívát ESP-re?"
EZ IS ARDUINO!
Ha csak C++-ban írt program, akkor egy akár UNO-ra írt program simán megy. Ha spéci, az Atmel proci sajátosságait kihasználó részek vannak benne, akkor az persze változtatás nélkül nem megy. Viszont egyre több minden készen van.
"Pl ws2812 lib"
Ez pl. sokkal egyszerűbben megy, mert az ESP32-ben van RMT = Remote Peripheral, (értsd infra távirányító) kezelő (szimuláló) hardver, így ezt hardver szinten megoldja. Nekem is az elsők között jutott eszembe a WS2812. Ez pl. rendesen működik, kipróbáltam én is:
https://github.com/MartyMacGyver/ESP32-Digital-RGB-LED-Drivers
Mivel hardver szinten intézi, nem is kell variálni a magok között.
Egyébként alapból a rendszer dolgai a 0-ás magon mennek, a useré pedig az 1-esen, ha nem változtatunk.
Ha éles a realtime dolog, akkor a realtime mehet az 1-esre, a ráérősebb pedig alacsony prioritással a 0-sra, a rendszer dolgai mellé. Akkor nem kell se interrupt letiltás, se egyéb, mert az 1-esen csak a szigorúan realtime dolog megy. -
jksx
senior tag
válasz
Teasüti #6625 üzenetére
Üdv!
Szerintem LM193, vagy LM293 (LM393) Dual-comparator IC-t alkalmaztak a kapcsolási rajz szerint. (Az általad linkelt oldalon lejjebb ott van a 3.3V-os ág védelménél az IC "másik fele".)
Biztos hogy nem LM311, mert az "single" és más a lábkiosztása is. Persze ezzel is megépíthető a kapcsolás.
A nem invertáló bemenet osztójába beraknék egy potit, hogy be lehessen állítani a billenési feszültséget pontosan a zener dióda szórása miatt. Vagy referenciát kell használni pl. az LM336-ot.
Dual comparator -
gyapo11
őstag
válasz
Teasüti #6593 üzenetére
Szerintem az a fő gond, hogy az emberek és a gyerekek sem egyformák. Az érdeklődésük sem. Tehát ugyanazt tanítani mindenkinek nem jó. Egyenként jó lenne, de nincs annyi tanár. Ezért elfogadjuk, hogy egy csomó gyerek nem tud kibontakozni, csak szenved a tanulással, és messze a képességeinek megfelelő képzettség alatt kell leélnie az életét. Néhányan azért tanulnak önként tovább is, és ők felszednek tudást, de nincs róla papírjuk, ezért nem tudnak jobban fizetett munkát végezni, esetleg azon a területen papír nélkül egyéltalán nem alkalmazzák őket. Szóval sok probléma van, ezekkel élünk együtt, hogy mi lenne a jó megoldás, azt nem tudom.
Az atomi szintnél nagyon sokat számít az információ forrása. Mert ugye minden tudás ott van a könyvekben, könyvtárakban, miért nem mondjuk a gyerekeknek, hogy irány a könyvtár, tanuljatok. Azért mert a hatásfoka közelítene a nullához. Ha pedig tanárok tanítják őket, akkor néhányuk akadémikus lesz, sokuk tudós, kutató, professzor stb. Nagyon fontos a tanulás/tanítás módszere. Gyerekeknél az életkor is, évről évre más módszer kell, mert rohamosan fejlődnek. Ha rossz időpontban kapják az anyagot, nem ér semmit, esetleg negatív hatást vált ki, lelohasztja az érdeklődést, ami a tanulás fő motorja. Ha nem kapják meg a jó időpontban, akkor ott vagyunk, mint ha elküldtük volna a könyvtárba. Összesítve a tanítás egy szakma, pedagógia, és ha jól csinálja a mester, akkor szárnyal a tanuló, és szívja magába a tudást mint a szivacs.
A kapcsolónál pl. pont jól jönne az atomi szint, mert az egész prell probléma amiatt van. Ha valaki tudja, hogy néz ki egy érintkező felülete mondjuk 10 ezerszeres nagyításban, akkor érteni fogja, hogy miért nem átmenet nélkül és egyszer jön létre a vezetés a két felület között. De rögtön azt is tudja, hogy miért élezi a kést a fenőacél, ami nem szed le anyagot. Hogy miért tudja polírozni a puha mészkőpor az acélt.
A tudás kinyitja a világot. Egy valamit megtanulunk, tíz más valamit húz maga után. Mint a láncreakció. Ha egy valamit megértünk, az segít megérteni tíz más valamit, amiket ha megértünk, az már száz mást segít stb.
Az elektronika is ilyen. Ha valaki megérti az Ohm törvényt, az ellenállás, feszültség és áram viszonyát, majd ehhez a kondenzátor, dióda, tranzisztor működését, onnantól már meg tud tervezni egy számítógépet tranzisztorból. Viszont ha ezt a pár dolgot nem érti, akkor nincs más választása, mint fekete dobozokból építkezni, és bízni abban, hogy tényleg azt csinálja a doboz, amit a készítője mondott. Egy egyszerű kimenetet nem tud invertálni egytranyóval meg egy bázis ellenállással, mert nem érti, hogy működik. És itt sem kell atomi szintre lemenni, hogy elektronok, meg lyukak, meg szennyezés, anélkül is lehet érteni a működést, lehet számolni és tervezni. De ha nem érti a hőtant, akkor ki fog szállni a füst egy párszor a tranyóból. Ha érti a hőtant, de nem érti az aerodinamikát, akkor a hűtőborda ellenére is kiszáll a füst, mert a légáramlás nem jól van méretezve.
Könnyen belátható, hogy egy kis erősítő vagy szinte bármi elektromos dolog előállításához sok területről kell rendelkezni valamennyi tudással. És ha nem, akkor elég sok munka az elkészítés előtt összeszedegetni ezeket a tudásmorzsákat. -
Vladi
nagyúr
válasz
Teasüti #6585 üzenetére
Egy alap elektronikai ismeret azért csak kellene. Pl ma beugorttam a helyi elektronikai boltba, hogy vegyek pár ellenállást. 10 forintos cucc, párat veszek. Pofa szinte kizavart az üzletből - jó hát megkeseredett vénemberr, remélem nem olvassa
- de jött a kérdés, hogy milyen ellenállásút. Hát 1Kohmost. Oké, milyen teljesítményűt... .őőőőő és hány amperest? őőőőhőőőhhhőőő....
Ami a felsőfokú képzést illeti: minden szakmában kell egy átfogó, alap tudás. Utána jön a specializálás. De sok intézményben nagyon kevésnek látom a gyakorlati képzést. Nem csak műszaki területen.
Pl: oké, hogy a bme-n gyakorlaton összeforrasztanak pár ledet, nade ebből mi a valós haszon?
Jöjjön akkor 3 hallgató hozzám, elmondom mi kell, megtervezik, bevásárolok, összerakják. Aztán kap egy ötezrest mindegyik, meg egy üveg pálinkát és egy rekesz sört.
Mindenki jól jár: A diák tanul, az iskola gyakorlati képzést ad, ráadásul ingyen, a vállakozó meg örül, hogy nem nyócszázezerér csinálták meg. -
válasz
Teasüti #6584 üzenetére
Hát nekem, mint amatőrnek borzasztóan hiányoznak az alapok, persze az általános iskolai fizika és egy csomó utánaolvasás megvan, de így is pont az általad írt empirikus módszerrel építem a legtöbb cuccomat. Lassan is haladok.
Nekem pont egy szájbarágós, számonkérős oktatás kellett volna fiatal (fogékonyabb) koromban, vén fejjel már csak a kosz ragad rám a tudás helyett...
tibi-d: a lexikális tudás van akiben megmarad, van, akiben nem. Viszont az fontos, hogy amit egyszer megtanultam, azt később könnyű újra tanulni, illetve tudom, hol kell utánanézni, másrészt be fog ugrani, hogy "igen, van ilyen is".
-
Vladi
nagyúr
válasz
Teasüti #6579 üzenetére
Ami a házi feladatot illet tanár úr... amit linkeltem könyvet nem a legjobb, az elején még szép alapos, de a kapcsolókról hardver ügyileg már kb semmit se ír.
ezt találtam. Erről mi a vélemény? Jó?
-
tvamos
nagyúr
válasz
Teasüti #6567 üzenetére
Amikor macro assemblert hasznaltunk meg, akkor sokminden igy ment....
(#6580) gyapo11 válasza Teasüti (#6577) üzenetére
Nem kell mindenhez erteni! Amugy erosen tul van ez a motorolaj kerdes misztifikalva. Az osszes auto (kiveve azt a 0.00001% nagy becsben tartott veterant) ugyan ott vegzi. Elobb, vagy utobb.
Amugy meg ugyis hiaba beszelsz az embernek. Leirom, hogy 40 alkatreszt vizsgaltam meg, az elettartama elejen, vegen, oszcilloszkoppal, kulonbozo terhelesek mellett, de hiaba. Osztja nekem az eszet, mert o egyet megmert. Hat, akkor ugy van. -
gyapo11
őstag
válasz
Teasüti #6577 üzenetére
Viszont engem speciel az elmélet teljesen hidegen hagy, a mai napig nem értenék egy fikarcnyit se ehhez, ha előbb az Elektromosságtan I-II-III tárgyakon kellett volna átmennem hozzá.
Érdekes ez. Rengetegen használnak olyan dolgokat, aminek nincsenek tisztában az elméletével. Pl. beleöntjük a motorba az olajat, és használjuk. Nekimegyünk a fúróval az anyagnak és fúrunk. Ez működik többnyire. Ilyesmi a libek használata is, fogalmunk sincs, hogy milyen program fut, de az eredmény megvan, többnyire.
Aztán amikor szükségessé válik, hogy értsük is a dolgok részleteit, akkor jön a gond. Pl. összekeverhetek-e két olajat a motorba öntés előtt, és milyen következményei lesznek a keverésnek, fúrhatok-e adott fúróval adott fordulatszámon adott anyagot, vagy kenni kell valamivel, ha igen mivel.
A libekkel vagy elektromossággal ugyanez van, ha bármit változtatni kell a készen kapott rajzon vagy programban, akkor már érteni kell a működését, amíg csak berakom és megy, addig nem szükséges érteni.
A libekhez van leírás, hogy kell beilleszteni, hogy kell hívni stb. Mégis vannak kérdések. Pont azért, mert a library rendelkezik egy csolgáltatás csomaggal, ami sokszor nem elég, vagy nem pont úgy kellene működnie stb.
A tervezés meg még magasabb szint, ha valaki csak érti a mások által tajzolt elektronika működését, az nem biztos, hogy tud tervezni, az üres papír és az elképzelt működés közé beilleszteni az elektronikai elemekből a működő hálózatot.
Aki pedig nem tud tervezni és programot írni, annak valóban csak a kész elemekből építkezés marad, ami szűkíti a lehetőségeket. -
Vladi
nagyúr
válasz
Teasüti #6543 üzenetére
Jogosak az észrevételeid, át is rágom majd rajta magam.
De most még ott tartok, hogy egy nyamvadt gombot se bírtam bekötni. Át kell ellenőriznem az egész cuccot, hogy minden működik -e.
Egyelőre egy nagyon egyszerű gombnyomó kódot veszek le az arduino oldaáról és 1 darab gombot fogok bekötni. Ha za megy jön a második, meg a relé és utána az időzítés.
Libek nélkül nagyon nehezen boldogulok, de megpróbálom nélkülözni őket.
-
Vladi
nagyúr
válasz
Teasüti #6525 üzenetére
Nem kell nyomkodni, de néha szükséges, véletlenszerűen.
Ez egy régi gyártógépen lévő kést fog vezérelni a projektem. Időzíteni kell, de sajnos a gép már régi és sok nyűgje van. Időnként igazgatni kell, meg piszkálni stb. ehhez kell az időzítőre egy pause gomb, ami mikrokapcsoló lesz, meg egy olyan gomb, ami nullázza a ciklust.Ez utóbbin nem kéne, hogy több jel menjen, mert vagy egymás után többször vág a kés, vagy szerintem beragad.,
"hacsak a főnök nem milliszekundumra normáz be."
nemhülyeség.mondjuk én vagyok a főnök, szal...
(#6528) kmisi99:
Van ilyenem, de érdemben még nem használtam, csak a régebbi fajtát.
-
Vladi
nagyúr
válasz
Teasüti #6510 üzenetére
Ha már ezen rugózunk, most én is néztem pár oktató videót a szoftveres prell mentesítésről. Arra jutottam, hogy az elvi működés:
Ha érkezik egy jel, mérjük annak hosszát. Ha x időt, mondjuk 30 milit meghaladó időn keresztül jön a jel, akkor azt egy igennek vesszük.
Én meg addig azt hittem, hogy úgy működik, mint az állatok idegrendszerében:
Ha érkezik egy jel, azt automatikusan 1 igennek vesszük és utána 30 miliig nem érdekel mi történik, oda se nézünk, mert már van egy igenünk. Ha 30 mili után is van jel (prell mentes folyamatos jel) akkor tartósan igen, tehát a gomb folyamatosan nyomva. Vagy nincs jel és akkor a dolgozó felengedte.Ezt amúgy neurológiában refrakter stádiumnak hívják.
Melyik igaz?
-
gyapo11
őstag
válasz
Teasüti #6479 üzenetére
A pergésmentesítési idő ne legyen 50 ms-nál hosszabb, mert egy mikrokapcsolóval egy pöccintés kb. ez az időtartomány, vagyis lehet, hogy a pergésmentesítés elnyeli a valódi gombnyomást.
Ez a library vagy saját kód örök téma. A library (mások kódja) jó, ha egyből működik, elfér és elég gyors. Ha babrálni kell vele, akkor már könnyen hosszabb időt elvihet, mint a saját kód. Ha tudni kell a futási idejét, akkor már bele kell mászni a forrásba, megint elég sok idő. Hogy mivel fog még ütközni és mikor, az megint egy jó kérdés, hosszas teszteléssel talán kiszűrhető vagy a forrás alapos elemzésével.
Ráadásul a saját kód írása mindennél jobban elősegíti a rendszer ismeretét, beleértve a hardware-t, a programnyelvet.
Olyan ez mint a szinusz tétel. Ha nem ismered, akkor nem is fogod tudni használni feladatok megoldásánál. Nem tudod beírni a google-ba, mert nem tudod, hogy létezik. Amiről nem tudsz, arra nem tudsz libraryt keresni se. Kell egy alap tudás, és ezt legjobban a programozással lehet megszerezni, nem libraryk összerakásával és variálgatásával. -
Vladi
nagyúr
válasz
Teasüti #6490 üzenetére
"Te neked ez nem egy hobbi? Általában élvezni szokás a hobbidnak szentelt időt."
Nekem pro felhasználásra menne a gép. Ha már az első modellt látnám működni, akkor megnyugodnék, megkönnyebbülnék, hogy van értelme, meg össze tudok hozni ezt-azt.
Egyébként pont ezért bírok falnak menni, mikor megy az erőlködés, hogy vettem egy arduinot, meg rpi-t mit építsek belőle?
Jó hát tanulás, meg hobbi oké... de ha ennyire nem bír mit kezdeni az erejével, adok én neki munkát segáz.
"Én előtte programozni csak Pascal-t tanultam,"
S én tudod mit? 25 éve c64-en béziket.azóta is rögzült a goto 10 gondolkodás, nehezen értettem meg a loopolást.
-
Vladi
nagyúr
válasz
Teasüti #6478 üzenetére
Ha megnézed a kódomat, még relé libet is használok.
(#6479) Teasüti:
Persze, mert te is úgy vagy vele, hogy "nem értesz a programozáshoz."
Ha saját magam írnám, 8-10x annyi idő lenne. Így meg:
- viszonylag hamar megírom, tehát 3 sor/óra tempóval
- Képes vagyok magam megírni. -
Vladi
nagyúr
válasz
Teasüti #6474 üzenetére
Igen, közben megnéztem, hogy a button libek némelyike tud debounce-ot. Amit én használtam azis.
Viszont kis ügyesek ezek a fejlesztők. Igen. Eddig 3 különböző libet találtam button.h néven. Nem kéne ezeket máshogy nevezni?Egyébként mennyi időt érdemes megadni? 20-50 ms?
-
tvamos
nagyúr
válasz
Teasüti #6444 üzenetére
Az ESD miatt jo, ha van ott egy soros ellenallas, de a zavarok szempontjabol meg rossz, mert rontja a jel-zaj viszonyt,,tehat jolmkell megvalasztani.
A zajokmmiatt kell a kondi.
Az ESD miatt meg ESD vedelem, mondjuk diodaval, supressor-ral, transillel, varistorral, akarmivel. -
válasz
Teasüti #6449 üzenetére
Én mondjuk az arduino-t egy külső érzékelővel összekötő kábelre és annak zajérzékenységére gondoltam. De azt nehezen hiszem el, hogy ha mondjuk egy 2m-es vezetékre kötött kapcsoló és az arduino közé iktatok sorosan (nem fel/lehúzó ellenállásként) valahová egy mondjuk 10k ellenállást, akkor ne kezdene hasznos jel helyett inkább légköri zajt közvetíteni.
Hogy a fogalmakat tisztázzuk, én mindent "drót"-nak hívok, ami áramot vezet, csak a kedvetekért próbáltam cizellálni, hogy ne tűnjek olyan műveletlennek. Gondoltam szólok...
Új hozzászólás Aktív témák
Hirdetés
- sziku69: Fűzzük össze a szavakat :)
- Azonnali notebookos kérdések órája
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Formula-1
- Xbox Series X|S
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Bittorrent topik
- További aktív témák...
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged