Teensy 4.0 First Beta Test

Status
Not open for further replies.
After the Restore this is what it tells me about the T4-2:

Could you please run this on your beta #2 board and post the result?

Code:
void setup() {
  while (!Serial) ; //wait
  delay(250);
  const uint8_t *data = (const uint8_t *)0x601FF000;
  for (int i=0; i < 4096; i++) {
    if ((i & 15) == 0) Serial.printf("%04X:", i);
    Serial.printf(" %02X", data[i]);
    if ((i & 15) == 15) Serial.print("\n");
  }
}

void loop() {
}

This program prints a hexdump of the top 4K of your flash chip. The big question is whether I messed up getting the restore program into your board, or if you have a good restore image but the restore process is not properly copying it.
 
I've been looking into the SD issues using SPI. This commit "fixes" SD card access on the audio shield (when CS is set to pin 10), at least well enough for "listfiles" to work, with the 1 card I tested here (Samsung EVO 32GB).

https://github.com/PaulStoffregen/SD/commit/4ca861105f5f127ed2673eef9adea142ed21e95b

I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...

That patch got listfiles working for my Kingston uSD on the SPI uSD on the audio shield on the T4B2. :)

I thought the memset() might just be acting as delay between the CS set and the SPI io, but trying delayMicroseconds(2) in place of memset() didn't work.
 
@KurtE did some good tests of data integrity for Serial#. Quick search didn't find note on pseudorandom.
Hi @defragster and @Paul, and @...

I have done a few different type tests with Serial. Really nothing special.
For hardware Serial, I did something like fill buffer with known values send them, with a loop back test (connect RX to TX) and compare the resulting values...
Extended it to have multiple Serial ports, where everything they receive they send back out. Then hook up Serial1 TX -> Serial 2 RX, 2TX->3RX... 7TX->1RX
And then I can compare the results on what was sent out on Serial1 to begin with with what was returned...

Then a more useful test for me, is try to talk to Robotis Dynamixel servos using Half duplex usually at 1mbs, but have tried 2mbs and more...
This uses a very specific packet format - Actually two different formats:
Older servos run Protocol 1: http://emanual.robotis.com/docs/en/dxl/protocol1/
Most newer ones run Protocol 2: http://emanual.robotis.com/docs/en/dxl/protocol2/

Protocol1 uses simple 1 byte checksum, Protocol 2 uses 2 byte CRC...

On Beta 1, I tried it using Half duplex using (RS485 like support TX direction line), and hooked up to some servos through a OpenCM 485 expansion board.
These boards are used to plug in their cheap controller (OpenCM9.04C) < $20, and it has a connector where the OpenCM9 board connects a Serial RX, TX, IO pin, and GND...
to this board, so I used jumpers from Beta 1 board to appropriate positions on the expansion board.... The servos worked :D

Next up, with working USB, is to try making the B2 board act like a simple Servo controller, where I try to control the servos of a Robot using RPI3... with it sending commands
to T4, which forwards to servos... The most simple version is more or less our simple USB Serial to Serial...

A more complex version is where you logically assign an Servo ID to the controller, who then parses the packets, and if the message is for their ID, it then generates it's own response packet...

Some of the more interesting things about these types of tests is often it is more interested in latency than it is about throughput. That is often times, the code works like:
(Send request to Teensy over USB)->Teensy forward packet over Serial -> Wait for response packet over Serial -> forward response back to program over USB... Program continues...

So The code on both sides is often setup to do something like Serial->flush() when it finishes writing out packet...

Example: On my hexapod I need to get back to, I may want to send out new position and speed (maybe other) to maybe 20 servos. But in that case with SyncWrites it is lets say we output something like 10 bytes per servo (ID, Position, Speed), plus the overhead of packet to the servos 20*10 + about 10 bytes overhead... So about 210 bytes, over USB... Note SyncWrite does not send response so don't have to wait for it... But then the user may want to get current information for the servos, like Current Position, or Torque, or Temp, or ... So again maybe with this we need to send out the request packet (maybe in the size of maybe 50 bytes (20*2 for ids plus overhead). Then wait for response, again probably in the order of 200+ bytes,
And we would like to do this maybe 50-100 times per second...

