A "Gem" found in the Prop Q&A
eldonb46
Posts: 70
This is my short story, . . .
I have been Spinning Propeller programs for several years, but still consider myself a Noobe. I have several Prop hardware sets, and they are all configured differently, for different projects.
But, it have been a "Pain in the Butt" to continually adjust SPIN programs when moving programs between my hardware sets. Or, trying to use DEMO programs from the OBEX. Or, to configure for DEBUG output to go to another display.
A big problem is that each my hardware configurations uses different (or multiple) Display devices:
To help with the display API compatibility issue, I had previously started programming my projects using a small subset of the capabilities of each Display OBJ Driver. That works to an extent, but greatly limited functionality.
To solve this major issue, I created an intermediate Object; as "DSPL.spin", which translates via Methods the OBEX Driver syntax into a common API for my SPIN programs. My "DSPL" object augments, and/or in some cases corrects errors, for the OBEX Drivers.
But still, my programs needed modifications when changing hardware, to take advantage of; Zero, One, or More connected displays.
What I need is a "Display Logical Unit" (LU), that can be accessed under program control. I ask the Parallax Forum for help or suggestions:
See: http://forums.parallax.com/showthread.php?141165-Does-an-Object-have-an-address-that-can-be-used-in-SPIN
Some good suggestions were provided. But still, I was disheartened, and I abandoned my hope for a software LU style solution.
. . .
And then!
While reading the Propeller Q&A, Under: Objects -> "Can one object use multiple instance of another object?" -
The text suggests that my "DSPL.spin" Objects could be accessed via an "index number". In my head I translated that into the following potential example:
I normally read everything that I can find on the prop, and have read the Manual several times. But somehow, the significance of this GEM has escaped my attention. The "index number" to access an Object effectively implements my desired programmable LU number!
But, my first attempt to use the LU strategy meet with an error, which to took some time to figure out. I had used "search and replace" to change my "DSPL." syntax to the indexed form; - "DSPL." became "DSPL[2]."
The compiler choked on:
with an error something like; "DSPL - Error (609:37) Expected"
What??? Expect What??? What Does that mean? !!
The prop manual, FAQ's and Q&A provided little help. A friend suggest that maybe because the OBJ is used only once by the compiler, maybe the index was not needed for "Object Constant Referencing"? even thou indexing is used every place else.
. . . . Yes, it worked !!, the corrected syntax is:
(A trap for us noobe players :-)
So, now everything works using LU's for my multitude of Displays. And, Very few SPIN changes are necessary when moving programs between my hardware sets.
---
An Interesting Note:
My original Forum Post where I asked about LU's, using dummy example syntax, was almost the exact syntax that is provided by SPIN (thanks dev guys).
The solution is simple:
Indexed an intermediate OBJ to provide common API Methods for OBEX Objects.
I am now a happy Prop Spinning Camper !!
Now, if I can just figure out a way to display a Cursor on the VGA display, . . . the quest goes on . . .
Eldon
--
I have been Spinning Propeller programs for several years, but still consider myself a Noobe. I have several Prop hardware sets, and they are all configured differently, for different projects.
But, it have been a "Pain in the Butt" to continually adjust SPIN programs when moving programs between my hardware sets. Or, trying to use DEMO programs from the OBEX. Or, to configure for DEBUG output to go to another display.
A big problem is that each my hardware configurations uses different (or multiple) Display devices:
- Serial
- VGA
- Parallel LCD
- I2C Backpack LCD
- Direct I2C LCD
- LCDs of different sizes
- TV
- etc, etc.
To help with the display API compatibility issue, I had previously started programming my projects using a small subset of the capabilities of each Display OBJ Driver. That works to an extent, but greatly limited functionality.
To solve this major issue, I created an intermediate Object; as "DSPL.spin", which translates via Methods the OBEX Driver syntax into a common API for my SPIN programs. My "DSPL" object augments, and/or in some cases corrects errors, for the OBEX Drivers.
But still, my programs needed modifications when changing hardware, to take advantage of; Zero, One, or More connected displays.
What I need is a "Display Logical Unit" (LU), that can be accessed under program control. I ask the Parallax Forum for help or suggestions:
See: http://forums.parallax.com/showthread.php?141165-Does-an-Object-have-an-address-that-can-be-used-in-SPIN
Some good suggestions were provided. But still, I was disheartened, and I abandoned my hope for a software LU style solution.
. . .
And then!
While reading the Propeller Q&A, Under: Objects -> "Can one object use multiple instance of another object?" -
I found a GEMstone !! Eureka !!
The text suggests that my "DSPL.spin" Objects could be accessed via an "index number". In my head I translated that into the following potential example:
[COLOR=#000000][FONT=arial]OBJ
DSPL[4] : "DSPL"[/FONT][/COLOR]
[COLOR=#000000][FONT=arial]PUB[/FONT][/COLOR]
[COLOR=#000000][FONT=arial]. . .[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] DSPL[N].str( . . .[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] DSPL[stdout].str( . . .[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] DSPL[DEBUG].str( . . .[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] DSPL[NULL].str( . . .[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] repeat D from 0 to 3[/FONT][/COLOR]
[COLOR=#000000][FONT=arial] DSPL[D].str( . . .[/FONT][/COLOR]
etc,etcI normally read everything that I can find on the prop, and have read the Manual several times. But somehow, the significance of this GEM has escaped my attention. The "index number" to access an Object effectively implements my desired programmable LU number!
But, my first attempt to use the LU strategy meet with an error, which to took some time to figure out. I had used "search and replace" to change my "DSPL." syntax to the indexed form; - "DSPL." became "DSPL[2]."
The compiler choked on:
[COLOR=#000000][FONT=arial]Cursor_Type := DSPL[2]#CUR_BLOCK[/FONT][/COLOR]
with an error something like; "DSPL - Error (609:37) Expected"
What??? Expect What??? What Does that mean? !!
The prop manual, FAQ's and Q&A provided little help. A friend suggest that maybe because the OBJ is used only once by the compiler, maybe the index was not needed for "Object Constant Referencing"? even thou indexing is used every place else.
. . . . Yes, it worked !!, the corrected syntax is:
[COLOR=#000000][FONT=arial]Cursor_Type := DSPL#CUR_BLOCK[/FONT][/COLOR]
(A trap for us noobe players :-)
So, now everything works using LU's for my multitude of Displays. And, Very few SPIN changes are necessary when moving programs between my hardware sets.
---
An Interesting Note:
My original Forum Post where I asked about LU's, using dummy example syntax, was almost the exact syntax that is provided by SPIN (thanks dev guys).
The solution is simple:
Indexed an intermediate OBJ to provide common API Methods for OBEX Objects.
I am now a happy Prop Spinning Camper !!
Now, if I can just figure out a way to display a Cursor on the VGA display, . . . the quest goes on . . .
Eldon
--
Comments
For the cursor, this can be done in a few ways...
1. Mod the VGA code to look for a cursor location, and turn the character on/off (i.e. replace with and underscore or block) during the vertical blanking interval. This results in an alternating character and underline/block. Just use a counter in the vertical blanking to set the time to about 0.5 seconds.
2. Use the spin code to swap the character to an underline/block every 0.5 seconds.
3. Just use an underline with the character (provided the character font allows for this)
For an example see my debug 1pin TV & keyboard in the obex.