Teensy 4.0 First Beta Test

Status
Not open for further replies.
defragster said:
@KurtE / @mjs513 - let me know where the latest usable 9488 / 9341 / USBHost are and perhaps that can be next.

ILI9488: https://github.com/mjs513/ILI9488_t3, all changes have been pushed.

ILI9341_t3: https://github.com/KurtE/ILI9341_t3/tree/T4_Beta, This is Kurt's version, the PR is in to update the master. Only works on SPI, I only tested on SPI1 (UPDATE: TESTED WORKING ON SPI)

ILI9341_t3n: Haven't tested it yet. https://github.com/KurtE/ILI9341_t3n/, I think that's the latest. (UPDATE: TESTED WORKING ON SPI)
 
Last edited:
@defragster - I have not done much yet figuring out the non-boot with Serial4 connected. I tried again with the Adafruit CP2104...

If I have only GND and RX(adapter)-TX(T4) the T4 boots when I apply power...
And I get the normal stuff like:
Code:
***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
  enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
USB reset took 6 loops
analogInit
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
after setup

And Blink program blinks

But if I also connect the the TX(adapter) - RX(T4) and then apply power to Teensy
Nothing. Nothing in the T4 monitor and no blinking. Pressing the program button does nothing, but pressing the power button for something like 10 seconds does turn off the power LED on the board pressing it again does start the LED again but still nothing else.

AND I now tried with an FTDI adapter where the USB connector is marked: TTL-RS232R-3.3V and the T4 is happy... It shows debug information and T4 boots with it attached... Something different on the RX pin...
 
@defragster, @Paul, @mjs513 - SPI, ILI9488, ILI9341...

I think most of the answers are in Mikes answer on #2501...

The update to ILI9341_t3 to work at all on T4 is in PR: https://github.com/PaulStoffregen/ILI9341_t3/pull/52
Some of this is based off of changes put into: ILI9488 - Although only the parts to work with SPI (not SPI1 and SPI2...)

To make the ILI9488 work with SPI1 and SPI2, I did some rather gross hacks, as to not use SPIN library which has some additional support that SPI does not (YET), although the data is there in SPI library to make it work properly.

In Particular: in order to select between using SPI or SPI1 or SPI2, the code needs to be able to select the right set of registers for the SPI port. So we hold onto a pointer to structure of SPI registers... Likewise it needs to know some additional information, like on T3.x how large the FIFO queues are, maybe information on DMA... Again the data is in the SPI library but we don't give APPS a real way to get this information.

Internal to the SPI library we have access to these bits of information:
To get access to the hardware registers we use the internal method: port() So on T4 to write to the SPI output register we do: port().TDR = data;
Likewise to get the additional information to the hardware information, we use the: hardware() function. to gain access.
Note: the return values/types returned by these functions is public...

So there are a couple of ways we could make this information easier to get to:
a) Move port() and hardware() functions into the public part of the SPI definitions... (obviously the easiest way)
b) Make them protected - and then those who want to use maybe create a subclass of SPI to gain access - would work but...

Or the hack I did in the ILI9488 library, which is knowing that the first two things in the SPI object are these pointers...
So something along the line of: Suppose you have pointer to SPI object like: _pspi;
Code:
    uintptr_t *pt = (uintptr_t*)_pspi;
    _port = (IMXRT_LPSPI_t *)pt[0];   // assuming T4 here
    _phardware = (SPIClass::PI_Hardware_t *)pt[1];
Note: in current code I used (uint32_t*) instead of uintptr_t...

Question is should we make a more valid way to do this? If we did I would probably update my ILI9341_t3n library to remove the SPIN library usage
 
Kurt, I get some warnings:
Code:
C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp: In member function 'void ILI9341_t3n::drawFontChar(unsigned int)':

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3002:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

      while(screen_x<=end_x) {

                    ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3004:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

       if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {

                     ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3004:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

       if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {

                                                     ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3006:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

        if ((screen_x<origin_x) || (screen_x>=glyphend_x)){

                     ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3139:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

      while(screen_x<=end_x) {

                    ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3141:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

       if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {

                     ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3141:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

       if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {

                                                     ^

C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3143:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

        if ((screen_x<origin_x) || (screen_x>=glyphend_x)){

                     ^
Some more warnings in NXP_SDHC.cpp:

Code:
:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'int SDHC_CardReadBlock(void*, uint32_t)':

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:583:13: warning: unused variable 'pData' [-Wunused-variable]

   uint32_t* pData = (uint32_t*)buff;

             ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'int SDHC_CardWriteBlock(const void*, uint32_t)':

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:646:19: warning: unused variable 'pData' [-Wunused-variable]

   const uint32_t *pData = (const uint32_t *)buff;

                   ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'void sdhc_setSdclk(uint32_t)':

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:881:12: warning: unused variable 'm_sdClkKhz' [-Wunused-variable]

   uint32_t m_sdClkKhz = f_pll / (1000 * sdclkfs * dvs);

            ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: At global scope:

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:428:13: warning: 'void SDHC_SetClock(uint32_t)' declared 'static' but never defined [-Wunused-function]

 static void SDHC_SetClock(uint32_t sysctl);

             ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:430:12: warning: 'int SDHC_ReadBlock(uint32_t*)' declared 'static' but never defined [-Wunused-function]

 static int SDHC_ReadBlock(uint32_t* pData);

            ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:431:12: warning: 'int SDHC_WriteBlock(const uint32_t*)' declared 'static' but never defined [-Wunused-function]

 static int SDHC_WriteBlock(const uint32_t* pData);

            ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1196:12: warning: 'int SDHC_CMD12_StopTransferWaitForBusy()' defined but not used [-Wunused-function]

 static int SDHC_CMD12_StopTransferWaitForBusy(void)

            ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1230:12: warning: 'int SDHC_CMD17_ReadBlock(uint32_t)' defined but not used [-Wunused-function]

 static int SDHC_CMD17_ReadBlock(uint32_t sector)

            ^

C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1250:12: warning: 'int SDHC_CMD24_WriteBlock(uint32_t)' defined but not used [-Wunused-function]

 static int SDHC_CMD24_WriteBlock(uint32_t sector)

            ^
 
@Frank B and @KurtE

I have this bad tendency to forget about warnings but Frank is right you do get those warnings for both SDCard and ILI9341_t3n libraries. If you want I will take a look at the libs and see if I can sort it out. Will start now anyway. Know you all are busy with other things.

EDIT:
Errors seemed to be centered around the last commit of the anti-aliased fonts. The additional code is using uint32_t's for:
Code:
glyphend_x = origin_x+width; // origin_x previous defined in other places as int32_t's
screen_x     //previously defined at int's in other places.

Looks like end_x is defined as int in the rest of file

So question - save to change to match rest of the .cpp.  Think so.
 
Last edited:
@Frank - Yes I need to go back into ILI9341_t3n and clean up some of these. I think some of them came in with more recent merges...

As for SD stuff, That part I have not touched.
 
I've been looking into the SD issues using SPI. This commit "fixes" SD card access on the audio shield (when CS is set to pin 10), at least well enough for "listfiles" to work, with the 1 card I tested here (Samsung EVO 32GB).

https://github.com/PaulStoffregen/SD/commit/4ca861105f5f127ed2673eef9adea142ed21e95b

I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...

The card I am testing with is a SansDisk Ultra 64Gb and appears to working normally. I ran CardInfo and listfiles with no problems. I ran the datalogger example and then read the file back with dumpfile without a problem. So not sure how to test this?

EDIT: Which Samsung EVO 32Gb card do you have? Amazon seems to have 3 different versions
 
@defragster - I have not done much yet figuring out the non-boot with Serial4 connected. I tried again with the Adafruit CP2104...

If I have only GND and RX(adapter)-TX(T4) the T4 boots when I apply power...


And Blink program blinks

But if I also connect the the TX(adapter) - RX(T4) and then apply power to Teensy
Nothing. Nothing in the T4 monitor and no blinking. Pressing the program button does nothing, but pressing the power button for something like 10 seconds does turn off the power LED on the board pressing it again does start the LED again but still nothing else.

AND I now tried with an FTDI adapter where the USB connector is marked: TTL-RS232R-3.3V and the T4 is happy... It shows debug information and T4 boots with it attached... Something different on the RX pin...

My DMM shows 23 mA from T_3.1 Tx hitting the T4-2 Rx when it is off - putting Power to the T4-2 stops the current flow but the T4-2 fails to startup.
A T_3.6 Tx looks like it is under 20 mA - but on T4-2/Rx it stops power up too.

I can't see the dim glow in daylight. I did touch T_3.1's 3.3V to that Rx pin and the LED went over half bright and again the T4-2 did not power up.
Probe from T_3.6 Tx touched breakout Rx and Tx together - opps - and the LED did glow

I put a 460 ohm resistor on 3.3V output of T_3.1 and it was more like 3 mA and the T4-2 powered up - so that current is a factor and as noted why it takes two current source on Rx in your case and my prior case on the T4-1.

As noted a UART Tx in idle state holds the pin at 3.3V. With multiples of those connected - or a set of external SPI or i2c with pullups on pins this will be repeated when a powered off T4 is powered.

Of course taking 3.3V power from the T4 itself doesn't cause a problem because the circuits are all live at the same time. But with UART/i2c/SPI connected to external powered device - like these independently powered UART Tx's it seems an issue.

As I'm not an EE so my fiddling here is just past what I should be doing - but it seems this is an issue Paul hopefully has on a short list.
T4-2 is fully functional - it just won't startup with the external UART Tx powered before the T4 gets that default high signal on Rx.

{edit} - back to the breakout for the T4-1 :: It has underside resistors on Rx and Tx lines! I asked about those way back then … and just remembered them
>> The T4-2 breakout does NOT have those resistors installed - so Rx on breakout is wired to pin without that added resistor.
If I put a T_3.6 on common USB:GND to the T4-1 and touch the T_3.6 Tx to T4-1 Rx it also fails to startup. That also goes to the T4-1 reported issue noted - where Multiple T_3.x's for Debug on UARTs caused the issue as each resistor limited current.

[UPDATE]: With this issue I've not gotten a DEBUG UART device on T4-2 yet, as I was connecting Rx and Tx for BiDi comms. So I put a T_3.1 on Serial4 - but left off the Rx - and it still failed to start up ???

DVM Shows the T_3.1 holding the Rx line at 3.15 volts - connecting that also stops the T4-2 from powering up without resistors on the line.
 
Last edited:
@FrankB - not pretty … but I did find and access some words of static RTC RAM with the following code.
The book said to expect four 32 bit Dwords - but the 4th only has the lower 16 bit writable? And when I incremented toward MAX uint32_t value it stopped taking changes - it didn't change or wrap - it was fine when I dropped power?
Also on the T_3.x those RTC uint32's could be mapped to a uint16 pointer and accessed - these seem to be 32 bit access only
Anyhow the method I used was this:
Code:
//  Battery backed NV RAM
// T4: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204248&viewfull=1#post204248

// https://forum.pjrc.com/threads/45854-Battery-backed-NV-RAM?p=151035&viewfull=1#post151035
// https://forum.pjrc.com/threads/55330-Info-adc?p=199876&viewfull=1#post199876

// TIME >> https://forum.pjrc.com/threads/55553-RTC-hour-displays-wrong-time?p=202332&viewfull=1#post202332
#define qBlink() digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) )

// 3 32 bit Dwords - don't write to the 4th as it has bit set in high 16 bits and those 16 bits won't change - and it cause failed restart
#define NVRAM_UINT32 ((uint32_t *)0x400A4000)

void setup() {
  pinMode( LED_BUILTIN, OUTPUT );
  qBlink();
  while (!Serial && millis() < 4000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  qBlink();
  for ( int ii = 0; ii < 3; ii++ ) {  // only safe 0,1,2 !!
    qBlink();
    Serial.print( NVRAM_UINT32[ii], HEX );
    Serial.print( " _[>" );
    Serial.println( NVRAM_UINT32[ii] / (ii * ii) );
    NVRAM_UINT32[ii] += ii * ii;
    // NVRAM_UINT32[ii] =0;
  }
}
void loop(){}

>Works on T4-1 and T4-2
 
Last edited:
I've patched interrupt.c to allow attachInterrupt() with GPIO6..9
Would be great if you test it? Any way to make it faster?
https://github.com/PaulStoffregen/cores/pull/370

@Frank B
Since I had the KY-040 rotary encoder I wanted to test I figured I would give it a try. I used pins 14 and 15 - hope those correspond to the same GPIO's. It appears to be working and catching everything. I even noticed something that I didn't notice before so was a good exercise. Here's the sketch I used:
Code:
/* Arduino New Rotary Encoder Pin states
Created by Yvan / https://Brainy-Bits.com
This code is in the public domain...
You can: copy it, use it, modify it, share it or just plain ignore it!
Thx!
*/

volatile boolean TurnDetected;  // need volatile for Interrupts

// Rotary Encoder Module connections
const int PinCLK=15;   // Generating interrupts using CLK signal
const int PinDT=14;    // Reading DT signal

// Interrupt routine runs if CLK pin changes state
void rotarydetect ()  {
  TurnDetected = true;  // set variable to true
}

void setup ()  {
  Serial.begin(2000000);  // high rate to assure good capture
  attachInterrupt (PinCLK,rotarydetect,CHANGE); // interrupt 0 always connected to pin 2 on Arduino UNO
}

void loop ()  {
  if (TurnDetected)  { // rotary has been moved
      TurnDetected = false;  // do NOT repeat IF loop until new rotation detected 
      Serial.print("CLK Pin: ");
      Serial.println(digitalRead(PinCLK));
      Serial.print("DT Pin: ");
      Serial.println(digitalRead(PinDT));
      //delay(5);
  }
}

ADDITIONAL INFO:
Ran the above sketch on pins 0/1 and worked well. Also ran the encoder library basic sketch on both pinsets 14/15 and 0/1 and it seemed to resolved something I was seeing periodically. So if I used the right pins I think its working.
 
Last edited:
@mjs: thanks :) any idea to make it more efficient?

Thank you Tim.
I'm not sure if it is useful for the RTC. It would, if there was a way to detect a "cold start" or fresh programming. I don't know of a way to detect it. The SRC_SRSR does not help :(
So, the way manitou used (Is the current time younger than the compiled time?) is the best way to determine which time is valid. It works good.

https://github.com/PaulStoffregen/cores/pull/371
 
Last edited:
@Frank B

Your kidding right me. Besides how can you improve on perfection :). I'm trying to get CAN-FD working with the SDK example I have - running into some issues almost like for CAN until I broke that code :(
 
Paul - what value are those inline Serial Rx/Tx resistors? I can't see markings on them ... either none there or they cooked off. Looks like a resistor on the active Breakout pin to unused pins to then connectthat to the incoming Rx/Tx is needed to prevent T4-2 lockout?

@FrankB - with no power those registers read zero on startup - but other than that they are static and it would be up to code to decide if it was a restart or reprogram ... Getting time from compiler to compare would answer the new code issue - that would represent a compile time "SerialNumber/Version" - and you have a place to store that now :) Of course a restart or power Off>On always hits setup.


@Frank B
Since I had the KY-040 rotary encoder I wanted to test I figured I would give it a try. I used pins 14 and 15 - hope those correspond to the same GPIO's. It appears to be working and catching everything. I even noticed something that I didn't notice before so was a good exercise. Here's the sketch I used:

ADDITIONAL INFO:
Ran the above sketch on pins 0/1 and worked well. Also ran the encoder library basic sketch on both pinsets 14/15 and 0/1 and it seemed to resolved something I was seeing periodically. So if I used the right pins I think its working.

Those are nice with real PINS - I got a pair form SFun and AdaF - both have stamped metal legs … they are buttons too and one may be lighted … but much more work to hook up :( And amazon at $11 for 5.
 
@frank B an @Paul and @mjs513 and @defragster and ...

SPI, (SPI1, SPI2), FlexSPI and SPISettings -

I know that I mentioned this earlier, but thought I would revisit, especially since looking at SPI1/SPI2, plus FlexIO-SPI...

History:
With T.x and earlier with T4... when the user did something like: SPI.beginTransaction(SPISettings(20000000, MSBFIRST, SPI_MODE0));
The compiler would take the SPISettings stuff and reduce all of this down to simply doing a few sets of the SPI Port register (in particular for T4, the CCR and TCR registers0, with constants. This was because since everythng was know at compile time the compiler coudl do all of the calculations and simply fill in with constants.

But then the change went in to allow the underlying clock to be changed and have the code understand that and calculate base don that...

In particular to the change:
Code:
-
		uint32_t d, div;
		uint32_t clkhz = 528000000u / (((CCM_CBCMR >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
				
		const uint32_t clk_sel[4] = {664615384,  // PLL3 PFD1
					     720000000,  // PLL3 PFD0
					     528000000,  // PLL2
					     396000000}; // PLL2 PFD2				
		uint32_t cbcmr = CCM_CBCMR;
		uint32_t clkhz = clk_sel[(cbcmr >> 4) & 0x03] / (((cbcmr >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
		
		uint32_t d, div;

The problem is, since now the clode depends on variables like CCM_CBCMR - it can no longer be computed at compile time, so there is a lot more code that happens at each of the places that use SPISettings.
So both grows code and slows it down.

Also I have not yet verified that the clock selected for SPI is valid for SPI1 and SPi2...

There are several things to look at:
Code:
	void init_AlwaysInline(uint32_t clock, uint8_t bitOrder, uint8_t dataMode)
	  __attribute__((__always_inline__)) {
		// TODO: Need to check timings as related to chip selects?
				
		const uint32_t clk_sel[4] = {664615384,  // PLL3 PFD1
					     720000000,  // PLL3 PFD0
					     528000000,  // PLL2
					     396000000}; // PLL2 PFD2				
		uint32_t cbcmr = CCM_CBCMR;
		uint32_t clkhz = clk_sel[(cbcmr >> 4) & 0x03] / (((cbcmr >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
		
		uint32_t d, div;		
		if (clock == 0) clock =1;
		d= clkhz/clock;
		if (d && clkhz/d > clock) d++;
		if (d > 257) d= 257;  // max div
		if (d > 2) {
			div = d-2;
		} else {
			div =0;
		}
		ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2);
		tcr = LPSPI_TCR_FRAMESZ(7);    // TCR has polarity and bit order too

		// handle LSB setup 
		if (bitOrder == LSBFIRST) tcr |= LPSPI_TCR_LSBF;

		// Handle Data Mode
		if (dataMode & 0x08) tcr |= LPSPI_TCR_CPOL;

		// Note: On T3.2 when we set CPHA it also updated the timing.  It moved the 
		// PCS to SCK Delay Prescaler into the After SCK Delay Prescaler	
		if (dataMode & 0x04) tcr |= LPSPI_TCR_CPHA; 
	}
The question is do all three SPI boejcts share the same Clock Setting? And do you mind if everything has to be recomputed each time?

That is we are computing everything depending on the values of the register CCM_CBCMR
Is this the same for SPI versus SPI1 versus SPI2?

That is for example suppose you crate an SPI object with speed 2000000

something like mysettings = SPISettings(200000, MSBFIRST, SPI_MODE0);

Then if you use this on a beginTransaction for SPi as well as SPi2 and SPi2, do you expect that iw till work properly on all 3?

Likewise do you expect us to be able to pass in the SPISettings into a flexIO version of SPI, which has a different set of registers?

For the fun of it I should experiment and see if we notice any differences in speed with, some cases. As for using the SPISettings with FlexIO. By default it is
sort of not able to be used here as registers defiend and used are different
 
Paul - what value are those inline Serial Rx/Tx resistors?

Those resistors are only on the first breakout board, for the beta #1 with the 1052 chip. For the second breakout board design (for beta #2 with 1062) I just used wires, since hand soldering so many not-so-necessary resistors really added a lot of manual labor when building a couple dozen boards. The 3rd rev (replacing the 8 tiny pogo pins with FFC cable) also just has wires. Those 3rd rev boards are being fabricated now and should be ready by the time we get the next round of T4 prototypes with the 1mm pads for FFC.

On some of those first boards I used 330 ohms, on others 220 ohms (when my supply of 330 ohm 0603 size resistors ran out). If your board has resistors without any marking, they're probably 220 ohms.

If you *really* want to know, just unplug the serial cable and use a multimeter to measure the resistor.
 
@KurtE

Your post on spi settings is really interesting. Here's why, at least for me. When I was trying to debug touchscreen with the graphics library I noticed that the clock for the display was at 30Mhz while the clock for the touch library was at 20Mhz. Don't know if this would be conflict using that rationale. I forgot what I tried now - have to revisit.
 
Quick CAN question, should I consider using a different transceiver chip on the next breakout board?

Right now we have MCP2558FD (which I haven't tested in any way....) It claims to work up to 8 Mbit/sec, which doesn't allow the full use of 12 Mbit/sec we supposedly have with the 1062 chip. But most of the other chips I see are rated up to only 2 or 5 Mbit/sec.

I have almost no experience with CAN or CAN FD. If anyone has opinions on this, please speak up.
 
Quick CAN question, should I consider using a different transceiver chip on the next breakout board?

Right now we have MCP2558FD (which I haven't tested in any way....) It claims to work up to 8 Mbit/sec, which doesn't allow the full use of 12 Mbit/sec we supposedly have with the 1062 chip. But most of the other chips I see are rated up to only 2 or 5 Mbit/sec.

I have almost no experience with CAN or CAN FD. If anyone has opinions on this, please speak up.
The only other chip that I have any experience with the MCP2517FD. Its the same chip that is on Mikroe Chip breakout board, https://www.mikroe.com/mcp2517fd-click, that @tonton81 and I used to test FD between Teensies. Think SK Pang uses the same chip. To be honest don't think I have ever seen and chip that supports 12Mbit/sec yet. But that is just me.
 
@Kurt, the alternative is to not beeing able to use alternate, higher (or lower) SPI frequencies. Is this wanted?

@Paul: I do not intend to use CAN, and I have not a single board or chip to test it :)
 
Those resistors are only on the first breakout board, for the beta #1 with the 1052 chip. For the second breakout board design (for beta #2 with 1062) I just used wires, since hand soldering so many not-so-necessary resistors really added a lot of manual labor when building a couple dozen boards. ...
On some of those first boards I used 330 ohms, on others 220 ohms (when my supply of 330 ohm 0603 size resistors ran out). If your board has resistors without any marking, they're probably 220 ohms.
...

220-330 is close enough - since they aren't marked I only assumed they were resistors - and measuring takes disassembly.

And yes - it is noted above the resistors are NOT on the Beta 2 breakout - that is why T4-2 is failing for me using a single T_3.1 for debug terminal - the UART standby voltage prevents the T4 from starting up.
 
@Frank - SPISettings and SPI.beginTransaction() - The other option would be to move the functionality around. That is don't have all of the stuff to compute ccr and tcr in that code...
But instead if necessary compute it within the beginTransaction...

I did this sort of quick and dirty within my FlexIO SPI implementation:

The whole implementation of the SPISettings:

Code:
class FlexSPISettings {
public:
	FlexSPISettings(uint32_t clock, uint8_t bitOrder, uint8_t dataMode) : _clock(clock), 
		_bitOrder(bitOrder), _dataMode(dataMode) {};

	uint32_t _clock;
	uint8_t _bitOrder;
	uint8_t	_dataMode;
};

And the FlexSPI::beginTransaction has code that does stuff like:
Code:
void FlexSPI::beginTransaction(FlexSPISettings settings) {
	#ifdef SPI_TRANSACTION_MISMATCH_LED
	if (inTransactionFlag) {
		pinMode(SPI_TRANSACTION_MISMATCH_LED, OUTPUT);
		digitalWrite(SPI_TRANSACTION_MISMATCH_LED, HIGH);
	}
	_in_transaction_flag = 1;
	#endif

	// right now pretty stupid
	if ((settings._clock != _clock) || (settings._dataMode != _dataMode )) {
		_clock = settings._clock;
		_dataMode = settings._dataMode;

		uint32_t clock_speed = _pflex->computeClockRate() / 2;   // get speed divide by 
		uint32_t div = clock_speed / _clock;
...
Potentially the above could be cleaned up by adding some public functions like
inline uint32_t clock() {return _clock;} ...

Just an idea. wondering what you all think? I personally think it will probably reduce code size and probably speed up the T4 SPI by a hair...

Edit: And if we did something like that, could share the SPISettings with the Flex IO SPI code.

Edit2: I did a quick and dirty version of this...
Looks like it actually grows the code some putting all of the stuff into beginTransaction... I would probably move some/all of this into spi.cpp...
But speed wise, I ran our hacked up version of ili9341_t3n graphic test program (requires updated code to run on T4).
Without changes:
Code:
ILI9341 Test!
Display Power Mode: 0x80
MADCTL Mode: 0x80
Pixel Format: 0x87
Image Format: 0x7
Self Diagnostic: 0x87
Benchmark                Time (microseconds)
Screen fill              245388
Text                     12923
Lines                    85415
Horiz/Vert Lines         21411
Rectangles (outline)     13747
Rectangles (filled)      504228
Circles (filled)         84719
Circles (outline)        72371
Triangles (outline)      20134
Triangles (filled)       180512
Rounded rects (outline)  31275
Rounded rects (filled)   562301
Done!
With changes:
Code:
ILI9341 Test!
Display Power Mode: 0x80
MADCTL Mode: 0x80
Pixel Format: 0x87
Image Format: 0x87
Self Diagnostic: 0x87
Benchmark                Time (microseconds)
Screen fill              245230
Text                     12653
Lines                    85456
Horiz/Vert Lines         21388
Rectangles (outline)     13737
Rectangles (filled)      503832
Circles (filled)         83910
Circles (outline)        71028
Triangles (outline)      20075
Triangles (filled)       179844
Rounded rects (outline)  30850
Rounded rects (filled)   561661
Done!
Again only sped up a touch... Is it worth it?
 
Last edited:
Status
Not open for further replies.
Back
Top