Timing wissen/schrijven

Ik probeer een EEPROM te schrijven van Philips, maar ik doe volgens mij iets niet goed met de timing. De schema's zijn heel vaag, en de tijdsindicatoren zijn slecht omschreven.
Welke wis-methode kies ik? Met CE of WE?

Zou iemand een de wis en schrijfcyclus (naar keus de CE of de WE) op de volgende manier kunnen omschrijven:
CE hoog
WE hoog
1 µs wachten
adres instellen
OE laag
MODE laag
2000µs wachten
enz.

Wat vreemd is dat hoe de grafiek rechts eindigt, niet strookt met hoe die links begint. Zit er een stuk overlap in?

In code heb ik nu dit, ik probeer de hoog/laag sequentie uit de grafieken te volgen, maar dat geeft bij wissen nog een sporadische E of B tussen de F-jes bij uitlezen naar een HEX editor, en bij het schrijven is ongeveer 1/3e goed.

for (uint32_t n = OFFSET; n < uint32_t(ROMSIZE)*128+uint32_t(OFFSET); n++) {
    // schrijf adrespinnen
    PORTF = uint8_t(n % 256);
    PORTK = uint8_t(n / 256);
    uint8_t b=0xFF;
    if (modus==0){
      // wis data (CE controlled)
      PORTL=0xFF;
      digitalWrite(MODE, HIGH);
      digitalWrite(WE, LOW);
      digitalWrite(OE, HIGH);
      delayMicroseconds(2);
      digitalWrite(CE, LOW);
      delayMicroseconds(2);
      digitalWrite(MODE, LOW);
      delayMicroseconds(2);
      digitalWrite(CE, HIGH);
      digitalWrite(OE, LOW);
      digitalWrite(WE, HIGH);
      delayMicroseconds(2);
      digitalWrite(CE, LOW);
      delayMicroseconds(4000);
      digitalWrite(CE, HIGH);
      digitalWrite(MODE, HIGH);
      digitalWrite(OE, HIGH);
      digitalWrite(WE, LOW);
      digitalWrite(CE, LOW);
      delayMicroseconds(2);
      digitalWrite(MODE, LOW);
      digitalWrite(CE, HIGH);
      digitalWrite(OE, LOW);
      digitalWrite(WE, HIGH);
      delayMicroseconds(2);
    }
    else {
      // schrijf data (CE controlled)
      digitalWrite(MODE, LOW);
      digitalWrite(WE, LOW);
      digitalWrite(OE, HIGH);
      delayMicroseconds(2);
      digitalWrite(CE, LOW);
      delayMicroseconds(2);
      if (n%64>2) b=tekst[n%64-3];
      else{
        if (n%64==0) b=byte((n/6400)%10+48);
        if (n%64==1) b=byte((n/640)%10+48);
        if (n%64==2) b=byte((n/64)%10+48);
      }
      PORTL=b;
      digitalWrite(MODE, HIGH);
      delayMicroseconds(2);
      digitalWrite(CE, HIGH);
      digitalWrite(OE, LOW);
      digitalWrite(WE, HIGH);
      delayMicroseconds(2);
      digitalWrite(CE, LOW);
      delayMicroseconds(2000);
      digitalWrite(CE, HIGH);
      digitalWrite(MODE, LOW);
      digitalWrite(OE, HIGH);
      digitalWrite(WE, LOW);
      digitalWrite(CE, LOW);
      delayMicroseconds(2);
      digitalWrite(CE, HIGH);
      digitalWrite(OE, LOW);
      digitalWrite(WE, HIGH);
      digitalWrite(MODE, HIGH);
      delayMicroseconds(2);
    }
  }

[Bericht gewijzigd door blanka op (68%)]

Niet eenvoudiger een I2C FROM te nemen? Bijvoorbeeld deze. Geen zorgen meer maken over het aantal read/writes (1014) en 400kHz of indien gewenst 1MHz.

Welke processor gebruik je en welke taal?

Op vrijdag 30 mei 2025 22:12:12 schreef buckfast_beekeeper:
Niet eenvoudiger een I2C FRAM te nemen? Bijvoorbeeld deze. Geen zorgen meer maken over het aantal read/writes (1014) en 400kHz of indien gewenst 1MHz.

Welke processor gebruik je en welke taal?

Het is voor het maken van ROMs voor diverse vintage computers: betere tekenset C64, homebrew Atari 2600 cartridges, Roms voor Tandy model 100, dat soort werk, deze zijn heel goedkoop en pincompatible met de huidige EPROMs.

Waarom het programmer-wiel opnieuw uitvinden?
Er zijn toch redelijk betaalbare programmers te koop waarmee het programmeren veel makkelijker gaat?

