best foundation for learning prop codeing?

rwgast_logicdesign

ok so im finally happy with the propeller board ive been working so dilgently on. right now it doing 104mhz flawless and im sure it will clock alot higher once i order the right crystals. ive also got vga, sound, sd, and keyboard boards built to plug in when i need them. other hardware on coming is an audiophile quality amp, real time clock, a serial port, and interface to an msp430 (waiting on a launchpad, have chips but cant find ne info about building a programmer if neone knows much aboit programming an msp info would help, id like to use a prop to do it).

anyways i need to start programming the thing, for those of you that dont know this is my first micro. ive been coding for the pc for along time though. i am pretty versed in c, vb and know my way around x86 assembly. ive also dabbled in lots of scripting languages ie python, perl, bash etc.

so the way i see it there are three main languages for the prop spin, pasm and c. im looking to get into micros as a career and want to become as good as i can with them. im not real sure what i really want to do with my prop set up but im very intrestes in learning new things that i have no idea about yet. id like to write alot of hardware stuff, im very intrested in testing tools, fast 5mhz i2c drivers, fast memmory bus stuff, wifi, blue tooth, and vga. in the long run id like to be able to write code on my phone and then send it to the prop and compile and run it.

heres my question should i just learn pasm first or should i start with spin? i already know c but im not sure if it would be fast enough to do any of this stuff? i know catalina and gcc are faster than spin but im not sure if its fast enough for a main language when trying to squeeze all the speed i can from drivers especially vga stuff. so im thinking c and pasm are best, but should i learn spin besides the very basic stuff? and if so what are some good resources i just saw the boe help file it looks like a good start, unfourtantely all the links at the prop wiki are mostly broken. where can i find some catalina or prop gcc tutorials? i have plenty of pasm stuff though

pik33

I am learning Spin/Pasm now. It is Spin, which is harder for me than Pasm. I use Free Pascal/Lazarus with x86 asm when needed for my everyday programming.. and have to unlearn some Pascal habits when programming is Spin, for example do not write these ; at the end of every line of code. Pointers working also in some different way here and I had to learn how to use them and how to pass data between Spin and Pasm.

I think Spin/Pasm is the most natural way to start Propeller programming. So now I am trying all these players, drivers and DOSes I can find in OBEX, and I am writing my own vga driver from scratch, simply to learn all these nuances of PASM. This wrlong src, dest (instead of dest,src) costs me some time to find what is wrong. Waitpeq didn't work until I realized I put arguments in wrong order, too. You cannot put : at the end of label in Pasm. It seems it is a lot to unlearn.

There are many object - maybe even too many - in OBEX, so I decided I have to choose and complete my own set of tools, and then make necessary changes to them to get them work together. I still want to have my own vga drivers, and it seems I will use KyeDOS as a base in my next learning phase It can work with sdhc and fat32, it has option to pass parameter to program it calls. When I can manage to get a KyeDos, wave player, chiptune player, serial driver and self made vga driver working together, it will be time to go to the next stage, which will be LMM, emulators and projecting a two propeller board.

mindrobots

If you are well versed in C, then you may want to try the PropGCC port of GCC and SimpleIDE, a cross-platform IDE for PropGCC.

There is an extensive Demo package you can download here.

There are also a couple tutorial packages on the PropGCC site. It's still in alpha testing but it's a very mature alpha. With the new C tools, you can certainly flex the muscles of the Propeller and have access to multiple COGs, pthreads, various memory models, support for various Propeller production boards and a growing library to support different hardware. The documentation is still rough in some spots but if you are a C programmer, this would be the quickest way to start exercising your new board.

You can also (when needed) access PASM code chunks for the maximum speed, provided you are expert enough in PASM to out code the optimizer.

The Propeller Tool, of course has the full documentation for both the SPIN language and PASM as online documents. And the Propeller education kit has tutorials for getting used to the hardware and software.

prof_braino

We MUST start with SPIN, per the design of the prop. Eventually we tend to want to move towards PASM, to use the full speed and power of the prop. The question is about a third tool, to use after we've begun with spin, but before we have fully mastered PASM.

If you already know and love C, then C it a logical choice as folks are familiar with it. But the prop has many architectural features that make it significantly different than typical (workstation) C implementations. It is useful to note that in the context of micro controllers, C is very handy for implementing OS for a workstation.

