Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
while( !done ){
len = radio.getDynamicPayloadSize(); done = radio.read(&RecvPayload,len); delay(5); } ezzel van gondja, ha csak simán radio.read(.... ); van írva akkor jó, de visszaírom hogy done = radio.read(......); akkor megint kiírja a hibát
A done az nem tiltott kifejezés? Vannak rendszer által használt kifejezések, amiket nem lehet változó azonosítóként használni. Ahelyett próbálj meg más változónevet adni esetleg.
Módosítottam de sajnos így sem jó. Szerintem ha tiltott lenne azt már a deklarációnál kidobta volna.
Az igaz.
A 91. sorban a radio.read(&RecvPayload,len) függvény mit ad vissza? Boolean értéket, vagy valami mást? Azért kérdezem, mert a done változód Boolean -ra van definiálva a 87. sorban. A hozzászólás módosítva: Márc 5, 2015
Booleant ad vissza, meg is néztem ez volt az első gyanúm. Olvasgattam googlen másnak is volt ez a problémája , de nem láttam rá megoldást csak h átirták teljesen az egész részt.
A hozzászólás módosítva: Márc 5, 2015
Valami furcsaság lesz nálad. Beszereztem a kívánt könyvtárat és simán lefordult a fenti kódod.
Annyit kellett csak módosítanom, hogy a printf.h-t mivel helyi fájl "" közé tettem ( #include "printf.h"). A <> csak a távoli könyvtárakra vonatkozik.
Mellékeltem az ino file-t, ez is lefordul nálad? a printf-et módosítottam ahogy írtad, de nincs hatással a dologra.
Itt egy srácnak ugyanez a probléma: http://forum.arduino.cc/index.php?topic=270504.0
Ettől az arduino sdk-tól mindig idegenkedtem, de most sem sikerült megszeretnem
Na hát az a helyzet, hogy több RF24.cpp van itt és egyikben boolenannal tér vissza de a másikban voiddal. De ami booleannal tér vissza az a RaspberryPi-hez való. Így viszont érdekes neked hogy fordult le mikor voidos a read függvény?
Ja, hogy te összevissza kevered a könyvtárakat...
Ez a kódja a függvénynek...
Amelyikben ez van ott nekem az elején van egy WiringPi nevű include is, azt kitörölted?
Idézet: „nrf_tx.ino: In function 'void nRF_receive()': nrf_tx.ino:91:14: error: void value not ignored as it ought to be Error compiling.” Ha a könyvtárban "void"-nak van deklarálva a függvény, akkor nincs visszatérési értéke, tehát nem szerepelhet értékadásban, kifejezésben!
Köszi a választ! Tehát Akkor nyugodtan megadhatom binárisan is? De szereintem hibát fog írni, mert nem annyi lesz, amennyi a tömb értéke.
Ez világos, csak kiderült hogy két RF24.cpp van amik nem egyformák.
Semmi ilyesmi nincs az elején. Nem töröltem ki, annyira nem érdekel
.Szedj le egy friss verziót a netről (Link) és töröld ki a meglévő szemetet a library-ból. Valószínűleg összevissza kevertél mindent és emiatt nem működik az egész.
Ezt, most nem igazán értem... A tömb tartalmától függ (legalábbis feltételezem, nem álltam neki az egész kódot átolvasni), hogy mely LED-eket gyújtja be a uC. Mi az, hogy nem annyi lesz mint a tömb értéke? (eleve, nincs is olyan mint a tömb értéke, ha matematikailag fogalmazzuk is meg, akkor is mátrixról beszélünk és ott is legfeljebb a determinánsának van értéke, tehát legfeljebb a tömb elemeinek az értékeiről beszélhetünk)
Ha tehát binárisan adod meg a hexadecimális helyett a tömb elemeit, az teljesen mindegy a fordító számra és nem fog emiatt hibát kiírni (azt a kissé lényegtelen részletet most hagyjuk, hogy a 0b nem része a c++ szabványnak, hiszen ennek ellenére az Arduino azért megeszi).
Köszi, értem és működik is, de az miért van, hogy fordítva működik, tehát a 0 a bekapcsolva és az 1 a kikapcsolva?
Gyorsan átfutottam a programot, mindenféle kapcsolási rajz ismerete nélkül. A működését illetően, amire tippelek. Ugye van két koordináta. X és Y. Az egyik koordináta irányába 4 kimenettel kiválasztod az aktuális munkasort [G-re aktiválódik a kiválasztás]. A másik irányba soros => párhuzamos átalakítással (két 8 bites chip?) feltöltöd a kiválasztott sor tartalmát (erre lesz való a CLK [órajel] és a DI [adat] kimenet). Mikor elment az adat a LAT [latch] frissíti a a chipek tartalmát az új adatokkal.
Na mármost a kérdésedre a válasz a LED panelek kialakításában keresendő. Ha közös katódos, akkor a LED-ek árama egy közös pont felé halad (ezt valószínűleg a panelen látható kis tranzisztorokon keresztül vezetik át [soronként egy tranzisztor, egyben a tranzisztor nyitásával választják ki a sort], normál IO-nak sok lenne a közös áram) a föld felé. Az áram pedig a kis 8 bites soros/párhuzamos átalakító chipekből ered (current source, áram forrás) (ilyenkor az 1-es adat világít, a 0 pedig nem). Természetesen van még a LED-ekhez áramkorlátozó soros ellenállás is, de ez a működési elv lényege szempontjából érdektelen. Ha közös anódos, akkor a közös tranzisztor felől halad az áram a soros/párhuzamos chip-ek felé. Ilyenkor csak akkor haladhat ha a chip lehúzta az adott kimenetét a földhöz (current sink, áram nyelő). Azaz ha 0 adat van akkor világít a LED. Ha 1 akkor pedig ugye zárva marad a LED és nem világít. Remélem érthető voltam... A hozzászólás módosítva: Márc 5, 2015
Köszi, érthető voltál, viszont még egy problémával szembesültem, ha a loop-ba teszek delay-t, akkor nem működik. Erre mi a megoldás? Előre is köszi!
Sziasztok!
ATMEGA128A chiphez létezik bootloader? Amit a program kezelni is tud? Vagy kompatibilis vele az Arduino könyvtárában lévők közül valamelyik? Azért kérdem, mert kb: 50kb-os programhoz ezt választanám, mert ezt még be tudom forrasztani. (TQFP64)
Nincsen, de atmega1284 viszont van, az dip40 tokos.
Akkor ezek szerint mégsem voltam annyira érthető.
Ha szinkron módban "írod" ki az adatokat a kijelzőkre, akkor nem használhatsz delay-t. Olyan rövid időre gyuladnak ki ugyanis a LED-ek, hogy nem fogod látni ha csak egyszer-egyszer gyújtod fel őket. A megoldás az, hogy asszinkron módon működteted a LED kijelzőt a programod többi részéhez képest. Magyarán úgy kell módosítanod a LED kijelző vezérlését, hogy megszakításból is helyesen működjön. Ilyenkor a uC megadott időközönként felfüggeszti a loop-ban futó kódod működését és elvégzi a kijelző frissítését számodra "láthatatlanul". Egyébként mindig is ez a helyes irány, a "költségesebb" feladatot a loopba helyezni, a kevésbé költségeset pedig a megszakításba. Például TFT kijelző meghajtásánál a kijelző frissítése a költségesebb, a méréseket javasolt megszakításból végezni. Egy ilyen LED panelnél - ahol a frissítési sűrűség miatt amúgy is javasolt megszakítást használni - pedig a költségesebb rész általában nem a panel kezelése.
Kipróbáltam, ez a megoldás működik Arduino 1.0.5-nél. Az újabbaknál nem lehet egy az egyben kicserélni a boards.txt fájt, azoknál bele kell ápolni az ATMEGA128-as processzor adatait. De jó lesz, köszi.
@GPeti1977 Azért nem jó a DIP40 tok, mert hatalmas.
De azt még simán be tudom forrasztani, a TQFP100-at már nem.
|
Bejelentkezés
Hirdetés |
