Teensy 4.0 First Beta Test

Status
Not open for further replies.
I got i2c SSD1306 working no issues when I got usable libraries [_GFX , SSD1306] it ran their sample Adafruit demo sketch using Wire.h.

I just got my Prop Shield out and removed EEPROM calls and the CalibrateSensors is running with copious data- Assume that is a second test of i2c?
View attachment 16476

@mjs513 - found it … right there on page #96 post #2388 … so that would have been w/T4B2 hardware … had to take out the EEPROM setting for the calibration.
 
I've committed a fix for this problem.

https://github.com/PaulStoffregen/cores/commit/938be5eaf7cb99491d75f5f0fd28c55acb3d2b81

USB serial communication should now properly resume when the cable is plugged back into an externally powered T4.

@Paul - Confirming this fix with Current Github\CORES fixes what I saw Here in post #2889::
Originally Posted by defragster
Conclusion: Problem is externally powered T4 doing USB output when USB is disconnected, T4 continues running - but USB stays 'offline' when cable plugged in.

Got T4B2 running on external power:
>> With 5v AND GND from a T_3.6 - up and running sketch - pulled T4's device USB the Sketch continues running - replugged USB and USB connects and resumes printing as desired/expected!

Got [T4B2 running on external power Trace Cut] AND [T4B2m does power fallover on USB unplug with uncut trace] :
>> Got the Orico Drive/Hub to supply power through USB HOST connector [ T4B2 and T4B2m ] then pulled Device USB from T4 the Sketch continues running - replugged USB and USB connects and resumes printing as desired/expected!

While BOTH in this 'condition' I tested POWER button OFF >> ON and both restart Setup() and run properly
 
Yes, this will be "fixed" by documentation.

You may recall I talked about being a bit reluctant to make the on/off feature available to Arduino users... months ago in the transition from 1052 (where I wired the 3.3V regulator always on) and 1062 (where all have supported on/off). It can be confusing when the hardware is "off", for whatever reason. It can be confusing when you believe you've shut off the power, but the caps don't fully discharge or microamps of current leak through the pins from something else that still has power. These are issues that will need to be documented on the troubleshooting page. Fortunately, it is pretty easy to check with a multimeter whether the power really went all the way to zero volts.

The on/off feature is so very useful for people making battery powered projects. It would seem like quite a shame to have this in the hardware and not make it available to users.

I tried to read through your messages again. There seems to be a lot of talk where the USB communication not restarting is mixed up with the on/off power management. Some parts I can't quite parse what you mean.

I also see a lot of talk about an Orico Hub/Drive which unintentionally powers T4 through the host port. While that's wrong hub behavior and we may see if from other hubs, as far as T4 is concerned this is the same as if you connected external 5V power to VIN. Nothing I can do about that in the T4 hardware or software.

Are there other outstanding issues I should investigate? Did I miss anything else in those messages?

On/Off definitely useful and important - like any of the Reset/Program pins they need to be understood to be connected/avoided - and inadvertent GND touch will 'activate' them - no different than the new Power pin - just a new set of possible end results to … be "fixed" by documentation.


… I also tried reading through those messages again and nothing else strikes me as critical - the only STOPPER was the one you fixed so USB reconnects/Resumes when USB rejoins while T4 was externally powered and USB dropped.


Calling this good : just wanted to know PaulStoffregren saw these oddities existed and understood them to not indicate any unexpected/unacceptable electrical connectivity or result based on your fuller understanding of the MCU as used.

I can't say I explored all the possibilities - but the MOD to T4B2m fixed the brown out restart and this has been the best I could do to dancing around it.


The only other thing in that mix (Orico Hub/Drive powered box - here external using 5V Pin power) is the following - but this matches Current T_3.6 behavior as well I just tested::

> T4B2: Not Mod - Vin<>VUSV cut - No UARTS:: Just T4B2 on breakout with 5V and GND wired from a T_3.6 on a wall wart and T4 Device plugged to PC

>> Using inline USB dongle with a switch on 5V to remove the power
> The T4 stays connected and transferring when the 5V line is switched open and sort of expected the connection to break


> As noted substituting a T_3.6 externally powered w/VIN<>VUSB cut - it also keeps USB connection up and transmitting when the 5V line is switched open.

So seeing this I see the USB core of T4 isn't different from T_3.6 - it is powered from either side as needed.

And with KurtE's note about the USBHost I see the T_3.6 is unique with HOST control pin that isn't presented to the breakout board to duplicate that behavior where it can feed an external 5V.
 
Does this present a usable scheme for EEPROM in FLASH? First question is the license after scanning the functional gist:

Eeprom emulation using external flash on the Spark Core.
It is licensed as "GNU Affero General Public License v3.0"
This library allows client code to write to the external flash as if it were EEPROM. It takes care of performing erases when required to ensure data is written correctly. 3 storage schemes are provided that offer different trade-offs in storage efficiency for increased number of write cycles over the lifetime of the device.
Key features:
Provides persistent storage using the external flash on the Soark Core, and Particle P1, and emulated EEPROM on the Photon.
EEPROM-like access - (byte erasable) no need to worry about erasing pages to ensure data integrity.
3 different types of eeprom emulations providing speed/erase cycle tradeoff.
Wear leveling and page allocation on demand for increased endurance
Circular buffers for logs, temporary data etc.
Stream access to the storage for convenient read and write of multiple values.
File System support: a FAT filesystem can be stored in a region of flash.

Also found this DOC - maybe it is what @mjs513 referred to? : st.com - Implementing EEPROM emulation

Question: The 1062 has unused BOOT ROM space - is that space able to be modified from user code? No it wouldn't be ROM then - but it would be handy - and it seems to be 128 KB? I finally found this in the DOC:"8.13 ROM APIs"
FlexSPI NOR Flash Driver API::See example code in section "FLASH API example on RT1060-EVK board".
flexspi_clear_cache
flexspi_command_xfer
flexspi_update_lut
flexspi_nor_flash_read
flexspi_nor_flash_erase

flexspi_nor_flash_erase_all
flexspi_nor_flash_page_program
flexspi_nor_flash_init
version


Question: The 5 second power on through 'Secure Non- Volatile Storage' (?) - is there a way to provide sketch() with advance notice of pending event? Normal operation of 'data integrity dependent' things perhaps USBHost HDD or other might like a chance to close files for instance in 'Normal operation'.
>> might kind to call a "__attribute__((weak)) void Teensy_Shutdown(void)" just in case the sketch cares?
> related Note: the 'usb.c' baud detection command to bootloader "if (usb_cdc_line_coding[0] == 134)"

Mag #6 Note: Just updated message #6 for SerialEvent not called: Not present is recurring call to delay() and normal Arduino loop() cycling
yield() is not currently part of the 'Beta T4' "main()" loop - as it doesn't have that code in place in startup as written.
 
Last edited:
@Paul - is Serial.AvailableToWrite() simple to implement for the next Beta TD1.47 release? By simple I mean trivial - it can certainly wait for your priority ordering and next pass at USB.

I have two T4's running the lps_test.ino on Windows and both are clocking in at 300,000 lines/seconds - VERY COOL! { 250K-320K lps against TyComm as sermon } - but a tad unreal without the proposed PullRequest "if ( 15< Serial.availableForWrite() ) count++" code in place.

But before powering the second - or taking one offline it drops to a more expected 80K to 120 on Windows10.

That computer I put a new HDD into - twin Core i7-6500u (+2 hyperthreads) - running TyComm was doing 150K to 300K with the T4B2 and putting the CPU at 57% and turned on the FAN more than I heard it before! It is running Newest Win10 major update. Not sure if this LPS speed from new Windows - or a CLEAN machine? Will know after more installs.

Also Windows 10 major update note:: Spring 2019 Win 10 update "1903.18362.30" ISO released 5/21 and already updated from ISO .30 version to Update .116. I put it on that machine no problem ( except it won't upgrade install with a flash drive in place … copied to HDD ).
 
Last edited:
@mjs513 - found it … right there on page #96 post #2388 … so that would have been w/T4B2 hardware … had to take out the EEPROM setting for the calibration.
@defragster - geez - didn't remember that one at all... Anyway, quite a number of years ago when I first got into this I was working with Fabio Versano FreeIMU library which I managed to morph in supporting a bunch of different sensors and added a bunch of other stuff his library, he had a Python Calibration library that he used for acceleration and magnetometer. So, instead of using Paul's calibration tool I typically use the FreeIMU (Paul and some other folks probably remember the library). Here a couple of screen shots of what I get now with the Prop Shield (Uncalibrated and Calibrated):
Uncalibrated.JPG Calibrated.JPG

Now with that tool I am getting:
Code:
---------------------
Orientation: 4.95 -0.10 2.26
rate = 778.05 Hz
---------------------
Orientation: 4.91 -0.10 2.27
rate = 779.79 Hz
--------------------

Now to setup and run my other sketch with a strip of DotStar's attached to the Prop Shield and @manitou's updated FastLED library.
 
@Defragster - so many questions, only time for quick answers...

Yup, seen the ROM's FlexSPI NOR Flash Driver API. So far, not using it and probably won't. Sorry, no time to write a lengthy explanation on my reasoning.

Yes, the hardware is supposed to be able to generate a "Pre Off" interrupt when the button is ON/OFF pressed, before the 5 seconds elapses. See Figure 20-3 on page 1328 of the RT1060 ref manual (rev 1, 12/2018).

No, Serial.availableToWrite() is not simple to implement. I believe many messages back I mentioned a subtle bug with Serial.availableToWrite() and automatic flushing on Teensy 3.x that I want to avoid. If you can find that old message, it has a detailed explanation of the finer points...

No, not going to consider GPL or Affero GPL code for inclusion in Teensy's core lib.

"The 1062 has unused BOOT ROM space" makes no sense to me. The address space starting 0x00200000 is definitely read-only.

Scattered across NXP's documentation are occasional mentions (maybe leftover copypasta from iMX6) about a ROM patch hardware. But NXP ships the chip with that region of OTP fuses locked, so even if the chip really has such hardware, and even if you could find documentation to use it, and even if you could somehow run code to set up a config that persisted across rebooting, the feature appears to be permanently locked out.

I already wrote eeprom emulation & wear leveling code on Teensy LC. Very likely will reuse that, or do something very similar... so really not a need to dig into these libs used on ST and Spark / Particle. Still might take a look, but definitely not going to copy any code from a GPL project into Teensy's MIT licensed core lib. However, the wear leveling it's the hard part. Preventing a FlexSPI AHB access while the flash is busy is the tricky business!
 
@PaullStoffregen @mjs513 and @defragster ...

Serial.availableForWrite - I think was mentioned in: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=205340&viewfull=1#post205340

EEPROM stuff - As to ST version of code... I updated some of the EEPROM code (and several other things) for the Robotis OpenCM9.04 Arduino code and working through some of the ST SDK code can be a challenge! If I remember correctly, They are using two code pages (maybe more), Each time you write a new value to EEPROM it uses the next spot and write out two values (location, value)... Each time you do a read it looks for the last location and uses that value... When the code page becomes full It, makes a pass through that code page and creates a new code page with only the last values for each of the addresses... And then sets that as the active page and clears the old one... But this code was limited to only something like 254 logical EEPROM locations... Sort of like TC with 128...

If I remember correctly I looked at the TC stuff when I was trying to fix some of their stuff (It would hang corrupt the data when you filled first page and corrupt)...
 
Yup, that's pretty much exactly how I implemented on Teensy LC. The reason for capping the size to 128 bytes on LC was to keep the RAM buffer smaller, when collecting up all the assigned values. LC has only 8K of RAM, so I worry a bit about allocating big buffers on the stack.
 
@Paul - good quick answers - saves misdirection and wasted effort ...
- No ROM for EEPROM or other is good to know. Knowing you have reasoning behind it is good enough
- Thanks for the ref on 'Pre Off' - an interupt seemed to be expected but my doc reading leaves me wanting.
- Thanks to KurtE I see the notes on Serial.ATW() - that would be a tough race to assure the right answer. For this lps test quick and dirty would help, but a distraction.
- GPL 'no good' for inclusion is good to know
- Read Only makes sense if it is BOOT ROM - wasn't sure where the line was between it needing to be programmed and secure for boot - and the ability to modify it.
- >> so comforting (not) to see I keep finding non-functional parts of the manual ...

>> opps - of course you have working emulation code for T_LC ...

@PaullStoffregen @mjs513 and @defragster ...

Serial.availableForWrite - I think was mentioned in: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=205340&viewfull=1#post205340

EEPROM stuff - As to ST version of code... I updated some of the EEPROM code (and several other things) for the Robotis OpenCM9.04 Arduino code and working through some of the ST SDK code can be a challenge! If I remember correctly, They are using two code pages (maybe more), Each time you write a new value to EEPROM it uses the next spot and write out two values (location, value)... Each time you do a read it looks for the last location and uses that value... When the code page becomes full It, makes a pass through that code page and creates a new code page with only the last values for each of the addresses... And then sets that as the active page and clears the old one... But this code was limited to only something like 254 logical EEPROM locations... Sort of like TC with 128...

If I remember correctly I looked at the TC stuff when I was trying to fix some of their stuff (It would hang corrupt the data when you filled first page and corrupt)...

@KurtE - indeed that covers it - I went right to the UART powered pins part of that post … and missed the significance there.
 
@PaullStoffregen @mjs513 and @defragster ...

Serial.availableForWrite - I think was mentioned in: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=205340&viewfull=1#post205340

EEPROM stuff - As to ST version of code... I updated some of the EEPROM code (and several other things) for the Robotis OpenCM9.04 Arduino code and working through some of the ST SDK code can be a challenge! If I remember correctly, They are using two code pages (maybe more), Each time you write a new value to EEPROM it uses the next spot and write out two values (location, value)... Each time you do a read it looks for the last location and uses that value... When the code page becomes full It, makes a pass through that code page and creates a new code page with only the last values for each of the addresses... And then sets that as the active page and clears the old one... But this code was limited to only something like 254 logical EEPROM locations... Sort of like TC with 128...

If I remember correctly I looked at the TC stuff when I was trying to fix some of their stuff (It would hang corrupt the data when you filled first page and corrupt)...

@KurtE @defragster @PaullStoffregen

Just catching up on my posts - been playing with FastLED and can't seem to get it working.

Going through the ST version of the code I pretty much saw what you are talking about it now that you explained it :). Only reference it for a reference = looking at the license didn't think it would fit as Paul mentioned in his next post anyway - but it give you other ideas. Didn't realize that the Teensy LC EEPROM "emulation and wear loading" incorporated so keep learning something new. Anyway now you know why I said ARGH! in one of my other posts after I looked at the st stuff.
 
