Teensy 4.0 First Beta Test

Status
Not open for further replies.
duff said:
Just got my T4 and expansion board yesterday, just been poking around for now. Going to work on the low power stuff soon but it looks like I will have to mess with the cpu speeds, voltages and multiple PLLS + Doze bits to get this thing into the real low power modes.
Click to expand...

May not help, but in testing the NXP EVKB eval board, there was a low power SDK example in
boards/evkmimxrt1050/demo_apps/power_mode_switch/

The example changes CPU speeds and exercises various sleep modes, but the API etc. is unlike the T4 core code, but obviously the underlying register manipulation is common. See
https://www.nxp.com/docs/en/application-note/AN12094.pdf
and https://www.nxp.com/docs/en/application-note/AN12085.pdf
and 1060 low power doc https://www.nxp.com/docs/en/application-note/AN12245.pdf
 
Last edited:
manitou said:
May not help, but in testing the NXP EVKB eval board, there was a low power SDK example in
boards/evkmimxrt1050/demo_apps/power_mode_switch/
Click to expand...
Thanks I did not see this before it definitely helps.

I know what was wrong with my optimized fft issue, had to change define about using Kinetis K chips. Even with dsp v1.5.1 it still beats the stock 1024pt fft with the T4:)
 
hi, got my beta board (thanks!) and trying to read/catch up ...

quick question, on p.1 it says "stuff confirmed working [ ...] works ADC". that's re analog.c, right? or the "ADC" library? (in which case i can't seem to find it, just https://github.com/pedvide/ADC )
 
Frank B said:
@Defragster:
I had to do the following changes to make LTO work:

...

Can you review that, and (maybe) do a pullrequest for Paul? Thanks :)
Click to expand...

Frank - please check edit as made for PaulStoffregen/cores/pull/358

I just pushed up a working github.com/Defragster/T4_demo/.../debug_tt. It allows checking code flow to a failure point etc, and Trace records - even in _isr()'s to print later.
Two working/updated examples are xxx_tt. It works on T_3.6. On T4 it works the same unless the processor is faulted. With UART Serial.flush() 'edit' then the prompt code is just a tease because Serial input is broken. USB needs updated for input - but will display on output.
 
manitou said:
? I don't think pedvide's ADC library has been ported. github site doesn't show T4 activity.
https://github.com/pedvide/ADC
Click to expand...

@manitou

Just looked at the ADC lib that is part of the Teensyduino install - and you are right it has been ported yet that I could see, at least by looking in the example and a couple of the files. Probably should remove the annotation "works" from ADC on page 1 if this is the case.
 
The T4 ADC is different from T3* and there is no PDB, so pedvide's lib will need some work. DMA is about the same. I have a simple adcdma example and and a PIT+XBAR+ADC example that clocks the ADC from PIT timer via XBAR, see
https://github.com/manitou48/teensy4

The teensy core ADC stuff (analogRead() etc) works.

Probably should remove the annotation "works" from ADC on page 1 if this is the case
Click to expand...
ok, edited status on page 1.

ADC DMA performance
With the default Teensy core ADC configuration (10-bit resolution, no averaging), I can get 222464 ADC samples/second with DMA and continuous mode. With a "faster" configuration (no long sample, no clock div, fast sample, 20 MHz ADC clock), for 10-bit I can get 779776 samples/sec. For the 8-bit ADC, the ADC speed is 935936 samples/sec (1.07 us/sample) with a 20MHz async ADC clock. The reference manual (63.5.4.6.3) calculates 1.3 us for fast 8-bit ADC assuming 20 MHz ADC clock. With polling and the ADC in 8-bit continuous mode, I measure sample speed at 1.07 us.
 
Last edited:
manitou said:
DMA is about the same. I have a simple adcdma example and and a PIT+XBAR+ADC example that clocks the ADC from PIT timer via XBAR, see
https://github.com/manitou48/teensy4
Click to expand...

that i've found, perfect. thanks. trying to get something like the 'flexible scan mode' working, we'll see. ... i've only had the thing for a couple of hours; still have to digest a lot (like is ADC1_HC0 equivalent to ADC0_SC1A, so i'd just use a second DMA channel (as with T3.2) to cycle through a set of "Input Channel Select" ids (p. 3165)).
 
