Negative RC delay with microcontroller

[ManlishPotato]

Hi everybody!
I'm (trying) to build a programmer for at28c EEPROM, for this i need a between 100ns - 1000ns *negative pulse to the write enable pin to initiate a write cycle. Now one could simply pulse the pin on the MCU in software with a 1μs delay in between, but using an RC delay would probably be better. I don't have access to a oscilloscope to confirm this type of thing anymore.
In the schematic bellow i theoretically get the graph that shows a delay of about 170ns until the voltage goes above 0.8V. I could not figure out a way to do this with a normal off/on pulse from the MCU. I would instead have to after pulling to ground then make it go Hi-Z so the cap can discharge.
So in avr-c it would look something like:
DDRB |= (1<<PORTB1); //Output PB1
PORTB &= ~(1<<PORTB1); LOW PB1
DDRB &= ~(1<<PORTB1); //Hi-Z PB1

instead of:
DDRB |= (1<<PORTB1); //Output PB1
PORTB &= ~(1<<PORTB1); //LOW PB1
PORTB |= (1<<PORTB1); //HIGH PB1

Is the circuit and pulling the output Hi-Z a hacky way to do it? The only other way i can think of doing it is to add a transistor that has the base connected to the MCU, but I'd rather not add to much complexity.
For reference the microcontroller of choice is a atmega328_U.
*By negative pulse i mean that the write enable is active negative and needs to be normally HIGH, and then pulled low 0V-0.8V when initiating write.
If you have any notes I'd be happy to hear them!
//Benjamin

[Siwastaja]

I'd be interested in hearing the thought process that made you think using an analog RC circuit hack for digital communication between two digital ICs, one which is freely programmable microcontroller, is a "better" idea?

The obvious solution is to do it in software.

100-1000ns is just a few clock cycles (or possibly just one) so you don't need to waste time in a long busy loop, or use interrupts.

[ManlishPotato]

I guess i was thinking that writing a pin would take about 2 microseconds and that it would be unideal way to turn a pin low in a 2 microseconds window, have a desired delay, and then turn the pin back high. Like I'm assuming the transition doesn't take 2 microseconds, but there may or may not be about a 1 microsecond delay until the next command is executed. Isn't that bad? I mean haven't you already gone over the time limit right there?

[Siwastaja]

On AVR, modifying a PORT register to change some output pin value takes approx. 1-5 clock cycles, depending on the part and IO register.

In most cases, it's 1 cycle on small Tiny AVRs, or 2 cycles on some other parts, when the compiler can use SBI/CBI instructions. In larger parts, some ports (like PORTE) do not fit into the addressing of SBI/CBI instructions and need to use read-modify-write pattern. Even then you can save time by avoiding |=, &= operations and instead just write the full register every time (you just need to keep track what values you need in other outputs of the same port so that you don't accidentally change them to wrong states). If you do this, it's back to 2 cycles again.

But I'd hazard a guess your use case makes the compiler use SBI/CBI so |= and &= is fine.

If you run at, for example, 16MHz, then 2 cycles would be 125ns. This would fit in the 100...1000ns specification right away. If this is an AVR part with 1-cycle SBI/CBI, you can add a single NOP instruction between the accesses. In avr-gcc C:
__asm__ __volatile__ ("nop");

Because the PORT registers are qualified volatile in the headers, as is that inline assembly part, the correct ordering is guaranteed.

Verifying with scope is a good idea, if you have one or can access one.

[ManlishPotato]

Ok that makes sense! I am indeed using a 16Mhz crystal so that will work. It's not always obvious how long things actually take, so it's easy to get a wrong scale of things. I wanted to properly stay within the datasheet limits, and your answer is obviously better. Thanks for a detailed and well written answer!

[Kleinstein]

The AVRstudio has a quite accurate simulator. One can do single stepping and measure the time in the simulation. If really paranoid one would disable interupts for the critical part.
100-1000ns is quite a wide window and chances are good that C code with not extra delay would work with a 16 MHz clock.

[SiliconWizard]

Yeah, same remark as above, I don't know for sure why you think it's a better approach than in software.
I agree that it would seem to allow a "fixed" delay - somewhat - not dependent on software execution - but it would come with a few drawbacks. To list a couple: extra components, of course, then an actually less accurate delay - would depend on tolerance of passives, which is never very good, especially with capacitors, and on actual thresholds of the input pin, which depends to some extent on each individual IC, then all that depending on temperature as well...

All in all, the software solution is much simpler here with fewer drawbacks, especially on parts as simple as an Atmega, with no cache and a pretty predictable execution time for instructions. Only thing to possibly care about as said already are interrupts, but that's all.

[ManlishPotato]

I picked a 10nF X7R ceramic capacitor with it's superior temperature stability. I became more aware of this after noticing that a ceramic capacitor seemed way out of spec when measuring it, and that when i stopped holding it with my fingers in went into spec. Anyway like i said, i was under completely false assumptions on the time scale. I was just thinking that matching a capacitor with a resistor would be easier than trial and error, doing it in software not having access to a DSO. That said a code soloution for such would look something like this no?

Code: [Select]

//Setup
sei(); //Set I-bit
DDRB |= (1<<PORTB1); //PB1 output
PORTB |= (1<<PORTB1); //PB1 HIGH

