Libraries not working on Due

[JakeWhelchel]

So I haven't been able to find anything on this, but is there a particular reason when using the IDE that works with the Due, and then the Due board, i get errors all over the place when trying to use certain libraries (generally third party libraries)

So is there some kind of method that changes in the way that the IDE and board run things compared to the default IDE ?

Also if there is a difference, is there any ways to , for instance, alter the library to run properly? I've got a Due that can't seem to work with any electronic components i want to use it with XD

[MorganS]

Remember the Due has a totally different processor inside. Assumptions which work on every other Arduino don't work on the Due.

I just recently converted a library for a TFT screen which was using direct port manipulation. Fortunately it had some #defines up the top that were for the MEGA and UNO, so I was able to add the appropriate code for the Due - just using ditigalWrite() instead of port manipulation.

If you stick to the basic Arduino framework functions like delay() and attachInterrupt() then your program will be quite portable. Unfortunately it seems a lot of library designers don't do it that way.

What particular libraries or components? There are probably Due versions available elsewhere.

[pjrc]

Unfortunately it seems a lot of library designers don't do it that way.

Indeed.  I'm very familiar with this, because I've ported many of the widely used libraries to Teensy 3.1.  Many of them access AVR timers, port registers, the SPI registers, and other hardware stuff.  Porting them is a lot of work!

In a great number of cases, it's really not the library author's fault.  Arduino simply doesn't provide functions for important features many libraries require.

For example, IRremote, VirtualWire, NewPing, SoftPWM and others require one of the timers to run an interrupt function at a regular interval.  The timing is much too fast to depend on regular calls from loop().  Arduino has never provided anything like attachInterrupt() for timers.  As a result, library authors who require an interrupt on a regular (short) interval have no choice but to access the hardware.

[bobcousins]

As a result, library authors who require an interrupt on a regular (short) interval have no choice but to access the hardware.

Not really, they could have written a library to encapsulate the timer function. It would only have taken one person to do that.

The fact is, a lot of firmware authors like to access the hardware directly, thinking it is the "best way" to write embedded code. Sadly, bare metal coding is regarded as "cool", but coding for portability isn't.

[robtillaart]

The fact is, a lot of firmware authors like to access the hardware directly, thinking it is the "best way" to write embedded code. Sadly, bare metal coding is regarded as "cool", but coding for portability isn't.

I've written some libraries and participated in several others. I have always three goals in mind:
1) get the functionality right
2) optimize footprint              - having more memory for application
3) optimize performance         - having more cpu cycles for the other functionality

The latter two often imply - direct port manipulation, code tricks, assembly etc. - which are not portable.

And yes, I think it is fun if I can get footprint down and/or speed up.