- AMD vs. INTEL vs. NVIDIA
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Fejhallgató erősítő és DAC topik
- Fájdalmasan gyenge kijelzőt válaszott a Switch 2-höz a Nintendo
- Extrém tűrőképességgel reklámozza új tápkonnektorát az ASUS
- Apple asztali gépek
- Gaming notebook topik
- Hobby elektronika
- HiFi műszaki szemmel - sztereó hangrendszerek
- Kisebb gond akadt az ASUS egyik felsőpolcos vízhűtésével
-
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
-
helltp
aktív tag
-
choco01
addikt
-
helltp
aktív tag
Sziasztok!
Boot problémám van az ESP8266 alapú Wemos D1 mini-vel. Ha a D4(GPIO2)csatlakoztatva van az áramkörhöz, akkor nem bootol rendesen, a beépített led folyamatsan világít, reset gombra nem reagál. Kicsit kerestem, és a D3(GPIO0) D4(GPIO2) 10k-val fel van húzva 3,3V-ra, a D8(GPIO15) földre van húzva 10k-val, annak ellenére, hogy ez az eszközön már alapból meg van csinálva.. Ha először kap tápot a d1 mini, és utána helyezem az áramkörbe, akkor rendesen működik. Valakinek valami tipp, hgy mit lehet ezzel kezdeni?
-
Janos250
őstag
válasz
choco01
#7719
üzenetére
Tapasztalatom szerint nincs felhasználás szempontjából lényegi különbség a különböző ESP32 panelek között, kivétel, ha nagyon régi.
ESP-WROOM-32 legyen rajta. Ez ugyanaz, ami korábban az ESP32S. USB szintén legyen rajta, amiről programozni is, tápolni is lehet. A többi szerintem mindegy.
Én ezekből használok/tam párat.
link -
-
Tankblock
aktív tag
válasz
choco01
#7722
üzenetére
Hello,
ESP32 van egy csomó Analog input, a kérdés, hogy hogyan is szeretnéd használni. Nem kell hozzá multiplexer szerintem.
Ha egyszerűen csak digitális GPIO pint akarsz használni akkor az 5 [V] TTL logika szerintem itt még egy egyszerű elleállás osztóval is megoldható.
milyen táppal lesz meghajtva ha egyszerű akksi akkor javaslom olvass utána a FET eknek és a deep sleep témának, különben gyorsan tud meríteni az aksit....,
ja és akkor belinkelt mellé kell még venni töltő áramkört is....
-
Tankblock
aktív tag
válasz
choco01
#7719
üzenetére
Hello,
Leírásban ott a válasz:
AO analog output can be connected to the microcontroller AD port to detect the size of the drops in the above rainfall. --> Analóg csatornán ad valamekkora arányos jelet
DO TTL digital outputs can also be connected to the microcontroller detects whether there is rain.
--> digitális, komparátorral ad szint felett 1 est.Az ESP32 3V3 működik ez meg 5V. bár azt írja h megy 3-5V között...
Operating voltage: 3.3V-5V
Voltage: 5Vén használák valami voltage level shiftert ha 5 V kellene használni.
-
-
vargalex
félisten
válasz
ratkaics
#7625
üzenetére
Hasonló elképzeléssel valósítottam meg a low power ESP8266 alapú hőmérőt. A cél a minél alacsonyabb fogyasztás volt. Az eszköz (jelenleg 2 példányt raktam le a lakásban) egyetlen Li-Ion celláról működik, ami így 42 nap folyamatos működés után 3.8 V-on áll. A pencenkénti hőmérést figyelembe véve azt gondolom, hogy eddig elégedett lehetek. Természetesen mindenképpen beszámolok, hogy meddig bírta (az ESP8266 miatt kb. 3V-ig hagyhatom merülni).
A kódot itt találod. A DS18B20 kiolvasása egyszerűen cserélhető bármilyen másik szenzorra. -
_q
addikt
válasz
Janos250
#7620
üzenetére
Köszi. Igazából csak tesztelni akartam az ESP-t és mivel eddig semmi tapasztalatom nem volt vele, ezért próbáltam kideríteni. Fő célom hogy képbe kerüljek a programozásával kapcsolatban meg legyen egy kicsi rálátásom. Bizonyos esetekben megoldható a driver írás, csak ha bonyolultabb szenzort akarunk működésre bírni ott nem biztos hogy neki akarunk állni sajátot írni.
-
-
_q
addikt
Sziasztok!
Megjött az ESP32. Próbáltam a "simplewifiserver" példát. 2 verzió is van az arduino ide-ben. Egyikbe van valami "wifi firmware", másik a githubon lévő, amiben nincs. Az utóbbit tudja csak lefordítani, ugyanis nem találja a wifi firmware változót.
Az utóbbi kódot rátöltve a mikrovezérlőre nem nagyon megy a dolog. Valami miatt nem tud csatlakozni szerintem a routerre, pedig megadtam SSID-t és jelszót is. Van valami trükk?
Ezt írja ki a serial monitor:
Connecting to Manhattan
Brownout detector was triggered
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode: DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078ad0 -
itg
tag
válasz
Janos250
#7607
üzenetére
igen, kb. idáig jutottam én is. csak az összes mintapélda a fenti (ezek szerint hibás/régebbi) módszerrel kérdezi le és azt hittem én vagyok a láma.
én egyébként a ESP8266WiFi.h -t hívom meg, de ha ezt megcsinálom, valószínűleg átalakítom push-ra a scriptet és akkor nem fog állandóan a wifi-n lógni.köszi a segítséget!
-
itg
tag
válasz
Tankblock
#7601
üzenetére
Üdv.
Köszi a választ!
Még akkor éjszaka pont ezt tettem és kiderült a turpiszság.
loop-ba raktam a wifi reconnect-et és valamilyen oknál fogva minden alkalommal újra csatlakozott a routerhez, ami az egyiket megfektette, a másik viszont bírta.Viszont ha csak a setup részbe rakom a wifi kapcsolódást, router újraindulás esetén nem csatlakozik újra az eszköz.
Az egyik eszköz: Wemos D1 mini, a másik D1 mini ESP-12.
(elméletileg egyformák) -
Janos250
őstag
Én legolcsóbbnak ezt találtam:
link
Egy a lényeg: ESP-WROOM32 (tehát az a fém tokos hibrid valami) legyen rajta. Amire azt írják, hogy ESP32S, ma már az is ugyanaz. Nézd meg a kinagyított fényképét.
A neten ajánlják azt is, amin van oldalt egy fehér tápcsati, de itt korábban valaki azt írta, hogy a + és - fordítva van bekötve, tehát figyelni kell.Bizony a kínai vásárláshoz türelem kell
-
Tankblock
aktív tag
Hello,
Most inább mutatnék egy példát arra amikor megy ez WebSockettal is.
Ez nekem anni 1 ESP-01 futott és 1x 3 eszközről lehetett csatlakozni (ennyit próbáltam).
Az eventek láthatóak szinte azonnal a többin böngészőben is.
[link]Amúgy a példádban a
server.send(200, "text/html", webPage);a wepPage helyett kellene valami másik string.... -
brickm
őstag
Sziasztok!
Sikerült végre feléleszteni az ESP-01-et arduino IDE alól is.
ott tartok a dologgal, hogy, itt a kódom, de ebbe hiába teszem be az if- else sorokat, a html lapon nem változik az input értéke. Annyit kifilóztam, hogy azért, mert a setupba került, és a loopban kéne tenni, de a loopba téve lesem generálja a html lapot, mivel az a setupban generálódik. Na itt akadtam el, hogy akkor hogyan tovább?
A kód aljára tettem az input kiolvasást, kommentbe#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>
MDNSResponder mdns;
// Replace with your network credentials
const char* ssid = "TP-LINK_B791B8";
const char* password = "passw0rd_000";
ESP8266WebServer server(80);
String webPage = "";
int gpio0_pin = 0;
int gpio2_pin = 2;
int dsc_state = 0;
void setup(void){
webPage += "<h1>DSC PC 1616 WebPage</h1><p>GPIO_0 <a href=\"socket1On\"><button>Arming</button></a> <a href=\"socket1Off\"><button>Disarming</button></a></p>";
// webPage += "<p>GPIO_2 <a href=\"socket2On\"><button>ON</button></a> <a href=\"socket2Off\"><button>OFF</button></a></p>";
//
// preparing GPIOs
pinMode(gpio0_pin, OUTPUT);
digitalWrite(gpio0_pin, LOW);
pinMode(gpio2_pin, INPUT);
digitalWrite(gpio2_pin, LOW);
delay(1000);
Serial.begin(115200);
WiFi.begin(ssid, password);
Serial.println("");
// Wait for connection
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.print("Connected to ");
Serial.println(ssid);
Serial.print("IP address: ");
Serial.println(WiFi.localIP());
if (mdns.begin("esp8266", WiFi.localIP())) {
Serial.println("MDNS responder started");
}
server.on("/", [](){
server.send(200, "text/html", webPage);
});
server.on("/socket1On", [](){
server.send(200, "text/html", webPage);
digitalWrite(gpio0_pin, HIGH);
delay(1000);
});
server.on("/socket1Off", [](){
server.send(200, "text/html", webPage);
digitalWrite(gpio0_pin, LOW);
delay(1000);
});
server.on("/socket2On", [](){
server.send(200, "text/html", webPage);
digitalWrite(gpio2_pin, HIGH);
delay(1000);
});
server.on("/socket2Off", [](){
server.send(200, "text/html", webPage);
digitalWrite(gpio2_pin, LOW);
delay(1000);
});
server.begin();
Serial.println("HTTP server started");
}
void loop(void){
server.handleClient();
}
//Ez az input mező kiírásához:
//dsc_state = digitalRead(gpio2_pin);
//if (dsc_state == HIGH){
// webPage += "<h2>Input is HIGH</h2>";
//}
//else {
// webPage += "<h2>Input is LOW</h2>";
//} -
Janos250
őstag
válasz
távcsőves
#7550
üzenetére
Szubjektív vélemény:
"1 hete használok STM32DUINO"
Jó is az! Előnye, hogy ARM. Annak ellenére, hogy az ESP32 dokumentációja is egyre bővül, az STM32-vel még nem veheti fel a versenyt részletesség és pricizitás terén. Az F103-at én is használtam, szerettem. Viszont mire az F4 boardjaim megérkeztek, addigra már az ESP32 támogatása is olyan szintre jutott, hogy az STM-ek a fiókba kerültek.
Az ESP32 előnye:
szintén sok memória, rengeteg periféria, 240 Mhz órajel kettő maggal, és mindkét mag jól használható. Ez némi párhuzamos programozási technikákat is lehetővé tesz. Az arduino környezetbe illesztése mostmár szinte tökéletes. A freeRTOS op. rendszer fut rajta, arra van ráillesztve az arduino héj, de elérhető az op. rendszer - majdnem minden - saját függvénye is. Nagy előnye a beépített WiFi és BT. Van benne olyan spéci lehetőség is, mint pl. az RMT. Az UNO-ra megírt programok gyakorlatilag változtatás nélkül futnak rajta. A GPIO lábak low/high állítására külön regiszterek is vannak, nem kell a lábak állapotát beolvasni, majd úgy módosítani közvetlen regiszter használat esetén se. Előny még az ára: 1600 Ft körül már kapható.
Hátránya:
Nem ARM. Ha az ember a C++ -nál lentebb akar menni, azaz a regisztereket közvetlenül akarja elérni, még akad dokumentációs hiányosság. Bármelyik periféria bármelyik lábhoz kapcsolható, ez gyakran előny, de néha bonyolítja a dolgunkat. A regiszterek kezelése jó, de mivel 32-nél több GPIO van, ezért a GPIO-hoz kapcsolódó regiszterek 2 x 32 controll regiszterhez tartoznak. Nem minden GPIO használható szabadon, de ezek nem a 32-n túliak. Egyik-másik funkció leírása még vagy nincs meg, vagy gyér.Összefoglalva:
Én az ESP32 mellett vagyok. Ha valaki csak C++ -szinten (tehát csak "arduino" módon) használja, akkor a felsorolt hátrányait nem érzi, előnyeit viszont igen.
A regiszterek közvetlen kezelése nem szükséges normál esetben, de nekem jó játék. -
távcsőves
senior tag
válasz
Tomi8822
#7539
üzenetére
Nem fordul le IDE-ben vagy mi a baj vele? Valamit azért írhatnál. Most ezt a sok linkelt könyvtárat nem töltöm le, ha nincs meg nekem, milyen lap amit használsz, kicsit bővebben kellene szerintem.
(Én sem vagyok profi, sőt azért keveredtem ide, mert programozás technikai kérdésem lenne. (Saját kódom működik, de valószínű van elegánsabb/hatékonyabb módja is egy bizonyos funkciónak. Csak az én dinnye fejem nem érti a megoldást.) Épp visszaolvasgattok, hátha más is feltette már a kérdést. Meg mindjárt nézem azt is, Wemos D1 mini vagy ESP8266 esetleg ESP32 legyen amit megrendelek.
Nem tudom ugyanis elsőre mi az ajánlott. Eddig csak AVR boardjaim voltak, 1 hete használok STM32DUINO-t, és hát a kakaó , ami benne van, megtetszett nagyon. ) -
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. -
Kérdezek mást. Az alaplapot úgy látom felismerte, ha meg eltűnik akkor újra be kell írni a http://arduino.esp8266.com/stable/package_esp8266com_index.json címet a beállításoknál, erre jutottam.
Adott a wemos d1 r2, és szeretném vele használni a dht-11 hő és páratartalom mérőt. Ennek a példaprogramját használom, de a wemosra nem lehet feltölteni, mert hibát ír:
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
A teszt előtte hiba nélkül lefut. Ugyanez a program működik sima uno-val és az esp32-vel is! Arra gondolok, hogy ezzel a szerencsétlen wemos-szal nem tud valamiért kommunukálni a cucc. 15-ös pint használnám. -
válasz
Victoryus
#7540
üzenetére
Nos, csak nem boldogulok. Letöltöttem az előző hsz-ban említett drivert az alaplap kezelővel. Ott is volt, hogy esp8266, fel is tettem a led villogtató programot. Nem villog, ha konkrét pint adtok meg, akkor se. De utána eltünt maga az eszköz a választhatóak közül, és az alaplap kezelőben sincs ott. Ezt megelőzően annyit írt az arduino, hogy frissítéseket talált. Most ilyenkor mi van?
Windows eszközkezelő látja (usb serial ch340 com3) -
Megint kérnék egy kis segítséget. Megjött a wemos d1 r2. (RobotDyn wifi d1 r2 esp8266 dev board 32m) Erre szeretném a led villogtató programot feltenni, de nem sikerül. Azt írja az arduino, hogy "A fatal error occurred: Timed out waiting for packet header" Esp32 dev modulnak tettem be. Vagy ez nem az? Én azt rendeltem.
Találtam megoldást, esp8266 leírás -
Janos250
őstag
Na, akkor én a következőt mondanám:
Portable verzió!
Letöltöd az arduino rendszert, kicsomagolod egy külön könyvtárba, pl C:\arduinoPortable. Lehetőleg ne a dokumentumokba, mert akkor túl hosszú lesz a path, amit nem fog szeretni. (
) MIELŐTT ELŐSZÖR ELINDÍTOD, csinálsz egy portable könyvtárat. Most már elindíthatod az arduino.exe-t. Ebbe töltöd le az ESP8266-ot a szokásos módon. A portable verzió nem akad össze a fenn lévő másik verzióval/verziókkal. -
Tankblock
aktív tag
Sziasztok, remélem tudtok segíteni.
Van egy problémám amire nem tudok rájönni://
// Mod: Add a double knock to send extra message to the MQTT
//
//
//
#include <FS.h> //this needs to be first, or it all crashes and burns...
#include <ESP8266WiFi.h> //https://github.com/esp8266/Arduino
#include <DNSServer.h>
#include <ESP8266WebServer.h>
#include <WiFiManager.h>
#include <PubSubClient.h>
//GPIO Pin definitions
#define WiFiLED 13
#define TouchLED 12 //Also operates Relay coil
#define TouchInput 0
//Only output info to serial if this is HIGH
#define fDebug true
//Set our inital states and values
boolean ledState = false;
boolean lastButtonState = false;
boolean buttonState = false;
// Removed because of the new concept implemented
//unsigned long lastDebounceTime = 0; // the last time the output pin was toggled
//unsigned long debounceDelay = 50; // the debounce time; increase if the output flickers
// Button timing variables
unsigned long debounce = 20; // ms debounce period to prevent flickering when pressing or releasing the button
unsigned long DCgap = 250; // max ms between clicks for a double click event
unsigned long holdTime = 1000; // ms hold period: how long to wait for press+hold event
unsigned long longHoldTime = 3000; // ms long hold period: how long to wait for press+hold event
unsigned long currentTime = 0;
// Button variables
boolean buttonVal = HIGH; // value read from button
boolean buttonLast = HIGH; // buffered value of the button's previous state
boolean DCwaiting = false; // whether we're waiting for a double click (down)
boolean DConUp = false; // whether to register a double click on next release, or whether to wait and click
boolean singleOK = true; // whether it's OK to do a single click
unsigned long downTime = 0; // time the button was pressed down
unsigned long upTime = 0; // time the button was released
boolean ignoreUp = false; // whether to ignore the button release because the click+hold was triggered
boolean waitForUp = false; // when held, whether to wait for the up event
boolean holdEventPast = false; // whether or not the hold event happened already
boolean longHoldEventPast = false;// whether or not the long hold event happened already
#define MQTT_VERSION MQTT_VERSION_3_1_1
const PROGMEM uint16_t MQTT_SERVER_PORT = 1883;
const PROGMEM char* MQTT_CLIENT_ID = "Enterance Room Light Switch";
const PROGMEM char* MQTT_USER = "mqtt_user";
const PROGMEM char* MQTT_PASSWORD = "mqtt_psw";
const char* MQTT_LIGHT_STATE_TOPIC = "enterance/lightswitch/status";
const char* MQTT_LIGHT_COMMAND_TOPIC = "enterance/lightswitch/switch";
const char* MQTT_LIGHT_SPECIAL_TOPIC = "enterance/lightswitch/special";
const char* LIGHT_ON = "ON";
const char* LIGHT_OFF = "OFF";
const char* CLICK = "CLICK";
const char* LONGPRESS = "LONGPRESS";
//Create our objects for MQTT and define our IP Address class
WiFiClient espClient;
PubSubClient client(espClient);
IPAddress MQTT_SERVER_IP(192, 168, 1, 140);
void setup() {
#if defined(fDebug)
Serial.begin(115200); Serial.println(); Serial.println(); Serial.println();
#endif
//Setup our GPIO pins for input/output as needed
pinMode(WiFiLED, OUTPUT);
pinMode(TouchLED, OUTPUT);
pinMode(TouchInput, INPUT);
//Turn those LEDS's off :)
digitalWrite(WiFiLED, HIGH);
digitalWrite(TouchLED, ledState);
//Instantiate the WifManager library
WiFiManager wifiManager;
//Set a host name
wifi_station_set_hostname("sonoffTouch");
//Un remark this if your want to clear the saved connection settings.
//wifiManager.resetSettings();
#if defined(fDebug)
wifiManager.setDebugOutput(true);
#endif
//If autoconnection fails, go into AP mode so the user can configure the WiFi connection to the local WLan
if (!wifiManager.autoConnect("TaTaTatooouchMe")) {
delay(3000);
ESP.reset();
} else {
//WiFi LED is on when low
digitalWrite(WiFiLED, LOW);
//get our MQTT servers address
//WiFi.hostByName("your_mgtt.server.co.uk", MQTT_SERVER_IP);
yield();
//Establish conenction to MQTT server
client.setServer(MQTT_SERVER_IP , MQTT_SERVER_PORT);
client.setCallback(callback);
//Phew, have a bit of a breather to give everything a chance to settle down
delay(1000);
}
}
// function called to publish the state of the light (on/off)
void publishLightState() {
#if defined(fDebug)
Serial.println("PublishLightState Called");
Serial.print("Light State: ");
Serial.println(ledState);
#endif
if (ledState == HIGH) {
#if defined(fDebug)
Serial.print("Light state high ");
Serial.println(ledState);
#endif
client.publish(MQTT_LIGHT_STATE_TOPIC, LIGHT_ON, true);
} else {
#if defined(fDebug)
Serial.print("Light state low ");
Serial.println(ledState);
#endif
client.publish(MQTT_LIGHT_STATE_TOPIC, LIGHT_OFF, true);
}
}
void publishClickState() {
#if defined(fDebug)
Serial.print("Click event ");
#endif
client.publish(MQTT_LIGHT_SPECIAL_TOPIC, CLICK, true);
}
void publishLongPushState() {
#if defined(fDebug)
Serial.print("Long push event ");
#endif
client.publish(MQTT_LIGHT_SPECIAL_TOPIC, LONGPRESS, true);
}
// function called to turn on/off the light
void setLightState() {
//Set our light state, ie turn the touch LED on/off which is the same GPIO pin as the relay.
digitalWrite(TouchLED, ledState);
}
// function called when a MQTT message arrived
void callback(char* p_topic, byte* p_payload, unsigned int p_length) {
// concat the payload into a string
#if defined(fDebug)
Serial.println("Callback...");
#endif
String payload;
for (uint8_t i = 0; i < p_length; i++) {
payload.concat((char)p_payload[i]);
}
#if defined(fDebug)
Serial.print("Payload: ");
Serial.println(payload);
#endif
// handle message topic
if (String(MQTT_LIGHT_COMMAND_TOPIC).equals(p_topic)) {
// test if the payload is equal to "ON" or "OFF"
if (payload.equals(String(LIGHT_ON))) {
if (ledState != true) {
ledState = true;
setLightState();
publishLightState();
}
} else if (payload.equals(String(LIGHT_OFF))) {
ledState = false;
setLightState();
yield();
publishLightState();
}
}
}
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
#if defined(fDebug)
Serial.print("INFO: Attempting MQTT connection...");
#endif
// Attempt to connect
if (client.connect(MQTT_CLIENT_ID, MQTT_USER, MQTT_PASSWORD)) {
#if defined(fDebug)
Serial.println("INFO: connected");
#endif
yield();
// Once connected, publish an announcement...
publishLightState();
// ... and resubscribe
client.subscribe(MQTT_LIGHT_COMMAND_TOPIC);
} else {
#if defined(fDebug)
Serial.print("ERROR: failed, rc=");
Serial.print(client.state());
Serial.println("DEBUG: try again in 5 seconds");
#endif
// Wait 5 seconds before retrying
for (int i = 0; i < 500; i++) {
if ( checkButton() == 1) {
ledState = !ledState;
setLightState();
delay(10);
}
}
}
}
}
void loop() {
if (!client.connected()) {
#if defined(fDebug)
Serial.println("Reconnect");
#endif
reconnect();
}
//Get the current button state
// int reading = digitalRead(TouchInput);
// //De-bounce the button
// if (reading != lastButtonState){
// lastDebounceTime = millis();
// }
// if ((millis() - lastDebounceTime) > debounceDelay) {
// // whatever the reading is at, it's been there for longer
// // than the debounce delay, so take it as the actual current state:
//
// // if the button state has changed:
// if (reading != buttonState) {
// buttonState = reading;
//
// // only toggle the LED if the new button state is HIGH
// if (buttonState == HIGH) {
// ledState = !ledState;
// }
// // set the LED:
// setLightState();
// publishLightState();
// }
// }
// // save the reading. Next time through the loop,
// // it'll be the lastButtonState:
// lastButtonState = reading;
// delay(64);
int b = checkButton();
yield();
if (b == 1) {
ledState = !ledState;
setLightState();
publishLightState();
}
if (b == 2) {
publishClickState();
}
if (b == 3) {
// Not Used
}
if (b == 4) {
publishLongPushState();
}
yield();
client.loop();
yield();
}
int checkButton() {
int event = 0;
buttonVal = digitalRead(TouchInput);
currentTime = millis();
// Button pressed down
if (buttonVal == LOW && buttonLast == HIGH && (currentTime - upTime) > debounce)
{
downTime = currentTime;
ignoreUp = false;
waitForUp = false;
singleOK = true;
holdEventPast = false;
longHoldEventPast = false;
if ((currentTime - upTime) < DCgap && DConUp == false && DCwaiting == true) DConUp = true;
else DConUp = false;
DCwaiting = false;
}
// Button released
else if (buttonVal == HIGH && buttonLast == LOW && (currentTime - downTime) > debounce)
{
if (not ignoreUp)
{
upTime = currentTime;
if (DConUp == false) DCwaiting = true;
else
{
event = 2;
DConUp = false;
DCwaiting = false;
singleOK = false;
}
}
}
// Test for normal click event: DCgap expired
if ( buttonVal == HIGH && (currentTime - upTime) >= DCgap && DCwaiting == true && DConUp == false && singleOK == true && event != 2)
{
event = 1;
DCwaiting = false;
}
// Test for hold
if (buttonVal == LOW && (currentTime - downTime) >= holdTime) {
// Trigger "normal" hold
if (not holdEventPast)
{
event = 3;
waitForUp = true;
ignoreUp = true;
DConUp = false;
DCwaiting = false;
//downTime = millis();
holdEventPast = true;
}
// Trigger "long" hold
if ((currentTime - downTime) >= longHoldTime)
{
if (not longHoldEventPast)
{
event = 4;
longHoldEventPast = true;
}
}
}
buttonLast = buttonVal;
return event;
}Ez egy SONOFF Touch kódja. Ha a checkButtont használom a loopba lévő kikommentezett rész helyett akkor random kifagy stack overflow ra hivatkozik. Mit rontottam el?
-
brickm
őstag
Sziasztok!
Az a helyzet, hogy tegnap még feltudtam csatolni a wifire az ESP8266-01-et. Most viszont majdnem minden programra ír ki valami errort.
Pl:-- print ap list
function listap(t)
for k,v in pairs(t) do
print(k.." : "..v)
end
end
wifi.sta.getap(listap)erre dobja:
> -- print ap list
function listap(t)
for k,v in pairs(t) do
print(k..> " : "..v)
end
end
wifi.sta.getap(listap)
stdin:1: unexpected symbol near '" : "'
>Azt figyeltem meg, hogy valami karakterkódolási baj lehet néha, mert pl a wifi SSID-met is felbontja pl TP>>LINK_B= stb, természetesen a >> nincs benne, ő teszi bele. Esetleg valakinek valami ötlete?
-
Teasüti
nagyúr
válasz
ngabor2
#7476
üzenetére
Ha megnézed a relé adatlapját, azon rajta lesz milyen áram kell a tekercs stabil behúzásához.
Songle esetén pl. az 5V-oshoz 3,7V kell minimum. De Songle-ből van 3V-os is.
Viszont ezekhez az alacsony feszültségűekhez rendre 70 és 120 mA áram kell, szóval sehogy se ajánlott közvetlen az ESP lábára kötni őket. Tranzisztorral kell meghajtani és védődiódát kell berakni! -
brickm
őstag
Most így áll a dolog.
ESP8266 flasher-rel rátettem a nodemcu_integer_0.9.5_20150318.bin -t
most 9600-as baudrate-tel elérem, comporton és ezt írja:NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4
lua: cannot open init.lua
>
----------------------------
No files found.
----------------------------
>
Total : 549941 bytes
Used : 0 bytes
Remain: 549941 bytesEz most jó így? Innen hogyan tovább?
-
Janos250
őstag
válasz
ngabor2
#7476
üzenetére
"Okozhat-e gondot" Tegyél be egy diódát!
"5V-os relét a 3.3 V-os jelszint kapcsolja-e"
Reléje válogatja, de mindenképp illesztő használata a korrekt.
"egy ilyen modul"
Na, olyan nem :-) (nézd meg, mit linkeltél!)
Az órákig járás nem probléma. Nekem kb egy hónapja megy egy ESP32 szerver kiakadás nélkül. Egy WiFi routerhez kapcsolódik, azon keresztül tudom a "világból" elérni. -
ngabor2
nagyúr
Adott egy Arduino és rákötve az egyik out-ra állított digital pin-re (pl. 3) egy 5V-os relé. Működik is gond nélkül. Okozhat-e gondot, ha erre a lábra (és a relére) direktben rákapcsolom az 5V-ot? Mert akkor "hardveresen" be tudnám programozni egyetlen plusz vezetékkel egy lámpa kézi bekapcsolását, nem kellene az egész programomat átbuherálni.
Amúgy hamarosan ESP32-re tervezem költöztetni, ott majd megpróbálom neten keresztül vezérelhetővé tenni. Kérdés, hogy az 5V-os relét a 3.3 V-os jelszint kapcsolja-e. Ha nem, akkor egy ilyen modul megoldhatja a gondomat? Ha jól sejtem, itt nem lesz gond a kommunikáció sebességével, hisz csak "kitart" egy jelszintet. Viszont azt órákig kellene tartani, nem tudom, hogy ezek alkalmasak-e arra.
-
vargalex
félisten
válasz
fpeter84
#7454
üzenetére
Én is gondolkodtam a deep-sleep-el megvalósított energiatakarékos hőmérő megoldasomnál, hogy a DS18B20-nak valamelyik GPIO-ról adok VCC-t, de egyrészt egyébként is minimális a fogyasztása, másrészt időm nem volt még utánaolvasni/tesztelni, hogy mennyivel kellene előbb feszt adni neki, hogy a mért érték kinyerhető legyen belőle. Ez utóbbi idő bármekkora is, sokat vesztenék azzal, hogy ezalatt nem deep sleep-ben van az ESP8266. Így én ennél a projektnél elvetettem.
Persze, ha nem a minél alacsonyabb fogyasztás a cél akkor abszolút korrekt megoldásnak érzem én is, ha az esp8266 által biztosított áramerősség elegendő. -
fpeter84
senior tag
ez valahol hasonló, mint amikor a marketingosztály azt adja parancsba az autóknál hogy márpedig 30-50e km-es olajcsereperiódus kell, a mérnökök meg fogják a fejüket hogyha rajtuk múlna akkor még a 15e-et is inkább csökkentenék... én inkább a mérnököknek hiszek - lehet pesszimisták, és lehet tényleg bírja a többet is valameddig - de mint ahogy az általad linkelt oldalon is említik:
The ESP32 does actually have an internal snapback circuit that protects it from overvoltage; in theory you should be able to feed it a fair amount of volts more. However it stresses the pad silicon (due to increased electron tunneling, iirc) and the long term effects aren't known so it's not in the datasheet.
-
-
-
fpeter84
senior tag
Fizikailag lehet bírja egy darabig, esetleg nem jön ki belőle az éltető füst azonnal, de a specifikációik szerint nem, tehát nem terveznék vele:
ESP8266 - 23. oldal 5.1. Electrical Characteristics - a tápfesz és a VIH is max 3.6V lehet
Az ESP32 picit összetetteb rendszer, itt a lábak a mux-tól függően kaphatják a VIO-t a maggal közös VDD3P3_CPU ágról valamint a VDD_SDIO 1.8-3.3V ágáról is, a táp pedig a 42dik oldal 5.1 Absolute Maximum Ratings szerint max 3.6V lehet
-
-
-
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. -
-
_q
addikt
válasz
Janos250
#7412
üzenetére
Úgy értettem, ha kell +5 V. Eddigiekben amivel találkoztam fejlesztői kártyán volt 5 V ami jól jött egyes szenzorok esetében. Most hirtelen csak egy szervo motor jut eszembe ahol kellene, esetleg hőmérséklet szenzorok között is akad vagy bizonyos IC-k igényelhetnek 5 V-ot.
Ha jól olvastam az ESP panelen nincs meg az 5 V kimenet.
-
modeller
aktív tag
válasz
Janos250
#7408
üzenetére
Szivesen vennék egy arduino-s példát hogy lehet akár a legtriviálisabb dolgot is a másik magon futtatni.
Simán lehet, hogy valamit elnézek, kb 1 hónapja láttam először esp32-tAzért érdekelne, mert kimondottan fogyasztás-kritikus, elemről (reményeim szerint) akár 1 évig is működő dolgokat próbálok csinálni és ahhoz nagyon jó volna a co-processzort beüzemelni. De asm szintig nem vagyok hajlandó elmenni, IDF-ezni is csak ha muszáj.
-
ngabor2
nagyúr
Szolgálati közlemény!
Úgy tapasztalom, hogy a topik egyre gyakrabban kezd elkanyarodni a címtől, ami nem probléma, inkább a technikai fejlődést követi. Ezért új címjavaslatokat várnék, mire lehetne átnevezni, hogy a kereső megtalálja, ha valaki a témában keres. Az Arduino az mindenképp benne maradna, de kiegészíteném az ESP8266/ESP12/ESP32 résszel. De milyen összefoglaló, könnyen idevezető nevet lehetne adni ezeknek?
Várom és köszönöm a címjavaslatokat.
-
vargalex
félisten
válasz
fecske13
#7382
üzenetére
Szia!
Szóval, a kód:
#include <ESP8266WiFi.h>
#include <Wire.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <ESP8266HTTPClient.h>
#include <time.h>
#define TEMPERATURE_PRECISION 11
#define REPORT_INTERVAL 60 // in sec
#define INTERVAL_CORRECTION 1.01 //1.06001
//AP definitions
#define FIRST_SSID "SSID1"
#define FIRST_PASSWORD "PASS1"
#define SECOND_SSID "SSID2"
#define SECOND_PASSWORD "PASS2"
#define UPDATEURL "http://az.en.szerverem.hu/updatesensor.php"
#define ONEWIRE_GPIO 2
#define VCC_ADJUST 1.0
#define MAXRTCDATACOUNT 50
#define MINPOSTCOUNT 10
#define NTPSERVER "time.kfki.hu"
ADC_MODE(ADC_VCC);
struct {
uint32 lastTime;
int cnt;
float temperatures[MAXRTCDATACOUNT];
float battery[MAXRTCDATACOUNT];
} rtcData;
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONEWIRE_GPIO);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
// device addresses
DeviceAddress DSAddress;
// device address in char array
static char DSAddressStr[18];
static char *hex = "0123456789ABCDEF";
int deviceCnt;
char *ap_ssid = NULL;
char *ap_password;
HTTPClient http;
boolean setSNTPTime(char *NTPServer) {
unsigned long entry=millis();
configTime(0,0,NTPServer);
while (millis()-entry<5000 && time(NULL)<3600) {
delay(500);
}
if (time(NULL)>100) return true;
else return false;
}
void scanWifi() {
WiFi.mode(WIFI_STA);
WiFi.disconnect();
delay(100);
Serial.println("Scanning for wireless networks");
// WiFi.scanNetworks will return the number of networks found
int n = WiFi.scanNetworks();
Serial.println("scan done");
if (n == 0)
Serial.println("no networks found");
else
{
Serial.print(n);
Serial.println(" networks found");
ap_ssid = NULL;
for (int i = 0; i < n; ++i)
{
// Print SSID and RSSI for each network found
Serial.print(i + 1);
Serial.print(": ");
Serial.print(WiFi.SSID(i));
Serial.print(" (");
Serial.print(WiFi.RSSI(i));
Serial.print(")");
Serial.println((WiFi.encryptionType(i) == ENC_TYPE_NONE) ? " " : "*");
if (WiFi.SSID(i) == FIRST_SSID) {
ap_ssid = FIRST_SSID;
ap_password = FIRST_PASSWORD;
}
if (WiFi.SSID(i) == SECOND_SSID) {
ap_ssid = SECOND_SSID;
ap_password = SECOND_PASSWORD;
}
}
}
if ( ap_ssid == NULL) {
Serial.println("Defined SSID-s not found. Resetting.");
ESP.restart();
}
Serial.println("");
}
void connect() {
// Connecting to Wifi.
Serial.println();
if (WiFi.SSID() == "") {
// Never connected, scanning for wireless networks
scanWifi();
WiFi.mode(WIFI_OFF);
WiFi.mode(WIFI_STA);
Serial.print("Connecting to ");
Serial.println(ap_ssid);
WiFi.begin(ap_ssid, ap_password);
}
else {
Serial.print("Connecting to ");
Serial.println(WiFi.SSID());
}
unsigned long wifiConnectStart = millis();
while (WiFi.status() != WL_CONNECTED) {
// Check to see if
if (WiFi.status() == WL_CONNECT_FAILED) {
Serial.println("Failed to connect to WiFi. Please verify credentials: ");
scanWifi();
WiFi.mode(WIFI_OFF);
WiFi.mode(WIFI_STA);
Serial.print("Connecting to ");
Serial.println(ap_ssid);
WiFi.begin(ap_ssid, ap_password);
ESP.restart();
}
delay(500);
Serial.print(".");
// Only try for 5 seconds.
if (millis() - wifiConnectStart > 15000) {
Serial.println("Failed to connect to WiFi");
scanWifi();
WiFi.mode(WIFI_OFF);
WiFi.mode(WIFI_STA);
Serial.print("Connecting to ");
Serial.println(ap_ssid);
WiFi.begin(ap_ssid, ap_password);
ESP.restart();
}
}
Serial.println("");
Serial.println("WiFi connected");
Serial.print("IP address: ");
Serial.println(WiFi.localIP());
}
// function to return device address as a String
String deviceAddressToStr(DeviceAddress deviceAddress)
{
String ret = "";
for (uint8_t i = 0; i < 8; i++)
{
// zero pad the address if necessary
ret = ret + hex[DSAddress[i] / 16];
ret = ret + hex[DSAddress[i] & 15];
}
return ret;
}
// getting temperature from DS18B20 sensor
float getTemperature() {
float tempC = 150;
// Start up the library
sensors.begin();
if (!sensors.getAddress(DSAddress, 0)) {
Serial.println("Unable to find address for Device 0");
}
else {
// set the resolution
sensors.setResolution(DSAddress, TEMPERATURE_PRECISION);
sensors.requestTemperatures();
tempC = sensors.getTempC(DSAddress);
Serial.print("Temp C for device ");
Serial.print(deviceAddressToStr(DSAddress));
Serial.print(" ");
Serial.println(tempC, 4);
}
return tempC;
}
// POST data as JSON to the server
bool sendData(DeviceAddress dsAddress) {
bool ret;
int i;
String postStr = "{\"sensorAddress\": \"" + deviceAddressToStr(dsAddress) + "\", \"values\": [";
for (i=0; i<rtcData.cnt; i++) {
if (i>0) {
postStr += ",";
}
postStr += "{\"offset\":\"" + String(i-rtcData.cnt+1) + "\", \"temperature\":\"" + String(rtcData.temperatures[i], 3) + "\", \"voltage\":\"" + String(rtcData.battery[i]) +"\"}";
}
postStr += "]}";
if (http.begin(UPDATEURL)) {
Serial.print("Post string: ");
Serial.println(postStr);
http.addHeader("Content-Type", "application/json");
int httpCode = http.POST(postStr);
Serial.print("HTTP POST return code: ");
Serial.println(httpCode); //Print HTTP return code
if (httpCode>0) {
ret = true;
}
else {
Serial.print("[HTTP] POST... failed, error: ");
Serial.println(http.errorToString(httpCode).c_str());
ret = false;
}
http.end();
}
else {
ret = false;
}
return ret;
}
void setup() {
unsigned long startTime = 0;
Serial.begin(115200);
// Wait for serial to initialize.
while (!Serial) { }
Serial.println("");
Serial.println("Dallas Temperature Sensor Control and post data to server (deep sleep version with RTC memory)");
Serial.print("Reset reason: ");
Serial.println(ESP.getResetReason());
if (ESP.getResetReason() != "Deep-Sleep Wake") {
Serial.println("Non deep-sleep wake. Clearing RTC data storage.");
rtcData.cnt = 0;
rtcData.lastTime = 0;
ESP.rtcUserMemoryWrite(0, (uint32_t*) &rtcData, sizeof(rtcData));
scanWifi();
WiFi.mode(WIFI_OFF);
WiFi.mode(WIFI_STA);
Serial.print("Connecting to ");
Serial.println(ap_ssid);
WiFi.begin(ap_ssid, ap_password);
startTime = micros();
}
if (ESP.rtcUserMemoryRead(0, (uint32_t*) &rtcData, sizeof(rtcData))) {
float temp = getTemperature();
rtcData.cnt++;
rtcData.temperatures[rtcData.cnt-1] = temp;
rtcData.battery[rtcData.cnt-1] = ESP.getVcc() * VCC_ADJUST;
Serial.print("CNT: ");
Serial.println(rtcData.cnt);
if (rtcData.cnt>=MINPOSTCOUNT) {
connect();
Serial.print("Setting NTP time with server ");
Serial.print(NTPSERVER);
while (!setSNTPTime(NTPSERVER)) Serial.print(".");
Serial.println("");
uint32 seconds = time(NULL);
if (seconds != 0) {
Serial.print("seconds: ");
Serial.println(seconds);
Serial.print("rtcData.lastTime: ");
Serial.println(rtcData.lastTime);
uint32 waitSecs;
if (rtcData.lastTime == 0 || rtcData.lastTime+rtcData.cnt*REPORT_INTERVAL< seconds) {
waitSecs = 0;
}
else {
waitSecs = (rtcData.lastTime+rtcData.cnt*REPORT_INTERVAL) - seconds;
}
Serial.print("Waiting ");
Serial.print(waitSecs);
Serial.println(" seconds before posting data");
delay(1000*waitSecs);
seconds = time(NULL);
startTime = micros();
if (sendData(DSAddress)) {
Serial.print("sendData returned true, setting cnt to 0 and lastTime to ");
Serial.println(seconds);
rtcData.cnt=0;
rtcData.lastTime = seconds;
}
}
else {
Serial.println("time function returned 0");
}
}
ESP.rtcUserMemoryWrite(0, (uint32_t*) &rtcData, sizeof(rtcData));
}
else {
Serial.println("RTC Memory read failed");
}
Serial.print("startTime: ");
Serial.print(startTime);
Serial.println(" microseconds");
Serial.print("Entering to deep sleep for ");
if (rtcData.cnt+1<MINPOSTCOUNT) {
Serial.print((REPORT_INTERVAL*1000*1000-(micros()-startTime))*INTERVAL_CORRECTION);
Serial.print(" microseconds and waking up with ");
Serial.println("wifi disabled");
ESP.deepSleep((REPORT_INTERVAL*1000*1000-(micros()-startTime))*INTERVAL_CORRECTION, WAKE_RF_DISABLED);
}
else {
Serial.print(((REPORT_INTERVAL-10)*1000*1000-(micros()-startTime))*INTERVAL_CORRECTION);
Serial.print(" microseconds and waking up with ");
Serial.println("wifi on");
ESP.deepSleep(((REPORT_INTERVAL-10)*1000*1000-(micros()-startTime))*INTERVAL_CORRECTION, WAKE_RF_DEFAULT); //WAKE_NO_RFCAL);
}
}
void loop() {
// put your main code here, to run repeatedly:
}A lényege: kb. percenként méri a hőmérsékletet és a VCC-t, ezeket tárolja RTC User memóriába. A MINPOSTCOUNT-ban meghatározott ébresztés valamivel korábban történik, hogy NTP-n időt szinkronizáljon, így a POST pontosan 10 percenként tud megtörténni (sajnos a deep sleep időmérése valamiért nem túl pontos). A szervernek JSON-ban küldi az adatokat (sensor address, majd a hőmérséklet/feszültség és offset (aktuális időpillanathoz képest időeltolás percben).
2 SSID-t és hozzá tartozó jelszavakat definiáltam, mivel 2 helyszínen szeretnék ledobni ilyen szenzorokat. Így a wifi scan-ból tudja majd a kód, hogy melyik látható a 2 közül és ahhoz csatlakozik.
A percenkénti méréshez wifi bekapcsolása nélkül ébresztem az ESP8266-ot, így kisebb a fogyasztása és néhány ms alatt végez is a méréssel, tárolással. Minden 10. mérésnél (vagy ha valamiért nem tudta POST-olni az adatokat, akkor minden következő mérésnél) wifi bekapcsolásával ébred a korábban említett rövidebb sleep után, csatlakozik a wifi-hez, NTP-n szinkronizál, POST-ol és elrakja RTC memóriába a POST idejét. A következő POST-kor ehhez képest történik a várakozás.Képet most nem készítettem az eszközről, de nekem az ESP8266-ok (ESP-12F) nálam ilyen boardra vannak felforrasztva. Ennek a hátoldalán ott a hely az LDO-nak (ahogy írtam, HT7333-at használok). Az LDO-t beforrasztva az előlapon található középső 0 ohm-os ellenállást le kell forrasztani. Így a board VCC lábára kötött feszültség az LDO-n keresztül jut el az ESP8266-ig, azaz annak VCC-jén már 3.3V fog megjelenni. Ennek megfelelően az ESP VCC lábát kötöttem össze a CH_PD-vel (mert ugye az alaplap VCC-jéről a Li-Ion cella feszültségét kapná, ami induláskor kb. 4,2 V). Az ESP VCC lábáról kapja a feszültséget a DS18B20 is, valamint az ESP VCC és GND lába közé a stabil tápellátás érdekében egy 1000 uF-os kondit tettem. A DS18B20 GND lába GND-re, a DATA lába a GPIO2-re van kötve (ez utóbbit konstansként definiáltam a proggiban). Ennyi a bekötés, nincs semmi varázslat.
Azóta is stabilan megy mindkét példány. Mindenképpen beszámolok, hogy 1 cellával meddig bírja az eszköz. -
_q
addikt
válasz
Janos250
#7392
üzenetére
Régebben nem volt szerintem akkora gond még. Mikor kezdtem az MSP430-as Texas Instruments mikrovezérlőkkel, akkor egyszerűbb volt a portok BIT szinten történő beállítása, legalább is az ESP32-es kóddal összehasonlítva. Persze ott nem is volt lehetőség minden portot mindenféle módban használni.
Ahogy rugalmasabbá válik a programozás (portkezelést mint példa), mellette meg úgy bonyolodik is. Viszont Arduino kerek segítenek megtalálni az egyensúlyt. Egymást kiegészítve jönnek fel párhuzamosan. MSP430 mikor elkezdett terjedni, még nem csak BIT szinten lehetett programozni, ma meg már Arduino keretek között is lehet. Fejlődik ez a terület is, ami nekünk csak jó.
-
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
Janos250
#7389
üzenetére
Én STM32-t keil-be programoztam függvénykönyvtárak segítségével. Regiszter vagy alacsonyabb assembly programozás sose vonzott, nem is terveztem használni, tehát ez ennek dokumentált hiányossága nem zavaró számomra.
Így ha jól értem az ESP32 + Arduino kombó nekem való, ráadásul a bluetooth (BLE vagy minden féle bluetooth nem tudom) kommunikációs hiányosságokat eltekintve mindent meg lehet Arduino környezetben valósítani. Meglátom, ha megjön a valóságban mi lesz.Köszi a részletes leírást.
-
Janos250
őstag
Teasüti jól összefoglalta a dolog lényegét, pár dolgot tennék hozzá:
Az Arduino ugyebár egy de facto "programozási szabvány". Azt mondja ki, hogy ha portolják egy kontrollerre, akkor bizonyos függvényeket, osztályokat kötelező az adott kontroller "nyelvén" megcsinálni, ami utána az "Arduino része" lesz. Ez nagyon nagy könnyebbség. Az STM32-re is portolták az Arduinot, elég jó is.
Az ESP32 kissé más, mint a többi:
Először is adott két mag. Azonkívül az általam ismert kontrollereknél a perifériák regisztereit memória címen símán elértem. Többnyire adott volt, hogy melyik periféria melyik lábhoz tartozik. Na, ez az ESP32-nél nem ennyire egyszerű. Bevezettek egy mátrixot, ezen keresztül lehet elérni a perifériákat. Ez nagyfokú rugalmasságot biztosít, mert bármelyik periféria bármelyik lábhoz kapcsolható, de egyben bonyolultságot is, mert meg kell mondanod,hogy mi mihez kapcsolódjon. Aztán, hogy még bonyolítsuk a dolgot, a perifériák alapállapotban "alszanak", pl. órajelet se kapnak.
Így még a hozzá tartozó regisztereket se tudod se írni, se olvasni. Először kell nekik órajelet adni, és resetelni, utána írhatók, olvashatók a regiszterei. Az órajel adás és a resetelés elvileg egyszerű: elérhető regiszterekben az adott perifériához tartozó bitet kell beállítani órajelhez, illetve törölni a resethez.
Igen ám, csakhogy az ESP azt nem mondja meg, hogy melyik perifériához melyik bit tartozik. Sebaj, kinézzük az illesztő programokból, gondolja Móricka. Viszont az illesztő programok lefordított assembly programok, aminek a forráskódját az ESP nem hozta nyilvánosságra eddig. Tehát a processzor közeli programozás még egy ideig macerás lesz. Az Arduino rendszerben viszont minden elég jól ki van dolgozva.
Tehát:
Az ESP megcsinálta az alapvető kezelést biztosító assembly nyelvű rutinokat.
Erre épülve készült el rá a freeRTOS. Ezt használja az IDF is. A freeRTOS-ra épülve portolták az Arduinora.
A freeRTOS függvényeit - általában - Arduino rendszerben is lehet használni, hiszen az Arduino "szabvány" függvényei is ebben íródtak.
Összefoglava:
Arduinoban programozása kényelmes, nagyon gyors, rengeteg a periféria, a két mag más programozási technikákat is lehetővé tesz, de ha processzor közeli módon akarod használni, az azért még jelenleg szívás. -
ngabor2
nagyúr
Én is kacsingatok az ESP32 felé. Viszont ebből egyáltalán nem, ESP12-ből is elvétve lehet találni olyat, amire külső antennát lehet csatlakoztatni. Ez zárt fém háznál viszont igen hasznos tud lenni.
Rá lehet valahogy mégis tenni, vagy könnyebb elrontani mint jól megcsinálni?
-
Teasüti
nagyúr
Nagy overhead a ram és rom méreteket illetően, bár van hely bőven így ez nem akkora probléma.
Emiatt ugye a számítási teljesítmény egy része is elúszik. Bár így is 100x gyorsabb egy UNO-nál, szóval mindegy is.
Egyfajta virtualizációhoz lehetne hasonlítani.Mondjuk nem hiszem, hogy nálam összetettebb felhasználása volna itt még vkinek (73 KB-os forráskód +könyvtárak, amiből a BLE megeszi a rom a közel 70%-át) és jómagam sem futottam még bele se teljesítmény se tárterület problémába. Mondjuk még szeretném majd kipróbálni az OTA programfeltöltést. Arra számítok, hogy az még egy jelentősebb szeletet elvesz a tárból.
A wifi azt hiszem teljes támogatottságot élvez, a BLE már működőképes, de még "béta" állapotú és így nem fejleszt rá egyetlen 3rd party sem. Ez azt jelenti, hogy a valós alkalmazásokban sok mindent magadnak kell megoldani.
A perifériák közül eddig én egyedül csak az RMT-t használtam, így a többiről nem tudok nyilatkozni.
Az Arduino függvények úgy tudom működnek mind, illetve nem tudok példát hozni az ellenkezőjére.
Nekem az UNO-ra írt programom egy az egyben lefordult ESP32-re is (az Atmel-re írt könyvtárak nélkül természetesen), így ez teljes értékűnek tekinthető szerintem.Nálam is tervben volt az IDF megismerése és az alacsonyabb C nyelv tanulgatása, de így hogy megy amit akartam Arduino-ban is, így nekem nem is fontos.
Meg a mai világban már nem divat a nehezebb úton menni és szopatni magad a hardver specifikus utasításkészlettel és telefonkönyv módszerrel regisztereket programozni, amikor némi overhead árán, de pár absztrakciós réteggel feljebb is meg lehet oldani a problémát könnyen és gyorsan, specializált tudás nélkül.
Persze nem is lesz olyan hatékony a kód, de ki nem szarja le, érted... Ez nem a Crysis, hogy ultra grafikán kisajtoljak minden fps-t a vasból.
Senkit nem érdekel mit csinál a digitalRead(), amíg megvan az eredmény.
Példánál maradva:extern int IRAM_ATTR __digitalRead(uint8_t pin)
{
if(pin < 32) {
return (GPIO.in >> pin) & 0x1;
} else if(pin < 40) {
return (GPIO.in1.val >> (pin - 32)) & 0x1;
}
return 0;
}Na most e szerint az sem mindegy melyik lábat olvasom. Programozzon így az, akinek két anyja van!
Én inkább beírom, hogy digitalRead() és együtt élek az overhead-del. -
_q
addikt
válasz
Janos250
#7354
üzenetére
Olvasgattam kicsit. Azt íták, hogy az ESP IDF környezetben lehet a leginkább kihasználni az ESP32-t. Arduinot fejlesztgetik, ezzel is használható, de elsődlegesen nem ez az ajánlott.
Én Arduino IDE környezetben szeretném a programozást megoldani. Kérdésem az, hogy mit tapasztaltatok, milyen funkció nem az igazi, mi nincs implementálni ami miatt nem használható ki az ESP32?
-
vargalex
félisten
válasz
vargalex
#7023
üzenetére
Jelentem, 1 hete szépen megy 2 példány az ESP8266+DS18B20 RTC-s megoldásból. Végül azt választottam, hogy minden 10. mérésnél kicsivel hamarabb ébresztem a cuccot deep sleep-ből, szinkronizálok NTP-n, ha kell, akkor várok és post-olok. Természetesen RTC-be az NTP időt (unix timestamp) is leteszem, hogy tudjak mihez viszonyítani a következő post-kor. Az ESP-vel mérem a feszültséget is (getVcc függvénnyel), amit 10 percenként tárolok, de ugye ez a HT7333 által már csökkentett feszültséget méri. Ez nyilván nem változott az indulás óta. Azért rámértem multiméterrel is, most 4,15 V a cella feszültsége. Sajnos induláskor nem mértem, hogy megvolt-e a 4,2V, így sokat még nem jelent. Illetve mindkét példány bontott (Lii-500 szerint kb. 2000 mAh-s példányok) notebook akkuból származik. Kíváncsi vagyok, hogy meddig fog üzemelni (figyelem a mért feszültséget, 2,8-2,9V körül majd cserélem). Ha érdekel valakit, szívesen megosztom a kódot, illetve bekötést, valamint képet is csinálhatok, bár még a kinézet szépsége nem volt cél.
-
_q
addikt
válasz
Tankblock
#7369
üzenetére
Köszi. Végül egy külső tápcsatis nélkülit rendeltem. Ha esetleg kell akkor magam beforrasztok egy csatit pluszba.
Addig is míg megjön. Tudtok ajánlani oldalt, amit érdemes olvasgatni ESP 32S-el kapcsolatban? Kezdve az arduino környezet beüzemelésével, ahol adatlapot találok a development board-ról, esetleg hasznos kiinduló minta példákat tartalmazó oldalt?
-
Teasüti
nagyúr
válasz
CHIPman
#7362
üzenetére
Semminek, hisz adat nélkül nem kapcsol be. Viszont ha adsz az adatbusznak egy kis interferenciát (vagy töltést az ujjaddal), akkor lehet felvillan néhány led.
Ezekhez kell egy adatfolyam, ami pixelenként 24 bitből áll (ugye három színkomponens 8 biten), és egy bit a szalag protokollja szerint egy magas és egy alacsony logikai jelszint adott időzítéssel. Szóval ezt te nem fogod úgy vezérelni, mint egy analóg szalagot, vagy egy ledet.
Ezekhez alapesetben egy könyvtárat szokás használni, amit a mikrovezérlődhöz választasz. Mint pl az Adafruit féle Neopixel, ami azt hiszem működik ESP-vel is.
Ezekben találsz példákat az animációkra.
Szóval itt animációt programozunk, jobban mondva egyenként ki kell számolni a pixelek színeit és berakni egy uint8_t tömbbe, majd ezt küldi ki a szalagra a könyvtár megfelelő függvénye. -
Teasüti
nagyúr
válasz
CHIPman
#7352
üzenetére
Hogyne lenne róla leírás, ne viccelj!
WS2812b a leánykori neve, több száz oldal foglalkozik a témával. Hozzádobod, h ESP és garantálom lesz rá találat.
Annyit fűznék hozzá, hogy ha komolyabb projekten dolgozol, ahol a szalag meghajtásán kívül mást is kéne csinálni, akkor tudni kell, hogy jelenleg az ESP32-n kívül minden más szoftveresen kezeli a szalagot és az adatküldés blokkolja a programot. Tehát nem lehetnek megszakítások és így arra a rövidke időre megszűnik a beérkező adatok fogadása.
-
CHIPman
nagyúr
Üdv.
Már régóta van egy címezhető RGB led stripem, viszont 3 bemenetű, "+", "data" és "-". Értelemszerűen 5V-os. Nem találtam még olyan leírást, ami ehhez lenne írva, mindenhol a 4 bemenetűt látom.
ESP eszközeim vannak, minimálisan konyítok hozzá, de eddig még nem sikerül működésre bírnom a ledeket. (Nem címezhető stripet mosfettel már vezéreltem gond nélkül ESP-ről, csak ez nem megy.) Dolgozott már valaki ilyennel? -
_q
addikt
válasz
Janos250
#7348
üzenetére
Köszi a részletes leírást. Ezek szerint minimális eltérés van, pl.: Wemos tesz rá egy külsö táp csatlakozót is mint ami a lentebb képen látható és 1 reset gombot (ami szemmel látható különbség elsőre). WROOM esetén nincs külső táp csatlakozó, de van egy plusz gomb, gondolom programozható. Szignifikáns külnbség nem nagyon van közöttük. Illeve ide jöhetnek még az OLED kijelzős verziók, ahol már kicsivel nagyobb lábkiosztás vagy egyéb eltérések is felléphetnek.
Arduino-t akartam először a programozási könnyebbség miatt, de mivel ESP32 teljesítményben illetve modulokban is jobb, olcsóbban, így gyorsan tovább is léptem az arduino-n. Köszi a linkeket, valószínűleg ezek közül választok.Tankblock
Neked is köszi az észrevétel. Ha jól értem akkor a képen jelölt külső aksi/táp csatlakozóra érted, hogy fel van cserélve a VCC-GND kivezetés?
-
Janos250
őstag
válasz
Janos250
#7348
üzenetére
Még annyit, hogy itt látható, mi van ez ESP-WROOM-32 hibrid chipben:
https://github.com/boseji/ESP-Store/blob/d80a4bafb5d0d2b9f78954681f995429110383d6/Ref-Designs/ESP-WROOM-32/SCH/sch.pdf
De ha magadnak akarsz gyártani , a gerber adatok is megvannak:
https://github.com/boseji/ESP-Store/commit/d80a4bafb5d0d2b9f78954681f995429110383d6 -
Janos250
őstag
Én most nem tudok olcsót, általában min 1500 Ft körül vannak.
A verziók gyakorlatilag megegyeznek. Az ESP32 ugyebár az alap chip. Amikor ez megjelent, akkor pár gyártó gyorsan el is kezdett vele lapot gyártani. Mivel nagyon vártam az ESP32-t, én is rendeltem gyorsan tavaly ősszel 9000 Ft-ért egy ilyen panelt, ami azóta is a fiókban hever. Akkor még nem volt megfelelő támogatás hozzá.
Igen gyorsan megjelent az ESP32S, ami egy hibrid tokozás fém tokban, tartalmazza az ESP32 chipet, flash memóriát, és még pár alkatrészt. Aztán gyakorlatilag ugyanezt elkezdte gyártani az Espressif is, ESP-WROOM-32 néven. Ma már ez gyakorlatilag egyeduralkodóvá vált, ezt érdemes venni. Amit ESP32S megjelöléssel hirdetnek, ma már azok is általában ezt tartalmazzák.
Pl.: https://www.ebay.com/itm/ESP32-ESP32S-CH340G-Development-2-4GHz-Dual-Mode-WiFi-Bluetooth-Module-Antenna/282633370924?epid=866775664&hash=item41ce42fd2c:g
eMAAOSwv-ZZ9YZE
Én pl. ezeket használom, mert szeptember elején ezeket lehetett 1200 Ft körüli áron megvenni. Nem volt vele gondom:
https://www.ebay.com/itm/ESP-32S-ESP-32-Development-Board-2-4GHz-Dual-Mode-WiFi-Bluetooth-Antenna-Module/302252239864?hash=item465fa32bf8:g3kAAOSwTM5Yx~38
A különböző gyártók által gyártott lapok között nem különösebben lényeges az eltérés. A lábaknak a panelra írt elnevezése különböző, de azt általában tartalmazza az Arduino IDE, ha a megfelelő panelt választjuk ki.
A hardware\espressif\esp32\boards.txt fájlban láthatjuk, mennyi féle laphoz van meg a saját támogatás, de az ESP32S-et választva se szokott gond lenni. A lábak elnevezése, stb. a hardware\espressif\esp32\variants könyvtárban található verzióként.
USB mindenképpen legyen rajta. Az USB chipek közül ki melyiket szereti, az ízlés kérdése. Megfelelő driverrel mind jól működik tapasztalatom szerint. -
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
Na, akkor lássuk konkrétan, hátha mást is érdekel:
Láttam, hogy Teasüti egy kész könyvtárat használt a WS2812 led szalag vezérlésére. Innen jött az ötlet, hogy - játékból - kipróbáljam, hogy az elég bonyolult kész program helyett a "kézzel" való vezérlést használjam.
Ennek a szalagnak a vezérlése úgy történik, hogy a szalag minden egyes ledjéhez kiküldjük a saját színét, 24 biten. A kiküldés bitenként megy: pl. a 400 nanos hoszú impulzus jelenti a "0" értékű bitet, a 800 nanos az "1"-et.
Ha beállítok egy lábon magas sztintet, akkor ha ez 0 értékű bit, akkor 400 nano múlva kell levinnem alacsony szintre, ha 1 a bit értéke, akkor 800 nano múlva. Ezt kell ismételni a szalag minden egyes ledjére sorban egymás után, ahogy a szalagon vannak. Egy led színe 24 bit, tehát egy 100 ledből álló szalagra 2400 db. - az egyes led kívánt színei szerint - különböző hosszúságú impulzust kell kiküldeni.
Viszont, ha egy 400 nanos impulzus középén jön egy megszakítás, akkor mire "visszatér" a task, az már akár 800 nanos is lehet, tehát hibásan másik bitként értelmezi a led.
Na, ez talán a legtipikusabb példája az ESP32 "RTM" funkciójának. Az egyes impulzusok adatait feltöltöm egy megadott memória területre, és ráeresztem a hardvert, ami teljesen önállóan kiküldi ezeket az impulzusokat, igen nagy pontossággal, mert 15 biten írom le az impulzus hosszát. A 16. bit jelzi, hogy a megadott ideig L vagy H szinten kell lenni az adott lábnak.
Ezt nevezi az ESP32 RTM-nek. Eredetileg az infrás távvezérlők szimulálására ajánlják, mert lehet úgy programozni, hogy egy magasabb vivőfrekvenciát moduláljon az adott hosszal.
Tehát - mint írtam - nem egy élő projekt problémájáról van szó, hanem kíváncsiságról. -
Teasüti
nagyúr
Üdv!
ESP32 és az RTOS task indítás érdekelne, ha van ezzel tapasztalat.
A kérdésem pedig, hogy milyen módon kezeli a kernel az éppen futó folyamatok újbóli meghívását?
xTaskCreate() függvény hívása, miközben már fut belőle egy példány.
Ilyenkor megszakítja az első példányt, el se indítja a második példányt, vagy párhuzamosan fut a kettő (vagy több)?
Egy ISR alapú meghíváson filózok, amit egy gombra kötött CHANGE állapotváltozás figyel. És itt jön a képbe a prell jelensége. (Illetve vmi vibráció, vmi zavar amivel szembesülök járó motornál a féklámpa kapcsoló felől, de eddig lusta voltam megnézni szkóppal.) És mivel delay()-ek vannak a folyamatban, ezért könnyen előfordulhat, hogy újból meghívásra kerül a folyamat annak végezte előtt.szerk: az RTOS kérdés az érdekes most, nem a jel szűrése.
Köszönöm! -
dzz
aktív tag
válasz
Janos250
#7301
üzenetére
Én linuxon élek már a 90-es évek közepe óta, szeretek mindent parancssorból intézni. Pl. az openwrt-nek megfelelő shell képességei vannak, valami ilyesmire gondoltam ESP32-n, tehát nem a PC oldalról hanem az eszközön magán. Mondjuk kicsi a memória minden ilyesmire, de csak feldobtam a kérdést, még nem jártam rendesen körbe az ESP képességeit csak meglepett, hogy mennyivel több a korábbi Arduino-s kütyüimnél
-
dzz
aktív tag
Nos a héten megérkezett az ESP32. Most játszadozom vele és ismerkedünk (Hello World megvolt
most épp duktape van rajta) Viszont az egyszerűbb modulokhoz képest lényegesen többet tud, ez az arduino nem az az arduino amit eddig használtam (mármint eddig ennyire komplex nem volt a kezemben). A ledek ki/be kapcsolása és ilyesmi volt eddig terítéken. Valaki botlott már olyanba, hogy egy unix szerű sh/bash-t használhassunk? Agyament ötleteim támadtak és egy ilyesmi tetszene ha lenne készen. Nem kutakodtam utána nagyon, leginkább az érdekelne, hogy valaki futott-e bele ilyenbe. -
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?
-
Teasüti
nagyúr
válasz
Spuri2000
#7252
üzenetére
Nem bonyolult, csak ránéztem és elszörnyedtem. Egy igazi kódhuszár erre köp egyet és tovább lapoz.
Tényleg hasznos az a "programkód" szövegformázás, így behúzza a sorokat a struktúrának megfelelően a fórum motor. Én pl már ott ráncoltam a szemöldököm, hogy három kapcsos zárójel egymás után.
Ami azonnal átlátható megfelelő formázással, de így meg át kell nyálazni, hogy melyik hova tartozik, ki kivel van.(#7250) dzz
Hát ha a karórámból indulok ki, ami BLE-vel kapcsolódik, akkor nem sok.
Két falon keresztül már megszakad a jel (mondjuk kimegyek a fürdőbe egyazon emeleten és hisztizik az óra, hogy megszakadt a kapcsolat). Néha a saját testemmel le tudom árnyékolni, mikor pl összefonom a karjaim. De hát ugye okkal az a neve, hogy Bluetooth Low Power.
A klasszik BT ugyan erősebb, de az nincs implementálva még az ESP-IDF-ben se, nem hogy Arduino vonalon.
Én azt mondanám jó, ha megvan a 10-20 méter szabad rálátás esetén.
Viselhető eszközökhöz és kis hatósugarú mesh hálózatokhoz van kitalálva, nem arra, hogy kirakjunk egy állomást a semmi közepére. Persze ha kimész a helyszínre kiolvasni az adatokat, ahhoz amúgy megfelelő, mert viszont jó választás az akkumulátoros üzemhez. Sőt, akkus üzemhez én eleve nem is gondolkodnék másban. Állítólag megfelelő alkalmazásban a BLE kevesebbet fogyaszt, mint az elem önkisüléséből eredő merülés. A wifi-nek nem lesz hosszú üzemideje e szempontból. -
Teasüti
nagyúr
Terepen szerintem a BLE lesz a nyerő, hacsak nem akarsz a mobilnettel b@szakodni.
Ugye vagy a telón csinálsz egy hotspot-ot amihez az ESP tud kapcsolódni (és akkor a hotspot adatait gondolom FW-be kéne rakni, aztán másik setup-pal nem lesz működőképes), vagy az ESP-n wifi AP-t (ha lehet ilyet egyáltalán, Janos250 biztos tud rá mondani vmit), amihez a teló csatlakozik és lőttek a mobilnetnek a telón. -
dzz
aktív tag
válasz
Janos250
#7244
üzenetére
Ez logikus és nem kifejezetten saját megírt appra gondoltam, hanem a lényeg, hogy terepen adott lesz egy smartphone meg a „kütyü”
Tegnap megrendeltem egy LiPo pigback-es, kijelző nélküli ESP32-t, a jövő héten megérkezik. Kifejezetten tetszik, hogy első körben rajta van minden ami kezdésnek kell, a kimeneteken egyenlőre szimulálom LED-el a perifériákat. A többi majd apránként... -
Janos250
őstag
Mivel ESP-WROOM-32 van benne, nagy gond nem lehet. Ez az ESP32-nek a "gyári tokozott" verziója, tehát ez az alap. A display még egy kis hab a tortán, szerintem nagy gond nem lehet vele. Mondom én, aki még soha nem használtam a display-es verziót.
Eltérés abban lehet, hogy milyen lábszámok vannak a panelra szitázva, egyébként ugyanaz. -
dzz
aktív tag
Sziasztok!
Új világ nekem az ESP32 (az arduino is, bár már egy ideje játszadozom vele), kellene egy kis megerősítés (vagy épp az ellenkezője )A kérdésem, hogy ezek az eszközök mennyire használhatóak?
1
2
3Az érdekelne, hogy van ezeknek valami olyan jellegű eltérése, ami jelentősen eltérne az alap ESP-DEV programozásától.
Thx
-
Sikerült!
Ezt az esp32-es kis lapot lehet egyáltalán használni a shield v5-tel?
Másik kérdésem is van: Arduino uno-t lehet egyszerre használni a shield v5-tel meg a l293d sihelddel, vagy ezt benéztem és ha a motorvezérlő van rajta akkor már nincs lehetőség ultrahang szenzort meg vonalkövető infra szenzort plusz bluetoothot használni?
Ez a terv az unoval egyáltalán kivitelezhető? meghajtó motor+kormánynak motor, ultrahang szenzor(ok), vonalkövető szenzor, világítás a járműre (4 helyzetjelző+indexek+tolató lámpa stb), bluetooth távirányítás. Tehát ha nem távvezérelt, akkor mondjuk kövesse a padlóra ragasztott vonalat, de ha van alami akadály akkor annak ne menjen neki. -
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? -
Elnézést, hogy 3 lett, de van köztük majdnem 24 óra... Végigmentem tegap este a tutorialon, de még mindig nem látszik az esp32-es lap. Ott van a hardware mappában hozzá minden, amit itt írnak, de nem jelenik meg a válsztjató eszközök között. Még egy újratelepítést megpróbálok.
-
válasz
Victoryus
#7213
üzenetére
Közben találtam egy tutorialt Azt nem gondoltam, hogy ilyen lassú lesz a letöltés, a git gui ~30 perc volt, meg az esp32-elf-win32-1.22.0-73-ge28a011-5.2.0.zip is több, mint 40 perce jön. 90 megás az egész... (100megabites nettel, szóval náluk van a szűk keresztmetszet)
-
Megérkezett az esp32-es mini vezérlőm. Ezt hogy lehet működésre bírni az arduinós programból? A led villogtató programot akarom rátölteni, de hibát ír: avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x20 Hiba történt a vázlat feltöltése közben
Alaplap infó ismeretlen alaplapot ír, portok közül felsimerte, hogy az ötösön kommunikál.
Windows 10 eszközkezelőben a portoknál Silicon labs cp210x usb to uart bridge-ként ott van.
Nem tudom ugyanis elsőre mi az ajánlott. Eddig csak AVR boardjaim voltak, 1 hete használok STM32DUINO-t, és hát a kakaó , ami benne van, megtetszett nagyon. )
) MIELŐTT ELŐSZÖR ELINDÍTOD, csinálsz egy portable könyvtárat. Most már elindíthatod az arduino.exe-t. Ebbe töltöd le az ESP8266-ot a szokásos módon. A portable verzió nem akad össze a fenn lévő másik verzióval/verziókkal.
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.
eMAAOSwv-ZZ9YZE
Új hozzászólás Aktív témák
Hirdetés
ekkold- AMD vs. INTEL vs. NVIDIA
- Magisk
- Kerékpársportok
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Fejhallgató erősítő és DAC topik
- Megjelent a Poco F7, eurós ára is van már
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Debrecen és környéke adok-veszek-beszélgetek
- Bemutatkozott a Fairphone 6
- Anglia - élmények, tapasztalatok
- További aktív témák...
- Csere-Beszámítás! Akciós Gamer PC! R5 5500 / GTX 1070Ti Rog Strix / 32GB D4 / 500GB SSD
- ThinkPad L13 Gen5 13.3" FHD+ IPS Ultra 5 125U 16GB 512GB NVMe ujjlolv IR kam gar
- Új Bontatlan Sony WH-1000xm5 bluetooth fejhallgató.
- Eredeti Bose QuietComfort Bluetooth fejhallgató
- X1 Carbon 9th 14" 4K UHD+ IPS i7-1185G7 32GB 512GB NVMe ujjlolv IR kam gar
- Apple iPhone X, 256GB, Kártyafüggetlen
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- Bomba ár! Dell Latitude E7250 - i7-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest