Forum Rule: Always post complete source code & details to reproduce any issue!
Page 115 of 119 FirstFirst ... 15 65 105 113 114 115 116 117 ... LastLast
Results 2,851 to 2,875 of 2971

Thread: Teensy 4.0 First Beta Test

  1. #2851
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    Quote Originally Posted by xxxajk View Post
    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.

  2. #2852
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,569
    Quote Originally Posted by WMXZ View Post
    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 by KurtE; 05-10-2019 at 10:51 PM.

  3. #2853
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    Quote Originally Posted by PaulStoffregen View Post
    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. :-)

    Quote Originally Posted by PaulStoffregen View Post
    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)

  4. #2854
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    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?

  5. #2855
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,929
    Quote Originally Posted by xxxajk View Post
    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)

  6. #2856
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    Quote Originally Posted by manitou View Post
    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.

  7. #2857
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    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.

  8. #2858
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    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.

  9. #2859
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,003
    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 by tonton81; 05-12-2019 at 08:22 PM.

  10. #2860
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    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.

  11. #2861
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    Quote Originally Posted by mjs513 View Post
    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.

  12. #2862
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,228
    Quote Originally Posted by defragster
    ...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.

  13. #2863
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    Quote Originally Posted by mjs513 View Post
    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.

  14. #2864
    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 by xacompany@gmail.com; 05-13-2019 at 04:54 AM.

  15. #2865
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,003
    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

  16. #2866
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    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?

    Quote Originally Posted by defragster View Post
    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...

  17. #2867
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    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 by defragster; 05-15-2019 at 02:31 AM.

  18. #2868
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    @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.

  19. #2869
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,003
    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

  20. #2870
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    Quote Originally Posted by tonton81 View Post
    please use USPS for canada too next time, DHL charges 20$
    Please send this directly to Robin by email. She does the shipping.


    Quote Originally Posted by defragster View Post
    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.

  21. #2871
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    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.

  22. #2872
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    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.

  23. #2873
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    @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.

  24. #2874
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    Quote Originally Posted by defragster View Post
    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.

  25. #2875
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,380
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •