Week3: PIC18 Schematic (cont’d) and Using a Raspberry Pi for SPI Testing

Last time, we faced the challenge of designing the circuit and hardware interfaces of our Spartan-6/PIC18 board. This week, we return for more work on the schematics and shift focus to a different aspect of our project: writing the firmware for the PIC18. My colleague, Jia Xien, has been busy working on SD cards and establishing the TCP/IP stack on the PIC18, but I will be trying to configure the device as an SPI slave, so our projects are quite dissimilar. (It seems, however, that our blogposts can be equally lengthy!)

As usual, the summary is at the bottom of the page.

Circuit schematics

Previously, much was discussed of how the JTAG/ICSP connector could be dual-function. Ultimately, it was decided that a much more convenient solution is not to combine the headers. Since the product is being designed to use the basic 10BASE-T Ethernet standard, the RJ45 Ethernet port would have four unused pins. These can be re-purposed as the programming pins (PGC, PGD and MCLR) for the PIC18 instead, so that a user can just use a custom ICSP-RJ45 adapter and a programmer (e.g. PICkit 3) to configure the PIC18. The only caveat is that the product prototype is unlikely to be compatible with Power over Ethernet (PoE) specifications as the project moves forward!

Fig. 1: Schematic of Ethernet RJ45 socket with ICSP lines

Power supply & regulation

The main source of power to the board happens to be the +5V micro-USB connection, which currently serves no other purpose. The 5V DC input has to be stepped down to 3.3V, 2.5V and 1.2V for VCCO, VCCAUX and VCCINT respectively for the Spartan-6 power pins. Meanwhile, the supply voltage VDD for the PIC18 is just 3.3V.

One thing to note is that when powered from a desktop computer, the product can rely upon a relatively stable DC voltage. However, if the board is connected by USB to a different source, there may be a need for more robust voltage regulation and surge protection than shown here. As such, this design may change heavily in future applications.

Fig. 2: Schematic of power management and distribution

Visual diff

As recommended by my supervisor, a useful tool in source control is to create visual diffs of circuit schematics, which was brought up in an earlier post on this blog (original source). At present, GitHub is not being used in this project, so this step will have to be done manually. Fig. 3 shows a comparison between the board in its state last week and with the changes implemented this week (removals are in blue, additions in red).

Fig. 3: Visual diff diagram of Week2 and Week3 circuits

SPI Slave Firmware

With the schematic integration between the Spartan-6 and PIC18 largely decided, it is unfortunate that project testing cannot proceed to physical implementation at this stage. Nevertheless, there is still a need write and test the firmware for the PIC18. For this purpose, a simple SPI interface is set up with a Raspberry Pi (RPi) acting as the master in place of the Spartan-6 FPGA, as briefly explained here. The PIC18 to be tested is on the Microchip PICDEM.Net2 development board.

Fig. 4: Raspberry Pi with SPI connection to PICDEM.Net2 dev board

One limitation to this method is that while most of the hardware SPI pins on the PIC18 can be accessed on the I/O riser, the slave select pin (SS/RF7) is not available. When testing with just the PIC18, this is not a large problem but it will be difficult to test the micro-SD card setup discussed last week.

The MPLAB C18 Libraries from Microchip have a set of functions for the SPI peripheral, so it is straightforward to initialise the PIC18 as a slave. The duplex transfer is initiated by the RPi, and that simply exchanges the contents of the PIC18 Shift Register (SSPxSR) and that of the RPi. Using this setup, it is possible to quickly create a very basic SPI interface which transfers and prints a byte into the RPi terminal at a time. Once this was achieved, it was merely a small step up to start reading, writing and storing arrays of data (see Fig. 5).

Fig. 5: Raspberry Pi terminal showing data received from PIC

In summary, the ICSP pins were moved to the Ethernet socket, voltage regulation may become a point of focus in future, and the RPi is a fantastic way to quickly test SPI communications! Personally, I have to gripe that although it was easy to set up the RPi SPI master, it was difficult to find information on the SpiDev functions and the various options available. Upon hearing this, my supervisor said that I ought to write a guide for future sharing.

But that will have to wait for now! With the basic SPI bus configured, next week’s tasks will branch into two different areas: writing code to use the ADC ports, and emulating a Flash PROM using the remaining memory on the PIC18.