Teensy 4.0 First Beta Test

Status
Not open for further replies.
is changing the PWM frequency going to still be available?

Yes. The FlexPWM and Quad timers are identical in the 1052 and 1062 chips.

The pin mapping for pins 5, 6, 7, 8, 33 changed, but the PWM is identical, just moved to other pins. Pins 30 & 31 also changed (for access to the 3rd CAN port), so those pins no longer have PWM.


Hint: the library is LPC speech synth and currently uses only ~26K of flash, and ~5K of RAM. :)

Wow, that sounds pretty awesome.
 
I did another update of uSDFS to reduce the compiler warnings.

For what I'm concerned concerning MSC-USBHost (USB disks) there seems to be some instabilities.
In other words, Teensy does not always behave as expected: enumeration sometimes needs a lot of time, program hangs from time to time, or dies with rc error. In principle, I see all symptoms that are also reported also by others.
So more work is needed.
Unfortunately, my knowledge in USB programming is close to zero, so I hope for @WWatson and other experts to fill the gap.
@WMXZ and @WWatson and others -

I have been doing a little debugging of the hang.. I have added a bunch of print statements in the code, specifically in the MSCInit code... Here is current debug output:
Code:
## mscInit Called
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 40 0C 09 00 10 00 11 01 02 00 01 
    VendorID = 090C, ProductID = 1000, Version = 1100
    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: SMI Corporation
enumeration:
Product: USB DISK
enumeration:
Config data length = 32
enumeration:
Configuration Descriptor:
  09 02 20 00 01 01 00 80 FA 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 02 08 06 50 00 
    Interface = 0
    Number of endpoints = 2
    Class/Subclass/Protocol = 8(Mass Storage) / 6(SCSI) / 80(Bulk Only)
  07 05 81 02 00 02 FF 
    Endpoint = 1 IN
    Type = Bulk
    Max Size = 512
    Polling Interval = 255
  07 05 02 02 00 02 FF 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 512
    Polling Interval = 255
enumeration:
USBHub memory usage = 960
USBHub claim_device this=200045E0
msController claim this=200049C0
Descriptor 4 = INTERFACE
msController claim this=200049C0
09 04 00 00 02 08 06 50 00 07 05 81 02 00 02 FF 07 05 02 02 00 02 FF 
endpointType = 2
numendpoint=2
endpointIn=81
endpointOut=2
packet size in (msController) = 512
packet size out (msController) = 512
polling intervalIn = 255
polling intervalOut = 255
new_Pipe
new_Pipe
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
## mscInit after available
## mscInit after reset
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
## mscInit after msgGetMaxLun
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
## mscInit before startstopunit
msController CallbackOut (static)
transfer->qtd.token = 1
msController dataOut (static)
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static)
## mscInit before media ready
msController CallbackOut (static)
transfer->qtd.token = 1
msController dataOut (static)
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static)
## mscInit before DeviceInquiry
## msDeviceInquiry before do command 36
msController CallbackOut (static)
transfer->qtd.token = 1
msController dataOut (static)
msDoCommand after msOutCompleted loop
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static)
msDoCommand after msInCompleted loop
So I know it is getting down to the DeviceInquiry call

