Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 25. (Read 176728 times)

I'm using the legkodymov cgminer fork... I haven't dug into how exactly it runs these chips.  I guess I need to get involved in that soon.

I've got it running 9.5GH on seven chips; was running 8.5GH on four.  Pretty disappointing

same task being given to multiple chips and/or waiting for repeats of the result? sounds like the isue relates to how the chips are being sent commands

take all but one chip out?

So I got three more chips placed on my board... all seven are recognized, but it runs SLOWER than it did with four!

Tweaking clock and voltage trying to find a happy medium.  Anyone have any suggestions?

oh, my bad. I was thinking of 101BTC.

I haven't posted any pix or details about our device (until now)...you're probably mixing me up with someone else.


ahh..in that case, you can use that code for reference (if you aren't already) =P. There's also https://github.com/daniel-santos/mcp2210-linux, but much more immature.


Yeah, we were probably wrong to go with the mcp2210 since it didn't save any time...should have investigated the linux API and datasheet more thoroughly. At first glance, the USB-SPI chips seem more amenable to software-only guys since you only need to write host code and don't need to write the firmware.

True, but the bitfury chips don't have much that is to be controlled. You can set the clock oscillator options, and that's about it. On the other hand, a microcontroller can do other useful stuff like monitor the board temperature, voltages, and even adjust the core voltage to allow smart overclocking: on a cool day, or with good ventilation, the chip will automatically hash faster, and on a hot day, it will automatically slow down to protect itself.

Firmware update could be a problem depending on the chip. The LPC11U have an option to boot as a mass storage device with a FIRMWARE.BIN file that you can overwrite. Alternatively, you could make some sort of bootloader.

No I'm not. I've written my own spi communication code on our usbutils. I've been burnt enough by external libraries...

np. You're probably using the code from https://github.com/kerrydwong/MCP2210-Library. This code needs to be modified to send large transactions (> 64 bytes) since the chip only supports 64 byte transmissions. I've spent a few days getting stuff to work and only just today got the chip to start consuming power (first 317 initialization bytes have been accepted)...tomorrow I make it hash =P.

Ohhhh... tell me about it! I hated that documentation when I read it the first time. And then I saw the chip on your boards and went back and reread it ... and hated it even more... I think you pretty much qualify for a hero for figuring it out!

Thanks very much for at least that information. I'm still not even sure if it's going to be possible then, but I'll keep poking.

Ha! I was so focused on driving the MOSI pin that I overlooked the idea of messing up with the SCK pin .. and that's even better!
By the way - the trick with the resistors would work just fine. (I've done it countless times on PICs - just pick the resistors so that current doesn't go over 2-3mA). And it's much cheaper than the MUX option

This was our initial thought as well, but the mcp2210 has such poor documentation and incomplete API that I've wasted far more time trying to get the mcp2210 to work than a normal microcontroller. On the plus site, the USB to SPI connection can provide the mining software for more control/flexibility since it can directly send commands to chips/SPI bus. Also, you don't need to flash firmware updates...

Note that you need 3 MOSI toggles for each chip in the chain.

Well, my method only works for us because we have a hardware MUX. The mcp2210 doesn't allow us to directly control SCK, so need to switch to a GPIO during the reset sequence.

The reset sequence is as follows:
---
Switch SCK to high (no oscillations)
Toggle MOSI 16 times. (at 1 MHz)
Switch SCK to low
---
That's how bitfury's reference code works on the RPI. However, you do have greater freedom if you need. Here's a response I got from Tytus about the reset sequence:


In order for us to set SCK to high during the reset, we toggle the MUX select line and switch from the mcp2210's SCK pin to a GPIO pin so INCLK on the bitfury chip sees a constant high level. Then we toggle MOSI (send 16 bytes of 0xff or 4 bytes of 0xAA or 0x55 as long it toggles MOSI). Then we set our GPIO pin to low and change the MUX select line back, so INCLK on gets SCK from the mcp2210.

Unless you have the MUX, I don't think this will work for you, but maybe it can give you some insight into how that sequence works.

The btc101 usb device has an MCP2210 chip. I keep poking it like a little kid with stick does to a dead animal, and that's how it behaves in response...

The mcp2210 chip shows up as an HID device under linux, and you're not really meant to use the SPI on it directly, yet the cgminer forked code opens it using the spidev interface on linux by mmap directly into /dev/mem and using some magic constants for memory offsets that correspond with the RPi ... that approach is about as portable as a brick shithouse.

We're using LPC11U. I'm just finishing the firmware for it. PC interface is a simple virtual com port over bulk endpoint. The PC software just sends 'work ' to send work to the chip(s), and the firmware sends back 'submit ' whenever it finds something.

I agree. I think at the end this will be the best solution. You can get a very cheap PIC with USB support for about $1-1.5 and it can take care of the heavy lifting and drive multiple (bitfury) chips. But - that would require more development for the PIC coding.
As an interim solution - the FT232R chip is about $2-2.5 and the CY7C65211 is $3-4 which I think is bearable for a start.

Option 1:
To be honest my initial idea was to use a RS232 serial port directly - TxD would be MOSI, RxD would be MISO (or any of the other inputs like RI, RTS, etc) and DTR would be SCK and I was going to manually drive them high/low. It works sufficiently fast (>200kHz) with built-in COM ports. Unfortunately it is horribly slow when using a USB-to-Serial chip such as FT232R (about 1kHz). It is still doable but somewhat pointless as there is a better option - see option 3.

Option 2:
The next option I looked at was MCP2210. But you can't switch the SPI pins into GPIO. I can tweak the SCK pin (by switching the phase) but I can't do anything about the MOSI one. The only (cheap) solution was going to be to sort of short-circuit it with another GPIO pin via a small resistor like this:
(MOSI) ---[200]--- (GPIO) ---[2k2]--- (BitFury INMOSI) ---[2k2]--- GND
I would put the GPIO as an input normally so that it doesn't interfere, and during RESET I would make it an output and use it to override the MOSI pin. It's ugly though. And the MCP2210 chip is waaaay overly complicated.

Option 3:
My next option was actually reusing the FT232R. In async bitbang mode it uses its 8-bit DBus and does a write followed by a read. I can just deserialize all pins - e.g. if I need to send-and-read one bit (let's say "1") and bit 0 is MOSI, bit 1 is SCK (both outputs) and bit 2 is MISO (input) I would write to the chip:
1) 0000-0?01 - set MOSI
2) 0000-0?11 - set SCK
3) 0000-0?11 - dummy - just to even out SCK 0s and 1s (and possibly optimize the code down the road by skipping 4 bytes)
4) 0000-0?01 - clr SCK
Since it does a read after each write I would read the result after 4) and that would be my MISO read bit.
I liked the simplicity of that chip - barely a few components. On the downside it would be a lot of manual labor rolling out the SPI protocol. But on the good side you can set the clock speed at 3MHz, so you effectively get 750kbps SPI. (at roughly 75 bytes per transaction that's 1000 chip-requests per second).
I tested that with a FT232R board that I had handy and confirmed that this will work.

Option 4:
And then I found the CY7C65211 chip. Oh joy of joys!
You can switch each of the SPI pins to GPIO if you want (so here is the RESET sequence). My plan is for the RESET sequence to manually drive each of the GPIO pins, and once done to switch them back to SPI mode.

Want to describe the sequence for me in detail please?