A programot nem néztem át (kicsit késő van már), de ez a prell-mentesítési megoldásod azért nem jó, mert a nyomógomb éppen ezt csinálja (prell): zár-felenged-zár-felenged.
A programod pedig "túl gyorsan" fut és ezeket érzékeli; a várakozó ciklusod pedig éppen a prell miatt rögtön tovább is enged.

Kicsit később kellene visszanézni a bemenetre, amikor a prell már lefutott.

Megszakításból szerintem a port bemeneteket kezeld (interruptot beállítod és engedélyezed a megfelelő bitekre), de a nyomógomb-kezelés mehet a főprogramba (feléleszted, elvégzed a beolvasást, visszaaltatod).

Azt tudom, hogy nem jó a prell mentesítésem, a "while" ciklus csak egy hirtelen fellángolás volt részemről, és azt is tudom, hogy egy ~20ms-os késleltetéssel jobban járnék, de a leendő megszakítás miatt, nem szeretnék késleltetést berakni.

Próbáltam, hogy a bemenetek megszakítást idézzenek, és a főprogramban állapítom meg, hogy mely gomb lett lenyomva, de valamiért állandóan fals eredményt kaptam. Lehet, hogy a megszakításban, csak azt kellene megállapítani, hogy melyik gomb okozta, és ezt az adatot elmenteni egy változóban? Lehet, hogy már túl korán van a gondolkodáshoz?
Pedig elsőre olyan egyszerűnek tűnt ennek a rutinnak a megírása, és már kb egy napja "szenvedek" vele.

Milyen fals eredményeket kaptál?

Amúgy a megszakításban is még egyszerűen lekérdezheted, melyik bemenetről érkezett.

Ha nem akarsz várakozást, akkor felhúzhatsz egy timert erre a célra (mondjuk 20-30ms múltán megnézed, még mindig aktív-e a bemeneted - ha nem, akkor "elfelejted" ).

Általában a függvénynek megfelelően, a 'h' eredményt kaptam, hiába volt megnyomva bármelyik gomb, de jöttek olyan eredmények is, amik a "KeyMap" táblázatban nem is szerepeltek.

A Timer-es megoldás lett a nyerő, (Még hajnalban kipróbáltam) plusz a megszakításból főprogramban lekezelés. De ez utóbbi, még változhat.
Még egy kicsit szépítek rajta, és ha valakit érdekel felrakom a kész programot.

Egy újabb problémám akadt, illetve a dolog számomra érthetetlen.

MSP430g2452 + PCF8574. Az I2C kommunikáció megy rendesen, illetve a FUG által ajánlott beállításokkal, az adatokat tudom küldeni, és fogadni is.
A hardver: I2C SDA+SCL 4,7k-val felhúzva, P0-P3 lábon 330ohm plusz 1-1 led.
Ha kiküldök egy bájtot a PCF-nek, pl. hogy a P1-es lába legyen magas, és nem adom ki a stop utasítást az i2c-nek, akkor a led normál fényerővel világít. De ha kiadom a stop utasítást, i2c kommunikáció vége, a led elhalványul teljesen (fesz leesik 2,2V-ra). Megpróbálta g2553-al is, jelenség ugyanaz. A PCF8574-es adatlapjában nem találtam, vagy nem vettem észre, semmi olyasmit, ami arra utalna, hogy a stop parancs utána a kimenetek állapota megváltozna.
Mi lehet ennek az oka?

Ellenőrizd a PCF tápellátását, előfordulhat, hogy nem kap rendesen földet, csak valahogy a védődiódákon keresztül.

Open source-os (vagy open collectoros) kimenetei vannak.
Ami mondjuk nem magyarázza meg számomra teljesen a dolgot, de lehet, hogy ez az oka.
Próbáld meg úgy is bekötni, hogy a táp és a láb közé kötöd a ledeket. És 0-ra lehúzni ahhoz, hogy bekapcsoljon.

Köszi.
Valóban, fordítva jól működik. Most invertálhatom az összes lábát, mert annyi energia nincs benne, hogy egy FET-et kinyisson.........

Szia!
Az adatlap szerint én úgy látom egy FET-et simán tud működtetni !?

A valóság mást mutat, mert egy sima H-hidat (2 x irf7309 + 2n3904) nem bír el. De beraktam elé egy 74hc04-est és így jó. (A gond, hogy 24 lábat kell invertálni.)

Nem tudom, mert nem használom, de ha egy LED-et működtetett, akkor valószínűleg mA-s áram folyt, ami elég egy FET gate-re tett ellenállás lehúzásához! Itt ami inkább gond lehet, ha a FET gyors kapcsolása miatt nagyon kicsi gate ellenállást használsz !

Én ezt úgy oldottam meg, hogy raktam be egy 4,7K-10K felhúzó ellenállást.
Persze ha számít a kapcsolás energiaigénye akkor ez nem túl jó megoldás mert L-ra állított kimenetnél kb. 1mA folyik rajta.

Mérések alapján, ellenállás nélkül, a led áramfelvétele, vagy inkább ami kijön a PCF-ből, az 0.11mA. Ez kevés a FET tranyó pároshoz, de a led világít. A FET gate ell. 33ohm, a tranyó bázis ell. 1k.

balux33: Jó megoldás, és lehet olcsóbb mint a 74hc04-es. Az áramfelvétel ebben a kapcsolásban nem nagyon számít.
Köszi.

A Balux-féle megoldást sugalltam én is ! Ha a FET gate ellenállását (felhúzóellenállás !? ) 33 ohmosnak veszed, akkor akár 3,3V-nál is kb. 3,3V/33ohm= 100 mA kellene, hogy létrejöjjön!!Ezért írtam, hogy ott nem stimmel valami!

Miért nem használsz másik mikrokontrollert a PCF helyett? Árban ugyanott vagy, fizikai méretben is kb., fogyasztásban is. És cserébe ezért sokkal intelligensebb lehet a rendszered. Mert ha kell, a feladatokat szét oszthatod a mikrokontrollerek között.

Egy kicsit összekevertél, de sejtem mit akarsz "mondani".
Egyszerűbb ha berakom a kapcsolást.

Nem olyan nehéz/nagy a "feladat". Ha egy olyan kontrollert használnék, amelynek van elég kimenete, annak olyan perifériái vannak amiket abszolút nem használnám ki, és ezt nem szeretném.
Jelen esetben, nagy vonalakban, a feladat csak annyi, hogy 11 gomb állapotát kell figyelni, és ennek függvényében 36 kimenetet vezérelni. Ez bőven belefér, még egy kis extrával is, egy g2xx2-be, és a PCF-ből meg van itthon egy marékkal (ezért ezt használom).

Erre szerintem is tökéletes a PCF főleg ha van sok belőle.
Nekem utoljára 8 gombot kellet kezelnem és az i2c is használatban volt úgyhogy adta magát hogy ezt használjam, ráadásul a megszakítás kimenete nagyban meg könnyítette a lekérdezést.
Jut eszembe neked végül sikerült megoldani, hogy ne kétszer fusson le a megszakítás? Én AVR-t használtam ennél a projektemnél és nem tapasztaltam semmi ilyen hibát.

Igen. Belső felhúzás, és az aktuális flag törlése segített megoldani.
Nálam a PCF-ek kimenetként lesznek használva, és a MCU "szabad" lábaira van kötve a bill. mátrix.
Egy nem teljes kapcsolás: (+1 PCF, + 16db led, + apróságok. A "V H-bridge" kapcsolását csatoltam az előbb.)

Szia!
Itt nem felhúzóellenállásként van a 33 ohmos, ez nem lehet baj!

Sziasztok!

Aki próbálkozott az új mikrokontrollerekkel (g2444, g2544, g2744, g2755, g2855, g2955), az melyikeket tudta felprogramozni a launcpad kártyával?
Nekem a g2955-öst nem tudja programozni. Van rá valami mód, hogy a launcpad kártya programozni tudja?
Ha nem, akkor lehet valahonnan beszerezni olcsó programozót ezekhez? A TI 175 dollárért kínál, de az nekem egy kicsit sok...
Köszi!

Én nem foglalkoztam vele, de első körben firmware frissítéssel próbálkoznék. Ha nem megy, akkor pedig a bootstrap loaderrel (BSL), amihez csak egy 3-4 dolláros USB-TTL átalakító kell (olyan, amin a DTR, RTS adatfolyam-vezérlő jelek is ki vannak vezetve). Vagy egy Launchpad kártya: ha nem értettem félre, ebben a leírásban pont arról van szó, hogy hogyan használhatjuk letöltésre a Launhchpad kártyát.

A firmware frissítés nem sikerül, mindig kilép az 54-es hibakóddal, mint sok más embernek is, ahogy olvastam.

Viszont ez a BSL érdekesnek tűnik. Ezzel majd eljátszogatok.

Én voltam a naiv, elhittem, amit írtak, hogy a firmware frissítés lehetővé teszi minden jövőbeni MSP430G2xxx chip támogatását. Azóta kinyilvánították, hogy ezt nem gondolják komolyan.

Közben kipróbáltam, és a g2744-et programozza. De valamiért, mikor felprogramozom, az IAR F2272-nek ismeri fel, és rákérdez, hogy fel akarom-e programozni.
Én kényszerítettem, hogy programozza fel. Eddig baj nem volt belőle.

Az MSP430G2955 programozása:
Bővebben: programming a MSP430G2955?

Launchpad + mspdebug + gcc

Vagy!
Mindenféle varázslat nélkül, LauchPad + CrossWorks for MSP430.
Még csak most ismerkedem a programmal (ha lenne rá időm), de ami megfogott benne, az az ára. Talán az első olyan program, ami igazán hobbi felhasználó barátnak nevezhető, a maga 150$-os árával. Nem úgy mint pl. az IAR ami kb. 2000$. Kérdem én... Egy hobbiszintű felhasználó mikor tud ennyit áldozni egy fejlesztőprogramra......

Sziasztok!
Azt szeretném kérdezni, van-e olyan változója a timernek, ami 0 és CCR0 közt számol fölfelé, és az értékét le tudom kérdezni? Azért lenne szükségem rá, hogy egy bizonyos értéket meghaladva kikapcsolja a timert.
Köszönöm!

Ezt én is néztem, de ez az mspdebug-os varázslás elég bonyolultnak tűnik nekem. Egyáltalán a programok feltétele, és beállítása.

Ez tetszik nekem. Jónak tűnik. Amint hazaérek, kipróbálom.