Graphic LCD driver in new cog (code help)

Cobalt

Hi all.

I'm new to the propeller, I've had the demo board for about a week and a half now, and I love it.· I ordered two of the 40-pin DIP chips so that I can breadboard and have access to all of the IO pins for more experiments.· I've run into a small problem that I'm hoping has a simple solution:

I have a small graphic LCD, 122x32 pixels (122 wide, 32 tall).· Its uses the SED1520 controller, and I've written an object spin file that has a few methods that can handle basic stuff for it to do.· The problem is that I want to be able to load the methods into a cog such that I can easily send data to it, and let the cog handle displaying the info.· It is also all written in spin, not assembly.

It's kind of like with the TV/VGA objects that come with the prop library, you can just use something like "lcd.out(@data)".· However, I've looked over code that loads into another cog to handle things like this, and it is all in assembly.· It also looks like the assembly is all that gets loaded into the cog, and the spin code is just extra stuff that will modify variables that the assembly portion uses.· Am I seeing this correctly?

Yeah, it may be hard to understand what I'm trying to explain (I'm not really great at that, haha), but basicly I would like help on how to·load my object with multiple methods into its own cog so I can just throw bytes at it here and there.

I haven't tried assembly yet, mainly because of the new words to use, I have about 3 years of experience with assembly with PIC microcontrollers, so most of this stuff isn't too new, just some of the coding is. Thanks!

Mike Green

SPIN is an interpretive language, compiled into "byte codes" which are downloaded to the Propeller. There's a SPIN interpreter, written in assembly, that's loaded from ROM into a cog, which interprets these "byte codes". You can have a separate SPIN interpreter running in each cog, each interpreting a different set of routines. So you can have a routine, written in SPIN, sitting there waiting for data to appear in certain variables in memory, edit those variables for display, and call the graphic LCD routines to display the information. In the meantime, other cogs can be running other parts of your SPIN program preparing new data. Usually you would use the LOCKxxx calls in SPIN to signal back and forth between the different execution "threads". COGNEW and COGINIT can be used to "launch" a new copy of the SPIN interpreter. Look at those sections of the Propeller manual. The only reason assembly is needed is for speed. SPIN is fast enough to do 19.2KBps serial I/O by itself, so it's pretty fast.

Cobalt

I'm still a little foggy on exactly what to do. I understand the difference between assembly and spin language, and I understand the hardware aspect of the propeller on how it interprets spin language. I do also know about the COGNEW/COGINIT commands, ive played around with them doing simple stuff (I've run through the tutorial in the manual). I guess I was looking more for psudo-code that was more specific to my situation.
I also wanted to have one cog by itself that ran all of the LCD coding, and for it to always be on and ready to go, and not constantly launching a new cog to run a method, and then shut it back down.

I've attached my code if it helps at all, I know its really bad and not very clean, but I'm just trying to get down commands to make it do stuff before I go back and clean it up.

Mike Green

I'm not familiar with the GFX LCD you're using, so I can't help with the specifics of your code. It looks pretty straightforward.

For the kind of thing you're doing, I don't see why you need a separate cog. Maybe you're confusing the idea of an "object" with a "cog".

The cogs really are effectively separate computers. You happen to have 8 computers in a Propeller that share I/O lines and memory. Your gfxlcd.spin is a collection of subroutines/functions that have some common variables and constant definitions and usually provide some packaged functionality. In your case, this is support for an LCD. Commonly, you need some kind of initialization for this package, usually called "start" or "init" or something similar. Any "program" using this package has to call this initialization routine once before it does anything else with the package. The package provides this functionality by defining some subroutines that can be called from "outside" (PUB). There may be some internal subroutines that cannot be referenced from "outside" (PRI).

One of these objects may provide its functionality just by providing these subroutine calls. Sometimes an object needs to do something in parallel with whatever's going on in the calling program. This is done by starting up another cog to do the work. Since it takes some time (100's of us) to start up a cog, this is usually not done to do one function at a time. In your case, there's not much point to using a separate cog for the I/O unless the pauses for the LCD to do its work are significant.

ALIBE

Cobalt, I have a similar scenario in my project where:
a. Cog-A - acts as a sensory processor
b. Cog-B - acts as a reactionary processor

Cog-A - runs an endless repeat loop and w/i this loop, I gather input values from various sensory devices (such as Temperature, GPS, Ping, etc) and store the values in an array of data

Cog-B - runs an endless repeat loop and w/i this loop, I simply take the values from the data array and display on my Parallax 2 line LCD display. Pretty straight forward.

One thing to keep in mind is, if you're looking for multiple Cogs to "share" the LCD device, you must get a Semaphore Lock. It is sort of like, "App or Key Lock" if you're familiar of such a thing in PC programming. So, for example, if Cog-C wants to display on LCD, it will get a Lock and Display on LCD, and once done, "unlocks" the SemaphoreId. The methods you will use are ::LockNew() and ::LockClr()

hope that helps - and I did not further confuse you
[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·

Cobalt

You two have been very helpful, and I'm able to understand everything now... I've had the knowledge from the start, I was just understanding it incorrectly, thanks!