FastLED testing

I don't pretend to understand most of FastLED lib, but I did hack enough to successfully test neopixel and DOTSTAR strips on Teensy 4 beta. See
https://github.com/manitou48/FastLED
The branch is a starting point for further T4 refinement and optimization. I did not incorporate F_CPU_ACTUAL, so you need to update boards.txt to teensy4b.build.fcpu=600000000 so that F_CPU reflects actual T4 CPU clock.

TODO:
  • incorporate F_CPU_ACTUAL
  • SPI clock is 6.25MHz, and the template doesn't seem to allow me to change SPI CLK speed ?
  • need FASTLED_TEENSY4 conditional?
  • M7 DSP support in lib8tion.h
  • other teensy3 optimizations? fastspi, clockless_block
  • more testing, more mods?

Note: Paul has already updated the Teensyduino Adafruit_NeoPixel lib to support T4.

EDIT: 5/9/19 add T4B2 (1062) pin defs in fastpin_arm_t4.h using fast GPIO (GPIO6-9). Tested with scope and with NEOPIXEL and DOTSTAR (SPI running at 22 mhz) strips. F_CPU 600mhz in boards.txt, 1.8.9 with 1.47-beta2

@manitou
Just gave you updated lib a try on the T4B2 (white wire on top) and seem to having a problem. I am using a strip of 10 DOSTAR LEDs attached to the T4 either directly or through the prop shield. I can get either the second LED to shine "white" or get the fist/second LED to shine White. Not 100% sure its the lib or my strand of dotstars. Heres the sketch taken from the Prop Shield page:
Code:
#include <FastLED.h>

#define NUM_LEDS 10
CRGB leds[NUM_LEDS];

void setup() {
  delay(2000);      // sanity check delay
  FastLED.addLeds<DOTSTAR, RGB>(leds, NUM_LEDS);
  pinMode(7, OUTPUT);
  digitalWrite(7, HIGH);  // enable access to LEDs
}

void loop() {
  // Move a single white led 
  for(int n = 0; n < NUM_LEDS; n++) {
    leds[n] = CRGB::White;
    FastLED.show();
    delay(8);
    leds[n] = CRGB::Black;
  }
}

