-
obviously on hold...
04/05/2015 at 23:42 • 0 commentsSo there were brainstorms...
But, obviously, development has been put on hold.
I get that 133MHz might require some better-designed circuitry, maybe a custom PCB; ground-planes, shielding, shorter traces, whatnot.
But I'm kinda surprised it seems to stop-dead at >30MHz.
The *method* of failure seems... unexpected.
Actually, now that I write this, it occurs to me that I had a similar failure, briefly, AT 30MHz. It seemed related to having the LCD attached, but experiments with different power-supplies, removing the LCD, and more, got it working, then putting it all back together *the way it was when it seemed LCD-related* still worked. So, maybe there's something there... the noise of the backlight-inverter...? Thermal effects on propagation-delays...?
Regardless, the actual *method* of failure seems... weird. It basically goes from stable/predictable to completely random. And, I can't seem to figure out any potential failure-point that would cause *complete randomness*. E.G. Sure, maybe, if the Chip Select multiplexer is too slow, the Chip Select signal might not reach full-on, which would result in writes that don't write, and reads that read floating pins. (Note that *delayed* chip-selects have been accounted-for in software). Sure, non-enabled-chip-selects would *seem* to result in utterly-random reads, as the pins would be floating... Then, consider, even if the read *command* was completely missed, the read process still continues, the data it should be receiving shouldn't be completely random, it should be the floating-values on the data-pins... Again, consider, it has been found in previous experiments, that when the data-lines are allowed to float, they tend to retain the last value written to them... (which would be and HAS BEEN the Read Command and its associated address, due to the fact that the data-lines are directly-connected to the command/address lines). That "Has Been" was at *lower* clock-frequencies, so seems reasonable to think it would be even *more* likely to store those values at *higher* frequencies... as... I believe it's capacitance that's causing the "floating" pins to retain their values...
And, unrelatedly: one must also consider that the memory has been holding previous values despite power-down, for *minutes* at a time, So read-commands that *do* go through (even if write doesn't), then, should be getting *something*.
I guess there're a few potentials in here... worth further consideration.
And then, the apparent link with the LCD display's being connected...? I dunno.
It's not like I'm jumping from 30MHz to 100MHz... these oddities appear at 40MHz, only 1/3rd faster. And even considering 1ns/6in of wire... worst-case-scenario we're talking differing propagation-times of 1ns due to wiring... routing some signals through other circuitry, while others go straight to the SDRAM. (neglecting the circuitry's delays, briefly, for this mind-experiment, see below). Then, of course, there's noise induced on nearby wires... it may *look* like a rat's nest, but in fact, I did consider the routing of the wires such that they shouldn't have much room for crossover.
These sorts of things, generally, in my experience, can lead to seeming randomness. But, they've been considered. And even the one-shots... even if *they're* too slow (which is possible) I still don't see *completely random* as the mode-of-failure.
So, it's on hold.
-
one shots... revisited.
03/31/2015 at 11:36 • 0 commentsduh. seriously. duh.Even without the cleverness of the single-instruction one-shot... why didn't I think along these lines...?
Of course, I should['ve] recall[ed], that the whole point of my AVR-LVDS-LCD project is to use the PWM signals (with PLL) for *exactly* the sort of purpose needed in *this* project for one-shotting.
Well, there are a few limitations:
- the PLL (on devices that have it) only works with the internal R/C oscillator. How would I generate the SDRAM's clock? (there's no PLL output)
- the only unused chips I have laying around with PLLs don't have enough pins for the SDRAM (and, does the biggest, even? The AT90PWM316?)
- the board was already soldered-up.
That said... Something could've been done, likely... with the PWM316, maybe...? It's an EXPENSIVE chip, though, last I checked.
Or... I might've been able to replace all that one-shot logic with two Tiny85's or a Tiny861, which I do have in-stock.
Plenty of thoughts... but here's one anyhow:
The SDRAM clock could be generated by a dedicated PLL-based timer set to FastPWM-mode with E.G. a Match-value of 1 and a Top-value of 2... THIS IS HOKEY without knowing your chip:
Different PLL-based devices actually act differently with low match/top values... (I did a lot of experimentation with this in AVR-LVDS-LCD). E.G. one device matches *after* the matching-count is *left*, another matches *when* the matching-count is *entered*. Further, because of this, some devices *can't* have a match/PWM value of 1 timer-count... In that device it's 0,2,3...
So, if I recall correctly, some devices could actually toggle, with Fast-PWM, at 1/2 the PLL frequency (so 4x the AVR clock?), whereas others no faster than 1/3rd, which wouldn't be square. That, then, driving the SDRAM, would limit the SDRAM/AVR clock-ratio (which, at some point, I really am hoping to bump up to 4:1 maybe higher... Though, it's not the ratio that's important, but the overall SDRAM clock-speed... and 30MHz, now, seems to be the limit... I've had several of the PLL-Based AVRs' PLLs running at ~128MHz, which even at 1/4th--for the sake of squarifying the PWM/SDRAM-Clock output--would still be faster than I'm currently getting...).
But, basically, this method probably would've removed the necessity for *all* the additional circuitry in sT4.0 (one-shots, clock-divider... even the crystal-oscillator/buffer).
Anyways, it's funny this concept hadn't even come up as an option when thinking about this project... seeing as how much time I spent on something not unlike it not even a year ago.
-
further deprocessorization brainstorm... + non-sequential free-running
03/30/2015 at 17:53 • 1 commentAs an aside... I've been pondering the possibility of ways to do further deprocessorization
E.G. windowed-repeat could occur sans-processor with the addition of one more multiplexer... Plausibly another chip-select one-shot circuit. (Or, possibly, just a rewiring of the other half of the 7451 multiplexer already in-use on the Free-Runner's chip-select? Or, possibly2.0: There's still *some* unused memory... maybe after the free-runner's LCD-update, the windowed-repeat commands could be stored... no multiplexer necessary? no change in circuitry at all?)
I have no idea *why* exactly... I guess it's the sort of mental-challenge my mind is suited-for at the moment.
Well: "possibly2.0" lends itself toward a feature I'd otherwise not found a particular use for...
Free-Running, as it stands, basically only goes through every page *sequentially*. The only place where it *doesn't* is at the very end of the LCD refresh, where it jumps back to the beginning. It doesn't exactly *wrap* to the beginning, as there is, technically, unused memory. But, otherwise, it's basically just outputting the memory sequentially.
There's no *need* for it to free-run sequentially. And, in fact, there's no *need* for the "Free-Runner" and "Side-Kick" to even free-run in the same addresses (right?).
As I said, I just haven't yet come up with a particular use for another, more complex, jumping-scheme.
So, since I'm on this thought-path (all of which is new, as of this writing, except for the first two sentences of the "E.G." paragraph)... why not some hypothesizing...
...
Rough-calculations and sketches suggest "possibly2.0" is only possible with quite a bit more memory. Disregarding horizontal and vertical blanking-times on the LCD... 1024x768*7(bits per LVDS transaction) is nearly 55Mb, and my chips are 64Mb (right?)... or 128? Maybe, then...
... Well, I might need to do some more thinking along these lines. I dig the idea it might be possible with Zero hardware-modification. Though, too, v3.0+ has shown that I'm somewhat intrigued by just how much can be accomplished by simple logic, sans processor. OTOH, at what point does it become less about pushing the memory's capabilities to the limit and more about something like making a custom processor out of (mostly) logic gates...?
We'll see where this goes.
------
OTOH, now that I think about it, the non-sequential jump-scheme is something I'd been contemplating *for the side-kick*
As it stands: The LCD and Sample/Repeat-scheme are handled in the same fashion, sequentially, as described earlier. That means, some of the samples are actually stored during the LCD's H/V-blanking-periods and therefore aren't seen on the LCD. (Though, they would be seen on the 'scope). In one of my recent photographs three serial-transactions are visible near the edge of the screen, selected by the cursors. In fact, there were five serial-transactions between the cursors (as seen by the 'scope), two of which must've been during the horizontal-blanking period.
...The reason: The "Free-Runner" and the "Side-Kick" use the same addresses in their two separate groups of memory.
Again, this needn't be the case... Though the math gets quite ugly.
There would have to be two separate sets of commands for the Side-Kick... Currently the *addressing* is shared by both the free-runner and the side-kick, and the latter in *both* sample and repeat modes.
The side-kick would need two separate addressing schemes based on whether it's in sample/windowed-repeat mode or LCD-Refresh-mode. ...another multiplexer.?
... Plausibly I could use that otherwise-unused-multiplexer on the Free-Runner, instead... Plausibly keep the Free-Runner's and Side-Kick's addressing-schemes the same, but include two different addressing-schemes *for both*...? But, still... more circuitry.
...
And then, in the realm of ugly-math...
The actual commands would have to be offset. E.G. currently the "read-next-page" command occurs near the last-used column in the page (a couple short of the last column, due to the CAS Latency).
But if we had two separate sets of commands for sample-stuff vs LCD-stuff, then the ... but wait!
The "read-next-page" command isn't actually "read next page" it's merely "read the selected page" and page-selection is another command entirely, which needn't be aligned anywhere in particular... so then the "read selected page" command could be used for *both* sets of commands, and the *selection* of the "next" page could be separate commands placed somewhat arbitrarily in each column. Woot!
... still, more circuitry.
unless, maybe, I merge the earlier idea with this one...?
What if I had two separate groups of commands in two separate locations in the Free-Runner's memory... (no multiplexer necessary!)
The first location is for the LCD refresh, identical to how it is now...
The second location is for sampling/repeat... It would be laid out basically identically to the LCD-Refresh location, but skipping over the Horizontal/Vertical blanking-periods used only by the LCD.
The actual windowed-repeat wouldn't be possible without a processor... (as thought-attempted, earlier)... but the concept of separate command-spaces... hmm...
..................
There is one *minor* flaw with this technique, that has been gnawing at me for a while... It's mostly an OCD-factor, and really doesn't matter...
Currently, when sampling occurs, the process is seen *in real-time* on the LCD. Again, the LCD-Refresh commands are tied-directly to the sample/repeat commands.
With the original sampling-to-visible-pixels-only idea, it would've shown the sampling in real-time, but would've shown the samples somewhat skewed (by the H/V-blanks). The next LCD-Refresh, and those thereafter, would show them properly-aligned with the pixels. That would've been an only-minor annoyance.
With this "new" technique (separate command-spaces in the Free-Runner for LCD-Refresh vs Sample/Repeat), it's *quite likely* *nothing* or even *complete garbage* would appear on the LCD during sampling. Another minor-annoyance... slightly less-minor than the other, but really only a visual-factor...
(A similar minor visual annoyance is the long-standing fact that when a large repeat-window is selected, the LCD sometimes displays the repeat-window repeatedly... wiping out the normal display during repeating. Again, just a factor of trying to make the circuitry as simple as possible... generally doesn't affect the functionality *much* but could stand to be slightly improved. Also, generally, if a large repeat-window is selected, then there's no reason to repeat it so-often, as the 'scope would have to have slower sweeps to show the entire window, anyhow, and thus they'd be brighter...)
......
And then, there's the issue of... if only sampling what can be stored in *visible* pixels, then the actual number of samples taken is reduced...
wherein I begin to contemplate the difficulty of having a sliding sample-window *on the display*... and now I won't be able to think about anything else for the next 20 minutes. Time to shower.
....
And, if you're wondering... The video could certainly stand to be improved. Apparently video isn't my canvas. I've plenty of ideas for improvement, but it's such a friggin' drag. And drop. And clip. And slide. And take after take... And watch after watch... I don't want to watch myself *that much* sheesh!
... sliding window on the display... something about having some Adder logic between the Address Data-Pins and the Address Inputs... oy.
-
DE-PROCESSOR VIDEO
03/27/2015 at 05:22 • 4 commentsIt is done!
Watch as Free-Running SDRAM continues to do its thing when de-processored!
Thanks @frankstripod for the idea!
-
Pictures!
03/21/2015 at 15:11 • 3 commentsPer resounding request...
sdramThing4.0:
Chips, from left-to-right, top-to-bottom from under the SDRAM DIMM:
- DM74H51N AND-OR-INVERT used as a multiplexer, of sorts, for the Chip-Selects and Enabling-thereof
- ATMEGA8515L-8PI (Atmel AVR, rated for 8MHz, has run up to ~20.5MHz!)
- 30MHz Crystal Oscillator stacked atop a CY2305 Clock Buffer (both found on an old dead TV's PCB) mounted on a SMT-to-DIP breakout board (see below)
- CD74HCT163E 4-bit binary-counter used to divide the Oscillator's frequency for the AVR (currently /2)
- (There's a couple resistors in the next socket, these help separate the input/sampled data from the output/repeated data on the same SDRAM Data pins).
- SN74LS86N (x2) XORs. These are used as Buffers/Inverters to drive the LVDS signal used by the LCD (the LCD connector is to the right of these chips)
- 74HC74D (x2) Flip-Flops used for the new one-shot circuitry (found on an old Pentium I Laptop's mobo)
- 74HC08D AND used for the Chip-Select one-shots (ditto)
- 74HC32A OR used for the DQM one-shots (ditto)
Atop the DIMM is a two-position (three-pin) jumper, used to select compatibility with software for sdramThing4.0 or sdramThing3.5 and below. This reroutes one chip's DQM differently so that the LCD's Blue (and Timing) data can be modified without having to recalculate the Free-Running commands, nor the LCD's clock. (The LCD's Blue/Timing Data, as well as the clock, is on the "Free-Runner" as that data--the cursors and status-bar--remains constant regardless of new samples). This change, mainly, was an attempt at allowing for changing of the blue-data despite the "double-write" issue, from before. Though it's a useful feature I'd had on the backburner, regardless.
Clock Buffer Breakout-board:
This guy fits in the original crystal-oscillator socket (seen in the background, right of the AVR)--with just a few rewires--and adds 5 buffered clock outputs... Handy... Some of my oscillators don't have the drive-strength for 8 SDRAM chips, the clock-divider, and 4 Flip-Flops.
ALSO: It has a 5V-tolerant input! Also handy, some of my oscillators don't play well with 3.3V. Next to the socket, in the background, is a three-pin two-position jumper for selecting 3.3V or 5V to drive the oscillator, which now gets attached to the top of this breakout-board. Also, this handles both 14-pin-spacing oscillators as well as 8pin. WEE!
Below: The latest sampled-data from the motor-driver...
(Apparently my uploading didn't go in order, and I daren't copy/paste these, as it'll likely take forever to reload them on my flaky 'net connection)
The upper trace(s) show, I presume, the clock-signal. The lower trace(s) show, I presume, the data-signal. (There seems to be a new bug in sdramThing4.0, the horizontal lines shouldn't be there). Otherwise, it *looks* about right, by which I mean the clock appears to be toggling at roughly 50%... I forgot to check the timing on my 'scope, but some of those toggles look a little skinny. I'm not sure the cause... But, it's plausible the toggling-rate is actually, still, slightly faster than my 30MS/s sampling. This *might* be corroborated by the fact that I'm counting, at best, what appears to be a pair of 16-pulse trains... Yet, as I recall, the *similar* but not-identical motor-driver I have specs for claims 18bit packets. This is why I wanted to sample this thing... I don't know if this chip uses the same data format as the other. That, and... I didn't quite understand what the registers *do*, especially on initialization. The *other* chip has some strange (to me) settings related to current-output, drive-strengths, and whatnot that I just can't parse from the data-sheet.
This packet is the first seen in the image below.
Below: The entire data-sample is shown on sdramThing's display in raster-fashion.
Two channels are currently in-use, corresponding to the two channels on my 'scope. One is shown on this display as Red and the other is shown as Green. Each pixel represents 7 data-samples. The cursors are (roughly) selecting three data-packets. The first packet is shown on the 'scope traces, shown earlier.
The status-bar, at the top, shows the number of samples between the cursors, as well as a "Delta" value for requested cursor-movements.
The cat found a good pillow...
-
40MHz, TV reception! A video.
03/21/2015 at 03:37 • 2 commentsSince my buddy @frankstripod keeps insisting on more pictures and videos, and I keep wanting to spend time improving the thing... Here's a funny state-of-things.
Experiments show:
This only appears to affect channel 13... and only when using the 40MHz oscillator.
Attempting a 40.96MHz oscillator, as we speak... Hey, that AVR Runs! And we're getting random data, again, which is what was happening with the 40MHz... But, no interference with Ch13, which according to Wikipedia is centered around 210MHz... wonder where that's coming from... 40*5=200MHz... maybe some edges somewhere are ringing fast?
-
IT'S ALIVE!
03/17/2015 at 12:47 • 13 commentsThe ONE-SHOTS WORK!
The pseudo-vernier-scale idea worked, with a little tweaking... Automation of determining the offset (between the column *requested* to be written and the column *actually* written) is now possible.
And, a good thing. Because....
- I replaced the clock-divider chip, a 4-bit counter, that I only had in 74LS form... It worked, but was noisy. Bumping up to 27MHz showed the noise *real bad* as each count looked more like... ¯_-_¯_-_¯ Nothing square about it, and where'd that extra blip come from? I found an HCT... technically, also, rated for 5V, but its output looks *MUCH* better. And, actually, from my reading, the HCT series is *designed explicitly* for interfacing HC-series chips, running at 5V, with 5V TTL chips (the output-voltages of the HC series aren't guaranteed to match the input-voltages of the TTL series *exactly*. The HCTs guarantee the outputs will match the inputs...) So, my theory goes, the HCT series chips are probably all-HC circuitry inside except for the output-drivers. And, the HC series is designed to run at <5V, as well.
- I fiddled with my oscillators. I have three I'd been working with regularly, 8MHz, 16MHz, and 20MHz... They all seemed to work, at various times... But I'd been noticing that the 16MHz is the only one that's really reliable. So I finally 'scoped 'em all. Sure-enough the 16MHz has nearly full-swing output, whereas both the 8MHz and 20MHz have ~1V swing (again, because they're, likely, rated for 5V, and I'm using 3.6V...? or maybe because there's so much fan-out...? 8 SDRAM chips, the clock-divider, four Flip-Flops... it's a bit.) I also have the 27MHz, which I think is actually designed for 3.6V, but it didn't work before the clock-divider was introduced (I think the AVR couldn't handle that frequency, it's only rated for 8MHz, so 20 was certainly a lucky-stretch).
As I write this, it's sitting on my desk running with:
- 27MHz SDRAM Clock
- 13.5MHz AVR Clock
(It might, now, actually be fast enough to sample the data-source I'd done all this work to sample!)
It was a bit weird... I was able to *reliably* write and read-back with the 16MHz clock, 8MHz for the AVR, and the LS divider... there was that double-write issue, but even that was reliably-accounted-for. I worked-around it in code. Even the "vernier test" worked, which meant that, technically, it was free-running exactly as expected. But, it just wouldn't work with the full system. Dunno why. Removed everything I thought could be causing trouble, still wouldn't run. Probably went *way* out of my way with all that, seeing as how all it, apparently, took was using more reliable/spec'd parts. Though, there was a few hours spent looking through *nearly* everything I had for a replacement for that divider-chip... what, a week ago now? There was *one* box I hadn't checked until now, and ironically, there was *exactly* one sitting there. (And, yes, I went through the entirety of the rest of the box, hoping to find an HC instead of the HCT. Exactly One. Weird). Also found a couple more of the AVR I'm using... which could be handy. Allegedly I burnt a pin on each of 'em, but this was way-back-when... early AVR days, maybe I just didn't know what I was doing.
So... what's next...?
Oh, so the 16MHz/LS "vernier test" resulted in a column-offset of -2. The new arrangement (27MHz/HCT) results in a column-offset of -1. So, thankfully I'd made that thing.
AND APPARENTLY No Double-Writing!
Which... means... I can't quite wrap my head around the magnitude of this, right now., since it's been so long in the making... It apparently means my one-shot idea was sound, from the start.
I've a few more higher-frequency oscillators I might try, with even higher clock-dividers. Who knows, maybe I'll even get it up to the full 133MHz?
-
something like a vernier scale... a mental-challenge
03/16/2015 at 01:04 • 1 commentStill trying to figure out an automated-process for determining *where* my data is actually being written...
It's an interesting challenge...
It's basically like adding data to a circular-buffer, but not knowing the actual index.
I can load that buffer up with data...
I can start it outputting that data, but there's a delay before it will start outputting the data, repeatedly, from some unknown index.
I need to determine the index-offset from the data-output (and possibly some correlation with time?).
e.g. I load the sequence 1,2,3,4,5,6,7,8, to some random starting-location in an 8-element circular buffer. It, eventually, spits out 3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2...
The above sequence doesn't tell me anything... I have no idea where it started, and it's cycling through every element.
Further, I can't actually *read* every element it spits-out. At-best (and this is highly unlikely) I'll be able to catch every-other element...
But, more-likely, it will be every 4th or 6th or 8th (but always a multiple of 2... also, plausibly shifted by one... e.g. 3rd, 5th, 7th...?))
So, I'm imagining something like a vernier scale...
Instead of telling it to output the *entire* sequence, what if it output an *odd* number of elements...?
e.g. I loaded 1-8, and told it to output the first 7 elements cyclically.
... again, I have no idea *which* elements are the first 7... it could be 1-7, or it could be 8,1,2,3,4,5,6 or any other combination. So, in the latter-case, I might get the stream: 3,4,5,6,8,1,2,3,4,5,6,8...
And, then, with the slow-sampling, only able to catch every-other output, I might get 4,6,1,3,5,8,2,4,6,1,3,5...
(And what if I only catch every 4th or 8th?)
Can I determine the offset from this information...?
Well, in the above case, I never get the value 7....
And I told it to spit-out the first 7 elements (of 8)...
So... I think there's only one case that would allow for this... which is
Written Value (random start-position) : 1 2 3 4 5 6 7 8 Value has been Read: Y Y Y Y Y Y Y Actual Position of unread value: 8 Actual Positions of written values: 2 3 4 5 6 7 1 Write-To-Actual Offset: = 2-1 = +1 (Heh, since when do I do stuff like this NOT zero-based?)
YES!Now... what if I only capture every 4th or 6th element...? Won't it repeat at some point where possibly two values will be missed every time...? I'll have to think about this some more. But, for now... I think I'm on a much more plausible track (and easier to implement) than the last idea...
Another case where writing-it-out has made things a little easier for me to grasp...
My original idea was to load each value with either 1 or 0, in a roughly-50% toggling fashion... But I couldn't quite figure out how to phrase it in words...
Then something about the amount of time *actually* measured high, vs the amount of time *actually* measured low...
(thus vernier-esque)...
Then I tried to come up with an example of a clock that'd been rotated, but it was too complex... (somehow it skips an hour?)
-
a merge... and so many branches in this fractal.
03/11/2015 at 10:39 • 0 commentsSo, the "bit grumpy" "reversion" method in the last log seems plausible, except for a couple commands which I'm almost certain the SDRAM would be unhappy with receiving repeated back-to-back.
Instead of reverting to sdramThing3.0 (by removing the one-shots), I did some experiments using the ideas behind the "reversion," merged into sdramThing3.5.
A brief reexplanation of the problem:
It appears that the one-shots are somehow allowing each individual byte/column write to occur in two consecutive columns. The whole point of the one-shot circuitry is to take a signal that's active for multiple clock cycles (a Strobe from the AVR), and cause it to only be active for one clock. But, as far as the SDRAM's concerned, it appears that it's still coming through as active during two. (gate propagation delays, differences in Vih/Vil on different chips' clock inputs...?).
So, I sh/could probably track down the bug, but there're so many possibilities, and 'scoping these tiny timing differences that occur seldomly is difficult... thus my having gotten "a bit grumpy" and thinking of ditching the one-shots entirely.
BUT: I *can* write to any specific column and the one thereafter... AND I only need 1022 of the 1024 columns in each page... So, as long as I write everything sequentially, it doesn't matter if column 1022 contains the same data as 1021, since it's never used, anyhow.
Thus, I'm using the one-shots, and ignoring the bug, using the same reasoning that might've resulted in attempted-removal of the one-shots altogether (as crazy and unlikely-to-work as that would've been).
So, I tried the merge... and it almost-sorta worked, briefly. No errors when reading-back the written-data, so possibly the reason it didn't free-run reliably has to do with not being certain which column "0" corresponds to, when writing, vs. which *actual* column is being written. Though I tested the probable offsets pretty thoroughly. So, another possibility is that somewhere I *don't* write the data consecutively. Specifically, for sure, the last column used to draw an LCD frame is initially linked to the next (unused) page, but then rewritten later to link back to the first page. There may be some other non-consecutive writes elsewhere...
IN FACT, I'm glad I wrote this, to get me thinking... Of Course, the Cursors (and status-bar) are written/drawn non-consecutively!
How could that be a problem....?
The pages are laid out (simplified)...
SDRAM PAGE ---------- LCD Data/Timing: | X | (X represents newly-written pixel-data) ---------- Fed-Back Commands: | PAR | ( P = Precharge, A = Activate Row, R = Read Column ) ----------
Yeah... Each page contains BOTH LCD data AND Fed-Back Commands, in different bits within the page...So each time a pixel is changed, the fed-back command at that same memory location must be calculated and rewritten...
So, if two columns are written each time, where only one should be, then, instead of having PAR, we have PPR.
Bad news.
The next page is not activated, So it tries to grab data from an unactivated page. There is no data, Free-Running dies.
----
So many branches... just keep piling up. For this bit alone.
(It's a wonder I'd ever gotten this thing running, it's like a friggin' fractal!).
First, (and regardless of whether I fix the one-shots or stick with this double-write bug):
I need some way to determine *which* column is *actually* written. This is important because e.g. each Fed-Back "READ" command points to column 0 in the next page. But, if the AVR's WRITE command to column 0 actually ends up in column 2, then the Free-Running Fed-Back "Read" will go to an unwritten column, which may randomly contain something that looks like a Fed-Back command. (It's more than just a matter of whether the column is unwritten, it has to start at the right location in order to keep the LCD's *serial* pixel-bitstream in order...).
...How...? I can be sure that Read and Write occur at the *same* column by simply writing the data then reading it back. But, the only way (I can think) of to determine whether *that* column-data was stored in the proper column (or, more importantly, *which* column it is actually being written to) is by actually initiating free-running and checking where it crashes.
I'm imagining a bunch of pages, the "Data" portion would contain some value that's consistent in every column in the page, but differs from page-to-page (maybe the page number itself). This can be read-back by the AVR periodically. Each page will have the "PAR" commands closer and closer to the beginning of the page (does the first have them start somewhere in the middle, in case the offset is negative?).
At some point, Free-Running *will* crash, because, at some point, the previous page's "Read Column 0 in the next page" command will start a read somewhere *within* the *next* page's "Read Column 0 in the next page" command. However many pages it cycled-through before crashing would indicate the column-offset.
(Bank: 0 1 2 3 0 1 ) Page: 0 1 2 3 4 5 SDRAM Col: 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 |----------| |----------| |----------| |----------| |----------| |----------| Data: |0000000000| |1111111111| |2222222222| |3333333333| |4444444444| |5555555555| |----------| |----------| |----------| |----------| |----------| |----------| Fed-Back: | PAR----->| PAR------>| PAR------->|PAR-------->|AR------(P)>|R-------(PA)> Commands |----------| |----------| |----------| |----------| |----------| |----------| Read/Write:2345678901 2345678901 2345678901 2345678901 2345678901 2345678901 "Column" (offset by 2, so PAR was written, in Page 0, to Cols567, but in the actual SDRAM, were stored in columns 345) Will this crash at page 4, because the Precharge does not get called before Activation at the next row...? (I'm pretty certain Activate -> Activate causes unhappy SDRAMs. Or, it might result in a read at the already-opened page...?) So, ignoring, for now, the AVR's inability to sample *every* column (too slow), it would read, from the data... (Also ignoring the CAS Latency) 00000011111222233344 ... and after that we'd get... either floating data-lines (which would probably still show "4" for several samples... even with pull-resistors) or 000000011111..... if an activate on an already-activated bank results in no change to that bank
It's not *difficult*, but it's a lot of work, and there are still a lot of unknowns as to the potential implementation. OTOH, this "auto-calibration" method could be thrown in the main project, and be used again if a new circuit is ever built, which may have different gates with different delays, or different sensitivities to clock-edge-levels, or even when I just change the clock to another that might have shallower/steeper edges...?
Second, I need to either work-around this one-shot dual-write bug, or fix it. Now that I remembered the cursors and status-bar, a workaround seems like nearly as much work as a fix. Again, one option *might* be to use a second register... maybe even a third. But if the issue's due to clock-edge-detection-times, then that might not help... And, then, maybe it's necessary to insert a fast-switching clock-buffer (think I'll have to dig around old motherboards for something like that)... And, even then, there may be an issue with the actual lengths/positions of the clock wires... Maybe I need to change from the star-topology used now to a daisy-chained topology...? Or insert gates in the clock path purely for the sake of a predictable delay... It's getting ugly. At this point, I shouldn't call this sdramThing3.5, I should call it sdramThing4000!
Third, nah... I'm already overwhelmed.
Gotta say, though... the ability to do reliable sampling from an AVR's input on data that's coming in at a 2x faster clock-rate is pretty sweet. Tempted to test out how reliable it is, in sdramThing10k.
-
As I'm a bit grumpy... A possible REVERSION.
03/09/2015 at 12:05 • 0 comments... it occurs to me there may be *another* way to go about this...
I have *read* working, it seems, with the SDRAM clock at at least 2x the AVR clock...
And, it seems, it's not freaking out about the other commands being received twice sequentially...
(assuming that's the case, what with the one-shots apparently appearing as two-consecutive commands)...
(which was a huge consideration, earlier... as, I'm somewhat certain, Activate, Precharge, or *at least* Load Mode Register, were once not happy being sent back-to-back...)
... what about considering the concept of *intentionally* allowing it to write multiple locations back-to-back with the same data ... ?
*If* it handles other commands being back-to-back... then... I could actually get away with this...
If I understand the issue correctly, we're getting *two consecutive* columns, written with the same data...
And, I can, clearly, choose *any* starting column...
So, if I wrote each "column" (pair) consecutively...
Then I'd only have an invalid column *at the end* of the page...
AND
Currently, it's set up such that each page (of 1024 columns) is only *using* 1022 columns (IIRC: 146 * 7, because each LVDS transaction takes 7 columns/bits to work with the LCD display...)
THEN
It doesn't matter what's in columns 1022 and 1023
BECAUSE
Free-running works *at the SDRAM Clock* and columns 1022 and 1023 will never be accessed.THUS
I could actually REMOVE the one-shot circuitry, and *still* run the SDRAM at, at least, 2x the AVR clock.
No kidding.
The only potential issues, I can currently predict, are "Activate" and "Load Mode Register"...
IF it's working as I think it is, then BOTH of these ARE occurring back-to-back, despite the (flakey) one-shot-circuitry...
...And... It's running.
IF that's the case, then this is entirely plausible.
PRIOR EXPERIENCE
suggests that some of this is entirely plausible...
READ, for instance, from the same column, in multiple sequential identical commands, results in multiple sequential outputs of the same column's data.
WRITE, works similarly...
This was a key-factor in sdramThing1.0... This concept is what made sdramThing1.0 (and 2.0?) possible...
...Again, the concept that, e.g., the SDRAM's reception of multiple consecutive "Read" commands at the same column results in a steady output of that column's data.
...And a "Write" command, received consecutively, at the same column, results in a *write* only to that column.
Again, if the SDRAM isn't pissed about a back-to-back consecutive Activate commands, and Load Mode Register commands, then, really, there's no need for one-shots, even with 2x SDRAM clock. (Precharge has since been determined, from the SDRAM's truth-table, to result in NOP on a previously-precharged bank/page... so it's no longer a concern, leaving only Activate and Load Mode Register).
Why didn't I try this from the start?