PDA

View Full Version : Teensyduino 1.20 Release Candidate #5 Available



Paul
09-30-2014, 10:49 AM
Here is a fifth (and likely final) release candidate for Teensyduino 1.20:


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



Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!

These are the changes since Teensyduino 1.20-rc4 (http://forum.pjrc.com/threads/26640-Teensyduino-1-20-Release-Candidate-3-Available):


Audio Library
FlexCAN Library
Fix SD card speed (default is 24 MHz SPI again)
Update Adafruit NeoPixel library
Update ILI9431_t3 library
Fix strncpy_P on Teensy 3.x

PaulStoffregen
09-30-2014, 11:02 AM
I plan to make a final 1.20 release by Friday. At this point, I'm only considering bug fixes.

New features (or not-so-new stuff that didn't make it into 1.20) can be discussed for 1.21....

xxxajk
09-30-2014, 08:09 PM
C99 switch would be nice...

stevech
09-30-2014, 08:45 PM
Yes, C99. So struct initializers can be practical.

MichaelMeissner
09-30-2014, 09:07 PM
In terms of C99, I don't believe C++ supports C99 designated initializers. So to use it, you would have to put the code into a library with the .c extension instead of .cpp so that the C compiler is invoked, and not C++.

PaulStoffregen
09-30-2014, 10:00 PM
Has anyone tried actually using C99 with a good number of Arduino libraries and sketches? Are there compatibility issues?

MichaelMeissner
09-30-2014, 10:34 PM
Ummm, the Arduino libraries are written in C++, not C. In my Teensy 1.19 installation directory in the libraries sub-directory, there are only 9 .c files that are not example files. While C++ is close to C, it is not 100% compatible. Generally you can write C code that is accepted by C++, but generally you will not be able to do the reverse.

stratosfear
10-01-2014, 12:41 AM
I had a problem with the Adafruit ILI9340 graphictest example and only get a white screen. I tried a few different combinations with the following results:

Arduino 1.05 and Teensy Loader 1.19 works
Arduino 1.05 and Teensy Loader 1.20-rc5 works
Arduino 1.06 and Teensy Loader 1.20-rc5 does not work

At this point it looks like Arduino 1.06 is at fault, but I thought it might be worth mentioning.

Jon

xxxajk
10-01-2014, 02:31 AM
C99 is needed if you want to use something like ATOMIC_BLOCK in C code with GCC (not G++)

You already have gnu0x enabled for C++, which is great, and along the same lines as C99 v.s. C89.

And yes, I would totally use the new features, and your arm cores would benefit as well.

embedded-creations
10-01-2014, 04:52 AM
Not a bug report, but I was inspired to finally take a look at your Audio Library, and updated the SmartMatrix Library to be compatible. Your DMAController class made that easy. I couldn't use a lot of the helper functions and just modified TCDs directly as the way I'm using most of the DMA channels in (I'm guessing) an uncommon way. I pushed the changes to a new branch until 1.20 is officially released:
https://github.com/pixelmatix/SmartMatrix/tree/DMAController

xxxajk
10-01-2014, 04:55 AM
As far as libraries go, my RTClib wants c99-- the avr GCC defaults to this.
Unfortunately I had to hack around things in order to get it to work-- basically by telling the compiler that the code is actually C, and renaming the file .cpp
e.g.
extern "C" {
... c99 code here ...
}

and that actually will work because of the gnu0x mode.

I have not checked the difference in code size or generated code for c99 mode of gcc and g++ hacked to see the code as C.
What I can say is it can be a real royal pain in the rump when I want to port something and make it into an arduino-type library.

getSurreal
10-01-2014, 02:46 PM
Is the pin33 low on boot issue addressed in this? http://forum.pjrc.com/threads/24823-Teensy-3-1-Tying-Pin-33-%28pta4%29-low-freezes-teensy?highlight=pin33

PaulStoffregen
10-01-2014, 02:48 PM
No, sorry, the pin 33 NMI issue will be fixed in 1.21.

KurtE
10-01-2014, 04:37 PM
I had a problem with the Adafruit ILI9340 graphictest example and only get a white screen. I tried a few different combinations with the following results:

Arduino 1.05 and Teensy Loader 1.19 works
Arduino 1.05 and Teensy Loader 1.20-rc5 works
Arduino 1.06 and Teensy Loader 1.20-rc5 does not work

At this point it looks like Arduino 1.06 is at fault, but I thought it might be worth mentioning.

Jon May need more info (what Teensy, what board, wiring, OS). I tried using the Adafruit 2.2" tft breakout with the ILI9340, with RC5 and Arduino 1.06 and it is working for me. FYI - I also verified again it works with the ILI9341_T3 driver (But you need for CS and DC to be on Teensy 3.1 CS pins). I tried this on Windows 7 machinge.

I then tried with the Adafruit ILI9340 driver and first I had white screen as well. I see that the graphic test showed RST connected to pin 8, So I connected my jumper, downloaded the program again and it is working.

stratosfear
10-01-2014, 09:48 PM
Im testing on a Teensy 3.1 and Adafruit 2.2 display. Connections match the example sketch:


#define _sclk 13
#define _miso 12
#define _mosi 11
#define _cs 10
#define _dc 9
#define _rst 8

When 1.06/TD1.20-rc5 gave me the white screen, I also noticed that the pin 13 LED (SCK) did not flash after uploading. Without changing any part of the circuit, I can upload using 1.05/TD1.19 and get a working display and flashing LED. The fact it works with the latter setup tells me the wiring, Teensy, and display are good.

My 1.06 and rc5 are fresh installs on a WIN7 Pro system.

PaulStoffregen
10-01-2014, 10:18 PM
Can you please double check the version. Use Help > About in Arduino.

KurtE
10-01-2014, 10:44 PM
I thought I would double check mine as well as I installed RC5 over RC4. So on my Linux 64 machine, I downloaded fresh copy of Arduino 1.06, plus a fresh copy of RC5. I then took my test one with the same display as you have as well as the same wiring and first downloaded blink in it to make sure it was not using the previous version... I then downloaded the graphic test for the Adafruit ILI9340 library that Teensyduino installed and it worked again. Likewise the graphic test program for ILI9341_T3 runs (a whole lot faster than the other library.

So I also would recommend you retry it again.

Kurt

stratosfear
10-02-2014, 01:03 AM
Help > About shows Arduino 1.0.6 and Teensyduino 1.20-rc5.

I tried a clean install on my alternate XP system and the display worked as it should, even the ILI9341_t3.

Went back to the Win7 system, deleted Arduino 1.0.5 and 1.0.6. Re-downloaded 1.0.6 and rc5 and installed both. Tried the ILI9340 example with the same white screen, so it's something specific to my Win7 system. Tried the ILI9341_t3 and it works - much faster, as Kurt said. I'll keep using the 9341 library.

Jon

pawelsky
10-04-2014, 01:49 PM
Paul, thanks for including FlexCAN library. One minor issue - the README.md file seems to be missing (the png file is included)

Ira
10-04-2014, 06:16 PM
No idea if you consider this a bug, but if you install it over an older version where you checked, include all libraries, and don't check include all libraries, I don't think it updates or uninstalls the unselected libraries. Problem being all the old versions of the libraries are still there.

Ira

PaulStoffregen
10-05-2014, 03:55 PM
I wouldn't consider this a bug, but perhaps an opportunity for future improvement.

This involves 2 tasks. Obviously the installer would need to be able to detect which libraries are already installed and have the ability to remove them.

But the more difficult task would involve a way to show this on the installer page. How do other installers show this, where the installer can possible add, update or remove components, some of which are already installed.

In other words, there are at least 5 cases:


not installed, will not be installed
not installed, will be added
already installed, will be deleted
already installed, no change
already installed, will be updated


Obviously a simple binary checkbox like the installer has now is probably only going to be confusing.

Are there other installers that many people are already familiar with, which do these 5 cases and have some clear way of showing all 5 cases within the limited screen space?

stevech
10-05-2014, 05:10 PM
Can it be as simple as: Teensy replaces only what libraries it brings to the party.
A pop-up warning might say, at the onset... warning, customized libraries may be overwritten; backup these before installing.

pawelsky
10-05-2014, 05:10 PM
In other words, there are at least 5 cases:


not installed, will not be installed
not installed, will be added
already installed, will be deleted
already installed, no change
already installed, will be updated



Instead of a checkbox you could use a combo-box with following values corresponding the 5 cases mentioned above
1. SKIP
2. ADD
3. REMOVE
4. KEEP
5. UPDATE

Same prefixes can be added to a library name when composing summary of selected libraries.

You can also decide on defaults to make the selection process easier (e.g. not installed defaults to SKIP, installed defaults to UPDATE).

Confirmation popup should show up each time the library is updated or removed (just in case).

P.S. Only 1/2 shall be available when the library is not installed and 3/4/5 when it is.

PaulStoffregen
10-05-2014, 09:50 PM
A pop-up warning might say, at the onset... warning, customized libraries may be overwritten; backup these before installing.

Only a small percentage of end users read such advisory messages in popup dialogues. Especially on Microsoft Windows, where they are commonly used, many people are in the habit of immediately clicking "Ok", without even glancing at the message.

pawelsky
10-05-2014, 10:02 PM
many people are in the habit of immediately clicking "Ok", without even glancing at the message.

Then they can only blame themselves...

Right now Teensyduino installer overwrites libraries WITHOUT ASKING. A popup would at least give the more careful ones a chance...

xxxajk
10-05-2014, 10:07 PM
How about a check box to confirm that you read the message... then an 'OK' click is thwarted, and people are forced to read.

Sometimes the simple solutions are right there in front of you.

PaulStoffregen
10-05-2014, 10:08 PM
I believe the installer's default behavior has all the boxes unchecked, causing no libraries to be written.

pawelsky
10-05-2014, 10:10 PM
I believe the installer's default behavior has all the boxes unchecked, causing no libraries to be written.

So can the defaults (SKIP/KEEP) be set for the 5-state combo to not make any changes...

PaulStoffregen
10-05-2014, 10:20 PM
How about a check box to confirm that you read the message... then an 'OK' click is thwarted, and people are forced to read.


Usually I'm opposed to this sort of GUI design.

However, I did briefly consider a checkbox for "yes, I posted complete source to reproduce my problem" on this forum, which would enable the button to post a new thread. But simple adding guidelines and the "forum rule" with red text seems to be working pretty well. (I recently spent a little time over on Arduino's official forum.... we have much better quality questions and most thread arrive at good answers much sooner).

But, back to the installer GUI.

I do like pawelsky's list of words.

1. SKIP
2. ADD
3. REMOVE
4. KEEP
5. UPDATE

I think these might work well, perhaps also with use of color, probably gray for SKIP and KEEP, red for REMOVE, maybe green for ADD and UPDATE. I'm imagining the "all" button will turn them all green (ADD the ones currently missing, UPDATE the ones already installed), and "none" would turn them all grey. To delete already-installed libs, I believe clicking on each individual one is probably reasonable.


Just to be absolutely clear, this conversation is about possibilities for a future installer. Maybe 1.21, but probably farther out. A big last-minute change is definitely not going to happen in 1.20, which I had intended to release today... but I'm investigating a mysterious issue when OctoWS2811 and Audio are used together in a specific way. I want to fully understand this and make sure it's not an obscure bug before a final release.

pawelsky
10-05-2014, 10:25 PM
I think these might work well, perhaps also with use of color, probably gray for SKIP and KEEP, red for REMOVE, maybe green for ADD and UPDATE. I'm imagining the "all" button will turn them all green (ADD the ones currently missing, UPDATE the ones already installed), and "none" would turn them all grey. To delete already-installed libs, I believe clicking on each individual one is probably reasonable.

I was thinking about colors as well, and I agree with one exception - I would consider UPDATE red (i.e. needs user attention, and for the red ones warning message would be displayed).

PaulStoffregen
10-05-2014, 10:27 PM
Why should UPDATE be red?

pawelsky
10-05-2014, 10:31 PM
Why should UPDATE be red?

Because it can overwrite someone's local changes.

It can be green as well, as long as the warning popup is displayed before overwriting.

xxxajk
10-05-2014, 10:48 PM
I believe the installer's default behavior has all the boxes unchecked, causing no libraries to be written.

Yes, that's not the idea. The Idea is a check box that won't let you just click the OK button. OK would be disabled until the check box is ticked.

PaulStoffregen
10-05-2014, 11:01 PM
Because it can overwrite someone's local changes.

It can be green as well, as long as the warning popup is displayed before overwriting.

How should the installer distinguish between overwriting user customizations vs simply updating an older version that doesn't have any user changes?

I want to avoid "false positives" that cause a strong warning to be shown in harmless situations.



Yes, that's not the idea. The Idea is a check box that won't let you just click the OK button. OK would be disabled until the check box is ticked.

No, I'm not going to do that. I'm philosophically against this sort of GUI design, which I believe is hostile or at least antagonistic to end users. But I will admit, the idea is tempting...

pictographer
10-05-2014, 11:07 PM
I'm not in favor of complicating the installer GUI. Time spent doing installation is time not spent doing cool projects.

If you're worried about overwriting locally modified libraries, have the installer compute a checksum for each library and refuse to install over something not recognized as identical to the expected older version. This implies the installer has a list of checksums for all older versions of all libraries it installs. Maybe it's reasonable to only go back a few versions and leave the behavior for older versions as it currently is. With this policy, it is always possible to undo an installation and roll back to an older version.

The problem with asking the user if they want to do 1-5 above is that unless they're very clear about the state of all their local libraries and the updates, they're stuck guessing. If they're not very clear, then they're probably not well prepared to investigate and do better than guessing. So, they'll guess wrong and complain.

Let the small minority of users who locally modify libraries deal with the problems of version management.

It would be nice if the release notes were integrated into the installer so it was possible to go through each library and see right there what had changed.

PaulStoffregen
10-05-2014, 11:18 PM
Yes, I believe to make this work, some sort of comparison against known checksums will be needed, to detect when a library has been edited or changed by a user.

I'm reluctant to start managing revision history for so many libraries.

But perhaps if the installer were to write a checksum list, it could later use those checksums to see if the library has been edited. Presumably people would not bother to edit the checksums in a separate file. Of course, this doesn't do anything for the very first time Teensyduino is installed, where copies of the extra libraries might already be present.

pictographer
10-06-2014, 12:09 AM
I agree folks are unlikely to mess with checksum files in library directories, however, either way, managing the checksums would need to be automated. If it's automated, you're better off storing the checksums in a location you control, namely inside the install image.

If you're reluctant to manage revision histories (and as well you should be--not a high leverage feature), fearlessly keep the installer as is. No one will get burned twice. I'll shed a crocodile tear for anyone who complains that a software update updated libraries after they explicitly requested this.

xxxajk
10-06-2014, 12:24 AM
Use SHA checksums, just like git does...

Oh, and I always install everything fresh personally. I must have at least 10 different Arduino and teensified Arduino installs :-)

Ira
10-06-2014, 02:30 AM
You seem to install the libraries in Program Files. Users should not touch files in that folder and if they do, too bad. If they want to modify a library it should be copied or moved to their Arduino folder in My Documents or where ever they choose.

I believe the only proper Windows like response for your installer is to delete all the libraries and install only the checked ones or at least offer the option to do that. I understand why that might not be your favorite choice, but I think it would be the only solution that fits the Windows paradigm.

embedded-creations
10-06-2014, 02:44 AM
I think Ira might have a good and simple solution. I would add a checkbox by default to any library that was already installed, and just go by the folder name to find matches.

Here's my use case: Some of the SmartMatrix examples require the prerelease FastLED 2.1. Teensyduino includes the stable FastLED 2.0. Some users already installed Teensyduino and checked the FastLED install, so for those users I have to tell them to navigate inside "Program Files\Arduino" or inside the Arduino.app on the mac (no idea for Linux), and delete the libraries\FastLED folder. I'd rather tell them to run the Teensyduino install again with FastLED unchecked, and install the FastLED 2.1 library using Arduino "Add Library".

If users install an alternate version of a library I expect they will either use the Arduino "Add Library" or put the folder in their sketchbook\libraries folder so it wouldn't interfere with what's inside the Arduino application folder.

pawelsky
10-06-2014, 06:09 AM
How should the installer distinguish between overwriting user customizations vs simply updating an older version that doesn't have any user changes?

It doesn't, it displays the warning in both cases to give the end user a chance to decide.

If you want to avoid tons of warning popups you can display just one containing a list of libraries that will be removed/overwritten during the installation.

Calculating checksums would be nice, but I think we shall keep it simple.

Alternatively you can create a backup of removed/updated libraries somewhere during the installation.

xxxajk
10-06-2014, 12:27 PM
Paul, I know lots of work has gone into this, and you can miss a thing or two, which is why we do testing.
I've noticed that we are missing SPI examples using the new transaction goodness.
Any chance of putting in some kind of simple examples for the new modes like interrupt driven?

Nantonos
10-06-2014, 01:07 PM
The trouble with adding a transactional SPI example is that it either has to be hardware specific (and to run it you need the two specific devices connected) or it is generic (in which case you can examine and compile the code, but it doesn't do anything).

I did include a generic transactional SPI example when I rewrote the PJRC SPI page. However, that updated page has not been posted on PJRC yet.

xxxajk
10-06-2014, 01:31 PM
That reminds me of one other small tid-bit with SPI, and possibly a few other libraries that have architecture dependencies.
SPI_HAS_TRANSACTION should not be defined if it does not match any of the architectures, and it should possibly do an #include-next <SPI.h>
I've actually ran into this as an issue with some of my own crazy code.

Also, if I recall correctly, if a user has an SPI library, doesn't that "trump" the one provided?
I haven't had a chance to test the theory yet, and just wondering if that is a correct assumption, but I will be needing to do that in the future.

PaulStoffregen
10-06-2014, 01:33 PM
I've noticed that we are missing SPI examples using the new transaction goodness.


Do the Ethernet and SD libraries count? And ILI9341_t3?



Any chance of putting in some kind of simple examples for the new modes like interrupt driven?

RadioHead and Audio (as of only a few hours ago... on github) are the only ones so far.

Yes, there should probably be examples added in File > Examples > SPI. Anyone want to write and contribute some?

xxxajk
10-06-2014, 01:35 PM
The trouble with adding a transactional SPI example is that it either has to be hardware specific (and to run it you need the two specific devices connected) or it is generic (in which case you can examine and compile the code, but it doesn't do anything).

I did include a generic transactional SPI example when I rewrote the PJRC SPI page. However, that updated page has not been posted on PJRC yet.

Not if you just connect MISO to MOSI as a loopback and just spew data and verify it. :p Yes it is "useless" as far as anything practical, with exception to testing your SPI port, but it does provide an example to draw on, and it should be way easy to whip one up fast.

xxxajk
10-06-2014, 01:38 PM
Paul: Yes, I looked in there for some basic usage, which is fine for now, since I am just polling.
Do any of the other libraries use an SPI IRQ or DMA to transfer data?
I just glazed over them quickly, and didn't really notice anything like that.

PaulStoffregen
10-06-2014, 01:45 PM
Well, I had hoped to finalize 1.20 yesterday.... but it's looking like 1.20-rc6 is coming later today!

I added SPI.notUsingInterrupt(), which undoes the effect of SPI.usingInterrupt(), and put code into the audio lib to use it. I also did quite a bit more testing and debugging of stuff with the audio library. OctoWS2812 is converted to use DMAChannel.h and has several more examples. Lots of testing there revealed leftover debugging code in Audio that interfered.

Dealing with all this stuff is what makes the whole platform nice to use. But it also seems to make for perpetual release delays!

PaulStoffregen
10-06-2014, 01:47 PM
Do any of the other libraries use an SPI IRQ or DMA to transfer data?


I believe Adafruit_CC3000 is the only other one at this moment. But that code is so horrible, I wouldn't recommend looking.

I intend to port many more, but after a 1.20 final release.

xxxajk
10-06-2014, 03:06 PM
I rather have a delay than problems. Don't rush it. :cool: