PDA

View Full Version : Teensyduino 1.40 Beta #1



Paul
09-30-2017, 04:50 PM
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.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


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

defragster
09-30-2017, 09:14 PM
Does it have the systick fix? Minimal-Blink-fails-with-void-yield() (https://forum.pjrc.com/threads/46442-Minimal-Blink-fails-with-void-yield()?p=154218&viewfull=1#post154218)



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

KurtE
09-30-2017, 09:24 PM
Does it have the systick fix? Minimal-Blink-fails-with-void-yield() (https://forum.pjrc.com/threads/46442-Minimal-Blink-fails-with-void-yield()?p=154218&viewfull=1#post154218)

Yes - Just visually verified on my windows 10 install version... Did not try earlier program with issue...

PaulStoffregen
09-30-2017, 09:39 PM
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.

PaulStoffregen
09-30-2017, 09:45 PM
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.

defragster
09-30-2017, 10:58 PM
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.

KurtE
10-01-2017, 12:45 AM
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

MichaelMeissner
10-01-2017, 05:09 AM
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.

jimmayhugh
10-01-2017, 03:19 PM
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

manitou
10-01-2017, 03:31 PM
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

KurtE
10-01-2017, 06:05 PM
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:

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:


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?

nox771
10-01-2017, 10:50 PM
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-New-I2C-library-for-Teensy3?p=155146&viewfull=1#post155146

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

PaulStoffregen
10-02-2017, 12:01 AM
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 (https://github.com/arduino/Arduino/commit/433fbeb29cd1d47a88faeb3a1ba74ce0348de28f), so it ought to appear soon.



Paul, please pull a new i2c_t3 off GitHub again for next TD version.

Done.

KurtE
10-02-2017, 02:22 AM
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/tree/HID-Device-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...

defragster
10-02-2017, 04:18 AM
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?

PaulStoffregen
10-02-2017, 01:48 PM
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.

PaulStoffregen
10-02-2017, 01:52 PM
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.

KurtE
10-02-2017, 04:13 PM
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...)...