All simultaneously usable pins on Max32?

Created Wed, 01 Feb 2017 00:10:18 +0000 by rasmadrak

rasmadrak

Wed, 01 Feb 2017 00:10:18 +0000

Hi there!

It's closing in on me to design a PCB for my custom pinball machine, with the MAX32 as a "slot in" CPU. :) At the current development stage I'm using 47 pins, but am hoping to avoid using shift registers for critical functions like today, as I really need every clock cycle and want to do full port writes instead of clocking out bits. Therefor, I'm curious if there are any pins that cannot ever be used as I/O or conflicts when used one way or the other? I've looked through the documentation and I believe this to be true:

• Pin 24 cannot ever be used.
• None of the hardware serial pins can be used.
• Pin 44 cannot be used if AREF is used as input.

Excluding the pins above, which ports/pins are safe to use with these libraries simultaneously?

• "Regular" SPI (for SD card) and DSPI1 (for LED display)
• I2C (for EEPROM)
• One Hardware Serial port, preferably two (for audio, WAV Trigger)

It would mean a lot to me if someone has the answer, as that would save me a very lengthy and possibly faulty trial and error period. :) Thanks in advance!

All the best, Robert

majenko

Wed, 01 Feb 2017 00:46:10 +0000

Sure you should be able to use the UART pins as GPIOs. They only become UART pins when you use Serial[x].begin(...).

There are a couple of pins in the big connector at the end of the board that can only be input, or only output, or something. I forget which exactly they are, but they are connected to the USB D+ and D- pins. I'd avoid them if I were you. I have a feeling the USBID pin (it's one of the RFx pins IIRC) may only be input as well. Not sure on that one, or where it is routed to even ;)

Other than that I think everything else in the main headers is unique and available for GPIO except TX0 and RX0 that go to the FTDI chip, and the two LEDs which share GPIOs with headers.

majenko

Wed, 01 Feb 2017 00:49:12 +0000

As for the functions you want, SPI is fixed and pointing to the 6-pin SPI header. Not sure where that is shared with off hand. I2C has its own pins, too.

I would have to check to see where DSPI1 is routed to on the board - the user manual tells you of course.

Serials are all well labelled on the board.

They're all fixed functions on the MX795 - there's no PPS, so you don't get to choose where things go to. For anything that's not labelled on the board it's all listed towards the back of the MAX32 manual - there's a couple of big tables in different orders and groupings to help you find where all the functions go.

rasmadrak

Wed, 01 Feb 2017 10:40:11 +0000

As I suspected then. I have gone through the schematics and reference manual as well, but it's quite 'heavy' to process what I've read, hehe. :) I think I got a good understanding of the different pins, but I guess there's no way to avoid a bit of testing on a breadboard. As long as there's not a whole lot of overriding/conflicting functions it shouldn't be to difficult. :)

Thanks for your help! \m/

majenko

Wed, 01 Feb 2017 12:23:50 +0000

Just going through the pin lists and crafting a pinout image. I'm dismayed at the number of shared pins on this board. Typical Digilent...

You're going to need this image to make out the tangled web of pins...

majenko

Wed, 01 Feb 2017 14:33:11 +0000

Ok, first draft of my pin layout image. I hope I have it right.

The shared pins are highlighted in dark orange. Where a single GPIO pin has two pin numbers assigned to it (which is just plain idiotic) the associated pin numbers are also shown.

[attachment=0]max32.png[/attachment]

rasmadrak

Thu, 02 Feb 2017 10:04:39 +0000

Wow, did not expect this at all. MUCH appreciated and certainly helpful! ( Pins 21 - 14 in your design are reversed on the actual board though )

But... MUCH concerning. This clearly means I won't have enough pins for my current design. :S I think I'll have to keep using shift registers, possibly sharing clocks to shave off a few cycles.

majenko

Thu, 02 Feb 2017 10:38:22 +0000

They are reversed? Oops - easy to fix though. I do all that with a bunch of PHP scripts :) Just reverse the contents of an array and bob's your uncle.

