Ian,
Will the PIC's alternate USART be available as a second virtual com port by default? I've been thinking about adding some hardware I2C and/or SPI triggering to the design and would want a second channel to the FPGA during operation so I can test and debug it without trying to extend the SUMP software or protocols at first. If I recall though, you were planning the second UART to be for alternate PC<->PIC communication, not PIC<->peripherals.
Alternately, I remember you mentioning the PIC had two SPI's as well, one pin configurable and one hard-wired. I'm assuming the hardwired one is the in-circuit programming header? Obviously there's going to be a way to program the FPGA's SPI flash from the PC, but is there any way to access either SPI while the virtual com port is up on USARTa for normal operation?
I haven't considered multiple end points yet, it's something that sounds very useful to add. There will be a USB bootloader for the PIC, so everything can be upgraded. It would be great to have multiple endpoints to access the PIC and FPGA bootloader modes, but there are also buttons on the PCB.
One uart (re assignable) is assigned to the PIC->FPGA. The other (hardwired, 5volt tolerant) is brought to a header for whatever use (debugging, serial mode, serial output, etc).
PICs have a separate programming protocol that's not related to SPI. One (re-assignable) module is currently slated for updating the FPGA bootloader ROM with new FPGA synthesis, and later also for a faster connection between the PIC->FPGA. The other (hardwired) shares some pins with the UART (I think) and some of them are used for other purposes (maybe unrouted).
I'm assuming the bootloader mode will be necessary to program the FPGA as well as the PIC itself? Because during normal operation the PIC just gets out of the way and does USB<->RS232, right?
I'm obviously not familiar with the PIC's virtal com drivers and how the endpoints are handled (if they talk directly to hardware or if you can easily handle them in software) but if there's a simple way to add a second com port that can just talk on the second USART or even the SPI (assuming the FPGA can use those same pins for communication after self loading) that could be really handy.
Right now, a button held at reset will trigger the PIC FPGA (ROM) upgrade mode. The PIC upgrade is triggered with a jumper over two of the programming pins. The multiple end point firmware makes a lot of sense too, one to program the ROM, one to trigger the PIC bootloader, one to talk to the FPGA, and another for extra I/O. The PIC supports up to 10 endpoints (I believe...).