-
Notifications
You must be signed in to change notification settings - Fork 80
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
Add new examples #55
Conversation
… into add-new-examples
… into add-new-examples
…noIoTCloud into add-new-examples
There was a problem hiding this 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?
Co-Authored-By: ubidefeo <[email protected]>
Because of the different init process for GSM and its required parameters we should have a separate example. |
Co-Authored-By: lxrobotics <[email protected]>
… warning - otherwise travis won't build
@ubidefeo @umbynos I've patched everything up so the file compiles also with travis for all boards. Two things:
I'd love to hear your opinion on this 😃 |
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. |
…led boards (MKR1010 and MKR1000)
Travis tests have failedHey @lxrobotics, 3rd BuildbuildExampleSketch MKRWIFI1010_Cloud_Blink
TravisBuddy Request Identifier: 6926dd90-5d37-11e9-8db0-bbda51d68b34 |
Hey @lxrobotics, TravisCI finished with status TravisBuddy Request Identifier: aaf45890-5d39-11e9-8db0-bbda51d68b34 |
Sorry about the mess I did just above. I'm still a noob using GitHub 😅
|
Good Morning @umbynos, Don't worry about the mess, it can always be cleaned up by applying Regardless of this I currently see two problems with this PR:
|
Thank you! I'm going to read the article you sent me right now.
|
I came up with two methods by which this could be accomplished: Define a separate
|
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). |
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 If you are concerned with efficiency of the CI build, a |
Co-Authored-By: lxrobotics <[email protected]>
Co-Authored-By: lxrobotics <[email protected]>
Travis tests have failedHey @lxrobotics, TravisBuddy Request Identifier: d7f65080-5f7f-11e9-8107-31db5b396b41 |
…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
No description provided.