Tido Posted July 22, 2019 Posted July 22, 2019 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 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?
Hijax Posted July 22, 2019 Posted July 22, 2019 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.
Hijax Posted July 22, 2019 Posted July 22, 2019 Ok chaps, final design of serial mux board, plus zip file full of gerber files. serial-mux.zip BOM: 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 } 3
Tido Posted July 22, 2019 Posted July 22, 2019 On 7/14/2019 at 4:30 PM, lanefu said: I haven't tested it so I don't know if that will help, but there's a tool named "LAVA", used by the Linaro folks, which is basically a CI agent devised for ARM boards and software testing. https://master.lavasoftware.org/static/docs/v2/index.html#lava-overview Beside Bash & Python, don't forget this option
Hijax Posted July 22, 2019 Posted July 22, 2019 One more update, I have added LEDs close to every port to show powering status and 7seg LED display to show which Serial is currently connected. 3D view: https://autode.sk/2OcgRSL 1
lanefu Posted July 22, 2019 Author Posted July 22, 2019 @Hijax awesome. If you're cool with it can i submit a test print to jlcpcb and order components?
Hijax Posted July 22, 2019 Posted July 22, 2019 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.
Tido Posted July 22, 2019 Posted July 22, 2019 Can we take the time and think about the whole package, including cables and adapters? Also, unless someone like @TonyMac32, hasn't overlooked the design I would wait to order, production takes longer. Who else beside Tony has some electronics know how? 1
Tido Posted July 22, 2019 Posted July 22, 2019 10 hours ago, Hijax said: Anyway the 4mm track I placed on PCB shall be enough to provide 7.5W to each of all 4 SUTs. 4 SUT.. why is there hardware for 8 Ports?
Hijax Posted July 22, 2019 Posted July 22, 2019 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 1
TonyMac32 Posted July 22, 2019 Posted July 22, 2019 I only got internet back today, my modem died after 5 years. Let me see.
lanefu Posted July 23, 2019 Author Posted July 23, 2019 2 hours ago, TonyMac32 said: my modem died after 5 years. Sorry for your loss; congrats on your upgrade.
Hijax Posted July 23, 2019 Posted July 23, 2019 @lanefu hold yourself with sending for production. Let me build the prototype, and when verified, I will publish final production files. 2
martinayotte Posted July 23, 2019 Posted July 23, 2019 17 hours ago, Tido said: Who else beside Tony has some electronics know how? Me ... 5
martinayotte Posted July 23, 2019 Posted July 23, 2019 44 minutes ago, count-doku said: But we should definetely have a few people look at the schematics I did ... Personally, I would rather use a MCP23017 I2C GPIO Expander instead of the 2x 74HC595 on SPI, it would be easier and more flexible ...
martinayotte Posted July 23, 2019 Posted July 23, 2019 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.
Tido Posted July 24, 2019 Posted July 24, 2019 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.
TonyMac32 Posted July 25, 2019 Posted July 25, 2019 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.
Igor Posted July 25, 2019 Posted July 25, 2019 1 hour ago, TonyMac32 said: Agreed. Merged stuff from private thread. OT posts were left there and are hidden out. 2
lanefu Posted July 26, 2019 Author Posted July 26, 2019 so i'm getting a little confused about the muxing and level shifting for console So the board itself won't have a UART, and its going to mux/switch TTL consoles to a single UART on the Master SBC?
Hijax Posted July 26, 2019 Posted July 26, 2019 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: 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 1
lanefu Posted July 26, 2019 Author Posted July 26, 2019 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
Hijax Posted July 26, 2019 Posted July 26, 2019 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 1
lanefu Posted July 26, 2019 Author Posted July 26, 2019 44 minutes ago, Hijax said: This however can be accomplished easily by connecting SBCs to single monitor via hdmi multi-viewer okay off-topic... but i was searching for mutliviewer and found the ultimate tribute to Radio Shack product design
Hijax Posted July 26, 2019 Posted July 26, 2019 I am using this multiviewer https://www.dmtrade.pl/p8826,multi-viewer-hdmi-4-1-pip-spacetronik-sph-mv41pip.html
Igor Posted July 26, 2019 Posted July 26, 2019 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.
Hijax Posted July 26, 2019 Posted July 26, 2019 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)
Hijax Posted July 30, 2019 Posted July 30, 2019 First PCB from jlcpcb in on the way. Meanwhile I have find some time to sit down on the mSD adapter. 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: And serial mux / power distribution (with I2C interface) 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: I have ordered 1m cables (JST/JST & JST/Dupont) from aliexpress. 1
Tido Posted July 30, 2019 Posted July 30, 2019 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).
Hijax Posted July 30, 2019 Posted July 30, 2019 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. 1
Recommended Posts