As I understand, Keyboard and Mouse libraries are limited to the "Leonardo". This is because the processor supports USB interface. However, the UNO also has an Atmel processor which supports the USB interface. Has anyone looked at compatible libraries for the UNO?
I known that the USB interface is on the main chip in the Leonardo and on a secondary chip on the UNO. But the interface is still there. I see two approaches, though there may be others.
Use the existing Serial interface at highest possible speed to exchange data and control information.
Use the SPI interface. This approach may be more problematic in that you may want to use that interface of other things in your project such as LCD displays and such.
Has anyone looked at compatible libraries for the UNO?
You can do that stuff on the UNO too, but you have to program the ATmega16U2 (or 8U2 depending on the revision) using it's ICSP (which has no headers by default). You have to keep the code small to fit in it's memory and you might loose the possibility to do the standard way of programming the Arduino if you don't include the default serial profile. So the Leonardo is definitely the easier way.
Use the existing Serial interface at highest possible speed to exchange data and control information.
Use the SPI interface. This approach may be more problematic in that you may want to use that interface of other things in your project such as LCD displays and such.
What do you wanna achieve with these approaches? Are they for the communication between the ATmega16U2 and the ATmega328p on the UNO board? If so, SPI won't work as the SPI lines are not connected. You may use the ICSP header of both but you're still missing the SS line then.
pylon:
You can do that stuff on the UNO too, but you have to program the ATmega16U2 (or 8U2 depending on the revision)...
The thought was to use the 16U2/8U2 to handle the data flow. Once programmed, it would not need to be changed except to fix bugs and add enhancements.
The idea is to not use the USART for typical serial communications. It would be more of a data channel. Through this channel, the main processor would control the slave processor (16U2). The slave processor would implement the USB devices (Serial, Keyboard, Mouse, ...). The channel would function as fast as possible so as to transfer the data with minimum lag. The slave processor would have minimum logic, only that required to implement the logical devices.
Most of the house keeping would be performed on the main processor. Data packets of 2-5 bytes would be sent and received in lieu of direct register manipulations. The methods of Serial.begin, Keyboard.press and Mouse.move would all be abstracted and implemented by the same slave processor communications protocol.
Keep in mind, that you have to implement some kind of serial layer to be able to upload sketches to the main processor. Sure, you could do that by the ICSP too but this is not very convenient.
Take care you have a 16U2 (Rev 3) to have enough flash storage available. Then you have to design your serial protocol to control the features you implement on the 16U2.
That is a good point. The bootloader would not know about the abstractions. Therefore. the 16U2 would need to start up is single function mode (USB to Serial). This would allow the flashing of sketches. When the sketch initializes, it could optionally add the abstraction layer.
I'm not sure how the handshaking and state tracking would work.
The differentiation between sketch uploading and multi mode state is quite easy: for the first few seconds after reset/power up you're in sketch upload mode, multi protocol afterwards. Alternatively you can add a special command sequence, that must be sent by the main processor to put the 16U2 in multi protocol mode.