mrburnette:
bperrybap:
Just ordered a Sleeping Beauty.
I'll be using it to test out my openGLCD library on several different IDEs, including pre 1.0 and 1.5.x
So Jack, I'll be joining you and others over in your 1284p core thread, as soon as I get the board in.--- bill
Bill, et al:
Is it feasible to run pre-1.0 on the 1284? We are having a discussion over on the 1284 side about 1.0.5r2 and 1.5.x as to where the effort should be places first. Nothing has been mentioned about pre-1.0 builds.
I must plead ignorance to the size of the pre-1.0 community that is still active.
Feasible? That may depend on your views. Different peoples view of what is feasible vary.
Possible? Yes - but with caveats.
Currently I test my library on about 10 different IDE versions, including versions with Teensy add ons
and chipKit versions, on Linux and Windows. So I see quite a bit of the issues
that crop up with respect to different IDE versions.
I would say trying to support pre 0019 is very difficult and not worth it as there
were some major changes in the core functionality at that point.
Some of the issues relate to things the Arduino team developers did in the core
files like improper header file include order, or attempting to outsmart the compiler
in attempt to gain performance - this would be the macros that re-define many of the
math functions. These types of things can and do break.
The linux users tend to be biggest victims of this as pre 1.0.3 the avr-gcc tools were not
included with the IDE so the linux users could end up with newer compiler tools than
than the Windows users. There are issues with the pre 1.x (I think even 1.0 has the issue)
and the newer gcc tools.
Most of these can be worked around, but it sometimes requires the user to patch
a core header file to fix the problem.
In the case of a 1284p core, most of the problems should be able to be fixed in the 1284p core files.
There are also some features that can be backported. For example, the F() macro.
My library will add F() support when using my library as it detects the environment in use
and adds the capability in if it is missing. Since I'm only adding support to my library files,
it only works with my openGLCD functions, vs if it were done in the core it would
work for all users of the Print class.
The main reason that I support pre 1.x at this point is that the chipKit stuff
has not fully upgraded their core to 1.0 and even when they do I doubt that they will
decide to break things like the Arduino team has done.
i.e. They will take measures just like Paul did in his Teensyduino core to ensure that most of the pre 1.x libraries
still continue to work with the post 1.0 IDE tools.
Having dealt with the compatibility issues across many of the IDES, I don't think it would be that big of a
deal to support 0022 and 0023 if that is desirable.
(Although I admit, I've not worked with any of communications and IP layer stuff - so I don't know
what issues lurk there)
In terms of the 1.x vs 1.5x support.
I'm not sure what the current state of that is. I know about 9+ months ago there
were some heated discussions on the developers list, about the new core & library "format".
After a long discussion, I think the Arduino team (at least the ones that matter) reached
an epiphany and realized the importance of not breaking compatibility with existing libraries and cores.
This was a major change from their thinking that lead to the 1.0 library debacle and was a HUGE
win for everyone. Prior to that, it was looking like there was going to be 1.0 library situation
all over again in that 100% of existing libraries would have had to be modified to work with the newer 1.5x IDE.
I haven't looked recently at the 1.5x core and library issues, since existing 1.0 libraries can now work "as is",
but my take is that things kind of went on hold or at least on the back burner
and that there are still desired changes that will start dropping in at some point.
My suggestion at this point would be target 1.x first, then move it over to 1.5x
and maybe the changes are simple enough that a single package can be created
that supports both.
--- bill