Bitcoin Forum
May 27, 2019, 04:56:54 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 [98] 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 ... 182 »
  Print  
Author Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary  (Read 434687 times)
Bitcoin_Bing
Newbie
*
Offline Offline

Activity: 46
Merit: 0



View Profile WWW
July 02, 2013, 07:41:17 PM
 #1941

The point is you need to leave this thread and beg for a loan elsewhere...this isn't for general discussion of different asicminers but for the development of the Klondike miners.

My apologies. Post deleted. Did not mean to get anybody upset.
1558933014
Hero Member
*
Offline Offline

Posts: 1558933014

View Profile Personal Message (Offline)

Ignore
1558933014
Reply with quote  #2

1558933014
Report to moderator
1558933014
Hero Member
*
Offline Offline

Posts: 1558933014

View Profile Personal Message (Offline)

Ignore
1558933014
Reply with quote  #2

1558933014
Report to moderator
1558933014
Hero Member
*
Offline Offline

Posts: 1558933014

View Profile Personal Message (Offline)

Ignore
1558933014
Reply with quote  #2

1558933014
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558933014
Hero Member
*
Offline Offline

Posts: 1558933014

View Profile Personal Message (Offline)

Ignore
1558933014
Reply with quote  #2

1558933014
Report to moderator
dimka890
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
July 02, 2013, 08:43:58 PM
 #1942

Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
cp1
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Stop using branwallets


View Profile
July 02, 2013, 08:53:25 PM
 #1943

Just hook your programmer up to the ICSP pins, compile, and flash the hex file.

Guide to armory offline install on USB key:  https://bitcointalk.org/index.php?topic=241730.0
Sophokles
Hero Member
*****
Offline Offline

Activity: 519
Merit: 500


die-hard GPU miner


View Profile
July 02, 2013, 09:45:03 PM
 #1944

Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed

Nice! Where did you order those? How long did it take? How much did you pay?
-Redacted-
Hero Member
*****
Offline Offline

Activity: 574
Merit: 501


View Profile
July 02, 2013, 10:56:43 PM
Last edit: July 02, 2013, 11:59:10 PM by -Redacted-
 #1945

Huh?  Where did these come from Huh?

(Yes.  China.)  I didn't realize there was a Klondike-1 in the works.   And people are having boards delivered already?
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 03, 2013, 12:54:08 AM
 #1946

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

joeventura
Hero Member
*****
Offline Offline

Activity: 770
Merit: 500



View Profile
July 03, 2013, 01:23:37 AM
 #1947

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 03, 2013, 01:29:05 AM
 #1948

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones
I haven't heard a peep from them so have no idea what they're up to or if they have made new boards or software.

gateway
Hero Member
*****
Offline Offline

Activity: 551
Merit: 500


View Profile
July 03, 2013, 01:31:24 AM
 #1949

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

I have a feeling that lots of people are already pressing boards before you even fully get yours working, fixed, or debugged.. oh well.. they have been warned
cardcomm
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 03, 2013, 02:12:06 AM
 #1950

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones
I haven't heard a peep from them so have no idea what they're up to or if they have made new boards or software.

I guess it can be very complex deciding the best vendor or group buy for purchasing chips and board assembly. I sure hope I chose the right one!  Undecided  haha

But for anyone that's been following this thread, it was clear that Terrahash was jumping the gun taking preorders and (allegedly) ordering boards knowing full well the design was not finished. Hopefully for those that purchased from them, they will ultimately deliver a product.

I'm really excited by this project, and I'm sure the design will be successful. Now if we can all just get through the chip arrival and board assembly process, we can be happily mining away...  Smiley

Easily see your cgminer status with my cgminerLCDStats app:  http://cardcomm.github.io/cgminerLCDStats/
Did my post help you or make you laugh? Let me know with Bitcoins at: 1CQfpMHQ5zVuZ5i9uxSHSSx4J8ZhehSjn3  Smiley
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 03, 2013, 03:24:16 AM
 #1951

Let's let BKKCoins post what needs to post here. This is a critical moment in the board development so we all need to let the people with the requisite skills communicate.  Time for questions about manuals, other builds and wow look they have K1s should be better placed in another thread.

If you have nothing to add to the technical aspects that BKKCoins is posting maybe it is better we all just step back and watch while they work. This thread is how they work.

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
dimka890
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
July 03, 2013, 07:03:05 AM
 #1952

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed
If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.
We hurried and ordered. Renewal came a week after the order(

Just hook your programmer up to the ICSP pins, compile, and flash the hex file.
i don't see hex files on github repository (( Maybe i doing something wrong?
Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  Embarrassed

Nice! Where did you order those? How long did it take? How much did you pay?
www.szviivtech.com
100pcs - 149USD
itod
Legendary
*
Offline Offline

Activity: 1456
Merit: 1017


^ Will code for Bitcoins


View Profile
July 03, 2013, 08:53:34 AM
 #1953

We hurried and ordered. Renewal came a week after the order(
...
100pcs - 149USD
At least price was not high for 100pcs. Better not order anything yet since not only PCB but BOM also are subject to change.
evilscoop
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
July 03, 2013, 10:16:30 AM
 #1954

the temptation to jump in a press the boards is high....
Im in a similar position, but have said I wont press them till they are stable, evan if this mean I miss batch 1

Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 03, 2013, 10:23:30 AM
 #1955

the temptation to jump in a press the boards is high....
Im in a similar position, but have said I wont press them till they are stable, evan if this mean I miss batch 1

+1 that is the best move for everyone involved. Measure twice cut once.

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 03, 2013, 11:19:56 AM
Last edit: July 03, 2013, 11:48:41 AM by BkkCoins
 #1956

I've solved the USB disconnect issue - I think. It hasn't done that for quite a while now. It was an issue with interrupt handling in the PIC. But the solution creates a timing sensitive condition where I've had to make the USB have priority and this could cause result bytes to be misread. I'm looking for a way to handle this now. Result bytes need to be handled in < 8uS and originally I had this block all interrupts to catch them (32uS blackout), but this is enough to throw the USB into fits, so I need a way they can co-operate but guarantee the result bytes get moved.

Ever since upgrading to cgminer 3.3.1 I've noticed that the screen updates very slowly. Sometimes it doesn't output any info for many seconds - up to 10 seconds. I have no idea what change was made that causes this now. If anyone knows why this happens please inform me. It seems to still work and the log file has entries every 2-3 seconds but the screen sometimes doesn't seem to get it's update.

I've also enhanced the PIC code to use a circular buffer for USB writes to host so that it can handle collisions gracefully. I'm not sure if this was part of the issue but I do see some data overruns which this should prevent.

edit: Actually the result overrun doesn't seem to be an issue because if an that occurs it increments the PIC error count and I've yet to see that occur. I just modified the result capture to handle multiple bytes in one ISR call, which means it can stand up to 16 uS of USB takeover.

Knock on wood - I'm seem to be seeing better capture now as I've hit 8 accepted nonces without HW errors. So I smell improvement.

BenTuras
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
July 03, 2013, 11:55:51 AM
 #1957

It was an issue with interrupt handling in the PIC. But the solution creates a timing sensitive condition where I've had to make the USB have priority and this could cause result bytes to be misread. I'm looking for a way to handle this now. Result bytes need to be handled in < 8uS and originally I had this block all interrupts to catch them (32uS blackout), but this is enough to throw the USB into fits, so I need a way they can co-operate but guarantee the result bytes get moved.
I guess your problem is blocking of interrupts while handling an interrupt.
Are you taking too much time to handle an interrupt ?
Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ?
This low level routine can then handle both usb and result bytes input.
Higher level routines can then poll for data in the circular buffer.

I am selling in stock OneStringMiner boards, based on the Bitfury chips. Have a look here: https://bitcointalk.org/index.php?topic=495536.0
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 03, 2013, 12:07:18 PM
 #1958

I guess your problem is blocking of interrupts while handling an interrupt.
Are you taking too much time to handle an interrupt ?
Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ?
This low level routine can then handle both usb and result bytes input.
Higher level routines can then poll for data in the circular buffer.
Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.

Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?

loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
July 03, 2013, 12:16:10 PM
 #1959

I guess your problem is blocking of interrupts while handling an interrupt.
Are you taking too much time to handle an interrupt ?
Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ?
This low level routine can then handle both usb and result bytes input.
Higher level routines can then poll for data in the circular buffer.
Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.

Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?
Bkk,

About HW errors with current Avalon Implementation they are less that 1.5% clocked at 350




Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
BenTuras
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
July 03, 2013, 12:35:56 PM
 #1960

Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.

Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?
My 3 module Avalons vary between 1.1% and 2.2% HW according to formula of CK: 100 * HW / (diff1shares + HW)

I am not trying to be smart, just trying to help with my common sense (and a long gone history of assembly hacking) Wink

I had a quick look at the PIC16(L)F1454/5/9 preliminary data sheet, focussing on interrupts. If I understand correctly, an interrupt occurs, it does automatic context saving, it jumps to the interrupt service routine(ISR) and there you need to determine the source of the interrupt by polling the interrupt flag bits, handle the interrupt, reset the global interrupt enable bit(GIE) and return from interrupt(RETFIE) which restores the context. If a new interrupt is pending, it will be handled after one instruction has been executed after returning from the interrupt.

Maybe your 'unacceptable to the USB stack' was caused by the fact that a second interrupt became pending while you were still handling the first interrupt ?

I am selling in stock OneStringMiner boards, based on the Bitfury chips. Have a look here: https://bitcointalk.org/index.php?topic=495536.0
Pages: « 1 ... 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 [98] 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 ... 182 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!