Teensy 4.0 First Beta Test

Status
Not open for further replies.
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.

I wire wrapped a 330 Ohm and a 200 from the Breakout Active posts to the pair of unconnected posts toward the GND post. This give a working 2 MB/sec Serial1 to the T_3.1 - if T_3.1 is OFF when the T4 is powered or 'switched On'

With the 330 inline I can power on the T4-2 with Tx to the T_3.1 Rx and get output and it gets to setup() and runs, without that it will not make it to setup().
That puts the 200 on the T4-2 Rx from the T_3.1 Tx and even alone that will not let the T4-2 get to setup.

Like my earlier noted and logged T4-1 issue - when connected to T_3.1 they have to be powered down before T4 will go through startup into setup().

Paul: I assume I'm explaining this properly and correct in seeing it as a significant issue with a relatively accurate analysis?
I'm out of my element here with details - but using a Teensy with EchoBoth for UART to SerMon for debug does not allow T4-2 to cold start.
<edit> A single wire Serial4 Tx to T_3.1 Rx for boot debug at 115200 does work - unless I also connect Rx from T_3.1.
> But after it is running Power Off works, but Power On will not restart - though the Green LED does light up Full bright and nothing comes out the debug port Serial4 in that case.


This might explain the odd behavior that stopped me from going further on T4-1 debug code.

Also when it functions on cold start with power switched by USB device it will at times work, when it will not work to Power On after it was powered Off with Breakout Button when the T_3.1 was connected.

Also I do have a USB TTL adapter and only seems to supply 9 mA on Tx when idle - that seems to allow Cold start, but not Button power On.

@mjs513 - when you were having your Faults while working - what was your UART/Debug setup?
@KurtE - I wonder how much/little current is coming from your TTL/USB Adafruit CP2104 or other units in use.
 
Last edited:
defragster said:
@mjs513 - when you were having your Faults while working - what was your UART/Debug setup?
When I was having the faults I typically didn't have anything hooked up to the UARTS. I did order a pololu CP2104 to see if I have the same problem. It wont get here until tomorrow or Monday.
 
@PaulStoffregen
I am working on testing CAN-FD using the example from the 1060 SDK. I do need to verify with you that the "S" pin on the MCP2558FD is attached to pin 6 on the T4B2 and that it needs to be driven "LOW" to enable to the transceiver. Essentially I am having the same problem I was having initially with CAN. PARTIAL ANS: Yes Pin 6. Took apart and checked.

Also is there a reason that you didn't populate the 120ohm resister on the breakout board. That may be my next step to test.


EDIT: this is one is really for everyone. While poking around there is no daisy register to set pin 37 as input but in the SDK I did find that they set register 0x401F878CU to 0. But for the life of me I don't know which one this in imxrt.h. Anyone can help? ANS: IOMUXC_CANFD_IPP_IND_CANRX_SELECT_INPUT = 0x401F878CU. Not in imxrt.h
 
Last edited:
@defragster and @mjs513... I thought I would try some of my other adapters, but having a hard time finding them... I have/had several different types I was using to make work on usbhost_t36, ... Did find a couple of PL2303 chips but windows does not work with them... Unless I figure a way to downgrade the prolific driver to an older version as Prolific does not support several of the older versions of the PL2303...

I have a couple FTDI ones (a 3.3v version which I tried and a 5v one which I won't)...

Anyway the one I have that shows the issue is the one from Adafruit, which I purchased through Amazon.com: https://www.amazon.com/gp/product/B06Y4V2HZY
(As Adafruit will not ship to PO or PMB box...)

EDIT: Did find one of the newer PL2303 devices: https://www.amazon.com/gp/product/B00QT7LQ88

And it also shows the same issue that the T4 will not cold boot if the TX/RX/GND pins are connected
 
Last edited:
@defragster and @mjs513... I thought I would try some of my other adapters, but having a hard time finding them...
...
Anyway the one I have that shows the issue is the one from Adafruit, which I purchased through Amazon.com: https://www.amazon.com/gp/product/B06Y4V2HZY
(As Adafruit will not ship to PO or PMB box...)

EDIT: Did find one of the newer PL2303 devices: https://www.amazon.com/gp/product/B00QT7LQ88

And it also shows the same issue that the T4 will not cold boot if the TX/RX/GND pins are connected

Thanks for checking/confirming @KurtE. It seems this explains the behavior I first noted on T4-1 as you are also seeing on T4-2. The B1 breakout resistors offered some buffer.

I recall a note by Paul once regarding power on pins of unpowered MCU - I don't recall it as detailed or think I could find it today. This link seems to speak to the issue electronics.stackexchange.com … VSupply+0.3V of course notes that when MCU is off with 0 volts on VSupply that 300 mV would be the limit for an attached pin on that indicated processor.

In general use and testing on T_3.x's this didn't show as a problem - perhaps there is more sensitivity on 1062.

@mjs513 - those faults were odd/spurious? as I saw and as you noted - interesting to note it was not this. It has been some time since I provoked ANY fault not clearly deserved and don't recall the setup then.
 
@defragster and @mjs513... I thought I would try some of my other adapters, but having a hard time finding them... I have/had several different types I was using to make work on usbhost_t36, ... Did find a couple of PL2303 chips but windows does not work with them... Unless I figure a way to downgrade the prolific driver to an older version as Prolific does not support several of the older versions of the PL2303...

I have a couple FTDI ones (a 3.3v version which I tried and a 5v one which I won't)...

Anyway the one I have that shows the issue is the one from Adafruit, which I purchased through Amazon.com: https://www.amazon.com/gp/product/B06Y4V2HZY
(As Adafruit will not ship to PO or PMB box...)

EDIT: Did find one of the newer PL2303 devices: https://www.amazon.com/gp/product/B00QT7LQ88

And it also shows the same issue that the T4 will not cold boot if the TX/RX/GND pins are connected

@degragster and @KurtE

I haven't received my CP2104 board yet so have not tested it. I did just receive the FTDI cable and tried to duplicate what you saw. I connected it to Serial4 and USB port on the PC. When I plugged in the T4 it booted right up with no issue and it was able to power off/power on with no problem. But then again its 232R adapter and those don't seem to have the problem. The 2104 should be here tomorrow and will follow up.
 
@mjs513 - it seems related to the V&A presented to the pins - perhaps collectively. The UARTs by design hold Tx high when idle - and it seems Rx is held over 3+V as well. So using T_3.x for UART Echo or another USB interface just changes the V&A presented to the pins. At some point it seems to go beyond the MCU's tolerance.

I noticed in the case a cold boot works - then when switched OFF>ON fails even taking the external UART offline doesn't allow a an OFF>ON to work without a shutdown - though the Green LED does cycle normally - it seems the idle current feeding the RTC after ON>OFF changes the operational influence of the V&A.
 
@mjs513 - it seems related to the V&A presented to the pins - perhaps collectively. The UARTs by design hold Tx high when idle - and it seems Rx is held over 3+V as well. So using T_3.x for UART Echo or another USB interface just changes the V&A presented to the pins. At some point it seems to go beyond the MCU's tolerance.

I noticed in the case a cold boot works - then when switched OFF>ON fails even taking the external UART offline doesn't allow a an OFF>ON to work without a shutdown - though the Green LED does cycle normally - it seems the idle current feeding the RTC after ON>OFF changes the operational influence of the V&A.

I just tried to repeat your experiment using teensy4 to T3.2 with both pins hooked up (Rx/Tx) and am pretty much seeing the same as you. When I turned the power off with the switch the LED went out but the T4 still showed in the Port drop down. So I disconnected the Tx line at the T3.2 end and it then disconnected. I repeated this a couple of times to see if I would get the same result, and yes it is repeatable. I used Serial2 for the test. I then repeated on Serial7 with the same result.
 
@all - I soldered in extra pogo pins into pins 24-25, 28-29 and I verified that Serial6 and Serial7 work with the new board... Did not have much doubts, other than maybe Input Mux Select tables might be different...

Hi @mjs513 and @defragster and @Paul - As I mentioned, I was able to reproduce the will not cold boot with two different adapter types: PL2303 and The Adafruit adapter...
However the FTDI adapter does NOT have this problem.

Likewise I can reproduce with Teensy LC connected to it running the USBToSerial sketch. I then configure the USB Baud rate to be 115200.

Side Note: If I choose the Serial port as a Teensy (top list) I don't see anyway to set the Baud rate, but if I instead choose the Arduino list, I can then set the Baud rate... Yes I know that USB Serial it self is not impacted by choosing a baud rate, however, the Serial object does know the selected baud rate(if (Serial.baud() != baud) ...) and use it to do things like configure another hardware Serial port to the desired baud rate...
 
I just tried to repeat your experiment using teensy4 to T3.2 with both pins hooked up (Rx/Tx) and am pretty much seeing the same as you. When I turned the power off with the switch the LED went out but the T4 still showed in the Port drop down. So I disconnected the Tx line at the T3.2 end and it then disconnected. I repeated this a couple of times to see if I would get the same result, and yes it is repeatable. I used Serial2 for the test. I then repeated on Serial7 with the same result.

Interesting - I hadn't looked at the ports - sounds like it is keeping USB active looking in some fashion. That seems to be an ON/Off Issue where that applied outside current is being abused to keep parts of the chip alive that were expected to shut down - and then they don't power up proper and fresh for startup?

in addition to the other issue: if you hooked up two Teensys { Or 2nd serial on that T_3.2 } at once to both Serial #2 and #7 - I expect it would not come on from a cold start. I think the other UART<>USB adapters may detect IDLE Serial and go into low power mode - when I was measuring current it would drop off from the 9mA to less making my slow meter hard to read - that would explain why they might not as easily/often trigger the start failure on T4 - It didn't seem like T_3.1 dropped the current on idle.

I just soldered female headers to an sparkfun 15140 encoder No hookup guide - but they have a sketch - and a mostly Chinese data sheet showing … I need to add caps and resistors … ICK … I just ordered the $11 5 pack of the KY-040 you have where that is already done out to pins.
 
Note: When it is in the 'Fail to Start Mode' the Button when Powered does not take the Teensy into Bootloader mode. And as noted: Power cycle alone will NOT restore function

New Thing - NO UART CONNECTS : Took the battery I had on a T_3.1 - put it on T4-2 { wires soldered to holder and wires placed into the open PCB holes : It works well enough to maintain those RTC RAM words I found }

>> I have a M<>F USB dongle with a switch on that cuts the 5V line to USB { from DigiSpark } :: Used since before I came to Teensy - Much better than unPlug - rePlug

>> opps :: that 4th value it seemed the Manual was there is not to be written! And the 3rd doesn't work right. It wouldn't take my value to show on next read in the high word - Something in the high word was not to be written. It seems the following now in Yellow can be ignored - code in next post edited - removed here

Code:
[Upload sketch - boring and stupid - this would I expect work as well watching the RTC Tick Value - but this is more deterministic:: 
* Leftmost RAM counter numbers are in HEX
* 4th display number has 0x8 in high word … that word is not writable it seems?

[QUOTE]#1: Upload the sketch again a couple times { IDE or Button w/TLoader } and watch for normal start blink, connect, print behavior with maintained & incrementing RAM counter.
#2: In the print you'll see RTC RAM values increment in some fashion the First 0 is always zero, the second goes up once with each setup(). 2nd and 3rd are trailed by a number of iterations the number represents.
#3: :cool: - this works![/QUOTE]

[CODE]#1: Remove USB Power from T4, Apply power, [watch for normal start blink, connect, print behavior nvRam increment]  … repeat { not a race just cycle at 1+ second }
#2: [B]after 1-5 cycles the T4 does not restart![/B]
#3: T4-2 will not come back - even after unpowered … because the RTC Battery is keeping something alive 
#4: A:> Remove/Restore battery - Count will be lost
   B:> Remove USB Power, Hold Button when Power is applied and it gets reprogrammed - [B]Count is maintained[/B]
#5: Apply USB power to T4 and it will start
<edit Note> RE:mjs513 note about Teensy on USB when in the 'Fail to start mode'{FTSM} - I don't see this here - I opened TyCommander {was closed} - it reports the T4-2 as normally 'missing' when the power is removed and restored in the FTSM. Also looking to the IDE under Ports I see no 'Teensy Ports' section until it is {#4:B} 'reset'

NEXT - repeat section steps above - but use Breakout Board POWER button, leaving the T4 under USB power … the results seem similar.
>> Including step #4:B - Holding Program Button while using Breakout Button to Power on T4 will go to bootloader

I did this while typing this post and my cycle count is 33 and output now looks like this:
T:\tCode\T4\T4_RTC_NVRAM_BARE\T4_RTC_NVRAM_BARE.ino Apr 27 2019 19:03:56
0 _[>0
21 _[>33
84 _[>33
80129 _[>58287
.........9581
.........19581

<< UPDATE / Edit / Added >>
Picked up a USB battery … so No TLoader or SerMon. It worked all of One cycle.
After that it would not recover with Button+PowerButton or Button+PowerCycle. - requires battery removal.
- all tests above had TLoader open for sketch upload - that may have been a critical part of restoring function …
<<Confirmed>> - Without TLoader upload and restart the T4-2 does not break out of FTSM.
-- Plugged back into PC, closed TLoader, Button Power Off/On is in FTSM. Power Off hold Prog_Button then Power_On - chimes in USB, Red Bootloader LED ready … Power Off (USB or button) - no start stiil in FTSM

> Need to better secure my battery connection as going for button can dislodge … I have 99 of those Adafruit TestPoint - like the GND loop Paul put on the BreakoutBoard
> going to do a 15sec Restore for starting point and confirm …

Update for now is :: Did 15s Restore - I did the Restore WHILE ON USB BATTERY - and it worked of course.
Using this EEPROM RawHID Restore sketch I SEE no FTSM after at least 10 Power Button cycles and 10 USB Power Off/On cycles! - I think ONE TIME I did get 6 cycles with Serial sketch

Next Step: Upload above sketch NO USB - connect Debug T_3.1 to Serial4 and send prior output there and repeat the above steps.
...
[/CODE]
 
Last edited by a moderator:
Can anyone tell me:
Where the 5 second delay from the Power On to Off comes from when that Pin is Grounded?
Does the Processor know/expose in anyway that this 5 second countdown has started and Power Off is pending/requested?

BTW - above sketch 'T4_RTC_NVRAM_BARE.ino' is short here it is:
SKETCH UPDATED the value that would not take a write should not have been written - at most the first 2 DWORDS are usable or safe to write.
Code:
//  Battery backed NV RAM
// T4: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204340&viewfull=1#post204340
#define qBlink() digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) )

[U]// 2 32 bit Dwords - 3rd next isn't fully writeable and 4th has bit set in high 16 bits and those 16 bits won't change[/U]
#define NVRAM_UINT32 ((uint32_t *)0x400A4000)

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

int ii = 0;
void loop()
{
  if ( !(++ii % 10) )
    Serial.println(millis());
  else
    Serial.print("." );
  delay(1000);
  qBlink();
}
 
Last edited:
Paul: Total fail building T4 with NO USB:
T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c:43:33: error: 'NUM_ENDPOINTS' undeclared here (not in a function)
endpoint_t endpoint_queue_head[(NUM_ENDPOINTS+1)*2] __attribute__ ((used, aligned(4096)));
^

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c: In function 'endpoint0_setup':

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c:286:8: error: unknown type name 'usb_descriptor_list_t'
const usb_descriptor_list_t *list;
^

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c:298:25: error: 'usb_endpoint_config_table' undeclared (first use in this function)
const uint32_t *cfg = usb_endpoint_config_table;
^

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c:298:25: note: each undeclared identifier is reported only once for each function it appears in
T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4\usb.c:311:23: error: 'CDC_ACM_ENDPOINT' undeclared (first use in this function)
endpoint_queue_head[CDC_ACM_ENDPOINT*2+1].config = (CDC_ACM_ENDPOINT << 16);
 
Updated above posts 2536,2537 - the hang in this case - that looked familiar was not - it was from making a write to a bad spot.
The manual said to expect 4 as RTC NVRAM backed - the first 3 work in above sketch - the odd write to the 4th was trashing something.
> ONLY 2 of the 32 bit words are fully usable

Did 102 cycles of above edited code with USB Power cut and Button Off/On and there were no Issues!

Also note:: If powered T4 is turned OFF with Button - and Battery is installed - removing USB power and then Restoring USB power - leaves the T4 in OFF mode and it comes back on with Power Button press.

No signs of issue when running more valid code.

Good news is I did NOT brick the T4! Though those writes and some hacks did make the 15s Restore hard to come by until the third adjusted iteration.
>> Hack was to manually remove USB INIT to see if I could blame that … that made the T4 very reluctant to even Restore.

Paul - KUDO's again on your methods, abilities and perseverance.
 
Last edited:
I just tried to repeat your experiment using teensy4 to T3.2 with both pins hooked up (Rx/Tx) and am pretty much seeing the same as you. When I turned the power off with the switch the LED went out but the T4 still showed in the Port drop down. So I disconnected the Tx line at the T3.2 end and it then disconnected. I repeated this a couple of times to see if I would get the same result, and yes it is repeatable. I used Serial2 for the test. I then repeated on Serial7 with the same result.

Just wanted to add a bit of additional information regarding when I said "When I turned the power off with the switch the LED went out but the T4 still showed in the Port drop down". I verified this morning the associated com port in device manger still appears for T4 until I remove either the Rx or Tx jumper from the T4.
 
Just wanted to add a bit of additional information regarding when I said "When I turned the power off with the switch the LED went out but the T4 still showed in the Port drop down". I verified this morning the associated com port in device manger still appears for T4 until I remove either the Rx or Tx jumper from the T4.

Oh - Yes - thanks for clarification - I see that as well. Running T4 turned Off with Power button on breakout still shows 'Running' in TyCommander when 'powered by Serial pins'

Paul did note that in the OFF state that the USB unit was powered, but when Off that 'Running' indeed only shows when the there is power on the Serial4 Rx/Tx pins in my current case from T_3.1. If no power on T_3.1 and those pins when it goes Off - it reports 'Missing' in TyComm.

But it will not hit ResetHandler startup {enabled LED13 in ResetHandler } or function when power button pressed to On with that external power.

@mjs513 - you undid my Yellow hiding.
 
@defragster
Oh - I am sorry - thought that was unintentional - I couldn't read it so I make it black. I will put it back - again my apologies.

UPDATE: DONE.. Should have asked first.
 
@mjs513 - No Biggie - you had to read it to see I was confused about the 'usb device active'. RE the Yellow I was misdirected - due to coding error on my part {per the manual as I read it} - but I was taking notes as I was testing so the steps would be clear. I didn't want to delete the post so I just added/did: 'following now in Yellow can be ignored' - so it wouldn't provide bad info.

And that post's first line seems interesting that the Bootloader MCU doesn't take over the 1062 in that state on Button press - or held on power up. I'm really hoping to hear Paul has a good understanding/fix for this - nothing appears to get HOT (or even warm) on the PCB so it isn't in a runaway lockup - it just isn't getting to ResetHandler or responding to Bootloader MCU. Even the 15s Restore cannot kick off, it does a single flash in 15 secs - but nothing after that - I just tried 5 times again - twice again with no vBat.

BTW: Leaving vBat battery in place does not change the situation with power on Serial Pins with the isolated power vBat provides as I mistakenly thought.

I'm just glad I was standing over the board at night with my shadow blocking room light and saw the dim glow on the LED when the Rx/Tx were connected and T_3.1 was powered!
 
I've committed the first code to implement Serial.available() and Serial.read().

https://github.com/PaulStoffregen/cores/commit/7e959d4a14ccfdaae13a7e5fa0d8cec244d44b22

This is still a work-in-progress. It's not efficient. Some functions like Serial.peek() and Serial.readBytes(buffer, len) are still not implemented. But at least basic reception on Serial should be working now.

:D - Just tried it out and now some of my simple tests like for ILI9341_t3n that ask for keyboard hit to continue, now work! :D
 
@Frank B and @mjs513
@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.
Just pushed up change to ILI9341_t3n which hopefully took care of those compiler warnings. As for SD ...
 
:D - Just tried it out and now some of my simple tests like for ILI9341_t3n that ask for keyboard hit to continue, now work! :D

@ PaulStoffregen
I will ditto what @KurtE said. Just tried it echoboth on T4 and USBtoSerial on T3.2 and did some typing and it worked :)

Amazing how little things make us happy and that we miss.
 
@KurtE and others

Look at the SD lib for those functions causing a problem. So I have a C++ question. In NXP_SDHC.cpp the are group defined under a header:
Code:
/******************************************************************************
  Forward declaration of private functions
******************************************************************************/
can I move them to the .h file and just declare them as private?

UPDATE:
ANS: NO. Not it a class.

NOPE - more involved to get rid of all the warnings so... like Kurt said..SD?
 
Last edited:
@KurtE - what Touch code is in the 'ILI9341_t3\examples\breakouttouchpaint\breakouttouchpaint.ino' - where does #include "TouchScreen.h" come from. Why does it use Analog pins? Don't you have ILI9341 with XPT2046 controller? Then in '\ILI9341_t3\examples\touchpaint\touchpaint.ino' it does "#include <Adafruit_STMPE610.h>" … that is just weird :)

Sorry I missed this message (or part of message)... I had to look it up where this breakouttouchpaint.ino came from... I think it must have come from ili9341_t3 library, in my first initial creation of the ili9341_t3n library... (T3.6 beta days)...

This morning with fixing the compiler warnings in my library that @Frank B pointed out, I tried compiling more examples and found that the current IDE is more picky on case sensitivity of header file names...

That is several of the examples did not compile that had: #include <ili9341_t3n.h>
in the main INO file. So updated them to: #include <ILI9341_t3n.h>

To get them to compile... So just ran across this one, which you noted.

It includes: #include <TouchScreen.h>

Which Teensyduino does install.

Code:
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_276200/pch" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\Wire" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ili9341_t3n" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\SPIN" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\TouchScreen" "D:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\TouchScreen\\TouchScreen.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_276200\\libraries\\TouchScreen\\TouchScreen.cpp.o"
D:\arduino-1.8.9\hardware\teensy\avr\libraries\TouchScreen\TouchScreen.cpp: In constructor 'TouchScreen::TouchScreen(uint8_t, uint8_t, uint8_t, uint8_t, uint16_t)':

D:\arduino-1.8.9\hardware\teensy\avr\libraries\TouchScreen\TouchScreen.cpp:184:11: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'RwReg* {aka volatile unsigned char*}' in assignment

   xp_port =  portOutputRegister(digitalPinToPort(_xp));

           ^

D:\arduino-1.8.9\hardware\teensy\avr\libraries\TouchScreen\TouchScreen.cpp:185:11: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'RwReg* {aka volatile unsigned char*}' in assignment

   yp_port =  portOutputRegister(digitalPinToPort(_yp));

           ^

D:\arduino-1.8.9\hardware\teensy\avr\libraries\TouchScreen\TouchScreen.cpp:186:11: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'RwReg* {aka volatile unsigned char*}' in assignment

   xm_port =  portOutputRegister(digitalPinToPort(_xm));

           ^

D:\arduino-1.8.9\hardware\teensy\avr\libraries\TouchScreen\TouchScreen.cpp:187:11: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'RwReg* {aka volatile unsigned char*}' in assignment

   ym_port =  portOutputRegister(digitalPinToPort(_ym));

           ^
And this library is mentioned in the list on the first page...
Looks like it needs to test for the IMXRT (Teensy 4 ) and use 32 bit register sizes...

I am assuming it is this library: https://github.com/PaulStoffregen/TouchScreen
Which I am assuming is some version of the Adafruit one: https://github.com/adafruit/Adafruit_TouchScreen/blob/master/TouchScreen.cpp
As the Readme file in our header mentions adafruit.

So will probably start off by: cloning Paul's library make patch and PR... But probably won't test that it actually works ;) Might require some other version of display without XPT...
Question is, should we compare our version to Adafruits?

EDIT: Actually Paul's library is fork of Adafruit library... There was a couple of other processor defines not in Paul's... So I pulled those in, plus added #if test for the T4 B1/B2 boards and made the register defines 32 bits instead of 8 bits...

https://github.com/PaulStoffregen/TouchScreen/pull/2

If this looks Ok, maybe @Paul - you may want to issue PR back to Adafruit?
 
Last edited:
Status
Not open for further replies.
Back
Top