Elvileg lehet vele, ha máshogy nem 8 bites módban. Mi a kijelző pontos típusa?

Egészen biztosan lehet. Szinte biztosan. Jó lenne tudni a típusát, vagy legalább a lábkiosztását. Gondolom egyik sem ismert, mert akkor mondtad volna. Miből származik? Van bármi infó róla?
Esetleg valami hasonló lehet mint ez..
Vissza kellene követni annyi vezetéket amennyit csak lehet.
Elképzelhető hogy nem intelligens chip-ek vannak rajta, hanem csak a driverek, és akkor sor/oszlop címzésre lesz szükség. Mint ez itt például.

Mérlegben volt. Annyi van a kijelzőn, ami látszik sajnos nem több.

Ha van aki kikisérletezi adok neki cserébe belőle.

Sziasztok!
A képen látható módon van fixre kötve egy HC-05 modul Mega alaplapra. Abban szeretném a megerősítéseteket, hogy ha a 16-17 pineket digitális I/O-ként konfigolom, nem soros portként, akkor a modulnak nem lehet baja, bármilyen is legyen a pinek állapota. Jól gondolom?

Ha az arduino 17. lábát kimenetre állítod és alacsony szintet teszel rá, miközben a HC-05 magas szintet szeretne kiadni a TX lábán, akkor a közte levő nyitóirányú diódán szkanderezni fognak egymással.

Az lemaradt, hogy amikor a 16-17 pinek I/O-nak vannak konfigolva, a bluetooth nem lesz használatban, de tápot akkor is kap. Ilyenkor is küldözhet némi adatot?

Ha adatot nem is küld, 3,3V jelen van a modul TX kivezetésén. A dióda és a mega RX lába közé beraktam egy 3,3k ellenállást. Így ha a 17. pin alacsony szintű kimenetként van beállítva, akkor is csak kisebb mint 1mA fog folyni a diódán, az meg nem okozhat gondot semminek. Szerintem.

Az uart kimeneteken általában logikai magas szint a nyugalmi állapot.

Sziasztok! Szeretném megköszönni az Arduinos-Due FM szintiben nyújtott segítségeteket! Szerintem létrejött egy nagyjából használható verzió, bár természetesen minden kódon van még mit javítani. A végén kialakult belőle egy 2x3 operátoros fm szintetizátor, mely különböző hangmintákból számol az fm moduláció elve alapján. Az operátorok hangolhatóak, lehetnek fix freki értékűek stb. Dinamikaérzékeny, a moduláció változhat a billentyűlenyomás erősségétől. A végén amin nagyon meglepődtem, hogy megszólalt egy ilyen reverb engine szerűség is, egy sima delay bufferbe átírásos, később visszaolvasásos algoritmussal. A többi szerintem le van írva a weboldalon, illetve még azt is javítgatom és foltozgatom. Videót hangmintákat cserélek jobbra majd.
Külön megköszöntem az oldalon kapu48, illetve Benjami-nak a segítséget, ha szeretnék, akkor a valós nevüket is kiírom. Persze úgy sem nézi meg a kutya sem
Mindenesetre azt veszem észre, hogy alakul egy különleges eszköz, ami lehet a végén még használható is lesz zenei célokra! A forráskód, egyéb leírás, segédszoftver letölthető az oldalon!
Arduino polifónikus fm szintetizátor

Szia!

Mi köszönjük a MIDI project közlését!
Szép munka, gratulálok a sikerhez!

Javasolnák kis hardveres gyorsítást, és akkor lehet, hogy nem is kellene külön uno az LCD-nek.
Bár kapcsolási rajzot ne közöltél, de a képekről látom, hogy nagyon sok pin fent maradt az unon.
Én ledobnám az LCD-ről az I2C bővítőt, és bekötném 8 bites párhuzamos adat kommunikációra.
Híd el, rengeteget dobna az LCD kezelés sebességén! Ezáltal az egész program futása gyorsabb lenne.
Nem fogná vissza a viszonylag lassú I2C.

Bővebben: Link
Csak az adatvonalat 1 portra tegyed, szépen sorban.

Vau, vau, megnéztem és tetszik . Esetleg GitHub -ra feltölteni a kódot? Többen láthatnák és lehet segítenének a fejlesztésben is.

Helló!

Kiváló projekt! Nekem nagyon tetszik!

Jelgenerátorral nem próbálkoztál? Azzal nem lehetett megoldani?

Csak annyiban egészíteném ki a hozzászólásodat, hogy alapban az I2C-s LCD kezelés lassabb a 4 bitesnél is. De ha az I2C vezérlő alapértelmezett, alapból lassú órajelét felpörgetjük, akkor sokkal gyorsabb tud lenni a 4 bitesnél. De azt nem tudom, hogy eléri-e a 8 bites módot.

Igen már többen javasolták, hogy hagyjam az i2c-t a fenébe. Egyenlőre nem a kijelzés volt a fővonal, hanem a hangszintetizálás része.

Ez lehet érdekelne, hogy hogyan...

A jelgenerátor az csak egy jelgenerátor

Annyi, hogy nem Uno, hanem Due. És igen nincs rajza, a DAC kimenete a kimenet, az rx2 a midi bemenet, illetve az lcd-nek az i2c alapértelmezett portja. Az rx2 meg kapott egy optocsatolót, annak a rajza ott van.

Egy észrevételem.

Ugyan azzal a névvel kétszer is létrehozol változókat?
A programod 402. sorától:
bool gorbetime0lehet = false;
bool gorbetime1lehet = false;
bool gorbetime2lehet = false;
bool gorbetime3lehet = false;
bool gorbetime4lehet = false;
bool gorbetime5lehet = false;

És ugyanez a setupban 445. sortól:
bool gorbetime0lehet = false;
bool gorbetime1lehet = false;
bool gorbetime2lehet = false;
bool gorbetime3lehet = false;
bool gorbetime4lehet = false;
bool gorbetime5lehet = false;
bool gorbetime6lehet = false;
bool gorbetime7lehet = false;

Ez így hibás szerintem! Vagy van valami oka ennek?

Ezt a változót jelenleg nem használom. Arra jött volna létre, hogy figyeljem a nulla-átmeneteket, és akkor léptessem a tva görbét, de ettől kiszámíthatatlan lett a működés, mert lehet bonyolult görbénél nincs is nulla átmenet. Ezért azt a részt már kivettem. Viszont meghagytam a változót, mert lehet még jól jön...
Köszi kidobálom a setup részben lévőket!

Valamikor régen csináltam egy sebessé tesztet a:

Futás ideje közt. Akkor a második variáció jobbnak bizonyult.
Ha ezek a részek érzékenyek a futás időre? Érdemes lenne kipróbálni.

A switch-case az elkülönülő feltételeknél gyorsabb. Legalábbis a tesztek szerint, ezzel a fordítóval.
Viszont ilyen ág, ahol egy feltétel teljesülése illetve else alapján kell megcsinálnom valamit biztosan gyorsabb az általad említett módon. Egyenlőre ez ügyben még nem nagyon rágtam át a programot.
Egyenlőre örültem annak, hogy működik a release,(lecsngés) sustem(hangtartás) rész, meg végre nem ragadnak be hangok. PL a MIDI részben pont egy ilyen else ág miatt szenvedtem pár napot...

Most nem kritizálom a munkádat, mert az így is nagyszerű!
Csak próbálok néhány hasznos tanácsot adni.

(Abban a reményben, hogyha valamiről beszélgetünk? Akkor általában akad valakinek valami hasznos ötlete vagy javaslata.)

Én a LiquidCrystal_I2C.h könyvtár mellett használom a Wire.h könyvtárat is. Így a Wire.setClock() függvény beállítja a kívánt frekvenciát. Az alapértelmezett érték Uno-Nano esetében 100000. Ha jól tudom, akkor Due esetében is, mert az I2C az I2C. Ennek az értéknek többszörösét is bírja a vas, de ha már 5-8-szoros sebességre gyorsítod, akkor a vezetékezésre is kényes és a felhúzó ellenállást is lehet, hogy módosítani kell kisebbre. Lehet kísérletezni, addig húzni, ameddig még stabil. 3400000 a plafon és Hz-ben adja meg az órajelet.

Még egy gyorsítási tipp:

A lassú -1-el szorzások helyet .
pich41 = (pichgorbe[gorbetime[0]] - 50) * picheglevel * -1;

gyorsabb lenne így:
pich41 = ~((pichgorbe[gorbetime[0]] - 50) * picheglevel -1);

Bővebben: Link

Pont azért dobtam ide, hogy lássák más szakemberek! Teljesen örülök minden kritikának, részemről az, hogy tegnap előtt megszólalt a reverb rész, már hatalmas élmény volt! Tehát köszönöm. Csak ugye sokszor járok úgy, hogy egyszerűbbnek meg logikusnak tűnne, mégsem működik a dolog.
Pl egy kérdés: miért nem tudom a delaybuffer tömböt nagyobbra venni, mint 3300?

Mert globálisan foglalsz le rengeteg memória területet, amiket sosem szabadítasz fel.
Ekkora területből kel gazdálkodnod: SRAM 64 + 32 Kbytes
Még csoda, hogy ennyit sikerült.

Meg kellene oldani, hogy amit éppen nem használsz, azt felszabadítsd.
Vagy csak a felhasználó függvényen belül foglalja helyet a tömbjeidnek.

Ez tök jó ötlet, megint tanultam, viszont van egy plusz zárójelezés, az nem lassít?

Eddig 10%-on álltam, de lehet elnéztem...

A zárójel csak a fordítónak szól, hogy milyen sorrendben hajtsa végre a műveleteket. Tehát nem lassít, akármennyit teszel bele.

Az a Flash 2 x 256 Kbytes-ből lefoglalt terület!
Nem keverendő a kettő össze!

És ha jól tudom? Itt az int az megegyezik a poci adatszélességével.
Vagyis 32 bites, míg az AVR-eknél csak 16 bites.