A new builder

[Federico Fissore]

Hi everyone

I'm happy to announce a new tool. We put our brains together, blended,
and called it "arduino-builder"

It's code is available at https://github.com/arduino/arduino-builder

Our bot is preparing a version of the IDE that bundles it: keep an eye
on https://github.com/arduino/Arduino/pull/3779

Now some details

Following Paul's suggestion of using gcc for preprocessing, we came up
with a mix of
- gcc -M for gathering includes
- gcc -E for preprocessing
- ctags for parsing preprocessed code and list missing prototypes
Everything is carefully mixed and linked in a way that should make it
easy to extend and evolve yet maintaining every concern separated. For
instance, ctags is run by a module, its output is parsed by another

Because it introduces a new tool, ctags, and because it must be used by
every single core, we changed how platform.txt works. You can now have
partial definitions in parent folders: those definition will percolate
down to the actual platform.txt
This allows to have a minimal platform.txt defined under "hardware" [1]
and to have its values copied over any actual platform.txt file.

Also, preprocessing involves calling gcc, and every core has its
specific flags.
Again, in order to avoid asking every core developer to modify every
platform.txt file, we used platform.keys.rewrite.txt. We inject
preprocessing recipes [2] and we added a handful of core specific
variables [3]: if these are not defined, they get cleared.
We tested this behaviour compiling a couple of example sketches using
every single core listed at 3rd party cores wiki page [4]

HOWEVER: core developers, please test this tool; if the good-for-all
preprocessing recipe we made is not so good for you, please provide your
own by defining it in your platform.txt.

Last news is about contributing: this is the first Arduino project using
the Developer Certificate of Origin (you may recall an old thread
talking about CLA and DCO)

Hope this will hit 1.6.6. Our plans may change depending on the feedback
we'll receive.

Regards

Federico

[1]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.txt
[2] note to self: while writing this email I noticed we can now move
"added" keys from platform.keys.rewrite.txt to the minimal platform.txt
described above
[3]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.keys.rewrite.txt#L25
[4]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.keys.rewrite.txt#L25

[Federico Fissore]

Federico Fissore ha scritto il 11/09/2015 alle 14:57:
> [4]
> https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.keys.rewrite.txt#L25
>
>

Sorry, correct url is
https://github.com/arduino/Arduino/wiki/Unofficial-list-of-3rd-party-boards-support-urls

[Federico Fissore]

New builder now included in nightly builds

Should you need ANY advice, have ANY question or doubt, please let me know

Regards

Federico

[q2dg2b .]

Sorry for my so stupid question but, what does this new tool in practice compared to "arduino" terminal command? Thanks

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Paul Stoffregen]

On 09/14/2015 08:20 AM, Federico Fissore wrote:
> New builder now included in nightly builds
>
> Should you need ANY advice, have ANY question or doubt, please let me
> know

Thanks. I plan to take a detailed look at it later this week!

[Federico Fissore]

q2dg2b . ha scritto il 14/09/2015 alle 22:12:
> Sorry for my so stupid question but, what does this new tool in practice
> compared to "arduino" terminal command? Thanks

There are three differences:
1) it has a faster startup, because it's a binary program, with no
dependencies (you don't need a JVM to run it)
2) it does LESS, because it only compiles
3) it doesn't rely on well known folders locations and file names. For
example, you can have "hardware" folders spread around your computer
harddrive: just provide as many "-hardware" parameters for this tool to
read their contents. This gives a finer control over what
"arduino-builder" is using for compiling

The "arduino" terminal command available with the nightly now uses the
arduino-builder under the hood, with all its params properly set up so
to behave just like it used too.

regards

federico

[Federico Fissore]

I've just noticed a nice side effect of arduino builder.

Since we use gcc -M for gathering includes, they CAN be specified even
in companion header files

Suppose you have "sketch.ino" which includes "my_includes.h" and
"my_includes.h" which includes all your libraries.
Arduino builder will find those library includes and add those libraries
paths to subsequent gcc calls

That's NOT resolving library to libraries dependencies but still is a
nice to have

Regards

Federico

[Georgitzikis Vasilis (tzikis)]

Just FYI, this will also break some sketches. If I recall correctly, something like 1 in 3000

Keep in mind, this is based on measurements we took on sketches hosted on codebender about 2 years ago, so this is hugely outdated, but I thought I’d let you know

Vasilis

[Matthijs Kooijman]

Hey Federico,

> That's NOT resolving library to libraries dependencies but still is a nice
> to have

Actually, won't this also solve library-to-library dependencies as well?
I haven't looked at the arduino-builder implementation, but if it does
this incremental "run gcc -M and process the first missing #include"
approach that Paul suggested a while ago, I guess it should also process
recursive includes? Or does it just do a single gcc -M run and then scan
the results for #include lines once?

Gr.

Matthijs

[Federico Fissore]

Yes it does that only once. You're saying to repeat that until all
includes are resolved? Uhm, it can work

[Andrew Kroll]

Recursive is how I suggested long ago as well. Just say'n...

[Paul Stoffregen]

Yes, indeed doing it recursively allows detecting all dependencies.

But there are some subtle points.  Matthijs explained it very well in the comments on #2792.

https://github.com/arduino/Arduino/pull/2792


I see the new building is implement in Go language.  I'm sure there's probably some good reasons, other than Go is the hot new in thing... installing yet another language now....

[Paul Stoffregen]

Federico,

I've started playing with the new builder. Wow, you've been busy!

My first question is whether the numerous "hooks" in 1.6.5-r5 are still
supported. For example, I want to use "hooks.linking.postlink" and
"hooks.postbuild". So far, I can't seem to get either to work with new
builder.

I believe these are the hooks from the old Compiler class:

hooks.prebuild
hooks.sketch.prebuild
hooks.sketch.postbuild
hooks.libraries.prebuild
hooks.libraries.postbuild
hooks.core.prebuild
hooks.core.postbuild
hooks.linking.prelink
hooks.linking.postlink
hooks.objcopy.preobjcopy
hooks.objcopy.postobjcopy
hooks.postbuild

[Federico Fissore]

A new hourly is available: it bundles arduino-builder beta8 which tries
to discover libraries dependencies

by default, it runs gcc -M 4 times, which means 4 nested levels of
dependencies between libraries

sketch -> lib1 -> lib2 -> lib3 -> lib4

http://www.arduino.cc/en/Main/Software#hourly

Regards

Federico

[Georgitzikis Vasilis (tzikis)]

could it try recursively as long as the list of detected libraries keeps changing?

[Federico Fissore]

Paul Stoffregen ha scritto il 18/09/2015 alle 13:53:
> Federico,
>
> I've started playing with the new builder. Wow, you've been busy!
>

I'm glad you like it

> My first question is whether the numerous "hooks" in 1.6.5-r5 are still
> supported. For example, I want to use "hooks.linking.postlink" and
> "hooks.postbuild". So far, I can't seem to get either to work with new
> builder.

Yes they are supported, although the first versions were buggy [1]. They
are working since beta7.

The correct syntaxt for a hook is

recipe.hooks.prebuild.NUMBER.pattern=something

Prefix all the recipes you wronte with "recipe."

Federico

[1] https://github.com/arduino/Arduino/pull/3799

[Federico Fissore]

Georgitzikis Vasilis (tzikis) ha scritto il 18/09/2015 alle 14:15:
> could it try recursively as long as the list of detected libraries keeps changing?
>

that could lead to infinite loops without state control, I didn't want
to put such another entry in the compilation context

If 4 is too low, let's raise it to... 10? Anyway, you can play with it
using CLI param -lib-discovery-recursion-depth

Federico

[Paul Stoffregen]

First, I must confess my platform.txt recipes are rather unconventional....

{runtime.ide.path} doesn't seem to work anymore in recipes.

I also can't seem to get build prefs from my boards.txt file to work in
recipes.

For example, if I have this in my boards.txt:

teensy31.menu.speed.72opt.build.flags.optimize=-O

nothing seems to happen when I use {build.flags.optimize} in recipes.

Even not as a menu option, I can't seem to get build prefs from
boards.txt to substitute into recipes. It definitely worked in 1.6.5.
Does the new builder support this?

[Georgitzikis Vasilis (tzikis)]

well I wasn’t saying that because I think 4 is too low, but i do think the max we ever saw when we used to do it in codebender was 5. i was mostly suggesting a non-static way to do it

the way we did it on codebender (before we removed it to be compatible with the Arduino IDE because some sketches were broken), we just stored the list of detected libraries, and ran it recursively, until the list of detected libraries stopped changing