Which the msDoCommand (called by DeviceInquiry..)
Code:
uint8_t msController::msDeviceInquiry(msInquiryResponse_t * const Inquiry)
{
	msCommandBlockWrapper_t CommandBlockWrapper = (msCommandBlockWrapper_t)
	{
		.Signature          = CBWSIGNATURE,
		.Tag                = ++CBWTag,
		.TransferLength     = sizeof(msInquiryResponse_t),
		.Flags              = CMDDIRDATAIN,
		.LUN                = 0,
		.CommandLength      = 6,
		.CommandData        = {CMDINQUIRY,0x00,0x00,0x00,0x00,0x00}
	};
	Serial.printf("## msDeviceInquiry before do command %u\n", sizeof(msInquiryResponse_t) );
	uint8_t retval =  msDoCommand(&CommandBlockWrapper, Inquiry);
	Serial.printf("## msDeviceInquiry after do command %u\n", retval );
	return retval;
}
...
uint8_t msController::msDoCommand(msCommandBlockWrapper_t *CBW,	void *buffer)
{
	if(CBWTag == 0xFFFFFFFF)
		CBWTag = 1;
	if((CBW->Flags == CMDDIRDATAIN)) { // Data from device
		if (!queue_Data_Transfer(datapipeOut, CBW, sizeof(msCommandBlockWrapper_t), this)) {
			println("msController::msDoCommand QDT failed CMDDIRDATAIN OUT");
		}
		if (!queue_Data_Transfer(datapipeIn, buffer, CBW->TransferLength, this)) {
			println("msController::msDoCommand QDT failed CMDDIRDATAIN IN");			
		}
		while(!msOutCompleted);  // Wait for out transaction to complete.
		println("msDoCommand after msOutCompleted loop");
		while(!msInCompleted);  // Wait for in transaction to complete.
		println("msDoCommand after msInCompleted loop");
	} else { // Data to device
		if (!queue_Data_Transfer(datapipeOut, CBW, sizeof(msCommandBlockWrapper_t), this)) {
			println("msController::msDoCommand QDT failed ELSE OUT");			
		}
		while(!msOutCompleted);  // Wait for out transaction to complete.
		if (!queue_Data_Transfer(datapipeOut, buffer, CBW->TransferLength, this)) {
			println("msController::msDoCommand QDT failed ELSE OUT 2");			
		}
		while(!msOutCompleted);  // Wait for second out transaction to complete.
	}
	// Reset completion flags. 
 	msOutCompleted = false;
	msInCompleted = false;
	return msGetCSW();  // Get status of last transaction
}
So I know that it has made it out of the two loops, so looks like it is getting hung in msGetCSW as not getting the print statement after the call... So now to see what is happening
there...

EDIT: wondering about msGetCSW call:
Code:
uint8_t msController::msGetCSW() {
	uint8_t CSWResult = 0;
	msCommandStatusWrapper_t StatusBlockWrapper = (msCommandStatusWrapper_t)
	{
		.Signature = CSWSIGNATURE,
		.Tag = 0,
		.DataResidue = 0, // TODO: Proccess this if received.
		.Status = 0
	};
	println("msGetCSW before QDT");
	if (!queue_Data_Transfer(datapipeIn, &StatusBlockWrapper, sizeof(StatusBlockWrapper), this)) {
		println("msController::msGetCSW QDT failed");
	}
	println("msGetCSW after QDT");
	while(!msInCompleted);
	msInCompleted = false;
	CSWResult = checkCSW(&StatusBlockWrapper);
	return CSWResult;
}
It is looking like it is setting up to return buffer that it pushes on to the input pipe and then expects the input pipe to return some data for the status information.
Need to remember how some of this works....
 
Last edited:
Yes. The FlexPWM and Quad timers are identical in the 1052 and 1062 chips.

The pin mapping for pins 5, 6, 7, 8, 33 changed, but the PWM is identical, just moved to other pins. Pins 30 & 31 also changed (for access to the 3rd CAN port), so those pins no longer have PWM.

Excellent! Good to know it will work across the entire ARM based toys. :)

Wow, that sounds pretty awesome.

It actually harks back to the 1980's type speech synth. Does fairly well with direct text, but can be also programmed to do specialized pronunciation, or if you use sort-of phonetic spellings, will do that too. It can sing as well. :O)
 
xxxajk - yeah my bing search noted an 80's Atari machine - that was why I mentioned a better Talkie - as opposed to it's limited exisiting sample set.

Quick note for TyCommander users - @koromix did provide a working Windows update for the T4B2 id. It was a folder with only Win - exe's - and I don't see source updates so I let him know it worked and sent him a verbose log.

It can upload and execute bootloader and reset from GUI. On Windows it is getting 90-150 lines per sec. But UI so throttled it is hard to select text without taking 'Serial' offline to pause the buffer I/O - but at least you can do that on TyComm !

The minimal output lps_text.exe last run lines show 200 to 225 K l/s - but then it just dropped again without notice? T4B2 still running - so it is just windows glitch?
 
It actually harks back to the 1980's type speech synth. Does fairly well with direct text, but can be also programmed to do specialized pronunciation, or if you use sort-of phonetic spellings, will do that too. It can sing as well. :O)
I look forward to playing with your voice synth lib. There also are several threads on the teensy forum on a text-to-speech lib based on phonemes (search for TTS)
 
I look forward to playing with your voice synth lib. There also are several threads on the teensy forum on a text-to-speech lib based on phonemes (search for TTS)

Aware of them. I plan on making this one cooperate with the audio library, as an audio source. That way additional filters may be used, along with mixing, etc.
 
CANFD/CAN20

@Paul and others interested in CANFD using the breakout board.

Found the big part of the problem. It appears that the lettering on the breakout board is incorrect. CANH is the middle pin and CANL is to the right. GND is correct. After I swapped connections to the EVK was able to transmit a message to the EVB board no problem. I also wrung the connections out to the MCP2558FD chip. At least I know now that it will work once I work the s/w bugs out. :)
 
Will be interesting to see the Audio library with voices and speech.

@mjs513 - glad you discovered the CAN wire;s bad silkscreen notes :( - no wonder it was not working for you.

I was busy yesterday revamping my home network and setting up hardware like it to install somewhere. Just had a 67 minute test Skype call with my Mom and Brother and it worked better - new router and my three WiFi units better spreadout so I could walk around inside and outside without dropping video.

So the Teensy spent 2 thousand seconds short of a day transferring 409.6 BILLION bytes with one visible lost line shift but none detected - 10 million 4K buffers of 63 alpha A-Y letter strings with \n, and then the 62 char Z line preceded by a \t and reduced output of only 3200 lines like this where it prints a line every 200,000 tested for the \n recurrence:
Code:
#99468750[4K] : __>>    ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ << >0> Good lines=____64
#99500000[4K] : __>> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB << >0> Good lines=____64
#99531250[4K] : __>> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD << >0> Good lines=____64
#99562500[4K] : __>> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF << >0> Good lines=____64
#99593750[4K] : __>> HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH << >0> Good lines=____64
#99625000[4K] : __>> JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ << >0> Good lines=____64
#99656250[4K] : __>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL << >0> Good lines=____64
#99687500[4K] : __>> NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN << >0> Good lines=____64
#99718750[4K] : __>> PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP << >0> Good lines=____64
#99750000[4K] : __>> RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR << >0> Good lines=____64
#99781250[4K] : __>> TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT << >0> Good lines=____64
#99812500[4K] : __>> VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV << >0> Good lines=____64
#99843750[4K] : __>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX << >0> Good lines=____64
#99875000[4K] : __>>    ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ << >0> Good lines=____64
#99906250[4K] : __>> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB << >0> Good lines=____64
#99937500[4K] : __>> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD << >0> Good lines=____64
#99968750[4K] : __>> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF << >0> Good lines=____64
#99999999[4K] : __>> VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV << >0> Good lines=____64
 ------  elapsed time 84125.735 secs for 400000000 KBytes

Since the lines are equal byte length the lps_test.exe is up to the task of doing the space checking of chars between newlines with each buffer holding the expected 64 sets of 64 chars.
The above pattern maintained through the lines printed.
Except the first 200 output lines were showing the 'A' and 'Y' lines for the first 200 lines - then it missed a line apparently and went to the 'B' to 'Z' repeat for the last 3,000 lines.

Paul: If this math is right 409B chars/84K secs is 4.87 MegaBytes/second and 10M buffers of 64 newlines overall processed 76,077 newlines per second. And the T4b2 is still happily running and connected to the PC ready to resume the test.

Should be quick enough to Add a check of the char before/after the \n to be off by one expecting modulo A-Z would add a way to catch/report missing lines. With the lines being 64 bytes each is a single packet - which is good for this test, but won't catch errors in partial packets like if I did it with a prime number of elements of maybe 61 or 67 chars per line.
 
CAN3 legacy mode CAN2.0 support added to the library. 3x CAN2.0 interfaces working at the moment. FD not yet implemented...
This was added today and confirmed after reading Mike's silkscreen note
 
Last edited:
CANFD and CAN2.0 Legacy through CAN3

@defragster, yeah the pin confusion was the big thing - once got that figured out after a day with the scope and a multimeter all was good this morning. Impressive numbers for the serial tests. Don't have the patience to let it run that long :)

As @tonton81 stated in post 2859 his flexcan_t4 library now works through the CAN3 bus on pins30/31 using CAN2.0 messages. In the meantime I got the T4 talking to 1060EVKB with CANFD using CAN3. So now the big challenge is to put CANFD in a usable library format.

Based on what I can see the T4 will be the first to have an actual usable CANFD implementation. The STM32H7 has the fsl CANFD driver but no Arduino style library that can be used.
 
CANFD and CAN2.0 Legacy through CAN3

@defragster, yeah the pin confusion was the big thing - once got that figured out after a day with the scope and a multimeter all was good this morning. Impressive numbers for the serial tests. Don't have the patience to let it run that long :)

As @tonton81 stated in post 2859 his flexcan_t4 library now works through the CAN3 bus on pins30/31 using CAN2.0 messages. In the meantime I got the T4 talking to 1060EVKB with CANFD using CAN3. So now the big challenge is to put CANFD in a usable library format.

Based on what I can see the T4 will be the first to have an actual usable CANFD implementation. The STM32H7 has the fsl CANFD driver but no Arduino style library that can be used.

Yeah 4.8 MB/sec is lots of room to create and pass data - and room to go faster - but what is on the other end taking all that data :) It only ran that long because I started it and got tied up. Odd thing is the run before aborted after a few lines with no error message. A shorter run of 1 Million buffers takes under 800 seconds. I ran it on T_3.6 and guess it would be 10K instead 76K lines per seconds - given the T4 is about half rate of the other test and the T_3.6 was hitting 20K there.

T4 is very fast and the last update made a big difference in speed - wanted to have a way to get the PC to test and measure so Paul would know if it was troubled now or with future updates. Put MinGW on my Surface book - very handy to write code with!

Does that mean a normal CAN2 board can connect to the CANFD transceiver and communicate - or is there a difference in the transceiver beyond message formatting/presentation? Very cool T4 will offer advanced CAN/CANFD capabilities - in a small package with good resources CPU/RAM.

With the updated Windows only TyCommander from koromix I'm able to use TSet with mods noted in Readme there for B1 and B2 and bypass the IDE and get Arduino build from command line within editor. Koromix is going to add GUI label differentiation for attached B1 versus B2 - but for now it just shows T4 and works for both.
 
defragster said:
...Does that mean a normal CAN2 board can connect to the CANFD transceiver and communicate - or is there a difference in the transceiver beyond message formatting/presentation? Very cool T4 will offer advanced CAN/CANFD capabilities - in a small package with good resources CPU/RAM
Most CANFD transceivers that I see will support CAN2.0 messages so as long as you are sending CAN 2.0 messages and NOT FD messages the answer is yes you can use the MCP2558FD transceiver that is on the breakout board to send CAN 2.0 messages. @tonton81 just did that with his library and the sdk version as a test.
 
Most CANFD transceivers that I see will support CAN2.0 messages so as long as you are sending CAN 2.0 messages and NOT FD messages the answer is yes you can use the MCP2558FD transceiver that is on the breakout board to send CAN 2.0 messages. @tonton81 just did that with his library and the sdk version as a test.

Okay - that was my initial hope - when I ordered one of the CAN2 units (eBay shows them 2 or 5 for the price of 1 on Amazon) - assuming upward/backward compatibility - but wasn't sure if the electrical spec was different - which wouldn't allow mixed systems. I have two now …

@Paul - perhaps - when sending out the T4 Beta 2.1_mod boards if any of those go to folks with Beta 2.0 Breakouts and want to try CAN2 - just the CAN2 transceiver hardware on those spare breakout boards - and POGO pins would allow T4<>T4 testing of CAN FD.
 
Hello Mr. Stoffregen I need to develop a project that involves the use of (2) USB High Speed (480 Mbit/sec) Ports,(one intercepting Data from a Host for processing purposes and the other to send the new data to a USB device at the same speed) since I am not an expert at all, my question is if you think that is possible with the Teensy 3.5, 3.6 or 4.0, and I am eager to know if you are including those capabilities in the new Teensy 4 model?
Thanks in advance and wish you the best with this new model!
 
Last edited:
Tim yes the CANFD can work in CAN2.0 mode in all controllers by disabling the brs (baud rate switch) bit in the FD frame (so it runs at the nominal rate only for both arbitration AND data) and setting a DLC to 8, however we are actually using legacy mode in flexcan CAN3 on teensy which is CAN2.0 only mode like CAN1 and CAN2 and not part of the FD system (registries for FD disabled).

Can1 definately works but not broken out on b2 breakout board, i tested by holding the probes on the pins, for now on B2 we can easily do CAN2 and CAN3, but T4 to T4 FD is definately the path we’re going, T4 to T4 CAN2.0 is already done, for now we test with a valid FD network using t3.x and click boards with the MCP2517FD that we can work up against
 
I have 5 of the beta #2 boards with the brown-out restart mod. Who has hit the brown-out lockup problem and wants one for testing?

perhaps - when sending out the T4 Beta 2.1_mod boards if any of those go to folks with Beta 2.0 Breakouts and want to try CAN2 - just the CAN2 transceiver hardware on those spare breakout boards - and POGO pins would allow T4<>T4 testing of CAN FD.

I do have 8 more of the breakout boards, but none are currently soldered. I was going to just send the T4 beta#2+mod boards without a breakout board. But if anyone really wants to test CAN to CAN communication between two T4s, please let me know? Also tell me whether you'd like to solder the breakout board. It's fairly easy to just send you a bare board and some parts. I could solder a couple more, if really needed, but that'll take longer...
 
Yes, please. Great news you have 'boards with the brown-out restart mod' - anxious to see it accept having debug Teensy's attached and Power UP and On/Off and do 15s Restore.

If you send the parts I'll self solder to get a second CANFD for test with current Beta #2.0 board. Are USB Host parts about as simple to solder?

COOL: " Shipping Label Created, USPS Awaiting Item 05/14/2019 5:19pm SHERWOOD OR"
 
Last edited:
@xacompany@gmail.com - a partial answer - AFAIK - is that until a newer Teensy 4 like this Beta only the T_3.6 has a second USB_Host port. The 2nd host port is 480 Mbit/sec hardware - but its device port is only 12 MBit/sec.

This beta T4 device processor does have 480 Mbit/sec USB hardware on the HOST and Device ports. Applicability to use case at hand may be supported - or need added development after hardware ships.
 
please use USPS for canada too next time, DHL charges 20$, I don’t care as its a hobby but i’d rather donate to pjrc than pay those competitors of mine ;P
 
please use USPS for canada too next time, DHL charges 20$

Please send this directly to Robin by email. She does the shipping.


If you send the parts I'll self solder to get a second CANFD for test with current Beta #2.0 board. Are USB Host parts about as simple to solder?

I soldered the SMT parts to 4 more of the breakout boards. For the first 4 of these beta 2+mod boards, I'll send those and a bag of the through hole parts. Not including the SD socket or 8 tiny pogo pins on these. I'm also out of the plastic bases.

The USB connector is pretty easy to solder. The 4 large pins sort-of snap into the holes and hold it roughly in place. As with all through-hole soldering, easiest to solder the shorter parts first and work up to the taller ones.
 
I've got 2 more beta #2 boards with brown-out restart mod, and 1 more bare breakout board + parts. Does anyone (on the beta testers list) want to do any testing with these? Email Robin directly, as I'll be traveling tomorrow for Maker Faire in San Mateo.

More prototypes which are exactly the same as beta #2+mod (but the extra wire is inside the PCB on layer #4) are coming next week. Assuming those work, we're going to finalize Teensy 4.0 with that PCB layout and order the first production batch. With 3 week lead time on the production PCBs, and 2-3 weeks for assembly, that'll put the Teensy 4.0 release in early July.

So these beta #2+mod boards are electrically identical to what we're going to go with as the final PCB, just with 1 little white wire soldered on the bottom side rather than the fix for brown-out restarting on the inner layer.
 
SMD soldering welcome :) - showing Friday delivery. Without SD and those little pogo pins was expected - through hole for USB and CAN will let the T4b2 unit have a place to live and be productive in coming days.

Glad it only took 'one wire' change in the PCB - and very happy to know it is fixed - expecially with the parts on hand for testing the modification.

Seems like the rest of the T4 is working - USB Host writing to HDD's at 9 or 11 MB/sec on two 3.5" units I had. Just ordered fresh pieces to make a powered boxed USB/SATA 2.5" Seagate - went HDD instead of SSD as without trim and other OS support it seemed that HDD 128 MB buffer might serve as well or better - and 500 GB double the size for a few bucks less than SSD.
 
@Paul - I have not removed the T4B2 from the breakout - I've not seen signs of a trace to cut to isolate VUSB from VIN. Is there an onboard provision for this?

… just saw the 5V VUSB through hole off USB toward VIN - it does have a top trace - but not segmented/marked as if to be cut.
 
I've not seen signs of a trace to cut to isolate VUSB from VIN. Is there an onboard provision for this?

Yes, it's on the bottom side, same location as Teensy 3.2, 3.5, & 3.6.

All the beta #2 boards were made without these pads joined. If you look into the breakout board from the side, you'll probably see the solder I put on the board to connect VUSB to VIN.
 
Good, I do see the shiny blob. Sense of scale with angled viewing under there and headers in place is way off from the larger visual on the card - especially the T_3.2 without the USB leg/pin there :) Teensy was well named - nice the 1062 MCU went smaller - except all those pin/balls are so close for routing … but it looks very nice with generous room for silkscreen pin numbers.
 
Status
Not open for further replies.
Back
Top