jonr
Senior Member

It would be really nice if the flasher code could directly accept any .hex lines it is likely to receive.

I would study the example below. Look closely at how/where "client" is set. https://gist.github.com/atomsfat/1813823

> A simple hardware diagnostic using patterns of red LED blinks is also planned Nice! - black boxes are hard to debug. Would be very helpful to distinguish between "loader can't talk to MCU", "crystal isn't working"...

That is my concern. Some protocols are likely to lose exactly an entire line. This could get flashed and the error might not be immediately obvious.

> you need to type in ":flash XXXX", where XXXX is the number of lines reported by the program I recommend that you don't do this. Type in ":flash XXXX", where XXXX is the number of lines you counted in your hex...

For speaker analysis and correction, this is great. https://www.roomeqwizard.com/ If you want to do convolution based correction, then just use the impulse response from REW and also use...

Yes, specifically "fast, partitioned convolution".

While it's only necessary for high resolution at low frequencies, I am able to run 12288 taps, stereo.

OK, I checked and some notes: T4 with a small heat sink attached It runs about 45C (far far different than the graph) Slowing from 600 to 528 is only a couple of degrees cooler wfi makes no difference extern...

In many cases, one could include this in their idle loop, which I understand reduces power/heat more than slowing down to 450 mhz. asm volatile("wfi");

My guess is that at 450 mhz, it will last a very long time. And most applications won't notice the slower speed.

There was some discussion of strlcpy(). IMO, don't just use it, use it and check the return value. Ie: if (strlcpy(dest, src, sizeof(dest)) > sizeof(dest)) handle_error();

3 years life at 600 mhz - that could be a problem.

Sure, you could pack four 10 bit samples into every five bytes. But consider other approaches - like a teensy 4.1 or a larger sd card.

My experience is that paste is better, even when you don't have a stencil. But I save time and frustration - unless JLCPCB puts most of the parts on, I always order a stencil. More advice - use a syringe + tubing to...

I agree with tomas. Is there a tool for predicting how many bits you need for how much distortion?

Consider either headphones (low bass with low power) or a subwoofer (which will need size and power).

For about $15, you can buy an external TOSLINK DAC box. Not the lowest cost option, but will probably outperform the PT8211.

Yes, it works on both 4.0 and 4.1.

See here for a newer, better teensy 3.x version: https://forum.pjrc.com/threads/43165-Over-the-Air-firmware-updates-changes-for-flashing-Teensy-3-5-amp-3-6

Nice work Joe.

I use the audio library with USB input and SPDIF optical output. I have no noise issues. You haven't explained what you need to do, but stay digital as much as possible and if you have to do a A/D or D/A conversion,...

Nice! Can you make a iMXRT1062 version too? :-)

For less noise, you should be doing a differential read on two analog inputs.

What options are available on a teensy to do bounds checking? Ie, what's the easiest way to find the above error?

