Bootloader for AVR-ATtinys with one pin photodiode optical interface - Page 1
Forum section: electronics / general

author: eneuro
author_rank: Super Contributor
timestamp: June 02, 2015, 11:25:00 pm
content: Hello,Maybe someone used this 550 bytesTinySafeBoot - A tiny and safe Bootloader for AVR-ATtinys and ATmegasand tried something else than this claimedQuoteI mean, one AVR only pin photodiode optical interface, to be able send new software to AVR device without any wiring just using "smartphone", tablet or other decent illumination light source using this bootloader?It looks like this TSB for ATtiny can update itself, which sounds nice, but will it work using different light signals instead of wires using only one wire more and one way communication from light source to this photodiode or phototransistor enabled one MPU pin ?Update: Nope, this simpleCI-Vexample interfacehttp://www.qsl.net/g3vgr/civ.htmlneeds bidirectional communication, but unfortunatelly with LCD or cell phone screen no way to send data in both directions-only out of LCD/phone/tablet, so something more fancy needed or changed simplified source code of this TSB needed to be able only Tx data from LCD and Rx on MPU pin, eg. using something aka Morse code interface, etc, so probably only TSB genaral concepts will be usable and we'll try design custom TinyLightBoot (TLB) based on TSB flash memory adresses, to be able use TSB when its oryginal PC software available andCI-VOne Wire interface-while in production environment TLB to ensure galvanic insulation between MPUs and end users handheld devices, so it is time try toTSB source code to support aka Morse code communication using only one pin and MPU pin in input mode after hardware reset with oryginal TSB concept in mind to be compatible with flash address spaces for boot loader...

author: ralphd
author_rank: Frequent Contributor
timestamp: June 03, 2015, 12:37:32 am
content: This circuit lets you program an avr using a headphone jack.https://hackaday.io/project/4926-cheepit-sparrow-dev-boards-for-smartphones

author: eneuro
author_rank: Super Contributor
timestamp: June 03, 2015, 01:14:22 am
content: Quote from: ralphd on June 03, 2015, 12:37:32 amYep, but I wouldn't like to mess on some HV PCBs with connecting handheld device without galvanic insulation between them, so wire connection is not an option, especially while I'd like program those devices directly from my WWW page where end user will be able to set some software options and get software update directly for his device with AVR LOCKBITS set to MODE 3 for enhanced security to prevent reading MPU memory using ISP-only bootloader protocol and MPU teradown by service authorized person will be able use wires to connect to MPU, but still with a few kV insulation between light software sender and photodiode/phototransistor with floating power supply attachable to given MPU bootloader pin, to ensure no chance for any electric shocks due to crappy handheld devices wall socket power supply, etc.

author: ralphd
author_rank: Frequent Contributor
timestamp: June 03, 2015, 02:07:25 am
content: Picoboot could work in a one-way mode. Just change the avrdude patch to time the page write commands instead of waiting for the ack.https://github.com/nerdralph/picobootAnd its 1/8th the size of tsb...

author: matseng
author_rank: Frequent Contributor
timestamp: June 03, 2015, 04:27:34 am
content: Quote from: eneuro on June 03, 2015, 01:14:22 amThat sounds very uber paranoid - do you usually also use an additional isolation transformer between the wall and your cell phone charger for "that extra protection"? O0

author: eneuro
author_rank: Super Contributor
timestamp: June 03, 2015, 06:17:32 am
content: Quote from: matseng on June 03, 2015, 04:27:34 amI don't use wall phone chargers at all, while in general my cell phone is powered from.... 12V car starter battery using 4.1V voltage regulator and... I didn't need charge this phone for a few months right nowWhen I need make a call can connect it to any voltage source <25VDC including solar PV panels etc

author: eneuro
author_rank: Super Contributor
timestamp: June 03, 2015, 06:38:34 am
content: Quote from: ralphd on June 03, 2015, 02:07:25 amDo you mean this AVR dude interfacepicobootsource?https://github.com/nerdralph/picoboot/blob/master/avrdude/picoboot.corpicobootAVR dude configuration file ?https://github.com/nerdralph/picoboot/blob/master/avrdude/avrdude.confAnyway, thanks for this link, while probably will be able write AVR dude extension for any bootloader right nowUpdate: After review AVR dude picoboot extension code, I think that adding newCode:connection_type = lightin AVR dude configuration file could be nice feature to enable in a transparent way light based one way one direction MPU programming.QuoteThan during opening simply check for light connection passed from AVRdude configuration file and adjust communication with light one way one direction bootloader .Code:static int picoboot_open(PROGRAMMER * pgm, char * port){DEBUG("PICOBOOT: picoboot_open()\n");strcpy(pgm->port, port);// TODO: pgm->connection_type// if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {// return -1;}return -1;...}However, I might have other requirements in my bootloader and strong pasword protection is a must, not only for security reasons, but to be able do something similar to mentioned above: choose which AVR MPU will be programmed by setting passwords and device IDs than send light beam and let it choose correct MPU for reflashing, so at list some password protection is needed.Additionally, not only full reflash mode might be needed, but changing part of MPU flash data and make at boot time checksums of whole flash for program integrity, so aging MPU with changed flash can be detected, so easy to detect any memory failures and in this case bootloader will stop running corrupted code, so probably I need glue a few small bootloaders together and make custom which will fit my requirements better, designed for those kind of projects.

author: Psi
author_rank: Super Contributor
timestamp: June 03, 2015, 07:40:48 am
content: I've made some programmable led ID tags that were reprogrammable from a light source.You could change the display message by holding it to a PC/phone screen running some software.It was only updating the eeprom not the actual code and at 60hz with manchester encoding you only get 30 bit per sec, far too slow for firmware.To get around the one way comms issue i had it sending all packets in a loop and the ID tag would display the message once it got all packets correctly

author: eneuro
author_rank: Super Contributor
timestamp: June 03, 2015, 11:06:44 am
content: Quote from: Psi on June 03, 2015, 07:40:48 amThank you, I forgot about refresh rates, while was thinking about maybe even simplier aka Morse code encoding like this:Code:00000001110101011101010111010....1110100000000where I send one byte separeted each other by zeroes meaning also end of communication and bit one is represented by 3 times longer logical high (1) sequence, separated by low level (1/3 of the time on one ) and also bit 0 send as 1's but at 3 times shorter perdiod of time than bit one in this aka Morse code encodingThis way at low speed it can be even redable by human, but probably due to this quite low refresh rates it might be real issue to flash AVR, because of Morse code will be of course much slower than in manchester encoding you sugested, so yep it happends sometimesHowever, when we assume ATTiny85 8KB flash program size, than.... we need send only 8192 bytes, which is ~81920 bits (assuming additional 2 bits in each byte for CRC) than at 30 bit/s... 45 minutes about half hour without CRC in each byte, so not to practical sometimes, but well, not every AVR ATTiny MPU will use full 8KB program size and additionaly we do not have to do to much during such AVR light programing-can leave device and let it go, than only after succesfull reflash bootloader will allow MPU run this send code, in some cases maybe it could be acceptable in final product (not during development, but we can use in this case some simply PC interface at much higher speed, eg. diode connected to PCB USB port driven from PC software, etc).Or send customer with our product small gadzet-LED PWM lamp connected to USB and tell him it can use this toy to reflash at much higher speeds.So, I do not dismis this idea, we'll see what happends and how it will perform

