Teensy 4.0 First Beta Test

Status
Not open for further replies.
Hey Tim, looks like its working if I am reading this right. So, good to go?

PS. Glad you got your T4 working again :)
 
YES, Mike - it seems to be very responsive across the full range of DAC ouput - with errors on my end after the fear of T4 loss ....

Looks like the RECEIVE and OUTPUT are shifted by one ( DOH ) using this more linear test with DAC going 0 to 4096 by 40 - with a CUSP at 4000 to jump 4040 and get a full 4096 to finish:
Code:
T:\arduino-1.8.8T4_146\examples\03.Analog\AnalogInOutSerial\AnalogInOutSerial.ino Jan  5 2019 19:04:44
 T4 RECEIVE >>3989	 output = 0
 T4 RECEIVE >>0	 output = 40
 T4 RECEIVE >>2	 output = 80
 T4 RECEIVE >>4	 output = 120
 T4 RECEIVE >>7	 output = 160
 T4 RECEIVE >>9	 output = 200
 T4 RECEIVE >>12	 output = 240
 T4 RECEIVE >>14	 output = 280
 T4 RECEIVE >>17	 output = 320
 T4 RECEIVE >>19	 output = 360
 T4 RECEIVE >>22	 output = 400
 T4 RECEIVE >>25	 output = 440
 T4 RECEIVE >>27	 output = 480
 T4 RECEIVE >>30	 output = 520
 T4 RECEIVE >>32	 output = 560
 T4 RECEIVE >>35	 output = 600
 T4 RECEIVE >>37	 output = 640
 T4 RECEIVE >>40	 output = 680
 T4 RECEIVE >>42	 output = 720
 T4 RECEIVE >>45	 output = 760
 T4 RECEIVE >>47	 output = 800
 T4 RECEIVE >>50	 output = 840
 T4 RECEIVE >>52	 output = 880
 T4 RECEIVE >>55	 output = 920
 T4 RECEIVE >>57	 output = 960
 T4 RECEIVE >>60	 output = 1000
 T4 RECEIVE >>62	 output = 1040
 T4 RECEIVE >>65	 output = 1080
 T4 RECEIVE >>67	 output = 1120
 T4 RECEIVE >>70	 output = 1160
 T4 RECEIVE >>72	 output = 1200
 T4 RECEIVE >>75	 output = 1240
 T4 RECEIVE >>77	 output = 1280
 T4 RECEIVE >>80	 output = 1320
 T4 RECEIVE >>82	 output = 1360
 T4 RECEIVE >>85	 output = 1400
 T4 RECEIVE >>87	 output = 1440
 T4 RECEIVE >>90	 output = 1480
 T4 RECEIVE >>93	 output = 1520
 T4 RECEIVE >>95	 output = 1560
 T4 RECEIVE >>98	 output = 1600
 T4 RECEIVE >>100	 output = 1640
 T4 RECEIVE >>102	 output = 1680
 T4 RECEIVE >>105	 output = 1720
 T4 RECEIVE >>108	 output = 1760
 T4 RECEIVE >>110	 output = 1800
 T4 RECEIVE >>113	 output = 1840
 T4 RECEIVE >>115	 output = 1880
 T4 RECEIVE >>118	 output = 1920
 T4 RECEIVE >>120	 output = 1960
 T4 RECEIVE >>123	 output = 2000
 T4 RECEIVE >>125	 output = 2040
 T4 RECEIVE >>128	 output = 2080
 T4 RECEIVE >>131	 output = 2120
 T4 RECEIVE >>134	 output = 2160
 T4 RECEIVE >>136	 output = 2200
 T4 RECEIVE >>139	 output = 2240
 T4 RECEIVE >>141	 output = 2280
 T4 RECEIVE >>144	 output = 2320
 T4 RECEIVE >>146	 output = 2360
 T4 RECEIVE >>149	 output = 2400
 T4 RECEIVE >>151	 output = 2440
 T4 RECEIVE >>154	 output = 2480
 T4 RECEIVE >>156	 output = 2520
 T4 RECEIVE >>159	 output = 2560
 T4 RECEIVE >>161	 output = 2600
 T4 RECEIVE >>164	 output = 2640
 T4 RECEIVE >>166	 output = 2680
 T4 RECEIVE >>169	 output = 2720
 T4 RECEIVE >>171	 output = 2760
 T4 RECEIVE >>174	 output = 2800
 T4 RECEIVE >>176	 output = 2840
 T4 RECEIVE >>179	 output = 2880
 T4 RECEIVE >>181	 output = 2920
 T4 RECEIVE >>184	 output = 2960
 T4 RECEIVE >>186	 output = 3000
 T4 RECEIVE >>189	 output = 3040
 T4 RECEIVE >>192	 output = 3080
 T4 RECEIVE >>194	 output = 3120
 T4 RECEIVE >>197	 output = 3160
 T4 RECEIVE >>199	 output = 3200
 T4 RECEIVE >>201	 output = 3240
 T4 RECEIVE >>204	 output = 3280
 T4 RECEIVE >>207	 output = 3320
 T4 RECEIVE >>209	 output = 3360
 T4 RECEIVE >>212	 output = 3400
 T4 RECEIVE >>214	 output = 3440
 T4 RECEIVE >>217	 output = 3480
 T4 RECEIVE >>219	 output = 3520
 T4 RECEIVE >>222	 output = 3560
 T4 RECEIVE >>224	 output = 3600
 T4 RECEIVE >>227	 output = 3640
 T4 RECEIVE >>229	 output = 3680
 T4 RECEIVE >>232	 output = 3720
 T4 RECEIVE >>234	 output = 3760
 T4 RECEIVE >>237	 output = 3800
 T4 RECEIVE >>239	 output = 3840
 T4 RECEIVE >>242	 output = 3880
 T4 RECEIVE >>244	 output = 3920
 T4 RECEIVE >>247	 output = 3960
 T4 RECEIVE >>249	 output = 4000
 T4 RECEIVE >>252	 output = 4056
 T4 RECEIVE >>255	 output = 4096

 T4 RECEIVE >>0	 output = 0
 T4 RECEIVE >>0	 output = 40
 T4 RECEIVE >>9	 output = 80
 T4 RECEIVE >>19	 output = 120
 T4 RECEIVE >>29	 output = 160
 T4 RECEIVE >>39	 output = 200
 T4 RECEIVE >>49	 output = 240
 T4 RECEIVE >>59	 output = 280
 T4 RECEIVE >>70	 output = 320
 T4 RECEIVE >>80	 output = 360
 T4 RECEIVE >>90	 output = 400
 T4 RECEIVE >>99	 output = 440
 T4 RECEIVE >>110	 output = 480
 T4 RECEIVE >>120	 output = 520
 T4 RECEIVE >>130	 output = 560
 T4 RECEIVE >>139	 output = 600
 T4 RECEIVE >>150	 output = 640
 T4 RECEIVE >>160	 output = 680
 T4 RECEIVE >>168	 output = 720
 T4 RECEIVE >>180	 output = 760
 T4 RECEIVE >>190	 output = 800
 T4 RECEIVE >>201	 output = 840
 T4 RECEIVE >>211	 output = 880
 T4 RECEIVE >>221	 output = 920
 T4 RECEIVE >>231	 output = 960
 T4 RECEIVE >>241	 output = 1000
 T4 RECEIVE >>251	 output = 1040
 T4 RECEIVE >>261	 output = 1080
 T4 RECEIVE >>271	 output = 1120
 T4 RECEIVE >>281	 output = 1160
 T4 RECEIVE >>291	 output = 1200
 T4 RECEIVE >>301	 output = 1240
 T4 RECEIVE >>313	 output = 1280
 T4 RECEIVE >>322	 output = 1320
 T4 RECEIVE >>331	 output = 1360
 T4 RECEIVE >>341	 output = 1400
 T4 RECEIVE >>351	 output = 1440
 T4 RECEIVE >>361	 output = 1480
 T4 RECEIVE >>372	 output = 1520
 T4 RECEIVE >>381	 output = 1560
 T4 RECEIVE >>392	 output = 1600
 T4 RECEIVE >>402	 output = 1640
 T4 RECEIVE >>413	 output = 1680
 T4 RECEIVE >>422	 output = 1720
 T4 RECEIVE >>433	 output = 1760
 T4 RECEIVE >>442	 output = 1800
 T4 RECEIVE >>452	 output = 1840
 T4 RECEIVE >>462	 output = 1880
 T4 RECEIVE >>472	 output = 1920
 T4 RECEIVE >>482	 output = 1960
 T4 RECEIVE >>494	 output = 2000
 T4 RECEIVE >>502	 output = 2040
 T4 RECEIVE >>513	 output = 2080
 T4 RECEIVE >>526	 output = 2120
 T4 RECEIVE >>536	 output = 2160
 T4 RECEIVE >>546	 output = 2200
 T4 RECEIVE >>556	 output = 2240
 T4 RECEIVE >>566	 output = 2280
 T4 RECEIVE >>576	 output = 2320
 T4 RECEIVE >>586	 output = 2360
 T4 RECEIVE >>596	 output = 2400
 T4 RECEIVE >>606	 output = 2440
 T4 RECEIVE >>616	 output = 2480
 T4 RECEIVE >>626	 output = 2520
 T4 RECEIVE >>637	 output = 2560
 T4 RECEIVE >>648	 output = 2600
 T4 RECEIVE >>657	 output = 2640
 T4 RECEIVE >>667	 output = 2680
 T4 RECEIVE >>677	 output = 2720
 T4 RECEIVE >>687	 output = 2760
 T4 RECEIVE >>696	 output = 2800
 T4 RECEIVE >>707	 output = 2840
 T4 RECEIVE >>716	 output = 2880
 T4 RECEIVE >>727	 output = 2920
 T4 RECEIVE >>737	 output = 2960
 T4 RECEIVE >>747	 output = 3000
 T4 RECEIVE >>757	 output = 3040
 T4 RECEIVE >>768	 output = 3080
 T4 RECEIVE >>777	 output = 3120
 T4 RECEIVE >>787	 output = 3160
 T4 RECEIVE >>798	 output = 3200
 T4 RECEIVE >>808	 output = 3240
 T4 RECEIVE >>816	 output = 3280
 T4 RECEIVE >>828	 output = 3320
 T4 RECEIVE >>838	 output = 3360
 T4 RECEIVE >>848	 output = 3400
 T4 RECEIVE >>858	 output = 3440
 T4 RECEIVE >>868	 output = 3480
 T4 RECEIVE >>878	 output = 3520
 T4 RECEIVE >>888	 output = 3560
 T4 RECEIVE >>898	 output = 3600
 T4 RECEIVE >>908	 output = 3640
 T4 RECEIVE >>918	 output = 3680
 T4 RECEIVE >>928	 output = 3720
 T4 RECEIVE >>938	 output = 3760
 T4 RECEIVE >>948	 output = 3800
 T4 RECEIVE >>960	 output = 3840
 T4 RECEIVE >>969	 output = 3880
 T4 RECEIVE >>978	 output = 3920
 T4 RECEIVE >>989	 output = 3960
 T4 RECEIVE >>998	 output = 4000
 T4 RECEIVE >>1008	 output = 4056
 T4 RECEIVE >>1022	 output = 4096

 T4 RECEIVE >>0	 output = 0
 T4 RECEIVE >>0	 output = 40
 T4 RECEIVE >>39	 output = 80
 T4 RECEIVE >>79	 output = 120
 T4 RECEIVE >>117	 output = 160
 T4 RECEIVE >>159	 output = 200
 T4 RECEIVE >>197	 output = 240
 T4 RECEIVE >>244	 output = 280
 T4 RECEIVE >>280	 output = 320
 T4 RECEIVE >>320	 output = 360
 T4 RECEIVE >>359	 output = 400
 T4 RECEIVE >>400	 output = 440
 T4 RECEIVE >>438	 output = 480
 T4 RECEIVE >>479	 output = 520
 T4 RECEIVE >>521	 output = 560
 T4 RECEIVE >>561	 output = 600
 T4 RECEIVE >>602	 output = 640
 T4 RECEIVE >>641	 output = 680
 T4 RECEIVE >>681	 output = 720
 T4 RECEIVE >>722	 output = 760
 T4 RECEIVE >>762	 output = 800
 T4 RECEIVE >>802	 output = 840
 T4 RECEIVE >>843	 output = 880
 T4 RECEIVE >>887	 output = 920
 T4 RECEIVE >>923	 output = 960
 T4 RECEIVE >>964	 output = 1000
 T4 RECEIVE >>1003	 output = 1040
 T4 RECEIVE >>1044	 output = 1080
 T4 RECEIVE >>1084	 output = 1120
 T4 RECEIVE >>1125	 output = 1160
 T4 RECEIVE >>1165	 output = 1200
 T4 RECEIVE >>1207	 output = 1240
 T4 RECEIVE >>1245	 output = 1280
 T4 RECEIVE >>1286	 output = 1320
 T4 RECEIVE >>1327	 output = 1360
 T4 RECEIVE >>1366	 output = 1400
 T4 RECEIVE >>1406	 output = 1440
 T4 RECEIVE >>1445	 output = 1480
 T4 RECEIVE >>1486	 output = 1520
 T4 RECEIVE >>1532	 output = 1560
 T4 RECEIVE >>1569	 output = 1600
 T4 RECEIVE >>1608	 output = 1640
 T4 RECEIVE >>1648	 output = 1680
 T4 RECEIVE >>1687	 output = 1720
 T4 RECEIVE >>1728	 output = 1760
 T4 RECEIVE >>1768	 output = 1800
 T4 RECEIVE >>1811	 output = 1840
 T4 RECEIVE >>1849	 output = 1880
 T4 RECEIVE >>1889	 output = 1920
 T4 RECEIVE >>1929	 output = 1960
 T4 RECEIVE >>1970	 output = 2000
 T4 RECEIVE >>2010	 output = 2040
 T4 RECEIVE >>2052	 output = 2080
 T4 RECEIVE >>2103	 output = 2120
 T4 RECEIVE >>2145	 output = 2160
 T4 RECEIVE >>2183	 output = 2200
 T4 RECEIVE >>2225	 output = 2240
 T4 RECEIVE >>2264	 output = 2280
 T4 RECEIVE >>2306	 output = 2320
 T4 RECEIVE >>2346	 output = 2360
 T4 RECEIVE >>2386	 output = 2400
 T4 RECEIVE >>2429	 output = 2440
 T4 RECEIVE >>2466	 output = 2480
 T4 RECEIVE >>2509	 output = 2520
 T4 RECEIVE >>2546	 output = 2560
 T4 RECEIVE >>2587	 output = 2600
 T4 RECEIVE >>2627	 output = 2640
 T4 RECEIVE >>2668	 output = 2680
 T4 RECEIVE >>2709	 output = 2720
 T4 RECEIVE >>2747	 output = 2760
 T4 RECEIVE >>2788	 output = 2800
 T4 RECEIVE >>2828	 output = 2840
 T4 RECEIVE >>2870	 output = 2880
 T4 RECEIVE >>2910	 output = 2920
 T4 RECEIVE >>2949	 output = 2960
 T4 RECEIVE >>2988	 output = 3000
 T4 RECEIVE >>3029	 output = 3040
 T4 RECEIVE >>3069	 output = 3080
 T4 RECEIVE >>3110	 output = 3120
 T4 RECEIVE >>3151	 output = 3160
 T4 RECEIVE >>3189	 output = 3200
 T4 RECEIVE >>3230	 output = 3240
 T4 RECEIVE >>3272	 output = 3280
 T4 RECEIVE >>3309	 output = 3320
 T4 RECEIVE >>3351	 output = 3360
 T4 RECEIVE >>3393	 output = 3400
 T4 RECEIVE >>3431	 output = 3440
 T4 RECEIVE >>3473	 output = 3480
 T4 RECEIVE >>3511	 output = 3520
 T4 RECEIVE >>3552	 output = 3560
 T4 RECEIVE >>3593	 output = 3600
 T4 RECEIVE >>3632	 output = 3640
 T4 RECEIVE >>3674	 output = 3680
 T4 RECEIVE >>3713	 output = 3720
 T4 RECEIVE >>3753	 output = 3760
 T4 RECEIVE >>3795	 output = 3800
 T4 RECEIVE >>3834	 output = 3840
 T4 RECEIVE >>3877	 output = 3880
 T4 RECEIVE >>3914	 output = 3920
 T4 RECEIVE >>3954	 output = 3960
 T4 RECEIVE >>3993	 output = 4000
 T4 RECEIVE >>4035	 output = 4056
 T4 RECEIVE >>4090	 output = 4096
 
