Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 84. (Read 435369 times)

I'm not sure what the formula is. I was just going by the value reported at the top of screen as HW: and comparing it to A: value also at top of screen. Not very sophisticated.

Regarding interrupts, GIE isn't disabled when handling an interrupt, so interrupts can be interrupted. But if I do set GIE=0 then that causes enough disruption to the USB stack in terms of timing delays while waiting for the servicing that is chokes and disconnects. I'm not worried now as I have solved that sufficiently that it no longer disconnects and the result capture hasn't so far had overruns related to not being service quickly enough.

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)

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 ?

Bkk,

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

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?

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'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.

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

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

At least price was not high for 100pcs. Better not order anything yet since not only PCB but BOM also are subject to change.

We hurried and ordered. Renewal came a week after the order(

i don't see hex files on github repository (( Maybe i doing something wrong?
www.szviivtech.com
100pcs - 149USD

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.

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!    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...  

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

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.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones

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.

?  Where did these come from ?

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

Nice! Where did you order those? How long did it take? How much did you pay?

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

Recived today from China

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine