For industrial-scale mining, you want a different project and you want someone other than me to design it because I really don't care one bit about industrial-scale miners. And this project will not use CAN, this project will use USB because specifically-non-industrial miners will probably get along better with it. Also because the point of the framework is to be generic, and I don't really see the use-case for stickminers or pods or a single S1 using CAN instead of USB and those are the use cases I do care about.

1 Firewire cable from the PC feeds first drive, that drive and all other drives is also a repeater (hub) with extra 2 ports. Each port from that drive feeds 2 more drives which also have 2 extra ports, those feed 2x more drives, rinse and repeat. Think of a tree, first FW cable from the PC is the trunk which branches out at each drive and the branches have branches. Any other name for that branching config?

Also if it connector durability really becomes an issue one can always use industrial grade high-retention force USB sockets. Exceeding reliable but also cost around 5x what you can get normal USB sockets for...

Here are Firewire stats from one of our systems that has been running 24x7 for the past 3 weeks. It has 14 axes of motion with the motor drives fed via Firewire in a daisy-chained star config. 1 main feed to 1st driver, branching out to 2 more drives, branching out to two more, etc.
https://imgur.com/kvWcSM1

Perfect with zero errors. Then again, they are fed by the motion systems RTOS which WIndoze rides on top of...

Yeah that's great, since the micro has an I2C bus. Except it's already in use talking to sensors as specified in my post on the first page. So if you want to make sure to address around those sensors (which are going to be implementation-dependent of course) I guess it's possible. And then add that into the firmware. And then add it into the driver on whatever you're compiling cgminer on.

So, to be not sarcastic, yes it's possible. Also, I'm not gonna do it. Please read my post on the first page with a description of everything I am going to do. If you want to extend that further on your own you're welcome to it, but I'm not going to. One of the things mandated was no design-by-committee because exactly this kind of thing happens. Feature creep kills time-sensitive projects just as much as anything. So, no offense guys, but I'm probably going to ignore all suggestions for at least the next month or so since Novak and I already spent most of a year talking over and ironing things out to where they are now and I figure that's good enough.

Funny, because I have exactly the opposite experience. I've never had USB-B problems, but mini are decent (though sometimes the connector comes off the board) and micro tend to disconnect, or more likely break, all over. I will never deliberately put a micro USB connector on something I want to work for very long. My first preference is USB-B, followed by mini.

While I liked the Firewire disk devices that I had, it's day is long since over. The USB universe has completely run roughshod over Firewire. Hubs, ports, cables are way more available and less costly for USB than Firewire.

It would be nuts to have your hashing hardware require a Firewire port for correct operation.

i had a lot of firewire 400 fire wire 800 they were a bit more reliable then usb2.  but the cables are costly.

usb2 I have run 121 usb2 sticks off 1 pc.  but truth be told it was a pita

but 40 usb sticks easy.

17 gridseed blades on 1 pc a pita but 12 blades on 1 pc was easy.

I have 4 or 5 pcs

 so putting 1  on the side to mine a dozen pcbs in the solar array should be a piece of cake

i never ran them but i know my school used to and they hardly ever failed... i bet theres some info online about them though

what about the ability to run them with a nic on each miner

or run 1 nic to a switch then the others would connect via usb to miner 1 and make a usb hub style where they could daisy chain down the line with less clutter of going mass into a switch with alot of cat 5 cables ? just a idea i had kinda like the old firewire days where you could keep chaining devices down the line till u needed another hub to boost the power

I think the part Novak spec'd is an NXP chip.

Okay am I missing something.

a simple cheap usb 2 hub like so

http://www.amazon.com/Sabrent-Adapter-Control-Switches-HB-U14P/dp/B00HL7Z46K/ref=pd_sim_sbs_147_1?

and a simple cable tie

http://www.amazon.com/Case-Logic-Attaching-Assorted-Colors/dp/B00004TZF9/ref=sr_1_1?

and you have 13 boards to 1 pc.

If that proves problematic   due to too many board on 1 hub then two of these

http://www.amazon.com/AmazonBasics-Port-USB-Power-Adapter/dp/B00DQFGJR4/ref=sr_1_3?

with the same ties and you have 14 boards.

Maybe it would make sense too consider using a Cat6 connection when chaining boards and the final output would be sent thru USB to the controller or hub but if some one had a dual NIC motherboard, then that could be used instead.

As I understand it, the goal is to use USB as the interface, that way you can use whatever controller option suits you provided it can run cgminer.  Quite flexible.

I remember when there were only a handful of people in the world who really understood Border Gateway Protocol (BGP) and we had to hunt them down and share them with our "competitors" when we were setting up PSINet in Japan.

Procedure

   This is the procedure for the TCP and IP Bake Off.  Each implementor
   of a TCP and IP is to perform the following tests and to report the
   results.  In general, this is done by using a test program or user
   Telnet program to open connections to your own or other TCP
   implementations.

   Some test are made more interesting by the use of a "flakeway".  A
   flakeway is a purposely flakey gateway.  It should have control
   parameters that can be adjusted while it is running to specify a
   percentage of datagrams to be dropped, a percentage of datagrams to
   be corrupted and passed on, and a percentage of datagrams to be
   reordered so that they arrive in a different order than sent.

   Many of the following apply for each distinct TCP contacted (for
   example, in the Middleweight Division there is a possibility of 20
   points for each other TCP in the Bake Off).

   Note Bene: Checksums must be enforced.  No points will be awarded if
   the checksum test is disabled.

      Featherweight Division

         1 point for talking to yourself (opening a connection).

         1 point for saying something to yourself (sending and receiving
         data).

         1 point for gracefully ending the conversation (closing the
         connection without crashing).

         2 points for repeating the above without reinitializing the
         TCP.

         5 points for a complete conversation via the testing gateway.

      Middleweight Division

         2 points for talking to someone else (opening a connection).

         2 points for saying something to someone else (sending and
         receiving data).

         2 points for gracefully ending the conversation (closing the
         connection without crashing).

         4 points for repeating the above without reinitializing the
         TCP.

         10 points for a complete conversation via the testing gateway.

      Heavyweight Division

         10 points for being able to talk to more than one other TCP at
         the same time (multiple connections open and active
         simultaneously with different TCPs).

         10 points for correctly handling urgent data.

         10 points for correctly handling sequence number wraparound.

         10 points for correctly being able to process a "Kamikaze"
         packet (AKA nastygram, christmas tree packet, lamp test
         segment, et al.).  That is, correctly handle a segment with the
         maximum combination of features at once (e.g., a SYN URG PUSH
         FIN segment with options and data).

         30 points for KOing your opponent with legal blows.  (That is,
         operate a connection until one TCP or the other crashes, the
         surviving TCP has KOed the other.  Legal blows are segments
         that meet the requirements of the specification.)

         20 points for KOing your opponent with dirty blows.  (Dirty
         blows are segments that violate the requirements of the
         specification.)

         10 points for showing your opponents checksum test is faulty or
         disabled.

Yes if you see any "snake" type traces its because they are parallel IO traces to some other longer traces, so they need to make the traces the same lengths hence the snakes. If you check out your PC motherboard you'll see them all over the place on the PCIe and RAM lanes. When your talking about throughputs in the muti Gigabits/s even the speed of light works against you

This does not matter on anything bitcoin related though, since these are very dumb chips IO rates coming to/from them are in the order of sub 1Mb/s, since nothing larger than a couple hundred bytes is ever sent to the chips( and return IO is even less...just an 8 byte nonce return and maybe a few bytes of chip info data).

Really? Are you for real? Nobody will buy these chips when they are less than 1 month away from mass deploying their new 16nm chip that needs less than 0.1W/GH. Please stop with your shilling!

What my basic plan is, is to use a basic USB-capable AVR microcontroller as a board-level brain. The chip Novak liked had a decent array of IO bus, including UART, SPI and I2C. We can interface to sensors and controls using I2C, use GPIO for fan speed, and interface to ASICs on UART or SPI.

Am I correct that the guys are trying to push more "rubbish" to the "error tolerant" protocol to increase their "mining power"?

Er, SideHack and I were just discussing them early this morning... Get out of our minds!!!
the pic of the  BitFury 48 chip board is pretty but considering all those traces are address and data coms lines that is just begging for trouble from crosstalk and depending on the actual speed the coms to each chip are, signal reflection. Problematic but usable with careful termination at both ends of the traces but shorter is better and easier to push to higher speeds.