DigitalWriteFast library for Uno32?

rasmadrak
Posts: 218
Joined: Mon Aug 15, 2011 9:21 pm
Location: Sweden
Contact:

Re: DigitalWriteFast library for Uno32?

Post by rasmadrak » Tue Feb 21, 2012 10:40 pm

You're the man! :)

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: DigitalWriteFast library for Uno32?

Post by bperrybap » Tue Oct 15, 2013 2:01 am

ok,
So I know this thread is old, but I'm just getting around to needing
fast i/o on the pic32 for my glcd library and all the digitalWriteFast()/digitalReadFast() stuff
annoys the !@#!@# out of me not to mention it is pain to deal with.
So let me explain further about not needing to go
down the digitalXXXFast() path again.

While I believe that a better more integrated solution should be supplied with the
IDE for a "it just works" out of the box experience, even when implementing
faster i/o by using the simple wrapper macros in a header file
like several of the FastDigital header files are doing, there is simply
no need to create a new/alternate API for the faster i/o.
The way C macro expansion works, you can use the exact name for the macro
wrapper as the name of the function it is wrapping.
This feature is specifically mentioned in the cpp
documenation. This allows you to wrap a function without the calling code
ever having to know about it.
It is one of the many subtle behaviors of cpp that often comes in handy.
I use it quite often.
So for example,
a tweak from the FastDigital.h header
works perfectly:

Code: Select all

#define digitalWrite(P, V) \
do {								\
    if (__builtin_constant_p(P) && __builtin_constant_p(V)) {		\
	if (V) {							\
	    *(_dpin_to_set_macro(P)) = _dpin_to_bitmask_macro(P);	\
	} else {							\
	    *(_dpin_to_clr_macro(P))  = _dpin_to_bitmask_macro(P);	\
	}								\
    } else  digitalWrite((P), (V));					\
}while (0)
Because of the way cpp works, it does not cause macro recursion.
In the above example,
the calling code will get the macro instead of the function
and the macro can then call the real digitalWrite() when necessary.
Defined this way instead, the user simply includes the FastDigital header and does
not have to modify his code.

--- bill

guymc
Posts: 98
Joined: Mon Sep 24, 2012 3:24 pm

Re: DigitalWriteFast library for Uno32?

Post by guymc » Thu Oct 17, 2013 1:40 am

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.

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: DigitalWriteFast library for Uno32?

Post by bperrybap » Thu Oct 17, 2013 2:53 am

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.
Huh?
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.
i.e.
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

--- bill

ricklon
Posts: 178
Joined: Sun May 22, 2011 6:59 am

Re: DigitalWriteFast library for Uno32?

Post by ricklon » Mon Oct 21, 2013 11:15 pm

If anyone would like to combine this into a 3rd party library on github. I could include it in the next build of MPIDE.

Let me know if there is an issue getting the code into Github. I can help with that.

-Rick

bperrybap
Posts: 48
Joined: Sat Nov 19, 2011 8:45 pm

Re: DigitalWriteFast library for Uno32?

Post by bperrybap » Tue Oct 22, 2013 12:41 am

Were you refreing to DigitalFast?
or the avrio stuff I've done?

When is the next build?

In the big picture, I still believe that the
digitalXXXfast() API is the wrong way to go.
I stronly believe that should be transparaent
to the actual user sketch code vs being a new API.

If it were to be handled as a 3rd party library, then
I believe that the user simply includes a header file,
and his existing code with no modifications,
continues to work, using the existing digitalWrite()/digitalRead() API,
but the code gets faster if certain parameters are constants.

i.e. the header file just creates wrapper macros that sit
on top of the existing API as I mentioned earlier.

The reason I ask about timing for the next release,
is that while I'm willing to do it,
I've still got a bunch of stuff on my plate to get my openGLCD library
pushed out.

As far as actual implemenation goes, there are some open items
like does the implemenation have to work for both C and C++?

Also, it would get much easier to do and maintain if there could be a
slightly different declaration in the Board_Data.c files to allow
turning on/off a static declaration so that the code could pull the data
from the actual IDE supplied pin data tables vs having to create and maintain
parallel tables in macros.

And if we are talking about going that far for integration, why not
just include it into the core code and be done with it so all sketches
benefit from the additional performance when paramters allow it?

--- bill

Post Reply