If one does not have prior attachments with a specific language or environment, it may be beneficial to consider forth on the prop. It allows immediate interactive experimentation with the peripherals. It allow interactive experimentation with snippets of assembly code. A set of functionality can be very quickly implemented, tested and debugged in forth. The bottle necks or other slow spots can be identified and optimized in assembly, without having to go through the very long learning curve to master all of assembler to be able to start using it. Many find this to be the right tool for the right job. Forth does not replace all tools, in this context it can be very handy.

pik33

I experimented with Forth some 20 years ago, so I can try it again. I still have a book about it.

rwgast_logicdesign

@prof_braino forth and some of the projects using it like the one we were e-mailing about looks very intresting. the problem is ive never used or even seen fourth. the fact that prop fourth is the only time ive seen anything modern using it kind of turns me off to investing time into it. im under the assumption that it is considered a dead language and only used in very niche/old/hobby enviroments. im not knocking fourth im just saying i dont see myself using ilt outside a few propeller based projects therefore the time invested in learning the fourth syntax and paradigm is just not worth the return.

however i already know c and usually use it for any project that needs to get any work done with resonable speed and flexability. i may use higher level languages to make a quick gui or something that then uses c for all the real work. what im having an issue with is wether c is going to as powerful on the prop as it is on a more native platform that compiles to straight binary not bytecode.

im kind of confused at to the difference in catalina and prop gcc. im very familiar with gcc already but catalina looks alot more mature and feature rich. for instance i read that catalina has stuff to interface to props seemlesly and use code on one to control the other as if it were dealing with one chip. this all seems cool but i guess what im asking is which is better at this point in time as far as speed/documentation and porting other ucontroller code to the prop.

as far as spin goes i understand there are things that have to be done with spin when using pasm. i guess im asking how far should i go down the spin route? im mean is reading through the boe going to be enough if most of things im intrested in doing just wont work at spims speeds? im also under the impression that i could just learn c on the prop and interface it with pasm which would completely void any reason for me to use spin and the c would be a faster hi level alternative to spin. im not saying this is the best route, but it is the fastest way to start writing prop apps at decent speed. i chose the prop as my first micro becuase of its power and architecture, but i really wish the learning curve wasnt so hi. i really just want to go down the right path to be a solid prop coder when ot comes to things like writing drivers. my whole intrest in micros is to learn alot of the low level stuff that is abstracted on a pc.

msrobots

I vote for SPIN, because of the code-size.

If you want C you need pretty soon external memory. Spin might be slower but it is very compact and 32K Hub is OK then.

And slow (?) hm. PASM about 10_000 Instructions per second and spin maybe 3000. Still pretty fast.

enjoy!
Mike

potatohead

I don't think it's a must to start with SPIN, particularly given we've got good C / C++ tool chains now. Some of us didn't do SPIN early on, just including enough to start PASM, moving from there too.

That said, I would deffo explore SPIN+PASM. It's a great combination! Easy, efficient, flexible, etc... Fun, if you ask me, just because it's lean and mean, and one can do more than it appears at first glance too.

Some simple SPIN benchmarks, copy memory, increment, add, etc... ran about as fast as assembly did on my old 8 bit computers. Slow by today's general expectations, but when combined with PASM, often plenty fast enough. Eric Ball wrote a low resolution video driver in SPIN, just for reference...

We've extended on the original design expectations inherent in SPIN + PASM. Bill Henning figured out LMM, and from there we have boot strapped C and it can run programs stored on pretty much anything. C is quite powerful now.

IMHO, the best overall attribute of SPIN + PASM is the lean and flexible nature of it. Easy things are pretty easy, and generally not laborious, and the many objects are useful, though I agree picking through them can be a burden. IMHO, nice problem to have!!

If it's raw speed and power on larger code bodies you need, or big data, C is probably where you will end up. Having a nice SPIN + PASM foundation will only enhance that experience, based on my own experiences so far. I find the C comes with some extras one needs to know, compared to SPIN + PASM, some just an artifact of the language and are well known and documented, others being a function of how the Propeller does things. Once a person gets past those, I think it's highly productive, and more capable in the end.

Cluso99

I chose to learn spin first, quickly followed by pasm. I am not a C programmer although I using a little C with Catalina. My background is firstly in assembly... mini-computers and micros, but I have also written commercial code in VB (up to VB6). I found spin easy - yes there are some gotcha's but the main parts are simple.

Once I knew enough to make programs work I started in pasm, using a mix of spin and pasm. Anything requiring speed was done in pasm and dedicated cogs where necessary. Spin was for the rest. If there is no reason for speed, then spin was fine, and I spent the time getting the pasm fast. Note that when I started on the prop C was not really available (ICC was but was $).

For what you say you are wanting to do, understanding the prop architecture is the most inportant, and for that you will need to become a master of pasm, will need to know the interaction with spin, and probably C (Catalina or GCC) for other tasks too.

This is just my 2c... hope it helps you decide. BTW try the prop exercises that come with PropTool - its a quick intro to the prop if you understand micros (and perhaps you know enough because of your 486 asm) and C. Its a quick and brief set of exercises.

rwgast_logicdesign

alright well ill just stick to the docs with the prop tool for now to get a grip on spin while reading potatos pasm book and leave c out until i have a good grasp on the propeller and things like spi, i2c, counters simple video etc. i would think knowing spin is propabably most handy even if you dont use it just becuase a majority of stuff on obex is spin.

i know pasm most pasm is about 1 instruction per cycle while most spin is 1 instruction per 4 cycles. does anyone know the numbers on c and fourth? also for those of you using c, which is the better route catalina or gcc? im thinking catalina is more functional but thats an assumption based on research

Heater.

msrobots,

...PASM about 10_000 Instructions per second...

What?! A Props COG executes one PASM instruction every four clock cycles. So that normally 20 million instructions per second. (Not counting hiccups when waiting to access HUB).

rwgast,

...pasm is about 1 instruction per cycle while most spin is 1 instruction per 4 cycles

No, see above. But what do you mean by "instruction" in Spin? A single Spin statement can result in many Spin byte codes. Executing each of those byte codes will take the Spin interpreter 50 to 100 PASM instructions. So we might say that Spin is perhaps a hundred times slower for the same functionality as PASM.

...does anyone know the numbers on c and fourth?

C gets compiled to PASM instructions which are loaded from HUB and executed in COG one by one. So called Large Memory Model (LMM). The load execute loop is taking about 4 instructions. So we can expect execution to be one quarter of in COG PASM speed. Much faster than Spin.

The same functionality will occupy much more memory in C than it does in Spin because Spin byte codes are a lot more compact than the 32 bit PASM instructions resulting from C compilation.

C code can also be compiled to PASM that is loaded and executed from external RAM , good for large programs but slower and uses many valuable Prop pins.

Catalina or gcc

Write your C code such that it can be compiled with either. Perhaps hiding any differences in library functions or header files. No point in using a cross platform language, C, if you can't swap from compiler to compiler on the same architecture even.

kwinn

Learn Spin and PASM. Seven cogs running PASM is 140,000,000 instructions per second. Add 1 cog running spin to co-ordinate the other 7 cogs and you have a pretty potent system.

You already know C so learning the quirks and limitations of C for the propeller should be simple enough, but keep in mind that C will need some form of added memory to be useful for all but the simplest of programs.

Forth is a simple, extensible, compact, and powerful language that can be adapted to any application by adding “words” to the dictionary. IMHO it's use will continue to increase for the forseeable future and is well worth learning.

rwgast_logicdesign

im sorry i must have gotten my pasm cli numbers confused with the prop2, i dunno where i pulled the spin number from.

when i asked about c i guess i meant as far as a si standards and capability on the prop architectire do gcc and catalina whiegh in the same. im sure using catalina librarys in gcc shouldnt pose a problem. i know gcc well and it is my compiler of choice unless im developing windows apps. im just trying to find out speed/stability/standard functionality wise if the use of these compilers is basically the same.

as far as fourth i may look into it i just assumed it has gone the way of languages like ada, fortran, cobol, etc.. it had its use in the day but has long since been overshawdowed and only used in niche clicks of coders or people suppprting 70s mainframes. i mean why not phython why fourth?

pik33

Forth was never very popular language - it is strange enough. It is one of those "esoteric" languages, and it doesn't look like Fortran, Pascal or Python.

This is language suitable for small systems, like a propeller. Its code is small and efficient. You have a default vocabulary at start, then you can create new words from what you have and created. At the end, your "program" is simply another Forth keyword.

Heater.

Both Catalina and propgcc are standards compliant. Catalina to C89 and propgcc to the assortment of standards provided by GCC. propgcc also supports some non-standard C extensions. One that I like "labels as values" which can be very useful in creating threaded code within a COG. Catalina does not have such extensions and does not allow for compiling code to run native in a COG anyway.
I believe Catalina is totally compliant with respect to the standard C library functions. Not sure if propgcc has reached that level yet but I would not be too worried about that.

I suspect that using Catalina libs in GCC or vice versa may not always work. What I meant was that you should be able to create code that works with either compiler, using #ifdefs and such. Much as is done normally to get cross platform code.

prof_braino

rwgast_logicdesign wrote: »

im under the assumption that it is considered a dead language

This would be your incorrect assumption. You don't hear about forth because folks don't advertise the "secret weapon". Typically, initial development on new hardware done in forth is later optimized in assembler, eventually being replaced by assembler, or the forth prompt is not accessible to the end user. In cases where corporation etc have workstations with tons of memory and existing staff of C coders, they can go directly to C. "Bleeding edge" development on sub-workstation hardware can call for other tools.

i already know c

In you case you fit the "existing staff" consideration, so C is your likely option. I'm posting here for others that might have the same question but different background.

im kind of confused at to the difference in catalina and prop gcc.

They are two different tools written by different people. As I understand it, Catalina is being done by mostly RossH, and GCC is being done by a group lead by Parallax, but lead by user jazzed. Both as useful and upder development. Both are being refined continuously. I got some C code compiled on the Image Craft C compiler, and it needs changes to work on Catalina and GCC. But I am not a C coder, and I could not even get the same build results as RossH and jazzed when I tried. So I have to spend the time to learn C, or find a high school kid to show me how to get started. I'm too lazy to learn Spanish just to talk to folks that already know English, and simply I'm too lazy to learn C for one compile. If both can be made to work, great, if only one works, also great, I'll post the results.

my whole intrest in micros is to learn alot of the low level stuff that is abstracted on a pc.

In this case you are back to considering forth. C abstracts everything on micro just as om PC, I believe thats the whole point. Unless you are a real expert, C "covers up" the internals just as SPIN does. (The folks that would disagree here are what I call "experts"). Assembler is what really controls what going on. Forth is less abstraction, and lends itself well assembly optimization of individual routines. This is just for information for folks asking the similar question but have not decided yet, I'm not trying to change anyone's mind.

prof_braino

pik33 wrote: »

Forth was never very popular language ...

All the folks that continue to use and develop forth would disagree, if they could be bothered, but usually they don't anymore (I'm the last one, I think). We're approaching 200 download of version v5.0, so unless my mom is hitting the download button over and over again, there are folks at least looking at it. The numerous forths for different micro controller and the continued support they receive also contradict the "dead language" idea. Forth is easy to get going and get right, and tends not to need further development unless you have a big crazy project in mind. (I only know a few folks that have written their own C compiler, but I know LOTS of folks that make their own forth system). Propforth and AMFORTH are examples where community refinements keep the project evolving. Forth is hugely popular among the users, their number just happen to be a minority percentage of total programmers, but continues to grow each year. There's no good statistic, but I don't see how it could ever decrease. Just cause todays job pays to code in ADA doesn't mean I'm no longer able to code in BASIC or forth.

This is language suitable for small systems, like a propeller.

And C is suitable for PC OS. We can use one in place of the other if we want, and it can be fun. But in my small opinion certain choices end up making us "fight the tool" instead of just "using the tool".

I do tend to carry on, but forth is a tool that belongs in any experimenter's arsenal. I should shut up, huh?

mindrobots

: forth-evangelize saddle burr swap Prof_Braino ;

Sorry, couldn't resist adding a new word to the vocabulary.

If you are already well versed in C, VB, X86 ASM and have used several scripting languages, you shouldn't have any problems either learning SPIN and/or PASM or using C to develop on the Propeller. The various advantages and disadvantages have been pointed out. The unique and flexible architecture of the Propeller is something you will need to understand to use it effectively in ANY language. The memory limitation is something to get used to if you are coming from a BIG environment, managing multi-processing where you are in explicit control of the processors is sometimes a challenge to grasp, shared (HUB) memory and non-shared (COG) memory is often a stumbling point for people. Any of the core Propeller languages allow you to do all of this with some study and understanding. Trading your coding time for execution time can weigh in your decision, sometimes, fast enough to get the job done is really fast enough. If you are waiting on an external event that occurs every 1/2 second running at 80MHz, 96MHz or 104Mhz probably really won't make a difference to getting the job done.

Forth takes a different way of thinking (ok, you can take that any way you want to ) for some people to "get it", some people never "get it" (resistance is futile because we move on and leave you behind). I find it very cool and rewarding to sit down with an interactive environment that gives me access to every COG and what they are doing. The ability to incrementally shape an application environment, the ability to start, stop and redefine what individual COGs are doing all interactively on a single Prop or now, multiple Props in a cluster, that's pretty nifty stuff. But at the end of the day, they are all just tools to get a job done, you make trade offs with every task, or you shrivel up and die.

Mike G

Agreed Rick... languages are tools. The real trick is simplifying a complex concept.