Sorry Paul, I never saw your reply until today. Unfortunately our load is pretty complicated; we have one thread for each I2C bus we configure (1 or 2 depending on the system) and two threads doing socket communication (one for outgoing and one watching for incoming). We're keeping track of resets and will monitor the systems. If it doesn't improve with later firmware releases then I'll have to look at debugging the crash. Do you have instructions on how to go about that?
@protean Pymakr is indeed using the zlib.decompress() micropython function for this feature. Normal upload also still works of course, but this way is faster for large files. Let me give you some pointers on how to code it:
The zlib function on the micropython side is documented here. Pymakr is compressing the files before uploading (here using this python file), writing the compressed file to the board with os.write() like always, and then decompressing them right after that (here). It'll definitely make uploading bigger files faster. Just realise that for files under 4k, it's actually slower because the overhead of compressing/decompressing is bigger than the savings of compressing the file.
I looked at the lora-alliance website put couldn't find the certification reports -- have you made them available? Obviously we would like to use your certification but need:
the certification reports
the git hashes or release number of the code which was actually certified
Also are you planning on getting AU-915 certified, as it's a supported region in your software?
The fixes to the stack and radio drivers that you mention sound great! I had an issue with the LBT in the radio (lack of filtering so that all channels could look busy) and am interested if that was addressed.
Looking forward to the certificates and associated code!
This is all a little bit tedious, so I avoid to do it.
I remember we had a discussion about this on GitHub around Christmas last year...
Ideally the Makefile should know which branch of pycom-esp-idf should be used and clone / checkout / submodule update as necessary. It could also run make -C ../mpy-cross all before building the firmware as it should only rebuild if necessary. However checking all this before every build would probably be very annoying if it increases the build time significantly especially if you just made a small change between builds. Maybe adding this as make prepare would be better... plus a small post git checkout script that creates a file .force_prepare that would tell make to run the prepare step first so you don't forget.
Of course you can always keep two separate firmware directories, one for the master / stable and one for the release-candidate branch. You can also have a shallow clone of the IDF in each directory (git clone --depth=1 --recursive -b [master | idf_v3.1] https://github.com/pycom/pycom-esp-idf.git esp-idf) and then use a relative IDF_PATH (export IDF_PATH=../esp-idf).
We also plan to change the way we use branches in this repository. Rather than master being the latest stable release, we will create a branch for each major release version. If we did this today, we would have branches called release/v1.18 for stable and release/v1.20 for the release candidate. The master branch would always have the latest code so we can publish hot fixes without creating a full new release for the software server and firmware updater.
start from the Linux menu "Pycom Firmware tool", quote "include dev releases"
then just choice /dev/ttyACM0 in High transfert mode
the firmware is flashed in 1.18.1.r1
Wrote 1.19 MiB from sipy.bin in 1 minute and 13.88 seconds
@bmarkus Win32:Evo-gen [Susp] is a broad classification used by the Avast Behavior Monitor feature for software that exhibits suspicious behavior categorized as potentially malicious. The Behavior Monitoring feature observes the behavior of processes as they run programs.
The firmware updater connects to the Internet. That is considered "suspicious" for some anti-virus applications.
Thanks for the details. However it is a bit strange,a s I'm frequently installing programs connecting to the net during installation and have never seen such message from my AVAST.
We could change the default sort order but I'm not sure this would affect existing users. I admit it throws me off too if I'm on the forum but not logged into my account. I'll see if our system admin can do some internal tests.