Not Quite Useless Raspberry Pi Replacement

Made a short demo video of the RPP_SOC5 card setting all of the bits one at a time on one of our Raspberry Pi Hats.

The card works really well. I was able to get test code running for all of our I/O cards this afternoon. It was nice to be able to write code so easily for the cards. The EEPROM writes are very fast. Makes me wonder why the Pi is so slow to write EEPROMs. Maybe they are not doing page writes correctly?

One thing I really like on this card is the USB micro connector. I went with a connector which has four through hole supports - one in each corner. It's expensive, at $2+ but it looks and feels far superior to the cheaper connectors with surface mount supports. Worth the $$$.

This ends this part of the project. I have full compatibility with the GPIO interfaces of the Raspberry Pi card but there are things I still want to do.

• I haven't yet touched the additional I/O connectors on the card. I'd like to do a "bounce an LED" test on the two connectors. They add a lot more GPIO to the card beyond the Raspberry Pi 40-pin connector.
• I haven't tried out the 2nd I2C interface as an I2C interface. We've got an I2C port expander that I'd like to test with the card.
• I haven't tried the UART interface. Like the other interfaces I've bit banged the pins as GPIO but I'd like to test it as a UART.
• I haven't put any logic into the logic array part of the card. I have used it in other projects but didn't need any for direct pin output.
• I'd like to measure current consumption - but it's too low for my USB power meter to measure.
• It might be fun to put a RPPSOC on as a hat and have two ARM CPUs. I might like to make programming of the RPPSOC.

