Hur identifiera I²C EEPROM programledes?

[Icecap]

Förklaring:
Använder EEPROM som sitter på en I²C bus tillsamman med en DS3232 RTC. Designen är inte öppet för ändring!

Men av ren nyfikenhet beslöt jag mig för att kolla priser osv. och det visade sig att om jag väljer ett 64kB EEPROM istället för det 32kB vi använder nu blir det billigare per krets. På kretskortet är det plats för 4 st och man kan piggy-back'a upp till 8 st (vilket jag testade idag).

Men kan jag få 64kB istället för 32kB OCH spara 1:10 på köpet är det ju inte mycket att prata om!

MEN - då kommer problemen: Deras masteradress är den samma så hur kan mjukvaran hålla koll på vilken det är?
Jag vill inte gärna blanda typer (32kB & 64kB) men jag vill gärna att programmet kan identifiera vilken typ det är. Det skiljer på write-page storlek (64/128 B) och såklart addressomfång.

Enl. databladet struntar 32kB i A15 varför jag får ACK oavsett, resultatet blir dock att den "wrappar" runt. Så enda sättet jag ser att jag kan lösa det på är att ha en rutin som rensar EEPROM'en, skriver ett värde i EN adress och kolla hur många gångar det "återuppstår" när det hela läsas ut.

Gör jag det rätt kan rutinen jobba med "alla" storlekar från 256B.

Men det känns som ett ganska dåligt sätt att göra allting på, man måste skapa en tabell (som måste sparas i EEPROM) över installerat och testat minne och adderar man minne ska rutinen "fortsätta" och det är totalt sett ingen bra lösning.

Javisst, jag kan hårdkoda värden och sedan anpassa från projekt till projekt - men det sätter käppar i hjulet för bakåtkompatibiliteten.

Så är det någon som har löst det eller hittat en lösning skulle jag bli tacksam för tips.

EDIT: Hittade en AN från µchip som anger att sättet det går på är att skriva ett identifierbart mönster i adress 0 (& 1...) och sedan söka igenom hur "snabbt" man hitta det mönster.

[Swech]

Hur upplever systemet minnet då du kan addera minne efteråt?
Är det ett enda linjärt minne som eftersträvas eller blockindelat?
Kommer din testadress även att kunna användas av mjukvaran till något "vettigt"
eller kan den reserveras till att detektera minnestyp?

Swech

[Icecap]

Problemet är att OM jag använder olika EEPROM-kretsar måste jag anpassa kommunikationsrutinen med avseende på Adressbit 15.
Jag har ingen problem med att ena kretsen har pagesize på 64 och den andra har 128 - man ska man ändå pilla...

Problemet är att när jag startar programmet går det ut och kolla om varje adress svarar (stoppar vid första icke-svar), varje krets som svarar räknas till 32kB och detta adderas i en variabel. Den variabel används sedan som definition av hur mycket EEPROM-minne som finns och styr då den insamling av statistik som sker.

Men om jag i ett gammal projekt har x antal 32kB och i nya projekt har x antal 64kB blir detta sätt fel.

Själva minnesplatsen är linjär.

Och detta gäller även om jag använder en 64kB EEPROM, den enda skillnad är att A15 används i 64kB-kretsen medan den sorteras bort i mjukvaran för närvarande.

[Micke_s]

En variant är att skippa första platsen när du kör 64k. Svarar första så har du 32k minnen. Svarar inte första men andra så är det 64k.

Problemet är om första minnet ger upp

[Icecap]

Micke_s: nu hänger jag inte med... Förklara gärna.

Oavsett om jag har ett 32kB eller ett 64kB EEPROM kommer de att svara på de 64kB de täcker. Den enda skillnad är att 32kB "speglas" utan möjlighet att få någon flagga om det.

Det börjar luta åt att skapa en tabell som börjar på plats 0 och sedan beskriver vilken EEPROM som är monterat. Då får jag acceptera att det är ett par bytes som går åt för detta.

[lillahuset]

Ett högt pris att betala!

[Icecap]

Ja, det är det faktisk. Det blir en del program för att kolla storleken och antal kretsar.

[Swech]

Du bör väl anta att monterade minnen är 32kb
De extra 32kb per minne lägger du sist i minnesträdet.

Så första max 8 platserna är alltid 32kb
Nästa max 8 är extended 32kb

Vad gäller att verifiera om det är 32kb eller 64kb
läs adress 0, läs adress 32768
ej samma -> 64kb

