I suggest looking at Micronucleus, I don’t plan to maintain this boot loader in the future.

Yes, this is definitly possible. In the previous version of MicroVNC I was using a modified windows VNC server. I haven’t tried the new version with any standard server yet, but if you find the right server to use, and probably some minor modifications to the client code, it will probably work. You need to force the server to use hextile mode, and nothing fancier, and probably just skip authentication or use a simple method. Hopefully the android server allows these options.

The way the client code is written right now, it will get updates as fast as it can from the server. This may not be fast enough to look good depending on the size of the screen and update frequency.

Good luck, and please post back if you end up using it.

Louis

I came across your µVNC project whilst doing online research for getting a an android device to export a screen/widget/desktop to a remote device; preferably atmel-µC driven

I had been using droid-VNC-server whilst doing some app development; so I know libVNC is already available for android. But how to interface it with a µC … and google sent me here

You wrote a custom VNCserver (Frame Server) to push image updates to the µC device, but is possible to have the µVNC client talk to a standard VNCserver ? Possibly limiting µC client to scheduled update cycles for screen refreshes …

grtz,
Gert

see the section labeled “Which clock rate should I choose?”

You could run at 12MHz, but you’d need an external crystal, taking up two valuable pins on the tiny85.

A couple of examples:
http://vusb.wikidot.com/hardware
http://forums.obdev.at/viewtopic.php?f=8&t=3274

Thanks again.

-John

It looks like the issue you’re seeing “a device attached to the system is not functioning” might be fixed by something I found last week but haven’t had time to commit yet to git, take a look at the issue here:
https://github.com/embedded-creations/USBaspLoader-tiny85/issues/1

More information on my hardware is here: http://candleplus.blogspot.com/

When trying to upload, I got similar messages that others received:

…
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e930b
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file “C:\Users\John\AppData\Local\Temp\build7826448490907735431.tmp\candle.cpp.hex”
avrdude: writing flash (1882 bytes):

Writing | #avrdude: error: usbasp_transmit: usb_control_msg: sending control message failed, win error: A device attached to the system is not functioning.

avrdude: error: usbasp_transmit: usb_control_msg: sending control message failed, win error: A device attached to the system is not functioning.

avrdude: error: wrong count at writing ffffffff
################################################# | 100% 2.24s

avrdude: 1882 bytes of flash written
avrdude: verifying flash memory against C:\Users\John\AppData\Local\Temp\build7826448490907735431.tmp\candle.cpp.hex:
avrdude: load data flash data from input file C:\Users\John\AppData\Local\Temp\build7826448490907735431.tmp\candle.cpp.hex:
avrdude: input file C:\Users\John\AppData\Local\Temp\build7826448490907735431.tmp\candle.cpp.hex contains 1882 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.16s

avrdude: verifying …
avrdude: verification error, first mismatch at byte 0×0040
0×00 != 0xff
avrdude: verification error; content mismatch

avrdude done. Thank you.

Aside from that, it should be as simple as changing the #define for the D+ pin.