Uno32 Second SPI

Created Tue, 16 Dec 2014 18:20:16 +0000 by Cosford

Cosford

Tue, 16 Dec 2014 18:20:16 +0000

Hi,

trying to make some design decisions at the moment, including which chip(s) I use for a project (made up of multiple devices).

The pic32mx320f has 2 spi ports, but the reference manual for the uno32 seems to suggest only one is accessible (SPI2).

Now, comparing the datasheet for the pic32mx320 (http://ww1.microchip.com/downloads/en/DeviceDoc/61143H.pdf)

and the reference manual for the uno32 (http://www.digilentinc.com/Data/Products/CHIPKIT-UNO32/chipKITUno32_rm.pdf)

would seem to suggest that I have the option of either: 2 SPI ports + 1 UART or 1 SPI port + 2 UART

Is that assumption correct?

Thanks in advance, -- Cosford.

majenko

Tue, 16 Dec 2014 18:57:55 +0000

The chip has 2 SPI and 2 UARTs. Each UART shares its pins with an SPI, so you can have two UARTs, or one UART and one SPI. It might be possible to have two SPI and no UARTs, but one UART is hard-wired for programming / USB port, which might interfere with the SPI communications somewhat - if the core even allows you to disable the UART in favour of the SPI...

Cosford

Wed, 17 Dec 2014 10:41:59 +0000

Hi, thanks for the reply.

I must admit, that's somewhat disappointing.

Off the top of your head, is there any chipkit compatible boards available with 2 seperate SPI ports and 2 UART? I've got a lot of libraries and things set up to use with the Arduino IDE that I shifted over to be compatible with MPIDE and pic32 that I'd like to use.

To provide a little insight, the system I'm developing involves a few units. Type A needs an SPI port for an nRF24L01 radio module, an SPI port for an LCD screen, two UARTs for communicating with other microcontrollers via a custom peripheral port and a final port for communicating with an audio chip.

Type B requires the same as the above, minus the LCD display.

As such, the uC for type A needs 2 SPI ports, and at least two UARTs (with the third being provided by SoftwareSerial). Type B could be the same chip, or alternatively with 1 less SPI port.

Thanks, -- Cosford

EDIT: In addition to the above, would I be correct in assuming the uC32 would allow me access to two UART and one SPI? (U1 on chipkit pins 0 & 1, U2 on chipkit pins 39 & 40 and SPI2 on pins 11 - 13)

majenko

Wed, 17 Dec 2014 11:39:28 +0000

There's plenty. The MAX32 is probably your best bet - the '795L has 4 SPI and 6 UARTs, and not all are shared with each other.

Then there's the Fubarino SD that has the '795H chip - the 64-pin version. That has (off the top of my head) at least 2 SPI and 2 UART available, and they're not all shared either. I can't remember exactly what there is on that one though.

Then of course you have the smaller chips - the 150 / 250 based boards. They have PPS that allows you to move the pins around a certain amount - makes it easier to arrange different combinations of peripherals.

Cosford

Thu, 18 Dec 2014 13:28:33 +0000

Hi, thanks once again.

Think I've got a little more research to do, got to price everything up as-well and work out which is the most suitable way to go.

Regards,

Cosford

Mon, 22 Dec 2014 16:47:50 +0000

Hi again,

some side developments have occurred elsewhere, which have resulted in me no longer requiring access to the second SPI port.

So, type A simply requires 1 SPI port and 1 Hardware UART. Type B requires only a single hardware UART and no SPI.

The other serial connections I can emulate in Softwareserial as the devices they will need to communicate with will be programmed by myself and I intend to program them such as they will never need to instigate communication with the main chip and instead will be polled by the main chip for information (I believe I can easily implement the functionality for the main chip to change which software port it is listening to?).

This simplifies my situation considerably, freeing up some space to consider cost. The pic32mx250f128 will suffice in terms of pin count etc, but I wonder if there is a more economical option. With this in mind, how easy is it to write MPIDE compatible bootloaders for other chips? And is there an easy way of porting these libraries over to use them in MPLAB in order that I might program the chip without the use of a bootloader, whilst maintaining the working functionality of libraries?

Sorry these are quite general questions, but I'm struggling to find up-to-date resources.

Regards, Iestyn.

majenko

Mon, 22 Dec 2014 17:01:32 +0000

If they're PIC32 chips, then it's simple enough - just grab the bootloader source and create a new hardware profile for the new chip.

Any other chip though, if there isn't already a suitable bootloader available, then a huge amount of work. Also porting the core and libraries for those other chips would be a massive task.

Cosford

Mon, 22 Dec 2014 17:07:17 +0000

Brilliant. It would of course be a PIC32 chip, but I'm thinking something like the PIC32MX150F128B.

Getting slightly off-topic now, but rather than starting a new thread; Is it possible to program the chip using core MPIDE libraries, minus the bootloader, in a similar fashion to the way you can for arduino?

majenko

Mon, 22 Dec 2014 20:53:21 +0000

There are ways and means, yes. You need to have the right bootloader-free linker script though. I can't recall if there's a 150 -nobootloader linker script in the distribution or not, but you may be able to take some of the existing ones for other chips and combine / edit them to make a 150 one.

Cosford

Tue, 23 Dec 2014 13:04:48 +0000

Are linker scripts in the core .ld files? If so, I can't seem to find one for the MX150. What exactly does the linker script do in the compilation process?

Whilst it's not preferable, I could of course do all the programming within MPLAB but whilst I'm quite happy to write most of my code using PLIB, one library I could really do with having is the SoftwareSerial library, as I will be relying on that for much of my functionality and it's not the sort of library I'd like to try and reconstruct.

EDIT: Just came across this thread: http://chipkit.net/forum/viewtopic.php?f=6&t=2439

This is my understanding thus far, if you're able to fill in the blanks at all or correct me please do. In order to use the MPIDE/Arduino core and libraries, I could go two routes.

-> Use MPIDE

-> Without a bootloader

[/list] [/list]

Now, there is a bootloader for the pic32mx150f128b available in this thread: http://chipkit.net/forum/viewtopic.php?f=17&t=2438 I believe with this I should be able to program my chip (and using the dp32 boards definition as stated in that thread).

Having said all this, is there any advantage to not using a bootloader?

Thanks once again.

majenko

Tue, 23 Dec 2014 13:26:15 +0000

Yes, those are the files.

The purpose of the linker script is to define what goes where in the chip. They specify how much memory there is, where that memory is, and what can go in that memory.

Take the MX250 one and rename it to the MX150 - the chips are pretty much the same, just the 150 doesn't have USB. It should work.