@rod1963, sadly I think you might be right. Is all that we do here going to be in vain?
I've just spent a few hours wandering aimlessly round the internet seeing what would be good to add to Catalina. Autocompletion of library methods a-la vim plugins or .net intellisense. Inclusion of inline assembly. Precompilation of .dll like libraries that can be put on an sd card to speed up the test/download/debug cycle. The addition of the obex into the Catalina libraries.
I have a PIC32 board on order and we shall see what it can do. It has more ram than a propeller and a lot more pins, so it might be able to run a touchscreen without needing external ram. I don't own a pi as I'm not really a linux convert. I've bought various arm based touchscreen computers in the last few years that have run linux and tossed them away due to lack of documentation. I have an android tablet that is hardly used as it takes 4 minutes to boot and can't do any real world I/O.
Bottom line is the propeller is still the most fun chip I've used in years. I want to translate the Spin touchscreen GUI to C as I think this should be possible, and I think it would be fun to have a GUI that can run with similar code on TV, VGA and touchscreen. I think Catalina can do these things.
I don't own a pi as I'm not really a linux convert.
Raspberry Pi now offers a Risc OS as an alternative to linux. I did not look into this any further, as to what C language would be available. Since it is open source, I would imagine it would probably be GCC.
Bottom line is the propeller is still the most fun chip I've used in years.
Amen! However, we need to find a way to help move the Propeller beyond being perceived as a "fun" chip to being thought of as a "useful" chip. I think this is where Catalina and Propeller GCC can help Parallax. They can provide a more familiar programming model to allow those who are not Propeller enthusiasts to appreciate the capabilities of this unique chip. I still wish it was possible to combine efforts but I guess that is more difficult than it seems.
Here is a small test program "registry.c" that I did to test/display the registry values. It uses the default "custom.def" platform.
...
Thanks Ray - just one comment - I would tend to use "\n" rather than "\r" as a line terminator - this would make it compatible with more terminal emulators (specifically, non-Windows ones).
If you use -C TTY256 there is an error in the xxxx.HMI files for each platform. This includes the \target\custom.hmi which is used as the default platform.
The error is that it does not save a cog, although it still works.
Add in the two lines marked below...
#elseifdef TTY
#define SUPPORT_TTY
'vvvvvvvvvv add in the following 2 lines...
#elseifdef TTY256
#define SUPPORT_TTY
'^^^^^^^^^^^
If you use -C TTY256 there is an error in the xxxx.HMI files for each platform. This includes the \target\custom.hmi which is used as the default platform.
The error is that it does not save a cog, although it still works.
Add in the two lines marked below...
Hi Ray,
The reason I didn't define this use of TTY256 is that the version of FullDuplexSerial with 256 byte buffers was only intended to be used as a plugin, not as a HMI option. You use it by linking with the libtty256 library instead of the libtty library.
To summarize, here are the possibilities with Catalina 3.10:
catalina program.c -C TTY <--- use the FullDuplexSerial plugin,
but access it as a HMI option
(i.e. via stdin/stdout/stderr).
catalina program.c -ltty <--- use the FullDuplexSerial plugin,
and access it via the libtty library.
You can also use any non-serial HMI as normal
(e.g. add -C TV or -C VGA).
catalina program.c -ltty256 <--- use the FullDuplexSerial256 plugin,
and access it via the libtty256 library.
You can also use any non-serial HMI as normal
(e.g. add -C TV or -C VGA)
However, I can see this is a little inconsistent, so I will add the ability to do the following to the next release:
catalina program.c -C TTY256 <--- use the FullDuplexSerial256 plugin,
but access it as a HMI option
(i.e. via stdin/stdout/stderr).
Here is a sample program that uses the -ltty to display the registry details...
Program tty.c and compile using...
catalina tty.c -lc -ltty -C NO_HMI
payload tty
Same note as above - if you use '\n' as line terminator instead of '\r' in this program, you can use payload's "interactive" mode to display the output very easily - i.e just say:
payload -i tty
I can see I will have to add a new option to payload to translate '\r' into '\n' - for people who insist on programming under Windows! .
I had not used the interactive mode of payload. Guess I just forgot when you introduced it Ross. Just so used to using PST.
Any reason to use Ctl-D to end the interactive mode? Ctl-C ???
BTW I misunderstood the payload command. The format is...
payload <binaryfilename> -i
Here is my program using \n...
/* Display the Registry Entries */
/* Test tty256 */
// compile with...
// catalina tty002.c -lc -ltty256 -C RAMBLADE3 -C RTC2 -C NO_HMI (my version)
// catalina tty002.c -lc -ltty256 -C NO_HMI
// download (and use interactive terminal mode) with...
// payload tty -i
#include <stdio.h>
#include <catalina_plugin.h>
#include <catalina_tty.h>
void wait(unsigned ms);
/*
* main
*/
int main (void) {
int i;
long *a_ptr;
while (1){
// printf("\n");
tty_tx('\n');
i=0;
while (i<8) {
// printf("Registry Entry %d: ", i);
tty_str("Registry Entry ");
tty_dec(i);
tty_str(": ");
// printf("%3d ", (REGISTERED_TYPE(i))); // =(REGISTRY_ENTRY(i) >> 24)
tty_decf((long) (REGISTERED_TYPE(i)),3);
tty_tx(' ');
// printf("%-20.20s ", (long *) (_plugin_name(REGISTERED_TYPE(i)))); // get the plugin name
tty_str((char *) (_plugin_name(REGISTERED_TYPE(i)))); // get the plugin name
tty_tx(' ');
// printf("$%4x: ", (REQUEST_BLOCK(i))); // =(REGISTRY_ENTRY(i) & 0x00FFFFFF))
tty_tx('$');
tty_hex((long)(REQUEST_BLOCK(i)),4); // =(REGISTRY_ENTRY(i) & 0x00FFFFFF))
tty_tx(' ');
a_ptr = (long *)(REQUEST_BLOCK(i)); // get the pointer to the request block start
// printf("$%-8x ", *(a_ptr +0)); // first Request_Block
tty_tx('$');
tty_hex(*(a_ptr +0),8); // first Request_Block
tty_tx(' ');
// printf("$%-8x ", *(a_ptr +1)); // second Request_Block
tty_tx('$');
tty_hex(*(a_ptr +1),8); // second Request_Block
tty_tx(' ');
// printf("\n");
tty_tx('\n');
i++;
};
wait(500);
//---------------------------
i = tty_rxcheck(); // get a char if avail, -1 if none
if (i != -1) {
// we have a char, so deal with it...
tty_tx(i); // just display it for now!
};
}
return 0;
}
//----------------------------------------------------------------------------------------------------
/*
* wait - wait a specified number of milliseconds
*/
void wait(unsigned ms) {
unsigned count;
count = _cnt();
count +=_clockfreq() / 1000 * ms;
_waitcnt(count);
}
//
Any reason to use Ctl-D to end the interactive mode? Ctl-C ???
While waiting for Ross to give the real answer.. Ctl-D is ASCII 4, aka EOT, aka End Of Transmission, and is commonly used to log out, or to detach a shell (as used in 'screen', for example), as end marker for transmissions to printers, and lots of other things which are about ending a session of some kind.
While waiting for Ross to give the real answer.. Ctl-D is ASCII 4, aka EOT, aka End Of Transmission, and is commonly used to log out, or to detach a shell (as used in 'screen', for example), as end marker for transmissions to printers, and lots of other things which are about ending a session of some kind.
-Tor
Quite right! Things were a breeze on nearly all platforms, with CTRL+C meaning interrupt nearly everywhere ... until Xerox (and then Windows) came along and confused us all by using CTRL+C to mean copy in some places, and interrupt in others (D'oh!).
Generally, it is best to avoid CTRL+C because in many environments (like Unix) it still means interrupt and may even be intercepted by the O/S before an application program can process it.
I thought Ctrl-C from the command line sent a SIGINT to the app before the OS got more deeply involved.
-Phil
I'm not a signal expert, but I think that's only true in Unix, not in Windows. Windows appears to have had signal handling "bolted on", not implemented as a fundamental part of the O/S (as it is in Unix) - and it even varies between windows versions. Apart from the obvious difference in behavior between console and non-console applications, and also between parent and child processes, there are deeper differences. For instance, this quote is from Microsoft documentation:
SIGINT is not supported for any Win32 application, including Windows 98/Me and Windows NT/2000/XP. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.
This can lead to some odd behavior, summarized (with an example) here.
Raspberry Pi now offers a Risc OS as an alternative to linux. I did not look into this any further, as to what C language would be available. Since it is open source, I would imagine it would probably be GCC.
I thought I might bring the spin2c discussion over to the most recent thread.
Attached is a zip that contains the latest spin2c program, a hello world spin program, a small batch file I wrote to compile this to c (rather than c++) and the 4 output files (two .c and two .h).
Ok, plug these into catalina in codeblocks and try compiling.
Getting a warning as there is no 'main' but that can be changed with one line.
First serious error - getting an "undefined" error with this
FullDuplexSerial_Start()
Tracing the structure, the hello.c program declares hello.h at the beginning. hello.h declares fullduplexserial.h and that declares the fullduplexserial_start routine. But it isn't finding it.
Is there still some c++ style synax in the code?
Also programs like tcc are choking on the cog.h file at line 17 and 18. Both propeller.h and cog.h are ? in c++ format. Maybe the author of spin2cpp can help here?
Getting a warning as there is no 'main' but that can be changed with one line.
Or you could add the --main option to your spin2cpp command line.
First serious error - getting an "undefined" error with this
FullDuplexSerial_Start()
I'm not seeing that when I compile it on the command line with:
catalina hello.c FullDuplexSerial.c -lc
Are you sure you included both .c files in your codeblocks project?
Also programs like tcc are choking on the cog.h file at line 17 and 18. Both propeller.h and cog.h are ? in c++ format. Maybe the author of spin2cpp can help here?
tcc is the Tiny C Compiler? If so I guess it is a Windows program, and hence has no Propeller support, which is why propeller.h and cog.h are missing.
spin2cpp doesn't try to produce code that will compile for any computer -- the output is pretty definitely Propeller specific, and so requires a Propeller C compiler (either Catalina or PropGCC).
Yes TCC is tiny C and ok, if it needs to be catalina that is fine.
I have an idea that we can start with a super stripped down version of a hello world, no stdio file, maybe just propeller.h and cog.h, and maybe not even those, and start with the simplest spin program possible and convert it to c. Then start adding obex objects.
The aim is to have the flexibility to work with different hardware options and not have to ask for custom drivers to be written. I know many have been written in C, eg vga drivers, keyboard etc, but some have not been (eg kye's sd driver) and this would be a good way to really test out spin2c. In other words, if spin2c can convert the hard objects in the obex, it can convert anything!
So - taking this slightly unorthodox approach, the first hello world is the minimalist spin program with the serial driver object, and the comms is via this object rather than via stdio. It doesn't even have to send "hello world". It can just send one character for the moment.
I have another ulterior motive, as I think this can be a way of getting "big spin". You pull together some spin objects that you know work together, and maybe you test them all individually in the spin tool, but for the final program you instead run the whole package through spin2c.
So... I need to get that hello world demo working.
In my enthusiasm I decided to get the latest version of catalina. And I have run into a problem with compilation, as catalina is calling homespun, and homespun has been updated and needs a .net update.
I have a bad feeling about this, because my computer can't do .net updates any more as microsoft has decided not to support .net on XP. Aaargh, this is why I have had to look at abandoning my favourite program, the C#/vb.net IDE and started that long discussion thread about computer languages that can run on multiple platforms.
See attached screenshot. Catalina is wanting homespun to run, homespun wants a new .net framework, .net won't install, plus it wants another program called windows imaging component and that also won't install.
I can maybe go back to an old version of catalina. I can also do all this on the windows8 machine that is sitting right next to my xp one, but if I develop on that using the latest shiny vb.net 2012 and all the other latest programs who knows if it will run on windows7 or vista?
A thought - how does the Proptool keep running on so many different platforms?
Anyway, what can we do to make things simpler? Can other compilers besides homespun be used for instance?
In my enthusiasm I decided to get the latest version of catalina. And I have run into a problem with compilation, as catalina is calling homespun, and homespun has been updated and needs a .net update.
Hi Dr_A,
You can revert to an earlier version of Homespun - just go to Catalina's bin directory and copy homespun031.exe to homespun.exe. For example:
cd "C:\Program Files\Catalina\bin"
copy homespun031.exe homespun.exe
I can't remember exactly what the fixes were in Homespun032 (the current version) but I do remember that Michael Park updated it to use a later version of .NET.
Or you could just update your version of .NET - see here.
I can't remember exactly what the fixes were in Homespun032 (the current version) but I do remember that Michael Park updated it to use a later version of .NET.
...
Ross.
Just found this info - Homespun version 032 was to do with handling unicode characters correctly. Most people will be ok with using 031 instead. If Homespun031 spits the dummy on any Spin file, just edit the file and re-save it as ASCII.
I've been waiting to see which way the wind blows before moving on to a different Spin compiler than Homespun.
I could move Catalina to bstc without much effort, but I'll probably wait to see what Spin compiler is supported on the Prop II. Does anybody know yet?
Or you could just update your version of .NET - see here.
Unfortunately that is the one that doesn't work - see screenshot on post #53. Mine is an earlier version of XP and that version is no longer supported and over the next year or so (according to the computer magazines) all versions of XP are no longer going to be supported. So more and more people will go to the microsoft site and find their software cannot be upgraded. Microsoft obviously want you to upgrade to a new operating system. But maybe people won't. Some years back they did this with Office and so I simply switched to Open Office. Ditto Internet Explorer, so I now use Firefox and Opera.
Heater keeps posting things that tempt me to the dark side. Linux I'm half way there with a linux system running in virtual box. Every time a microsoft program won't download I am tempted further...
So, ok I'll see if I have an old version of homespun.
But if BST isn't based on .net, maybe that is an option.
As for the prop II, I still think we shouldn't wait for that. So many fun things to do with the prop I. I want to get a GUI system running in C and that is going to be the same task for the prop I and the prop II, so may as well just get on with it in the prop I.
I have some ideas for pseudo classes for catalina I'd like to explore and brainstorm once I get the hello world compiling.
The front page of the Spin compiler repo says "This is the main repository for Parallax Semiconductor's port of the Propeller Spin/PASM Compiler from Chip Gracey's x86 Assembly code to C/C++." So I would be directing any questions about it to Parallax.
I don't know about limbo, it has had changes checked in quite recently. I suspect that as it as been tested a lot and compiles all the code in OBEX it is basically "done" and the next developments will come for the Prop II Spin. As far as I can tell it is intended to replace use of BSTC in the propgcc build system at some point. Simple IDE already can use it.
RossH,
The front page of the Spin compiler repo says "This is the main repository for Parallax Semiconductor's port of the Propeller Spin/PASM Compiler from Chip Gracey's x86 Assembly code to C/C++."
Yes, it does seem to have had a more recent release than last time I looked. I was keeping an eye on Roy's forum thread about it, which seemed to die about 6 months ago.
Comments
I've just spent a few hours wandering aimlessly round the internet seeing what would be good to add to Catalina. Autocompletion of library methods a-la vim plugins or .net intellisense. Inclusion of inline assembly. Precompilation of .dll like libraries that can be put on an sd card to speed up the test/download/debug cycle. The addition of the obex into the Catalina libraries.
I have a PIC32 board on order and we shall see what it can do. It has more ram than a propeller and a lot more pins, so it might be able to run a touchscreen without needing external ram. I don't own a pi as I'm not really a linux convert. I've bought various arm based touchscreen computers in the last few years that have run linux and tossed them away due to lack of documentation. I have an android tablet that is hardly used as it takes 4 minutes to boot and can't do any real world I/O.
Bottom line is the propeller is still the most fun chip I've used in years. I want to translate the Spin touchscreen GUI to C as I think this should be possible, and I think it would be fun to have a GUI that can run with similar code on TV, VGA and touchscreen. I think Catalina can do these things.
Ray
Guys - tone it down please.
Well, since Jazzed appears to have no more to say on this issue, I will also let it drop. I think Catalina can speak for itself.
Ross.
And here is the output...
The "official" set is compiled into the library function _plugin_name() - see source\lib\catalina\catalina_plugin_name.c.
This function will return "Unknown" for any plugin type it doesn't recognize.
Ross.
Thanks Ray - just one comment - I would tend to use "\n" rather than "\r" as a line terminator - this would make it compatible with more terminal emulators (specifically, non-Windows ones).
Ross.
The error is that it does not save a cog, although it still works.
Add in the two lines marked below...
Hi Ray,
The reason I didn't define this use of TTY256 is that the version of FullDuplexSerial with 256 byte buffers was only intended to be used as a plugin, not as a HMI option. You use it by linking with the libtty256 library instead of the libtty library.
To summarize, here are the possibilities with Catalina 3.10:
However, I can see this is a little inconsistent, so I will add the ability to do the following to the next release:
Ross.
Here is a sample program that uses the -ltty to display the registry details...
Program tty.c and compile using...
catalina tty.c -lc -ltty -C NO_HMI
payload tty
and here is the output...
Same note as above - if you use '\n' as line terminator instead of '\r' in this program, you can use payload's "interactive" mode to display the output very easily - i.e just say:
payload -i tty
I can see I will have to add a new option to payload to translate '\r' into '\n' - for people who insist on programming under Windows! .
Ross.
Any reason to use Ctl-D to end the interactive mode? Ctl-C ???
BTW I misunderstood the payload command. The format is...
payload <binaryfilename> -i
Here is my program using \n...
-Tor
Quite right! Things were a breeze on nearly all platforms, with CTRL+C meaning interrupt nearly everywhere ... until Xerox (and then Windows) came along and confused us all by using CTRL+C to mean copy in some places, and interrupt in others (D'oh!).
Generally, it is best to avoid CTRL+C because in many environments (like Unix) it still means interrupt and may even be intercepted by the O/S before an application program can process it.
See http://en.wikipedia.org/wiki/Control-C
Ross.
-Phil
I'm not a signal expert, but I think that's only true in Unix, not in Windows. Windows appears to have had signal handling "bolted on", not implemented as a fundamental part of the O/S (as it is in Unix) - and it even varies between windows versions. Apart from the obvious difference in behavior between console and non-console applications, and also between parent and child processes, there are deeper differences. For instance, this quote is from Microsoft documentation:
This can lead to some odd behavior, summarized (with an example) here.
Ross.
It looks as though the main programming language is BBC BASIC (http://rosettacode.org/wiki/Category:BBC_BASIC). Lua and Python are also supported.
http://news.ycombinator.com/item?id=4752741
Interesting.
I thought I might bring the spin2c discussion over to the most recent thread.
Attached is a zip that contains the latest spin2c program, a hello world spin program, a small batch file I wrote to compile this to c (rather than c++) and the 4 output files (two .c and two .h).
Ok, plug these into catalina in codeblocks and try compiling.
Getting a warning as there is no 'main' but that can be changed with one line.
First serious error - getting an "undefined" error with this
Tracing the structure, the hello.c program declares hello.h at the beginning. hello.h declares fullduplexserial.h and that declares the fullduplexserial_start routine. But it isn't finding it.
Is there still some c++ style synax in the code?
Also programs like tcc are choking on the cog.h file at line 17 and 18. Both propeller.h and cog.h are ? in c++ format. Maybe the author of spin2cpp can help here?
I'm not seeing that when I compile it on the command line with: Are you sure you included both .c files in your codeblocks project?
tcc is the Tiny C Compiler? If so I guess it is a Windows program, and hence has no Propeller support, which is why propeller.h and cog.h are missing.
spin2cpp doesn't try to produce code that will compile for any computer -- the output is pretty definitely Propeller specific, and so requires a Propeller C compiler (either Catalina or PropGCC).
Eric
Yes TCC is tiny C and ok, if it needs to be catalina that is fine.
I have an idea that we can start with a super stripped down version of a hello world, no stdio file, maybe just propeller.h and cog.h, and maybe not even those, and start with the simplest spin program possible and convert it to c. Then start adding obex objects.
The aim is to have the flexibility to work with different hardware options and not have to ask for custom drivers to be written. I know many have been written in C, eg vga drivers, keyboard etc, but some have not been (eg kye's sd driver) and this would be a good way to really test out spin2c. In other words, if spin2c can convert the hard objects in the obex, it can convert anything!
So - taking this slightly unorthodox approach, the first hello world is the minimalist spin program with the serial driver object, and the comms is via this object rather than via stdio. It doesn't even have to send "hello world". It can just send one character for the moment.
I have another ulterior motive, as I think this can be a way of getting "big spin". You pull together some spin objects that you know work together, and maybe you test them all individually in the spin tool, but for the final program you instead run the whole package through spin2c.
So... I need to get that hello world demo working.
In my enthusiasm I decided to get the latest version of catalina. And I have run into a problem with compilation, as catalina is calling homespun, and homespun has been updated and needs a .net update.
I have a bad feeling about this, because my computer can't do .net updates any more as microsoft has decided not to support .net on XP. Aaargh, this is why I have had to look at abandoning my favourite program, the C#/vb.net IDE and started that long discussion thread about computer languages that can run on multiple platforms.
See attached screenshot. Catalina is wanting homespun to run, homespun wants a new .net framework, .net won't install, plus it wants another program called windows imaging component and that also won't install.
I can maybe go back to an old version of catalina. I can also do all this on the windows8 machine that is sitting right next to my xp one, but if I develop on that using the latest shiny vb.net 2012 and all the other latest programs who knows if it will run on windows7 or vista?
A thought - how does the Proptool keep running on so many different platforms?
Anyway, what can we do to make things simpler? Can other compilers besides homespun be used for instance?
Hi Dr_A,
You can revert to an earlier version of Homespun - just go to Catalina's bin directory and copy homespun031.exe to homespun.exe. For example:
I can't remember exactly what the fixes were in Homespun032 (the current version) but I do remember that Michael Park updated it to use a later version of .NET.
Or you could just update your version of .NET - see here.
Ross.
Just found this info - Homespun version 032 was to do with handling unicode characters correctly. Most people will be ok with using 031 instead. If Homespun031 spits the dummy on any Spin file, just edit the file and re-save it as ASCII.
I've been waiting to see which way the wind blows before moving on to a different Spin compiler than Homespun.
I could move Catalina to bstc without much effort, but I'll probably wait to see what Spin compiler is supported on the Prop II. Does anybody know yet?
Ross.
Unfortunately that is the one that doesn't work - see screenshot on post #53. Mine is an earlier version of XP and that version is no longer supported and over the next year or so (according to the computer magazines) all versions of XP are no longer going to be supported. So more and more people will go to the microsoft site and find their software cannot be upgraded. Microsoft obviously want you to upgrade to a new operating system. But maybe people won't. Some years back they did this with Office and so I simply switched to Open Office. Ditto Internet Explorer, so I now use Firefox and Opera.
Heater keeps posting things that tempt me to the dark side. Linux I'm half way there with a linux system running in virtual box. Every time a microsoft program won't download I am tempted further...
So, ok I'll see if I have an old version of homespun.
But if BST isn't based on .net, maybe that is an option.
As for the prop II, I still think we shouldn't wait for that. So many fun things to do with the prop I. I want to get a GUI system running in C and that is going to be the same task for the prop I and the prop II, so may as well just get on with it in the prop I.
I have some ideas for pseudo classes for catalina I'd like to explore and brainstorm once I get the hello world compiling.
If you installed Catalina 3.10 you already do - just look in the bin directory and copy the version you want to use to "homespun.exe".
Ross.
I'm pretty sure it will be Roy Elthams open source Spin compiler. http://code.google.com/p/open-source-spin-compiler/
That would be good - but I asked Roy about that several times. Never got an answer, so I assumed it was in limbo.
Ross.
The front page of the Spin compiler repo says "This is the main repository for Parallax Semiconductor's port of the Propeller Spin/PASM Compiler from Chip Gracey's x86 Assembly code to C/C++."
So I would be directing any questions about it to Parallax.
I don't know about limbo, it has had changes checked in quite recently. I suspect that as it as been tested a lot and compiles all the code in OBEX it is basically "done" and the next developments will come for the Prop II Spin. As far as I can tell it is intended to replace use of BSTC in the propgcc build system at some point. Simple IDE already can use it.
Yes, it does seem to have had a more recent release than last time I looked. I was keeping an eye on Roy's forum thread about it, which seemed to die about 6 months ago.
Ross.