There is a test program (test_time.c) in the Catalina/demos directory that turns your Prop into a digital clock. Requires TV or VGA output, and it should be compiled with the CLOCK option defined - e.g:
In case you're interested, here is the terminal code I use in propeller-load.
Thanks, David - but the problem is definitely serial comms related. I use the curses library (which means the terminal emulation code is only a few lines) and everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.
Ross - I think some time ago you posted something about running Spin and C together. I was wondering - is it possible to run two C threads at the same time? Let's say, hypothetically, that each thread had access to half the hub ram and 4 cogs. Or, if that is too complicated, one thread is the Input/Output thread which would handle keyboard/mouse/display via stdio, and the other thread talks to the I/O thread via common hub memory?
Of course. You can either run two kernels on two cogs, or run two threads in one kernel on the one cog - or do both. And any cog not being used for C (or plugins) can be used to run Spin.
What I am thinking of is an 'operating system' thread that handles input and output, and a 'program' thread where programs can be loaded and unloaded. Or more specifically, I am trying to write a program in C and it ends up with huge overheads running OS type stuff like loading in fonts from sd card and putting them on a display, and it may be easier to split the task into two.
Certainly possible, although I'd not recommend a Prop 1 for such a task. Perhaps on the Prop 2 ...
I'm doing some experiments with 320x240 displays and these have their own internal memory, so this has opened up a whole new way of doing things because no hub is needed for a screen buffer, so essentially all the hub is free.
If the above is possible, is it also possible to have separate caches for each thread? Maybe 4k for each or something?
I'm working on this. This is required to run multi-cog XMM programs effectively. I have to say again, though - I don't think the Prop 1 is ever going to be very suitable for projects like this - I'd at least wait for the Prop 2.
One thing that has struck me with many propeller programs is that you have 8 cogs that can run in parallel, and the first thing you do is write a program that is one single program. I find it hard to *think* in parallel, but if you have cogs running in parallel, why not kernels running in parallel, and XMM programs running in parallel? Each has its own cog, hub and external memory.
I think the prop I could be eminently suitable doing this. eg there is a post active at the moment where someone wants to run a robot with 5 propellers - one does legs, one does vision etc. If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller, or 5 kernels on separate propellers, and the process of changing from one to the other should be fairly simple as it is all just C code. So you start off trying to fit it all in one propeller but if you run out of cogs then you can move code into other propellers.
Ok, say this is possible, how would kernels talk to each other? Can you define a common block of memory for "inter-kernal communications"?
One thing that has struck me with many propeller programs is that you have 8 cogs that can run in parallel, and the first thing you do is write a program that is one single program. I find it hard to *think* in parallel, but if you have cogs running in parallel, why not kernels running in parallel, and XMM programs running in parallel? Each has its own cog, hub and external memory.
Yes, this is generally a very difficult things to do. Ideally, you want a language that does it for you automagically - but to date there isn't a good candidate language available (by that I mean a usable one - I know there have been many attempts).
I think the prop I could be eminently suitable doing this. eg there is a post active at the moment where someone wants to run a robot with 5 propellers - one does legs, one does vision etc. If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller, or 5 kernels on separate propellers, and the process of changing from one to the other should be fairly simple as it is all just C code. So you start off trying to fit it all in one propeller but if you run out of cogs then you can move code into other propellers.
If I get time, I'll add the work I've done on multi-core XMM support to the next release of Catalina. I'm not getting as much time to work on this as I'd like at the moment.
Ok, say this is possible, how would kernels talk to each other? Can you define a common block of memory for "inter-kernal communications"?
In most cases, you can just use global variables. Where this is not sufficient (e.g. due to race conditions) Catalina also provides low level support for mutexes, from which any higher level inter-process comms mechanism you want can be constructed.
...if you have cogs running in parallel, why not kernels running in parallel,
and XMM programs running in parallel? Each has its own cog, hub and external
memory...
Because it would be mind bendingly slow. In the simple case each XMM program
fetches it's instructions and data from external memory directly with no
caching. So the kernel(cog) currently accessing external memory holds up all
the other kernels until the access is done. Result being that everything
proceeds at a snails pace.
Next up up put a cache in HUB, or even one per kernel, still all the kernels
are fighting over external memory when they need their caches updating. Plus
you have lost all your HUB space.
This is a thousand time worse than cogs waiting for their HUB slots to access
HUB RAM. At this point you are better off running your code on some other MCU
that has the address space for large programs and interrupts to schedule
tasks/threads,
If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller,
or 5 kernels on separate propellers, and the process of changing from one to the
other should be fairly simple as it is all just C code. So you start off trying
to fit it all in one propeller but if you run out of cogs then you can move code
into other propellers.
"Fairly simple as it's all just C code" except for:
Ok, say this is possible, how would kernels talk to each other? Can you define a
common block of memory for "inter-kernal communications.
In one chip they would probably communicate via shared HUB. In many chips they
would need to use some inter chip coms link. Migrating code around like this
is not so simple.
This is exactly the problem addressed by the old Transputer chip from the 1980's and today the chip from the company that shall remain nameless here.
Because it would be mind bendingly slow. In the simple case each XMM program
fetches it's instructions and data from external memory directly with no
caching. So the kernel(cog) currently accessing external memory holds up all
the other kernels until the access is done. Result being that everything
proceeds at a snails pace.
Those of us who try to run large C programs on the Prop 1 are used to that, surely?
Next up up put a cache in HUB, or even one per kernel, still all the kernels
are fighting over external memory when they need their caches updating. Plus
you have lost all your HUB space.
This is a thousand time worse than cogs waiting for their HUB slots to access
Not exactly - the nature of caching means that performance of 1x8k cache is not going to be significantly different than the performance of 8x1k caches.
At this point you are better off running your code on some other MCU
that has the address space for large programs and interrupts to schedule
tasks/threads,
I beg to differ - it is not actually code you are migrating, it is a thread of control. Catalina can already do this between cogs. Doing it between chips is not much more difficult (assuming all the chips have the same code loaded). This is on my list.
Let's see. Say you take a C program running in a cog kernel and say it has 8k of hub ram available as a cache. This is what we have already. Now Ross has said this runs extremely fast because almost all the time it is reading from cached hub ram, not from XMM ram. I did not quite believe this so I wrote my own test code and ran it. Ross is correct. It runs almost as if the XMM is not being accessed, and I suspect because it is a cache, the XMM memory is not being accessed much.
That means that the XMM memory speed is rather irrelevant. It also means that if two kernels are trying to access XMM memory, this will only happen infrequently and it is actually very unlikely that both want to access XMM at the same time.
I very much suspect that the two kernels will run just as fast as one kernel. Indeed, because they are separate, they will be running twice as fast overall. Net result - maybe you lose 10% of speed due to external ram access, but you gain 2x speed due to two kernels. I suspect this means faster code overall, not slower code.
WRT inter kernal comms, let's say we had 5 physical propeller chips all talking via Tim Moore's 4 serial object. And let's say that the way they all talked was via a common circular buffer in hub of 128 bytes. That enables intercompatability with existing code. Now let's say you put all this into one propeller. You could do the same thing by creating 5x128 byte buffers in hub memory. Not difficult. Each buffer might contain data packets of various sizes, with say a start byte (02), number of bytes, source, destination, data packet, and finish byte (03). Any program can search for packets destined for itself.
There are other protocols that are possible, but you don't need much to enable a comms system. With the above protocol, you might define a data packet to say "read x bytes at hub location y" and then you can transfer arrays between kernels.
You could even define a super simple interkernal comms system using one or two longs. Flag to say data is present. Read i bytes at hub location j to location k. Reset flag when you have read this. That might only be two longs and it enables whole hub memory to be transferred.
In some ways it may not matter what protocol you choose. That can be defined in your C program. All you really need is for a C program to be able to read and write longs (only one or two) to fixed locations in hub memory.
Where this could lead is something really cool. You could have two (or more) C programs, hundreds of kilobytes in size, running in parallel. How they interact is up to the programmer. Maybe they don't even interact at all (each has its own external comms ports for instance and interacts with the real world but not with each other). If there are race conditions, well it is up to the programmer to handle how those work.
I beg to differ - it is not actually code you are migrating, it is a thread of control. Catalina can already do this between cogs.
This is what I am thinking - Catalina already does this. Much of the propeller runs in parallel anyway. Hub for each kernel are going to be separate so there is no thread problem there. Each thread will have its own cogs so no problem there (eg each thread might have its own serial comms port cog for instance). The main one that seems complicated to me would be two kernels wanting access to XMM at once, and two kernels wanting access to an SD card at once. But that ought to be just two locks?
Thanks, David - but the problem is definitely serial comms related. I use the curses library (which means the terminal emulation code is only a few lines) and everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.
Ross.
I wasn't aware that curses (or is it ncurses?) had a terminal emulator function. Does using curses mean that you get full VT100 or ANSI terminal emulation? That should be handy. My terminal mode is much simpler than that. I put it in originally for debugging the loader and people found it useful so it's become a permanent feature.
I wasn't aware that curses (or is it ncurses?) had a terminal emulator function. Does using curses mean that you get full VT100 or ANSI terminal emulation? That should be handy. My terminal mode is much simpler than that. I put it in originally for debugging the loader and people found it useful so it's become a permanent feature.
Hi David,
No, curses does not have a built-in terminal emulator (although it does simplify the code if you want to do fancy things like screen manipulation in your own code). Mainly, it just avoids the need to do all the low level i/o configuration and "select" calls on a set of file descriptors just to be able to do multiple stream character I/O. I hate all that crazy BSD stuff - it's such a bizarre and non-portable way to have to do things.
... everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.
Ross.
I've finally managed to test the new Payload on a native Linux installation (thanks to those that offered theirs) and confirmed that this is indeed a problem related to using a virtual serial port when running Linux under VirtualBox. VirtualBox seems to have quite a few problems with USB devices and serial ports.
On a native Linux installation everything works fine.
However, I probably won't bother releasing a Linux binary until Catalina 3.5 is ready for release - but if someone really wants it sooner, let me know.
I think Spin is going to run out of memory for such a display so it is back to XMM C.
These displays come with a huge library of C code but I don't think this is going to work as it is not fast enough. Filling an entire screen with 320x240x2 bytes using Spin takes ten seconds. C is faster but ideally I'd like this to be 100x faster and take 1/10th of a second, which is a data rate of around 1.5 megabytes per second.
For things like font libraries, the display has a mode where you send it an "address" which is 4 bytes, x1,y1,x2,y2 and then you stream bytes and the display fills up a block defined by those four values. If x1=x2 or y1=y2 it draws a line. Or you fill a square or a rectangle.
This is perfect for tile drivers and for icons, and for drawing fonts on the screen and is a lot faster than sending pixels one at a time (though if x1=x2=y1=y2 it does just draw a pixel with the next two bytes).
However, the more pixels and the better the resolution, the more data is needed. I am not sure if an SD card is fast enough. It probably is but I need to do some real tests with refreshing text by drawing fonts one at a time.
To get the speed up I am trying to use parallel data as much as possible. So data goes from an SD card into external memory (it could go into hub, but at 153k for a screen, this is too much for hub, or for a cache for that matter). Access to the sram is via a pasm program and I'm hoping I can write some pasm primitives to move blocks of data directly from sram out to the display one byte at a time. Maybe 30 pasm instructions to move one byte??
One catch is that the display shares the same propeller pins as the XMM C code. So one needs to pause C processing while a block of memory is moved out to the display. I already have this working with other graphics drivers.
I have some ideas for how this pasm code will look and maybe once I write it I might also have some ideas that could be useful for the huge intercog communication standard thread!
Hopefully we can get some sort of GUI working on this display using C
I have one or two of those displays available plus a spare adapter board that plugs into a standard GG USB board. So you could test this out if you wanted and see if something is possible in C. Even a dual color 40 column text display would be very useful on this display.
I've come up against a silly little problem with the cache command - I think it is paired with something else. This is my program:
#include <stdio.h>
int main ()
{
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
return 0;
}
and if I compile with LMM it works fine.
If I compile with external memory and a cache using this line it works fine
I have one or two of those displays available plus a spare adapter board that plugs into a standard GG USB board. So you could test this out if you wanted and see if something is possible in C. Even a dual color 40 column text display would be very useful on this display.
I've come up against a silly little problem with the cache command - I think it is paired with something else. This is my program:
#include <stdio.h>
int main ()
{
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
return 0;
}
and if I compile with LMM it works fine.
If I compile with external memory and a cache using this line it works fine
but if I compile with the XMM on but cached off using this line
catalina -lcx -D LARGE -D DRACBLADE -D HIRES_VGA NEW.C
I get a blank screen with just a cursor flashing.
What is the correct syntax for no cache?
Hi Dr_A,
I think we've been down this road before. I can't remember the exact answer (I'll figure it out again tonight) but just try removing all those unnecessary options from your compile command.
I'll try it out tonight, but in the meantime you could try:
catalina -lcx -D LARGE -D DRACBLADE -D HIRES_VGA NEW.C
No sorry, won't have a chance to test till later tonight.
I tried reading the document you have that describes all the settings but SHARED_XMM does not seem to be on the list, so I'm sort of guessing and randomly removing settings but not quite knowing what they all do.
I have some C code that loads up cog 7 with a plugin and it works with LMM mode but not with XMM mode and caching, and I suspect the cache is using the last free cog. So I had the idea of removing the cache command and leaving it in XMM mode but then it wouldn't print "Hello World" any more.
Freeing up a cog is the first step in getting a 320x240 touchscreen working...
No sorry, won't have a chance to test till later tonight.
I tried reading the document you have that describes all the settings but SHARED_XMM does not seem to be on the list, so I'm sort of guessing and randomly removing settings but not quite knowing what they all do.
SHARED_XMM is now an internal flag - it should only be set on certain hardware, and (if required) it is now set in the *_CFG.inc file (e.g. DracBlade_CFG.inc).
SHARED_XMM is now an internal flag - it should only be set on certain hardware, and (if required) it is now set in the *_CFG.inc file (e.g. DracBlade_CFG.inc).
Ross
Dr_A, I just did a quick search, and here is the previous thread on exactly the same issue.
Yes, it looks like I fixed that in code::blocks. Now I need to do the same thing on my IDE.
code::blocks is nice but it doesn't quite have the flexibility of a custom IDE. Debugging plugins is hard and I need a way of including inline pasm code so that changes can be made in the C code and the pasm code at the same time. Once I get a driver working I'll be able to go back to code::blocks but meantime, thanks for your patience while I bring my IDE up to the version 3 standard
Another option is to leave in the caching and remove some other cog. Maybe the mouse cog, since that won't be needed for a touchscreen...
The only change here is that when the cache is deleted it does not work.
I have tried with vga hi res, vga lo res, tv hi res and tv lo res and it is the same problem - with no cache there is just a flashing cursor and no "Hello World".
Below is the full printout of the compilation. Any help would be most appreciated.
Addit: having said all this, what I really want to do is free up a cog so maybe there is another way. Will removing the mouse free up a cog and if so, what command do I add?
Sorry to trouble you again but I made those changes and I'm still having problems. I know this is v 3.3, not 3.4, but hopefully that is ok.
I can't see why this wouldn't work - everything looks ok. I will re-install 3.3 and try this tonight. I do vaguely remember making some changes in the VGA support of the DracBlade, but I can't remember which version that was in, so I'll have to wait till I get home to investigate further.
If you get time before then, try using -D SMALL (instead of -D LARGE), and also try using -D HIRES_VGA (instead of -D LORES_VGA).
Works for me under Catalina 3.3 or 3.4 (or 3.5), using any combination of library, memory model and HMI options.
I'd say your problem is that when you removed the cache option from your program, you did not also rebuild the utilities. The XMM loader and the program to be loaded have to be compiled with the same cache options (or with no cache options).
Try the following (from the main Catalina directory):
cd utilities
build_all DRACBLADE
then try it again.
Also, make sure you don't have an old copy of XMM.binary in your local directory - if you do, delete it - Catalina will use the one in the Catalina bin directory.
Then again, the cache is so nifty, I'll have to find a free cog some other place. Touchscreens won't need either a mouse or a keyboard so that could save cog(s)? I found the NO_MOUSE etc commands - I think they free up a cog, right?
Also, a general question, if you have a registry, is there a function you can use in a program to query the registry and see what cogs are loaded with what? I know there is a command that tells you which cog catalina is running in (my program says it is cog #2) but can you find out about the other cogs?
If so, that could justify that entire inter-cog communication thread you are running
A better option would be to build the utillities twice - once with the cache and once without, renaming the cached version of XMM.binary to XMM_cache.binary (or something else appropriate).
Then again, the cache is so nifty, I'll have to find a free cog some other place. Touchscreens won't need either a mouse or a keyboard so that could save cog(s)? I found the NO_MOUSE etc commands - I think they free up a cog, right?
Not on the DRACBLADE - I think NO_MOUSE is the default. Anyway, I may implement a touchpad driver that is mouse-driver compatible.
Also, a general question, if you have a registry, is there a function you can use in a program to query the registry and see what cogs are loaded with what? I know there is a command that tells you which cog catalina is running in (my program says it is cog #2) but can you find out about the other cogs?
Yes, there is a demo program in the demos directory called test_plugin_names.c
If so, that could justify that entire inter-cog communication thread you are running
Yes, I will get back to that thread later this week - I now have a complete service-oriented model for cog-to-cog communications that I intend to adopt in Catalina - Mike and Eric's suggestions of implementing a service-based registry actually fixes a long-standing problem with Catalina. I knew about the problem, but had held off fixing it because my own solution took too much code to justify - but Mike's idea works a treat!
Comments
As far as I know, yes.
There is a test program (test_time.c) in the Catalina/demos directory that turns your Prop into a digital clock. Requires TV or VGA output, and it should be compiled with the CLOCK option defined - e.g:
Ross.
Thanks, David - but the problem is definitely serial comms related. I use the curses library (which means the terminal emulation code is only a few lines) and everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.
Ross.
Ross.
One thing that has struck me with many propeller programs is that you have 8 cogs that can run in parallel, and the first thing you do is write a program that is one single program. I find it hard to *think* in parallel, but if you have cogs running in parallel, why not kernels running in parallel, and XMM programs running in parallel? Each has its own cog, hub and external memory.
I think the prop I could be eminently suitable doing this. eg there is a post active at the moment where someone wants to run a robot with 5 propellers - one does legs, one does vision etc. If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller, or 5 kernels on separate propellers, and the process of changing from one to the other should be fairly simple as it is all just C code. So you start off trying to fit it all in one propeller but if you run out of cogs then you can move code into other propellers.
Ok, say this is possible, how would kernels talk to each other? Can you define a common block of memory for "inter-kernal communications"?
In most cases, you can just use global variables. Where this is not sufficient (e.g. due to race conditions) Catalina also provides low level support for mutexes, from which any higher level inter-process comms mechanism you want can be constructed.
Ross.
For a change I am going to agree with RossH:)
Because it would be mind bendingly slow. In the simple case each XMM program
fetches it's instructions and data from external memory directly with no
caching. So the kernel(cog) currently accessing external memory holds up all
the other kernels until the access is done. Result being that everything
proceeds at a snails pace.
Next up up put a cache in HUB, or even one per kernel, still all the kernels
are fighting over external memory when they need their caches updating. Plus
you have lost all your HUB space.
This is a thousand time worse than cogs waiting for their HUB slots to access
HUB RAM. At this point you are better off running your code on some other MCU
that has the address space for large programs and interrupts to schedule
tasks/threads,
"Fairly simple as it's all just C code" except for:
In one chip they would probably communicate via shared HUB. In many chips they
would need to use some inter chip coms link. Migrating code around like this
is not so simple.
This is exactly the problem addressed by the old Transputer chip from the 1980's and today the chip from the company that shall remain nameless here.
I did say there were no usable languages, not that there were no languages.
Ross.
Let's see. Say you take a C program running in a cog kernel and say it has 8k of hub ram available as a cache. This is what we have already. Now Ross has said this runs extremely fast because almost all the time it is reading from cached hub ram, not from XMM ram. I did not quite believe this so I wrote my own test code and ran it. Ross is correct. It runs almost as if the XMM is not being accessed, and I suspect because it is a cache, the XMM memory is not being accessed much.
That means that the XMM memory speed is rather irrelevant. It also means that if two kernels are trying to access XMM memory, this will only happen infrequently and it is actually very unlikely that both want to access XMM at the same time.
I very much suspect that the two kernels will run just as fast as one kernel. Indeed, because they are separate, they will be running twice as fast overall. Net result - maybe you lose 10% of speed due to external ram access, but you gain 2x speed due to two kernels. I suspect this means faster code overall, not slower code.
WRT inter kernal comms, let's say we had 5 physical propeller chips all talking via Tim Moore's 4 serial object. And let's say that the way they all talked was via a common circular buffer in hub of 128 bytes. That enables intercompatability with existing code. Now let's say you put all this into one propeller. You could do the same thing by creating 5x128 byte buffers in hub memory. Not difficult. Each buffer might contain data packets of various sizes, with say a start byte (02), number of bytes, source, destination, data packet, and finish byte (03). Any program can search for packets destined for itself.
There are other protocols that are possible, but you don't need much to enable a comms system. With the above protocol, you might define a data packet to say "read x bytes at hub location y" and then you can transfer arrays between kernels.
You could even define a super simple interkernal comms system using one or two longs. Flag to say data is present. Read i bytes at hub location j to location k. Reset flag when you have read this. That might only be two longs and it enables whole hub memory to be transferred.
In some ways it may not matter what protocol you choose. That can be defined in your C program. All you really need is for a C program to be able to read and write longs (only one or two) to fixed locations in hub memory.
Where this could lead is something really cool. You could have two (or more) C programs, hundreds of kilobytes in size, running in parallel. How they interact is up to the programmer. Maybe they don't even interact at all (each has its own external comms ports for instance and interacts with the real world but not with each other). If there are race conditions, well it is up to the programmer to handle how those work.
This is what I am thinking - Catalina already does this. Much of the propeller runs in parallel anyway. Hub for each kernel are going to be separate so there is no thread problem there. Each thread will have its own cogs so no problem there (eg each thread might have its own serial comms port cog for instance). The main one that seems complicated to me would be two kernels wanting access to XMM at once, and two kernels wanting access to an SD card at once. But that ought to be just two locks?
Hi David,
No, curses does not have a built-in terminal emulator (although it does simplify the code if you want to do fancy things like screen manipulation in your own code). Mainly, it just avoids the need to do all the low level i/o configuration and "select" calls on a set of file descriptors just to be able to do multiple stream character I/O. I hate all that crazy BSD stuff - it's such a bizarre and non-portable way to have to do things.
Ross.
Yes - check out pdcurses
Ross.
Regarding the problem I was having on Linux with the new version of Payload - i.e. ...
I've finally managed to test the new Payload on a native Linux installation (thanks to those that offered theirs) and confirmed that this is indeed a problem related to using a virtual serial port when running Linux under VirtualBox. VirtualBox seems to have quite a few problems with USB devices and serial ports.
On a native Linux installation everything works fine.
However, I probably won't bother releasing a Linux binary until Catalina 3.5 is ready for release - but if someone really wants it sooner, let me know.
Ross.
I've been distracted from Catalina while I searched for the perfect display. I think I now have an answer and it is a tower of Gadget Gangster boards with TV, VGA and a 320x240 full color display. Why not have them all, I say! See this thread for some photos http://forums.parallax.com/showthread.php?110134-2.4-quot-320x240-TFT-Prop-based-display-module/page2
I think Spin is going to run out of memory for such a display so it is back to XMM C.
These displays come with a huge library of C code but I don't think this is going to work as it is not fast enough. Filling an entire screen with 320x240x2 bytes using Spin takes ten seconds. C is faster but ideally I'd like this to be 100x faster and take 1/10th of a second, which is a data rate of around 1.5 megabytes per second.
For things like font libraries, the display has a mode where you send it an "address" which is 4 bytes, x1,y1,x2,y2 and then you stream bytes and the display fills up a block defined by those four values. If x1=x2 or y1=y2 it draws a line. Or you fill a square or a rectangle.
This is perfect for tile drivers and for icons, and for drawing fonts on the screen and is a lot faster than sending pixels one at a time (though if x1=x2=y1=y2 it does just draw a pixel with the next two bytes).
However, the more pixels and the better the resolution, the more data is needed. I am not sure if an SD card is fast enough. It probably is but I need to do some real tests with refreshing text by drawing fonts one at a time.
To get the speed up I am trying to use parallel data as much as possible. So data goes from an SD card into external memory (it could go into hub, but at 153k for a screen, this is too much for hub, or for a cache for that matter). Access to the sram is via a pasm program and I'm hoping I can write some pasm primitives to move blocks of data directly from sram out to the display one byte at a time. Maybe 30 pasm instructions to move one byte??
One catch is that the display shares the same propeller pins as the XMM C code. So one needs to pause C processing while a block of memory is moved out to the display. I already have this working with other graphics drivers.
I have some ideas for how this pasm code will look and maybe once I write it I might also have some ideas that could be useful for the huge intercog communication standard thread!
Hopefully we can get some sort of GUI working on this display using C
Hi Dr_A,
I've been meaning to buy a GG module, so I will go ahead and buy one of these as well. We'll see what we can come up with.
Ross.
I've come up against a silly little problem with the cache command - I think it is paired with something else. This is my program:
#include <stdio.h> int main () { printf("Hello, World!\n"); while (1); // Prop reboots on exit from main()! return 0; }and if I compile with LMM it works fine.
If I compile with external memory and a cache using this line it works fine
but if I compile with the XMM on but cached off using this line
I get a blank screen with just a cursor flashing.
What is the correct syntax for no cache?
Hi Dr_A,
I think we've been down this road before. I can't remember the exact answer (I'll figure it out again tonight) but just try removing all those unnecessary options from your compile command.
I'll try it out tonight, but in the meantime you could try:
Ross.
Do you mean that got it working?
Ross.
I tried reading the document you have that describes all the settings but SHARED_XMM does not seem to be on the list, so I'm sort of guessing and randomly removing settings but not quite knowing what they all do.
I have some C code that loads up cog 7 with a plugin and it works with LMM mode but not with XMM mode and caching, and I suspect the cache is using the last free cog. So I had the idea of removing the cache command and leaving it in XMM mode but then it wouldn't print "Hello World" any more.
Freeing up a cog is the first step in getting a 320x240 touchscreen working...
SHARED_XMM is now an internal flag - it should only be set on certain hardware, and (if required) it is now set in the *_CFG.inc file (e.g. DracBlade_CFG.inc).
Ross
Dr_A, I just did a quick search, and here is the previous thread on exactly the same issue.
Ross.
Yes, it looks like I fixed that in code::blocks. Now I need to do the same thing on my IDE.
code::blocks is nice but it doesn't quite have the flexibility of a custom IDE. Debugging plugins is hard and I need a way of including inline pasm code so that changes can be made in the C code and the pasm code at the same time. Once I get a driver working I'll be able to go back to code::blocks but meantime, thanks for your patience while I bring my IDE up to the version 3 standard
Another option is to leave in the caching and remove some other cog. Maybe the mouse cog, since that won't be needed for a touchscreen...
Sorry to trouble you again but I made those changes and I'm still having problems. I know this is v 3.3, not 3.4, but hopefully that is ok.
My program:
#include <stdio.h> int main () { printf("Hello, World!\n"); while (1); // Prop reboots on exit from main()! return 0; }This works
and this does not
The only change here is that when the cache is deleted it does not work.
I have tried with vga hi res, vga lo res, tv hi res and tv lo res and it is the same problem - with no cache there is just a flashing cursor and no "Hello World".
Below is the full printout of the compilation. Any help would be most appreciated.
Addit: having said all this, what I really want to do is free up a cog so maybe there is another way. Will removing the mouse free up a cog and if so, what command do I add?
Works with a cache:
and not working when the cache is removed:
I can't see why this wouldn't work - everything looks ok. I will re-install 3.3 and try this tonight. I do vaguely remember making some changes in the VGA support of the DracBlade, but I can't remember which version that was in, so I'll have to wait till I get home to investigate further.
If you get time before then, try using -D SMALL (instead of -D LARGE), and also try using -D HIRES_VGA (instead of -D LORES_VGA).
Ross.
Works for me under Catalina 3.3 or 3.4 (or 3.5), using any combination of library, memory model and HMI options.
I'd say your problem is that when you removed the cache option from your program, you did not also rebuild the utilities. The XMM loader and the program to be loaded have to be compiled with the same cache options (or with no cache options).
Try the following (from the main Catalina directory):
then try it again.
Also, make sure you don't have an old copy of XMM.binary in your local directory - if you do, delete it - Catalina will use the one in the Catalina bin directory.
Ross.
Maybe I could add "build_all" to the batch file?
Then again, the cache is so nifty, I'll have to find a free cog some other place. Touchscreens won't need either a mouse or a keyboard so that could save cog(s)? I found the NO_MOUSE etc commands - I think they free up a cog, right?
Also, a general question, if you have a registry, is there a function you can use in a program to query the registry and see what cogs are loaded with what? I know there is a command that tells you which cog catalina is running in (my program says it is cog #2) but can you find out about the other cogs?
If so, that could justify that entire inter-cog communication thread you are running
Yes, I will get back to that thread later this week - I now have a complete service-oriented model for cog-to-cog communications that I intend to adopt in Catalina - Mike and Eric's suggestions of implementing a service-based registry actually fixes a long-standing problem with Catalina. I knew about the problem, but had held off fixing it because my own solution took too much code to justify - but Mike's idea works a treat!
Ross.
Im programming in SPIN but I like more C.
Thanks