Teensyduino 1.40 Beta #1

Status
Not open for further replies.

Paul

Administrator
Staff member
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
 
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.
 
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.
 
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.
 
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
 
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:
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:
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
 
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?
 
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.


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

Done.
 
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?
 
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.
 
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.
 
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...)...
 
Status
Not open for further replies.
Back
Top