For this project:
100MHz crystal oscillator (Yep, looks like I'll be trying this one-shot thing after-all)
74AC574 (D-Latches for one-shot circuits)
74AHC125 (TSSOP, blech... $0.29 YAY!) 5V-tolerant buffers for my inputs...
Mighta forgot a few things, I'll need a divider from 100MHz to something the AVR can handle... Also, forgot to look for 3.3V glue-logic (inverters+ANDs) needed for the one-shot... hopefully my vast assortment of 70's-80's TTLs can help out. (I'm currently using an S-series 74S51, and LS series (two) 74LS86's each rated for 4.5-5.5V at 3.6V, so we'll see!
Also, was up most of the night trying to figure out the one-shot circuitry... That part's easy. The hard part is how to interface it with the CS + CS_Enable arrangement I've got now.
This is an old design... Unfortunately, it means I need yet another pin, and I'm already pretty much maxed-out. (Glad I looked, though... the repeatedAccess pin is something I'd forgotten in my attempts last night... that may help).
//nCS_RepeatedAccess >------------------------------ // | ____ // ___ -| \ // -----------------\ \ | AND |->SDRAM_nCS // _____ | _____ | OR >--|____/ //nCS_OneShot >----|D Q|--+---|D Q|--|>o--/___/ // | | | | // --|>____| -|>____| // | | //SDRAM_CLK >---+-------------
So, e.g. when the nCS_OneShot output goes active (low) for 10 SDRAM clock cycles (one AVR cycle), the output of the OR gate shows it active for only *one* SDRAM clock-cycle. Good...
But, again, in this design, with the funky burst-writing-timing-scheme, this means I can't use nCS_OneShot to drive the associated DQ line to actually write the *data* on the nCS_OneShot pin.
It's hokey to describe, there are actual commands being actually fed, in real-time, from the AVR to the SDRAM. Then there are commands being written into the SDRAM's *memory*; these commands aren't *executed* they're just *stored*, and later they will execute on their own because of the fed-back DQ->Command/Address pins.
So, I guess, a "Write Command" sent to the SDRAM is different than a "command written" into the SDRAM.
...and I need a one-shot circuit for the various chip-select lines *as well as* the DQM lines. The CS lines *also* need to have *non* one-shot access, as described. Likewise, the DQM lines need non-one-shot access to allow the "Free-Runner" to output its data. So, if I use the "nCS_RepeatedAccess" method, as shown above, then that means I need an additional.. 5? pins?! I have *one*. And that'd be disabling the UART.
Further, it just occurred to me, in sdramThing3.0 (the functional version, now, before the one-shot gets added), the CS pins must also *switch direction*. Yeah, this one-shot won't do that. So, of course, I could add another buffer with an output-enable... but then we need *6* pins (possibly 8?)!
I think I can multi-purpose some pins, maybe reduce some logic, It's plausible... Maybe, even, without needing to use a demultiplexer.