Teensy 4.0 First Beta Test

Status
Not open for further replies.
I installed Beta7...

As for mappings for which Uart and pins for Serial ports:
Here are some comments I put in one of my test programs:
//UART6 Serial1 [0/1] UART4 Serial2 [6/7] UART2 Serial3 [15/14] UART3 Serial4 [16/17]
//UART8 Serial5 [21/20] UART1 Serial6 [25/24] UART7 Serial7 [28/29] UART5 Serial8 [30/31]

I have not tested the higher Serial ports yet, as I have not wired up anything to the bottom pads yet...

With the Sparkfun_Teensyview library - I reverted to master branch (current sparkfun code), which does not do anything fancy. i.e. uses digitalWrite to set the CS/DC pins.
Again their Screendemo program does not link as it relies on using String object, and it looks like we are not link scripts does not appear to include this yet...

Can work around this, by changing their printTitle function and pass in const char * instead of string. The It uses the print method from print.cpp so this compiles in. Need to change one reference to .length of the string and instead use strlen()...

Once I make those changes, still does not link as library calls setMOSI and setSCK which looks like may not exist yet in SPI library...

Once this is working, may then convert back over to my own version and/or my own SSD1306 library... Maybe should make one of them ssd1306_t3 ...
My version is/was using the buffer writes as well as the non-blocking transfers in the SPI library which would be good to test ...
 
//UART6 Serial1 [0/1] UART4 Serial2 [6/7] UART2 Serial3 [15/14] UART3 Serial4 [16/17]
//UART8 Serial5 [21/20] UART1 Serial6 [25/24] UART7 Serial7 [28/29] UART5 Serial8 [30/31]
Thank you. Was getting confused on that myself.

On another note I converted that tempmonitoring sketch I had into one .c file so it could be incorporated into startup.c. I actually tried it and looked like it was working as it picked up some errors, which I fixed, but still gives me a few warnings only. I did try to get the temperature by calling tGetTemp() but the sketch came back with an error about it not being declared. Ok, what am I missing - do I need to add something somewhere like in imxrt.h?

EDIT: Ok, found it goings into core_pins.h. Gave it a try and it keeps resetting? Strange have to do a double check on conversion.
 
Last edited:

Nice! Fix for Wire - will make T_3.x compare testing work :) … WireKinetis.cpp and .h - I wondered where such a break would be hiding.

KurtE - format of Serial ports list looks familiar ? :) - I see it posted on the pin Msg.
> 4 sketch Serial ports active overnight no problem [plus 5th as Debug printf], two manually transferred crossed/loopback, and two running on 'EventResponder'

Mike - Nice you got Talkie cleaned up! Seems the things I noted helped. How are you doing audio/speakers without Prop Shield? Glad the LedControl units works for you! I saw that and hoped it would be a nice T4 thing that would work.
>> for that 8 digit display make sure you give it a stable GND and 3v VCC - I saw was stealing power in some odd way from other pins - the one time seemed to shut T4 down. I pulled VCC to disconnect and it would still light up.

TD 1.47 Beta7 installed no problem.

yield() not yet in Arduino loop() - so in sketch loop() to feed the Serial Events code.

<edit>: Sketch still halts when it uses USB Serial and no SerMon connected. Though the Serial test seems to work again to prevent that:
Code:
    if ( Serial ) Serial.println( "123456 @" );
    else Serial4.println( ii++ );
 
Last edited:
Mike - Nice you got Talkie cleaned up! Seems the things I noted helped. How are you doing audio/speakers without Prop Shield? Glad the LedControl units works for you! I saw that and hoped it would be a nice T4 thing that would work.
Just attached a small 8 ohm speaker that I pulled out of an old computer. Not much volume but audible. Didn't have a breadboard jack to plug in a amplified speaker. Yeah, never played with before and looked like something fun to play with.
 
Just attached a small 8 ohm speaker that I pulled out of an old computer. Not much volume but audible. Didn't have a breadboard jack to plug in a amplified speaker. Yeah, never played with before and looked like something fun to play with.

I'll try that then. Glad I let you hit the code first to enjoy :), it was fun to play with putting that Que code - Paul did the Porting and it was crazy to have it block the Teensy - it was on my list to go fix. FrankB did the DAC# edit for T_3.5/3.6. If only there was a way to encode new words.
 
Teensyview - I have the hacked up version of their graphictest that does not use String class as I mentioned in other posts. And it is working now...

