A hd44780 driverben a D4-D7 -et át akarom tenni P2.0-P2.3 -ig de valamiért nem sikerül. A fejlécben átírom a biteket de nem akar összejönni. A driver icserny cikkéből való.

Prellmentesítést nem látok sehol hogy lenne a programban,
a legegyszerűbb módja, ha megszakitásba raksz egy 100 ms várakozást. Csak azt tudom javasolni nézd át a forrasztást alaposan, és ellenőrizd le a kvarcot az okozhatja.
Ha nem jó a kvarc akkor nem számolja az időt.

Nagyon szép munka gratulálok. Sokan fognak neki örülni.

Ennek a hozzászólásnak az utolsó két sorában megtalálod a megoldást.

"Ha megnézed a kártya kapcsolását, látható, hogy a vörös és a zöld LED különböző értékű ellenállásokkal vannak sorbakötve. "
Hát ez az. A leírásod, ill. az egymásnak ellentmondó adatok teljesen elbizonytalanítanak. SMD LED-ekkel még nem volt dolgom, de gondolom a fizikát azok is tudják, tehát a nyitófeszültségük olyan mint a normál LED-eknek. Itt az áram ami kérdéses. Ugye a régi iskola szerint küldjön rá az ember kb. 20mA-t és jól van. De azért kb. 10mA alatt nem nagyon szoktak "megszólalni", illetve normál fénnyel nem. Ráadásul ez egy mplx. dolog lenne, ami ugye tovább csökkenti a fényerőt.
A kártyáról kiindulva piros (nyitófesz. 1.6-1.8V) 470R-mal 3.4-3.8mA 3.5V-ra számolva. Zöld: 2.2-2.4V 7.5-7.9mA.
Amúgy a táp 3.5V, de azért gondolom a uP ejt egy min. 0.2-0.7V-ot ebből, vagy nem? Tudom megmérhetném, de még nincs beüzemelve a drága hála az ügyesen beforrasztott csatlakozóknak
Lehet muszáj lesz füstgenerátort építeni egy uC-ből okulás végett?
Jah' és a másik gond. A boltban kapható LED-eket általában manapság úgy hívják pl., hogy "3mm diffúz sárga". Nem CQY..., stb. hogy adatlapot kereshess hozzá, az itthon lévőkkel ugyan ez a baj

Egy kicsit túl aggódod szerintem ezt a LED kérdést, pláne ha figyelembe veszed, hogy a nagyfényerejű ledek között is találsz kisáramú változatokat. De szerintem 3--4 mA-rel már megfelelően világít a legtöbb SMD led.

Erre csak azt tudom mondani, hogy meg kel nézni (ehhez mikrovezérlő sem kell), hogy adott áramhoz mekkora ellenállás kell, s hogy ez mekkora fényerőt produkál. Én egységesen 1 kOhmos ellenállást használok mindenhol (3,3 V-os mikrovezérlőknél is), s a kísérleteimhez bőven elegendő a fényük. Egy gyakorlati alkalmazásnál természetesen figyelembe kell venni a szélsőséges fényviszonyokat, s el tudom képzelni, hogy muszáj nagyobb áramot használni. Ehhez viszont valami meghajtóra is szükség lesz.

Multiplex kijelzésnék szoktak azzal szélhámoskodni, hogy nem tesznek áramkorlátozást, hanem az időtényezővel játszanak. Ez viszont meglehetősen kockázatos dolog, s a pl. PIC16F628-nál alkalmazott megoldások nem alkalmazhatók ugyanúgy az eleve kisebb kimenő áramú MSP430G2xxx-nél. Célszerűbb inkább valami meghajtó áramkört használni.

Hát igen. A PIC-ek tolnak-nyelnek 20mA-t. A meghajtás alkalmazásával itt az a baj, hogy van 4 szabad port és 10 ledet akarok róla vezérelni. Innentől a PNP, NPN dolog miatt esélytelen. Ráadásul a cél a minél kisebb fogyasztás. Na majd kísérletezek, hátha ujjhőmérővel meg tudom menteni a vezérlőt az elszállástól
Jah' és másik perverzió 1 bementeről 12 gomb kezelése hasonló okokból

