Hi all,
I would like to port my project to Mbed, connecting to Blynk via a ESP-12F module wired to a Nucleo STM32 board.
Is there a basic Mbed example around?
Thank you!
Теж цікаво.
Also interesting.
No, but you’re welcome to create one 
я б з радістю. але деякі речі я не розумію і розпочати не знаю з чого.
I would be happy to. but some things I do not understand and I do not know what to start with.
I am not a programmer, therefore I am trying to understand the structure of a Blynk project…
Correct me if I am wrong, but I assume that I would need:
- HW connection of ESP-12 module to Nucleo board
- A library to support NodeMCU firmware
- A Blynk library (that I assume relies on NodeMCU communication over the serial port)
I am starting from this example:
https://www.google.it/amp/www.instructables.com/id/STM32F103-Esp8266-NodeMCU-Getting-Started-using-Mb/%3Famp_page=true
Apart some bugs in the ESP8266NodeMCUInterface library, I can successfully connect a Wemos Mini D1 module (flashed with NodeMCU FW) to my SSID.
The connection to the host address fails, but I consider this as a following step.
What is more concerning at the moment is that adding this Blynk library
https://os.mbed.com/users/vshymanskyy/code/Blynk/docs/tip/BlynkConfig_8h.html
to the project I don’t get errors or warning, but the Nucleo board turns totally not responsive…
I cannot either make a LED blinking if the Blynk library is present…
Where am I wrong?
Думаю що, blynk + STM32, ще довго не буде популярне. Розробники не будуть приділяти цій темі багато часу. Або вже коли набереться критична маса користувачів, які хочуть використовувати STM32 разом з Blynk, тоді з’являться і приклади і бібліотеки.
На цей час для себе бачу один вихід - це:
- як blynk добре працює і підтримується на ESP8266, то хай там і працює. Бере на себе підтримку зв’язку і взаімодію з сервером і мережею.
- вся інша логіка роботи з периферією хай буде на моєму улюбленому MCU STM32.
- STM32 і ESP8266 з’єднати між собою по UART або SPI.
- створити якийсь “універсальний” протокол обміну між цими MCU для взаімодії.
Поки що питання в мене по останньому пункту. Як побудувати взаємозв’язок між ESP8266 і STM32 (чи будь який інший MCU, наприклад, PIC), щоб firmware на esp8266 не переписувати кожного разу коли робити якісь зміни на STM32. А було б якось універсально. Наприклад, я до STM32 додав датчик температури і його показники хочу відправити на шпильку V10. Пересилаю з STM32 на ESP8266 данні про температуру і на яку шпильку потрібно. А ESP8266 вже знає що робити з тим і надсилає до blynk. А також навпаки при змінах зі сторони серверу, щоб прийнявши ESP8266 відповідні зміни надіслав це до STM32. А вже STM32 вже знає для чого ті данні.
На загал, виходить потрібна ще така собі бібліотека “протокол-прокладка” для взаємодії між Blynk <-> ESP8266 <-> other MCU.
Такий варіант мене б дуже влаштував. Навіть бачу багато переваг в такому рішенні. І великий потенціал. Та все більшої популяризації системи blynk серед розробників.
В мене немає поки ще ідей як це реалізувати. Може кому сподобалась таке рішення поміркуємо як це організувати?
I think that, blynk + STM32, will not be popular for a long time. Developers will not pay much attention to this topic. Or once the critical mass of users who want to use STM32 with Blynk is set up, then examples and libraries will appear.
At this time I see for myself one way out:
- how blynk works well and supports ESP8266, then let it work. Takes on itself the support of communication and interaction with the server and the network.
- All other logic with peripherals let it be on my favorite MCU STM32.
- STM32 and ESP8266 connect to each other by UART or SPI.
- create a “universal” exchange protocol between these MCUs for interactions.
So far, I have a question on the last item. How to build an interface between ESP8266 and STM32 (or any other MCU, such as PIC), so that the esp8266 firmware does not rewrite each time you make any changes to STM32. And it would be somehow universal. For example, I added a temperature sensor to STM32 and I want to send the indicators to the V10 pin. I send from STM32 to ESP8266 temperature data and what pin is needed. And ESP8266 already knows what to do with it and sends it to blynk. And also vice versa, when the server changes, to accept the ESP8266 the corresponding changes sent it to STM32. And already STM32 already knows for what those data.
All in all, we still need a “protocol-lining” library for interaction between the Blynk <-> ESP8266 <-> other MCU.
This option would be very good for me. Even I see many advantages in this decision. And great potential. But the growing popularity of the system blynk among developers.
I still have no idea how to implement it. Maybe someone likes this solution and think how to organize it?
You could try Easy Transfer, I believe one of its communication variants will work with ESP (i2c will work, at least as Master… don’t know about STM32). Otherwise I am sure there must be another form of MCU-MCU data transfer, besides simple serial.
@Gunner The complexity of the translation.
I did not mean the UART, SPI or I2C interface. With this everything is clear. There are no questions.
The thing is to create some kind of universal protocol. To focus on creating a firmware for STM32 while designing, and the firmware for ESP8266 did not need to be rewritten every time you make changes to the project.
I see… I took these two points as the question of simple data transfer…
If I understand then, what you are referring to involves making a 3rd party library for Blynk compatible data translation… and as you said, not a likely proposition without much demand.
Personally I would still use some form of EasyTransfer like method and write simple “translation” code to take, for example, 10° as a number from one non-Blynk device and submit it to the Blynk server as a pre-defined Blynk.virtualWrite() command from a Blynk capable device… and visa versa.
@Gunner Exactly. 3rd party library.
Since you are using EasyTransfer - I understand it and for the time being I can use it too. But this is not convenient. I want the comfort in development.