Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Arduino

To your last point, you’re not annoying me. :). The Arduino CDT is fully function except for a few areas so I’m almost done with it except for bugs. The great news is that it’s been instrumental in proving out the new CDT build, launch bar, and the IRemoteConnection architectures including it’s Command Shell Console over CDT’s new serial port library that I use for the serial monitor. I’m glad I did it and am quite proud of it and sets a great direction for CDT. I’ll be blogging about it soon.

As mentioned I will continue with it and will accept patches (using our official channel on Gerrit) for it, assuming the patches comply with the architecture and are IP clean. Feel free to take what ever code I’ve written as long as you comply with the EPL license it’s under. You can probably keep the extra things you mentioned and make that the value add for your plug-in. I’m really only focused on build and launch and the serial port I/O.

I do have a lot of other things I need to work on, like proper ESP8266 support and Raspberry Pi and Qt and need to get going on those so will have less time for the Arduino CDT going forward.

Doug.

From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jan Baeyens <jan@xxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Thursday, August 27, 2015 at 11:12 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Arduino

Sorry for the lengthy answer.

1; OK but that is really simple to fix by placing this info in the platform.txt file. Besides there is a fix needed in this area on windows in regards to due and zero due to the use of defines with spaces making a double quote problem.

2: First of all. I'm not fond of the ino format. I have added it because library makers are certainly users and they need to make examples if they want to do a good job. Not supporting ino is not supporting good library makers.
Here is a blog I posted about this http://blog.baeyens.it/#post13
Porting my ino implementation to another plugin is easy as I simply create a .ino.cpp file -based on the cdt indexer and project content- which includes the .ino files and I do not compile .ino files
So I also only support cpp files. I just made a trick to convert ino to cpp.
To make it work one needs to
1) configure the workspace: add *.ino to the cdt file types as source code (for the indexer) which I still fail to do automatically.
2) before build launch the static processProject(Project) in  /it.baeyens.arduino.core/src/it/baeyens/arduino/tools/PdePreprocessor.java
3) tell the toolchain not to compile .ino files

Secondly: If you really want it to be "the best it can be" I only see benefits in cooperation.
For instance: you have following things I do not have
CDT Arduino plug-in reads the package_index.json
CDT Arduino plug-in reads the library_index.json
A very good connection to CDT
...

I have
Debugging arduino sketches on the local machine
Debugging arduino sketches on the zero
unit test arduino sketches with google test
Support for upload to yun
The serial monitor (I know there is a IP conflict here)
The plotter integration (called scope but it is a plotter)
80% of the arduino hardware boards.
A good connection to the arduino core team
....


As to arduino and cdt
I fully understand that you are working on a new toolchain for CDT 9.0 and use arduino as your driver. But is this a good enough reason to make your arduino code part of cdt? Even for your development work I think it is lots better to cut arduino and cdt as that will put you in the place of a real user of your new toolchain.
Cutting your arduino plugin from CDT also releases you from eclipse enforced IP rules.

As to patches and cdt
I have tried several times to deliver patches to the cdt team. I have done so by
1 offering the code on the mailing list
2 creating bug reports which contain the problem description and the fix in full detail
3 trying the description of how to install cdt and use pull requests (I never got anywhere even with the one click install solution announced a couple of months ago)
Basically I gave up on trying to improve CDT because I can not deliver the changes.
I'm currently working on windows (Normally I work on linux) and the experience is at least saddening. Many functions simply do not work as they do in linux. (for instance context sensitive coloring for ifdefs)
With all the issues I know exist in cdt I think the delivery in march is ... well I'm not sure how to put it.
What I see here missing is a easy growth path for people to become collaborator.



What I'm trying to say is that collaboration is the way to "the best it can be" both for CDT and for arduino.
Please, lets work together, otherwise we will only annoy each other.

Best regards
Jantje




On 08/27/2015 04:00 PM, Doug Schaefer wrote:
Changing the subject line since this thread was really about asking for feedback on the new build model.

Answers:
1 - Because you need to know to pass –E –P –v –dD to the compiler to generate the built-in includes and symbols for scanner info. The mechanism will be different for Visual C++ say. And it’s slightly different with our QNX toolchain.

