Switching Product from T3.5 to T4.1

G

Gremlin

Active member
I'm starting to work on switching my product from the T3.5 to the T4.1 for obvious reasons.
I've shipped almost 350 units with T3.5 but I am down to my last 20(ish) T3.5's on hand.

Here are the areas of concern I have with functionality that I'm using with the T3.5.
I'm trying to find and research all the differences with the T4.1 and head off any major gotchas.
I have read a lot of forum posts on the areas below but here are my thoughts.

Dev Environment: Currently using Arduino 1.8.8 & TeensyDuino 1.4.5: I plan on upgrading to the latest on both. Hopefully no breaking changes with my 8k+ lines of existing code?? I hate the way all the libraries get upgraded/changed with no easy way to lock them to a specific version without making my own copies of all them. Maybe there is a better way..

Lack of 5V tolerance: I am adding a few level shifters to my board to take care of this. No prob.

ADC/AREF: I have been using AREF pin with a TI precision 3.3V ref. (This possibly has always been overkill but it works)
Code: 
analogReference(EXTERNAL); analogReadRes(16); analogReadAveraging(32)
T4.1 doesnt have AREF.
I'm trying to decide if switching to the T4.1's onboard 3.3V for my application is going to be fine and if the 12bit max(10bit practical) is going to be good enough. Application is reading a 10k precision String Pot for distance measurements. I will be testing this soon. I have thought about adding external ADC..

EEPROM: Code changes necessary? Looks like it may work exactly the same as is..

RTC: I currently use a Touchscreen to enter Date/Time so the user can set it.
Using this code with <TimeLib.h>
Code: 
dateTimeSetting = makeTime(dateTimeElements);
Teensy3Clock.set(dateTimeSetting); setTime(dateTimeSetting);

RawHID: I talk to T3.5 using rawHID from a C# App. I also flash FW using my custom app.I embed my .HEX file into app source code. Is this going to be possible with the T4.1 or are there breaking changes with the way they are flashed that would make this impossible? I did see reference to the same 4 magik bytes used for T4.0.

RA8875: It looks like there has been enough work done on the libraries to make this work with T4.1.

I'm not looking for exact answers for any of this as I know I didn't provide enough info in some cases. I'm just throwing this out there to get any helpful tips or areas that I may be overlooking here at the start of the changeover from T3.5 to T4.1.
 
Current most tested IDE is 1.8.19 and TeensyDuino 1.56 with 1.57 about to show up as Beta 1, so using that any 'PJRC' issues might get addressed in short order, but going to that 1.57b1 perhaps best to get current code support for T_4.1.

The T_4.1 MCU built for speed so ADC takes a backseat, functional for sure, but 600 MHz core doesn't put that front and center and indeed, 3.3V limitations versus T_3.5.

EEPROM and other common Arduino functionality is ideally made seamlessly compatible as spec'd for size, including high level TimeLib support with RTC, and RawHID.

Self programming may require edits most likely - perhaps following non-PJRC supported 'Flasher' code thread(s) that others have evolved?

For sure work on displays has taken place, maybe some added functionality if needed.

YMMV, other exact answers limited to "2+2=4" and "42" :), without specific questions that may arise.

Overall bigger (resources), better, faster - with some altered details.
 
Not sure what all more I can add here, but

RA8875 - Yes should work the same. Probably played more with the code using T4.x than I have with T3.x

RawHid - By default should work the same. However it can work a whole lot better. That is I experimented with using the whole possible buffer on T4.x
That is 512 byte buffers. More details up in a Pull Request (https://github.com/PaulStoffregen/cores/pull/629) that I suspect will not be
integrated. If this were to be incorporated, there may still be some issues on the host software on them being able to detect that I am using larger USB packets.

That is instead of sending 64 byte packets, it sends the whole 512 byte packets... But on the host side you need to know that the end points connected are for 512...
I also have code in the USBHost_t36 that could detect this and could get as expected about an 8 times speed up.

No idea on reflashing, although I can easily imagine it would be possible.
 
Thank you all for the helpful info.
There are more pin changes than I originally anticipated. I hadn't looked into the T4.1 much until deciding that it was about the only way to go based on availability.
Its a bummer that pin 14 isn't available for SCK because of course that's what I used to keep 13 free for status led. I never liked using 13 for SPI since it had the LED.
I think I can use my current PCB for testing by getting rid of using 13 for status and then just tieing 13&14 together for

That is interesting info on the RawHID. I transfer files off the SD card to my windows app so the speedup could be extremely helpful. Ill have to see if I can get the larger packets working.

I have completely updated my entire toolchain to Arduino 1.8.19, teensyduino 1.56, and latest vMicro for VS. Took some work but at at least I have everything back compiling for the 4.1 now.

I have looked at the "flasher" posts and the self flashing is interesting but I would like to just mimic what the TeensyLoader does like I'm doing with the T3.5. Hopefully that is still achievable with the 4.1.

I noticed some Differential ADC measurement examples in the ADC library. Curious if I could get better results using (2) analog pins on the 4.1 or if those examples are for T3.x or ??. I haven't dug into it yet.

Is there a way to read the VBAT pin's voltage with an internal ADC or register? I've always used VBAT for RTC with T3.5 and wanted to give user a readout on Voltage but now sounds like a good time to do it. I could even add some external circuitry if needed since I'm having to rev the PCB as well. I don't want any drain on my battery while system is powered down though. I use a rechargeable lithium 3v cell and it charges while system is powered on.
 
You must log in or register to reply here.
Back
Top