chipKIT® Development Platform

Inspired by Arduino™

MPIDE environment for a custom board

Created Wed, 07 Dec 2011 01:37:10 +0000 by Jacob Christ

Jacob Christ

Wed, 07 Dec 2011 01:37:10 +0000

Mark et. al,

I've been working on documenting (in the wiki) what I've been learning on customizing the MPIDE environment for a custom board. The deeper down the rabbit hole I go the more I see your name written on the walls.

So it looks like the strategy that you've been using is as follows.

  1. In the boards.txt file you add a define that identifies the board.
  2. Where necessary in the code you check if that define is set to enable functionality for that particular board.

I have a bit concern in this strategy. We have already created three custom boards based on the chipKIT system and have at least two new boards in the works. Of the boards we've created, one is based on the Uno32, one on the Max32 and one that can best be described as a hybrid of the Uno32 and CUI32. Of the one board we've started thinking about this issue we were have been trying to make a custom wiring for it so that its easy to use the pinWrite and pinRead abstractions. We can see how to dig into MPIDE to accomplish this but as new version are released it will require us to each time modify code in the MPIDE to restore functionality of our custom boards. It seems equally impractical to roll in every custom board that comes into existence

I like the abstraction of the USE_USB_FOR_SERIAL in the HardwareSerial.h file and was think that it would be nice to put all of these types of abstractions into a single file so that custom boards need only update the boards.txt file and this one file. Also, this could be extended so that a custom boards file could exist in the users library contributed library directory so that changes need not even be made to the MPIDE install. It might be even a good idea to have a boards directory that could exist in the libraries directory that one need only drop a board and wiring file in to establish the use of this custom board.

Comments welcome.

GeneApperson

Tue, 13 Dec 2011 08:09:59 +0000

Jacob,

The main task that I have been working on for the last month and a half or so is rearchitecting the system to remove all board dependencies from the code. With Rick Anderson's help on the IDE side, I have implemented a board definition mechanism that allows anyone to easily plug the definition for a new board into the system. (BTW... this is why I haven't been on the forum answering questions lately)

The test release that was put up on github today contains this work in its final form. Look in the /hardware/pic32/variants folder in the installation tree. There is a folder for each defined board variant. Inside each board variant folder are two files: Board_Defs.h and Board_Data.c.

Board_Defs.h contains symbols that describe the mapping of PIC32 peripherals to logical function within the system (e.g. UART1 to Serial, UART2 to Serial1, or UART5 to Serial2). This file also contains symbols like PIN_LED1, PIN_LED2, PIN_BTN1, PIN_BTN2, etc. that map the device (e.g. LED) to the pin it is connected to on any given board. Using these symbols will make it much easier to write sketches that are portable between boards.

Board_Data.c contains table that map pin numbers to port and bit, analog pin numbers to digital pin numbers, and a/d channel, and pin numbers to timers and so on.

I rewrote all of the parts of the core and libraries that had hard coded references to peripheral devices so that they now get which peripheral they are supposed to use from the declarations in the Board_Defs.h file for the currently selected board.

I'm working on a document that describes the process of adding a new board definition to the system, but feel free to ask questions.

Gene Apperson Digilent

randomrichard

Sun, 08 Jan 2012 10:54:40 +0000

I am attempting to run the OLED display on the basic IOshield fitted to the chipKIT MAX32. I have downloaded the software you recently made available on Github and this removed an error message calling for a Board_Defs.h file when I tried to compile Oliver Jones' OLEDDemo example. But I now have an error stating:

C:\Users\Dick\Documents\Arduino\libraries\pic32\WInterrupts.c:50:37: error: 'NUM_EXTERNAL_INTERRUPTS' undeclared here (not in a function)

I've looked in the relevant Mikroe C file and it does look as though, to my badly tutored eye, that 'NUM_EXTERNAL_INTERRUPTS' does indeed need some more definition, but I have not found any support for this function. Can you please point me in the right direction? Thanks Richard

Gene Please ignore the above. I have now successfully compiled the OLEDDemo example using a more up-to-date version of MPIDE R

bperrybap

Tue, 10 Jan 2012 03:30:14 +0000

Gene, Maybe it is too late and too big of a change, but what about creating some kind of "arduino" object that holds all the arduino symbol related constants?

So for example say it really was called "Arduino". Then users could access things by referencing them off the Arduino object when using C++

I.e Arduino.PIN_LED1 instead of simply PIN_LED1

Or if it were hierarchical it could be: Arduino.pin.LED1 Arduino.pin.SS Arduino.pin.MOSI Arduino.pin.A0

etc....

You simply declare them as static const values inside your class object. There is no additional code size or runtime overhead for doing it this way, but it may create some issues for C code.

