First link doesn’t mention how much RAM, only 1GB?
Second link talks are about RPI3 with only 1GB RAM… ![]()
First post even includes RAM stats ![]()
First link doesn’t mention how much RAM, only 1GB?
Second link talks are about RPI3 with only 1GB RAM… ![]()
First post even includes RAM stats ![]()
Indeed it does and it is only using one core to compile. Imagine if it was trying to use all 4 how much more it would need (that it doesn’t have).
I use a rpi zero 2w and no about how to add swap to make it able to do more. I only use that for a photo frame so it isn’t really tasking it with too much. A 2GB rpi is limited in what it can do. If it is the only machine you have, it will have to do. If you have a laptop that is reasonably current (last decade or so) it likely has the ability to do the task in 1/10 the time. Why wouldn’t you want to take advantage of that?
Good morning ![]()
I have read all, what you guys wrote, but didnt understand all…
I think, the time-problem is made by myself. I had an other error and searched in the web for it and the solution was, adding the
compile_process_limit: 1
I am an " try and error" and “copy and paste” guy… sorry for that…
Ok, when i change the value to 4 or delete the code, the compiling is faster… the CPU goes up to 99% and the memory goes up to 1,6GB… but:
And that is why you added the line to limit the compile to one core. As the sign for the big roller coaster says, “you must be this tall to ride”.
You have three choices:
I have a repurposed mini desktop PC that uses a little more power at normal operation than a rpi, but can use several times that when it needs to compile something.
Now you compile on all cores ![]()
So it works? ![]()
You could try freeing up memory by temporary stopping some (heavy) add-ons before compiling ![]()
Increase the swap size and you get more virtual memory. It might keep the compile process from crashing. It will probably wear out your SD card faster, so make sure you have a tested backup AND recovery plan for when the inevitable happens and your SD card is toast.
The B&R process is good for the unusual things that can happen.
Hmmm Chromebook is what I’m using to compile esphome ESP32 projects, and it’s terribly slow… Is that due to lacking hardware resources?
I do see it is compiling stuff that I don’t use, like i2c and i2s. Is that really needed?
And it seems to compile everything on every run. Shouldn’t it compile only the files that changed? Are there some settings I need to check?
It depends on the Chromebook, but most of them are designed to be cheap. Since their goal in life is just to surf the web and run web apps, they are generally what many would consider under powered.
But, how long is your terribly slow?
For building FW for an esp chip I consider more than 30-60s to be slow and 5 min to be intolerable. This is assuming the PlatformIO has a hot cache (so it doesn’t need to download a bunch of stuff). I started using esphome because the compile times for Tasmota got to be too long for me.
Depending on the changes you make to your configuration it might actually need to rebuild everything (changing the logging level will do that) or it might just need to link everything. It does take less time to do the later, but if you are watching closely it looks like it is compiling everything.
I agree that a Chromebook is a cheap PC so indeed it cannot be expected to be quick on compiling code.
A clean build (esphome clean my_project.yaml followed by esphome compile py_project.yaml) took 7:48. This is with multiple instances of google Chrome open, each with about 10 tabs, all instances minimized.
I do indeed notice that it only recompiles a lot of files when it detects a change in the integrations used. On minor changes, like the text shown on a display it only recompiles main.cpp