Here is a second beta test for Teensyduino 1.54.
Edit: Links removed. Please use 1.54-beta9
https://forum.pjrc.com/threads/67252...no-1-54-Beta-9
Changes since Teensyduino 1.54-beta1:
Fix 1.54-beta1 startup problem on Teensy 4.1
EEPROM put/get handle String and warn for incompatible classes (luni64)
Add _extram_start & _extram_end for Teensy 4.1
Update Bounce2
It installs
<edit>
T_4.1 10-15 uploads of 5 recent sketches noted in beta1 thread all good.
Last edited by defragster; 10-24-2020 at 02:28 AM.
Great, the EncoderTool which depends on a current Bounce2 now compiles out of the box. ThanksUpdate Bounce2
Tested with the code below. Works as expected.EEPROM put/get handle String and warn for incompatible classes
Prints outCode:#include "EEPROM.h" struct GoodType // this is bytewise copyable { const char* text = "Good struct"; float version = 1.54f; int relelase = 2; }; struct BadType // this is NOT bytewise copyable { String text = "Bad struct"; float version = 1.54f; int relelase = 2; }; void setup() { while (!Serial) {} int pos0 = 0; // Save to EEProm ------------------------------- String s1 = "Hello Teensyduino 1.54 beta 2"; EEPROM.put(pos0, s1); int pos1 = pos0 + s1.length() + 1; // need to take the delimiting /0 into account GoodType goodType; EEPROM.put(pos1, goodType); int pos2 = pos1 + sizeof(goodType); BadType badType; //EEPROM.put(pos2, badType); // if uncommented this generates a compile time error since the type is not bytewise copyable int pos3 = pos2 + sizeof(goodType); // read from EEProm ----------------------------- String storedString1; EEPROM.get(pos0, storedString1); GoodType storedGoodType; EEPROM.get(pos1, storedGoodType); Serial.println(storedString1); Serial.println(storedGoodType.text); Serial.println(storedGoodType.version); Serial.println(storedGoodType.relelase); } void loop(){ }
Code:Hello Teensyduino 1.54 beta 2 Good struct 1.54 2
Same here - all seems to be working. Ran with OpenGL, EigenTest, check42 psram test with no problem.Originally Posted by defragster
It installs
<edit>
T_4.1 10-15 uploads of 5 recent sketches noted in beta1 thread all good.
Morning all,
Installed Windows 10, and built T4.1 code
Side notes: But with simple Camera test sketch I am now working through the new warnings for Serial.printf(...)
Fixed the first obvious one, of I passed a uint... to a %d instead of a %u...
But that still did not work, neither does %x...
Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!
Installed RPI4 8GB SSD Ubuntu Arm64 - Arduino 1.8.12, earlier 13 was not found on Arduino server.... It is today so downloading.
Same issue as mentioned in the thread: https://forum.pjrc.com/threads/61623...l=1#post255856
The build goes through but launching the Teensy tool has issues and errors out. The Teensy app shows up as a white window with nothing in it.
But if I go into and manually start Teensy app it shows up properly. But most of the time does not automatically program properly, but will if I press the program button.
Tested on T3.2
Edit same thing on 1.8.13
Last edited by KurtE; 10-24-2020 at 01:14 PM.
> Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!
> printf("uint32_t var : %"PRIu32"\n", u32x);
I see one here:
Audio/input_adc.cpp:341:45: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}'
Where appropriate, I'd maintain portability with this idea (from bperrybap):
printf("uint32_t var : %"PRIu32"\n", u32x);
Seeing exactly the same thing using Ubuntu 18.04, the screenshot matches exactly.
Ran across an instance of that myself this morning. There are probably quite a few Lib's and examples that will need updating? Think there was a post where Paul mentioned this somewhere?Code:Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!
Sorry I am old dog who has not learned the new trick yet
What does that mean? Yes I can and will google it,
but does this print Hex or Decimal? Not terribly clear. Or maybe an example might help. Here is one I just fixed up:
Example how would you translate this one I just updated to remove the warnings:
This dumps out a DMA structure I am using to help debug some code...Code:void dumpDMA_TCD(DMABaseClass *dmabc) { Serial.printf("%lx %lx:", (uint32_t)dmabc, (uint32_t)dmabc->TCD); Serial.printf("SA:%lx SO:%d AT:%x NB:%lx SL:%ld DA:%lx DO:%d CI:%x DL:%ld CS:%x BI:%x\n", (uint32_t)dmabc->TCD->SADDR, dmabc->TCD->SOFF, dmabc->TCD->ATTR, dmabc->TCD->NBYTES, dmabc->TCD->SLAST, (uint32_t)dmabc->TCD->DADDR, dmabc->TCD->DOFF, dmabc->TCD->CITER, dmabc->TCD->DLASTSGA, dmabc->TCD->CSR, dmabc->TCD->BITER); }
I wonder what would that translate to 8)
I just installed TD 1.54B2 and I was going through some sketches using USBHost_t36 and found that "#define USBHOST_PRINT_DEBUG" was uncommented.
So far all of everything is working well
PRIxN -> x is the usual u, d, x, X etc N is the width of the variable.Sorry I am old dog who has not learned the new trick yet
What does that mean? Yes I can and will google it,
E.g.
PRIu16 will print a 16bit unsigned
PRId64 will print a 64bit signed
PRIX32 will print a 32bit hex number with uppercase letters
...
Advantage: doesn't rely on the platform dependent width of int, unsigned etc.
Disadvantage: a pain to type
I think I'll stick with lu, lx etc...
Edit: They and a lot more of them are defined in 'inttypes.h'
@luni - Thanks, Yep I think I will too stick with the easy way... With the more typing version wonder if one an do things like:
printf("Var: %08xl", my_var);
Would it be something like: printf("Var: %08"PRIu32"\n", u32x);
Again I could try but for now...
Thanks again!
Nearly :-). You also need to add spaces:
Prints:Code:void setup() { while(!Serial){} uint32_t test = 42; Serial.printf("Var: %08" PRIu32 "\n", test); } void loop(){}
Without the spaces I get a warning:Code:Var: 00000042
I'm sure this syntax was invented to scare users away from printf :-)Code:src/main.cpp:8:19: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] Serial.printf("Var: %08"PRIu32"\n", test);
More tests with the PRIs
Prints:Code:void setup() { while(!Serial){} Serial.println("int64_t"); int64_t test0 = -2; Serial.printf("PRIi64: %" PRIi64" \n", test0); Serial.printf("PRIu64: %" PRIu64" \n", test0); Serial.printf("PRIX64: %" PRIX64" \n", test0); Serial.println("\nint32_t"); int32_t test1 = -2; Serial.printf("PRIi32: %" PRIi32" \n", test1); Serial.printf("PRIu32: %" PRIu32" \n", test1); Serial.printf("PRIX32: %" PRIX32" \n", test1); Serial.println("\nint16_t"); int16_t test2 = -2; Serial.printf("PRIi16: %" PRIi16" \n", test2); Serial.printf("PRIi16: %" PRIu16" \n", test2); Serial.printf("PRIX16: %" PRIX16" \n", test2); Serial.println("\nint8_t"); int8_t test3 = -2; Serial.printf("PRIi8: %" PRIi8" \n", test3); Serial.printf("PRIu8: %" PRIu8" \n", test3); Serial.printf("PRIX8: %" PRIX8" \n", test3); } void loop(){}
Looks like the 8bit variants are not working as advertised?Code:int64_t PRIi64: -2 PRIu64: 18446744073709551614 PRIX64: FFFFFFFFFFFFFFFE int32_t PRIi32: -2 PRIu32: 4294967294 PRIX32: FFFFFFFE int16_t PRIi16: -2 PRIi16: 65534 PRIX16: FFFE int8_t PRIi8: -2 PRIu8: 65534 PRIX8: FFFE
@luni - thanks for the lesson. Learning something new now. Never realized those things were defined in inttypes.h. I have seen something similar in some .h files though.
EDIT: did a google search on the PRIX8 issue and came across this post first thing: https://stackoverflow.com/questions/...any-characters
Using that format for 8 bit variants gets you:A int8_t will go through the usual integer promotions as a parameter to a variadic function like printf(). This typically means the int8_t is converted to int.
Yet "%X" is meant for unsigned arguments. So covert to some unsigned type first and use a matching format specifier:
For uint8_t, use PRIX8. With exact width types, include <inttypes.h> for the matching specifiers.
#include <inttypes.h>
printf(" int negative var is <%02" PRIX8 ">\n", iNegVar);`
With int8_t iNegVar = -1;, convert to some unsigned type before printing in hex
printf(" int negative var is <%02" PRIX8 ">\n", (uint8_t) iNegVar);`
Code:int64_t PRIi64: -2 PRIu64: 18446744073709551614 PRIX64: FFFFFFFFFFFFFFFE int32_t PRIi32: -2 PRIu32: 4294967294 PRIX32: FFFFFFFE int16_t PRIi16: -2 PRIi16: 65534 PRIX16: FFFE int8_t PRIi8: -2 PRIu8: 65534 PRIX8: FFFE int negative var is <FE>
Last edited by mjs513; 10-24-2020 at 04:47 PM. Reason: Additional info
I've never heard of this syntax either.
This thread.
https://forum.pjrc.com/threads/62473...ments-checking
So far I've used it only for 64bit variables where this is the only way (I know of) to 'printf' them.I've never heard of this syntax either.
@mjs513: funny how complicated a simple thing like printing an 8bit variable can get :-).
IMHO, most of the code written here is tightly coupled to the used processor anyway. So, using all this complicated syntax just to get platform independent printfs for platform dependent code seems a bit, say, overengineered to me.
I like the new printf warnings but I personally think fixing it by lu, lx etc. should be good enough in most cases.
Was just playing with the different types and added results to my previous posts. Looking at inttypes.h appears there are a few more variants for PRIxxxx usage as well:
Which i think is defined as:
- Least-width integer types that are guaranteed to be the smallest type available in the implementation, that has at least specified number n of bits. Guaranteed to be specified for at least N=8,16,32,64.
- Fastest integer types that are guaranteed to be the fastest integer type available in the implementation, that has at least specified number n of bits. Guaranteed to be specified for at least N=8,16,32,64.
---https://en.wikipedia.org/wiki/C_data_types#inttypes.h
I agree with you on how something simple can get overly complicated. Always subscribed to the KISS principal
I've made a pull request here for some more SPI transfer functions for the Teensy 4.x. These can offer a significant speed improvement when you are sending large buffers such as pixel data for displays, is there any chance this can make it into a beta for testing?
Has anyone looked at the new map() function yet?
Several issues were reported on these 2 threads:
https://forum.pjrc.com/threads/63230...uino-vs-teensy
https://forum.pjrc.com/threads/44503...l=1#post241232
There is also quite a bit about map() problems on Arduino's issue trackers. Here's a message where Cristian Maglie (then Arduino's lead developer) compared 3 implementations and concluded "there isn't still a good solution".
https://github.com/arduino/ArduinoCo...mment-69585614
My hope is we'll finally have that "good solution" in Teensy, where the results are correct at the extremes of the mapped range and the numbers are fairly distributed throughout the range, and no weird non-linearity exists if you extrapolate beyond the mapped range (within numerical range of 32 bit long, of course).
I will admit, the new implementation is probably slower. How much I don't know. Also unknown is whether just using 32 bit float on Teensy 3.5 & 3.5 and maybe 64 bit double on Teensy 4.x would be faster than such a complicated integer-only approach?
I'm not eager to extend the SPI library public API this way, so as written, no, probably not.
But I would be happy to merge this if it didn't change the public API. Maybe some trickery with inline methods and possibly __builtin_const_p could let these be private functions that get automatically used when the inputs are conducive?
I have a PR pending on adding a function to DMAChannel.h to allow ISR to be executed at specific interrupt level.
Was looking that over this morning and planned on testing. That cmaglie sketch helps. I changed it to read:
with the results:Code:// This is the original map() function in Arduino Core long map1(long x, long in_min, long in_max, long out_min, long out_max) { return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min; } // This is the same but with the +1 "range extrension" as suggested by st42 long mapPlus1(long x, long in_min, long in_max, long out_min, long out_max) { return (x - in_min) * (out_max - out_min + 1) / (in_max - in_min + 1) + out_min; } // This is another version of map with rounding done only with integer calculations // as suggested by M.Kooijman long mapRound(long x, long in_min, long in_max, long out_min, long out_max) { return ((x - in_min) * (out_max - out_min) + (in_max - in_min)/2) / (in_max - in_min) + out_min; } void setup(void) { Serial.begin(115200); delay(2000); long x; Serial.printf("Range 0-20 to 0-4\n"); Serial.printf(" x map map1 map(+1) map(round)\n"); for (x=-10; x<=30; x++) { Serial.printf("%6ld %6ld %6ld %6ld %6ld\n", x, map(x, 0, 20, 0, 4), map1(x, 0, 20, 0, 4), mapPlus1(x, 0, 20, 0, 4), mapRound(x, 0, 20, 0, 4)); } Serial.printf("\n\n"); Serial.printf("Range 0-5 to 0-1023\n"); Serial.printf(" x map map1 map(+1) map(round)\n"); for (x=-5; x<=10; x++) { Serial.printf("%6ld %6ld %6ld %6ld %6ld\n", x, map(x, 0, 5, 0, 1023), map1(x, 0, 5, 0, 1023), mapPlus1(x, 0, 5, 0, 1023), mapRound(x, 0, 5, 0, 1023)); } } void loop() {}
Now have to figure the output out and reread the rest of the issue.Code:Range 0-20 to 0-4 x map map1 map(+1) map(round) -10 -2 -2 -2 -1 -9 -2 -1 -2 -1 -8 -2 -1 -1 -1 -7 -1 -1 -1 0 -6 -1 -1 -1 0 -5 -1 -1 -1 0 -4 -1 0 0 0 -3 -1 0 0 0 -2 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 2 0 0 0 0 3 1 0 0 1 4 1 0 0 1 5 1 1 1 1 6 1 1 1 1 7 1 1 1 1 8 2 1 1 2 9 2 1 2 2 10 2 2 2 2 11 2 2 2 2 12 2 2 2 2 13 3 2 3 3 14 3 2 3 3 15 3 3 3 3 16 3 3 3 3 17 3 3 4 3 18 4 3 4 4 19 4 3 4 4 20 4 4 4 4 21 4 4 5 4 22 4 4 5 4 23 5 4 5 5 24 5 4 5 5 25 5 5 5 5 26 5 5 6 5 27 5 5 6 5 28 6 5 6 6 29 6 5 6 6 30 6 6 7 6 Range 0-5 to 0-1023 x map map1 map(+1) map(round) -5 -1023 -1023 -853 -1022 -4 -819 -818 -682 -818 -3 -614 -613 -512 -613 -2 -409 -409 -341 -408 -1 -205 -204 -170 -204 0 0 0 0 0 1 205 204 170 205 2 409 409 341 409 3 614 613 512 614 4 818 818 682 818 5 1023 1023 853 1023 6 1228 1227 1024 1228 7 1432 1432 1194 1432 8 1637 1636 1365 1637 9 1841 1841 1536 1841 10 2046 2046 1706 2046
I should have mentioned, another property some people are expecting is identical result for "reverse" mapping.
In other words, ideally these should give the same result for all inputs:
map(x, 0, 5, 0, 1023);
map(x, 5, 0, 1023, 0);
And these 2 should give the same result as the 2 above, but "reversed"
map(x, 0, 5, 1023, 0);
map(x, 5, 0, 0, 1023);
Of course Arduino's map() doesn't do any of this, and I do not believe any of the proposed map() functions on their issue trackers do either, especially when considering extrapolating beyond the mapped range.
Posting Permissions