Tim
Just wanted to be sure. Just did a double check, analogReadAveraging is defaulted to 4 samples on ADC module initialization. The delta may be do some averaging going on in the ADC. I will go ahead and clean up the code and put in the my core and then do a pull request.

That would me the only thing left is analogReference. To be honest - i'm too nervous about screwing something up that so going to leave to a braver sole than me :)

Tomorrow is playing with the IR remote library trying something with Flexcan.

Mike

EDIT: Tim. Just created PR#317 to update the core :)
 
Good Job Mike!

Indeed the receive values LAG the output in the prints - surprised the code works at all. It was too easy to get close … and too close to bother making it right.

They show the read values do change 8/10/12 bits in range - and also show clear and consistent trend with regularity in increasing across the full range.

Just a quick note - I wrote more code testing than you did in the doing :)github.com/ ... /T4readTwin

<Mike: for my sanity I had to open that prior posted INO - it did have the res change IF conditional in loop() when it got the 'n'/Next command.>
 
Last edited:
ANALOGREADAVERAGING

think I got the analogreadaveraging function working. If someone besides me wants to give it a try here is a standalone copy before I propose the change:
Sorry, I just looked at this and analog.c in github T4 core. It looks to me like it's missing support for disabling averaging, analogReadAveraging(1); (or 0), where you would clear bit 5 in ADCx_GC
 
Morning Tim/Tom
ust a quick note - I wrote more code testing than you did in the doing … github.com/ ... /T4readTwin

<Mike: for my sanity I had to open that prior posted INO - it did have the res change IF conditional in loop() when it got the 'n'/Next command.>
yeah, isn't that always the way. Yeah you are right it was there, when I went through the code the first time didn't realize what you were doing until after you posted. Sometimes it takes awhile for things to sink in.

Sorry, I just looked at this and analog.c in github T4 core. It looks to me like it's missing support for disabling averaging, analogReadAveraging(1); (or 0), where you would clear bit 5 in ADCx_GC
Yeah. To be honest didn't think about it, On init the module defaults to 4 so that was as far I went. Easy enough to change. After coffee and I wake up will give it a try :)

EDIT: Got it. If you put in any number <4 or leave it blank it will disable averaging. If you want to give it a try (note this is my debug version ):
Code:
void aRAveraging(unsigned int num)
{
  uint32_t tmp32, mode, avg=0;
  
  //disable averaging
  tmp32 = ADC1_GC;
  //Serial.println("ADC1_GC :"); Serial.println(ADC1_GC, BIN);
  ADC1_GC &= ~0x20;
  
  //Serial.print("Turn off ADC1_GC :"); Serial.println(ADC1_GC, BIN);
  //Serial.print("Initial ADC1_CFG :"); Serial.println(ADC1_CFG, BIN);

  mode = ADC1_CFG & ~0xC000;
  //Serial.print("Clear bits ADC1_CFG :"); Serial.println(mode, BIN);

    if (num >= 32) {
      mode |= ADC_CFG_AVGS(3);
      //Serial.println(ADC_CFG_AVGS(3), BIN);
    } else if (num >= 16) {
      mode |= ADC_CFG_AVGS(2);
    } else if (num >= 8) {
      mode |= ADC_CFG_AVGS(1);
    } else if (num >= 4) {
      mode |= ADC_CFG_AVGS(0);
    } else {
      mode = 0;
    }

  ADC1_CFG = mode;
  //Serial.print("After avg set :"); Serial.println(ADC1_CFG, BIN);

  
  //enable averaging
  //ADC1_GC &= ~(ADC_GC_AVGE & 0x20);
  if(num > 4)
      ADC1_GC = ADC_GC_AVGE;// turns on averaging
  //Serial.print("Turn on ADC_GC :"); Serial.println(ADC1_GC, BIN);
}
 
