cp1
|
|
June 08, 2013, 03:13:06 AM |
|
My pickit is finikcy too -- sometimes it seems erasing the pic's menory and restarting mplab helps, but I think it's just random when it works and doesn't.
|
|
|
|
fasmax
|
|
June 08, 2013, 03:22:48 AM |
|
Glad you got it to work. You said a full work push takes 385 us. How many bytes is this transfer ?
108 bytes. Each bit is typically 166nS low and 249nS high, but there is a gap between 32 bit words as well. I push 32 bits rolled out in asm and loop each data section in asm. Also, this is to both banks simultaneously, so really I push 216 bytes with most being the same to each bank but the nonces being bit-split. (My term for splitting the ranges during the push) There is a way to get to 83nS low and 166nS high, but it's more involved, and with a further trick I think I can get exactly 125nS low (as specified by ASIC), and 250nS high (seems acceptable depending on spec reading). But this is only in bursts, with idle between and overall isn't as fast due to time to setup data. Do you ever go idle during the 108 byte transfer? I was wondering if going idle on the config bus would result in the ASIC starting its search before all the config data is transferred. The documentation did not seem complete on this.
|
|
|
|
BkkCoins (OP)
|
|
June 08, 2013, 03:56:20 AM |
|
Do you ever go idle during the 108 byte transfer? I was wondering if going idle on the config bus would result in the ASIC starting its search before all the config data is transferred. The documentation did not seem complete on this.
Ya, it's vague and I wondered about that. Currently I do go idle between data sections but I don't have to. I made it explicit so if the idle causes it to reset, then I'll move it to the end. I put it after each section now as it makes it easy to see the sections on the LA.
|
|
|
|
fasmax
|
|
June 08, 2013, 04:15:41 AM |
|
Do you ever go idle during the 108 byte transfer? I was wondering if going idle on the config bus would result in the ASIC starting its search before all the config data is transferred. The documentation did not seem complete on this.
Ya, it's vague and I wondered about that. Currently I do go idle between data sections but I don't have to. I made it explicit so if the idle causes it to reset, then I'll move it to the end. I put it after each section now as it makes it easy to see the sections on the LA. I kind of convinced myself the when both config signals go low that it resets the internals and gets ready to receive configuration and when both config signals go high that it would release the chip from config mode and start hashing.
|
|
|
|
Adano
Member
Offline
Activity: 108
Merit: 10
|
|
June 08, 2013, 09:21:56 AM Last edit: June 08, 2013, 09:37:25 AM by Adano |
|
BkkCoins, I m sorry for distracting you, but did you see this? https://bitcointalk.org/index.php?topic=228677.0Bitfury gives away his chips to testers. Are you in?
|
Flatter me, and I may not believe you. Criticize me, and I may not like you. Ignore me, and I may not forgive you. Encourage me, and I will not forget you.
|
|
|
erk
|
|
June 08, 2013, 09:39:54 AM |
|
|
|
|
|
|
Bicknellski
|
|
June 08, 2013, 11:25:59 AM |
|
Ya not Avalon chips... so why do we need to talk about that here. Send PM to people. Keep the thread clear of this stuff guys please.
|
|
|
|
dan99
|
|
June 08, 2013, 02:24:37 PM |
|
Ya not Avalon chips... so why do we need to talk about that here. Send PM to people. Keep the thread clear of this stuff guys please.
Yes better keep to Avalon DIY by Bkkcoins. At this stage his focus is pretty much on Avalon DIY Chip, as you see they is a huge chip buy...hopefully sample is coming soon
|
|
|
|
torzsy
|
|
June 08, 2013, 05:36:50 PM |
|
Whats the difference between 702N and 703N? Can 702N flashed with OpenWRT and used for K16 mining? I have a dealer who sells 702N very cheap. Or should I order 703N? Thanks.
|
|
|
|
wrenchmonkey
|
|
June 08, 2013, 06:44:14 PM |
|
I think the 702n is missing the USB connector, which would make it useless for this application. It also has too small a flash size to run the openwrt firmware.
Still a decent little knock-around router for general purposes though.
|
|
|
|
torzsy
|
|
June 08, 2013, 07:10:17 PM |
|
I think the 702n is missing the USB connector, which would make it useless for this application. It also has too small a flash size to run the openwrt firmware.
Still a decent little knock-around router for general purposes though.
Ahh yes, it has only a micro usb. Thanks for your answer.
|
|
|
|
KS
|
|
June 08, 2013, 07:13:45 PM |
|
Whats the difference between 702N and 703N? Can 702N flashed with OpenWRT and used for K16 mining? I have a dealer who sells 702N very cheap. Or should I order 703N? Thanks. 702N also has much less RAM/FLASH 2MB/8MB (or vice versa - half the 703N AFAIK) and is not supported by OpenWRT.
|
|
|
|
wrenchmonkey
|
|
June 08, 2013, 07:51:18 PM |
|
I think the 702n is missing the USB connector, which would make it useless for this application. It also has too small a flash size to run the openwrt firmware.
Still a decent little knock-around router for general purposes though.
Ahh yes, it has only a micro usb. Thanks for your answer. That micro USB is a power header, not a communications bus. If it were an actual communications port, the physical port size wouldn't matter, as it would be no big deal to make a cable for it. However, power headers are pretty worthless for anything other than supplying power. And, as I said before, the flash size is too small anyway.
|
|
|
|
zefir
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
June 09, 2013, 11:34:58 AM |
|
Cross-post in all threads of projects that are registered for Avalon sample chips from my order.Delivery of sample chips seems to have started. If you have chips ordered with me that you want to support this project with, do it now. If you are the owner of this project, please provide me your shipping address. Find the details here.
|
|
|
|
BkkCoins (OP)
|
|
June 09, 2013, 11:16:56 PM |
|
I'll just confirm that any info I uncover from testing sample chips will be made freely available. And time permitting if specific tests are requested I'll try to provide answers for them as long as I don't think that chip damage could occur due to testing, or that it interferes with finishing my own tests.
If I had to reduce testing to a level where I was comfortable saying "ok this works", I'd say 2 chips per bank and there is 2 banks on a K16 board, ie. 4 chips. This allows testing the ASIC chain, the result wire-ORing, and nonce range splitting between banks. Having more chips would not help much with testing stacking or multiple K16 chaining as those functions are independent. It possibly could help with detecting timing issues in the code under heavier utilization.
The primary reason to have more test chips would be to test the K16 under heavy power use and heat dissipation and I think that's useful, of course, but will have to be approached according to how many samples I end up receiving. Sure, more would be better and allow more complete testing such that board users/assemblers/mfrs can be more sure that some use conditions won't have problems. If I can't test everything I'll try what I can and probably simulate what I cannot.
(I'll cross post this in the ASIC sample-news thread for completeness)
|
|
|
|
daemondazz
|
|
June 10, 2013, 02:13:12 AM |
|
Thanks BKK, (as the tech lead in another project) definitely appreciate your openness!
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
Enigma81
|
|
June 10, 2013, 02:21:57 AM |
|
Woke up this morn and started messing with the PICKit3 again. It still didn't work. But after trying many things I decided to try the Programmer To Go mode (where it stores a bin image in it's memory so you can program without USB to PC). This didn't work either, but when switched back to regular mode it magically started working again. Great! So I'm off on new work again but with the fear hanging over me that it could crap out any time. Grrr.
(BTW back in the day I had a couple of those parallel PIC programmers, and a USB programmer made in Thailand later on, and then a PICKit2. Unfortunately none of those methods now have support for this new chip and I even had to buy the PICKit3 despite having my PICKit2 on hand. Though, apparently the PICKit2 may be useful for re-programming the PICKit3.)
I've got dozens of PICKIT3s, and they all do this once in a while. The simple solution, almost every time, is to set MPLAB to a different chip family (PIC121840, for instance), then connect the pickit. It will tell you that a new firmware must be downloaded to the PICKIT to work with that different chip family. Say ok. Then switch it back to your real chip. Again, it will say it needs a new firmware. Say ok again. Should be functional. Enigma
|
|
|
|
BkkCoins (OP)
|
|
June 10, 2013, 02:53:20 AM |
|
I've got dozens of PICKIT3s, and they all do this once in a while. The simple solution, almost every time, is to set MPLAB to a different chip family (PIC121840, for instance), then connect the pickit. It will tell you that a new firmware must be downloaded to the PICKIT to work with that different chip family. Say ok. Then switch it back to your real chip. Again, it will say it needs a new firmware. Say ok again. Should be functional.
Enigma
Thanks. I'll try that. I've also discovered that using Programmer To Go mode is more reliable. Disconnect from my circuit, program as To Go mode, then connect and press button - works almost always, which seems to indicate it's not a problem with my circuit hookup but MPLAB-X software (since it goes off the deep end and can't recover).
|
|
|
|
Enigma81
|
|
June 10, 2013, 03:20:44 AM |
|
I've got dozens of PICKIT3s, and they all do this once in a while. The simple solution, almost every time, is to set MPLAB to a different chip family (PIC121840, for instance), then connect the pickit. It will tell you that a new firmware must be downloaded to the PICKIT to work with that different chip family. Say ok. Then switch it back to your real chip. Again, it will say it needs a new firmware. Say ok again. Should be functional.
Enigma
Thanks. I'll try that. I've also discovered that using Programmer To Go mode is more reliable. Disconnect from my circuit, program as To Go mode, then connect and press button - works almost always, which seems to indicate it's not a problem with my circuit hookup but MPLAB-X software (since it goes off the deep end and can't recover). Oh yeah, MPLAB-X, in my opinion, sucks. I still use 8.8X. MPLAB-X was such a resource hog and seemed quite unstable. I have nearly zero issues with PICKIT3 and MPLAB 8.8X - Other than the occasional loss-of-mind that I mention above, they work great for $40 programmers. Even the loss of mind is quite infrequent. Enigma
|
|
|
|
|