Vasilis

[Federico Fissore]

Yes
When specifying -fqbn param, make it look like this

pack:arch:teensy31:speed=72opt

Federico

[Paul Stoffregen]

Is "rewriting=disabled" still supported?

I'm getting really strange problems, like something is interfering....

[Federico Fissore]

Paul Stoffregen ha scritto il 18/09/2015 alle 14:47:
> Is "rewriting=disabled" still supported?
>
> I'm getting really strange problems, like something is interfering....
>

Good catch: no, I forgot it. I'm implement it right now

Federico

[Paul Stoffregen]

Ok, I see now it's trying to run recipe.preproc.includes first.

I can't seem to get {runtime.ide.path} to work. Is that still
supported? It seems to be an empty string no matter what I try!

[Paul Stoffregen]

It seems the published platform.txt files uses these two to get the
pathnames to the toolchains:

{runtime.tools.avr-gcc.path}
{runtime.tools.arm-none-eabi-gcc.path}

What is the recommended way to install my own toolchain?

Historically, I've just created my own directory under hardware/tools,
where I copy the toolchain. But Arduino can't provide a special
{runtime.tools.paulstoolchain.path}, because it has no idea about stuff
I've added. So I've been simply using {runtime.ide.path} plus the
relative pathname.

I can't seem to get {runtime.ide.path} to work at all in the new
builder. I do need some way to construct a {compiler.path} that is the
location where I install my customized toolchain.....

[Federico Fissore]

Indeed. arduino-builder knows nothing about the IDE, with the exception
of ide-version, which some libs use to decide what to include

[Federico Fissore]

Paul Stoffregen ha scritto il 18/09/2015 alle 15:25:
> I can't seem to get {runtime.ide.path} to work at all in the new
> builder. I do need some way to construct a {compiler.path} that is the
> location where I install my customized toolchain.....
>

There are two ways

First one (preferred) is to create a folder structure such as
"tools > name of tool > version of tool > every other file"

This is what boards manager does. For example

tools/bossac/1.6-arduino

This will create runtime.tools.bossac.path and runtime.tools.bossac-1.6.path

Second one is to put a builtin_tools_versions.txt file where your tools
are installed. That's what the IDE you download does, because it bundles
the AVR toolchain
You can find that file in IDE/hardware/tools/avr/

Stick with the first one if you can. It's easier to understand and maintain

Federico

[Federico Fissore]

A new hourly bundling the fix has just been published

Federico

[Paul Stoffregen]

> A new hourly bundling the fix has just been published
>
> Federico
>

Awesome. I'll give it another try within the next hour or two.

I got really tripped up on my first attempt by a triple-whammy of
runtime.ide.path no longer working, unexpected recipe rewriting, and
mistakenly believing the cpp rule was running, when in fact the
preprocess rule was being run.

Thanks to your help, I (hopefully) have a much clearer idea what to try
this time! :)

[Matthijs Kooijman]

Hey Federico,

> tools/bossac/1.6-arduino
>
> This will create runtime.tools.bossac.path and runtime.tools.bossac-1.6.path

It seems weird to me that a tool name of "bossac" and version of
"1.6-arduino" result in a "bossac-1.6" name in the variable (dropping
the "-arduino" part). Is some
mangling applied here, or is your example incorrect here?

Gr.

Matthijs

[Federico Fissore]

Incorrect example. It is indeed runtime.tools.bossac-1.6-arduino.path

[Matthijs Kooijman]

Hey Federico,

> >could it try recursively as long as the list of detected libraries keeps changing?
> that could lead to infinite loops without state control, I didn't want to
> put such another entry in the compilation context

I actually think that infinite loops are possible. See
https://github.com/arduino/Arduino/pull/2792#issuecomment-83400324 for
some earlier discussions touching on this subject. I'm not 100% sure
though, so having some kind of limit makes sense?

The above does assume that it only processes *just one* missing include
on every invocation, which I suspect the current code does not do, which
could indeed lead to oscillations in the included file list.

> If 4 is too low, let's raise it to... 10? Anyway, you can play with it using
> CLI param -lib-discovery-recursion-depth

I guess that ideally it would just loop until there are no more changes,
and have a (fairly high) recursion limit just in case it somehow
ininitely loops (which should probably be reported to the user, asking
him to file a bug report?).

Gr.

Matthijs

[Georgitzikis Vasilis (tzikis)]

This would be a great time to split the versions between the Arduino language/SDK, and the IDE

Vasilis

[Federico Fissore]

(disclaimer: I'm not a c++ guy, so be kind if I say b******t)

I've tried an empty sketch with files:
- bar.cpp
#warning bar.cpp
#include "foo.h"
#ifndef FOO
#include "bar.h"
#endif

- foo.h
#define FOO
#warning foo

- bar.h
#warning bar

and it compiles as expected. gcc warns with

/tmp/buildecd22bce3dfe8a36765a66d22512ae58.tmp/sketch/bar.cpp:1:2:
warning: #warning bar.cpp [-Wcpp]
#warning bar.cpp
^
In file included from
/tmp/buildecd22bce3dfe8a36765a66d22512ae58.tmp/sketch/bar.cpp:2:0:
/tmp/buildecd22bce3dfe8a36765a66d22512ae58.tmp/sketch/foo.h:2:2:
warning: #warning foo [-Wcpp]
#warning foo
^

which is expected

I've also tried with an empty sketch including a fake library MyLib
- MyLib.h
#include "foo.h"

- foo.h
#include "bar.h"

- bar.h
#include "foo.h"

gcc crashes with

In file included from /home/federico/Arduino/libraries/MyLib/foo.h:1:0,
from /home/federico/Arduino/libraries/MyLib/bar.h:1,
from /home/federico/Arduino/libraries/MyLib/foo.h:1,
from /home/federico/Arduino/libraries/MyLib/bar.h:1,
from /home/federico/Arduino/libraries/MyLib/foo.h:1,
from /home/federico/Arduino/libraries/MyLib/bar.h:1,
[...]
from /home/federico/Arduino/libraries/MyLib/foo.h:1,
from /home/federico/Arduino/libraries/MyLib/bar.h:1,
from /home/federico/Arduino/libraries/MyLib/foo.h:1,
from /home/federico/Arduino/libraries/MyLib/MyLib.h:2,
from sketch_sep21a.ino:1:
/home/federico/Arduino/libraries/MyLib/bar.h:1:17: error: #include
nested too deeply
#include "foo.h"

which is again expected

Not sure if all this assures you

[Paul Stoffregen]

I'm continuing to work with the new builder. Things are going much
better, thanks to your help last week.

My latest trouble is the extra time stuff doesn't seem to be working.
Here's the code that was in 1.6.5-r5.

https://github.com/arduino/Arduino/blob/1.6.5-r5/arduino-core/src/processing/app/debug/Compiler.java#L587

I need these for automatic RTC date/time setting....

[Paul Stoffregen]

It doesn't seem to discover library dependencies, even though #2792 was
closed.

For example, this doesn't compile:

#include <SD.h>
void setup() { }
void loop() { }

The builder seems to be just running the gcc -M four times on the
sketch, but never on libraries. It also seems to be picking up more
than 1 new include path per run, which will lead to subtle failures with
headers using conditional compilation.

To work properly, it really needs to be run in a nested pair of loops
similar to #2792:

https://github.com/arduino/Arduino/pull/2792/files#diff-9cd90eab2dcf151a63c144aff0e043b9R363

The outer loop needs build a list of all known locations. Then the
inner loop must run gcc -M on every .cpp, .c and .S file in every
location (except there's little point to doing this on the core library
files). If new locations are discovered, only the first discovered
location is added to the list. Any others are ignored, and the outer
loop is restarted. This process repeats until a run of the inner loop
discovers no new locations.

As I implemented in the #2792 pull request and Matthijs explained in the
comments, this iterative process where only the first new location is
added to the list and the process restarted is critically important.

Missing support for {extra.time.utc} and {extra.time.local} are also
causing me some pain....

[Federico Fissore]

Paul Stoffregen ha scritto il 22/09/2015 alle 14:58:
> It doesn't seem to discover library dependencies, even though #2792 was
> closed.
>
> For example, this doesn't compile:
>
> #include <SD.h>
> void setup() { }
> void loop() { }

It ends with this error

[...]/libraries/SD/src/utility/Sd2Card.cpp:26:17: fatal error: SPI.h: No
such file or directory

SPI is included by a .cpp, not by one of the files included from the
sketch (SD.h down to Sd2Card.h)

gcc -M is run starting from the sketch and not looking into every file
of every library

This is a known limitation. Can this be solved (in case of SD) by moving
the include into Sd2Card.h ?

>
> As I implemented in the #2792 pull request and Matthijs explained in the
> comments, this iterative process where only the first new location is
> added to the list and the process restarted is critically important.
>

I'm trying to avoid running gcc -M for every single source file found.
It could mean running it tens of times, slowing everything down.

> Missing support for {extra.time.utc} and {extra.time.local} are also
> causing me some pain....

Ah I missed those too. Adding them right now

Federico

[Paul Stoffregen]

On 09/22/2015 06:19 AM, Federico Fissore wrote:
>
> I'm trying to avoid running gcc -M for every single source file found.
> It could mean running it tens of times, slowing everything down.

This can and should be done. There really isn't any other 100% reliable
way to solve this library dependency detection issue!

First, gcc -M is very fast.

But if speed is a concern, the results can be stored and reused if the
file modification time is older than the stored result, as is currently
done for the .o files.

[Paul Stoffregen]

On 09/22/2015 06:19 AM, Federico Fissore wrote:

> Can this be solved (in case of SD) by moving the include into Sd2Card.h ?

Tried that here. It does indeed fix SD for the current builder program.

[Federico Fissore]

Added in beta11

https://github.com/arduino/arduino-builder/releases

IDE Hourly is on the way

Federico

[Paul Stoffregen]

On 09/22/2015 07:48 AM, Federico Fissore wrote:
>
> Added in beta11

It's working much better now! :)

I am seeing differences in handling of duplicate libraries. It doesn't
seem to apply the same rules as Arduino 1.6.5 to decide which libraries
to use when there's a conflict. This isn't a failure, but merely
different behavior than prior Arduino IDEs.

I'm also seeing the duplicate message when a package overrides a
built-in library. Previously the duplicate detection didn't consider
this case to be a duplicate. For example, my package installs a custom
copies of SD and Ethernet, which have extra code for specialized
hardware (which can't be fully supported by only overriding SPI).
Hopefully the intention is still to allow packages to gracefully
override the built-in libraries?

[Federico Fissore]

Yes of course

That duplicate message is due to the builder not filtering out
libraries. As long as the result is the expected one, it's fine.

I'll double check which algorithm the old code implemented and see how I
can improve the code

federico

[Paolo Paolucci]

Why not jump to 1.7.0?

With the introduction of Arduino-builder and modifying the file platform.txt breaks the continuity with the previous release. I think it's cause for a new major version.

What do you think?

Translated by google :-/

Il giorno venerdì 11 settembre 2015 14:57:19 UTC+2, f.fissore ha scritto:

Hi everyone

I'm happy to announce a new tool. We put our brains together, blended,
and called it "arduino-builder"

It's code is available at https://github.com/arduino/arduino-builder

Our bot is preparing a version of the IDE that bundles it: keep an eye
on https://github.com/arduino/Arduino/pull/3779

Now some details

Following Paul's suggestion of using gcc for preprocessing, we came up
with a mix of
- gcc -M for gathering includes
- gcc -E for preprocessing
- ctags for parsing preprocessed code and list missing prototypes
Everything is carefully mixed and linked in a way that should make it
easy to extend and evolve yet maintaining every concern separated. For
instance, ctags is run by a module, its output is parsed by another

Because it introduces a new tool, ctags, and because it must be used by
every single core, we changed how platform.txt works. You can now have
partial definitions in parent folders: those definition will percolate
down to the actual platform.txt
This allows to have a minimal platform.txt defined under "hardware" [1]
and to have its values copied over any actual platform.txt file.

Also, preprocessing involves calling gcc, and every core has its
specific flags.
Again, in order to avoid asking every core developer to modify every
platform.txt file, we used platform.keys.rewrite.txt. We inject
preprocessing recipes [2] and we added a handful of core specific
variables [3]: if these are not defined, they get cleared.
We tested this behaviour compiling a couple of example sketches using
every single core listed at 3rd party cores wiki page [4]

HOWEVER: core developers, please test this tool; if the good-for-all
preprocessing recipe we made is not so good for you, please provide your
own by defining it in your platform.txt.

Last news is about contributing: this is the first Arduino project using
the Developer Certificate of Origin (you may recall an old thread
talking about CLA and DCO)

Hope this will hit 1.6.6. Our plans may change depending on the feedback
we'll receive.

Regards

Federico

[1]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.txt
[2] note to self: while writing this email I noticed we can now move
"added" keys from platform.keys.rewrite.txt to the minimal platform.txt
described above
[3]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.keys.rewrite.txt#L25
[4]
https://github.com/arduino/arduino-builder/blob/master/src/arduino.cc/builder/hardware/platform.keys.rewrite.txt#L25

[Federico Fissore]

It doesn't break anything, at least I'm not aware of any breaks.
Actually it fixes a lot of things

Federico

[Paul Stoffregen]

Strict semantic versioning (Major.Minor.Patch) would probably dictate most Arduino releases incrementing the Minor number (due to new but backwards-compatible functionality), and releases like "1.6.5-r5" incrementing the Patch number rather than appending a suffix.

I personally don't care about the major or minor version numbers.  But I would like to mention the difficulty in helping end users caused by the additional suffix.  It leads to a lot of end-user confusion.  When a novice has 1.6.5-r2 installed (which itself is hard to figure out, since "-r2" isn't shown in Help > About), explaining they need to upgrade to 1.6.5-r5 is difficult.  Many people see only "1.6.5" and do not understand (or believe) even the most simply and strongly worded instructions to update to the latest version.

--

[Cristian Maglie]

Il 30/09/2015 11:33, Paul Stoffregen ha scritto:
> additional suffix. It leads to a lot of end-user confusion. When a
> novice has 1.6.5-r2 installed (which itself is hard to figure out, since
> "-r2" isn't shown in Help > About), explaining they need to upgrade to
> 1.6.5-r5 is difficult. Many people see only "1.6.5" and do not
> understand (or believe) even the most simply and strongly worded
> instructions to update to the latest version.

The reason for the suffix is that between the various -rX the only
changes are mostly on how the software is packaged (signature for Mac,
drivers installed on Windows, etc.).

But I see your point the suffix has less visibility compared to the
patch level (I see now that also the download page doesn't show the -r5
but only 1.6.5), so maybe even the smallest change deserves an update to
the patch level anyway. Will consider this for the future.

C

[tzi...@gmail.com]

And keep in mind, even though the new builder doesn't change the APIs, the build process does change, resulting in a different SDK, and breaking some (small number) of sketches.

If I'm not mistaken, that (breaking backwards compatibility) constitutes a major change in semantic versioning

Vasilis

[Federico Fissore]

Can you point me to some of these sketches? We aim at zero b0rkage as
much as we can

Federico

[Georgitzikis Vasilis (tzikis)]

We’d have to test specifically, so it would take time. What I do know is that we used to do smart library recognition/linking in codebender, and changed to the way the Arduino 1.0.x works for maximum compatibility.

When we did, we had ~20K sketches hosted on codebender, with something like 12K unique ones. Roughly 30 broke, and another 30 were fixed by that change.

Vasilis

[Federico Fissore]

I'm happy to say that now library to library dependencies resolution
should work for real.

Paired to the first implementation, now for every found library, gcc -M
is executed using .c and .cpp as targets. This allows the sketch above
to compile flawlessly

Thanks everyone for your suggestions :)

Regards

Federico

[Andrew Kroll]

I don't have time at the moment, hardly have time to do this quick email, could you please verify it can compile the UHS 3.0 file storage demo?

The library uses some really tangled tricks to get around the old IDE includes, and it would be nice to know if it can operate untouched. URL is https://github.com/felis/UHS30

Thanks!

Federico

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Federico Fissore]

Tried a couple and they fail with

In file included from
/tmp/arduino_3079b7b4f7dbb39d7cd277a5220c9c33/KINETIS_DEV_DESC.ino:33:0:
/home/federico/Arduino2/libraries/UHS_KINETIS_FS_HOST/UHS_KINETIS_FS_HOST.h:23:2:
error: #error include dyn_swi.h first
#error include dyn_swi.h first

Tried adding the include to the sketch and to UHS_KINETIS_FS_HOST.h but
keeps on failing

Federico

[Andrew Kroll]

Kinetis is teensy 3.[01] and 3LC, just interested in the max chip for avrs/due.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.