Forum Rule: Always post complete source code & details to reproduce any issue!
Page 143 of 168 FirstFirst ... 43 93 133 141 142 143 144 145 153 ... LastLast
Results 3,551 to 3,575 of 4189

Thread: Teensy 4.0 First Beta Test

  1. #3551
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,087
    @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...
    Attached Files Attached Files

  2. #3552
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,087
    Quote Originally Posted by mjs513 View Post
    @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/B0...?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.

  3. #3553
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,087
    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 by defragster; 07-08-2019 at 09:44 AM.

  4. #3554
    Senior Member
    Join Date
    Mar 2015
    Location
    UK
    Posts
    280
    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?

  5. #3555
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    Quote Originally Posted by KurtE View Post
    @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.

  6. #3556
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,341
    Quote Originally Posted by defragster View Post
    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 by PaulStoffregen; 07-08-2019 at 10:46 AM.

  7. #3557
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,341
    Quote Originally Posted by TelephoneBill View Post
    Does Teensduino use the PIT timers de facto ?
    All 4 PIT timers are usable by IntervalTimer. By default, none are used. But several Arduino libraries do use IntervalTimer. So does the tone() function.

  8. #3558
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    Quote Originally Posted by defragster View Post
    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

  9. #3559
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,087
    Quote Originally Posted by mjs513 View Post
    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

  10. #3560
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    @KurtE
    The FPS is exactly what I was seeing - so quite a bit of speed up which is noticeable. Nice job.

  11. #3561
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,087
    @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.

  12. #3562
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    @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 by mjs513; 07-08-2019 at 03:21 PM.

  13. #3563
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    Quote Originally Posted by KurtE View Post
    @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.

  14. #3564
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,087
    Quote Originally Posted by mjs513 View Post
    @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.

  15. #3565
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    @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.

  16. #3566
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,087
    @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-Col...dp/B01HHPOD44/ So I can see if the OLED looks different...

  17. #3567
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    Quote Originally Posted by KurtE View Post
    @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-Col...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-Di...gateway&sr=8-4

  18. #3568
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,087
    @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 by KurtE; 07-08-2019 at 09:14 PM.

  19. #3569
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,714
    @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.

  20. #3570
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,341
    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?

  21. #3571
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,087
    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:
    void startup_default_late_hook(void) {} // about line #38 in startup.c
    void startup_late_hook(void)		__attribute__ ((weak, alias("startup_default_late_hook")));
    __attribute__((section(".startup"), optimize("no-tree-loop-distribute-patterns"), naked))
    void ResetHandler(void)
    {
    // ...
    	startup_late_hook();  // line about #116 in startup.c
    	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();

  22. #3572
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,087
    @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:
    #define printf printf_tt
      asm volatile("mrs %0, ipsr\n" : "=r" (addr)::);
      printf("\nFault irq %d\n", addr & 0x1FF);
    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?

  23. #3573
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,085
    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

  24. #3574
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,085
    Quote Originally Posted by mjs513 View Post
    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.

  25. #3575
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,341
    I tracked the mysterious serial monitor freeze to a character set decoder parsing exception within the Java code which gets data from teensy_serialmon and gives it to the serial monitor window.

    Fixed with this:
    https://github.com/PaulStoffregen/Ar...c00d68da9a7f8e

    I'll package up a 1.47-beta5 installer soon. I know nobody has reported this rare bug yet, but it really is annoying when it strikes.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •