Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 28 of 28

Thread: Query speed limit teensy 4.1

  1. #26
    Junior Member
    Join Date
    Sep 2020
    Posts
    11
    I understand that you don't like the way I have sent you the DAC designation. I could have put it with text, much simpler the truth although I understand that I gave you a look without bothering to search the internet.

    The DAC works perfectly even above 250 Msps (since I have tested it with an arbitrary 16 Bit word generator, and by the way the clock must be synchronous to the data with the delay guard indicated in the graph of times of the datasheet. I don't want to put a clock that goes independently of the data (actually it was an initial idea, but it caused a lot of jitter in the A/D output since possibly many clock upload slopes were matching with input data ( 16 bits) in an unstable situation, for that reason I discarded an asynchronous clock to the data (and by the way I even tried with time bases that I have very high stability (Rubidium) and the jitter in the asynchronous case that you mention was uncontrollable.

    It is true that with the external clock I could forget to generate it in TEENSY 4.1 itself and eliminate the two sentences

    digitalWriteFast (.. HIGH);
    digitalWriteFast (.. LOW);

    which in the end eliminated 2 nS + 2 nS = 4 nS from the total of the time, what the DAC suited him wonderfully.

    I discarded the external asynchronous clock also for the reason that as it happened to me in the previous DAC904 of the current one, they do not have CS (selector chip) and one way to do it is to simulate it by the clock (in the case of putting more than one DAC in parallel).

    In any case, thanks for your explanations.

    By the way, I have generated a clock signal from the data itself (bit change), although apparently it works, I don't like the circuit idea that has to be implemented (I refuse, do something in hardware that I think can be done by firmware in the CPU, true that it will be necessary to scrutinize the deep knowledge of this CPU and travel to the bottom of the assembly).

    To your question about how I am using TEENSY 4.1, I already think I have commented on it ... I have it forced to 1GHz clock (with the corresponding heatsink) I have even given it the possibility of dynamically modifying said clock:

    #if defined ( __IMXRT1062__)
    extern "C" uint32_t set_arm_clock (uint32_t frequency);
    #endif

    Although executing that complex statement takes 2 uS (since it has many synchronization waits of the CPU's own buses) but these statements do not fall within the problematic DAC that I have open since they are not in the data sending loop between TEENSY 4.1 and DAC.

    Gracias un saludo

  2. #27
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    626
    Outputting a clock signal as a 17th bit in the data is a good idea to reduce instruction count. Could delay it and use it with a clock doubler - so a single instruction per DAC output. Or output data at 2X the expected rate with just the 17 bit alternating (no additional hardware, two instructions per DAC output).

  3. #28
    Junior Member
    Join Date
    Sep 2020
    Posts
    11
    Yes, YES, YES sir jornr an "ole" for smart people.
    You have just given me the GREAT IDEA with which I have managed to load 2 nS of the whole process, thanks to your suggestion it is not necessary to set the CLOCK bit to LOW it sets itself with the sending of data.
    Thank you thank you thank you.

Posting Permissions

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