Hi Alex, >>> I think the endpoint 0 is different between bootloader (dfu) and the >>> application (atusb). Maybe then add this functionality for the >>> bootloader only. >> >> If you add it to the boot loader, then you need to flash your >> enhanced boot loader via in-circuit programming (or find a way >> to bypass the write protection. NB: no such way should exist.) >> Not everyone may find that convenient ;) >> >> I'd leave the boot loader as it is and just add a new operation >> to the application part of the firmware. >> > > yea, this was just an idea because Marcel said: > > "... you might want to push that device into a special mode to allow > programming of these settings" > > and that's for me the dfu mode. My idea was just make the "new > operation" accessable in dfu endpoint only. > > Nevertheless I am also fine with normal application operation, or making > some special bus access cycles to get into "privileged mode" or > something else, everything is possible. I would not do that at runtime mode unless you have an easy way to re-enmuerate that device. Reason is that changing settings like the address should be only be done when the device is in a special mode. So at minimum that needs to be when the device is powered off or something. And if you change the address it re-enumerates again so that userspace can know that the address has changed. For a permanent address, that is normally done in a special mode when you provision it. Be that DFU mode or some other mode you push the device into. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