Nem SMD LED-ekről van szó. Sose használtam még. Szeretem ha valami nagy, ezt hagyták ránk orosz testvéreink (pl. MP401). Tudod eddig Texas vezérlőkkel nem találkoztam, de tetszenek a tulajdonságaik és próbálkoznék velük, de nem szeretnék nekik "fájdalmat" okozni Lehet, hogy ez már félvezető fetisizmus?

Ahol a kis fogyasztás a cél, ott elsőként a nagyáramú LED-eket kell kiküszöbölni. A LED-es karórák sem véletlenül mentek ki a divatból, pedig annak idején nagyon menő volt a Hewlett-Packard cég kalkulátorral egybeépített karórája.

Az orosz Ledek......még mindíg van olyan piros ledem tőlük, ami izzadás nélkül bírja a 100mA-t folyamatosan, pedig legalább 25 éve gyártották. Ez a nem semmi. Akkor szerintem csak próbálgatással - akarom mondani méregetéssel - jutsz előrébb. Tesztelni kell kis áramra a fényüket.

Rájöttem. A felhúzóellenállás 10k volt de 5k val jó. szóval csak delay 100ms a gomb megnyomása után?

Köszi. Amúgy, ugyanezen az elven átírható egy egyszerű serial/parallel shift-regiszterre is, pl 74hc164. Ezt könnyebb beszerezni. A hátránya, hogy pl az mcp-nél a maradék két portot fel lehet használni bemenetnek, akár megszakításban is, de shift-regiszternél nem.

Megoldottam. Képek: Bővebben: Link

Szép, igényes munka, csak gratulálni tudok.

Köszi. Nem magamnak lesz azért ilyen szép

Köszönöm, hogy megosztottad az mcp-s meghajtás kódját mert én is gondolkodtam valami hasonlón, csak PCF8574 -el mert az van itthon. Így már könnyű lesz a dolgom.

A PCF8574-re is megcsináltam. Nem rakom fel a teljes kódot, mert majdnem ugyan az. A változások =
1: A main.c-ből a "void mcp23_setup(){" nem kell.
2: A "void i2c_init(void){"-ben a UCB0BR0 = 10; // Ha DCO = 1MHz akkor SMCLK/10 = 100kHz i2c clk !
Az lcd_i2c.c-ben, a "void mcp23008_i2c(unsigned char tx){" helyett
kerül. A PCF-nek csak annyi a hátránya, hogy lassabb, ezért próbáltam ki az MCP-t, és nem csalódtam benne.

