Finally got Crystal-Free USB working.  I'm using the stock USB HID Keyboard demo from the June 15, 2013 edition of Microchip Libraries for Applications (MLA).  On my PC, with the MLA folder installed at root level of C:\, it's the folder:

I use the PICDEM_FSUSB_K50 configuration and C18 (not XC8) compiler.  Microchip's excellent online ticket support pointed me to this folder and helped me find an evaluation copy of C18.

Instead of searching for the schematic of the target board, it was actually faster to just read the source code and infer the schematic.  I skimmed it quickly, and replicated LED1, LED2, LED3, and LED4 at RD0, RD1, RD2, and RD3, respectively, as well as SW2 on RB4 and SW3 on RB5.  There is also a potentiometer that I ignored.  It turned out though that only two of the LEDs and one of the switches are used, so I could've breadboarded less had I waited and read more of the code.  The potentiometer that I ignored is not used in this demo, so ignoring it was correct.

I have not changed the code at all, but running the stock code on my breadboard has convinced me that Crystal-Free USB really does work.  I also now have a starting point from which to make software changes.

The circuit is bus-powered.  For now, I make use of a USB connector breakout board from SparkFun (the small red board into which I plug the cable).

The demo code emits a keyboard key everytime SW3 is pressed.  It sends 'a' the first time, then 'b', then 'c', etc.  Here's a video...  Look, Ma, No Crystals!

I successfully copied/pasted snippets of Analog-to-Digital conversion code using plib on the PIC18F25K50.  Initially, I thought the potentiometer I was using was non-linear, as values tended to swing very quickly.  It turned out that I had set the PORTC pins to digital in order to get the USART working.  Once I made sure the pin I was using with the pot was set to analog input, it worked.

I'm using fairly safe and conservative configuration values for now (nowhere near the sampling rates the A/D is capable of), so I should revisit this.  However, it still means I have some placeholder code that can correctly read analog input.

The input values looked correct when printed out to putty via the UART...  which seemed a very digital way of looking at analog values...  which got me thinking...  Can there be a more analog way to verify?

In the first video below, I use the old trick from Fortran / BASIC days of charting via a text screen by treating vertical as the X-axis and horizontal as the Y-axis.  One would imagine viewing while rotating one's head 90 degrees, with forehead at 3-o'clock and chin at 9-o'clock.  In this case, the X-axis is time and the Y-axis is the analog input value.

In the second video, I display a bar with length proportional to analog input value.  For convenience, the value itself is printed next to the bar.  There is no need for ncurses to keep the bar at the top of screen instead of scrolling away -- I just send a Ctrl-L ('\014') to clear the screen and position at upper-left corner before printing each bar.

Both these methods involve no code on the desktop -- I'm just running putty here.  A useful trick though is changing putty's cursor from block to underline -- this reduces flicker.

The term  REPL, for Read-eval-print loop, is quite in vogue these days.  REPLs used to just be called interpreters, a term every 80's computer user was familiar with since in those days computers booted into BASIC.

Well, I made a Nano-REPL with a breadboarded PIC18F25K50.  Here I have it connected to the PC via the USART and an FTDI module (not using on-chip USB yet), and interacting with putty.  It does not wait for you to hit ENTER to evaluate your command.  All commands are single-character tokens.  '1' is taken to mean turn on the LED.  '0' means turn off the LED.  All other tokens are considered comments.  The print part of the REPL is to echo what you type, while the result of the eval is clearly seen from the LED on the breadboard.

Okay, really, all I have here is proof that I can use the plib USART routines in bidirectional mode correctly :-)  Next up will be to try out the plib routines for analog input, then eventually, crystal-free USB.

Microchip has a library called plib, for Peripheral Library, that abstracts some of the very chip-specific magic bit settings that one needs to deal with when programming microcontrollers.  You still need to deal with magic numbers, e.g. when opening the serial port you still need to pass in a number that is the result of a formula involving oscillator frequency and desired baud rate.

plib is not available for the PIC16F series but is available for the PIC18F series.  It is also available for PIC32s, but it's not clear if Microchip made an attempt made at API compatibility.

I'll play a bit with the PIC18F25K50 using plib so I can prototype code slightly faster.  Once I have working code, I can then make it work on the PIC16F1459 without plib.

Despite the mistakes with my PCB, it's salvageable for simple circuits.  I'm abandoning one due to poor soldering (it would be a lot of work to repair), but the other two I received from OSH Park can be put to use.  I will still spin a new version though.

Since the crystal is optional, I am reusing one of the crystal pins as GPIO RA4.  I also "convinced" the .2"-spaced capacitors to squeeze into .1" spacing.

Using right-angle headers with PICkit3 was a good decision.

Those USB FTDI modules work great as power supplies during testing!  I'm not using the serial lines at all here.

The PIC16F1459 has a pin called VUSB3V3.  An internal LDO generates 3.3V for use with USB.  An external capacitor of 0.47uF should be placed between this pin and ground.

When I initially populated my board, and tried to get something going quickly, I thought this would only be necessary once I started using USB.  However, without this, PICkit3 sees an ID of zero and fails to program the chip.  Various web pages mention that an ID of zero usually means power issues, and sure enough, when I populated this capacitor, PICkit3 started seeing the correct ID.

After getting the correct ID, I also had to remove the 100Ω resistors on the PGC/PGD paths to actually get programming going.  Some sample circuits have these for protection, but others say to avoid these.

Order sent to OSH Park on January 24; PCBs arrived February 3rd.  Just 10 days!  $17.25 for three PCBs.

I designed a general purpose, everyday workhorse PCB around the PIC16F1459.  The boards are on their way back from OSH Park, and likely to arrive later today.

Here are the DipTrace files on github, and below is a PDF of the schematic: