Lenni kell ott valami másnak is mert ez nem indokolja, bár lassan CCS ügyben már semmin nem tudok nagyon meglepődni.
A gyanúm az hogy az egyszerű master módban erőlteti a hardveres I2C használatát, de lagalábbis ragaszkodik a hardver pinekhez és nem lehet lebeszélni róla FORCE_SW paraméterel sem, mert más pineken képtelen voltam lelket lehelni bele, de így menni látszik. Hogy mennyire megbízható az majd kiderül.
Tuulajdonképpen nem is lenne baj, mert a végleges áramkörben 2 MSSP-s PIC lesz, de szeretem kipróbálni legalább részletekben a cuccot próbapanelen mielőtt pénzt ölök bele és összerakom a végleges verziót, mert a TQFP tokok ki-be forasztgatásához nem nagy ambícióm van..

Sziasztok

Lehet , hogy a pic kezdő topic-ban kellene feltennem a kérdésemet, de mivel CCS-t használok itt teszem fel.

Tehát: adott egy tömb és egy rá mutató pointer.
Egy másik tömböt szeretnék feltölteni az eredeti elemeivel az alábbi módon:


Debuggoláskor látom, hogy a pointer felveszi a megfelelő értéket. Azt is látom, hogy megfelelő helyre mutat és a ciklus futása közben növekszik a cím. Csak azt nem látom, hogy a mutatott címen levő érték betöltődne a tömbbe.
Valószínűleg valami triviális dolgot nem csinálok jól, de sajnos hosszas fejtörés után sem jöttem rá, hogy mi az.
Ha valaki fel tudna világosítani azt megköszönném.

Üdv.

Két lépésben csináld.
1.: Egy változóba olvasd be a pointer által mutatott értéket.
2.: Az indexált tömb elembe tedd le a változó értékét.

Vagy használd a memcpy() függvényt.

Szervusz!
A pointert (és a tömböt) hogy deklaráltad?

Köszi megpróbáltam mindkettőt. Sajnos a változóba sem töltődik be a címen található érték. Nem értem Látom, hogy a pointer pl a 0X01c6 címre mutat. Ezen a címen 0xFE van. Azt mondom, hogy j= *ptr; és semmi.
A memcpy() sem megy, legalábbis így:

A pointer jó helyre mutat? (másik tömb)
A egyik tömb másikba másolásához minek még egy pointer is? Bár működnie kéne.

Szia


Utána van egy switch case , case után:



A case után a pointerben a th tömb címe van.
Üdv.

Azért kell a poiter, mert több tömb közül egy feltételvizsgálat után dől el, hogy melyik lesz az aktuális. Maga a program működik, de nem szép. Minden case ágban van egy ciklus ami felülírja a tömböt. Valahogy így:
...........

Közben rájöttem.
A pointer egy olyan tömbre mutat, amit a cost int -tel deklaráltam, hogy a programmemóriába kerüljön. (Erre azért van szükség, mert a ram-ba nem fér el ennyi tömb.) Ahova másolni szeretnék, az pedig a RAM-ban van. Böngészem kicsit a CCS manualt, hátha van erre valami megoldás.

Köszi mindenkinek.

Ezért kérdeztem a deklarációt...

Azért jöttem rá mert kérdezted...Köszi.
Van lehetőség pointer használatára a két memória között?

Valószínűleg úgy kell létrehoznod a pointert is, mint ahogy a tömböt, amire mutat. Így a fordító tudja, hogy a chpointerl az a kódmemóriára mutat. Tehát valami ilyesmi:

Próbáltam, de a const -tal létrehozott változóknak kötelező értéket adni. (Tehát igazából nem változók hanem konstansok).

Akkor pedig szerintem létezik olyan függvény, amivel lehet kódmemóriából ramba másolni.

read_program_memory( )
read_external_memory( )
Syntax:
READ_PROGRAM_MEMORY (address, dataptr, count );
READ_EXTERNAL_MEMORY (address, dataptr, count );
Parameters: address is 16 bits on PCM parts and 32 bits on PCH parts . The least significant bit should always be 0 in PCM. dataptr is a pointer to one or more bytes. count is a 8 bit integer on PIC16 and 16-bit for PIC18
Returns:
undefined
Function: Reads count bytes from program memory at address to RAM at dataptr. B oth of these functions operate exactly the same.
Availability:
Only devices that allow reads from program memory.

Szerintem ez kell nekem.

Sziasztok!
Csak érdeklődnék, hogy volt-e már valaki olyan szerencsés hogy egy 5V-os PIC-re tudott kötni egymás mellé egy ENC28J60-at és egy SD kártyát is?
Az ENC megy szépen, de az SD kártya kezelése halott.....
Ha valakinek van egy kipróbált, biztosan működő rajza legyenszíves ossza meg velem! Lassan az őrületbe kerget a dolog....

... persze ha a trükk a programban van az is nagyon érdekelne...

A program memóriában lévő tömböt nem lehet pointerezni, de indexelni lehet. Egy for ciklusban jól lehet másolgatni a tömböket.

Akkor kicsit egyszerűsítek a kérdésen.
Mitől lehet az, hogy az mmssd.c mmcsd_init() akkor is true, ha nincs betéve a kártya?
Valami nagy kufircság van, de nem vagyok képes rájönni.....

Hali
Most hirtelen nem tudok utananezni, de a SPI negyfele uzemmodot hasznal, az eszkoztol fuggoen. Nalad meg kellene nezni, hogy az ENC, es a SD ugyanazt az uzemmodot hasznalja, vagy nem. Ugy mint a "0_0", "0_1", "1_0" es az "1_1". Ez az orajel ele, es az adatbeolvasas ele. Lehet vele szivni, ha a ket eszkoz nem azonos modusu. Epp mostanaban szivtam a MCP3551 AD-vel. 16F877, 16F887 jo, 18F4520 nem olvasta. Vegulis a "SPI_SAMPLE_AT_END" varazsszo segitett.