With beta9 I get the cryptic memory error (section `.bss' is not within region `DTCM') with this sketch:
Code: 
#define BUF_SIZE 30066
uint32_t buffer[BUF_SIZE];


void setup() {
  memset(buffer, 0, BUF_SIZE * sizeof(uint32_t));
}


void loop() {


}

I assume there is a boundary issue with the memory section 'DTCM'? If I use a buffer size 30065 it compiles and says I have used only 48% of available memory. I have tried to read through this thread but didn't see this exact issue come up, maybe it did? 30065 words is almost the entire 128k of the DTCM section maybe add the memory section and whats what to the first comment on this thread?
 
@Paul:
I'm working on SPDIF, and I think I have hardware- SPDIF-OUT working tomorrow (just found a bug that took me 3 hours.. :)

SPDIF-INPUT: How to handle sample-freqs != AUDIO_SAMPLERATE ? Discard data?

User-Datachannel or "CD-DATA" (in+out): Do we need it ? (I have no way to test it)

Edit: If I'd wanted to build a SPDIF-based "audioshield" which used SPDIF instead I2S : Which chip should I use?
 
Last edited:
duff said:
With beta9 I get the cryptic memory error (section `.bss' is not within region `DTCM') with this sketch:
Code: 
#define BUF_SIZE 30066
uint32_t buffer[BUF_SIZE];

void setup() {
  memset(buffer, 0, BUF_SIZE * sizeof(uint32_t));
}


void loop() {


}

I assume there is a boundary issue with the memory section 'DTCM'? If I use a buffer size 30065 it compiles and says I have used only 48% of available memory. I have tried to read through this thread but didn't see this exact issue come up, maybe it did? 30065 words is almost the entire 128k of the DTCM section maybe add the memory section and whats what to the first comment on this thread?
Click to expand...

Try DMAMEM uint32_t buffer[BUF_SIZE];
or use malloc()
 
Frank B said:
Try DMAMEM uint32_t buffer[BUF_SIZE];
or use malloc()
Click to expand...
Ok so DMAMEM is OCRAM which is 256k makes sense now. I saw this comment on this thread just now that explains that Paul is using fixed memory sections in the linker script and will fix later. Ok I'm moving on to other things.
 
I have started updating my Teensy google spreadsheet adding the T4 stuff from post #3. Right now the link I've given out before does not include the T4 stuff, but it is available as another sheet in that document. Some of the things are guesses (Can/SPI/I2C numbering), and I haven't added the i2s, flexio, or xbar columns yet. The link to the spreed sheet with the T4 additions is:

Paul, if you would prefer me to remove to to a more private document, I can do that.

Now, looking at the standard 28 pins of the Teensy (ground, 0-13, A0-A9, 3.3v, agnd, VIN), if you are wanting to write something that can run on both T3 and T4's, it looks like:
  • The only common serial connection is Serial1 (pins 0/1);
  • Use the main I2C device (pins 18/A4 and 19/A5) -- don't forget the pull-up resistors;
  • Use the main SPI pins (11-13) -- pin 10 looks like the favored CS pin;
  • The PWM pins shared in all Teensys are: 3, 4, 22/A8, 23/A9, and perhaps pins 9 & 10 if the QT column means normal PWM will work;
  • It does not look like the CAN ports use the same pins;
  • No touch support;
  • Pin 13 is the LED;
  • 3.3v digital inputs only.
 
I think it's interesting the reference manual mentions NAND and EMMC. One big item that's been on my wish list for the Teensy 3.x is availability of large amounts of non-volatile memory. Has anyone looked into it yet?
 
brtaylor said:
I think it's interesting the reference manual mentions NAND and EMMC. One big item that's been on my wish list for the Teensy 3.x is availability of large amounts of non-volatile memory. Has anyone looked into it yet?
Click to expand...

The SD pins like T_3.5/3.6 uses are pads on the Beta bottom - one tester got it working - but no promise on having the room to ship with layout or a mounted SD adapter in place due to space - physical size/layout and routing. IIRC some note was made that the T4 follow on would perhaps have second storage chip, but seemed only to suggest it would not be on the T4 - but yes there are control pins and MCU features that would support second channel for fast storage IC with the 1062 MCU.

A bit of heresy - but given the physical location issues of the bottom area for SD - and affects of the current passage and power draw for SD: wondering about the utility of the second memory/storage chip easier/better/faster on T4 - even like Prop or layout like Audio for chip of 16 MB.
 
%&/ still struggeling with the SPDIF .. never seen that, only one channel works? funny, as it is pure digital over one single wire :)
Something must be terrible wrong with the data-channel.
One of my chinese SPDIF->analog converters outputs one channel, the other nothing.. :) Have to do more tests tomorrow, luckyly I can compare it with the software-version. Or both are problematic.. in this case I'd have to annoy my wife and use the home-cinema for tests... :)

@Kurt: Do you know if it is possible to decode SPDIF with Salae Logic 1.2.18? Have you ever seen a plugin for SPDIF?
 
defragster said:
Frank - did you see this in my post #1829


Frank is this a good tip :: This plugin is for use in the Saleae Logic program to decode captured data from any SPDIF Interface.
Click to expand...

Thanks! It is not that useful, becuase it decodes not more than the pure audio-data - and that even wrong because it is 24bit-data, not 16 bit. But at least it decodes *something* and that shows that I must have configured SPDIF wrong, or it has a DMA problem:
screenshot.jpg
Even the lef-channel data is wrong: it should be 0x112233, 0x445566, 0x112233, 0x445566, ......

Edit: #1829: Yes :)
 
@Frank B - Sorry I missed the question about logic analyzer... But @defragster looks like he found one... Wonder how hard it would be to update to handle 16 bit data as well...
Been awhile since I worked on a plug in analyzer. I have one for Robotis Dynamixel Servos, which works reasonably well (does not crash too often ;) )

Glad you have it working!
 
KurtE said:
@Frank B - Sorry I missed the question about logic analyzer... But @defragster looks like he found one... Wonder how hard it would be to update to handle 16 bit data as well...
Been awhile since I worked on a plug in analyzer. I have one for Robotis Dynamixel Servos, which works reasonably well (does not crash too often ;) )

Glad you have it working!
Click to expand...

yup, Tims find was useful :) Although the decoder is not good, it gave me a useful hint :)
 
@Paul if you have spare T4s.. what about having VGA on the T4? Maybe the developer "qix67" is willing to port it.. DMA which does all the work is the same. And with the increased memory, it may be possible to inrease the resolution..

 
Frank - thanks for checking #1829's PULL - that should be good then. Glad the LA Decoder helped - if not directly - and decoder might be fixable if needed again.

Also yes, having DMA VGA would be very nice if @qix67 was up to it. It worked well on the T_3.6!

Frank - thanks for notes into the use of the this code to read vars _isr()'s can change like I did for micros()! I'm about to use it again … and it seems the it works on T_3.6 { (to be confirmed soon) - which means micros() there could be improved }:
Code: 
   uint32_t safe_read;
   do { // must :: #include "arm_math.h"
        __LDREXW(&safe_read);
      // Code here accesing vars that can change on interrupt
   } while ( __STREXW(1, &safe_read));
 
Status
Not open for further replies.
Back
Top