THE testing thread


lanefu
 Share

6 6

Recommended Posts

13 hours ago, Hijax said:

power distribution

It may seem unnecessary, but I would label the power input like:  5,1 - 5,25VDC ,  to avoid boring questions.

 

If each SUT and SBC has a maximum consumption of

15 W x 9 = 135W (I = P/U == 27 Amps)    however, standard use I guess 7 W max are average = 63W == 13 Amps  still quite some juice :o

 

The placement of the power connector, aren't there the metal housing of USB- & Ethernet-Connector?  having devices not on hand right now  AND  if ones uses it without 'spacers', like you do on the picture. Is there a chance to move the THT parts away from the 'dangerous' area?


How come you are so quick & talented with KiCad?

 

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

4 minutes ago, Tido said:

standard use I guess 7 W max

For example Rock64 takes 0,9A at processor peak. Measured by myself. I will later check other SBCs I have, including Odroid XU4.

Anyway the 4mm track I placed on PCB shall be enough to provide 7.5W to each of all 4 SUTs. Or max 30W in total, which better describes reality.

 

But to not overload external power supply,  I suggest to use such a board in a way to not start all SUTs at the same time, but boot them one by one, with let's say 2s delay.

Then after ~15sec all SUT will be running, but power usage will be on reasonable level.

 

8 minutes ago, Tido said:

The placement of the power connector, aren't there the metal housing of USB- & Ethernet-Connector?

 

Yes, but spacers will secure insulation.

 

9 minutes ago, Tido said:

How come you are so quick & talented with KiCad?

Using EDA for several years already.  Long time ago I have started with Orcad, then moved to Protel 99, and now KiCad fan.

Link to post
Share on other sites

Ok chaps, final design of serial mux board, plus zip file full of gerber files.

obraz.png.1b6227ca24dbe224bcf3fc4c2d4ee785.png

serial-mux.zip

 

BOM:

obraz.thumb.png.c55c9c6af89ad957dc260a61ff88737c.png

 

 

manufacture.pdf

 

Simple example how to control mux from bash (not verified, concept only

 

#!/bin/bash

# pin allocation 
MOSI_PIN=353    #GPIO2
SCK_PIN=3       #GPIO3
EN_PIN=19       #GPIO4

function gpio-setup {
    for pin in $MOSI_PIN $SCK_PIN $EN_PIN; do 
        [[ -d /sys/class/gpio/gpio$PIN ]] && echo $pin > /sys/class/gpio/export
        echo "out" > /sys/class/gpio/gpio$PIN/direction
    done
}

function gpio-write_byte {
    for i in {1..8}; do 
        // set data pin to high or low value
        BIT=0
        (( $1 > 127 )) && BIT=1
        echo "$BIT" > /sys/class/gpio/gpio$MOSI_PIN/value
        
        // set clock high
        echo "1" > /sys/class/gpio/gpio$SCK_PIN/value
        $1=$(( $1 << 1 ))
        // set clock low
        echo "0" > /sys/class/gpio/gpio$SCK_PIN/value
    done
}

# 16 bits: -- -- -- -- -- b3 b2 b1 p7 p6 p5 p4 p3 p2 p1
# px - power status on port x
# bx - serial connected to port x
function setup_mux {
    local high_byte=$(( $1 >> 8 ))
    local low_byte=$(( $1 & 255 ))
    
    gpio-setup
    gpio-write_byte(high_byte)
    gpio-write_byte(low_byte)
    
    # toogle EN bit to latch new value on 595s
    echo "1" > /sys/class/gpio/gpio$EN_PIN/value
    echo "0" > /sys/class/gpio/gpio$EN_PIN/value
}

 

Link to post
Share on other sites

Note there was no prototype yet but... Yeah, I cool with it.

 

And surly  I will shortly create order. Will try jlcpcb as usually  I use seeed studio fusion service.

Components I will order from TME, my nearby "local" company :) 

I expect that within 1-3 weeks (depending on PCB avaiability) first few boards will be assembled. And I will test them in my workshop.

 

Link to post
Share on other sites

13 hours ago, Tido said:

4 SUT..  why is there hardware for 8 Ports?

Two 4mm lanes for 4 SUTs equals 8 SUTs in total.

 

14 hours ago, lanefu said:

can i submit a test print to jlcpcb

Did that already, so the version with LEDs is now in production ( 5pcs).

Hope within a week (DHL) boards will reach my workshop.

 

Be careful, as the gerbers I attached previously are for other version w/o LEDs. As well as BOM and manufacture pdf.

 

Some comments:

- for 7seg display essentially all common anode will work with distance between pin rows 5.08mm

- 10k resistor, any 0805 will do the job

- for assembly one will need "2.54mm 10 Pin Double Row Stackable Long Legs Female Header" and 4 screwed spacer sleeves

Link to post
Share on other sites

1 minute ago, Tido said:

Shall I ask Hijax what lead to the choice for a SPI chip versus an I2C,

I presume he read both threads, so let see if he reply soon ...

 

BTW, 74HC595 is not really SPI chip, but simple shift register attached to SPI, some kind of hack to save few pennies, since MCP23017 is more expansive than those 74HC595 ...

I prefer I2C because it can be driven by simple "i2cset" commands in bash shell, while SPI need more complex software to handle transactions. It is also possible to use unused GPIOs as inputs, while 74HC595 only provide outputs.

Link to post
Share on other sites

what lead to the choice for a SPI chip versus an I2C... I like to bring attention to the discussion regarding a component on the board.

 

@martinayotte ... looked on the components and brought up this point.

74HC595 is not really SPI chip, but a simple shift register attached to SPI, the MCP23017 i2c is more expensive than those 74HC595 ...

 

I prefer I2C because it can be driven by simple "i2cset" commands in bash shell, while SPI need more complex software to handle transactions. It is also possible to use unused GPIOs as inputs, while 74HC595 only provide outputs.

As we are looking at small production, and therefore the cost is relevant but not the priority, we focus on the easiest solution to keep the effort on testing and scripting as little as possible.

 

 

Please raise your discomfort, thankfulness or other ideas about the design idea per se. It is not about challenging the design, it is about using the sheer power of the crowd, as we have the chance.

 

Link to post
Share on other sites

On 7/23/2019 at 3:09 PM, Tido said:

??? why not keeping a technical discussion in the open Forum?

 

Agreed.

 

The I2C option has a top bus speed of 1.7 MHz, the shift register being fed from a SPI bus can be *much* faster (see cheap SPI TFT displays).  That said, it is easier to use the I2C from a software standpoint, and it's bidirectional.  

Link to post
Share on other sites

2x595 or MCP23017 - no problem to switch.  Actually 595 as simple shift register can be driven by SPI directly, yet on RPi header (first 10 pins) there is I2C, so no big deal to use MCP23017 instead.

Why I have chosen 595 initially? As it saves some pennies and footprint. And it it really simple to send command using "software SPI". And commands are to be sent rarely, no need for high speeds.

 

Concept picture of the automated test device:

 

 


 

obraz.png.52b04dc60f17c7159322036fe256500e.png

No spacers are visible.

Rock64  is a MasterSBC here, it is to be used to control 8 system under test - SBCs. Each of them connected using 10pin header (power + serial) plus custom SD card adapter.

On top of the MasterSBC is a (shorter) SD mux board, micro SD sockets placed on both sides of the PCB are invisible, as I have no 3D model for them (MOLEX 47219-2001 one). Also 4 pin headers would be replaced by JST XH2.54 ones.

Yes, instead of single SD shared between all SUTs, newest design has 8 SD cards, and MasterSBC can connect those to SUT or to itself for image uploading process. Of course if  SDx card is beeing used by MasterSBC, then SUTx shall be powered of as it will not see and SD card "inserted", will not boot.

 

Next to it, top one its serial mux + power distribution board, with 8 sockets of type Molex KK 254 AE 6410 04AKK 254.

 

Both add-on boards works together. When it comes to use cases, one shall use SPI / i2C interface to program 16 bit configuration word. 

 

From msb to lsb:

ME M2 M1 M0 SE S2 S1 S0 | P7 P6 P5 P4 P3 P2 P1 P0

 

Meaning of particular bits:

 - "Px"  is power section control (8 independent ports)

-  "Mx" is a SD card multiplexer control (8 micro SD cards)

-  "Sx" is a serial interface multiplexer control

 

Meaning of bits ME & SE:

 

ME : 0 - SUTx disconnected from SDx, MasterSBC connected to SDx pointed by M2-0
ME : 1 - SUTx uses SDx

SE : 0 - MasterSBC connected to SUTx serial pointed by S2-0, 7-seg led active
SE : 1 - No serial link crossed, 7-seg led inactive

 

So with this design all 8 SUTs can be power controlled at the same time, serial console be connected to one of he powered SUT while at the same time other SD card can be used to upload new image.

 

Examples:

Upload image to SD card 3, SUT 5 & 7 working, Master listens to Serial from SUT7
0 0 1 1   0 1 1 1   1 0 1 0 0 0 0 0

Upload image to SD#1 (thus) SUT#1 disconnected, all other SUT are working
0 0 1 1   1 0 0 0   1 1 1 1 1 1 0 1

Upload image to SD#1 all SUT are working (SUT1 do not see SD card, will not boot)
0 0 1 1   1 0 0 0   1 1 1 1 1 1 1 1

 

