- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- Apple MacBook
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Milyen széket vegyek?
- Egérpad topik
- Teljesen az AI-ra fókuszál az új AMD Instinct sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Fejhallgató erősítő és DAC topik
- AMD GPU-k jövője - amit tudni vélünk
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
-
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
-
Dißnäëß
nagyúr
De komolyan, Ti itt annyi türelemmel írogattok minden kezdő szöcskének, és tartjátok bennük a lelket, nagyon nagy köszönet és hála. Nem is tudjátok, mekkora öröm ez most nekem
Egy éve (!!!) álmodok erről, hogy maaajd egyszer, ha nagy leszek ...
Tartsátok ezt a topic-ot így, segítőkészség, alázat a kezdőkkel szemben, emberség, minden topp. Sok egyéb topic példát vehetne. És ez szól mindkettőtöknek.
-
-
Dißnäëß
nagyúr
Igen, Neked is jár pirospont
, sőt.. csak .. amíg az "emélet" nem állt össze a fejemben erről az egészről, addig ezt az infót nem tudtam értelmezni. Szóval mea culpa, most esett le és kerültek kb. a kirakós darabjai a helyükre. Hát ez wow. Még mindig csak bámulom csendben a demo-t és gyönyörködök benne.
Ez kúúúúúvajóóóóó
-
Dißnäëß
nagyúr
Hát, röhögni fogsz, Nektek triviális, de .. bekötöttem MINDENT, azt is, amit említett a konstruktor (és ott a helyes portot kiválasztottam neki), a maradék, vélhetően default (csak itt kódban nem említett) bekötéseket pedig rendre a jobboldali zöldekre tettem, szóval most így néz ki a bekötésem, ha hozzá nézed ezt az ábrát:
U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ 15, /* dc=*/ 4, /* reset=*/ 5); // Enable U8G2_16BIT in u8g2.h
A fentebbi definiálandók közül:
- cs-t is bekötöttem azért, biztos ami biztos alapon, bár értettem, hogy nem szükséges, a GPIO15-re (zölddel jelölt HCS) - fizikailag a D8
- dc-nek kinéztem a GPIO4-et - fizikailag a D2
- reset-nek kinéztem a GPIO5-öt - fizikailag a D1A vélhetően defaultokat is bekötöttem, amit nem kellett kódban megadni:
- kijelző SCLK-t ESP8266 HSCLK-ra (GPIO14/D5)
- kijelző SDIN-t ESP8266 HMOSI-ra (GPIO13/D7)
+ a GND és 3v3 természetesen.Így most ha jól látom, 7 kábellel megyek a kettő között, ebből 2 táp, 5 a többi.
Jó ez így, míg működikSzerk.: próbaképp lehúztam róla RST-t és CS-t, és kifogástalanul megy. Kihúzva-újrabedugva is. Szóval így most 5 kábel, 2 táp, ergo 3 SPI-s kábellel meg van oldva.
-
Dißnäëß
nagyúr
[link]
Bakker, örülök, mint hülyegyerek a nemtomminek..Na most már nyugodt karácsonyom lesz, nem fog frusztrálni végig a családozás alatt, hogy hogy a pékbe kellene ezt a jószágot szóra bírni.
Kellemes Ünnepeket Nektek, mindenkinek !!
-
Dißnäëß
nagyúr
válasz
Dißnäëß #16692 üzenetére
Istenem, MŰKÖDIK !!!!!!!!!!!!!!!!!!
ÓBBAASSSZKI mindjárt elbőgöm magam, tegnap 5-6 órát elcsesztem erre.. oké, tök kezdő vagyok az egészhez, de akkoris ...KÖSZÖNÖM Janos250, azt hiszem, meghoztad a karácsonyi ajándékom #16688-al.. KÖSZÖNÖM !!!!!!!!!!!!!!!!!!!
WOO HOOO !!!!
Úúúúúgy hasít a GraphicsTest mint a szééééééél
Aryes, Neked is, hogy ránéztél.
-
Dißnäëß
nagyúr
válasz
Janos250 #16688 üzenetére
Természetesen a /* clock=*/ 14, /* data=*/ 12, bármelyiket használod is, mindenképpen bekötendő akkor is, ha a konstruktorban nem adod meg, hanem defaultként kezeli.
Aaaa kezdem kapizsgálni. Vélhetően default-ol a kikommentelt sorom clock-ra és data-ra a zöldekkel jelölt portokat illetően ? (Tegyük fel, rápróbálok a jobboldali zöldekre, akkor
clock = HSCLK, azaz GPIO14
data = HMOSI, azaz GPIO 13).Ettől függetlenül még CS-t megadhatom neki (kéri is a sor), HCS = GPIO 15-re.
A konstruktorban a dc és a reset hova lennének köthetők ezen ?
-
Dißnäëß
nagyúr
Igazság szerint be van most kötve SW módnak megfelelôen és jó, de nyilván a gyors HW módra hajtok.
A bekötéshez nem nyúlva, a HW módos sort használva meg se moccan.
Valszeg az lesz, amit Janos250 mond, clock és data defaultok mennek még ettôl, csak rossz helyre kötöttem.
Na teszek egy próbát megint.
Janos250 köszi Neked is, ez a hosszabbik szösszeneted kellett nekem, hogy rendbe tegyem fejben, mi is van itt.
-
Janos250
őstag
válasz
Dißnäëß #16687 üzenetére
"lehet más fejlesztőkörnyezetben és más library-vel jó."
Ezért szeretem én - ha nem nagyon bonyolult - saját magam megírni a kezelést, más által megírt könyvtár helyett.
Látom, közben ESP32-t is bekommenteltél. Ha azon csinálod, akkor többet tudok segíteni, mert azt jobban ismerem. -
Janos250
őstag
válasz
Dißnäëß #16687 üzenetére
"Ha pedig önkényesen mégis megadom azt neki ugyanúgy, mint az SW verziónál (ahol viszont kéri), hibára fut a fordító."
Ne add meg neki, de kösd be!Mivel csak ESP32-n használtam az SPI-t, ESP8266-on nem, ezért csak általánosságban tudok hozzászólni.
Az általad linkelt képen látszik, hogy két SPI van. Zölddel vannak jelölve.
Általánosságban az SPI használ MOSI , MISO (Master Out Slave Input, a másik fordítva), és egy CLK clock jelet. Az ESP a master, a kijelző, stb. a slave. Van egy-egy CS (chip select láb). Be lehet úgy állítani, hogy a CS-t is a hardver kezelje, általában ez a default. Viszont ezzel az a baj, hogy akkor csak egy slave használható, holott az SPI több slave kezelésére alkalmas. Ebben az esetben minden slave-nek külön CS láb kell, és ezeket szoftverből kell vezérelni, hogy most éppen kihez akarsz szólni. Mivel nálad egyetlen slave (a kijelző) van, ezért célszerű a default választás. Általában a könyvtárakban, ha olyan konstruktort használunk, amiben nem szerepel a CS, akkor a default lesz érvényes, és a hw kezeli. Esetedben ez azt jelenti, hogy HSPI esetén a GPIO15 lesz automatikusan a CS, míg VSPI esetén a CMD-vel jelzett láb. Ha pl. kijelzőt hajtunk meg, akkor vissza irány (MISO) nem is kell. A H-nak, V-nek ne akarj értelmet tulajdonítani, tekintsd egyszerűen egy megkülönböztető jelnek.Az, hogy hány lábat kell a konstruktorban megadni, az még nem jelenti azt, hogy a többi lábat nem kell megadni.
Itt úgy látom, a CS mindig megadandó, nincs default.
Természetesen a /* clock=*/ 14, /* data=*/ 12, bármelyiket használod is, mindenképpen bekötendő akkor is, ha a konstruktorban nem adod meg, hanem defaultként kezeli. -
Dißnäëß
nagyúr
válasz
Dißnäëß #16686 üzenetére
Az u8g2 doksijában nézelődve, a táblázatot középtájon, a második sor lenne rám releváns, tehát clock, data, cs, dc - 4 vezeték.
És mégis, mikor a constructor reference-ből a számomra megfelelőt teszem be a kódba (előre ott van a minta kódban, csak ki kell kommentelnem és a megfelelő GPIO-t megadnom neki), már csak 3 vezetékkel tudok operálni, amit nagyon nem értek, miért. A 6. sor lenne jó, azaz ez:
U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI(rotation, cs, dc [, reset]) [full framebuffer, size = 2048 bytes]
F mint full framebuffer, 4W mint 4-vezetékes, HW mint hardveres, és utána ? A rotation mint paraméter tiszta, megadom, de utána cs és dc marad, clock és data sehol.Ha pedig önkényesen mégis megadom azt neki ugyanúgy, mint az SW verziónál (ahol viszont kéri), hibára fut a fordító.
SPI-kről:
The ESP32 contains 4 SPI bus hosts calledSPI
,SPI1
,HSPI
, andVSPI
.SPI
is locked to flash communication and is not available for the application.SPI1
is currently also tied to flash support, but might be available in the future. Applications can currently only use theHSPI
andVSPI
hosts.
Még ezt a srácot megkérdezem Youtube-ról, hátha mond valami okosat, ő összetákolta a dolgot sikeresen. Köszi azért a próbát. Kicsit bonyinak tűnik u8g2-vel, lehet más fejlesztőkörnyezetben és más library-vel jó. -
Dißnäëß
nagyúr
Van valami bug a 32 bites procikkal (azaz a kóddal) és mindhez bekapcsoltatják ezt, a library doksijában írják valahol. Ezért van itt is extrán kommentelve a sok kikommentelt sornál, a két 256x64-esnél a végén, hogy még extraként az u8g2h-ban is nézzük ezt meg.
A NodeMCU-n a hardveres SPI le van foglalva a programozónak valamiért, azt olvastam. Van egy másik tüskesor vele szemben, a HSPI, ami használható, illetve VSPI (virtual SPI?) amit nem találtam, de mintha egy valaki olyan magas GPIO szàmokat is használt volna a kódban, ami kizárt h létezzen fizikailag az eszközön, lehet a VSPI egyike volt az. Még ennek utánanézek.
-
válasz
Dißnäëß #16683 üzenetére
For any device with a pixel width of 256 or higher, you must uncomment (remove the //) from the following line in u8g2.h:
//#define U8G2_16BITNekem ez fura, 8bit pont elég 256pixel szélességhez, biztos, hogy neked 16 bit kell? Szerintem ez a szöveg pontatlan.
Meg kell nézni a nodemcu-n melyik lábakon van a hardveres SPI, úgy látom a D5-D6-D7 lábak, D5 a CLK és a D7 a MOSI.
-
Dißnäëß
nagyúr
Sziasztok,
beszereztem ezt a kijelzőt (leírás, portok legörgetésre lentebb), 256x64-es OLED.
És van egy NodeMCU ESP8266-om, hajszálpontosan ez.Leszedtem Arduino IDE alá a megfelelő library-t a kijelző meghajtására, u8g2 (elvileg ez valami új, ami a régit leváltotta).
A github oldalán az instrukcióknak megfelelően
U8g2 is configured for 8 Bit mode by default. For any device with a pixel width of 256 or higher, you must uncomment (remove the//
) from the following line inu8g2.h
://#define U8G2_16BIT
u8g2.h-ban kiszedtem a kommentet a fentebbi sorból.Próbáltam bekötögetni a kábeleket, és rájönni arra a mapping-re, ami azt mondja, hogy az ESP lábai más számú GPIO-hoz vannak rendelve az IDE-ben. Ez mesél erről, ha legörgettek.
Hát mondom jó, legyen.
A kijelző 4-SPI jelölésű, azaz 6 drótos, ebből 2 a táp, 4 pedig a többi.
-----------------------------------------
Az IDE alatt mondom betöltök valami Example kódot, legyen egy klasszik Hello World.
A kódban megjegyzés van arra, hogy a sok contructor sorból a rám megfelelőt ki kell kommentelni.Ez a kettő van:
U8G2_SSD1322_NHD_256X64_F_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 14, /* data=*/ 12, /* cs=*/ 15, /* dc=*/ 13, /* reset=*/ 4); // Enable U8G2_16BIT in u8g2.h
//U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ 15, /* dc=*/ 13, /* reset=*/ 4); // Enable U8G2_16BIT in u8g2.h
Az első SW, a második HW módban kezeli a kijelzőt. Az első tetűlassú, a második gyors. Az elsőnél clock, data, cs, dc, reset PIN-ek adhatók meg, a másodiknál csak cs, dc és reset. Clock és data nuku.
- Tehát az első 5-wire SPI nekem
, nem 4, bár elvileg a reset elhagyható és akkor 4-wire.
- A második viszont csak 3-wire SPI így, és meg se mukkan vele a kijelző.Az első működik, viszont látszik szemre, hogy tetűlassan teszi ki, lehet úgy 2fps talán ?
Srác is ezt tapasztalta előttem, hasonló cipő: [link]Szerintetek hogy a pékbe kell ezt HW módban használni, hogy működjön ? Mi a péket kössek hova, egy 4-SPI-s kijelzőnek, 3-kábeles felállásban, hogy működjön a gyors HW módban ?
-
Janos250
őstag
válasz
gyulank #16678 üzenetére
Régen én is PIC-et használtam, míg meg nem találtam az Arduinot. A régi PIC fejlesztő így már kipróbálás nélkül szomorkodik a fiókban a PICKIT mellett.
Az STM32 előnye - egyebek mellett - hogy ARM, amihez rengeteg minden van.
Én is Arduino alatt használtam, és kedveltem, amíg az ESP32 támogatottsága el nem érte azt a szintet, aminél már érdemesnek láttam átállni.
Akkor átálltam, és nagyon megkedveltem.
A PICBASIC-et én is használtam, de így utólag azt látom, hogy gyermeteg játék volt.
A PIC-en szerzett ismereteimet nem tudtam a későbbiekben felhasználni, a chipeket elajándékoztam, ami meg már annyira régi, hogy nem kellett senkinek, azt kidobtam.
Kedveltem, hogy a ChipCAD-nél mindent viszonylag tűrhető áron be lehetett szerezni, de persze a mostani kontroller árakkal nem versenyezhetne.
Az STM32-ből a nagyobbak, és a komolyabb fejlesztő készletek ára húzósabb, de a már említett kicsik olcsók, és jók, nagyon sok mindent tudnak, Arduino alatt is lehet jól használni a hardver lehetőségeiket.
Én az ESP32 mellett azért maradok, mert valós 2 magja van, és a hozzá illesztett fordító C++11, és a benne lévő WiFi nekem nagy előny, mert én nem használok se kijelzőt, se gombot, tekertyűt, miegymást, nekem minden a WEB lapon van, mert az ingyenes, és univerzális, a telefon meg kéznél van. És persze fel akarom hívni a figyelmet erre az "okos otthon", stb irányvonalra, aminek én komoly jövőt jósolok. Persze tévedhetek is. -
gyapo11
őstag
válasz
gyulank #16673 üzenetére
Sose programoztam picet, de gyűjtöttem hozzá anyagot, ha van rá kapacitásod 326 megát letölteni, akkor fölteszem a serverre, a listát itt találod.
Látok benne basic stampet, mikrobasicet, micropascalt, let-pic-basicet, pic basic pro-t, picpascalt meg még sok mindent, jó része dosos 20 évvel ezelőtti. -
ekkold
Topikgazda
válasz
Undoroid #16677 üzenetére
Saját célra készültek. Régebben vettem nagyon baráti áron néhány STM32F101 procit. Mivel mostanában nehézkes pl. a BluePill beszerzése, ezért (is) készültek ezek a kis modulok.
Az a vicces a dologban, hogy a 101-es proci elvileg 36MHz-es, a bluepill viszont 72MHz-es, de a BulePil-en levő procikat 104MHz-ig tudtam felhúzni fagyás nélkül, amiket vettem, az mindegyik megy 128MHz-en is. Ráadásul az F101 adatlapja szerint nincs benne USB periféria, a gyakorlatban viszont mindegyiken működik... Igy ezeket a kis modulokat is simán lehet arduinoval programozni. -
ekkold
Topikgazda
válasz
gyulank #16678 üzenetére
Igen! Mármint a nem igen. Tehát nem.
Nagyon régen programoztam PIC-et, és nálam sokkal-sokkal hozzáértőbbektől (több embertől is) azt hallom, hogy az ST-t érdemes megtanulni, mert az feljődik a leggyorsabban, és az utóbbi időben minden új fejlesztést ST-vel készítenek, kivéve ha valami nagyon alapos oka van hogy PIC-et kell használni. -
-
ekkold
Topikgazda
válasz
gyulank #16673 üzenetére
Igazából ez is led villogtatás, de készítettem néhány fejlesztőpanelt ami lábkompatibilis a BluePill-el. Minden I/O lábra került egy LED, ezzel tesztelem le, hogy sikerült-e rendesen beforrasztani a procit a panelre:
[VIDEO-MP4-link]
-
gyulank
addikt
PIC programozásról tud valaki jó anyagokat, lehetőleg magyarul? Amiben nem LED-et villogtatnak, hanem tudok belőle csinálni valamit amit kitalálok?
-
Undoroid
őstag
-
vegyszer
addikt
Már ha minden rendben van a csomaggal.
Nekem hétfőn jött meg egy fotófej. És rá volt írva, hogy 800Ft ellenében adják ki. Aliexpress-es beszerzés, 12000ft értékben. Mikor kérdezem, hogy mire föl, az a válasz jött, hogy azért, mert a csomag levél gyanánt volt feladva. Így a többlet költség engem terhel.
(Nem nagy összeg, de semmi papírt nem kaptam róla. És ezt bármire rá lehet majd fogni. De így is felé árban lett, mint itthon. És 3 hét alatt ért ide) -
gyapo11
őstag
válasz
razorbenke92 #16666 üzenetére
Én is ali-bg, aliról standard shipping és saver shipping, bg-ról banggood express.
-
-
-
Szancsó
aktív tag
válasz
Undoroid #16656 üzenetére
Analóg nincs, csak egy kb. 20 éves digitális és mivel sose tanultam így csak minimálisan boldogulok vele.
( Ezért a kapcsolási rajz is a ti mércétekkel ilyen gyerekrajz szinten lett volna. Illetve amatőrtől nem is biztos, hogy megéri ilyet kérni, mivel a rajzot ugyanúgy lehet rontani és akkor az félreviszi a dolgot. Fénykép jobb, bár ott meg egy komplikáltabb áramkör esetén ember legyen a talpán, aki kibogarássza a vezetékeket)
Viszont programozó lennék van mifene, így némileg lusta vagyok és a "debugot" a rövidebbik végén fogtam meg: mivel eléggé egyszerű az áramkör és átnézve nem tűnt fel hiba, így méregetés helyett csak kicseréltem a konvertert egy fix 5V -ot adó darabra, átkötöttem a Nano -n (VCC helyett 5V -ra) és rendbe is jött. Szóval úgy néz ki a DC-DC átalakítóval volt gond, ez megy rendesen és nem melegszik. (Összeforasztás előtt azért rámértem és így most alapon 18mA megy át a konverterből az Arduino felé.)
Köszi mindenki másnak is!( Majd még jövök erre szerintem...
)
-
Janos250
őstag
De, egyetértek. Én még Bangoodról is szoktam rendelni. Gyors, és szintén futár hozza, nincs külön fizetni való, de drágább, mint az Ali, és kisebb a választék. Amióta van ez a dili, ebay-ről nem rendeltem, azt nem tudom, mi van ott most.
Például 48V-ot is tudó DC/DC-t Bangoodon csak egyet láttam, csillagászati áron, Aliról rendeltem párat egy hete kb, majd meglátjuk. -
válasz
puritan #16661 üzenetére
Leginkább Aliról, mert rendezi az áfát, csak AliExpress-es standard shipping-gel kell kérni a csomagot, és akkor a posta nem teszi rá a
koszosmancsát a csomagra, hanem csomagküldő hozza és adja a kezedbe, minden külön díj és ügyintézés nélkül. Legalábbis nálam legutóbb így volt, és többek ugyanezt írták. De majd ír valaki, ha nem ért egyet. -
puritan
csendes tag
Kedves Mindenki!
Honnan érdemes most Arduino shield-eket, DC-DC konvertert, és egyéb apró, kis értékű elektronikai kütyüket beszerezni?
Korábban nagy részben az Ebayről rendeltm, kisebb részben az Aliról, de amióta az unió kitalálta nekünk ezt a nagyszerű vámolós dolgot, nem rendeltem semmit.
Ugye régebben nem volt probléma, ha minden 1 dolláros kütyü külön csomagban jött, most célszerűbb egy eladótól megvenni egy halom dolgot egyszerre, amit egybe csomagolnak.
Próbáltam európai forrást keresni, de egyrészt ilyesmi nem nagyon van eu raktárakban, de ha igen, akkor meg horribilis áron.
Ti honnan veszitek ezeket mostanában? -
Tankblock
aktív tag
válasz
ecaddsell #16652 üzenetére
pedig sok érdekes dolgot lehet faragni abból FPGAból. Szerencsémre munkahelyen nem egy project használ FPGA-t, bár én még nem tudok sokat hozzá ugatni se, de főleg a még a lényeg.
Próbálj meg autóiparban/Biztonság/... gondolkodni aztán rájösz hogy a sok Design Pattern nem is annyira az ödögtől való.
Ahogy haladunk az új dolgok felé az FPGA is lehet hogy ilyen lesz. Digikey is tolja a saját tananyagát, egy C7 board meg 31 + Áfa egy ismert webshopban ami már felfedezőnek is eléggé jó szett.
-
-
Undoroid
őstag
válasz
razorbenke92 #16657 üzenetére
Ez így rendben is van, de... " Nano-n van gyárilag LDO, emiatt a VIN-nek papíron 6V-20V, gyakorlatban 7V-12V betáppal mennie kell " Megy is, viszont közben valami miatt a konverter hatalmas hőt kezd el eldisszipálni, ami arra utal, hogy valami nagyon nincs rendben! Aminek a forrása a túláram, elkötés vagy a konverter hibás működése is lehet! Erre csak akkor kaphatunk választ, ha látjuk a jelenlegi áramkör teljes és valós kapcsolási rajzát! Ezért is írtam így: " Így -a teljes kapcsolás- pontos ismerete nélkül csak ennyit tudtam segíteni! " Csak tippeltem, mert ha minden rendben van, akkor ez a jelenség nem kellene, hogy mutatkozzon! Várjuk meg a kérdező válaszát a felmerült kérdésekre!
-
válasz
Undoroid #16656 üzenetére
Annyit szólnék bele a dologba, hogy az Arduino Nano-n van gyárilag LDO, emiatt a VIN-nek papíron 6V-20V, gyakorlatban 7V-12V betáppal mennie kell, ha nincs extra terhelés az 5V-ján.
(Szerk.: Innentől Szancsó-nak):
De ha nagyon akarod, akkor beiktathatsz egy külsőt is, akár 5V-osat is, de akkor már ne a VIN-en táplálj. Vagy tegyél be egy 7809-et, és a 9V-ot vidd az arduino VIN-jébe. Ez utóbbi azért javallott, mert kevesebb lesz az ohmos ellenállás a stabkocka és a fogyasztó között.Ha pedig mindenképp step-down-al akarod megoldani, akkor vegyél egy nagyobbat, lehetőleg olyat, aminek tisztességes pufferkondi van a kimenetén, és csinálj vele egyből 5V-ot.
(Bár ha nem akksis felhasználás lesz, akkor mehetsz stabkockával, mert hiába fűtöd el a 60%-ot, arányaiban és abszolút értékben is minimális a nyereség a LED-ek fogyasztásával összevetve.) -
Undoroid
őstag
válasz
Szancsó #16654 üzenetére
Üdvözöllek!
Az első kérdésre megkaptad a választ...most jönnek a logikus kérdések:
- Van-e otthon, nálad valami jóféle mérőműszer (az analóg lenne a legjobb), amit tudsz is helyesen kezelni?
- Meg tudod-e mérni vele a 12V-os ág és a konverter közötti (felvett) áramot?
- Meg tudod-e mérni a konverter kimenete és a Kontroller betápja között folyó áramot?
- Következő lépésként válaszd le a MOSFET-modult és úgy mérd meg a 12V-os ág és a konverter közötti áramfelvételt...ha ekkor jelentősen csökken az áramfelvétel, akkor valamit elkötöttél, ha marad a magas áramfelvétel és a hőfejlődés, akkor lehet, hogy elkötöttél valamit, avagy rossz a konverter...szerintem! Így -a teljes kapcsolás- pontos ismerete nélkül csak ennyit tudtam segíteni!
Ha a konvertered rossz és mégis egy 7805-ös stabkockát választanád (ennél olcsóbb és egyszerűbb megoldást nem nagyon találni) akkor egyszerű dolgod lesz a bekötésével! Még elkötni is nehéz, mert mindössze 3 lába van!
Szerk: " Találtam egy hasonlót otthon (csak másik fajtát) és majd kicserélem " Ugye az egész konvertert akarod cserélni és nem csak a rászerelt potmétert?
A rosszul megválasztott poti az egész konvertert és a rákötött mikrovezérlőt is hazavághatja! Szóval csak óvatosan!
-
válasz
Tomika86 #16653 üzenetére
const float c1_1 = 1.1494275e-03;
const float c2_1 = 2.5608838e-04;
const float c3_1 = 0.6755814e-07;
const double d1_1 = 1.1494275e-03;
const double d2_1 = 2.5608838e-04;
const double d3_1 = 0.6755814e-07;
printf("%.20f\n%.20lf\n%.20f\n%.20lf\n%.20f\n%.20lf", c3_1, d3_1, c2_1, d2_1, c1_1, d1_1);
0.00000006755814041526
0.00000006755814000000
0.00025608838768675923
0.00025608838000000002
0.00114942749496549368
0.00114942749999999991Szerintem a float is elég pontos, de a legtöbb lebegőpontos függvény double-t eszik, szóval nem szórakoznék floattal.
-
Szancsó
aktív tag
válasz
tonermagus #16651 üzenetére
Ja, az nem végállásban van azért, de már nem rémlik. Találtam egy hasonlót otthon (csak másik fajtát) és majd kicserélem - megnézem az mennyire bírja a gyűrődést.
Egyébként igen, a 12V --os táp megy a MOSFET modulon át a LED szalagra, illetve párhuzamosan a konverteren át az Arduino bemenetére.
-
Tomika86
senior tag
Sziasztok!
Ezeket így teljesértékű adatokként tudom kezelni ha "csak" float?
// Beszívott levegő NTC adatok
const float c1_1 = 1.1494275e-03;
const float c2_1 = 2.5608838e-04;
const float c3_1 = 0.6755814e-07;Vagy double-ként kellene?
A számolások végén a hőmérséklet "csak" 1 tizedes kijelzésűKöszönöm!
-
ecaddsell
aktív tag
válasz
Tankblock #16642 üzenetére
Lassan FPGA is olyan olcsó lesz h csak na és abban meg mindent is lehet csinálni még Linuxot futtató ARM magokat is lehet szimulálni.
Ilyet csak elborult elméleti (szak)emberek meg retró bolondok csinálnak amikor a soft core helyett ott van a zynq 7020 két arm maggal.
A C++ design patternek tényleges használatához is kell némi elborultság.
Egyébként mivel nálunk komoly elektronikai fejlesztés nem folyik tényleg nincs igény FPGAs dolgokra, hobby szinten meg a BGA tokozás meg a 4 rétegű nyák megint okoz némi természetes szelekciót...
-
tonermagus
aktív tag
válasz
Szancsó #16650 üzenetére
Trimmer szerintem a szabályzón lévő feszültség beállító csavar.
Egyébként én jelenleg is használok ilyen megoldást amit Te. 12V-ról lehúzom 5V-ra a feszültséget, de rövid távon nem vettem észre, hogy melegedne. LM2596-ot használtam, gondolom Te is azt használod.
Erről a fasz stabilizátorról ment egy Ardu és egy GPS modul is.
Az a LED szalag ~1,8A-t fogyaszt teljes fényerőn, fehér színben.
Tehát van egy 12V tápod ami egyrészt megy a LED szalagra, másrészt egy DC-DC stepdownra, ami 7V-ot állít elő és azt rákötötted az Ardu VIN lábára? -
kavalkád
senior tag
egy Nema 17-es stepper motornak (nincs benne nyomaték áttét) mennyi kb. a maximálisan elérhető fordulatszáma DRV8825 illetve A4988 vezérlővel ha a motor 24V-ot és 2A-t kap? Arduino Nanoval lesz meghajtva.
-
Undoroid
őstag
válasz
Szancsó #16647 üzenetére
Akkor valószínű, hogy azért melegszik ennyire az a modul, mert kitekerted a trimmer-t 'nullára' és ez annak a modulnak nagyon nem tetszik! Az "ilyesmi" kimenetére mit kötöttél?
Ha a teljes terhelésed áramfelvétele nem haladja meg az 1A-es határt, akkor a DC-DC konverter helyett használj egy 7805-ös stabkockát! Nem árt rá egy kis hűtőzászló, de vigyázz, mert negatív potenciálon lesz a hűtőzászlód!
-
Janos250
őstag
válasz
Tankblock #16642 üzenetére
Az igaz, hogy kell a sikerélmény, és ebben az UNO verhetetlen, mert túlcsordul tőle a net. Hogy kinek mit ajánlunk, az egy sokkal általánosabb didaktikai probléma. Van, aki azt mondja, hogy a kezdő kezdjen a régebbi dolgokkal, van aki azt, hogy a kezdő is a korszerűvel kezdje. Nekem ezidáig egyetlen pattern se volt hasznomra, de lehet, nem igazán kerestem. A C++ az UNO-n és a többin is ugyanaz - kibővítve néhány spec Arduino dologgal - és persze régebbi, vagy újabb verziójú fordító, de az újabban is (majdnem) minden benne van, ami ami a régiben, alig van valami, ami obsolete.
Az FPGA dolgot nem tudom. Elég közeli ismerősöm diplomamunkája volt az FPGA, de azóta elő se vette, mondván, nincs rá igazán igény, inkább az általánosabb megoldásokat kedvelik.
Majd meglátjuk, én csak néha ránéztem, mit csinál, de soha nem foglalkoztam FPGA-val.
Egyébként az a véleményem, hogy ami UNO-n elmegy, az általában korszerűbbön is elmegy, és akkor a felhasználót idővel csak hajtja a kiváncsiság, hogy továbblépjen, de ha ehhez lapot kéne váltani, akkor inkább ott ragad. -
Szancsó
aktív tag
Sziasztok!
Elkezdtem próbálkozni Arduino Nano -val és lenne vagy 2 kérdésem, az egyik "égetőbb".
1) LED vezérlésre lenne használva, ehhez a LED 12V-os tápjáról hajtanám meg egy kis DC-DC step-down átalakítóval, amin a poti segítségével 7V -ra lőttem be a kimeneti feszültséget. A gondom ott van, hogy a szabályzó melegszik, de nem kicsit. Ennek egy zárt dobozkában lesz a végleges helye és nem szeretnék még egy 5V -os bemenetet is használni. Van valakinek ilyen bevált szabályzó, ami nem fő fel és elérhető mondjuk EU -n belül? Végszükség esetén lehetne valami hűtőbordás verzió és azt kirakom akkor a dobozból a LED tápja mellé, de az sem lesz épp huzatban
(Valami ilyesmi lehet.)2) unsigned long változókban tárolok "időt" és van egy függvény, ami 2 idő különbségét adná vissza. Az mitől lehet, hogy ehelyett fixen a típus max. értékével (4294967295) tér vissza?
-
Tankblock
aktív tag
válasz
Janos250 #16639 üzenetére
Szia,
Arra próbáltam reflektálni, hogy kezdőnek csak óvatosan az ajánlásokkal, mert általa nem vagy csak nehezen feloldható problémák jöhetnek elő. A Design Pattern meg azért szükséges, mert adott problémára nyújt működő megoldást.
Aztán ha megy a C,C++, ... bármilyen programnyelvben is akkor lehet mélyre ásni. Tanulási görbe mellett fontos a sikerélmény is.
Én mondjuk a Micro Phytonnal vagyok úgy hogy életidegen feláldozni egy csomó erőforrást egy interpreterre, de ki tudja merre megyünk.
Lassan FPGA is olyan olcsó lesz h csak na és abban meg mindent is lehet csinálni még Linuxot futtató ARM magokat is lehet szimulálni. -
válasz
Janos250 #16639 üzenetére
Ne becsüljük alá annak a jelentőségét, hogy nagyon sokszor azért használnak egyszerűbb processzort, mert egyszerűbb-> megbízhatóbb. Nem ok nélkül használtak például még a 90-es évek végén is Intel 8086-os CPU-kat az NASA űrsiklóiban: a lassabb órajel, a nagyobb csíkszélesség jobban tűrte a szélsőséges körülményeket, kiröhögte az űrbéli háttérsugárzást.
Én ha egy feladatot meg tudok oldani AVR-rel, nem fogok ESP-t használni, ha nincs szükségem a nagyobb tudásra. Miért? Mert régebbi, kipróbált technika, jobban tűri a hibákat (például: ESP-n lévő flash chip 3,6V tápfeszültségen megfő, egy AVR 7-8V-ot simán kiröhög). -
Janos250
őstag
válasz
Tankblock #16638 üzenetére
Igazad van, de éppen a mikrokontrolleres alkalmazásban gyakran vannak egymástól teljesen független teendők. Például az egyik szál nem csinál mást, csak egy hőmérsékletet olvas, és ez alapján állít egy PWM-et, és ezeket senki más nem használja. A másik szál meg figyeli a lángérzékelő detektort, hogy nem lángol-e az Anetka (kigyulladni szerető 3D nyomtató), és ha igen, akkor mindent áramtalanít, vagy szirénázik, vagy akármi. Hát az ilyennel nagy tudomány lenne deadlockot generálni.
Aztán, ha egy több bájtos adatot egy valaki ír, de többen olvassák, akkor meg lehet flaget használni.
És persze - mint írtad - a freeRTOS tudja ezeket kezelni. A minták szerintem nem igazán használhatók a sokszálazáshoz.Megnéztem, tényleg rendben van a PWM.
Én továbbra is úgy vagyok vele, hogy ha ott van a ládafiában a Mega, akkor ne dobja ki, használja, de venni már ne vegyen, hanem vegyen korszerűbbet. Elsősorban azért, hogy megtanulja.Én mindenesetre maradok az ESP-nél, pedig valóban van még nekem Z80 is. Amit mellesleg - a maga idejében - kedveltem is. Lehet, ezért szerettem a ZX81-et, és a Spektrumot is.
-
Tankblock
aktív tag
válasz
Janos250 #16637 üzenetére
Szia,
Ha már Thread és kezelés, ESP32 -n ott a FreeRTOS, az legalább threadsafe módon tud megszakításból is adatokat kezelni, van benne MUTEX, miegymás....
Ha nem vagy jártas Design Patternekben a sokszálazáskor random fogsz találkozni a az ugynevezett Deadlock jelenséggel, ami kezdőnek megtalálni nem triviális. Azt nem mondom egy szóval sem hogy a FreeRTOS nem lehet ilyet csinálni, mert lehet, de a dokumentációjában nagyban segít benne.
AVR ekben nagyszerűen van hardwaresen a PWM megoldva. A Mega az egy 2560 as (még ANSI Cből vagy Assemblyből is
)... [link]
Volt alkalmam könyékig turkálni pár kódban, van amire nem használnak ESP-t csak bevált technológiát hiába régi. -
Janos250
őstag
válasz
tonermagus #16629 üzenetére
"Egyszerűen csak profibbnak érezné ha ESP/STM-en futna..."
Nem az a lényeg a váltásnál, hogy "profibb"!
A korszerűbb technikára való áttérésnek az az elsődleges előnye, hogy megtanulod.
Évek múltával úgyis mindenből a korszerűbb jön elő. Én használtam a Z80-at. Ami akkor kellett, meg tudtam vele oldani, mert nem is gondoltam olyan dolgokra, ami azzal ne lett volna megoldható. Ma már nagyon nem szívesen dolgoznék Z80-al, pedig még valószínűleg kerülne 1-2 darab belőle, és vannak olyan dolgok, amit azzal is meg tudnék oldani.
A jelen problémára visszatérve: Az, hogy egy csomó minden hardverben meg van oldva, ha azokat az emberfia megismeri, azok azért hasznosak.
Továbbá a multitasking szisztéma is olyan, hogy nagyon sok mindent világosabban, áttekinthetőbben lehet vele megoldani. Mondok egy példát a saját dolgomból.
Hőmérő méri a hőmérsékletet (akár Z80-al is meg tudnám oldani, de nem teszem), és időnként WiFi-n átküldi egy másik lapra, ami mindenféléket csinál. Hogyan oldjuk ezt meg? Időnként lekérdezzük a ciklusban, hogy jött-e új adat, ha igen, akkor azt beolvassuk, és beírjuk, hogy onnantól kezdve azzal számoljunk.
ESP32-n: egyik task semmi mást nem csinál, csak megnézi, érkezett-e új adat, ha igen, akkor azt beteszi a globális változóba, így mindig automatikusan a legfrissebb adattal történik a további meló. Az "időnként megnézi" azt jelenti, hogy semmi más nincs egyik taskban, mint "megnézi", ha van beolvassa, majd delay. Ugyanis a multitasking esetén a delay nem jelenti azt, hogy ténylegesen várakozik, hanem, hogy a várakozás alatt egyszerűen nem megy rá a vezérlés arra a taskra, hanem fut a többi. Az már csak hab a tortán, hogy két mag van, és megválogathatjuk, ha akarjuk, hogy melyik task melyik magon fusson. Így ídőkritikus dolgokat lehet tenni önállóan az 1-es magra, ami meg ráér, az mehet minden a 0-ra. Ha meg nem akarjuk, akkor rábízhatjuk az oprendszerre, hogy válogasson, azaz egyszerűen használjuk a C++ thread-jét
Például:thread szal1(helloWorld1);
thread szal2(helloWorld2);Ha kell:
szal1.join();
szal2.join();
Ő majd eldönti, mit hova tegyen.
Ha ezeket megtanulod, akkor jössz rá, mire is használd. Evés közben jön meg az étvágy."- 8 db PWM értéket mérek digitális bemeneten
- 10 db PWM értéket írok ki digitális kimeneteken"Nem tudom, mennyire jól van a PWM a Megán megoldva, de STM-en, ESP32-n például igen kényelmesen, hardverből.
-
Tomika86
senior tag
válasz
tonermagus #16632 üzenetére
A jelszintek is változnak ESP32 esetén, 3,3v lehet maximum.
-
válasz
tonermagus #16632 üzenetére
Egyszerűen csak profibbnak érezné ha ESP/STM-en futna...
Hülye sznob...
-
válasz
tonermagus #16632 üzenetére
Nekem anno azt mondta az egyik tanárom, hogy mindig van jobb, olcsóbb meg gyorsabb. A jó mérnök nem az, aki mindenből a legjobbal dolgozik, hanem aki tudja, hogy mibe fektesse a leghasznosabban a forrásait.
Ha valóban szükséged lesz valami miatt platformot váltani, akkor pedig majd fogod tudni, hogy mit keress, mi az amiből jobb kell.
-
tonermagus
aktív tag
Hát ez az, nem lassú semmi
Egyszerűen csak profibbnak érezné ha ESP/STM-en futna...
Természetesen nem használok blocking delay()-t, csak millis()-el operálok.Személyes véleményem hogy hiába lenne gyorsabb a hardware, az adatok amikkel dolgoznom kell úgyis csak 500ms-enként jönnek... Szerintem ezt röhögve tudja a Mega.... Még ha 100ms-enként jönne az adat, gondolom még az sem lenne neki probléma.
-
válasz
tonermagus #16629 üzenetére
Egész pontosan mi az a jelenlegi konfiguráción, amit lassúnak talál? Lehet, hogy egyszerűen csak szoftver-optimalizálásra van szükség.
Amiket írtál, hogy másodpercenként 2 alkalommal, meg 10 másodpercenként csinálsz feladatot, ezeket gondolom aszinkron módon oldod meg, nem delay()-jel -
tonermagus
aktív tag
Sziasztok!
Sebességgel kapcsolatos kérdésem lenne.
Egyik kollégám folyamatosan csesztet, hogy a már meglévő Arudino Mega 2560-on futó projektemet ültessem át ESP32/STM32-re, mert hogy azok sokkal gyorsabbak.
Ebben igazat adok neki, tény hogy azok a mikrovezérlők jóval gyorsabbak.
Viszont én úgy gondolom, hogy arra a feladatra amire én használom az Arduino Mega 2560 sebessége is túlzó.
Ebben kérném a segítségeteket, hogy ti mit gondoltok? Elég a Mega?
A kód kb. ~300 sorból áll.
Amit a fő loop csinál dióhéjban:
- másodpercenként 2 alkalommal GPS koordinátát olvasok be (2Hz)
- ezekhez a koordinátákhoz képest looponként számításokat végzek. Irány, távolság, szatelitek száma, stb.
- 1 db UART porton keresztül looponként beolvasok 10 sort
- 1 db UART porton keresztül looponként kiírok 5 sort
- 8 db PWM értéket mérek digitális bemeneten
- 10 db PWM értéket írok ki digitális kimeneteken
- Másodpercenként 10 alkalommal olvasok be i2c eszközről adatot
- a kód többi része if feltételek és matematikai sorokból áll össze, jellemzően soronként egy feltétel/művelet és tök egyszerű összeadás/kivonás
- Feltétel teljesülése esetén EEPROM-ba írok 10 memóriaterületre adatot (ez csak ~10 secenként forul elő)
Szerintem ez egy Arduino Megának bele kell hogy férjen a számítási sebességébe, jól gondolom?
Nem akarnék teljesen feleslegesen áttérni ESP/STM-re csak azért mert az gyorsabb, de amúgy gyakorlatilag semmi különbség nincs a kettő között... Én úgy gondolom a vékony keresztmetszet jelenleg a GPS modul...
Amúgy meg a sok EEPROM kezelés miatt úgy hallottam célszerűbb Arduinot használni. Talán annak jobb a memória kezelése.
Ti mit gondoltok? -
Janos250
őstag
-
Janos250
őstag
Régebben én is megnéztem, de úgy döntöttem, maradok az ESP32-nél:
Okok:
A legfontosabb, hogy az ESP32-n bótilag ott a WiFi
Ugyanígy 2 mag van benne, amihez elég jó a kezelés, nem tudom, ez hogyan van a RP-nél
C++11 fordító van hozzáillesztve, lehet, hogy az RP-nél ez jobb, mert ARM proci van benne.
Vannak, akik szidják az Arduino kezelő felületét, de én megszoktam, nekem jó.
Az ESP32-n van még egy csomó hardver (periféria) lehetőség, ami hasznos, de az RP-n nincs.
Az, hogy az ESP32 összes lábát bármire tudom használni, azaz bármit át tudok helyezni bármelyik lábró bármelyik másikra, az számomra előny.
Az ESP32-re rengeteg kidolgozott program, könyvtár van, fene tudja, mi a helyzet az RP-vel. -
_q
addikt
Mit gondoltok a raspberry pico-ról? Én ESP32-t használok, esetleg arduino minit és nem látom hol van az előnye. Vagy ez nem is erről szól, hogy előnye lenne, csak a raspberrysek egy rést fedtek le vele, a név meg eladja a terméket?
-
-
válasz
kavalkád #16622 üzenetére
erre valók a step-up/step-down eszközök?
Pontosan. Kellene egy dedikált 35V-os táp, és abból kellene előállítani egy step-down konverterrel az 5V-ot. Bár nem tudom, hogy van-e belőle olyan, ami ekkora tápfeszültségről is működik, emiatt esetleg lehetne helyette egy külön usb-s töltő az Arduino tápja.
Esetleg ha mindenképp 1 eszközt szeretnél, egy olyan trafót lehetne használni, ami mindkét tápfeszültséget elő tudja állítani, és abból csinálni egy stabilizált tápot, de ebben szerintem a hobbielektronika topikban több segítséget kapsz.
-
kavalkád
senior tag
teljesen kezdő vagyok ebben az Arduino bizniszben, elektronikai ismeretem erősen korlátozottak, úgyhogy előre is bocs ha valami triviálisan egyértelmű kérdéseim lennének most vagy a jövőben.
egy egyszerű kis stepper vezérlőt próbálok összerakni, amit Uno vagy Nano vezérelne, DRV8825 vagy A4988-as vezérlővel. kapcsolási rajzot találtam, szoftvert meg tudom írni, amiben viszont segítség kellene az, hogy mivel transzformáljak áramot hálózatról.
az Arduino-nak kellene 5 V, viszont a stepper olyan 35V körül szeretném táplálni (a leírása szerint ez a max amit tud) olyan 1.5-2A-el. hogy tudnám megoldani, hogy egy eszközzel le tudjam venni mindkét feszültséget? erre valók a step-up/step-down eszközök vagy teljesen rossz nyomon járok?
-
Undoroid
őstag
-
válasz
Undoroid #16616 üzenetére
Az Arduino IDE-ben keresd meg a könyvtárak kezelését, és írd be a keresőbe az eszköz nevét! Ha szerencséd van, 1db találatot kapsz rá, ami pont ez lesz.
Ha nincs szerencséd, több találatot is kaphatsz, amiből lehet mind jó, de lehet egyik sem. Ilyenkor egyesével töltsd le, próbáld ki, ha nem jó, töröld, és töltsd le a következőt.
Abban az esetben, ha egyik fenti megoldás se működik, a Google-ben keress rá arra, hogy "DS18B20.h", valószínűleg találsz egy github oldalt, onnan töltsd le az összes fájlt zip-ben:
majd csomagold ki az Arduino könyvtárban található library könyvtárba. -
válasz
Undoroid #16616 üzenetére
Ez egy ún. header fájl, amiben konstansok, függvény deklarációk, makrók vannak. Ez azért kell, hogy az objektumfájl le tudjon fordulni. Utána, hogy működő programot kapj, hozzá kell linkelni a könyvtárat is. Tehát a megoldás az, hogy fel kell telepíteni Arduino IDE-ben a könyvtárat, és akkor már fordulni fog a kód. Mármint nem te linkelsz, hanem az IDE helyetted, de a háttérben ez történik, többek között.
-
Undoroid
őstag
Sziasztok!
Ismét a szakértelmeteket szeretném segítségül hívni! Tudjátok, hogy teljesen kezdő vagyok ebben a témában, de remélem elnézitek ezt Nekem!
Nemrégiben vettem egy kezdőkészletet és szereztem hozzá egyszerű próbafeladatokat, amiket egymás után ki is próbáltam, de...
...de volt olyan feladat is, aminek a program legelején szerepelt egy sor, ami a példában szereplő főalkatrész nevét tartalmazta és minden esetben ".h" -kiterjesztésű (?) volt. Ahogyan ITT is: " #include <DS18B20.h> "
A próbafeladataim egytől - egyig a teljes programot tartalmazták, de amiben ez a sor benne volt ott már a feltöltésnél problémák akadtak...
Kérdés: mire szolgál ez a sor? Hogyan kell az ilyet pótolnom, mert nyilván nélküle nem megy a dolog!
Biztos pofonegyszerű a válasz, de Én nem szégyellek kérdezni, ha valamit nem tudok!
-
Janos250
őstag
válasz
Tankblock #16614 üzenetére
Igazad van, az RTOS nem operációs rendszer olyan értelemben, hogy nem tudok konzolról ilyen-olyan userként bejelentkezni, programokat futtatni, de nekem erre egy mikrokontrolleren nincs is szükségem. Amire szükségem van, azt tudja. Legalábbis az Espressif kiegészítéseivel. Tudja a fájlok kezelését úgy, hogy ha írok neki egy fájlnak a C szerinti megnyitását, tudja mi az, vagy ha azt mondom neki, hogy cout, tudja miről beszélek.
Ha valamelyik perifériát fájlként akarom használni, akkor persze meg kell hozzá írnom a drivert, de ezt be tudom illeszteni az ő rendszerébe, beírja a fájl leíró táblába, és onnantól már fájlként (is) tudom használni. Kell persze saját magamnak írni drivert, de már a DOS-hoz is saját magunk írtunk COM port kezelő drivert, mert az eredeti nem megszakítással dolgozott, pedig az Ix86x proci tudta.
Vagy, ha nem akarom az ő thread kezelését használni, hanem a programban szerepel a thread és a join, tudja, mit akarok, a fordító le tudja fordítani az ő API-jaira.
Végezetül, ami elvárásom nekem van egy mikrokontroller nem tudom, minek nevezzemjétől, az ebben az ESP32-ben benne van. Mellesleg viszonylag korszerű fordítót használ, bár nagyon sok mindent nem használok ki, mert például lambdát csak minden második szökőévben, bár azzal számos dolog tömörebb. -
Tankblock
aktív tag
válasz
Janos250 #16613 üzenetére
[link] A Wiki is pont azt mondja hogy :
RTOS typically does not have the more advanced features that are typically found in operating systems like Linux and Microsoft Windows, such as device drivers, advanced memory management, user accounts. The emphasis is on compactness and speed of execution. FreeRTOS can be thought of as a thread library rather than an operating system, although command line interface and POSIX-like input/output (I/O) abstraction are available.
Ezért írtam inkább egy scheduler mint egy rendes operációs rendszer. Bare Metálba kell megírni hozzá egy csomó mindent, ami meg van annak meg örülni kell.
[link] pont arról beszél, hogy mikor éri meg milyen projectet építeni. 10 perc körül....
-
Janos250
őstag
válasz
Tankblock #16612 üzenetére
(I)"FreeRTOS használ és az nem egy operációs rendszer sokkal inkább egy scheduler."(/I)
Hát, azért az OS, ha nem is hejde...
Igaz ugyan, hogy boldog és boldogtalan ráhúzta a freeFTOS-t a legkülönbözőbb kontrollerekre, és gondolom, pl. az AVR-ekre megírt verziók csak schedulerek.
A freeRTOS tartalmazza például az lwip-t, ami egyértelműen UNIX filozófia.
Onnan tudom, hogy az ESP32 net kezeléséről kevés info van a neten, de a UNIX-hoz rengeteg, és azt kell nézni, mert teljesen passzol az ESP-hez. A teljes socket kezelés, miegymás. A nevek is megegyeznek.
Espéék nem találták fel a spanyol viaszt, hanem - jó kínai módra - alkalmazzák azt, amit mások megcsináltak.
Van file leíró tábla, ahova a file-ok be vannak jegyezve. A soros port sorszáma (file descriptor) például 2.
Futtasd le a következő programot:void setup() {
Serial.begin(115200);
delay(2000);
FILE* filePointer = fdopen(2, "r+");
fprintf (filePointer, "Szevasz ESP!\nEn vagyok a soros port\n") ;
fclose(filePointer);
} ;
void loop() {};Vagyis eredendően a Serial is file, csak rá van ültetve mindenféle Arduino dolog.
-
Tankblock
aktív tag
válasz
Janos250 #16611 üzenetére
Nem véletlenül a ESP32 Flash structúrájában hasznáét SPIFF et használod itt, mint háttértár?
Arduino alatt lehet hogy az is be van hozzá includálva.
Ahol minden egy file az UNIX alapú operációs rendszerek.
ESP32 FreeRTOS használ és az nem egy operációs rendszer sokkal inkább egy scheduler. -
Janos250
őstag
Való igaz, hogy mondjuk az UNO-n és se akartam fájlként kezelni semmit, a PIC-eken meg végképp nem. Attól függetlenül, hogy nincs háttértároló, még a UNIX-ból adódóan eléggé elterjedt a "minden fájl" szemlélet. Tényleg az ESP-ben gondolkodom, de én azt hiszem, növekszik azoknak a tábora, akik áttérnek valamilyen 32 bitre.
ESP32-n például a WiFi is fájl. Lehet rá fájlként írni, róla fájlként olvasni, és nem kell hozzá külön library, hanem a C-ben szokásos file kezelési módon használható.
Például:FILE* filePointer = fdopen(fileSorszama, "r+");
fprintf (filePointer, "Szevasz!\n") ; -
Tankblock
aktív tag
válasz
Janos250 #16607 üzenetére
Szia
No problem, ismerem az érzést. Nem hiába szoktam a C++ referenciát betenni.
Nincs a standard C vel sem semmi probléma. Feladathoz választunk megoldást, és nem fordítva. Addig örülj amíg nem más által összerakott projectbe kell új featuret írnod, full nulla dokumentációval, kesze kusza arhitechtúra alatt....Amúgy a structos megoldást egyszer már megcsináltam demo szintjén, működik szépen, a hátránya a castolás overheadje.
Az összevissza könyvtárazást ar Arduino hozta el véleményem szerint. és mivel kényelmes elfejeltettek programozni, csak az jön hogy nem működik.... Igen ez egy szép szakma....
-
-
-
Janos250
őstag
válasz
Tankblock #16605 üzenetére
Igen, így van.
"előre meg nem határozott számú paramétert"
Rossz volt a megfogalmazás, mert valóban egy paramétert visz be.
A helyes megfogalmazás az lett volna, hogy "előre meg nem határozott számú adatot" . Ezalatt azt értettem, hogy a függvény írásakor nem tudjuk, hogy hány beviendő adat lesz. Persze, a ... a feladathoz jobban passzoló. Ezért is kerestem ki a neten először azt, mert már nagyon régen csináltam, gőzöm nem volt, hogyan is kell. Ezt tettem a 16600-ba.
"Amit csinász az standard C ben is egy láncolt listára is mutathatna.... akár egy pointer is". Teljesen igazad van, de én azok közé tartozom akiknek feláll a szőr a hátukon a standard C nagyon széles pointer használatától. Nem is foglalkoztam a C-vel, csak később a C++ -al. Igyekszem nem lemenni alacsonyabb szintekre, ha nem muszáj. Épp eleget programoztam assemblyben ahhoz, hogy kerüljem az alacsonyabb szinteket. Persze azért nem akarom a COBOL szószátyár szintjét sem, de a C++ az szimpatikus, szimpatikusabb, mint a pascal bővítések.
"ennyi erővel struct ba tehetnél". Igen az általánosabb, nem macerás.Én azért úgy gondoltam/lom, hogy nem káros emlékeztetni/megmutatni/memóriát frissíteni (ki hol tart a programozásban) azt, hogy a vektor, list, deque, és egyéb konténerekről se feledkezzünk meg, és hogy az iterátorok nem felesleges dolgok, meg az auto se, ezek néha egyszerűbbé teszik az életünket, mintha visszamennénk a standard C szintre. Ott nem kell se iterátor, se auto.
Mellesleg most muszáj a standard C-vel foglalkoznom, mert kíváncsiságból az ESP32 net kezelését bogarászom mélyebben, és az LWIP ugyebár a standard C-ben íródott.
Ez legalább emlékeztet arra, hogy minden külvilággal való kapcsolat "file". Tulajdonképpen nem is tudom, hogy a mikrokontrolleres világban a perifériákra miért nem a bevált file kezelést alkalmazzuk, ahelyett, hogy ezerféle könyvtárat használnánk, és összevissza hibákat okoz, hogy egy neten talált program nem megy, mert más könyvtárat használ.
Az SPI, stb. kényelmesen kezelhető file-ként is az ESP32-n is.
Hű, hosszú lett, bocs mindenkitől. -
ekkold
Topikgazda
válasz
Janos250 #16600 üzenetére
Köszönöm! Kb ilyesmit találtam én is, a
va_arg
()-nak meg kell adni milyen típusú paramétert olvasson fel, és visszaadja az értékét. Tehát vagy meg kell adni, hogy hány paraméter van aktuálisan, vagy a legutolsó paraméternek kell pl .nullának, vagy mondjuk nullpointernek lenni, amiből a program tudhatja, hogy ez volt az utolsó paraméter. Azon gondolkoztam, hogy írok egy printf()-hez hasonlóan működő függvényt ami alfanumerikus LCD-re ír, de kevesebbet tud mint a printf (csak egész számot és c stringet kezelne), és cserébe sokkal kevesebb erőforrást fogyasztana mint a sprintf() + lcd-re írás. -
Tankblock
aktív tag
válasz
Janos250 #16604 üzenetére
Szia,
ezen példáidban pont hogy meghatározott számú lesz.... std library elemei a bemeneten....
Ha nem tudod hogy mennyi, akkor a (...) lesz használatos, de ugye ezzel csak annyi lesz hogy fordítási időben lesz meg.....Amit csinász az standard C ben is egy láncolt listára is mutathatna.... akár egy pointer is....
ennyi erővel struct ba tehetnél egy void * és egy type paramétert és ebből egy listát/vectort, na akkor már bármit beletehetsz. Utána típus castolással vissza tudod alakítani. Ebbe még függvény pointert is tehetsz....
-
Janos250
őstag
válasz
ekkold #16588 üzenetére
Hogyan tudunk függvénybe bevinni előre meg nem határozott számú paramétert?
Közben csináltam mintapéldát, hogyan tudjuk belerakni containerbe, akármennyi van is, és a függvényben iteratorral annyit használunk fel, amennyi van./*
mintapelda elore meg nem hatarozott szamu parameter atadasa fuggvenybe iteratorral
Minden olyan container hasznalhato, aminek van .begin() es .end() iteratora
peldaul: vector, list, deque, map, set, stack, stb
*/
#include <iostream>
#include <vector>
#include <list>
#include <deque>
using namespace std;
//void parameterAtadasVectorral(auto parameter){ // ez csak C++14 -tol el
void parameterAtadasVectorral(vector <int> parameter){
Serial.println("\nfelhasznaljuk a vector elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
//vagy: for (vector<int>::iterator i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void parameterAtadasListaval(list <int> parameter){
Serial.println("\nfelhasznaljuk a lista elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void parameterAtadasDequeSorral(std::deque <String> parameter){
Serial.println("\nfelhasznaljuk a deque elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void setup() {
Serial.begin(115200);
delay(1000);
vector <int> enVectorom {10,115} ;
enVectorom.push_back(8); // a vegere betesz egy elemet
parameterAtadasVectorral(enVectorom) ;
std::list<int> enListam = { 9,7,3,29 };
enListam.push_back(50);
parameterAtadasListaval(enListam) ;
std::deque<String> enDqueueDuplaveguSorom= { "macska","kutya","lo" };
enDqueueDuplaveguSorom.push_front("kismalac"); // elejere teszi
enDqueueDuplaveguSorom.push_back("pipi"); // veger teszi
parameterAtadasDequeSorral(enDqueueDuplaveguSorom) ;
} ;
void loop() {
};
/*
Ezt irja ki:
felhasznaljuk a vector elemeit:
10
115
8
felhasznaljuk a lista elemeit:
9
7
3
29
50
felhasznaljuk a deque elemeit:
kismalac
macska
kutya
lo
pipi
*/ -
Janos250
őstag
válasz
Dißnäëß #16599 üzenetére
"Mi a különbség print és printf között ?"
A printf-ben megadsz egy szöveg mintát, hogy "így nyomtasd ki", és ebben szövegben a printf-ben az idézőjeles szöveg után felsorolt, kinyomtatandó változók helyét egy % jellel jelzed, és hogy milyen formában, azt meg közvetlenül a % után megadott specifikáló kóddal.
Pl: előjeles decimális d, vagy i, előjel nélküli decimális u, hexa x, stb.
Azt is megadhatod, hogy hány jegyre nyomtasson, stb.
A sortörést a \n -nel adod meg.
Új hozzászólás Aktív témák
Hirdetés
- MSI RTX 4070 SUPER 12GB GAMING X SLIM WHITE - 20 hónap garancia
- GIGABYTE RTX 4070 SUPER WINDFORCE OC 12GB - 20 hónap garancia
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Csere-Beszámítás! Olcsó RTX Gamer Laptop játékra! I5 11400H / RTX 3050Ti / 16GB DDR4 / 512GB SSD
- Lenovo Yoga Pro 9 (16IMH9) - Intel Core Ultra 9 185H, RTX 4060, 32GB, érintős ELKELT
- Azonnali kézbesítés az év bármely pillanatában
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest