PDA

View Full Version : Teensyduino 1.21 Test #2 Available



Paul
12-29-2014, 11:26 PM
Here is a test version for Teensyduino 1.21:


EDIT: old links removed. Please use this newer version (https://forum.pjrc.com/threads/27740-Arduino-1-6-0-any-plans-to-support-it?p=66275&viewfull=1#post66275).


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

This test version has a newer 4.8.4 toolchain for Teensy 3.1 and improvements to the Arduino Serial Monitor.

Theremingenieur
12-30-2014, 12:46 PM
Just installed it and loaded my current project which compiled without issues. Could not yet shoot it towards the teensy since I'm at work and not at home. Will report problems later in case there are.

pawelsky
12-30-2014, 02:10 PM
improvements to the Arduino Serial Monitor.

Paul, is there any more detailed changelog available somewhere? I'm wondering what kind of improvements for ASM this Teensyduino version introduces.

Theremingenieur
12-30-2014, 02:16 PM
Paul, is there any more detailed changelog available somewhere? I'm wondering what kind of improvements for ASM this Teensyduino version introduces.

Yes, +1 for a changelog ! :-)

PaulStoffregen
12-30-2014, 02:33 PM
Paul, is there any more detailed changelog available somewhere?

Sure. Here's all the details. 1.20 was released on Oct 7th, so ignore commits before that date.

https://github.com/PaulStoffregen/cores/commits/master

https://github.com/PaulStoffregen/Arduino-1.0.6-Teensyduino/commits/master

https://github.com/PaulStoffregen/SPI/commits/master

As you can see, pretty minor stuff and small fixes. The toolchain upgrade and edits to the serial monitor are the only major changes.

PaulStoffregen
12-30-2014, 02:39 PM
I'm really hoping you'll give the improved serial monitor a try. That's the big new change.

The tricky part to watch is whether is always manages to automatically reopen the connection to your Teensy after an upload.

Theremingenieur
12-30-2014, 02:41 PM
The tricky part to watch is whether is always manages to automatically reopen the connection to your Teensy after an upload.

Oh, that's a new feature which I consider as being important. Can't wait to go home after work and give it a try!

pawelsky
12-30-2014, 02:45 PM
I'm really hoping you'll give the improved serial monitor a try. That's the big new change.

The tricky part to watch is whether is always manages to automatically reopen the connection to your Teensy after an upload.

Thanks Paul, will try that for sure. I'm also glad that the memory leak with auto scroll disabled was addressed. I think that was reason why the serial monitor became non-responsive sometimes after long logging session.

Constantin
12-30-2014, 02:45 PM
Hi Paul, just a quick note of thanks for the update and so far it seems to coexist very nicely with the xCode environment. I was able to build a program for my device and run it too, with the serial output now coming via a Terminal shell vs. the Arduino Serial Monitor. So far, it looks like it works great.


Thanks Paul, will try that for sure. I'm also glad that the memory leak with auto scroll disabled was addressed. I think that was reason why the serial monitor became non-responsive sometimes after long logging session.

The memory leak is something I also encountered. Though I didn't know what it was, I just noted that the computer itself would become unstable. :p

PaulStoffregen
12-30-2014, 02:51 PM
Yes, this is supposed to fix the memory leaks and also allow most PCs and Macs to keep up with maximum rate printing. It put the GUI update of the serial monitor on a 30 Hz schedule, so no matter how fast Teensy prints, Java only has to redraw the window contents at 30 Hz.

But I can't possibly test on a wide range of PCs and Macs... which is the main reason for this test release.

duff
12-30-2014, 03:17 PM
Just installed on my OSX 10.9.5 and the RawHID does not print anything to serial monitor now. Sketch:



void setup() {
Serial.begin(38400);
}


void loop()
{
Serial.println("Hello World");
delay(1000);
}

pawelsky
12-30-2014, 03:29 PM
Not sure if you want to add any more corrections in this release, but I've noticed that some of the examples (especially the ones for SD and SPI) are missing some CS pin description for Teensy 3.x. Also in other examples (e.g. where built in LED is used) there is only reference to Teensy 3.0 but not 3.1). These are minor things but in examples which are meant for newcomers may be important.

Here are some examples:
CardInfo.ino
Datalogger.ino
DumpFile.ino
Files.ino
listfiles.ino
ReadWrite.ino

But I'm sure there is more...

duff
12-30-2014, 08:32 PM
I really hope the serial monitor will work with RAWHID because compiling with Serial crashes my computer still!

el_supremo
12-31-2014, 12:26 AM
I can't get sprintf to work with floating point - neither float nor double. It worked this morning before I installed 1.21 Test #2.
Teensy3.1 on 64-bit Windows 7 Pro.
A sample program which demonstrates the problem and shows that sprintf still works with integers.



#include <stdio.h>
#include <stdlib.h>

float e = 2.7f;
double p = 3.14159;
char tmps[64];
void setup(void)
{
Serial.begin(9600);
while(!Serial);
Serial.println("Start");

// sprintf of double and float doesn't work at all.
sprintf(tmps,"%8.5f, %8.5lf",e,p);
Serial.println(tmps);

// printing a float with Serial works
Serial.println(e,2);
// and sprintf of an integer is OK
sprintf(tmps,"%6d",12345);
Serial.println(tmps);
}

void loop(void)
{
}


Output is:


Start
,
2.70
12345



Can anyone reproduce this or have I made a dumb mistake?

Pete

duff
12-31-2014, 01:11 AM
ok, not trying pile on but it seems after printing data very fast to serial monitor it crashes (freezes) the IDE when you try to upload while its printing.

OS: OSX 10.9.5
Teensy: 3.1, Serial, 48MHz, 1.21(#2)
Arduino: 1.0.6
Sketch to reproduce this: same as before just changed the delay for fast printing let it go awhile ~(2 minutes) then try to upload the same or any code without closing the serial monitor. The IDE will freeze and I have to Force Quit it.


void setup() {
Serial.begin(38400);
}


void loop() {
Serial.println("Hello World");
delay(10);
}


Edit:
It also seems that if you just upload this code and then try to upload again very soon after a couple of times it freezes also. I know this is a bit neurotic but just want this serial monitor stuff working good so I'm trying to see where it breaks:D

Theremingenieur
01-01-2015, 03:21 PM
Edit agin: Don't care about what I wrote before (in italics below).

A fresh install of Arduino 1.06, then Teensyduino 1.20, then Teensyduino 1.21#2 solved all problems. The serial monitor remains open, clears its content when uploading code, and starts displaying again!

Thank you for this fine update!

OK, all that does NOT work for me after upgrading from 1.20 to 1.21#2 ... :-(
a) The serial monitor window remains blank, no output is seen.
b) It does not reopen automatically after uploading code to the teensy.
Thus I'll have to revert to teensyduino 1.20 - hope that this will work for me

(OSX 10.10.2, Arduino 1.06)

Edit: Gave it another try. Did a fresh install of Arduino 1.06 and Teensyduino 1.21#2. Same problem. No output on the serial monitor. No automatic (re-)opening of the serial monitor. Now doing a fresh install of 1.06 again with 1.20 and hope that things will art least work as they did before.

Frank B
01-02-2015, 09:04 PM
I get "deprecated" warnings with

bool findUntil(char *target, char *terminator); (Stream.h)

If the strings are "const". I don't know if this is normal (did not test with TEENSYDUINO120).
Maybe it should be bool findUntil(char const *target, char const *terminator); ?

Regards,
Frank.

stevech
01-03-2015, 01:52 AM
use of double and "lf" in sprintf... does Teensy 3 software floating point support doubles in math as well as the DEFAULT clib formatter for doubles (versus single/float)?

el_supremo
01-03-2015, 02:13 AM
With version 1.20 of Teensyduino, this code on a Teensy 3.1:


void setup(void)
{
char tmp[32];
Serial.begin(9600);
while(!Serial);
delay(1000);

sprintf(tmp,"%18.12lf",sin(3.14159/4));
Serial.println(tmp);
}

void loop(void)
{
}

prints:

0.707106312094

But it doesn't work with 1.21 test#2. It doesn't print anything.

Pete

Theremingenieur
01-03-2015, 02:10 PM
Pete, it is not true that it doesn't print anything, it does print - a CRLF... ;-)

