Tárold el az információs memóriában. Pár kommenttel korábban le lett írva a menete, éppen én kérdeztem.

Köszi a gyors választ!
Ehhez még nőnöm kell egy kicsit...

Nem kell megijedni tőle.
- deklarálsz egy változót
- Flash setup
- flash tartalom másolása változóba
- változó használata.....
-----
- a megváltoztatott változót mented rögtön a flash-be.
A függvények, és a setup.

Köszi!

Egy nagyon egyszerű próbát kreáltam és működik (magam is csodálkozom ezen )
A biztonság kedvéért bemásolom a kódot, hogy nincs-e benne valami nagy hiba. Ha rápillantanál azt megköszönném!

Így első ránézésre jónak tűnik.
Egy javaslat a flash (info memory) írással kapcsolatban.
Ha hosszútávra tervezed a programot, és sűrűn használod a flash írást, akkor érdemes egy szegmenset teleírni. (pl. jelen esetben, "flash_write(0x1000, i, 0);" következő írás: "flash_write(0x1000, i, 2);"..... Tehát az első írás a 0. címre, a következő írás az első adat nagyságától függően a következő üres bájra, szóra történjen. Így nem kell minden írás előtt törölni, csak ha megtelik a szegmens. Plusz még az újraírhatóság is véges, arra is oda kell figyelni.

Nekem is flashel kapcsolatban lenne pár kérdésem...

Nekem lebegőpontos értéket is kellene tárolnom, nem teljesen vagyok tisztában a címzéssel és a flash felépítésével. Ha jól gondolom a függvényeddel bele tudom írni azt is, csak utána a címet egy floatnyival kell eltolni, hogy a következő érték is jó helyre kerüljön? Az én procim 16MHz-en fut, eddig arra jutottam, hogy ACLK órajelről, osztó bekapcsolással tudom a kellő sebességet biztosítani neki, ehhez esetleg van készen kód? Az ACLK lassítása melyik perifériákat lassítja?

Mivel nem támogatja a mikrovezérlő ezért inkább csinálj belőle "long" típust, vagy más támogatott típusú értéket. Jobban jársz.

Kinek?

Amelyiknek azt mondod, hogy az ACLK órajelet használja.

Tettem egy próbát a kóddal amit fentebb írtatok. Ha jól sejtem akkor a lebegőpontos változómat fel kell szorozni egész értékre és úgy eltárolni a javaslatod szerint. Megprobáltam átírni a függvényeket, hogy tudjak long-ot írni és olvasni, de nem teljes a siker. Az int változókat probléma nélkül tudom beírni és kiolvasni, de a long változót valamiért nem menti el. Meg tudnád mondani hol a hiba vagy tudnál küldeni olyan függvényt, amivel longot is tudok menteni? A cim_1 eltolás jól gondolom, hogy a menteni kívánt változó hossza lenne bájtban? Tehát egy longot így kéne mentenem flash_write(0x1000, long változóm,0); és a következő flash_write(0x1000,long változó2,4); ?

Nem egészen jó az elméleted! Nézz utána a változótípusoknak!

A "float" hogy jön létre? Nem lehetne eleve "long" értéket megadni, vagy létrehozni?

Az infó memóriába max. 16 bites változókat/értéket tudsz tárolni.
Tehát, ha Te long típust szeretnél tárolni, (vagy float típust) azt szét kell szedni 16 bites értékekre, és a függvénybe "int" helyett "uint"-et kell megadni. Ennek a legegyszerűbb módja, ha a long típusú változóból, két uint változót csinálsz, és azokat mented az infó memóriába.
Valahogy így!?:

Az IAR-ban, ha bekapcsolod a "View/Memory->INFO" opciót, akkor látod mit is csinálsz.
Azt még hozzá kell tegyem, hogy ennyire még nem mélyedtem el a flash kezelésben, ezért lehet, hogy van egyszerűbb módja is ennek a folyamatnak.

Főként HeStore-os alkatrészekből, kb. 5-6000 Ft-ból, építettem egy alacsony költségvetésű kis vonalkövető robotot. icserny kolléga nagyszerű Launchpad-es cikkei adták az ötletet hozzá.
Az angol nyelvű cikk a Let's Make Robots weboldalról:
SiLi LiLa BOT

Jól néz ki. Nekem speciel az újrahasznosított dolgok tetszenek.

Sziasztok!

MSP430-al lehet valahogy érzékelni a rövidzárat? (Valószínűleg MSP430G2553-at fogok használni).
Van egy ATX tápom amiről táplálom az áramköröket fejlesztés során. Tudom, hogy van benne rövidzár védelem, de mivel mást is hajtok róla (pl. Raspberry Pi-t) nem szeretném, hogy az egész táp lekapcsoljon.
Ezért arra gondoltam, hogy csinálok egy kapcsolódobozt amivel külön-külön tudom kapcsolgatni a feszültségeket ki/be és van benne rövidzár védelem csatornánként (3,3V, 5V, 12V).

pl. teszel a tápvonalakba egy-egy soros (mondjuk 0,01 Ohmos) ellenállást és méred rajta a feszültséget, így akár konkrét beállított áramnál is lekapcsolhatod. De lehet ágyúval verébre dolog erre MCU-t használni. Egy áteresztő/kapcsoló tranzisztor/FET mindkét esetben kell, áramfigyelő ellenállás szintén. Onnan meg kb. plusz egy tranzisztor és meg van oldva a sima, vagy visszahajló karakterisztikájú áramkorlátozás.
Mondjuk nagyobb áramoknál már kapcsolóüzemű szabályzókat érdemes használni, különben nem lesz gond a fűtéssel sem

Google a barátod...

A tápban a rövidzárvédelem gyors és analóg. Ezzel nem fogja tudni felvenni egy kis uC a versenyt (ADC konverzióhoz idő kell, feltételt kell vizsgálni, parancsot kiadni), különösen több csatorna esetén.

Azért használok MCUt, mert Capacitive Touch gombokat szeretnék

idlob szerint a táp védelme gyorsabban fog reagálni. Ez esetben kénytelen leszek analóg megoldást választani.

Köszönöm mindkettőtöknek a hozzászólást!

Sziasztok!

Volt egy kis szenvedésem, amit szeretnék megosztani.

Vettem Ebayen Nokia 1202 kijelzőt, mert olcsó volt és szükségem lesz majd néhány darabra.
Láttam, hogy többen meghajtották, de mindenhol bitbang-es megoldást találtam, ezzel pedig túlságosan nem voltam kibékülve, ha már az MCU ismeri az SPI-t is.

A probléma ott kezdődik, hogy a kijelző 9-bitet vár a buszon, az MSP430 pedig 7 vagy 8-bites üzemmódban tud működni.
Ugyan a vezérlője ismer I2C, három vagy négyzetékes SPI-t (itt a D/!C nevű bit is elérhető), de a kijelzőn csak a háromvezetékesnek nevezett változat van kivezetve.
(Hogy miért SDA-t emleget az adatlap SPI-nél, azt azért nem tudom, de mindegy is.)

Tehát úgy kell kiküldeni az adatot a kijelzőnek, hogy az első bit ez a bizonyos D/!C legyen, az összes többi pedig mehet utána.

A következő kérdés, hogy kiküldhetem ugyan 8-bites sorozatokban az adatomat, de mi lesz a maradék bitekkel?
Első gondolatom az volt, hogy legrosszabb esetben megkeresem a legkisebb közös többszöröst és gyakorlatilag 9-byteot küldök ki egyszerre. Ez rendben is lenne, ráadásul találtam egy NOP utasítást is (bár lenne másik, amivel helyettesíthetném), de ez azért mégiscsak pazarlásnak tűnik.

Neten keresgélve máshol javasolták, hogy egyes esetekben a vezérlő az utolsó X byte-ot veszi figyelembe (amolyan shift-regiszterbe érkezik az adat és a CS felfutó élénél dolgozza fel).

Ám végül az adatlap további olvasgatása hozott eredményt: ha az adott byte nem teljes (és itt byte alatt 9-bitet kell érteni), akkor a csonkolt adatot a kijelző vezérlője egyszerűen eldobja.
Úgy éreztem, ez kell nekem.

Tehát a következőket csinálom jelenleg:
- Megnézem az LSB-t, hogy 1 vagy 0 volt
- Jobbra tolom a küldendő byte-ot
- Az MSB-t 1-be billentem a kijelző írásához és 0-ba parancshoz (ez a D/!C bit)
- Kiküldöm
- Második byte első bitje lesz az előbb elmentett LSB, második bitet szintén 1 vagy 0-ba billentem, bár erre lehet, nincs is szükség.
- Kiküldöm

Ezzel a módszerrel tökéletesen működik a "9-bites SPI-t" igénylő kijelzőm hardveres SPI támogatással.

Csatoltam egy képet róla.
A NYÁK nem túl jó, amolyan tesztként lett összerakva (nem akartam letépni a szalagkábelét) és a háttérvilágítás áramkorlátozó ellenállását valószínűleg nagyobbra cserélem majd.
Reset lábnak nem láttam értelmét kivezetni (bár indokot elfogadok, miért kellene), LED-et pedig a FET kapcsolja, elég egy GPIO kimenet hozzá.

A kijelző csatlakozója amúgy egész jól forrasztható, ára 2.49 AUD volt.
Ez Google szerint jelenleg 538 Ft.

A kiírt adatsor ismerős lehet, egyelőre egy meglévő programban írtam át az SPI-kezelést (van benne egy "hiba" a kiírt karaktereknél a nagy I környékén).
...de azt hiszem, kicsit másként fogom majd megoldani a vezérlését - egyelőre az volt a lényeg, hogy működjön az SPI hardveres támogatással.

Bocs a hosszú írás miatt.

Ebben milyen vezérlő van? Nokia 5110 kijelzőnél (PCD8544 vezérlő) ki van vezetve a D/C láb, és akkor nem kell 9 bitet küldeni.

Ebben STE2007 van, de sajnos nincs kivezetve a D/C láb. :S

Kiosztás pl. itt látszik

Olyan ismerős ez a kijelző...Mintha lenne egy "marékkal" ebből a fajtából nekem. Van egy képed a hátuljáról?

Google Nokia1202 LCD keresésre a képtalálatok között találsz néhányat.

Megvan, köszi.

Egy hasonló termék (eeről nem írják, hogy Nokia kijelző volna) pedig ezen a fórumon található.

Látom, találtál már, de azért készítettem róla képet (ez még egy "felhasználatlan" darab).

Mondjuk sok nem látszik ebből...

Egy furcsa jelenségre keresem a választ.
Készítek egy programot, valamilyen g2xxx vezérlővel. Általában, az esetek 99%-ban, kihasználom az UART-ot ellenőrzés, kontroll céljából. Csak akkor nem, ha minden I/O foglal. Az, hogy melyik UART-ot használom (HW/SW), az mindegy.
A hibajelenség, hogy tízből nyolcszor, egyszerűen nem ismeri fel, vagy nem jelenít meg semmit, sem a PUTTY, sem a Hyperterminal. Ilyenkor a Launchpad USB ki/be húzgálásával, és a program (Putty, Hyper) újraindításával (többször), egyszer csak elindul.
Mielőtt valaki a COM port beállításokra gyanakodna, azokkal semmi gond nincs. Van egy olyan LP-om, amin már nem is megy, sem a HW UART, sem az SW.
Találkozott már valaki ilyesmivel? Vagy van valakinek valami ötlete, hogy mi lehet a gond?
OP: Win 7 x64.

Valószínűleg ez: "OP: Win 7 x64."

Az alapértelmezett 9600 Baud-dal szokott a legnagyobb valószínűséggel elindulni. PuTTY-val szokott a legnehezebben elindulni. Szégyen, nem szégyen: ha nagyon nem megy, akkor az Amicus18 IDE terminál emulátorát szoktam elővenni.

Az a sejtésem, hogy néha a Win8 Bluetooth-os programjai is bekavarnak. Amit lehet, azokat ki szoktam lőni, de mivel Bluetooth egerem van, mindent nem tudok leállítani.

Ha valami komoly dologhoz kell a kapcsolat, akkor tegyél az MSP430 mellé egy CP2102, PL2303HX vagy FTDI FT232 USB-UART protokol konvertert!

Köszi.
Mivel "Amicus18 IDE" programot nem ismerem, marad a szenvedés...Már próbáltam a Bluetooth kikapcsolni, más terminál programokkal is próbáltam (TeraTerm, HyperTerminal Private Edition...), de az eredmény ugyanaz. A Baud mindig az alapértelmezett 9600, csak kivételes esetekben szoktam megváltoztatni.
Ja, és a Win 7 x86-os gépen is ugyanez a hibajelenség van, pedig azon nincs is Bluetooth.
Rejtély....

Én rengetegszer, még nem sikerült rájönnöm mi okozza nálam is WIN7X64.
Viszont azt tapasztaltam, hogy ha elsőnek bedugom a LP -t utánna indítom a terminalt majd utoljára a CCS -t- akkor nem kel vacakolnom az LP ki/be húzgálással.

Ez jó. Kipróbálom, de így fejleszteni elég nehéz, pláne ahogy én szoktam.
Röviden a fejlesztési stílusomról: dugdosós panel - "tele" külső alkatrésszel - összekötve a LP-el - IAR vagy CCS - program futtatás/debug - teszt - ha nem jó valami, LP lehúz, ilyenkor, ha elfelejtem, az IAR kiabál, hogy eltűnt a LP, - alkatrész csere - LP visszadug - újra futtatás.

Ha minden egyes alkalommal mindent újra kellene indítanom.....
Pl. egy a képen látható projektnél, az időm nagy részét az újraindítással tölteném, töltöm most is.

Khmmm, ezt mindenféle USB CDC eszköznél eleve így kell csinálni. A Microchip mintapéldák között volt egy Plug and Play mintaalkalmazás, az kivételesen képes (de nem mindig!) kapcsolódni az utólag bedugott eszközhöz.

A Launchpad esetében az a probléma, hogy a mikrovezérlőnek csak valami szoftveresen emulált kapcsolat jut, ami bizonytalan működésű. Eleve elfuserált konstrukció...

A képen mi látható?