Yapay zekâ tarafından English dilinden çevrildi ·
Sulama kontrolcülerimizde vana mantığını bir STM32F407 yürütüyor, Wi-Fi ve MQTT işini ise yalnızca yapan bir ESP32 var; ikisi 921600 hızında UART üzerinden konuşuyor. ESP32’yi güncellemek kolay. STM32’yi ise sahada ST-Link ile donanımlı biri flaşlamak zorunda; yazın bu da çok fazla yol anlamına geliyor.Hermetry firmware güncellemelerimin STM32 imajını da iletmesini istiyorum. Bir güncelleme atandığında cihaz Hermetry’den tam olarak neyi alıyor ve geri ne bildirmesi gerekiyor? STM32 tarafında çift banka (dual bank) kurulumuna mı ihtiyacım var, yoksa harici flash’ta ikinci bir slot ile idare edebilir miyim? Parça 1 MB, imaj yaklaşık 380 KB.
Our irrigation controllers have an STM32F407 doing the valve logic and an ESP32 that only does Wi-Fi and MQTT, the two talk over UART at 921600. The ESP32 is easy to update. The STM32 has to be flashed by someone with an ST-Link in a field, which in summer means a lot of driving.
I want Hermetry’s firmware updates to deliver the STM32 image too. What exactly does the device get from Hermetry when an update is assigned, and what does it have to report back? And on the STM32 side, do I need the dual bank setup or can I get away with a second slot in external flash? 1 MB part, image is about 380 KB.
Yapay zekâ tarafından English dilinden çevrildi ·
Devamla, HVAC kontrolcülerimizde de aynı ayrım var.
Following, we have the same split in our HVAC controllers.
Yapay zekâ tarafından English dilinden çevrildi ·
Bina kontrolcülerinde tam olarak bunu yaptık (STM32 ve bir ESP32 modem). Hermetry, imajı hangi çipin çalıştırdığını umursamaz; yalnızca oturum açmış cihazla konuşur, bu yüzden indiren ve rapor eden ESP32’dir.Bir paket atadığınızda cihaz, v1/attributes/set üzerinden tek bir mesajla şu paylaşılan öznitelikleri alır: fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url ve paketin ayrık imzası varsa fw_sig. fw_url kısa ömürlü bir HTTPS adresidir, 15 dakika geçerlidir ve indirme bir HTTP Range isteğiyle kaldığı yerden devam edebilir.Cihaz ilerlemeyi istemci öznitelikleri olarak bildirir: fw_state DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (ya da fw_error ile FAILED) değerlerinden geçer, indirme sırasında fw_progress 0 ile 100 arasındadır ve yeniden başlatmadan sonra current_fw_title ile current_fw_version gönderilir. Yalnızca UPDATED kabul edilmez; yeni çalışan sürümü görmek ister.ESP32 üzerindeki akışımız:
1. fw_* gelir -> fw_title == "irr-stm32" kontrol et
2. fw_url adresinden (Range ile devam) ESP32 flash'ına GET, fw_progress raporla
3. fw_sig'e karşı SHA-256 + Ed25519 kontrolü -> fw_state VERIFIED
4. İmajı UART üzerinden STM32 bootloader'a, bank 2'ye akıt
5. STM32 tekrar doğrular, bankaları değiştirir, yeniden başlar -> fw_state UPDATING
6. STM32 sürümünü ESP32'ye bildirir -> current_fw_versionElinizde tek bankalı bir 1 MB F407 var; 380 KB için üst 512 KB’ı indirme alanı olarak kullanmanızı ve kontrol sonrasında imajı kopyalayan küçük bir bootloader yazmanızı öneririm. Harici flash da işe yarar, ancak bu durumda bootloader’ın SPI sürücüsüne ihtiyacı olur.Profilin Firmware sekmesinde firmware güncellemelerini açın (varsayılan olarak kapalıdır) ve test tezgahı dışında İmzasız imajlara izin ver seçeneğini kapalı tutun. LTE üzerinden güncellemeler de varsayılan olarak kapalıdır. ESP32 imajının asla STM32 alanına yazılmaması için pakette Donanım modellerini ayarlayın.Firmware updates (OTA)
We did exactly this on building controllers (STM32 plus an ESP32 modem). Hermetry doesn’t care which chip ends up running the image, it only talks to the device that’s logged in, so the ESP32 is the one that downloads and reports.
When you assign a package, the device gets these shared attributes in one message on v1/attributes/set: fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url and fw_sig if the package has a detached signature. fw_url is a short-lived HTTPS address, valid for 15 minutes, and the download can resume with an HTTP Range request.
The device reports progress as client attributes: fw_state goes DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (or FAILED with fw_error), fw_progress 0 to 100 while downloading, and after the reboot current_fw_title and current_fw_version. UPDATED alone isn’t accepted, it wants to see the new running version.
Our flow on the ESP32:
1. fw_* arrives -> check fw_title == "irr-stm32"
2. GET fw_url (Range resume) into ESP32 flash, report fw_progress
3. SHA-256 + Ed25519 check against fw_sig -> fw_state VERIFIED
4. stream image over UART to the STM32 bootloader into bank 2
5. STM32 verifies again, swaps banks, reboots -> fw_state UPDATING
6. STM32 reports its version to ESP32 -> current_fw_versionYou have a 1 MB F407, which is single bank, so for 380 KB I’d use the upper 512 KB as the download slot and a small bootloader that copies it over after checking it. External flash works too, but then the bootloader needs the SPI driver.
On the profile’s Firmware tab turn on firmware updates (off by default), and leave Allow unsigned images off outside the test bench. Updates over LTE are off by default too. Set Hardware models on the package so an ESP32 image never ends up in the STM32 slot.
Yapay zekâ tarafından English dilinden çevrildi ·
Çok net, teşekkürler. Bağlantı zayıfken bir indirmenin ortasında 15 minutes dolarsa ne olur? Sahadaki bazı noktalarımızda yalnızca bir çubuk sinyal var.
Very clear, thanks. What happens if the 15 minutes run out halfway through a download on a weak link? Some of our fields have one bar.
Yapay zekâ tarafından English dilinden çevrildi ·
Cihaz fw_url değerini yeniden ister (bir öznitelik isteği) ve yeni bir tane alır, ardından Range ile sahip olduğu bayttan devam eder. Bu şekilde bir saat süren indirmelerimiz oldu ve hiçbir sorun yaşamadık.
The device asks for fw_url again (an attribute request) and gets a fresh one, then resumes from the byte it had with Range. We’ve had downloads take an hour that way without a problem.
Yapay zekâ tarafından English dilinden çevrildi ·
İki test cihazında ve bir sahadaki cihazda çalışır hale getirdim. Flash belleğin üst yarısını ve 16 KB’lık bir bootloader’ı kullandım. İlk deneme başarısız oldu; paketteki fw_title değerini “irr_stm32” olarak ayarlamıştım, ESP32 ise bir tire arıyordu, bu yüzden cihaz Queued durumunda takılı kaldı. Adı doğru şekilde verince işlem UPDATED durumuna geçti ve yeni current_fw_version değeri göründü.
Got it working on two bench units and one in the field. I used the upper half of flash plus a 16 KB bootloader. First try failed because I set fw_title on the package to “irr_stm32” and the ESP32 checked for a dash, so it just sat in Queued. Named it properly and it went through to UPDATED with the new current_fw_version.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.