Show Posts
Pages: [1] 2 3 4
1  Using Arduino / Project Guidance / Re: Problem with AREF input (MEGA2560) on: September 19, 2011, 03:14:45 pm
Hi Coding Badly,

Why are you changing ADMUX?  For most folks, the Arduino Core manages that detail.  Are you using the analog-to-digital converter in a non-Arduino way?

Yup - I'm trying to use the ADC on higher frequency, and so trying to do the MUX switching and ADC sampling "manually" in separate steps...

Cheers!
2  Using Arduino / Project Guidance / Re: Problem with AREF input (MEGA2560) on: September 14, 2011, 04:48:34 am
Ok, I think I found what the problem is...

Basically, the doc2549 - MEGA2560 datasheet on pg 276 gives a schematic, where we can see that AREF is basically led to the output of a transistor - the transistor otherwise feeding the choice between AVCC and internal reference. Obviously, if this transistor is ON, then AREF will behave as a voltage source.

Thus, the trick is to turn off this transistor - and that is controlled by bits REFS(1:0) - the most significant bits of ADMUX register; specifically, to turn the transistor OFF, REFS(1:0) have to be set to 0 0.

In my case, the loop part of the code (which is not listed above in the OP), actually sets specifically ADMUX in order to sample, and I realized it is set to 0b01xxxxxx - which selects the AVCC reference... Since this part ran in the loop, it basically cancelled any influence analogReference(EXTERNAL) may have had - and hence I kept getting a 'voltage source' behavior from AREF pin.

As soon as I changed the ADMUX to be set to 0b00xxxxxx - the AREF pin seems to behave; it basically sits at 0V, and when 3V3 is brought to AREF - AREF seems to happily accept it now...

Well, hope this may help others in similar trouble smiley
Cheers!
3  Using Arduino / Project Guidance / Problem with AREF input (MEGA2560) on: September 14, 2011, 04:01:30 am
Hi all,

Working on a MEGA2560, and I would like to set the analog voltage range to 3.3V.

Related to this, the main page says:
... By default they measure from ground to 5 volts, though is it possible to change the upper end of their range using the AREF pin and analogReference() function.

There are a couple of other pins on the board:

AREF. Reference voltage for the analog inputs. Used with analogReference().

Right .... And then, the analogReference page says:
Don't use anything less than 0V or more than 5V for external reference voltage on the AREF pin! If you're using an external reference on the AREF pin, you must set the analog reference to EXTERNAL before calling analogRead().

So, the way I'm reading this, AREF should be an input pin (in other words, Hi-Z/high-impedance pin), to which I should be able to bring some sort of a reference voltage source.

However, the problem is that AREF by default, constantly generates a 5V reference!

Ok, so then, I thought that the problem is with the analogReference function, so in my code, I added first in setup:
Code:
void setup()
{
  // set up the analog reference pin;
  analogReference(EXTERNAL);
...

.... and NOTHING happens - the AREF pin STILL generates +5V... How do I know this? Well, I made a small jumper that connects the Arduino 3V3 pin to AREF pin: and the 3V3 pin measures 3.3V when it is unconnected - but as soon as I connect it to the AREF pin, it is forced to 5V!!!  I'm thinking, this cannot be good..

So will someone explain to me:
  • Obviously, the AREF pin behaves like a voltage source; is it supposed to behave like a Hi-Z input at times?
  • Is the analogReference(EXTERNAL); supposed to make the AREF pin behave like an input?

If I'm going completely wrong with the statements above - what would I need to do, in order to set the analog voltage range to the 3.3V that come out of the 3V3 pin of the Arduino?

Many thanks in advance for any answers,  
Cheers!

4  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 11, 2011, 11:46:39 am
Hi @Coding Badly,

Thanks a lot for this clarification:

Quote
So this is a bug, it seems, specific to Timer/Counter 0

Timer 0 is used by millis, micros, delay, and delayMicroseconds (and two PWM pins).  You can certainly use timer 0 for your own purposes but doing so will very likely cause those four functions to misbehave.  In your case, delay completely stopped working.

I was of course aware that some sort of resources must be already used on the board, but it didn't really sink in until I read your comment - probably because now I had a real problem smiley And good for me to know it is not a bug - however, it is something to take into account... (although, I just now bumped into a similar freeze problem, when I try to set ADCSRA on the ATMega2560 to anything else than its default value smiley-sad I wish I knew if any of the API functions are using it as well... smiley-wink )

Btw, is there any sort of a quick reference that mentions these kind of resource usages by the Arduino API functions?

Thanks again - much appreciated,
Cheers!
5  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 06:15:59 pm
Hola again,

Well, it seems I have somewhat of a workaround fix: basically, I avoid using Timer 0; and use Timer 2 instead (simply replace respective register names to: TIMER2_COMPA_vect, TCCR2A, TCCR2B, TCNT2, TIMSK2, OCR2A in the code above) - and then both interrupt pulses, and main loop pulses and serial writes, are visible continuously. This is fine for my current project where I need only one timer anyway - but what to do in case there is need of more?

So this is a bug, it seems, specific to Timer/Counter 0 on Arduino MEGA 2560... By using PORTA = TCCR0A;, I could see its initial value (in the setup function, at least) is 0b00000011 (incidentally, that is the same initial value for TCCR2A) - which is "fast PWM" mode; and indeed, if you consult arduino-mega2560-schematic.pdf, the output compare pin A for timer 0 (OC0A/OC1C/PCINT7) PB7 (26) - D13 is marked with "PWM". The only thing, obviously different from timer 2, is that this OC pin is also used to drive the LED (but then again, the same pin is used in the same way on the Diecimilla/Uno - and they seemingly don't have this problem). 

In any case - I'd still love to hear an explanation for why this is happening smiley

Cheers!
6  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 03:40:50 pm
Hi @Coding Badly,

Don't thank me yet.  I'm about to scold you...

Hah, no worries - I certainly don't mind scolding, if I missed anything important, and I learn something new! smiley Besides, it's always nice to see a thread is alive... so thanks again! smiley


// Remove ISR_NAKED.  Even for very experienced AVR developers, this is difficult to get correct.
...

With the ISR_NAKED option, you are lucky that it works.  Get rid of that option.

Done - honestly, I don't know much about interrupts, and I have copied that initialization some time ago from somewhere (forgotten where from) - and as it worked then (but for a different interrupt, and chip), I just kept on copying it in different projects ...  


...// Remove the following two lines of code.  The are unnecessary. (x2)

Done - now the function looks like this:
Code:
...
ISR(TIMER0_COMPA_vect)
{
  digitalWrite(DBGPINI, not((bool)digitalRead(DBGPINI)));
}
...

When I run the code with this function, the ATMEGA2560 shows interrupt debug pin pulsing; however, nothing on main debug pin (13), and the serial output is:
Code:

Hello from setup
Hello from loop: A

.... and that's it, there the main loop apparently locks. I'm guessing it is some of the register setting in the "register update part" that breaks the main process...


So, I thought to look once more into that part of process, and look at this - the following piece (along with the previous simplification of the ISR) actually demonstrates both serial write and interrupts on the 2560:
Code:
#if 1 // register update part
  cli(); // disable interrupts
  GTCCR = 0b10000011; // halt timers
  // set up Timer/Counter 0
  //  TCCR0A = 0b00000010; // CTC; normal mode (don't use output pin)
  TCCR0B = 0b00000101; // no force output; CTC; ... and clock select: prescale 1024
  TCNT0 = 0; // init the actual counter variable
  TIMSK0 = 0b00000010; // enable (only) Compare Match A Interrupt
  OCR0A = 125; //the top value, to which the running counter is compared to

  GTCCR = 0b00000000;
  sei(); // Enable interrupts once registers have been updated
  
  digitalWrite(DBGPINM, LOW);
  delay(200);
#endif

... That is, I just need to comment the TIMSK0 = 0b00000010; TCCR0A = 0b00000010; statement - and code starts working on the MEGA2560 just as on the other two chips! However, the question is why ? And also, as far as I understand - I *do* need to set TIMSK0 TCCR0A, in order to set CTC mode, right?

Seemingly, this  TIMSK0 TCCR0A setting will kill serial.write even if it is in setup() (that is where I first noticed it) ... And so I found this post for TIMSK0: atmega2560 Interrupt :: AVR Freaks:
Quote from: Koshchi link=http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48439&p=803359#803359
OUT only works for registers with addresses below 64 (0x40). TIMSK0 on that chip has an address of 110 (0x6E). You need to use STS instead.

... but it is from 2005, and if I press Shift+Verify in Arduino IDE to get the command line, and then modify the switch -c to -S, I get an assebly line listing, which shows that the C command TIMSK0 = 0b00000010; is correctly compiled using the STS assembly instruction:
Code:
# for stdout:
$ grep -r SKETCHNAME /tmp/console*
/tmp/console390364846081395661.tmp/stdout.txt:avr-g++ ...

$ avr-g++ -S -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=22 -I/path/to/arduino-0022/hardware/arduino/cores/arduino /tmp/build6714629142643953238.tmp/SKETCHNAME.cpp -o/tmp/build6714629142643953238.tmp/SKETCHNAME.cpp.s

$ less /tmp/build6714629142643953238.tmp/SKETCHNAME.cpp.s

# shows:

/* #APP */
 ;  42 "/tmp/build6714629142643953238.tmp/isrsertest.cpp" 1
        cli
 ;  0 "" 2
        .stabn  68,0,43,.LM7-.LFBB1
.LM7:
/* #NOAPP */
...
.LM8:
        ldi r25,lo8(2)
...
.LM11:
        sts 110,r25                     <== YUP sts being used, all fine
        .stabn  68,0,49,.LM12-.LFBB1
/* #APP */
 ;  52 "/tmp/build6714629142643953238.tmp/isrsertest.cpp" 1
        sei
 ;  0 "" 2
        .stabn  68,0,54,.LM15-.LFBB1
.LM15:
/* #NOAPP */

So, that ain't it either - but apparently, the key here is some conflict between  TIMSK0 TCCR0A and the UART on an ATMEGA2560... Any tips related to how to proceed on this, are more than welcome smiley

Cheers!

EDIT: Made a mistake - should have been TCCR0A not TIMSK0 (so I shouldn't have bothered with the above assembly listing check... but I'm leaving that part for reference)
7  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 02:28:34 pm
HI @Coding Badly,

Thanks for replying!

Is this the code you are running on the 168 and 328 processors...
http://arduino.cc/forum/index.php/topic,69017.msg509975.html#msg509975

Yup - the exact same (except for that I changed pin 34 to pin 7 for the smaller Arduinos)..

Cheers!
8  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 11:24:44 am
Hi again,

Just to note - I just re-run the exact same code above (apart from change of debug pin) through an Arduino Diecimilla with an ATMega168 - everything works fine - interrupt function is running along with happily with the main loop (and in spite of halting and resetting everything at each execution of the main loop!) EDIT: Also tried it with an Arduino UNO with an ATMega328 - works fine too...

Which gives?: this is probably a bug, either with: avr-gcc specifically for the ATMega2560; or some wrong defines are being read for the ATMega2560 by the Arduino IDE (but then, compiler would complain, no?); or there is some register that needs to be set additionally for the ATMega2560 (which means plowing through the massive datasheet smiley-sad ); - or finally, there is maybe some sort of a "hardware" bug on the board?

Well, if anyone could think of a thing to try, please comment ...

Thanks - cheers!
9  Development / Suggestions for the Arduino Project / Re: Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 09:16:32 am
Hi @frank26080115;

Thanks for the prompt response!!

oh and double check that you have the right board selected, so that the compiler is indeed targetting the atmega2560

Did that, double-checked smiley


also, do you need to constaintly re-initialize the timer in loop()? why not do it only once in setup()?

You're absolutely right - that initialization indeed started in setup; then when I saw it failing, I thought it maybe has to do with it being located there (although it should be in setup, as you note) - I tried a myriad of combinations of code placements, to see if that made a difference - and when I finally exhausted all I could try, I decided to post; and that code is simply the version I had at the time... EDIT: But it also helps to demonstrate where exactly the code fails - which arguably would be more difficult if it is kept in setup...


Try it without using ISR_NAKED (and so you don't need to remember SREG or use cli or use sei or use reti)

This sounds very promising, thanks - I had no (clear) idea that ISR_NAKED is related to use of SREG cli/sei/reti - will give it a shot!

Many thanks again for the prompt response,

Cheers!


 
10  Development / Suggestions for the Arduino Project / Avr-gcc: Timer/counter interrupts conflicting with UART? on: August 10, 2011, 08:45:33 am
Hi all,

I tried this question first as Avr-gcc: Timer/counter interrupts conflicting with UART?; but since that problem is a showstopper, I'd like to see if I get some comments here. Not sure if its a bug, per se, (I think it could be more, due to my lack of understanding of C++ classes and interrupts) but the content follows: :::::

Please consider the following example (tried on Arduino IDE 0022, Ubuntu 11.04, Arduino AtMEGA 2560), where I'm trying to start a timer/counter interrupt and use the Arduino `Serial` class at the same time:

Code:

volatile uint8_t sreg;

// main loop debug pin
#define DBGPINM 13
// ISR debug pin
#define DBGPINI 34


// Timer 0 interrupt routine
ISR(TIMER0_COMPA_vect, ISR_NAKED)
{
  sreg = SREG;  /* Save global interrupt flag */
  cli(); /* Disable interrupts */

  digitalWrite(DBGPINI, not((bool)digitalRead(DBGPINI)));

  SREG = sreg; /* Restore global interrupt flag */
  reti(); // must for ISR: return and enable interrupt 
}

void setup() {
  pinMode(DBGPINM, OUTPUT);
  pinMode(DBGPINI, OUTPUT);
  Serial.begin(115200);
  Serial.println("Hello from setup");
  delay(200);
}

void loop() {
  digitalWrite(DBGPINM, HIGH);
  Serial.println("Hello from loop: A");
 
  digitalWrite(DBGPINM, LOW);
  delay(200);
 
  digitalWrite(DBGPINM, HIGH);
#if 1 // register update part
  cli(); // disable interrupts
  GTCCR = 0b10000011; // halt timers
  // set up Timer/Counter 0
  TCCR0A = 0b00000010; // CTC; normal mode (don't use output pin)
  TCCR0B = 0b00000101; // no force output; CTC; ... and clock select: prescale 1024
  TCNT0 = 0; // init the actual counter variable
  TIMSK0 = 0b00000010; // enable (only) Compare Match A Interrupt
  OCR0A = 125; //the top value, to which the running counter is compared to

  GTCCR = 0b00000000;
  sei(); // Enable interrupts once registers have been updated
 
  digitalWrite(DBGPINM, LOW);
  delay(200);
#endif

  digitalWrite(DBGPINM, HIGH);
  Serial.println("Hello from loop: B");
 
  digitalWrite(DBGPINM, LOW);
  delay(200);
}

As the example is, the printout via serial will be:
Code:
   Hello from setup
    Hello from loop: A
    Hello from loop: B
    Hello from loop: A
    Hello from loop: B

... and then all processing will stop (indicated by lack of action on both LED pin 13 and 34); I guess, this is what you would call a BSOD in the chip world smiley Superficially, the halt happens as soon as the ISR routine kicks in for the first time.

If you take out the "register update part", then the serial printout runs forever, as expected - and also (as expected), there is no ISR running. However, if the "register update part" is left, and the two "Serial.println(..." lines are commented instead - then the program prints only "Hello from setup" - but the interrupt does run (as evidenced by pulses on pin 34).

Which seems to tell me, that you cannot run a timer ISR and the UART on the ATMega2560 at the same time - which is silly, given that I had previously used, with success, the same kind of approach on an ATMega328.

So, I'm wandering whether what I want to do (have both serial printout and pins pulsing) is fundamentally impossible with this architecture - or am I just missing something in the setup?

Thanks in advance for any answers,
Cheers!

(Just wanted to note that this Serial class actually operates on a class definition in HardwareSerial.cpp in the Arduino IDE package; and this class defines the reception USART interrupt routines; thought this may be the problem - but again, I used the same approach in ATMega328, where I had seen it work.. )
11  Development / Other Software Development / Re: A "simple" makefile for Arduino on: August 03, 2011, 03:56:22 pm
Hi all,

Just to say that I also posted my version of a Makefile (Makefile_0022_sdaau) on Arduino playground - CommandLine; works on me for Arduino IDE 0022 and Ubuntu 11.04 - should also have some limited handling of libraries, and should save output files in a sketch subdirectory ...

Cheers!
12  Using Arduino / Networking, Protocols, and Devices / Re: WiFly Shield: can't get it work. on: July 17, 2011, 02:24:48 pm
Hi all,

It's stuck on WiFly.begin().

Had exactly the same problem, think I got it fixed - so I thought I'd document my steps.

So, I get a WiFly, and I get the code from GitHub. With the intent to use it on the Arduino MEGA 2560, I resolder D13, D12, D11, D10 on the shield to D52, D50, D51, D53 on the MEGA 2560 as explained in  src/WiFly/README.txt. I copy the folder WiFly-Shield/src/WiFly from the code to arduino-0022/libraries; and I decide to try src/WiFly/examples/tools/SpiUartTerminal.pde... and, I experience the freeze on WiFly.begin().

Well, since the main communication between the Arduino and the WiFly is via SPI, I decide to check the SPI pins on an oscilloscope. I would have expected at least the SCLK clock (D13 on Uno, D52 on Mega) to be shown pulsing - but surprisingly, all of the pins showed DC voltage. Then I thought about trying the default SPI examples in arduino-0022, so I chose SPI/examples/BarometricPressureSensor.pde. Immmediately after building and uploading this sketch, I could see SCLK pulses on D52 on the Mega; so my conclusion was, there must be a problem with the SPI initialization in the WiFly library.

Thus, I began a somewhat tedious process of comparing the default SPI library in the Arduino IDE, and the SPI related parts of the WiFly library. My initial guess was, that the SCLK pulses start immediately after a succesful .begin() has been initiated; however, actual pulses (that I could catch on the scope) usually occur when a .transfer() command executing in the loop(). So I made me a small .pde program, to have the same .begin in setup(), and .transfer in loop() implemented through either library for comparison - and I could realize that, as concluded earlier, .begin() from WiFLy simply never returns - here's the test code I used, called it spi_test_wi.pde:

Code:
// comment/uncomment the define as needed:
#define WIFLY
//#define DFLTSPI

#ifdef DFLTSPI
// from Examples/SPI/BarometricPressureSensor.pde
// the sensor communicates using SPI, so include the library:
#include <SPI.h>

void setup() {

  // start the SPI library:
  SPI.begin();

}
#endif

#ifdef WIFLY
// from Examples/WiFly/WiFly-examples/tools/SpiUartTerminal.pde
#include "WiFly.h" // We use this for the preinstantiated SpiSerial object.

void setup() {

  // start the SPI library:
  SpiSerial.begin();

  // if these functions are made public in SpiUart.h, they
  // will then show pulses in this loop here..
  while(!SpiSerial.uartConnected()){
    SpiSerial.configureUart(9600);
  }

}
#endif

void loop() {
#ifdef DFLTSPI
  SPI.transfer(0x00);
#endif

#ifdef WIFLY
// class SpiUartDevice : public SpiDevice, public Print
// overloads SpiDevice, which has SpiDevice::transfer
  SpiSerial.transfer(0x00); // ok if setup doesn't lock
  ////SpiSerial.writeRegister(LCR, 1 << 7); //private :(
  ////SpiSerial.print(0x00); //ok if setup doesn't lock; big delays
  //SpiSerial.write("hello"); //ok if setup doesn't lock; big delays
  //SpiSerial.configureUart(9600); //private
#endif

  ;
  //asm("nop"); //delay? not much ..
}

So, I decide to look closer in SpiSerial.begin(); - that function eventually calls SpiUartDevice::initUart, where a comment can be read: "// Lock up if we fail to initialise SPI UART bridge.", this lock up being entering a while(1) loop. So, I basically decide to comment this loop in arduino-0022/libraries/WiFly/SpiUart.cpp:

Code:
void SpiUartDevice::initUart(unsigned long baudrate) {
  /*

    Initialise the UART.

    If initialisation fails this method does not return.

   */
  // Initialise and test SC16IS750
  configureUart(baudrate);

  if(!uartConnected()){
    //~ while(1) {
      //~ // Lock up if we fail to initialise SPI UART bridge. <======
    //~ };
  }

  // The SPI UART bridge is now successfully initialised.
}

... and move the running of uartConnected() check in the main .pde code; however, since this function is by default private, it needs to be made public for that - so in arduino-0022/libraries/WiFly/SpiUart.h simply move the uartConnected() and  configureUart() above the private keyword:

Code:
...
    void ioSetState(unsigned char bits);

    void configureUart(unsigned long baudrate);
    boolean uartConnected();
  private:
    void writeRegister(byte registerAddress, byte data);
...

Now, we can go back to the good old SpiUartTerminal.pde; except now we'd need to modify the connection procedure in setup() as such:

Code:
...
  Serial.println("Attempting to connect to SPI UART...");
  SpiSerial.begin(); //hack in SpiUart.cpp so it don't lock
  // hack below: repeat configuration until it passes
  while(!SpiSerial.uartConnected()){
    SpiSerial.configureUart(9600);
  }
  // end hack

  Serial.println("Connected to SPI UART.");
...

Finally, with these changes, I could see SCLK pulses immediately after upload; and of course, the entire connection procedure passed - and I could execute the WiFly commands and connect to a wireless router as described in WiFly Tutorial - Wireless SpeakJet Server - SparkFun Electronics. (Note I had to change my router from WEP 64 bit to WEP 128 bit, as that is the only WEP WiFly supports; and then there is difference between key/passphrase command). Here tested telnet wireless access via  SpiUartTerminal.pde, worked fine.

With this done, I also tried the Examples/WiFly/WiFly-examples/WiFly_WebServer, which samples analog inputs and sends them to a client over wireless - the good thing is that the above SpiUart.cpp hack seems to propagate to the WiFly class as well; unfortunately, I couldn't measure more than 2.7 kByte/sec transfer speed over wireless, even with specifying WiFly.configure(WIFLY_BAUD, 38400);.

In any case, glad I could get this to run - so hope this writeup would be of use to others smiley ,
Cheers!
13  Community / Website and Forum / Re: PinMapping2560 page inaccessible on: July 15, 2011, 12:08:21 pm
Hi retrolefty,

Is there a discrepancy between your pin mapping picture and the arduino reference on user interrupt numbers Vs pin numbers?

Could well be - as I noted, I didn't really go through the ATMega datasheets myself, instead I just copied the data from this Arduino Pins spreadsheet, the link for which I found elsewhere on the web...

It's probably based on the fact that the arduino external interrupt numbers (0-5) have no direct association with the AVR external interrupt names. This is sure to confuse sometimes what mega pins numbers to wire to utilize a given arduino attachinterrupt function. See the below Arduino reference extract for the arduino's assignment of interrupt names (0-5) to mega pin numbers, and see the possiblity of confusion.

Quote
attachInterrupt(interrupt, function, mode)

Description
Specifies a function to call when an external interrupt occurs. Replaces any previous function that was attached to the interrupt. Most Arduino boards have two external interrupts: numbers 0 (on digital pin 2) and 1 (on digital pin 3). The Arduino Mega has an additional four: numbers 2 (pin 21), 3 (pin 20), 4 (pin 19), and 5 (pin 18).

Ok, I see what you mean - I guess that is from Arduino - AttachInterrupt; could be that was written for the ATmega1280, and I copied data for the ATmega2560? Unfortunately, the spreadsheet doesn't say... At least, on the pin map image, digital pins D3, D2, D18, D19, D20, D21 all have "INT" or "ext int" numbers, so at least that is right - but I can see what you mean by the interrupt number confusion..

In any case, if anyone has a suggestion which particular text in the map image I should change, I will eventually do so (I currently do not work with external interrupts, so it may be a while until I figure out possible errors myself)..

Thanks for the feedback,
Cheers!
14  Community / Website and Forum / Re: PinMapping2560 page inaccessible on: July 15, 2011, 11:13:37 am
Ah, well, instead of waiting for a "third party", I used up some hours, and made a "pin map" for both Uno and Mega in Inkscape, please check here:

http://sdaaubckp.svn.sourceforge.net/viewvc/sdaaubckp/xtra/arduino-pinmap/

The images are from the Arduino site, and the data is from this Arduino Pins spreadsheet.

Here is the link to PDF map of MEGA: Mega2560-pin-map.pdf - there are .svg and .png versions in the folder, too - below the .png is shown:



Well, hope this helps someone,
Cheers!
15  Community / Website and Forum / Re: PinMapping2560 page inaccessible on: July 15, 2011, 08:05:46 am
Hi Graynomad,

I get the same. It's either a bad link or not open to the public (can't imagine why and if so the link shouldn't be there in the first place).

Thanks for confirming - hopefully, someone can either open up this link or remove it; otherwise I hope someone will be able to post something "third party" like the ATmega328 image in Arduino Forum - Arduino Mega2560 Pin Names...

Cheers!
Pages: [1] 2 3 4