Digistump Forums
General Discussion => General Electronics => Topic started by: natarajan on June 25, 2014, 01:12:49 am
-
Hi,
I am using micro-nucleus bootloader for a personal project of mine. However, I was trying to mess with the code and changed the Vendor ID to default USBAsp vendor id which is provided free by obdev. I compiled and burnt the code into attiny45. It does give a "ding" sound saying that it is connected. I used the default USBAsp windows driver and all went well. However, I am not able to load any code through USB once connected. I am able to do it using the default vendor ID provided by Digispark (through micro-nucleus). Does anyone please let me know why?
Thanks,
Natarajan
-
Why it should work? Micronucleus is no USBAsp.
USBASP is a ISP-programmer, which is capable to load programs to blank AVR chips. With USBASP you need at least two chips. That one, whioch acts as programmer and the target, which will be programmed.
You can load littlewire on the digispark (http://digistump.com/wiki/digispark/tutorials/programming#using_littlewire_as_usbtinyisp) and use that as an ISP, which works very close to USBASP.
Micronucleus is a piece of software, which need to be present on the target device, when you wish to write programs to it. The benefit is, that you need no extra programmer. However you need either an USBASP or USBtinyISP, ot STK500, ... programmer, to write the micronucleus on a blank chip.
When you have an USBASP VID/PID on a USB-device, avrdude assumes to speak the USBASP protocol, which is totally different from the micronucleus. (vice versa the same)
-
Thanks for the response. Ofcourse it should work. Why not?
The drivers for windows tell the computer that there is a device with xx vid connected which belongs to this manufacturer and the name of device is xx.
When I use the drivers of obdev and use usbasp drivers, the reason is because it uses that same vendor id. Since the bootloader is still micronucleus, that should take care of it.
Secondly, I tried littlewire. For some reason it never works for me. Once the fitst issue is sorted, I thought of looking over it.
I may be wrong in understanding. Someone can shed some light please.
Thanks.
-
Just because you slap a Porche sticker on a Hyundai, it doesn't make the car go faster.
Likewise, changing the USB VendorID to the one for USBAsp, it doesn't magically make your device act like a USBAsp. Basically, you're lying to the computer, telling it that your device is one thing, when it's really another thing.
-
micronucleus doesn't take care of anything for a running application.
USBASP has its own VID/PID littlewire as well.
Both program can be run on a AVR without any bootloader involved. However in many cases, there is an bootloader below.
When you start an digispark with littlewire loaded, the digispark fist enumerates with the VID/PID of micronucleus, waiting for the command line client to connect.
When the command line client does not connect within some seconds, micronucleus disconnects from the USB bus and starts the installed application. In case of littlewire or USBASP the application itself takes over the USB bus and enumerates with their VID/PID, ready to talk e.g. with avrdude.
-
One more example:
When I use a digispark with littlewire as USBtinyISP, i it enumerates with a VID/PID which is registered by Adafruit Technologies. I uses the libusb32-USB driver (http://sourceforge.net/apps/trac/libusb-win32/wiki) and I can flash code to an AVR, which is connected to the digispark, using USBtinyISP as programmer.
----+ +----------------+ +--------------------+
| | digispark with | | target |
PC +---USB--+ littlewire +-----+ AVR chip |
| | as ISP | | e.g. blank tiny85 |
----* +----------------+ +--------------------+
When I however select in the same setup accidently the digispark as programmer,
----+ +----------------+ +--------------------+
| | digispark with | | no target :-( |
PC +---USB--+ micronucleus + + AVR chip |
| | | | e.g. blank tiny85 |
----* +----------------+ +--------------------+
and reset the digispark in the right moment, that micronucleus can enumerate with the USB bus, i overwrite littlewire on my digispark with that program, I planned to send to the target chip.
-
Thanks for the responses. I think I am complicating the issue than what I need to say. Just trying to make it more clear.
My question - How do I change the VID given by Digispark to free VID given by Obdev?
First, I have this micronucleus bootloader. I edit usbconfig.h file to insert a new USB_CFG_VENDOR_ID and USB_CFG_DEVICE_ID which is (0xc0, 0x16) and (0xdc, 0x05) and compile it successfully. This is the one provided for free by Obdev. Now, I use libusb-win32 to create an INF file, dll's and supporting files for this particular vendor ID which means that Windows should be able to recognize the usb device. I replace the micronucleus windows drivers with this one. So, to my understanding, the device id, vendor ID and dll files are used as a handshake between the computer and usb device. (to enumerate) Am I correct in this?
After doing all this, I upload the modified micronucleus code into the device, connect the device through a USB cable and open command window. I get the ubiquitous "ding" sound which means it is connected and asks for drivers. I provide the new driver location. The install succeeds and says "your new device is ready... " and so on. Now I open micronucleus command window and pass a new "blinking LED" hex file to upload. It stays there and does not go further. Why is this?
Some guesses:
1. There is something in the command line window code of micronucleus which is connecting only to particular VID.
2. The VID is present in more than one place in the actual code.
3. I am getting it all wrong which means somebody can please guide me.
micronucleus doesn't take care of anything for a running application.
I understand. It is used only as a bootloader which helps load custom firmware through *usb*.
When I use a digispark with littlewire as USBtinyISP, i it enumerates with a VID/PID which is registered by Adafruit Technologies.
I have tried littlewire, but somehow it does not work. Maybe because I have reset the reset pin to work as reset pin rather than normal IO pin. Still not sure though. By the way, are you using Digispark Arduino to program and selecting USBTinyISP, or is it that you are using AVRDude directly?
I am using AVRDude with this commands : "-pt85 -cusbtiny -Uflash:w:SIMPLEBLINK.hex:a" and failed. It says:
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny85 is 1E 93 0B
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
Clearly, it is not able to flash or recognize Littlewire firmware as USBTinyISP.
-
What are you trying to accomplish? Why are you changing the VenderID in the micronucleus bootloader?
You didn't say anything about recompiling the micronucleus command line utilities to match the VendorID, so I assume that's the problem. As far as I know, the command line tools will look for the predefined VendorID/ProductID to recognize which device to program.
-
What are you trying to accomplish? Why are you changing the VenderID in the micronucleus bootloader?
I am trying to learn how this entire concept of VUSB, USB Enumeration works.
As far as I know, the command line tools will look for the predefined VendorID/ProductID to recognize which device to program.
I did find it in micronucleus command line code. Will recompile and update you all soon.
-
Well. Failed again. This time, it did compile properly, but failed in micronucleus_lib.c with error:
I modified the vendor ID in micronucleus_lib.h to reflect:
#define MICRONUCLEUS_VENDOR_ID 0x16C0
#define MICRONUCLEUS_PRODUCT_ID 0x05DC
Assertion failed: res >= 4, file library/micronucleus_lib.c, line 66
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Why is modifying this code so difficult?
-
It seems like I have to give up learning this. The code is too difficult for my first project. For god's sake, I do not know where all they have modified it and why is it not working. Maybe the author of this micronucleus can show the way.
-
It still looks, that you are making things ways to complicated and are generating a mess:
Micronucleus and USBASP are totally different things. Its like ssh and telnet, if you are familiar with that. In ssh the server listens on port 22, the telnet server on port 23.
If you patch the telnet server to listen on port 22, and the telnet client, that it connects by default as well to port 22, they still speak telnet and no ssh!
When you are patching now micronucleus (bootloader and command line client) that they use USBASPs VID/PID you are creating a mess. Sure, YOUR micronucleus client is now able to talk to YOUR micronucleus loader, but your avrdude will fail, when you are trying to use USBASP, as that device which claims to be by VID/PID a USBASP is still a micronucleus.
The original USBASP runs on atmegas, and has no bootloader below. There is an USBASPLOADER avaliable, which can be installed on atmegas but not on attinies. This loader behaves from protocol like an USBASP-ISP, but is included in the target.
With the digispark I use littlewire very often, as I have described in the wiki (http://digistump.com/wiki/digispark/tutorials/programming#using_littlewire_as_usbtinyisp).
I use it to flash several AVRs without any problem from linux and windows, from the command line and embedded in the Arduino-IDE (which also only calls the command line).
What you have to understand, is, that a digispark with littlewire has TWO VID/PID paits, depending on its running state. In the very first seconds after reset it uses the micronucleus pair, and is ready to accept new code for itself. Later, when littlewire is started, it uses the littlewire VID/PID and behaves as ISP.
For Windows/linux it looks like, that you are connecting/disconnecting two different devices to your USB port. Both devices will get different COM-ports associated as well!
The next point, where you also need to take care, that you should use always a micronucleus client, which is has the same or a more recent version, than the loader. As the protocol has changed, older clients can't talk to newer loaders. Newer clients are however backwards compatible.
-
It seems like I have to give up learning this. The code is too difficult for my first project. For god's sake, I do not know where all they have modified it and why is it not working. Maybe the author of this micronucleus can show the way.
I don't think, that the current author will show you the way, even when he (cpldcpu) is member of this board.
It makes IT systems very unstable, when you change VID/PIDs, which are assigned to a very specific device to those of other devices, which are incompatible.
-
Then why in the device description of usbconfig.h they have mentioned this? This is what led me to start learning about VUSB and then further came to this conclusion:
#define USB_CFG_VENDOR_ID 0xD0, 0x16 /* = 0x16d0 */
/* USB vendor ID for the device, low byte first. If you have registered your
* own Vendor ID, define it here. Otherwise you may use one of obdev's free
* shared VID/PID pairs. Be sure to read USB-IDs-for-free.txt for rules!
*/
I thought open source is all about sharing and learning. If it is tied to a particular vendor and project, then it should be closed source as it cannot be modified further. Also, I have read a lot about VUSB and there are a thousand projects which use shared VID/PID. Maybe yes, I am new to this and may not understand it fully, but if I ever recreate one like this, I am sure to make it as customizable as possible such that anyone can just change VID/PID and use it for their own purposes (no harm in dreaming I guess :)
BTW gogol, thanks for all the kind assistance you provide. I know it may not have solved the problem, but atleast you are helpful.
Edit:
Just missed your previous post. Reading it to understand it properly :)
Edit again: Ok. Just read the entire thing you wrote and kind of understood. So now the conclusion is that there is no way I can change VID/PID (though the documentation says in the code). Even If I do, I need to get a VID/PID which is purchased to act as a USBTinyISP and there seems to be no free VID/PID which I can use to demonstrate at. I guess this is where it ends. Thanks for all the support. I seriously need to learn a lot yet.
-
Ok, just if someone is interested, all devices using libusb (includes USBASP also) uses the same free VID/PID pair. Here is an extract of these pairs:
PID dec (hex) | VID dec (hex) | Description of use
==============+===============+===================
1500 (0x05dc) | 5824 (0x16c0) | For Vendor Class devices with libusb
-------------------+-------------------+--------------------------------------------
1503 (0x05df) | 5824 (0x16c0) | For generic HID class devices (which are
| | NOT mice, keyboards or joysticks)
------------------+-------------------+--------------------------------------------
1505 (0x05e1) | 5824 (0x16c0) | For CDC-ACM class devices (modems)
-------------------+-------------------+--------------------------------------------
1508 (0x05e4) | 5824 (0x16c0) | For MIDI class devices
-------------------+-------------------+--------------------------------------------
Also, for ones information, micronucleus depends on libusb too I guess. I may stop today, but will keep my research on. If in case I succeed, will share it across with all of you
-
I thought open source is all about sharing and learning. If it is tied to a particular vendor and project, then it should be closed source as it cannot be modified further. Also, I have read a lot about VUSB and there are a thousand projects which use shared VID/PID. Maybe yes, I am new to this and may not understand it fully, but if I ever recreate one like this, I am sure to make it as customizable as possible such that anyone can just change VID/PID and use it for their own purposes (no harm in dreaming I guess :)
It is - which is why people are here helping you on their own time for free. It is also why even the VID/PID of Digispark/Micronucleus is open source and can be used for any compatible device. That doesn't mean people will go out of their way to make the code ready for any change anyone wants to make. You can easily change the VID/PID - you're on the right track for it - it looks like you have some other errors going on/and or are running micronucleus with your device already plugged in. You also need to recompile the command line upload tool to use the new vid pid.
All that said - as has been said - you cannot convert micronucleus into a avrdude/usbisp compatible bootloader without completely rewriting it - its not because it wasn't made to be open source "enough" - its because it is a totally different protocol that is not related in any way.
As far as littlewire - that is a separate project, that happens to run on the Digispark, is unrelated to the micronucleus bootloader and uses a vid/pid (with permission) that is owned by Adafruit - so while it is also easy to change that VID/PID pair - that is completely different then micronucleus changes.
Ok, just if someone is interested, all devices using libusb (includes USBASP also) uses the same free VID/PID pair.
They definitely do not - those are just free non-commercial ones that they "may" use. There are endless devices that use their own VID/PIDs that use libusb for their drivers - (it is after all a host side library for usb devices - and has nothing to do with the bootloader on the device itself).
I'd encourage you to keep reading and learning before making assertions about what is open and closed - thats just a good way to get people to not help you.
Welcome to our community - I hope you'll learn more about bootloaders and VUSB and come back and share/ask questions once you've absorbed the info that is out there - the VUSB site/wiki/and forums is a great place to start learning.
-
Thanks for the reply. I appreciate you responding to this.
It is - which is why people are here helping you on their own time for free. It is also why even the VID/PID of Digispark/Micronucleus is open source and can be used for any compatible device. That doesn't mean people will go out of their way to make the code ready for any change anyone wants to make.
I did not know that Micronucleus VID is opensource that can be used for any compatible device. Happy to know that your are not forcing one with "Written Permission" while using your VID/PID. (If I have understood it right from your words).
You can easily change the VID/PID - you're on the right track for it - it looks like you have some other errors going on/and or are running micronucleus with your device already plugged in. You also need to recompile the command line upload tool to use the new vid pid.
I am not sure where it is going wrong. Probably I will compile and upload the code with the new changes if it is allowed here. Somebody can suggest if it should'nt be.
I'd encourage you to keep reading and learning before making assertions about what is open and closed - thats just a good way to get people to not help you.
Welcome to our community - I hope you'll learn more about bootloaders and VUSB and come back and share/ask questions once you've absorbed the info that is out there - the VUSB site/wiki/and forums is a great place to start learning.
Thanks for the words. I will research and will sure give back to this community which is helping me so much. Always admire the power of opensource software or hardware.
-
Ok, just if someone is interested, all devices using libusb (includes USBASP also) uses the same free VID/PID pair. Here is an extract of these pairs:
PID dec (hex) | VID dec (hex) | Description of use
==============+===============+===================
1500 (0x05dc) | 5824 (0x16c0) | For Vendor Class devices with libusb
-------------------+-------------------+--------------------------------------------
1503 (0x05df) | 5824 (0x16c0) | For generic HID class devices (which are
| | NOT mice, keyboards or joysticks)
------------------+-------------------+--------------------------------------------
1505 (0x05e1) | 5824 (0x16c0) | For CDC-ACM class devices (modems)
-------------------+-------------------+--------------------------------------------
1508 (0x05e4) | 5824 (0x16c0) | For MIDI class devices
-------------------+-------------------+--------------------------------------------
Also, for ones information, micronucleus depends on libusb too I guess. I may stop today, but will keep my research on. If in case I succeed, will share it across with all of you
Of course, there are Hundreds of devices using libusb. Libusb is only a set of methods for communication with USB devices on lower levels. There are printers, smartcard readers, wireless radios and other devices, using libusb for communication.
However you can't make a digispark to an printer, by using the printers VID/PID pair!
Its the choice of the developer, if he will use libusb or if he will implement the communication by other ways.
The VID/PID Information tells the operating system, which kind of device is connected, and which drivers are needed to talk to that specific device. The protocol, which is used to talk to that device, differs totally.
You will see some manufactures, which own large ranges of PID, that they use different PID for very similar devices. In that case the driver knows only by PID, which sub-type of a device is connected, and uses all features associated with that device.
Other manufactures use the same PID for devices with much more differences. They use a more intelligent protocol, where one of the first actions is, that the device will identify itself with all usable features.
For example it would have been a possibility, that the new micronucleus 2.0 uses a different PID. But instead of that, the developer decided, to implement a version field into the protocol, so that the most current client is capable to differentiate between old and new version of the bootloader and can use therefore a slightly different protocol.
Owners of VID/PID are trying to make as sure as possible, that their VID/PID pair will not be used for any other product/protocol, because that will harm their product! If you have a system, which associates wrong drivers to a VID/PID, the original product will fail to communicate. That failure will be seen as an error of that product and will spoil the good name of that product.
Because of that, even in the OPENSOURCE world, VID/PID pairs are associated with a very specific product and protocol. Many companies allow the use of their VID/PID only for unchanged code or with prior written permission. The whole code is opensource and you are free to modify it. But it is similar to the name': If you produce a clone of a digispark, you are free to to so, but you are not free, to name that clone digispark. The same with the original Arduinos. You are free to produce a clone of the Arduino DUE, as long it has another name. The VID/PID is very similar, as it identifies a very specific device.
-
Of course, there are Hundreds of devices using libusb. Libusb is only a set of methods for communication with USB devices on lower levels. There are printers, smartcard readers, wireless radios and other devices, using libusb for communication.
However you can't make a digispark to an printer, by using the printers VID/PID pair!
Its the choice of the developer, if he will use libusb or if he will implement the communication by other ways.
For example it would have been a possibility, that the new micronucleus 2.0 uses a different PID. But instead of that, the developer decided, to implement a version field into the protocol, so that the most current client is capable to differentiate between old and new version of the bootloader and can use therefore a slightly different protocol.
Ah! Now I seem to get a flavor of this. The VID/PID for USBASP has some way to communicate with the PC and say that this protocol is for USBASP and cannot be used for USBTinyISP. Since the comments said that we can change it to free VID/PID's from Obdev, I thought simply replacing should work as it is just a series of numbers. Also, if INF file and command line code has the same ID, I thought it should work.
Because of that, even in the OPENSOURCE world, VID/PID pairs are associated with a very specific product and protocol. Many companies allow the use of their VID/PID only for unchanged code or with prior written permission. The whole code is opensource and you are free to modify it. But it is similar to the name': If you produce a clone of a digispark, you are free to to so, but you are not free, to name that clone digispark. The same with the original Arduinos. You are free to produce a clone of the Arduino DUE, as long it has another name. The VID/PID is very similar, as it identifies a very specific device.
Thank you for this. This makes it more clear about opensource and its usage.
If someone is interested, I have compiled and uploaded the files with modified VID/PID under windows. I have only modified VID/PID in micronucleus_lib.h and usbconfig.h.
-
Ah! Now I seem to get a flavor of this. The VID/PID for USBASP has some way to communicate with the PC and say that this protocol is for USBASP and cannot be used for USBTinyISP. Since the comments said that we can change it to free VID/PID's from Obdev, I thought simply replacing should work as it is just a series of numbers. Also, if INF file and command line code has the same ID, I thought it should work.
The notes in that file are from the original VUSB file - which is why they aren't more specific - the usbconfig.h file was just copied over (and changed to match the chip being used).
If someone is interested, I have compiled and uploaded the files with modified VID/PID under windows. I have only modified VID/PID in micronucleus_lib.h and usbconfig.h.
Sounds like you figured it out - great!
-
Micronucleus project founder here:
The micronucleus vid/pid pair is free for all to use. While digistump did register it, they have donated it to the community. You are welcome to use it for any piece of software which implements the micronucleus protocol, even if it doesn't use any code we have written! You don't need to ask anyone permission. Just do it.
There is no sensible reason to use a different vid/pid pair. There is no technical or cultural basis in doing so. You are simply making things less compatible, open, and interoperable. The way micronucleus identifies itself as a device that implements the micronucleus protocol is using the vid/pid pair. No micronucleus programming tool has any way to detect if a device implements the protocol other than this, so they will all ignore every other USB device. This is pretty standard behaviour for USB devices! There is no universal usb-if defined standard for programming devices like AVRs compactly. There is no more open way to do it.
Of course you are free to change the vid/pid to be proprietary if you want to.. our liberal open source licensing allows you to do that.. but there really is no reason to do so. It is kind of a weird and anticompetitive thing to do. We haven't gone to any effort to make changing those details easy, because there is no good reason to do it! Don't be a jerk. Stop breaking the standards!
-
Hi Bluebie,
back from a longer break? Glad to see you and your valuable comments again!