On 2012年02月28日 10:48, Stefan Tauner wrote:
Well, it may be more clear to specify exact frequencies, but we may end up with weird set of frequencies for all these large dividers. Maybe it would be better to support a limited set of "standard" dividers and their corresponding frequencies, like:
divider | freq --------+-------- 2 | 30MHz 4 | 15MHz 6 | 10MHz 8 | 7.5MHz 10 | 6MHz 12 | 5MHz 20 | 3MHz 30 | 2MHz 60 | 1MHz 80 | 750KHz 100 | 600KHz 120 | 500KHz 150 | 400KHz 200 | 300KHz 300 | 200KHz 600 | 100KHz 800 | 75KHz 1000 | 60KHz 1200 | 50KHz 1500 | 40KHz 2000 | 30KHz 3000 | 20KHz 6000 | 10KHz 8000 | 7.5KHz (and so on)
But i vote for supporting specific divider after all, one can never know if there is some obscure device out there in the wild that supports only 6365372Hz.
On Tue, 28 Feb 2012 11:50:37 +0900 Samir Ibradžić sibradzic@gmail.com wrote:
well we could support both actually... selecting the divider as in our patch, or alternatively the frequency (if it is not possible print the next lower available one)...
anyway this can be done later and i'd like to get this into svn now-ish rather than wait for the perfect patch. you do not happen to own a logic analyzer that could confirm that the frequency now is really what we think it is, do you? in any case could you please test the patch i have sent so that we know it does not break the programmer completely?
if you like to work on a followup patch please use "spispeed" as the parameter for the frequency because that is the one used in serprog and the buspirate already.
On 2012年03月07日 00:25, Stefan Tauner wrote:
Sorry, no analyzer available here. I can confirm though, that when using bigger dividers, data transfer speeds achieved matches the calculated frequencies, at least on the device i have here (PicoTAP).
in any case could you please test the patch i have sent so that we know it does not break the programmer completely?
Already tested, seems ok. Anyway, we just need to be careful that the patch has zero consequences when "spispeed" option is not used at all.
Do you have any updates, or i can re-base on top of your previous patch?
R, S
On Sat, 31 Mar 2012 00:52:14 +0900 Samir Ibradžić sibradzic@gmail.com wrote:
by "matches" you mean that e.g. doubling the divisor approximately doubles the time needed for an read/erase/write, right?
thanks for testing. yes (though i think you meant divisor not spispeed?), altough zero consequences need to be specified more precisely: the previous code set divisor 2 by sending 0 to the device. our new code does the same by setting DEFAULT_DIVISOR to 2 and doing the math right. so from the programmers point of view the communication should be equal.
no updates yet, but i will change this bit because it does seem like a typo: * Hence the expressible divisors are all even numbers between 2 and - * 2^17 (=131072) resulting in SCK frequencies of 2 MHz down to about + * 2^17 (=131072) resulting in SCK frequencies of 6 MHz down to about * 92 Hz for 12 MHz inputs. */
it would be nice if someone could really verify the correct frequencies on the output pins, but if no one will do that in the next days/weeks, i will commit it anyway.
On Sat, 31 Mar 2012 00:05:19 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
committed in r1537 after adding a section to the manpage explaining the new parameter.