Teensy 4.0 First Beta Test

Status
Not open for further replies.
@mjs513... I played some more with speeding up drawing... Did sort of a hack and created a sub-class of the ST7735_t3 library, to add writeRect() function like ILI9341... Should maybe add to main one... And I build one line at a time...

Probably all for today...
 

Attachments

  • uncannyEyes-190707b.zip
    943.9 KB · Views: 80
@KurtE

Strange. I added in @defragster's debug and got this for output but its still running fine:
Code:
C:\Users\Merli\OneDrive\Desktop\uncannyEyes\uncannyEyes.ino Jul  7 2019 21:24:12

********
 T4 connected Serial_tt ******* debug_tt port


C:\Users\Merli\OneDrive\Desktop\uncannyEyes\uncannyEyes.ino Jul  7 2019 21:24:12
>>> Reason for 'reset': 1 IPP_RESET_B :: done Reason
F_CPU==600000000   F_BUS==150000000 FreeMem(); 4293328804
Init
//...
I am using two of the adafruit ST7735R displays (https://www.amazon.com/gp/product/B00SK6932C/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1). Don't have any other ones to test with. Which do you recommend for me to get to give it try, if you don't solve it first.

Cool you both got debug_tt to install and work. That Reason for 'reset' - is bogus - I never implemented the proper read of SRC_SRSR ? - but it is displayed because the T_3.x code is there and works.
 
Paul - Help - Post #6 corrupted/Truncated by my browser/ISP web - can you revert?

<edit>: missing segment should be restored - finally got the version compare to show edits to copy and replace

Trying to remove this from Msg #6 - it is a duplicate of the resolved BrownOut PCB change.
board not detected until other Teensy boards unplugged, #2373,

Copied that entry - but not the whole post before trying a save - and saving post choked ...

I was there seeing the there is ONE issue noted for 'Optimize' - it mentioned One issue with 'Pure' - but most times the default optimize wasn't picked the build wasn't good. SO some effort for testing alternate build Optimize would be good.
 
Last edited:
Playing with GPT1 and GPT2, I found that the highest clock speed available in the Clock selections (powerup de facto) to be 24 MHz. I'm trying to make 150 MHz available for counting. Reading the 1060 RM, diagram Fig 13-2 (p 1072), it looks like PERCLK_CLK_ROOT has a muxed source either IPG_CLK_ROOT or OSC. This is controlled by bit 6 in CSCMR1[PERCLK_CLK_SEL]. But there is a warning note in 13.7.7 to disable modules using this clock first, or else irreversible damage can happen.

The diagram shows GPT and PIT timers. Does Teensduino use the PIT timers de facto ? If so then I should disable these before I try change this selector. Does anyone know of other modules using this source that also need disabling first?
 
@mjs513... I played some more with speeding up drawing... Did sort of a hack and created a sub-class of the ST7735_t3 library, to add writeRect() function like ILI9341... Should maybe add to main one... And I build one line at a time...

Probably all for today...

Kurt - just tested it and seems to working smoother to my eye (pun intended). Would go ahead and add it to the ST7735 and guess 7789 class.
 
Post #6 corrupted/Truncated[/URL] by my browser/ISP web - can you revert?

No, not without reverting the entire forum. Our server backups are only once per day (around 10:30 to 11pm pacific time), so any revert of the entire forum would be the state it happened to be at the time the backup ran. The backup is really only meant for recovery from a complete catastrophic loss, like if the server hardware dies.

Perhaps we should abandon using the forum's table feature on msg #4 and msg #6. It makes editing more difficult and error prone. Originally those messages were just "code" text.
 
Last edited:
Paul - Help - Post #6 corrupted/Truncated by my browser/ISP web - can you revert?

<edit>: missing segment should be restored - finally got the version compare to show edits to copy and replace

Trying to remove this from Msg #6 - it is a duplicate of the resolved BrownOut PCB change.
board not detected until other Teensy boards unplugged, #2373,

Copied that entry - but not the whole post before trying a save - and saving post choked ...

I was there seeing the there is ONE issue noted for 'Optimize' - it mentioned One issue with 'Pure' - but most times the default optimize wasn't picked the build wasn't good. SO some effort for testing alternate build Optimize would be good.

@defragster - @Paul,

Just looking at Msg #6 looks like its restored compared to what was there last night (and what I remember and notes on the list) when I saw @defraster's original post. Nice work Tim :)
 
Kurt - just tested it and seems to working smoother to my eye (pun intended). Would go ahead and add it to the ST7735 and guess 7789 class.
Yep! - Using the FPS that was being output in the terminal monitor, before this change it was outputting about 8fps with this change it was outputting about 63-64pfs

Having it build whole image into an array and only calling writeRect once sped up to about 70fps...

Also found that the reset pin delay was left pretty large (1.5 seconds), so changed to match Adafruit SPITft code to .4 seconds.

And put in PR: https://github.com/PaulStoffregen/ST7735_t3/pull/2
 
@KurtE
The FPS is exactly what I was seeing - so quite a bit of speed up which is noticeable. Nice job.
 
@mjs513 - Not T4 specific - But wondering if it would make sense to add frame buffer support to the displays. Would not gain much over current stuff as more or less did that with the one writeRect (which you would translate to updateScreen in my ili9341_t3n library... However if I then added the DMA (asynchronous Update) in, wonder how well it would work with this app, IF you could change to each eye on different SPI buss and then start DMA update on each eye such that they both update at the same time... But again not T4 Beta/release issue... So may hold off for now.
 
@KurtE
Here is something interesting for you to ponder.

I loaded the changes to my original sketch (w/o debug_tt) with the second eye on pin 6 and it was only giving me 8fps. Hmm, changed the second eye (right) pin to 23 just as a test and lost the USB like you did. So I loaded up your posted sketch with the debug code in and it ran but was getting gibberish on Sermon. I reset it and then it loaded and printed fine showing 64fps. Then I reloaded my sketch (pin 23 for right eye) and it ran fine showing 64fps. Ok - so now I changed it back to pin 6 reloaded and it ran at 64fps. Weird!

This is with the T4B2 with the white wire on top on a breadboard.

EDIT: Ok.. just make a minor change to flip photoresistor settings, just a Boolean and lost the usb again like you did. I did the 15s reboot and reloaded the sketch successfully - got the usb back. Using your latest library changes.
 
Last edited:
@mjs513 - Not T4 specific - But wondering if it would make sense to add frame buffer support to the displays. Would not gain much over current stuff as more or less did that with the one writeRect (which you would translate to updateScreen in my ili9341_t3n library... However if I then added the DMA (asynchronous Update) in, wonder how well it would work with this app, IF you could change to each eye on different SPI buss and then start DMA update on each eye such that they both update at the same time... But again not T4 Beta/release issue... So may hold off for now.

Does sound interesting - a couple of things - I did remove some samd code that did DMA transfer for that board. Also if you look closely there seems to be a synch pin code to using wire to get the eyes in synch. Have touched that yet.

I agree that I would wait on making the change though for now.
 
@defragster - @Paul,

Just looking at Msg #6 looks like its restored compared to what was there last night (and what I remember and notes on the list) when I saw @defraster's original post. Nice work Tim :)

There is a DIFF function for Sr+/Mods - clicking the 'last edited by ...' - selecting the right 'old&new' finally gave a page with the 'lost text' in RED that I pulled out and then re-edited it back in.

Indeed the table adds lots of overhead and bulk to edit and step over and transfer.
 
@KurtE
Here is something interesting for you to ponder.

I loaded the changes to my original sketch (w/o debug_tt) with the second eye on pin 6 and it was only giving me 8fps. Hmm, changed the second eye (right) pin to 23 just as a test and lost the USB like you did. So I loaded up your posted sketch with the debug code in and it ran but was getting gibberish on Sermon. I reset it and then it loaded and printed fine showing 64fps. Then I reloaded my sketch (pin 23 for right eye) and it ran fine showing 64fps. Ok - so now I changed it back to pin 6 reloaded and it ran at 64fps. Weird!

This is with the T4B2 with the white wire on top on a breadboard.

EDIT: Ok.. just make a minor change to flip photoresistor settings, just a Boolean and lost the usb again like you did. I did the 15s reboot and reloaded the sketch successfully - got the usb back. Using your latest library changes.

@KurtE
Just to determine whether this issue is unique to the T4 or not I loaded it up on a T3.2. It loaded and ran fine on first upload at 54-56fps. I then made a change to the sketch, commented out "#define LIGHT_PIN_FLIP" and reloaded. No issues were seen like on the T4. So not 100% sure where the problem lies.
 
@mjs513 - No idea... As I mentioned it is strange when it happens and when it does not. It has not happened to me since yesterday... Although been mostly busy with other things.

Like @Paul - merged in the bluetooth branch of the USBHost code, so sunk back up my master branch. Maybe soon will be ready for update to that where we have multiple Bluetooth devices supported. I almost merged it in to the earlier bluetooth branch as do have it such that you can have mouse and keyboard. But still trying to figure out some issues with PS3/PS4...

As to Uncanny Eyes - I accidentally on purpose clicked on: https://smile.amazon.com/DIYmall-Colorful-SSD1351-128X128-Resolution/dp/B01HHPOD44/ So I can see if the OLED looks different...
 
@mjs513 - No idea... As I mentioned it is strange when it happens and when it does not. It has not happened to me since yesterday... Although been mostly busy with other things.

Like @Paul - merged in the bluetooth branch of the USBHost code, so sunk back up my master branch. Maybe soon will be ready for update to that where we have multiple Bluetooth devices supported. I almost merged it in to the earlier bluetooth branch as do have it such that you can have mouse and keyboard. But still trying to figure out some issues with PS3/PS4...

As to Uncanny Eyes - I accidentally on purpose clicked on: https://smile.amazon.com/DIYmall-Colorful-SSD1351-128X128-Resolution/dp/B01HHPOD44/ So I can see if the OLED looks different...

If you go back to Uncanny remove the debug code and see if you run into problems again. My version that I retested doesn't have it in.

I saw the merge - cool. Have to get back to multi Bluetooth again :) except I don't have 2 same devices to test with.

I looked too - this is the one I found: https://www.amazon.com/MakerFocus-D...955011&rnid=2470954011&rps=1&s=gateway&sr=8-4
 
@mjs513 - But I don't want the problems ;) But of course if we can give @Paul a good candidate image, than maybe can be debugged.

Bluetooth: For me the most interesting was how I used bluetooth on PC which currently have a mouse and keyboard. But I can also see maybe wanting two joysticks. Especially maybe if using the PS3 Move and Navigator....

I did not see the one you mentioned. Probably because I was looking for SSD1351 and that one is a SSD1327 (again not sure of the differences) Figured having at least one of them would be good to verify that drivers exist...
I believe Sumotoy has some faster drivers for these, but I am sure does not run with T4... Again wondering if we should

I also see we install a directory ssd1351 in the Teensy install, Which shows up in Arduino Examples menu as: teensy_ssd1351

I tried building simpletest and I get compiler errors... It is trying to reference things like: KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;

So looks like I need to do some editing... (I noted that in posting #4) - I should note this library only works with T3.x boards... Does not look like TLC was added either...
 
Last edited:
@KurtE

@mjs513 - But I don't want the problems But of course if we can give @Paul a good candidate image, than maybe can be debugged.
Going to change my version as a test and see what happens. If I get the problem again I will let you know - maybe its a good candidate for Paul. One of the reasons I was asking if you checked again without debug_tt is that was curious if you encounter the problem again.

I did not see the one you mentioned. Probably because I was looking for SSD1351 and that one is a SSD1327 (again not sure of the differences) Figured having at least one of them would be good to verify that drivers exist...
I believe Sumotoy has some faster drivers for these, but I am sure does not run with T4... Again wondering if we should
I just canceled the SSD1327 order and went with the ones you referred too - missed that it was a 1327. Although.... may get one anyway.

I tried building simpletest and I get compiler errors... It is trying to reference things like: KINETISK_SPI0.PUSHR = data | (pcs_data << 16) | SPI_PUSHR_CTAS(0) | SPI_PUSHR_EOQ;

So looks like I need to do some editing... (I noted that in posting #4)
From what I saw a lot of code was geared to the T3.x and specifically did stuff like that instead of using SPI transactions which would have made it easier but maybe a little slower.
 
I'm testing Ethernet, using a WIZ850io module (W5500 chip). Seeing a strange problem with the WebClient example. Looks like Ethernet WebClient is actually working, but printing to the serial monitor mysteriously stops part way through. My USB protocol analyzer shows the communication is being sent over the cable, so maybe this is a strange problem on the PC side?

Has anyone else run Ethernet's WebClient example?
 
WIZ850io - nope - never got one of those.

FYI: I posted the recent time.h sample - while I was looking after the startup.c Early/Late hooks post.

I don't know about a startup_early_hook() - but for a late_hook::
There is a :: while (millis() < 300) ; // wait at least 300ms before calling user code
>> If I short that wait it gets into setup() at under 66 ms - but trying anything Serial early makes it take longer to arrive - so that is why it isn't ready.

With code in startup.c to call a _Hook() before that while - in the same place and that code in the INO file - elapsedMillis, pinmode and digitalWrite to LED work:
Code:
[B]void startup_default_late_hook(void) {} [U]// about line #38 in startup.c[/U]
void startup_late_hook(void)		__attribute__ ((weak, alias("startup_default_late_hook")));
[/B]__attribute__((section(".startup"), optimize("no-tree-loop-distribute-patterns"), naked))
void ResetHandler(void)
{
// ...
	[B]startup_late_hook();  [U]// line about #116 in startup.c[/U][/B]
	while (millis() < 300) ; // wait at least 300ms before calling user code
As usual that code has to be "C" code as needed with :: #ifdef __cplusplus extern "C" { #endif

Paul - I'd do a PULL request and show that but you may have better ideas for placement - and doing an early() at the same time.

ALSO: is this line best left where it is? - not sure if it could affect anything done in above startup_late_hook() "C" code?
Code:
	__libc_init_array();
 
@mjs513 and KurtE : odd linking in debug_tt changes the behavior - though the problem IIRC is before setup so linked code just changes out the base HardFault code - and nothing else until setup()?

The only thing unique in that code that comes to mind - copied from 'cores' is this:
Code:
[B]#define printf printf_tt[/B]
  asm volatile("mrs %0, ipsr\n" : "=r" (addr)::);
  [U]printf("\nFault irq %d\n", addr & 0x1FF);[/U]

I link to debug_tt print routine instead of the PJRC Serial4 print? So perhaps turning off the "#define PRINT_DEBUG_STUFF" in debug\printf.h would have similar effect - and indicate something about the problem?

@Paul - probably not related - but perhaps your WIZ850io case might change if the PRINT_DEBUG_STUFF is turned off?
 
I got my T4 beta 2 board today. I am using Arduino 1.8.8 along with 1.47 beta 4 Teensyduino. Here are some simple tests, I'm sure everybody has done.

I tried the on/off switch and it seems to work, after pressing the off but for about 6 seconds, and it turns back on after pressing it for a full second. I was surprised that it had the timeouts in place, but it does make it friendlier (IMHO) are more immune to accidental connecting the off pin to ground. Originally before I kept the button down for the full 6 seconds, I was afraid that it wasn't working.

Next for fun, I tried the Wire i2c scanner. Since the audio board is mounted in the expansion slot, I figured it would find the SGTL5000 at address 0xA and the WM8731 at address 0x1A, but the scanner just loops finding no devices. But I suspect you have to initialize the audio board before the i2c devices show up.

Then for fun, I removed the audio board and restarted the Teensy 4b2. Now with Teensy 3 it would hang because there aren't the pull down resistors between SDA/3.3v and SCL/3.3v. But the i2c scanner still looped not finding anything.

I put on a prop shield with motion sensors, and the i2c scanner did find the the 3 i2c devices on the prop shield.

I dug out a MCP23017 test board I had, and it seemed to work fine. One light on the MCP23017 didn't light up, but I saw the same behavior on my Teensy 3.5, and in looking at the board, the pin wasn't soldered. Whoops :)

Then I tried the i2c_t3 version of the scanner. Unfortunately, it looks like i2c_t3 has not yet been ported to the Teensy 4 beta 2:
Code:
basic_scanner: In function 'void setup()':
basic_scanner:28: error: 'Wire' was not declared in this scope
     Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
     ^
basic_scanner:28: error: 'I2C_MASTER' was not declared in this scope
     Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
                ^
basic_scanner:28: error: 'I2C_PINS_18_19' was not declared in this scope
     Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
                                  ^
basic_scanner:28: error: 'I2C_PULLUP_EXT' was not declared in this scope
     Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
                                                  ^
basic_scanner: In function 'void loop()':
basic_scanner:48: error: 'Wire' was not declared in this scope
             Wire.beginTransmission(target);       // slave addr
             ^
basic_scanner: In function 'void print_scan_status(uint8_t, uint8_t)':
basic_scanner:65: error: 'Wire' was not declared in this scope
     switch(Wire.status())
            ^
basic_scanner:67: error: 'I2C_WAITING' was not declared in this scope
     case I2C_WAITING:  
          ^
basic_scanner:71: error: 'I2C_ADDR_NAK' was not declared in this scope
     case I2C_ADDR_NAK: 
          ^
'Wire' was not declared in this scope
 
Does sound interesting - a couple of things - I did remove some samd code that did DMA transfer for that board. Also if you look closely there seems to be a synch pin code to using wire to get the eyes in synch. Have touched that yet.

I agree that I would wait on making the change though for now.

I believe the SYNCPIN stuff was added to allow two HALLOWINGs to work together. The HALLOWING which is a M0, with a feather pinout and a builtin TFT 128x128 display:

One thing that I've thought about is rather than using two analog pins for eye direction is to hook up two distance sensors and make the eyes track as something comes closer on one side.
 
Status
Not open for further replies.
Back
Top