guymc wrote:This sounds like a great idea. So I asked a few of our run-time engineers to take a closer look.
Turns out there may be complications with PPS mapping on MX1,2 devices, and with pull-ups for Change Notification pins. These concerns might be resolvable, but there is also a third issue. A new I/O architecture is under development that is definitely not compatible with this proposal. In the interest of compatibility across board variants, I donâ€™t think we can implement this macro in the core system.
Nevertheless, thank you for taking the time to write up a clear explanation of how it could work. That's useful info for those of us with limited C preprocessor (cpp) experience.
I'm following what you are saying.
You can wrap CPP macros on top of anything.
There should be no compatiblity issue with respect to variants
the macros just have to smart enough to deal with things.
I have a set of macros that are thousands of lines long that I use on AVR
to do raw port i/o. They automatically determine if bits are adjacent
on ports and can do multi bit i/o.
In my openGLCD library I have layers and layers of macros
that make decisions based on all kinds of information, including
board types, which in some cases has to be determined by looking
at analog to digital pin mappings from other macros down in the variant files.
(Arduino IDE does not tell you which board the code is being compiled for)
All of this is done at compile time with help from lots of cpp macros.
The key is macros need to be very high up if not on top
of the API rather than down in the middle of a design.
My suggestion is that anybody involved with defining a i/o architecture
will need to be VERY proficient at CPP.
The reason being is that as much as possible needs to be done at compile time
vs run time to get the performance up.
There will have to be trade offs between what can be done at compile time
vs run time given the API.
But often you gain significant advantages when taking of advantage of
capabilites of CPP and using smart macros.
There are also some things that can be done in C++ that can really help,
but then you can't use it in regular C code.
For me, one thing that is needed that is missing from the existing Arduino i/o
API is multi bit i/o.
the abilty to set/read multiple i/o pins with a single API call.
This allows the underlying code to optimize the i/o to reduce the number
of register operation and dramatically speed up the i/o process.
For an example of what I'm talking about see my avrio header file:
http://code.google.com/p/mcu-io/source/ ... io/avrio.h