Idea of improvement: USB code factorization between bootloader and sketch

[RC Navy]

Hi all,

Please, correct me if I'm wrong:

I started to play with DigiUSB library: it works fine (Thanks again to Bluebie for her digiterm application).
But, I believe it's stupid to not benefit of the USB code already present in the bootloader.

I also noticed usbdrvasm.S monopolizes the pin change interrupt vector, so, it's currently impossible to use Pin Change for other purposes whilst using DigiUSB library.
I suggest to centralize the pin change interrupt Manager in a library/function such as TinyPinChange already presented here: http://digistump.com/board/index.php/topic,689.0.html (TinyPinChange library is in the attached zip)
As the ATtiny85 is a little micro-controller, the number of ISR to record can reasonably be limited to 3 or 4 (hardcoded).

The changes I suggest: modify  usbdrvasm.S:
1) to not hardcode the pinchange interrupt vector in order to allow the pin change interrupt sharing
2) to include the Pin Change Manager
3) to declare a vector (at fixed address) in the bootloader to allow the user arduino sketch to call the related bootloader USB functions and the Pin Change Manager

This will allow to save lots of precious flash memory.

Unfortunatly, I'm not very familiar with AVR assembler (only with "vintage" intel 51 assembler).

What do you think about this idea?

Regards,

RC Navy.

[Bluebie]

The USB driver is already pushed nearly to breaking point so far as interrupt latency goes because of the interrupt hooking mechanism in the bootloader (which is definitely required), so adding more abstraction between the pin change interrupt vector and the USB library may very well not work at all.


As for referencing the USB library in the bootloader from sketches, this is technically plausible but introduces tight coupling (content coupling aka pathological coupling) in the architecture - users should be free to replace and update their bootloader to other types, or upload their sketches to raw chips through a programmer tool. This change would break all that stuff and add a lot of complexity and potentially be a disaster if we ever need to patch a bug in the bootloader. I've already patched several bugs in the bootloader and released many updates with extra functionality or improved stability or more user program space.


Most importantly, micronucleus is open source and i'm not paid to maintain it, so I only do things which are interesting to me or useful in my own projects, and neither of these are (I'm not a computer scientist or intrinsically interested in coding or hacks, I just write code to enable my art installations and interactive objects - it is a chore)

[RC Navy]

Hi Bluebie,

If an idea brings more advantages than drawbacks, it's a good idea. In this case, after your argumentation it seems to be a bad idea...

Regards,

RC Navy