Comments appreciated.

 

I am attaching also schematics for anyone wanted to take a look.

(now with 595 which can be replaced for I2C connectivity). 

 

 

 

 

 

serial-mux.pdf sd-card-mux.pdf

Link to post
Share on other sites

3 hours ago, Hijax said:

So with this design all 8 SUTs can be power controlled at the same time, serial console be connected to one of he powered SUT while at the same time other SD card can be used to upload new image.

 

3 hours ago, Hijax said:

Comments appreciated.

 

Okay that sounds pretty awesome.    most of the boards should come up on the network anyway, so really the serial console is hopefully just for logging and debugging rather than test automation.   Being able to validate an image can boot successfully will be huge

Link to post
Share on other sites

I assume all SUTs will also be connected to network by means of Ethernet at least. Then not only uboot/kernel booting proces can be tested but also login via ssh over network as well. Detection if USB ports are working. Proper apt update etc.

 

One thing that will not be tested is the hdmi output. This however can be accomplished easily by connecting SBCs to single monitor via hdmi multi-viewer and camera that will take a picture when needed. 

 

I have several SBCs. Several cameras. 4-port multi viewer as well. What I do not have is the topic of this thread :)

 

But now you shall understand why I am so keen on constructing this mux device ;) 

Link to post
Share on other sites

1 hour ago, Hijax said:

I have several SBCs. Several cameras. 4-port multi viewer as well. What I do not have is the topic of this thread


I only have webcam :) ... but for testings I utilize 8 channel HDMI switch + HDMI recorder + TS monitor. Switch and recorder can be controlled from Linux. Switch can do up to 4k/30p but recorder can go up to 1080/60p (enough for now). I tried with few cheaper models in the past but there were many troubles ... this combination is the cheapest I found that works but its still fairly expensive.

Link to post
Share on other sites

Back to main (from my perspective) topic:

 

- Serial MUX board: I have changed analog to digital switching. I.e. instead of 4052 I placed 74HC151 & 74HC238 chips. Used P-MOS IRF7425 are chosen to minimize heat generation.

- SD mux board: total redesign here. Eight 74HC157 (quad 2-input multiplexer) are used to connect SD either to SUT or MasterSBC. Only SPI mode of SD is utilized here. From MasterSBC perspective CLK, DI and CS signals are connected to all SDs, while DO signal of every SD card is multiplexed so only only selected card is available at the time.

 

PCBs are designed to use only 2 layers (hence cheaper) with chips in SOIC enclosures. To make those easier for hand soldering.

 

I have already sent for production initial design of Serial-Mux board. I will use it to test some ideas.

But before sending next order I would appreciate comments on this design (fairly simple though)

Link to post
Share on other sites

First PCB from jlcpcb in on the way.

Meanwhile I have find some time to sit down on the mSD adapter.

 

obraz.png.f3b5017af9cdaed52683423267ed9e69.png

 

Small PCB with JST XH connector. Thus cables between mux boards and those should be 4-Pin JST XH Female Connector Double Ended ones.

 

An micro SD mux board final design:

obraz.png.a3ae0d4e20b6de81b3306a0feee811e7.png

 

And serial mux / power distribution (with I2C interface)

 

obraz.png.6952dcd5482de7e664d8e08581e8c60d.png

 

For serial / power connection, standard NEMA17 extender cable (4-pin JST XH & DUPONT connectors) will do the job.

Dupont connector inserted into following pins on the SUT board:

obraz.png.f38c9cfc6388b3c56da369579d35b2af.png

 

I have ordered 1m cables (JST/JST & JST/Dupont) from aliexpress.

 

 

 

Link to post
Share on other sites

1 hour ago, Hijax said:

NEMA17 extender cable (4-pin JST XH

these 4 pin cable get locked with their hooks, right?

If it is meant to leave these cables attached all the time, fine.  However, it maybe easier to plug /unplug these on the 'serial mux' than on the SBCs and in such a situation a connector with a notch /Snap Tab  would be easier to plug /unplug and still sit well.  For example /as an idea  like the 4 pin connector next to the CPU of X86 (ATX 12V 4 Pin Connector Motherboard).

 

Link to post
Share on other sites

12 minutes ago, Tido said:

these 4 pin cable get locked with their hooks, right?

 

JST connectors shall be locked in place and not touched, yes. This is due to the need of having firm board-cable connection, also there is no need to disconnect that.

 

For power & serial cable, second end I plan to use 4 pin Dupont connectors. This time for easy plugging into SBC 40pin header. 

Hence, together with uSD card adapter both can be reconnected as many times as one need.

Link to post
Share on other sites

  • Igor pinned this topic
  • lanefu unfeatured this topic
 Share

6 6