Question about pins_???.h files

Projects General Guidance
1

Hi All...

I apologize for the cross posting, but I'm really stuck. I originally posted this question is a lower traffic section of this forum, but I'm hoping by asking here more people who might know the answer will see it.

Original posting here:

http://arduino.cc/forum/index.php/topic,62929.0.html

In a nutshell, I'l trying to write a proper pins cxx file for an ATMega1284P-AU, as opposed to the -PU. The distinction is that the pins files that support the 1284P now are for the DIP package. The SMT package has more pins and the port to pin mapping is quite different.

Any suggestions are appreciated, thanks!

2

I'm not really sure what you're trying to do. The mapping between ports and associated functions is identical between packages - the SMD version's extra pins may need to be addressed, but for your situation that doesn't seem to be an issue.

The issue you've got appears to be that the pins you've got hooked up to various peripheral components have changed - we'll need to see your hardware board design and/or a schematic to help you convert the code over. If you connected the peripherals to the same port/pin (e.g. PB0, PC5, PD2, etc), the code would be identical.

The Arduino "pin" to port mapping is dependent on the board and available functionality - it's a high-level software abstraction, not an actual hardware difference. That is: digital pin 1 refers to the pin labelled "1" on the Arduino board - mapping a port/pin in software to that particular physical pin is what the pins cxx file does. This allows you to more easily write code for the board - it's more confusing to use PORTB |= (1 << 2) than to do digitalWrite(1, HIGH), for example.

3

Aeturnalus:
The Arduino "pin" to port mapping is dependent on the board and available functionality - it's a high-level software abstraction, not an actual hardware difference. That is: digital pin 1 refers to the pin labelled "1" on the Arduino board - mapping a port/pin in software to that particular physical pin is what the pins cxx file does. This allows you to more easily write code for the board - it's more confusing to use PORTB |= (1 << 2) than to do digitalWrite(1, HIGH), for example.

I think I understand you. I noticed that in the case of the 1284P, the SMT package has physical pin 1 assigned to PB5, while PB5 is physical pin 6 in the DIP package and thought the code was mapping virtual pins to physical pins. From looking at the code, it seems that it is doing something based on the pin to port arrangement.

So what you are saying is that "digital pin 1" has nothing to do with physical pin 1. Are you saying that digital pin 1 should always map to PB5 (for example - I don't know what it really maps to)?

If so, how do I figure out which "digital pin" maps to which port on the chip?

4

The pin mapping file aren't real intuitive on what is going on but this link gives a better visual.

https://spreadsheets.google.com/pub?key=rtHw_R6eVL140KS9_G8GPkA&gid=0

Lefty

5

Oh I think the light just went on!

So in this code sample, taken from pins_duino644.cxx, an array is built. Perhaps "digital pin 7" is element 7 in this 0-based array, and therefore port PB7? I see from Lefty's chart that digital pin numbers are 0 based, like this array is. Is that how it works?

So in my case, all I would need to do is figure out from my schematic which port the particular thing I am interested in is wired to, then look at this code and I'll know the corresponding "digital pin"?

const uint8_t PROGMEM digital_pin_to_port_PGM[] =
{
	PB, /* 0 */
	PB,
	PB,
	PB,
	PB,
	PB,
	PB,
	PB,
	PD, /* 8 */
	PD,
	PD,
	PD,
	PD,
	PD,
	PD,
	PD,
	PC, /* 16 */
	PC,
	PC,
	PC,
	PC,
	PC,
   	PC,
	PC,
	PA, /* 24 */
	PA,
	PA,
	PA,
	PA,
	PA,
	PA,
	PA  /* 31 */
};
6

Is that how it works?

Yes.

However it gets more complex later as there is need for arrays to determine which pins have timers that are also abstracted, user interrupts numbers are also an abstractions. There is really a lot of magic to make the whole arduino pin number and pin functions abstractions and account for the speed penalty over using simple port/pin commands using direct port access commands. Of course using direct port command then makes sketches non portable across say uno and mega boards.

Lefty

7

Okay thanks very much Lefty and everyone else. I still can't get my SD Card reader to work, so perhaps the problem is not my SS pin. I thought I just had the wrong pin selected. I'll dig deeper. But at least now I know I'm probably on the right pin. I think I'll dig out a volt meter just to be 100% sure.