Skip to content

Add new examples #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 23 commits into from
Apr 15, 2019
Merged

Add new examples #55

merged 23 commits into from
Apr 15, 2019

Conversation

aentinger
Copy link
Contributor

No description provided.

Copy link
Contributor Author

@aentinger aentinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@umbynos This example only compiles for MKR WIFI 1010/MKR 1000. Should MKR GSM 1400 also be supported?

@ubidefeo
Copy link
Collaborator

ubidefeo commented Apr 10, 2019

Because of the different init process for GSM and its required parameters we should have a separate example.
I've tried to tackle a single example encompassing all supported boards (and forward-thinking) but the excess of #ifdef made me refrain from it :)
@umbynos any comments?

@aentinger
Copy link
Contributor Author

aentinger commented Apr 11, 2019

@ubidefeo @umbynos I've patched everything up so the file compiles also with travis for all boards. Two things:

  • In order to compile for all boards (and especially to cover undefined secrets) we need quite a bit of #ifdef magic - we could extract that into another file (e.g. arduino_travis_secrets.h).
  • Since the board works for both GSM and WIFI enabled boards I'd propose to rename the example simply to Cloud_Blink.

I'd love to hear your opinion on this 😃

@umbynos
Copy link
Contributor

umbynos commented Apr 11, 2019

This sketch will be the one used in the getting started procedure. I've started a rework in order to use the new connection flow. So I think having one sketch for 1000, 1010 and GSM is a good thing, but maybe we should hear an opinion from @AlbyIanna.
@ubidefeo Originally there were different sketches for different boards. One for 1010, one for GSM and so on.
@lxrobotics Cloud_Blink sounds good to me.

@umbynos umbynos closed this Apr 11, 2019
@umbynos umbynos reopened this Apr 11, 2019
@TravisBuddy
Copy link

Travis tests have failed

Hey @lxrobotics,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.

3rd Build

View build log

buildExampleSketch MKRWIFI1010_Cloud_Blink
Picked up JAVA_TOOL_OPTIONS: 
Loading configuration...
Initializing packages...
Preparing boards...
Verifying...
java.io.IOException: No valid code files found
	at processing.app.Sketch.listSketchFiles(Sketch.java:117)
	at processing.app.Sketch.<init>(Sketch.java:54)
	at processing.app.Base.<init>(Base.java:412)
	at processing.app.Base.main(Base.java:151)
TravisBuddy Request Identifier: 6926dd90-5d37-11e9-8db0-bbda51d68b34

@TravisBuddy
Copy link

Hey @lxrobotics,
Something went wrong with the build.

TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.

View build log

TravisBuddy Request Identifier: aaf45890-5d39-11e9-8db0-bbda51d68b34

@umbynos
Copy link
Contributor

umbynos commented Apr 12, 2019

Sorry about the mess I did just above. I'm still a noob using GitHub 😅
I split MKRWIFI1010_Cloud_Blink in two examples:

  • WiFi_Cloud_Blink which is compatible with MKR1010 and MKR1000
  • GSM_Cloud_Blink which is compatible with MKRGSM1400
    I did this beacuse on create all the secrets are parsed and it's not possible to hide them. So having a single sketch will generate all the secrets: some for WiFi boards and some for GSM boards.
    Although I'm still having some problems with the GSM sketch, I don't know why the serial monitor remains empty.

@aentinger
Copy link
Contributor Author

Good Morning @umbynos,

Don't worry about the mess, it can always be cleaned up by applying git rebase 😉 . I'll send you a confluence article which I wrote on this topic via slack.

Regardless of this I currently see two problems with this PR:

  • Since GSM_Cloud_Blink.ino and WiFi_Cloud_Blink.ino contain platform specific code for the MKR GSM 1400 and the MKR WIFI 1010 they can not be successfully run by our travis build script, due to the fact that the build script build each example against all platforms. @per1234 Do you have an idea how to modify the travis build script so that GSM_Cloud_Blink.ino will be only build for MKR GSM 1400 and WiFi_Cloud_Blink.ino will only be build for MKR 1000 and MKR WIFI 1010?
  • You are mentioning that you have problems with the serial monitor for the GSM sketch. This sounds to me like this PR is not complete yet. You can contact me on slack and maybe we can sort those issues out together in order to get this PR to completion. For future PRs: If at the time of opening a PR you are aware that there is still work to be done, please use the feature of creating a draft pull request ( https://github.blog/2019-02-14-introducing-draft-pull-requests/ ). Doing so ensures that people taking a look at your PR know it's work in progress and they can respond accordingly 😉

@umbynos
Copy link
Contributor

umbynos commented Apr 15, 2019

Thank you! I'm going to read the article you sent me right now.

  • Now I understand the problem with travis errors, but I don't know how to solve them.
  • I did't know about draft pull request, but in the future I will certainly be using them!
    Thank you for your advises.

@per1234
Copy link
Contributor

per1234 commented Apr 15, 2019

@per1234 Do you have an idea how to modify the travis build script so that GSM_Cloud_Blink.ino will be only build for MKR GSM 1400 and WiFi_Cloud_Blink.ino will only be build for MKR 1000 and MKR WIFI 1010?

I came up with two methods by which this could be accomplished:

Define a separate script phase for each job

https://github.com/per1234/ArduinoIoTCloud/commit/7a2eacfb5666641ed4b185c3f6fba20f121fa9af
build:
https://travis-ci.org/per1234/ArduinoIoTCloud/builds/520194410

Cons:

  • Some duplication of the script phase configuration between each job

Use conditional logic

https://github.com/per1234/ArduinoIoTCloud/commit/0976b58af4c8fea2ecf1f5a4ea68661848fc249b
build:
https://travis-ci.org/per1234/ArduinoIoTCloud/builds/520184751

Cons:

  • The conditional code makes .travis.yml and the job logs a bit "messy".

@aentinger
Copy link
Contributor Author

Thank you very much for your input 👍

In my opinion the first version ( https://github.com/per1234/ArduinoIoTCloud/commit/0976b58af4c8fea2ecf1f5a4ea68661848fc249b ) should be implemented, since it is much simpler to read and understand (by humans). If the downside is that the CI server has a bit more work I'd say that's a small sacrifice for the increased readability (and therefore reduced probability of bug introduction).

@per1234
Copy link
Contributor

per1234 commented Apr 15, 2019

In my opinion the first version ( per1234@0976b58 )

Just to avoid any confusion, I should point out that per1234@0976b58 is the commit for the second version.

I don't believe that the per-job script definitions will result in any more work for the CI server. My concern with the duplication is that it makes maintenance a bit more work. For example, if a new example sketch is added to this library, it would then need to added to three separate locations in .travis.yml. I don't think that's really a significant problem though, and it's easily balanced out by the benefits of improved readability.

If you are concerned with efficiency of the CI build, a before_install phase could be defined for each job. This would allow only installing the libraries needed for that specific job. For example, there is no need to install the WiFi101 or MKRGSM libraries for the BOARD="arduino:samd:mkrwifi1010" job.

@TravisBuddy
Copy link

Travis tests have failed

Hey @lxrobotics,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.

TravisBuddy Request Identifier: d7f65080-5f7f-11e9-8107-31db5b396b41

@aentinger aentinger merged commit 34f35cf into master Apr 15, 2019
@aentinger aentinger deleted the add-new-examples branch April 15, 2019 14:32
aentinger added a commit that referenced this pull request Jun 3, 2020
…obal timestamp. (#55)

This is necessary because right now we are relying on the RTC within the SAMD MCU which is instantiated (RTCZero) within the ArduinoIoTCloud library and reference within ArduinoCloudThing via extern devlaration. Due to the extern binding this is a very brittle dependency which can be easily destroyed, it is therefore better to explicitly register a function which provides the time (this can be serviced by the TimeService class available in ArduinoIoTCloud
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants