I added oledv2.zip to the first post. This exemplifies most of what I talked about in the previous post.
I added i2c to it, though it may not work at all as I have no way to test it. That pushed me over the maximum limit of what the interpreter can handle in a single file, so I broke it up into 3:
1. oled_init.lua - holds the initialization and i2c/spi specific code. Notice the init functions load the flash functions into memory and keep them there (while also choosing whether to load the spi or i2c version). That is what
and similar is accomplishing. This is one way to create an in-memory function, but realize it has the same access limitations as flash functions, which is basically that no variables local to the file are available. Its scope includes its parameters, its own local variables, and global.
2. oled_func.lua - holds the flash functions that actually define the interface of the module. The division of these two files was rather arbitrary, you can have as little as one function in each file, or as many as you can fit and still load the file.
3. oled.lua - this is the actual entry point to the module. This is the other way to define in-memory functions and data (other than the init method mentioned above).
So, to use this module, you would execute oled_init.lua and oled_func.lua once, then you can delete them until you change them. The persisted version of the functions will remain in flash until they are needed. Then the
in oled.lua will create the proxy module that will load those functions as needed, and add the additional functions and data that need to stay in memory.
Finally, as in test.lua, you call
to load the complete package from a compiled oled.lua.
Notice that I switched to the format
to define the function. In case you didn't know, this is just syntactic sugar
. Likewise, when I call functions on oled, I call them like
, which is syntactic sugar for
. This is what makes oled available on the self parameter within methods.
Hopefully you can get the i2c part working from this base.