Use pin name instead of number fails - why?

Hi all,

On the MEGA2560 R3 board, the schematic diagram shows (for example), digital pin #30 as PC7. Yet, if I use "PC7" or "PORTC7" in a sketch, pin 30 is not addressed. Anyone know why this is, and what the proper way to address by port name/pin number is?

Thanks!

-- Roger

PORTC7 is a shift value meant to be used with PORTC…

  PORTC |= (1 << PORTC7);

Is that how you are using it?

Those defines are ATMEL defines not Arduino defines. Yeah, I don't know why Atmel bothered to define all those defines. (There are hundreds of them)

They are pretty much worthless. All they do is define the bit number of the bit used within the register. (and they have them for port/pin/ddr ) Given you had to know the bit number to reference the define name, it seems rather pointless.

So DD7 is 7 PORT7 is 7 PIN7 is 7 PORTC7 is 7 PORTD7 is 7 DDB0 is 0 PORTB0 is 0

and on and on. I think people could figure out how to use the bit numbers directly......

Now the other hundreds of defines they created that assign mnemonics to the bit numbers, in the registers that match the names used in the AVR datasheet those are very useful. BODS, PUD, WRDF, RXEN0, etc....

The really crazy/lazy ones are the new Arduino defines like A0, A1, D0, D1, MISO, etc... Those are just plain dumb and begging to have name collisions. Just look at how they handled their first collision that people complained about "LED" was changed to "LED_BUILTIN". They should have used more unique names,with a common prefix on all of them or even better created a C++ Arduino object so that there would be no collisions and then it could be referenced like: Arduino.pin.miso

In terms of being able to directly reference a pin by its AVR port/pin # Arduino has no such mechanism since the entire pin mapping concept is an arduino thing. There are libraries that can do direct port i/o from taking an arduino pin #.

But the other way around is pretty hard given the goofy way the Arduino guys have implemented their pin mapping.

I do it in the glcd library and have written a GPL open source library that does it. It can be found here: http://code.google.com/p/mcu-io/downloads/detail?name=avrio.zip

Just keep in mind that this code is intentionally licensed as GPL v3 and not LPGL so it cannot be used in closed source projects.

It allows you to do direct port i/o by using pin names like: PIN_Pb where P is the PORT, A, B, C, ... and b is the bit number 0 - 7. i.e. PIN_C7 would be PORTC bit 7

It works outside the core code so that it can do single cycle i/o operations rather than the goofy slow table lookup mechanisms that the Arduino core code uses. It can also do multi bit i/o (like a full byte) in a single cycle when the multiple pins happen to be adjacent bits in the same register all in the correct order.

Again, I want to emphasized that this code is GPL v3 which forces any project that uses it to be GPL which is different from most of the other code used in Arduino which uses LGPL v2 which allows use in closed source projects.

--- bill

update: to reflect new mcu-io project where avrio will live

I see my mistake. I wasn’t using it that way. For some reason, I thought “PORTC7” would be the same as “30” (the pin on the MEGA2560).

Thanks.

bperrybap: I do it in the glcd library and have written a GPL open source library that does it. ............ It works outside the core code so that it can do single cycle i/o operations rather than the goofy slow table lookup mechanisms that the Arduino core code uses. It can also do multi bit i/o (like a full byte) in a single cycle when the multiple pins happen to be adjacent bits in the same register all in the correct order.

Wow! I didn't know you were one of the authors of the GLCD library!

Anyway, what I was trying to do is exactly the same as you... change the code in the Noritake GUU-100 (128 x 64 GVFD library) from using digitalReads and digitalWrites because they are so slow.

I purposely wired the VFD to PORTA for the data port so I could do a fast "PORTA = data" and "data = PINA", but the other control lines are on PORTC and I'm stuck with slow digitalWrite calls.

I'll check out your avrio library... it sounds like what I need.

By the way, I added a function to your GLCD library... a "SetBrightness()" function - because the Noritake display I'm using is KS-108 compatible and it supports 8 levels of brightness, so I added that to the library.

Thanks for the reply.

-- Roger

(edit) I see I already have avrio.h... in the GLCD library! :)

Krupski: (edit) I see I already have avrio.h... in the GLCD library! :)

But the version you have in glcd is only licensed for use with glcd and is not licensed for other use. If you want to use avrio in some other project then you must get the other one I linked to. In reality they are the same, other than the license but you still need the other one to comply with the license.

All this is due to a VIOLENT disagreement I had with Michael over the licensing of the glcd library. The ks0108 library he did wasn't really licensed. It was assumed to be lgpl but it really didn't have a license. I wanted to switch to GPL since I believe in open source and lgpl is all about allowing and promoting closed source. GPL v3 forces code that uses it to be open source. Without that restriction, you potentially become an unpaid slave to some else's closed source project. I was doing most of the work for the ks0108 to glcd transition and in particular all the tremendous amount of work for the AVR raw i/o and text rendering. Therefore I wanted it to be GPL vs LGPL. We settled on a hybrid which can be done with with gpl/lpgl v2 agreements. The compromise is that some of the code is only lgpl if used in the glcd library when used in Arduino environments. Any other use is not allowed.

Essentially I license avrio as GPL v3 but made an exception and created a separate lgpl license when avrio is used with the glcd library.


I'm curious about the brightness control you mentioned. I've added backlight control with backlight brightness, but I'm assuming what you are talking about is for the actual pixels and not the backlight. Got a link to a datasheet for that display?


I think I'll create an actual google code repository for it so it can be properly source code controlled and track any issues that show up.

--- bill

bperrybap:
(1) But the version you have in glcd is only licensed for use with glcd and is not licensed for other use.
If you want to use avrio in some other project then you must get the other one I linked to.
In reality they are the same, other than the license but you still need the other one to comply
with the license.

(2) I’m curious about the brightness control you mentioned.
I’ve added backlight control with backlight brightness, but I’m assuming
what you are talking about is for the actual pixels and not the backlight.
Got a link to a datasheet for that display?

— bill

(1) OK no problem. I’ll D/L the one you linked to.

(2) You would have to supply your name and address and email to Noritake to download the datasheet, so to save you the trouble, I attached it for you instead. Also attached is the code library that Noritake supplies (that’s where you’ll see how they do the brightness - in the file “Noritake_VFD_GUU100.cpp”.

And finally a #3… I’ve been looking at the “avrio.h” code and the “glcd” code and I’m not quite sure exactly how to use it. I would really appreciate it if you could give me a push in the right direction.

Here is a the code that I would love to convert to use avrio (this is my version of “parallel.cpp” which you’ll see in the Noritake code library) - but I call it “mode0.h”:

// mode0.h - GU-U100 in parallel mode
// Arduino MEGA2560 R3 pinout

#ifndef _MODE0_H
#define _MODE0_H

#define RS	30
#define RW	31
#define EN	32
#define CS1	33
#define CS2	34
#define RESET	35

#define PORT	PORTA
#define DDR	PORT-1
#define PIN	PORT-2

// VFD PIN	PORT	  MEGA2560
// NUMBER	NAME	PIN	PORT
// =======	====	===	====
//	 4	RS	30	PC7
//	 5	RW	31	PC6
//	 6	EN	32	PC5
//
//	 7	DQ0	22	PA0
//	 8	DQ1	23	PA1
//	 9	DQ2	24	PA2
//	10	DQ3	25	PA3
//	11	DQ4	26	PA4
//	12	DQ5	27	PA5
//	13	DQ6	28	PA6
//	14	DQ7	29	PA7
//
//	15	CS1	33	PC4
//	16	CS2	34	PC3
//	17	RESET	35	PC2

void initPort() {
	digitalWrite(RESET, HIGH);
	digitalWrite(EN, LOW);
	pinMode(RS, OUTPUT);
	pinMode(RW, OUTPUT);
	pinMode(EN, OUTPUT);
	pinMode(CS1, OUTPUT);
	pinMode(CS2, OUTPUT);
	pinMode(RESET, OUTPUT);
}

void hardReset() {
	digitalWrite(RESET, LOW);
	_delay_ms(10);
	digitalWrite(RESET, HIGH);
	_delay_ms(100);
}

uint8_t readPort(bool rs, bool chip) {
	uint8_t data;
	digitalWrite(CS1, !chip);
	digitalWrite(CS2, chip);
	digitalWrite(RS, rs);
	*(&DDR) = 0b00000000; // DDR input
	digitalWrite(RW, HIGH);
	digitalWrite(EN, LOW);
	digitalWrite(EN, HIGH);
	data = *(&PIN);
	return data;
}

void writePort(uint8_t data, bool rs, bool chip) {
	digitalWrite(CS1, !chip);
	digitalWrite(CS2, chip);
	digitalWrite(RS, rs);
	*(&DDR) = 0b11111111; // DDR output
	digitalWrite(RW, LOW);
	*(&PORT) = data;
	digitalWrite(EN, LOW);
	digitalWrite(EN, HIGH);
}

#endif

I would love to get rid of all those digitalWrites and digitalReads… :slight_smile:

Noritake_GU-G100_Datasheet.zip (270 KB)

Noritake_VFD_GUU100.zip (582 KB)