Prop to Prop memory mirror?
lmclaren
Posts: 104
Hi,
My current project has outgrown a single prop board and I now need to use 2.
I am building a coffee roaster and have a large number of inputs / outputs using different protocols and have ran out of cogs and I will be stretching with memory by the end.
My biggest problem is the video display uses 3 cogs "vga_1280x1024_tile_driver_with_cursor" I have choosen this driver as I want to be able to change the colour of charaters on a line.
What I am thinking of doing is to split the display / sd card functions onto one prop and free up resources on another.
As most of my cogs communicate via a shared memoy object, I was wondering if a basic coms routine that is ran on both props could bidirectionaly update their own DAT memory.
It would need some basic error checking as corrupting the memory for the 15Amp heater and blower control might result in some expensive repairs.
Any suggestions?
many thanks
Lee
My current project has outgrown a single prop board and I now need to use 2.
I am building a coffee roaster and have a large number of inputs / outputs using different protocols and have ran out of cogs and I will be stretching with memory by the end.
My biggest problem is the video display uses 3 cogs "vga_1280x1024_tile_driver_with_cursor" I have choosen this driver as I want to be able to change the colour of charaters on a line.
What I am thinking of doing is to split the display / sd card functions onto one prop and free up resources on another.
As most of my cogs communicate via a shared memoy object, I was wondering if a basic coms routine that is ran on both props could bidirectionaly update their own DAT memory.
It would need some basic error checking as corrupting the memory for the 15Amp heater and blower control might result in some expensive repairs.
Any suggestions?
many thanks
Lee
Comments
Lee,
How many lines of VGA do you really need?
If your only problem is using 3 cogs on the VGA but you could actually live with only 15 display lines on the VGA, then I think perhaps you could use the plain old VGA_text object. You can change colors with that, at least to some extent. You can also place text in different block areas on the VGA. Just a thought.
http://obex.parallax.com/objects/70/
Too easy! - just use Catalina!
On multi-CPU Propeller platforms Catalina supports C programs that execute across multiple Propellers, using drivers that run on either one. The TriBladeProp and the Morpheus are both supported "out of the box" - other platforms would take a little work.
For instance, the Morpheus has a high resolution VGA device on one CPU and the keyboard, mouse and SD card device on the other CPU. You can run a Catalina program on either CPU that uses all these devices as if they were local to that CPU.
There are examples in the Catalina demo folder.
Ross.
The main reason I came to the propeller is SPIN and the Assembly.
My brain does not like C, but as I am doing a masters degree in IT I may not be able to dodge it...
I understand it may not suit your current application, but I'm afraid you won't be able to dodge it forever - C is the "de facto" standard for embedded work, and also for most low level system work (kernels, drivers, etc). While this state of affairs will not last forever, there is nothing currently on the horizon that looks like dislodging it, so it is worth learning (now excuse me while I go and don my asbestos suit!
Ross.
-Tor
Multiprocessing is really what Catalina is all about. I never cared particularly about writing a C compiler - I just wanted to explore multiprocessing, and C happened to be the easiest vehicle to do it with. I don't think many people realize it yet (or care much, if the truth be known - which makes you wonder why they use a Propeller in the first place!) but Catalina already has full multithread and multicog processing designed into the kernel - i.e. you can run multiple C threads on one cog, and multiple C cogs on one Prop. All these C threads can then communicate and interact freely. You can even "move" C threads from one cog to another (I'm not quite sure myself what the use of this capability will be - but it turned out to be easy to do, so it's in there!).
The next step is to be to be able to do the same between cogs running on different CPUs in a multi-Prop system. All the pieces are in place ... just got to find the time to finish it off
Ross.
I can understand your feelings. If you can do assembly, you might want to consider forth. How do you like RPN calculators?
Adding more props to get more cogs and pins is pretty much transparent to the application.
http://code.google.com/p/propforth/
The current version is 4.6, demonstrates all the technics, the next version is scheduled for September and is optimized for speed and smaller memory footprint.
I've never done it myself, but I've been collecting bookmarks for doing such a thing. For example:
http://forums.parallax.com/showthread.php?129064-Inter-propeller-communication-hardware
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=395364
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=430277
PropForth (although a different language) does have the basic mechanics in it to allow multiple props to exchange data, execute code on each other and other needed functions. From this basic support, complex, multiple prop applications can be built but the programmer still needs to come up with the protocol to support their needs. Works well and lots of fun to play with. I haven't written an application using it yet.
It sounds like Catalina has the basic mechanics in place also (no personal experience) but the programmer still needs to build the higher level protocols.
As for Spin and PASM, the basics also exist but may need to be packaged and as with the others........higher level functions are left for the programmer.
Once working, it sounds like a good OBEX contribution!
Sure, if he thinks its easier. Spin tends to be best on a single prop, an alternative exists thats designed for multiple props. The propforth method makes extra props appear as more resources on the same prop, one big virtual prop. But if its easier to do this from scratch, by all means go ahead. There are always better solutions waiting to be discovered.
In any case, there is still work to be done.
The project is a coffee roaster, my first propeller project, never seen or touched one before I started the roaster. Have played with PIC and Arduino over the years.
Currently implemented:
Dual phase controlled dimmers for the blower and heater
Dual Max6675 thermocouple thermometers
Quad A/D for height etc
Serial to Artisan
Video display
To be done
Complete the GUI
SD card interface to load profiles and log data
PID control
Roasting Profile programming language.
I have ran out of cogs as I am using 4 in the user interface, 3 for the video display and 1 for the keyboard.
The phase controller runs on its own cog, it each half phase it check a memory location for the required output and sets the appropiate trigger delay, This is done every 10mS and has no room for jitter.
The Max6675 and A/D are read every in turn every 40mS and again save their values in shared memory for the other cogs to look at, the cog that does the Max and A/D also processes the serial out for Artisan. I have interleaved the processing but are pushing my luck if I try to add more.
Serial device uses 1 cog.
Main cog processes the data from the KB and will do the PID.
3 go for the video device and 1 for the KB device.
As you can see, things are tight. I would love to add SD card but dont have the cog and also memory is getting low, buy the time I flesh out the display I will be out.
As most of the important stuff just runs in its own world and just gets or sets values in shared memory, the coms between cogs is not complex. The same would apply if they where on seperate props.
I dont want to do a complete rewrite at this point as I am close to finishing and really want to roast coffee as that is the whole point!
best regards
Lee