uint8_t oldSreg=SREG; //Save status register
cli(); //Clear I-bit

PORTB &= ~(1<<PORTB1); //PB1 LOW
asm volatile("nop");
asm volatile("nop"); //16Mhz clock - 62.5ns * 2=125ns > 100ns - time limit
PORTB |= (1<<PORTB1); //PB1 HIGH

SREG=oldSreg; //Restore status register
Where in avr studio is this simulator? You can also of course use something like an Atmel Ice and debug it. Don't know if timings and such are accurate then.

[bson]

Which AT28C chip is this?  WE# would normally have a minimum time, not an exact duration.  Maximum write cycle time is often on the order of ms.

[ManlishPotato]

It's the at28c256. In the datasheet that i have it only lists a minimum of 100ns and no maximum. And yet i have seen at least on video a max limit of 1000ns. In any case I'm assuming that it would decrease life expectancy if you have a write pulse that is too long. I don't know it was just a arbitrary time limit that i put down to select resistor and capacitor. I have had a ROM chip before that suddenly stopped working, so i wanted to take out as many unknown variables as possible.

[SiliconWizard]

/WE is just a write enable, it doesn't control the timings of the write cycle itself. The DS says:

A low pulse on the WE or CE input with CE
or WE low (respectively) and OE high initiates a write cy-
cle. The address is latched on the falling edge of CE or
WE, whichever occurs last. The data is latched by the first
rising  edge  of CE  or WE. Once  a byte write has  been
started it will automatically time itself to completion.

[bson]

Well, if you do want to use an RC delay (series R, shunt C), the C charge voltage is:

Vc=Vdd*(1-e^(-t/RC))

If we set Vc=0.5*Vdd we get RC = 1.4427*t.

So if you want a 1μs rise time from 0 to 50%, you need RC=1.4μ.  Like a 0.01μF cap and R=147Ω.

But in general you're probably better off just inserting a few NOPs.  It's not enough to just insert an RC; if you toggle it too fast it just ends up suppressing the write strobe altogether - and you still need to time it.

[james_s]

This is all moot, the specified value is the *minimum*, there is no maximum, at least within reason. There is no reason to worry about precise timing there, just make it long enough, but not ridiculously long.

[ManlishPotato]

Well i used that formula to calculate the resistor and capacitor needed to get a 170ns delay until it reaches 0.8 volts which is the thresholds low voltage for TTL. But like said the software solutions is better in this case. That said am i wrong in that it would decrease lifetime? I mean ideally you'd have a delay that's as close to the minimum requirement as possible. 

[james_s]

Why would it decrease lifetime? The write enable is just a trigger, the precise timing is generated internally within the chip. Notice that the rated number of write cycles in the datasheet does not factor in the timing at all.

[ManlishPotato]

Yeah ok that makes sense I guess.

[SiliconWizard]

Yeah ok that makes sense I guess.

Well, I quoted the part of the DS that explains how WE works, and how the write cycle is self-timed.

Actually, this particular part is even more telling IMO:

The address is latched on the falling edge of CE or
WE, whichever occurs last. The data is latched by the first
rising  edge  of CE  or WE.

Which should imply that the actual write cycle doesn't start until WE goes back high in your case, making the time it stays low irrelevant? (Except that the longer it is and the longer the time overhead.)

Additionally:

Following the initiation of a write cycle, the device will auto-
matically write the latched data using an internal control
timer.

Until data is latched, nothing will happen as far as the actual write is concerned.

Do not believe everything you see on blogs or Youtube. But if you still think the person making the claim had a point and could be trusted, could you in this case link their video so we can see for ourselves?

[ManlishPotato]

I heard this from a Ben Eater video:
https://youtu.be/K88pgWhEb1M
At 44:16 he points out the time limit in the datasheet.
That said i now realize:
This is a different chip so doesn't really apply.
It was just speculation on his part.
I was really just trying to take out all the unknown variables, and thought the MCU would be too slow to fit within the theoretical time limit. But clearly i was wrong.

[SiliconWizard]

Thanks for providing the source. Indeed, the chip he was using is not the same and its datasheet effectively mentioned a maximum time for the write pulse width, as opposed to the chip you're using.

Note that he was using an AT28C16, which has a much shorter write cycle time too. But while its DS states a max tWP, it doesn't explain why, and the rest seems to be similar to the AT28C256.

Thinking about it a bit more, tWP probably has zero effect on the internal write cycle itself as it's self-timed, so no effect whatsoever on "life expectancy", but the key point here is that the write cycle is triggered by the *falling edge* of the write pulse while data is latched on the rising edge (at least that's what I read in the DS). What it means is that there's probably indeed a max tWP, if, as we can guess, the internal timer starts on the falling edge. If the rising edge comes in too late, then the write cycle will have passed with no data latched and probably the write will be internally canceled, so what I think is, the worst that could happen is a missed write, not any early failure. But then after this further thought, your concern doesn't seem as invalid as it first looked. It raises a question that I don't have a clear answer for. Still very likely that a couple µs are nothing to worry about in your case, but still seems to be some info missing in the DS about tWP.

[abyrvalg]

IIRC, AT28C has some write sequence timeout (you need to do several fancy writes in a sequence within some time window as a measure to prevent spurious writes), so the maximum tWP can be related to this (i.e. a pulse longer that sequence timeout could not work).