author: ralphd
author_rank: Frequent Contributor
timestamp: June 03, 2015, 02:24:17 pm
content: If you want a secure password protection with one way communication, I think you'll have to use pki, which will add significant overhead to a bootloader.

author: eneuro
author_rank: Super Contributor
timestamp: June 03, 2015, 04:14:23 pm
content: Strong passwords will be next step, now making software to connect from Linux using UCB to small ATTiny85 based PCB with white LED powered from USB to be able speed up AVR programming using light interface mentioned aboveDesigning small PCB based on this schematics below fromV-USB with ATtiny45 / ATtiny85 without a crystal, while succesfully compiled sample code to toggle LED on this dongle of course without FTDI fake chipsFirst have to ensure this thing above will notmy PC USBWhat do you think to add additional resistors betwen USB D+/D- pins and zeners 3V6?Probably will use TL431I voltage reference to power up ATTiny 85 from this USB port and lower down voltage on ATTiny to 3.6V and drive LED from USB+5V using NPN transistor based on MPU outpin pin, while I do not like idea conect MPU directly to USB+5V?? without any voltage regulator.Zeners probably not needed no more when I will lower down MPU voltage to 3.3V.This will be proove of concept only, so do not care too much now about this quick PC USB to MPU hack with a few additional components.Than will trysample bootloaders source code (combine TSB with PICOBOOT to support AVR light programing interface...maybe with AVRDude support shown above...

author: ralphd
author_rank: Frequent Contributor
timestamp: June 03, 2015, 06:01:05 pm
content: Its better to use a 3.3 or 3.6V supply rather than 5V with zeners.http://nerdralph.blogspot.ca/2015/01/usb-interfacing-for-avr-microcontrollers.html

author: eneuro
author_rank: Super Contributor
timestamp: June 04, 2015, 09:57:17 pm
content: Quote from: ralphd on June 03, 2015, 06:01:05 pmI have 3.44Vcc without any zeners, but problem is that firmware written for this V-USB from the link above probably expects (wants) 16MHz frequency, while they wrote something like this (this will work for sure on 5Vcc)Fuse bitsOh and one last thing – the fuse bits need of course be changed.Remove the 8x clock divider and switch to High Frequency PLL clock (CKSEL=0001) with slowly rising power (SUT=10). For ATtiny45/85 this should result in low fuse byte of 0xE1. You might also consider 2.7 V brown-out detection, making the high byte 0xDD:avrdude -c usbtiny -p attiny85 -U lfuse:w:0xe1:m -U hfuse:w:0xdd:mThose settings (required for oryginal code to work) leads to 16MHz system clock: 64MHz PLL divided by 4:When we take into account clock frequency vs VCC:http://www.atmel.com/Images/Atmel-7669-ATtiny25-45-85-Appendix-B-Automotive-Specification-at-1.8V_Datasheet.pdfthan it looks like at Vcc between 3.3V - 3.6V we can have max 8MHz clockThe same on those fugures: active current vs frequency:So, probably sample oryginal source code included for V-USB implementation need to be changed, to support maximum 8MHz ATTiny @ 3.44Vcc I have, while unsure if it will work without any tweaking oryginal MPU source code for V-USBhttp://www.avrfreaks.net/forum/attiny-16mhzYep, they expect 16MHz MPU, so probably @ 3.44Vcc it is not possible, so that i swhy they uses USB 5V as VCC and 3.6V zeners, so probably description is wrong and oryginal included codehttp://codeandlife.com/data/usb_tiny85_20120222.zipwon't work at 3.3V since we have 8MHz max at this Vcc

author: ralphd
author_rank: Frequent Contributor
timestamp: June 04, 2015, 11:59:06 pm
content: While technically overclocked, all the AVR MCUs Ive used work fine at 16Mhz with a 3.3V supply.If you are not comfortable with that, you could use the 12Mhz mode with the RC oscillator. Tim documented how to do this on his blog cpldcpu.wordpress.com.

author: ralphd
author_rank: Frequent Contributor
timestamp: June 05, 2015, 12:02:39 am
content: Just looked at the tiny13a datasheet figure 19-2. Its speced for up to 13Mhz at 3.3V.

author: Marco
author_rank: Super Contributor
timestamp: June 05, 2015, 12:38:13 am
content: Quote from: ralphd on June 03, 2015, 02:24:17 pmThe tiny is pretty much a lost cause at that point, NanoECC takes 6 kB.

author: Psi
author_rank: Super Contributor
timestamp: June 05, 2015, 07:21:00 am
content: One issue I had was the LCD backlight pwm which is usually 100 - 400hzIt gets in the way of the data. You need to do some analog filtering of the signal first. An envelope worked best for me

author: eneuro
author_rank: Super Contributor
timestamp: July 14, 2015, 09:15:13 pm
content: Quote from: ralphd on June 03, 2015, 02:24:17 pmNow, just trying to figureout what is going on inpicobootcode and... realized that it uses serial port under AVRdude and USI serial on AVR?Inpicoboot.Si looks like AVR RESET pin is used as boot pin?Code:/* PINB5 = Reset on ATtinyx5 */#define BOOTPIN PINB5Do I have to have Reset disabled, since there is something like this in this code, so to be able run this code with BOOTPIN=PINB5 (Reset pulled up to VCC via 10k most often) on ATTiny85, I have to disable reset pin or change this BOOTPIN for another one, I guessCode:BootStart:; sbi PORTB, BOOTPIN ; enable pullupsbic PINB, BOOTPIN ; run bootloader if BOOTPIN lowrjmp AppStart ; jump to application codeHowever, it looks like USI is used for serial communication, so I will have to completly change this code as well as conditions when bootloader is activated -add password protection thereUpdate: Nope, it is never easy decode assembler code especially, when Makefile is used and no clear inforamtion which assembler source files are compiledInboot.Swe have:Code:#define BOOTPIN PINB0so I do not know, but according to project description there:http://code.google.com/p/picoboot/Code:The bootloader is started when a serial idle signal is detected on the Rx pin (PB0 on the ATtiny84 and ATtiny85, PD0 on the ATtiny88).Probably PB0 is used for ATTiny85.BTW: I've changed Makefile to use 1MHz clock and set device asattiny85.I will try make a few changes to this software and we'll see what happends-it should now run on my ATTiny85 with current fuses settings -1MHz clock by default changed to 8Mhz in main softwareStill a long way to go for custom bootloaderHow did you managed make it so smallCode:avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o picobootSerial.elf picobootSerial.oIts address in MPU flash memory 0x1FBE means on 8KB ATTiny85, that it i slocated at last... 8192?8126=66 bytes?

author: eneuro
author_rank: Super Contributor
timestamp: July 15, 2015, 12:01:17 am
content: Quote from: ralphd on June 03, 2015, 02:07:25 amOK, finally I've found that soft UART is used inpicobootSerial.SSo, it looks like avrdude protocol is like described inpicobootSerial.Sheader:Code:* The protocol is pairs of 4-byte frames:* data lo, data hi, FCS (EOR), command* data from the first frame is copied r0, r1. For the next frame,* data is copied to Z, command is written to SPMCSR, followed* by the spm instruction. The command for the first fame must be 0.However, since it looks like:Code:* bootloader acks to programmer with 0xC0 after each byteprobably I need remove this part of code in the case of my light interface (not serial) since I can't give any feedback toavrdudeprogrammer and change avrdude config and recompile extension to be able in avrdude do not wait for ack from bootloaderSo, now I've created my custom bootloader code based on picobootSerial.S example and hopefully it compilesCode:$ makeavr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -x assembler-with-cpp -c eneurobootlight.S -o eneurobootlight.oavr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o eneurobootlight.elf eneurobootlight.oavr-objcopy -O ihex eneurobootlight.elf eneurobootlight.hexI need to change this code to read data bytes from PCavrdudecustom extension in a diferent way just using one of AVR pins connected to photodiode and PC driving this photodiode using light and customavrdudeextension, since supported methods are PC ports parellel/serial/usbIt will be fun to use laser light beam to reflash AVR ATTiny85 from quit elong distance if I manage this changed code to work

author: eneuro
author_rank: Super Contributor
timestamp: July 15, 2015, 10:13:41 am
content: Yep, succesfully added my new programer typeeneurobootlighttoavrdude version 6.1inpgm_type.cand installed new version doesn't complain about my new programmer type:Code:$ avrdude -c eneurobootlightavrdude: syntax error at /opt/avrdude-6.1-x64/etc/avrdude.conf:360however it doesn't like my new connection type:light$ avrdude -c ?avrdude: syntax error at /opt/avrdude-6.1-x64/etc/avrdude.conf:360Code:programmerid = "eneurobootlight";desc = "Eneuro boot light programmer";type = "eneurobootlight";###baudrate = 10000; # 230400@8Mhz, 460800@16connection_type = light;###connection_type = serial;;Update: Changed this connection type to:serialsince despite it is light interface, still it is some kind of serial comunication, so that is fine-now recompiledavrdudenicely shows my new programmer:eneurobootlightCode:$ avrdude -c ?...eneurobootlight = Eneuro boot light programmerere-isp-avr = ERE ISP-AVR <http://www.ere.co.th/download/sch050713.pdf>flip1 = FLIP USB DFU protocol version 1 (doc7618)flip2 = FLIP USB DFU protocol version 2 (AVR4023)frank-stk200 = Frank STK200ft232r = FT232R Synchronous BitBangft245r = FT245R Synchronous BitBang...It does nothing for the moment since I have to implement this light avrdude interface, but it looks like I've properly setup avrdude for my new custom light programmer-there is no/dev/lightdevice of courseCode:$ avrdude -c eneurobootlight -p t85 -P /dev/lightavrdude: TODO: IMPLEMENT LIGHT interface for port: /dev/light !!!avrdude done. Thank you.

author: eneuro
author_rank: Super Contributor
timestamp: July 15, 2015, 01:04:30 pm
content: Tried implement dummy simulated flash write and log what avrdude tries to send to MPU using my customeneurobootlightprogrammer:Code:$avrdude -v -v -c eneurobootlight -p attiny85 -P screen -U flash:w:attiny85-light-test.hexandavrdudesays among other stuff to check connections...Double check connections and try again, or use -F to overridethis check....Unfortunatelly, there will be no eelctric connection at allCode:Programmer Type : eneurobootlightDescription : Eneuro boot light programmeravrdude: programmer operation not supportedENEUROBOOTLIGHT: eneurobootlight_not_implemented_1()ENEUROBOOTLIGHT: eneurobootlight_initialize()ENEUROBOOTLIGHT: eneurobootlight_send_frame()ENEUROBOOTLIGHT: eneurobootlight_send_frame()avrdude: frame bytes: 0x00 0x00 0x00 0x00avrdude: eneurobootlight_send_frame(): (a) protocol error, expect ACK=0xc0c0c0c0, resp=0x00000000avrdude: initialization failed, rc=-2Double check connections and try again, or use -F to overridethis check.avrdude: programmer operation not supportedENEUROBOOTLIGHT: eneurobootlight_close()avrdude: close: port: screenavrdude done. Thank you.I need to make happyavrdudethat it will never get what expects from MPU, especially ACK

author: eneuro
author_rank: Super Contributor
timestamp: July 15, 2015, 02:07:37 pm
content: Now much better -avrdude return of course fake hardcoded device signature since we can't read anything from MPU and attempt to verify written bytes fails, but that is fine for the momentCode:$ avrdude -c eneurobootlight -p attiny85 -P screen -U flash:w:attiny85-light-test.hexavrdude: open: port: screen baudrate: 10000avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.00savrdude: Device signature = 0x1e2a00avrdude: programmer operation not supportedavrdude: programmer operation not supportedavrdude: NOTE: "flash" memory has been specified, an erase cycle will be performedTo disable this feature, specify the -D option.avrdude: erasing chipavrdude: reading input file "attiny85-light-test.hex"avrdude: input file attiny85-light-test.hex auto detected as Intel Hexavrdude: writing flash (334 bytes):Writing | ################################################## | 100% 0.19savrdude: 334 bytes of flash writtenavrdude: verifying flash memory against attiny85-light-test.hex:avrdude: load data flash data from input file attiny85-light-test.hex:avrdude: input file attiny85-light-test.hex auto detected as Intel Hexavrdude: input file attiny85-light-test.hex contains 334 bytesavrdude: reading on-chip flash data:Reading | avrdude: programmer operation not supportedavr_read(): error reading address 0x0000read operation not supported for memory "flash"avrdude: failed to read all of flash memory, rc=-2avrdude: programmer operation not supportedavrdude: close: port: screenavrdude done. Thank you.We were able to log all bytes send to bootloader in 64 bytes pages (flash writes )which is nice-it will help debug AVR bootloader assembler codeCode:avrdude: eneurobootlight: frame bytes: 0x00 0x00 0x00 0x00avrdude: eneurobootlight: paged write: address: 0x0000 bytes: 64avrdude: eneurobootlight: frame bytes: 0xDF 0xCF 0x10 0x00avrdude: eneurobootlight: frame bytes: 0x00 0x00 0x01 0x01avrdude: eneurobootlight: frame bytes: 0x28 0xC0 0xE8 0x00avrdude: eneurobootlight: frame bytes: 0x02 0x00 0x03 0x01avrdude: eneurobootlight: frame bytes: 0x27 0xC0 0xE7 0x00avrdude: eneurobootlight: frame bytes: 0x04 0x00 0x05 0x01avrdude: eneurobootlight: frame bytes: 0x26 0xC0 0xE6 0x00...avrdude: eneurobootlight: frame bytes: 0x00 0x00 0x03 0x03avrdude: eneurobootlight: frame bytes: 0x00 0x00 0x05 0x05avrdude: eneurobootlight: paged write: address: 0x0040 bytes: 64avrdude: eneurobootlight: frame bytes: 0x10 0xE0 0xF0 0x00avrdude: eneurobootlight: frame bytes: 0x40 0x00 0x41 0x01...avrdude: eneurobootlight: frame bytes: 0x00 0x01 0x02 0x03avrdude: eneurobootlight: frame bytes: 0x00 0x01 0x04 0x05avrdude: eneurobootlight: paged write: address: 0x0140 bytes: 64avrdude: eneurobootlight: frame bytes: 0x46 0x55 0x13 0x00...avrdude: eneurobootlight: frame bytes: 0xFF 0xFF 0x00 0x00avrdude: eneurobootlight: frame bytes: 0x7E 0x01 0x7E 0x01avrdude: eneurobootlight: frame bytes: 0x40 0x01 0x42 0x03avrdude: eneurobootlight: frame bytes: 0x40 0x01 0x44 0x05That is interesting-to program 334 bytes of flash, it looks like we need send ~4.75 ~5 times more bytes to bootloaderCode:avrdude: close: port: screen bytes: send: 1588it can be killer and in practice it will be difficult send all AVR MPU code using LCD screen light flashes, but it will depend on application and sometimes we'll let enduser apply only patches to configuration data, not code itself, so amount of data can be lowAnyway, time to change AVR bootloader itself and let it talk with LCD screen or other light source on one MPU pin using some kind of light sensorIt could be perfect have on this pin LED as output as well as light sensing, so lets try design such tricky circuit and implement it in new bootloader assembler code...

author: eneuro
author_rank: Super Contributor
timestamp: July 15, 2015, 10:14:36 pm
content: There is some progress, but yep I had to look again and again into AVR assembler RJMP instruction descriptionhttp://www.atmel.com/webdoc/avrassembler/avrassembler.wb_RJMP.htmwhile I had to write small disassembly utility to be able understad this hardcoded RJMP statements in examplepicobootavrdude implementationCode:avrdude: eneurobootlight: flash address: oryginal appstart: 0xC00E changed appstart: 0xCFEE reset vector: 0xCFDF virtual reset vector addr: 0x1FC0avrdude: eneurobootlight: paged write: page: 0 address: 0x0000 bytes: 64avrdude: eneurobootlight: frame bytes: 0xDF 0xCF 0x10 0x00 flash data: 0xCFDFavrdude: eneurobootlight: frame bytes: 0x00 0x00 0x01 0x01 flash addr: 0x0000Compiled sample AVR code (classic Hello AVR I'd like to use to test bootloader-diode blinking on PB1 ATTiny85 pin ay 1Hz at 8MHz clock) created code like shown above for first flash page, where at address 0x0000 reset vector was: 0xC00E, which means (thanks to disassemblers and Atmel AVR instruction set documentation linked above):Code:$ avr-rjmp 0xC00EAVR assembler RJMP code: 0xC00E rjmp: +0x001E (+28)So, nothing fancy- so far so good-classic AVR MPU code-oryginal reset verctor jumps somwhere to main program as RJMP instruction is: 0xC00E decoded above.However, as we can see by analysis of whatpicobootdoes the trick and change this oryginal restet vector during avrdude programming to point to his own code, but... lets see what we get when we'll try disassemble thisIt changes this application reset vector code from oryginal 0xC00E, to...0xCFDF, which means:Code:$ avr-rjmp 0xCFDFAVR assembler RJMP code: 0xCFDF rjmp: -0x0040 (-66)Yes, jump 66 bytes back, but... we are at first flash program memory adress 0x0000We know from bootloader complation that bootloader code is placed at adress 0x1FBECode:avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -x assembler-with-cpp -c eneurobootlight.S -o eneurobootlight.oavr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o eneurobootlight.elf eneurobootlight.oSo, it puzzled me for a few hoursthis RJMP -66 means and why someone hardcoded it as 0xCFDF in avrdude interface code?Code:const uint8_t reset_vec_lo = 0xdf; /* rjmp BootStart */const uint8_t reset_vec_hi = 0xcf; /* rjmp BootStart */Hopefully, I realized that, since ATTiny85 has 8KB flash program memory, so it is: 8120 bytes, which in hex is: 0x2000,so when we apply this strange 0xCFDF (RJMP -66) instruction send by avrdude, which means that from address where it starts we need substract -0x0040 , we get: 0x2000 -0x0040=0x1FC0, so very close to place where our bootloader is already programmed in MPU:0x1FBE.How close is it?Two bytes before place where new reset vector RJMP redirects us after succesfull MPU programming:0x1FC0 = 0x1FBE +2 (rjmp)So, now this part of bootloader code explains everything: VirtualReset is at adress: 0x1FBE and BootStart: at 0x1FC0, since instruction:rjmp BlinkLEDis exactly 2 bytes in flash program memory and is replaced by bootloader with uploaded application during avrdude programmingCode:.section .bootloader,"ax",@progbitsVirtualReset:rjmp BlinkLED ; will be overwritten by programmerBootStart:sbis UART_Port-2, UART_Rx ; Rx high = start bootloaderrjmp VirtualReset ; jump to application codeclr FCSsbi UART_Port-1, UART_Tx ; set Tx pin to output mode; continuous loop for commands from programmer; when upload is finished, programmer resets chip & starts appSo, sick-it remainds me LOGO programming on Commodore64 by... writting directly into its RAM assembler code and this is exactly what is done during avrdude flash programming, where modified RJMP instruction is calculatedCode:/* calculate new rjmp for appstart */vrst_vec_addr = m->size - BOOTLOADER_SIZE;appstart = 0xc000 |( (vrst_vec_addr/2) + (appstart & 0x0FFF) );Unfortunatelly,0xC000is hardcoded in this samplepicobootcode, so... it is not clear that it is part of RJMP binary two byte codeNow, it should be easy change bootloader code, since we know howto calculate new bootloader position and.. howto (hard)code this new reset vector code in the case bootloader size will change if we have other requirements too.BTW: If someone found this information usefull in his custom avrdude based bootloader project, feel free to... donate fraction of bitcoin at one of my Bitcoin adresses below, since I need to take a deep breath andafter thispicobootcode investigation, so it probably can save someone a lot of time

author: ralphd
author_rank: Frequent Contributor
timestamp: July 16, 2015, 03:36:21 am
content: You're doing pretty good. I know the comments I write are good enough so I can understand the code when I go back to it, but it is nice to know others can figure it out too. :-)For the ack handling in the avrdude code, you'll need to substitute a delay of 5ms after the page erase and page write commands.

author: eneuro
author_rank: Super Contributor
timestamp: July 16, 2015, 11:32:27 am
content: Quote from: ralphd on July 16, 2015, 03:36:21 amCopy thatAny hints helpfull since it is never easy create byte opcode for microcontrolers and guess what MPu opcode doesHowever, I'm more concerned about another issue I think I've foundI mean, when I've made analysis of flash program commands send to MPU during bootloader programming, it looks like bootloader RJMP to application code is not overwritten, so after flashing uploaded program using modified avrdude with oryginal picoboot MPU will still have such RJMP instead of new calculatedCode:0001fb0: ffff ffff ffff ffff ffff ffff ffff 21c0 ..............!.ootloaderEven worse, when we disassemble this RJMP opcode at 0x1FBE flash byte address (first instruction in our bootloader) we have there still 0x21C0 RJMP:Code:$ ./avr-rjmp 0xC021AVR assembler RJMP code: 0xC021 rjmp: +0x0044 (+66)which means that it will RJMP MPU NOT to uploaded app oryginal reset vector at 0x0000 in oryginal HEX (bin) app program code, but to... flash byte address0x0002and this is not what many applications will like, since this is.... INT0 interrupt on ATTiny85 as I knowReset vector is overwtitten with bootloader to RJMP to 0x1FC0, but at 0x0002 uploaded app program will find interupt vectors NOT oryginal app start code, I thinkCode:0000000: dfcf ffff ffff ffff ffff ffff ffff ffff ................0000010: ffff ffff ffff ffff ffff ffff ffff ffff ................Below is why RJMP will go there (disassembler also shows 0x2002 RJMP there)RJMP: 0xC021 : 0x2000 +0x0044= 0x2002, flash size is 0x2000 in hex, so we land at 0x0002 flash byte-no supprise since this is place where BlinkLED: is in picobootSerial.S code:Code:.textrjmp BootStartBlinkLED:sbi DDRB, LEDPINBlink:sbi PINB, LEDPINldi ZH, 30DelayLoop:Unfortunatelly, what I mean-it looks like this VirtualReset: RJMP is updated in avrdude picoboot and marked (taggled), but... no flash programming code send to AVR MPU -so trying to fix this by add needed flash command for page before where bootloader is installedCode:.section .bootloader,"ax",@progbitsVirtualReset:rjmp BlinkLED ; will be overwritten by programmerBTW: I think, that oryginalblink.Sdiode blink app demo for bootloader has no chance to work with oryginalpicobootSerial.S, because of avrdude picoboot programmer will write in the place where ledblink pin is set as output at 0x0000 flash program memory byte-will overwrite with AVR opcode:0xCFDF rjmp to bootloader BOOTSTART:, so addingnopfixes this as shown below-elseCode:sbi DDRB, LEDPINwill be replaced with 0xCFDFCode:.textnopLedOutput:sbi DDRB, LEDPINBlink:sbi PINB, LEDPINldi ZH, 40

author: eneuro
author_rank: Super Contributor
timestamp: July 16, 2015, 02:29:53 pm
content: Moment of truth and time to see if all this hard assembler RJMP opcode math is worth somethingProbably managed my avrdude extension for custom programmer properly calculate and update in MPU memory changed application start RJMPQuoteDisassembly of sections updated in MPU after avrdude programming with new application start RJMP calculation below flash program 0x0000 reset vector view:Code:eneurobootlight.bin.avrdude.hex: file format ihexDisassembly of section .sec1:00000000 <.sec1>:0: df cf rjmp .-66 ; 0xffffffc02: 28 c0 rjmp .+80 ; 0x544: 27 c0 rjmp .+78 ; 0x546: 26 c0 rjmp .+76 ; 0x548: 25 c0 rjmp .+74 ; 0x54a: 24 c0 rjmp .+72 ; 0x54c: 23 c0 rjmp .+70 ; 0x54e: 22 c0 rjmp .+68 ; 0x5410: 21 c0 rjmp .+66 ; 0x5412: 20 c0 rjmp .+64 ; 0x5414: 1f c0 rjmp .+62 ; 0x5416: 1e c0 rjmp .+60 ; 0x5418: 1d c0 rjmp .+58 ; 0x541a: 1c c0 rjmp .+56 ; 0x541c: 1b c0 rjmp .+54 ; 0x540x001e: 11 24 eor r1, r120: 1f be out 0x3f, r1 ; 63...We can see, that oryginal application RJMP reset vector was 0xC00E, which means it was a jump to program at byte adress:Code:0x001e: 11 24 eor r1, r1After sucessfull upload in our custom bootloader, we want be able jump there somewhere from bootloader and now it seams to me that it might work, since at botloader app RJMP at byte adress 0x1FBE we have, I hope properly calculated RJMP to this oryginal application code at adress 0x001E, since disassembler shows nice RJMP 0xC02F to adress 0x201Em but since we have flash size 0x2000, probably bootloader now make good RJMP to 0x001E as we wanted toCode:1fbe: 2f c0 rjmp .+94 ; 0x201eAnyway, that is amazing that rest below is ALLpicobootbootloader code starting from 0x1FBE - ONLY 66 bytesCode:....1fba: ff ff .word 0xffff ; ????1fbc: ff ff .word 0xffff ; ????1fbe: 2f c0 rjmp .+94 ; 0x201e1fc0: b0 9b sbis 0x16, 0 ; 221fc2: fd cf rjmp .-6 ; 0x1fbe1fc4: 00 27 eor r16, r161fc6: b9 9a sbi 0x17, 1 ; 231fc8: 0d d0 rcall .+26 ; 0x1fe41fca: e6 2f mov r30, r221fcc: 0b d0 rcall .+22 ; 0x1fe41fce: f6 2f mov r31, r221fd0: 09 d0 rcall .+18 ; 0x1fe41fd2: c1 9a sbi 0x18, 1 ; 241fd4: 07 d0 rcall .+14 ; 0x1fe41fd6: 02 13 cpse r16, r181fd8: ff cf rjmp .-2 ; 0x1fd81fda: 67 bf out 0x37, r22 ; 551fdc: e8 95 spm1fde: 0f 01 movw r0, r301fe0: c1 98 cbi 0x18, 1 ; 241fe2: f2 cf rjmp .-28 ; 0x1fc81fe4: 60 e8 ldi r22, 0x80 ; 1281fe6: 2c e0 ldi r18, 0x0C ; 121fe8: b0 99 sbic 0x16, 0 ; 221fea: fe cf rjmp .-4 ; 0x1fe81fec: 06 d0 rcall .+12 ; 0x1ffa1fee: 28 e0 ldi r18, 0x08 ; 81ff0: b0 99 sbic 0x16, 0 ; 221ff2: 08 94 sec1ff4: 67 95 ror r221ff6: d0 f7 brcc .-12 ; 0x1fec1ff8: 06 27 eor r16, r221ffa: 21 50 subi r18, 0x01 ; 11ffc: f1 f7 brne .-4 ; 0x1ffa1ffe: 08 95 retGood job @ralphdI think, since I've dumped binary MPU code app+bootloader in one file using my custom avrdudeeneurobootlightprogrammer and oryginalpicobootbootloader merger (as it were uploaded to MPU), so I can reflash MPU using ISP, just to confirm that this calculated RJMP 0xC02F to application from bootloader address byte 0x1FBE will workAfter restart I should be able try triger into bootloader mode since MPu should jump to 0x1FC0 code and check for one of its pins,Code:1fc0: b0 9b sbis 0x16, 0 ; 22than jump to application if it is not in bootloader triger state, etcCode:1fc2: fd cf rjmp .-6 ; 0x1fbeFrom 0x1fBE bootloader should now start our programmed application:Code:1fbe: 2f c0 rjmp .+94 ; 0x201eWe'll see if it will work

author: eneuro
author_rank: Super Contributor
timestamp: July 16, 2015, 09:06:11 pm
content: Quote from: eneuro on July 16, 2015, 02:29:53 pmNo problem what so ever -it looks like I've generated new application start RJMP opcode 0xC02F for my sample led blinking app properly and everything works as expected-for the moment oryginal picoboot bootloader is used for testing purposes of this RJMP from bootloader to app startI've included working .hex and dissasembled flash program binary in attached .zip file if someone wants to test it in README file I've described my ATTiny85 setup and how tested itREADME from attached .zip below:Code:2015-07-17: 22:40:00: Tested sucessfully HEX code flashed using ISP to ATTiny85 with I2C pullups 10k on PB0/PB2 and diode on PB1.* When PB0 is pulled down using 1k resistor (~0.45V on PB0 since 10k pullups to 5VCC ) during restart as excpected bootloader redirects program flow to given application code - switching to 8MHz in software and flashing diode at PB1 at 1Hz frequency** When during restart PBO is high (pulled up to 5VCC by 10k ), then bootloader doesn't make RJMP to application code-when pulled down via the same 1k resistor, diode on PB1 stays ON (no flashing), so probably bootloader is waiting for conection with avrdude .NOTE: Dissasembled binary version of this test code from flashed *.hex included in *.asm .ATTiny85 MPU has normal 1MHz fuses and BOD enabled-it switches in software to 8Mhz, when pin PBO is low and then as described above, PB1 diode should blink at 1Hz when in application mode.It is time to change this AVR bootloader to fit into my requirements and debug avrdude, to be able send this flash programing page with updated application start RJMP (0xC02f) in my case.I'm not sure how avrdude manages those TAGLED memory bytes with marked virtual reset opcode RJMP in this sample picoboot avrdude programming interfaceUpdate: I've forgot to mention that picoboot linked there was compiled with F_CPU=1000000, but didn't tested if this bootloader is capable upload any software via modified avrdude-I wanted only test RJMP to application start from bootloader in this test

author: rs20
author_rank: Super Contributor
timestamp: July 16, 2015, 10:00:29 pm
content: Quote from: Marco on June 05, 2015, 12:38:13 amMore than that, public/private key crypto doesn't help unless you have a challenge/response system going (or else a trivial replay attack works). A challenge/response requires bidirectional comms.

author: ralphd
author_rank: Frequent Contributor
timestamp: July 17, 2015, 04:31:52 am
content: Quote from: rs20 on July 16, 2015, 10:00:29 pmReplaying a digitally encrypted and signed message would not let you flash arbitrary code to the device.

author: rs20
author_rank: Super Contributor
timestamp: July 17, 2015, 06:17:40 am
content: Quote from: ralphd on July 17, 2015, 04:31:52 amGood point. I was overly attached to the original "password" proposal.

author: eneuro
author_rank: Super Contributor
timestamp: July 17, 2015, 01:54:35 pm
content: Quote from: rs20 on July 17, 2015, 06:17:40 amWhen I'm thinking about application authentication than rather OTP (https://en.wikipedia.org/wiki/One-time_password)of course, eg, some kind of token based on RTC and internal flash encrypted data shared between devicesone-time password (OTP) is a password that is valid for only one login session or transaction, on a computer system or other digital device.Authenticated application could manage those OTP passwords, so bootloader password could be OTP based too, so no chance to guess or intercept this password:Boot loader password/ID rather for other purposes-to be able protect against unintentional upload of software that was not developed for given MPU in simple version -in the case of additional security eg. upload using RF transmision OTPAnyway, simply CRC check I'd like to add to bootloader to verify programed flash gives me additional +53 bytes fror this CRC16 implemented in C, but I think, it is a must to ensure correct program was downloaded, as well as I'd rather use CRC16 to ensure before flash page write, that this what was received is correct-if CRC16 fails, then this page in MPU will be overwritten with 0xFFFF .Code:0000009c <crc_update>:9c: 70 e0 ldi r23, 0x00 ; 09e: 68 27 eor r22, r24a0: 79 27 eor r23, r25a2: 80 e0 ldi r24, 0x00 ; 0a4: 90 e0 ldi r25, 0x00 ; 0a6: 41 e0 ldi r20, 0x01 ; 1a8: 50 ea ldi r21, 0xA0 ; 160aa: 26 2f mov r18, r22ac: 37 2f mov r19, r23ae: 36 95 lsr r19b0: 27 95 ror r18b2: 60 ff sbrs r22, 0b4: 05 c0 rjmp .+10 ; 0xc0 <crc_update+0x24>b6: 62 2f mov r22, r18b8: 73 2f mov r23, r19ba: 64 27 eor r22, r20bc: 75 27 eor r23, r21be: 02 c0 rjmp .+4 ; 0xc4 <crc_update+0x28>c0: 62 2f mov r22, r18c2: 73 2f mov r23, r19c4: 01 96 adiw r24, 0x01 ; 1c6: 88 30 cpi r24, 0x08 ; 8c8: 91 05 cpc r25, r1ca: 79 f7 brne .-34 ; 0xaa <crc_update+0xe>cc: 86 2f mov r24, r22ce: 97 2f mov r25, r23d0: 08 95 retMaybe someone has shorter CRC16 implementation on AVR ATTiny's?Update: This 8bit CRC ibutton might be fine toohttp://www.nongnu.org/avr-libc/user-manual/crc16_8h_source.htmlIt is not so critical, but just to see what could be the smallest one CRC16 on AVR implementation in comparision to this generated from CCode:inline uint16_t c_crc16_update(uint16_t crc, uint8_t a);uint16_t crc_update(uint16_t crc, uint8_t a) {return c_crc16_update(crc, a );}inline uint16_t c_crc16_update(uint16_t crc, uint8_t a) {register unsigned int i;register unsigned int a001= 0xA001;crc ^= a;for (i = 0; i < 8; ++i) {if (crc & 1) {crc = (crc >> 1) ^ a001; }else {crc = (crc >> 1);}}return crc;}Additionally changed bootloader to do nothing (RJMP 0xCFFF does this trick)Code:1fbe: ff cf rjmp .-2 ; 0x1fbewhen no application programmed yetCode:.textrjmp BootStart.section .bootloader,"ax",@progbitsVirtualReset:rjmp VirtualReset ; will be overwritten by programmer after successfull programming to application start RJMPBootStart:

author: ralphd
author_rank: Frequent Contributor
timestamp: July 17, 2015, 02:25:26 pm
content: The EOR FCS is pretty good already; 1 parity byte for every 3 data bytes. If you really need more than that, use a fletcher-style checksum instead:add crclo, dataadc crchi, crcloFletcher gives error detection rates extremely close to crc16.

author: ralphd
author_rank: Frequent Contributor
timestamp: July 17, 2015, 02:33:16 pm
content: I also toyed with an 8-bit sum FCS. The hamming distance may be worse than EOR, but I suspect it may catch more of the types of errors common to serial comm than EOR.

author: eneuro
author_rank: Super Contributor
timestamp: July 17, 2015, 02:55:39 pm
content: Quote from: ralphd on July 17, 2015, 02:33:16 pm8 bit (ibutton) CRC is ~30 bytes long, so probably I will replace this 8-bit FCS sum with CRCDepending on bootloader size, maybe include CRC16 for each 64 bytes flash page and after programming verify written uploaded application code with CRC16 and if everything will be fine, than flash page with vritual reset vector will be overwritten to RJMp to application start to commit flash programming.My plan is, flash this RJMP to application start code with shown earlier RJMP 0xCFFFat the begining of flushing new application code, so when it fails at some point later, eg. skipped flushing during reprogramming- than after unintended device reset it will prevet run corrupted not complete application, but instead will go into infinite loop if no additional boot loader attempt will be made to reflash againCode:VirtualReset:rjmp VirtualReset ; will be overwritten by programmer after successfull programming to application start RJMPCode:1fbe: ff cf rjmp .-2 ; 0x1fbe1fc0: b0 9b sbis 0x16, 0 ; 221fc2: fd cf rjmp .-6 ; 0x1fbeI was thinking on MD5sum, but nope, not for tiny bootloader too much code-application code may use MD5 if really needs is.

author: ralphd
author_rank: Frequent Contributor
timestamp: July 17, 2015, 03:44:47 pm
content: It's not documented, but most experienced AVR programmers know that 0xFFFF (unprogrammed flash) is a NOP.So if the virtual reset vector page is erased and not programmed, it will be 0xFFFF, and so the rjmp AppStart will execute a NOP and fall back into the bootloader again.

author: eneuro
author_rank: Super Contributor
timestamp: July 17, 2015, 11:01:10 pm
content: Quote from: ralphd on July 17, 2015, 03:44:47 pmNOP instruction has opcode 0x0000, not 0xFFFFIt puzzled people some time ago:http://www.avrfreaks.net/forum/what-does-opcode-0xffff-actually-doAnyway, I wouldn't like erase whole flash page (64 bytes) before bootloader (including those two last bytes for RJMP to app code), since there can be somewhere on this page usefull data or code, so I'll rather only update those last 2 bytes to 0x0000 (NOP), without changing whole flash page with 0xFFFF-this will mark something like start of transaction at the begining of flash programming, commited by writing correct RJM to app start after successfull upload and veryfication .

author: eneuro
author_rank: Super Contributor
timestamp: July 18, 2015, 01:36:59 pm
content: In spare time I've managed to use pure C implementation of my custom AVR (tested on ATTiny85 now) bootloaderWe can see that flash CRC16 computation using standard AVRGCCCode:#include <avr/pgmspace.hlibrary creates quite nice code to access avr flash memory and had no problem what so ever to add my custom CRC functions written in C, however it was a little bit tricky to tell avrgcc linker to properly allocate those routines in flash memory program space.Code:1e38 <flash_read_byte>:1e38: fc 01 movw r30, r241e3a: 84 91 lpm r24, Z1e3c: 08 95 retThis what I like, while coding it in C (maybe I will use pure assembler code if bootloader size will be concern) is that in this tricky way it is easy to create proper machine code to make RJMP to given bootloader sections-for example this C code below creates nice RJMP from MPU 0x0000 reset vector after restart to main bootloader start codeCode:// Bootloader sectionsvoid bootloader_reset(void) NAKED SECTION(".bootloader_reset");// boot loader resetvoid bootloader_reset(void) {{ __asm__ __volatile__ ("rjmp bootloader_start"); }}After linking with this below to tellavrgccwhere this bootloader reset vector code should be (at address 0x0000 of course in MPU flash memory)Code:LFLAGS += -Wl,-section-start=.bootloader_reset=0x0000and disassembling this part of code we can easy verify that this is what we want at 0x0000 flash byte address -RJMP to main bootloader start using this RJMP 0xCEFF:Code:00000000 <bootloader_reset>:0x0000: ff ce rjmp .-514 ; 0xfffffe00Lets verify if this is correct RJMP?My developed utilityavr-rjmpsoftware shows RJMP opcode 0xCEFF says in machine code that it will RJMP -0x0200 from address where RJMP is located, so while this opcode is at 0x0000 flash program memory address and we have 0x2000 flash size (8KB), so it will RJMP to 0x2000-0x0200= 0x1E00Code:$ avr-rjmp 0xCEFFAVR assembler RJMP code: 0xCEFF rjmp: -0x0200 (-514)After examining dissassembled code we can confirm that it is good RJMP while there is out bootloader satrt code located (2 bytes after virtual reset at the end of previous flash page):Code:1e00 <bootloader_start>:1e00: 00 00 nop1e02: 00 00 nop1e04: 00 00 nopI've inserted few NOP opcodes to mark this bootloader start for debug purposes.While those flash memory allocations for critical parts of our bootloader works, it is good starting point to implement communication protocol between MPU and.... light source.Seriously thinking about forget about avrdude, since I do need it to send binary AVR program and make custom software written in OpenCV, which will have capability to send only differential binary code and flash pages needed to update MPU firmware with expected CRC checksums, which despite we have only one way communication, MPU can verify expected checksums and do not let run code on MPU (no commit by writting RJMP to application code) if verification of partialy send application update will fails-no need to do any reply, just after reset MPU will not work at all so it can be detected on something like MPU status diode, so we know that we need reflash more MPU code and it will take maybe more time using light interface, but that is fine-it will happen only from time to time and application code integrity is the highest prority, so my bootloader will be slightly bigger than eg.picobootbut probably I will implement additional CRC check before running aplication after restart and disable code if CRC check fails-for example aging procsses, etc-this is what I want to have in some projects, so while we chave CRC computations routines in bootloader, such flash program code check during boot (like memory check on PC during POST if enabled) is what I want to have and depending on bootloader size will go this way in this custom bootloader implementation-it will be of course possible to turn off this feature by service code or during compilation, to save bootloader sizeFun purt begins since it looks like I nicelly fit into this needed address space, so understanding RJMP on machine code level by writing own dissasembler of this RJMP AVR opcode should help now resolve any issues with badly created RJMP or misssed good RJMPs

author: eneuro
author_rank: Super Contributor
timestamp: July 20, 2015, 09:02:11 pm
content: Quote from: Psi on June 05, 2015, 07:21:00 amProbably I will use special hardware to be able read from LCD screen one byte (8bits) with additional 9th bit asparity checking.and convert to faster bit rate to one MPU wire.I'm really interested in using...International Morse Code, but of course not in a way described in oryginalSamuel Morse Patent, but instead of alphabet letters send only bytes and words, however while I'm also interested in low speed radio communication, so I'd like for example to be able reflash MPU code using.... RF module at low bit rates, but enhanced data redundancy while it will be only one way communication to MPU using only 1 pinI'm curious what kind of encoding is used in fiber optics?ThereFiber-Optic Encodingare some hints and it looks likeQuoteHowever, what about coding using Morse code at rates taken from its first standard mentioned above?I really like idea to be able "hear" bytes transmited via RF or light source where I can recognize easy each bit, when speed will be slow enougth.So, at 1Hz 1 second dot length in Morse code for example I could be able hear readings from my wether station like temperature within +/-127 *C using just one byte (8 bits)...It sounds ridiculous low speed, but... imagine that some device from lost airplane was able output such signal from its beacon system, easy to hear and uderstand even by humans and this way even such low transmision speed sometimes might be fine, since sometimes any feedback is much more important than no feedback at all, so yeah.. I want to test binary Morse code as additional mode in my bootloader physical layer transmission first, then I'll add support for Manchester encoding, but I've a few projects now where I believe this binary Morse coding will be fine, so I've already made encoding interface and now all I need to do is implement decoding in a smart way -capable to autodetect transmitter bit rate to be able adjust to data source speed.Code:// 1MHz MPU by default#ifndef F_CPU#define F_CPU 1000000UL#endifvoid morse_space(uint8_t pin);void morse_one(uint8_t pin);void morse_zero(uint8_t pin);void morse_byte(uint8_t pin, uint8_t byte );void morse_word(uint8_t pin, uint16_t word);Succesfully tested this binary Morse transmiter code_I will try tomorow also RF a fe hundreds meters transmition at low speed to see I will be able easy receive send bytes and words with additional parity bits to distant RF receivers on my yard using low power 433 MHz RF modulesOf course each flash page (64 bytes) will have additional CRC check, but I want to be able skip receiving rest of transmition if at the beginning of flash page we have bad bytes, so we can cancel flash page erase and jump to wait for another transmission of bytes/words later.It should be easy to encrypt such binary Morse code encoded bytes with exchanged set of bytes osing simply XOR cipher, so lets check it out and implement binary Morse receiver, since I have implemented and tested binary Morse code transmiter

author: ralphd
author_rank: Frequent Contributor
timestamp: July 21, 2015, 02:33:42 am
content: Since most phones have a led for the camera, you could make your app modulate the led at a high baud rate.

author: rs20
author_rank: Super Contributor
timestamp: July 21, 2015, 04:00:17 am
content: Quote from: ralphd on July 21, 2015, 02:33:42 amI believe that LED is turned on and off by recording a video with the LED enabled and discarding the video stream (this certainly was the case early on at least); a high baud rate is certainly not achievable if that's still the case.

author: eneuro
author_rank: Super Contributor
timestamp: July 21, 2015, 03:37:34 pm
content: Even if I had access from custom software to this camera LED, still probably it could be difficult keep stable timings at higher rates and it could require very low level development on those devices.Intead It could be perfect... play movie with our transmisiion data, so it could be independent of device and operating system used, but video encoding and refresh rates might be critical, but probbaly it will be easier to get decent frame rate video-at list I know howwto create it for testing purposes directly from OpenCV tollbox, so I'd rather working on special hardware converter between LCD screen and one MPU pin, which will be able to read in pararell 8-9 bits from the screen and convert to serial in realtimeAnyway I need also LCD MPU based modules with photodiode detectors to be able display on its screens data send througth serial optics channels like simply diode or even cheap plastic optics fiber, so now I'd rather concentrate howto connect to one (the same) MPU pin photodiode and LED to be able create bidirectional light MPU pin interface, but in the case when LCD will be used as source of data, only light detection will be used as one way to MPU communication-it could be nice output some bootloader status data, so having LED shared on the same pin with photodiode could be nice and trying to figureout how to do it-there were some talko about this so it is time try to test something like this.eevblog.com: Sensing light in the gap between emitting light?QuoteFor example this one:http://playground.arduino.cc/Learning/LEDSensorQuoteI've bought a few red small SMD 0805 LEDs , but its LED die seams to be very tiny-small.Is it posible to turn this thing into decent LED/light sensor at the same time?It would be nice, so lets check it outUpdate:Probably this is what I was looking for-LED cameras, etcVery Low-Cost Sensing and Communication Using Bidirectional LEDsUps, I didn't notice thisCode:A novel microprocessor interface circuit is described which can alternately emit anddetect light using only an LED, two digital I/O pins and a single current limiting re-sistor.It needstwo digital I/O pins, so yep I will test it for fun, but nope-it could be nice use only one pin for this kind of communication.

author: eneuro
author_rank: Super Contributor
timestamp: July 21, 2015, 10:08:11 pm
content: Quote from: eneuro on July 21, 2015, 03:37:34 pmHopefully, inpired by this LED equivalent circuit, I've found a tricky way to sense photocurrent ... as well as drive LED using only one MPU pinIt works fine in simple circuit simulation, but it require real photocurrent values, however according to ATTiny85 datasheet RAIN (Analog Input Resistance ) is: 100M Ohm, so this tricky LED photocurrent sensing might work

author: rs20
author_rank: Super Contributor
timestamp: July 22, 2015, 12:27:49 am
content: Yeah, I've used the LED-as-a-photoreceiver trick many times. The only catch (which may not be a catch for the one-off hobbyist) is that the photosensitivity of the LED is not specified in the datasheet, so it's difficult to design for without doing your own characterization, and not guaranteed to remain consistent over time. For example, hypothetically, if the manufacturer develops a more luminous-per-sq-mm LED chip, they'll shrink the die in the LED to save costs, while maintaining the specs listed in the datasheet. However, the photosensitivity may go down when this happens, and you'll never know. Again, if you're just doing a one-off, you only need to get the one to work, so this isn't such a concern.Note that unless you pull a clever trick, you can't transmit and receive on the same LED with a single MPU pin because the LED needs to be biased different ways. However, if you place an LED and current limiting resistor across two MPU pins, then yes you can use the same LED for transmit and receive (albeit not at the same time, of course!).

author: ralphd
author_rank: Frequent Contributor
timestamp: July 22, 2015, 04:21:15 am
content: You can power a LED and sense light with 1 MCU pin.http://spritesmods.com/?art=minimalism

author: rs20
author_rank: Super Contributor
timestamp: July 22, 2015, 05:31:34 am
content: Quote from: ralphd on July 22, 2015, 04:21:15 amOK, I stand marginally corrected. What you linked is different to what eneuro was talking about, in the link they're using the LED as a solar cell, slightly forward-biasing itself, rather than a reverse-biased photodiode. This also means it needs the slow, power-hungry ADC with the prescaler set to max, it's not using digital logic; so forget about the cool tricks where you have a whole series of LEDs and read them in as an 8-bit bus at once.So I stand corrected and revise my statement accordingly: you can't transmit and receive on the same LED with a single MPU pin unless you use the ADC. If you have a couple of pins spare, you'll have a much nicer time if you connect your LED across 2 MPU pins, much more versatile.

author: con-f-use
author_rank: Unknown
timestamp: July 22, 2015, 08:18:11 am
content: I didn't read the thread and have no idea if that works for the tinies, but have you looked at this:https://avrirdownloader.wordpress.com/

author: eneuro
author_rank: Super Contributor
timestamp: July 22, 2015, 01:47:29 pm
content: Quote from: rs20 on July 22, 2015, 05:31:34 amYeah, Looking into a few photodiodes datasheets it looks like photodiode can be used in my tricky circuit instead of reverse-biased LED if I wanted to use eg. plastic optics fiber for communication in a few projects, where thunder storms and lighting can be an issue, so time to make prototype PCBs and test itEven this niceIF-D91 Plastic Fiber Optic Photodiodeshould work since it should have decent photocurrent.It is time for some development now an we'll se how it will perform in home automation project, where wall RF wireless ring bell switch will have some hidden security functions enabled... by sensing exposed leds installed in switch buttonNow,when this bootloader project is finished, I should be able reflash switch software just using those external leds.This is theory-prectise timeUps, accidentally I've replaced my previous post with this one which I wanted to add as another newI hate those small fonts in those message modify/edit forms, which leads to so many misstakes while typing into those message boxes....

author: eneuro
author_rank: Super Contributor
timestamp: July 24, 2015, 08:13:30 pm
content: Just made ~10mm x 10mm PCBs for bidirectional light button sensor on one MPU pin, but no time today to solder and test it.Probably, I will need additional two caps in some projects, to get longer response timed easier to count, but it shouldn't be a problem since one side of PCB are only input/output LEDs, so those caps can be easy add there or on other side, since it can be smaller, while I've designed this PCB to be able make prototype at home using thermal transfer, so VIAS are as big as 1mm and quite thick tracks.Anyway, even 12mm x 12mm is not so bad since when measured PC keyboard buttons they have on the top something similar, so even using SMD 0805 parts in this version it seams to be usable and still quite easy to assembly at homeCan't wait if those light buttons will work as expected