Will be interesting to see how some things play out for throughput speed. That is for example with the SyncRead. You send out the request for the different servos to respond, each of these servos will wait until the previous servo in the list finishes outputting it's data (plus maybe a gap), before it will send out it's response... So will it be better on USB to wait for all of the packets to finish sending before we respond, or let each part dribble out as it is received...

Probably enough rambling. Will try out some of this soon!
 
Looks like i've managed to "brick" my T4B2.
I edited the imrtx1062.ld file to
Code:
    ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 256K
    DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 256K
and uploaded a simple sketch
(yes I know that I have to configure the "flexram, too.. was about to do it)

And from that point, it does not work anymore.
I took the changes back, but this does not help.
It responds to a button-press and upload seems to work:
Code:
19:29:44.428 (post_compile 1): Begin, version=1.47-beta1, high-res time
19:29:44.632 (loader): Teensy Loader 1.47-beta1, begin program
19:29:44.694 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
19:29:44.710 (loader): Listening for remote control on port 3149
19:29:44.710 (loader): initialized, showing main window
19:29:44.804 (loader): remote connection 1340 opened
19:29:44.804 (loader): remote cmd from 1340: "comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)"
19:29:44.804 (loader): remote cmd from 1340: "status"
19:29:44.804 (loader): HID/win32:  vid:046A pid:0023 ver:0220
19:29:44.804 (loader): HID/win32:  vid:046A pid:0023 ver:0220
19:29:44.804 (loader): remote cmd from 1340: "dir:c:\temp\arduino_build_318689\"
19:29:44.804 (loader): remote cmd from 1340: "file:sketch_apr29a.ino.hex"
19:29:44.804 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
19:29:44.804 (loader): remote cmd from 1340: "status"
19:29:44.806 (post_compile 1): Sending command: comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)
19:29:44.810 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
19:29:44.810 (post_compile 1): Sending command: dir:c:\temp\arduino_build_318689\
19:29:44.810 (post_compile 1): Sending command: file:sketch_apr29a.ino.hex
19:29:44.819 (loader): remote cmd from 1340: "auto:on"
19:29:44.820 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
19:29:44.820 (post_compile 1): Sending command: auto:on
19:29:44.822 (post_compile 1): Disconnect
19:29:44.835 (loader): remote connection 1340 closed
19:29:45.074 (loader): remote connection 1340 opened
19:29:45.074 (loader): remote cmd from 1340: "comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)"
19:29:45.074 (loader): remote cmd from 1340: "status"
19:29:45.074 (loader): remote cmd from 1340: "dir:c:\temp\arduino_build_318689\"
19:29:45.074 (loader): remote cmd from 1340: "file:sketch_apr29a.ino.hex"
19:29:45.074 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
19:29:45.079 (post_compile 2): Begin, version=1.47-beta1, high-res time
19:29:45.081 (post_compile 2): Sending command: comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)
19:29:45.082 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
19:29:45.082 (post_compile 2): Sending command: dir:c:\temp\arduino_build_318689\
19:29:45.082 (post_compile 2): Sending command: file:sketch_apr29a.ino.hex
19:29:45.090 (loader): remote cmd from 1340: "status"
19:29:45.092 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
19:29:45.092 (post_compile 2): Disconnect
19:29:45.105 (loader): remote connection 1340 closed
19:29:45.105 (loader): remote connection 1340 opened
19:29:45.105 (post_compile 3): Running teensy_reboot: "C:\Arduino\hardware\teensy\..\tools\teensy_reboot.exe" teensy_reboot.exe "-board=TEENSY40" "-port=usb:0/1A0000/0/1/6/3" "-portlabel=(null)" "-portprotocol=(null)"
19:29:45.118 (reboot 4): Begin, version=1.47-beta1, high-res time
19:29:45.118 (reboot 4): location = usb:0/1A0000/0/1/6/3
19:29:45.118 (reboot 4): portlabel = (null)
19:29:45.118 (reboot 4): portprotocol = (null)
19:29:45.118 (reboot 4): LoadLibrary cfgmgr32 ok
19:29:45.118 (reboot 4): LoadLibrary ntdll ok
19:29:45.119 (reboot 4): nothing new, skipping HID & Ports enum
19:29:45.121 (loader): remote connection 1408 opened
19:29:45.121 (reboot 4): Disconnect
19:29:45.137 (loader): remote connection 1408 closed
19:29:45.137 (loader): remote connection 1340 closed
19:29:50.160 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
19:29:50.166 (loader): remote connection 1388 opened
19:29:50.168 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#0008d7a1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
19:29:50.168 (ports 5): found_usb_device, loc=usb:0/1A0000/0/1/6/4    Port_#0004.Hub_#0006
19:29:50.168 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0002
19:29:50.168 (ports 5): found_usb_device, devinst=00000012
19:29:50.168 (ports 5): add: loc=usb:0/1A0000/0/1/6/4, class=HID, vid=16C0, pid=0478, ver=0002, serial=0008d7a1, dev=\\?\usb#vid_16c0&pid_0478#0008d7a1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
19:29:50.168 (ports 5): hiddev_from_devinst_list: iface=0
19:29:50.169 (ports 5): found_usb_device complete
19:29:50.169 (ports 5): hid, found devinst=00000013
19:29:50.169 (ports 5): hid, path=\\?\hid#vid_16c0&pid_0478#8&af6fcf9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
19:29:50.169 (ports 5): hid,  opened handle
19:29:50.170 (ports 5):  devinst=00000013, location=usb:0/1A0000/0/1/6/4
19:29:50.170 (ports 5):  vid=16C0, pid=0478, ver=0002, usepage=FF9C, use=0024
19:29:50.170 (ports 5):  devpath=\\?\hid#vid_16c0&pid_0478#8&af6fcf9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
19:29:50.170 (ports 5): usb_add: usb:0/1A0000/0/1/6/4  hid#vid_16c0&pid_0478 (Teensy 4-Beta2) Bootloader
19:29:50.173 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
19:29:50.175 (ports 5): nothing new, skipping HID & Ports enum
19:29:50.188 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
19:29:50.200 (ports 5): nothing new, skipping HID & Ports enum
19:29:50.213 (loader): Device came online, code_size = 1572864
19:29:50.213 (loader): Board is: Teensy 4-Beta2 (IMXRT1062), version 0.02
19:29:50.213 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
19:29:50.213 (loader): set background IMG_ONLINE
19:29:50.213 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
19:29:50.213 (loader): elf appears to be for Teensy 4-Beta2 (IMXRT1062) (1572864 bytes)
19:29:50.213 (loader): elf binary data matches hex file
19:29:50.213 (loader): elf file is for Teensy 4-Beta2 (IMXRT1062)
19:29:50.213 (loader): begin operation
19:29:50.228 (loader): flash, block=0, bs=1024, auto=1
19:29:50.228 (loader):  gauge old value = 0
19:29:50.228 (loader): flash, block=1, bs=1024, auto=1
19:29:50.526 (loader):  gauge old value = 1
19:29:50.536 (loader): flash, block=2, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 2
19:29:50.536 (loader): flash, block=3, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 3
19:29:50.536 (loader): flash, block=4, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 4
19:29:50.536 (loader): flash, block=5, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 5
19:29:50.536 (loader): flash, block=6, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 6
19:29:50.536 (loader): flash, block=7, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 7
19:29:50.536 (loader): flash, block=8, bs=1024, auto=1
19:29:50.536 (loader):  gauge old value = 8
19:29:50.536 (loader): flash, block=9, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 9
19:29:50.546 (loader): flash, block=10, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 10
19:29:50.546 (loader): flash, block=11, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 11
19:29:50.546 (loader): flash, block=12, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 12
19:29:50.546 (loader): flash, block=13, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 13
19:29:50.546 (loader): flash, block=14, bs=1024, auto=1
19:29:50.546 (loader):  gauge old value = 14
19:29:50.556 (loader): sending reboot
19:29:50.556 (loader): begin wait_until_offline
19:29:50.591 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
19:29:50.593 (ports 5): remove: loc=usb:0/1A0000/0/1/6/4
19:29:50.593 (ports 5): usb_remove: usb:0/1A0000/0/1/6/4
19:29:50.593 (ports 5): nothing new, skipping HID & Ports enum
19:29:50.627 (loader): offline, waited 1
19:29:50.627 (loader): end operation, total time = 0.415 seconds
19:29:50.627 (loader): set background IMG_REBOOT_OK
19:29:50.627 (loader): redraw timer set, image 14 to show for 1200 ms
19:29:50.642 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
19:29:50.643 (ports 5): nothing new, skipping HID & Ports enum
19:29:50.709 (loader): HID/win32:  vid:046A pid:0023 ver:0220
19:29:50.709 (loader): HID/win32:  vid:046A pid:0023 ver:0220
19:29:51.837 (loader): redraw, image 9
19:29:52.270 (ports 5): purge, name=hid#vid_16c0&pid_0478 (Teensy 4-Beta2) Bootloader, loc=usb:0/1A0000/0/1/6/4, age=1.677 sec
19:29:56.080 (loader): Verbose Info event
But the program does not run.
Same if I do the 15-sec reset (the inbuilt "blink" works)

Edit: Arduino shows no Teensy port - com1 only, which is on the PC-mainboard.


Edit: Don't know exactly what this was... deleted all Teensy USB dvices from Windows, rebooted, downloaded Teensyduino again and did a fresh install.. works!!
 
Last edited:
Man - a lot going on. Have to download the latest changes. Been trying to get FD working but 0 luck so far. Did find that for CAN3 there is a IOMUXC register missing from imxrt.h but everything else is there. Now just trying to break the code on why its not working. A little more complicated than regular CAN - a couple extra variable thrown in - new MCP2558FD chip and having to get it to talk to a different setup - clickFD board on the T3.5.
 
Could you please run this on your beta #2 board and post the result?

...

This program prints a hexdump of the top 4K of your flash chip. The big question is whether I messed up getting the restore program into your board, or if you have a good restore image but the restore process is not properly copying it.

You read my mind … to read the source …
Code:
[ATTACH]16509._xfImport[/ATTACH]

Code:
08F0: 02 03 01 26 03 54 00 65 00 65 00 6E 00 73 00 79     & T e e n s y
0900: 00 64 00 75 00 69 00 6E 00 6F 00 20 00 52 00 61   d u i n o   R a
0910: 00 77 00 48 00 49 00 44 00 18 03 54 00 65 00 65   w H I D   T e e
0920: 00 6E 00 73 00 79 00 64 00 75 00 69 00 6E 00 6F   n s y d u i n o

Code:
void setup() {
  while (!Serial) ; //wait
  delay(250);
  char lTxt[20];
  int i, jj = 0;
  const uint8_t *data = (const uint8_t *)0x601FF000;
  for (i = 0; i < 4096; i++) {
    if ((i & 15) == 0) Serial.printf("%04X:", i);
    Serial.printf(" %02X", data[i]);
    if ( data[i] >= 32 && data[i] <= 126 )
      lTxt[jj++] = data[i];
    else
      lTxt[jj++] = ' ';
    if ((i & 15) == 15) {
      lTxt[jj] = 0;
      Serial.printf("  %s\n", lTxt);
      jj = 0;
    }
  }
}

void loop() {
}


My sketch ran happily the past hours - encoder turn gave expected messages … general function seems good Paul
 
Last edited:
@Paul, is it correct, that the size of a RAM Bank is 64KB on a 1062, and 32 KB on a 1052?
So, doing this:

noInterrupts();
IOMUXC_GPR_GPR17 = 0x55AFFA55;
IOMUXC_GPR_GPR16 |= (1<<2);
interrupts();

in theory should switch to ITCM=256, DTCM=256, OCRAM =512 ?


However, it seems it does not because this crashes:

#define TESTADR (*( uint32_t *)0x20020000)
TESTADR = 7;

Where is my fault?
 
If I wanted to play a little with canbus suggestions on what I should order?

Hi Kurt. Just woke up :) Anyway to get started with CAN you have to know there are 2 flavors of CAN. CAN2.0 and CANFD. On the T4 you have CAN1/2 on pins 22/23 and pins 0/1. CAN2.0 is also available on the T3.2/3.5/3.6 :) For that all you will need is two transceivers (someone said you could just hook up the pins directly but not sure how reliable that is), I use these, since they are breadboard friendly: https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1. There are several libraries available to use them on the T3.x and @tonton81 has one working for CAN2.0 for the T4 but still a WIP. These have been tested.

Now, CANFD is a different animal, Tony and I are using a Mikro MCP2517FD Click, https://www.digikey.com/products/en?keywords=mikroe mcp2517fd, that we used to play with FD on the T3.x's. Uses SPI to communicate with the FD driver/transceiver on the Click board. @tonton81 has a nice library for that he developed and we tested the heck out of. It's similar to SK Pang's CANFD boards. One would be a minimum to interface to the T4.

Now, I have been playing with the SDK driver but having challenges that I just can't seem to pin down. @tonton81 just got his T4 today so probably more on this later. Not sure if the problems are the clock configuration, pin configuration or something with the driver or with the interface to the Click.

Know this is long winded but figured I would put it out there for reference. I am sure @tonton81 will jump in here if I said anything wrong.
 
I thought the memset() might just be acting as delay between the CS set and the SPI io, but trying delayMicroseconds(2) in place of memset() didn't work.

Yeah, I was a little surprised at first. SD cards are supposed to ignore MOSI during that time, but it seems some cards don't. Kinda makes me wonder what sort of undocumented behavior may be lurking.

At first I wondered how this ever could have worked. But then I realized that particular code is only used by Teensy LC. Makes me wonder if we've had similar SD card problems on LC all this time, but never knew because only some cards are affected and most people don't use LC for heavier tasks involving SD card access?
 
@Paul, is it correct, that the size of a RAM Bank is 64KB on a 1062, and 32 KB on a 1052?
So, doing this:

noInterrupts();
IOMUXC_GPR_GPR17 = 0x55AFFA55;
IOMUXC_GPR_GPR16 |= (1<<2);
interrupts();

in theory should switch to ITCM=256, DTCM=256, OCRAM =512 ?


However, it seems it does not because this crashes:

#define TESTADR (*( uint32_t *)0x20020000)
TESTADR = 7;

Where is my fault?

My fault was that 512KB are dedicated to OCRAM, so the RAM-BANK size is still 32KB.
This works:
noInterrupts();
IOMUXC_GPR_GPR17 = 0xAAAAFFFF;
IOMUXC_GPR_GPR16 |= (1<<2);
interrupts();

//Serial.println(TSTADR);
Serial.println();
Serial.println(IOMUXC_GPR_GPR16, HEX);
Serial.println(IOMUXC_GPR_GPR17, HEX);

#define TSTADR (*( uint32_t *)0x20030000)
TSTADR = 7;

now, with adjusting the stackpointer it should be possible to use the mentioned configuration. Only minor edits to startup.c are needed.

I'll try that tomorrow. Too late here for working people...

