Well, someone just had to go and give me an Arudino UNO. And then I felt compelled to do something useful with it. So, I did.
I'm finding it a little strange, due to the freedom/responsibility tradeoffs they used here vs the total control I have with PICs, but I'm getting by, and finding that worst-case, I can just go brute force it to be more flexible in pure C (or asm), if I'm willing to decode enough of the 660 page manual for the atmega 328.
So, I wrote a sketch (their terminology) that acquires all the a/d inputs and uses the one available counter (they grab the others for themselves, more or less) as a counter. Seems to work well as long as I run it off a wall-wart. Even blinking a LED makes enough noise to mess up the A/D, and the amount of noise on any of my machines on the USB 5v (laptop is by far the worst) is a couple a/d bits worth...so, we run from wall-wart.
Here's what it looks like at the moment:
In the serial monitor, the first number is milliseconds since last boot, the next 6 are a/d channels, and the last is counts since last report. I have it set to run every 100ms (more or less), and have the counter counting a pin I toggle each time through the main loop - so that number is half the number of times loop() was called in 100 ms (10 hz) - as you can see, it varies, timing isn't real deterministic in this in the same sense as my multi-threaded interrupt-drive PIC opsys, but hey, looks like 60-70 khz worth of times we get called per actual time to do something, so I'm not wasting a ton of cycles, and neither are they.
I have channel 1 digitizing a 1.56v alkaline battery, channel 4 to ground, and channel 5 digitizing the on-board 3.3v regulator. The rest are just floating and showing you noise plus the inter-channel leakage that's normal for a floating pin in cmos.
This is, of course, a "work in progress". I can't make this useful in my fusor setup until I have *at least* two counters. I managed one hardware, with interrupts only when the 16 bit counter overflows - that one will take MHz speeds. To get another (and stay out of the way of what they grab for their "opsys"), I'll just have to count external digital interrupts, which if you drive it too fast - might mess up the rest. Stay tuned, more to come on this, with variations (I also ordered an SD card add on I plan to use for standalone data aq with other speeds and feeds for the homestead, for example).
Here's the code as is, of course you have to zip stuff like this or the board won't take it.