Search:

Quick answer: No.

My knowledge may be outdated, but as far as I remember the Pico can do either audio-in or audio-out, but not both. You would also have to see if it can provide mclk for the SGTL.

In the meantime...

Would be easier and save much time to just use a Teensy ;)

Hi,
use transfer(void *buf, size_t count) - that's the fastest.

..and..can you show us a photo? Is everything soldered?

This is the USB Serial. You may want to try Serial2 :-)

If that doesn't solve the problem, you'll have to show us some code - or better, all the code.
It needs to be broken down to a minimalistic...

That's the easy part. attachInterrupt()
Then, you can take a look at the audio-library SPDIF input and look at the code. Remove all the DMA stuff, and it is almost done..

The Audio library provides raw data. Just use the AudioRecordQueue: https://www.pjrc.com/teensy/gui/?info=AudioRecordQueue to read the data - and then print it.
What is printing useful for?

IMXRT1060 Reference Manual Rev2, Page 2028 shows that it can gegerate an interrupt depending on the fill-state of the FIFO.

Of course there is no example code to do that, as the audio library is...

Well, first it would be needed to define what "realtime" is.

Don't know why you posted this in Announcements - I moved this thread to "Audio".

Serial flash is - compared to other memory - incredible slow.
I don't think there is a way to make it much faster.

I would say the Pico would be more than busy with the sound emulation alone. The sound chip is very complex, and was the best of its time. The code for the sound emulation is quite complex, too.......

The ILI9341_T3 lib sets it to 119Hz. I did this some years ago by adding it to the init data.

Yes :-)
In the meantime I have now learned that __aeabi_uldivmod is used here for 64 bit data types.
So, everything is OK.

See this Forum, "Announcements".

All your files will be deleted when you upload a new sketch.
As far as I know it is planned to change that. May take some months.

Glad that it works now.

Yes, please!

Teensy 4, see title.
Do we have a bug with printf? Perhaps include a wrong library?
T4 shouldn't need integer divisions in software...
The added code is a) slow and b) very large... and not...

Teensy 4.1 builtin SD does not use pin 10. The Audio Board uses pin10 if you use its SD.
I think it should be natural to look at everything carefully before connecting anything, and I can't see an...

I'd double-check if you really need more than 400kHz instead. Humans tend to overestimate some things..

The audio shields uses Pin 15 - it's for the optional potentiometer and has a capacitor to smooth its readings..
It's always a good idea to take a look at the used pins before connecting something :)

Hi,
I never tried that.
The code uses the SD from an interrupt, so I'd expect problems.
You can try to surround your code by AudioNoInterrupts() [..] AudioInterrupts()n and make sure it computes...

How should the board connect to your instrument? Which interface? Or is it usb?

You can use the godbolt link I gave you, and modify the foo() function on the left to see the influence of different ways to write code. Even if you don't know assembler, you get an idea of what is...

Whenever you call set_arm_clock.. Or try to copy the lines form set_arm_clock (regarding the IPG) to your program.

The other things..and "assembler".
Note, it is not really assembler.

a)
This...

No I said the other chip just does not blink. The blink codes are not needed for boards sold by PJRC, because they are all tested.

The blink still indicates a problem that should be fixed, and you...

Yes these chips use a different firmware - for the normal 4.0/4.1 the blink codes are just not needed :)

Remember the pins are in swapped order.

https://github.com/PaulStoffregen/cores/blob/a2368ad57e9470608a234d942c55a2278c6cd72b/teensy4/clockspeed.c#L148

You could try to change the both "4" to 3 or even 2.. (600 / 3 = 200MHz or 600 / 2=...

I think we have to wait for Paul, and that he tests that board.

Hm that looks correct...

it's possible to overclock that IPG - in the past when I tried it, it was not 100% stable in every case. But it leads to pretty amazing speedup..

I tried it with godbolt: https://godbolt.org/z/dbbefx5K7
Looks like the compiler does translate the code above optimal (with -O2):


foo():

ldr r0, .L2
ldr r1, .L2+4
ldr...

Great .... :o)

You can try something like
{
uint32_t gpt1=GPT1_CR | GPT_CR_EN;
uint32_t gpt2=GPT2_CR | GPT_CR_EN;
asm("":::"memory");
GPT1_CR = gpt1;
GPT2_CR = gpt2;
asm("dsb":::"memory");
}

..and what is the format of the wave file? It needs to be 44kHz, 16 Bit, Stereo. Everything else does not work..

You are using
AudioOutputPT8211_2 pt8211_2_1; //xy=557,951

Are you sure you are using the correct pins? Can you show your a photo of your hardware, please`?
And did you try one of the...

If the ADAU is I2S compatible, the timing is not an issue.
a) did you close the jumper R15?
b) How did you sample it? It works with 1.8V levels.

24374

Add some Audio memory..


void setup() {
AudioMemory(20);

Hi Chichiwoof,
yes, you'll need the latest Teensyduino beta.

Most likely the problem are all the out of bound accesses to the array (Post #6) - there may be more than the String strings[5] array.
ist has 5 elements. the first is [0] - the last element is [4]...

AH...
Not sure if this is the case here... but it almost looks like!
Sounds it reasonable when I say the freeze is about 1.6 .. 1.7 seconds?
If yes, please try to update Teensyduino to 1.54 Beta...

String strings[5];//

An array with 5 entries.

Pretty fascinating that this works on AVR..


for (int i = 0; i <=5 ; i++)
{
strings[i]= myString.substring(0,myString.indexOf("|"));

all the code in this style

void thirteen()
{
digitalWrite(demux0,LOW);
digitalWrite(demux1,HIGH);
digitalWrite(demux2,HIGH);
digitalWrite(demux3,LOW);
digitalWrite(0,LOW);
...

Normally, a freeze is a hardfault.
Unfortunatley, Teensyduino jumps to a endless loop, then, instead of showing them ;)
I'd look for array / buffer overflows, nullpointers, etc.

Note, there is a newer revision (Rev.4 10/2019) of the Hardware Development Guide on the NXP website than the one mentioned here: https://www.pjrc.com/store/ic_mkl02_t4.html (which is Rev 0).
Needs...

Can you post a photo of the hardware you built? (i.e. the connections of the board and display should be clearly visible)

Oh... the comments are not very enthusiastic.

again, you use pins that are used by the audio board.

Perhaps we should review the PAD settings for I2C and use very conserative settings.
From my experients they work well, even for higher I2C speeds and may cause less problems.


edit: Perhaps the...