Urak! A dolog megoldódni látszik, bár nem akarom elkiabálni.
Úgy tűnik az SD kártya inicializáláskor az SPI_CLK_DIV_64 kevésnek bizonyul. 20MHz-en ennek elvileg 312,5kHz-et kéne hogy adjon, ami beleférne az SD kártyák inicializálásához szükséges 100-400kHz-be, de úgy tűnik ez a kártya nem szereti.
A megoldás az lett, hogy a kártya inicializálás idejére az SPI clock-ot SPI_CLK_T2-re állítom kb 100 kHz-re.
Ami továbbra is érdekes, hogy az SD kártyát MMC-nek ismeri fel, de ezzel már tudok együtt élni. Az init után visszaállítható az SPI órajele SPI_CLK_DIV_4 -re.

Szia

Hosszas keresgélés és fórumolvasás után rájöttem én is. Azt írják a ccs c fórumon is, hogy ezt sajna nem lehet.
Próbáltam a read_program_memory és a read_program_eeprom függvényeket de hülyeségeket csinált. Arra tippelek, hogy azért, mert a 16f887-el ezt nem lehet megcsinálni.
Épp most sikerült átalakítanom a kódot úgy, hogy működjön is, és ne legyen minden case ágban ugyanaz az indexelő for ciklus.

Köszi az infót, üdv.

Szervusz!
Az eepromot a read_eeprom(i) és write_eeprom(i, c) függvénnyel lehet írni olvasni.
Valahogy így:
for( i = 0; i < 16; ) { write_eeprom(KALIBR_MENT + i, u.eeprom[i]); i++; }
for( i = 0; i < 16; ){ u.eeprom[i] = read_eeprom(KALIBR_MENT + i); i++; }>>

A fórummotor valamiért lenyeli a tömbindexeimet...
Talán most nem:

Szia

Nekem nem a sima eeprom-ot kellene írni/olvasni, hanem a program memóriában tárolt (const tomb[] konstansokat szerettem volna pointerekkel elérni.
A problémát indexeléssel kiküszöböltem, viszont most egy újabb probléma adódott. Van 44 db 10 elemű tömböm. Const -tal dekraláltam őket, így a fordító betette a program memóriába 000b - 01d6-ig. A tömbök indexelése egész addig kifogástalan, amíg 0100-nál kisebb címen van az adott elem. A 0100-nál magasabb címekről hülyeségek jönnek vissza. (PL 0110-t indexelve a 0010-n levő adattal jön vissza) Assambly- ben ezt a PCLATH módosításával lehet korrigálni.
Most kezdtem a ccs c-t használni, de nem gondolnám, hogy a fordító ezt nem kezeli önállóan. Vagy tévedek?

Nekem úgy tűnik, int8 változóval indexeled, és 0-255-ig értelmes a dolog, aztán hex0110=dec272 helyett hex0010=dec(272-256) jön. Ha int16 a változód, akkor nézz utána annak is, hogy nem-e valami régebbi verziójú a fordító, volt amikor nem kezelt 256-nál nagyobb tömböket. Most kezeli szó nélkül.

Kellene neki, a helpje ezt írja:
The compiler has support for placing any data structure into the device ROM as a constant read-only element. Since the ROM and RAM data paths are separate in the PICŽ, there are restrictions on how the data is accessed. For example, to place a 10 element BYTE array in ROM use:

and to access the table use:

OR

BUT NOT

A programnak amit írok két verziója van. Van egy régebbi fapados ami teljesen jól működik, de nem túl korrekt. Ebben a program elején létrehozom a tömböket egyesével. A programmemória egy része a kritikus pontnál a mellékelt file-ban van. Látszik, hogy a 0x0100 előtti címeken a RETLW-k előtt BCF 0x0a,0 van. A 0x100 utáni címeken BSF 0x0a,0 van. A 0x0a a PCLATH címe, tehát kezeli a lapváltást.
Az újabb verzióban egy header file-ban dekralálom a tömböket ráadásul úgy, hogy struktúrákba vannak létrehozva más kapcsolódó adatokkal. Ha itt megnézem a programmemóriát akkor nyoma sincs a PCLATH kezelésének. Nem értem.

Van amikor a működőképesség és átláthatóság fontosabb mint az elegancia...
Mivel nem látjuk a konkrét kódot, ezért csak találgatni lehet az elmondásod alapján. Így nekem úgy tűnik a struktúra körül lehet a gond. Nem kevered esetleg az unionnal? Mert pl. attól is lehet hasonló tüneted!

Ez van a header file-ban most már kicsit leegyszerüsítve. Van egy struktúra ami 2 tömb-ből áll. Van egy tömb ami ilyen struktúrákat tartalamz.:



stb..stb..még 42db tömb. A deklarálás szerintem jó, mert a debuggerben megfelelően látom a charact struktúratömböt.
__________________________________________
Az ascii egy olyan indexelő ami a struktúra tömb egy elemét azonosítja. A next_charl és a next_charh tömböket az alábbi módon feltöltöm az ascii által indexelt struktúra tömbjeivel.

Ez Így működik is, csak az a probléma, hogy a programmemóriában az egész struktúratömb egy nagy összefüggő RETLW sorozat, ezért van gond lapváltáskor az indexeléssel.

Lehet, hogy én bonyolítom túl, de a kód így sokkal rövidebb és nekem jobban tetszik. Csak sajna nem működik rendesen, pedig az elmélet szerintem jó. Ha nem indexelek 0x0100 fölötti tömböt akkor tökéletes.
Üdv