Teensy 4.0 First Beta Test

Status
Not open for further replies.
@KurtE
Since I spent the day shoveling ice/snow

Well, something broke good in it. Can't use any wired devices with the new version. Tried Joystick (PS4 or PS3) only and then keyboard/mouse but both hung the T4 to the point where I had to use the pgm button to load the next sketch. Tough to isolate the problem area. With the keyboard mouse on the hub it just looses USB connection to the PC from the start.


EDIT: Kurt - maybe we should start another thread just for USB BT - and use this thread just for T4 specific issues? Don't know what do you think.

Maybe move to the thread I opened awhile ago to talk about usb host and Bluetooth: https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth

Obviously we need to put any T4 specific comments up on this thread.

Will also continue to do some stuff with BT stuff as well... My new PS4 controller almost made it into our Mailbox... It appears like they were closed probably due to snow... We had maybe 6-9 inches over the last day or so... So we did not get out today... Maybe tomorrow...
 
I tried to add something like the filename without path or $random to the compiler-switches (defines) - so far not successful. I don't have any more ideas to make PROGMEM work with both, data & code in the same file. I've proposed a solution with COUNTER which is better than nothing - at least it suppresses the gcc errormessage. Worst case is, the linker does not remove unused code or data.
So we may need some ideas here - or just stay with the gcc bug and explain this to users every 5 days (would be easier with a FAQ). Nobody but me seems to see a problem here, at least not in this threat, so perhaps just ignoring this issue seems to be the best solution? Don't know.
Running all from flash or just use it as a file storage can't be a solution and does not solve any problem.. dunno for what this should help?
 
Last edited:
I need to fix my temporary solution for audio - just removed DMAMEM from all outputs. I need to know if DMAMEM stays as it is - for audio, I dont see a problem (all perfect linear accesses), just need to know it. So.. will it be "write back"?

Edit: It takes 1130 cycles to flush a half SPDIF-Buffer - I expected more :eek:
 
Last edited:
@MichaelMeissner: Is it possible to make a linker script that automatically assignes variables to ITCM when DTCM is full?

Edit: Can we use the Gold linker? It's faster - tried it with a few programs and seems to work.
 
Last edited:
Maybe move to the thread I opened awhile ago to talk about usb host and Bluetooth: https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth

Obviously we need to put any T4 specific comments up on this thread.

Will also continue to do some stuff with BT stuff as well... My new PS4 controller almost made it into our Mailbox... It appears like they were closed probably due to snow... We had maybe 6-9 inches over the last day or so... So we did not get out today... Maybe tomorrow...

Morning Kurt
Ok you beat me with the snow - only had a couple of inches of snow but then with the freezing rain and sleet - felt like a lot more.

Anyway, agree lets use your reference Bluetooth thread unless its T4 specific issue. Like I said I got my PS3 mouse - haven't tested it yet in BT mode, but just for reference, I got it all put back together so BT and wired worked.
 
I am not an expert here, but my 3 cent guess is that this display does not do what we would typically think of a normal SPI conversation...
Instead I am thinking that there is 3 shift registers connected to each other, so you end up sending a 24 bits of data, probably 18 bits of color, plus maybe the D/C signal encoded on it it as well... But again just guessing.

Think you are right - there are three shift registers on the back of the display as you can see from the schematic. Was also poking around this repository (https://github.com/loboris/ESP32_SPI_MASTER_NODMA_EXAMPLE) and that is about what it is doing. Have to wait now for the new displays to get here.
 
@MichaelMeissner: Is it possible to make a linker script that automatically assignes variables to ITCM when DTCM is full?

Edit: Can we use the Gold linker? It's faster - tried it with a few programs and seems to work.

Its been many years since I last edited linker scripts. I imagine it might be possible, but you would need to iterate over the documentation. Also note that gold may/may not support the same linker scripts as the GNU linker:
 
USBHost - Follow up

My Logitech K400+ arrived and it worked fine with the Mouse example program. This included both the keyboard and the touchpad.

The PS4 controller is probably at mailbox, but was not out yet in my box when I made it to town... Probably fine as had to leave car at bottom of hill and walk half mile to house, due to ice on road... Hopefully it will melt soon...
 
Its been many years since I last edited linker scripts. I imagine it might be possible, but you would need to iterate over the documentation. Also note that gold may/may not support the same linker scripts as the GNU linker:

In the meantime I have read that the gnu-linker cannot do this.
I don't know if "gold" can do it.
I have found a linker that is compatible, and can do that: https://blog.segger.com/the-segger-linker-replacing-the-gnu-linker/
I haven't found anything on the license yet. Maybe we can use it? It is more optimized for embedded development.

edit:mad:others: Now, you can add "FASTRUN" ;-) to variables or large arrays to do that manually if you are short on DTCM ..
 
Hi Frank
The only thing that I saw at the end of the link you posted was "Obviously, the SEGGER Linker will be free for non-commercial use just like all of Embedded Studio." It may follow the same licensing as for Embedded studio. Question I would have is compatible to Arduino IDE and other potential compatibility issues? Just a thought.

Did find this reference manual: https://studio.segger.com/segger/UM20005_Linker.pdf
 
My internet seems to be back reliably after a few days a couple days at modem (4-64Kbps) speeds when it worked at all.

KurtE tried the Tset wrapper for FrankB's compile.cmd - under windows [w/SublimeText] and TyCommander and found it to work on his T4 - I updated the Readme. I did a second TD_1.46b9 install and noted the only changes needed to boards.txt there on github - a single char change to keep the build in sync with the board name [a '4b' not '40'], and adding a minimal menu.speed even if no added value but keeping the params in order.

Would like to say the Red T4 Bootloader LED is nice to know when the T4 is in the offline state - nicely visible but not annoyingly flashy or bright! One attempt to get boards.txt right for the above made the compiler spew about F_CPU not being right - it would be nice perhaps to have that passed in and #define'd as the initial T4 speed - and add a speed menu that was respected and established during startup … perhaps there is a good reason for that I missed?
 
SERIAL.AVAILABLE/SERIAL.READ Question

Are these functions working on the T4. I have been trying to use them to read keyboard input from the sermon in the Arduino IDE and they don't seem to be functioning.
 
SERIAL.AVAILABLE/SERIAL.READ Question

Are these functions working on the T4. I have been trying to use them to read keyboard input from the sermon in the Arduino IDE and they don't seem to be functioning.

I have had no luck getting Serial input on the USB on the T4... Typically it has just killed any program I have tried to run... Which is why at times I have converted the code over to run on Serial1 or Serial4, such that I can get input...
 
I have had no luck getting Serial input on the USB on the T4... Typically it has just killed any program I have tried to run... Which is why at times I have converted the code over to run on Serial1 or Serial4, such that I can get input...

Oh boy. I looked in hardwareserial and available/read are there but Serial.available always returns 0. Put in a couple prints into "available" and head/tail are always zero. Is that right?

EDIT: or is this a USB issue? Just a question

EDIT2: Strange. I put prints in "available" in hardware.cpp is this the right place to do this - think so? or should it be associated with usb_serial.c? If its usb_serial those all have "#if 0" in those functions. Don't know, help
 
Last edited:
Mike didn't those #if 0's come up the other week? Proper/complete USB stack is 'on the way' from Paul.
01-25-2019, 07:27 PM
defragster replied to a thread Teensy 4.0 First Beta Test in General Discussion
Mike - I suspect if you look at the T3 tree you'll see the #ifdef's where the extra USB parts come and go. And in similar spot in T4 you'll see " #if 0 // TODO #endif return 0; " - if it is there yet at all? In...

The Forum being so hard to search I went to 'my posts' and viewed them as far back as they go - and then cut and pasted the pages of them into a Word file that I can search for "#if 0"

Hey - today is my 4 year Anniversary here "Join Date 02-14-2015" - since Teensy did the IDE 1.6.0 Beta and I decided Teensy might be worth looking at … 7,531 posts later ...
 
Tim. It might have but I just don't remember seeing it. I remember we talked about "if 0's" when I was looking at USB_keyboard and such. Never looked at usb_serial. Assumed it was ok since transmit was working and we use USB all the time. Also wasn't sure that was the right place, guess it is :)

Guess will just have to be patient.
 
The Serial.read() code for Teensy4 would be in the files teensy4/usb_serial.c/h

That is the Object is defined in usb_serial.h where for example the class is defined:
Code:
class usb_serial_class : public Stream
{
public:
	constexpr usb_serial_class() {}
        void begin(long) {
		//uint32_t millis_begin = systick_millis_count;
		//disabled for now - causes more trouble than it solves?
		//while (!(*this)) {
			// wait up to 2.5 seconds for Arduino Serial Monitor
			// Yes, this is a long time, but some Windows systems open
			// the port very slowly.  This wait allows programs for
			// Arduino Uno to "just work" (without forcing a reboot when
			// the port is opened), and when no PC is connected the user's
			// sketch still gets to run normally after this wait time.
			//if ((uint32_t)(systick_millis_count - millis_begin) > 2500) break;
		//}
	}
        void end() { /* TODO: flush output and shut down USB port */ };
        virtual int available() { return usb_serial_available(); }
        virtual int read() { return usb_serial_getchar(); }
...

The function usb_serial_available() is in the usb_serial.c file which probably does not help much...
Code:
int usb_serial_getchar(void)
{
#if 0
	unsigned int i;
	int c;

	if (!rx_packet) {
		if (!usb_configuration) return -1;
		rx_packet = usb_rx(CDC_RX_ENDPOINT);
		if (!rx_packet) return -1;
	}
	i = rx_packet->index;
	c = rx_packet->buf[i++];
	if (i >= rx_packet->len) {
		usb_free(rx_packet);
		rx_packet = NULL;
	} else {
		rx_packet->index = i;
	}
	return c;
#endif
	return -1;
}
...
int usb_serial_available(void)
{
#if 0
	int count;
	count = usb_rx_byte_count(CDC_RX_ENDPOINT);
	if (rx_packet) count += rx_packet->len - rx_packet->index;
	return count;
#endif
	return 0;
}
Which sort of explains why we are not getting anything ;)

I know a few weeks ago @Paul mentioned he was going to rewrite a bunch of the USB code. Not sure of the status of this.

Kurt
 
That gave the date of the post - but the scrape of the posts ends in "…" here's the full post - that is when you were looking at enabling joysticks in main USB …

Mike - I suspect if you look at the T3 tree you'll see the #ifdef's where the extra USB parts come and go. And in similar spot in T4 you'll see " #if 0 // TODO #endif return 0; " - if it is there yet at all?

In passing the core USB simple core stuff like this is showing that : usb_serial_read, usb_serial_available, usb_serial_write_buffer_free, usb_serial_flush_output,

Suppose USB coming along as best it can - haven't seen Paul note it lately … perhaps it is being a bugger ...
 
Last edited:
That gave the date of the post - but the scrape of the posts ends in "…" here's the full post - that is when you were looking at enabling joysticks in main USB …

Suppose USB coming along as best it can - haven't seen Paul note it lately … perhaps it is being a bugger ...
Thanks Tim.
Yeah that's the post I remember but I didn't remember that last line in the post - I went back but could find it when I did a search for "#if 0". Going to play around with that piece a little bit - almost got it to compile - need usb_mem and a couple of edits - have to look more between t3 and t4. Think it could work without all the other stuff that needs to be done with USB.

EDIT: Just started to dig deeper - may be a little more complicated but you all knew that :)
 
Last edited:
Status
Not open for further replies.
Back
Top