Apparently, what you see is the "normal" behavior. See this link (http://forum.arduino.cc/index.php?topic=65185.0)

It would rather be interesting to understand why this worked in 1.20, though...

Theremingenieur
01-03-2015, 02:21 PM
Just discovered another issue: Even the "simple" Serial.println() does some unexpected and weird variable casting.

printing a int8_t (signed byte) which contains a negative value gives a int32_t output. WHY???


void setup(void) {
Serial.begin(57600);
while(!Serial);
delay(1000);
Serial.println("Started");
int8_t i = -2;
Serial.print("DEC");Serial.print("\t");
Serial.print("size");Serial.print("\t");
Serial.print("HEX");Serial.print("\t");
Serial.println("BIN");
Serial.print(i,DEC);Serial.print("\t");
Serial.print(sizeof(i));Serial.print("\t");
Serial.print(i,HEX);Serial.print("\t");
Serial.println(i,BIN);
}

void loop(void) {
}

Output:


Started
DEC size HEX BIN
-2 1 FFFFFFFE 11111111111111111111111111111110

instead if the expected


Started
DEC size HEX BIN
-2 1 FE 11111110

MichaelMeissner
01-03-2015, 02:51 PM
Just discovered another issue: Even the "simple" Serial.println() does some unexpected and weird variable casting.

printing a int8_t (signed byte) which contains a negative value gives a int32_t output. WHY???


That is because there is no version of the Print class that takes signed char (i.e. int8_t) as a type, and the compiler does the standard conversions to one of the types that have alternates in Print.h. The C/C++ languages first convert signed char/short to int. On the arm platform, int is a 32-bit type. On the AVR platform (like the Arduino), int is a 16-bit type.



size_t print(unsigned char n, int base) { return printNumber(n, base, 0); }
size_t print(int n, int base) { return (base == 10) ? print(n) : printNumber(n, base, 0); }
size_t print(unsigned int n, int base) { return printNumber(n, base, 0); }
size_t print(long n, int base) { return (base == 10) ? print(n) : printNumber(n, base, 0); }
size_t print(unsigned long n, int base) { return printNumber(n, base, 0); }

Theremingenieur
01-03-2015, 03:05 PM
Thank you, MichaelMeissner!

I was just trying to accelerate some of my code, replacing floats by integers as pseudo-floats and doing some bitwise operations and bit shifting, which can be dangerous with signed numbers. I need also to use deliberately some rollover effects. All that can be useful when emulating harmonic oscillators with resonating filters.

So, I wanted to check out some of my "ideas" with the famous "Serial.print debugger" and was really confused by its outputs...

stevech
01-03-2015, 05:40 PM
Thank you, MichaelMeissner!

I was just trying to accelerate some of my code, replacing floats by integers as pseudo-floats and doing some bitwise operations and bit shifting, which can be dangerous with signed numbers. I need also to use deliberately some rollover effects. All that can be useful when emulating harmonic oscillators with resonating filters.

So, I wanted to check out some of my "ideas" with the famous "Serial.print debugger" and was really confused by its outputs... Sounds like fixed-point math. There are libraries for fixed-point arithmetic, written in C.

Kontakt
01-07-2015, 07:02 AM
Ran into an error compiling a known good program, and I've found why.
I don't know when Adafruit_SSD1306 was changed, but the version supplied by the installer doesn't match the version on Paul's github.

The compile fails due to a prototype not having a matching function definition;
the header declares

void dim(uint8_t contrast);
but in the source we have

void Adafruit_SSD1306::dim(boolean dim) {
uint8_t contrast;

if (dim) {
contrast = 0; // Dimmed display
} else {
if (_vccstate == SSD1306_EXTERNALVCC) {
contrast = 0x9F;
} else {
contrast = 0xCF;
}
}
// the range of contrast to too small to be really useful
// it is useful to dim the display
ssd1306_command(SSD1306_SETCONTRAST);
ssd1306_command(contrast);
}

Bringing the prototype in line with the definition removes the error being thrown, but I can't vouch for the functionality.

Kontakt
01-07-2015, 07:05 AM
I have verified expected functionality with the modified prototype.

embedded-creations
01-08-2015, 04:13 AM
@Paul, do you have a deadline if I want to submit the SmartMatrix Library to be included in Teensyduino 1.21? Do you know if you're going to update FastLED to version 3.x for Teensyduino 1.21?

PaulStoffregen
01-08-2015, 10:25 AM
Anytime in the next few weeks would be good.

duff
01-09-2015, 12:25 AM
Paul, did you try this with RAW-HID (Serial) yet (https://forum.pjrc.com/threads/27403-Teensyduino-1-21-Test-2-Available?p=60865&viewfull=1#post60865)? It does not print to serial monitor. My setup -> OSX 10.9.5, Arduino 1.0.6

pixelk
01-09-2015, 02:46 AM
It seems the Mouse.move(x,y) has reversed directions. To achieve the same directions as 1.20 I had to replace it with Mouse.move(-x,-y).

Not a big concern for me, but you never know...

nox771
01-09-2015, 08:18 PM
Question on the toolchain setup. I'm trying to update my Eclipse setup to Arduino 1.0.6 and Teensyduino 1.21. The toolchain directory is different, but moreover things like make.exe are gone. I'm at a loss on where to point things. Looking in the makefile at: arduino\hardware\teensy\cores\teensy3\Makefile, it appears to be wrong. The COMPILERPATH is incorrect.

Do I need to install this separately as described here? : http://gnuarmeclipse.livius.net/blog/build-tools-windows/

Is there an existing thread on this topic?

nox771
01-09-2015, 09:03 PM
Do I need to install this separately as described here? : http://gnuarmeclipse.livius.net/blog/build-tools-windows/


A followup, downloading the build tools from http://sourceforge.net/projects/gnuarmeclipse/files/Miscellaneous/ (as provided by above link), and installing the .exe and .dll files provided to: arduino\hardware\tools\arm\bin has restored functionality to my Eclipse build process.

I'm curious if the make.exe functionality is provided via some other mechanism in the 4.8.4 build process? Or is this an oversight? make.exe was in my previous Teensyduino 1.19 install.

Frank B
01-10-2015, 10:56 AM
The #define FASTRUN needs (at minimum) an additional attribute "noinline". maybe more, i'm investigating this..

Frank B
01-11-2015, 11:24 AM
Paul, i would suggest
#define FASTRUN __attribute__ ((section(".fastrun"), noinline, noclone ))

MichaelMeissner
01-11-2015, 04:48 PM
Paul, i would suggest
#define FASTRUN __attribute__ ((section(".fastrun"), noinline, noclone ))
Just to be safe, you want two leading underscores before/after each word just in case somebody decides to #define noinline, etc.:



#define FASTRUN __attribute__ ((__section__(".fastrun"), __noinline__, __noclone__))

MichaelMeissner
01-11-2015, 04:48 PM
Paul, i would suggest
#define FASTRUN __attribute__ ((section(".fastrun"), noinline, noclone ))
Just to be safe, you want two leading underscores before/after each word that is not within quotes just in case somebody decides to do some like #define noinline, etc.:



#define FASTRUN __attribute__ ((__section__(".fastrun"), __noinline__, __noclone__))

Frank B
01-18-2015, 10:28 AM
Don't know if it were mentioned before, two warnings when using SD:


C:\Arduino\libraries\SD\utility\Sd2Card.cpp: In member function 'uint8_t Sd2Card::readData(uint32_t, uint16_t, uint16_t, uint8_t*)':
C:\Arduino\libraries\SD\utility\Sd2Card.cpp:478:12 : warning: unused variable 'n' [-Wunused-variable]
uint16_t n;
^
C:\Arduino\libraries\SD\utility\Sd2Card.cpp: At global scope:
C:\Arduino\libraries\SD\utility\Sd2Card.cpp:145:13 : warning: 'void spiSend(const uint8_t*, size_t)' defined but not used [-Wunused-function]
static void spiSend(const uint8_t* output, size_t len) {
^

Frank B
01-18-2015, 10:33 AM
Still with malloc_trim():


c:/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m\libc_s.a(lib_a-mtrim.o): In function `malloc_trim':
mtrim.c:(.text.malloc_trim+0x6): undefined reference to `_malloc_trim_r'
collect2.exe: error: ld returned 1 exit status


Can you please add it ?
For the codecs, i want to check the free space (they need much ram) before playing, and this works better with trim..

Even better would be a malloc that does not crash if no memory is available (if possible(???))
EDIT: just tested again, sorry, it does not crash.. (funny, i remember that it did some time ago...)

Frank B
01-18-2015, 12:29 PM
Maybe you could set in "control_sglt5000 " the chip select pins for SD and SPIFlash "high" ... (if not already done there or elsewhere)
I just noticed that - according to the schematic - there are pullups missing...perhaps it causes problems when the flash is soldered and has a floating chipselect...

PaulStoffregen
01-18-2015, 02:51 PM
A new revision of the audio board is on the way. It has 2 real pullup resistors on the SD and SPI Flash chip selects.

Frank B
01-22-2015, 09:33 PM
hm.. according to this document http://alumni.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf, (i just found it, because i'm doing some research..) there a some more pullups needed (?)
Is this correct ?

The external pullups shown are required by the SD protocol, and must be present even for the unused data pins.

Nantonos
01-22-2015, 10:31 PM
This is what happens when usage of a standard requires paying USD 2000 per year and the specification lives behind a paywall.

People reply on leaked summaries which may be incomplete, and there is no channel for reporting bugs. Having a pin labelled "unused (or IRQ)" with a mandatory pullup to stop the interrupt being randomly triggered would be one such bug that might be reported.

Frank B
01-23-2015, 03:28 PM
See:
http://www.nxp.com/documents/application_note/AN10911.pdf Table 3

For SD, CS, CMD, Dat0-DAT2 10K-100K(90K), for MMC 4k7(CMD) or 50-150k (Table 7)

Frank B
01-24-2015, 12:06 PM
http://embdev.net/attachment/39390/TOSHIBA_SD_Card_Specification.pdf (the last one, dont want annoy. Sorry. Please. see 6.4. SD card Electrical Characteristics)

Headroom
01-25-2015, 02:41 AM
I'd like to bring up the bonjour/ multicast topic again discussed in the TD1.2 thread.

Paul, you mentioned a fallback solution in this post (https://forum.pjrc.com/threads/26640-Teensyduino-1-20-Release-Candidate-3-Available?p=54732&viewfull=1#post54732). Could you provide a more specific pointer where I would find that perhaps in what file so I can start looking at this ?

xxxajk
01-31-2015, 01:08 AM
Experiencing too many compiler bugs with gcc version 4.8.4 20140725
(I write some complex C++ code, apparently!)
Going to see if gcc-arm-none-eabi-4_9-2014q4-20141203 resolves them.

PaulStoffregen
01-31-2015, 01:24 AM
Maybe write simpler code?

xxxajk
01-31-2015, 05:55 AM
LOL! Nice :-) Not an option. Handling USB and filesystems can be a complicated affair. ;)

stevech
01-31-2015, 06:13 AM
Experiencing too many compiler bugs with gcc version 4.8.4 20140725

A short example or two?

xxxajk
01-31-2015, 06:13 AM
First the good news.
Code that was majorly broken now compiles without complaints.
optimizer bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58545
has been fixed! YAY! Progress!


Now for the bad news...
There is still some strange issue with using a derived child class beyond 2 levels when said code is fully contained in a header file and simply included.
Technically this shouldn't matter, but for some silly reason, it does.
I still need to continue the research on this

xxxajk
01-31-2015, 07:11 AM
FWIW 2015-Q1 will have a lot of other nice fixes too. While this does fix some optimization bugs, others still do of course remain.

I am seeing variable corruptions, which may be related to a few other optimization bugs that have been reported.
So, for my next step...
I'll try and compile with -O2 and see if that remedies the problem, and report my findings here. Supposedly this solves some of the issues that I may be tripping.
If different optimization options do provide a fix, then I at least know I am on the correct path to locating the root cause.

PaulStoffregen
01-31-2015, 08:28 AM
Have you tried -Og ?

xxxajk
01-31-2015, 09:04 AM
Well, using -O[02g] didn't matter :(

So I tried not using an ISR (polling), which makes the code path identical to AVR with all three options too, and that gave same failure, so there is something still bugging it.
I don't discount that it could even be something else that I am missing.
Perhaps I need to flush the instruction pipelines, but that shouldn't matter if I am polling...

My conclusion, for "normal" code, I highly recommend that the newer GCC (2014q4-20141203) be used because:

The compiler now reports the correct line number with an error
Many important optimizer/backend bug fixes that don't crash the compiler anymore
Initialization on arrays now happens properly


I'll keep quiet now, and keep hacking at it. Please consider using the newer GCC and associated utilities that are a part of it.
The build scripts provided work fantastic, and with no need to hack them.
If you need to know how I did my build, don't hesitate to ask! :D

pixelk
01-31-2015, 04:20 PM
Playing with some ESP8622 I had more opportunities to use and abuse the new console, and I can say that it's better in every way. Thank you !

On a tottaly different subject, in the Adafruit_SSD1306.h line 142 should be

void dim(boolean dim);
and not

void dim(uint8_t contrast);

It only poped as an error with the 1.21rc2, maybe due to the new compiler.

stevech
01-31-2015, 08:48 PM
the older GNU ARM compiler did OK with my wireless code where the base class to the instance class is 4 or more levels of inheritance.
But this is with default optimization.

xxxajk
01-31-2015, 09:15 PM
the older GNU ARM compiler did OK with my wireless code where the base class to the instance class is 4 or more levels of inheritance.
But this is with default optimization.

Well, try renaming your .cpp to .h files, and #include them in your sketch.
There are also sections in my code that is extern "C" as well
I think the mix is confusing it pretty bad...

stevech
01-31-2015, 10:19 PM
Well, try renaming your .cpp to .h files, and #include them in your sketch.
There are also sections in my code that is extern "C" as well
I think the mix is confusing it pretty bad...
I have little or no code in the .h files. Not my habit to do that. But it's sometimes done because a lazy IDE approach doesn't want the user to have to pick and choose .cpp files. So same-same, they pick and choose .h files. Or more likely, one top level .h includes all the others and the code thus comes in anyway.
I do have some extern "C" declarations too.

xxxajk
02-01-2015, 02:08 AM
I have little or no code in the .h files. Not my habit to do that. But it's sometimes done because a lazy IDE approach doesn't want the user to have to pick and choose .cpp files. So same-same, they pick and choose .h files. Or more likely, one top level .h includes all the others and the code thus comes in anyway.
I do have some extern "C" declarations too.

I do so because the "IDE" lacks the ability to allow you to do any kind of configuration.

stevech
02-01-2015, 03:28 AM
I do so because the "IDE" lacks the ability to allow you to do any kind of configuration.

Use a better IDE!

xxxajk
02-01-2015, 03:33 AM
Use a better IDE!
That doesn't help a noob wanting an out-of-box good experience, Yes, I use NetBeans for myself, that doesn't help those who are learning.

stevech
02-01-2015, 05:28 AM
Oh, I misunderstood. I though your code that was encountering the compiler bugs was for your own use.

xxxajk
02-01-2015, 06:11 AM
Even if it was, broken tools help nobody. ;)

I'm actually cross-supporting boards, and USB Host Shield from http://www.CircuitsAtHome.com
Among the boards that use a broken tool chain include the Arduino Zero and Arduino Due.

As a side-benefit to everybody, once things are all sorted out...
Paul's Teensy 3.x products will be able to have native-host capability, and be able to also use the mini host shield as well, even at the same time.

PaulStoffregen
02-01-2015, 02:44 PM
It only poped as an error with the 1.21rc2, maybe due to the new compiler.

It's actually due to this bug fix in Arduino (https://github.com/arduino/Arduino/pull/2151), which I also applied to the latest Teensyduino.

I sent a pull request (https://github.com/adafruit/Adafruit_SSD1306/pull/21) to Adafruit, and I'm updating Teensyduino's copy of this library.

KurtE
02-01-2015, 03:31 PM
Probably a set of nits, but when I compile some stuff, especially stuff that use with multiple platforms, I am getting more warnings than before.
Example:

#include <avr\pgmspace.h>
static const word GetSin[] PROGMEM = {
0, 87, 174, 261, 348, 436, 523, 610, 697, 784, 871, 958, 1045, 1132, 1218, 1305, 1391, 1478, 1564,
9975, 9981, 9986, 9990, 9993, 9996, 9998, 9999, 10000 };//

void setup() {
Serial.begin(38400);
}

void dummyFunction(char *psz) {
}

void loop() {
word sin4;
sin4 = pgm_read_word(&GetSin[5]);
Serial.print(sin4);

dummyFunction("String");

}

Note: the depreciated string message I am now also getting for Uno, so probably been there awhile...


In file included from sketch_feb01a.ino:1:0:
sketch_feb01a.ino: In function 'void loop()':
C:\Program Files (x86)\Arduino\hardware\teensy\cores\teensy3/avr\pgmspace.h:56:60: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
#define pgm_read_word(addr) (*(const unsigned short *)(addr))
^
sketch_feb01a.ino:24:10: note: in expansion of macro 'pgm_read_word'
sketch_feb01a.ino:27:25: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]

Maybe I will have to convert some code to using string objects....

Frank B
02-01-2015, 03:45 PM
I am getting more warnings than before.
Yes, the reason is that the newer compiler emits more warnings, which is a good thing!

KurtE
02-01-2015, 04:38 PM
Agree: but not sure if something should be done with system header files like pgmspace.h as to avoid these messages.

PaulStoffregen
02-01-2015, 08:39 PM
The "deprecated conversion from string constant" warning has nothing to do with pgm_read_word(). The real problem is this:



void dummyFunction(char *psz) {
}


Your dummyFunction takes a normal writable pointer, not a const one. If you pass a const string to it, the compiler warns your giving non-writable data to a function that is defined as intending to write. It doesn't matter what code is actually inside dummyFuncton. All that matters is you didn't use const in the function definition.

PaulStoffregen
02-01-2015, 08:53 PM
The "dereferencing type-punned pointer will break strict-aliasing rules" warning is appearing because you've got a size mismatch between the array and pgm_read_word(). Even though they're both defined as "word", the name is used inconsistently by Arduino. Teensy is trying to follow the "standard" set by the Arduino developers. They decided "word" means 16 bits on AVR and 32 bit on ARM.

The pgm_read_word() function is emulating an AVR-only library, on ARM. So it is using a 16 bit access.

When you access something as 16 or 32 bit, and the thing you're accessing isn't the same size, the compiler prints this warning. On Teensy 3.1, you can almost always ignore this warning, because the ARM Cortex-M4 processor supports unaligned access. It's slower, since the bus controller needs to stall the CPU for another couple cycles while it does 2 reads, or 2 reads and 2 writes if you wrote across a 32 bit boundary, but other than taking longer, there's little harm.

But this warning is far more serious on the upcoming Teensy-LC. One of the many non-essential features removed from the ARM Cortex-M0+ CPU to lower the cost is the automatic handling of non-aligned memory access. On Teensy-LC, this particular code would probably still work, since it's accessing 16 bits using the address of a 32 bit data item. Usually the problems occur with a point to 8 bit data is used to perform a 16 or 32 bit access.

Normally, the compiler will automatically align everything properly. But when you start typecasting pointers, you're telling the compiler to trust you - you know what you're doing - and consider the pointer to really be to something else. If you do that, be careful.

stevech
02-01-2015, 09:17 PM
Do such a cast with C# or Objective C?

KurtE
02-01-2015, 09:21 PM
Thanks, will take a pass through the real code bases and fix up some of these. Although these days I am tempted to punt in some code bases and remove the progmem stuff as I am not sure I will downgrade back to AVR processors anytime soon!

Kurt

PaulStoffregen
02-01-2015, 09:46 PM
I'd suggest first finding all your functions that take a normal pointer, but never actually need to write to memory, and change them all to const pointers. For a larger code base, that can have really good long-term benefits. It's relatively quick and easy to do, but best done one function at a time starting at the lowest levels of abstraction and working up. If you change too many, too quickly, it's easy to get into a confusing mess of which things depend on which other things.

The best reason to tackle the const pointer warning first is the possibility your code actually does write in places where it shouldn't. That's rarely a quick and easy fix, but the value of fixing those warnings, and in general adding const to every pointer that never write is it tends to expose those more serious design flaws.

Fixing the strict aliasing warnings in a large, already-written code base is really painful. In the end, if your code isn't crashing, there's probably better ways to spend your time.

xxxajk
02-01-2015, 11:43 PM
Looks like the last bit of corruption is actually my fault. I forgot to atomically guard a variable. On the AVR it just happens to work because the AVR will not abort an instruction, whereas ARM does. Therefore, once updated to the newer tool-chain, everything works as expected on ARM too,

PaulStoffregen
02-02-2015, 12:01 AM
I'll probably migrate from 4.8 to 4.9 after Teensy-LC and Teensyduino 1.21 (and maybe 1.22) are released.

Quite a lot of testing has been done on 4.8 over the last couple months. With a new product release demanding all my attention, now hardly seems like a great time to upgrade the toolchain.

xxxajk
02-04-2015, 08:36 PM
No problem, since I can (for now) upgrade it on my own anyway.
You may as well upgrade it to the latest when you do decide to do this anyway.

Codefella
02-16-2015, 08:56 AM
I'm really hoping you'll give the improved serial monitor a try. That's the big new change.

The tricky part to watch is whether is always manages to automatically reopen the connection to your Teensy after an upload.
Just tested this new feature which is very useful to me but encountered a problem:

opening the serial monitor is very slow, the lag after click is 3 seconds. it seems that it's searching or probing all serial ports available not only the
one used to communicate with teensy.

if i remove a bluetooth module (usb, providing two virtual com ports) everything is fine!

let me know if i could provide further information.

regards, andi

PaulStoffregen
02-16-2015, 09:03 AM
let me know if i could provide further information.


Please try with Arduino 1.6.0 and Teensyduino 1.21-beta5.

https://forum.pjrc.com/threads/27740-Arduino-1-6-0-any-plans-to-support-it?p=64839&viewfull=1#post64839

Arduino 1.6.0 switched to an entirely new serial library. Odds are good that will solve the problem. If not, I'd like to only pour dev work into the new JSSC library path. The old RXTX library is a dead end.

Theremingenieur
02-16-2015, 10:21 AM
Arduino 1.6.0 and Teensyduino 1.21-beta5 work fine for me. There was still an old annoying issue which would ask me every time when I open the Arduino app if I wanted to allow incoming connections. That's an OS X problem because the original (signed) Arduino.app was modified by Teensyduino. Resigning Arduino.app with a self generated key after installing Teensyduino did the trick and the annoying dialog disappeared.

Codefella
02-16-2015, 10:37 AM
Please try with Arduino 1.6.0 and Teensyduino 1.21-beta5.

https://forum.pjrc.com/threads/27740-Arduino-1-6-0-any-plans-to-support-it?p=64839&viewfull=1#post64839

Arduino 1.6.0 switched to an entirely new serial library. Odds are good that will solve the problem. If not, I'd like to only pour dev work into the new JSSC library path. The old RXTX library is a dead end.

Still the same problem. problem also appears if opening the "Tools" menu in the arduino IDE. must be some kind of delay when checking installed com ports.
but there's no lag when opening the serial monitor with old teensyduino version.

i think you could reproduce the problem by installing the following driver which emulates an com port for an rs232/ethernet adapter: http://www.wut.de/download/e-00111-ww-swww-420.exe

wbowers9000
02-17-2015, 07:09 PM
The installer still shows that it is for Arduino ver. 1.0.5 and 1.0.6. Just a reminder to update.

getSurreal
02-25-2015, 05:22 PM
Did the pin33 low on boot issue get addressed in this one? https://forum.pjrc.com/threads/24823-Teensy-3-1-Tying-Pin-33-(pta4)-low-freezes-teensy?highlight=pin33

JBeale
02-28-2015, 09:30 PM
I seem to get a lot of retries when programming Teensy 3 from Win7 with Arduino 1.0.6 / Teensyduino 1.21-beta6 before the programming finally completes. A few times it has stopped midway with an error, but re-trying then succeeds.


teensy_reboot, verbose mode
Device Instance: 2048
DeviceRegistryProperty: acquired
Key type: REG_MULTI_SZ
property: USB\VID_16C0&PID_0483&REV_0100
property: USB\VID_16C0&PID_0483
Registry Key: acquired
PortName: "COM23"
pathname: \\.\COM23
add_serial_name, \\.\COM23
trying port 3149
found Teensy Loader, version 1.21
send: status - at Sat Feb 28 09:35:52 2015
do_reset (serial) \\.\COM23
send: status - at Sat Feb 28 09:35:52 2015
status read, retry 0
send: status - at Sat Feb 28 09:35:52 2015
status read, retry 1
send: status - at Sat Feb 28 09:35:52 2015
status read, retry 2
send: status - at Sat Feb 28 09:35:53 2015
status read, retry 3
send: status - at Sat Feb 28 09:35:53 2015
status read, retry 4
send: status - at Sat Feb 28 09:35:53 2015
status read, retry 5
send: status - at Sat Feb 28 09:35:53 2015
status read, retry 6
Success

Avenue33
03-02-2015, 10:58 AM
@PaulStoffregen

Unfortunately, the installer of Teensyduino 1.21 Test #2 doesn't detect Arduino 1.6.0 on Mac OS X.

PaulStoffregen
03-02-2015, 05:30 PM
Delete that old "-test2" copy. Five more have been published since them. Get the latest, which works great with Arduino 1.6.0:

https://forum.pjrc.com/threads/27740-Arduino-1-6-0-any-plans-to-support-it?p=66275&viewfull=1#post66275

Avenue33
03-02-2015, 05:32 PM
Thank you!

chipmc
03-04-2015, 03:35 AM
I am having this issue too. sprintf stopped working with the 1.21 test#2. Any way to fix?

Thanks, Chip

el_supremo
03-07-2015, 03:16 PM
sprintf of float and double now work with beta8 and 1.6.0 on a Teensy 3.1 (see the test code in #14) but neither of them work on T3.0 or T-LC

Pete

PaulStoffregen
03-07-2015, 04:51 PM
Look in Tools > CPU Speed. 1.21-beta8 has new choices, to optimize for speed or code size.

The small code size settings default to a printf and scanf without floating point. But there's a trick to get the float versions:

https://forum.pjrc.com/threads/27827-Float-in-sscanf-on-Teensy-3-1

el_supremo
03-07-2015, 08:25 PM
That fixed it! Thanks Paul.

Pete

stevech
03-07-2015, 09:35 PM
Look in Tools > CPU Speed. 1.21-beta8 has new choices, to optimize for speed or code size.

The small code size settings default to a printf and scanf without floating point. But there's a trick to get the float versions:

https://forum.pjrc.com/threads/27827-Float-in-sscanf-on-Teensy-3-1
can the IDE have a GUI to enable big printf, along with compiler optimization choices?

esapode688
03-12-2015, 01:35 PM
I just installed Arduino 1.6.1 and downloaded teensy 1.21-beta8.

But when I try to install I get a popup with supported arduino Versions and there is this error


Directory: C:/Program Files (x86)/Arduino/
Checking Arduino 1.0.5:
file: "arduino.exe" present
file: "rxtxSerial.dll" missing
Does not match Arduino 1.0.5
Checking Arduino 1.0.6:
file: "arduino.exe" present
file: "rxtxSerial.dll" missing
Does not match Arduino 1.0.6
Checking Arduino 1.6.0:
file: "arduino.exe" present
file: "arduino_debug.exe" present
file: "lib/jssc-2.8.0.jar" present
file: "hardware/arduino/avr/boards.txt" present
file: "hardware/arduino/avr/platform.txt" present
dir: "hardware/arduino/avr/cores/arduino" present
file: "hardware/arduino/sam/boards.txt" present
file: "hardware/arduino/sam/platform.txt" present
dir: "hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1" present
dir: "libraries" present
dir: "examples" present
java: "lib/pde.jar" object: "processing/app/Base.class" wrong size, unsupported Arduino version
Does not match Arduino 1.6.0
Checking Arduino 1.6.1:
file: "arduino.exe" present
file: "arduino_debug.exe" present
file: "lib/jssc-2.8.0.jar" present
file: "hardware/arduino/avr/boards.txt" present
file: "hardware/arduino/avr/platform.txt" present
dir: "hardware/arduino/avr/cores/arduino" present
file: "hardware/arduino/sam/boards.txt" present
file: "hardware/arduino/sam/platform.txt" present
dir: "hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1" present
dir: "libraries" present
dir: "examples" present
java: "lib/pde.jar" object: "processing/app/Base.class" wrong size, unsupported Arduino version
Does not match Arduino 1.6.1

I'm Using Windows 8.1 X64

PaulStoffregen
03-12-2015, 02:13 PM
How'd you download beta8? I left the files on the server, but removed the all links. Or at least I thought I removed all the old links.

We're on beta10 now, and there's a known issue where it's only recognizing the Windows ZIP file for 1.6.1, but not the EXE installer version. Tuesday's 1.6.1 release was the first Arduino has ever published different files in the 2 Windows downloads! I'm working on a fix today.

If you want to try now, use beta10 and the Windows ZIP file version.

esapode688
03-12-2015, 10:22 PM
How'd you download beta8? I left the files on the server, but removed the all links. Or at least I thought I removed all the old links.

We're on beta10 now, and there's a known issue where it's only recognizing the Windows ZIP file for 1.6.1, but not the EXE installer version. Tuesday's 1.6.1 release was the first Arduino has ever published different files in the 2 Windows downloads! I'm working on a fix today.

If you want to try now, use beta10 and the Windows ZIP file version.

you were right it was the beta 10 and yes it gives the error.

I wait for the fix on the exe file