Ez sajnos az arduino keretrendszer "hülyesége", nincs mit tenni vele.
Van egy megérzésem, hogy a "00002" cím nem fog működni. Ez egy egészen elmebeteg, sok kódolási konvencióval szembe menő szintaktika. Próbáltam rákeresni, de egyelőre sikertelenül.
uint...
u = unsigned, vagyis nem előjeles (nem lehet negatív értéke).
int = egész, tehát nem lebegőpontos (tört).
64_t = 64 biten van ábrázolva, ez annyit jelent, hogy meglehetősen nagy térben tud gazdálkodni. Az Arduino keretrendszerben alapvetően nem is értelmezhető, hiszen az arduino 8 bites mcu, tehát kvázi a rendszer megerőszakolása. Persze a forító megoldja, hogy értelmezhető legyen, de vészes gyorsasággal zabálja a memóriát. Ez technikailag egyébként két unsigned long típusú változó (azok 32 bitesek és alapból része a keretrendszernek). A _t jelzi a fordítónak, hogy platformtól függetlenül ugyanakkorának kell fordítania a változót, tehát akár 8, akár 16, akár 32, akár 64 bites az mcu, minden esetben ugyanakkora tárhelyet fog fenntartani neki (pointerek miatt fontos).
0xE8E8F0F0E1LL Ez egy 64 biten ábrázolt hexadecimális szám, a végén a két LL jelzi, hogy "erőszakoltan" long-long, vagyis dupla unsigned long változóként kell fordítania, függetlenül attól, hogy nem annak néz ki. Decimálisan 1000340517089, binárisan 1110100011101000111100001111000011100001 az értéke. Hogy ez hogyan áll össze, azt viszont már az nrf működtető könyvtárában kell keresni.
De.
Ezek alapvetően csak változók (pontosabban változóként értelmezett konstansok). Az, hogy ez hogyan befolyásolja a forráskód működését, és pláne a forráskódból hívott függvények (/könyvtárak) működését, ahhoz ismerni kellene ezeknek is a beltartalmát. Mégpedig elég alaposan.
Én valószínűnek tartom, hogy a két kód nem ugyanarra az nrf könyvtárra épül.
Azóta egy fórumon megtaláltam, hogy a pipe valójában nem csatornát, üzemmódot vagy frekvenciát determinál, hanem egy jelszó (kulcs), ami az adót és a vevőőt hangolja össze. Ha ezek nem azonosak a vevőben és az adóban, akkor nem lesz átvitel. Több adó esetén a legkisebb helyiértékű (utolsó) értéknek kell változnia, hogy egyértelműen azonosítható legyen a vevő számára, hogy ki az adó. Szóval én inkább azt javasolnám, hogy az nrf működtető könyvtárának dokumentációját kezdd el bújni, abból minden kiderül. Ha nincs neki, az gáz, de a git és a stack segíthet.
Szükségem lenne egy kis mondatelemzésre , jó lenne ha egyszerűen de alaposan elmagyarázná valaki ezt a pár sort. nRF24 rádiót és arduino UNO egységet használok .A garázsból a szobába küldök hőmérséklet adatot.
Már két éve működik , csak a címzést nem látom át .
Ezt a címzést használom :
const byte address[6] = "00001";
const = állandó
byte = típusa
address = cím
[6] = 6 elemű tömb
"00001" = a szobai vevő a bázis ,azaz "00000" , ez a központ
"00001" = garázsban a vevő
még lesz egy víztartály ami "00002" címet kap.
Ez idáig világos, csak a csomópontokat térképezi , de lehet állítani a frekvenciát is
2400 - 2525 MHz.-ig állítható 125 csatorna 1 MHz lépésekben.
Állítólag jobb az alsó és felső széleket használni a sok wifi miatt, nekem kb 10 métert tud áthidalni , ami éppen csak elég.
Ahonnan a programot koppintottam ott ezt a címet használta , ezzel is működik de én az előzőt használom :
const uint64_t pipe = 0xE8E8F0F0E1LL ; Erre a sorra kellene koncentrálni.
uint = u betüt nem tudom mi,
int = integer
64_t = erre mondjatok valamit
pipe = rádiócsatorna
0xE8E8F0F0E1LL = először azt hittem 16-os számrendszerben a freki, de mit keres ott az "x"
ráadásul LL az sehogy nem illik bele.
Ha tudtok írni egy sort :mondjuk 2420 MHz ra és 2500 MHz .-ra akkor átlátnám a dolgot.
570 ohm plusz "bármilyen" led. A lényeget látod majd úgyis.
Keress rá az "Arduino Basic Connections" könyvre. Bár már nem árulja a készítő, de egészen kafa alapkapcsolások vannak benne érdemi hiba nélkül. Az mondjuk más kérdés, hogy pár alkatrész de facto nem létezik már sehol, de ez sokszor van így sajnos).
Úgy tűnik, hogy megmentettem az Arduino klónomat a kétszeres reset-módszerrel. A kínainak hittem és Leonardo lett, nem pedig Pro Micro.
Most tudok feltölteni rá (pl blink)kódrészletet, bár nem látszik. Holnap kipróbálom egy sorba kötött led+ellenállás kombóval, hogy működik-e valamelyik lábon vezérelve. Majd beszámolok róla!
Köszi a javaslatot, megpróbálom ma éjjel még egyszer ezt a reset-es módszert, aztán ha nem megy, akkor mindenképp berendelek egy általánosabb modellt, mondjuk egy UNO-t.
Egy midi kontrollereket készítő jutyubertől láttam, hogy ilyen processzorral szerelt kártyát használ, pont az általad említett USB-eszközként funkcionálás miatt.
Egy alap midi-kontroller készült volna belőle.
A kínai írta a kártyáról egyébként, hogy Leonardo clone.
Köszi az eddigieket, beszámolok majd a tapasztalataimról!
Egyrészt, ez nem egy Leonardo, bár nagy valószínűséggel a Leonardora vagy a Micro-ra fordított kód fog rajta normálisan menni, de ez sem 100 százalélk, mert mindkét eszköz használ egy illesztőt az USB-re.
Én egyébként másfelé mennék, mert a dupla resetes móka egyáltalán nem biztos, hogy éleszteni fogja. Kerítenék máshonnan egy Aurduino kártyát, arra feltenném az Arduino-as-ISP kódot, bekötném külső programozóként ISP-re, és megpróbálnám feltenni a gyári bootloadert újra. Egyáltalán nem biztos, hogy sikerülni fog, de jóval nagyobb esélye van, mint így.
Engedj meg pár kérdést, illetve javaslatot.
Egyrészt, mi vitt arra, hogy az egyik legkevésbé felhasználóbarát modult válaszd? A 32U4 egyetlen érdemi előnye a többi (klasszikus) MCU-hoz képest az, hogy tud USB eszközként működni (pl. billentyűzetként, egérként). Cserébe sokkal háklisabb minden másra.
Másrészt. Ha megnézed a kapcsolási rajzát a kártyának, akkor elég gyorsan kiderül, hogy nincs rajta D13 (user) led. Van két led, amelyek az RX/TX LED néven futnak, de ezek funkcionalitása valószínűleg a bootloaderbe van kódolva (nagy valószínűséggel vagy az UART, vagy valószerűtlenebb forgatókönyv esetén az USB adatforgalmat hivatott vizualizálni. A Blink tehát soha nem működik rendesen (illetve dehogynem, csak mivel nincs mit villogtatnia, nem lesz látható eredménye. És még csalni sem tudsz, hogy a D13 lábra ráteszel egy ledet és egy előtétellenállást, mert nincs kivezetve a 13-as láb a tüskesorra.
Harmadrészt. Az ilyen és hasonló lélekromboló élmények helyett érdemesebb előre kérdezned, aztán ha más nem, mazsolázni a tanácsok között. Itt szerencsére ritka a kiemelkedő sületlenség, amit a face hasonló tematikus közösségéről nem lehet elmondani sajnos.
Hasonlót csináltam vele, ha a két forrcsúcsot(GND+RST) összeérintem 2x, tényleg csak pár másodpercem van feltölteni a kódot és ez ennyi idő alatt eddig nem is sikerült, de az általad küldött leírásban a végén szerepel, hogy a compiling után kell neki még a kétszeres reset.
Meló után megpróbálom, én is nagyon kíváncsi vagyok!
Köszi a gyors választ! Bocsánat, hogy én meg lassan reagálok!
Azt hiszem, hogy sikerült kinyírnom az Arduinomat. Elkezdtem angol nyelvű oldalakon olvasgatni, ahol azt írták, hogy ha nem jól adom meg azt, hogy milyen típusú az alaplap, és úgy töltök fel rá kódot, akkor szokott előfordulni az, hogy nem fut le a kód, hasonlóan, mint az enyémen.
Megpróbáltam SparkFun Pro Micro-ként, fel is ismerte így. Feltöltöttem az alap blink kódot, aztán kiírta, hogy ismeretlen usb eszköz. Azóta nem látja az Arduino IDE sem. Úgyhogy nem tudok próbálni már semmit rajta.
Mindenekelőtt kellene egy fotó erről a csodáról, lehetőleg úgy, hogy nagyjából lehessen látni rajta az IC-t, és azt, hogy a nyák vezetőszálai merre kanyarognak. Nyilván nem lesz tökéletes, de irányba álláshoz nem rossz.
Másrészt kellene a konkrét forráskód, amit feltöltöttél (codeshare.io vagy a pastebin.com tök jó a célra, ne ide másold be, mert csak katyvasz lesz belőle).
A lehetséges okok sokfélék lehetnek:
Hiba van a kódban.
Hibás a bootloader a kártyán. Ennek lehet az a következménye, hogy ha nem tud rendes USB handshake-et csinálni, akkor eldobja a rendes futást és vár pl. kód feltöltésre. Ehhez hasonlót tudnak produkálni az STM Nucleo kártyák, amikor a programozó rész direkt USB tápolást kap, de nem gépről, hanem egy szarabb kínai zsebakkuból.
Maga a kártya vagy rajta az MCU hibás.
A fentieken túl próbáld meg rátölteni a "nyers" alap Blink-et, illetve a mintaprogramok közül a BlinkWithoutDelay-t. Nézd meg, hogy azok lefutnak-e rendesen.
A Serial.print(1)-gyel nem sokat értél el, mert csak azt írja ki, amikor a kód futása eléri ezt, de hogy hogyan jut oda, azt már nem. Érdemesebb egy számlálót betenni, és annak a változó értékét kiíratni, és nem print-tel, hanem println-nel, hogy meglegyen a sortörés is.
A print függvény meghívása és a soros kommunikáció időbe telik, ezért a szoftver időbeli viselkedése más. Próbáltál pl. hosszabb delayt tenni a ciklusba?
Egy kis segítséget szeretnék kérni, ha szabad! Kezdő vagyok, kevés szerencsével :-)
Vásároltam Kínából egy Arduino Leonardo klónt, a csipen ATMEL Mega32U4 van írva.
Mondjuk nem hasonlít kinézetre a Leonardohoz, de a leírásban ez volt. Az alaplapra "Pro Micro" van nyomtatva.
Az Arduino IDE szépen felismeri. Feltöltöttem rá a legelső kódot, az onboard led villogtató kódot és sajnos nem működik.
Olyan, mintha a LOOP csak egyetlenegyszer futna le és a led csak egyet villan.
Ha teszek a loopba egy Serial.print(1); -sort, akkor a soros kimeneten kiírja, amit kiírattam vele minden újrakezdett loopnál és fel is villanik a led, ahogy kell(és villog szépen).
De ha nincs a Serial.print sor a kódban ÉS nincs megnyitva a soros kimenet, akkor nem villog a led.
Gondolom, ha egy telefon töltőfejre dugom rá az Arduinomat, akkor is le kéne futnia a kódnak nem? Mert úgy sem villog.
Segítsetek kérlek, hogy tudnám működésre bírni! Terveim vannak vele, hogy mikre fogom a jövőben használni, de így sajnos reménytelennek tűnik.
az A/B dekódolást végző arduino interruptokkal kezeli a jeleket és lépteti fel/le a 0-4000 tartományban a számlálót. Vagyis tulajdonképpen bekapcsolás illetve reset (nyomógomb) után egy relatív szöghelyzetet ad.
A második arduino ezt beolvassa a 12 biten, majd készít belőle 360 fokos rendszerben egy 0,1 fok felbontású kijelzést, illetve neki lehet saját ABSZOLÚT/RELATÍV funkciója, mint egy tolómérőnek, meg kiteszi a kijelzőre.
Az egész projekt egy, a VW-csoportnál alkalmazott vezérműtengelyállítási készülék kiváltására kell. Annyit kell tudnia, hogy (álló motornál) az adott pozícióból adott szögértékre lehessen elforgatni a vezérműtengelyt.
És 12 direkt vonalon bekötöd a másikba, vagy ott már csinálsz valami előfeldolgozást (pl. MCP23x17?)?
Ez annyira nem elegáns, hogy egy dekáddal ugyanezt meg tudod csinálni. Mondjuk konkrétan nem tudom, hogy melyik ideális hozzá, de rövid kereséssel ez is megoldható.
Mondjuk a teljes specifikáció az első kérdésben általában rettenetesen hasznos. Sok felesleges órát spórol a mérnöki óradíjból. :-)
Egy információ lemaradt, bocs. Ezt a jeladót konkrétan szögmérésre akarom használni, 4000/kör az tulajdonképpen 10%-kal több, mint tized fok felbontás.
Nem kell gyorsabban forognia, mint 1-2 fordulat / másodperc.
A kijelző frissítése bővel elég, ha 2/ sec.
Viszont egy facebook fórumon valaki megadta közben a pofonegyszerű megoldást:
Az első arduinoval ugye eljutok a 0-4000 tartományban való ábrázoláshoz (tehát túlforduláskor újrakezdi 0 foktól).
A kapott érték ÉPPEN BELEFÉR 12 ábrázolásba - vagyis ha ezt a számot kiteszem 12 digitális lábra, akkor azok ott konkrétan pufferként tárolják, a másik ardu meg akkor olvassa be, amikor akarja. (ok, hogy ne éppen a másik frissítése közben olvasson be marhaságot, ő mondjuk végezhet egy vizsgálati ciklust, olyasmit, mint egy prellegés kiküszöbölésére, néhány mikroszekundum eltéréssel összehasonlít két mintát, ha egyformák, akkor fogadja el, ilyesmit.
Ennyi szabad láb pont van, vagyis lehet, hogy ez nem "elegáns" módszer, de az adott feladatra valószínűleg a legjobb :)
A jövőben pedig majd építek szögmérőt AS5047P chipből, mert az feldolgozott digitális adatot is tud szolgáltatni.
1 Mbps teoretikusan elmegy, de bírkóznod kell eléggé az erőforrásokkal. 115k, mint "szabvány" sávszélesség gond nélkül, és még marad is mellette órajel.
De...
Azon gondolkodtam, hogy -- a kapott információk alapján -- miért szempont ilyen istentelenül nagy átviteli sebesség?
Ha a diszkrét értéket adod át (mármint azt, ahol éppen a számláló tart), és ezt akarod kiírni egy 7 szegmensesre (felteszem, hogy valamilyen shift registerrel), akkor felmerül, hogy mégis, mennyi a shift register maximális frekvenciája, amin még épp meg tud jeleníteni, illetve a megjelenített értéket mégis hogyan akarod leolvasni? Az SN74HC595 25 MHz-es órajelig vidáman elketyeg, bár ezt egy Arduino (pontosabban egy Arduino keretrendszerben programozott ATMEL 329P) már nem tudja kiszolgálni, pláne nem több számjegy kijelzése esetén.
Nekem korábbi tesztekből az rémlik, hogyha nem akarod rommá szétfolyatni a kijelzést (össze-vissza villogó szegmensekkel), akkor valahol 10 Hz környékén érdemes megállni, a fölött már az utolsó számjegy (ha változik), értelmezhetetlen lesz. 50 Hz már olvashatatlan.
Arduino Nano / Nano közötti kommunikációra kérnék javaslatot.
A feledat: van egy 1000 impulzus/ ford, vagyis emiatt valójában 4000 jel/fordulat felbontású forgóenkóderem (Hall-jeladós verzió), A/B kimenetekkel. Ezt egy arduino Nanoban megszakításokkal kezelem, az eredmény egy egész szám, aminek nő vagy csökken az értéke, a forgásirány szerint. Mivel már 1 ford/sec sebességnél is csak 250 usec idő van két megszakítás között, az eredméynt egy második Nanoban dolgoznám föl, illetve küldeném egy 8x7 szegmenses kijelzőre.
Mindkét feladat működik külön-külön.
Meg kellene oldanom a két eszköz közötti adatcserét. Tulajdonképpen már ez is működik soros adatátvitellel, de csak 56kbaud sebességgel, a portD.3 és PortD.4 lábakon.
NEM az arduino IDE-ben programozom, tehát nem tudok onnan libraryt használni.
A soros ártvitelre mindenütt a Tx/Rx lábakat ajánlották - viszont ezek ugye be vannak kötve a CH340 IC-re,nem értem hogyan működne párhuzamosan a két dolog.
Volna valakinek jobb javaslata? Esetleg SPI vagy i2C busz?