2 - I’ve said this before. I’ve been working in redoing CDT’s build and launch system for the last year heading towards CDT 9.0 in Neon next June. I wanted something very different to experiment with and since I’ve become an Arduino fan I chose it. And since I’m using it, I want it to be the best it can be and to use it with the ESP8266 that I bought a few months ago.

This isn’t the first time there’s been more than one. Yours is certainly different than mine since I’m using all the new CDT frameworks that I’m creating at the same time. And I’m more restricted by the Eclipse IP policies.

Also, probably the most important point, the CDT one doesn’t support ino files. It’s only pure C++. I’m also trying to teach Arduino developers that they are an include statement and declare before use away from being C++ programmers and to take that leap.

Being open source, I’m happy to accept patches from you or anyone who’d like to help with the CDT. Especially if someone wants to make ino files work with CDT’s parsers. I also need people to help test with their boards. I only have an Arduino Uno and the ESP8266 (which isn’t really Arduino. I’d rather do a less Arduino-y integration for it).

Doug.


From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jan Baeyens <jan@xxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Thursday, August 27, 2015 at 7:29 AM
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Qt qmake and initial thoughts on new build model

There are 2 things I really do not understand.
1) If everything is read from the configuration files provided by arduino, why is there a dependency on gcc?
2) What is the added value of having 2 fully open sourced arduino plugins on top of CDT?

On 08/27/2015 02:49 AM, Doug Schaefer wrote:
Yes, the CDT Arduino plug-in now reads the package_index.json, library_index.json, boards.txt, platform.txt, etc. files and does all the right things for the selected board in the Launch Bar. Nothing is hardcoded, except right now that the toolchains are GCC. And yes, all toolchains I’ve seen for “Arduino” including ESP8266 and the Intel boards are GCC. GCC supports pretty much every architecture and OS and not-OS in the Arduino and other microcontroller cases which is why CDT concentrates so much on it.

And it’s knowledge of the toolchain which drives CDT’s great features including content assist, open declaration, and search for references. It really needs to be there to provide a great user experience.

Doug

From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jan Baeyens <jan@xxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wednesday, August 26, 2015 at 7:00 PM
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Qt qmake and initial thoughts on new build model

My knowledge of toolchain implementations is very limited.  It never crossed my mind that the ARM toolchain could be a GCC compiler.

I only know that Due and Zero are both ARM based Arduino boards. They do not use the same toolchain as the "avr based" products. (read it is a different folder with different files)
Now I think of it.
The galileo is an arduino board based on intel. Again has its own toolchain.

Arduino IDE has completely opened-up for other platforms. For instance the ESP8266 processor boards work with arduino IDE. Again a different toolchain.

I do not know whether these toolchains are all gcc based toolchains or not. I do know that arduino IDE requirement for a toolchain is basically "have a command line interface". The only limitation I see for gcc toolchains (whatever that may be) is in the consistency of the output for parsing reasons. Part of the parsing (size of the sketch) is already in the platform.txt file.

Please note that all this is supported by the arduino eclipse plugin based on CDT.


PS Arduino and microsoft have announced to be collaborating. I expect a board using the visual studio toolchain to arrive one day.


On 08/26/2015 11:51 PM, Doug Schaefer wrote:
Do you mean the ARM compiler? I only saw the GCC compiler for ARM in the metadata.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Jan Baeyens
Sent: Wednesday, August 26, 2015 5:40 PM
Reply To: CDT General developers list.
Subject: Re: [cdt-dev] Qt qmake and initial thoughts on new build model

Your assumption "For Arduino, everything is gcc based." is false.
Arduino supports arm as well. since 1.5.0 basically any toolchain is supported.

On 08/26/2015 10:35 PM, Doug Schaefer wrote:
Hey gang,

I’ve spent the last couple of days with my head in Qt-land and figuring out how to do a build system similar to the Arduino one I’ve done. That has led me to the next layer of though on the new build model. Feel free to have a read and please provide feedback. I’m getting itchy to start adding this stuff to cdt.core.


Doug.



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top