BriComp
Well-known member
He says which in Post #24.What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.
He says which in Post #24.What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.
Isn't the above clear?I´ve used version 1.58 beta 2.
Paul mentioned to switch to 1.57, which more or less gave me the same storage amount needed like in IDE 1.8.19.
IDE 1.8.19
141 296 bytes program storage space
42476 bytes dynamic memory
IDE 2.0 + 1.57
140 848 bytes
42476 bytes
IDE 2.0 + 1.58 beta 2
151 376 bytes
42552 bytes
Isn't the above clear?
What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.
Not quite. Again, my point is the IDE doesn’t matter. Hex file is determined by source code (sketch, TD, libraries) and build tools, not by IDE version, as far as I know.
Not quite. Again, my point is the IDE doesn’t matter. Hex file is determined by source code (sketch, TD, libraries) and build tools, not by IDE version, as far as I know.
yes, fixing bugs is undoubtedly more useful. Then, warnings.I do intend to look into the code size increase
yes, fixing bugs is undoubtedly more useful. Then, warnings.
i.e. When will the cmsis bugs be fixed? The "sin" there is painful slow, because of a bug, for many years now![]()
i.e. When will the cmsis bugs be fixed? The "sin" there is painful slow, because of a bug, for many years now![]()
#include <arm_math.h>
void setup() {
// put your setup code here, to run once:
delay(2000);
uint32_t x_bin = 0xbfc90fdc;
float *x = (float*)&x_bin; // *x is -pi/2 in float
float cos_result;
cos_result = arm_cos_f32(*x);
Serial.println(cos_result);
cos_result = cosf(*x);
Serial.println(cos_result);
}
void loop() {
// put your main code here, to run repeatedly:
}
6.28
-0.00
Ah... my memory lied... it was not cmsis but the normal newlib.
sinf() was the problem.
Yes of course there were reports - they should all be in this forum. Several. Unfortunately I can't find them via search.
But that the newlib had also changed, the error should now be magically settled.
This isn't even on my list. Has it been previously reported with a reproducible test case?
CMSIS API is also a low priority. A huge backlog of far more important things are pending. Even with a test case, CMSIS stuff probably isn't going to get any updates for a very long time, maybe not ever. But no test case means it doesn't even go onto the low priority list.
A huge backlog of far more important things are pending.
... mostly just a reminder to future me to check ATOMIC_BLOCK macros on Teensy LC.
Turns out the ATOMIC_BLOCK stuff really wants to be inline, but with gcc 11.3.1 when optimizing for small code size (the default on Teensy LC) it isn't without __attribute__((always_inline)).
https://github.com/PaulStoffregen/RadioHead/commit/90a2414da665199413931f5203561ac0c8517b94
https://github.com/PaulStoffregen/cores/commit/9084d8e68fd772a04f3f0d601cf3de93b60efe44
File not found - '*.ino'
File not found - '*.ino'
Testing 0 examples
Commands created: 0
Commands to run: 0
$dir = 'F:\arduino-1.8.19-1131';
$sketchbook = 'D:\Users\Merli\Documents\Arduino';
I was trying once again to see if I can get that perl script of yours working on windows using strawberry Perl for window but I keep getting this