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

Thread: 12-bit parallel data Vs FTM's

  1. #1
    Member
    Join Date
    May 2019
    Location
    Brisbane, QLD
    Posts
    50

    12-bit parallel data Vs FTM's

    I'm trying to figure out which pins to assign to a 12-bit parallel data line (all sync'd). At first i thought I'd group the pins by GPIO port, for example on t3.6 GPIOC has pins 15,22,23,9,10,13,11,12,35,36,37 & 38 as the lower 12-bits. But then i realized that these don't share a common FTM timer;

    15 - Unknown
    22 - FTM0
    23 - FTM0
    9 - FTM0
    10 - FTM0
    13 - UNKNOWN
    11 - UNKNOWN
    12 - UNKNOWN
    35 - FTM3
    36 - FTM3
    37 - FTM3
    38 - FTM3

    First obvious question. Are FTM's only associated with pins marked as PWM on the teensy board?

    2nd question, does it makes sense to simply group together data lines that should be sync'd to a common FTM timer, so you don't ruin the ability to use PWM's (say as 8-bit analog outs) associated with other timers? My idea of grouping them by GPIO port was to grab all 12-bits in one go as a single variable, without a common port I'd likely default to digitalReadFast and digitalWritefast commands one by one, maybe a slower than the all-in-one-go option?

    Is this a complete list below of pins associated with FTM timers, or are ones on the back ignored?


    Board Timer PWM Pins Default Frequency
    Teensy 3.6
    FTM0 5, 6, 9, 10, 20, 21, 22, 23
    FTM1 3, 4 488.28 Hz
    FTM2 29, 30
    FTM3 2, 7, 8, 14, 35, 36, 37, 38
    TPM1 16, 17

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,176
    Quote Originally Posted by martianredskies View Post
    First obvious question. Are FTM's only associated with pins marked as PWM on the teensy board?
    Yes. The FTM and TPM timers create the PWM signals, so only the pins shows as having PWM are connect to the channels of those timers.


    2nd question, does it makes sense to simply group together data lines that should be sync'd to a common FTM timer, so you don't ruin the ability to use PWM's (say as 8-bit analog outs) associated with other timers? My idea of grouping them by GPIO port was to grab all 12-bits in one go as a single variable, without a common port I'd likely default to digitalReadFast and digitalWritefast commands one by one, maybe a slower than the all-in-one-go option?
    You're asking for an opinion of what "makes sense", but not giving much insight to *why* you want to read 12 signals at the same moment and how that relates to use of a timer.

    On a purely technical level, maybe having the timer trigger a DMA channel which reads all 32 bits of a GPIO port "makes sense". Then you'd later have code pull out the 12 bits from the 32 bit value written to the buffer in RAM. While DMA has latency and some variability in timing to access the bus, those vary much less than interrupts or other software techniques.

    But maybe you're going to do something as immediately as possible with the 12 bits? In that case, DMA might not "make sense", since it's efficiency and fairly consistency latency are mainly useful for storing data into a buffer, which you later read when it's full or half full. If you're going to do something like generate another output as quickly as possible, then you'd want your code running ASAP. A timer interrupt with FASTRUN and highest ISR priority might make more sense for that use.

    Use of 12 digitalReadFast operations certainly takes more time than reading the whole 32 bit GPIO register all at once. But it's much more flexible for assigning the pins. There are probably many scenarios where you'd want to use certain pins for other stuff, so the trade-off of more time taken to read 12 signals might be worthwhile. Again, very hard to know what "makes sense" without insight about the project.

  3. #3
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,673
    ...and it would be useful to know what speed-requirements you have.. often, it makes sense to tell more about a project if help is wanted.

  4. #4
    Member
    Join Date
    May 2019
    Location
    Brisbane, QLD
    Posts
    50
    Speed would need to be up to 2mhz. Iím designing a harware module that acts as a man-in-the-middle between a keyboard assigner cmos (that reads a keyboard matrix and generates a 4-bit keycode signal) and the sound chips onboard the keyboard (that responds to 4-bit keycode).

    The 4-bit code is done in a serial manner (per bit) at 1mhz clock in a 54us period.

    Iím gonna need 12 datalines all syncíd to the master clock, that could possibly go up to 2mhz. 4 data lines inís from the keyboard, 4 data lines out to the sound chips, 1 for master clock out, 1 for sync clock in (every 54 master clocks) and an additional 2 1-bit serial data lines that control some additional sound aspects on the sound chips. All of it needs to be immediate, as iím still gonna use the hardware keyboard assigner cmos to generate the keycode from internal keyboard and also the sync signal

    Iím also likely going to implement a ring/circular array to handle read/write for all data lines.

    I guess the bottom line is that there isnít a gpio port that offers more than 8-bits that share a common timer or have no timer associated. So iíd probably have to do two port reads, one for 8-bits, and another for 4-bits.

    GPIOC : 22,23,9,10(bit 1,2,3,4 FTM0) + 15,13,11,12 (bit 0,5,6,7 no timer) - first 8-bits

    GPIOD : 6,20,21,5(bit 4,5,6,7 FTM0) - last 4-bits

    Choosing those pins would at least have the bits sequential(ish).

    I do like the ease of digitalReadFast and digitalWriteFast, but if i can handle it in two swipes vs 12 iíd rather try that first.

Posting Permissions

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