However, I need to test OCRAM - not sure if the printed Adress here is correct - it is the same as for 1052(?!)
https://www.nxp.com/docs/en/application-note/AN12240.pdf

 
...we can use a common linker file for all RAM configs :)
Code:
MEMORY
{
    ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
    DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
    RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
    FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1536K
}
[...]
It will not detect overflows anymore - that a job for a new size - print tool... we need it anyway.

...and we can detect the needed ITCM at runtime, so it's possible to automatically select the needed ITCM/DTCM sizes in 32KB steps - at runtime.
I'll do that tomorrow.
 
...we can use a common linker file for all RAM configs :)



It will not detect overflows anymore - that a job for a new size - print tool... we need it anyway.

...and we can detect the needed ITCM at runtime, so it's possible to automatically select the needed ITCM/DTCM sizes in 32KB steps - at runtime.
I'll do that tomorrow.

Good info and progress FrankB! Nice finding you can't really brick the T4 too! - I thought I did it the other day as the 15s Restore took 3 times to work.

Also nice you did the print size tool - that will come in handy and be important given the memory split/segmentation. I was thinking it is good the T4 is small like the T_3.2 - that will leave more room on the card for pin details - but the T4 is going to need a Tech manual - or a good web page or wiki.
 
Tim,
for the fixed 256k, 256k, 512k you can use this:
Code:
void ResetHandler(void)
{
    asm volatile("CPSID I");
    //SCB_MPU_CTRL = 0; // turn off MPU
    IOMUXC_GPR_GPR17 = 0xAAAAFFFF;
    IOMUXC_GPR_GPR16 |= (1<<2);
    //force the stack to begin at some arbitrary location
    asm volatile("mov sp, %0" : : "r" (0x20040000) : );
    asm volatile("CPSIE I");    
    
    unsigned int i;
...
...

with this edit to the imxrt1062.ld file:
Code:
MEMORY
{
    ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
    DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
    RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
    FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1536K
}

ENTRY(ImageVectorTable)
...
...
tomorrow, I try to make it more flexible, and add a "automatic adjust".
Yes the linker files has wrong numbers. This is intentionally.. :)
Attention, OCRAM is still not tested. Maybe we have to adjust the OCRAM adress. I'm not sure...

Good night.

edit: Attention this will not work for the 1052 - We have to add a #ifdef for 1062 only.
 
toromorrow, i try to make it more flexible.

On my todo list (but after USB) is changing the linker script to 512K for both ITCM and DTCM, and an additional program run during the build which checks the total size when rounding each up to nearest 32K doesn't exceed 512K, and of course code in startup to dynamically configure based on the real sizes.

If you're going to work on this soon, please go with that basic approach. I know it'll feel risky declaring 1M of TCM memory in the linker script without the middle step to check for too much memory used, but please go that route and assume I'll later add the overflow check.
 
@PaulStoffregen

Just received the modified breakout board with the addition of the resistor - thank you for doing that. I just played my wavFilePlayer and worked right out of the box, only 1 file didn't play but that's a problem with the file :). The player reads the SD Card on the audio shield and the plays the various formats using @Frank B's codecs:
Code:
initialization done.
SYSTEM~1
Playing file: //OPERAT~1.WAV
2001
Playing file: 2001/CALCUL~1.WAV
Playing file: 2001/COMPLE~1.WAV
Playing file: 2001/DANGER~1.WAV
Playing file: 2001/ENOUGH~1.WAV
Playing file: 2001/FUNCTI~1.WAV
Playing file: 2001/ONE_MO~1.WAV
Playing file: 2001/OPERAT~1.WAV
Playing file: 2001/SORRY_~1.WAV
Playing file: 2001/STOP.WAV
FLAC
Playing file: FLAC/T1_1024.FLA
Playing file: //BERLIN~1.FLA
Playing file: //CHRIST~1.AAC
Playing file: //ODD.MP3
Playing file: //ODD1.MP3
Playing file: //ZARATH~1.MP3
Playing file: //ODD1.WAV
Playing file: //SDTEST1.WAV
Playing file: //CALCUL~1.WAV
I also checked Zelda and Guitar sketches and sounds great.
 
Yes Mike everything you said is correct, i might play a couple more days on the rtr frames before bringing fd into play since it has same offsets as the other busses, once i reconnect the click boards to the t3.5 and t3.6 and have them communicating back and forth in a loop ill be able to work on the FD version from the sdk for t4. The library wont have features or enhancements in it’s current state because i’m rebuilding it from the base up, so only after the functionality is in play i will readd queue support and enhancements. The new library will support up to 128 can ids for fifo and obviously 64 mailboxes (in it’s current state they are working) but i want to tackle the transmissions of rtr, also t4 will have the can clock selectable in future, currently we have the clock running at 60mhz, the sdk runs at 20/24 :)
 
Looking into Windows app for USB I found : github.com Device enumeration and pairing sample

Paul - did you note that 'Winusb.sys' is the inbuilt driver used to talk to a Teensy?

@KurtE / mjs513 - that sample app might be useful for USBHost enumeration and pairing observation

Also thought that or another sample might lead to T4 interface to do some data Transfer testing ...

… Sure While that 27MB package is unzipping the WHOLE sample set - I'll open VS2017 and UPDATE … opps ... Update involves removing the install and pulling down 8.8GB … how handy … my internet is mostly blocking all else and getting 400 to 490KB/sec … just 18+ hours … 1.6GB down ...
 
Paul - did you note that 'Winusb.sys' is the inbuilt driver used to talk to a Teensy?

Nope, we're not using winusb in any way. I'm considering it (and libusb or similar on Mac & Linux) for a future feature, but kinda hoping more Windows users migrate away from version 7 first. Yeah, I know it's possible to make it work on Windows 7, but that requires installing stuff that doesn't fit well with the Teensyduino installer. The last thing I want is more Windows 7 support nightmares!

Please remember to run the code from msg #2576. I want to understand why the restore process isn't always working on your board. The first step is to figure out whether your board really does have a complete copy of the restore image permanently stored in the top of the flash.
 
Paul - reposting this as it seems to have been missed some hours back? Output is in the attached TXT file.

Nope, we're not using winusb in any way. ...

Please remember to run the code from msg #2576. ...

If I worked up the sample - would winusb on my machine find the device as is as far as you know? What is the 'standard windows driver' named that works for Teensy?

You read my mind … to read the source …
Code:
[ATTACH]16509[/ATTACH]

Code:
08F0: 02 03 01 26 03 54 00 65 00 65 00 6E 00 73 00 79     & T e e n s y
0900: 00 64 00 75 00 69 00 6E 00 6F 00 20 00 52 00 61   d u i n o   R a
0910: 00 77 00 48 00 49 00 44 00 18 03 54 00 65 00 65   w H I D   T e e
0920: 00 6E 00 73 00 79 00 64 00 75 00 69 00 6E 00 6F   n s y d u i n o

Code:
void setup() {
  while (!Serial) ; //wait
  delay(250);
  char lTxt[20];
  int i, jj = 0;
  const uint8_t *data = (const uint8_t *)0x601FF000;
  for (i = 0; i < 4096; i++) {
    if ((i & 15) == 0) Serial.printf("%04X:", i);
    Serial.printf(" %02X", data[i]);
    if ( data[i] >= 32 && data[i] <= 126 )
      lTxt[jj++] = data[i];
    else
      lTxt[jj++] = ' ';
    if ((i & 15) == 15) {
      lTxt[jj] = 0;
      Serial.printf("  %s\n", lTxt);
      jj = 0;
    }
  }
}

void loop() {
}

...
 
Yeah, but hard to say exactly what to test or how.

Long ago, there was a thread about sending a huge amount of pseudo-random data in both directions and verifying a checksum after several megabytes. Any maybe measuring the speed along the way. Was going to try to recreate that. If anyone wants to give it a try, please jump in and write a little code on both sides. Otherwise, I'll probably do it in a day or two....

FYI. There were some serial USB throughput and latency tests that we used on K66

https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107140&viewfull=1#post107140
https://www.pjrc.com/teensy/benchmark_usb_serial_receive.html
https://www.pjrc.com/teensy/usb_serial.html
https://forum.pjrc.com/threads/23643-USB-Serial-Receive-Speed-Improvement
https://forum.pjrc.com/threads/7826-USB-to-digital-I-O-delay

Tests were sensitive to the host OS as well as core USB implementation.

and 2011 UNO/Teensy2 discussions http://forum.arduino.cc/index.php?topic=59892.0

EDIT: 6/26/19

USB serial benchmark results (latency_test and USBreadbytes) on T4B2R 1.8.8 1.47-beta4
Code:
latency_test /dev/ttyACM0
port /dev/ttyACM0 opened
waiting for board to be ready:
.ok
latency @ 1 bytes: 0.18 ms average, 3.56 maximum
latency @ 2 bytes: 0.16 ms average, 1.81 maximum
latency @ 12 bytes: 0.13 ms average, 0.21 maximum
latency @ 30 bytes: 0.19 ms average, 4.70 maximum
latency @ 62 bytes: 0.12 ms average, 0.17 maximum
latency @ 71 bytes: 0.17 ms average, 4.26 maximum
latency @ 128 bytes: 0.12 ms average, 0.17 maximum
latency @ 500 bytes: 0.32 ms average, 6.98 maximum
latency @ 1000 bytes: 0.43 ms average, 4.97 maximum
latency @ 2000 bytes: 0.84 ms average, 5.44 maximum
latency @ 4000 bytes: 1.40 ms average, 2.20 maximum
latency @ 8000 bytes: 2.77 ms average, 3.72 maximum

            receive_test /dev/ttyACM0
            port /dev/ttyACM0 opened
            ...
            Bytes per second = 5450581
            Bytes per second = 5459509
            Bytes per second = 5516227
            Average bytes per second = 5450651
 
Last edited:
WOW - the flashcode text has 5 Views! Paul hopefully you are one of them? It was posted as soon as I got to the forum … before I ate even.

T4- has two working encoders with a different interface to each - the @mjs513 linked code and the encoder.h library - both working together without issue - interrupts seems fine. Did a quick edit as the encoder was pulsing 4 times per click so I cut the range/4.

Found a com port stress test that shows ~24KB/sec on T_3.6 with block reads and about the same with byte reads on T4-2 - it sends and gets random data and verifies, seems it doesn't work in 64 byte blocks so the T4 runs same speed - when I did the write(buffer) I forgot the buffer len param and it was showing errors until added on T_3.6, so app works to confirm data and both handled the data.

Visual Studio update completed and rebooted … now [well not now now] to do a loopback test … assuming the PC will be better at write/read/verify with larger memory space. Maybe I'll get somewhere with that by the time read(buf, .available) is ready?

Edit>> now 6 views on the code … and just a few more GB to get the new SDK for Visual Studio …
 
Last edited:
Does anyone on the list of beta testers with only beta #1 hardware, or no hardware at all yet, want to do specific stuff with the beta #2 hardware? Within the next 2 weeks?

The beta #3 boards are being made now. They're approx 2 to 3 weeks out. Beta #3 is nearly identical to beta #2. Beta #3 will be the first machine-built boards and we'll have enough for everyone on the list.

Beta #2 boards take quite a lot of manual labor, so please request one only if you're sure you'll do something specific with it in the next 2 weeks. If you are, please reply here and/or contact me by email. Looks like we can solder up just a few more beta #2 boards. If you're on the list and really have something you want to do with it right now, I'd love to get one of these last beta #2 boards into your hands.

As always, the beta test hardware is only being made available to the people listed in msg #1 of this long thread. When we have more hardware available, I might expand the list a bit - but generally the list is only open to people who've been long-time contributors on this forum and authors of important open source Arduino libraries.
 
Status
Not open for further replies.
Back
Top