There are many fun peripherials that you can connect to a RPi but PC users are not left out either

• attiny85 <a href="http://www.banggood.com/ATTINY85-Mini-Usb-MCU-Development-Board-For-Arduino-p-971122.html"><img height="48" src="http://img2.banggood.com/thumb/large/2014/xiemeijuan/03/SKU207366/SKU207366-3.jpg"/></a> has SPI and i2c interface so could be possibly used as USB<->i2c or USB<->SPI bridge. Unfortunately, the USB support needs some non-standard timings so there is quite a bit of integration and debugging needed.

  • and there is a patch floating around to make devicetree available on non-devicetree platforms so with this you could enjoy all the awesomeness of devicetree -configured peripherials on your PC

• i2c OLED displays <a href="https://learn.adafruit.com/ssd1306-oled-displays-with-raspberry-pi-and-beaglebone-black/overview"> <img height="48" src="https://cdn-learn.adafruit.com/guides/images/000/000/633/medium800/DSC00469_copy.jpg?1448301844"/></a> work nicely with an Arduino but for some reason fail with an A10S Olinuxino so there is some room for debugging the sunxi i2c drivers.

• SPI TFT displays <a href="https://plus.google.com/+JensHauke/posts/JYDeuQ6z7jH"><img height="48" src="https://lh3.googleusercontent.com/-ytJsEesueJU/VZVr_ZUm0uI/AAAAAAAABVA/wbUFZcickWw/w530-h398-p-rw/esp8266_ili9163c_hw.jpg"/></a>work quite nicely with any board including Arduino, ESP boards and ARM computers. The specific issue with ARM mainline is devicetree or similar integration to support the display.

• RC522 <a href="http://shop.tavir.hu/product_info.php/rfid-mifare-rfid-iroolvaso-funduino-mfrc522-p-197"><img height="48" src="http://shop.tavir.hu/images/sen-rfid-rc522-red-1.jpg"/></a>is an inexpensive RFID reader which can be obtained for around $2 from Chinese vendors. The problem is the device is not very easy to interface with. I can run the Arduino sketches that use the reader on a Linux box but have not seen a decent driver for it so far

• place an accelerometer on a desktop screen and have the screen orientation updated automagically in system when it is rotated.

• ...

Tried to build ATtiny85 USB<->I2C bridge using a Digispark clone. The Arduino IDE packaging is not in very good shape on SUSE so started by making it possible to install Arduino on any platform by packaging the bundled binaries. The changes are in the process of getting submitted in CrossToolchain:avr and other repositories.

After some debugging I finally found that there is a board definition which defines several arguments including expected CPU clock speed (which is used to calculate delay loops and such) and 'fuse' bits which define actual CPU clock source and settings (which are not programmed at all by uploading using the micronucleus bootloader) as well as some other random parameters which I don't use. I modified the board definition to set the expected clock correctly to 16.5MHz as set by micronucleus.

I don't really understand the 16.5MHz clock choice. This seems the clock most commonly used with V-USB for some reason and it is what micronucleus itself uses so when you upload your sketch using micronucleus you inherit this clock. The CPU spec says something like it can do 1-8MHz at 1.8V and 8-20MHz at 4.5-5V so doing 16.5MHz at 3.3V looks reasonable but it is not something the manufacturer guarantees as working. The USB clock is 1.5MHz so you need a multiple of that. The canonical V-USB solution is to run at 5V and use resistors/diodes/... to get the data lines down to 3.3V when it does not work with 5V. Digispark uses 3.3V so does not have this problem but is basically running overclocked.

There is V-USB and many variants of it that can be used to implement USB in software on ATtiny or ATmega but the canonical implementation uses different pins for USB from what Digistump does. The reason is probably to use INT0 which is somehow special. Looking at the datasheet it seems on ATtiny85 the INT0 can be triggered by level change on one pin and level change on any other pin triggers the other external interrupt when configured. So INT0 is probably picked to avoid interrupt sharing between the library and user program.

Nonetheless, there is V-USB variant ported to Digispark by the manufacturer Digistump. Unfortunately, I could not transfer more than a single byte in an USB transfer with this V-USB variant. Some examples work better and some worse but did not get anything to transfer some reasonable amount of data in both directions. The i2c-tiny-usb is built on top of the canonical library so needs to be ported/rebuilt/...