Question about Uno32 pinout...

Created Fri, 27 May 2011 20:29:43 +0000 by CopperPhil

CopperPhil

Fri, 27 May 2011 20:29:43 +0000

I'm searching a way to reduce the software changes in order to get existing shields working with the Uno32.

In many cases, pins 0 to 7 are used as a bidirectional 8 bit bus. I'm afraid those pins are mapped to a scramble set of D & F ports bits... not so easy to exchange 8 bit data through these pins then...

Something very strange, the pins 26 to 33 are well mapped to RE0 to RE7... so those pins are perfect to be used as a data bus... but they are located just beside the pins 0 to 7, and so it is not compatible with my shield...

Is it right?

Finally, perhaps I'm missing something and I'll be glad to get some explanation, or my understanding is correct and the Uno32 is not so compatible with existing Arduino shields...

Please tell me I'm wrong ;)

WestfW

Fri, 27 May 2011 23:08:11 +0000

I don't think you can expect too much compatibility below the arduino abstraction layer (and assuming that particular pins all belong to the same port is WAY below that layer. For instance, Arduino MEGA also has a scramble of different ports/bits for D0:7...)

Mark

Sat, 28 May 2011 14:48:22 +0000

It is impossible to get the pin mappings the same. Even on different versions of AVR chips, the special purpose pins such as tx/rx spi pins, i2c pins, etc all move around. For example if you made a mega board with an Atmega128 it would not be compatible at the port level with the same board made with an atmeaga 1280.

Now through in a different manufacturer that has 16 bit ports instead of 8 bit ports, has there own arrangement of special pins to ports which ALSO varies from chip to chip and there is now way that you can get that level of compatibility.

Take for example code written for the Adruino UNO board that uses the ports directly. It will NOT work on a mega board, no way, no how. You have to re-map the pins. I have done this several times writing graphics drivers for various LCD boards.

As long as you use the abstraction layer (i.e. digitalWrite()) it will work fine. But of course, for such things as graphics drivers for an LCD board, this has a time penalty.

Mark

CopperPhil

Sat, 28 May 2011 19:25:37 +0000

Finally I've modified the library to use the abstraction functions, easy for single bit control signals (R/W, CS and so on)... except for the data bus...

I have multiple shields using the pins 0 to 7 (scrambled through ports D and F) as bidirectional databus. Using digitalWrite/Read is not a good solution for me because of the speed. I would like to read/write very quickly the 8 bits... As far I know there is no abstraction function to do that, so I'm implementing home made solution. I evaluated the usage of bit shift & logical operation but it is still consuming too much time (I want to keep the CPU power for processing, not for stupid IO patching). So finally I'm moving to a solution using byte cross-ref const tables. It consumes Flash but it is very fast. Perhaps there is other solution, any other idea is welcome ;)

But again, it's very sad that pins 0 to 7 are mapped to RF & RD... while there is a pin to pin mapping between RE0->RE7 and pins 26 to 33, located just beside, same connector! It would have been so easiest to get it on pins 0 to 7 instead... :roll:

Perhaps a suggestion for the next version :idea:

By the way, I need to use Analog A0 to A5 as digital output. Abstraction functions do not allow to control them using digitalWrite, does it? So in my library, I'm using PORTSSetPinsDigitalOut, PORTClearBits and PORTSetBits on IOPORT_B... is it the right solution?

Thx,

/Phil

WestfW

Sat, 28 May 2011 20:29:39 +0000

I need to use Analog A0 to A5 as digital output. Abstraction functions do not allow to control them using digitalWrite, does it?

It should. (It does on AVR. There are constants defined so that you can do "digitalWrite(A0, HIGH)"; (do pinMode() first!))

If the RE port had been used for D0..7, it would have been impossible to put the PWM outputs in the same places they were on the Arduino, and those are more widely used than byte-wide IO. (ArduinoMEGA made the same decision: group all PWM pins together, rather than group ports together.)

It would be interesting to try to put together some max-speed byte-wide IO for assorted pin sets on the pickit boards. There are assorted weird things that you can do with a barrel shifter and/or 32bit multiply that might help. Better to do it once than have everyone attempt similar things separately.

Mark

Sun, 29 May 2011 02:32:35 +0000

By the way, I need to use Analog A0 to A5 as digital output. Abstraction functions do not allow to control them using digitalWrite, does it? ?

Yes the analog pins can be used as outputs. you should be able to use the pins exactly the same as in Arduino/AVR.

i.e. pinMode(14, OUTPUT); // 14 is A0 digitalWrite(14, HIGH);

or pinMode(A0, OUTPUT); // 14 is A0

CopperPhil

Sun, 29 May 2011 05:40:18 +0000

yes it works! I pefer using A0 instead of pin number ;-) but it's cool, I've modified the library to use only abstraction functions instead of direct registry.

My "write to databus" function is working (writing a byte to pins 0 to 7), except for bits 0 & 1 (which are also connected to FTDI through resistors). I'm testing sending values from 0 to 255, each bit is toggling except 0 and 1 keeping high even I have configured pins 0 & 1 as output.

Is there any usage limitation related to pins 0 and 1? are they reserved by the bootloader?