-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtroubleshooting.txt
158 lines (135 loc) · 6.91 KB
/
troubleshooting.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
delay_cyc isn't highly-accurate, and may work differently on different
C compilers. TODO: I need to look into this.
This is in delay_cyc.c/h
Also affects delay_Dots()
THESE AFFECT: display's timing-parameters aren't exact...
And where called with a VARIABLE argument,
As it stands, this may result in row-timing (H-Blanks + DE) that aren't
constant and/or aren't exactly as requested...
This *may* affect some display's sync-ability.
So far, it hasn't been found to be a problem, except visually where,
e.g. in BLUE_DIAG_BAR(_SCROLL) the bar is not perfectly diagonal, more
stair-stepped (or even slightly jagged, in the "hokey" case).
First test (BLUE_TESTING + DE_BLUE) isn't showing *anything*?
You might want to make sure the processor's functioning *at all*
('scope?) This is where it'd be handy to have the heartbeat functioning
again... TODO!!!
Problem may be: Technically, with the default values, the processor is
running at twice its rated speed. the PLL is set to run at its maximum
(which is more than its rated "saturation" speed) ~128MHz,
the processor is set to run *from* the PLL / 4 (~32MHz, rated for 16MHz).
This works in my case, but maybe some other versions/revisions/batches of
the ATtiny861 might not handle this...
You might be able to get away with disabling PLL_SYSCLK and/or modifying
LVDS_PRESCALER.
BLUE_BORDER only showing one blue bar, and one black (no second blue bar)
OR
BLUE_DIAG_BAR showing a tiny fraction of a blue triangle at the bottom,
nowhere near filling half the display:
Probably a timing-thing...
e.g. PLL_SYSCLK may be enabled, but the fuses haven't been programmed
for it.
Early "BLUE_TESTING"
Weird seemingly-random garbage coming through? Try disconnecting the
programming-header. There's no way 'round using the same pins for
programming as "LVDS", due to the chip-layout.
(Oddly, this presented itself on one display, but not another, same
exact code. Dunno.)
// If you want to lose hope, read this: It's quite plausible that the
// display may just be repeating one row's data, rather than actually
// paying attention to each (identical) row's data... So cross your
// fingers
// when you move on to BLUE_DIAG_BAR
Some topics to keep in mind:
It's a good idea to start and end with white on the horizontal borders.
I usually do 3psegs.
After all segments are drawn, they're followed by white for a short
duration, then that's followed by cyan (the red value is set 0)
Ideally these two colors wouldn't be seen;
the total length of all segments would reach the edge...
but it's not *necessary*
White indicates a duration before DE is disabled
a bit of a hack, explained in code
Cyan (or the absense of red) indicates row-calculation-time (right?)
And these values are dependent on a white segment at the very end?
Then there's a green-bar, too... what's this?
Blue has dropped-out, but I think that shoulda happened much sooner
... when NADA_from_DE is called. I need to look into this more
Horizontal Jitter Issues? Look into:
increasing ROW_CALCULATION_DELAY
Is ALIGN_PIXCLK set?
Trying to compile with different options?
First guess, I've moved that code to _unusedIdeas...
Try moving files back out of there into the main directory
Some pixels coming through, but horizontal syncing is off and/or
solid-colors appear pixellated?
You may be at the minimum LVDS-bit-rate that the display can just
*barely* handle... try to increase the bit-rate
(Decreasing LVDS_PRESCALER, though keep in mind this affects all math
related to pixel-segment-widths, Dot-counts
(for e.g. Hsync width=T_Hlow), etc.)
--TODO for me:
Now that PLL_SYSCLK has been added, maybe distribute with it disabled
then have a "Double bit-rate" option, which BOTH uses PLL_SYSCLK and
divides LVDS_PRESCALER / 2 (==4)
This allows math to take the same amount of time for each pixel
Thus, no scaling is necessary. Essentially it just doubles
the speed of *everything*, bit-clock, CPU frequency, etc.
--NOTE from experience:
Doing the above has allowed the "flakey" display to sync!
--NOTE 2: Using PLL_SYSCLK far exceedes the specifications for the AVR
running at close to 32MHz (rated for 16!)
-- Can decrease if necessary by messing with OSCCAL
Also a possibility: the signal output by your "LVDS chips"
(74LS86 specified here) isn't clean enough...
Did you use the same chip for both the + and - signals on each LVDS
signal?
Your likely newer chips may have higher output drive capability than
mine... you might need to put some resistors in series (untested)
Your 74LS series chips may not like being under-driven at 3.3-3.6V
(they're specified for 4.5-5.5V)
The displays are rated for 3.3V, but you could probably get away
with upping that a little bit... (I've used 3.6)
The signal received at the LCD isn't clean enough...
Did you twist the pairs of wires in each LVDS signal? Try shielding
Try to keep the lengths of all wires between the LCD and the circuit
the same
Try working with just one signal at a time, in the process...
e.g. the "blue" signal is also responsible for timing, so disconnect
the "green" and "red" "LVDS drivers" from the AVR, and tie their
inputs to a constant voltage (you'll have a combination of
full-red/green and no red/green across the screen)
and just work with cleaning up the blue/timing signal, first.
Using a solderless-breadboard?
These are inherently flakey...
Contact between the wires and the breadboard can be "loose" or
oxidized, at best
There's a NON-NEGLIGIBLE amount of capacitance between the rows of
breadboard "clips", and also with the breadboard's backing, if
mounted on metal.
They inspire nice little ratsnests of wires which can couple
inductively and capacitively
Can also inspire long wires between boards, etc, which make for
great antennae
Also inspiring the disuse of "decoupling" capacitors at each chip
(hard to breadboard a capacitor across a TTL chip, whose power
pins are so far away. Even though they're probably *more*
necessary in a breadboard environment than on a PCB!)
Nevermind shorting of resistor-leads, etc.
The metal breadboard "clips" in each row can actually pop-out of
the breadboard, making them even harder to get good contact with
Their springiness also wears out over time...
Rows repeating?
Check those RowCalculationCycs... increase, maybe decrease...
Made your own thing:
----------------------
and it's showing only white and cyan?
Make sure you've got enough pixels/psegs to fill a significant portion
of the screen... (?) --a/o SEG_STRETCH in tetrifying
with the rowBuffer:
and it seems to be syncing randomly...?
Make sure you're not writing rowBuffer[] with direct values...
use fb_to_rb()! (fb values are RGB, rowBuffer values are OCRvals)
and it's only showing white and cyan...?
Make sure to clear the rowbuffer with valid color-data before
calling your drawing-functions! (e.g. tet_drawRow())