Update on Visual Studio Code, new plugin

For anyone that is looking for an alternative to the Arduino IDE, there is now an Arduino plugin for Visual Studio Code, developed by Microsoft.

It is a much, much better IDE than Arduino, easily supports big projects, has very helpful code completion, etc. Here’s the link, though you can install it easily from within VS Code.

https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.vscode-arduino

You need to have the regular Arduino IDE installed, since it relies on many of the same libraries. I had it up and running in a matter of minutes. There is a handy little toolbar across the bottom of the screen that lets you define the board type, programmer, etc.

There are verify and upload buttons, just as in the Arduino IDE and they work the same. During upload you’ll see the Arduino splash screen.

A couple of small gotchas:

  1. You need to define a serial port, even if you are using the USBTinyISP and don’t need it. Any port will do.
  2. It will warn you about missing libraries. You might need to manually add #include <blinklib.h> to some sketches, and then define the include_path, VS Code will propose a fix.

Here’s the Arduino extension page in VS Code, you can install it directly from the extension marketplace.

Here’s an example, you can see how the Board Manager is supported, and you can select your board type.

Here’s BGA’s awesome Hexxagon, you can see how the programmer and the board type can be selected directly on the status line:

5 Likes

image

This looks much nicer than the Arduino IDE! The first gotcha is tripping me up. Whenever I click < Select Serial Port > or try to upload, I get the message to define a serial port, which just leads me back here. Can I get a clarification on how to define the serial port?

Click where Select Serial Port is written in the bottom blue bar? :slight_smile:

Returns the error displayed above

It doesn’t actually need the serial port when you are using the USB Tiny programmer, but it doesn’t let you proceed without one. Trying plugging in the serial interface board that came with the dev kit, that should turn up as a serial interface. Then select it, even though you won’t use it.

In my case I have a Bluetooth virtual serial port for some random robot selected.

I’ll report it as a bug, should be easy enough to fix. (Actually, it’s already on the issue tracker. The reporter found a workaround by editing the arduino.json file to include a dummy port.)

Actually, one can just manually edit the arduino.json file in the ,vscode dir and and do something like this:

{
    "board": "blinklib:avr:blink",
    "port": "dummy",
    "programmer": "USBtinyISP",
    "sketch": "blinks-hexxagon.ino",
    "output": "./output"
}

You just need to have a port listed there, even a dummy one. It is not used at all and it is just to make the VSCode Arduino extension happy.

2 Likes

Editing the JSON worked! I’ll try it again when actually using serial. Thanks @BGA and @gpvillamil

I’m liking Visual Studio as an IDE, but am having trouble getting it to work well with BGA’s custom blinklib.

Something with the programmer is getting overwritten.

A successful download looks like:

Using Programmer : usbtiny

While the custom lib has this:

Using Programmer : stk500v2

Even though I have usbtinyisp selected as my programmer.

Anyone more familiar with Visual Studio Code+Arduino know what might be wrong?

The first difference in the output is the call to arduino-builder. The custom blinklib has a few extra prefs parameters on the command line. These don’t appear when using the standard blinklib.

Don’t know if this is the cause of the failure, but it’s where the two start to diverge.

-prefs=runtime.tools.avrdude.path=C:\Users\Scott\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Users\Scott\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avr-gcc.path=C:\Users\Scott\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino5
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino5.path=C:\Users\Scott\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino5

It must be your setup that is not quite right somehow. It works flawlessly here for me.

Can you try something like this?

Yeah I’m sure it’s something with my setup. I had to reinstall the Arduino IDE again because I put it in a non-standard place the first time so maybe I have two versions floating around confusing things.

Mostly I think I just need to roll up the sleeves and learn more about how Arduino does things :slight_smile:

@BGA I’m curious about this tools.avrdude.upload.pattern from your platform.txt

tools.avrdude.upload.pattern=“{cmd.path}” “ERROR_TELL_JOSH_UPLOAD_WAS_CALLED -C{config.path}” {upload.verbose} UPLOADPAT {upload.verify} -p{build.mcu} -c{upload.protocol} “-P{serial.port}” -b{upload.speed} -D “-Uflash:w:{build.path}/{build.project_name}.hex:i” “-Uflash:w:{runtime.platform.path}/bootloaders/BlinkBIOS.hex:i” “-Uefuse:w:0xf8:m” -u

It seems this isn’t used since the ERROR isn’t seen in the output, but I’m wondering what pattern is used?

For my passing case with the stock blinklib, the pattern in the Blinks-SDK-1.1.0-GM platform.txt file matches the output I see in my log.

When I switch to the custom blinklib, it fails and the upload log shows a different command that doesn’t match the above pattern.

What determines which pattern it uses? If it’s not based on the selected board then it must be overridden somewhere?

Okay I got it working by hacking your boards.txt to add the upload.protocol (despite the comment telling me not to) and changing the upload.pattern in your platform.txt to match the one from the stock blinklib.

I hate not understanding how things work so this will still bother me, but at least I can switch between the two now.

All the configuration files on my custom Blinklib were a direct fork of the existing Move38 files at the time I did it. It is possible that they changed something that now diverged on my library but that does not explain why I am not seeing any issues while you are. I still think it is something on your specific setup that is causing it.

In any case, as I understand it, Move38 should be releasing a new SDK release in the near future. When thye do, I will update my custom blinklib to match its configuration again.