This application note AN1277 describes how to interface a serial SRAM to a PIC32 microcontroller using the C32 Compiler. The page has a link to a zip file containing source code, which should have low level routines for reading and writing data via the SPI interface.
EDIT:
How do I set the baudrate? I am
guessing it got something to do with
SPI1BRG
I see that you have downloaded the "datasheet" for your processor (datasheet is a bit of a misnomer, it is 632 pages long), so I will be using page references from that.
The equation (on page 397) for the SPI clock frequency is
Fsck = Fpb / (2 * (SPI1BRG+1))
I believe the PIC32MX360F starts out with a internal FRC oscillator of 8 MHz, divided by 2 (due to the FRCDIV default value of 1 in OSCCON register, page 56), and since you are not making a changes in your code to OSCCON, the SYSCLK value will be 4 MHz.
Fpb is the Peripheral Bus Clock frequency. It is set up in PBDIV field of the OSCCON register, which in turn is initialized to the value of the FPBDIV field in the DEVCFG1 (boot configuration register), depicted on page 63. Assuming you haven't changed this, the default POR (power-on reset) value is binary 11, which means the Fpb is SYSCLK divided by 8.
Therefore Fpb = 4 MHz / 8 or 500 KHz.
If SPI1BRG = 1, as in your example, Fsck = Fpb / (2 * (1+1)) = Fpb / 4 = 500 KHz / 4 or 125 KHz.
If your SYSCLK differs from 4 MHz, then scale the Fpb accordingly.
Aren't embedded processors fun?
The PIC UART can be picky. Did you remember to check the Frame Overrun (OERR) bit? The PIC will be unable to receive UART communications until the OERR is cleared.
EDIT: I was also thinking...perhaps you could try a sort of loopback? That is, cut the UART out of the loop, and when the PC sends anything over USB, just send it straight back. This would tell you whether the issue is with the UART or the USB side of the PIC.
Best Answer
As already discussed, the Communications Device Class (CDC) is probably a better fit than Human Interface Device (HID) class for a data logging application. That being said, there may be some reasons for using a HID based protocol rather than CDC such as availability of host operating system drivers.
Windows provides a generic programming interface for HID devices which allow you to access any device using the HID class without any special drivers. If this is a commercial product, using a HID avoids the needs to have a signed driver such as would be required if CDC were used. Since a HID device does not require a driver to distributed with your product, the end user experience may also be simpler.
There are some drawbacks with using a HID based driver though. HID is not stream based, meaning the host OS will poll for data (reports) and will happily drop incoming report packets if the application does not read the incoming data fast enough. This then requires that you implement your own protocol on top of the provided HID reports at the application layer to provide a reliable transport using the output and input report fixed length packets for data transfer. Data throughput using this method will be significantly slower than a stream based protocol such as CDC.
Some useful data on USB HID can be found at http://www.lvr.com/hidpage.htm