@Jakob-Rosenberg-0 Good news. Given the content of the EOL announcement email sent out recently, specifically the focus on the platform as a service I did begin to wonder whether the Pymakr plugin would continue to be maintained. I really hope it is. I have no desire to switch to using Pybytes whatsoever.

@ahmadelmasri I solved this with a tip from the README. Python version was incompatible.

@kjm Since main.py is executed on the target, it is accessing the files on the target. The GPY has no acces to the PC file system. The only thing that you can get is synchronizing the lib files form you Atom/PC library to GPY. I do not work with the pymakr plug-ins, so I cannot give you details, but there were threads of synchronizing a project directory with the target module.

I ended up using Atom on my windows pc and was able to talk on the port no problem. I'm not sure why the port was closed on the fedora pc. Hopefully this helps someone in their setup.

Thanks for this information. It is useful

@momentaj When using the pycom uploader 1.15.2, you have tghe option to erase the device on uploading a new firmware image.

@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.

@kjm But maybe since we are mentioning it... someone who already has a fix can pass it along. Or someone who didn't realize it was a problem can make the next version a little bit better. Hopefully shared misery will have a shared cure. ;)

@mraj That's the way: Either it is called main.py, or main.py contains a line import mycode or boot.py contains a statement machine.main("mycode.py"), which causes mycode.py to be executed instead of main.py

@dan I finally made it work! But only because of your advice! Thank you so much!!!

@dan I understand that and get this error when I flash it, but I would also like it to link in Atom so I can build and run it right away without having to flash it. [image: 1537809779016-2f6c007e-17d2-4496-a1eb-b82c77973113-image.png]

Hi @grideagle, Thank you for reporting that, I've reported it to GitBook. The current workaround is to use the "copy" button it the top right corner of the code section.

@nickboots Great! I'm glad you sorted it out. The project name label might be related to this issue, you should be still able to upload/run your project, it's just the label that doesn't update. FTP only works with WiFi, if you want to use the serial connection, you can use Pymakr with Atom/VSCode, or rshell.

@mj It's just some math, you don't need a module to do it. However, be aware that most trilateration formulas are based on exact distances, which you are very unlikely to get, so you'll end up with no solutions if you try to solve the equations as equalities. Also, I don't know your use case, but it may indeed make more sense to do this stuff network-side rather than on the node.

We are aware of this issue, expect and update very soon to resolve this.