Search results

Thanks all, After I realized I was looking at the wrong pin, and using Manitou's guidance, I whittled my code to: void PWMPhaseShift(void) { // will use FTM2_CH1 FTM2_SC = 0b00001000; //clk src = System; div 1 FTM2_MOD = (1000-1); // F_BUS/1000 FTM2_C1V = (1000/2-1); // Duty Cycle...

I have a measurement instrument that is already using FTM0 and FTM1. I want to generate a 48 kHz (FBUS/1000) signal on the Teensy's pin #25 (PTB18), the duty cycle doesn't really matter (squareish). I can't use the timers because their PWM output is slightly jittery (20 ns; occasionally more)...

I can confirm that (by using ARM_DWT_CYCCNT) it is working as desired now. 48 h and no spurious values for Phase.

I'm going to try using ARM_DWT_CYCCNT. Since the intermediate multiplication result can overflow, I used 360LL to force a 64-bit calculation (the final result won't overflow). (setup): volatile uint32_t PhaseMicrosARM0=0; // From internal counter; not really microseconds. ... (60_Hz ISR)...

Thanks all. 1) I now see the purpose and use of _LDREX & _STREX. I expect this should also work if an interrupt was nested between them that also used LDREX/STREX (around some completely different variables); likely the outer _STREX would also fail (falsely), but would succeed the 2nd time...

Thanks -- I'll insert some debug code. I did try to look at the compiler listing: 1fff895e: f000 f84b bl 1fff89f8 <__micros_veneer> 1fff8962: 4b1e ldr r3, [pc, #120] ; (1fff89dc <ftm1_isr+0x124>) Phase = PhaseMicros * 360 * Target_Hz / 1000000...

I have 2 external pin interrupts to my Teensy 3.2 (48 MHz)-- one at ~60 Hz, the other at 1 Hz (see project at https://github.com/jp3141/60Hz) Here's (what I think are) the relevant parts of the code. The main loop prints the value of 'phase' every approx. 5 s. Phase should be between 0 and 360...

This uses a Teensy 3.2 and its FTM to precisely measure the frequency of the AC power line. An external GPS provides a 1 pps calibration pulse to continuously calibrate the Teensy's 48 MHz clock. Data is logged via a Raspberry Pi 0 W. A 9 V AC adapter powers the system and also provides the 60...

You might have an oscillation. You'll never observe an opamp's settling time with a multimeter -- it's in the us range at worst. You don't really need the extra input resistor anyway; opamp input offset will likely cause a greater error.

Yes. The input signal is the resistance. You can power the sender from any voltage -- the 3.3 V supply on Teensy is convenient. In any automotive system, you need to protect against transients and noise. So, from the 180 Ω .. Sensor tap point, use a 10k resistor to the ADC and 0.1 uF to GND at...

You don't really need an opamp. If you don't need perfect accuracy, connect 2 resistors in series between the +3.3 V and -3.3 V line that you want to measure. Connect the junction to the ADC input. Make the R to the +3.3 V slightly lower in resistance than the other one -- say 10k to +3.3 V...

for this part - "Also, the 1/15Hz = 66,666 us. (mark of the devil!) which is > 65,536." --could you have a timer for 1/30 Hz and then in the callback just skip every 2nd one ?

Try this -- connect one input to VDD (3.3 V), and the other to GND. Then run a small sketch that reads alternately between the two inputs -- see how slow you have to go to only (mostly) see codes near 0 and near full scale.

The reference for the ADC is the VDD (3.3 V) supply -- from a TLV75733P. This only has 1.5 % accuracy, about 200 uV p-p noise in the BW you are using, and probably a change of a few mV over the temperature swing. This will contribute an error in the ADC reading proportional to the input voltage...

Yes, that spike could be bad. Add 1k in series with the input, or just in series with the 10 uF. You don't need to use 1k & 220 Ω -- they make the cutoff frequency too high for audio (10 uF & (220//1k) = 10u&180 = 88 Hz; They also set the bias point unnecessarily low (around 0.6 V) -- so just...

Be careful -- a very large DC offset on the input (say 5 V) could damage the Teensy when it is initially plugged in because the initial step as the 10 uF is charged will be driven straight into the A2 pin. If this is a possibility, put a 1k resistor in series with that 10 uF.

I looked at interrupt-driven ADC conversions some more. Using this ISR: FASTRUN void ADC_loop(void) { digitalWriteFast(admarkpin, HIGH); adc->adc0->startSingleRead(A9); // start a single conversion digitalWriteFast(admarkpin, LOW); adcbuffer[adcidx] = adc->adc0->readSingle(); if...

At 8 bits, quantization errors possibly make STDEV analysis inaccurate -- you may have a DC input that falls well within an ADC conversion step, thus giving 0 STDEV (even with some noise on the signal (LSB = 12.9 mV). On the other hand, if you are just at the edge, you can get a STDEV of (12.9 /...

@borgerson -- yes, it compiles; I don't think the variable sizes are the problem. What seems to be happening is that at > 10 bits resolution, I can't run 1 ADC at 1 MHz - I need 500 kHz for 12 bits, and about 200 kHz for 16 bits. I'm trying now to understand why that is. Undersampling a signal...

Thanks all. It seems like NVIC_SET_PRIORITY(IRQ_PIT, 1); and myTimer.priority(1); // set high priority have the same effect of raising the priority. Furthe looking through my code, it seems that the delay() function in the loop() is the culprit. With delay() in the code and priority(1), I...

@mborgerson, I can't get your 1st post to work on a T4.1 (with a PSRAM also) at anything other than 8 bits. Am I missing something simple ? I have tried changing these lines: adc->adc0->setResolution(8); // set bits of resolution...

But how can I find what other interrupts are using priority 0 and move them to (say) 8 ?

But how do I do that specifically ? I don't know the interrupt number. I tried NVIC_SET_PRIORITY(IRQ_PIT, 1);? and ...,0); -- that helps and reduces the jitter from 10's of us to about 1us. I guess I need use the hardware directly and likely DMA to get 'zero' jitter ? Presumably there are...

I have a simple demo on Teensy LC that generates an interval timer interrupt nominally each 10 ms and toggles a pin. However the interrupts (or pin toggling) don't come at precise intervals. Here is a screenshot -- note the narrower pulses are not caused by the interrupt coming early, but by the...

It probably won't damage anything -- the '5 V' will rise to the highest of the USB voltage and the external supply. In the worst case, the USB power supply will current limit or shutdown (in some MacBooks, you'll have to reboot to reset it). Most power supplies can handle their output being...

Where did digitalToggleFast() come from ? I can't even find it on Google. What other useful functions am I missing ?

Given that it is driving a mechanical system, the requirement to have the phase change smoothly by 'x' ns every single cycle isn't real -- it just requires that the average does this. It still does require that the 2nd frequency cycle through 360 deg every minute -- so the frequency is...

There is only a single DAC output on the Teensy's. But your VOR probably doesn't really need a sine wave -- likely a square wave will do, and you can generate those from PWM signals -- to get your phase shift of 360 deg/minute, he 2nd channel would run at (400 + 1/60) Hz. Note that the VORs...

There has been some interest in this question. I setup a test with a Teensy_LC where I supplied an external DC signal, and monitored it with both the Teensy and an Agilent 34410A DVM using USB for the Teensy and the Ethernet on the DVM. It turns out that (especially at 16 bit), noise in the...

Try load this file https://github.com/tloimu/adapt-ffb-joy/blob/master/downloads/adaptffbjoy-r54.hex by using the Teensy application (File..Open HEX File).

My favourite tool :D For Windows users - here's a copy of AWK: https://sourceforge.net/projects/ezwinports/files/gawk-5.1.0-w32-bin.zip/download

I'm back on this again. I created a simple script that I run manually to generate a #include file. The script is: awk 'BEGIN{print "Serial.println( F( \\"}{gsub("\"","\\\"");print "\"" $0 "\\n\""}END{print "));"}' *.ino > printme.h which generates a file containing the program as a long F()...

Can someone please post an example of how to do this ? I'm confused over the number of endpoints I need; where the unique number is for each interface (is it 'PRODUCT_ID') ? Is DEVICE_CLASS necessary ? Also, I'm running on MacOS Catalina and changes I make to usb_desc.h don't show up in the...

Thanks -- that works, but I agree it's quite twisted; I'll wait until I am really out of memory.

Thanks @JarkkoL -- that's closer to what I was aiming for, but I was hoping (for clarity) to have it all on one line without having to invent new names for all the intermediate variables like pulseOn[] -- I'll have a couple of dozen of those. I guess C can't do something like: Key keyOn =...

I am trying to initialize an array as part of a structure variable, but the compiler options in place on Arduino seem to require that the array size is predefined. Is there a way around this ? Ultimately, different instances of my Key structs will have different lengths for the Pulse[] array and...

If you are just interested in the average current, then most measurement systems will actually do this by default -- they don't (instantaneously) sample the signal and then digitize it. For instance, the TI chip you mention will filter (== average) the signal. If you are interested in the peak...

I do that too, but with many computers of different vintages and locations, it's not unique enough for me. I'd like something like (I know this won't work) where the #include basically loads the contents of FILE as a string. One reason it won't work is FILE will contain quotes and other...

I suspect this is not possible, but is there a way (in the Arduino environment) to have a program print its own source code for documentation purposes ? I'd like to be able to do this as part of the standard compile process, not as an extra step. I have many programs on various Teensy's and...

what works really well is to run through the array, and with a probability p, change it from off to on. If you want 10 % of the LEDs on (on average), then p is 0.1 etc. This keeps the whole set of LEDs working randomly.

15 V might be a little too low for the TVS -- as the battery goes bad (but not failed), the voltage could approach 15 V -- together with the TVS tolerance, it could cause some current to flow and it might overheat (and not blow the fuse). Try 18-24 V version. if you care about keeping...

You can't connect the 'A0 COM' connections together from the multiple rotary switches -- you won't be able to read the switches independently (or correctly). You can connect multiple Teensy analog input pins to the same 'A0 COM' and read it on all those channels, but why ?

If you have problems with signal amplitude, you could use this. It uses the analog comparator in the Teensy and can detect 200 mV 10 MHz signals. Put your signal on pin23, and connect the output from pin10 to the frequency counter. More info at...

1) jitter: you can't easily remove this. If you 'just' remove the last bit, you'll still have errors when the result crosses the next-to-last. For instance, say the numbers were 1..1000, and you had 567/568 -- you could remove the last digit and have just 560 steadily. but, say the code was...

You are asking too much. 1) The ADC can always have a jitter of +/- 1 count -- imagine the input voltage is just on the border between two conversion codes -- depending on noise etc, it might return one or the other value. 2) The pot isn't that stable (or repeatable) -- why does the jitter in...

0.1 mV for a 100 mV signal requires 10 bit resolution (log2(100 mV/0.1 mV)) -- the ADC can do that (it has 16 bits. but realistically only ~ 13 are 'good'). With a 1.2 V reference, the LSB is 0.14 mV. If you use the PGA (programmable gain amplifier) you can scale your input signal by 8x (so it...

There is a sufficient amount of digital IO on T 3.2 etc. This IO is 5 V tolerant -- i.e. it survives 5 V being applied, but can only output 3.3 V. The ROM uses 5 V, but the datasheet indicates that the input threshold spec is 2.2 v, so it likely will work.

See my code in thread https://forum.pjrc.com/threads/30822-Teensy-3-1-and-Flextimer(s)-Counting-external-pulses-accurately -- checking for 24 h with 15 MHz on pin3 and 20 Hz on pin A2 shows no errors. It does 'waste' ~ 10 us in the ISR routine though which I'd prefer not to do. *EDIT* -- I'm...

I think I have this figured out. When the FTM overflows and an input capture occurs nearly simultaneously, it is difficult to know which occurred first, and therefore if the pre-overflow or post overflow counter value should be used. My solution is to compare FTM1_C0V and FTM1_CNT at the...

Thanks @robsoles. I see what you are doing, but that won't work for me -- I trigger a capture with the FTM Channel 0. I am leaning towards not generating an interrupt with a Channel 0 event, just polling it at each FTM! interrupt, but I don't have that working properly yet. Your code possibly...