ILI9488: https://github.com/mjs513/ILI9488_t3, all changes have been pushed.Originally Posted by defragster
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 by mjs513; 04-26-2019 at 12:21 PM. Reason: Updated test results
Ok PR #47 submitted.
Me too- As Paul pulled our stuff in to the master branch (and beta build), the PR should be against his master branch...
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...dea142ed21e95b
I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...
@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:
And Blink program blinksCode:***********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
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;
Note: in current code I used (uint32_t*) instead of uintptr_t...Code:uintptr_t *pt = (uintptr_t*)_pspi; _port = (IMXRT_LPSPI_t *)pt[0]; // assuming T4 here _phardware = (SPIClass::PI_Hardware_t *)pt[1];
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:
Some more warnings in NXP_SDHC.cpp: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)){ ^
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 by mjs513; 04-26-2019 at 04:15 PM.
@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.
@KurtE
Looks like our posts hit at the same time
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
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
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 by defragster; 04-26-2019 at 09:21 PM.
@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:
>Works on T4-1 and T4-2Code:// 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(){}
Last edited by defragster; 04-28-2019 at 06:44 AM.
@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: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); } }
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 by mjs513; 04-26-2019 at 09:09 PM. Reason: added info
@mjs: thanksany 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 by Frank B; 04-26-2019 at 10:16 PM. Reason: updated link
@Frank B
Your kidding right me. Besides how can you improve on perfection
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
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
@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:
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.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;
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:
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?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; }
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
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.
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
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:
And the FlexSPI::beginTransaction has code that does stuff like: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; };
Potentially the above could be cleaned up by adding some public functions likeCode: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; ...
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:
With 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!
Again only sped up a touch... Is it worth it?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!
Last edited by KurtE; 04-27-2019 at 01:02 AM.
Posting Permissions
Reply With Quote