Teensy 3.6 VGA driver
- Thread starter qix67
- Start date
defragster
Senior Member+
Nice work Frank and qix67!
The pixel-flickering went away when I switched back to "auto" setting.
Seems, that I don't need extra hardware... it's already good enough
Impressive.
In fact, if you were able to have the frame buffer partially in SRAM_L, you should use AUTO, it uses a bit more memory but improve image stability a lot.
Don't you have any problem to clear screen fast enough between frame ? I plan to add a function to automatically clear screen using DMA at start of Vsync. DMA has a 16 bytes write which can clear screen very fast while CPU does something else and during Vsync, a 2nd DMA channel does not disturb pixel DMA channel.
defragster
Senior Member+
I have my board built and tried with Franks C64 HEX and I just built "...\libraries\uVGA\examples\DrawingTest".
On two displays connecting VGA:
>C64 code woke monitor - then it found 'Analog No Signal'
>Drawing test also got 'No Signal' but it didn't seem to wake it?
With 10 resistors to solder to pins and joins - plus the way I did GND (common across GNDs on middle offset row to pin 5 with 30 ga wire - then trimmed middle row pins to mount on PCB) - lots of room for errors on my end, or it could be low V on the sync lines with the 100E's?
I'll go to a CRT and try . . .
{edit} Found two CRT's - No luck - one does self test and told me "check my PC" . . .
qix67 - what compile options for the github code? 240 or 180 MHz?
Perhaps a multi-meter will tell me how my connections are . . .
On two displays connecting VGA:
>C64 code woke monitor - then it found 'Analog No Signal'
>Drawing test also got 'No Signal' but it didn't seem to wake it?
With 10 resistors to solder to pins and joins - plus the way I did GND (common across GNDs on middle offset row to pin 5 with 30 ga wire - then trimmed middle row pins to mount on PCB) - lots of room for errors on my end, or it could be low V on the sync lines with the 100E's?
I'll go to a CRT and try . . .
{edit} Found two CRT's - No luck - one does self test and told me "check my PC" . . .
qix67 - what compile options for the github code? 240 or 180 MHz?
Perhaps a multi-meter will tell me how my connections are . . .
Last edited:
Take caution, one of the middle row pins is not a GND and MUST not be connected to other.
All examples use default resolution. Depending of CPU frequency, the default resolution is different but I think I define one for all frequencies from 24Mhz to 240Mhz. If a default resolution is not defined, you will have a compilation error.
That's a good idea, it is so easy to wire incorrectly. You can also check using a blue/green led (pin output = 2V max). Plug it in the middle row (GND) and the pin you want to test.
Hsync and R, G, B pins are clearly visible this way, Vsync just produce a very dim light (act like a PWM @60Hz with a duty < 3%).
defragster
Senior Member+
Thanks qix67 - I'll check my GNDs and go from there for signals and try an LED.
Re GND:: Indeed I first trimmed the OPEN pin on the middle row - then left wire insulator where it passed over.
Not much history doing this and may have made a bad assumption about pin order or gotten confused with VGA rotation or top/bottom flip - or miscounted . . . if that checks out I'll parallel resistors on the sync lines down to { 220,220,330 } to get 82.5 - won't that be pretty - looks like there is room on the PCB to fit them okay.
Re GND:: Indeed I first trimmed the OPEN pin on the middle row - then left wire insulator where it passed over.
Not much history doing this and may have made a bad assumption about pin order or gotten confused with VGA rotation or top/bottom flip - or miscounted . . . if that checks out I'll parallel resistors on the sync lines down to { 220,220,330 } to get 82.5 - won't that be pretty
- looks like there is room on the PCB to fit them okay.Nope. The reason is simple: I don't clear the screen. The entire screen gets rewritten anyway, every time, so there's no need to clear it.
One little issue, that I'd like to mention is, that this rewrite happens with 50Hz (PAL), whereas the screen-refresh is 60Hz. Theroretically, this should result in some not so fine effects... Well, i'm aware of this - but I can't do anything to prevent this anyway (even if 50Hz VGA is possible - we can't sync to it, because some rasterlines need a bit more time than allowed..). So I'm just ignoring it - As you see in the video, in fact, even the full-screen scrolling is not too bad.. (I did choose this game as a test because of the full-screen scrolling) I think the old TV-Sets with NTSC/PAL were much worse ..
So, if a particular game or "demo" shows this effect - we have to live with it. Any Ideas how to make the quality a bit more PAL/NTSC like ? Some filters and some noise...?
This is a good thing for other applications, for sure !
I still have to test if USB-HOST (Keyboard) works.... I guess it uses DMA ?
Last edited:
Same on my Sony "Bravia" TV with VGA Input: The VGA-"Icon" lights up, but If if try to select it, it says the PC is not switched on.
A timing issue ? Or is it possible that it wants 5V on Pin 9 ? https://en.wikipedia.org/wiki/VGA_connector
Unfortunately, I have hot glue all over the backside of my "experimental" board, impossible to connect Pin 9 without destroying things...
Last edited:
PaulStoffregen
Well-known member
2 quick questions:
Should I include this library with Teensyduino 1.40?
Can someone post a video, showing the hardware used and results running on a monitor? Looking for something showing how it works, not just a close-up of the screen only.
Should I include this library with Teensyduino 1.40?
Can someone post a video, showing the hardware used and results running on a monitor? Looking for something showing how it works, not just a close-up of the screen only.
Pullrequest: https://github.com/qix67/uVGA/pull/4
I can see one potential problem with your change. To work properly, DMA channel must be <=15 (see uVGA.cpp line 213) because any other DMA channels belong to what seems to work like a 2nd DMA controller and have a lower priority in case of DMA conflict.
In your code, where are dmachan{1,2,3} declared ? I find them nowhere in teensyduino code.
In your code, where are dmachan{1,2,3} declared ? I find them nowhere in teensyduino code.
Hi Paul,
I think you can. I have not encountered any crash on my test and all functions seems to work as expected.
I will try to do this this weekend. I just need to take time to clean my desk
Ops.. I forgot to copy one line..
I'll add it this evening, when Im back. From my memory, the DMA lib does not allocate DMA Cahnnels >15. We should check this.
https://github.com/qix67/uVGA/pull/4/commits/c62906b8c8d67aa06f4bcb6d09ca5222455b173d
And yes, only the fist 15 channels are used. So, no problem.
But a problem is the malloc.. esp the first, for the lower sram - I used DMAMEM to make sure that it is at the beginning of RAM (DMAMEM uses a section at the beginning of SRAM_L). Can you support that somehow ? (Best would be to remove that malloc completely.. together with the fixed DMA Channels.. but I understand, that dynamic modelines are not possible without that. Who cares ;-) I can't image a situation where a app need to change the resolution - would be no problem to make it at compile-time, not runtime.. with that malloc, it's not possible to use mores than 64K for variables...
One more thing to check: Is the use of your timer compatible to other libs ?
Last wish: move the frame_buffer from private to public.
A minor observation: Serial.print results in pixel-flicker - not only when printing. It's enough to open the Arduino Serial Monitor. The Pixels keep flickering in this case. Ok, not so important in my case.. but nice to know.
I fear that the USB-HOST will show the same... i have no idea how to avoid that... and I really need that. No Chance without.
And yes, only the fist 15 channels are used. So, no problem.
But a problem is the malloc.. esp the first, for the lower sram - I used DMAMEM to make sure that it is at the beginning of RAM (DMAMEM uses a section at the beginning of SRAM_L). Can you support that somehow ? (Best would be to remove that malloc completely.. together with the fixed DMA Channels..
but I understand, that dynamic modelines are not possible without that. Who cares ;-) I can't image a situation where a app need to change the resolution - would be no problem to make it at compile-time, not runtime.. with that malloc, it's not possible to use mores than 64K for variables...One more thing to check: Is the use of your timer compatible to other libs ?
Last wish: move the frame_buffer from private to public.
A minor observation: Serial.print results in pixel-flicker - not only when printing. It's enough to open the Arduino Serial Monitor. The Pixels keep flickering in this case. Ok, not so important in my case.. but nice to know.
I fear that the USB-HOST will show the same... i have no idea how to avoid that... and I really need that. No Chance without.
Last edited:
Yes. Flickering. :-(
Can you post the schematics for the additional hardware ? I want to make/order testboards..
defragster
Senior Member+
Multimeter just pointed out that indeed I improperly translated top and bottom rows as presented and soldered on the PCB
Looking at the face I saw it properly - the but when upside down and faced away I treated the true bottom row as the top. So I get to do it again.
Looking at the face I saw it properly - the but when upside down and faced away I treated the true bottom row as the top. So I get to do it again.
https://github.com/qix67/uVGA/pull/4/commits/c62906b8c8d67aa06f4bcb6d09ca5222455b173d
And yes, only the fist 15 channels are used. So, no problem.
But a problem is the malloc.. esp the first, for the lower sram - I used DMAMEM to make sure that it is at the beginning of RAM (DMAMEM uses a section at the beginning of SRAM_L). Can you support that somehow ? (Best would be to remove that malloc completely.. together with the fixed DMA Channels..
Changing the resolution no but using the same library between different projects not using the same resolution. The only solution I can think of is to keep the current code but add a function to call before begin(), function receiving a user preallocated buffer
Yes if they use a different FTM or the same FTM but different channel. The 2 channels generating Hsync signal and the channel starting pixel DMA at start of each line should not affect or be affected by other timer channel.
This requires additional function to retrieve row stride.
I know, I failed to find the reason. At first, I though it was USB DMA but it does not seem so. Do you have a similar flickering when you play sound ?
Not so fast, I have neither a working board nor a prototype.
My first test does not work as expected. One of the signal is inverted and during this test, I successfully removed from the bus ... data instead of address. The NOT gates I ordered should arrive very soon now. I also though of replacing the latch by an edge trigger flip-flop, it will probably remove the need of signal inversion. I want to use a 74LVTH16374 and I should have received it yesterday. Unfortunately, the seller sends me the wrong component, a LCX16543.
I can at least tell you how I want to wire everything. Instead of pins 2,14,7,8,6,20,21,5 (port/bit=D0, D1, D2, D3, D4, D5, D6, D7), I use 21,20,6,8,7,37,36,35 (port/bit=D6, D5, D4, D3, D2, C10, C9, C8). Connect this 8 pins to latch inputs and VGA connector to latch outputs. Connect pin 14 (flexbus Chip Select) to latch LE pin through a NOT gate to invert the signal.
My first test uses a 74HC573, a 8 bit latch in DIP20 package, cheap component (~1.90€ for 10). I will also test a 74LVC573, same latch but 4 times faster in SOIC20 package, even cheaper (~3.20€ for 20). For my test with edge trigger flip-flop, at first, I wanted to use a 74LVC574 but I found no friendly package and none on aliexpress. Moreover, nearly all 8-bit chips I checked use 5V and 3.3V one are expensive compared to 16-bit ones.
Multimeter just pointed out that indeed I improperly translated top and bottom rows as presented and soldered on the PCB
Looking at the face I saw it properly - the but when upside down and faced away I treated the true bottom row as the top. So I get to do it again.
I really understand your problem. This morning, when upgrading my domotic circuit, I noticed I inverted the wires of all RJ45 connectors which permute 3.3V and GND signals
I still wonder how all components still work.I am currently merging your code but I have encountered 2 problems. The debug you add in the uVGA constructor hard crash the teensy. It is not possible to use Serial in the constructor because Serial is not yet initialized. The crash is so hard it is not possible to auto update teensy anymore, I had to press the reset button. I will fix the problem but I found no way to merge your code without committing it to let me fix the problem.
The second problem is not in your code. For an unknown reason, DMA runs slower today
or monitor does not understand the frequency because the highest resolution @240MHz does not fit in screen anymore. I powered off everything (monitor & teensy) for 30 minutes and now, it works properly, weird problem.Sound: Works good, no problem so far!
USB-HOST : Causes flickering. I'm searching for an other solution to connect a keyboard..
Print: Hm, it printed for me without crash.
DMA slower: Yes, i had the same effect. Closing Arduino, and deleting the temp directory helped.
buffer public: ->This requires additional function to retrieve row stride. yes please ;-)
They just need to be defined before #include your library.
16Bit Chips: How about ignoring the upper 8 bit ? It's a bit wasteful - but who cares..as long it makes things easier...or cheaper..
USB-HOST : Causes flickering. I'm searching for an other solution to connect a keyboard..
Print: Hm, it printed for me without crash.
DMA slower: Yes, i had the same effect. Closing Arduino, and deleting the temp directory helped.
buffer public: ->This requires additional function to retrieve row stride. yes please ;-)
#defines would help (?!)
They just need to be defined before #include your library.
16Bit Chips: How about ignoring the upper 8 bit ? It's a bit wasteful - but who cares..as long it makes things easier...or cheaper..
defragster
Senior Member+
I really understand your problem. This morning, when upgrading my domotic circuit, I noticed I inverted the wires of all RJ45 connectors which permute 3.3V and GND signals
I even dutifully marked the PCB with a white ink pen for VGA pin1 (And T_3.6 GND) to keep my orientation for all wires as I flipped it over - the bad thing I did that when I was disoriented WRT VGA - and then used that afterwards
Question: Does the Added RAM replace the MCU RAM for buffer? That would mean a T_3.5 could then use this VGA hardware for display.
PaulStoffregen
Well-known member
Maybe try reconfiguring the crossbar switch bus master priority levels? The default priority levels are shown on page 417. USB1 has priority level 6, the highest of all.
The RAM is slave port #1. So you should be able to change it by writing to AXBS_PRS1. Maybe try writing 0x05432610, so the DMA controller gets highest priority for slave #1.
Maybe also be worthwhile to write to AXBS_CRS1, to configure the arbitration for slave #1 to park on master #2....