That way the global name space is not "polluted" with all these arduino specific defines. The global name space is starting to get really ugly when looking at the all the stuff the Arduino guys are starting to toss in to their pins_arduino.h header files down in their variants areas with no consistent naming convention.

As far as Jacob's original question, I've been kind needing something similar. I have situations where the architecture is the same but the board layout is different so the pin mapping is different. (Code needs to use different pin numbers) This requires creating a new board type for the IDE. mpide allows you to set custom defines in the boards.text file by using the compiler defines and you do get a define from {boardname}.board Is there any reason why the actual {boardname} wasn't used? So for example you would get a -Duno_pic32 when selecting the Chipkit UNO32 That way every board gets a define by simply creating its entry. And would it make sense to create a single define for the board name as well: So you would get something like -DMPIDE_BOARD={boardname} where {boardname} is the name of the board in the boards.txt file?

That gives the user the option of using #ifdef {boardname}

or #if MPIDE_BOARD == {boardname}

If it were limited to the latter, the global namespace has less of a chance for collision as there would only be a single define name.

But like Jacob mentioned, it would be nice to somehow extend the boards.txt file with one under your local sketchbook area so that you don't have to update the master boards.txt file with each release.

--- bill

andre85

Wed, 07 Mar 2012 09:14:24 +0000

I have a custom board with PIC32MX440F512H. I'm using MPIDE 0822. EEPROM doesn't function.. So I'm trying with MPIDE 1221 to hope EEPROM function correctly, but in MPIDE 1221, the same code give me an error in Serial " \HardwareSerial.cpp:670:60: error: Interrupt priority must be specified as 'single' or 'IPLn[AUTO|SOFT|SRS]', where n is in the range of 0..7, inclusive. " I try to modify Serial0 to Serial and then to Serial1, but the same errors appear.

Can someone help me? Is possible to have a document that describes the process of adding a new custom board definition to the system in MPIDE 1221??

Thanks to everybody.

Andrea

Jacob Christ

Thu, 08 Mar 2012 15:24:13 +0000

I have a custom board with PIC32MX440F512H. I'm using MPIDE 0822. EEPROM doesn't function.. So I'm trying with MPIDE 1221 to hope EEPROM function correctly, but in MPIDE 1221, the same code give me an error in Serial " \HardwareSerial.cpp:670:60: error: Interrupt priority must be specified as 'single' or 'IPLn[AUTO|SOFT|SRS]', where n is in the range of 0..7, inclusive. " I try to modify Serial0 to Serial and then to Serial1, but the same errors appear. Can someone help me? Is possible to have a document that describes the process of adding a new custom board definition to the system in MPIDE 1221??

The good news is the eeprom code works in 1221 with the MX440. We had this same problem as well and have fixed it. I though I submitted the fix to Gene.

The bad news, I'm so busy today I can't help you further. If you bug me tomorrow or Saturday I'll be able to send you the fix.

Jacob

ricklon

Fri, 09 Mar 2012 00:09:45 +0000

There is a new test release. If you can confirm this fixed with in that build, then it's going to be fixed in the next release.

https://github.com/chipKIT32/chipKIT-builds/downloads

andre85

Fri, 09 Mar 2012 08:11:03 +0000

So in the last release (mpide 0304) I try to read to EEPROM but IDE give me the error:
"address 0x9d081000 of My_Project.cpp.elf section .eeprom_pic32' is not within region kseg0_eeprom_mem' ".

If can help you, this is a part of my boards.txt: mychip_pic32.build.mcu=32MX440F512H mychip_pic32.build.f_cpu=80000000L mychip_pic32.build.core=pic32 mychip_pic32.build.variant=Uno32

Thanks to all

andre85

Fri, 09 Mar 2012 16:47:00 +0000

Hi Jacob, when you're free, can you give me the eeprom code fixed Thanks, Andrea

ricklon

Tue, 20 Mar 2012 19:35:41 +0000

Is there an issue number for this? I can verify if it's fixed or not in the latest test build.

--Rick

Jacob Christ

Sat, 24 Mar 2012 05:21:37 +0000

Sorry for the delay, got real busy.

There are two issues.

  1. The hardware\pic32\variants\Default_64\Board_Defs.h file has some missing code, this is what is causing the error when you compile.

The github repo is up to date, fixed by Gene.

The linker file is incorrect, and not fixed. I submitted issue #217

The MX440 linker file needs to be updated for the EEPROM emulation by updating the following line:

kseg0_program_mem (rx) : ORIGIN = 0x9D001000, LENGTH = 0x7B000 /* gap reserved for future eeprom usage */

Jacob