Sharing objects in spin
Seairth
Posts: 2,474
in Propeller 1
So, I've written a menu object for the badge (more on that in a later post). While writing this, I encountered an issue that I had surprisingly not encountered before. The issue is that I want the menu object to directly access the OLED. To do this, I would normally just instantiate an OLED object in the menu object. However, the top-level object had already instantiated the object for the OLED (for doing non-menu drawing). Since the OLED object uses an additional cog, this would result in two cogs being used.
To avoid this, I am doing all of the OLED interaction in the top-level object and simply using method calls on the menu object to get the necessary data to draw it. It's not an ideal solution, but I'm not aware of another one.
Is there an established design pattern for accessing a shared resource from multiple objects, particularly when the shared resource's object uses additional cogs? This is a general question, not specifically about the OLED object code. Even if additional cogs were not being used, there's still the potential of two instances of an object performing conflicting operations on shared resources (pins, locks, etc.)
@cgracey: for future versions of Spin, what I'd really like to do is something like:
where the "GLB" section indicates singletons that are truly global to all objects. Each object would still have a local unique name, but they would all reference the global instance.
To avoid this, I am doing all of the OLED interaction in the top-level object and simply using method calls on the menu object to get the necessary data to draw it. It's not an ideal solution, but I'm not aware of another one.
Is there an established design pattern for accessing a shared resource from multiple objects, particularly when the shared resource's object uses additional cogs? This is a general question, not specifically about the OLED object code. Even if additional cogs were not being used, there's still the potential of two instances of an object performing conflicting operations on shared resources (pins, locks, etc.)
@cgracey: for future versions of Spin, what I'd really like to do is something like:
' top-level object GLB oled : "oled_driver" OBJ menu : "menu_driver"
' menu object GLB screen : "oled_driver"
where the "GLB" section indicates singletons that are truly global to all objects. Each object would still have a local unique name, but they would all reference the global instance.
Comments
If there's a method to start a cog, that method should only be called once.
I personally think this already works really well with Spin. I don't see a need for a change.
I doubt you need but I have a faster version of the OLED driver. I've also added some methods to "bounce" bitmaps around the screen. You can see an example of this in my CNC controller video.
I'm sure it's all relatively easy to reproduce but if anyone is interested, I'll try to get it cleaned up for public viewing.
As I mentioned earlier, the Start method should only be called once. I believe this example includes locks.
localroger wrote about using multiple instances of objects. I'll see if I can find his post.
http://forums.parallax.com/discussion/148937/concept-test-general-purpose-string-output-formatting
http://forums.parallax.com/discussion/149189/updated-x2-with-examples-modular-programming-in-spin
http://forums.parallax.com/discussion/149341/proptool-object-files-exceed-64k
I would still like a change to Spin that supports something like I was suggesting to Chip. The primary reason is that it gives the user control based on intent. For instance, suppose you wanted to use the same OLED driver to interact with two separate displays. In that case, you don't want to share. Or maybe you still want to share, but still need two distinct object instances. Either way, using DAT would not be appropriate. In essence, the above suggestion basically allows a user to indicate whether they want the VAR section of an object to be treated as per-instance (like VAR currently) or per-object (like DAT).
For my needs, however, using DAT should work fine. After all, the eBadge only has one OLED display. For that matter, it also has one set of button pads, so I'll be rewriting my button pad object to use DAT as well.
incidentally, the OLED object I'm using has some of those methods that you mentioned. I don't have the code in front of me at the moment, so I haven't looked to see who wrote the driver. All I recall is that comments indicate it supports two different OLEDS (128x32 and 128x64) sold by Adafruit.
My version (look in the menu demo thread) of the driver simply takes the fastasm version you were using and moved the VAR variables to DAT.
I've written my own Spin driver and am now moving most operations to PASM. The other driver builds the buffer in Spin which slows things. I also have magnifying for the built-in 8x8 font so it can display 8x8, 16x8, or 16x16. The trick is converting the Propeller font mapping to PASM. Hope to be done by the end of the month, and may ask for help from some of the PASM gurus on the forums.