uVGA library with non-default pins

Status
Not open for further replies.

kallikak

Active member
Hi,

I am using the uVGA library with a Teensy 3.6, and all worked fine with the default settings. But for port-related reasons, instantiating the uVGA object using (hsync_ftm_num, hsync_ftm_channel_num) = (3,4) as described in the README suits my requirements better, but I can't get it to work.

Specifically I want HSYNC on pin 34 (which should be set from the parameters above) and VSYNC on pin 35 which is just specified as a parameter to the constructor. Both signals then go through 82R resistors to the appropriate pins of a VGA connector in the normal way, and remember this is working for the default settings.

Measuring the output I can see what looks like a valid HSYNC signal on pin 34, but there's nothing on pin 35.

The constructor call I am using is:
uVGA(0, 0, 0, 3, 4, 6, 35)

Have I missed something obvious? I have checked and I don't think there is any problem with the connection of the pin, and I have also tried with (3,6) and pin 37, but also couldn't get a VSYNC output.

I'd be very grateful for any pointers or suggestions.

Thanks,

Ken
 
Looked this up - been some time - lib it two years old : github.com/qix67/uVGA

Notes there say:
Hsync pin (default: 22) -> 82R resistor -> VGA 13 depend on HSync FTM channel
Vsync pin (default: 29) -> 82R resistor -> VGA 14 can be changed to any pin except pin of port D

have to confirm that #34 Vsync is not on port D
Seems FTM channel control of Hsync may influence use of pin #35 for that.

Pin#34 is port E

Pin #22 is FTM0 and Pin 35 is on FTM3
Teensy 3.6
FTM0 : 5, 6, 9, 10, 20, 21, 22, 23
FTM1 : 3, 4
FTM2 : 29, 30
FTM3 : 2, 7, 8, 14, 35, 36, 37, 38

And I see this : github.com/qix67/uVGA/blob/master/uVGA_FTM.h#L72
Code:
#if 0
//defined(FTM3_SC)
#define FTM3_ADDR ((FTM_REGS_t*)(&FTM3_SC))
#else
#define FTM3_ADDR NULL
#endif
 
Last edited:
I believe pin 34 is E25, and from the library info:

"The pair (hsync_ftm_num, hsync_ftm_channel_num) defines the pin generating Hsync signal. Look at teensyduino's teensy3/core_pins.h file, CORE_FTM*_CH*_PIN

On teensy 3.6, valid pairs (not on port D) are:

(0,0) => pin 22
(0,2) => pin 9. This FTM can use pin 13 but you will have to configure it yourself and problem may occur due to LED on this pin.
(3,4) => pin 35
(3,6) => pin 37. This FTM can use pin 57 but you will have to configure it yourself."

This is why I chose pins 34 & 35.

I'm hoping that I've just got the parameters wrong, but if not I can rewire to the default case and work around the consequences. (The issue is if I use pin 22 for sync then I lose the first 8 bits of port C for my data byte.)
 
That code snippet looks odd - seems to imply FTM3 is disabled?

But the README says:

"1 FTM with 4 channels (on teensy 3.6, only FTM0 and FTM3 are possible. on teensy 3.2, FTM0 only). All others channels will be free."

Has anyone used this library successfully with the non-default setup?
 
Indeed - for some reason - that code is made inactive with the :: #if 0

Perhaps it causes use of unneeded resources, conflict or other reason when not required. Perhaps you can make sense of it ?

In the time I worked with the VGA - I had PCB's made to use default pins - suspect others did the same. Code hasn't been active in some time. Would be cool if @qix67 were around and even checked it to work with T4.

Just wondering if $8-$15 VGA>HDMI adapter would get a usable clean VGA signal to cable to HDMI. I didn't try that before. There is an HDMI board that works with Teensy - mentioned on T4Beta thread - but last version was like $60 - may be refined for newer boards?
 
Well I'll certainly try re-enabling FTM3 this evening when I get home. Fingers crossed it was just commented out for testing... :)
 
Got it working. The defines are a bit broken, so it's not just a matter of removing the #if 0, but it's not much more than that. I can't be sure that there aren't any other side-effects, but it seemed ok.
 
That is good news! Not surprised there was a bit more - easier to "#if 0" than to fix everything when it isn't actively used - at least that left a MARKER to start the changes needed.

I only looked enough to post info above. I've run it in the default state and found it cool - mostly after initial board I built I used it on the FrankB Teensy64 emulator PCB.

If you have github maybe do a fork and post your updated version. If @qix67 comes back it might help with a PULL request - if not then maybe further work can go from there.
 
Status
Not open for further replies.
Back
Top