const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH] = {
    0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,

The EEPROM example I included in a previous log was a CAT24C04. This is a smaller EEPROM and only has one single word address at the start of the I2C command (after the Slave Address). I'm not sure how 8-bits work with the CAT24C04 since it has 512-bytes which should need 9-bits of address. 

Regardless of this, the 24C32 EEPROM used on the hat requires two bytes for address. I set the image to another part and was able to get it to successfully write to the ID EEPROM.

To do this I added conditional code which uses enums for the different card types. This lets the card type be selected by the main( ) calling code.

enum EEPROM_Images {
    RPPUIO16,
    RPPGVSCFG,
    RPPSOC
};

The call, then, looks like:

writeEEPROM(RPPGVSCFG);

The dump of the EEPROM on PuTTY looks like:

Read from the EEPROM
0000  52 2d 50 69 01 00 02 00 75 00 00 00 01 00 00 00  R-Pi....u.......
0010  39 00 00 00 7b 27 6f 99 72 25 6c bd 33 46 3e 35  9...{'o.r%l.3F>5
0020  9f c8 a7 3e 04 00 01 00 0f 12 6c 61 6e 64 2d 62  ...>......land-b
0030  6f 61 72 64 73 2e 63 6f 6d 52 41 53 50 49 2d 50  oards.comRASPI-P
0040  4c 55 53 2d 47 56 53 2d 43 46 47 7a 43 02 00 01  LUS-GVS-CFGzC...
0050  00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0070  00 00 00 ed 6e 00 00 00 00 00 00 00 00 00 00 00  ....n...........

The different card type can be seen in the text to the right. Setting the calling value to the PRR-UIO-16 card and doing a write followed by the read shows:

Read from the EEPROM
0000  52 2d 50 69 01 00 02 00 6d 00 00 00 01 00 00 00  R-Pi....m.......
0010  31 00 00 00 c0 e9 73 39 59 5c 8b af 62 4f 19 32  1.....s9Y\..bO.2
0020  fe 3f 2d d5 05 00 01 00 0f 0a 6c 61 6e 64 2d 62  .?-.......land-b
0030  6f 61 72 64 73 2e 63 6f 6d 52 50 50 2d 55 49 4f  oards.comRPP-UIO
0040  2d 31 36 f2 9f 02 00 01 00 20 00 00 00 00 00 00  -16.............
0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060  00 00 00 00 00 00 00 00 00 00 00 ed 6e 00 00 00  ............n...
0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

So it looks like it's working well now and it is callable with the different board EEPROM contents.

Process to Make a New ID EEPROM for the Raspberry Pi

I've put up bits of this already but here's a thumbnail sketch of making an ID EEPROM for Raspberry Pi Hat. These steps only need to be done once for a particular Hat design or if the device tree needs to be updated for the Hat.

• Download the tools from the GitHub RPi Hat repository to the Raspberry Pi. There are additional helps there.
• Study the Design Guide (from above). Particularly, read the ID EEPROM section.
• The EEPROM format section is here. Don't get scared. There's a tool to help make the file in the proper format.
• Edit the eeprom_settings.txt text file for your particular hat design
• eepmake: Parses EEPROM text file and creates binary .eep file. Run this program on the Pi. It will create the eepcfg.eep file.  eepmake could probably compiled to run on any computer and probably doesn't have to be run on a Raspberry Pi but who doesn't like to play with their Pi?
• Run eepmake with:

  ./eepmake eeprom_settings.txt eepcfg.eep

• eepcfg.eep is a binary file. Use a tool like HxD to open the file. Export the file as a C array. Use a file name which distinguishes the file from other hats.
• Add the hat file to EEPROM_Images.c file in the PSoC code.
• Change the type to const uint8. The result should look like:

  const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH] = {
      0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
      0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,
  

• The length of the file was indicated in comments in the C array file created from HxD.  This could also be created by srec_cat (part of srecord).
• In the EEPROM_Images.h file.
• Make a #define for the length of the record (example below).
• Make a function prototype for the array. It should look like:

  #define RPP_UIO16_EEPROM_LENGTH 109
  extern const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH];
  

• This lets the write function access the EEPROM data.
• This process replaces all of the I2C configuration on the Raspberry PI.
• No need to do I2C port scans.
• No need to do eepflash.
• No need to do eepdump.

With the ID EEPROM programmed the card can now be identified by reading the ID EEPROM. This should prove useful for card testing, particularly repeating tests since the PSoC software can detect the card type automatically. If the part is not programmed, it can ask the user to select the EEPROM image to program into the part. The correct card tests can then be automatically selected and run.

EEPROMs come with 0xFF from the factory so it should be easy to detect if a part has ever been programmed. These values are set in the ExtEEPROM.h file and are found in these values:

#define MAX_ID_IMAGE_SIZE   128
#define NUM_32_BYTE_BLOCKS  4
#define EEPROM_BLOCK_SIZE   32

These could change with a different EEPROM. Consult the part data sheet for other parts.

To have a table larger than 128 bytes. the defines above would need to changed. The three values are inter-related. The first (IMAGE_SIZE) has to be larger than the ID file. The third value is dependent on the EEPROM part but the CAT24C32 has 32-byte blocks. The second value is the first divided by the third value and indicates how many blocks must be written.

The code zero pads past the end of the ID EEPROM data.

The functions to read the ID EEPROM on the Raspberry Pi Hat are now working. The expected data is:

const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH] = {
    0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,
    0x59, 0x5C, 0x8B, 0xAF, 0x62, 0x4F, 0x19, 0x32, 0xFE, 0x3F, 0x2D, 0xD5,
...

The data read from the EEPROM was:

0000  52 2d 50 69 01 00 02 00 6d 00 00 00 01 00 00 00
0010  31 00 00 00 c0 e9 73 39 59 5c 8b af 62 4f 19 32
0020  fe 3f 2d d5 ...

The data matches. I am reading 4 blocks of 32 bytes each for a total of 256 bytes. 

Took a while to debug. I hooked a logic analyzer up to the EEPROM and found it wasn't accessing the I2C interface. Rookie mistake. I copied the reading code but forgot to include the initialization code in main (goes before the program loop):

    // enable I2C interrupts
    I2C_EEPROM_EnableInt();  
    //Start I2C
    I2C_EEPROM_Start(); 

After adding the initialization code, the read worked. The read code looks like:

void readEEPROM(uint8 * eepromBuffer)
{
    uint8 SLAVE_ADDR = 0x50;
    uint8 cMessage[2];
    uint16 cLength = 256;
    
    cMessage[0] = 0;
    cMessage[1] = 0;
    
    //write a dummy byte to initialize the address word counter of 
    //eeprom to start address for read back operation. First location 
    //of cMessage array has word address.
    
    I2C_EEPROM_MasterWriteBuf(SLAVE_ADDR, cMessage, 2, I2C_EEPROM_MODE_COMPLETE_XFER);
    
    //wait until Transfer is complete
    while((I2C_EEPROM_MasterStatus() & I2C_EEPROM_MSTAT_WR_CMPLT )==0);
    
    //Delay for setting address in EEPROM
    CyDelayUs(1);
    
    //Read the 16 bytes from slave, staring from word address specified by iMessage
    //SLAVE_ADDR is the slave address in this API
    //cRx_Buffer is the pointer to array where data has to be stored after reading from EEPROM.
    //cLength-1 is the number of bytes which have to be read from EEPROM
    //I2C_MODE_COMPLETE_XFER, is to read data completly before sending stop command.
    
    I2C_EEPROM_MasterReadBuf(SLAVE_ADDR, eepromBuffer, cLength-1, I2C_EEPROM_MODE_COMPLETE_XFER );
            
    //wait until Transfer is complete
    while((I2C_EEPROM_MasterStatus() & I2C_EEPROM_MSTAT_RD_CMPLT )==0); 
}

The read function reads 256 bytes from the EEPROM into an array. The pointer  into the array was provided by the calling function in main( ). After reading the array is dumped to the USB and gets displayed in the PuTTY screen.

    uint8 eepromBuffer[256];
...
                        readEEPROM(eepromBuffer);
                        dumpEEPROM(eepromBuffer);

I added a plain text field to the right of the read. That lets me see the data as readable characters. Here's the output:

Read from the EEPROM
0000  52 2d 50 69 01 00 02 00 6d 00 00 00 01 00 00 00  R-Pi....m.......
0010  31 00 00 00 c0 e9 73 39 59 5c 8b af 62 4f 19 32  1.....s9Y\..bO.2
0020  fe 3f 2d d5 05 00 01 00 0f 0a 6c 61 6e 64 2d 62  .?-.......land-b
0030  6f 61 72 64 73 2e 63 6f 6d 52 50 50 2d 55 49 4f  oards.comRPP-UIO
0040  2d 31 36 f2 9f 02 00 01 00 20 00 00 00 00 00 00  -16.............
0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060  00 00 00 00 00 00 00 00 00 00 00 ed 6e 00 00 00  ............n...
0070  00 00 00 ed 6e ff ff ff ff ff ff ff ff ff ff ff  ....n...........
0080  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
0090  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00a0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00b0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00c0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00d0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00e0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00f0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f9  ................

You can see our company name, land-boards.com and the board ID, RPP-UIO-16.

 Next, time to check the write code.  

Now that I have C arrays with the card EEPROM files and a short menu (command line interface) running over the USB port I can proceed to get the EEPROM read/write working.

I've got two functions now: 

• void readEEPROM(char *eepromBuffer);
• void dumpEEPROM(char * eepromBuffer);

The readEEPROM( ) function reads the contents of the EEPROM. The function dumpEEPROM( ) provides a dump of the memory. The third function we need is: 

• void writeEEPROM(char * eepromBuffer);

PSoC Utilization

The PSoC utilization is:

Flash used: 18696 of 131072 bytes (14.3%).
SRAM used: 2805 of 32768 bytes (8.6%). Stack: 2048 bytes. Heap: 128 bytes.

The logic utilization is practically nll.

Here's what the hex dump of the ID EEPROM file for the RPP-UIO-16 card looks like:

I dumped the binary file using HxD which I found here.

Our company name land-boards.com can be see in the right side as well as the card name RPP-UIO-16. The length is 109 bytes.

Conveniently HxD exports directly to .c files. The result is:

unsigned char rawData[109] = {
    0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,
    0x59, 0x5C, 0x8B, 0xAF, 0x62, 0x4F, 0x19, 0x32, 0xFE, 0x3F, 0x2D, 0xD5,
    0x05, 0x00, 0x01, 0x00, 0x0F, 0x0A, 0x6C, 0x61, 0x6E, 0x64, 0x2D, 0x62,
    0x6F, 0x61, 0x72, 0x64, 0x73, 0x2E, 0x63, 0x6F, 0x6D, 0x52, 0x50, 0x50,
    0x2D, 0x55, 0x49, 0x4F, 0x2D, 0x31, 0x36, 0xF2, 0x9F, 0x02, 0x00, 0x01,
    0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED,
    0x6E
};

This should make it easy to load the EEPROM. I will need to rename the array but other than that minor detail this looks like a good approach. srec_cat would probably work just as well but having the HxD editor will be very convenient for what I want to do.

I am putting the 3 hat EEPROM images into a file: EEPROM_Images.c so that they can be loaded as needed. I am also changing the type from unsigned char to const uint8 so that the array doesn't get moved into SRAM (saving some SRAM).

The three images are different sizes; 109, 117, and 105 bytes. So I think I just need to have a 128 byte buffer or 4 blocks of 32 bytes each.

Wrote a very basic command interface with three commands:

• W - Write the EEPROM
• R - Read the EEPROM
• B - Bounce an LED across the RPP-UIO-16 card

The result looks like this:

Write to the EEPROM
Read from the EEPROM
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Blinking the LEDs on the RPP-UIO-16 card, please wait
Completed blinking the LEDs on the RPP-UIO-16 card

 For the Write to EEPROM I am filling an array with 0x00-0xFF. For the Read from EEPROM I am dumping the array that was filled. For the bounce LED I am using the routine that I wrote earlier but instead of running it forever, I just run it once.

Works well. Made a workspace bundle as an archive in the file: RPS_PSOC5_Serial_01.cywrk.Archive02.zip in the GitHub for this project.

I need a really simple test menu. It should display over the USB-Serial interface and run under PuTTY.

This project started with the PSoC example project: USBUART. Currently, the code is doing the USBUART code which takes the serial data that the PSoC receives and loops it back to the Host.

Instead of pickup up the code it needs to be interpreted and responses sent back to the Host.

I think I will implement a very simple command interpreter to being with. The commands will be:

• R - Read EEPROM and dump results to the Serial to USB
• W - Write EEPROM
• B - Blink the LEDs on the RPP-UIO-16 card

That was fairly easy to do. Here's the code:

       /* Service USB CDC when device is configured. */
        if (0u != USBUART_GetConfiguration())
        {
            /* Check for input data from host. */
            if (0u != USBUART_DataIsReady())
            {
                /* Read received data and re-enable OUT endpoint. */
                inCount = USBUART_GetAll(inBuffer);

                if (0u != inCount)
                {
                    /* Wait until component is ready to send data to host. */
                    while (0u == USBUART_CDCIsReady())
                    {
                    }
                    
                    if ((inBuffer[0] == 'r') || (inBuffer[0] == 'R'))
                    {
                        strcpy(outBuffer,"Read from the EEPROM\n\r");
                        outCount = strlen(outBuffer);
                        USBUART_PutData(outBuffer, outCount);
                    }
                    else if ((inBuffer[0] == 'w') || (inBuffer[0] == 'W'))
                    {
                        strcpy(outBuffer,"Write to the EEPROM\n\r");
                        outCount = strlen(outBuffer);
                        USBUART_PutData(outBuffer, outCount);
                    }
                    else if ((inBuffer[0] == 'b') || (inBuffer[0] == 'B'))
                    {
                        strcpy(outBuffer,"Blinking the LEDs on the RPP-UIO-16 card, please wait\n\r");
                        outCount = strlen(outBuffer);
                        USBUART_PutData(outBuffer, outCount);
                        testRPPUIO16();
                        strcpy(outBuffer,"Completed blinking the LEDs on the RPP-UIO-16 card\n\r");
                        USBUART_PutData(outBuffer, outCount);
                    }
                    else
                    {
                        strcpy(outBuffer,"Not a valid command, legal values are r, w, b\n\r");
                        outCount = strlen(outBuffer);
                        USBUART_PutData(outBuffer, outCount);
                    }
                    /* If the last sent packet is exactly the maximum packet 
                    *  size, it is followed by a zero-length packet to assure
                    *  that the end of the segment is properly identified by 
                    *  the terminal.
                    */
                    if (USBUART_Buffer_SIZE == inCount)
                    {
                        /* Wait until component is ready to send data to PC. */
                        while (0u == USBUART_CDCIsReady())
                        {
                        }

                        /* Send zero-length packet to PC. */
                        USBUART_PutData(NULL, 0u);
                    }
                }
            }
        }

The creation of Raspberry Pi Hat EEPROMs is described in the Foundation's documents.

The HAT EEPROM allows the hat to describe the function of the GPIO pins. Most of our cards are not for a specific purpose but are I/O breakouts with power distribution. Many of the cards perform 3.3V to 5V translation. As such, there's no dedicated purpose for a given GPIO pin so there's no way to fully pre-determine the contents of the hat EEPROM. In fact, it might even be an input pin or an output pin.  But we still provide the EEPROM on these cards for users who want to fill in the contents based on their specific applications. This is complicated enough to do that most casual users never bother with doing it.

The hats typically do connect to all pins. But in the case where the hat is designed to fit on either the 40-pin connector or the older 26-pin connector, there's no pins on the additional 14 connector pins.

Details of the EEPROM Contents

Details of the EEPROM data format can be found in the EEPROM format specification. 

Host Side Software Tools to Create EEPROM Images

Software tools are available for creation of valid EEPROM images, to flash an image or read and dump and image to/from an attached ID EEPROM. Conveniently the tools are written in C and that's compatible (at least at the language level) with PSOC Creator.

EEPROM Flashing Tool

The tool to program and read the EEPROM on the card (eepmake32) obviously don't run on the PSoC so it needs to be re-created.

The EEPROM image will be loaded into the PSoC Flash Memory when the PSOC is programmed and needs to be made into a C Array from the perspective of the PSoC Creator. We've used one of the srecord utilities called srec_cat to convert binary images into C Arrays before so this would probably be a good tool for this instance. The specific tool can actually be run on the Pi itself to make the binary file:

eepmake: Parses EEPROM text file and creates binary .eep file

We've already done this for the hats we currently make and probably will continue to use the Pi for this function. Alternately, the code could be run on a PC or Linux machine.

EEPROM Physical Interface from the PSoC

The ID EEPROM is at I2C address 0x50 on ID_SD and ID_SC pins. That is the I2C slave address and is a function of the EEPROM part itself.

The I2C lines are connected to a dedicated I2C interface in the PSoC.

The pins are pre-determined for this I2C interface as above. Dropping the I2C Master symbol onto the PSOC Creator schematic page causes API code to be generated for the I2C master function but the API functions need to be called by the program that needs to use the I2C master.

EEPROM

We use the recommended On Semiconductor CAT24C32 32Kbit EEPROM for our hats.

A recommended part that satisfies the above constraints is OnSemi CAT24C32 
which is a 32kbit (4kbyte) device. 

The CAT24C32 has the key feature that it has "Hardware Write Protection for Entire Memory".

We could use either byte write mode or page write mode. The eepflash.sh program uses the linux dd command to copy data from the file to the Flash and there's no easy visibility to which mode it uses.

The spec for the contents of the flash is here.

Since the data is only written and read as a block, I'm going to use the Page Write mode. This only comes at the cost of speed and the part is so small that speed isn't particularly critical. Write cycles are 10 mSec. If we were to write to all of the 4KB of the EEPROM that would be 40 seconds. But looking at the file for the RPP-UIO-16 shows that it's only 109 bytes long so this will take a little over a second to flash the portion of the EEPROM we want to flash. That should be fine.

Let's use a 256-byte block size. Since the EEPROM has 32-byte blocks we will need to break this up into 8 separate block transfers.

We will use a software delay timer of 10 mS between each write to ensure that the part has completed the previous transfer.

There is a handy application note by Cypress on connecting an external EEPROM to the PSoC. Here is a link to the source code. In the example, the code does the following to write a block to the EEPROM:

        //Following API writes the data from PSoC3 RAM buffer to EEPROM
        //SLAVE_ADDR is the slave address in this API
        //cMessage is the pointer to array which contains the data to be written to EEPROM.
        //cLength is the number of bytes which have to be written to EEPROM
        //I2C_MODE_COMPLETE_XFER, is to send data completly before sending stop command.
        
        I2C_MasterWriteBuf(SLAVE_ADDR, cMessage, cLength, I2C_MODE_COMPLETE_XFER);
        
        //wait until Transfer is complete
        while((I2C_MasterStatus() & I2C_MSTAT_WR_CMPLT )==0); 
        
        // delay to complete the write operation(twr)
        CyDelay(10);

Reads are similar except there's a "dummy write" to get the address set for read.

        //write a dummy byte to initialize the address word counter of 
        //eeprom to start address for read back operation. First location 
        //of cMessage array has word address.
        
        I2C_MasterWriteBuf(SLAVE_ADDR, cMessage, 1, I2C_MODE_COMPLETE_XFER);
        
        //wait until Transfer is complete
        while((I2C_MasterStatus() & I2C_MSTAT_WR_CMPLT )==0);
        
        //Delay for setting address in EEPROM
        CyDelayUs(1);
        
        //Read the 16 bytes from slave, staring from word address specified by iMessage
        //SLAVE_ADDR is the slave address in this API
        //cRx_Buffer is the pointer to array where data has to be stored after reading from EEPROM.
        //cLength-1 is the number of bytes which have to be read from EEPROM
        //I2C_MODE_COMPLETE_XFER, is to read data completly before sending stop command.
        
        I2C_MasterReadBuf(SLAVE_ADDR, cRx_Buffer,cLength-1, I2C_MODE_COMPLETE_XFER );
                
        //wait until Transfer is complete
        while((I2C_MasterStatus() & I2C_MSTAT_RD_CMPLT )==0); 
        

This is similar to the Arduino code to write/read EEPROMs on our ODAS cards.

Before working on this code, I think I need to have a way of displaying the EEPROM contents. For that I will create some Test Menu code.

There's still quite a few things I'd like to do.

Menu System for Card Tests

Since the first target is the Land Boards Raspberry Pi I/O Hats, I'd like a menu system to select the Hat to test. The menu would run over the USB connection and should allow tests to be developed for the hats. I'd like the only host requirements to be running a terminal emulator, like PuTTY which supports Serial over USB.

The cards are mostly GPIO breakouts that add Ground and Signal as well as do voltage translation of the 3.3V of the Raspberry Pi to 5V signal levels. For these cards it's enough to bounce a light across each of the output pins and light LEDs. This checks for shorts, opens, etc.

But we do have some other cards, such as a serial port card which does USB to Serial that are more than just testing GPIO lines.

Hat ID EEPROM Read/Write

One of the primary reasons I made this card is I don't want to have to figure out how to use the I2C interface everytime Raspbian changes the Device Tree approach. For that to work, I need to be able to program the EEPROM on the hat. If there's a hat that's already been programmed it can be read to automatically determine what hat is attached.

Not all of our Land Boards Raspberry Pi Cards are technically hats. To be a hat, the card has to have an ID EEPROM. Some of our cards are breakouts and don't have the ID EEPROM. Some of our cards just support the smaller GPIO connector size, as well.

Cards which have an ID EEPROM include:

• RPP-UIO-16 - Full hat functionality
• RASPI-PLUS-GVS-CFG - Full hat functionality
• RPPSOC - This card in reverse - uses as PSoC as a hat to the Pi

The cards which don't have an ID EEPROM include:

• RasPi-GVS -
• RASPI-PLUS-GVS - Hat sized but no EEPROM
• RPIO-TINY - Very small breakout of the GPIO pins with Ground and VCC pins for each GPIO
• RPIO-TINY-2 - 5V translator on 8 dedicated GPIO pins
• RPIO-TINY-3 - Similar to RPIO-TINY with all of the GPIO inside the board volume
• RPI-MDI - 3 Channel Servo controller
• RPI-CONSOLE - Serial USB port with USB B mini connnection
• RPI-CONSOLE-U - Serial USB port with USB B micro connection
• RPI-I2C-HUB - Four port I2C hub

So there's really only 3 hats on the list (cards with ID EEPROMs). Still it would be nice to have a way to do this without the pain of using a Raspberry Pi.

Part of the reason it's painful to do this with a Raspberry Pi is that the Pi viewed the EEPROM as something it interrogates at power up rather than a device it want's to let users read. That has to be worked around and most of the workarounds on the Internet just don't work all that well.

I've got a Raspberry Pi Hat (board) which is an I/O card for the Raspberry Pi, the RPP-UIO-16. It has 16-bits of I/O translators on it as well as connections to all of the GPIO pins on the 40-pin connector. The hat is the standard form factor as other hats and happens to match the RPI_PSOC5 card.

I hooked up jumpers to take the 3.3V side of the translators to 16 of the GPIO lines from the Raspberry Pi connector. I hooked up 16 LEDs to these 5V signal level lines. I also hooked up LEDs to the other pins and ran code to bounce light across each of the LEDs. This showed that the RPP_PSOC5 can set all of the lines properly.

The code has been written to use the BCM pin names. On the GPIO connector, these are: