Teensy 4.0 First Beta Test

Status
Not open for further replies.
Looks like Arduino Serial Monitor on Macintosh also suffers Java out of memory exceptions with data arriving this fast. :(

mac.jpg
 
I have now installed on RPI3 on Arduino 1.8.9 and all of my compiles for Teensy4 are failing to compile:
Code:
Arduino: 1.8.9 (Linux), TD: 1.47-beta2, Board: "Teensy 4-Beta2, Serial, Faster, US English"

/home/pi/Desktop/arduino-1.8.9/arduino-builder -dump-prefs -logger=machine -hardware /home/pi/Desktop/arduino-1.8.9/hardware -hardware /home/pi/.arduino15/packages -hardware /home/pi/Arduino/hardware -tools /home/pi/Desktop/arduino-1.8.9/tools-builder -tools /home/pi/Desktop/arduino-1.8.9/hardware/tools/avr -tools /home/pi/.arduino15/packages -built-in-libraries /home/pi/Desktop/arduino-1.8.9/libraries -libraries /home/pi/Arduino/libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o2std,keys=en-us -ide-version=10809 -build-path /tmp/arduino_build_811270 -warnings=all -build-cache /tmp/arduino_cache_924888 -verbose /home/pi/.arduino15/packages/OpenCM904/hardware/OpenCM904/1.2.0/libraries/OpenCM9.04/examples/01_Basics/b_Blink_LED/b_Blink_LED.ino
/home/pi/Desktop/arduino-1.8.9/arduino-builder -compile -logger=machine -hardware /home/pi/Desktop/arduino-1.8.9/hardware -hardware /home/pi/.arduino15/packages -hardware /home/pi/Arduino/hardware -tools /home/pi/Desktop/arduino-1.8.9/tools-builder -tools /home/pi/Desktop/arduino-1.8.9/hardware/tools/avr -tools /home/pi/.arduino15/packages -built-in-libraries /home/pi/Desktop/arduino-1.8.9/libraries -libraries /home/pi/Arduino/libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o2std,keys=en-us -ide-version=10809 -build-path /tmp/arduino_build_811270 -warnings=all -build-cache /tmp/arduino_cache_924888 -verbose /home/pi/.arduino15/packages/OpenCM904/hardware/OpenCM904/1.2.0/libraries/OpenCM9.04/examples/01_Basics/b_Blink_LED/b_Blink_LED.ino
Using board 'teensy4b2' from platform in folder: /home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr
Using core 'teensy4' from platform in folder: /home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr
Detecting libraries used...
/home/pi/Desktop/arduino-1.8.9/hardware/teensy/../tools/arm/bin/arm-none-eabi-g++ -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH -I/home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr/cores/teensy4 /tmp/arduino_build_811270/sketch/b_Blink_LED.ino.cpp -o /dev/null
In file included from /home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr/cores/teensy4/wiring.h:44:0,
                 from /home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr/cores/teensy4/WProgram.h:45,
                 from /home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr/cores/teensy4/Arduino.h:6,
                 from /tmp/arduino_build_811270/sketch/b_Blink_LED.ino.cpp:1:
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/type_traits:38:28: fatal error: bits/c++config.h: No such file or directory
compilation terminated.
Error compiling for board Teensy 4-Beta2.

Note: the blink program will compile for Teensy 3.2

Made some progress: Found this folder did not exist: /home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/arm-none-eabi/armv7e-m/fpu/fpv5-d16
Which on PC appeared to have exact copy of bits and ext folder of parent folder... So I did a copy...

Now the compiles go through but link fails:
Code:
Linking everything together...
/home/pi/Desktop/arduino-1.8.9/hardware/teensy/../tools/arm/bin/arm-none-eabi-gcc -O2 -Wl,--gc-sections,--relax -T/home/pi/Desktop/arduino-1.8.9/hardware/teensy/avr/cores/teensy4/imxrt1062.ld -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o /tmp/arduino_build_811270/b_Blink_LED.ino.elf /tmp/arduino_build_811270/sketch/b_Blink_LED.ino.cpp.o /tmp/arduino_build_811270/core/core.a -L/tmp/arduino_build_811270 -larm_cortexM7lfsp_math -lm -lstdc++
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find crti.o: No such file or directory
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find crtbegin.o: No such file or directory
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find crt0.o: No such file or directory
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find -lm
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find -lstdc++
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find -lgcc
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
Error compiling for board Teensy 4-Beta2.

Edit: Note: the lib directory on PC also has a fpv5-d16 folder RPI one does not... Tried to copy again. Still not finding files.

Note On PC, there are a lot more files in the arm7e-m/fpu folder than there are on the RPI... Have not checked out the Linux 64 bit machine version yet...

But now off to other things.
 
Last edited:
In anyone has the time and patience to test with Raspberry Pi, I'd really like to hear whether T4 also suffers from this issue on Raspberry Pi?

https://forum.pjrc.com/threads/5573...ry-Pi-with-USB?p=203634&viewfull=1#post203634

Also curious to hear how the lines/sec benchmark runs on Raspberry Pi. Does the Arduino Serial Monitor on Raspberry Pi also have the heap memory exception? Or does T4's fast transmit so completely overwhelm Java on Raspberry Pi that you can't even get that far?

Well, i fired up my RPI3B+ (headless) and installed 1.8.9 and 1.47-beta2. compiled and ran UNO sketch and T3.6 sketch, but T4B2 failed to compile
Code:
/home/Downloads/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/type_traits:38:28: fatal error: bits/c++config.h: No such file or directory
compilation terminated.
Error compiling for board Teensy 4-Beta2.
?? seems like i've seen this bits/c++config.h problem before ? RPI OS is from May 2018, and I rarely use the RPI

I built USB lines sketch on linux64 and ran it with RPI3 serial monitor (albeit headless, through ssh). I saw 214831 lines/sec, but eventually java croaked
Code:
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
 
Last edited:
@PaulStroffregen and @manitou (and others)
RPI3 with Teensy4...

Got it now to build and run!

Note: I have Arduino 1.8.9 installed on my desktop... As I mentioned in the previous post:

To fix the compiles, I needed to:
Copy all of the files (including directories) in: /home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/arm-none-eabi/armv7e-m/fpu/
To a new child directory of this path) fpv5-d16
Which is: /home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/arm-none-eabi/armv7e-m/fpu/fpv5-d16

