Teensyduino 1.60 Beta #5

Is it possible the flash chips aren't happy with the changes to CSINTERVAL/TCSH/TCSS for port 2 (causing intermittent failures when accessed in a particular manner) ?
 
jmarsh said:
Is it possible the flash chips aren't happy with the changes to CSINTERVAL/TCSH/TCSS for port 2 (causing intermittent failures when accessed in a particular manner) ?
Click to expand...
reading this right? :: Possible the LTO code order/timing is different, and one way works on timing and the other does not? Either way it is on a hairy edge for the Flash chip?
 
  • Installed under Arduino 1.8.19 (portable) on Win10
  • Got a warning, clicked to install anyway
  • tried the example code I provided in the PR#673 (lockups due to PFD setting) comments
  • no lockups, so that appears to be OK now
  • I've also used these changes with TeensyDebug and Audio, which was another lockup trigger - still OK

In other news, I've been needing to use a full implementation of DMA pre-emption in order to get displays and audio to coexist peacefully. The thread for this is here. Unfortunately the partial implementation in this commit has broken my ability to detect the full implementation (I could previously use #if defined(DMA_DCHPRI_DPA)). If you could persuade @jmarsh to create a PR, and pull it in, that would be ideal.
 
Installed on MacBook Air, Sequoia 15.6, Arduino IDE 2.3.6, no problems.

Not sure if instructions 4 and 5 are mixed up. Seems you'd need to install b4 indexing? That's what I did. With the restart it doesn't matter anyway. Only looked at a T3.2 program, 48mhz, faster, i2c_t3, SPI, gpis_expander so far.
 
Trying to adapt a simple MTP sketch to the new MTP code in the core and there's some obvious problems:

- useFileSystemIndexFileStore() is gone. There is useFilesystemForIndexList(), but the point is I don't want to use a physical drive for the index file at all (I don't want *anything* written to my drives unless I put it there) and now there's no equivalent to useFileSystemIndexFileStore(MTPStorage::INDEX_STORE_MEM_FILE)
- What is the appropriate method to remove a filesystem from MTP i.e. the opposite of addFilesystem() ? I used to perform send_StoreRemovedEvent(handle) followed by storage()->removeFilesystem(handle) but now both of those functions are private/removed.
 
Initialisation of PSRAM wont work with the higher clock speed, if I set it to a higher speed manually later it will work though. I use PSRAM that supports the higher clock speed according to its spec sheet.
 
Problem with optimization settings when testing around max integer. Arduino IDE 2.3.6, T1.6b5. This worked back in 2015 :)

Code: 
void setup() {
  int x,y,z;
 
  Serial.begin(9600);
  while (!Serial)
    ;

  x=2;
  y=0;
  while(x>y){
    y=x;  //keep the last value
    x*=2;
  }
  Serial.printf("\nwhile(x>y) correctly exits after multiplies when %d < %d\n", x, y); 

  y=2*y-5;  //make it less than double
  x=y+1;
  z=5;

  Serial.println("\nbut only works after add on T4.1 if optimize is set to fast."); 
  Serial.printf("x=%d, y=%d z=%d\n",x,y,z);
  while(x>0 && z>0){
    y=x;
    x+=1;
    z-=1;
    Serial.printf("x=%d, y=%d z=%d",x,y,z);
    if(z==1){
      Serial.println("<-should have exited here");
    }else{
      Serial.println();
    }
  }
}

void loop() {
}

I get this when optimize is set to fast

Code: 
while(x>y) correctly exits after multiplies when -2147483648 < 1073741824

but only works after add on T4.1 if optimize is set to fast.
x=2147483644, y=2147483643 z=5
x=2147483645, y=2147483644 z=4
x=2147483646, y=2147483645 z=3
x=2147483647, y=2147483646 z=2
x=-2147483648, y=2147483647 z=1<-should have exited here

and this when optimize set to anything else

Code: 
while(x>y) correctly exits after multiplies when -2147483648 < 1073741824

but only works after add on T4.1 if optimize is set to fast.
x=2147483644, y=2147483643 z=5
x=2147483645, y=2147483644 z=4
x=2147483646, y=2147483645 z=3
x=2147483647, y=2147483646 z=2
x=-2147483648, y=2147483647 z=1<-should have exited here
x=-2147483647, y=-2147483648 z=0
 
the second while:
while(x>0 && z>0){
should have been (or was originally) :
while(x>y && z>0){
but demonstrates that even a test of positiveness fails.
 
I'm reasonably sure integer overflow/underflow is still undefined behavior so the compiler is free to make optimizations assuming it will never happen, i.e. if it sees a loop with "x<=0" as an exit condition, but it knows x starts as a positive value and only ever gets incremented inside the loop, it can assume that exit condition will never occur (and skip any testing for it).
 
Yes, _signed_ integer overflow is not defined in C or C++ at all... Many programs assume it is defined, and usually it works as expected, sometimes it does not (and it can be very confusing). Use unsigned if deliberately overflowing ints.
 
As raised in this post, it's not as easy as it could be to create a custom USB mix which includes MTP support, in accordance with the advice in usb_desc.h:
If you are using existing interfaces (making your own device with
a different set of interfaces) the code in all other files should
automatically adapt to the new endpoints you specify here.
Click to expand...
I've put in PR#790 which I believe makes the conditional compilation adapt in a manner consistent with the other interface types (MIDI, Serial, keyboard etc.). Briefly tested, seems to work OK.
 
Happy to report that the 1.60 beta 5 fixed any issues I was having with the ST7796 screen! Seems to run the graphics test sketch perfectly now.
 
You must log in or register to reply here.
Back
Top