Getting The Pmod Shield To Work Correctly

[JColvin 415]

Hi,

 

I was attempting to use the PmodOLED and was attempting to get it's demo code correctly.  The demo code claimed you can use the Pmod Shield header JC, but it did not seem to be working.

 

So, I did a bit of research and found out what the problem was and successfully found a way to fix it and have the Pmod Shield work.  Check out my answer below for what you need to do.

[JColvin 415]

To get the Uno32 Pmod Shield to work you need to do the following:

 

Make sure that in your main MPIDE folder where you originally installed MPIDE under the hardware/pic32/variants folder, you have the Uno32_Pmod_Shield with the C and H files (these are likely there already). 

 

If you do, (or do not have them), go to the product page for the Uno32 Pmod Shield, and download the board 

variants file available. If you did not have the C and H files, copy the "Uno32_Pmod_Shield" folder that you see from the download and paste it into the hardware/pic32/varients folder.

 

Then, from the download, open up the readme text file. In the readme you will see a section that says: 

 

 

############################################################

uno32_pmod.name=chipKIT Uno32 with Pmod Shield

 

# new items

uno32_pmod.platform=pic32

uno32_pmod.board=_BOARD_UNO_

uno32_pmod.compiler.define=-Danything_you_want::-Danything=1

uno32_pmod.ccflags=ffff

uno32_pmod.ldscript=chipKIT-UNO32-application-32MX320F128L.ld

# end of new items

 

# Use a high -Gnum for devices that have less than 64K of data memory

# For -G1024, objects 1024 bytes or smaller will be accessed by

# gp-relative addressing

uno32_pmod.compiler.c.flags=-O2::-c::-mno-smart-io::-w::-ffunction-sections::-fdata-sections::-G1024::-g::-mdebugger::-Wcast-align

uno32_pmod.compiler.cpp.flags=-O2::-c::-mno-smart-io::-w::-fno-exceptions::-ffunction-sections::-fdata-sections::-G1024::-g::-mdebugger::-Wcast-align

 

uno32_pmod.upload.protocol=stk500v2

uno32_pmod.upload.maximum_size=126976

uno32_pmod.upload.speed=115200

 

uno32_pmod.bootloader.low_fuses=0xff

uno32_pmod.bootloader.high_fuses=0xdd

uno32_pmod.bootloader.extended_fuses=0x00

uno32_pmod.bootloader.path=not-supported

uno32_pmod.bootloader.file=not-supported

uno32_pmod.bootloader.unlock_bits=0x3F

uno32_pmod.bootloader.lock_bits=0x0F

 

uno32_pmod.build.mcu=32MX320F128H

uno32_pmod.build.f_cpu=80000000L

uno32_pmod.build.core=pic32

uno32_pmod.build.variant=Uno32_Pmod_Shield

#uno32_pmod.upload.using=

 

Copy this whole section and go to the boards.txt file that is available in the hardware/pic32 folder.  Go to the bottom of that text file and copy this whole section in.

 

Then, we need to make the following changes:

 

The first is merely for convenience: underneath the top line of the section that we just copied into the text file which says 

 

uno32_pmod.name=chipKIT Uno32 with Pmod Shield

 

 

type in the following:

 

uno32_pmod.group=chipKIT

 

What this does is add the "chipKIT Uno32 with Pmod Shield" option into the chipKIT section when choosing your board in MPIDE.

 

Next, and what makes all the difference, find the line (about 7 lines down) that says:

 

uno32_pmod.ldscript=chipKIT-Uno32-application-32MX320F128L.ld

 

Change this line to instead say:

 

uno32_pmod.ldscript=chipKIT-application-32MX320F128.ld

 

What this does is tell MPIDE to look for a linker script file that actually exists.

 

Now, save this boards.txt file and close out any MPIDE program that you already have running. When you reopen MPIDE, you should see chipKIT Uno32 with Pmod Shield as a board option under chipKIT and the program which uses the Pmod Shield should now successfully compile, and more importantly, successfully run with demo code that uses any of the headers on the Pmod Shield.

 

Please let me know if you have any questions.

[JColvin 415]

After working with the Pmod Shield some more, I was running into another issue with getting the supposedly "pass-through" pins, such as pins 26-33, to work correctly since I would declare a pin to be an output, set it to the logic high voltage and... get nothing out of the pin.

 

After digging around, I found that the issue is within the Board_data.c and Board_defs.h file that is under the hardware/pic32/varients/PmodShield folder. In these files the pins on the shield are assigned in software as connector header groupings so that the associated pin numbers that you work with in software are incorrect (although the port bits are the correct).

 

For example, on header JC the SS2, MOSI, MISO, and SCK2 (RG9, RG8, RG7, RG6) are assigned to chipKIT pins 16, 17, 18, and 19 rather than pins 10, 11, 12, and 13. Consequently, if you wanted to run SPI, you would have to declare pins 16, 17, 18, and 19 as your I/O's to get the labeled SPI pins on the Pmod Shield to operate instead of pins 10, 11, 12, and 13.

 

This issue will be easily fixed by reorganizing the arrays that list all of the chipKIT pins on the Board_data.c file, although it will no longer look "pretty". However, all of the ports bits will be assigned to the same pin numbers with and without the Pmod Shield library.  An update will be given once this issue has been resolved.

[djcheezy 1]

Hi JColvin,

Would you be able to do something like this for the uC32 and the Pmod Shield.  It appears that the Uno32 is discontinued and you no longer have stock.

Thanks,

djcheezy

[djcheezy 1]

This seems to be working for me when I paste it into boards.h.  I am able to compile example code using the uC32 board with Pmod Shield:

############################################################
uC32_pmod.name=chipKIT uC32 with Pmod Shield
uC32_pmod.group=chipKIT

# new items
uC32_pmod.platform=pic32
uC32_pmod.board=_BOARD_UNO_
uC32_pmod.compiler.define=-Danything_you_want::-Danything=1
uC32_pmod.ccflags=ffff
uC32_pmod.ldscript=chipKIT-application-32MX340F512.ld
# end of new items

# Use a high -Gnum for devices that have less than 64K of data memory
# For -G1024, objects 1024 bytes or smaller will be accessed by
# gp-relative addressing
uC32_pmod.compiler.c.flags=-O2::-c::-mno-smart-io::-w::-ffunction-sections::-fdata-sections::-G1024::-g::-mdebugger::-Wcast-align
uC32_pmod.compiler.cpp.flags=-O2::-c::-mno-smart-io::-w::-fno-exceptions::-ffunction-sections::-fdata-sections::-G1024::-g::-mdebugger::-Wcast-align

uC32_pmod.upload.protocol=stk500v2
uC32_pmod.upload.maximum_size=126976
uC32_pmod.upload.speed=115200

uC32_pmod.bootloader.low_fuses=0xff
uC32_pmod.bootloader.high_fuses=0xdd
uC32_pmod.bootloader.extended_fuses=0x00
uC32_pmod.bootloader.path=not-supported
uC32_pmod.bootloader.file=not-supported
uC32_pmod.bootloader.unlock_bits=0x3F
uC32_pmod.bootloader.lock_bits=0x0F

uC32_pmod.build.mcu=32MX340F512H
uC32_pmod.build.f_cpu=80000000L
uC32_pmod.build.core=pic32
uC32_pmod.build.variant=uC32_Pmod_Shield
#uC32_pmod.upload.using=

############################################################

[JColvin 415]

Yes, what you did is exactly what you needed to do to get the uC32 up and running.

I know the Pmod Shield library has been changed since I've posted this though and it is a little more difficult to work with now. I'll do my best to help you out though if you need it.

Let me know if you have any more questions.

Thanks,
JColvin