Fórum témák
- • Pneumatika végállások reed kapcsolóval
- • Internetes rádióvevő
- • Nagyfeszültségű tápegység
- • Alternativ HE találkozó(k)
- • Elfogadnám, ha ingyen elvihető
- • 3D nyomtatás
- • Felajánlás, azaz ingyen elvihető
- • Akkumulátor töltő
- • Elektronikai témájú könyvek újságok
- • Rádióamatőrök topikja
- • LED szalag
- • Klíma szervizelés, javítás
- • TDA7294 végerősítő
- • Háromfázisú aggregátor
- • Szintetizátor javítás
- • Kondenzátor
- • Dobozolási technikák, műszerdobozok
- • Boombox javítás
- • Sütő javítás
- • Erősítő mindig és mindig
- • Arduino
- • Mosógép vezérlők és általános problémáik
- • Számítógép hiba, de mi a probléma?
- • Hangszórójavítás (otthon)
- • Laptop javítás, tuning
- • Elektromos távirányítós kapunyitó
- • Autós erősítős kérdések, problémák
- • Mikrohullámú sütő javítás, magnetron csere, stb.
- • Villanymotor
- • Vegyes barkácsfogások
- • Digitális óra
- • Hűtőgép probléma
- • TV hiba, mi a megoldás?
- • Szünetmentes táp javítása, élesztése
- • Erősítő építése elejétől a végéig
- • Műhelyünk felszerelése, szerszámai
- • Kombikazán működési hiba
- • Függvénygenerátor építése
- • SMD, mi a típusa?
- • Hibrid erősítő
- • Suzuki Swift elektronika
- • Videomagnó problémák
- • Általános antennás kérdések, válaszok
- • Érdekességek
- • STK erősítők javítások
- • DC-DC konverter max. kapacitív terhelése
- • Audiofil, High End Audio
- • Központi fűtés (vezérlés)
- • IMI villanymotor
- • Borhűtő vezérlő panel
- • Androidos okos telefonok
- • Klíma beszerelése, fűtés-hűtés házilag
- • Súlymérés
- • Varrógép elektronika
- • Analóg oszcilloszkóp javítása
» Több friss téma
|
A klónok CH340 Soros-USB illesztőjének drivere ( Letöltés)
Másik ötlet.
Az általad használt if sorozat vizsgálat esetén mindig megtörténik az összes vizsgálat, feleslegesen.
if (noteByte == oldnoteByte1) { gorbetime[0] = maxrelease; } if (noteByte == oldnoteByte2) { gorbetime[1] = maxrelease; } if (noteByte == oldnoteByte3) { gorbetime[2] = maxrelease; } if (noteByte == oldnoteByte4) { gorbetime[3] = maxrelease; } if (noteByte == oldnoteByte5) { gorbetime[4] = maxrelease; } if (noteByte == oldnoteByte6) { gorbetime[5] = maxrelease; } Ha else if kombinációt használsz akkor az első találat után nem vizsgálja a többi feltételt. if (noteByte == oldnoteByte1) { gorbetime[0] = maxrelease; } else if (noteByte == oldnoteByte2) { gorbetime[1] = maxrelease; } else if (noteByte == oldnoteByte3) { gorbetime[2] = maxrelease; } else if (noteByte == oldnoteByte4) { gorbetime[3] = maxrelease; } else if (noteByte == oldnoteByte5) { gorbetime[4] = maxrelease; } else (noteByte == oldnoteByte6) { gorbetime[5] = maxrelease; }
Bár lehet, hogy pont az egyforma futás idő miatt választottad az első verziót?
Igen, mert szerintem nem segít a dolgon, ha létezik olyan állapot, melynek hosszabb idejű fennállása bizonytalanná teszi a dolgot. Tehát ha mindig az 5-ös hang billentyűjét engedném el akkor nagyobb a terhelés, de akkor mindig pont az 5-ös hangot kéne kiadni, ami lehet lehetetlen... Tehát ez az algoritmus egyszerűsíthető szerintem, de nem így lenne célszerű, nem is véletlen van mögötte a switch-case kommentben, bár az úgy hülyeség... A hozzászólás módosítva: Máj 13, 2020
Ha már sebességre optimalizálunk!
Próbáld ki ezt is:
byte gomb1 = 2; byte gomb2 = 3; byte gomb3 = 4; byte gomb4 = 5; byte gomb5 = 6; byte gomb6 = 7; byte gomb7 = 8; byte gomb8 = 9; void setup() { pinMode(gomb1, INPUT); pinMode(gomb2, INPUT); pinMode(gomb3, INPUT); pinMode(gomb4, INPUT); pinMode(gomb5, INPUT); pinMode(gomb6, INPUT); pinMode(gomb7, INPUT); pinMode(gomb8, INPUT); // controller-ben digitalRead(gomb_);gyorsítása: // Be olvassa a GPIO regisztert és kimaszkolja a megfelelő bitet uint32_t gomb1val = PIOB->PIO_PDSR & 1u << 25 ;// D2 = B.25 uint32_t PC = PIOC->PIO_PDSR ; uint32_t gomb2val = PC & 1u << 28 ;// D3 = C.28 uint32_t gomb3val = PC & 1u << 26 ;// D4 = C.26 uint32_t gomb4val = PC & 1u << 25 ;// D5 = C.25 uint32_t gomb5val = PC & 1u << 24 ;// D6 = C.24 uint32_t gomb6val = PC & 1u << 23 ;// D7 = C.23 uint32_t gomb7val = PC & 1u << 22 ;// D8 = C.22 uint32_t gomb8val = PC & 1u << 21 ;// D9 = C.21 // A kapott értéket eltoljuk jobb szélre bit.0-ba gomb1val >>= 25; gomb2val >>= 28; gomb3val >>= 26; gomb4val >>= 25; gomb5val >>= 24; gomb6val >>= 23; gomb7val >>= 22; gomb8val >>= 21; } void loop() { // put your main code here, to run repeatedly: }
A hozzászólás módosítva: Máj 14, 2020
Ha a fenti kód működik? Akkor jó regisztereket olvastam be.
És tovább gyorsítható a műveletek összevonásával:
byte gomb1 = 2; byte gomb2 = 3; byte gomb3 = 4; byte gomb4 = 5; byte gomb5 = 6; byte gomb6 = 7; byte gomb7 = 8; byte gomb8 = 9; void setup() { pinMode(gomb1, INPUT); pinMode(gomb2, INPUT); pinMode(gomb3, INPUT); pinMode(gomb4, INPUT); pinMode(gomb5, INPUT); pinMode(gomb6, INPUT); pinMode(gomb7, INPUT); pinMode(gomb8, INPUT); // controller-ben digitalRead(gomb1);gyorsítása: // Be olvassa a GPIO regisztert és kimaskolja a megfelelő bitet uint8_t gomb1val = ((uint32_t)PIOB->PIO_PDSR & 1u << 25)>> 25 ;// D2 = B.25 uint32_t PioC = PIOC->PIO_PDSR ; uint8_t gomb2val = (PioC & 1u << 28)>> 28 ;// D3 = C.28 uint8_t gomb3val = (PioC & 1u << 26)>> 26 ;// D4 = C.26 uint8_t gomb4val = (PioC & 1u << 25)>> 25 ;// D5 = C.25 uint8_t gomb5val = (PioC & 1u << 24)>> 24 ;// D6 = C.24 uint8_t gomb6val = (PioC & 1u << 23)>> 23 ;// D7 = C.23 uint8_t gomb7val = (PioC & 1u << 22)>> 22 ;// D8 = C.22 uint8_t gomb8val = (PioC & 1u << 21)>> 21 ;// D9 = C.21 // A kapott értéket eltoljuk jobb szélre bit.0-ba } void loop() { // put your main code here, to run repeatedly: }
És még spórolunk a memória foglalással is.
Köszönöm működik, bár csak 5 gombot tudtam kipróbálni, mert elég régiek, de annyi is működött 
A setup függvényt szerintem inkább kódméretre érdemes optimalizálni, hiszen csak induláskor egyszer fut le (ritkán van jelentősége ott a futási időnek). Normál gcc-ben lehet a program egyes részeinek az optimalizációját a globális beállítástól eltérő módon állítgatni (nem tudom, ez az arduinoban levő fordítóval is működik-e, de tudtommal az is gcc-t használ).
#pragma GCC push_options #pragma GCC optimize("Os") // ide mehet a kódméretre optimalizált függvény #pragma GCC pop_options ... #pragma GCC push_options #pragma GCC optimize("O3") // ide mehet a max módon optimalizált függvény #pragma GCC pop_options
vannak a lehetséges optimalizálási szint beállításai.
Működni látszik. Változik a lefordított programméretem húsz és huszonnyolc százalék között opciótól függően. Köszönöm kísérletezgetek vele! A hozzászólás módosítva: Máj 14, 2020
Az egész program 9 fájlból áll, a méreteik miatt nem idéztem ide az egészet.
Természetesen a gombok kezelése nem a setupban van. Megjegyzésben oda írtam melyik részre gondoltam. Idézet:
„// controller.ino-ben digitalRead(gomb1);gyorsítása:”
A példa azért így van megcsinálva, hogy le tudjam ellenőrizni, legalább próba fordítással.
Akinek szólt az megértette. A hozzászólás módosítva: Máj 14, 2020
Lehet kísérletezni a fordító optimalizálásával.
De sajnos az olyan részeket kapásból kifogja dobálni amiket a jó hangzás céljából raktál-be időzítésnek.
Ok!
Akkor kíváncsiságból lefuttatnád ezt a teszt programot:
#include <LiquidCrystal_I2C.h> LiquidCrystal_I2C lcd(0x27, 16, 2); byte gomb1 = 2; byte gomb2 = 3; byte gomb3 = 4; byte gomb4 = 5; byte gomb5 = 6; byte gomb6 = 7; byte gomb7 = 8; byte gomb8 = 9; unsigned long starttime, stoptime, eltelttime, eltelttime2 ; void setup() { pinMode(gomb1, INPUT); pinMode(gomb2, INPUT); pinMode(gomb3, INPUT); pinMode(gomb4, INPUT); pinMode(gomb5, INPUT); pinMode(gomb6, INPUT); pinMode(gomb7, INPUT); pinMode(gomb8, INPUT); lcd.init(); lcd.backlight(); starttime = micros(); int gomb1val_ = digitalRead(gomb1); int gomb2val_ = digitalRead(gomb2); int gomb3val_ = digitalRead(gomb3); int gomb4val_ = digitalRead(gomb4); int gomb5val_ = digitalRead(gomb6); int gomb6val_ = digitalRead(gomb5); int gomb7val_ = digitalRead(gomb7); int gomb8val_ = digitalRead(gomb8); stoptime = micros(); eltelttime = stoptime - starttime; lcd.setCursor(0, 0); lcd.print(eltelttime); lcd.print(" us."); // controller-ben digitalRead(gomb1);gyorsítása: // Be olvassa a GPIO regisztert és kimaskolja a megfelelő bitet starttime = micros(); uint8_t gomb1val = ((uint32_t)PIOB->PIO_PDSR & 1u << 25)>> 25 ;// D2 = B.25 uint32_t PioC = PIOC->PIO_PDSR ; uint8_t gomb2val = (PioC & 1u << 28)>> 28 ;// D3 = C.28 uint8_t gomb3val = (PioC & 1u << 26)>> 26 ;// D4 = C.26 uint8_t gomb4val = (PioC & 1u << 25)>> 25 ;// D5 = C.25 uint8_t gomb5val = (PioC & 1u << 24)>> 24 ;// D6 = C.24 uint8_t gomb6val = (PioC & 1u << 23)>> 23 ;// D7 = C.23 uint8_t gomb7val = (PioC & 1u << 22)>> 22 ;// D8 = C.22 uint8_t gomb8val = (PioC & 1u << 21)>> 21 ;// D9 = C.21 // A kapott értéket eltoljuk jobb szélre bit.0-ba stoptime = micros(); eltelttime2 = stoptime - starttime; lcd.setCursor(0, 1); lcd.print(eltelttime2); lcd.print(" us."); eltelttime2 = eltelttime - eltelttime2; lcd.setCursor(0, 2); lcd.print("elteres: "); lcd.print(eltelttime2); lcd.print(" us."); } void loop() { // put your main code here, to run repeatedly: }
Ki írja az LCD-re a két gomb kezelés futás idejét, és a különbséget.
Tíz illetve kettő mikroszekundumot mutat. Ez mindenképpen jelentős különbség.
Igen.
Mivel csak 2us-enként van 1 megszakítás, ennél kevesebb időt nem is tudunk mérni.
És nagy valószínűséggel ennek a 2us-nek is a nagy része a megszakítás lekezelése.
Most betettem a kész programba az időmérésedet, a vezérlők eljárásba. Itt tizennégy mikroszekundumot és három mikroszekundumot mértem, a kétfajta beolvasással. Viszont a GPO regiszter olvasása hiába gyorsabb, ha sok billentyűt nyomok le a Midi vezérlőn, akkor "beleaggol" a hangszer. Ha visszateszem a régit, akkor tökéletes... Tehát ezek szerint, valahogy másképpen használja a megszakítást, és az összeakad, vagy a MIDI-vel, vagy az audió, illetve LCD résszel...
Leginkább az LCD a gyanús, de ha működik a sima DigitalRead akkor nem bántom.
Tehát hiába gyorsabb a dolog, egyenlőre marad a régi. Viszont ezt az időmérést lehet beteszem egy rejtett menübe, és tesztelgetek vele máshol is...
Köszönöm a segítséget, ha Miskolcon jársz egyszer, a vendégem vagy! A hozzászólás módosítva: Máj 15, 2020
Kell neked az LCD biztosan?
Ha több gombot használsz, esetleg minden funkcióhoz egyet (nem tudom mennyi kellene), akkor az LCD felesleges lenne, nem venne el plusz időt.
Viszont találtam még tempót az LCD írásnál.
Rámértem a programban az eltelt időkre több clock frekvenciával, nyerek harminc milliszekundumot ha felteszem 1 MHz-re 800 kHz-ről! Csináltam diagramot, hátha hasznos még valakinek... A hozzászólás módosítva: Máj 15, 2020
Moderátor által szerkesztve
Körülbelül 120paraméter, többségük 1-127-ig állítható, nem nagyon úszom meg. De ha minden igaz kész a dolog, csinálok egy részletes videót róla, annak linkjével még zaklatlak majd titeket, hogy miről is van szó. Köszönöm a segítségeket! A hozzászólás módosítva: Máj 15, 2020
Ha ezt a library-t használod, akkor nézz bele a pulseEnable függvényébe. Ez minden íráskor várakozik kétszer 50usec-et. Nem lehetne ezt az i2c kijelzőt sima 6 vezetéken is működtethető verzióra cserélni? Akkor elég lenne 2msec sűrűséggel kb 1usec idő a folyamatos frissítéséhez.
Köszönöm! De Nem ellenszolgáltatásért segítettem! Inkább azért mert sokat lehetett tanulni tőled, hang technikai megoldások terén. Viszont nagyon kíváncsi leszek a végleges program változatra. Vajon menyit tudtál javítani rajta?
Erre már többen felhívtuk a figyelmet,hogy az I2C nagyon lassú!
De valamiért nagyon ragaszkodik hozzá?
Az én LiquidCrystal_I2C.cpp fájlomban nincsen benne ez a késleltetés.
I2C-vel hajtott kijelzőn a következő kód 3404 mikroszekundum alatt fut le. 32 MHz-es órajelen 2500 mikroszekundumig tudom lefaragni:
lcd.setCursor(0, 0); lcd.print("01234567"); lcd.setCursor(0, 1); lcd.print("01234567");
Ha valaki gyorsan lefuttatna egy tesztet egy másik rendszeren, az tényszerűen mutatná a sebességeket.
Addig-addig találtam itthon egy vasat, amin a "6 vezetékes" rendszerrel van a kijelző. 5048 mikroszekundum alatt futott le a fenti kódrészlet.
Tehát, szerintem gyorsabb az I2C, de a 8 bites vezérlés kipróbálása még vissza van.
Most tesztelek, tesztelek, tesztelek. Valamiért nagyon nem működnek a tömbök. Ha különálló programban összehasonlítom a sebességeket kb. 10 százalékot rávernek a különálló változókra, egy egymilliószoros értékadáson. A baj az, hogy amikor a programban, feltehetően megszakításos környezetben használom őket, habár a saját sebességük jobb, összességében még is problémát okoznak az időzítésekben, mindezt ciklus nélkül értsd, ami hihetetlen számomra. És mivel nem tudom az okát, ezért vizsgálódom még... A hozzászólás módosítva: Máj 16, 2020
Köszönöm a tesztet nagy segítség!
Nem az i2c az igazi probléma, hanem a tömbök. Amit nem értek...
Ha ezt az audio drivert használod, én megmérném mennyi időt tölt el az write függvényében levő várakozásban (56. sor, amíg a félbufferek DMA írása véget nem ér). Ha sokat, akkor azt az időt érdemes lenne a kevésbé időkritikus dolgok elvégzésére fordítani inkább.
Most látom üres utasításokat hajt végre, amíg nem végez, de hogy tudok ide betenni valamit? Írjam bele az audió osztályba mint függvény, amit itt meghívok az üres utasítás helyén. Az egy változó értékét kiszámolja amit majd a főprogramban kiolvasok az audió osztályon keresztül?
Vagy érdemesebb lenni az Audió függvényeket átemelni a főprogramba, és akkor azonos hierarchiába vagyunk?
Bocs ha hülyeség!
Én kiegészíteném egy foglaltsági függvénnyel:
int AudioClass::busy(void) { return (next == running); }
És csak akkor hívnám meg a write-ot, meg előtte a prepare-t, ha nem jelez foglaltat. Csak annyi a lényeg, hogy addig a hanggeneráló részt is szüneteltetni kell. A hozzászólás módosítva: Máj 16, 2020
Sziasztok,
Ezzel a szenzorral és egy LM386-os előerősítővel amit egy Arduino Nano analog bemenetére csatlakoztatok tudok-e annyira precízen mérni hogy megtudjam különböztetni 0.3 bár nyomást 0.4 bártól?
A választ előre is köszönöm. A hozzászólás módosítva: Máj 16, 2020
| (#) |
Bell hozzászólása |
Máj 16, 2020 |
 |
/ |
 |
|
Sziasztok!
A legfrissebb Arduino-val, a legfrissebb RF24-el, Pro-micro-kal, NRF24L01+ kínai klónokkal szeretném az "ack"-ot kijelezni az adó oldalon.
De az itt található (Bővebben: Link) leírás és a programok segítségével ez nem sikerül.
A radio.write(...) sosem ad igaz értéket.
Kondi van a modulokra forrasztva. Mit rontok el? A modullal lehet gond, vagy a programmal?
Az RX programja:
#include <SPI.h> const byte rAddress[] = "1Node" "2Node" "3Node" "4Node" "5Node"; byte ackData = 1; byte theMessage[32]; void loadAckData(byte pipe) { radio.writeAckPayload(pipe, &ackData, sizeof(ackData)); ackData++; } void setup(void) { Serial.begin(9600); radio.begin(); radio.setChannel(108); radio. setDataRate( RF24_2MBPS ); radio.enableAckPayload(); radio.enableDynamicPayloads(); for (byte i = 0; i < 5; i++) { radio.openReadingPipe(i + 1, &rAddress[i * 5]); } loadAckData(2); loadAckData(3); loadAckData(4); radio.startListening(); } void loop(void) { byte pipeNum = 0; if (radio.available(&pipeNum)) { if (pipeNum == 2 || pipeNum == 3 || pipeNum == 4) { loadAckData(pipeNum); } byte len = radio.getDynamicPayloadSize(); radio.read(theMessage, len); Serial.print(F("received [")); Serial.print(len); Serial.print(F("] ")); for (int x = 0; x < len; x++) { if (theMessage[x] < 16) { Serial.write('0'); } Serial.print(theMessage[x], HEX); } Serial.print(F(" via ")); Serial.println(pipeNum); } }
A TX programja:
#include <SPI.h> const byte wAddress[] = "1Node" "2Node" "3Node" "4Node" "5Node"; byte testData[32] = ">12345Test1234567890String12345"; byte ackMessg; void setup(void) { Serial.begin(9600); radio.begin(); radio. setDataRate( RF24_2MBPS ); radio.setChannel(108); radio.enableAckPayload(); } void loop() { static byte index = 0xFF; static unsigned long lastSend; unsigned long topLoop = millis(); if (topLoop - lastSend >= 1000) { lastSend = topLoop; if (++index > 4) { index = 0; } const byte* ptr = &wAddress[index * 5]; radio.openWritingPipe(ptr); if (radio.write(testData, sizeof(testData))) { if (radio.isAckPayloadAvailable() ) { radio.read(&ackMessg, sizeof(ackMessg)); Serial.print(F("Acknowledge for ")); for (byte i = 0; i < 5; i++) { Serial.write(*ptr++); } Serial.print(F(" received: ")); Serial.println(ackMessg); } } else { Serial.print(F("Send to ")); for (byte i = 0; i < 5; i++) { Serial.write(*ptr++); } Serial.println(F(" failed ")); } } } A hozzászólás módosítva: Máj 16, 2020
Sziasztok!
A Nano és az UNO között, mik az alapvető különbségek?
Eddig, csak UNO-m volt. A Nano-t is ugyanúgy, ugyanazon a felületen tudom programozni?
Ugyanúgy vannak analóg kimenetei is? A hozzászólás módosítva: Máj 16, 2020
Mindkettőn ugyanaz a mikrokontroler van, teljesen megegyezik a programozásuk. Analóg kimenet (DAC) egyiken sincs.
|
|
