A megszakítások használhatók az ESP8266-on, de óvatosan kell őket használni, és számos korlátozásuk van:
A megszakítási visszahívási funkcióknak az IRAM-ban kell lenniük, mert előfordulhat, hogy a flash más műveletek közepén van. Ehhez adja hozzá az IRAM_ATTR attribútumot a függvénydefinícióhoz. Ha ez az attribútum nem található meg, a vázlat összeomlik, amikor hibaüzenettel kísérel meg attachInterrupt-ot.
IRAM_ATTR void gpio_change_handler(void *data) {...
A megszakítások nem hívhatják meg a delay() vagy a yield() függvényt, és nem hívhatnak meg olyan rutinokat, amelyek belsőleg a delay()-t vagy a yield()-et használják.
A hosszan futó (>1 ms) feladatok megszakításokban instabilitást vagy összeomlást okoznak. A WiFi és a mag más részei instabillá válhatnak, ha a megszakításokat egy hosszú ideig tartó megszakítás blokkolja. Ha sok tennivalója van, beállíthat egy változékony globális jelzőt, amellyel a fő loop() minden lépését ellenőrizheti, vagy használhat ütemezett függvényt (amely a megszakítási kontextuson kívül kerül meghívásra, ha biztonságos) a hosszú távú munka elvégzéséhez.
A memóriaműveletek veszélyesek lehetnek, és ezeket kerülni kell megszakítások esetén. A new vagy malloc hívásokat minimálisra kell csökkenteni, mert ezek hosszú futási időt igényelhetnek, ha a memória töredezett. A realloc és free hívásokat SOHA nem szabad hívni. Ugyanebből az okból kifolyólag tilos olyan rutinok vagy objektumok használata, amelyek maguk hívják a free-t vagy a realloc-ot. Ez azt jelenti, hogy a String, std::string, std::vector és más olyan osztályokat, amelyek összefüggő memóriát használnak, és amely átméretezhető, rendkívül óvatosan kell használni (annak biztosítása, hogy a karakterláncok ne változzanak, vektorelemek ne legyenek hozzáadva stb.).
Az Arduino kivezetések számozása közvetlenül megfelel az ESP8266 GPIO kivezetések számozásának. A pinMode, digitalRead és digitalWrite funkciók a megszokott módon működnek, tehát a GPIO2 olvasásához hívja meg a digitalRead(2)-t.
A 0–15 digitális kivezetések lehetnek INPUT, OUTPUT vagy INPUT_PULLUP. A 16. kivezetés lehet INPUT, OUTPUT vagy INPUT_PULLDOWN_16. Indításkor a kivezetések INPUT-ként vannak konfigurálva.
A kivezetések más funkciókat is szolgálhatnak, például soros, I2C, SPI. Ezeket a funkciókat általában a megfelelő könyvtár aktiválja. Az alábbi diagram a népszerű ESP-12 modul kivezetés-leképezését mutatja be.
A kivezetések funkciói
A 6-11 digitális kivezetések nem láthatók ezen az ábrán, mert a legtöbb modul flash memória chip csatlakoztatására szolgál. Ha ezeket a kivezetéseket IO-ként próbálja használni, valószínűleg a program összeomlik.
Vegye figyelembe, hogy egyes kártyák és modulok (ESP-12ED, NodeMCU 1.0) a 9-es és 11-es érintkezőket is kitörik. Ezeket IO-ként lehet használni, ha a flash chip DIO módban működik (szemben a QIO-val, amely az alapértelmezett).
A pin-megszakításokat az attachInterrupt, detachInterrupt funkciók támogatják. A megszakítások bármely GPIO kivezetéshez csatolhatók, kivéve a GPIO16-ot. A szabványos Arduino megszakítási típusok támogatottak: CHANGE, RISING, FALLING. Az ISR-eknek IRAM_ATTR-nek kell lenniük a függvénydefiníció előtt.
MEGJEGYZÉS: Az analogRead() túl gyakori hívása a WiFi leállását okozza. Ha a WiFi üzemel, az analogRead() eredménye legalább 5 ms-ig gyorsítótárban maradhat a hatékony hívások között.
Az ESP8266 egyetlen ADC csatornával rendelkezik a felhasználók számára. Használható az ADC érintkező feszültségének vagy a modul tápfeszültségének (VCC) olvasására.
Az ADC érintkezőre adott külső feszültség olvasásához használja az analogRead(A0)-t. A csupasz ESP8266 bemeneti feszültségtartománya 0–1,0 V, azonban egyes kártyák feszültségosztókat is alkalmazhatnak. A biztonság kedvéért <1.0V tesztelhető. Ha pl. A 0,5 V ~512 körüli értékeket ad, akkor a maximális feszültség nagy valószínűséggel 1,0 V, a 3,3 V pedig károsíthatja az ESP8266-ot. A ~150 körüli értékek azonban azt jelzik, hogy a maximális feszültség valószínűleg 3,3 V.
A VCC feszültség leolvasásához használja az ESP.getVcc()-et, és az ADC kivezetést nem kell csatlakoztatni. Ezenkívül a következő sort kell hozzáadni a vázlathoz:
ADC_MODE(ADC_VCC);
Ennek a sornak minden függvényen kívül kell megjelennie, például közvetlenül a vázlat #include sorai után.
Az analogWrite(pin, value) engedélyezi a szoftveres PWM-et az adott kivezetésen. A PWM a 0-tól 16-ig terjedő kivezetéseken használható. Hívja az analogWrite(pin, 0) parancsot a PWM letiltásához a kivezetésen.
A value 0 és 255 között lehet (ami az Arduino alapértelmezése). A PWM tartomány megváltoztatható az analogWriteRange(new_range) vagy az analogWriteResolution(bits) meghívásával. A new_range lehet 15…65535 vagy a bits 4…16.
Az analogWriteMode(pin, value, openDrain) függvény lehetővé teszi, hogy a pinmódot OUTPUT_OPEN_DRAIN értékre állítsa az OUTPUT helyett.
MEGJEGYZÉS: Az alapértelmezett analogWrite tartomány 1023 volt a 3.0 előtti kiadásokban, de ez a külső könyvtárakkal való összeférhetetlenséghez vezetett, ami az Arduino mag alapértelmezett 256-os értékétől függ. Azok a meglévő alkalmazások, amelyek az előző 1023-as értékre támaszkodnak, hozzáadhatják az analogWriteRange(1023) hívását a setup() rutinjukhoz, hogy visszatérjenek régi viselkedésükhöz. Azon alkalmazásokon, amelyek már hívták az analogWriteRange-et, nem kell változtatni.
A PWM frekvencia alapértelmezés szerint 1 kHz. Hívja az analogWriteFreq(new_frequency) függvényt a frekvencia megváltoztatásához. Az érvényes értékek 100 Hz-től 40 000 Hz-ig terjednek.
Az ESP-nek nincs hardveres PWM-je, így a megvalósítás szoftveresen történik. Egy 40 kHz-es PWM kimenettel a CPU már meglehetősen terhelt. Minél több PWM-kimenetet használunk, és minél magasabb a frekvenciájuk, annál közelebb kerülünk a CPU-korlátokhoz, és annál kevesebb CPU-ciklus áll rendelkezésre a vázlat-végrehajtáshoz.
A millis() és a micros() az alaphelyzetbe állítás után eltelt ezred-, illetve mikromásodpercek számát adja vissza.
A delay(ms) egy adott számú ezredmásodpercig szünetelteti a vázlatot, és lehetővé teszi a WiFi és TCP/IP feladatok futtatását. delayMicroseconds(us) szünetet tart adott számú mikroszekundumra.
Ne feledje, hogy a vázlaton kívül sok kódnak futnia kell a chipen, amikor a WiFi csatlakozik. A WiFi és TCP/IP könyvtárak lehetőséget kapnak a függőben lévő események kezelésére minden alkalommal, amikor a loop() függvény befejeződik, VAGY a delay meghívásakor. Ha a vázlatban van valahol egy ciklus, amely sok időt vesz igénybe (>50 ms) a delay hívása nélkül, érdemes lehet egy delay hívási funkcióval kiegészíteni, hogy a WiFi verem zökkenőmentesen működjön.
Van egy yield() függvény is, amely egyenértékű a delay(0)-val. A delayMicroseconds funkció viszont nem enged más feladatoknak, így 20 ezredmásodpercnél nagyobb késleltetés esetén nem javasolt a használata.
A Serial objektum ugyanúgy működik, mint egy hagyományos Arduino esetében. A hardveres FIFO-n kívül (128 bájt TX és RX esetén), a Serial további testreszabható 256 bájtos RX pufferrel rendelkezik. Ennek a szoftveres puffernek a méretét a felhasználó módosíthatja. Nagyobb vételi sebességnél nagyobb méret használata javasolt.
A ::setRxBufferSize(size_t size) metódus szükség szerint módosítja az RX puffer méretét. Ezt a ::begin() előtt kell meghívni. A méret argumentumnak legalább elég nagynak kell lennie ahhoz, hogy az olvasás előtt kapott összes adatot tartalmazza.
Csak átvitel esetén a 256 bájtos RX puffer kikapcsolható a RAM megtakarítása érdekében a SERIAL_TX_ONLY mód átadásával a Serial.begin()-nek. Egyéb módok a SERIAL_RX_ONLY és SERIAL_FULL (az alapértelmezett).
A fogadás megszakítás-vezérelt, de lekérdezéseket és foglalt várakozásokat küld. A blokkolási viselkedés a következő: A ::write() hívás nem blokkol, ha a bájtok száma belefér a TX FIFO-ban rendelkezésre álló aktuális helyre. A hívás blokkolja, ha a TX FIFO megtelt, és megvárja, amíg van hely, mielőtt további bájtokat írna bele, amíg az összes bájt meg nem íródik. Más szóval, amikor a hívás visszatér, az összes bájt beírásra került a TX FIFO-ba, de ez még nem jelenti azt, hogy az összes bájt ki lett küldve a soros vonalon. A ::read() hívás nem blokkol, még akkor sem, ha nem állnak rendelkezésre bájtok az olvasáshoz. A ::readBytes() hívás addig blokkol, amíg az olvasott bájtok száma el nem éri a bevitt argumentum által megkívánt bájtok számát. A ::flush() hívásblokkok arra várnak, hogy a TX FIFO üres legyen, mielőtt visszatérne. Javasoljuk, hogy ezt hívja meg, hogy megbizonyosodjon arról, hogy az összes bájt el lett küldve, mielőtt konfigurációt módosítana a soros porton (pl. az átviteli sebesség megváltoztatása) vagy a kártya alaphelyzetbe állítása előtt.
A Serial az UART0-t használja, amely a GPIO1 (TX) és GPIO3 (RX) érintkezőkhöz van leképezve. A Serial újra leképezhető GPIO15 (TX) és GPIO13 (RX) formátumra a Serial.swap() meghívásával a Serial.begin után. A swap ismételt hívása az UART0-t visszaképezi a GPIO1-re és a GPIO3-ra.
A Serial1 UART1-et használ, a TX pin GPIO2. Az UART1 nem használható adatfogadásra, mert általában az RX érintkezője van lefoglalva a flash chip csatlakozáshoz. A Serial1 használatához hívja a Serial1.begin(baudrate) parancsot.
Ha a Serial1 nincs használva, és a Serial nincs felcserélve - az UART0 TX-je leképezhető GPIO2-re a Serial.begin utáni Serial.set_tx(2) meghívásával vagy közvetlenül a Serial.begin(baud, config, mode, 2) paranccsal.
A Serial.begin meghívásakor a WiFi-könyvtárak diagnosztikai kimenete alapértelmezés szerint le van tiltva. A hibakeresési kimenet ismételt engedélyezéséhez hívja a Serial.setDebugOutput(true) parancsot. A hibakeresési kimenet Serial1-re való átirányításához hívja a Serial1.setDebugOutput(true) parancsot.
A printf() függvény kimenetének engedélyezéséhez a Serial.setDebugOutput(true)-t is használnia kell.
Mind a Serial, mind a Serial1 objektumok támogatják az 5, 6, 7, 8 adatbitet, páratlan (O), páros (E) és nem (N) paritást, valamint 1 vagy 2 stopbitet. A kívánt mód beállításához hívja a Serial.begin(baudrate, SERIAL_8N1), a Serial.begin(baudrate, SERIAL_6E2) stb. parancsot. Az alapértelmezett konfigurációs mód a SERIAL_8N1. A lehetőségek a következők: SERIAL_[5678][NEO][12]. Példa: a SERIAL_8N1 azt jelenti, hogy 8 bit, nincs paritás és 1 stopbit.
Mind a Serial, mind a Serial1 esetében új módszert alkalmaztak az aktuális adatátviteli sebesség beállításához. Az aktuális adatátviteli sebesség megtekintéséhez hívja a Serial.baudRate(), a Serial1.baudRate() parancsot. A visszatérési érték int, az aktuális sebesség. Például
// Állítsa az adatátviteli sebességet 57600-ra
Serial.begin(57600);
// Az aktuális adatátviteli sebesség lekérése
int br = Serial.baudRate();
// Kinyomtatja, hogy "Serial is 57600 bps"
Serial.printf("Serial is %d bps", br);
A Serial és Serial1 objektumok egyaránt a HardwareSerial osztály példányai.
Ez a hivatalos ESP8266 Software Serial könyvtár esetében is megtörténik, lásd ezt a lekérési kérelmet.
Vegye figyelembe, hogy ez a megvalósítás csak ESP8266 alapú kártyákra vonatkozik, és nem működik más Arduino kártyákkal.
A Serial-ra érkező adatok ismeretlen átviteli sebességét a Serial.detectBaudrate(time_t timeoutMillis) használatával észlelheti. Ez a módszer megpróbálja észlelni az adatátviteli sebességet maximum timeoutMillis ms-ig. Nullát ad vissza, ha nem észlelt átviteli sebességet, vagy egyébként az észlelt átviteli sebességet. A detectBaudrate() függvény a Serial.begin() meghívása előtt hívható meg, mert nincs szüksége sem a fogadópufferre, sem a SerialConfig paraméterekre.
Az uart nem tud más paramétereket észlelni, mint például a start- vagy stopbitek száma, az adatbitek száma vagy a paritás.
Maga az észlelés nem változtat az átviteli sebességen, észlelés után a szokásos módon be kell állítani a Serial.begin(detectedBaudrate) segítségével.
Az észlelés nagyon gyors, mindössze néhány bejövő bájtot vesz igénybe.
A SerialDetectBaudirate.ino a felhasználás teljes példája.
A Program memória funkciói ugyanúgy működnek, mint egy hagyományos Arduino esetében; csak olvasható adatok és karakterláncok elhelyezése a csak olvasható memóriában, és heap felszabadítása az alkalmazás számára.
A 2.7 előtti alapverziókban a fontos különbség az, hogy az ESP8266-on a literális karakterláncok nincsenek összevonva. Ez azt jelenti, hogy ugyanaz az F("") és/vagy PSTR("") karakterláncban definiált karakterlánc fog helyet foglalni a kód minden példányához. Tehát magának kell kezelnie az ismétlődő karakterláncokat.
A 2.7-es verziótól kezdve ez már nem igaz: az r/o memórián belüli ismétlődő literális karakterláncok kezelése már megtörténik.
Van egy további segítő makró, amely megkönnyíti a const PROGMEM karakterláncok átadását olyan metódusoknak, amelyek egy FPSTR() nevű __FlashStringHelper-t vesznek igénybe. Ennek használata megkönnyíti a karakterláncok összegyűjtését. Nem egyesíti a karakterláncokat…
String response1;
response1 += F("http:");
...
String response2;
response2 += F("http:");
Az FPSTR használata…
const char HTTP[] PROGMEM = "http:";
...
{
String response1;
response1 += FPSTR(HTTP);
...
String response2;
response2 += FPSTR(HTTP);
}
A C++ kivételekről, a new operátorról és a Kivételek menüpontról
A C++ szabvány a következőket mondja az új operátor viselkedéséről heap összeakadás esetén (memória megtelt):
std::bad_alloc C++ kivételt kell dobnia, ha engedélyezve vannak
ellenkező esetben abort()
A fenti első pontnak több oka is van, köztük a következők:
garantálja, hogy az új visszaadása soha nem nullptr
garantálja a legfelső szintű objektum és az összes tag alobjektum teljes felépítését
garantálja, hogy a részben megépített részobjektumok megsemmisülnek, és a megfelelő sorrendben, ha az oom az építés felénél találkozik
Ha a C++ kivételek le vannak tiltva, vagy a new(nothrow) használatakor, a fenti garanciák nem tarthatók fenn, így a fenti második pont (abort()) az egyetlen életképes std::c++ megoldás.
Történelmileg az Arduino környezetekben a new túlterhelt, hogy egyszerűen visszaadja az egyenértékű malloc()-ot, amely viszont visszaadhatja a nullptr-t.
Ez a viselkedés nem C++ szabvány, és ennek jó oka van: vannak rejtett és nagyon rossz mellékhatások. Az osztály- és tagkonstruktorok mindig meghívásra kerülnek, még akkor is, ha a memória megtelt (this == nullptr). Ezenkívül a felső objektum memóriafoglalása sikeres lehet, de egyes tagobjektumokhoz szükséges lefoglalás meghiúsulhat, így az építés meghatározatlan állapotban marad. Tehát Ardudino new történeti viselkedése, amikor az elégtelen memóriával szembesül, előbb-utóbb rossz összeomláshoz vezet, néha megmagyarázhatatlan, általában a memória sérülése miatt, még akkor is, ha a visszaadott értéket ellenőrizzük és kezeljük. Szerencsére az esp8266-on a RAM 0-s cím közelében történő frissítése azonnal hardveres kivételt jelent, ellentétben az olyan uC-k esetében, mint az avr, amelyen ez a memória elérhető.
A core 2.6.0-tól kezdve 3 lehetőség van: örökölt (alapértelmezett) és két egyértelmű eset, amikor új oom-mal találkozik:
a new nullptr-t ad vissza, lehetséges rossz hatásokkal vagy azonnali összeomlással, amikor a konstruktorok (amúgy hívják) inicializálják a tagokat (ebben az esetben a kivételek le vannak tiltva)
A C++ kivételek le vannak tiltva: a new abort() hívások "tisztán" összeomlanak, mert nincs mód a memóriafoglalás tiszteletben tartására vagy a kecses helyreállításra.
A C++ kivételek engedélyezve vannak: a new std::bad_alloc C++ kivételt dob, amely elkapható és kecsesen kezelhető. Ez biztosítja a helyes viselkedést, beleértve az összes részobjektum kezelését, ami garantálja a stabilitást.
A Stream az Arduino API egyik alapvető osztálya. A vezetékes, soros, hálózati és fájlrendszerek olyan adatfolyamok, amelyekből adatokat olvasnak vagy írnak.
A streamekkel való átvitel meglehetősen gyakori, mint például a történelmi WiFiSerial vázlat:
//ellenőrizze a kliensek adatait
//lekérni az adatokat a telnet klienstől és továbbítja az UART-hoz
while (serverClient.available()) {
Serial.write(serverClient.read());
}
//ellenőrizze az UART adatokat
if (Serial.available()) {
size_t len = Serial.available();
uint8_t sbuf[len];
Serial.readBytes(sbuf, len);
//UART adatok küldése az összes csatlakoztatott telnet kliensnek
if (serverClient && serverClient.connected()) {
serverClient.write(sbuf, len);
}
}
Észrevehető, hogy a hálózatban a soros irányban az adatok bájtonként kerülnek átvitelre, miközben az adatok rendelkezésre állnak. A másik irányban egy ideiglenes puffer jön létre a veremben, feltöltődik az elérhető soros adatokkal, majd átkerül a hálózatra.
A readBytes(puffer, long) metódus időtúllépést tartalmaz annak biztosítására, hogy az összes szükséges bájt megérkezzen. A write(puffer, hossz) (a Print::) függvény is általában blokkol, amíg a teljes puffer el nem kerül. Mindkét függvény az átvitt bájtok számát adja vissza.
A Stream osztály így működik és általánosan használatos.
A Stream::-ből származtatott osztályok általában bevezetik a read(buffer, len) metódust is, ami hasonló a readBytes(buffer, len) timeout-hoz: a visszaadott érték kisebb is lehet, mint a kért méret, ezért erre fokozottan ügyelni kell. funkció, amelyet az Arduino Client:: osztályban vezettek be (vö. AVR referencia implementáció). Ezt a funkciót más olyan osztályokban is bevezették, amelyek nem a Client::-ből származnak, pl. HardverSerial::.
Az Stream-bővítményeket úgy tervezték, hogy kompatibilisek legyenek az Arduino API-val, és további módszereket kínálnak az átvitel hatékonyabbá és egyszerűbbé tételéhez.
A fenti soros hálózati átvitel a következőképpen írható fel:
serverClient.sendAvailable(Serial); // darabonként
Serial.sendAvailable(serverClient); // darabonként
Egy visszhangszolgáltatás így írható:
serverClient.sendAvailable(serverClient); // tcp echo szolgáltatás
Serial.sendAvailable(Serial); // soros szoftveres visszacsatolás
A kódolási idő csökkentése mellett ezek a módszerek optimalizálják az átvitelt azáltal, hogy lehetőség szerint elkerülik a puffermásolatokat.
Felhasználói API: Stream::send()
A streamek célja az adatátvitel a gyártók és a fogyasztók között, mint a fenti telnet/soros példa. Négy módszer áll rendelkezésre, amelyek mindegyike visszaadja az átvitt bájtok számát:
Stream::sendSize(dest, size [, timeout])
Ez a metódus a megadott vagy alapértelmezett időtúllépésig vár a size byte-ok átviteléhez a dest adatfolyamba.
Stream::sendUntil(dest, delim [, timeout])
Ez a módszer a megadott vagy alapértelmezett időtúllépésig vár az adatok átviteléhez, amíg a delim teljesül. Megjegyzés: A határoló beolvasásra kerül, de nem kerül átvitelre (például readBytesUntil)
Stream::sendAvailable(dest)
Ez a módszer minden már rendelkezésre álló adatot továbbít a célállomásra. Nincs időtúllépés, és a visszaadott érték 0, ha nincs mit átvinni, vagy nincs hely a célállomáson.
Stream::sendAll(dest [, timeout])
Ez a módszer a megadott vagy alapértelmezett időtúllépésig vár az összes elérhető adat átviteléhez. Hasznos, ha a forrás meg tudja mondani, hogy nem lesz több adat elérhető ehhez a híváshoz, vagy ha a célállomás meg tudja mondani, hogy többé nem fog tudni fogadni.
Például egy forráskarakterlánc nem növekszik az átvitel során, vagy egy adott hálózati kapcsolatnak meghatározott mennyiségű adatot kell küldenie a bezárás előtt. A ::sendAll() az összes bájtot megkapja. Az időtúllépés akkor hasznos, ha a célállomásnak feldolgozási időre van szüksége (pl. a hálózat vagy a soros bemeneti puffer megtelt = kérjük, várjon egy kicsit).
Két további osztály biztosított.
StreamConstPtr:: állandó puffer tárolására szolgál (RAM-ban vagy flash-ben).
Ezzel az osztállyal egy Stream:: készíthető const char*, F("néhány szó flashben") vagy PROGMEM karakterláncokból. Ez az osztály nem készít másolatot, még flash adatok esetén sem. Flash-tartalom esetén a bájtonkénti átvitel következménye, ha a „memcpy_P” nem használható. Más tartalmak lehetőség szerint azonnal átvihetők.
StreamConstPtr css(F("my long css data")); // A CSS-adatok nem másolhatók a RAM-ba
server.sendAll(css);
Az S2Stream:: arra készült, hogy egy String:: Stream::-t készítsen másolat nélkül.
String helloString("hello");
S2Stream hello(helloString);
hello.reset(0); // megakadályozza, hogy a ::read() felhasználja a karakterláncot
hello.sendAll(Serial); // azt mutatja, hogy "hello"
hello.sendAll(Serial); // semmit nem mutat, a tartalmat már elolvasták
hello.reset(); // tartalommutató visszaállítása
hello.sendAll(Serial); // azt mutatja, hogy "hello"
hello.reset(3); // állítsa vissza a tartalommutatót egy adott pozícióba
hello.sendAll(Serial); // azt mutatja, hogy "lo"
hello.setConsume(); // A ::read() pusztítani fog, ez az alapértelmezett
Serial.println(helloString.length()); // azt mutatja, hogy 5
hello.sendAll(Serial); // azt mutatja, hogy "hello"
Serial.println(helloString.length()); // azt mutatja, hogy 0, a string elpusztítva
StreamString:: az S2Streamből származik
StreamString contentStream;
client.sendSize(contentStream, SOME_SIZE); // legfeljebb SOME_SIZE bájtot fogad
// egyenértékű:
String content;
S2Stream contentStream(content);
client.sendSize(contentStream, SOME_SIZE); // legfeljebb SOME_SIZE bájtot fogad
// a tartalom tartalmazza az adatokat
Belső Stream API: peekBuffer
Íme a módszerek listája és azok jelentése. Jelenleg a HardwareSerial, a WiFiClient és a WiFiClientSecure verziókban valósulnak meg.
virtual bool hasPeekBufferAPI() true-t ad vissza, ha az API jelen van az osztályban
virtual size_t peekAvailable() az elérhető bájtok számát adja vissza
A virtual const char* peekBuffer() visszaadja a mutatót ezekre a bájtokra
Ez az API megköveteli, hogy a peekBuffer() után és a peekConsume() meghívásáig semmilyen "read" függvényt ne hívjanak meg.
virtual void peekConsume (size_t consume) azt mondja, hogy dobja el ezt a számú bájtot
virtual bool inputCanTimeout()
A StringStream false értéket ad vissza. A zárt hálózati kapcsolat false értéket ad vissza. Ez a függvény lehetővé teszi, hogy a Stream::sendAll() korábban visszatérjen.
virtual bool outputCanTimeout()
A zárt hálózati kapcsolat false értéket ad vissza. Ez a függvény lehetővé teszi, hogy a Stream::sendAll() korábban visszatérjen.
virtual ssize_t streamRemaining()
-1-et ad vissza, ha az adatfolyam hátralévő mérete ismeretlen, a megvalósítástól függően (karakterláncméret, fájlméret...).