EDIT: Forgot - can't get it working on a T3.5 either.
 
Last edited:
Hi All, I've been pretty quite on the T4 as of late but have made some progress with the low power features of this chip. I'm decoupling Snooze from the each of the teensy chips and putting all the low power features of each teensy into its own hal. Now the functional aspect of Snooze will not have any hard coded register access to a particular chip, this will all be done in the Hal. By doing this it has caused me to rethink a how Snooze actually should function and how I can make this transition seamless with the current library. I'm almost there but not there yet:(

As far as the T4's on/off function I think it should be available to the users, I agree that it would a great feature for portable battery powered projects even if there are hardware concerns with how it can be used. I'm not going to provide any functionality with the on/off feature with Snooze but need to run some test on how it works while the T4 is in low power state. I have no clue as of yet.
 
@manitou
Just gave you updated lib a try on the T4B2 (white wire on top) and seem to having a problem. I am using a strip of 10 DOSTAR LEDs attached to the T4 either directly or through the prop shield. I can get either the second LED to shine "white" or get the fist/second LED to shine White. Not 100% sure its the lib or my strand of dotstars.
EDIT: Forgot - can't get it working on a T3.5 either.

Your DOTSTARs don't work on T3.5 with production FastLED lib? Not sure i can help.

Sanity check:
for my T4 modified FastLED lib, you need to edit boards.txt so that F_CPU will be set to 600 mhz. If you're plugging prop shield into female headers on T4B2 breakout board, then I don't see how that can work. FastLED for DOTSTAR expects SPI SCK on 13 and MOSI on pin 11, but T4B2 breakout (see silk screen) has MOSI and SPI SCK "relocated" to work with the audio shield, yes? I never tried it from prop shield, but hooked DOTSTAR to MOSI (on silkscreen) and SCK (on silkscreen). I only tested with 3 or 4 DOTSTAR LEDs and i was powering from T4 3v3. You could peek with scope to see signals on pins 11 and 13.
 
@duff - sounds like good work.

Power On gets a full restart from OFF, and OFF Gnd of POWER pin held 5 seconds takes it to OFF - where the low power section stays alive and remembers that state while there is power for it. It works well - I just made the worst of the edges where unexpected power can lead to no device feedback when it went off - and when what would normally restart a 'now powered' is held OFF with low power section holding state. Nothing that can't be designed with for good function.

Paul pointed to page 1328 (of 12/2018 manual) with a pretty picture of 'Pre-Off' showing it hits a SW Interrupt - but I haven't gotten to where that is defined/exposed yet. I suppose there is an structure block somewhere with address offset? Scanning for T_3.x style int tables doesn't work
Closest I got to usage or presentation was imxrt.h - before the last set of interrupts before lunch:
#define IOMUXC_SNVS_SW_MUX_CTL_PAD_PMIC_STBY_REQ (IMXRT_IOMUXC_SNVS.offset008)
#define IOMUXC_SNVS_SW_PAD_CTL_PAD_PMIC_STBY_REQ (IMXRT_IOMUXC_SNVS.offset020)

Going OFF is fatal to anything ongoing - so I was hoping to catch the processor before going OFF for 'shutdown cleanup' notice. Whether that would be a window to 'sleep' before going OFF and then recover in setup in a snooze'like fashion? But I need to find that interrupt vector …

<< EDIT >> Maybe this is the ISR:
// Definitions based these documents:
// i.MX RT1050 Reference Manual, Rev. 1, 03/2018
// ARM v7-M Architecture Reference Manual (DDI 0403E.b)

