Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 32 FirstFirst ... 3 4 5 6 7 15 ... LastLast
Results 101 to 125 of 798

Thread: Teensy 4.1 Beta Test

  1. #101
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,837
    Quote Originally Posted by KurtE View Post
    Looks like fun output of the different pin information...
    Using a volt meter, none of the pins for the two memory solder pads match any of the 3 SPI buses (except for ground and 3.3v obviously). But except for the CS pad (1st pad where the dot is), the other 7 pads are connected to each other between the two pads. Using your table, the internal pins are EMC_25 to EMC_29 for the common SPI pins, and EMC_24 and EMC_22 for the two CS pins.

    The i.MX1062 does support 4 SPI buses, so it looks like the 2 memory pads use that 4th SPI bus. Thus we have SPI and SPI1 for normal SPI accesses, SPI2 for the micro-SD card reader, and SPI3 for the memory chips.

  2. #102
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    So I'm starting work on the Ethernet interface now. In the past (for FlexIO and clock tree generation), my approach has been to start with known working code in MCUXpresso and then move that over to Arduino-land. For the clock configuration in particular, this has saved me considerable time since NXP's tool has a convenient graphical manager that generates pretty straightforward configuration code. The biggest challenge I see is that imxrt.h uses a different structure for register access than the Freescale SDK, so there will probably be a lot of head-scratching and binge drinking there.

    That said, I'm open to suggestions for alternate approaches. How have others beaten the various peripherals of this part into submission? Do you give up on the Arduino environment entirely and do everything in Eclipse? Honestly that's an environment I'm far more comfortable with given my day job (STM32 in Eclipse with OWD/Segger). Any other advice? Thanks!

  3. #103
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    Also, before I totally reinvent the wheel, are there any existing functions/macros for things like setting the pin mux or pin configuration registers? What would be the most recent low-level library with good examples of canonical approaches to hardware manipulation?

  4. #104
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,575
    I have run the NXP SDK examples for ethernet on the 1062 eval board. Take a look at https://github.com/PaulStoffregen/teensy41_ethernet
    there are some "raw" ethernet examples (arduino) sketches that enable clocks and configure pins and ethernet ring buffers for the Teensy 4.1. On top of that we have implented lwIP examples using polling and callbacks that do UDP/TCP client/server things. The README has some performance comparisons
    Last edited by manitou; 04-27-2020 at 05:20 PM.

  5. #105
    Senior Member blackketter's Avatar
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    289
    I can't seem to find a reference for the circuit needed for the ethernet port. Is it as simple as wiring a RJ-45 with integrated magnetics and maybe a current limiting resistor for the LED?

  6. #106
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    @manitou Thanks for that! Well heck, looks like everything's done then. Is there anything useful I can add at this point or should I move on to something else? Maybe work on getting the existing Arduino Ethernet library integrated with the T4.1 hardware, or is the plan to just move to lwip for everything in the future? Thanks.

  7. #107
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,575
    Quote Originally Posted by blackketter View Post
    I can't seem to find a reference for the circuit needed for the ethernet port. Is it as simple as wiring a RJ-45 with integrated magnetics and maybe a current limiting resistor for the LED?
    paul provided a limited number of RJ45's with magnetics and 6-pin ribbon cable for the pre-beta testing. I assume at some point he will provide schematics and BOM for the RJ45 connection.

    For the USB host connection, the PJRC USB host cable will work (same as with T3.6)
    Last edited by manitou; 04-27-2020 at 05:10 PM.

  8. #108
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,575
    Quote Originally Posted by Ward View Post
    @manitou Thanks for that! Well heck, looks like everything's done then. Is there anything useful I can add at this point or should I move on to something else? Maybe work on getting the existing Arduino Ethernet library integrated with the T4.1 hardware, or is the plan to just move to lwip for everything in the future? Thanks.
    Paul's hope has always been (since T3.6 beta testing) wanting to provide an arduino-like library for the T3.6/T4.1 native ethernet. If you can do that, you will receive great adulation. Implementing a TCP/IP suite with timers, interrupts, and memory management is no small task and makes one appreciate off-loading all of that to a co-processor (e.g. Wiznet SPI ethernet). Here are some notes from the "private" thread used during pre-beta T4.1 testing

    -----------
    Ethernet and lwip testing and performance

    I'll summarize my lwIP testing as I add to this sticky post

    The beta teensy4.1 came with an RJ45 jack/PCB kit with 6 pin ribbon cable. The cable is attached to the 6 pins on the T4.1 as shown here
    Click image for larger version. 

Name:	t41e.jpg 
Views:	58 
Size:	12.6 KB 
ID:	20063
    Initial testing was done in February 2020 with Arduino 1.8.11 and TD 1.51-beta1


    low-level Ethernet tests:
    Paul provided a low-level sketch to configure the T41 ethernet interface. The interface is configured with 12 RX and 10 TX ring descriptors using 512-byte packet buffers. The sketch provides ARP reply and ICMP echo (ping) reply using a fixed IP and MAC address. The sketch listens in promiscuous mode (ENET_RCR_PROM) and prints incoming packets (broadcasts and multicasts). ICMP ping round-trip times were 396 us, slowed somewhat by the packet printing.
    Code:
    PLL6 = 80202001 (should be 80202001)
    GPR1 = 80020018
    RCSR:0061, LEDCR:0480, PHYCR 8000
    RCSR:00A1, LEDCR:0280, PHYCR 8000
    enetbufferdesc_t size = 32
    rx_ring size = 384
    MIBC=40000000
    ECR=F0000000
    ECR=F0000112
    MDIO PHY ID2 (LAN8720A is 0007, DP83825I is 2000): 2000
    MDIO PHY ID3 (LAN8720A is C0F?, DP83825I is A140): A140
    BMCR: 3100
    BMSR: 786D
    I extended Paul's sketch, adding hand-crafted UDP packets to create etherraw.ino based on 2016 K66 beta ethernet testing. I disabled promiscuous mode and increased packet buffers to 1536 bytes and updated to use single ISR to count packets. The 1062 has an option to coalesce packet interrupts, but I'm still using legacy mode.
    • ARP request(broadcast), reply, respond OK, (192.168.1.17) at 04:e9:e5:00:00:01. request/response time 93 us. could build ARP table
    • ICMP/ping reply OK. ping RTT time from linux host: 120 us (print's disabled in sketch)
    • UDP receive test: linux box sends 20 1000-byte UDP packets as fast at it can. T41 receives all in 1660 us (bout 96 mbs), receiver clock is started when first packet arrives.
    • UDP blast : T41 sends 20 1000-byte packets (with sequence numbers) to UDP sink program on linux, linux measured 96 mbs.
    • UDP echo reply, RTT for 8-byte pkt with simple T41 sendto/recvfrom echo'd back from linux: 93 us, with T41 echoing, 98 us.
    • UDP NTP query using sendto/recvfrom, RTT 182 us
    • modified output() to keep trying til ring output buffer is available
    • To simulate TCP performance, a UDP transmit function was configured like TCP (MSS=1460, max window 2*MSS) and uses a "slow start" of a full window of data, sending 1460-byte packets. The window size and RTT latency will determine TCP bulk transfer rates. With a simple linux UDP "ack" program (no delayed ACK), our T41 TCP-like transfer rate was 70 million bits/second (mbs) on the home wired-Ethernet. Increasing the window to 4*MSS increased the throughput to 95 mbs. Since the T41 hardware checksums are flakey (?maybe), we are calculating IP header checksum in software, and using 0 for UDP checksum.

      We include a micros() timestamp in each packet to measure RTT.
      RTT stats: 100 pkts min 330 max 463 avrg 335 (microseconds)
      The RTT jitter is caused by other traffic (broadcasts) on the home net, or the linux host having something better to do.

    T41 ethernet registers:
    Code:
    PLL6 = 80202001 (should be 80202001)
    GPR1 = 80020018
    RCSR:0061, LEDCR:0480, PHYCR 8000
    RCSR:00A1, LEDCR:0280, PHYCR 0000
    enetbufferdesc_t size = 32
    rx_ring size = 384
    MIBC=40000000
    ECR=F0000000
    ECR=F0000112
    MDIO PHY ID2 (LAN8720A is 0007, DP83825I is 2000): 2000
    MDIO PHY ID3 (LAN8720A is C0F?, DP83825I is A140): A140
    BMCR: 3100
    BMSR: 786D
    ENET_PALR 0x4e9e500
    ENET_PAUR 0x18808
    ENET_EIR 0x0
    ENET_EIMR 0xa000000
    ENET_ECR 0xf0000112
    ENET_MSCR 0x12
    ENET_MRBR 0x600
    ENET_RCR 0x45f25104
    ENET_TCR 0x104
    ENET_TACC 0x1
    ENET_RACC 0x80
    ENET_MMFR 0x6004786d


    lwIP tests: (v2.0.2, no RTOS NO_SYS=1)

    I ported lwIP (v2.0.2) from 2016 T3.5/T3.6 beta ethernet testing. I updated the low-level interface to support the T41 ethernet and configured 5 Tx and 5 Rx ring descriptors with 1536-byte packet buffers. lwIP uses polling and callbacks (no RTOS) and provides ARP, IP, ICMP, UDP, TCP, DHCP, DNS, and multicast. There are numerous tuning and configuration options (lwipopts.h). Hardware checksums appear to be working with lwIP.

    I developed test sketches for NTP, DNS, multicast, web server, web client, httpd with SD or SdFat-beta lib, tfttp server (SD, SdFat-beta, or SPIFFS), ftpd (get/put) with SD lib, and TCP/UDP client/server benchmarking. TCP performance improves from 59 mbs to 81 mbs by increasing TCP window to 4*MSS in lwipopts.h. Some of the benchmark results are reported in the table below (column T41e is the Teensy 4.1 ethernet).

    Code:
                             Ethernet performance
                       T41e   1062SDK  T41fnet T41USBe  T35e  T4+W5500    info
    TCP xmit (mbs)       73        87     92       78     59         9 
    TCP recv (mbs)       93        71     78       30     81        11  
    
    UDP xmit (mbs)       97        97     97       95     85        11   blast 20 1000-byte pkts
    UDP xmit (pps)   149476    137453 152052    32331  66534     21514   blast 1000 8-byte pkts
    UDP recv (mbs)       91        95     96       40     67         9   no-loss recv of 20 1000-byte pkts
    UDP RTT (us)         94       104    104     1651    183       150   RTT latency of 8-byte pkts
    
    ping RTT (us)       120       108    103     2000    127        82 
    
    ePower (ma)          59       100     59      174    100       132   ethernet module current
     
      tests on 100mbs full-duplex Ether with linux box on switch
      T41fnet and T41USBe  FNET TCP/IP native (arduino wrapper) and USB host, no threads
      W5500 SPI @37.5MHz, 2KB buffers
    The memory usage for a sketch is 66 KB flash and 148 KB RAM. RAM usage includes 15 KB of Ethernet ring DMA buffers. Teensy also copies flash into RAM for faster execution. Packet buffers are allocated/freed from the heap (malloc()).

    Below is power consumption of T4.1 with Ethernet. After powering up, the sketch delays a few seconds before transmitting TCP packets for about 8 seconds. Power stays high, even after the transfer is complete. A temperature probe on the PHY chip measures 40℃ .
    Click image for larger version. 

Name:	t41ether.png 
Views:	79 
Size:	23.1 KB 
ID:	19877
    Turn off power to PHY with
    mdio_write(0,0,0); // auto negotiate off
    mdio_write(0,0,0x0800); // power down

    builtin microSD and native ether performance
    Code:
      microSD read times (seconds)  (4.2MB file, 2KB reads)
          T4 SD lib  T3.5 SdFatv1  T4.1 SdFatv2  T4.1 SPIFFS EFLASH
    tftp    4.76        2.2          2.2 s         2.3 s
    http    3.6         0.9          0.9
    ftp     2.8         0.6  
    read()  2.76        0.26         0.19 s        0.2 s
    lwIP TODO:
    • upgrade to latest lwIP
    • lwIP tuning options: memory/pbuf's, LITE options, memcpy
    • IP frag is enabled, but not tested
    • lwip_servers (httpd, ftpd, tftpd) with SdFat fails to build (worked on T3.5 SdFatv1) ? needs T4/VFS support
    • DEBUG and stats_display() want to use printf
    • integrate yield() with ethernet polling
    • coalesce interrupts and use DMA, cache management (NXP SDK fsl_enet.c)
    • mbed uses zero-copy (need to reclaim TX buffers), DMA?
    • integrate multicast CRC/hash into lwIP API
    • bettter integrate lwIP into IDE
    • develop Ethernet/TCP/IP stack? lwIP variations? FNET? Paul would like to have the shield API be a drop-in replacement for existing Arduino Ethernet interface (maybe based on STM32duino lwIP or UIPEthernet?). Done? see T4.1 FNET and Arduino API wrapper 2020

    lwIP updates:
    6/23/20 D Drown refactors lwIP include files so no modifications to boards.txt is required to build lwIP sketches with the IDE. Lib now supports 1588 time stamps. Paul's repository updated from https://github.com/ddrown/teensy41_ethernet. Also see NTP server with GPS PPS and 1588.


    FNET and NativeEthernet tests: May, 2020

    An Arduino-like API has been provided by @vjmuzik atop of FNET TCP/IP. The API includes the Arduino TCP/IP examples. I have tested ARP, ICMP, DHCP, DNS, multicast, and various TCP/UDP client/servers. The memory usage for a sketch is 88 KB flash and 118 KB RAM. RAM usage includes 6 KB of Ethernet ring DMA buffers, and Teensy copies flash into RAM. Packet buffers are allocated/freed from the heap (malloc()). Performance results are presented in the table above (T41fnet column). Increasing FNET_SOCKET_DEFAULT_SIZE from 2048 to 4*1460 in NativeEthernet.h improved T4.1 TCP recv from 60.5 mbs to 78.4 mbs and TCP xmit from 45.2 mbs to 92 mbs! Edit: there are now function calls to set buffer sizes.

    fnet_perf.ino and tftp servers fnet_tftpd (with SD lib) or fnet_tftpd_SPIFFS
    See discussions on NativeEthernet thread


    References:
    Last edited by manitou; 07-10-2020 at 06:43 PM.

  9. #109
    Senior Member blackketter's Avatar
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    289
    Quote Originally Posted by manitou View Post
    paul provided a limited number of RJ45's with magnetics and 6-pin ribbon cable for the pre-beta testing. I assume at some point he will provide schematics and BOM for the RJ45 connection.
    Ah, ok. Can anybody with one confirm that it's just wires and connectors?

  10. #110
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    Can confirm. No ballast resistor needed for the LED. There are pads for tying the Ethernet connector shield (and by extension the wire side of the magnetics) to ground, as well as the circuit side center taps of the magnetics. I populated those with 0.1uF 100V caps, 1kV would be better for the wire side, but I didn't have one in my pocket. Honestly, if you're handy with a soldering iron, a magjack and some twisted pair (or better, twist up some wirewrap wire) is all you'd need.

    @manitou, I've got blinkenlights and see ARP traffic, so we'll call that a win. Thanks again!

  11. #111
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,228
    Quote Originally Posted by blackketter View Post
    Ah, ok. Can anybody with one confirm that it's just wires and connectors?
    The unit I got from PJRC was a ribbon cable to a digikey MagJack ( back in stock soon ) on a PCB - the PCB has 4 components. At a glance it looks to be one resistor and three caps.

  12. #112
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    Okay, I take back the "1kV" comment. Looking at the datasheet in the link defragster posted, there's a 2kV 1000pF cap in the package already.

  13. #113
    A short advice for an Ethernet library as a starting point. There is a lwip based lib for STM32duino here https://github.com/stm32duino/STM32Ethernet
    The API follows the Ethernet lib of Arduino, maybe that helps.

  14. #114
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,556
    Quote Originally Posted by defragster View Post
    The unit I got from PJRC was a ribbon cable to a digikey MagJack ( back in stock soon ) on a PCB - the PCB has 4 components. At a glance it looks to be one resistor and three caps.
    Think this might be the same: https://www.sparkfun.com/products/13021 or this https://www.kr4.us/SparkFun-RJ45-MagJack-Breakout.html. Not sure, what do you all think.

  15. #115
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,575
    Quote Originally Posted by sstaub View Post
    A short advice for an Ethernet library as a starting point. There is a lwip based lib for STM32duino here https://github.com/stm32duino/STM32Ethernet
    The API follows the Ethernet lib of Arduino, maybe that helps.
    This API looks promising. i've added it to the list of candidates at the end of post #108. The API uses a 1 ms timer to check for packets and network events.
    Last edited by manitou; 04-28-2020 at 12:02 AM.

  16. #116
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,228
    PJRC unit had the 4 component parts added? Maybe not needed just overkill on Paul's part? Or maybe he knows something about working with the 'TINY' ethernet chip he could squeeze on the T_4.1 PCB?

    Those don't show any resistor or caps in place in the images I can see. Also PJRC part had a similar 2x3 pin connector for the cable as he made it up that - given the ribbon bale with female ends pushed right on - the SFun item had a row of some pins that may not map 1::1 - maybe that is what the onboard parts did?

  17. #117
    Member
    Join Date
    Mar 2013
    Location
    Hillsboro, OR
    Posts
    20
    No, there were no SMT components populated...I added them. It's good practice to terminate the center tap on both sides of the Ethernet magnetics. The line side is typically shunted to ground through a 50- or 75-ohm resistor and a high-voltage cap. The device side is typically shunted to ground through only a cap. On this part, the line-side 75 ohm load resistors and cap are inside the jack. The breakout board I was sent had four enormous sets of pads, probably for 0805 components. Two were in parallel from the line side center tap to ground, and two were in parallel from the device side center tap to ground. I stuffed each pair with a single 0.1uF 100V 0603 (physically biggest I had) capacitor. Everything seems to be working fine. If you're designing your own magjack breakout, I'd recommend adding some ESD diodes as well, which are cheap insurance. I've seen Wiznet chips die without external overvoltage protection, TI is probably more robust.

  18. #118
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    601
    Once I get my hands on a T_41 I’ll be working on getting FNETs native support for the 1062 processor working, so it should handle setting up all the necessary registers and timers by itself. Since I’ve already gone through a lot of FNET when I was getting the USB Ethernet working I already roughly know what needs to be done to get it working. As it stands I could have Paul’s low level sketch interfaced with my port fairly quickly since I designed it to be easily interfaced with, but I believe the native support will be more stable in the long run so I would like for that to work.

  19. #119
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,228
    Quote Originally Posted by vjmuzik View Post
    Once I get my hands on a T_41 I’ll be working on getting FNETs native support for the 1062 processor working, so it should handle setting up all the necessary registers and timers by itself. Since I’ve already gone through a lot of FNET when I was getting the USB Ethernet working I already roughly know what needs to be done to get it working. As it stands I could have Paul’s low level sketch interfaced with my port fairly quickly since I designed it to be easily interfaced with, but I believe the native support will be more stable in the long run so I would like for that to work.
    Cool, did you request a unit with your name on the post 1 list?

  20. #120
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    601
    Quote Originally Posted by defragster View Post
    Cool, did you request a unit with your name on the post 1 list?
    I did, just a little later than everyone else.

  21. #121
    Hi.
    Will this new version allow uploading signed/encrypted images of the user firmware?

  22. #122
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,228
    Quote Originally Posted by LuisHS View Post
    Hi.
    Will this new version allow uploading signed/encrypted images of the user firmware?
    Not seen any signs of that as a WIP at this point.

    Quote Originally Posted by PaulStoffregen View Post
    No. Teensy 4.0 is not using the encryption features.

    We may at some point in the future (not likely until at least 2021) support encrypted firmware. But that is no simple matter. These powerful features come with many dangers if used improperly, including lots of ways to permanently brick your Teensy. When (if) we do support encryption, it very likely will be a different board and the changes will (probably) not be possible as a software update to existing boards.

    All of the design that has gone into Teensy 4.0's bootloader and uploading process has revolved around making Teensy safe for experimentation and preventing boards from becoming bricked.
    Last edited by defragster; 04-28-2020 at 05:21 PM. Reason: Edited prior PJRC post on encrypted FLASH

  23. #123
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,471
    Wondering about best way to gain access to the bottom pins, when not used with external memory.

    As I posted with a few XLS outputs, these two memory chips map out to 7 additional IO pins, where 6 of these signals are common on both chip pads:
    Code:
    												Back Memory Chips													
    EMC_26	4.26		1:12					RX1		P	52			GND											
    EMC_25	4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
    EMC_29	4.29		1:15				MOSI2			P	54		(pin 1)	49	P			SCK2				1:13		4.27	EMC_27
    									3.3V					51	P					SCL1				4.22	EMC_22
    																									
    EMC_26	4.26		1:12					RX1		P	52			GND											
    EMC_25	4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
    EMC_29	4.29		1:15				MOSI2			P	54			49	P			SCK2				1:13		4.27	EMC_27
    									3.3V				(pin 1)	48	P		RX8							4.24	EMC_24
    Or from the other tab:
    Code:
    48	EMC_24	4:24	Serial8(5) RX 		FLEXSPI2_A_SS0_B	PWM1_B0						
    49	EMC_27	4:27	Serial8(5) RTS		FLEXSPI2_A_DATA01, SPI2(1) SCK  	PWM1_A2				1:13		
    50	EMC_28	4:28	Serial8(5) CTS		FLEXSPI2_A_DATA02, SPI2(1) MOSI	PWM1_B2				1:14		
    51	EMC_22	4:22		Wire1(3) SCL	FLEXSPI2_A_SS1_B	PWM3_B3, QT2_3						
    52	EMC_26	4:26	Serial1(6) RX 		FLEXSPI2_A_DATA00	PWM1_B1				1:12		
    53	EMC_25	4:25	Serial1(6) TX 		FLEXSPI2_A_SCLK	PWM1_A1						
    54	EMC_29	4:29	Serial1(6) RTS		FLEXSPI2_A_DATA03, SPI2(1) MISO	PWM3_A0				1:15
    I can see a few different ways to get some/all of them:
    a) Pogo pins - Sort of a pain especially with the .127...
    b) Wondering about SMT connector. Maybe something like: https://www.digikey.com/product-deta...4-1-ND/2209146 ?
    c) Quick and dirty castellated smt. Not sure if I do one to put the new pins in line so could maybe plug into breadboard. Or just two rows just behind SDCard slot... May try to layout one or the other.

    But now back to playing

  24. #124
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,471
    Quote Originally Posted by LuisHS View Post
    Will this new version allow uploading signed/encrypted images of the user firmware?
    I suspect the T4.1 functionality for this will be identical to T4's, as they use same processor and think same loader chip. Although maybe some slight changes to the firmware?

  25. #125
    Member
    Join Date
    Feb 2020
    Location
    Dublin, Ireland
    Posts
    39
    Quote Originally Posted by KurtE View Post
    a) Pogo pins - Sort of a pain especially with the .127...
    Hi,
    I haven't seen them, but I presume that, b
    ecause of the duplication, most of the pogo pins could be 0.254 apart. Only two would have to go to pads that are adjacent. I don't know how long the pads are - if those for either chip are as generous as the ones on the audio board, then the two going to adjacent pads could be 0.254 spaced at an angle to the pads. Would that be possible?

Posting Permissions

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