Teensy 4.0 First Beta Test

[mjs513]

@Paul

Just got the pogo pins in the mail. Thank you - really appreciate it. Now if I can stop obsessing over BT I can get back to the breakout board.

 

[PaulStoffregen]

I too have been distracted for the last several days... also with pogo pins. I've mostly been making repairs and long-delayed improvements to the bed-of-nails test fixtures we use here.

 

[mjs513]

@Paul
Glad you are feeling better enough to get back to something pretty tedious as a bed of nails

 

[Frank B]

@mjs, i've fixed the codecs-library. should compile now
On T4, it uses IRQ_Reserved1 as secondary interrupt.

 

[mjs513]

@FrankB
Thanks for letting me know - will give it a try tomorrow - just about shot for today.

 

[mjs513]

@Frank B
Ok I tested the changes and seems to work like a charm. Tried Wav, Raw, FLAC, MP3 and AAC all operational. I read a whole bunch of files from the SD card using this sketch:

// Requires the prop-shield
// This example code is in the public domain.

#include <string.h>

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>
#include <play_sd_mp3.h>
#include <play_sd_aac.h>
#include <play_sd_flac.h>

// GUItool: begin automatically generated code
AudioPlaySdMp3           playMp3; //xy=154,422
AudioPlaySdWav           playWav; //xy=154,422
AudioPlaySdRaw           playRaw; //xy=154,422
AudioPlaySdAac           playAac; //xy=154,422
AudioPlaySdFlac          playFlac;
AudioMixer4              mixer1;         //xy=323,326
AudioMixer4              mixer2;         //xy=323,326
AudioMixer4              mixer3;

AudioOutputI2S           audioOutput;

AudioConnection          patchCord1(playMp3, 0, mixer1, 0);
AudioConnection          patchCord2(playMp3, 1, mixer1, 1);
AudioConnection          patchCord3(playWav, 0, mixer1, 2);
AudioConnection          patchCord4(playWav, 1, mixer1, 3);
AudioConnection          patchCord5(playAac, 0, mixer2, 0);
AudioConnection          patchCord6(playAac, 1, mixer2, 1);
AudioConnection          patchCord7(playRaw, 0, mixer2, 2);
AudioConnection          patchCord8(playFlac, 0, mixer3, 0);
AudioConnection          patchCord9(playFlac, 1, mixer3, 1);
AudioConnection          patchCord10(mixer1, audioOutput);
AudioConnection          patchCord11(mixer2, audioOutput);
AudioConnection          patchCord12(mixer3, audioOutput);

AudioControlSGTL5000     sgtl5000_1;

// Use these with the Teensy 3.x Audio Shield
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  11
#define SDCARD_SCK_PIN   13

float volume = 0.5f;
File root, entry;

void setup() {
  
  AudioMemory(40);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0.5);  
  delay(100); 

  SPI.setMOSI(SDCARD_MOSI_PIN);
  SPI.setSCK(SDCARD_SCK_PIN);
  if (!(SD.begin(SDCARD_CS_PIN))) {
    // stop here, but print a message repetitively
    while (1) {
      Serial.println("Unable to access the SD card");
      delay(500);
    }
  }
  Serial.println("initialization done.");
  root = SD.open("/");

}

void playFile(const char *filename)
{
  int filetype;

  filetype = 0;
  if (strstr(filename, ".MP3") != NULL) {
      filetype = 1;
  } else if (strstr(filename, ".WAV") != NULL ) {
      filetype = 2;
  } else if (strstr(filename, ".AAC") != NULL ) {
      filetype = 3;
  } else if (strstr(filename, ".RAW") != NULL ) {
      filetype = 4;
  } else if (strstr(filename, ".FLA") != NULL ) {
      filetype = 5;
  } else
      filetype = 0;

  if (filetype > 0) {
    Serial.print("Playing file: ");
    Serial.println(filename);
    
    switch (filetype) {
      case 1 :
        mixer1.gain(0, volume);
        mixer1.gain(1, volume);
        mixer1.gain(2, 0.0f);
        mixer1.gain(3, 0.0f);
        playMp3.play(filename);
        delay(5);
        while (playMp3.isPlaying()) {
        }
        break;
      case 2 :
        mixer1.gain(0, 0.0f);
        mixer1.gain(1, 0.0f);
        mixer1.gain(2, volume);
        mixer1.gain(3, volume);
        playWav.play(filename);
        delay(5);
        while (playWav.isPlaying()) {
        }
        break;
      case 3 :
        mixer2.gain(0, volume);
        mixer2.gain(1, volume);
        mixer2.gain(2, 0.0f);
        playAac.play(filename);
        delay(5);
        while (playAac.isPlaying()) {
        }
        break;
      case 4 :
        mixer2.gain(0, 0.0f);
        mixer2.gain(1, 0.0f);
        mixer2.gain(2, volume);
        playRaw.play(filename);
        delay(5);
        while (playRaw.isPlaying()) {
        }
        break;
      case 5 :
        mixer3.gain(0, volume);
        mixer3.gain(1, volume);
        playFlac.play(filename);
        delay(5);
        while (playFlac.isPlaying()) {
        }
        break;
    }
  }
}

void loop() {
  playAll(root);
}

void playAll(File dir){
  char filename[64];
  char filnam[64];
  
   while(true) {
     entry =  dir.openNextFile();
     if (! entry) {
       // no more files
       // rewind to begining of directory and start over
       dir.rewindDirectory();
       break;
     }
     //Serial.print(entry.name());
     if (entry.isDirectory()) {
       //Serial.println("Directory/");
       //do nothing for now
       Serial.println(entry.name());
       playAll(entry);
     } else {
       // files have sizes, directories do not
       //Serial.print("\t\t");
       //Serial.println(entry.size(), DEC);
       // files have sizes, directories do not
       strcpy(filename, dir.name());
       strcat(filename, "/");
       strcat(filename, strcpy(filnam, entry.name()));
       playFile(filename);
     }
   entry.close();
 }
}

 

[Frank B]

Nearly all outputs work now, too. We have 3xSPDIf, 2xI2S, MQS, 2xTDM.. some of them can't be combined. Stacking two Audioshields and the inputs and slaves are still TODO ( I work on them..)
Being able to use so many in-and output channels more will open some new possibilities..
I wished the final T4 had a bigger flash, as it would be very useful here
Had the idea to add a resampler now, but this will take some time, and I want to start with the displays, and, and, and...

 

[Frank B]

Who has ADAT compatible devices? I can't work on this..

 

[PaulStoffregen]

I wished the final T4 had a bigger flash,

Me too. Sadly, this is the largest one we could buy in a 6 sq mm package. The next largest package is 12 sq mm, and the smallest package that goes up to substantially higher capacity is 40 sq mm.

After 4.0 is released, I'm considering making a larger (and more expensive) board using this same processor, but with one of those bigger flash chips, an audio codec chip, and probably an ethernet phy chip, and some way to break out more of the I/O pins.

 

[Frank B]

Me too. Sadly, this is the largest one we could buy in a 6 sq mm package. The next largest package is 12 sq mm, and the smallest package that goes up to substantially higher capacity is 40 sq mm.

After 4.0 is released, I'm considering making a larger (and more expensive) board using this same processor, but with one of those bigger flash chips, an audio codec chip, and probably an ethernet phy chip, and some way to break out more of the I/O pins.

Yes, you mentioned the package issue in the old thread, I think

If someone want to try resampling: there is a very good resampler (uses "sinc") in the speex codec - it is already optimized of ARM Cortex M4 and uses the DSP extensions - and if I read the license correctly, we can use it. I'd do it, but can't begin before late spring or summer.. perhaps the codec is useful, too? It's optimized for speech.

Oh, the larger board is very interesting..!

 

[MichaelMeissner]

I assume this is obvious, but it is my experience that sometimes what I think is obvious might not be, or things might get forgotten because Paul/Robin are doing so many things.

Anyway, when it comes time to do the pinout card, given we don't have a DAC, and I2S is expected to be used for sound. It would be helpful to users if one or both of the I2S ports and the SPIDF port will be on the pinout card. I assume the crossbar and flexio pins will also be listed.

It certainly would also be helpful if somewhere on the card we mentioned I2C needing pull-up resistors. I realize the card is already getting crowed, and if it doesn't go in, it isn't the end of the world.

Of course it probably means the library section needs to be re-vamped also, to add any more qualifiers for T4.

In terms of the pinout card, if we have more special CS pins like we did in T3.x, it might be nice to put them on the card too, but as before, it is hard to explain (particularly for the pin overlaps).

 

[defragster]

The larger T4 follow on was noted early - it wasn't clear if it would be T4's MCU or perhaps a more capable MCU not yet public. That was before the 1062 became the expected T4 MCU. And now the i.MX RT1064 with On-chip Flash (4 MB) would double T4's flash and drop a part and perhaps remove those lines from PCB layout to get cleaner routing to other added parts.

...
Anyway, when it comes time to do the pinout card, given we don't have a DAC, and I2S is expected to be used for sound. It would be helpful to users if one or both of the I2S ports and the SPIDF port will be on the pinout card. I assume the crossbar and flexio pins will also be listed.

It certainly would also be helpful if somewhere on the card we mentioned I2C needing pull-up resistors. I realize the card is already getting crowed, and if it doesn't go in, it isn't the end of the world.

Of course it probably means the library section needs to be re-vamped also, to add any more qualifiers for T4.

In terms of the pinout card, if we have more special CS pins like we did in T3.x, it might be nice to put them on the card too, but as before, it is hard to explain (particularly for the pin overlaps).

Perhaps a Browser based card layout tool is needed? Like Audio Library design tool. Click the desired interface (or pin) and be presented with the pins (or func) that can be accessed in what ways to get the desired bus/function. Perhaps make selection and then repeat edit/update to configure a picture of what pins are where - and as needed tips and info on how to get that working.

 

[PaulStoffregen]

If someone want to try resampling: there is a very good resampler (uses "sinc") in the speex codec - it is already optimized of ARM Cortex M4 and uses the DSP extensions - and if I read the license correctly, we can use it.

Could you please post this as a new thread, with a link to the code?

I'd like to save it on my audio library wish list (not calling it a "todo" list at this point).

 

[KurtE]

After 4.0 is released, I'm considering making a larger (and more expensive) board using this same processor, but with one of those bigger flash chips, an audio codec chip, and probably an ethernet phy chip, and some way to break out more of the I/O pins.

Sounds great! Will be fun to work with...

At some point it would be great if it also somehow could do WIFI... But not sure how doable that is without adding a bunch of other stuff. I know some boards have done it by adding ESP... Again sorry if not specific to this Alpha/Beta...

 

[defragster]

Here's the Aliexpress link for those 3.5 inch, 480x320 displays. Right now is Chinese New Year, so expect any order to take a couple extra weeks.

https://www.aliexpress.com/item/3-5...reen-with-Touch-Panel-Driver/32908809356.html

Paul - ILI9488 displays arrived - in 23 days - they bumped to air ship it seems after Spring break delay. They are packed/labelled like shown in your post#1470. Wholly different than the layout on KurtE/mjs513 displays.

T4 USBHost work looks good and T_3.6 compatible/interchangeable and mjs513 and KurtE are doing well on that thread using T_3.6 and now 12 pages of chatter - about Bt dongles and Joysticks/mice/keyboards not on this thread

Took a pic to show the 3.5" pinout matches the 2.8" pinout for SPI on TFT and Touch - put it next to PJRC OSH display board:

 

[daywalker03]

Sounds great! Will be fun to work with...

At some point it would be great if it also somehow could do WIFI... But not sure how doable that is without adding a bunch of other stuff. I know some boards have done it by adding ESP... Again sorry if not specific to this Alpha/Beta...

Can we discuss this in another thread? There may be a way to do it.

 

[sublinear]

Could you please post this as a new thread, with a link to the code?

I'd like to save it on my audio library wish list (not calling it a "todo" list at this point).

Just curious, what would be the specs on the resampling you want to do?

Years ago I wrote a very fast polyphase resampler for a previous Cortex-M4 project that I'm happy to contribute.
It used 16-tap precomputed filters to convert standard rates (8k, 11025, 16k, 22050, 32k, 48k) to 44100Hz.

The specs on the FIR filters looked like:

