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