MicroPython Forum (Archive)

I recently designed a 10DOF Wing for Adafruits Feather boards and today I did a redesign for the ESP8266 board. The original design works well, but on this, I completely rerouted everything. Also, the ESP double and triple uses just about any pin for some weirdo boot and sleep function, so I'm really unsure about all that.

It has:

• reset button
• BMX055 - gyro+accelrometer+magnetometer
• BME280 - pressure+temperature+humidity
• 16mb SPI flash

Check it out here: https://github.com/turbinenreiter/10DOF ... aster/v0.3

Any feedback welcome. I will let it rest a little before I have boards made. I'm also still not sure whether to use the BMX055 or the MPU9250. The later has a Micropython driver ready, for the former I'd had to write one. What I'm even less sure about is whether or not the ESP8266 actually can drive all this. The BME280 driver alone seems to be to big for it, even cross compiled and frozen. It only worked after I upped the heap to 40k.

I'm surprised a driver as small as the BME280 one is causing memory problems when saved as frozen bytecode. On the Pyboard frozen bytecode works wonders for loading large programs.

While I can see a few things which could be done to make it more compact*, I doubt it will make enough room for the other device drivers you have in mind.

* Ideas which come to mind from a brief study of the code are: use the const() declaration for register addresses, replace @property decorators with methods, remove unused methods from the Device class. A thorough review and a pass through pylint would doubtless reveal more.

pythoncoder wrote:use the const() declaration for register addresses

This actually won't save any memory. The constant still has to be available to outside modules, so it uses memory anyways.

Recently I used a different pattern in one of the drivers I wrote -- instead of using symbolic constants, which are unlikely to be used outside of the module anyways, I'm just using the constant values directly, and adding a comment explaining the value's role. While it does feel like going back in time, it does actually save memory. I'm not sure it's worth those few bytes, though.

deshipu wrote:...This actually won't save any memory. The constant still has to be available to outside modules, so it uses memory anyways...

I take your point that it doesn't save memory at the point where the constant is declared. But what about the points where the constant is used? As I understand it the const() declaration means that the compiler substitutes the literal value rather than using a level of indirection. Does this save RAM? (I guess in the case of fozen bytecode the answer would be 'no').

pythoncoder wrote:

deshipu wrote:...This actually won't save any memory. The constant still has to be available to outside modules, so it uses memory anyways...

I take your point that it doesn't save memory at the point where the constant is declared. But what about the points where the constant is used? As I understand it the const() declaration means that the compiler substitutes the literal value rather than using a level of indirection. Does this save RAM? (I guess in the case of fozen bytecode the answer would be 'no').

Well, the generated code is shorter. And faster. But as you say, in case of frozen modules that lives in the flash, so no gain there.

Do you find it surprising that the ESP8266 seems near the limits with this driver as frozen bytecode, or is it representative of the maximum size of program we can expect to run?

Hi All,
I'm wondering if really frozen bytecode was tested and not frozen modules. With frozen bytecode I had no problem running a 600 LOC program, and I did not even test the limits or notice one. Since frozen bytecode resides in flash and the critical compile step is done during the creation of the image, only the RAM usage for data objects counts at the end. But the frozen bytecode is not officially available yet. You can try it using this PL https://github.com/micropython/micropython/pull/2067, which gives you a good impression of the properties.
But at the moment there is still a conflict with socket service.
Kind Regards

P.S.: I loaded the BME280 driver to frozen byte code. Flash usage 5408 bytes, RAM usage after import 1440 bytes. Interestingly, there was only 24 bytes difference in flash usage when using const() definitions, and no change in RAM usage.

Extending the discussion above about using const() and possible improvements:

I loaded the BME280 driver to frozen byte code. Flash usage 5408 bytes, RAM usage after import 1440 bytes.
Loading the same driver with the assignment replaced by const definitions: Flash usage 5394 bytes, RAM 1440 bytes
Replacing the const definitions be literal constants in the code: Flash usage 4110 bytes, RAM 1088 bytes.
That makes me wonder whether using const() really is replacing the symbol by a constant during parsing, as claimed.
Regards, Robert

In my recent drivers, I decided to write things like:
instead of
I think it's as readable (or even more), and at the time saves memory. The only down side is that you don't get to use the constants from outside of the library, but usually you never want to anyways.

I wonder if it would make sense to add it to the driver guide in the wiki?

Registers or commands that don't need to be exposed outside of the driver, should be fine to be left hardcoded I think. But for example in my st7735 driver, the init function is left up to the user to avoid increasing the size of the driver, so some have to be left as const(). If there is really no better way of achieving the same, it makes sense to add it to the wiki as a general guideline. But would be nice to get an opinion from one of the core devs!