Teensyduino 1.21 Test #2 Available

Status
Not open for further replies.
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.
 
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:
  1. The compiler now reports the correct line number with an error
  2. Many important optimizer/backend bug fixes that don't crash the compiler anymore
  3. 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
 
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
Code:
void dim(boolean dim);
and not
Code:
void dim(uint8_t contrast);

It only poped as an error with the 1.21rc2, maybe due to the new compiler.
 
Last edited:
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.
 
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...
 
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.
 
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.
 
Oh, I misunderstood. I though your code that was encountering the compiler bugs was for your own use.
 
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.
 
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:
Code:
#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...
Code:
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....
 
Agree: but not sure if something should be done with system header files like pgmspace.h as to avoid these messages.
 
The "deprecated conversion from string constant" warning has nothing to do with pgm_read_word(). The real problem is this:

Code:
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.
 
Last edited:
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.
 
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
 
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.
 
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,
 
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.
 
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.
 
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
 
Status
Not open for further replies.
Back
Top