Access to T1,T3 and T4 inputs on Mega 1280, etc.

For God's sake, please consider at least bringing these unique I/O connections to an internal pad where we can solder a connection, if needed. As it stand now, only T5, the counter input to Timer 5 is brought to a pin. Some of us do want to do things like count fast events and the current PCB layout really cripples this capability.

Wayne

Why not get one of the more evolved derivatives?

Like the 'Seeeduino Mega' or 'Iteaduino MEGA 2560'.

madworm:
Why not get one of the more evolved derivatives?

Like the 'Seeeduino Mega' or 'Iteaduino MEGA 2560'.

My goal was to write a library that might be useful to others. But, if it's only going to be usable on a narrow set of Ardunio variants, why bother... Frankly, it just boggles my mind that these pins would be omitted from the pin out. I can see omitting them if they were just another set of digital I/O pins like PL6, PL7 and PJ7, but they're not. In fact, why someone would choose to provide connections to PL6, PL7 and PJ7 rather than T1, T3 and T4 is doubly mind boggling...

Wayne

mind boggling...

I thought the same when I first looked into the Mega design, I still do. Also IIRC some of the external interrupts are not broken out.

I can see omitting them if they were just another set of digital I/O pins like PL6, PL7 and PJ7, but they're not.

Exactly, given that the "normal" GPIO is software mapped to whatever pin you like, why not give you something that you can use as both GPIO and another function.

I haven't analysed the PCB design but this sort of thing often happens because it's easier to run the traces, when another 2 hours of thought would produce a better design. Given that the Mega board is swimming with spare real estate one would hope that wasn't the reason here.

I'm looking forward to the Due, it has a more complex pinout and it will be interesting to see if some useful functions will be dropped, I2S for example.


Rob

wholder:
My goal was to write a library that might be useful to others. But, if it's only going to be usable on a narrow set of Ardunio variants, why bother...

I've hit similar issues with a couple libraries I've published. Usually I just use #define in a header, and in the web-based documentation I only document the default setting. But if anyone looks in the header, I have commented out the other possible timers. Occasionally I get emails from people asking if I can add lines for the other on-chip timers. Of course, it's impossible since those pins don't have numbers assigned and can't be accessed, at least not without extremely difficult soldering.

For example, in AltSoftSerial AltSoftSerial Library, for an extra serial port

// Arduino Mega
//
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)

 //#define ALTSS_USE_TIMER4
 //#define INPUT_CAPTURE_PIN            49 // receive
 //#define OUTPUT_COMPARE_A_PIN          6 // transmit
 //#define OUTPUT_COMPARE_B_PIN          7 // unusable PWM
 //#define OUTPUT_COMPARE_C_PIN          8 // unusable PWM

 #define ALTSS_USE_TIMER5
 #define INPUT_CAPTURE_PIN              48 // receive
 #define OUTPUT_COMPARE_A_PIN           46 // transmit
 #define OUTPUT_COMPARE_B_PIN           45 // unusable PWM
 #define OUTPUT_COMPARE_C_PIN           44 // unusable PWM

In FreqCount FreqCount Library, for Measuring Frequencies in the 1 kHz to 5 MHz Range

// Arduino Mega
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  // #define COUNTER_USE_TIMER1 // T1 is not connected
  // #define COUNTER_USE_TIMER3 // T3 is not connected
  // #define COUNTER_USE_TIMER4 // T4 is not connected
  #define COUNTER_USE_TIMER5    // T5 is pin 47
  #define TIMER_USE_TIMER2

In FreqMeasure FreqMeasure Library, for Measuring Frequencies in the 0.1 to 1000 Hz range, or RPM Tachometer Applications

// Arduino Mega
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  // #define CAPTURE_USE_TIMER1    // ICP1 is not connected
  // #define CAPTURE_USE_TIMER3    // ICP3 is not connected
  #define CAPTURE_USE_TIMER4       // ICP4 is pin 49
  // #define CAPTURE_USE_TIMER5    // ICP5 is pin 48