This got me to the link... Again a similar issue with needing a child directory of the parent:
/home/pi/Desktop/arduino-1.8.9/hardware/tools/arm/arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16

I tried making that folder and again copy parent folder stuff, which still was not sufficient.
So I went to my 64 bit Linux install and copied the fpu directory from it into my RPI folder of same name... Figured the folder was all .a or .o files which probably did not matter where they were compiled.

It then built and Teensy.exe update the T4 :D

Brought up the USB Speed test and like windows (and MAC) it died iwth java.lang.OutOfMemoryError: Java heap space

Kurt
 
uSDFS on Teensy 4b2

got uSDFS (reworked, simplified and refactored) https://github.com/WMXZ-EU/uSDFS working on T4b2
implemented spi, usdhc, and msc (usb-disk) from @wwatson https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments

uSDFS uses ELM CHaN's FATFS, which supports exFAT.

For the time being I tested it with SPI (AudioCard), USDHC, but not MSC (have no spare USB-stick at hand)
Configuration capability is reduced (was better in earlier version of uSDFS and will be addressed again later)

Caveat: SPI is seperate implementation and not compatible with stock Teensy SPI library (no transaction) so there can be side-effects.
 
@mjs513 - Thanks,

Some of it was just figuring out what files were on one computer (Windows and not on the RPI version).
So did a search on RPI for: c++config.h (find | grep c++config.h )
Probably more direct ways to do a locate of files, but...
And If I remember correctly found it in 6 places:

Then did the same on my Windows 10 machine (actually here I just typed c++config.h in search box of folder) and it found it in 7 places...
Then I verified that the files appeared to be the same at both directories...

@WMXZ - Sounds great - I need to try it out! Not sure is it best to try out for SD Cards with the SD slot or with USB Host stuff?

Thanks
Kurt
 
got uSDFS (reworked, simplified and refactored) https://github.com/WMXZ-EU/uSDFS working on T4b2
implemented spi, usdhc, and msc (usb-disk) from @wwatson https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments

uSDFS uses ELM CHaN's FATFS, which supports exFAT.

For the time being I tested it with SPI (AudioCard), USDHC, but not MSC (have no spare USB-stick at hand)
Configuration capability is reduced (was better in earlier version of uSDFS and will be addressed again later)

Caveat: SPI is seperate implementation and not compatible with stock Teensy SPI library (no transaction) so there can be side-effects.

That sounds way cool WMXZ - Good work.

No spare SDHC Flash 'chips' and USB adapters?
 
@WMXZ

Nice job on converting but I am testing it now with uSDFS test sketch. Depending on the option I get a variety of errors:
Code:
OPT 0:  Get a done of error messages before it exits
OPT 1:
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_status':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:44: undefined reference to `MSC_disk_status'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_initialize':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:84: undefined reference to `MSC_disk_initialize'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_read':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:130: undefined reference to `MSC_disk_read'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_write':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:181: undefined reference to `MSC_disk_write'
collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy 4-Beta2.

OPT 2:
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_status':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:44: undefined reference to `MSC_disk_status'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_initialize':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:84: undefined reference to `MSC_disk_initialize'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_read':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:130: undefined reference to `MSC_disk_read'
C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_write':
D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:181: undefined reference to `MSC_disk_write'

Not sure what I am doing wrong here.

EDIT:
If I compile with the MSC Sketch:
Code:
Arduino: 1.8.9 (Windows 10), TD: 1.47-beta2, Board: "Teensy 4-Beta2, Serial, Faster, US English"

C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_status':

D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:44: undefined reference to `MSC_disk_status'

C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_initialize':

D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:84: undefined reference to `MSC_disk_initialize'

C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_read':

D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:130: undefined reference to `MSC_disk_read'

C:\Users\Merli\AppData\Local\Temp\arduino_build_665720\libraries\uSDFS-master\diskio.c.o: In function `disk_write':

D:\Users\Merli\Documents\Arduino\libraries\uSDFS-master\src/diskio.c:181: undefined reference to `MSC_disk_write'

collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy 4-Beta2.
Invalid library found in D:\Users\Merli\Documents\Arduino\libraries\FRAM_MB85RC_I2C_store_anythingv1: no headers files (.h) found in D:\Users\Merli\Documents\Arduino\libraries\FRAM_MB85RC_I2C_store_anythingv1
Invalid library found in D:\Users\Merli\Documents\Arduino\libraries\FRAM_MB85RC_I2C_store_anythingv1: no headers files (.h) found in D:\Users\Merli\Documents\Arduino\libraries\FRAM_MB85RC_I2C_store_anythingv1

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

EDIT2: Lib is having problems finding the libs in Utility and if I move them to the main src directory it can not find diskio.h so not sure whats going on.
 
Last edited:
@WMXZ and @mjs513..

About the source file sd_msc.cpp...
Code:
#include "sd_msc.h"
 
#define HAVE_MSC 1

#if HAVE_MSC == 1
	#if defined __MK66FX1M0__ || defined __MK64FX512__
		#include "msc.h"
		#include "MassStorage.h"

		static int MSC_disk_status() {return 0;}

		static int MSC_disk_initialize() 
		{	return mscInit();
		}

		static int MSC_disk_read(BYTE *buff, DWORD sector, UINT count) 
		{
			WaitDriveReady();
			return readSectors((BYTE *)buff, sector, count);
		}

		static int MSC_disk_write(const BYTE *buff, DWORD sector, UINT count) 
		{
			WaitDriveReady();
			return writeSectors((BYTE *)buff, sector, count);
		}

		static int MSC_ioctl(BYTE cmd, BYTE *buff) {return 0;}
	#endif
#else
	static int MSC_disk_status() {return 0;}
	static int MSC_disk_initialize() {return 0;}
	static int MSC_disk_read(BYTE *buff, DWORD sector, UINT count) {return 0;}
	static int MSC_disk_write(const BYTE *buff, DWORD sector, UINT count) {return 0;}
	static int MSC_ioctl(BYTE cmd, BYTE *buff) {return 0;}
#endif
Unless I am confused, I believe that the static at start of these imples that the function is only defined for this source file... So won't be used by others...
Will experiment and try to build removing it... At least for the second part that should be for T4...
And actually don't think this will compile for anything for T4 as HAVE_MSC == 1 is defined and we are not T3.5 or T3.6...

Edit: Example compiles if I set HAVE_MSC 0
And got rid of warnings, by commenting out static (complained they were defined elsewhere as external)

Edit2: It appears to run as well, with SD Card in on T4B2...
Code:
Test uSDFS
1:/

Change drive

Create a new subdirectories.

Create a new file /Ascii/HELLO12.TXT.
Write some text lines. (Hello world!)
Close the file.

Open same file /Ascii/HELLO12.TXT.
Get the file content.
Hello world!
Second Line
Third Line
Fourth Line
Habe keine Phantasie
Close the file.

open binary file
write file
close file
Binary test done

Open root directory.
Directory listing...
   <dir>  System Volume Information
   <dir>  Ascii
   <dir>  Binary
  230454  ANNIE1.BMp
  230456  annie3.bmp
  230456  annie2.bmp

Test completed.
 
Last edited:
@PaulStroffregen and @manitou (and others)
RPI3 with Teensy4...

Got it now to build and run!

Kurt,
I almost got T4B2 to compile on RPI with your instructions, perhaps, I misunderstood. Anyhow, here is what I did. I used the fpu/ directories from my linux64 teensyduino to replace the RPI teensyduino fpu/ directories in the following folders
Code:
hardware/tools/arm/arm-none-eabi/include/c++/5.4.1/arm-none-eabi/armv7e-m/
hardware/tools/arm/arm-none-eabi/lib/armv7e-m/
hardware/tools/arm/lib/gcc/arm-none-eabi/5.4.1/armv7e-m

some results from RPI 3B+
Code:
           latency @ 1 bytes: 0.06 ms average, 0.15 maximum
           latency @ 2 bytes: 0.06 ms average, 0.11 maximum
           latency @ 12 bytes: 0.07 ms average, 0.11 maximum
           latency @ 30 bytes: 0.07 ms average, 0.17 maximum
           latency @ 62 bytes: 0.07 ms average, 0.19 maximum
           latency @ 71 bytes: 0.12 ms average, 0.22 maximum
           latency @ 128 bytes: 0.13 ms average, 0.19 maximum
           latency @ 500 bytes: 0.38 ms average, 0.46 maximum
           latency @ 1000 bytes: 0.76 ms average, 0.80 maximum
           latency @ 2000 bytes: 1.47 ms average, 1.53 maximum
           latency @ 4000 bytes: 2.75 ms average, 2.87 maximum
           latency @ 8000 bytes: 5.36 ms average, 5.48 maximum

        USBsend to serial_listen /dev/ttyACM0
         Total bytes read: 37711382
         Speed 3771.14 kbytes/sec

        USBread to receive_test /dev/ttyACM0
          Bytes per second = 1508637
1.8.9 1.47-beta2 T4B2
 
@WMXZ and @mjs513..

About the source file sd_msc.cpp...
Code:
#include "sd_msc.h"
 
#define HAVE_MSC 1

#if HAVE_MSC == 1
	#if defined __MK66FX1M0__ || defined __MK64FX512__
		#include "msc.h"
		#include "MassStorage.h"

		static int MSC_disk_status() {return 0;}

		static int MSC_disk_initialize() 
		{	return mscInit();
		}

		static int MSC_disk_read(BYTE *buff, DWORD sector, UINT count) 
		{
			WaitDriveReady();
			return readSectors((BYTE *)buff, sector, count);
		}

		static int MSC_disk_write(const BYTE *buff, DWORD sector, UINT count) 
		{
			WaitDriveReady();
			return writeSectors((BYTE *)buff, sector, count);
		}

		static int MSC_ioctl(BYTE cmd, BYTE *buff) {return 0;}
	#endif
#else
	static int MSC_disk_status() {return 0;}
	static int MSC_disk_initialize() {return 0;}
	static int MSC_disk_read(BYTE *buff, DWORD sector, UINT count) {return 0;}
	static int MSC_disk_write(const BYTE *buff, DWORD sector, UINT count) {return 0;}
	static int MSC_ioctl(BYTE cmd, BYTE *buff) {return 0;}
#endif
Unless I am confused, I believe that the static at start of these imples that the function is only defined for this source file... So won't be used by others...
Will experiment and try to build removing it... At least for the second part that should be for T4...
And actually don't think this will compile for anything for T4 as HAVE_MSC == 1 is defined and we are not T3.5 or T3.6...

Edit: Example compiles if I set HAVE_MSC 0
And got rid of warnings, by commenting out static (complained they were defined elsewhere as external)

Edit2: It appears to run as well, with SD Card in on T4B2...
Code:
Test uSDFS
1:/

Change drive

Create a new subdirectories.

Create a new file /Ascii/HELLO12.TXT.
Write some text lines. (Hello world!)
Close the file.

Open same file /Ascii/HELLO12.TXT.
Get the file content.
Hello world!
Second Line
Third Line
Fourth Line
Habe keine Phantasie
Close the file.

open binary file
write file
close file
Binary test done

Open root directory.
Directory listing...
   <dir>  System Volume Information
   <dir>  Ascii
   <dir>  Binary
  230454  ANNIE1.BMp
  230456  annie3.bmp
  230456  annie2.bmp

