Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Helló!
Itt van egy táblázat is szerintem az SPI lesz a jóbb. https://www.rfwireless-world.com/Terminology/UART-vs-SPI-vs-I2C.html
UART sebessége, 115 200 bit/s, e fölé már nem nagyon tudnak menni egyszerű eszközök, SPI-vel 1 Mbit/s is könnyen elérhető, nem számítva a CS be- és kikapcsolásának idejét.
I2C-n 400 kHz-es órajelet is könnyen el lehet érni, a következő, 1 MHz-es órajelet már nem sok eszköz tud kezelni. Ráadásul I2C esetén a kapcsolat elején megy a pinpongozás, amíg az eszközök megbeszélik egymás közt, kinek is szól az adat.
ok! Akkor mondjuk legyen az SPI ...
Hogy célszerű az adatokat küldeni? Legyen a PIC a mester, és csak tolja az adatokat egymás után, vagy a nodemcu legyen a mester és mint pl egy memória kiolvasásnál kérje egyesével az adatokat? Vagy mi lenne célszerű?
Mi a lassú? Megmérted és a névleges sebesség a lassú, vagy nem megy a névlegessel? Nem lehet, hogy az olvasó vagy a küldő rutin a lassú?
Egyébként járatok UART-ot 920000 Baudon is. Igaz scak időlegesen. Eszközöktől, kábelezéstől, órajel forrástól is függ. A NodeMCU ennyivel frissíti a Nextion szoftverét. Egyébként, ha a NodeMCU-n hardveres UART-ot használsz (serial0) és közben a serial.print-et is használod debuggoláshoz akkor az be is kavarhat a sebességbe, mert az a serial0-ra ír alapból. Nem tudom, hogy van nálad konfigurálva, de nálam amikor a Nextion-os cuccot csináltam, nagyon lelassította. Igaz a Nextion lib inicializált egy új kommunikációs csatornát a serial-ra.
Szerintem csak arra gondolt, hogy érzetre szeretné ha gyorsabb lenne..
Ha a NodeMCU kéri, kéregeti az adatokat, az ismét ront a sebességen. Csináld meg úgy, ahogy UART-on csináltad, tolod az adatokat, ahogy jönnek.
Ez nekem hiányosnak tűnik. A t2 az nálad pointer. Abból hogy lesz tömb? Csak ha rámutat.
Ha meg rámutat akkor nem mutathat máshová is.
Továbbmegyek. Ha kiegészítem, sem jó, mert fordítva kellene az egyenlőség. A t1-nek szeretném átadni a t2 elemeit, mert a t1 a nagyobb, és a fordító azt nem fogadja el.
Heló!
Nem boldogulok ezzel az Arduinoval. Megvan egy Duemilanov bootloaderrel ellátott ATmega328P PU IC, benne egy programozón át feltöltött blink, ami működik. De USB-soros átalakítóval nem lehet programozni. Ugyanezt máshol is használom és működik. GND, +5V, RX, TX, helyén vannak, a DTR 100nF-al rákötve a RESET lábra a 10KOhmos felhúzó ellenállással együtt. Táppal párhuzamosan 10 µF és 100nF. Mi lehet a hiba?
Helló!
Az Arduino a soros portból kapja az 5V-ot és a GND-t? Gondolom igen, mert azt írtad. Milyen környezetben programozod? Win+Arduino IDE? Gondolom a port jól van beállítva az id-ben. Mit jelent, hogy máshol jó? Arra gondolok, hogy szoftveresen is lehet a hiba esetleg. Fordított byte sorrendben küldi az usb soros átalakító, vagy valami port beállítás esetleg. Elképzelhető, hogy ezt a gondot a korábbi programozó áthidalja, direktben meg nem. https://www.embeddedrelated.com/showarticle/174.php A hozzászólás módosítva: Márc 13, 2020
Ilyesmire gondolok:
https://v8doc.sas.com/sashtml/lgref/z1270373.htm Ott a UNIX-NUXI problémára is gondolhatunk szerintem.
"b" tömb pointerei így már "a" tömb szabadon választott elemeire mutatnak.
Ha "b" tömböt változtatja, változik "a" is, és fordítva is igaz. Ez volt a kérés nem?
Lefordítom amit írtál:
A b-nek sem az a-nak nincsenek pointerei, egy pointer van ebben az esetben mindkettőnél, ami különböző és konstans, ez a pointer azonosítója, tehát a és b.
Sziasztok!
Hogyan tudom a BME280 szenzor SDA SCL portját áttenni D12-13-ra?
A BME280I2C.h, vagy a Wire.h fájlokban kell hogy legyen a definíciója, hogy alapból melyik pineket használja. Nézz bele!
Miért kell átrakni? A használt MCU-nak az SCL/SDA lábainak kivezetése adottak-fixek az I2C-hez.
Mert a képen látható kijelző lefoglalja az A4-A5 pineket.
Azaz az i2c-n van a kijelző is?
Az nem gond. Az I2C egyik előnye, hogy ugyanazon a vonalon több mint 100 eszköz lehet. Címezni kell őket. A hozzászólás módosítva: Márc 13, 2020
Win7 64bit, Arduino IDE 1.8.12 (a legújabb).
Ugyanezt az USB-soros átalakítót használom egy Arduino mini-nél és ott nincs vele semmi gond. A portot nem tudom hol és milyen értékre kell beállítani az ID-ben. De gondolom, hogy ugyanaz minden bootloadernél. Ilyen hibákat kapok: Arduino: 1.8.12 (Windows 7), Alaplap:"Arduino Duemilanove or Diecimila, ATmega328P" Using Port : COM5 Using Programmer : arduino Overriding Baud Rate : 57600 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xef avrdude: ser_recv(): read error: Az I/O művelet megszakítva. (Egy folyamat véget ért, vagy egy alkalmazás megszakította az I/O műveletet.) avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xef avrdude: ser_send(): write error: sorry no info avail avrdude: ser_recv(): read error: Az eszköz nem ismeri fel a parancsot. Ezek szerint a soros porttal van gond. Pontosabban el sem indul a programozás folyamata, mert villog tovább attól, ami benne van. Lehet, hogy kell oda valamilyen felhúzó ellenállás?
Érdekes akkor nem az amire gondolok. Mi az alap baud rate? Annak kellene utána nézni. Nem lehet, hogy a bootloader alapban nem ezzel a sebességgel akar kommunikálni?
Kulcskérdés, hogy van-e DMA? Ennek az a lényege, hogy a processzor munkája nélkül becsorognak az adatok a RAM-ba. Én a 8 bites AVR-eket ismerem, ott nincs. Arra tippelnék, hogy a PIC-en sincs. Gyanítom, hogy a nodeMCU-ban van ilyen, vagy legalább nagyobb vételi puffer.
DMA nélkül minden fogadott bájt (fogadó puffer megtelés, adási puffer ürülés) egy interruptot okoz (vagy pollozva fel kell dolgozni), és annak a feldolgozási ideje is korlátozhatja az átviteli sebességet. Illetve biztosítani kell, hogy időben lefusson - az SPI slave ugye nem tudja jelezni, hogy felkészült-e a következő bájt fogadására, tehát csakis a sebesség korlátozásával lehet ezt biztosítani. Az I2C-ban a slave is tudja lassítani az átvitelt ismereteim szerint, de lehet, hogy rosszul emlékszem. AVR-en a legnagyobb sávszélességet szerintem szoftveresen megvalósított SPI-szerű protokollal lehet elérni úgy, hogy nem 1, hanem pl 8 adatvonalat használunk az 1 db órajel mellé. Tehát 1 órajellel átmegy egy teljes bájt. Cserébe sok lábat lefoglal, és szoftveresen kell megvalósítani. Ez tuti megvalósítható PIC és nodeMCU között is, de csak akkor érdemes, ha _valóban_ szükség van rá. Az, hogy lassú, az egyébként nem túl pontos megfogalmazás. Mi lassú? A késleltetés? Nem tudsz elegendő periódusnyi adatot átküldeni egy másodperc alatt? Túl sokáig "áll" a program, ameddig a kommunikáció tart? Mert ha csak az a baj, hogy túl sokáig áll a program, akkor megoldás lehet, ha interrupt segítségével "háttérben" történik a kommunikáció. Ha valóban nem elegendő a sávszélesség, akkor kell a kommunikációs protokollon változtatni. A hozzászólás módosítva: Márc 13, 2020
Ezzel a példával megy a kijelző:
Nem tudod átírni. Az IIC busz fix helyen van. LCD típus jó lenne, de a kódból ítélve az SPI-t használ. Meg a deszka típusát sem írtad, hogy UNO, MEGA vagy micsoda? Sok vezérlőnél Az SPI-nek és az IIC-nek vannak közös lábaik. IIC általában fix, SPI talán jobban áthelyezhető emlékeim szerint, de deszka típus nélkül passz.
Uno-n szeretném használni, szerintem nem spi-s a kijelző mert használja az A0-A5 éd D2-D9 lábakat.
Ha jól látom a kijelző lábai átszabhatóak.
Idézet: „LCDWIKI_KBV mylcd(ILI9486,A3,A2,A1,A0,A4); //model,cs,cd,wr,rd,reset”
Az egyiket át tudom tenni digitálisra is?
Mindet át tudod. A kijelzőnek nem kell analóg jel. Magas vagy alacsony jelet kap.
Én belezavarodtam de hála az Égnek, kikapták a kezemből a gépet. Ezek szerint az A4 lábat kell lecserélni valami másra?
Igen a kijelző A4 lábát át sikerült tennem a D10-re így a BME280-nak maradt az A4-A5 szabadon.
Kijelzi az értékeket ahogy kell. Köszönöm mindenkinek a segítséget! |
Bejelentkezés
Hirdetés |