Arduino Mega 2560 digital pins 50-52 / ICSP pins

https://code.google.com/p/tlc5940arduino/wiki/ArduinoMegaHardwareSetup

Required Pins

Mega pin 51 (MOSI) -> SIN (Tlc pin 26) Mega pin 52 (SCK) -> SCLK (Tlc pin 25) Mega pin 11 (OC1A) -> XLAT (Tlc pin 24) Mega pin 12 (OC1B) -> BLANK (Tlc pin 23) Mega pin 9 (OC2B) -> GSCLK (Tlc pin 18)

According to this: http://arduino.cc/en/Reference/SPI, digital pins 50-52 on Arduino Mega are also connected to the pins on the ICSP header. But I I run this sketch:

#include "Tlc5940.h"
#include "Tlc_config.h"
#include "tlc_progmem_utils.h"

void setup()
{
  pinMode(3, OUTPUT);
  pinMode(8, OUTPUT);
  pinMode(9, OUTPUT);
  pinMode(10, OUTPUT);
  pinMode(11, OUTPUT);
  pinMode(13, OUTPUT);
}

#define pulse_pin(port, pin)   port |= _BV(pin);

void loop()
{
//  pulse_pin(GSCLK_PORT, GSCLK_PIN);
//  pulse_pin(XLAT_PORT, XLAT_PIN);
//  pulse_pin(BLANK_PORT, BLANK_PIN);
//  pulse_pin(VPRG_PORT, VPRG_PIN);
//  pulse_pin(SIN_PORT, SIN_PIN);
  pulse_pin(SCLK_PORT, SCLK_PIN);
}

Digital pins 50 - 52 will light up a LED but none of the pins on the ICSP header do.

Do you actually have to do something in code to connect them up perhaps?

They are physically connected, however I note that you haven’t set them as outputs.

The ICSP pins on an arduino are wired to the ISP pins of the AVR, which are in parallel with the hardware SPI interface pins (at least, on all AVRs that are used on Arduinos.) They are NOT always connected to Digital 11..13 !

[quote author=Nick Gammon link=topic=185029.msg1370497#msg1370497 date=1377724139] They are physically connected, however I note that you haven't set them as outputs. [/quote]

Oh....forgot about that. That would probably explain why the LED only lit up faintly on the last 4 of those pins in the loop() function.

From the next reply it sounds like those digital pins and the ICSP pins may not necessarily be connected on my particular mega.

I suppose I would have to trawl through the library to find out how exactly it is uploading data to the TLC5940.

I had been looking at another example: http://www.kevindarrah.com/download/arduino_code/TimersCountersV7.ino, http://www.youtube.com/watch?v=FehBLNHMlfo and this guy is using ICSP / SPI to upload data to the TL5940.

I had assumed this library would similarly use SPI, but perhaps it does not given that it does not specify any connections to the ICSP header.

If they weren't you wouldn't be able to program it using ICSP which would make the provision of the header rather redundant.

The ICSP header is connected to the ISP pins on the micro, which are the SPI pins since SPI (serial peripheral interface) is the protocol used to program via ICSP (in-circuit system programming).

As westfw said, you're setting pins 11-13 as OUTPUT, then you're writing to the SPI pins. On an Uno, those happen to be the same physical pins. On the Mega, they're not.

(The whole point of using the ICSP connector for SPI shields like the Ethernet Shield is that they run SPI on all of (Uno, MEGA, Due.) Older shields (older versions of of the ethernet shield, even) connected up D11..13 but still used the SPI peripheral, and that wasn't where SPI WAS on the MEGA. So the original Ethernet shield didn't work on the MEGA, and modern shields are supposed to use the ISP connector if they want to do 'hardware spi.'

Of course, you could do SPI via software bit-banging on pins D11..13 regardless of HW type, but that would usually be slower.

I don't know what the TLC5940 driver that you're using does...)

The schematic shows pretty clearly that the SPI pins on the Mega2560 board do not go to D10..D13. However, much to my chagrin, I discovered this week that the schematic shows all of the INT0..INT5 pins wired to the "wrong" header pins. This killed me for a little while.

Can someone explain why they decided it was necessary to remap the INTx pins so that INT0 would still be on D2 and INT1 would still be on D3, but they didn't care to put SPI on D10..D13?

Looking at it, it looks like they wanted to have all the PWM pins grouped together…

oric_dan: The schematic shows pretty clearly that the SPI pins on the Mega2560 board do not go to D10..D13. However, much to my chagrin, I discovered this week that the schematic shows all of the INT0..INT5 pins wired to the "wrong" header pins. This killed me for a little while.

You've seen this I suppose?

That was from: http://www.gammon.com.au/interrupts

No I hadn’t, but otherwise sure enough discovered the interrupts are all remapped on the Mega2560 board. You will also notice pighixxx doesn’t mention this on his neato Mega board diagram either.

westfw:
Of course, you could do SPI via software bit-banging on pins D11…13 regardless of HW type, but that would usually be slower.

After looking through the cpp file of the TLC5940 library it looks as though that it is using software SPI as you describe.

It uses that macro I found “pulse_pin” and that does not seem to use the SPI library.

A dumb question…

What sort of things would you use that ICSP header for? Can you give some examples?

BTW Nick, just to confuse matters, even with respect to your listing, Arduino says this: http://arduino.cc/en/Main/ArduinoBoardMega2560

External Interrupts: 2 (interrupt 0), 3 (interrupt 1), 18 (interrupt 5), 19 (interrupt 4), 20 (interrupt 3), and 21 (interrupt 2). These pins can be configured to trigger an interrupt on a low value, a rising or falling edge, or a change in value. See the attachInterrupt() function for details.

http://arduino.cc/en/Reference/AttachInterrupt

Board int.0 int.1 int.2 int.3 int.4 int.5 Mega2560 2 3 21 20 19 18

I guess one can interpret INTx any way they like.

boylesg: What sort of things would you use that ICSP header for? Can you give some examples?

First and foremost, for ICSP -- that is, programming the AVR chip from an external programmer. Or, using the Mega AS a programmer FOR another AVR chip.

But also, as a way for shields to reliably know where to find SPI, regardless what physical (on the chip) or digital (in the Arduino lib) pins its implemented on.

oric_dan: BTW Nick, just to confuse matters, even with respect to your listing, Arduino says this: http://arduino.cc/en/Main/ArduinoBoardMega2560

External Interrupts: 2 (interrupt 0), 3 (interrupt 1), 18 (interrupt 5), 19 (interrupt 4), 20 (interrupt 3), and 21 (interrupt 2). These pins can be configured to trigger an interrupt on a low value, a rising or falling edge, or a change in value. See the attachInterrupt() function for details.

http://arduino.cc/en/Reference/AttachInterrupt ... I guess one can interpret INTx any way they like.

They agree with my chart if you count the first number as a "pin on board" number. So pin D19 is indeed "attachInterrupt (4, ...)" however it is not INT4. So that document refers to what you are "supposed to use" not the INTx values. That's why I did the chart, because it is damn confusing if you want to configure the correct registers.

That's what I'm saying. It's confusing no matter what one tries to do. Too bad Ardunio centrale doesn't mention anything about the discrepancy (aka confusion) on the Mega board product page.

Yes, it's a pity.

I haven’t tested this, but just wanted to bring it to your attention, and ask your opinion on whether this will work or not for the Mega2560, with its remapped interrupts.

I am using a library that has the following line in it,

bitClear(EIMSK, INT0);

Given the library, this line assumes INT0 is on D2 because of the remapping, but INT4 is “really” on D2 in actuality. So will the proper bit get cleared in the EIMSK register, or not?

I can test this, but just find the overall logic of such operations to be utterly confusing. Given the following code that appears in WInterrupts.c,

    case 0:
      EICRB = (EICRB & ~((1 << ISC40) | (1 << ISC41))) | (mode << ISC40);
      EIMSK |= (1 << INT4);
      break;

I think the first code line above is a gotcha. ???

Given the library, this line assumes INT0 is on D2 because of the remapping, but INT4 is "really" on D2 in actuality. So will the proper bit get cleared in the EIMSK register, or not?

No it won't.

So, as I thought, it's another gotcha hidden in the obfuscation of the Catch-22 known as interrupt-remapping on the Arduino Mega2560 board.