IMO, the memory allocation details should be abstracted away for the typical use case. Ie, a single mallocX() call where you optionally pass it a hint as to the speed desired (or other requirements like DMA...

I'd use the existing routine for writing blocks. Specifically: void eeprom_write_block(const void *buf, void *addr, uint32_t len)

I'm curious, is there any reason that the library shouldn't have an empty constructor and do the initialization in begin()? In any case, just crashing is poor design.

My understanding is that if you omit the stop, then the bus isn't released and, with your slave chip/application, the following start isn't needed/tolerated. But the libraries don't provide a way to do this.

Good that you found something that works. As I see it, your application could use less buffer space if it had something like this for all but the first and last portions: endTransmission(omitStart, omitStop);

You should post your actual code. I don't know much about it, but possibly use wait_idle() between partial writes.

Can you do many smaller writes? What is the target chip and software running on it?

There is a nice spreadsheet coefficient calculator/visualizer here: https://www.minidsp.com/applications/advanced-tools/advanced-biquad-programming +1 on using the teensy code (see...

> The geometric mean gives 965Hz, i.e. 35Hz bellow the 1000Hz I get: sqrt(1390*720) = 1000.4 Hz

If you really need a custom iMXRT1062 design now, then I'd design it for both a MKL02 and a jtag connector.

>but not symmetrical around 1000Hz. You should use the geometric mean and with that, it is symmetrical.

You might as well get used to the teensy way of debugging. Lots of print statements, sometimes with a Serial.flush() followed by a delay.

Two questions: I use partitioned fast convolution to greatly reduce filtering delays. Can't partitioning be used for this application? If one does use 96 biquad bandpass filters (which seems feasible), does the...

I only looked at it briefly, but that code appears to be doing a FFT and then combining bins. Not clear why so many people write code without comments.

Agreed, the typical person watching is likely to prefer larger bins and less delay. You can still use the same number of lights, probably most people won't notice the lack of accuracy on the low end.

+1 on combining bins. Say you down sample to 11K sps, then run a 22,000 sample FFT. Each bin would represent .5 hz. The DD4WH code is an example of large FFTs.

If one is going to mix digital circuitry with analog audio, better to use differential/balanced for the audio. Or stick with digital audio (eg, an i2s microphone).

Is the teensy loaded with code that emulates a serial port?

With com0com, you would just have to write the code to move bytes over TCP. http://com0com.sourceforge.net/ Or possibly this: https://tibbo.com/support/downloads/tdst.html

Very minor change - leave interrupts off when done flashing.

With interrupts, it's critical to be clear about during which stage. The first when data is being moved from input to upper flash and the second when upper flash is being moved down to lower flash. There were some...

The ESP-01 seems like a good fit.

I didn't look closely at what you are doing, but in general, for low jitter input, you can disable interrupts while waiting for the next pulse. Or use an interrupt of the highest priority to capture pulses.

I would have some use for a teensy version of OpenLog that uses MTP over usb. But would have to have similarly low power consumption.

A fine but important point. When you use the teensy clock to measure a ratio between two external clocks, drift in the teensy clock is mostly irrelevant. Because it effects both measurements equally. Jitter goes...

When you talk about "ground", you need to specify which ground. For example, the teensy could have one ground and your other equipment could have a different ground. Don't connect these grounds together and the teensy...

Note that if your teensy and the other equipment don't share a ground, then the ground of the other equipment can be at the teensy VGND level. Ie, it can work, even without balanced inputs on the other equipment. ...

Depending on volume, I'd try hard to have all parts on the same side (which appears to be possible in this case). After being fooled too many times about solder bridges, I stopped connecting adjacent pads directly...

Has anyone verified that grounding PTA1 (or more likely PTA3) on the MKL02 disables it properly?

The ADC makes sense if the audio signal will always be in the 0-3.3V range.

What is the voltage range of these "audio signals for timing"?

To reduce confusion about which serial port is which, I've added the SYMLINK option to the teensy udev rules. IMO, something like this should be standard. KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0",...

> Actual result: Just the i2c address is written. The clock only transmits 8 pulses. i2c on t4 works fine. Here is a relevant quote from a description of the protocol: "Each byte of data (including the...

> T4's USB data stream is too fast for some interfaces sounds plausible.

Absolute max on the input voltage to the T4's TLV75733P regulator is 6V. So 5.5V max is recommended.

I recently wrote some quite similar code (for exact audio clock matching). When you are ready, send me a message if you want the code. Basic technique is to measure clock A with the teensy clock and clock B with...

I'd feed a GPS 1 PPS into a teensy 4 and not use an external oscillator. The teensy will be able to measure the 1 PPS and pendulum signals with its 600 mhz clock.

Yes, but the reverse should work if you use: Adafruit_SSD1306 display(128, 64, &Wire1, -1, 1000000); Ie, the SSD1306 is easy to move to different connections. The temp sensor is best on SCL0 / SDA0.

To the extent it is possible, my opinion is that it's better to fix and add features (clock sync, more channels, more bits, different rates) to the teensy4 USB audio code.

If that doesn't work, it looks like it would be easy to move the OLED display to SCL1 and SDA1.

What's the problem that is being solved? I use the T4 and PC->teensy audio over USB works fine. The PC matches rate to the teensy clock, but if for some reason I wanted the teensy to match the PC clock, that is now...

It's common in electronics and many other fields: "X worked once, so X is good practice".

Could be a short elsewhere. As I see it, your power pin next to D4 goes to a via - not a decoupling capacitor.

You are using a 10A driver and then limiting it to 40mA of gate current. Use something far lower than 300 ohms.

You should have a decoupling capacitor on every MK20 3.3V line, close to the MK20 pin. Which of these is the case? a) MK20 is loaded and running, just not talking to USB b) MK20 doesn't start up and keeps...