Last edited:
For beta7 (coming soonish...), let's try removing -fsingle-precision-constant.

Looking for feedback on the performance hit, for "normal" programming where a "f" suffix is missing.
 
actually it should read

Code:
if(num >=  4)
      ADC1_GC |= ADC_GC_AVGE;// turns on averaging
need to "or" in value, in case other bits are set
 
manitou - are you still having to button press T4 for upload? What OS?

T4 back on the T_ports menu - but now my T_3.6 is gone from there but showing on IDE_Serial_Ports. Just unplugged and replugged USB - Like the T_3.1, the T_3.6 is sending its output to TyComm. For AnalogRead testing I had TLoader closed as the work was on the T_3.6 with TyComm, and TLoader would wake up on each program. As noted the T4 did that the other day - not sure why IDE/TyComm see 'some' Teensy but T_ports does not?

Using that LCD Display fully wired and all is well. I noticed the cheap pin end jumper wire for GND would trigger the display - when the power VCC was off, somehow it was feeding from the data/ctrl pins?

Changing -fsingle-precision-constant sounds like fun - across all 32b Teensy boards?

Went back to the Kurt Serial Cross-loopback test and went to 5 Mbaud between the two active ports it is working, fails at 6 and 8 Mbaud - what is the MAX rate expected? Maybe that is just lost data from Serial code now (FIFO) updated? Message passed is 10-19 bytes and doing over 7100 per second out each port and back in the other in turn with 50 us delay after each ~2-3 MB data/sec total. Doing atol of received string to check for corruption to reduce USB Serial output. Still doing 500K Interval timers, and updating the transfer loop count each second to the LCD display - pushed the 16 bit loop counter to 32 bit - that count is part of the transferred message that is the check.

T4 seems Stable and Fast and everything coded and compiled correctly is working as it should. 21 page thread in a week and no bricked units, and lots of progress - a successful bootloader update and no 15 reset needed here.

Re: - Low Priority - but I have this data now:: T_3.6 not on T_ports list. I unplugged T_3.6 and re-plugged and TLoader enumerated, IDE Serial Board Info displays with '... no serial # until programmed':
Code:
05:02:05.220 (serialmon 206): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
05:02:05.221 (serialmon 206): remove: loc=usb:0/140000/0/1/1
05:02:05.221 (serialmon 206): usb_remove: usb:0/140000/0/1/1
05:02:05.221 (serialmon 206): nothing new, skipping HID & Ports enum
05:02:05.237 (serialmon 206): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
05:02:05.238 (serialmon 206): nothing new, skipping HID & Ports enum
05:02:05.238 (serialmon 206): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
05:02:05.239 (serialmon 206): nothing new, skipping HID & Ports enum
05:02:11.992 (serialmon 206): WM_DEVICECHANGE DBT_DEVICEARRIVAL
05:02:11.993 (serialmon 206): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#2272540#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
05:02:11.993 (serialmon 206): found_usb_device, loc=usb:0/140000/0/1/1    Port_#0001.Hub_#0003
05:02:11.993 (serialmon 206): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0277
05:02:11.993 (serialmon 206): found_usb_device, devinst=00000005
05:02:11.993 (serialmon 206): add: loc=usb:0/140000/0/1/1, class=Ports, vid=16C0, pid=0483, ver=0277, serial=2272540, dev=\\?\usb#vid_16c0&pid_0483#2272540#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
05:02:11.993 (serialmon 206):   comport_from_devinst_list attempt
05:02:11.993 (serialmon 206):   found Ports in classguid_list at index=0
05:02:11.993 (serialmon 206):   port COM11 found from devnode
05:02:11.993 (serialmon 206): found_usb_device complete
05:02:11.995 (serialmon 206): found new COM port, devinst=0000001F
05:02:11.995 (serialmon 206):   portname=COM20
05:02:11.995 (serialmon 206): usb_add: usb:0/140000/0/1/1
05:02:11.995 (serialmon 206): usb_add: usb:0/140000/0/1/3
05:02:11.996 (serialmon 206): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
05:02:11.997 (serialmon 206): nothing new, skipping HID & Ports enum
05:02:12.034 (serialmon 206): WM_DEVICECHANGE DBT_DEVICEARRIVAL
05:02:12.035 (serialmon 206): nothing new, skipping HID & Ports enum
05:02:12.052 (serialmon 206): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
05:02:12.054 (serialmon 206): nothing new, skipping HID & Ports enum

This shows the associated COM #'s:
Lost_T3.6.PNG
 
another "or" fix ADC1_CFG |= mode;
Actually you don't need to do the "or".
Code:
mode = ADC1_CFG & ~0xC000;
retains the lower 12 bits of the ADC1_CFG register (the ones not dealing averaging. Then I'm or'ing that with the averaging bits which are in the upper part of the register. So in effect, when all said and done mode is the ADIC_CFG register. So just need to set ADC1_CFG to mode.
 
manitou - are you still having to button press T4 for upload? What OS?

Yes, button press is required on 2 32-bit linux boxes, one 64-bit linux box, and mac os (i don't use windows much, so i haven't updated its IDE).

I don't think my T4 required button press at first, but i don't know what trauma might have happened. I haven't knowingly shorted anything. T4 is pushed into breadboard. The other observation is: if i've done an upload but not pressed the program button, and then i power down (unplug USB) T4. Then when i repower T4, it is still in its catatonic state and I have to press program button. I've tried holding button for 13 secs, but problem persists. There is NOT a /dev/ttyACMx when T4 is in its catatonic state

But i can still use the T4, so i'm not an unhappy camper.

EDIT: I installed arduino 1.8.8 and teensyduino 1.46-beta6 on Windows 10. I still have to push the program button afer an upload.
 
Last edited:
Actually you don't need to do the "or".
Code:
mode = ADC1_CFG & ~0xC000;
retains the lower 12 bits of the ADC1_CFG register (the ones not dealing averaging. Then I'm or'ing that with the averaging bits which are in the upper part of the register. So in effect, when all said and done mode is the ADIC_CFG register. So just need to set ADC1_CFG to mode.

but you now have the case: mode = 0; hence the need for "|" .... yes?
 
I too did an T4 ADC (12-bit) test with DAC output from a T3.2. I also jumper the DAC output to an INPUT pin on the T4, so I can observe the voltage at which digitalRead goes from 0 to 1 and from 1 to 0 ... just because I can. ;)
Code:
...
         2177  1.754 v 1
         2137  1.722 v 1
         2093  1.686 v 1
         2044  1.647 v 1
         2006  1.616 v 0
         1963  1.582 v 0
         1924  1.550 v 0
...
         1963  1.582 v 0
         2003  1.614 v 0
         2043  1.646 v 1
         2093  1.686 v 1
         2136  1.721 v 1
on T4 transition voltage is about the same (T4 GPIO hysteresis settings?). On other MCU's i usually see a wider difference (hysteresis) in hi-lo and lo-hi transition voltage.

DAC-ADC test I use on Teensy 3's
https://github.com/manitou48/teensy3/blob/master/dacadc.ino
and T3.2 voltage thresholds
Code:
           1960  1965 31448   0 1.584
           2000  2006 32099   0 1.616
           2040  2045 32732   0 1.648
           2080  2086 33381   1 1.681
           2120  2125 34005   1 1.712
           2160  2166 34658   1 1.745
           ..
           1936  1941 31056   1 1.564
           1896  1901 30418   1 1.532
           1856  1860 29773   1 1.499
           1816  1821 29137   1 1.467
           1776  1779 28472   0 1.434
           1736  1740 27841   0 1.402
           1696  1700 27207   0 1.370
T3.2 hysteresis about 200 mv
 
Last edited:
Bugreport: Please read the last posts - Two problems: DMAMEM does funny things, big arrays not possible.

Committed a fix for DMAMEM.

https://github.com/PaulStoffregen/cores/commit/2a7fc906f7710c98692d9d177a8e41a2980fbb92

Looks like we're also facing multiple bugs that make the results very confusing.

1: On Upload, the error message is misleading. If Teensy Loader can't parse the HEX file the error message is "Teensy Loader is unable to read your compiled sketch (r)". But in fact Teensy Loader was able to read the file, but couldn't parse the data. This gets reported the same way as if the file was physically missing. The message should tell you the file was opened, but had an error, ideally which line had the error.

2: The Arduino IDE appears to be translating the filename to a "friendly name", discarding the .HEX suffix. I believe this code in the IDE has the intention of dropping the ".cpp" suffix when the compiler gives errors and the base name is the .ino file of your program (which got .cpp added for the compiler). The IDE should be smarter to do this "friendly name" translation in this case.

3: On Verify, the very first time after starting the IDE, case #1 & #2 are triggered. But then clicking Verify again appears to succeed. Why I do not know. Will investigate these issues later (maybe much later, like 2020 time frame) but writing this now so I can save it on my list of known problems.

This only appears to be an issue when the HEX file is created badly, with a parse error. In this case, the wrong linker script was causing data in a memory range Teensy Loader can't use. Teensy Loader treats illegal addresses as parse errors (that too should probably be reported better to the end user). The commit to github fixes the linker problem, so we should have proper HEX files and not trigger these 3 other bugs.
 
@Paul - I am in the process of splitting up the HardwareSerial objects, such that Serial1, Serial2...Serial8 are in their own source file, along with their buffers, call back functions...

So hopefully when we are done a SerialX object will be included only if the sketch actually uses that object...

Could do a PR for this now if desired, currently that is the only change s in my branch: https://github.com/KurtE/cores/tree/T4_SerialX_Split_Objects

---

Also looking at the SerialEvent1...8 call backs.

I was thinking about doing this in pieces. That is first attempt might not use EventResponder objects, but hopefully work toward them.

What I am thinking is, add a couple (or one with flag), member functions to HardwareSerial, something like: enableSerialEvents, disableSerialEvents (or again could be one with bool).

The HardwareSerial::begin - method would call the enable, so pieces needed to process these would be put in place only if Serial object is begun. l

HardwareSerial::end - would probably call the disable... Might only actually disable, after the queue is empty...

I would also add a call to disableSerialEvents in our default weak SerialEventX functions, as no reason to keep calling it, if the user actually does not do anything with it....

Thoughts for first pass kludge to make it work without necessarily pulling in all objects.

Have static method in HardwareSerial::processSerialEvents and an array of function pointers, with one item per HardwareSerial object (so 8 of them),
Where the processSerialEvents function probably checks if any are set and returns if not, else loops, looking for non-null pointers and call those functions...

Then Each Serial object would have simple function like:
void serial1_process_serialEvent() {
if (Serial1.available()) SerialEvent1();
}


I know I can do most of this with EventResponder - But what I don't know is how to emulate the current functionality. I know that I could probably setup to have each HardwareSerial object have an EventResponder object embedded in it. Could have my above enable/disable functions probably setup the eventResponder to run on the yield calls.

Could have the Receive ISR setup to trigger the responder to trigger probably at the next call to yield.... But what I don't know is how to have it keep calling the users function on each yield, until the Hardware Serial object has no more receive data in it. That is currently the users function has no requirement to process any/all of the data in the corresponding receive buffer...

Thoughts?
 
SAI2 issues

Some update from the SAI front

Trying to get SAI2 working I run into some issues.
first, internal logic (SAI2 triggering DMA seems to work properly)
but I cannot observe any clock signal on the ports

The following code demonstrates this (only SAI1 works as expected (clock on pin23))
I noted from P310 it seems that sel_mclk is for SAI2 is only possible for spdif_clock and others but not saix_clock
but did not succeed to implement this (initSAI1x, initSA2x do not work (no clock on MCLK ports)

no idea wat I'm missing
Code:
// some missing macros/definitions
#define CCM_ANALOG_PLL_AUDIO_POST_DIV_SELECT(n) ((uint32_t)(((n) & 0x03)<<19)) 
#define CCM_ANALOG_PLL_AUDIO_BYPASS ((uint32_t)(1<<16)) 
#define CCM_ANALOG_PLL_AUDIO_BYPASS_CLK_SRC(n) ((uint32_t)(((n) & 0x03)<<14)) 
#define CCM_ANALOG_PLL_AUDIO_ENABLE ((uint32_t)(1<<13)) 
#define CCM_ANALOG_PLL_AUDIO_POWERDOWN ((uint32_t)(1<<12)) 
#define CCM_ANALOG_PLL_AUDIO_DIV_SELECT(n) ((uint32_t)((n) & ((1<<6)-1))) 

#define CCM_ANALOG_MISC2_DIV_MSB (1u<<23)
#define CCM_ANALOG_MISC2_DIV_LSB (1u<<15)

#define CCM_ANALOG_PLL_AUDIO_NUM_MASK (((1<<29)-1)) // should it be 30 ?
#define CCM_ANALOG_PLL_AUDIO_DENOM_MASK (((1<<29)-1)) // should it be 30?

#define CCM_CSCMR1_SAI1_CLK_SEL_MASK (CCM_CSCMR1_SAI1_CLK_SEL(0x07))
#define CCM_CS1CDR_SAI1_CLK_PRED_MASK (CCM_CS1CDR_SAI1_CLK_PRED(0x07))
#define CCM_CS1CDR_SAI1_CLK_PODF_MASK (CCM_CS1CDR_SAI1_CLK_PODF(0x3f))

#define CCM_CSCMR1_SAI2_CLK_SEL_MASK (CCM_CSCMR1_SAI2_CLK_SEL(0x03))
#define CCM_CS2CDR_SAI2_CLK_PRED_MASK (CCM_CS2CDR_SAI2_CLK_PRED(0x07))
#define CCM_CS2CDR_SAI2_CLK_PODF_MASK (CCM_CS2CDR_SAI2_CLK_PODF(0x3f))

#define CCM_CSCMR1_SAI3_CLK_SEL_MASK (CCM_CSCMR1_SAI3_CLK_SEL(0x03))
#define CCM_CS1CDR_SAI3_CLK_PRED_MASK (CCM_CS1CDR_SAI3_CLK_PRED(0x07))
#define CCM_CS1CDR_SAI3_CLK_PODF_MASK (CCM_CS1CDR_SAI3_CLK_PODF(0x3f))

#define CCM_CDCDR_SPDIF0_CLK_SEL_MASK (CCM_CDCDR_SPDIF0_CLK_SEL(0x03))
#define CCM_CDCDR_SPDIF0_CLK_PRED_MASK (CCM_CDCDR_SPDIF0_CLK_PRED(0x07))
#define CCM_CDCDR_SPDIF0_CLK_PODF_MASK (CCM_CDCDR_SPDIF0_CLK_PODF(0x07))

int nfact=32;
int nmult=0;
int ndiv=1;
int n1=4;
int n2=8;

void initPLL4(void)
{
 // sets PLL4
  CCM_ANALOG_PLL_AUDIO = 0;
  //CCM_ANALOG_PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_BYPASS;
  CCM_ANALOG_PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_ENABLE;
  CCM_ANALOG_PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_POST_DIV_SELECT(2); // 0: 1/4; 1: 1/2; 0: 1/1
  CCM_ANALOG_PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_DIV_SELECT(nfact);    
  
  CCM_ANALOG_PLL_AUDIO_NUM   = nmult &CCM_ANALOG_PLL_AUDIO_NUM_MASK;
  CCM_ANALOG_PLL_AUDIO_DENOM = ndiv &CCM_ANALOG_PLL_AUDIO_DENOM_MASK;
  
  CCM_ANALOG_MISC2 &= ~(CCM_ANALOG_MISC2_DIV_MSB | CCM_ANALOG_MISC2_DIV_LSB);
 }
void initSAI1(void)
{ 
  CCM_CCGR5 |= CCM_CCGR5_SAI1(CCM_CCGR_ON);
  // clear SAI1_CLK register locations
  CCM_CSCMR1 &= ~(CCM_CSCMR1_SAI1_CLK_SEL_MASK);
  CCM_CS1CDR &= ~(CCM_CS1CDR_SAI1_CLK_PRED_MASK | CCM_CS1CDR_SAI1_CLK_PODF_MASK);
  //
  CCM_CSCMR1 |= CCM_CSCMR1_SAI1_CLK_SEL(2); // &0x03 // (0,1,2): PLL3PFD0, PLL5, PLL4,  
  CCM_CS1CDR |= CCM_CS1CDR_SAI1_CLK_PRED(n1-1); // &0x07
  CCM_CS1CDR |= CCM_CS1CDR_SAI1_CLK_PODF(n2-1); // &0x3f   
  
  CORE_PIN23_CONFIG = 3;  //1:MCLK
  IOMUXC_GPR_GPR1 &= ~(IOMUXC_GPR_GPR1_SAI1_MCLK1_SEL_MASK);
  IOMUXC_GPR_GPR1 |= (IOMUXC_GPR_GPR1_SAI1_MCLK_DIR | IOMUXC_GPR_GPR1_SAI1_MCLK1_SEL(0));
}

void initSAI2(void)
{
  CCM_CCGR5 |= CCM_CCGR5_SAI2(CCM_CCGR_ON);

  // clear SAI2_CLK register locations
  CCM_CSCMR1 &= ~(CCM_CSCMR1_SAI2_CLK_SEL_MASK);
  CCM_CS2CDR &= ~(CCM_CS2CDR_SAI2_CLK_PRED_MASK | CCM_CS2CDR_SAI2_CLK_PODF_MASK);
  //
  CCM_CSCMR1 |= CCM_CSCMR1_SAI2_CLK_SEL(2); // &0x03 // (0,1,2): PLL3PFD0, PLL5, PLL4,  
  CCM_CS2CDR |= CCM_CS2CDR_SAI2_CLK_PRED(n1-1); // &0x07
  CCM_CS2CDR |= CCM_CS2CDR_SAI2_CLK_PODF(n2-1); // &0x3f   
  //
  CORE_PIN5_CONFIG = 3;  //2:MCLK
  IOMUXC_GPR_GPR1 &= ~(IOMUXC_GPR_GPR1_SAI2_MCLK3_SEL_MASK);
  IOMUXC_GPR_GPR1 |= (IOMUXC_GPR_GPR1_SAI2_MCLK_DIR | IOMUXC_GPR_GPR1_SAI2_MCLK3_SEL(0)); 
}

void initSAI1x(void) // try to derive SAI_MCLK from ccm.spdif0_clk_root (P310)
{
  CCM_CCGR5 |= CCM_CCGR5_SPDIF(CCM_CCGR_ON);
  
  // clear SPDIF0_CLK register locations
  CCM_CDCDR &= ~(CCM_CDCDR_SPDIF0_CLK_SEL_MASK);
  CCM_CDCDR &= ~(CCM_CDCDR_SPDIF0_CLK_PRED_MASK | CCM_CDCDR_SPDIF0_CLK_PODF_MASK);
  //
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_SEL(0); // &0x03 // (0,1,2): PLL4, PLL3PFD2, PLL5  
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_PRED(n1-1); // &0x07
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_PODF(n2-1); // &0x3f 
  //
  CORE_PIN23_CONFIG = 3;  //1:MCLK
  IOMUXC_GPR_GPR1 &= ~(IOMUXC_GPR_GPR1_SAI1_MCLK3_SEL_MASK);
  IOMUXC_GPR_GPR1 |= (IOMUXC_GPR_GPR1_SAI1_MCLK_DIR | IOMUXC_GPR_GPR1_SAI1_MCLK3_SEL(0));
}

void initSAI2x(void) // try to derive SAI_MCLK from ccm.spdif0_clk_root (P310)
{
  CCM_CCGR5 |= CCM_CCGR5_SPDIF(CCM_CCGR_ON);
  
  // clear SPDIF0_CLK register locations
  CCM_CDCDR &= ~(CCM_CDCDR_SPDIF0_CLK_SEL_MASK);
  CCM_CDCDR &= ~(CCM_CDCDR_SPDIF0_CLK_PRED_MASK | CCM_CDCDR_SPDIF0_CLK_PODF_MASK);
  //
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_SEL(0); // &0x03 // (0,1,2): PLL4, PLL3PFD2, PLL5  
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_PRED(n1-1); // &0x07
  CCM_CDCDR |= CCM_CDCDR_SPDIF0_CLK_PODF(n2-1); // &0x3f 
  //
  CORE_PIN5_CONFIG = 3;  //2:MCLK
  IOMUXC_GPR_GPR1 &= ~(IOMUXC_GPR_GPR1_SAI2_MCLK3_SEL_MASK);
  IOMUXC_GPR_GPR1 |= (IOMUXC_GPR_GPR1_SAI2_MCLK_DIR | IOMUXC_GPR_GPR1_SAI2_MCLK3_SEL(0));
}

void setup() {
  // put your setup code here, to run once:
  int isel=1; // select mode (0,1,2,3)

  initPLL4();
  if(isel==0)
    initSAI1(); // works (24 MHz on pin23)
  else if(isel==1)
    initSAI2(); // works (no clock on pin 5)
  else if(isel==2)
    initSAI1x(); // works (no clock on pin 23)
  else if(isel==3)
    initSAI2x(); // works (no clock on pin 5)
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);

}
 
Last edited:
I know I can do most of this with EventResponder - But what I don't know is how to emulate the current functionality. I know that I could probably setup to have each HardwareSerial object have an EventResponder object embedded in it. Could have my above enable/disable functions probably setup the eventResponder to run on the yield calls.

Could have the Receive ISR setup to trigger the responder to trigger probably at the next call to yield.... But what I don't know is how to have it keep calling the users function on each yield, until the Hardware Serial object has no more receive data in it. That is currently the users function has no requirement to process any/all of the data in the corresponding receive buffer...

Ah yes, that's a very good point. This probably needs to be done with another level of callback, where the EventResponder calls a function within the HardwareSerial class. Then that function calls serialEvent(), and after the serialEvent() function returns, if there's still data in the receive buffer after the user's serialEvent ran, it would again trigger the EventResponder to repeat this process on the next yield (or on some near-future yield).

Yeah, that's kinda convoluted, but I don't see a lot of other options.

Maybe if the files are arranged properly the user serialEvent function can be checked for NULL like Arduino does in their AVR core lib, and most of this can be skipped if the serialEvent function doesn't exist? Might even be worthwhile to create the EventResponder on the heap with malloc() or new, since the most common case will be serialEvent undefined by the user.

Could do a PR for this now if desired, currently that is the only change s in my branch: https://github.com/KurtE/cores/tree/T4_SerialX_Split_Objects

Whenever is convenient for you is perfectly fine.

I'm pretty far behind where I wanted to be this weekend... lost some time on Friday, catching up now. I'm considering a beta7 installer before doing anything major on USB or Audio, to roll up the many little fixes and ported libs before changing too much other stuff.
 
Another sort of generic question: What state to set IO pins when you call some subsystems ::end method

Examples: Serial1.end(), SPI.end(), Wire.end()

For Teensy 3 - Many of them did something different. Like some of the Serial objects tried to setup the TX and RX pins to a GPIO pin:
like:
Code:
void serial_end(void)
{
	if (!(SIM_SCGC4 & SIM_SCGC4_UART0)) return;
	while (transmitting) yield();  // wait for buffered data to send
	NVIC_DISABLE_IRQ(IRQ_UART0_STATUS);
	UART0_C2 = 0;
	switch (rx_pin_num) {
		case 0:  CORE_PIN0_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		case 21: CORE_PIN21_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		#if defined(KINETISL)
		case 3:  CORE_PIN3_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		case 25: CORE_PIN25_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		#endif
		#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
		case 27: CORE_PIN27_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		#endif
	}
	switch (tx_pin_num & 127) {
		case 1:  CORE_PIN1_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
		case 5:  CORE_PIN5_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); break;
...

others simply just set the state to disabled... Example:
Code:
void SPIClass::end()
{
	volatile uint32_t *reg;

	reg = portConfigRegister(hardware().mosi_pin[mosi_pin_index]);
	*reg = 0;
	reg = portConfigRegister(hardware().miso_pin[miso_pin_index]);
	*reg = 0;
	reg = portConfigRegister(hardware().sck_pin[sck_pin_index]);
	*reg = 0;
	port().MCR = SPI_MCR_MDIS | SPI_MCR_HALT | SPI_MCR_PCSIS(0x1F);
}

Wire is like SPI here as well.

So far I am not seeing us doing anything on T4 yet. So question is what should we do? Try to emulate T3, where each type is different?

EDIT: Also what is a disabled and/or default state on T4 0?

EDIT2: I know looking at the PDF file that for some of these pins the default is MUX_MODE = 5, could default to this, or could build that into my HardwareTable (SerialX objects). Probably likewise for Wire, SPI...
 
but you now have the case: mode = 0; hence the need for "|" .... yes?
@manitou

Actually, in my schema mode=0 is wrong. It really should be mode |= 0 to make it work right. I changed that. I also tested ADC1_CFG |= mode; it gives the exact same bit field as ADC1_CFG = mode;. Probably do the "or" for clarity.

The one thing I noted and forgot is that AVGS bits can only be 4(00), 8(01), 16(10), and 32(11) samples. So if I set mode to 0 it defaults to 4 samples. What controls averaging is the GC bit to enable or disable it.

@tonton81 gave me a couple of suggestions as well so I have to clear up the code and will issue a PR with the updates
 
Something is wrong with DMA..
I tried my "fillscreen" all the time, and indeed it worked.
Well, in fact it filled the screen with same *wrong* adresses in the buffer - was not visible because it had the same contents.. The same code worked for 3.6, so there must be some difference in the hardware..

Edit:
..or..not..it was a cached TCD, I think.

solved.
 
Last edited:
Re: analogWrite() anomalies

In my testing pin 0 and pin 1 PWM are inverted??? There is a polarity bit in OCTRL, but that is zero'd, so it should be OK. So as a hack, I reversed polarity for pins 0 and 1 in flexpwmWrite() in hardware/teensy/avr/cores/teensy4/pwm.c
Code:
void flexpwmWrite(IMXRT_FLEXPWM_t *p, unsigned int submodule, uint8_t channel, uint16_t val)
{
    uint16_t mask = 1 << submodule;
    uint32_t modulo = p->SM[submodule].VAL1;
    uint32_t cval = ((uint32_t)val * (modulo + 1)) >> analog_write_res;
    if (cval > modulo) cval = modulo; // TODO: is this check correct?

    //printf("flexpwmWrite, p=%08lX, sm=%d, ch=%c, cval=%ld\n",
        //(uint32_t)p, submodule, channel == 0 ? 'X' : (channel == 1 ? 'A' : 'B'), cval);
    p->MCTRL |= FLEXPWM_MCTRL_CLDOK(mask);
    switch (channel) {
      case 0: // X
        p->SM[submodule].VAL0 = cval;
        [B]p->SM[submodule].OCTRL =  FLEXPWM_SMOCTRL_POLX;[/B]
        p->OUTEN |= FLEXPWM_OUTEN_PWMX_EN(mask);
        //printf(" write channel X\n");
        break;
      case 1: // A
...
that seemed to fix duty polarity on pins 0 and 1. Doesn't make sense (is there an errata?), and there may be a better fix.

Just for the record, I tested all the T4 PWM edge pins with analogWrite(pin,64) and confirmed that all have proper 25% high duty, except pins 0 and 1, where waveform is inverted. I suspect pins 24 and 25 on the backside would have inverted waveforms like pins 0 and 1 since they are PWM1_Xn pins. Adding
p->SM[submodule].OCTRL = FLEXPWM_SMOCTRL_POLX;
to pwm.c as noted above seems to fix the inversion problem with pins 0 and 1 (and presumably with pins 24 and 25).
 
does anyone have the nanos() code i can play with? i think the chip is too fast to do speed tests on variables, as micros/millis never change when im testing floats
Also there doesnt seem to be a code limit size break in the IDE, always shows 1% program and 6% global variables, at a certain point i tried to exagerate as a test 10000 floats and doubles, and the T4 didn't lock up but went into a reboot-loop, so the post data was scrolling on Serial4 over and over and over and over. I didn't need to hit reset though to reprogram :)
 
Status
Not open for further replies.
Back
Top