I think part of your problem is that you're expecting something more complex than what actually exists. The best reference for the "memory model" is the Propeller block diagram here. Anything else is the result of running an interpreter of some sort as a program in one of the cogs.
The HUB memory is actually treated somewhat like an I/O device as far as the cogs are concerned. There are special instructions to fetch and store bytes, words, and long words in the HUB, so it's not mapped at all into the cogs' memory space.
The Spin interpreter is written to use HUB memory for the interpretive code, global variables, and various internal tables used to access the code and variables. There is a stack allocated from the end of the program upwards in HUB memory that is used for the default (or only) cog. The interpretive code is based on a stack machine with local variables allocated in the stack frames for the call chain.
When you start up a new cog to run Spin code, a copy of the Spin interpreter from ROM is loaded into the cog (and occupies essentially all of it). You have to supply a stack area for the new Spin interpreter to use and the current cog's Spin interpreter passes a set of pointers to the new Spin interpreter that enable it to start interpreting at the proper place in your program. The description of the COGNEW and COGINIT statements in Spin is pretty complete.
As far as Spin is concerned, memory is a monolithic block of 32K bytes containing the program, variable areas, and stack space. It is possible to generate the address of the current end of stack and some programs will dynamically allocate space starting at the end of memory downwards or at some minimum number of bytes past the end of the stack upwards. There are a few objects in the Object Exchange that will do that for you, but it's usually easier to do it yourself.
Assembly is just a block of constant information compiled into the object program that happens to be written using the assembly language. A variant of COGNEW and COGINIT copies 512 longs beginning at the specified address. It's assumed that the first long is the first instruction to be executed. If the code is less than 512 longs, whatever follows in HUB memory is copied (usually Spin interpretive code). It shouldn't matter what's in that area as far as the cog is concerned.
The Spin compiler is smart enough to figure out if the same object is being included multiple times in one or more places in the program. In that case, only one instance of the interpretive code (and any constant areas) is included. Each instance has its own set of unique global variables. If you use an object like FullDuplexSerial that implements a full-duplex serial device and you need more than one instance, you'll have only one copy of the code, but each instance will have its own buffer areas (part of its global variables).
Each cog has 512 longs of it's own local memory (registers that can also be code). The hub which is a shared resource, is 64k of memory (32k ROM and 32k RAM). The hub cycles around to each cog in turn giving it access to the shared memory.
PASM code runs in the cogs local memory. There are PASM instructions (RDLONG/WRLONG/etc.) that allow a cog to read from the hub memory (during one of those access cycles mentioned above).
When you boot up the Propeller, a cog is loaded up with the PASM code that is the interpreter, and then that is given the address in hub memory to start reading the spin code from. The first PUB function in your spin file is what will be run. All of your local and global variables in Spin are located in shared hub memory. For the initial boot up Spin code the stack is handled for you.
Additionally there are Spin commands (COGNEW or COGINIT) that can be used to start another cog with either Spin or PASM code.
In the Spin case, the interpreter is loaded up into the new cog and given the address of the spin function you passed into COGNEW or COGINIT. You also need to define a global variable to be stack space for this new instance of the spin interpreter and pass the address into COGNEW or COGINIT.
In the PASM case, you pass in the address of a block of PASM code (defined in a DAT block), and a single long user parameter. The new cog gets loaded up with this block of PASM code, the PAR register initialized to the value of the user parameter, and the cog starts running the PASM code starting at long 0 in it's local memory. This code can do whatever it wants to with the local cog memory via PASM instructions, and it can access hub shared memory using RDLONG/WRLONG/etc. How you choose to use the local or shared memory is up to you in this case.
Note: a cog can not access the local memory of another cog directly. Each cog can only access it's own memory and hub memory. You can write code in different cogs that coordinate with eachother to copy their memory back and for via the shared hub memory if you want.
Roy
p.s. and, of course, while I was typing this, Mike Green posted a better explaination, but I'll leave this here in case it helps.
I think Ken answered the professional use quite well. I bought a pair of ProtoBoards (non USB as that was all that was available back then). I already had an FTDI 2232 board so it was easy for me to make 2 propplugs on that framework. I had done a little research into the prop while waiting for my pcbs to arrive, including downloading the PropTool.
Within an hour or two, I had worked through all the examples that came with the PropTool. That gave me the best insight into the prop and how it basically works. My first program was a few lines of code (less than 10) and I had a led flashing just by pushing it into the holes on the ProtoBoard to use the existing 10K pullups on the PS2 port!
My experience on the AVR (ATtiny84) was not so great... It took me days to understand how the compiler ran and get a led flashing. Why so long - I said above, I was programming it with a new ISP programmer that I wrote using the prop and thought my timing must be wrong. Eventually I discovered the "C delay routine" in the AVR compiler was not working!!! I replaced it with a simple counting loop and my LED flashed. Talk about a bad experience!
I digressed, so back to Ken's point. I use the prop professionally. I am not interested in an Arduino style reference platform and what the hobbyists can do with it. I am interested in what I can do with it. I design my own pcbs for what I require. This is no biggie for a professional user. Just buy a demo pcb and try a few things, then build your own circuit.
Fernand: Memory model...
Firstly, forget about adding memory for now as that is not for beginners. With your professional background you will get there quickly, but you need to understand the basics. I suggest you do the 10? examples that come with the PropTool as they build up quickly to multicore processing.
There is 64KB of hub memory and each cog can access this by byte, word or long using the rdxxxx and wrxxxx (pasm) instructions. The upper 32KB is ROM and contains a copy of the booter and spin interpreter, log and sin tables, and a 16x16 IIRC font (I haven't used any of it - well we all actually use the booter and interpreter, but not directly). The lower 32KB is SRAM. When you boot the prop it checks to see if a download is being attempted on P31/P30 serial (and its not true serial because it is using the internal RC oscillator so timing is not accurate). If so, then some of the 32KB hub SRAM will be loaded, depending on the hex file downloaded. Not sure what happens to the remainder. If not, then the prop tests for the EEPROM on P29/P28 via I2C. If found, a whole 32KB block is downloaded from eeprom to the whole 32KB hub SRAM. If neither, the prop shuts down.
Once the hub SRAM is loaded, the spin interpreter is loaded into COG 0 memory (496 longs) from the hub ROM. The prop begins executing the spin interpreter using the downloaded hub SRAM for the spin byte code. Stack space and variables (local and global) are all located in hub SRAM.
So you have...
Hub space 64KB (accessible and shared by all cogs)
lower 32KB SRAM
upper 32KB ROM
Cog space 8 @ 2KB SRAM for each of 8 cogs, 0-7
Makes 496 longs of 32b SRAM
16 longs at top of COG ram for registers
Shadow SRAM overlay the 16 registers (for advanced users only - many restrictions)
Each set of 16 registers is specific to the cog
All I/O pins are accessible by each cog - users responsibility to ensure no conflicts
If more than one cog makes a pin an output, then the pins are simply or'ed together, so a 1 overrides a 0 (so no hardware conflict)
The CNT register is global and read only, so all cogs have access to this 32b counter which increments on every clock (~90s wraparound) and can be used for all sorts of synchronising.
Spin vs PASM...
Each cog can run either spin or pasm, but not both.
Actually, the spin cog is running pasm which is the spin interpreter, but it fills the whole 496 longs of cog space.
Cog pasm code runs in the cog space and may have its variables in cog or hub or both.
Cogs accessing hub...
Each cog is given a round-robbin time slice at hub access (by using the rdxxxx/wrxxx pasm instructions)
It takes a total of 16 clocks to make 1 revolution of access
Cog 0 gets access on clock 0
Cog 1 gets access on clock 0+2 = 2
etc
If a cog does not require access, the slot is wasted (it does not move on)
If a cog requires access before its slot, it will stall until its turn. This is why rdxxxx/wrxxxx have a variable access time
External memory...
There is no defined mechanism as the address and data bus cannot be brought out to the pins.
A number of us have added external memory in various ways and provided access drivers for this.
This is for advanced users, although some programs can access this (ZiCog, Catalina, GCC)
I hope this clears up a few details for you Fernand.
Postedit: I see others have also jumped in here too. The more explanations I guess the better understanding.
Just for the record, while everything says that 512 longs are loaded from hub to cog to start a cog, I believe that only 496 are actually loaded because the registers are not loaded, but are cleared. And I think the shadow ram is not loaded either.
...and when I try to ask about the memory model, that happens to be quite specialized, one guy tells me to go RTFM, the other sort of says, yeah, RTFM, but since it's very easy for me, I'll agree to answer you, this time.
I'll apologize for coming across that way. I think part of it is that you've come here and posted along the lines of, "it *should* be this way, or they ought to do that, and this thing is ***-backwards compared to X...' kind of thing. We've seen our share of Prop bashing (and other chip bashing too), and it gets old. Once you've done that a few times you're more likely to get snarky responses than helpful ones.
It's also that many the questions you're asking kind of answer themselves fairly quickly if you use it a little. By working through a few of the simple examples in the Prop help section you'll figure out the difference between launching SPIN or ASM in its own cog, among other things. The examples Cluso mentions are exactly how I started as well. They're small, but they hit a decent amount of what you're asking.
It shows the (very high level) layout of the RAM, ROM, and cog memory, and shows that the cogs have access to RAM/ROM via the hub. The Propeller data sheet includes this image as well, and on page 7 explains quite clearly how the cogs and hub work together. (sections 4.3 and 4.4). Section 5.0 is memory organization.
So the information is there, and very easily and quickly obtained, which is probably why you got the RTFM response - we assume that you'd know the answers to these things if you've done some fairly cursory reading. (I'm sorry if that came across as snarky or antagonistic - I don't mean it in that way). Most of the forum members here are happy (almost eager) to help if you have questions, but many of those same people have a distaste for "I haven't done my homework, and can't be bothered with Google, can you do my homework for me?" If your question comes across in that way, it might be met with an RTFM response.
The shorter version: You should read through the datasheet or Chapter 1 of the Propeller manual, which is very similar in content (both available here: http://www.parallax.com/PropellerDownloads/tabid/832/Default.aspx). A lot of the questions you're asking will be at least partially answered by those. Whatever's left over we'll be happy to fill in.
I apologize if I came across snarky. I thought maybe you hadn't heard enough of the "initial reaction", but I guess you have ;-)
The amount of compatible hardware for Arduino
I'm pleased that you weren't here to simply "prop bash"... You seem to have invested yourself in figuring out which end is up. You've already caught the attention of a few of our brighter bulbs here (Mike Green, Jason, Cluso,Roy, and the like) who we are lucky to have around.
Nick and I (Gadget Gangster) are working on additional modules (shields) for the Propeller Platform. There are a number of good things happening in that regard which I can't yet talk about.
I'm pleased that you weren't here to simply "prop bash"... You seem to have invested yourself in figuring out which end is up. You've already caught the attention of a few of our brighter bulbs here (Mike Green, Jason, Cluso,Roy, and the like) who we are lucky to have around.
Nick and I (Gadget Gangster) are working on additional modules (shields) for the Propeller Platform. There are a number of good things happening in that regard which I can't yet talk about.
Welcome aboard!
Jeff/OBC
Thanks, Jeff! It's raining really hard here, and I need to go see if the humidity is whacking the harpsichord out of tune.
(footnote) I nonetheless implore y'all to work towards merging with the Arduino community by favoring common pinouts and hardware and software similarities wherever possible. I see the lovely offerings at Gadget Gangster and the ASC, and I see all the Arduino shields, and "why can't we all just CMOS along" ... ;-)
You can, but not from the same cog with just the counters. I'd suggest downloading one of the many PWM objects from the Object Exchange and using that. The Prop will handle many PWM outputs, but you typically have to devote a cog to it. Your main cog will set values in the PWM object, and the PWM object runs your outputs on another cog.
.
Since there are two counters per cog, can I have two PWM outs per cog, and just do it the same bonehead way but use a cog for every pair of PWM outputs, so for one RGB LED, just use both counter in my main gog, and just spawn another cog and keep passing it the value for the remaining single PWM output I need? So what's the simple way to pass data from my main cog to the secondary?
Since the on/off time for rgb leds is quite slow, you could just use a routine to count the time slices and control multiple pins from the one cog. IIRC the servo object handles 8 servos in 1 cog as an example.
But yes, start another cog for the next two counters. You will set the value in a hub variable, and the cog will just read this variable each time it goes to check on what value to set the pwms to.
Perhaps one of the RGB led threads or an object may give you some examples. Alternately, checkout the Quadcopter thread in the builders forum and look at the code there (Jason's or my variant of Jason's code). We pass variables via hub there between cogs.
If you're going to "spawn another cog" you might as well do software pwm of the LEDs. As I live and work in "Hollywood," LED control is a big part of my Propeller programming life. The images are from a 2010 project for Steve Wang (famous for creating the Predator and a lot of other cool movie monsters). This is Jim Rayner from the game Starcraft II. Steve's job was to take the game model and bring it to life. My job was to make the lighting work. Using the Propeller this was a breeze. I'm actually using separate Spin cogs to control each lighting zone (face, chest, "engines" on back), with a 12-channel dimmer cog (written in PASM) that provides brightness control for the LED channels. By using Spin cogs for each zone I could program and tune them separately. A master cog commands the slave cogs via state variables in the hub.
Though Steve didn't put it to use I even added an SIRCS (Sony IR control) cog so that the lighting elements could be controlled with a TV remote.
Here's two projects we did in 2011:
This one is for the game, Firefall. It has two characters that use the same controller setup I used in Jim Raynor. They have a sensor channel input that tells them when to start their animation sequence so that it is coordinated with the big prop (the "thumper") in the display.
This is Tyreal from Diablo 3 (yes, the movie business is slow right now but the gaming industry is booming). We didn't need a lot of channels for this project but we did need a lot of current so I took a different approach: I used the Propeller as a custom DMX master that would send lighting control levels to off-the-shelf DMX "bricks" (each had four outputs at 5A each). For this project we had three 12V, 25A power supplies. Each tendril had six to eight segments so they would shimmer and then do an "energy burst" animation from time-to-time.
Now let me step onto my soapbox: I *might* have been able to do these projects with an Arduino, but I know it would have been a nightmare. Steve likes to be very fluid with the lighting control and animation and by using Spin (and especially by separating lighting sections into their own cogs) I can update the animations to Steve's and the client's desires nearly as fast as they can explain what they want.
Thanks, Jeff! It's raining really hard here, and I need to go see if the humidity is whacking the harpsichord out of tune.
(footnote) I nonetheless implore y'all to work towards merging with the Arduino community by favoring common pinouts and hardware and software similarities wherever possible. I see the lovely offerings at Gadget Gangster and the ASC, and I see all the Arduino shields, and "why can't we all just CMOS along" ... ;-)
Old habits are hard to break.. (referring to the BBS computer wars of the 80's) The Propeller community is slowly coming around to a sense of inter-connectivity with projects like C for the Propeller, several open source Propeller products, and hardware compatibility. You should have seen the discussion that happened here last year when I suggested an Open Source Design Contest. There are good people here, but many are still in the early stages if accepting what the Ardunio community has openly embraced.
@Jeff: You could ask the guys at Red-5 Studios but I'm pretty sure the answer would be "No." Those props were built by a crew of 12 people over a period of six weeks, usually working 7 days each week. Needless to say, they're expensive -- and not easy to transport, either.
And in case it's not clear, the images above have no live humans in them: those people are not flesh and blood, they are silicone and fiberglass. They are amazingly lifelike; each has "real" glass eyes, hand painted skin, and thousands of hand-punched hairs.
What I love about my life in Hollywood is working with great artists on both sides of the camera. I have also used the Propeller for a commercial pan and tilt controller, and a focus/zoom controller. For my own projects I'm converting my SX-based intervalometer (time-lapse controller) to the Propeller.
I don't want to derail this thread: it was going down a path that multiple cogs with the counters are required to control an RGB LED. As can be seen in the Jim Raynor image, I'm controlling two RGB LEDs (independently, so that each engine has its own "rumble" effect) as well as four channels on the chest and a final (not seen in the image) channel for the face. The LED brightness control (accumulator-divider style PWM) for 12 channels is handled by one PASM cog.
Those coming from the Arduino mindset may first resort to hardware peripherals; those of us from the SX and Propeller world enjoy virtualizing and having exactly the control we need.
They have a lucrative sideline building electronic props for TV programs and films. They built their own CNC milling machine for making PCBs etc. and made their own injection moulder. They made the control panels for most of the Bond films. They even bought a crashed fighter jet, and have it in their yard, in case it comes in useful one day! I've known Dave Fisher, who owns the company, for many years.
And in case it's not clear, the images above have no live humans in them: those people are not flesh and blood, they are silicone and fiberglass. They are amazingly lifelike; each has "real" glass eyes, hand painted skin, and thousands of hand-punched hairs.
The first image did look weird, but the others looked like real actors.. You guys over there are amazing..
The Arduino has served to expand the electronics audience and that's a very positive contribution for the business in total. Parallax benefits by selling our sensors and related products to Arduino customers, too. All of the comparisons have been made with the Propeller, and for whatever use they may be I'm not sure, but at this stage we can move back to regular programming.
From my point of view what lies ahead for Parallax customers is truly exciting. Parallax's effort and results come in large steps. Customers sometimes think we've even gone dormant, but we're only preparing for the next phase of innovation. Many of you have been with us since the early 90s, and might own our PIC tools, SX chips, BASIC Stamp 1, or perhaps even an ISEPIC or SoundAce. This history is an important indicator of what lies ahead for our customers.
We build on prior experiences to move forward. In the near term you will be part of:
- PropGCC compiler beta for Propeller 1, with preparations and groundwork being made for Propeller 2
- open-sourcing of the Propeller compiler in C/C++, enabling many requests to be addressed
- Propeller 2 test chip and release [received an encouraging message from Chip this morning, but don't ask for specifics please]
- learn.parallax.com, where all customers will choose PBASIC, Spin, ASM or C and be able to run all of our demos more easily from the web
- Parallax Semiconductor to publish additional application notes and hardware reference designs
- hardware additions, such as the Propeller BOE, Spinneret 2, etc.
In between these larger releases you will see many smaller efforts as well, usually related to sensors, contests, expos, educational partnerships, etc.
We truly appreciate your support in keeping the forums what they are, and feel honored to have your support to keep them somewhat cohesive, not divisive, and on topic. With such contributors it is in our interest to channel their efforts in a positive way that help our customers (past, present and future). I think this thread has provided most of the value at this stage.
I too strongly believe in "the more the merrier", and in this space there is a strong upward trend. That's good for everybody. One data point you all might be interested in:
When I latched onto the Prop, it was near the beginning. We didn't have a lot of docs, other than the "guts" document Chip did, first rev of the manual, and some code moving around. (which actually was the documentation for me in many ways)
Back then, I would talk about it with the general response being, "meh." Who wants to go hardcore with just a CPU, when there are game consoles, computers and such?
Deffo felt like a niche thing, and in some ways it still is, but the times are changing. People are more interested now, and I can link to projects of many kinds on many different platforms that spark interest. This is a really good thing!
It has been my life experience the really killer platforms never see the large share. It has also been my experience that where there is something great, it's kept alive by the people who grok it for what it is. The Prop has a smallish community compared to others, and it's new in a lot of ways requiring some boot-strapping not as necessary for many other devices out there. OBC is always mentioning projects and such, and that's where the growth is at. People who enter this hobby, or who have professional interests, do so on any number of devices. Might be Prop, might be Xmos, Arduino, TI, PIC, you name it. Doesn't matter.
What does matter is they build the skill needed to then select a Prop when it makes sense, and having it makes sense means seeing what Props do and having people to talk to / work with to do them. That is where our small club has and continues to do a good job. If somebody walks in, they generally get a good experience and there is a lot of value added to the Prop because of that. One doesn't just buy a chip. They buy into the community surrounding it.
This is a big part of why Arduino has the share it does. This is also why we are growing Prop mind-share out there too.
There are always tech sweet spots. Cost / capability ratio is really great on some devices, not so great on others. That's all weighted by a given persons experience and interests too. Projects out there help with this big, and the more the merrier. Tools are another big contributor, and we've got great tools now, getting better! Compared to the early days, the choices now are potent, varied, growing, supported. More open now as well, though I personally don't see open as a primary selection criteria. So long as it's open enough, I'm good. Many differ on this, and the general trend seems to be "really open", and we are nearly there.
Props are very interesting devices, and those qualities that differentiate them also put them off the mainstream track. This dynamic is always in play, always will be too.
From where I stand, the single most important thing is whether or not the community surrounding the Prop is enough to move Parallax and the various vendors associated forward. If that's true, we gain and it's all viable. Prop I chips will be available for a very long time. Each new member is worth a lot over that time period too. There will be lots of one-offs, and every so often, somebody more than that. We need 'em all, but we need the "lifer" type users more, because they carry things through over the longer haul.
Retro-computing communities are still thriving on old stuff, and they see enough mind-share to continue to do new things, release software, hardware projects, etc... They all work to capture newbies, not like some dedicated effort, but more like just being open, friendly, fun, sharing, challenging, etc... We've got that here too, and it is a great thing, one that keeps me going personally.
IMHO, we are in a great time right now. Lots of new interest, and general public awareness of our niche is growing nicely right now, reinforced by many things in play economically, politically, and just culturally. The geeks are of age now, and are influencing things just as the boomers did before, and it's our time more than it isn't because of that.
So bring it on! Whatever device gets a person started, great! When they work that one over to it's limits, they will explore another one, or they will find one or the other aligned with their personal interests / product needs. Props are great, and will capture plenty of those as long as the majority of us are good ambassadors to our corner of the hobby.
Ken: Thanks for your words of inspiration. Interesting about the propII - we wait with baited breath
Jon: Magnificent. And I am convinced you are right when it comes to the prop being the ideal micro for your jobs.
Some of the more recent discussion has been a little OT (off topic). However, it tends to reinforce what can be done with the prop. This has been one of the better threads and thankfully did not go the way they usually do. It provides quite a lot of good info for a beginner. Perhaps it deserves a reference in one of the stickies?
Thanks for the help, guys. It's obvious what an experienced person can do with their tools of choice. What some people will do by piling on cogs, others will do by piling on boards. There's no point in debating pros and cons of multi-core vs multi-processor. When you run out of cogs you have to pile on boards anyway. You can do it fastest with whatever you can be productive with fastest.
Propellers are wonderful. I'm not knocking the prop. But one of the key things with any platform and its community is ease of entry. We're living in a time when a lot more young people grew up with technology in hand, and now are starting to explore what THEY can build. Not just here. In India. In China. This market now in the tens of thousands, will be in the millions. I came here looking at the prop, and found specific things that I thought could be done better to make entry smoother. One of them was taking advantage of the momentum of the Arduino interconnect "standards", because it's likely the best way to get more NEW people who can't always build their own hardware to be using the prop. The other was making the software entry easier with very clearly coded examples for readily available hardware. In all the horn blowing and Prop enthusiasm, which I can relate to, I hope these thoughts will not be lost.
Thousands of users with varying degrees of experience who want to build something and who either don't want to, or don't know how to, build a lot of hardware or write a lot of code.
We should take no comfort in the idea that products are being developed by engineers with this mindset. I mean, really, would you want an aircraft safety system designed by a person who doesn't want to be bothered learning electronics or writing code?... And does Arduino sales to the hobbyist world translate to large scale sales of Atmel chips? Probably not; I believe most using Atmel chips for large scale products took a more traditional path. If anything, I think Parallax has erred on counting too much on the hobby world, and not providing the tool chain that professionals -- you know, the kind that can be bothered to learn how to do things correctly -- want to use.
I know I'm stating the obvious here, but the Arduino was not created by Atmel. So if you're really that concerned about Propeller market share, why not create your own Propeller based product that lights up the hobbyist world, that turns the "lazy" into engineers? I'm sure Parallax would be very happy. You seem to have all the solutions -- why not put them to use. If you're right, you might make a nice living for yourself, too.
the Arduino interconnect "standards"
Except for that pesky, non-standard pin spacing on headers which makes prototyping with perf-oard a pain! Sorry... couldn't help myself.
The irony of your last statements.. You created the Propeller Platform standard. A device which has a hobby friendly footprint, allowing people with limited understanding to do amazing things with the Propeller.
I think your statement was harsh. There are many EE's who got their start early on with those Radio Shack, spin-clipped electronics kits. They don't use springs today in their current professional designs, but they certainly started there! Many computer technicians got their start with mere "toys" (Commodore 64, Atari, etc). These stepping stones provided the first-steps to entry in what have become lifetime careers.
I'm proud to be on the front lines of these types of projects. The stepping stones of hobby electronics may well hold the interests of young people who will make technology their professional career later.
The Arduino is a excellent example of software driven success. It's software has allowed artists and other non-technical types to build their own embedded systems with relative ease.
Embedded Artists did as much the same with their ARM based mbed controller, it wasn't so much the hardware as the C compiler suite with a rich set of routines that allowed programmers to get up and running quite fast without having to dig into ARM data books. Without it's elaborate library, the mbed would have been just another eval board.
The mbed is an ARM initiative, and is nothing to do with Embedded Artists. You are probably thinking of the LPCXpresso, which was designed by the latter.
I think your statement was harsh. There are many EE's who got their start early on with those Radio Shack, spin-clipped electronics kits.
I'm one of them! And do you know what I use every day? The PPDB. I can actually develop useful circuits with it before worrying about building a PCB. While I have Demo Boards and QuickStart boards, I only use them as "blinky light show-and-tell" boards'; as a developer I don't want to be restrained by hardware connections made by somebody else.
You're right, I did create the Propeller Platform and as I stated in print, it was inspired the by the Arduino (less the goofy pin spacing). Honestly, I had hoped that Parallax would produce it because I thought that would drive the price down, and combined with BST provided a option for those happy about cross-platform development for the Arduino (which I absolutely support).
I think Ken and Parallax have made some difficult and brave decisions about creating development tools, and while it will be a little rough to start, long term I think it's good for the Propeller and those of us that put it to use in our work. For the record, I do that: while I have fun with the Propeller, a big part of my day-to-day work is designing commercial products (or circuits for products) with it.
I'm one of them! And do you know what I use every day? The PPDB.
Ah, so you developed the PPDB I've seen in Nuts & Volts. But I'm confused, is your name McPhalen or Williams, because I've seen both used in N&V in conjunction with the Propeller and the PPDB?
I developed the original Propeller Platform (all DIP chips for easy assembly) for my column in Nuts & Volts; the Propeller PDB was developed by Parallax after I helped start EFX-TEK (and I'm happy for it; it's my favorite development board). I am in fact the artist formerly known as Jon Williams (still use it for the magazine by-line).
Comments
The HUB memory is actually treated somewhat like an I/O device as far as the cogs are concerned. There are special instructions to fetch and store bytes, words, and long words in the HUB, so it's not mapped at all into the cogs' memory space.
The Spin interpreter is written to use HUB memory for the interpretive code, global variables, and various internal tables used to access the code and variables. There is a stack allocated from the end of the program upwards in HUB memory that is used for the default (or only) cog. The interpretive code is based on a stack machine with local variables allocated in the stack frames for the call chain.
When you start up a new cog to run Spin code, a copy of the Spin interpreter from ROM is loaded into the cog (and occupies essentially all of it). You have to supply a stack area for the new Spin interpreter to use and the current cog's Spin interpreter passes a set of pointers to the new Spin interpreter that enable it to start interpreting at the proper place in your program. The description of the COGNEW and COGINIT statements in Spin is pretty complete.
As far as Spin is concerned, memory is a monolithic block of 32K bytes containing the program, variable areas, and stack space. It is possible to generate the address of the current end of stack and some programs will dynamically allocate space starting at the end of memory downwards or at some minimum number of bytes past the end of the stack upwards. There are a few objects in the Object Exchange that will do that for you, but it's usually easier to do it yourself.
Assembly is just a block of constant information compiled into the object program that happens to be written using the assembly language. A variant of COGNEW and COGINIT copies 512 longs beginning at the specified address. It's assumed that the first long is the first instruction to be executed. If the code is less than 512 longs, whatever follows in HUB memory is copied (usually Spin interpretive code). It shouldn't matter what's in that area as far as the cog is concerned.
The Spin compiler is smart enough to figure out if the same object is being included multiple times in one or more places in the program. In that case, only one instance of the interpretive code (and any constant areas) is included. Each instance has its own set of unique global variables. If you use an object like FullDuplexSerial that implements a full-duplex serial device and you need more than one instance, you'll have only one copy of the code, but each instance will have its own buffer areas (part of its global variables).
PASM code runs in the cogs local memory. There are PASM instructions (RDLONG/WRLONG/etc.) that allow a cog to read from the hub memory (during one of those access cycles mentioned above).
When you boot up the Propeller, a cog is loaded up with the PASM code that is the interpreter, and then that is given the address in hub memory to start reading the spin code from. The first PUB function in your spin file is what will be run. All of your local and global variables in Spin are located in shared hub memory. For the initial boot up Spin code the stack is handled for you.
Additionally there are Spin commands (COGNEW or COGINIT) that can be used to start another cog with either Spin or PASM code.
In the Spin case, the interpreter is loaded up into the new cog and given the address of the spin function you passed into COGNEW or COGINIT. You also need to define a global variable to be stack space for this new instance of the spin interpreter and pass the address into COGNEW or COGINIT.
In the PASM case, you pass in the address of a block of PASM code (defined in a DAT block), and a single long user parameter. The new cog gets loaded up with this block of PASM code, the PAR register initialized to the value of the user parameter, and the cog starts running the PASM code starting at long 0 in it's local memory. This code can do whatever it wants to with the local cog memory via PASM instructions, and it can access hub shared memory using RDLONG/WRLONG/etc. How you choose to use the local or shared memory is up to you in this case.
Note: a cog can not access the local memory of another cog directly. Each cog can only access it's own memory and hub memory. You can write code in different cogs that coordinate with eachother to copy their memory back and for via the shared hub memory if you want.
Roy
p.s. and, of course, while I was typing this, Mike Green posted a better explaination, but I'll leave this here in case it helps.
Within an hour or two, I had worked through all the examples that came with the PropTool. That gave me the best insight into the prop and how it basically works. My first program was a few lines of code (less than 10) and I had a led flashing just by pushing it into the holes on the ProtoBoard to use the existing 10K pullups on the PS2 port!
My experience on the AVR (ATtiny84) was not so great... It took me days to understand how the compiler ran and get a led flashing. Why so long - I said above, I was programming it with a new ISP programmer that I wrote using the prop and thought my timing must be wrong. Eventually I discovered the "C delay routine" in the AVR compiler was not working!!! I replaced it with a simple counting loop and my LED flashed. Talk about a bad experience!
I digressed, so back to Ken's point. I use the prop professionally. I am not interested in an Arduino style reference platform and what the hobbyists can do with it. I am interested in what I can do with it. I design my own pcbs for what I require. This is no biggie for a professional user. Just buy a demo pcb and try a few things, then build your own circuit.
Fernand: Memory model...
Firstly, forget about adding memory for now as that is not for beginners. With your professional background you will get there quickly, but you need to understand the basics. I suggest you do the 10? examples that come with the PropTool as they build up quickly to multicore processing.
There is 64KB of hub memory and each cog can access this by byte, word or long using the rdxxxx and wrxxxx (pasm) instructions. The upper 32KB is ROM and contains a copy of the booter and spin interpreter, log and sin tables, and a 16x16 IIRC font (I haven't used any of it - well we all actually use the booter and interpreter, but not directly). The lower 32KB is SRAM. When you boot the prop it checks to see if a download is being attempted on P31/P30 serial (and its not true serial because it is using the internal RC oscillator so timing is not accurate). If so, then some of the 32KB hub SRAM will be loaded, depending on the hex file downloaded. Not sure what happens to the remainder. If not, then the prop tests for the EEPROM on P29/P28 via I2C. If found, a whole 32KB block is downloaded from eeprom to the whole 32KB hub SRAM. If neither, the prop shuts down.
Once the hub SRAM is loaded, the spin interpreter is loaded into COG 0 memory (496 longs) from the hub ROM. The prop begins executing the spin interpreter using the downloaded hub SRAM for the spin byte code. Stack space and variables (local and global) are all located in hub SRAM.
So you have...
- Hub space 64KB (accessible and shared by all cogs)
- lower 32KB SRAM
- upper 32KB ROM
- Cog space 8 @ 2KB SRAM for each of 8 cogs, 0-7
- Makes 496 longs of 32b SRAM
- 16 longs at top of COG ram for registers
- Shadow SRAM overlay the 16 registers (for advanced users only - many restrictions)
- Each set of 16 registers is specific to the cog
- All I/O pins are accessible by each cog - users responsibility to ensure no conflicts
- If more than one cog makes a pin an output, then the pins are simply or'ed together, so a 1 overrides a 0 (so no hardware conflict)
- The CNT register is global and read only, so all cogs have access to this 32b counter which increments on every clock (~90s wraparound) and can be used for all sorts of synchronising.
Spin vs PASM...- Each cog can run either spin or pasm, but not both.
- Actually, the spin cog is running pasm which is the spin interpreter, but it fills the whole 496 longs of cog space.
- Cog pasm code runs in the cog space and may have its variables in cog or hub or both.
Cogs accessing hub...- Each cog is given a round-robbin time slice at hub access (by using the rdxxxx/wrxxx pasm instructions)
- It takes a total of 16 clocks to make 1 revolution of access
- Cog 0 gets access on clock 0
- Cog 1 gets access on clock 0+2 = 2
- etc
- If a cog does not require access, the slot is wasted (it does not move on)
- If a cog requires access before its slot, it will stall until its turn. This is why rdxxxx/wrxxxx have a variable access time
External memory...- There is no defined mechanism as the address and data bus cannot be brought out to the pins.
- A number of us have added external memory in various ways and provided access drivers for this.
- This is for advanced users, although some programs can access this (ZiCog, Catalina, GCC)
I hope this clears up a few details for you Fernand.Postedit: I see others have also jumped in here too. The more explanations I guess the better understanding.
Just for the record, while everything says that 512 longs are loaded from hub to cog to start a cog, I believe that only 496 are actually loaded because the registers are not loaded, but are cleared. And I think the shadow ram is not loaded either.
I'll apologize for coming across that way. I think part of it is that you've come here and posted along the lines of, "it *should* be this way, or they ought to do that, and this thing is ***-backwards compared to X...' kind of thing. We've seen our share of Prop bashing (and other chip bashing too), and it gets old. Once you've done that a few times you're more likely to get snarky responses than helpful ones.
It's also that many the questions you're asking kind of answer themselves fairly quickly if you use it a little. By working through a few of the simple examples in the Prop help section you'll figure out the difference between launching SPIN or ASM in its own cog, among other things. The examples Cluso mentions are exactly how I started as well. They're small, but they hit a decent amount of what you're asking.
As for the memory layout, take a look at the image on the bottom of this page: http://www.parallax.com/PropellerChips/tabid/833/Default.aspx
It shows the (very high level) layout of the RAM, ROM, and cog memory, and shows that the cogs have access to RAM/ROM via the hub. The Propeller data sheet includes this image as well, and on page 7 explains quite clearly how the cogs and hub work together. (sections 4.3 and 4.4). Section 5.0 is memory organization.
So the information is there, and very easily and quickly obtained, which is probably why you got the RTFM response - we assume that you'd know the answers to these things if you've done some fairly cursory reading. (I'm sorry if that came across as snarky or antagonistic - I don't mean it in that way). Most of the forum members here are happy (almost eager) to help if you have questions, but many of those same people have a distaste for "I haven't done my homework, and can't be bothered with Google, can you do my homework for me?" If your question comes across in that way, it might be met with an RTFM response.
The shorter version: You should read through the datasheet or Chapter 1 of the Propeller manual, which is very similar in content (both available here: http://www.parallax.com/PropellerDownloads/tabid/832/Default.aspx). A lot of the questions you're asking will be at least partially answered by those. Whatever's left over we'll be happy to fill in.
I apologize if I came across snarky. I thought maybe you hadn't heard enough of the "initial reaction", but I guess you have ;-)
The amount of compatible hardware for Arduino
http://shieldlist.org/
is so impressive it's a bit hard to understand reinventing the interconnect wheel. Anyway, sorry if you've heard it all before and thanks.
I'm pleased that you weren't here to simply "prop bash"... You seem to have invested yourself in figuring out which end is up. You've already caught the attention of a few of our brighter bulbs here (Mike Green, Jason, Cluso,Roy, and the like) who we are lucky to have around.
Nick and I (Gadget Gangster) are working on additional modules (shields) for the Propeller Platform. There are a number of good things happening in that regard which I can't yet talk about.
Welcome aboard!
Jeff/OBC
Thanks, Jeff! It's raining really hard here, and I need to go see if the humidity is whacking the harpsichord out of tune.
(footnote) I nonetheless implore y'all to work towards merging with the Arduino community by favoring common pinouts and hardware and software similarities wherever possible. I see the lovely offerings at Gadget Gangster and the ASC, and I see all the Arduino shields, and "why can't we all just CMOS along" ... ;-)
kumbuyah
Since there are two counters per cog, can I have two PWM outs per cog, and just do it the same bonehead way but use a cog for every pair of PWM outputs, so for one RGB LED, just use both counter in my main gog, and just spawn another cog and keep passing it the value for the remaining single PWM output I need? So what's the simple way to pass data from my main cog to the secondary?
But yes, start another cog for the next two counters. You will set the value in a hub variable, and the cog will just read this variable each time it goes to check on what value to set the pwms to.
Perhaps one of the RGB led threads or an object may give you some examples. Alternately, checkout the Quadcopter thread in the builders forum and look at the code there (Jason's or my variant of Jason's code). We pass variables via hub there between cogs.
Though Steve didn't put it to use I even added an SIRCS (Sony IR control) cog so that the lighting elements could be controlled with a TV remote.
Here's two projects we did in 2011:
This one is for the game, Firefall. It has two characters that use the same controller setup I used in Jim Raynor. They have a sensor channel input that tells them when to start their animation sequence so that it is coordinated with the big prop (the "thumper") in the display.
This is Tyreal from Diablo 3 (yes, the movie business is slow right now but the gaming industry is booming). We didn't need a lot of channels for this project but we did need a lot of current so I took a different approach: I used the Propeller as a custom DMX master that would send lighting control levels to off-the-shelf DMX "bricks" (each had four outputs at 5A each). For this project we had three 12V, 25A power supplies. Each tendril had six to eight segments so they would shimmer and then do an "energy burst" animation from time-to-time.
Now let me step onto my soapbox: I *might* have been able to do these projects with an Arduino, but I know it would have been a nightmare. Steve likes to be very fluid with the lighting control and animation and by using Spin (and especially by separating lighting sections into their own cogs) I can update the animations to Steve's and the client's desires nearly as fast as they can explain what they want.
Old habits are hard to break.. (referring to the BBS computer wars of the 80's) The Propeller community is slowly coming around to a sense of inter-connectivity with projects like C for the Propeller, several open source Propeller products, and hardware compatibility. You should have seen the discussion that happened here last year when I suggested an Open Source Design Contest.
We're getting there,,..
OBC
I KNEW IT! LEDs are still cool!!
Any chance you can get your hands on one of those suits for display at the Parallax Expo this year?
OBC
And in case it's not clear, the images above have no live humans in them: those people are not flesh and blood, they are silicone and fiberglass. They are amazingly lifelike; each has "real" glass eyes, hand painted skin, and thousands of hand-punched hairs.
What I love about my life in Hollywood is working with great artists on both sides of the camera. I have also used the Propeller for a commercial pan and tilt controller, and a focus/zoom controller. For my own projects I'm converting my SX-based intervalometer (time-lapse controller) to the Propeller.
I don't want to derail this thread: it was going down a path that multiple cogs with the counters are required to control an RGB LED. As can be seen in the Jim Raynor image, I'm controlling two RGB LEDs (independently, so that each engine has its own "rumble" effect) as well as four channels on the chest and a final (not seen in the image) channel for the face. The LED brightness control (accumulator-divider style PWM) for 12 channels is handled by one PASM cog.
Those coming from the Arduino mindset may first resort to hardware peripherals; those of us from the SX and Propeller world enjoy virtualizing and having exactly the control we need.
We have a company here, Display Electronics, that specialises in electronic junk:
http://www.distel.co.uk/
They have a lucrative sideline building electronic props for TV programs and films. They built their own CNC milling machine for making PCBs etc. and made their own injection moulder. They made the control panels for most of the Bond films. They even bought a crashed fighter jet, and have it in their yard, in case it comes in useful one day! I've known Dave Fisher, who owns the company, for many years.
The first image did look weird, but the others looked like real actors.. You guys over there are amazing..
OBC
The Arduino has served to expand the electronics audience and that's a very positive contribution for the business in total. Parallax benefits by selling our sensors and related products to Arduino customers, too. All of the comparisons have been made with the Propeller, and for whatever use they may be I'm not sure, but at this stage we can move back to regular programming.
From my point of view what lies ahead for Parallax customers is truly exciting. Parallax's effort and results come in large steps. Customers sometimes think we've even gone dormant, but we're only preparing for the next phase of innovation. Many of you have been with us since the early 90s, and might own our PIC tools, SX chips, BASIC Stamp 1, or perhaps even an ISEPIC or SoundAce. This history is an important indicator of what lies ahead for our customers.
We build on prior experiences to move forward. In the near term you will be part of:
- PropGCC compiler beta for Propeller 1, with preparations and groundwork being made for Propeller 2
- open-sourcing of the Propeller compiler in C/C++, enabling many requests to be addressed
- Propeller 2 test chip and release [received an encouraging message from Chip this morning, but don't ask for specifics please]
- learn.parallax.com, where all customers will choose PBASIC, Spin, ASM or C and be able to run all of our demos more easily from the web
- Parallax Semiconductor to publish additional application notes and hardware reference designs
- hardware additions, such as the Propeller BOE, Spinneret 2, etc.
In between these larger releases you will see many smaller efforts as well, usually related to sensors, contests, expos, educational partnerships, etc.
We truly appreciate your support in keeping the forums what they are, and feel honored to have your support to keep them somewhat cohesive, not divisive, and on topic. With such contributors it is in our interest to channel their efforts in a positive way that help our customers (past, present and future). I think this thread has provided most of the value at this stage.
Sincerely,
Ken Gracey
Re: Others.
I too strongly believe in "the more the merrier", and in this space there is a strong upward trend. That's good for everybody. One data point you all might be interested in:
When I latched onto the Prop, it was near the beginning. We didn't have a lot of docs, other than the "guts" document Chip did, first rev of the manual, and some code moving around. (which actually was the documentation for me in many ways)
Back then, I would talk about it with the general response being, "meh." Who wants to go hardcore with just a CPU, when there are game consoles, computers and such?
Deffo felt like a niche thing, and in some ways it still is, but the times are changing. People are more interested now, and I can link to projects of many kinds on many different platforms that spark interest. This is a really good thing!
It has been my life experience the really killer platforms never see the large share. It has also been my experience that where there is something great, it's kept alive by the people who grok it for what it is. The Prop has a smallish community compared to others, and it's new in a lot of ways requiring some boot-strapping not as necessary for many other devices out there. OBC is always mentioning projects and such, and that's where the growth is at. People who enter this hobby, or who have professional interests, do so on any number of devices. Might be Prop, might be Xmos, Arduino, TI, PIC, you name it. Doesn't matter.
What does matter is they build the skill needed to then select a Prop when it makes sense, and having it makes sense means seeing what Props do and having people to talk to / work with to do them. That is where our small club has and continues to do a good job. If somebody walks in, they generally get a good experience and there is a lot of value added to the Prop because of that. One doesn't just buy a chip. They buy into the community surrounding it.
This is a big part of why Arduino has the share it does. This is also why we are growing Prop mind-share out there too.
There are always tech sweet spots. Cost / capability ratio is really great on some devices, not so great on others. That's all weighted by a given persons experience and interests too. Projects out there help with this big, and the more the merrier. Tools are another big contributor, and we've got great tools now, getting better! Compared to the early days, the choices now are potent, varied, growing, supported. More open now as well, though I personally don't see open as a primary selection criteria. So long as it's open enough, I'm good. Many differ on this, and the general trend seems to be "really open", and we are nearly there.
Props are very interesting devices, and those qualities that differentiate them also put them off the mainstream track. This dynamic is always in play, always will be too.
From where I stand, the single most important thing is whether or not the community surrounding the Prop is enough to move Parallax and the various vendors associated forward. If that's true, we gain and it's all viable. Prop I chips will be available for a very long time. Each new member is worth a lot over that time period too. There will be lots of one-offs, and every so often, somebody more than that. We need 'em all, but we need the "lifer" type users more, because they carry things through over the longer haul.
Retro-computing communities are still thriving on old stuff, and they see enough mind-share to continue to do new things, release software, hardware projects, etc... They all work to capture newbies, not like some dedicated effort, but more like just being open, friendly, fun, sharing, challenging, etc... We've got that here too, and it is a great thing, one that keeps me going personally.
IMHO, we are in a great time right now. Lots of new interest, and general public awareness of our niche is growing nicely right now, reinforced by many things in play economically, politically, and just culturally. The geeks are of age now, and are influencing things just as the boomers did before, and it's our time more than it isn't because of that.
So bring it on! Whatever device gets a person started, great! When they work that one over to it's limits, they will explore another one, or they will find one or the other aligned with their personal interests / product needs. Props are great, and will capture plenty of those as long as the majority of us are good ambassadors to our corner of the hobby.
Jon: Magnificent. And I am convinced you are right when it comes to the prop being the ideal micro for your jobs.
Some of the more recent discussion has been a little OT (off topic). However, it tends to reinforce what can be done with the prop. This has been one of the better threads and thankfully did not go the way they usually do. It provides quite a lot of good info for a beginner. Perhaps it deserves a reference in one of the stickies?
Propellers are wonderful. I'm not knocking the prop. But one of the key things with any platform and its community is ease of entry. We're living in a time when a lot more young people grew up with technology in hand, and now are starting to explore what THEY can build. Not just here. In India. In China. This market now in the tens of thousands, will be in the millions. I came here looking at the prop, and found specific things that I thought could be done better to make entry smoother. One of them was taking advantage of the momentum of the Arduino interconnect "standards", because it's likely the best way to get more NEW people who can't always build their own hardware to be using the prop. The other was making the software entry easier with very clearly coded examples for readily available hardware. In all the horn blowing and Prop enthusiasm, which I can relate to, I hope these thoughts will not be lost.
We should take no comfort in the idea that products are being developed by engineers with this mindset. I mean, really, would you want an aircraft safety system designed by a person who doesn't want to be bothered learning electronics or writing code?... And does Arduino sales to the hobbyist world translate to large scale sales of Atmel chips? Probably not; I believe most using Atmel chips for large scale products took a more traditional path. If anything, I think Parallax has erred on counting too much on the hobby world, and not providing the tool chain that professionals -- you know, the kind that can be bothered to learn how to do things correctly -- want to use.
I know I'm stating the obvious here, but the Arduino was not created by Atmel. So if you're really that concerned about Propeller market share, why not create your own Propeller based product that lights up the hobbyist world, that turns the "lazy" into engineers?
Except for that pesky, non-standard pin spacing on headers which makes prototyping with perf-oard a pain! Sorry... couldn't help myself.
The irony of your last statements.. You created the Propeller Platform standard. A device which has a hobby friendly footprint, allowing people with limited understanding to do amazing things with the Propeller.
I think your statement was harsh. There are many EE's who got their start early on with those Radio Shack, spin-clipped electronics kits. They don't use springs today in their current professional designs, but they certainly started there! Many computer technicians got their start with mere "toys" (Commodore 64, Atari, etc). These stepping stones provided the first-steps to entry in what have become lifetime careers.
I'm proud to be on the front lines of these types of projects. The stepping stones of hobby electronics may well hold the interests of young people who will make technology their professional career later.
OBC
Embedded Artists did as much the same with their ARM based mbed controller, it wasn't so much the hardware as the C compiler suite with a rich set of routines that allowed programmers to get up and running quite fast without having to dig into ARM data books. Without it's elaborate library, the mbed would have been just another eval board.
I'm one of them! And do you know what I use every day? The PPDB. I can actually develop useful circuits with it before worrying about building a PCB. While I have Demo Boards and QuickStart boards, I only use them as "blinky light show-and-tell" boards'; as a developer I don't want to be restrained by hardware connections made by somebody else.
You're right, I did create the Propeller Platform and as I stated in print, it was inspired the by the Arduino (less the goofy pin spacing). Honestly, I had hoped that Parallax would produce it because I thought that would drive the price down, and combined with BST provided a option for those happy about cross-platform development for the Arduino (which I absolutely support).
I think Ken and Parallax have made some difficult and brave decisions about creating development tools, and while it will be a little rough to start, long term I think it's good for the Propeller and those of us that put it to use in our work. For the record, I do that: while I have fun with the Propeller, a big part of my day-to-day work is designing commercial products (or circuits for products) with it.
Ah, so you developed the PPDB I've seen in Nuts & Volts. But I'm confused, is your name McPhalen or Williams, because I've seen both used in N&V in conjunction with the Propeller and the PPDB?
Well, at least you don't use a weird looking symbol instead of a name! ;-)