[attachment=0]max32.png[/attachment]

I'm sure you can prioritise your shift register use so that high speed things are direct to the chip and only slow things go to the shift registers.

You may consider using IO expanders (eg MCP23017 / MCP23S17) instead of shift registers - much better functionality, and also do things like interrupt-on-change, internal pullup/pulldown, open drain, etc. SPI (fast) or I2C (not so fast) connected. Should give a more pleasurable experience than shift registers.

Alternatively maybe a different board is in order. One with more pins. There isn't one yet though... not until I finish designing Zoë... same footprint as MAX32, but a 144 pin PIC32MZ...EF chip. No pin duplication ;)

That's a while off yet though - like months and months.

Of course, you could always not use a separate board for the MCU and solder the chip direct (maybe the MX370 would be a better choice for you - 120MHz, PPS to remap peripherals to different pins, no USB taking up precious pins, etc). Or maybe think about a multi-processor system? Have a couple of smaller chips (two MAX32 boards?) and have them communicate. Double the processing power then. One could drive the display and sound and things like that, the other the game board and user interaction.

majenko

Thu, 02 Feb 2017 10:52:13 +0000

One thing with using SPI, though, is you could possibly use DMA to do the SPI transactions in the background. The normal SPI libraries don't do that at the moment, but not too hard to arrange.

Alternatively DSPI can do interrupt-based transfers which would take some of the load off. SPI can be used to drive shift registers if you are careful. The transfer happens in hardware, the interrupt triggers to just queue the next byte. With DMA it doesn't even need to do that. The DMA interrupt would just trigger at the end of the whole transfer to turn of the chip-select pin (or whatever needs to happen).

With DMA it may be slightly more involved, actually - there's the SPI's buffer to consider, which may be enabled or disabled at will - not sure which is best. With it enabled you'd:

• Turn on DMA and the "transfer finished" interrupt
• Enable CS
• Start transfer
• [color=#008800]Data transfers into SPI buffer as and when it can completely asynchronously[/color]
• Transfer finishes, interrupt triggers
• In interrupt enable SPI's "Buffer Empty" interrupt
• [color=#008800]Last few bytes get sent out of the buffer cmpletely asynchronously[/color]
• SPI finishes transferring from its buffer, interrupt triggers
• Disable CS

The bits in [color=#008800]green[/color] all happen in the background with no CPU use at all - so you can keep doing things while your shift registers are updating.

rasmadrak

Thu, 02 Feb 2017 11:41:22 +0000

Alternatively maybe a different board is in order. One with more pins. There isn't one yet though... not until I finish designing Zoë... same footprint as MAX32, but a 144 pin PIC32MZ...EF chip. No pin duplication ;) ... Of course, you could always not use a separate board for the MCU and solder the chip direct (maybe the MX370 would be a better choice for you - 120MHz, PPS to remap peripherals to different pins, no USB taking up precious pins, etc). Or maybe think about a multi-processor system? Have a couple of smaller chips (two MAX32 boards?) and have them communicate. Double the processing power then. One could drive the display and sound and things like that, the other the game board and user interaction.

Tasty! :mrgreen:
No pin duplication would be a nice selling point. That has indeed been the toughest nut to crack using any of the Arduino/Genuino/Chip-boards so far, hehe. But perhaps standard customers doesn't use that many. ;)

I was kind of hoping to simply convert my current development board system into a single PCB and optimize a few things here and there, hehe. I am actually using a Mega2560 for lights at the moment but hope to avoid it in the future as the communication is actually slower than letting the Max32 do the work itself. The core code is pretty tight today, but code and rules will be completely redesigned as a part of the PCB process. But I hope to avoid changing too much of the hardware to avoid adding too much to the already 5+ years time of development, haha! :D

Edit:

I/O expanders are actually looking pretty nice. Could possibly redesign to use those instead of SR's, like you said. Worthy to investigate at least! For the interested: [url]http://tronixstuff.com/2011/08/26/tutorial-maximising-your-arduinos-io-ports/[/url]