Here is another take on 'What is a Propeller assembly program?' From datasheet.
It is often advantageous to write objects almost entirely in Propeller Assembly, but at least two lines of Spin code are required to launch the final application.
Good explanation too.
What are those two lines? Now we're getting someplace!
How many instructions are there? Sure hope they are categorized like Stamp Editor Help!
Found it. It's not called an Instruction Set. 'Instruction Table'.
It does not say how many there are! The average person would like some advance info on that.
Here is 'what' they are:
The Propeller Assembly Instruction Table lists the instruction’s 32-bit opcode, outputs and number of clock cycles. The opcode consists of the instruction bits (iiiiii), the “effect” status for the Z flag, C flag, result and indirect/immediate status (zcri), the conditional execution bits (cccc), and the destination and source bits (ddddddddd and sssssssss).
Like Dobie Gillis. 'WORK!?'. It will take awhile just to understand this part.
They are 'multi' instructions all right. I have looked at two operand instructions a little bit before.
This is a very difficult device for me to nail down.
Understandable.
Have you got a Propeller to bang around on? If not, get one. Seriously. It really helps to run a few of the easy "demo" programs you find in the library folder loaded when you install the Propeller Tool.
We haven't yet seen what kind of example code makes sense for you. When / if you want / can tell us a bit about that, some conversation may go a lot easier.
I came from the 8 bit world, mostly 6502 / 6809 and a little z80 / Intel 8086. Recently, I've been working with the 8085 a little. Kind of brings some questions back to mind. One of those is what the general approach to things looks like. In some ways, it's very familiar. Say, one writes a bit of code to look at a keyboard. On those old chips, we stuff that into an Interrupt Service Routine, and once it's setup, we forget about it and get back to the main application. Where you would do that on a Propeller, you do it with one of the COGS. And a COG can do more than one thing usually.
The cool part is where we would add chips to an older type computer, say to make a display, or do something more complicated, a Propeller COG often can do those things too. Soft peripherals, is what we tend to call doing that, and it's why we really like this chip a lot.
In this sense, you may find it helpful to think of the Propeller as a little system. Unlike other hardware based systems, Propellers are software defined. You build up the system you need to get the job done, then getting the job done is pretty easy, mostly because the system is dialed right in for that particular job. It's like making a dedicated, embedded computer, only most of the work is software, not hardware.
First, just know a few things: (these are just good to keep in mind)
The most difficult thing, for me at least, was understanding a Propeller can only execute it's native instructions from the COG memory! There is no concept of a larger assembly language, really machine language, big program running from the HUB memory region. It can only happen in the COG.
The other difficult thing is to grok how a COG works. When one gets started up, a pointer to a region of HUB memory is provided. The COG memory gets filled up with a copy of that HUB memory image, and program execute starts at COG address 0. Not a move, just a copy. Literally, those bytes get copied from the HUB, and once they are all copied, the COG starts up.
So, one can do things like start a few COGS up from the same code image in the HUB. People do that when tasks need to be done in parallel.
Or, start a COG up, and once it's running, it can overwrite the program image in the HUB as it's no longer needed! (makes a great buffer space) People do this when they need concurrent execution, like being able to check a mouse, keyboard, or do comms, or a display, for examples.
Finally, it can really help to visualize the Propeller COGS as little, self-contained computers, all connected to the HUB memory and the pins, and all of them see the same system counter too. Very handy. These turn into peripherals, basically. They turn into the things your main program is gonna need, specifically.
Each COG is completely independent of the others too. They can't see one another, except through the pins and the HUB.
There is no "central" COG. They are all the same, and it will turn out that one of them is running your "main" program, but there is no defined way, or specific COG. It just works out that way, most of the time.
Maybe it will help to see a big picture, low detail look at how one might actually get something done on a Propeller!
So, let's do that, here we go!
Ever notice how most parts of a program just don't need a lot of speed? That's what SPIN is for, and SPIN runs about as fast as machine language programs do on 8 old bit computers. The SPIN execute speed is comparable to a couple Mhz 6502, etc...
COGS are roughly 20x faster, running native machine PASM language code.
Think about all of that, and realize the intended use is to write your program in SPIN. Then, you use the COGS to do the fast parts. Fast parts can be things like math, comms, video displays, audio...
Now, the tools!
Today, we've got a variety of tools for the Propeller, and we've got ways to execute PASM programs out of the HUB memory too. That's called LMM, invented by Bill Henning, and it's basically a supervisor program, a little virtual memory program that fetches instructions from the HUB so they can be run in the COG. That got us C, and tools that may seem more familiar:
But, the native SPIN + PASM isn't like that. Most of those functions are performed, but the truth is, you can make big programs and put the whole darn thing into one file! Or you can break your program up into modules. (much better way most of the time) That stuff all gets compiled down to bytecode, and COG machine language program images. That's all one binary package that ends up being loaded into the Propeller from a PC, or EEPROM.
ie:
[SPIN byte codes]
+[PASM program image 1] --> Goes to a copy in a COG, or more than one COG
+[PASM program image 2]
+[SPIN byte code, maybe a method] --> Can also go to a COG, but is not copied to the COG
+[buffer space pre filled with data]
= [EEPROM image up to 32Kbytes]
That EEPROM load happens on power up. Cog 0 runs a program that fills the HUB up.
(It can be done differently, and often is, but know that is the designed method.)
When that binary image, containing SPIN byte codes and COG PASM images, get loaded into the Propeller, COG 0 is started, and it starts with the SPIN instructions it finds there.
All else comes from that.
So, let's say we've got a program that produces a video display, takes keyboard input, and does something with that, maybe some math. Who cares what, just that it does. Maybe picture a scientific calculator application, for example.
Your typical Propeller programmer would approach it like this:
Write or find a program to drive a display.
Write or find a program to take input from the keyboard.
Write or find a program to do the math.
Let's say the display program is PASM. Needs to be fast, so PASM it is.
Let's say the keyboard program can just be SPIN.
Let's say the math is PASM too.
As far as COGS are concerned, SPIN and PASM are interchangable. A COG runs PASM, but that PASM can be interpreting SPIN. From the programmer point of view, these are roughly the same, but for SPEED and where the actual program lives. SPIN lives in the HUB, PASM lives in the COG.
Now, let's take the display. People typically develop these as OBJECTS. The intent is for them to be included in your application program. The display program would come as a SPIN + PASM package. That's usually enough to demo the functionality in some basic way. That, plus whatever documentation was written is enough for you to try it out!
So you fetch that display program from the OBEX, wire up a suitable circuit to your Propeller, open the program in the Propeller Tool, then hit F11 or F10 to run it, optionally storing it in a connected EEPROM.
There is the display! So you tinker with this a bit, realize you need a few functions. Print character, draw line, clear screen, whatever. Once you've got this done, your display "device" is also done. You can now forget about most of that, except for the bits it needs.
Display needs a font, pointer to screen memory, pins to output on, modes, clocks and a few other things. So you do that, package it all up, until you have the necessary functionality.
We really like the Propeller for this next bit, and this next bit is what this chip is all about.
Once you have the display all setup, you simply include it in your application, and from that point on, treat it as if you had an actual graphics chip driving your display. In reality, one of the COGS is doing that for you, and it's gonna do it simple and easy.
All your program needs to do is supply the parameters and COGSTART the display object, and it's off to the races, next problem!
Keyboards are slow, so maybe write that one in SPIN. Test it, by typing things and making sure they end up on your display. Maybe tune the display methods up some, little details like backspace maybe.
Now, you can save that and optionally share it with others, and provide a little demo code to show off how it works, maybe.
Include that in your main program, and COGSTART it. Now you've got a keyboard device, same as the display. Run it, forget it. It will just do what it needs to.
Now you found or are writing the math package. Include it, and COGSTART it. But wait? How does a math library just run?
In that math COG, you have a little loop. It's watching for a command, something in shared HUB memory to work on. When it sees that, it does the math, writes the results, and then waits again, after signalling it's done with the work. Think of it like your math co-processor.
Now, you've built up the system needed to write your application!
In your application, you now have an init SPIN method that kicks everything off:
Setup parameters, pointers to shared memory regions, declare buffers, that sort of thing. Then just COGSTART, COGSTART, COGSTART...
At this point, three of the COGS are handling your display, keyboard and math.
You've got 5 left, one of which is running your main SPIN application, which isn't really written yet, but all the framing needed to write it is done now.
You start writing your main SPIN! And that's fine, until it isn't. If it's all fine, you are done!
If not, speed is usually the issue, or maybe you figure out a mouse would be nice.
So you identify what it is, how to do it, then write a small PASM program to do the thing, and once you have that done, you package it up, same as the ones you will have found, COGSTART it in your init method, and continue on.
Assuming a mouse would make sense, a COG could get dedicated to that task, and you put that in your init code, start that mouse COG up, like the others, and now you have a mouse in your system, just the thing you need to finish your main application.
When you get done, you will have a SPIN + PASM program that delivers all the necessary functions, peripherals needed to support your application.
You can load it into a Propeller to test, and when you are happy with it, have it written to an attached EEPROM so that application is what gets loaded by the Propeller when it's powered on.
See, I did a very similar thing with the 8085 recently. Got a Tandy Model 100 to play with, and to get a feel for the thing, I knocked out a little hand assembled program that basically was what you put here, only mine returned instead of ending. (because that machine has an environment already, gotta play ball with that. You know how it is.
If you want to do that, then the next best thing is to do what I have in the Beginner manual. I wrote it for that purpose. More advanced things are in the DeSilva companion work, and or the topic of discussion here, but people gotta get going, so...
That little LED blinker program in the beginner document is basically what you are looking for.
Edit: I should say, this thing is built from the ground up for people to build on code already out there. Baked in. And that is the very easiest way.
Won't seem like it, but trust me. It is. And it won't take you long at all, once you give doing that a go.
Chip has a way. It's compelling, potent, effective.
And, yes! PIC, SX, others are style cramps.
Right on, that did bring him up. And a lot of what is in Propeller chips is intended to get past difficult, not so fun, work on more standard devices that work in the usual, expected ways.
Sometimes those blank sheets do not pan out. Happens. Has to me, more than once. But, the beauty here is people rarely have to do that.
By overwhelming majority, people will go fetch the objects they need, get those into a sort of test harness or framework, container maybe so to speak, then they set about writing the code that solves the problem, or gets that thing, whatever it is, done.
Many of us have domain experience too. We've written objects that package that experience up into bits others can start from.
Anyhow. With the new Propeller 2 coming out. Is it worth learning the Propeller 1?
Does it build on the Propeller 1 or like the 1 now it will be a different animal with little crossover?
Edited:
P1 is not going anywhere. A lot of what people have learned will apply and be generally useful on P2.
And, the chips differ enough in scale, power, etc... that P1 will continue to be well indicated enough of the time to warrant understanding it longer term.
The way I see it, if one is going to learn how to use a Propeller, the big differences, the stuff of this thread, matter. Gotta get through those things.
Anyone who does will enjoy P2, while likely continuing to use P1 where it makes the most sense.
Actually, there are exactly 64 instructions (I-field is 6 bits), but the assembler splits some of them up into multiple mnemonics for easier programming.
For example, "and foo,bar nr" is the same instruction as "test foo,bar"
A little late coming to this MCuser, but thought I 'd add a bit of perspective. At early stages you shouldn't be worrying about PASM at all. That's like learning to drive in a Porsche Panamera -- you're going to be concerned with a lot of stuff other than just how to drive. Better to start with a Toyota, and get to the Porsche when you know what to do at a Yield sign.
What happens when you boot a Propeller, if it is in a normal environment with an EEPROM, is that it self-loads a 32K Hub RAM image. That image can be anything -- Spin, snippets of PASM, C byte codes, the Propeller doesn't care. It uses that image to fill up the no longer blank Hub RAM though. This is entirely in the silicon, it's not a program doing it.
And the reason "everything starts with Spin" is that the Propeller then loads a cog with a PASM image, not from Hub RAM, but from its permanent ROM. This is the Spin interpreter, which is a PASM program itself. The boot cog running this program then starts interpreting Spin at a default address point.
Now there are systems whose only spin bytecodes tell the Propeller to start another cog with another PASM image, and then stop the original Spin cog. That's why you need two spin instructions minimum. The Spin interpreter, which is itself a PASM program, is auto-started when the Propeller boots. And that's because Chip considered Spin the native language of the Propeller.
Spin runs pretty fast; at 80 MHz Spin is about as fast as assembly language was on the beloved 8-bit computers of the 1980's, and much easier to use. And those machines were fast enough to do a lot of surprisingly useful stuff. PASM comes in when you want to do something _wicked_ fast or very accurate timing-wise. But most of that is done by objects that come with their own PASM drivers so you don't have to mess with it -- fullduplexserial for serial ports, various video drivers, the keyboard PS/2 driver, all rely on their own PASM images to start cogs up with PASM code to do fast stuff. But you don't need to worry about any of that; you can do serial communication, put up a video display (or even more than one, which is ultra cool), read keyboard or mouse or a SD card, without worrying about how any of it really works. Just use the OBEX objects to do the functions for you. You get into PASM when you want to do something wicked fast that nobody else has done before, which honestly doesn't happen very often.
What is ultra cool about the Propeller is that its pins are all the same. If you go shopping for any other MCU you face a bewildering array of possibile peripheral options, often small variations on the same CPU core. With the Propeller you get 32 totally generic pins. You want to use three banks of 8 to implement three VGA displays? Software. You want twelve serial ports? Software. You want six serial ports, a buffer on a SD card, and a display and keyboard control console? Software. All from the same CPU. Nothing else can do that.
Comments
Thank you Phil
I just realized I have yet to see the Assembly instruction set.
When you search for Propeller info it is mostly for Spin.
I will keep looking for it.
Good explanation too.
What are those two lines? Now we're getting someplace!
How many instructions are there? Sure hope they are categorized like Stamp Editor Help!
Back to looking for instruction set.
Found it. It's not called an Instruction Set. 'Instruction Table'.
It does not say how many there are! The average person would like some advance info on that.
Here is 'what' they are:
Like Dobie Gillis. 'WORK!?'. It will take awhile just to understand this part.
They are 'multi' instructions all right. I have looked at two operand instructions a little bit before.
That is enough for now.
-Phil
It is.
Understandable.
Have you got a Propeller to bang around on? If not, get one. Seriously. It really helps to run a few of the easy "demo" programs you find in the library folder loaded when you install the Propeller Tool.
We haven't yet seen what kind of example code makes sense for you. When / if you want / can tell us a bit about that, some conversation may go a lot easier.
I came from the 8 bit world, mostly 6502 / 6809 and a little z80 / Intel 8086. Recently, I've been working with the 8085 a little. Kind of brings some questions back to mind. One of those is what the general approach to things looks like. In some ways, it's very familiar. Say, one writes a bit of code to look at a keyboard. On those old chips, we stuff that into an Interrupt Service Routine, and once it's setup, we forget about it and get back to the main application. Where you would do that on a Propeller, you do it with one of the COGS. And a COG can do more than one thing usually.
The cool part is where we would add chips to an older type computer, say to make a display, or do something more complicated, a Propeller COG often can do those things too. Soft peripherals, is what we tend to call doing that, and it's why we really like this chip a lot.
In this sense, you may find it helpful to think of the Propeller as a little system. Unlike other hardware based systems, Propellers are software defined. You build up the system you need to get the job done, then getting the job done is pretty easy, mostly because the system is dialed right in for that particular job. It's like making a dedicated, embedded computer, only most of the work is software, not hardware.
First, just know a few things: (these are just good to keep in mind)
The most difficult thing, for me at least, was understanding a Propeller can only execute it's native instructions from the COG memory! There is no concept of a larger assembly language, really machine language, big program running from the HUB memory region. It can only happen in the COG.
The other difficult thing is to grok how a COG works. When one gets started up, a pointer to a region of HUB memory is provided. The COG memory gets filled up with a copy of that HUB memory image, and program execute starts at COG address 0. Not a move, just a copy. Literally, those bytes get copied from the HUB, and once they are all copied, the COG starts up.
So, one can do things like start a few COGS up from the same code image in the HUB. People do that when tasks need to be done in parallel.
Or, start a COG up, and once it's running, it can overwrite the program image in the HUB as it's no longer needed! (makes a great buffer space) People do this when they need concurrent execution, like being able to check a mouse, keyboard, or do comms, or a display, for examples.
Finally, it can really help to visualize the Propeller COGS as little, self-contained computers, all connected to the HUB memory and the pins, and all of them see the same system counter too. Very handy. These turn into peripherals, basically. They turn into the things your main program is gonna need, specifically.
Each COG is completely independent of the others too. They can't see one another, except through the pins and the HUB.
There is no "central" COG. They are all the same, and it will turn out that one of them is running your "main" program, but there is no defined way, or specific COG. It just works out that way, most of the time.
Maybe it will help to see a big picture, low detail look at how one might actually get something done on a Propeller!
So, let's do that, here we go!
Ever notice how most parts of a program just don't need a lot of speed? That's what SPIN is for, and SPIN runs about as fast as machine language programs do on 8 old bit computers. The SPIN execute speed is comparable to a couple Mhz 6502, etc...
COGS are roughly 20x faster, running native machine PASM language code.
Think about all of that, and realize the intended use is to write your program in SPIN. Then, you use the COGS to do the fast parts. Fast parts can be things like math, comms, video displays, audio...
Now, the tools!
Today, we've got a variety of tools for the Propeller, and we've got ways to execute PASM programs out of the HUB memory too. That's called LMM, invented by Bill Henning, and it's basically a supervisor program, a little virtual memory program that fetches instructions from the HUB so they can be run in the COG. That got us C, and tools that may seem more familiar:
Editor
Compiler
Assembler
Linker
Object Code Image.
But, the native SPIN + PASM isn't like that. Most of those functions are performed, but the truth is, you can make big programs and put the whole darn thing into one file! Or you can break your program up into modules. (much better way most of the time) That stuff all gets compiled down to bytecode, and COG machine language program images. That's all one binary package that ends up being loaded into the Propeller from a PC, or EEPROM.
ie:
[SPIN byte codes]
+[PASM program image 1] --> Goes to a copy in a COG, or more than one COG
+[PASM program image 2]
+[SPIN byte code, maybe a method] --> Can also go to a COG, but is not copied to the COG
+[buffer space pre filled with data]
= [EEPROM image up to 32Kbytes]
That EEPROM load happens on power up. Cog 0 runs a program that fills the HUB up.
(It can be done differently, and often is, but know that is the designed method.)
When that binary image, containing SPIN byte codes and COG PASM images, get loaded into the Propeller, COG 0 is started, and it starts with the SPIN instructions it finds there.
All else comes from that.
So, let's say we've got a program that produces a video display, takes keyboard input, and does something with that, maybe some math. Who cares what, just that it does. Maybe picture a scientific calculator application, for example.
Your typical Propeller programmer would approach it like this:
Write or find a program to drive a display.
Write or find a program to take input from the keyboard.
Write or find a program to do the math.
Let's say the display program is PASM. Needs to be fast, so PASM it is.
Let's say the keyboard program can just be SPIN.
Let's say the math is PASM too.
As far as COGS are concerned, SPIN and PASM are interchangable. A COG runs PASM, but that PASM can be interpreting SPIN. From the programmer point of view, these are roughly the same, but for SPEED and where the actual program lives. SPIN lives in the HUB, PASM lives in the COG.
Now, let's take the display. People typically develop these as OBJECTS. The intent is for them to be included in your application program. The display program would come as a SPIN + PASM package. That's usually enough to demo the functionality in some basic way. That, plus whatever documentation was written is enough for you to try it out!
So you fetch that display program from the OBEX, wire up a suitable circuit to your Propeller, open the program in the Propeller Tool, then hit F11 or F10 to run it, optionally storing it in a connected EEPROM.
There is the display! So you tinker with this a bit, realize you need a few functions. Print character, draw line, clear screen, whatever. Once you've got this done, your display "device" is also done. You can now forget about most of that, except for the bits it needs.
Display needs a font, pointer to screen memory, pins to output on, modes, clocks and a few other things. So you do that, package it all up, until you have the necessary functionality.
We really like the Propeller for this next bit, and this next bit is what this chip is all about.
Once you have the display all setup, you simply include it in your application, and from that point on, treat it as if you had an actual graphics chip driving your display. In reality, one of the COGS is doing that for you, and it's gonna do it simple and easy.
All your program needs to do is supply the parameters and COGSTART the display object, and it's off to the races, next problem!
Keyboards are slow, so maybe write that one in SPIN. Test it, by typing things and making sure they end up on your display. Maybe tune the display methods up some, little details like backspace maybe.
Now, you can save that and optionally share it with others, and provide a little demo code to show off how it works, maybe.
Include that in your main program, and COGSTART it. Now you've got a keyboard device, same as the display. Run it, forget it. It will just do what it needs to.
Now you found or are writing the math package. Include it, and COGSTART it. But wait? How does a math library just run?
In that math COG, you have a little loop. It's watching for a command, something in shared HUB memory to work on. When it sees that, it does the math, writes the results, and then waits again, after signalling it's done with the work. Think of it like your math co-processor.
Now, you've built up the system needed to write your application!
In your application, you now have an init SPIN method that kicks everything off:
Setup parameters, pointers to shared memory regions, declare buffers, that sort of thing. Then just COGSTART, COGSTART, COGSTART...
At this point, three of the COGS are handling your display, keyboard and math.
You've got 5 left, one of which is running your main SPIN application, which isn't really written yet, but all the framing needed to write it is done now.
You start writing your main SPIN! And that's fine, until it isn't. If it's all fine, you are done!
If not, speed is usually the issue, or maybe you figure out a mouse would be nice.
So you identify what it is, how to do it, then write a small PASM program to do the thing, and once you have that done, you package it up, same as the ones you will have found, COGSTART it in your init method, and continue on.
Assuming a mouse would make sense, a COG could get dedicated to that task, and you put that in your init code, start that mouse COG up, like the others, and now you have a mouse in your system, just the thing you need to finish your main application.
When you get done, you will have a SPIN + PASM program that delivers all the necessary functions, peripherals needed to support your application.
You can load it into a Propeller to test, and when you are happy with it, have it written to an attached EEPROM so that application is what gets loaded by the Propeller when it's powered on.
Done.
Thank you Phil
The Many Loves of Dobie Gillis
Thank you Potatohead
I was kind of headed the other way about this.
1 Two lines of code to start assembler
2 Program Start
3 Label
4 Goto Label
5 End
Just want to prepare you for how my mind works or doesn't work.
That would be after locking things down to just one cog running.
Nothing car run out of main memory?
If it's PASM, it happens in a COG, period.
Ahh, I see I probably hit the mark.
See, I did a very similar thing with the 8085 recently. Got a Tandy Model 100 to play with, and to get a feel for the thing, I knocked out a little hand assembled program that basically was what you put here, only mine returned instead of ending. (because that machine has an environment already, gotta play ball with that. You know how it is.
If you want to do that, then the next best thing is to do what I have in the Beginner manual. I wrote it for that purpose. More advanced things are in the DeSilva companion work, and or the topic of discussion here, but people gotta get going, so...
That little LED blinker program in the beginner document is basically what you are looking for.
Edit: I should say, this thing is built from the ground up for people to build on code already out there. Baked in. And that is the very easiest way.
Won't seem like it, but trust me. It is. And it won't take you long at all, once you give doing that a go.
Blink LED.Got it.
I guess you can say the Propeller is 'Chip Gracey Unchained!'.
If you have that kind of stuff in your head working with existing devices like PIC and SX would cramp your style.
Of course I would say working with those brought his knowledge up to that point.
The boogaboo with that is with a blank sheet to work with will the final creation hold water? Be worth doing.
Anyhow. With the new Propeller 2 coming out. Is it worth learning the Propeller 1?
Does it build on the Propeller 1 or like the 1 now it will be a different animal with little crossover?
Chip has a way. It's compelling, potent, effective.
And, yes! PIC, SX, others are style cramps.
Right on, that did bring him up. And a lot of what is in Propeller chips is intended to get past difficult, not so fun, work on more standard devices that work in the usual, expected ways.
Sometimes those blank sheets do not pan out. Happens. Has to me, more than once. But, the beauty here is people rarely have to do that.
By overwhelming majority, people will go fetch the objects they need, get those into a sort of test harness or framework, container maybe so to speak, then they set about writing the code that solves the problem, or gets that thing, whatever it is, done.
Many of us have domain experience too. We've written objects that package that experience up into bits others can start from.
Edited:
P1 is not going anywhere. A lot of what people have learned will apply and be generally useful on P2.
And, the chips differ enough in scale, power, etc... that P1 will continue to be well indicated enough of the time to warrant understanding it longer term.
The way I see it, if one is going to learn how to use a Propeller, the big differences, the stuff of this thread, matter. Gotta get through those things.
Anyone who does will enjoy P2, while likely continuing to use P1 where it makes the most sense.
Thank you Potatohead
Counted the instructions in the instuction set(Table).
78 of them.Now we will go looking for them grouped by category like Stamp Editor Help does.
Will work on flashing LED lesson.
Happy Holidays!
For example, "and foo,bar nr" is the same instruction as "test foo,bar"
Thank you Wuerfel_21
Good info.
Will read Potatohead's manual tonight.
Happy Holidays!
What happens when you boot a Propeller, if it is in a normal environment with an EEPROM, is that it self-loads a 32K Hub RAM image. That image can be anything -- Spin, snippets of PASM, C byte codes, the Propeller doesn't care. It uses that image to fill up the no longer blank Hub RAM though. This is entirely in the silicon, it's not a program doing it.
And the reason "everything starts with Spin" is that the Propeller then loads a cog with a PASM image, not from Hub RAM, but from its permanent ROM. This is the Spin interpreter, which is a PASM program itself. The boot cog running this program then starts interpreting Spin at a default address point.
Now there are systems whose only spin bytecodes tell the Propeller to start another cog with another PASM image, and then stop the original Spin cog. That's why you need two spin instructions minimum. The Spin interpreter, which is itself a PASM program, is auto-started when the Propeller boots. And that's because Chip considered Spin the native language of the Propeller.
Spin runs pretty fast; at 80 MHz Spin is about as fast as assembly language was on the beloved 8-bit computers of the 1980's, and much easier to use. And those machines were fast enough to do a lot of surprisingly useful stuff. PASM comes in when you want to do something _wicked_ fast or very accurate timing-wise. But most of that is done by objects that come with their own PASM drivers so you don't have to mess with it -- fullduplexserial for serial ports, various video drivers, the keyboard PS/2 driver, all rely on their own PASM images to start cogs up with PASM code to do fast stuff. But you don't need to worry about any of that; you can do serial communication, put up a video display (or even more than one, which is ultra cool), read keyboard or mouse or a SD card, without worrying about how any of it really works. Just use the OBEX objects to do the functions for you. You get into PASM when you want to do something wicked fast that nobody else has done before, which honestly doesn't happen very often.
What is ultra cool about the Propeller is that its pins are all the same. If you go shopping for any other MCU you face a bewildering array of possibile peripheral options, often small variations on the same CPU core. With the Propeller you get 32 totally generic pins. You want to use three banks of 8 to implement three VGA displays? Software. You want twelve serial ports? Software. You want six serial ports, a buffer on a SD card, and a display and keyboard control console? Software. All from the same CPU. Nothing else can do that.
Thank you Localroger
Good info!
Looking forward to using Propeller
Happy holidays!