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

Thread: Teensyduino 1.40 Beta #1

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    294

    Teensyduino 1.40 Beta #1

    Here is a first beta test for Teensyduino 1.40.

    This beta is mostly focused on checking Linux compatibility with using libudev to detect USB devices.

    Linux 32 bit:
    https://www.pjrc.com/teensy/td_140-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_140-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_140-b...stall.linuxarm

    Mac OS-X:
    https://www.pjrc.com/teensy/td_140-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_140-b...inoInstall.exe


    Changes since Teensyduino 1.39

    Linux Teensy Loader now uses udev to find USB devices
    Audio library fixes
    USBHost_t36: HID parsing, improved Mouse driver, new Joystick driver
    Updated: i2c_t3 and TinyGPS

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    Does it have the systick fix? Minimal-Blink-fails-with-void-yield()

    Code:
     
    -void systick_isr(void)		__attribute__ ((weak, alias("unused_isr"))); 
    +void systick_isr(void);

  3. #3
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Quote Originally Posted by defragster View Post
    Does it have the systick fix? Minimal-Blink-fails-with-void-yield()
    Yes - Just visually verified on my windows 10 install version... Did not try earlier program with issue...

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,600
    Please please please try this beta with Linux systems, especially non-Ubuntu ones.

    Three simple questions:

    1: Does the installer run? It's now links to a newer set of Gnome/GTK libraries. Problems would manifest as not being able to run at all, due to missing libraries.

    2: Does Teensy Loader appear when you click Verify? It now links to libudev, and newer Gnome/GTK libraries. Problems would manifest as not being able to run Teensy Loader, due to missing libs.

    3: Can you upload LED blink or any other program? USB devices are now discovered with udev. Problems would manifest as not finding your Teensy, so no uploading possible.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,600
    Arduino is likely to release 1.8.5 on Monday or Tuesday.

    I need to decide whether to go forward with using libudev, or revert to the old & kludgy scanning of /dev & /dev/bus/usb. Please help me to understand if this libudev change is going to work on a wide range of Linux distros.

    As usual, my plan is a week or two of betas, where the first one or two is relatively open to merging features and the ones right before release are (supposed to be) for bug fixes only.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    Thanks Kurt, indeed installed now and I see:: void systick_isr(void);

    I had to STOP Malwarebytes [Win 10] it stopped installer on this file as blocked:
    I:\arduino-1.8.4\hardware\tools\arm\lib\gcc\arm-none-eabi\5.4.1>del cc*.exe
    I:\arduino-1.8.4\hardware\tools\arm\lib\gcc\arm-none-eabi\5.4.1\cc1plus.exe
    Access is denied.
    Didn't have that with 1.39 installer.

    No active Linux box to test.

  7. #7
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Paul do you want more information here or over in the libudev thread.

    As I mentioned over there I have been able to download and install on
    Odroid XU4 (Ubuntu 16.04 ARM) - Works
    UP2 (ubilinux - X86 64 bit) - Works
    Windows 10 machine - Works...

    Since then tried:
    MAC with Parallel desktop Ubuntu 14.04 - Works

  8. #8
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,718
    On my Fedora 24 system (x86 64-bit), it installed fine, and generally ran fine.

    I did have one instance where the program had hung and could not be reset via the IDE, so I pressed the programming button. The downloader said no such record. I exited the IDE and the downloader, and restarted them, to note down the steps I used, but I can't get it to fail once again (but I also haven't been able to get the program to hang). The only thing I can think of is I had been doing 1.39 before doing 1.40 beta 1, and I may not forced the downloader to exit.
    Last edited by MichaelMeissner; 10-02-2017 at 12:16 AM.

  9. #9
    Senior Member jimmayhugh's Avatar
    Join Date
    Nov 2012
    Posts
    168
    No problems with Debian 8.9 64 bit

    Debian 9.1 (Stretch) compiles, but fails to upload. Manually pressing the Program button also hangs. Verified this on two different systems, an UdooX86 and an Intel Atom board. Update: My Bad, forgot to install 49-teensy.rules, works fine now.

    Only tested with blink and blink-no-delay on an unmodified Teensy3.1
    Last edited by jimmayhugh; 10-05-2017 at 02:39 PM. Reason: My Bad

  10. #10
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,472
    It works on my two 32-bit ubuntu boxes with 1.8.4
    Ubuntu 14.04.5 LTS 32-bit

    Ubuntu 16.04.3 LTS 32-bit

  11. #11
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Quote Originally Posted by PaulStoffregen View Post
    Arduino is likely to release 1.8.5 on Monday or Tuesday.

    I need to decide whether to go forward with using libudev, or revert to the old & kludgy scanning of /dev & /dev/bus/usb. Please help me to understand if this libudev change is going to work on a wide range of Linux distros.

    As usual, my plan is a week or two of betas, where the first one or two is relatively open to merging features and the ones right before release are (supposed to be) for bug fixes only.
    Paul - What things are you interested in merging in?
    I have some host usb stuff - A few bug fixes (linked list issue, plus 2 pass looking at drivers for HID, such that Keyboard driver will get first shot even if a HID driver is seen first), plus started to add in additional query functions to get information like VID/PID and also first pass at getting strings...
    The most risky is the strings stuff... So could issue PR for all or part.

    Also may play some with keyboard stuff. Probably just learning for now.

    Also wondering if you would be interested in some simple (maybe stop gap) updates to maybe help minimize system impact by things like yield() and changes to systick... i.e. in both cases don't call off to stuff if feature not used.

    For Yield - Was thinking of adding maybe uint16_t variable named something like yieldEventsMask or some such thing.
    Probably first pass use a simple KISS like: have Serial1.begin() do something like yieldEventsMask |= 2;

    So some of yield might look like:
    Code:
    void yield(void) __attribute__ ((weak));
    void yield(void)
    {
    	static uint8_t running=0;
    
    	if (!yieldEventsMask) return;	// nothing to do
    	if (running) return; // TODO: does this need to be atomic?
    	running = 1;
    	if ((yieldEventsMask & 1) && Serial.available()) serialEvent();
    	if ((yieldEventsMask & 2) && Serial1.available()) serialEvent1();
    	if ((yieldEventsMask & 4) && Serial2.available()) serialEvent2();
    	if ((yieldEventsMask & 8) && Serial3.available()) serialEvent3();
    #ifdef HAS_KINETISK_UART3
    	if ((yieldEventsMask & 16) && Serial4.available()) serialEvent4();
    #endif
    #ifdef HAS_KINETISK_UART4
    	if ((yieldEventsMask & 32) && Serial5.available()) serialEvent5();
    #endif
    #if defined(HAS_KINETISK_UART5) || defined (HAS_KINETISK_LPUART0)
    	if ((yieldEventsMask & 64) && Serial6.available()) serialEvent6();
    #endif
    	running = 0;
    	EventResponder::runFromYield();
    };
    So the SerialX calls will only be called for those Serial objects that the user actually does a begin on...
    Plus I would change the default SerialEvent functions to disable the calls again like:

    Code:
    void serialEvent1() __attribute__((weak));
    void serialEvent1() {yieldEventsMask &= ~2;}
    So again the yieldEventsMask would be reset such that the SerialEvent1 will only be called once...

    Again this is KISS version, more advanced would be change Serial1 ISR to set the mask value and have Serial1.read clear (when empty)...

    Above is not quite correct as I bail if mask is zero... But it did not call the runFromYield... I would actually also change the EventResponder to set a bit in this mask when ever a user adds an event object with the option of running from yield...

    Should I try doing this?

  12. #12
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    409
    Paul, please pull a new i2c_t3 off GitHub again for next TD version. There were some more fixes on the LC/3.5/3.6, details: https://forum.pjrc.com/threads/21680...l=1#post155146

    Here is the link:
    https://github.com/nox771/i2c_t3

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,600
    Quote Originally Posted by KurtE View Post
    Paul - What things are you interested in merging in?
    Most interested in the USB host stuff. I like to get anything that's not a bugfix or very low risk feature into the next beta.

    That may be only hours away, or perhaps days... whenever Arduino puts 1.8.5 on their website. They already put 2017.09.29 at the release date in their changelog, so it ought to appear soon.


    Quote Originally Posted by nox771 View Post
    Paul, please pull a new i2c_t3 off GitHub again for next TD version.
    Done.

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Quote Originally Posted by PaulStoffregen View Post
    Most interested in the USB host stuff. I like to get anything that's not a bugfix or very low risk feature into the next beta.

    Done.
    Most current stuff is in the thread: https://github.com/KurtE/USBHost_t36...-API-Additions

    I have been playing around with the ability of being able to set the keyboard LEDS. Will look tomorrow on what can be merged... Or feel free to take a look...

  15. #15
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    Kurt - As far as USB Serial - it is already set to go NULL isn't it - i.e. (!Serial)? Also Serial starts without .begin when selected. Did you work it up and see it to be less overhead?

    It seems the Serial#.begin aware adjustment is simple and safe and changes nothing outside the use in yield() - and could be undone anytime?

    In the end EventResponder is planned to do the calls to serialEvent#()? That could be done in the same place in .begin as the flag setting you suggest - and the default 'weak' you suggest would as it works above to turn off yield() checking would be similarly changed to remove the EventResponder. This seems like a safe and good practice run for Event changes?

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,600
    Arduino put 1.8.5 on their website, but there's a problem. The build was made with the wrong set of i18n translation files. They're apparently going to redo the release.

    I'm putting together a beta right now that targets the files they already put up. Might have to redo it when they replace them.

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,600
    In more testing here I noticed the upload on Linux would sometimes experience a long pause. It seemed to happen when a previous upload had been made within the last 10-20 seconds. I ultimately tracked it down to the libusb usb_find_devices() function in teensy_reboot. I rewrote that code to match the udev way in Teensy Loader. It seems to be running much better now.

  18. #18
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Quote Originally Posted by defragster View Post
    Kurt - As far as USB Serial - it is already set to go NULL isn't it - i.e. (!Serial)? Also Serial starts without .begin when selected. Did you work it up and see it to be less overhead?

    It seems the Serial#.begin aware adjustment is simple and safe and changes nothing outside the use in yield() - and could be undone anytime?

    In the end EventResponder is planned to do the calls to serialEvent#()? That could be done in the same place in .begin as the flag setting you suggest - and the default 'weak' you suggest would as it works above to turn off yield() checking would be similarly changed to remove the EventResponder. This seems like a safe and good practice run for Event changes?
    Nope I have not done it, was waiting to see if Paul would be interested... Would probably take about an hour of work or so...

    Yes Serial one is special and that it does not require begin... Could either still require begin to be called to enable serialEvent to be used as most other Arduinos will require you to call begin anyway... Could have it's bit set at startup, so will keep calling the Serial.available until it receives something and then it would shut off. Or could build in the support that when Serial receives a packet it turns it on (unless it was disabled...)...

Posting Permissions

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