I’ve setup everything and have loaded the driver for libusb-win32 which shows a functioning device in Device Manager as “USBtiny”
Then in Ardunio’s IDE, I’ve set the board to “tools > board > Blinks Tile” and the programmer to “USBtinyISP”.
Everything is wired up, and the tile is connected to the little blue socket. When I apply some pressure (as mentioned in another thread about having trouble uploading to the Blink) it glows a nice bright red, indicating it knows I’ve done something.
Unfortunately, I get the error “Please select a port before uploading” when trying to compile. Under “tools” port is grayed out, so I can’t much of select anything. The Arduino forums suggest I have the wrong board selected, but it seems all correct.
I went through all the steps again on a different computer and had no problems whatsoever. I never had to do anything with the port; it just defaulted to COM1 and I was able to load a sketch into the tile without issue.
The computer that’s failing is a Microsoft Surface, whereas the one that worked is some unholy monstrosity I built myself. When I get some time I’ll mess with it. I have verified the USB port is functional, so it’s not like it’s just a basic hardware failure.
If anyone knows anything about this, it would help a ton! I’d rather do dev outside when fooling with stuff like this. It’s weird; I know.
First of all, welcome @Chris_Woods!! Sounds like you are up and running.
Let’s figure out how to get your Window’s tablet programming Blinks happily. You have exactly the right intuition, which is that the Blinks don’t use the serial port to program the Blinks, so selecting a port in the Arduino IDE is only needed when using the Serial Port Adapter for Blinks, not for the act of programming.
It is a little odd that Arduino will stop you from compiling without a port selected, since there are plenty of reasons you might want to compile without a board even attached. If you can provide a screenshot of the situation, that always seems to help, I’d love to get you up and running on your regular machine asap.
One other small note:
I love this bright red glow as well, but a quick tip (and something I should add to the quickstart guide) is that there is a little switch on the programmer that allows for you to power the board or not provide power. When the Blinks have their batteries in (i.e. almost all of the time) there is no need to power it while programming.
A Surface has no reason to have any old serial ports, so I wonder if the IDE is just barfing due to legacy code that assumes you’re using serial instead of USB to connect to the embedded system. You’re right that I’ve selected “COM1” on my main computer, which is nonsense because I’m just on the USB adapter.
I’ll dig around and see if I can sort it out.
On the good news side, I’ve successfully written a rudimentary program and uploaded it! So, yay!
On two unrelated notes:
I’m new to Arduino, so forgive me if this is something I should already know – how often does Loop() get called? Is it on a frequency, or is it basically “while (true) { Loop(); }”?
Also, has anyone had trouble getting stdlib.h to include? I’m going to need malloc, but when I include stdlib it barfs calling ‘extern’ an unqualified id.
EDIT: Okay, I’ve /sort of/ solved problems with including stdlib, but it’s weird. I have to undef abs before the include, because I guess it’s getting defined elsewhere? This works:
#undef abs #include “stdlib.h”
which is really strange. These are the first 2 lines of my program, so I’m not really sure how I can be accidentally getting abs from somewhere else.
malloc() and free() are generally avoided on the resource constrained Arduino platform.
We have so little memory to work with that is it very easy to run out, so it is nice to allocate all the memory you need statically so at least you can see that you are running out at compile time.
I even avoid putting anything too big to fit into a register on the local variable stack just to avoid hard to track down out of memory bugs. You can use the static keyword to keep the scoping of a local variable inside the code block while still having it get allocated from the static memory pool (just remember to initialize its value manually inside the block).
I’d like to just second this problem, inasmuch as I am also having it; on two separate laptops.
Laptop 1:
HP Convertible x360
Windows 10
Arduino IDE 1.8.7
No COM ports
USB 3.0
Laptop 2:
Toshiba Satellite C55D
Windows 8.1
Arduino IDE 1.8.7
No COM ports
USB 2.0 and 3.0
Aside from the difference in hardware, the problem I am having is manifesting in exactly the same way as it was for Chris above on his Surface. Well, I say that; I have no problem when compiling - just when attempting to upload. (I bet this is what Chris meant too.)
This is helpful to see the screenshots. My guess is that the libusb driver isn’t pulling its weight. Adafruit created a modified version of the libusb driver for Windows users to use the USBtinyISP. The installer for the driver is here.
Let us know if that works and fingers crossed we can post a solution
Sadly, I don’t think this is the solution. I had already installed exactly that driver from Adafruit. I reinstalled it nonetheless from the link you included above but it has not solved the issue. We need to keep digging.
Whilst we’re here talking about it, I’ve been trying to debug the issue myself. I’m not greatly familiar with the Arduino ecosystem but I’ve been digging into this for the last couple of hours and I’m following a definite line of enquiry. Here are some assumptions I’m making; you can tell me if I’m on the right track or not:
The Arduino IDE forks avrdude to upload the compiled sketch to the connected device; a Blink tile in this case.
The command line pattern used to fork avrdude is specified in platform.txt
When I attempt to upload the compiled sketch, the error I’m getting is “Please select a Port before Upload.” This suggests to me that the command line argument value for specifying the port to use is not being supplied to avrdude, such that a “-P” or “-p” without a port value is being passed to avrdude and avrdude is choking on it. So I’m guessing, if no -P (or -p) argument were passed to avrdude, it would default to using USB and just work. Either that or we should supply “-Pusb” or similar on the command line. If I’m right, we should be able to make this work by just tweaking the command line patterns in platform.txt
Bottom line; I’m guessing this problem only occurs on machines with no COM ports. On a machine with a COM port, the first time the IDE runs, it finds the first COM port and subsequently that always gets passed to avrdude in the {serial.port} variable, even though it’s not needed for USB comms. On a machine with no COM ports, {serial.port} never gets populated so avrdude chokes on a -P command line argument with no value.
Does any of this make sense or am I WAAAAY off track here?
@MikeSynnott I haven’t done the digging that you have, and I’m a bit of a layman in regards to some of this low-level stuff, but if it helps to support your theory, I can confirm I’ve been having the exact same issue when trying to program my blinks with an old Acer Netbook (running Windows XP) that I’ve used for some projects in the past. It too does not have any COM ports, and the “Port” menu in the Arduino IDE stays greyed out.
EDIT: I should mention that I haven’t tried @jbobrow’s suggestion of using the Adafruit modified driver for the USBtinyISP. I might give that a try myself when I get home.
So we have a definite correlation on the “no COM ports” thing. I’m going to do some more digging this morning to try and establish a causal relationship between that and the issue at hand, and to then come up with a workaround. If I can just get the Arduino IDE to emit some debug logs so I can see the command line it’s constructing to fork avrdude …
More later; unless @jbobrow beats me to it, which I bet he will!
@MikeSynnott Darn I wish I had brought my laptop into work to try this on my break… I’ll try it out later this evening and report back. Thanks for figuring this out!
@MikeSynnott Just wanted to follow up, this fix looks like it works for me as well! @jbobrow might be worth pinning this solution somewhere, possibly on the support site?
@jbobrow: Dude, I love the work you’re doing and I’m delighted to have been able to take some of the burden off you. You continue to focus on all the difficult stuff and let the rest of us in the community help each other out with this simple stuff.
As regards the workaround, I’ve discovered you don’t actually have to set the upload.verify setting to false. Just set the serial.port setting to COM1 (or anything you like) and the workaround will, er, work!
So here’s the consolidated list of steps to follow:
On the Arduino IDE menu, navigate to File -> Preferences (or hit [Ctrl] Comma)
The Preferences dialog will appear and, near the bottom of that dialog, it will show you the full path to the preferences.txt file itself.
Click on the full path to the preferences.txt file and the Arduino IDE will open a file browser window showing you preferences.txt
IMPORTANT: Shut down the Arduino IDE app now.
Open the preferences.txt file in your favourite text editor, and edit it as follows:
— Set the value of the serial.port setting to COM1
Save the changes and exit from your text editor.
Restart the Arduino IDE and try an upload to your Blink tile. It should work with no errors.
Hi…on a new install, there would be no need to select a serial port with these boards. However, the newly added message is still shown, and uploading is prevented. On a system without serial ports, where a port has never been selected before, this completely prevents users from uploading their sketches.
Are you having this issue right now? Curious to know if the current solution is still applicable or if this is a new issue that the forum can help with. Looking for a bit of clarification on your post. Also, welcome!