I can see omitting them if they were just another set of digital I/O pins ... but they're not.

I can see it as in the best interests of Arduino that the use of special purpose functions of particular pins on particular variations of particular Arduinos be discouraged.

Look at the mess that accompanied the release of ethernet on Arduino. The original shield used the built-in SPI hardware, which it "knew" were on pins 11-13. Then MEGA was released and this was no longer true. So there was a new shield created that moved SPI to the ISP connector, where both Uno and MEGA had the appropriate connections (but not ALL AVRs, and certainly not all possible interesting CPUs.) (and instantly making the ISP connector part of the "fixed physical API" of an Arduino board, breaking several "enhanced" versions from other vendors.) (Ewww!)

Likewise, it's preferred to use digitalWrite() rather than direct port IO, even if you're using multiple bits. Portability and standardization. (Sigh.)

I guess the target demographic for Arduino was (is?) less technical people who wouldn't know JTAG from JAG. I've no problem with that, I think it's done a great service to the geek world.

on pins 11-13. Then MEGA was released and this was no longer true.

Why did they break this? With a quick look at the schematic there's no obvious reason the SPI could not have been run to D11-13. Although originally there's a PWM output on 11 and I guess they wanted all PWMs in a contiguous block. It also make sense to separate the SPI functionality I suppose. There often does come a time when you have to break a few things to get a better result.

Portability and standardization. (Sigh.)

There are obvious advantages to this, that's why there are 500-odd shields around. The trouble comes when you start with a 28-pin processor then grow to a 100 pin version with more features. You pretty much have to dumb down the new board and there will always be incompatibilities that cannot be reconciled.

Which brings me to the new Due. Will that be dumded down as well? Will we lose 4-bit SD and I2S because it wasn't on the Duemilanove or because they don't fit on the current header pinout? Will external memory be supported or is "50k more than anyone should need". And what about when the Due 2 comes out with a processor that has native HDMI?

The Arduino headers are essentially a bus and I guess this sort of issue has been a problem ever since 98% of the IO peripherals were stuck inside the processors. In the days of IO/memory-mapped UARTs etc all you had to do was provide address, data and control signal then add features later. All processors had these signals and the only real difference was the Motorola/Intel/Zilog style control lines and these could usually be standardised with a few gates IIRC.

I think it's more difficult these days, and I'm hanging out to see how they handle these issues with the Due.


Rob

I think it's more difficult these days

Yes, it's a "hard" problem. More so because most of the user community doesn't really understand WHY it's a hard problem (and don't notice that it is.) So I occasionally try to explain...

The same sort of issues have to make IC vendors somewhat unenthusiastic about Arduino. Occasionally I wonder why there aren't a large number of Arduino-compatible boards and IDE extensions from the chip people. (the way there are linux samples for that class of CPUs.) And then I remember that Arduino HIDES the things that the chip vendors really want to show off...

westfw:
I can see it as in the best interests of Arduino that the use of special purpose functions of particular pins on particular variations of particular Arduinos be discouraged.

Does that mean I should not have written those 3 libraries?

Many people have used them in their projects.

Especially AltSoftSerial has made a lot of people's projects "magically work" in cases where SoftwareSerial / NewSoftSerial caused trouble with simultaneous data on HardwareSerial or other libraries. AltSoftSerial can offer low interrupt latency (less interference with other functions using interupts) only because it uses the special timer input capture and output compare waveform generation features.

Does that mean I should not have written those 3 libraries?

No, of course it doesn't mean that. "The best interests of Arduino" do not necessarily match "the interests of some subset of Arduino users", and the latter deserve to be served as well. It's a strength of Arduino that this is possible (As a counter-example, if you step outside the box on a BASIC Stamp or similar, and you're screwed) But that doesn't mean that you'll get official agreement that T1/T3/T4 should have been accessible...

westfw:
But that doesn't mean that you'll get official agreement that T1/T3/T4 should have been accessible...

Maybe not, but I would absolutely agree with wholder's original post. It's a shame those pins weren't at least brought to pads within the large interior space of the Mega, and assigned higher pin numbers, so they could at least be used.

It is a strength of Arduino that hardware can be utilized. But in this case, with 4 on-chip 16 bit timers, only 2 of them have ICP pins exposed and only one has the clock input pin exposed. You can't actually use those other timers for these hardware functions, much like a Basic Stamp, due to design decisions made in the board layout and pin assignments.

I believe that's really unfortunate.

But that doesn't mean that you'll get official agreement that T1/T3/T4 should have been accessible...

I hate to sound harsh, but don't the makers of "closed" hardware make just those source of arguments about what kinds of uses are "permissible" with their hardware? I would certainly hope that Arduino not become closed to certain uses and applications just because someone feels that Arduino is only really intended for a certain target audience build "permissible" sorts of projects...

Come, on is it really that hard to at least makes these extra functions available in some form that doesn't require micro soldering skills just to make an electrical connection? Are these digital pins so extraordinarily dangerous that we must make sure novice users cannot get access to them?

Wayne

Well it was noted by the forum community when the first mega1280 board was released that there were 16 I/O pins not exposed to PCB traces or pads. But being a open source project, another vendor, Seeeduino, built their version of the mega1280 board that went ahead and brought those pins to a added header connector. So for those that want to utilize such pins there is a path to proceed without having to build your own board, but you will have to supply your own software functions in some cases to support using those added pins.

To suggest that the arduino team must meet all requirements to all users in all their products is somewhat unrealistic, there are always trade-offs to be made for any engineering effort. At least the open source nature of the arduino platform allows SOMEONE to proceed if they so wish as there are no proprietary, trade secrets, or closed source code to prevent improvements.

I have several issues with most of the arduino boards such as the auto voltage selection design, auto-reset design, shield connector spacing, and that is just on the hardware side. But none of these things are show stoppers that can't be worked around or eliminated by selecting another vendor's version of a compatible design. The easy part is finding faults with others decisions, but that need not stop progress for users. It's not like you need permission to change anything you have the ability to change.

Lefty

But that doesn't mean that you'll get official agreement that T1/T3/T4 should have been accessible...

I hate to sound harsh, but don't the makers of "closed" hardware make just those source of arguments about what kinds of uses are "permissible" with their hardware?

I think you're reading too much into my words. You probably also won't get a strong statement of "yes, we left those unconnected intentionally because we don't want people using the timers for other than their official purpose!" It'd probably be more along the lines of "oh. We didn't think anyone was using that feature, so we focused on getting more PWMs and analog inputs out..." (I think this is the first thread I've seen complaining about these particular pins being missing, for example.)

And the big difference in this case is that you can download the schematics and pcb design, add the extra pads (or replace other pads) yourself. I don't think it will be as easy as you think; given the design rules that they're using, it's pretty hard to find space for anything as big as am extra pad. The MEGA board doesn't have a bunch of empty area; it's got areas that are covered with TRACES.

OTOH, it's clearly possible, since Seeed has done it...

westfw:
I don't think it will be as easy as you think; given the design rules that they're using, it's pretty hard to find space for anything as big as am extra pad. The MEGA board doesn't have a bunch of empty area; it's got areas that are covered with TRACES.

OTOH, it's clearly possible, since Seeed has done it...

Actually, as your own OTOH points out, there's plenty of room on the Mega 1280 board for lots of new pads and traces. This is especially true considering that the Seeed board brings all the traces to pads on a PCB that's significantly smaller.

But, I don't want to get into an argument here. I would simply like to put forward the proposal (humble request) that, henceforth, pins not be sacrificed in this fashion on new Ardiuno designs. I don't know who decides these things, but it would be really great if they could consider trying to go the extra mile and leave no pins behind!

Wayne