I just got the USB dev kit from CCS and got things fired up. I got the bare board, no cables or tutorial this time. I found an example that moves data between a USB serial emulator and the PICs normal rs-232 to start with in the regular compiler distribution, made a project by copying this and all the include files to their own project directory, built it, and bam, it seems to work at least to the point of the PC seeing it, and recognizing the USB dev board as a serial port. I have a few glitches on the dev machine I'm using, so will have to drop back a little and fix that stuff up better.
Just to make it more complex (well....to have an excuse to use this fine machine more) I'm doing this right now on an 8 core i9 series with 32 gigs of ram (and a SSD drive (plus a tb of other drives) and 192 core nvidia gpu, man this thing screams!), running ubuntu 10.04 64 bit, with windows xp (32) running in virtual box for the ide and programmer. I might have screwed up adding another available processor core to the windows install post-install, as windows goes nuts trying to find "driver software" for a simple usb-serial dongle, and really doesn't have a clue about the new USB serial port the pic dev board makes (though linux sees it fine!).
Interesting that now it's windows that has all the issues of non support of odd hardware, eh? Or most of them. I got an off-brand PCI "real" serial port board that seems flakey in that machine, so I've got to fix up all that comm issue stuff before it's worth proceeding, or move to this machine or another for this job.
The goal of this project is to integrate the USB stuff into my "standard" opsys that has all the other nice features, and create a boilerplate project to add other things to down the road.
Probably the first specific project will be something like the "multigeiger" thing we've done already, simplified somewhat, to use as the base of our "standard counter" for activations. We might add some a/d data aq to this like we did there to grab things like power supply or pressure data during a run along with counts. The really nice thing about this USB is that all machines and opsys can handle it (my wierd windows problem notwithstanding, it's probably a cockpit type of error there), and it provides power to the device if it doesn't require tons. I've spent so much time building power supplies one after another for things I'm getting pretty sick of doing it, and this just makes that go away altogether -- and makes for a smaller, cheaper product too, bonus.
While just counting, measuring, and reporting some a/d results sounds trivial, it's actually not if you want real accuracy. For example, in counting -- what if a count comes in while I'm reading the counter? Have all the carries rippled yet? What if a count comes in while I'm resetting the counter after reading it? I'll be pulling out some tricks to handle that kind of thing -- resync to a random signal is still pretty much an unsolved problem in general -- but you can mess up only a little or a lot.
A/D inputs have issues too. In multigeiger, we took samples at about 30hz, and reported a sum of them for each channel once a second (if you add 30 samples, you get some more bits of effective resolution). If our sampled signal has any non-random noise on it that's under sampled, say 60hz -- we can see a huge long, slow sinusoidal drift as that "beats" with our fixed sample rate. But we could do a median smooth....and so on. there's more to this "simple" stuff than meets the eye if you want it "right" and of course I do.
One issue that's going to take some work is mapping our farm of USB-pic things to known places so PC software can deal with it in some automatic form. An issue linux and windows both seem to have is a more or less random assignment of a given USB-serial thing to a com port or tty number - the mapping seems to change on every boot and every time you plug something in or out.
In other words, unplugging something that was mapped to com3 and plugging it back in might make it com5 (while 3 is still there but gives errors if you talk to it) We could easily have a query/response thing on our own hardware to let it self-identify on a sweep of com ports, but -- whatever we use as a query might also screw up other USB devices that look like serial ports, maybe even dangerously -one of the things here is a USB driven arb waveform generator driving a 1.5kw amp -- you don't want to mess with that one. So it looks like digging into opsys innards to find a way to map com ports to USB vendor/serial number id's as a side issue. What a PITA, but if it was easy, anyone could do it and there'd be no money in it.