Azért villog, mert 19*8 ábrának definiáltál tömböt, de abból csak az 0-ást töltötted fel értékekkel!


Azt a lehetőséget választod amelyik neked jobb!

Sziasztok!
Adott egy Arduino Uno vezérlő és egy rotary encoder, nyomógombos verziós. Midi rendszerben szeretném használni, akár mint egy potméter akár kihasználva a 360 fok előnyeit. Találtam már sok féle megoldást, de sajnos egyik se működött a midit kezelő szoftveremmel.
Ezen az oldalon található példa áll talán a legközelebb amit szeretnék kihozni ebből az egészből. Viszont nem tudom feltölteni valamiért az Unomra, mert sehogy se találja a hozzárendelt fájl-t pedig sok féle képpen próbáltam már hozzárendelni.
Tudnátok nekem ebben segíteni, vagy hogy hogyan tudnám megvalósítani az elképzelésem?
Köszönöm!

Köszi. Most már világos.

Még az lenne a kérdésem, hogy a következő kódrészlet nem befolyásolja magának a karakternek e megjelenését illetve idejét?



Tudom, hogy ezek a címek a MAX7219 katalógusából kiolvashatóak.

Sziasztok!
Készítettem nyomtatott áramkört egy atmega328(rajta az arduino bootloader) köré, rajta minden szükséges alkatrész( kvarc, 22p-22p, ardu13-as láb kivezetve, ftdi usb-s programozónak lábak, stb). Kérdésem, hogy a feltöltésnél melyik opciót kell választanom? Mivel nem UNO, meg nem is NANO.
Köszönöm a választ.

Arduino nano szerintem jó választás.
Az FTDI USB-UART átalakító DTR lába és az Arduino RESET lába közé kötöttél kondenzátort (100nF)? Ha nem, akkor letöltéskor neked kell RESET-elni a mikrovezérlőt.

Ha UNO-t választom, akkor a program felöltődik, de nem indul el az atmega. Ha resetelem vagy elveszem a tápot, akkor az új programmal indul a proci, hiba nélkül.
Természetesen van kondi és felhúzó ellenállás is, tehát automata a programozás ebből a szempontból.

Sziasztok!
A péntek éjszakám pár demo összeollózáslába telt (nincs potimalizálva), hogy tudjak demozni egy kiállításon.
Sajna meg is mutatkozott a nano hátránya. A 128x64-es kijelző kezelésén kívül nem nagyon kell mit beletenni. a 2K sram nagyon kevés ha 1k a buffer (adafruit).
Egy másik Lib-et használva lehetett megoldani, hogy valamit működjön, de az meg így nagyon lassú.

Van valami köztes megoldás, mert így, hogy 75% a kijelző SRAM igénye így esélytelen.
Van ilyen hogy EEPROM bővítés. SRAM-ra nincs ilyen lehetőség amit pl. a bufferre fel lehetne használni?

A demo itt, hogy látszódjon mi a gond: DEMO1

Szerezz be egy encoder.h fájlt.

Az 1Kb úgy jön ki, hogy 1bit=1 pixel, mivel mono a kijelző, így (128x64)/8=1024byte. Pont ezért van benne ekkora, hogy ne legyen lassú. Összerakja a képet a bufferbe, majd tolja kifele a portokra egyszerre. A méretet fordításkor állítja be, ha nagyobb lenne a kijelző még nagyobb lenne a buffer. EEPROM-ban még lassabb lenne és pár óra alatt el is "kopna" az írástól.

Ha a NANO-t választom, akkor nem tölti fel a programot.

The code uses the encoder library, which is included with the Teensyduino install.

Itt a megoldás

Köszi.
Az EEPROM tudom erre nem jó.
Azért kérdeztem, hogy Más valami felejtő memória nincs -e erre...

SPI memóriák vannak, az Arduino.cc-n írnak is róla, csak nem tudom elég gyors lenne-e.

Köszi.
Utána járok, hogy van -e infó a kettő házasításáról...

STM32F103-höz tud valaki olyan drivert, ami alapján hajlani is a Win felismeri?

Az STM32F103-ban nincsen USB-t használó botloader!
Gyártás során kerül bele botloader, amihez ST-LINK néven árulnak programozót.

Van eredeti gyári jó drága, viszont van rajta JTAG-is ezért gyorsabb!
És van Ebay-es olcsón, de csak soros programozást tud .

Kicsit részletezné, mert nem teljesen tiszta.

Erről van szó: STM32F103-MS
Az USB akkor mire ró rajta?
A pro mini miatt egy ilyenem van: FTDI232

Itt azt írja a tulajdonságokban (ha erről van szó), tápfeszültség és kommunikáció, ha lehet hinni neki...

STM32F103-MS...

Én is így gondoltam.

Amúgy ESP8266-tot használt már valaki Arduino keretrendszer alatt?
Örültem, hogy itt mennyivel több memória van a nanohoz képet, de nem.
Maga a fordított program is nagyságrendileg nagyobb.
Adafruit 128x64-es demo:


Remélem van valamit rosszul állítok be.

A részletezést inkább kihagynám!

Inkább itt 1 link:
Bővebben: Icserny Link

Köszi.
De az én kártyámon gyárilag van USB.
Akkor is nem azon keresztül kell feltölteni a programokat?
Akkor az mire vagy?

Ha most hülyeséget kérdeztem, akkor előre is bocsi.

Nem unod már sokadszor feltenni ugyanazt a kérdést?

Ott a link és olvasd végig az oldalt, és a benne található további oldalakat is!
Mert ez nem 1 hetes szenvedés lesz!

Kösz.
Bocs, hagyjuk.

Dobom a kukába.
Hiába olvastam el, nem értettem hogy pontosan hogy van ennyi.
Most egy sejtésem van, hogy FW-kell rátenni talán így, de hogy utána hasonlóan használhatom mint az arduinot vagy sem, azt nem vili.

Bocs.

Itt és emitt megírtam, hogy mit kell csinálni.
Igen, firmware-t kell rátenni (legalább egy USB-UART átalakító kell hozzá, vagy egy ST-link programozó - utángyártott is lehet).
Igen, utána Arduino-hoz hasonlóan használható. Természetesen az Arduinohoz készült könyvtárak nem mindegyike fog automatikusan működni vele, mivel hardverileg más.

Nem értem, hogy miért kell használni ebben az esetben olyan kijelzőt, ami lezabálja az erőforrásaidat.
A demovieón látottak alapján megfelelhetne egy ilyen kijelző is. Bele is férne, működne is, és az erőforrás is megmaradna.

Köszi.
Ez hasznos infó amúgy.

Nem tudom fejből, de méretileg még lehet be is férne.
(ebből csak nagyobbat láttam eddig.)
A sajátomnál is a kijelzőt a panelről le kellett választani, mert belógott volna a vetni elé.

Viszont elég közel van, és elég sötét is van odabent.
Ezért a kavarcos megoldást alapban ki is húztam, mert valószínű nem látnám, mert úgy kell kicsit majdnem bebandzsítani az olvasáshoz.
Először LED-es kijelzőt alaktartam, de csak 9 szegmensest találtam, amin kicsit nehézkes lenne minden kommunikáció, mert csak pár betűt lehet valahogy számkijelzővel ábrázolni.

Mivel volt egy ilyenem, és az oled alapban világít, és így olvasható volt, ezért raktam be ezt.

Legvégső esetben közben jött egy 128x32-es verzió is. Ez kevesebbet enne gondolom, de jó lenne nem kéne azt a részt újra építeni ha van megoldás.

Gondolom a buffer addig kell, míg kiszámolja az egy képernyőnyit, aztán a következő változásig nem is szükséges. De pont azért keresek alternatívát, hogy lehet a vezérlő, vagy vezérlők cseréjével is lehet játszani.

Köszönöm mindenkinek a sok segítséget, így most már legalább az egyszerű dolgok felé el tudok indulni! Remélem sikerül valamit összehozni ezzel az Arduinoval. Viszont én is csatolnék egy linket amit egy másik fórumon kaptam, nekem nagyon tetszik, és ez is az alapokról indul:Hobbirobot

A fórumot olvasva, nem egyértelmű számomra, hogy melyik a jobb csatlakozású arduino panel. Ezalatt a normál, mini usb-s variációkra értem. Van aki a normál, van aki a minit favorizálja. Az hogy milyen csatlakozóval van felszerelve az arduino panel, nem mindegy?
Tudom, volt aki írta, a mini usb-s nem olyan stabil, de csak ennyi lenne a kettő között a különbség?

Még mindig nem érted a buffer lényegét. Azt nem lehet csak úgy megszüntetni/létrehozni, mert akkor elvész a lényege. Másodpercenként nagyon sokszor van rá szükség, ha megszünteted és létrehozod, nagyon kevés időd marad a helyét használni és a kijelzés ugyanúgy lassú lesz. 128x32-es képernyőnél 512 byte a buffer (128x32)/8, más különbség nincs. Annyi, hogy ilyenkor bele kell nyúlni az Adafruit-ba és átállítani a méretet amik #define formában vannak. A másik vezérlőnél meg el tudom képzelni, hogy nem 1 biten tárolt egy pixelt hanem 1 byte-on és akkor 8192 byte volt a buffer.

Amúgy van 16 szegmenses LED kijelző is, azon már minden betűt meg lehet jeleníteni normálisan. Hestore-ban alfanumerikus néven vannak.