Which language should i use to program prop?
richaj45
Posts: 179
Hello:
Would any of you programmers give me tradeoffs in using the following languages for programming the prop:
1) Spin
2) Catalina C
3) Tachyon Forth
Thank you much for educating me!
regards,
rich
Would any of you programmers give me tradeoffs in using the following languages for programming the prop:
1) Spin
2) Catalina C
3) Tachyon Forth
Thank you much for educating me!
regards,
rich
Comments
hm tradeoffs - hm
if you now the language c you could use catalina c or propeller gcc
on the other hand if you are familiar with c you will learn SPIN really fast.
C is faster than SPIN. But anything that does not need really high speed can be coded in SPIN
(even a serial interface with 19200 baud can be done in SPIN)
if you really need high speed Propeller-Assembly (PASM) is the choice.
one specialty about PASM is that EVERY command can be conditional on two flags
I came from delphi when I started programming the propeller-chip. It just took me 2 or 3 hours to get into SPIN
just some differences in syntax-details.
I don't know forth I only know it is a highly stack orientated language. All you commands are piled up on a stack
(@the forth-specialists please forgive this description and feel free to give a better explanation)
best regards
Stefan
There are several options for basic, one is a standalone basic terminal which is very cool
http://propellerpowered.com/shop/?page_id=234
There are several option for C, Catalina being fairly complete and stable, and an excellent short term solution, and probably a good long term solution as well. There is also PropGCC, which is still fairly new, but is likely to become a very good long term solution.
There are several options for forth, they vary slightly and overlap a lot. Tachyon is ideal if your primary concern is execution speed for small drivers, etc. pfth is ideal if your primary concern is ANSI compatibility. Propforth is idea for pretty much everything else, such as complex systems, filtering and pre processing fast data streams, and logging large amounts of data. Of course your could use any option for any application and be fine.
I recommend forth in general, because it its more fun (to me), and propforth in particular, because I know the guy that writes it and he is a very sharp engineer and does consistently amazing work.
I currently program in SystemVerilog for design and synthesis. I have done z80 assembly, some Pascal, some Perl, and a very little python. But i must say SystemVerilog is my strongest as i use it each day at work. (Chip front end design)
I use of the Prop is as a embedded controller with some interaction from a PC. That is like you might use a PIC for but with the faster computing power of the Prop. I am more interested in the Prop I than II. (I think Prop 1.5, delivered in a year, would have been a better market match. Just an opinion.) I also like the idea that the Prop I is simple, from a hardware point of view, and that Parallax will have it around for a long time if they go like they have been. I want to be able to do relatively simple control applications easily with support that will be around a very long time at the DIY price point.
Regards,
Rich
Based on your background, forth should be idea. It should be a small step from thinking in terms of the hardware to thinking in terms of that hardware in action. Any of the forths should be able to get you where you are going. Propforth has been in development longer, and is completely stable (has been for pretty much the whole time), and is on its final kernel release, with all its optimizations for speed and small size.
Can you tell us anything about your application? There might be an indication as to which option would be the best fit.
SPIN + PASM is very effective, lean, simple, fun, productive. It's the native language of the chip and most features are nicely exposed in an easy to use, productive way. Should your projects exceed the capability those two offer, C is the next place to go as it's possible to write bigger programs and write them in a language that may be more familiar.
I would not have imagined "lean" to be applied to C/C++ on the prop, with all the memory models requiring additional ram, etc. What am I missing?
C.W.
Lean does have a few axis, and it's true that there is more "thick" learning associated with C, and that's why it has a secondary recommendation from me. In terms of the work product, it's lean now and effective. Getting there was not easy either. Hats off to all who continue to power through!
However, if one knows a lot of about C, most of that goes away, leaving just understanding the particulars associated with the Propeller.
It's not so much the memory models require additional RAM as they were implemented to support the multiple RAM configurations the Propeller supports and to provide the most flexibility for tailoring your application to your hardware. As Dave Hein points out, the ability to put C and PASM(GAS) code anywhere form the COG memory to XMM on an SD card. That's actually a pretty impressive feature.
Hi Rich,
If you are interested in programming in general, and have had some exposure to C or any similar procedural language then you will probably find Catalina the quickest and simplest way to get up and running. With Catalina, you don't need to know (or learn) anything Propeller-specific even when writing quite complex programs.
However, if you aren't primarily interested in programming, and instead want to explore some of the unique hardware aspects of the Propeller, I'd recommend Spin - it allows you to "deep dive" immediately into the low-level Propeller Assembly Language.
I'm not a Forth person, so I can't advise on that one - but my general advice would be that if you already know Forth, by all means start out with that - but if you don't then you'd probably be better off with something else.
Ross.
I guess I'd look first to find some Prop code, in any language, that's the closest match to what you want to do and start from that.
There are just so many Spin examples out there compared with C or other language examples, that it would probably be Spin.
Thanks for more input.
Actually i have written my own Forth many years ago on a Z80 CP/m system during lunch breaks. I patterned it after the book "Threaded Interpretive Languages" by R.G. Loeliger. It is really the best book describing the concepts of a stack machines. There is enough info there to almost write a Forth, just no all of it. I am always surprised it is not referenced in any Forth discussion i hear.
As for 'C' i would use Catalina, if there were more examples. I prefer tools that are written and maintained by a very small group (single) of people. When the CMM model came out then i knew it was going the wright way. I expect the Virtual Machine for Catalina's CMM is very simular to Tachyon's kernel. That to me is a convergent of the COG being a Virtual Machine for byte-code interpretation that the Parallax principle designer's have always thought as their computing architecture model. I least thats what i think.
I don't care much for the C++ on a microcontroller. All that class inheritance and memory management is beyond my interest, an i don't think it has lived up to the hype. But then i am a hardware guy that wants to control things and not a programming that wants to write elegant code.
I do use gcc tools occasionally at work for the 16bit PIC family. Gcc is a big beast with many options and switched and linker scripts and i don't need big tools to do useful work so for DIY i keep it simple.
My first projects will be driving a parallel LCD with buttons to control a DDS chip. Very simple and done many times with PIC chips.
My next project will be to build a command interpreter so i can command the prop from a terminal program. Again done many times before.
I have mulled over coding up a COG look alike in Verilog and testing is in an FPGA. But that takes alot of effort for a DIY project so it will probable not happen.
Another project i would like to do is port some of my Verilog IIR filter work to a COG program along with an I2S interface that i saw someone doing on the list. I love filter work.
Regards,
Rich
Thanks to Jazzed we have the SimpleIDE that really simplifies using PropGCC.
I'm not sure if this is the current link, but it's a place to start:
http://code.google.com/p/propside/downloads/list
C.W.
Hi Rich,
There are lots of example programs in the Catalina distribution - 73 simple "test" programs in the demo folder alone, each intended to test/demonstrate some particular Catalina feature - for example, test_leds.c and test_leds_2.c show two alternative means of just turning on and off a single output (such as an LED) - one uses the _outa()/_dira() library functions, and one uses the more traditional (for the Propeller) OUTA/DIRA registers.
Also, there are subdirectories off the demo folder containing all kinds of more sophisticated demo programs:
graphics - programs to demonstrate the Parallax "graphics" object accessed from C
minimal - programs to demonstrate the alternate "minimal" target and also how to create new plugins
multicog - programs to demonstrate multi-cog programs in C (i.e. running C functions separately on up to 8 cogs)
multithread - programs to demonstrate multithreaded programming in C (i.e. running hundreds of C functions on each cog)
serial4 - programs to demonstrate the Parallax "four port serial" driver accessed from C.
sound - programs to demonstrate using sound from C.
spi - programs to demonstrate accessing SPI/I2C devices from C (e.g to directly access an SD card or EEPROM).
spinc - programs to demonstrate running Spin programs from C.
tty - demonstrate the tty serial library
tty256 - demonstrate the tty256 serial library
vgraphics - programs to demo the virtual vga graphics functions
There are also a bunch of Catalyst demo programs in the various catalyst sub-folders - but these mostly require SD card and/or XMM RAM support (whereas most of the ones listed above don't).
Overall, there are hundreds of demo programs included in the Catalina distribution - if you want me to point you in the direction of any specific type of demo, just let me know.
Ross.
-Phil
I agree with Phil if you need to use some of the more hardware-specific OBEX objects. But don't forget that Catalina includes versions of most of the common OBEX objects already fully integrated and ready for you to use.
Here is a (partial) list ...
mouse drivers
TV drivers
VGA drivers
Gamepad drivers
sound drivers
serial drivers (many different types - e.g. single serial port per cog, 4 serial ports per cog, small or large buffer)
SD card access
EEPROM access
graphics functions
Floating Point functions
MS-DOS File system functions
In general, accessing these from C is easier than accessing them from Spin, since C provides built-in support for them (e.g. I/O drivers, floating point functions, file system access) whereas with Spin you always have to "roll your own".
Ross.
I'd suggest taking a look at Spin and PASM. Even if you end up deciding something else would be more to your liking. The Spin interpreter is built into the P1. The PropTool or BST or Simple IDE are dead easy tools to use. PASM is an amazingly simple, elegant and easy to use assembly language. Mostly because of the Prop architecture but partly because it's so easy to use PASM withing a Spin object.
The Prop architecture, Spin, PASM and the Proptool, as a whole, are a fascinating example of what can be done by someone thinking outside the box and going for the simplest possible solution and well worth looking at just for that.
<... runs away before hordes of Forth and Basic harpies programmers descend to tear him to shreds! ...>
Ross.
Frankly the challenge of learning the Propeller chip hasn't been Spin. It is the counter hardware which do a lot of heavy lifting but remain somewhere mysterious to me.
Ross.
I've used the Propeller for almost two years and the counters remained a black box. However, my recent Theremin and DC motor control projects forced me to jump into what feels to me like the deep end. But given that the Propeller can generate and process video signals, and at least one software defined radio project has been done with it, I'm still in the kiddie pool.
I am wondering why Catalina 'C' programs are not in the Object Exchange?
As i remember some time back there was a 'C' label for object. I think.
Regards,
Rich
Ray
Heater's comment is spot on. The whole package, Prop Tool, SPIN, PASM is worth just doing. Won't take too long. You will probably have fun too. Most of us did.
I think the C label in the OBEX was originally intended for Imagecraft C programs only, but it never got used much, and now that compiler is unsupported.
I imagine in future it might be used for PropGCC programs - I'm not really sure what Parallax intend, so I've just stayed away from it and simply re-release all my Catalina programs and libraries whenever I re-release the compiler.
Also, there is the license complication (no, I don't want to restart that argument in this thread ... please!). Everything in the OBEX is supposed to be MIT licensed (although not everyone seems to follow that rule) and so there are various parts of Catalina (such as libraries etc) that simply could not be included (e.g. anything GPL licensed).
Finally, who needs an OBEX with C? The internet is your OBEX!
Ross
I cant speak for all Catalina users, but many of the ones I know of use Catalina to develop application programs rather than re-usable libraries or components - and so they don't want to put them in the OBEX.
I probably didn't help by not using the OBEX myself in the first place (e.g. for the various Catalina libraries) - but that's just historical. Catalina grew up when Parallax wasn't interested in C at all, and the C label didn't exist in the OBEX. Now they do seem to have come around, you could say much the same thing about PropGCC. Is there any PropGCC code in the OBEX? (I have to admit I've never actually looked!).
There is also the fact that C doesn't really lend itself to writing small re-usable objects like Spin. C programs tend to be larger, more complicated, and highly non-portable between different platforms, even different C compilers on the same platform. Catalina tries to be 100% ANSI C only, but even that doesn't mean a Catalina program will compile unaltered under ImageCraft or PropGCC if it makes use of hardware dependent features, since these are implemented differently in each of these compilers.
Also, we have to be realistic here - the Propeller is a niche processor, and there are just not that many people using it for the type of commercial applications that would normally be written in C. So the number of people using C on it (of any variety) is really quite small.
Ross.
(I am a user, not a compiler builder.)
For my projects I make a table to decide, which language and system will solve the task quickest.
The advantage of the rather slow propeller special language Spin is, that there are a lot of hardware drivers (assembler) in obex. If you can use these or if you want to learn assembler, you can be happy with Spin. You will need assembler for fast parts of your program.
If you want to write fast programs without assembler code, you will need a compiler like PropBasic or C. C supports float math as well.
As a matter of fact, I have not yet found a situation for me, where the interesting Forth developments would have been of advantage. (PropForth is not very fast, Tachyon is fast but special)
Have fun, Christof