AVR Freaks

Well, John, that was my thought, too. I didn't need it, but someone ask for it and it wasn't too hard to add.

Thanks for the additional information, Mike. It'd be simple to add a filter to remove trailing zeros and use the same filter for both fields.

But, I do wonder about your original suggestion. Didn't your suggestion come prior to the "Acceptable Common Clocks" subsection? In any case, I was focused only one the Clock selection section -- but having those two fields be the same is a good idea. The only significant disadvantage of differing number of decimal points in "Acceptable Common Clocks" is that the error percentage will no longer line up which also has a decreased readability issue. But, perhaps people would have that number not be aligned rather than trailing decimal zeros.

Davef, that's interesting. Are you are testing the .exe (unzipped by two different unzippers) on two different machines? Or, was it your home XP machine that it previously did not work on and now does? If the latter is true, would you be able to compare the 2 .exe files for number of bytes and md5sum? If this is truly an unzip issue, then maybe I have an isse with my zip file creation program. Thanks for the report.

I uploaded version 1.7. No new features, but layout and number formatting as suggested by Michael. Michael, did I get the formatting as you'd like?

I think you and I have a bit different concept of nitpicking, David. An application crash due to user input, no matter how innocently or devilishly constructed, is a bug of great importance. I thought I got all the division by zero errors caught, but I missed that one. Thanks very much for the report. Do try to break the program in whatever way you can, such exercises help exorcise the bugs. Again, thanks for the report.

But, I'm glad to remove them. Since people can enter an arbitrary frequency, there's no need to have selectable anything but common frequencies. Along that same thinking, it'd make some sense to remove frequencies above 20MHz since they are not used with AVR's (excepting for that overclocking 22.1184 request).

Edit: At this time, I have the below list of frequencies to keep and remove. Anyone who has an opinion of what frequencies they'd like, let me know.

Hi Shane, I'm using my favorite programming language, ANSI Common Lisp. While there are free, open-source versions of Lisp available (some with graphical user interface tools), I'm using the commercial LispWorks ( http://www.lispworks.com ), because if offers graphical user interface that is compatable across Windows, Linux, and OS X.

Yes, Lesstif would work fine. I built the image with Etch 32-bit, so Ubuntu 7.04 32-bit Intel should work. For 64-bit Linux, you'll need to grab a 32-bit version of the Motif/Lesstif library. Yes, there is no resizing on the main frame and the Motif version has a larger frame than the Windows version. I'm far from an expert on Motif. Do you know if you can set some X-Window font parameters to reduce the size of the fonts to perhaps shrink the frame so it fits on your screen?

While I can't shrink the frame without removing some components (or going to a tabbed pane approach), I could reorganize the frame to be wider and shorter to fit into shorter displays.

Thanks for the reference, Robin. I've already add code so the application starts in the center of the desktop. Since people can enter their own arbitrary frequency, I probably will put the idea of user-modified frequency list on hold. One slight workaround is to save one's current clock frequency and then load that file when you want to use that clock frequency. Yes, to store user data, one would need a default home location to the application.

Thanks for the input, Ross. Yes, I've used that approach as well. The main disadvantage (or possible advantage for sophisticated users) is the possibility of having multiple copies of the application thus multiple data files with the user getting confused why the application seems to have different data each time. But, having a typical location for user data is supported by all common operating systems.

Thanks, Ross. In my many years of supporting users, it's been my experience they (at least the ones who ask for help) try as little as possible to be responsible for their actions. ("Hey, this program should tie my shoes as well" :)) Nonetheless, your point is very well taken, thanks.

Actually, Cliff, several components that I use in KAVRCalc have been published as open-source packages. A list of my open-source repositories is at http://gitpub.b9.com/cgi-bin/git...

Currently, I'm using cluck (a microcontroller clock library) and kmrcl (set of lisp utilities) in kavrcalc. But, I've never received any feedback, suggestions, or patches for cluck. I just don't think many freaks here use Lisp. And, kavrcalc is more specialized requiring a commercial development system for its GUI component.

Paul Graham's 1983 quote on the Wikipedia link you provided interestingly compares with later use of Lisp as his "secret weapon" in his commercial success: http://www.paulgraham.com/avg.html