Samma -> invertera data på adress 0
läs adress 32768
Samma -> 32kb , ej samma -> 64kb
återställ inverteringen.

Swech

[Micke_s]

Jag tänkte om man bestyckar kortet med 32k så monterar man chip 1, 2, 3...n
kör man med 64k så bestyckar man 2, 3, 4...n.

Programvaran testar att läsa på plats nr 1, om den hittar eeprom så är det 32k den ska jobba med.
Vid miss så är det 64k och addressen börjar på nr2.

[Magnus_K]

Får man fråga vilka EEPROMs du använder dig av?

[MagnusK]

Kanske är fel ute men skulle det inte vara enklast att ha en bygling för 32K/64K minnen och sen
en dip-switch som man sätter binärt antal kretsar... lätt att läsa av och tar inte mycket kod.

Gäller ju iof bara om man inte blandar minnen.

Edit: Såg att designen inte kunde ändras... aja..

[Icecap]

Magnus_K: Den nuvarande är µchip 24FC256, den tilltänkta är CAT24C512 från ON semiconductor.

MagnusK: Jag förstår din tanke - men bygling? Aldrig! Våra projekt är oftast i ett otrevligt miljö (skakningar, temperaturskillnader, fukt, damm osv.) och alla mekaniska saker kommer att glappa med tiden så jag lärde mycket tidigt att inte ha någon form av socklade kretsar, byglingar, DIP-switchar eller liknande med i designen.

Detta gjorde att våran fel-frekvens på utrustningen vi hyrde ut sjönk något i hästväg. Våra turer på 55 mil för att trycka en krets på plats i en sockel näst intill försvann och plötsligt hade vi en vinst att jobba med.

Och att låta bli att montera kretsar och liknande är ju bara ett skämt hoppas jag. Grejen er ju att (kunde) få MYCKET minne, inte att öka lita lagom.

Men resultatet blir rätt säkert att jag reserverar ett par (4 st) bytes i inställningarna (som alltid börjar på adress 0) som beskriver kretsarnas storlek. Kommer nog att skriva en liten rutin som läser adress 0-3 & adress 32k, ändrar adress 0-3 innehåll och läser adress 32k igen och ser om det är skillnad från förra läsning. Är det skillnad vet jag att det är 32k krets, är det inte skillnad är det 64k krets - och då skrivs koden för 64k i adress 0-3.

Men om adress 0-3 redan har koden för 32k alt. 64k accepteras det bara och räkningen sker på det valda vis.

[Magnus_K]

Med risk att göra bort mig.

Skulle man kunna nyttja page "wrap around" på följande vis?

• - Skriv till plats 0
  - Skriv till sista adressen + 1 på första page:n för 32kB-minnet
  - Kolla om det du skrev på plats 0 ändrats. Ja = Minnesstorlek 32kB, Nej = fortsätt
  - Skriv till sista platsen + 1 på första page:n för 64kB-minnet
  - Kolla om det du skrev på plats 0 ändrats. Ja = Minnesstorlek 64kB, Nej = Felaktigt?

Ni kanske diskuterat detta redan och bara jag som inte förstått...

[Micke_s]

Fick uppfattningen av första inlägget att det var för spara pengar i bom:en.

[Icecap]

Ja, det är inte så enkelt faktisk. Hade gärna hittat en "läs en såhär sekvens" så att man kunde läsa information om kretsen - men det verkar inte finnas.

Så resultatet blir att jag på adress 0 förväntar en DWORD med ett visst bitmönster. Det bitmönster varierar på en bit om det är 32k eller 64k.

Så när systemet startar och det initierar EEPROM läsas dessa 4 bytes från adress 0 och 32k, båda sparas undan temporärt.
Om inte de motsvarar endera av de valda mönster skrivs mönstret för 32k på adress 0.

Sedan läsas adress 32k och det kollas om mönstren passar och det inte redan var det mönster.
Har det inte ändrats skrivs mönstret för 64k - och sedan ska jag fundera lite på om man ska flytta innehållet i resten av EEPROM'et 4 platser upp eller bara aktivera en "Set Default"-funktion.

Då jag "alltid" har mina inställningar liggande först i EEPROM'et blir det alltså till att när systemet läser Config in i RAM kan man omedelbart läsa om kretsarna är på 32k eller 64k om den har varit igenom en start innan.

Så när man bygga nya system blir det enkelt att sköta, det klarar sig mer eller mindre automatisk.