I think that's a good idea.@mjs513 - the merge maybe updated the max SPI speed... 12mhz instead of 22mhz... Not sure if you want to undo that part?
Also thinking it would be nice to maybe add third optional parameter, to begin with max SPI speed or add another method, with it?
Think that would be a good idea with these displays. If the fastio settings work for @neurofun probably should update it with a PR?Also thinking it would be nice to maybe add third optional parameter, to begin with max SPI speed or add another method, with it?
uint32_t fastio = IOMUXC_PAD_DSE(6) | IOMUXC_PAD_SPEED(1);
@neurofun @mjs513 - I was also going to suggest, disconnecting everything from that T4, plug it in and hold the program button in for 15+ seconds, and see if the dim LED turns on, hopefully within 30 seconds, if so, release the button, and the LED should get brighter and then it should reprogram the T4 back to the shipping blink program.
And also like I suggested with @mjs513 I would double check the display and make sure it was shipped configured for 5V and 4 wire SPI. Although since it worked on T3.6 I assume so.
And as @sumotoy I believe said on his Wiki, that don't try to run the 7" using USB power... So if all else fails, maybe try rebooting your computer. Maybe the USB was overloaded and shut off... I hit that a few times, where my computer will complain about something overloaded USB...
My 4.3" display works perfectly with T4, without the fastio setup.@neurofun
As a test I just tried my 4.3in display using a 5v Anker power bank as an external power source to the display. Have fastio setup and RST connected. T4 connected directly to the computer. Benchmark sketch worked no issues. I did connect gnd on the display to gnd on the T4 for the test. Something strange is going on.
That's because the RA8875 CS, SDI and SCLK inputs each have a 10k pull up resistor to 3.3V(R1, R3, R3, respectively). So the SCLK pin feeds 3.3V via the pull up resistor to the led.I did not notice that the T4 orange lite came on when power was applied to the display without power to the T4. If I disconnected SCK the orange lite went out. May want to check if this happens on the T3.6 as well.
Oh I'm sure it is fried, on both T4 the fuse is too hot to touch.Did you try and replug the T4 and do a 15s reboot just to make sure its fried?
Sorry to hear that, it is never a good sign!Oh I'm sure it is fried, on both T4 the fuse is too hot to touch.
Sorry to hear that, it is never a good sign!
Again I assume you checked the chip to see if by chance you can see some short that is there, like a solder bridge...
#if defined(__MKL26Z64__)
static bool _altSPI;
#endif
#ifdef SPI_HAS_TRANSACTION
static volatile uint32_t _SPImaxSpeed;//holder for SPI speed
#endif
void _startSend()
__attribute__((always_inline)) {
#if defined(SPI_HAS_TRANSACTION)
#if defined(__MKL26Z64__)
_altSPI == true ? SPI1.beginTransaction(SPISettings(_SPImaxSpeed, MSBFIRST, SPI_MODE3)) : SPI.beginTransaction(SPISettings(_SPImaxSpeed, MSBFIRST, SPI_MODE3));
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__)
_pspi->beginTransaction(SPISettings(_SPImaxSpeed, MSBFIRST, SPI_MODE3));
#elif defined(ESP8266)
...
void _startSend()
__attribute__((always_inline)) {
#if defined(SPI_HAS_TRANSACTION)
#if defined(__MKL26Z64__) || defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__)
_pspi->beginTransaction(SPISettings(_SPImaxSpeed, MSBFIRST, SPI_MODE3));
#elif defined(ESP8266)
..
volatile uint8_t _enabledInterrups;
[COLOR="#FF0000"]static void _isr(void);[/COLOR]
#if !defined(_AVOID_TOUCHSCREEN)
volatile bool _touchEnabled;
volatile bool _clearTInt;
#endif
#if defined(USE_FT5206_TOUCH)
volatile bool _needCTS_ISRrearm;
[COLOR="#FF0000"]static void cts_isr(void)[/COLOR];
#elif defined(USE_RA8875_TOUCH)
KurtE said:So question will be should I go ahead and issue PR with the current stuff or wait until maybe I can test two displays.
Not sure how well I will be able to test USE_FT5206_TOUCH for two displays as I will only have one with a workable version of it (coming today), but at least maybe?
static void _isr(void);
static void _isr1(void);
static void _isr2(void);
void RA8875::_isr(void)
{
_RA8875_INTS |= (1 << 0);//set
}
void RA8875::touchReadPixel(uint16_t *x, uint16_t *y)
{
uint16_t tx,ty;
readTouchADC(&tx,&ty);
//*x = map(tx,_tsAdcMinX,_tsAdcMaxX,0,_width-1);
*x = constrain(map(tx,_tsAdcMinX,_tsAdcMaxX,0,_width-1),0,_width-1);
//*y = map(ty,_tsAdcMinY,_tsAdcMaxY,0,_height-1);
*y = constrain(map(ty,_tsAdcMinY,_tsAdcMaxY,0,_height-1),0,_height-1);
_checkInterrupt(2);
}
To be honest think just getting the SPI clock in enough as well as being able to use 2 displays for graphics would be a plus. But trying to get different types of touch working think its more trouble especially if SumoToy isn't around? The branch we are working with is even his beta branch and not the officially released one so that could cause more problems. But it did fix a bunch of bugs.KurtE said:But is it worth it? Would anyone use it? And wish someone like SumoToy was still there to own it...