Hi
I use a Yun to act as a keyboard on Windows PC.
When I connect the yun, the device manager shows it like a keyboard (fine) and a unknown device which need a driver.
This driver is for the COM/LPT device. So if I install the Arduino Yun COM/LPT driver evrything is OK.
Of course I can :
install the driver
disable the device (that I don't use for the COM part)
ignore the fact that this device is not recognize.
But my problem is that's not clean from client point of view.
I thought that remove the bootloader would save me. So I've followed this topic (Can I safely run without the bootloader? - Arduino Yún - Arduino Forum) and I've modified the merge-sketch-with-bootloader file and load the sketch on linux side.
The bootloader is gone (I can't uploaded the sketch from USB side) but I still need the COM/LPT driver.
So my question is : is there anything to do on the yun side to have "a pure keyboard behaviour" = no asking for COM/LPT driver at connection of the Yun?
Best regards
I think I can now answer my own question : Arduino boards appear as a serial device for all programming and communication. Arduino remains connected as a serial device while it reboots.
So I think there's no way to avoid a message from Windows to ask for COM driver.
I can use a Teensy to have a native USB, but a teensy is not a Yun ...
Reading them I think my question was not clear enought.
When i take my YUN with my sketch running as a keyboard and I connect it on several PC (which never have seen an Arduino), Windows is asking for a driver because it sees the serial part of YUN.
This is not a Windows configuration problem or an Arduino IDE communication problem.
Olipop:
This is not a Windows configuration problem or an Arduino IDE communication problem.
The core software that is always included as part of your sketch will always set up the USB port to be a CDC (serial port) device. I believe that is true whether you actually use the Serial port object or not. Your sketch is undoubtedly explicitly configuring a keyboard USB class diver, and then accessing that object. To make life simpler for most users, the Serial CDC object is automatically created so that it's use is transparent and all of the other users don't have to explicitly set up the CDC object. Automatically doing that works well for most people, but you have an unusual situation and it doesn't work for you.
I think you will need to look at the core software and hack it so that it doesn't automatically create the CDC device on the USB port. Unless someone who has already done it happens to read this thread, I think you are going to be on your own to figure that out?
#include "Keyboard.h"
void setup() {
// open the serial port:
Serial.begin(9600);
// initialize control over the keyboard:
Keyboard.begin();
}
void loop() {
// check for incoming serial data:
if (Serial.available() > 0) {
// read incoming serial data:
char inChar = Serial.read();
// Type the next ASCII value from what you received:
Keyboard.write(inChar + 1);
}
}
sonnyyu:
ATmega32u4 processor at Yun support switch from CDC usb descriptor to HID usb descriptor by use
Are you sure about that? What you are saying ("switch from") seems to imply that enabling the HID descriptor disables the CDC descriptor.
I don't think that's the case. Enabling the HID function does not automatically disable the CDC function, it just adds another supported class. If HID did replace CDC, how could the sketch you posted possibly work, as it uses both HID and CDC at the same time?
I believe the issue is that the OP wants to disable the CDC class so that when his Yun is plugged in, the computer does not try to enumerate as a serial port (and therefore try to install a serial driver.) He wants it to be ONLY a HID device, not HID and CDC. I don't think the HID function is causing him a problem, it's the unwanted CDC function.
ShapeShifter:
Are you sure about that? What you are saying ("switch from") seems to imply that enabling the HID descriptor disables the CDC descriptor.
...
You are right, enabling the HID descriptor, CDC descriptor is not automatically disabled.
That would eliminate the temporary appearance of the bootloader's CDC while the bootloader is running, but not the CDC created by the Serial class in the sketch.
I really think it's going to take some digging around in the core source code to disable the default Serial CDC instance.
After re-reading your original post, then re-reading your reply, it appears to me this is a "Windows configuration problem".
MS Windows still lives with legacy issues. One of the legacy issues is plug-n-play. When MS Windows get a "discovery" event, it tries to resolve the event by looking for the appropriate driver. If it does not find it, it tries the alternatives - which include the Internet, any mounted CDs (or similar), or "Ask the user".
You have the last. The alternative is to
"register a driver" with Microsoft and install from the Internet (very difficult to do),
put some drivers on a CD that "auto installs" when found, or
pre-install drivers in to the target machines.
In addition, I know there is a higher level USB protocol that allows the software to load from the "mouse, keyboard or device". However, I do not know how this is done, nor do I know how where to find the reference. Perhaps, it is USB 3.0. Perhaps, someone else has an idea.
I think the way it works is it is a hack. What happens is the device loads as a hub, then loads the device, and a storage device. That storage device loads as USB drive. So we have a hub, the device, and a storage device that contains the self installing driver. To be clear, this last paragraph is my speculation. It may not even be true.... But it seems to follow some logic in my head - so I may have seen this somewhere.
jessemonroy650:
After re-reading your original post, then re-reading your reply, it appears to me this is a "Windows configuration problem".
Am I the only one actually reading and understanding the problem? Or do I have it totally wrong?
I believe the OP wants his Yun to appear to a computer as a HID keyboard and nothing else. He has the keyboard part working, and it doesn't need a driver - just as it should be. However, at the same time, the Yun is also acting like a serial port, and this requires a device driver. The OP doesn't need the serial port, and would like to disable the Yun's default behavior of creating a serial port. This will prevent the host computer from requesting that an unnecessary device driver be loaded.
Actually, the Yun will try to appear as TWO different serial devices: the normal run-time CDC, and a different device when the bootloader is running. The latter is easy to bypass - don't include a bootloader on the AVR processor. This can be done by
loading the code using an ICSP programmer,
copying the image to the Linux side and manually running the /usr/bin/run-avrdude command
make a "do nothing" version of /usr/bin/merge-sketch-with-bootloader.lua and perform a normal code upload from the IDE over the network
But that still leaves the default behavior of the sketch creating an unused instance of a CDC class for the default Serial object. It's not a matter of getting Windows to install a serial driver, it's a matter of not having the Yun appear as a serial device in the first place.
It can't be more clear to me: with his sketch, the Yun appears to the computer as a keyboard AND a serial port. How can he make it so that it appears to be ONLY a keyboard?
My impression was that you wanted a common issue resolved. I think, by asking a question, that was tangentially related to your goal, made it easy to continue to a wrong assumption on my part.
As ShapeShifter, you want your Yun to respond and act like a USB keyboard no matter which PC you plug it into.
The answer you are looking for is very close to what ShapeShifter is say. That is, a USB device can identify itself (as a keyboard) before it identify itself as anything else.
I know how to do this, although I have never done it. You need to reduce the "endpoints" for the device. I've been looking for documentation on this, but have found none since the USB organization has removed all 2.0 documentation and put up 3.0 documentation.
I'll keep looking and get back to this in a day or two, if I don't find it sooner.