I updated SPI library to have quick and dirty versions of the pinIsMISO and setMOSI, Put some of the data into the hardware definitions for these pins. Note Begin is still hard coded, will change that next

Also wondering about creating SPI1, but looks like I need to solder some wires to bottom pads to get these to work, also to test other Serial ports...

Anyway PR: https://github.com/PaulStoffregen/SPI/pull/38
Can grab now if you are wanting another release Or you can wait until I flesh out more of this...

EDIT: Probably wait to pull in PR... Looks like SPI needs lots of work.
 
Last edited:
I'll try that then. Glad I let you hit the code first to enjoy ,
Yeah it was fun getting it working and then once I used writefrequency it worked right away. Its fun getting things working especially when you can figure it out - wouldn't dream of touching things like spi, i2c, or sd and eeprom. Probably would break something.
 
I'll try that then. Glad I let you hit the code first to enjoy :), it was fun to play with putting that Que code - Paul did the Porting and it was crazy to have it block the Teensy - it was on my list to go fix. FrankB did the DAC# edit for T_3.5/3.6. If only there was a way to encode new words.

Unlimited words ;) there was also a crude text-to-speech lib (TTS), which was ported to T3 DACs from PWM.
https://forum.pjrc.com/threads/44587-TTS-(Text-to-Speech)-Library-Port
 
Unlimited words ;) there was also a crude text-to-speech lib (TTS), which was ported to T3 DACs from PWM.
https://forum.pjrc.com/threads/44587-TTS-(Text-to-Speech)-Library-Port

Hope everyone is sitting down - I missed commenting on a thread :) Interesting there are alternatives though that one didn't get as much attention as Talkie. Was hoping it was a way to create added encoding for Talkie.

Funny note there about 'volume is good enough to annoy my wife' … I had that issue here with Talkie as I wrote the Que code … it had to be tested and refined and not just with one sound - but partial and full and overfull que and killing the que … and billions of repetitions of Tom's Diner. <edit> - just looked Que array is 24 entries.

Yeah it was fun getting it working and then once I used writefrequency it worked right away. Its fun getting things working especially when you can figure it out - wouldn't dream of touching things like spi, i2c, or sd and eeprom. Probably would break something.

That comment in the code was a good clue on the freq - I hoped that would clean up the sound you heard. The .begin should be <Added> to pass in a pin with default to AVR==3, and T_3.x's==DAC. Then a whole new generation of T4's can move it to any pin. In fact T3.x might do well to have PWM pin choice if it gives better volume - or doesn't require an AMP. <edit> It could also then work on T_3.0 with PWM.

I'll hopefully get to test in in coming days. I pulled the ZIP down but have a couple other things to do … and my wife's weekend is Sun/Mon so I don't want to trigger her 'Prior Talkie Stress Distress' while she can hear it :)

Kurt: I have my TeensyView here on a micro breadboard - with 7! wires … I'll get the dust off of that soon.
 
That comment in the code was a good clue on the freq - I hoped that would clean up the sound you heard. The .begin should be <Added> to pass in a pin with default to AVR==3, and T_3.x's==DAC. Then a whole new generation of T4's can move it to any pin. In fact T3.x might do well to have PWM pin choice if it gives better volume - or doesn't require an AMP. <edit> It could also then work on T_3.0 with PWM.
I actually started working on a couple of things with the lib including best way to define alternate pins to use besides pin3. Not terrible but wasn't sure how far you all wanted to depart from the existing lib at this point. Done easily enough but would require some mods over and above whats necessary for the T4 effort.?

PS. You realize of course I will probably wind up doing it after I get tired of flexcan :)

Unlimited words there was also a crude text-to-speech lib (TTS), which was ported to T3 DACs from PWM.
https://forum.pjrc.com/threads/44587...)-Library-Port
You know, bringing back memories when I read back on what I wrote. Don't think I pursued anything with TALKIE or TTS because I went over to using the EMIC2 board. Funny how things old become new again.
 
Tested some linker-related things, because I was wondering where the values from the size-tool come from.
I wrote a sketch that displays some useful info for our tests:

Output looks like this:

Code:
Addresses:
Text: 0x00000000
Data: 0x20000000
BSS : 0x20002000
DMA : 0x20200000
Heap: 0x20200000

Lengths:
Flashimage   : 31344
Progmem      : 5648
Text(ITCM)   : 21152
DMAMEM(OCRAM): 0
Heap(OCRAM)  : 262144
DTCM         : 17088

Code:
Code:
// from the linker
extern unsigned long _stextload;
extern unsigned long _stext;
extern unsigned long _etext;
extern unsigned long _sdataload;
extern unsigned long _sdata;
extern unsigned long _edata;
extern unsigned long _sbss;
extern unsigned long _ebss;
extern unsigned long _heap_start;
extern unsigned long _heap_end;
extern unsigned long _flashimagelen;

/*
  add these lines to imxrt.ld ( after _teensy_model_identifier = 0x23; ) :
[COLOR=#ff0000]
  _progmemlen = SIZEOF(.text.progmem);
  _dmamemlen = SIZEOF(.bss.dma);
  _sdma = ADDR(.bss.dma);[/COLOR]

*/

extern unsigned long _dmamemlen;
extern unsigned long _sdma;
extern unsigned long _progmemlen;
extern unsigned long _heaplen;

PROGMEM void meminfo() {

  Serial.printf("Addresses:\n");
  Serial.printf("Text: 0x%08x\n", &_stext);
  Serial.printf("Data: 0x%08x\n", &_sdata);
  Serial.printf("BSS : 0x%08x\n", &_sbss );
  Serial.printf("DMA : 0x%08x\n", &_sdma );
  Serial.printf("Heap: 0x%08x\n", &_heap_start );
  Serial.println();

  Serial.printf("Lengths:\n");
  Serial.printf("Flashimage   : %d\n", (uint32_t)&_flashimagelen );
  Serial.printf("Progmem      : %d\n", (uint32_t)&_progmemlen );
  Serial.printf("Text(ITCM)   : %d\n", (uint32_t)&_etext - (uint32_t)&_stext);
  Serial.printf("DMAMEM(OCRAM): %d\n", (uint32_t)&_dmamemlen );
  Serial.printf("Heap(OCRAM)  : %d\n", (uint32_t)&_heap_end - (uint32_t)&_heap_start );
  Serial.printf("DTCM         : %d\n", (uint32_t)&_ebss - (uint32_t)&_sdata);
}
void setup() {
  delay(800);
  meminfo();
}

void loop() {}

You may want to add the red lines to the imxrt.ld

Well, I still don't know what the size-tool displays :)
And, how much is used from ITCM?


Edit: Found it - updated the program.
 
Last edited:
I actually started working on a couple of things with the lib including best way to define alternate pins to use besides pin3. Not terrible but wasn't sure how far you all wanted to depart from the existing lib at this point. Done easily enough but would require some mods over and above whats necessary for the T4 effort.?

PS. You realize of course I will probably wind up doing it after I get tired of flexcan :)

Enjoy FlexScan! Up to Paul about the extent of Talkie mods - but it seemed to generate good Teensy interest. Audio output is a fun new way to get feedback after a blinking LED, which is what I found [myself and LOTS of interest at the time - seems that was when Beta testing the Prop Shield] and didn't like that it was a blocking call. If you put your Talkie code on github.com... WIP maybe I'll see about adding the optional Pin_# ( like I did for IRQ on Touch_ILI9341 ) if I get to it before you we'll see. I have a T_3.0 too since I got one as they were unstocking them. Maybe I'll use your Temp code to trigger voice alerts :)
 
Up to Paul about the extent of Talkie mods - but it seemed to generate good Teensy interest. Audio output is a fun new way to get feedback after a blinking LED, which is what I found [myself and LOTS of interest at the time
Took care of it all with adding a begin call:
Code:
voice.begin(PWM PIN, PROPSHIELD FLAG
PWM PIN = any pwm pin (tested 8 and 9) and propshield flag on whether one is attached or not (true or false). This way if you don't have a propshield you can use any Teensy with a pwm pin :) If you want to play its up on my WIP page. Told you I was going to wind up doing it.
 
As I mentioned in previous post, doing some more hacking on the SPI library.

Things like, trying to remove the hard coded register usages as to allow us to define SPI1...

To help with this, I edited the imxrt.h file to create an LPSPI structure:
Code:
typedef struct {
        const uint32_t VERID;           // 0
        const uint32_t PARAM;           // 0x04
        const uint32_t UNUSED0;         // 0x08
        const uint32_t UNUSED1;         // 0x0c
        volatile uint32_t CR;           // 0x10
        volatile uint32_t SR;           // 0x14
        volatile uint32_t IER;          // 0x18
        volatile uint32_t DER;          // 0x1c
        volatile uint32_t CFGR0;        // 0x20
        volatile uint32_t CFGR1;        // 0x24
        const uint32_t UNUSED3;         // 0x28
        const uint32_t UNUSED4;         // 0x2c
        volatile uint32_t DMR0;         // 0x30
        volatile uint32_t DMR1;         // 0x34
        const uint32_t UNUSED5;         // 0x38
        const uint32_t UNUSED6;         // 0x3c
        volatile uint32_t CCR;          // 0x40
        const uint32_t UNUSED7;         // 0x44
        const uint32_t UNUSED8;         // 0x48
        const uint32_t UNUSED9;         // 0x4c
        const uint32_t UNUSED10;        // 0x50
        const uint32_t UNUSED11;        // 0x54
        volatile uint32_t FCR;          // 0x58
        volatile uint32_t FSR;          // 0x5C
        volatile uint32_t TCR;          // 0x60
        volatile uint32_t TDR;          // 0x64
        const uint32_t UNUSED12;        // 0x68
        const uint32_t UNUSED13;        // 0x6c
        volatile uint32_t RSR;          // 0x70
        volatile uint32_t RDR;          // 0x74
} IMXRT_LPSPI_t;
Also setup pointers to it for each of the hardware SPI objects.

I did a PR to core to pull in. Note: I did not update all of the previous defines to use the structure, like:
Code:
#define IMXRT_LPSPI4		(*(IMXRT_REGISTER32_t *)0x403A0000)
#define LPSPI4_VERID			(IMXRT_LPSPI4.offset000)
#define LPSPI4_PARAM			(IMXRT_LPSPI4.offset004)
#define LPSPI4_CR			(IMXRT_LPSPI4.offset010)
#define LPSPI4_SR			(IMXRT_LPSPI4.offset014)

But just added new defines like:
Code:
#define IMXRT_LPSPI4_S          (*(IMXRT_LPSPI_t *)0x403A0000)

I now pass in this pointer into the constructor for the SPI object, which gets set into port variable, which I updated the references like:
LPSPI4_CR to instead be port->CR.

So far my Teensyview test app is still running with these changes. Next I need to update the ::begin code to use the stuff in the hardware structure to intialize stuff instead of hard coded registers.
 
Ok, found the problem with ITCM-len and heaplen in Post 586

Here's results in a sketch:
Addresses:
Text: 0x00000000
Data: 0x20000000
BSS : 0x20002000
DMA : 0x20200000
Heap: 0x20200000

Lengths:
Flashimage : 34384
Progmem : 5648
Text(ITCM) : 23328
DMAMEM(OCMEM): 0
Heap(OCMEM) : 262144
DTCM : 17088

and a second:
Lengths:
Flashimage : 37680
Progmem : 5776
Text(ITCM) : 26096
DMAMEM(OCMEM): 0
Heap(OCMEM) : 262144
DTCM : 17088

And the IDE shows:
Sketch uses 31904 bytes (2%) of program storage space. Maximum is 1572864 bytes.
Global variables use 14704 bytes (5%) of dynamic memory, leaving 247440 bytes for local variables. Maximum is 262144 bytes.
 
Last edited:
Ok, I found the reason for the wrong numbers which are printed by the builder:

To fix the program size, replace:
Code:
#recipe.size.regex=^(?:\.text|\.data|\.bootloader)\s+([0-9]+).*
recipe.size.regex=^(?:\.text|\.data|\.text.progmem|\.bootloader)\s+([0-9]+).*
in platform.txt

For the variables, there is no easy fix. The printed number is too small.
Code:
...
20000804 00000004 D F_CPU_ACTUAL
20000808 00000428 d impure_data
20000c30 00000004 D _impure_ptr
20000c34 00000408 D __malloc_av_
2000103c 00000004 D __malloc_trim_threshold
20001040 00000004 D __malloc_sbrk_base
20001044 0000016c D __global_locale
[COLOR=#ff0000]200011b0 D _edata
20002000 B _sbss[/COLOR]
20002000 b completed.8605
20002004 b object.8610
2000201c 00000004 b prev_usec.5373
20002020 00000004 B systick_millis_count
20002024 00000004 b endpoint0_notify_mask
20002028 00000001 b usb_reboot_timer
20002030 00000008 b endpoint0_setupdata
20002038 00000008 b endpoint0_buffer
20002040 00000001 B usb_configuration
20002044 00000400 b txbuffer
20002460 00000020 b transfer
20002480 00000001 B usb_cdc_line_rtsdtr
20002481 00000001 b yield::running
...

Between the red marked lines, there is a gap, I think due to aligment. I have not found the reason for the alignment so far. Maybe intended, maybe a bug. The gap is very big, 3664 bytes. So, the number displayed by the compiler is 3664 bytes too small in this program.

Paul: It would be nice if the used PROGMEM, ITCM and DMAMEM could be displayed too, after compiling - is this possible?

EDIT:
Found the reason:
There is something missing in the linkerfile:
Please use
Code:
    .bss [COLOR=#ff0000]ALIGN(32) [/COLOR]: {        
        *(.bss*)
        *(COMMON)
to fix the unneeded gap - not sure about (32) - perhaps 2 or 4 or 16 works, too. Too late to test this now. Good night.
 
Last edited:
I have not tested the higher Serial ports yet, as I have not wired up anything to the bottom pads yet...

Oh, I have some hardware here that can help you. Will solder up a board and get it to you later this week.
 
Last edited:
Oh, I have some hardware here that can help you. Will board up a board and get it to you later this week.

I have a bent pin header here that fits - looked at soldering that on - then lifting with sockets to the breadboard - those pads are just big enough to see around the pins.

Frank - I updated my post 592 above with current IDE numbers for the second set - with go patch build file and update again … soon.

<EDIT> Frank - I put that in [T:\arduino-1.8.8T4_146\hardware\teensy\avr\platform.txt] and it messed up the output? Dropped a line and math was wrong?
"T:\\arduino-1.8.8T4_146\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_924998/SerailEvent23.ino.elf"
Sketch uses 0 bytes (0%) of program storage space. Maximum is 1572864 bytes.
T:\arduino-1.8.8T4_146\hardware\teensy/../tools/teensy_post_compile -file=SerailEvent23.ino -path=T:\TEMP\arduino_build_924998 -tools=T:\arduino-1.8.8T4_146\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/2/3 -portlabel=hid#vid_16c0&pid_0478 (Teensy 4-Beta) Bootloader -portprotocol=Teensy

Versus:
"T:\\arduino-1.8.8T4_146\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_924998/SerailEvent23.ino.elf"
Sketch uses 28736 bytes (1%) of program storage space. Maximum is 1572864 bytes.
Global variables use 14304 bytes (5%) of dynamic memory, leaving 247840 bytes for local variables. Maximum is 262144 bytes.
T:\arduino-1.8.8T4_146\hardware\teensy/../tools/teensy_post_compile -file=SerailEvent23.ino -path=T:\TEMP\arduino_build_924998 -tools=T:\arduino-1.8.8T4_146\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/2/3 -portlabel=hid#vid_16c0&pid_0478 (Teensy 4-Beta) Bootloader -portprotocol=Teensy
 
Something got corrupted in your platform.txt, Tim. I'll post the whole file tomorrow - I'm not at the computer and going to sleep :) Have to work tomorrow. Will do a pull request for the linker file too.
 
Something got corrupted in your platform.txt, Tim. I'll post the whole file tomorrow - I'm not at the computer and going to sleep :) Have to work tomorrow.

Okay, it works after removing the change - goes back to what is shown. Maybe the edit doesn't copy from forum to the file right. Will look for file as you can post.
 
Oh, I have some hardware here that can help you. Will board up a board and get it to you later this week.
Thanks that would be helpful especially if I also try to setup for SPI1 to work as well...

Note: in my current SPI PR I have done a second PR with decoupling most of the SPI code from being LPSPI4 specific... Will figure out the rest soon.

But may first have some fun and re-implement the SPI.transfer(buf, txbuf, cnt) to actually fill up the FIFO.
 
IRrecv Lib
Got my receiver a little while ago, hooked it up and ran the demo sketch - picked up my old Samsung remote as well the FiosTV remote. Another lib off the list.

Just got mine - it works with TV remote - connected to open pin #9 with Demo.
 
Thanks that would be helpful especially if I also try to setup for SPI1 to work as well...

It's going into today's mail. :)

Most of this board is untested, but it does bring the 8 serial ports to 6 pin headers (just GND, TX, RX - other 3 pins are no connect). I checked all the TX & RX pins quickly by uploading the LED blink 16 times, once for each digital pin.

I have parts to build 4 more of these. Anyone else want one?
 
Status
Not open for further replies.
Back
Top