Test completed.

@KurtE and @WMXZ

Ran the test with MSC=0 with and without static and no problem with it reading the disc. Think that issue is that there is not define for 1062 only the T3.5 and 3.6? Is the 3.5 suppose to be 1062?

EDIT: Nope just answered my own question with a simple test.
 
Follow up on post below - the lps_test.exe is still running and the signs of dropout continues - but T4b2 still running past 4 million 64K buffer reads of the LPS Sketch data - that is really 8+ Billion printed lines { by buffer counts and the elapsed time } at 157K/sec for the past hours!

Again this is Windows with lps_test.exe running - the text between >> and << is clipped from the buffer \n's :: Just updated github.com/Defragster/T4_demo/.../TView with the change noted with post below.
>> So the USB Connect is stable between T4n2 and the PC - just dropping bytes?

I mention this seeing is look similar to other thread Serial Monitor missing data on some Macintosh computers

Code:
#4121199[64K] : __>> count=1084454309, lines/sec=157006 <<__
#4121200[64K] : __>> count=1084456130, lines/sec=157006 <<__
#4121201[64K] : __>> count=1084457951, lines/sec=157006 <<__
#4121202[64K] : __>> count=1084459772, lines/sec=157006nt=1084457952, lines/sec=157006 <<__
#4121203[64K] : __>> count=10844615ines/sec=157006 <<__
#4121204[64K] : __>> count=1084463413, lines/sec=1 <<__
#4121205[64K] : __>> count=10843, lines/sec=1 <<__
#4121206[64K] : __>> count=1084465234, lines/sec=157006 <<__
#4121207[64K] : __>> count=1084468876, lines/sec=157006 <<__

As noted - yes - but Serial full is no longer blocking so the lps_test sketch is skewed now on T4 like it was before on T_3.x's. It isn't showing impossible numbers - just untrue.

And to update - TyCommander Serial to T4-2 with beta 2 is still running usably - showing 311-370K type numbers.


The lps_test.exe I made is keeping going at 140-150K lps. I put in an exit when it got 4 _brk_ from waiting - and that was statis and adding up - so I had to zero it on read data - so now it keeps running without quitting falsely.

It is showing data loss in the 64K buffer - where it reads the first \n string in the buffer after the first \n found after it has read 512 bytes - so it has pulled buffered data before stopping to print.

Both of those things did not happen before - accumulating wait timeouts nor showing regular skips in the data string
 
the signs of dropout continues

Can you delete these lines from usb_serial_write() in usb_serial.c and check if the dropouts continue or disappear?

Code:
                        if (transmit_previous_timeout) return sent;
                        if (systick_millis_count - wait_begin_at > TX_TIMEOUT_MSEC) {
                                // waited too long, assume the USB host isn't listening
                                transmit_previous_timeout = 1;
                                return sent;
                                //printf("\nstop, waited too long\n");
                                //printf("status = %x\n", status);
                                //printf("tx head=%d\n", tx_head);
                                //printf("TXFILLTUNING=%08lX\n", USB1_TXFILLTUNING);
                                //usb_print_transfer_log();
                                //while (1) ;
                        }

Earlier I mentioned this feature tends to mask other problems. Maybe I put it back in too soon? Or maybe it's causing the issue?
 
opps … Looking at the posted code - there was a mistake in the test code for lps_test.exe :(

This problem NOT from Teensy - but a conditional in the code was wrongly written.

Restored the usb_serial_write() code and all is well.

Edited output to add length of string printed - all are showing '33' - dropped to 8K buffer for more freq testing as well:
#164908[8K] : __>> count=191368987, lines/sec=160856 <<__(33)
#164909[8K] : __>> count=191369221, lines/sec=160856 <<__(33)
#164910[8K] : __>> count=191369455, lines/sec=160856 <<__(33)

It is looping after each full buffer and then knowing where the first \n is I walk the buffer to count them to be where epected:
#53639[128K] : __>> count=439127096, lines/sec=166581 << > Good lines=3745____
#53640[128K] : __>> count=439130841, lines/sec=166581 << > Good lines=3745____
#53641[128K] : __>> count=439134586, lines/sec=166581 << > Good lines=____3744
#53642[128K] : __>> count=439138330, lines/sec=166581 << > Good lines=3745____
#53643[128K] : __>> count=439142075, lines/sec=166581 << > Good lines=3745____

This is working - except after a pause when the lines change and on occasion I'm seeing this:
#58373[128K] : __>> count=604637049, lines/sec=153037 << > Good lines=727____
> _____MISSED lines____
#58374[128K] : __>> count=604640802, lines/sec=153037 << > Good lines=____3744
 
Last edited:
Not a perfect or exhaustive check on incoming strings - but now confirming the first \n char in buffer is followed at the expected interval for the rest of the buffer. This lps_test is derived from latency_test code - to just read Teensy data to RAM buffer.

To cut down on interruptions only printing after each 100K lines tested. Windows "Alt+Tab" window change was showing some data corruption when printing line for each tested buffer as it scrolled fast up the window. Now only printing 1 line for each 28 buffers of 128 KB, or 1 for 10 of 384KB .

Only testing from first \n in buffer to last \n - so at least one will be split - then print the # of \n found where expected (Good lines=10923____) and when there is a miss found that FIRST test area is printed. Keeping the data testing toward the minimal shows ~150K lines per seconds.
Code:
 > _____MISSED lines____ #1
690, lines/sec=439840
count=1970538691, lines/sec=439840
count=1970538692, lines/sec=439840
count=1970538693, lines/
#0[384K] : __>> count=1965534272, lines/sec=153984 << > Good lines=____44
#10[384K] : __>> count=1970647873, lines/sec=266603 << > Good lines=____10922
#20[384K] : __>> count=1970757099, lines/sec=266603 << > Good lines=10923____
#30[384K] : __>> count=1970866326, lines/sec=161792 << > Good lines=10923____
#40[384K] : __>> count=1970975553, lines/sec=148409 << > Good lines=____10922
#50[384K] : __>> count=1971084779, lines/sec=148409 << > Good lines=10923____
#60[384K] : __>> count=1971194006, lines/sec=141607 << > Good lines=10923____
#70[384K] : __>> count=1971303233, lines/sec=143199 << > Good lines=____10922

When I click in the dos box to select test data it results in missed data detected - as it does on first starting - when lps is 0 or not up to 6 digit stable value.

Odd thing not accounted for is that Teensy 'count=' # advances more than my 'Good lines=' and I only expect to lose a couple per buffer - I don't know what happens after one buffer's last \n and the start of the next to the first \n while buffer is being verified.

With 4KB buffers I just saw 11 lost per 100K, and with a 384KB buffer it was over 9,000 - I suspect that is because PC is not emptying the buffer as the buffer check is longer on 384KB buffer and without Serial.availableForWrite() it is over counting in sketch when the out buffer is full.

<edit> some of the error was resetting the counter after 100K rather than reducing by 100K - another part is buffer crossing the 100K point during checkout of sync with printed line extreme on large buffer:
Code:
#23731[4K] : __>> count=2664606852, lines/sec=157504 << >1> Good lines=____114
#24609[4K] : __>> count=2664706749, lines/sec=157504 << >1> Good lines=____114
#25488[4K] : __>> count=2664806760, lines/sec=157560 << >1> Good lines=113____
#26367[4K] : __>> count=2664906770, lines/sec=157560 << >1> Good lines=____114
Just saw first unforce error report - no showing enough to see what was lost.
 
Last edited:
Not sure what prompted this intrusion? Running fine for some time - 6.49M buffers 4KB in size - now using computer and saw this flash by. Probably a spasm caused using the EDGE browser {holding over 5GB of RAM - with bounces to 7GB and 27 to 57% of CPU} - but why this data in app buffer? Machine has too much open and is sluggish - has had IDE crash twice without reboot in 4 days.

Somehow my testing started on a clean message edge show it had >0> errors indicated in : >0> Good lines=____114.

Then the buffer was found corrupted in these successive fillings - where only the first error is shown when found in a buffer - then it went back to normal.
Buffer is statically allocaed in compile and re-used:
Code:
#6494238[4K] : __>> count=3503584334, lines/sec=163767 << >0> Good lines=____114
#6495117[4K] : __>> count=3503684345, lines/sec=168548 << >0> Good lines=113____
#6495996[4K] : __>> count=3503784355, lines/sec=168548 << >0> Good lines=____114

 > _____MISSED lines____ #1 {cpl=208}
[COLOR="#FF0000"]" />
        <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.17763.1" processo[/COLOR]
#6496640[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterCorEdition" version="10.0.17763.1 >1> Good lines=____2

 > _____MISSED lines____ #2 {cpl=343}
[COLOR="#FF0000"]ame="HyperV-Storage-VHD-VHDMP-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildTyp[/COLOR]
#6496641[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >2> Good lines=____2

 > _____MISSED lines____ #3 {cpl=209}
[COLOR="#FF0000"]35" />
        <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEdition" version="10.0.17763.1" processorArch[/COLOR]
#6496642[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterACorEdition" version="10.0.17763. >3> Good lines=____2

 > _____MISSED lines____ #4 {cpl=343}
ame="HyperV-Storage-QoS-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="rel
#6496643[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >4> Good lines=____2

 > _____MISSED lines____ #5 {cpl=209}
/>
        <assemblyIdentity name="Microsoft-Windows-ServerSolutionEdition" version="10.0.17763.1" processorArchitectu
#6496644[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalEdition" version="10.0.17763. >5> Good lines=3____

 > _____MISSED lines____ #6 {cpl=212}
" />
        <assemblyIdentity name="Microsoft-Windows-ServerHyperCoreEdition" version="10.0.17763.1" processorArchite
#6496645[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.177 >6> Good lines=____2

 > _____MISSED lines____ #7 {cpl=209}
/>
        <assemblyIdentity name="Microsoft-Windows-ServerSolutionEdition" version="10.0.17763.1" processorArchitectu
#6496646[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalEdition" version="10.0.17763. >7> Good lines=____2

 > _____MISSED lines____ #8 {cpl=210}
" />
      </parent>
    </parent>
    <installerAssembly name="Microsoft-Windows-ServicingStack" version="6.0.0.0"
#6496647[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerStandardEvalCorEdition" version="10.0.17763 >8> Good lines=____2

 > _____MISSED lines____ #9 {cpl=207}
35" />
        <assemblyIdentity name="Microsoft-Windows-ServerStandardEdition" version="10.0.17763.1" processorArchit
#6496648[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerStandardACorEdition" version="10.0.17763.1" >9> Good lines=____2

 > _____MISSED lines____ #10 {cpl=343}
ame="HyperV-IsolatedVM-SVC-onecore-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" bui
#6496649[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >10> Good lines=____2

 > _____MISSED lines____ #11 {cpl=209}
/>
        <assemblyIdentity name="Microsoft-Windows-ServerSolutionEdition" version="10.0.17763.1" processorArchitectu
#6496650[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalEdition" version="10.0.17763. >11> Good lines=____2

 > _____MISSED lines____ #12 {cpl=343}
ame="HyperV-IntegrationComponents-VirtualDevice-Core-Package" version="10.0.17763.1" processorArchitecture="amd64" lang
#6496651[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >12> Good lines=____2

 > _____MISSED lines____ #13 {cpl=343}
ame="HyperV-Hypervisor-onecore-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildTy
#6496652[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >13> Good lines=____2

 > _____MISSED lines____ #14 {cpl=212}
" />
        <assemblyIdentity name="Microsoft-Windows-ServerHyperCoreEdition" version="10.0.17763.1" processorArchite
#6496653[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.177 >14> Good lines=____2

 > _____MISSED lines____ #15 {cpl=343}
ame="HyperV-Guest-Vpci-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="rele
#6496654[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >15> Good lines=____2

 > _____MISSED lines____ #16 {cpl=212}
" />
        <assemblyIdentity name="Microsoft-Windows-ServerHyperCoreEdition" version="10.0.17763.1" processorArchite
#6496655[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.177 >16> Good lines=3____

 > _____MISSED lines____ #17 {cpl=343}
ame="HyperV-Guest-IcSvc-Package" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="rel
#6496656[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >17> Good lines=____2

 > _____MISSED lines____ #18 {cpl=207}
35" />
        <assemblyIdentity name="Microsoft-Windows-ServerStandardEdition" version="10.0.17763.1" processorArchit
#6496657[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerStandardACorEdition" version="10.0.17763.1" >18> Good lines=____2

 > _____MISSED lines____ #19 {cpl=343}
ame="HyperV-Compute-System-VirtualMachine-vm-Package" version="10.0.17763.1" processorArchitecture="amd64" language="ne
#6496658[4K] : __>> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB449 >19> Good lines=____2

 > _____MISSED lines____ #20 {cpl=212}
" />
        <assemblyIdentity name="Microsoft-Windows-ServerHyperCoreEdition" version="10.0.17763.1" processorArchite
#6496659[4K] : __>>         <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.177 >20> Good lines=____2
#6496894[4K] : __>> count=3503886629, lines/sec=167554 << >20> Good lines=____114
#6497773[4K] : __>> count=3503986640, lines/sec=139197 << >20> Good lines=113____
#6498652[4K] : __>> count=3504086650, lines/sec=139197 << >20> Good lines=____114

Also interesting the Teensy 'count=' is only 10 or 11 off in checking \n registration after 100K checks with 4K buffer. The count is incremented on the fir \n even though what came before it is unchecked.
the {cpl=#} is the chars per line calculated from sample data assuming all messages should be he same as the first in the buffer - it is normally {cpl=36} to jump between \n's.
 
No spare SDHC Flash 'chips' and USB adapters?
I have indeed a USB adapter, So will continue testing.
I did test with T4B2 native SDHC card

@KurtE:
I put static, as I thought in C++ static means that function is C-style and not C++ style.
But the extern"C" declaration in header may have same effect.

@mjs513
That missing 1062 declaration was cut and past issue (GitHub directory is not coinciding with Arduino library)
 
I have indeed a USB adapter, So will continue testing.
I did test with T4B2 native SDHC card

@KurtE:
I put static, as I thought in C++ static means that function is C-style and not C++ style.
But the extern"C" declaration in header may have same effect.

@mjs513
That missing 1062 declaration was cut and past issue (GitHub directory is not coinciding with Arduino library)
If I can ask a couple of questions since I am not sure the difference between SPI and SDHC. SPI seems to read the SD Card on SPI with no problem. Question is, if I try to read a sdhc either on board or via USB doesn't seem to work get either a rc=1 or rc=13 depending on option 1 or 2.

Also, I did notice that for MSC=1 it is looking for massstorage.h - can I just copy and past those files over? Secondly in the MSC.zip instructions were to copy and past 4 files to replace yours - am I assuming that I don't have to do that anymore?

As for the GITHUB not syncing - been there - I understand - can I just add it.
 
@WMXZ and @mjs513 -

I was also wondering if I needed to use the zip file with the MSC files or not or... Would be great to be able to easily use a USB storage device!

as for the static versus extern "C" - More a question for other C/C++ experts... My understanding (probably wrong) is there are two different uses of the static keywords in c++
a) Outside of a class - The scope of the function(or variable) is only visible within that compile unit (c/c++ source file).
b) Inside class definition - The function/variable - is not specific to any instance of the class...