enum IRQ_NUMBER_t {
// ...
IRQ_SNVS_ONOFF = 48,
// #define IOMUXC_SNVS_SW_PAD_CTL_PAD_ONOFF (IMXRT_IOMUXC_SNVS.offset014)
 
Last edited:
Your DOTSTARs don't work on T3.5 with production FastLED lib? Not sure i can help.

Sanity check:
for my T4 modified FastLED lib, you need to edit boards.txt so that F_CPU will be set to 600 mhz. If you're plugging prop shield into female headers on T4B2 breakout board, then I don't see how that can work. FastLED for DOTSTAR expects SPI SCK on 13 and MOSI on pin 11, but T4B2 breakout (see silk screen) has MOSI and SPI SCK "relocated" to work with the audio shield, yes? I never tried it from prop shield, but hooked DOTSTAR to MOSI (on silkscreen) and SCK (on silkscreen). I only tested with 3 or 4 DOTSTAR LEDs and i was powering from T4 3v3. You could peek with scope to see signals on pins 11 and 13.

Ran the T3.5 test with your modified lib. I will install the production lib and test with the T3.5 as a sanity check.

Probably should have mentioned I have breakout board for the T4 that I am testing with that breaks things out so I can use Arduino style shields, I also have a prop shield on a Arduino style shield that I can plug into so I all the pins line up correctly, just had to remember to add in the LED_EN pin code on pin 7. Yeah I know I do things strange.

But just for reference I also put the T4B2m on a breadboard and hooked in the dotstar directly (5v-5v, CI - SCK, DI - MOSI and Gnd to Gnd) and got the same results. Going to see if I can find the other half of strand I took the 10 from and retest but going to put the production version back in to test on the T3.5 again.

EDIT: Has to be something with the DOTSTAR strand - have to go get the scope and see whats going on. Production version does not work either - just downloaded the latest.
 
Last edited:
@manitou

Traced the problem to the connector from the LEDs to the Teensy. Removed that and connected jumpers from the connector on the LED to the Prop Shield and success. Had it running with a strip of 10 LEDs from board power only.

Thanks - thought I was loosing my mind there for a while.
 
Hi all, I just found out that I'm on the list, too :D sweet!

So, how's Audio going so far? And what about USB Audio and MIDI? These are the areas of most interest for me, I only read a couple of posts about people successfully streaming WAV files from SD, and Serial stuff working, but it's 121 pages of posts, I don't think I'll have the time to read them all.
 
@MickMad - Cool to be on the list ! There is a note by Paul about sending email to get delivery underway … Audio came together well when I tested it with the Shield after FrankB did some early critical work IIRC … It is certainly there for testing.

So far USB core read/write is the supported interface with other elements like Audio TBD. The USB Stack went from 12 Mbps to the 480 Mbps - so not only 'some' changes to deal with … but a huge FIREHOSE to drink from :)

Best summary starting aid is to read the First page posts on Pinout and Issues in Messages #4 and #6. Some of those point to posts #'s of active work or issue areas and is a decent reference into the pages of posts when a keyword search might fail.

Beta 2 change to the 1062 MCU happened about here at post #2280 … https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test and would be a smaller list of things to see status for reference.
 
At the moment I'm working on the EEPROM lib. After much fiddling, I believe I finally have the underlying flash writing and sector erase working. Many thorny little issues, keeping the system from crashing and clearing both CPU caching and FlexSPI FIFOs.
 
At the moment I'm working on the EEPROM lib. After much fiddling, I believe I finally have the underlying flash writing and sector erase working. Many thorny little issues, keeping the system from crashing and clearing both CPU caching and FlexSPI FIFOs.

Very cool. Good luck minding all the thorns. Any idea if it will run at good speed? i.e. no apparent conflicts or bus fights - other than the ever so handy and helpful cache - fun things the T_LC didn't 'offer' - and offered direct I/O too …
 
At the moment I'm working on the EEPROM lib. After much fiddling, I believe I finally have the underlying flash writing and sector erase working. Many thorny little issues, keeping the system from crashing and clearing both CPU caching and FlexSPI FIFOs.

Wow, guess you couldn't resist - hope it doesn't you too far back with your fixture testing.
 
3.3v Power or SPI issue Question

Lately I have been testing with my version of the T4 breakout board so I can use Arduino style shields I put together or have. Right now I am testing with the Prop Shield on a shield and it working fine - tested with SensorFusion, LED strips and Serial Flash so all that is good. I tested a ILI9341 shield so I don't have to mess with jumpers (my design) and that works fine by itself like the Prop Shield. If I stack them they run no problem on a T3.5 breakout board, sensor data is displayed in SerMon and Compass displayed on ILI9341. Now if I put them on the T4 breakout the SensorFusion data is displayed on the SerMon but the display just flickers, nothing is displayed.

Not sure this is me or there is some limitation. I am using the ILI9341_t3n library for the display.
 
Status
Not open for further replies.
Back
Top