In the standard "Blink" program in the Examples section the Blink program says this:
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
But the LED has the cathode to the microprocessor pin. So that means a low to that pin (LED_BUILTIN, LOW) turns the LED_BUILTIN "on, not "off" and vice-versa. You may want to correct that labeling on the next version of the Blink code.
It depends on the board. That example is used for all boards, not the MKR Vidor 4000 alone. The comments are correct for official Uno, Mega, Leonardo, Nano, and MKR Zero boards, but incorrect for MKR Vidor 4000, MKR1000, MKR WiFi 1010. I didn't check other boards.
That example was written long before the MKR boards existed. Likely at that time the comment was correct for all the official Arduino boards.
It seems there is now no standard for the configuration of the onboard LED on the official Arduino boards. For that reason, the only solution is remove any mention of the LED being off or on from the comments and only state that it sets the pin HIGH or LOW.
I had a look at the schematics and I was wrong. Only the MKR Vidor 4000 has an active LOW LED. All the other official Arduino boards have active HIGH LED. I'm not sure that it makes sense to change the example just for one board.
Well, at the very least it makes sense to mention it in comments by the code. ie:
"For the MRK Vicor 4000 these cases/states are reversed."
What I'd REALLY like to see is some Example loading intelligence. Every board indentity could be polled (Tools>Get Board Info) and then examples are loaded which match the board. I've found other examples that reference pins (like "pin 9" for some analog input, doesn't match an analog input at least on the 4000. Polling could have an else/if based load so Examples loaded would match the board. But that would take actual effort so I'm not expecting it. That's why I'm saying writing comments in the code is the least to be done.
The hallmark of the Arduino boards are two things. 1.) Easy to use for the novice 2.) Easy to understand for the novice. What if someone cuts and pastes
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
And can't figure out who their LED isn't on? Yeah, they'd figure it out but this isn't matching those hallmark ideals. Plus, if most of the boards have outputs "high" to drive something directly connected then that means the processor is pulling more power to drive it. If you're driving a transistor with current limiting to drive something, then fine. Do you know what I mean? The high output goes through a current limiting resistor to have just enough to saturate the base of a transistor and turn it on. That transistor in turn could be driving a 12 volt relay and have it's own power source, reducing low power mode needs in the uP.
So comments are minimum, examples loaded by board recognition are optimum. The more goof proof you make things for novices the better they are at making things.
max2kow:
Well, at the very least it makes sense to mention it in comments by the code. ie:
"For the MRK Vicor 4000 these cases/states are reversed."
The problem is that the Blink example is the very first sketch most Arduino users see. It's very important to keep it as simple as possible. A beginner will have no idea of what to make of that comment and will possibly get even more confused than they are already. I would prefer my original idea of removing mention of off and on from the comments to adding that one.
I think it would be a good idea for Arduino to specify the pin and polarity of the onboard LED in the Documentation page of the MKR Vidor 4000 product page.
max2kow:
What I'd REALLY like to see is some Example loading intelligence. Every board indentity could be polled (Tools>Get Board Info) and then examples are loaded which match the board. I've found other examples that reference pins (like "pin 9" for some analog input, doesn't match an analog input at least on the 4000. Polling could have an else/if based load so Examples loaded would match the board.
It's already possible to do this for hardware packages, though not for individual boards. Libraries can be bundled with hardware packages. The bundled libraries are only accessible when a board of that package is selected from the Tools > Board menu, and the examples of that library will only show up under the File > Examples menu then. So you can put package-specific examples in a dummy library. Several 3rd party hardware packages already do this.
max2kow:
I've found other examples that reference pins (like "pin 9" for some analog input, doesn't match an analog input at least on the 4000.
There are definitely some examples that need improvement. Another issue is that some of them still assume the built-in LED is on pin 13, rather than using LED_BUILTIN. Feel free to report or submit pull requests for any specific problems you find in the examples.
OMG. Removing information doesn't make things clearer. Make Blink4000 and put a comment "Use Blink4000 for MKR Vicor 4000" in the old Blink.
Are you someone working for Arduino or just a contributing member here? Arduino made a mistake, plain and simple, and it's not the only one I'm finding. Where's the QC? Giving an amateur less to work with won't help. Are you an engineer with 35 years experience with customer service, hardware, software and firmware design, board layout design, customer quality control and product management and technical writer like me? Or are you not seeing the obvious?
There is still few bugs in tool scripts in github. If you try to synthesize multiple project to same folder structure.
Also you need pretty good design knowledge to do something with FPGA part of vidor.
They have promised simplified editor for web ide where you select used IP blocks. For desktop usage there are libraries / bit file sets but if you want little more then you have to get git repo and Quartus Prime lite and start to do your own bit file.
Currently this is pretty good board for training Verilog or VHDL but there are cheaper FPGA boards also with MKR pinout. You need just little tweak USB Blaster sketch to work with signaltap.