Op zaterdag 31 mei 2025 00:04:24 schreef Bobosje:
Waarom het programmer-wiel opnieuw uitvinden?
Er zijn toch redelijk betaalbare programmers te koop waarmee het programmeren veel makkelijker gaat?

Toch, anders stel ik de vraag wel aan een gare AI bot op Ali. Altijd leuk om wielen opnieuw uit te vinden, we moeten de prefrontale cortex actief houden tussen de schermzombies op straat.
En ik had al een uitleesmodule werkend op mijn Arduino MEGA, dus aanpassing software zou moeten volstaan.

[Bericht gewijzigd door blanka op (13%)]

Even voor de goede orde. De bedoeling is (voor write, CE) dat je ADDRESS, MODE, OE, WE en eigenlijk ook data klaarzet, dan CE een pulsje geeft. Klaar.

Als je dan de grenzen gaat opzoeken is het datasheet heel exact met allerlei setup en hold tijden, maar de data wordt op de opgaande flank van CE gesampled en moet van <kort er voor> tot <kort er na> stabiel en de-waardie-die-je-wilt zijn. Hetzelfde geldt voor het adres en de WTF moet er gebeuren bitjes, maar dan ten opzichte van de CE laag flank.

De schuine strepen in het timing diagram betekenen niet dat je de boel MOET veranderen, alleen dat de werking van de chip niet beinvloed wordt door de waardes van de draadjes op dat moment.

Ik zou voor leesbaarheid een delay_ns schrijven die als argument dan bijvoorbeeld MAX(TAS, TOES, TCS) neemt. De implementatie is dan delay_microseconds (1)... (of iets beters als je later de boel sneller wil maken).

Na afloop is het enige wat MOET is dat CE weer hoog is. TWPH is de beperking: Wanneer mag je op z'n vroegst weer een volgende actie starten? F-ing snel dus. Geen beperking als je het met een arduino doet.

[Bericht gewijzigd door rew op (10%)]

En heel belangrijk is dat je de WRITE en ERASE delay (wacht) tijden in acht neemt. Deze tijden kosten enkele ms per WRITE of ERASE actie.
Het programmeren van de volledige chip kost circa 21s aan tijd.

Die heb ik er in zitten, alleen lastige is in uitleg, de tijd wordt voor het geheel gegeven. De tussenstapjes zijn niet nader omschreven. Dat zijn nu die 4000µs (3-5ms in datasheet) en 2000µs (1,5-2,5ms in datasheet)

[Bericht gewijzigd door blanka op (22%)]

Op maandag 2 juni 2025 08:39:52 schreef blanka:
Die heb ik er in zitten, alleen lastige is in uitleg, de tijd wordt voor het geheel gegeven. De tussenstapjes zijn niet nader omschreven. Dat zijn nu die 4000µs (3-5ms in datasheet) en 2000µs (1,5-2,5ms in datasheet)

Daar moet je dus altijd de maximum tijd wachten: minimaal 6ms voor erase en minimaal 3ms voor write.

Kijk maar op pagina 6 van je datasheet; de "erase cycle time" en "write cycle time"

Strict genomen mag je daar een paar honderd ns vanaf snoepen omdat de tijd om een commando te geven erbij zit, maar dat is gemiereneuk in de marge. Als je het wil optimaliseren kun je een datalijntje uitlezen of de chip al klaar is.

Verder is belangrijk (is nu niet goed in je code) dat je (als je write en erase CE-controlled doet, wat het makkelijks is) dat address, data, WE/OE/MODE ALTIJD stabiel zijn als CE laag is.
Dus:
Adress instellen
Data instellen
OE/MODE/WE instellen
(kort wachten, 10ns, (address setup time))
CE laag maken
Wachten (1us oid) (CE pulse width, kan korter)
CE hoog maken
Wachten (6 milliseconden!)

En dan de volgende byte

Op maandag 2 juni 2025 08:39:52 schreef blanka:
De tussenstapjes zijn niet nader omschreven. Dat zijn nu die 4000µs (3-5ms in datasheet) en 2000µs (1,5-2,5ms in datasheet)

Zoals blurp al zegt, je moet het maximum aanhouden. De typical tijden gelden als je gaat pollen "of ie al klaar is" (datasheet: blz 8 onderaan). Zeker bij dit soort dingen: Eerst heel robuust veel marge nemen. Dan kan je later als je vind dat het programmeren te lang duurt altijd nog gaan optimaliseren. Dat pollen is ingewikkeld, eerst maar eens gewoon de opgegeven max wachten.