Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: uVGA library with non-default pins

  1. #1

    uVGA library with non-default pins


    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.



  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Looked this up - been some time - lib it two years old :

    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 :
    #if 0
    #define FTM3_ADDR ((FTM_REGS_t*)(&FTM3_SC))
    #define FTM3_ADDR NULL
    Last edited by defragster; 06-25-2019 at 12:23 AM.

  3. #3
    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.)

  4. #4
    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?

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    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?

  6. #6
    Well I'll certainly try re-enabling FTM3 this evening when I get home. Fingers crossed it was just commented out for testing... :-)

  7. #7
    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.

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts