Closed wolfgangr closed 5 years ago
Sorry,
I don't understand your point. What do you want to achieve with the retired esp-14 module? There is no sonoff device with this chip.
it opens a new level of creativity for users without nuisancing tasmota maintainers
Let me drop some of my creative junk pile in front of you.
You know all those tiny arduino sensor examples? Of course yo do: https://github.com/arendst/Sonoff-Tasmota/tree/development/lib
I want to run some of them on my farm with two locations, several km apart. Some of them maybe located out in the field, some maybe on mobile machinery. My irrigator, e.g. requires control checks in 2...3 hrs intervals, 24/7 over 4 weeks - travel 7 km each time. That' real work
I had tried some of those arduino examples on my desk, with the arduino attached to the usb cable. Quick, handson and simple. But limited to the USB cable. So the intranet/internet should replace the cable, and tasmota the USB-serial chip. I thnik they call this idea IoT, don' they?
I had the network connection in place 4 yrs ago (well, had some pause due to an accident then...) I even have own internet root server since that time. I have an moquito runnnig and want to deply FHEM and zoneminder. (have been lifted several times now) Tasmota fits perfectly into that environment
With out of the box sonof devices I could cover half of my needs, with cheap multi-relay cards another quarter. But then it gets hard. One challenge is a double.setpoint_control https://en.wikipedia.org/wiki/Double-setpoint_control But this might be done with tasmota rules, I think
Next challenge is to position valves. 1.5" size in the heatings, 3" ... 4" in the irrigator.
I have motors, controlled by arduino monster shield
DC driver, that could drive them.
Envisioning an arduino sketch for that job is easy.
Throwing a mqtt-tls-syslog-http-capable interface upon them is hard work
This task I think begs for sth like the esp14
There are some control tasks that don't demand such short response times. I copuld implement them in my favourite perl on the server. But they should be self contained and continue working if the server/network is not available. In search for an alternative, I found back to FORTH, the pet of my youth. In the hackaday link posted, they have a FORTH running on the STM8 within a ESP14.
Remote control of the crop dryer. Need a bunch of temp/homidity sensors, sense and switch some dozens of 220 V lines and relays. Maybe a couple of cameras. The PCF8574 multi-IO prototype is on my desk. The 8-channel 220V-sensing PCB is close to production. If it requests a little bit more programming than what is provided in tasmota, I could easily shift it to an independent processor.
There is no sonoff device with this chip.
Got it. Shall I close the issue or will you do it?
Sorry for my long answer to
What do you want to achieve
I think that should not be the primary question here. The question here is whether there are enough other people who want to have such a thing, too.
Sorry, I think I didn't express my question as precise as I wanted.
What do you want Tasmota to do with the other mcu?
The esp8266 and the other mcu in the esp14 chip are connected by the uart serial right? Tasmota already supports sending and receiving commands thru serial. So it is just a matter that you flash the arduino sketch you want in the other mcu and do the rules in Tasmota that you want for the interaction between the two.
So, my question is if there is something extra you think is needed from the Tasmota side.
OTA flash of the STM8
Ok. I don't know if that is possible. For that other pins should be also connected from the esp8266 to the stm for programming.
Ok. I don't know if that is possible.
Agree, it's not that simple as I thought initially.
The STM require a special protocol, not just simple serial flashing. They call it 'Embedded single-wire interface module SWIM' . For details, search for SWIM in the STMicro STM8S003F3P6 manual . Find a pointer to some "SWIM communication protocol and debug module user manual (UM0470)" Usually you get a ST-Link 2€ USB-Dongle from your fav CN dealer with just another STM inside to do so.
I assume that there is C-Code lingering around, that might be implemented on the ESP8266. And maybe, the connections required to do so are provided under the hood of the EPS-14 modules? The ESP8266 ESP-14 Chinese manual does not show the internal wirings. According to the STM8 data sheet, there is only "PD1/SWIM" required. So, maybe, connecting this to ESP-GPIO0 might suffice. However, I see, sonsiderable integration work, flash and ram space might be required.
Anyway, I got my first ESP-14 and couldn't get it easily nailed onto a breadboard, either. There are 6 pads at the small edge, like in a ESP-12, which are required for the setup, among them GPIO for ESP flash. The generic adapters sold are for ESP07, which just has the 8+8 pads on the long edges.
So I did my test with a D1 mini, a STM32 blue pill and jeelabs esp-link. Requires a long breadboard (or larger PCB in deployment) , but for extendet I/O-work, this is a requirement anyway.
Quick way to first success:-) Just working on my first double setpoint control in FORTH :-)))
However, the ESP-Link has its quirks, too. There is no encryption, and you can't flash an STM either (you could flash an AVR, as they promise, though). MQTT is still to be tested.
And yes, I already required an unplanned reflash. You can do anything in FORTH, which includes shooting yourself. So If I have a need for elaborate in place development with risk of FORTH suiciding itself, I'd have to deploy a raspberry with an ST-Link dongle beneath. Ugly, but manageable.
So I did my test with a D1 mini, a STM32 blue pill and jeelabs esp-link.
ESP-Link is engineered to flash their tiny "master" µC, but they struggle with the STM protocol, too: https://github.com/jeelabs/esp-link/issues/250
The ESP-14 has a 8-bit STM8S003 processor built into the module. https://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-14
The original design idea was to offer ESP8266-AT-command-WiFi support to the STM8 application. So, the STM8 - despite much lower performance figures - was considered as master, the ESP as slave.
Why would we like an independent super-cheap-processor as a "master" which "abuses" tasmota as its interface?
Itead labels the module as "expired", https://www.itead.cc/esp-14.html but I hope that will not hinder clone manufacturers to supply it in the future.
The ESP-14 module goes for < EUR 3 at chinese sellers. It has the same form factor than the ESP12, ESP07, ... and fits on common breakout adapters (so I hope)
The STM8 is reported to be in wide use on cheap consumer and DIY gadgets - cmp: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets So the interface could as well be used to connect such a STM8 device to a "bare" module like the ESP-12.
Here https://hackaday.com/2017/02/13/hacking-on-the-weirdest-esp-module/ is a description for implementing forth on the STM8S003 of an ESP-14
This was the google-catcher how I found this, since I consider to run forth on an ESP8266. But sharing real estate (ram, timing, confguration, management) between tasmota and a language like forth that pretends to replace an operating system is .... close to a nightmare https://github.com/VerboteneZone/WESPOTA/issues/15
There are basically two level of support that tasmota as wifi gateway could supply to the STM8S003:
For a running application, I think the serial bridge functionality available in tasmota might suffice. https://github.com/arendst/Sonoff-Tasmota/blob/e7e378f463bf9a3232506d671d1b85be5aad69bd/sonoff/xdrv_08_serial_bridge.ino Maybe we'd like a remote reset, but I hope that can be implemented by just a GPIO pulled low. I'll post the results as soon as I have tested it.
Of course it would ease the development in place if we were able to flash the STM8 over the air from the tasmota. The mechanism might basically be the same as implemented to flash the EFM8BB1 chip on the Sonoff RF Bridge, as can be found here https://github.com/arendst/Sonoff-Tasmota/blob/2e101839a457ead0bd6d4ede0856902000d3b65c/sonoff/xdrv_01_webserver.ino#L41 and here https://github.com/arendst/Sonoff-Tasmota/blob/447ec6256eb6e277a350ea94a387e5c7755f5693/sonoff/xdrv_06_snfbridge.ino#L43 So I would favour a code reuse, which might, however, require some generalisation of the code alredy at hand.
I haven't found any pointers in the Wiki nor in others issues nor in the source - beyond the quoted RF bridge flasher.
Alternatively, I think it might be possible to flash the STM8 just over the serial connection, which remains to be checked.