It would be easier if you also wire the MLX90614 to SCL0 and SDA0.

If you have a program that is crashing, standard practice is to add print statements and delays to find out exactly where.

If you are building a PCB anyway, consider adding a better ADC to it. Preferably differential. If not, use some oversampling plus a trimmed mean for less noise. Might be useful to have an extra calibration channel...

I think you are going to have to do some testing. Which will provide more accurate answers anyway. Share the results.

I'm aware of teensy boards or boot loaders in some commercial, low-moderate volume products. Higher volumes, low support costs - so I'd guess that the economics of this are far more attractive than selling single...

Some answers here. And more if you search this forum. https://forum.pjrc.com/threads/23447-Teensyduino-analogReference-(INTERNAL)-same-as-default

Indeed, most of it is with -E. The sketch itself is recompiled and then everything is relinked. It's quick, so not an issue - but I expected it to do nothing (since no files have been touched). Maybe it's the price...

I'm curious, why is it recompiling all kinds of things that didn't change? It happens for me too (Linux, just by hitting verify twice).

I've blown two speakers. In both cases, the tweeter, so DC offset had nothing to do with it.

Generally yes, sending audio over ethernet and/or IP is increasingly popular. Teensy doesn't have much support for it, but there is this: ...

I have a philosophical question about clock sync. Which is better for teensy related, separated audio clock use cases? a) just match rates b) match rate and phase (like a PLL). If clock A is slightly slower...

I've seen debug log messages like "value too high", which leaves me lost as to what it means and how to fix it. For some use cases, consider using something like: LOGD("%s %d %s", "Debug", __LINE__, __FILE__);

Here is some very general advice. Learn the basics of LTSpice and use it, even for simple circuits. Never perfect, but it's a great way to learn things like "what would happen if I injected a little noise here".

I have some code working that will take a periodic input from any source at any frequency and adjust the teensy audio clock to match it. For example, I'm syncing to a PC sending a single byte via serial every second. ...

I tried it and while changes to CCM_ANALOG_PLL_AUDIO_NUM clearly changes the clock rate, it isn't a simple ratio. You could use trail and error to find the right value. Or use the c1 value from the nice spreadsheet...

I think so, but let us know. I'm working on some code that will calculate the correction ratio to apply from any kind of periodic communication. But a fixed ratio is fine for some uses.

AUDIO_SAMPLE_RATE_EXACT is a compile time setting. You are looking for a run-time clock change, which has to be done differently. Using Paul's recent discovery, should be something like: if (pin) ...

> a virtual GND of 1.65V and power the AD8224 with +-3.3V)? You would want the AD8224 to operate without a virtual ground. And the 2nd stage needs power too. Probably not worth the changes, I'd go with one of...

It could be "what the teensy clock registers are going to be initially set to". Which, glancing at AudioStream.h, is already sometimes a non-integer number.

I could see a use for an AUDIO_SAMPLE_RATE_NOMINAL that would always be 44100, 48000 or etc.