Még egy apró, ám de fontos megjegyzés. Ha össze-vissza karaktereket írna ki az lcd, akkor a "void pcf8574_adat(....){" ill. a "void mcp23008_i2c(....){" rutin végén, a várakozást (__delay_cycles(xy) növelni kell ! Sajnos nem értem, hogy miért, mert elméletileg, amíg nem ér ki az adat, addig nem állíthatná le az i2c rutint. A lényeg, hogy a várakozás nélkül nem megy!

Hálás köszönet ez nem semmi.

Még egy kérdés, úgy próbáltad, hogy a prociban lévő ellenállásokat húzod fel és nem raksz a P1.7 és P1.6 ra külső ellenállást?

A pcf-nél próbáltam,
de nem ment. A vezeték hossz (mivel dugdosós panelen van az egész) kb. 15cm. Beraktam két 10k ohm-os ellenállást és úgy megy. Szerintem ha nyákra kerül, két ellenállás már nem zavar senkit.
Közben megint eszembe jutott valami. Amit beraktam kódrészeltet (pcf8574_adat), ott azért adom ki a "slave címet" mindíg, mert fel volt fűzve mégegy Launchpad az i2c-re. Ha csak a pcf van az i2c vonalon, elég egyszer, az elején kiadni a slave címet.

Megoldottam a pergésmentesítést is. A kérdésem az lenne hogy ennek mennyire kéne pontosnak lennie. Ma tesztüzemen volt de mivel hurcoltam magammal ezért volt 30C hőmérséklet eltérés is ami nem biztos hogy termosztát nélkül jót tesz a kvarc pontosságának.

A pergésmentesítés pl. a gombhoz kell... a gombok nem egyformák --> az a lényeg, hogy jól működjön, nincs egzakt érték ( persze, ha "túlméretezed", akkor biztos jó !), ha 50 - 100 ms-ot vársz, akkor biztos nem fog zavarni a prell ! A kvarc pontossága 30 fokon sem változtatja lényegesen az időzítésedet ( nem "rakétavezérlés" készül! ), pl. 20 ppm/C-es kvarc 10 fok változásnál 200 ppm változást szenved, ami 0,02%-os eltérést jelent (ennyivel változik az általad beállított idő is!) !

Steve

Hát ezt elírtam rendesen. A pergés csak egy bejelentés volt de köszi. A pontossági kérdés magára az órára vonatkozott

Sziasztok.
ICserny fórumtársunktól szeretnék kérdezni, de ha valaki más is tudja a választ, kérem ne tartsa vissza magát. (És elnézést a személyeskedésért.)
Tehát, szereztem egy HC-05-ös bluetooth modult, ami kifogástalanul működik. A kommunikáció elsőre összejött az USCI UART A0 perifériával, a PC és egy G2553 között. (Csináltam egy kis programot, ami a PC billentyűzetről beolvasott karaktert, kiírja a g2553-on lévő lcd-re.) A problémám a következő: a kommunikációt csak a hyperterminálon tudom megvalósítani. Írtam egy kis programot a Processing 1.5.1 -ben, de nem látja a bluetooth portját.
A Processing ezeket a portokat látja, a HC-05 pedig a COM14-en van. A hyperterminál viszont látja a COM14-et. Ez mitől lehet?

Nem tudom hogy mitől van, de a HC-05 vagy HC-06 (azt hiszem, nekem az utóbbi van) bluetooth modul esetén sok alkalmazás megtoldja a COMn nevet valami betűvel (b vagy ilyesmi). Nekem már Hyperterminálom sincs (a Win7-ből kispórolták), így csak a Putty.exe-vel tudok kommunikálni.

Nekem is Win7-em van. Amit Én használok hypert., csatolva. A bluetooth ikonra, jobb klikk, beállítások megnyitása, COM portoknál, az látom, hogy
port irány Név
COM14 kimenő HC-05'Dev B'
COM15 bejövő HC-05
Nem foglalkoztam még ilyesmivel, ígyhát nem is értem, hogy miért van egy kimenő, és egy bejövő port.

Nem tudom miért van külön be-ki port igaz nem is vittem túlzásba a nyomozást utána, de ez nem egyedi. Pl. ARF32-es modulnál is így van, a magasabb portszámon kommunikál oda-vissza, az alacsonyabbon meg a terminál programtól függően már vagy megnyitáskor megfagy vagy csak az első kommunikációs kísérletnél.
Terminálként Realterm-et használok, szépnek nem szép, de van néhány hasznos szolgáltatása. Sourceforge-on megtalálható.

Nálam a hyperterminál a COM15-ön nem tud kommunikálni a HC-05-el, csak a COM14-en, de ott oda-vissza. Nekem a legnagyobb problémám, az, hogy a Processing nem látja a COM14-et, és ő sem tud a COM15-el mit csinálni. Most viszont előre léptem egy kicsit, mert véletlenűl bekapcsolva maradt a hypert, és elindítottam a Processing programom, és látja a COM14-et, de infót nem küld. Már csak arra tudok gondolni, hogy valamit be kéne állítani a HC-05-n, ugyanis nem csináltam vele semmit, csak rákötöttem a vezérlőre, és felismertettem a PC-vel. (ill. a key lábat GND-re kötöttem.) Megkeresem a progit amit írtál, hátha okosabb leszek.
Köszi.