Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

Thread: Arduino 1.8.11

  1. #1
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,493

    Arduino 1.8.11

    Apparently Arduino is planning to release version 1.8.11 on Monday, Jan 27th.

    This isn't great timing for Teensy, as I have travel plans, returning Tuesday afternoon. Normally I try to make a beta version of Teensyduino within hours of each Arduino release, and then typically a final release within a couple weeks. Assuming they really do release on the 27th, this time it may be late on the 28th or early on the 29th until I can make a Teensyduino installer for it.

    Please direct people asking for 1.8.11 support to this thread.

    Also, now's a good time to mention things I should consider merging for a 1.50 release. I believe there's USB host mass storage and ethernet, and USB device MTP. Are these mature enough and ready to be merged? Anything else?

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,973
    Any worthwhile updates included in 1.8.11? I just went back to 1.8.9 …

    Only first thing (updated MOD page p#2) : make the 1008 OC build set that speed not 996 MHz

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,493
    Quote Originally Posted by defragster View Post
    make the 1008 OC build set that speed not 996 MHz
    Ok, I've updated boards.txt in the source, so this will be in 1.50-beta1.


    Any worthwhile updates included in 1.8.11?
    Yes, they fixed the bug that was causing unnecessary recompile.

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,362
    Will be interesting to see what all is in 1.8.11? Maybe MAC fixes for the new security requirements?

    Things maybe to pull in:

    ADC - @Pedvide has pulled in my T4 support. Hopefully his changes to the library definitions won't break too many apps. Should be easy to update, those that id did break.

    T4 Hardware Serial? - Have Branch/PR with changes for handling RX Water setting. Last update leaves water set (2) and available, peek, read now if needed check for bytes already received but not yet pulled out of RX Queue... Also has half duplex support, which if desired could be split out.

    Not sure if there is any display driver updates, that make sense to pull in yet?

  5. #5
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,570
    Concerning USB device MTP, I would appreciate a design decision (i.e.usb_desc.c/h and usb.c) on MTP_DISK with Seremu or Serial, or both.

    Concerning issues with download and TeensyMonitor (especially with MTP+Serial) may require more insight into intended functionality.

    Similar to Teeny3, functionality of usb_mtp.c/h may or may not be integrated into cores. If you intend to suggest an early setup, as with other devices, these files should be merged.

    Overall: Maturity? Im using it without touching cores code, but got never events working.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,493
    Quote Originally Posted by KurtE View Post
    Will be interesting to see what all is in 1.8.11? Maybe MAC fixes for the new security requirements?
    They updated revisions.txt just yesterday, in prep for the release next week.

    ARDUINO 1.8.11 2020.01.2x

    [ide]
    * FIX: Serial plotter do not hang if empty lines are received
    * A lot of accessibility improvements in Libs and Board managers GUI for screen readers (thanks @joew46167)
    * Sligtly improved support for themes in Libs and Board managers (thanks @matthijskooijman)
    * Serial plotter: added serial input text field (thanks @cactorium)
    * MacOSX: support for notarization (thanks @PaulStoffregen for the support)
    * Fix wrong bracket match rectangle on auto format (thanks @magedrifaat)
    * Pluggable discoveries: runtime.platform.path and runtime.hardware.path are now available as variables (thanks @PaulStoffregen)

    [arduino-builder]
    * FIX: missed library-detection cache (forcing lib detection on each build)
    * FIX: Windows: the build folder may reside on a different partition
    * FIX: Segfault in arduino-builder with -dump-prefs if no sketch is specified
    * FIX: Allow loading of global user-define platform.txt
    * FIX: Fixed nil pointer exception on some rare case with multiple libs
    * FIX: Print "multiple libraries found for header.h" message only when it really happens
    * FIX: Fixed library priorities on some rare circumstances

    [hardware]
    * updated AVR core to 1.8.2

    [wifi-updater]
    * updated to 0.10.10

  7. #7
    Senior Member
    Join Date
    Aug 2017
    Posts
    198
    As far as MSC , I have been working an updated version. At this point the old version is working but not what would be called mature. I have updated the error processing portion and reduced the number of function calls to each transfer. Transfer sequences are basically a sequence of two or three USBHost queues per transfer. This version of MSC is more stable and does report errors which are very rare unless I have messed with the code to cause some error or made timing errors. I have been learning about and working with queuing and buffering transfers.

    I think it's time to upload the latest version for testing as a new branch on github.

    This will also be something for me to learn how to do

  8. #8
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    472
    If it's my USBHost ethernet you are referring to, it's currently in a working state the last time I checked however I wouldn't really consider it too mature since it's not really user friendly right now and there are a couple of performance issues that probably should need to be addressed in a better way than how I handled it. Not to mention that it currently requires a significant amount of code placed in the project file to function how it's supposed to, some of it can be moved into the driver itself, but a lot of other parts should be moved into their own wrapper library to be used with the TCP/IP stack I chose to use. Also concerning the wrapper library that I've yet to start on because of other obligations I want to make it have the same syntax as the normal Ethernet library so porting code over is a lot easier than what it would currently be.

  9. #9
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,362
    @Paul - probably low priority for next release, but...

    A lot of the time when I cut and paste stuff out of the Serial monitor, the text will come out double spaced when I paste it into other places, like forum posts. So often times I end up trying to edit them out.

    Hints, these lines do not double space when I cut past the result from the window:
    Code:
      Serial.printf("ITCM allocated: %u  DTCM allocated: %u\n", itcm_size, dtcm_size);
      Serial.printf("ITCM init range: %x - %x Count: %u\n", &_stext, &_etext, (uint32_t)&_etext - (uint32_t)&_stext);
      Serial.printf("DTCM init range: %x - %x Count: %u\n", &_sdata, &_edata, (uint32_t)&_edata - (uint32_t)&_sdata);
      Serial.printf("DTCM cleared range: %x - %x Count: %u\n", &_sbss, &_ebss, (uint32_t)&_ebss - (uint32_t)&_sbss);
    When I cut and paste I get:
    Code:
    IOMUXC_GPR_GPR17:aaaaaaaf IOMUXC_GPR_GPR16:7 IOMUXC_GPR_GPR14:aa0000
    Initial Stack pointer: 20070000
    ITCM allocated: 65536  DTCM allocated: 458752
    ITCM init range: 0 - b9e0 Count: 47584
    DTCM init range: 20000000 - 200019d0 Count: 6608
    DTCM cleared range: 200019d0 - 200042c0 Count: 10480
    Note, I may have pasted in a few extra lines here.

    But if you output stuff using print and println, it will double space:
    Code:
      Serial.print("Display Front of card ");
      elapsedMillis em = 0;
      drawImage(L1, 240, 320, (uint16_t*)teensy40_pinout1, RA8875_RED);
      Serial.println((uint32_t)em, DEC);
    Code:
    Display Front of card 108
    
    Display Back of card 108
    Where println outputs CR and LF
    Code:
    size_t Print::println(void)
    {
    	uint8_t buf[2]={'\r', '\n'};
    	return write(buf, 2);
    }
    So my guess is your internal handling for the Serial monitor is holding onto CR and cut and paste is transferring these as well..

    Again probably low priority, but thought I would detail it as I noticed the differences in the two types of output

  10. #10
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,573
    The old problem linux != windows with cr+lf ?

  11. #11
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,362
    Not sure. Could simply be old Serial monitor code simply swallowed the CR and new one preserves it in its buffer. Again nothing critical, just at times annoying

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,362
    Quick FYI - Looks like 1.8.11 has released!

    As Paul mentioned in post #1, he will be gone until Tomorrow afternoon and as such probably, best case, we won't see any beta builds to at least Wed more likely later that support this Arduino release.

Posting Permissions

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