Sziasztok
Bocs hogy ilyen témát nyitok, de nem találtam megoldást erre a problémára.
Egy pic16f877-en keresztül szeretném írni olvasni a 24c64-es EEpromot mikropascalban, de nem sikerül a 24c08-at szépen viszi. Tudom hogy a 24c08-nak 8 bites címzése van a 24c64-nek meg 16 bites, csak nem tudom hogy is alakítsam át a forráskódot.

Felesleges sortöréseket töröltem.

Elnézést!

Ha jól emlékszem előbb a felső majd az alsó 8 bitet kell elküldeni.
Ha a beépített I2C függvényét használod, és longintet használsz, akkor úgy emlékszem (robotos pic-es cikknél szórakoztam vele először és utoljára) helyesen küldi ki.
Így mikor az I2C buszra a write-al longintet írsz ki, akkor szépen elküldi a két bájtot.

A doksi szerint is előbb MSB-t majd LSB-t kell küldeni (6. oldal)

Ha jól értek akkor 2x egymás után köldöm el a címeket elsőnek a felső 8 bitet majd a következő sorba az alső 8 bitet.
i2c_wr(felso);
i2c_wr(also);
stb...

Üdv !

A mikroelektronika által gyártott mindenféle fordítótól óva intek mindenkit, mert amilyen kecsegtető a bennük előre megírt függvények mennyisége, annyira bugosak is a fordítók.

Tehát nagy valószínüséggel nem te csinálod rosszul.

A device az attól függ, hogy hogy van bekötve az eeprom.
Ha A0=0 ; A1=0 ; A2=0 akkor device=0xA0
Ha A0=1 ; A1=0 ; A2=0 akkor device=0xA2
Ha A0=0 ; A1=1 ; A2=0 akkor device=0xA4
Ha A0=1 ; A1=1 ; A2=0 akkor device=0xA6
Ha A0=0 ; A1=0 ; A2=1 akkor device=0xA8
Ha A0=1 ; A1=0 ; A2=1 akkor device=0xAA
Ha A0=0 ; A1=1 ; A2=1 akkor device=0xAC
Ha A0=1 ; A1=1 ; A2=1 akkor device=0xAE
Írás:
i2c_start();
i2c_write(device);
i2c_write(addrH);
i2c_write(addrL);
i2c_write(adat);
i2c_stop();

Olvasás:
i2c_start();
i2c_write(device);
i2c_write(addrh);
i2c_write(addrl);
i2c_restart();
i2c_write(device+1);
adat=i2c_read();
i2c_nack();
i2c_stop();

Kiváncsi vagyok mik ezek a "bug"-ok, mert én eddig még csak 1 problémával találkoztam, a longint konstans tömbnél.
Itt más a probléma, a mikropascal mintaprogram hibás, illetve nem erre az eeprom-ra íródott, ezért át kell írni.
Szerintem ez más programnyelvben is így van.

Én sem javaslom az ilyen cifra nyelvű fordítókat Mint a robotos PIC-es cikkemben is említettem, ezek nagyrésze sok jóval kecsegtet, de meg is szívod.
Pl. Mikropascalban ott egy csomó hardvernek a kezelő rutinja. De csak valami lefordított kód. Egy C vagy assembly fordítónál a külső kezelő unit is forráskód szinten van meg.
Tehát ott van benne az EEPROM kezelő kód, de nem forrás szinten, tehát ha bármi kell, akkor nem tudod belőle kihámozni, mert már bekódolt cucc. Ezzel szemben a fentebb említett fordítók pl. az eeprom kezelő unitot is forrás szinten teszik oda, hadd lássad, hadd javítsál bele!

Én is kíváncsi lennék, milyen bugokkal találkoztál? Vagy csak ez előítélet? Vagy valami ősrégi tört verziód van? Jöttök itt, hogy szar így, szar úgy, de nincs komoly indok, csak.

Nekem kétszer volt problémám, pedig nem kis projekteket csinálunk mP alatt (bár lassan megyünk a C18 és C30 felé...), írtam nekik e-mailt és pár órán beül ott volt a segítség. Ráadásul az egyik esetben én voltam a "barom"...

Ha pedig valami gond van a beépített rutinnal, a lehetőség megvan, meg kell írni... Bármilyen más nyelv alatt is ez a módjam ha kész kódot használunk.

Zárszónak csak annyit írnék, hogy először mindig az eszköz adatlapját érdemes megnézni, mert általában minden, ami szükséges, le van benne írva.

Bocs, hogy szóltam.

Nekem annyi volt, hogy minden faszán ment, aztán használni akartam a sprintf függvényt és tovább nem működött, el sem indult. Ha kivettem az sprinf-t akkor megint működött. Aztán kipróbáltam a fat kezelést és azzal sem működött (se kép se hang) csodák csodájára kiderült, hogy az is használja az sprintf függvényt.

Ezt a mikroc-vel sikerült átélnem, majd fórumozva derült ki, hogy nem csak a c-vel vannak gondok, hanem a pscallal is.

Való igaz, hogy nem tegnep történt, hanem kb másfél éve.
Elsőnek én is azt gondoltam, hogy amiatt van, hogy feltörtem. Majd kipróbáltam tisztán a demóval és az eredmény ugyanaz volt.

Mindenesetre csak figyelmeztetésnek szántam, hogy előfordulhat, hogy valami nem ugy működik vele, ahogy azt elvárnánk.

Zárszónak csak annyit, hogy nem tegnap kezdtem, a témát és adatlapról én is hallottam már, ráadásul nem szarom össze magam, ha valamit meg kell írni.
Ezért is nem használok ilyen csodafordítókat amiben "minden benne" van.
Az én fordítómban csak az ANSI függvények vannak benne gyárilag és ezen kívül minden függvényt sajátmagam készítek.

Ez a megoldás azért jobb, mert ha valami gond van egyből tudja az ember, hogy a saját kódjában hol kell beavatkozni.

De ebből az is következik, hogy embere válogatja, hogy kinek mi a jó.
És egyik módszer nem feltétlenül roszabb a másiknál.

Ja még annyit, hogy én alapból minimum 18 as családdal dolgozok, tehát lehet, hogy mivel akkoriban kezdtek az egyéb forditókban is megjelenni a 18-as család támogatásai, ebből kifolyólag is lehetett a probléma.

Vigyázat!
A mC és a mP teljesen más kódbázisra épül, ígaz vannak átfedések, de nem túl sok... Tessék csak megnézni: már az IDE is különbözik (és ezt nem a háttérszínre értettem ).
De való igaz, a FAT rutinnal régebben voltak gondok, bár én sohasem használtam a beépítettet.

Ha jól értettem a hozzszólásokat, akkor ez a programrészlet működőképes is lehet. Ha tévedek vagy valamit elírtam javítsatok ki! A célom az hogy 4752 helyre az adat változóba lévő adatot akarom beírni a 24c64-be majd kiolvasni az adatki változóba.

for x:=0 to 4752 do begin
//*** felső 8 bit, és alsó 8 bit********
felso:=(x div 256); //felső 8bit x változóból
also :=(x mod 256); //alsó 8 bit x változóból
//******* írás EEpromba ****************
i2c_start;
i2c_wr($A2);
i2c_wr(felso);
i2c_wr(also);
i2c_wr(adat);
i2c_stop;
delay_ms(5);
//******* olvasás EEprom-ból ***********
i2c_start;
i2c_wr($A2);
i2c_wr(felso);
i2c_wr(also);
I2C_Repeated_Start;
i2c_wr($A3);
adatki:=I2C_rd(0);
i2c_stop;
end;

Köszönöm a segítséget mindenkinek!
Már működik az írás olvasás is, a legnagyobb segítség a példaprogram volt.