//
// 16-tap minimum-phase equiripple FIR
// passband = 18KHz gain = -1.25dB +- 0.25dB
// stopband = 26KHz attn = -90dB
// coefs = Q15 with sum(abs(coef)) < 65536
//
static const int16_t filter_4_1[4][NTAPS] = {
    { 57, -681, -497, 845, -1472, 2162, -2734, 2873, -2152, -77, 4489, -10987, 13872, 18409, 3388, 36 }, 
    { 52, -373, -938, 1031, -1367, 1541, -1357, 559, 1090, -3802, 7377, -10282, 6354, 21285, 6171, 192 }, 
    { 29, -131, -1084, 733, -684, 335, 428, -1708, 3481, -5547, 7139, -6303, -1540, 21825, 9926, 634 }, 
    { 10, 8, -961, 135, 190, -840, 1780, -2943, 4095, -4805, 4178, -676, -7853, 19340, 14267, 1608 }, 
};

and the inner loop used Cortex-M4 DSP instructions do a pairs of 16x16 MACs.
This is the stereo filtering kernel:

static int SRCFilter(SRC *s, int16_t *src0, int16_t *src1, int16_t *dst0, int16_t *dst1, int inframes)
{
    int16_t *src0_end = src0 + inframes;
    int16_t *dst0_old = dst0;
    int phase = s->phase;

    ASSERT(NTAPS == 16);

    while (src0 < src0_end) {

        const int16_t *coef = s->filter[phase];
        int32_t x0, x1, c0, c1;
        int32_t acc0, acc1;

        c0 = _SIMD32_OFFSET(coef+0);
        c1 = _SIMD32_OFFSET(coef+2);
        x0 = _SIMD32_OFFSET(src0+0);
        x1 = _SIMD32_OFFSET(src0+2);
        acc0 = __SMUAD(x0, c0);         // Q15 * Q15 = Q30
        acc0 = __SMLAD(x1, c1, acc0);

        x0 = _SIMD32_OFFSET(src1+0);
        x1 = _SIMD32_OFFSET(src1+2);
        acc1 = __SMUAD(x0, c0);
        acc1 = __SMLAD(x1, c1, acc1);

        c0 = _SIMD32_OFFSET(coef+4);
        c1 = _SIMD32_OFFSET(coef+6);
        x0 = _SIMD32_OFFSET(src0+4);
        x1 = _SIMD32_OFFSET(src0+6);
        acc0 = __SMLAD(x0, c0, acc0);
        acc0 = __SMLAD(x1, c1, acc0);

        x0 = _SIMD32_OFFSET(src1+4);
        x1 = _SIMD32_OFFSET(src1+6);
        acc1 = __SMLAD(x0, c0, acc1);
        acc1 = __SMLAD(x1, c1, acc1);

        c0 = _SIMD32_OFFSET(coef+8);
        c1 = _SIMD32_OFFSET(coef+10);
        x0 = _SIMD32_OFFSET(src0+8);
        x1 = _SIMD32_OFFSET(src0+10);
        acc0 = __SMLAD(x0, c0, acc0);
        acc0 = __SMLAD(x1, c1, acc0);

        x0 = _SIMD32_OFFSET(src1+8);
        x1 = _SIMD32_OFFSET(src1+10);
        acc1 = __SMLAD(x0, c0, acc1);
        acc1 = __SMLAD(x1, c1, acc1);

        c0 = _SIMD32_OFFSET(coef+12);
        c1 = _SIMD32_OFFSET(coef+14);
        x0 = _SIMD32_OFFSET(src0+12);
        x1 = _SIMD32_OFFSET(src0+14);
        acc0 = __SMLAD(x0, c0, acc0);
        acc0 = __SMLAD(x1, c1, acc0);

        x0 = _SIMD32_OFFSET(src1+12);
        x1 = _SIMD32_OFFSET(src1+14);
        acc1 = __SMLAD(x0, c0, acc1);
        acc1 = __SMLAD(x1, c1, acc1);

        *dst0++ = __QADD(acc0, acc0) >> 16; // Q30 -> Q15 with saturation
        *dst1++ = __QADD(acc1, acc1) >> 16;

        // phase step
        src0 += s->srcstep[phase];
        src1 += s->srcstep[phase];
        phase += s->phasestep;
        if (phase >= s->up)
            phase -= s->up;
    }

    s->phase = phase;

    return dst0 - dst0_old; // outframes produced
}

 

[Frank B]

Just curious, what would be the specs on the resampling you want to do?

At the moment I can only say something about the SPDIF input: Normally you can't select the sample rate for consumer electronics. Here, downsampling from the usual rates (multiples of 48 and 44.1 KHZ - up to 192KHz) to 44.1KHz would be useful to process it on the teensy. It can be useful for wav-files and other formats, too.

@Paul: It took me a while to find it again: It's the github account of xiph.org : https://github.com/xiph/
Both the old Speex and the newer Opus codec use a resampler. At the moment I can't find the Cortex-M4 optimization again. Perhaps it was a fork.. don't know... At least, it has some ARM specific code, I saw NEON (not compatible or useful) and a fixed-point implementation.

 

[defragster]

For what it is worth: I just hooked it up to my T4...

My connections are: Display-T4

1-GND, 2-+3.3v, 21-7, 23-10, 24-13, 25-9, 27-11, 28-12, 29-8

I updated the sketch a little to turn the LED on and to change the pin numbers...
Sketch here …
And it run! With stuff on the display

I have a T4 Running ILI9488 using KurtE's code same 'updated sketch' code in linked post #1708 above!

I just put headers on a PJRC OSH Purple Board - T4 overwide of course so I ran two lines 5V and SCK down to the header {with 14 pins of long header socketed on the other side - lucky I can't post a picture of it } - and the wiring was right. Tested the same before (though not the T_4_Beta branch) with a T_3.6 using KurtE's code and it worked.
[note - I got a few of the PJRC OSH boards - I didn't complete the power segment - just dropped in 3 resistors and a jumper wire to feed 5 volts directly across the board )

Used library code { and above edited sample sketch } from:github.com/KurtE/ILI9488/tree/Teensy_4_beta

As posted prior the boards I got are from the link Paul supplied and the package looks the same - and two of two have been tested to work.

The TOUCH library works … it uses the same controller - at least sort of … just not very well - the pressure calc must be off (always 4095) I get hits with hard press and then they fade - and the _isr for TIRQ_PIN fails as written - always reading … and the X,Y values are bad - no reported y other than 0 and X only knows 16,32,48 or 0. Will go look ...

 

[defragster]

ILI9488 write only when using Touch - or other SPI device

Arrgh - looks like the ILI9488 doesn't tristate its own twin SPI devices? So having both wired as the PJRC OSH Purple board with SDO { MISO } connected prevents reading touch data. It would also block any other shared SPI bus device.
>> Paul this is the 9488 board you have as well.

ESP32 with SPI ILI9488 Touch LCD
I have created a test setup and have found that the SDO line sticks low and does not go tristate even if the TFT chip select is high. This means that the SDO line must not be connected up if the SPI bus is to be shared with other devices. Disconnecting the SDO line also means that the TFT read functions will no longer operate correctly.

So I cut the TFT MISO trace on the OSH board and sure enough - I am now getting Touch Data on T_3.6 and now the T_4 Beta.

Question ahead:: Seems the MISO touch also not tristated to allow another device to exist with Write only ILI9488 with active Touch? Somebody with a scope knowing what to look for could see and confirm this faster than hooking up two things on my single header. Though test below seems to show using Touch voids the display.

_isr code for Touch IRQ test seems to be working ( no tft display ) in TouchTest.ino, with IRQ pin no SPI chatter until touch. So the XPU2084 Touch code seems perfectly functional.

First example mod for reading Touch - doesn't seem to allow display . . . the not yet renamed ILI9341Test.ino converted to ILI9488 is failing attempts at screen pixel changes . . . the SCK LED flashes for writes but nothing appears …

KurtE - I wonder if your ILI9488 has this behavior?
My rPi version of this board has single SPI line set - so it must be tristated - I'll wire that.

<edit>Was about to declare this a tft issue - but now seeing TFT text with T_3.6. Screen reports X,Y location on TFT and then No Touch per misnamed example. Going back to T4 fails to display.

Here is the now renamed Touch Example - no XPT2046 change needed: View attachment ILI9488Test.zip
Works on T_3.6 with KurtE's lib, but not T4, with display MISO not connected
Slight mod - should run Graphics testText [Groop] then show when Touched (removed clear screen && increased Font Size)
KurtE - slight pixel remains on right edge of X,Y digit display edit line #80 to 'tft.fillRect(100, 150, 142, 60, ILI9488_BLACK);'

Following is an rPi_ILI9488 issue - not T4 - same behavior on T_3.6:
I ran wires to the rPi ready display I got - Touch works, but nothing ever displays. It does not have the D/C pin broken out like the ILI9341 and other 9488. May be in 16 bit color mode?

 

[mjs513]

<edit>Was about to declare this a tft issue - but now seeing TFT text with T_3.6. Screen reports X,Y location on TFT and then No Touch per misnamed example. Going back to T4 fails to display.

Here is the now renamed Touch Example - no XPT2046 change needed: ILI9488Test.zip
Works on T_3.6 with KurtE's lib, but not T4, with display MISO not connected
Slight mod - should run Graphics testText [Groop] then show when Touched (removed clear screen && increased Font Size)
KurtE - slight pixel remains on right edge of X,Y digit display edit line #80 to 'tft.fillRect(100, 150, 142, 60, ILI9488_BLACK);'
Following is an rPi_ILI9488 issue - not T4 - same behavior on T_3.6:
I ran wires to the rPi ready display I got - Touch works, but nothing ever displays. It does not have the D/C pin broken out like the ILI9341 and other 9488. May be in 16 bit color mode?

That's the same display that I was using and never could get it to work, I was complaining about the same thing - no DC. That's why I order the one KurtE has and the one Paul showed. Haven't done anything yet with them though

 

[manitou]

quad timer tests

I developed a T4 sketch to exercise quad timer (ch 52) pin capture to test functionality that might be used in porting PulsePosition lib to T4.
https://github.com/manitou48/teensy4/blob/master/qtmr_capture.ino
The sketch runs QTMR1 at 150mhz/4, and rising pulse on pin 11 captures the clock value. Overflows of the 16-bit timer are counted with match on 0xffff ISR. Tested with PWM from pin 23 jumpered to pin 11.

TMR1_SCTRL2 0x1440
TMR1_CSCTRL2 0x340
TMR1_CTRL2 0x3520
TMR1_LOAD2 0x0
TMR1_COMP12 0xFFFF
TMR1_CMPLD12 0xFFFF
TMR1_COMP22 0x0
TMR1_CMPLD22 0x0
ticks 6 oflows 1 v0 63688 v1 6518
ticks 5061 oflows 573 v0 57896 v1 726
ticks 10116 oflows 1146 v0 53498 v1 61864
ticks 15170 oflows 1718 v0 47706 v1 56072
ticks 20225 oflows 2290 v0 41914 v1 50280
ticks 25275 oflows 2862 v0 37516 v1 44488

My first try was to use timer overflow interrupt(TOF) to count overflows, but I was never able to get the TOF interrupt to fire???
(NXP discussion confirms bug in overflow for counting up).
Here is another quad timer sketch that has various tests for counting and PWM variations on pin 10.
https://github.com/manitou48/teensy4/blob/master/qtmrtst.ino

EDIT: update with a PulsePosition-like T4 PPM input capture sketch and a PPM output sketch

10/30/19 T4 PulsePosition discussion github pull request

 

[Frank B]

Added S/PDIF input (attention 44100 Hz only)
Current state: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=193744&viewfull=1#post193744

RE: Audio: I'll take a break now.. some things are still missing - partly I have no hardware (i.e. PDM, ADAT..).. I'll leave the remaing rest for others at least analog input would be important.
If possible, please use the same PLL-freq as in the other in-/ouputs (not mqs- but I think I can fix that..)

 

[manitou]

at least analog input would be important.

Re: PIT-controlled ADC with DMA

I tried to add DMA to PIT+XBAR+ADC, discussed in post #1307

I couldn't find the right incantation to get the DMA to work, but here is the non-working sketch
https://github.com/manitou48/teensy4/blob/master/adcdmapit.ino

EDIT: update github with options to use ADC_ETC as DMA trigger, but get too many interrupts???

 

[Frank B]

@Kurt, Paul: Is there a way to use the SPI-Transactions without SPI? I have some ideas for a new display-library and want to use my own SPI, but the transaction should be compatible to the existing SPI-Lib.
I guess I need the inTransactionFlag ?
I'm playing with the new 320x480 Display..

Edit:no, obviously not the inTransactionFlag. So, how to do it?