sketch for attiny85 firmware upload by air.

[biznesup]

Please write a sketch for attiny85 firmware upload by air.
There are many sketches of flashing esp8266 itself on wifi. .
Task: esp8266 get the firmware via wifi and upload it to your slave ittiny85 via i2c.

Thanks in advance.

[casanovg]

Hi! It can be done, but there are some issues/limitations to consider, and decisions to make depending on the intended use:

1-The tiny85 firmware should support I2C so that the esp8266 can reset it to start the bootloader, or ... the esp8266 should be able to control the reset pin of the tiny85 by hardware for this.

2-If the esp8266 resets the attiny85 with a command through I2C, both, the current tiny85 firmware and the new one should support I2C to make future updates available. If the reset is by hardware, this would not be necessary but the esp8266 sketch should control an available pin to reset the tiny85, which in turn should have the reset pin available and enabled by the AVR fuses

3-The firmware for the tiny85 could be "part" of the esp8266 firmware as a data array in the flash, or it could be an external file. The first option is simpler, but it would only allow updating the attiny85 after updating the esp8266 via OTA. The second option would allow updating both devices independently, but it is a considerably greater challenge since the tiny85 firmware file has to be sent via WiFi to the esp8266, it has to temporarily store it and then flash the tiny85.

Could you expand a little more what would be the requirements or the use that you would give to this sketch considering the issues/limitations mentioned?

[biznesup]

on my board tiny85 monitors the dry contact closure (pulse counter) and stores it in an energy-independent memory in case of a short-term shutdown. and once a day supplies power to esp01. esp01 wakes up and calls tiny85 on i2c reads the readings and sends it to the http server. Esp01 then sends the tiny85 command to disable itself. In other words, tiny85 controls the power of esp01, and esp01 is the i2c master on slave tiny85. this saves battery life. (v1) the board has a configuration mode where esp01 answers as a server ... (v2) when sending readings to the server, the latter gives the task to change the firmware. in case the remote url does not need to use the device memory. it is possible to read in kilobytes in a loop and simultaneously write firmware. I would like to be able to change both firmwares by air ... or at least any primitive sketch with an example. thanks in advance.

[casanovg]

Hi!

Thanks for the explanation and diagram, I'll write an Arduino example sketch that follows these steps:

1. After a reset (or power on by the Tiny85, as per your design), the ESP8266 checks an internet URL to determine if there's a new firmware for the Tiny85.
2. If so, the ESP8266 downloads the new Tiny85 firmware file to its SPIFFS partition.
3. It resets the Tiny85 to stop the user application (your T85 program) and start the Timonel bootloader. For this, I'm assuming that the application running on the T85 supports I2C and accepts the master's command to restart (please read below how Timonel works).
4. The ESP8266 uploads/flashes the Tiny85 firmware by reading the SPIFFS file and sending it to Timonel, now in control of the Tiny85 (for this, the sketch uses the "Timonel-TwiM" I2C-master library for Arduino).
5. If the flashing is successful, it sends Timonel the command to run the user application, so handing over the Tiny85's control back to it.

Anyway, reading how your application should work, I'm not quite sure that this bootloader fits your needs since it would require a complex reset/power-on/control synchronization among both micros.

Regards, Gustavo

Brief on how Timonel works:

The Timonel bootloader takes control of the tiny85 ONLY after a reset. After starting, depending on its settings, it may continue as follows:

Option A) It waits some time for initialization from the I2C master: If the master initializes it on time, it becomes ready to receive and flash (or delete) an user application. After the flashing, it waits for an I2C master's command to run the application. So, Timonel jumps to the user application, handing over the chip control to it. The only way for Timonel to regain control is resetting again. The reset can be physical (through the reset pin), or logical (the user application must reset the chip, e.g. forcing a WDT reset). If the I2C master doesn't initialize Timonel on time, It just jumps to the user application in flash, if there's one, to just restarts itself.

Option B) It waits for I2C master's initialization forever. In this mode, the user application in flash will no start unless the I2C master so commands to Timonel. The flashing, deleting, and user-app starting work in a similar way to option A.

The Timonel bootloader resides in the Tiny85's upper flash memory, while the user application uses the lower part. In the current solution design, the Tiny85 can be by under Timonel's, OR user application control. Both execution modes are mutually exclusive. To switch from user app running mode to Timonel, a chip reset is required. The opposite way, the Timonel switch to the user app is made by a "jump" to the application start position.

[biznesup]

Thank you very much for your interest. Yes, it is true that at the moment in the firmware it is really not implemented not the bootloader nor the functions start, restart, stop, load firmware of the client application. I hope you implement their example in your sketch. usually seeing an example, everything becomes clear. I am sure that the bootloader is small and typical. and I understand that it must first be uploaded with the client program on the chip tiny85. The long-awaited procedure for filling a new client program by air, will be added. Waiting sketch with great hope.

[casanovg]

You're welcome! Right now, I'm fixing the NbMicro library (needed by any Timonel master application) since I just discovered that the Arduino environment doesn't support some constructs (e.g. "std::unordered_set") for AVR boards. Since I'm mostly developing for ESP chips with PlatformIO IDE, I haven't noticed this. What's needed is more of a "downgrade" than a solution. However, I want these libraries to run in the native Arduino environment, despite its limitations. After this fix, I'll take on the OTA demo sketch. It might be available next week.

[casanovg]

Hi, I was quite busy these last few weeks but, I finally was able to write this demo sketch that shows an ESP8266 uploading new firmware to an ATtiny85 over the internet. I hope it is not too late for your project. It requires too much memory as it uses the serial console a lot to show what's going on, and besides, it uses the String library, which could also be switched to char arrays later. The recommended bootloader configuration to flash the ATtiny85 is "tml-t85-std-norun-dump". The only hardware needed to test it is a NodeMCU, a bare ATtiny85, a LED, and a resistor. I made a (poor quality) video to take a look at it working. If you need further details, please let me know. Regards!

[biznesup]

Thank you so much. I will be testing.

Recommended bootloader configuration to flash the ATtiny85 is "tml-t85-std-norun-dump"

Please provide an exact link.

[casanovg]

Hi, You can use this binary to flash the Tiny85 with AVRdude. If you want to compile the bootloader yourself, clone this repo, open a bash prompt window in the timonel-bootloader folder, and run this script to compile it: ./make-timonel.sh tml-t85-std-norun-dump timonel 10 1B00 1 false (see this or run ./make-timonel.sh --help for options). The resulting binary will be in the releases folder. Regards!