Arduino IoT Cloud controlled MKR Robot ARM: Das Blinken LED

Yeah, I had seen that site maintenance thing as well.

With regards to the Arduino code issue, that would take someone or something that controls what code is checked into a base Arduino Repo or some other means to make the Interfaces and such of every Arduino library writer visible to everyone else and a gatekeeper to make sure everyone plays nice.  Sort of like the mainline Linux Kernel model.  In a complete Open Source environment, this is pushed to the user, or consumer of the code, to ensure the code they pull in is compatible with the current code base and does not break any other code.  The Arduino IDE sort of has this and will report when it sees multiple instances of the same code, or same names. There are ways to increase the warning levels and such in the Arduino IDE though.   In a true IDE, these triggers can be implemented and the code would not compile if there is a conflict.  The other option is to use some sort of Configuration Management and set triggers for code conflicts, but this is out of scope for a typical Arduino user.    

Some of this is controlled on the Arduino GitHub repo, but they can not control what everyone else is doing for their individual Arduino based board or shield.  At one point the since ousted director of Arduino, AG, Frederico Musto, pulled much of the Open Source licenses, schematics and code from the Arduino site.  I suspect this was due to the number of non Arduino licensed products being developed.  I'm not sure what the resolve of this was, but if Arduino pulls all of the Open Source stuff back and make Arduino strictly a Closed Source Architecture and Software product, then it could control what code is developed for a particular Arduino board or shield.  However, I suspect Arduino would die on the vine if this happens.  In the mean time, with so many non truly Arduino products being created that call themselves Arduino compatible, it is basically use at your own risk with regards to hardware and code.  If there is an issue or conflict with Arduino build code, then an issue can be filed at their GitHub repo or posted on their forum which I have done for the Create Cloud IDE and Arduino IoT Cloud. No guarantee if it will be fixed though.

https://github.com/arduino

At least, that is the way I see it.

John,

I have read your message yesterday night and started answering you. Then when things were almost finished, trying to send the reply I got the nice message 'system undergoing for maintenance' and goodbye, I went in bed.

Now I forgot what I wrote but the concept is that I agree with you and continue pointing the attention on the problem (or just the issue) that who write the libraries never take care that maybe the same library will be used in conjunction with something else.

Enrico

My view with the Arduino boards are that they are nice Maker boards or Prototype boards at best.  With the partnership between Arduino and ARM and now the extended line of ARM based Arduino boards, they have moved more into to the dev kit space.  However, with regards to a crypto chip, looking at this from a production perspective, I would not want to have this exposed where someone or something could easily tap into the crypto with a hardware attack.   Thus, I would not have the i2c signals exposed if the crypto chip was used.

As far as interrupts are concerned, that is an implementation issue, in that when interrupting the chip, how this affects anything else using it would have to be taken into account.  I've seen instances where code from a vendor will reinitialize all of the gpio pins when the begin is called for that driver which could reset predefined pin definitions.  Also, I've seen where a particular timer was used in one vendors code which conflicted with the default timer or the timer used in another vendor code.  I've also run into instances where 2 different libraries from separate shield vendors used the same namespace and class names, so there was no easy way to use both in the same app without changing one of the namespaces. Since there really is no control of who creates libraries for the Arduino boards, then conflicts are bound to happen. This is something that is not exclusive with Arduino though; its the joy of Open Source.

With the Arduino IoT Cloud, I have found they are using some libraries that are not compatible with other common libs and actually limit the user from adding certain libs to the Create environment.  However, the limitations I was referring to previously are inherent with the development of the Arduino IoT Cloud as it stands now; Only 1 Thing can be active at a time, although you can define multiple boards (things), and only 5 Properties can be defined for a Thing. However, this is a Beta environment so I expect changes to be frequent and features limited.

John, you are right, me too I read of the SDA/SCL. But the concept is just this, you have a lot of pins and also a lot of potential limitations. I have not tried how does the interrupts will influence the behavior of the MKR IoT specific features.

We should also consider one thing; many of these features are due to the libraries that are not 100% compatible with other devices. IMHO one of the big problems of the software libraries and general approach to the Arduino boards (especially but not only) is that all those make a piece of software or a shield, rarely think that some project needs more than one or two things only on the same board.

Just a cascade example I have experienced recently: NeoPixel impact with the servo library (does not work). Servo library impact with PWM (two stop working and the other are unreliable). And I am sure these are only two of more cases.

Enrico

I had some conflicts in the i2c software. The MKR1010 and wire library don’t work nicely together. Had to insert some tactical init() calls. The radio made the Wire lib stop. The wire lib made the radio stop.

There are still some rough edges in this new product range.