Again great work!
 
If I can ask a couple of questions since I am not sure the difference between SPI and SDHC. SPI seems to read the SD Card on SPI with no problem. Question is, if I try to read a sdhc either on board or via USB doesn't seem to work get either a rc=1 or rc=13 depending on option 1 or 2.

Also, I did notice that for MSC=1 it is looking for massstorage.h - can I just copy and past those files over? Secondly in the MSC.zip instructions were to copy and past 4 files to replace yours - am I assuming that I don't have to do that anymore?

updated GitHub

Only to make sure, what I have here is
running uSDFS_test on T4b2 with
- TEST_DRV=0 and uSD card in AudioCard: works fine
- TEST_DRV=1 and uSD card on expansion board: works fine
- TEST_DRV=2 and uSD card in uSD to USB adapter: hangs in mscInit() while waiting for device available (no error thrown)

Now, my problems with MSC is that I compile with USB_SERIAL
I recall that USBHost needs USB_DISABLED as it uses own USB stack
now, if I compile with USB_DISABLED, usb.c complains that "NUM_ENDPOINTS" is not defined (USB_DISABLED is not part of usb_desc.h)

@KurtE
I may migrate Warrens USBHost interface into uSDFS

edit:
@mjs513: run test on T3.6 with build-in SDHC (TEST_DRV = 1) got the same rc=1 error
OK will investigate
 
Last edited:
@WMXZ

Only to make sure, what I have here is
running uSDFS_test on T4b2 with
- TEST_DRV=0 and uSD card in AudioCard: works fine
- TEST_DRV=1 and uSD card on expansion board: works fine

Just downloaded the latest and confirm if I put an SD Card where it belongs it works fine as you stated. Don't get that RC=1 error message anymore. Glad it helped with finding the T3.6 issue.
 
I've read through the last 18 pages (starting with msg #2351) and updated msg #6 with unresolved issues. Will look farther back in a few days.

If anyone knows of any problems that aren't on msg #6, please edit it, or just reply and I'll add them.
 
@PaulStoffregen
Went ahead and updated the status of some of the issues that are resolved. Have to check on a couple of more.

EDIT: Just noticed that there is some duplication between the library post #4 and #6.
 
Status
Not open for further replies.
Back
Top