Welcome to the forums Fernand!
I'm a big fan of the Propeller because I like to break complex problems into simple pieces. The Propeller's architecture allows me to build one piece at a time and ensures that I won't have integration problems later, even when I do high speed things like video capture and analysis. Parallax is a great company that cares about it's customers, this forum is a wonderful resource to resolving problems.
Hanno
ps- Yes, to view/graph/change variable values you just need to reference ViewPort's "conduit" object to your spin file and call the "share" function with the location of your variables. You can provide additional configuration strings or use the graphical interface to choose which channels to display, how to graph them, timescale, etc... Best way to start is to try some of the tutorial files. Sounds like ViewPort is sharing your data but you're not seeing data in the graph because you didn't click the "plot" button.
Thanks, Hanno, but the problem's not that. What I'm having is the config keeps setting my channels to V1 and io, which come from a previous compile. And I can't change it. I modified an existing Tutorial that was working to use my own variables, the QS is now showing pins, as it was in the Tutorial file, but it's not changing the variables as per my changes. If I start from scratch, nothing works at all, it seems to be following a null config. I thought it was permissions, but I'm now running ViewPort 4.6.2. (as 4.6.7 was not setting breakpoints) as admin. My code is being saved in the same directory I took the 90_My first Program sample from that I've been modifying.
Now it's suddenly decided variable V1 is an unsigned 16 bit int.
Hanno, if I can just get ViewPort working, I think I can manage with all the specifics of the Propeller. But I need a working debugger. I've left posts on your BBS with no response.
Hi Fernand,
I'm an old-fashioned troubleshooter, easiest for me is to call you to resolve your issue...
Once we've fixed the issue I'll post a write-up of the problem and solution here.
Let's return to the Arduino vs. Prop discussion How about them Prop counters? Check out Phil's color NTSC capture using 3 counters!
Hanno
Interrupts are hell on new programmers which is why the Propeller doesn't have them.
Ah, that old chestnut again. I suppose that hardware stacks are hell too because the Prop doesn't have them? Seems to me that people on this forum conveniently turn every missing feature of the Prop into a so-called advantage. My favorite was the guy who said, a few months ago, that the lack of a debug interface (such as J-TAG) was a feature because debuggers rot your brain and turn you into an inferior programmer (or something to that effect).
I don't regard not having interrupts as a "missing feature" of the Propeller. I do regard having 8 cores as an alternative way of acheiving what 8 interrupt inputs would do. With the advantage over interrupts that having cores handle your events ensures that those events cannot upset the timing of each other or anything going on in your "main line".
Multiple cores is an alternative solution to the problem that interrupts were invented to solve. They are logically equivalent but multiple cores removes the burden of having to worry about how different parts of your program will interact timing wise.
That's certainly one way to look at it, and quite valid, of course. I just find it a little upsetting from an efficiency standpoint: devoting an entire 32-bit processor to handling a serial port or an I2C interface or whatever. Seems like a waste of resources.
Sometimes I have that feeling as well. However having multiple programmable cores instead of a single cpu and dedicated silicon for peripheral devices results in enormous flexibilty. I don't have to search around for that particular PIC or AVR or whatever that has just the right combination of peripherals for the job at hand. I just reach into my box of Propellers and configure one how I want it.
From an efficiency standpoint, remember that a cog that's not being used takes virtually no power. The same is true of a cog that's waiting for an I/O pin or pins to change state (WAITPNE or WAITPEQ) or that's waiting for a future time to occur (WAITCNT). The primary resource that a cog takes is silicon area. If you look at the picture of the chip (here), you'd see that the hub's memory and common functions take up almost as much space as the 8 cogs, so leaving one cog unused maybe leaves 7% of the chip area idle. For a lot of PIC chips with plenty of unique functional blocks on the chip (like UARTs, timers, etc.), unused functional blocks similarly occupy silicon area. You may try to choose a specific PIC variant that has only what you need for your project, but that combination may not be available. Part of the architecture of the Propeller is its use of cogs to provide software-defined peripherals.
Curious, the only thing the prop can't do is hardware breakpoints.
I was thinking, every COG can sniff on hub memory and the state of the inputs/outputs.
What you don't have access to is COG ram and counters.
If you write your program to store the variables you want to monitor in the VAR section, you can implement a debugger in one COG. You simply tell it to dump a memory location.
With a modified SPIN interpreter you could then single step by having the SPIN interpreter look for state in a share register or memory. Consider using 1 I/O pin for a gate for stepping, have the SPIN COG monitor that pin and do a reset once the instruction is executed. The other COG reads HUB variables and does a set of the pin after confirming it was reset.
With a modified SPIN interpreter you could then single step by having the SPIN interpreter look for state in a share register or memory. Consider using 1 I/O pin for a gate for stepping, have the SPIN COG monitor that pin and do a reset once the instruction is executed. The other COG reads HUB variables and does a set of the pin after confirming it was reset.
I used a communications stub in the interpreter and a monitor cog in my old Spin debugger. The debugger "SPUD" can single step, step over functions, step out of functions, run to a break-point, show current line, and allow examining any hub address. Printing cog register states is not supported. Every now and then the debugger loses track of the stack - I eventually lost interest and abandoned the project. The C code is very ugly
The code is buried in the forum here. There are some bugs. Some Spin operators are disabled to make room for the debugger stub. YMMV.
I don't think the the statement "Interrupts are hell on new programmers which is why the Propeller doesn't have them." is correct.
I think it's better to say that the Propeller is architected in such a way that it doesn't need or use interrupts. You can do the same sorts of things you might use an interrupt for on the propeller in simpler ways.
Quite right Roy! You don't need interrupts and all the problems that go with them. However, it takes a little while to realise this.
I like having my parts on hand. I could not afford to have every AVR or every PIC on hand just in case it was that version with the widget interface that I required.
And a cog is not wasted for a UART function because that cog can do so much more. Or take the 4port UART object in 1 cog. We never have to worry about all those registers to configure like the other chips. We just pull in an object and there we go. No uart registers! Now, before someone corrects me, yes, there are a few registers like the vga registers or thecounter registers. But these are not low-level registers.
And mostly, we can use whatever pins we like (vga is relegated to a block of 8 and tv to a block of 4). So, in a layout, you can mostly put the interfaces on any pins. Of course, the downside is that boards do tend to move some of these pins around because we don't stick to a standard. I am always trying to squeeze props into boards that don't fit, so I change the pins to suit the pcb. At least I can do that and I don't have to worry that if I use a uart then the i2c wont work because it shares the I/O pins.
Anyway, Jazzed gave a link to the group board done by tubular. My CpuBlade is on the panel and I also sell it separately. It is a 1"sq pcb with propeller, eeprom, pluggable xtal (I usually overclock to 104MHz using a 6.5MHz xtal) and has a 3v3 regulator and an optional transistor reset cct. All I/O pins are brought out. It requires 5V regulated (like from a USB type source). Writeup is at www.clusos.com and here http://forums.parallax.com/showthread.php?134134-Cluso-s-new-Propeller-stackable-and-pluggable-boards-(MultiProps-too) (posts 16 & 18 and a pic in post 12 top left of the pics)
I like having my parts on hand. I could not afford to have every AVR or every PIC on hand just in case it was that version with the widget interface that I required.
What if you need Ethernet or USB, like some of the more recent PICs and AVRs support? How do you implement that on a Propeller cog?
JLT7: I am not going to say that everything can be done with a prop. USB has been done but it does use a lot of resources and is not compliant. This depends on the app. But you certainly cannot compare the whole range with 1 prop but you can compare 1 prop with a lot of the family!
Well, can't complain about the teamwork here. Hanno called me and we got to a point where I DO have a working debugger.
Way to go. Now I just have to get some better hardware than the Quickstart.
Just finished talking with Fernand, sounded like we're making progress.
See here for a screenshot of the ViewPort debugger, it basically offers you what you get with Visual Studio: step modes, breakpoint, memory map, IO pins, edit variables, command interpreter, terminal, profiler, call stack...
Multiple cores is an alternative solution to the problem that interrupts were invented to solve. They are logically equivalent but multiple cores removes the burden of having to worry about how different parts of your program will interact timing wise.
Seems to me it's pretty much the same issues you have to deal with either way. If multiple cores or interrupts are working on shared data, you cannot avoid the burden. Once you're dealing with shared data structures beyond a single long you have to understand concurrency issues, locking and semaphores. In fact, the Interrupt on a single CPU is much easier in many ways, as you can be sure only one stream of code is executing at any time. And whether an interrupt is affecting your timing or not depends on who's doing the looking. The code handling the interrupt is very happy to have a (relatively) predictable response time relative to an external event. And what it's not predictable by is say a disabling of the interrupt to ensure data integrity, which you have to do on either platform. On very simple projects the 8 core multiprocessor approach might seem clearer, but as soon as there's some complexity, seems to me it's the same old stuff, with obscure bugs due to race conditions, data contention, and all the goodies.
Anyway .. i came here because I'm hoping that the concept of a standardized hardware platform takes hold. Speaking of the 8 cog modularity, what we need is hardware building block modularity. People who make their own boards don't need that, but it would be very healthy for the Propeller's marketplace "footprint" for the boardmakers to arrive at a sort of standard that could just drop in with existing Arduino shields, with A/D on the same pins, etc. THEN the big Arduino user community has an upgrade path.
Question, not sure where to even look: how do I simulate an analog out on a Prop pin with PWM, the way on the Arduino you do a
analogWrite(AnalogOutPin, Brightnessb)
Thanks!
p.s. I started on a controller for those RGB LED arrays, and it was so easy on the Arduino, that a likely sense of guilt carried me upwind to the Propeller.
But if this uses one of the two Propeller counters, are you limited to one concurrent PWM output using ctra, and then you have to have a separate analogWrite using ctrb, and 2 "analog" outputs is all she wrote ? I can't even control one RGB type LED?
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.
A good way to think of it is that many microcontrollers have dedicated hardware for lots of stuff, but only one main thread. The Propeller has many threads, but very few dedicated hardware peripherals. That's by design - The intention is that you can create the things you need in software on other cores, and many of the objects do tasks normally done by hardware on other chips, but they're not wasting silicon if you aren't using them.
Seems to me it's pretty much the same issues you have to deal with either way. If multiple cores or interrupts are working on shared data, you cannot avoid the burden. Once you're dealing with shared data structures beyond a single long you have to understand concurrency issues, locking and semaphores. In fact, the Interrupt on a single CPU is much easier in many ways, as you can be sure only one stream of code is executing at any time.
Actually mutual exclusion between threads is not the "burden" I was thinking of. Rather this simple thing:
I have process A running doing something quite time critical. Perhaps A is my entire program with multiple threads of execution going on.
Now I want to add another time critical function B.
If I only have one CPU I have to hook B into an interrupt system or thread scheduler. I have to understand the timing requirements of B and all the other activities in A so that I can figure out if I actually have time to do all of A and B combined. If there is time I have to assign priorities to my interrupts/threads so that everything works out OK. It's notoriously hard to be 100% sure that such a system is always reliable.
However if I have another core on which to run my new functionality B I can just build B into my program and use it without having to know anything about it's timing requirements and with out having to know all about the timing requirements of all the other objects in my code, which I may not have written.
So we see that having multiple cores instead of a single core and interrupts makes life a lot easier when integrating components.
Given that the philosophy of the Prop is to offer the flexibility of implementing peripheral in software rather than dedicated silicon this is very important.
As for the mutual exclusion problems, they will exist wherever you have multiple threads sharing data in memory no matter if it's threads derived from interrupts or actual parallel processing. The Prop offers locks to enable such mutual exclusion but it turns out that in the vast majority of cases they are not required to be used.
Thanks, Jason, I understand. I was imagining such a software solution, and then I found some OBJects that can do it or illustrate how. But I guess some things, like A/D, are better done in hardware. For all those Cogs, it's not a lot of RAM in the chip, and it sure would have been nice to have internal EEPROM for code to keep parts count down. But, yes, I can see the intent. Thanks.
I have process A running doing something quite time critical. Perhaps A is my entire program with multiple threads of execution going on.
Now I want to add another time critical function B.
If I only have one CPU I have to hook B into an interrupt system or thread scheduler. I have to understand the timing requirements of B and all the other activities in A so that I can figure out if I actually have time to do all of A and B combined.
I dunno, it's not all that difficult, if you plan ahead, say FORTH-like systems can switch context on every operator return, the NEXT if you will, and it's not very different from a multi-processor system, just a bit slower. To me the race conditions and data access contention are more subtle and tricky. But for retrofitting additional very time-sensitive functions, no question that having spare cogs can be very handy. But I haven't studied the Prop in sufficient detail yet, specifically the interpreter and the Hub. Where can I read about how these work? I thought I read that a cog is dedicated to the interpreter, so where is machine code buffered and when? Are there then really 7 available cogs or 9 total?
But I guess some things, like A/D, are better done in hardware.
Not always. With the Arduino you're stuck with the A2D capabilities it has, on the pins that they're assigned to -- with the Propeller I can decide (by selecting an appropriate A2D chip). Same with serial IO in terms of flexilitly.
There will always be a problem comparing the Arduino to the Propeller; it's like comparing a street car to a Forumula 1 car. Yeah, they're both cars; the street car is more comfortable and "easier" to handle, but doesn't offer a skilled driver the same performance as a racing car. Some of us like racing cars.
By the way, the actor in me -- that enjoys watching human behavior -- finds it fascinating that you want the simplicity and ease of the Arduino and yet refer to interrupts as "not at all difficult." In the hands of a skilled programmer, I agree. That said, I will take multiple cogs over interrupts any day; I'm way past having to re-code interrupts to add a feature to a product and don't ever want to do it again.
But I haven't studied the Prop in sufficient detail yet
And yet, this has not stopped you from criticizing its design....
Are there then really 7 available cogs or 9 total?
There are eight total cogs. On power-up, Cog 0 is loaded with the Spin interpreter and runs your program. That program could be as simple as launching another cog (PASM) and then shutting down cog 0. What I find fun for things that are not super timing sensitive is that you can launch another Spin interpreter and it can share Spin methods with the other Spin cogs (it can because Spin code lives in and is executed from the hub).
Here's an example of something I do from time-to-time: I can setup an array of rtc-type variables in the hub and then launch this method into its own cog. The beauty of waitcnt is that the code executes at a specific interval; and yes, Spin is fast enough to run this loop in under 1ms.
pri rtc | t ' start with cognew
'' Simple timer/rtc
'' -- runs in separate Spin cog
t := cnt
repeat
waitcnt(t += MS_001) ' update every millisecond
ms := ++ms // 1000
if (ms == 0)
scs := ++scs // 60
if (scs == 0)
mns := ++mns // 60
if (mns == 0)
hrs := ++hrs // 24
if (hrs == 0)
day := ++ day // 7
In many applications I will launch a secondary Spin cog to show me the state of critical variables (poor man's debugger). Unless there's a code crunch I just leave this in -- which has come in handy. One customer with a DMX application wanted to see the raw stream values. I showed him how to connect a Prop-Plug to his device and bingo, it was there.
The Propeller is not perfect, but I think when you give it a chance -- unburdened by your desire to make it work like other devices -- you'll find it is quite useful and a joy in may respects.
Being in this forum I evidently like the propeller, and I would like to share the reasons I like it. It is a little bit off topic, because the "vs" is missing, but I would like to tell my positive experience.
Besides the forum, and a lot of incredibly skilled people, the possibility to use the obex is a great value.
Some objects are good, others not, but if you spend a little bit of time you'll find you can exploit other's work with little effort.
Being a poor programmer I usually have the main, slow, crappy loop I badly coded in a cog, and quality code from the obex in the spare COGS.
As an example at a price of a COG you can have float, SD card/FAT handling, 4 serial ports with buffer (4 ports in 1 cog!!), VGA, video, servo control over 32 pins and at a price of an extra cog also ramping, and many other nice things.
I have not the skills neither to code nor to understand the mentioned objects, but at no cost they are available, and I can use some/many of them at the same time, even with my limited skills...
Curious, the only thing the prop can't do is hardware breakpoints.
I was thinking, every COG can sniff on hub memory and the state of the inputs/outputs.
What you don't have access to is COG ram and counters.
If you write your program to store the variables you want to monitor in the VAR section, you can implement a debugger in one COG. You simply tell it to dump a memory location.
With a modified SPIN interpreter you could then single step by having the SPIN interpreter look for state in a share register or memory. Consider using 1 I/O pin for a gate for stepping, have the SPIN COG monitor that pin and do a reset once the instruction is executed. The other COG reads HUB variables and does a set of the pin after confirming it was reset.
I think this method is pretty flexible.
That's the ticket!
The next Prop could have some virtual ports that were just used to internally connect flags from prop to prop. That way a wait on pin could be used to synchronize the movement of data between COG as in breaking up digital filters between cogs. That would mean one cog would not have to wait on a HUB memory location to know a sample is ready and external pins would not have to be consumed for internal signaling. Good ideas but maybe off this topic.
To expand Jon's comments ... There can be multiple Spin interpreters, each running in its own cog. When you start up a new cog using COGNEW or COGINIT, you can specify that the cog should be started with a program written in the Propeller's instruction set (assembly) or a program written in Spin interpretive code. In the 1st case, the hardware loads a block of 512 long words from the shared (HUB) RAM and passes a single 14 bit parameter that usually points to a block of data aligned on a long word boundary. In the 2nd case, the hardware loads the Spin interpreter from ROM into the cog and passes it the necessary information about the Spin interpretive code.
The next Prop could have some virtual ports that were just used to internally connect flags from prop to prop. That way a wait on pin could be used to synchronize the movement of data between COG as in breaking up digital filters between cogs. That would mean one cog would not have to wait on a HUB memory location to know a sample is ready and external pins would not have to be consumed for internal signaling. Good ideas but maybe off this topic.
Rich
Rich, the Prop 2 does have such a port. Port D is an internally connected port, effectively a register shared by all COGs at once. You can still do this with the Prop 1 by using an I/O pin or using the hub locks. The problem with hub locks is the huge overhead (relatively) in comparison to the I/O pins.
Comments
Here's my offer: http://forums.parallax.com/showthread.php?135920-2012-Propeller-Community-OSHW-quot-SmorgasBoard-quot-***-22-designs-MemBlade-PIC8-***&p=1066897&viewfull=1#post1066897
Terms negotiable.
--Steve
I'm a big fan of the Propeller because I like to break complex problems into simple pieces. The Propeller's architecture allows me to build one piece at a time and ensures that I won't have integration problems later, even when I do high speed things like video capture and analysis. Parallax is a great company that cares about it's customers, this forum is a wonderful resource to resolving problems.
Hanno
ps- Yes, to view/graph/change variable values you just need to reference ViewPort's "conduit" object to your spin file and call the "share" function with the location of your variables. You can provide additional configuration strings or use the graphical interface to choose which channels to display, how to graph them, timescale, etc... Best way to start is to try some of the tutorial files. Sounds like ViewPort is sharing your data but you're not seeing data in the graph because you didn't click the "plot" button.
Now it's suddenly decided variable V1 is an unsigned 16 bit int.
Hanno, if I can just get ViewPort working, I think I can manage with all the specifics of the Propeller. But I need a working debugger. I've left posts on your BBS with no response.
I'm an old-fashioned troubleshooter, easiest for me is to call you to resolve your issue...
Once we've fixed the issue I'll post a write-up of the problem and solution here.
Let's return to the Arduino vs. Prop discussion
Hanno
Ah, that old chestnut again. I suppose that hardware stacks are hell too because the Prop doesn't have them? Seems to me that people on this forum conveniently turn every missing feature of the Prop into a so-called advantage. My favorite was the guy who said, a few months ago, that the lack of a debug interface (such as J-TAG) was a feature because debuggers rot your brain and turn you into an inferior programmer (or something to that effect).
Multiple cores is an alternative solution to the problem that interrupts were invented to solve. They are logically equivalent but multiple cores removes the burden of having to worry about how different parts of your program will interact timing wise.
I was thinking, every COG can sniff on hub memory and the state of the inputs/outputs.
What you don't have access to is COG ram and counters.
If you write your program to store the variables you want to monitor in the VAR section, you can implement a debugger in one COG. You simply tell it to dump a memory location.
With a modified SPIN interpreter you could then single step by having the SPIN interpreter look for state in a share register or memory. Consider using 1 I/O pin for a gate for stepping, have the SPIN COG monitor that pin and do a reset once the instruction is executed. The other COG reads HUB variables and does a set of the pin after confirming it was reset.
I think this method is pretty flexible.
The code is buried in the forum here. There are some bugs. Some Spin operators are disabled to make room for the debugger stub. YMMV.
I like having my parts on hand. I could not afford to have every AVR or every PIC on hand just in case it was that version with the widget interface that I required.
And a cog is not wasted for a UART function because that cog can do so much more. Or take the 4port UART object in 1 cog. We never have to worry about all those registers to configure like the other chips. We just pull in an object and there we go. No uart registers! Now, before someone corrects me, yes, there are a few registers like the vga registers or thecounter registers. But these are not low-level registers.
And mostly, we can use whatever pins we like (vga is relegated to a block of 8 and tv to a block of 4). So, in a layout, you can mostly put the interfaces on any pins. Of course, the downside is that boards do tend to move some of these pins around because we don't stick to a standard. I am always trying to squeeze props into boards that don't fit, so I change the pins to suit the pcb. At least I can do that and I don't have to worry that if I use a uart then the i2c wont work because it shares the I/O pins.
Anyway, Jazzed gave a link to the group board done by tubular. My CpuBlade is on the panel and I also sell it separately. It is a 1"sq pcb with propeller, eeprom, pluggable xtal (I usually overclock to 104MHz using a 6.5MHz xtal) and has a 3v3 regulator and an optional transistor reset cct. All I/O pins are brought out. It requires 5V regulated (like from a USB type source). Writeup is at www.clusos.com and here http://forums.parallax.com/showthread.php?134134-Cluso-s-new-Propeller-stackable-and-pluggable-boards-(MultiProps-too) (posts 16 & 18 and a pic in post 12 top left of the pics)
What if you need Ethernet or USB, like some of the more recent PICs and AVRs support? How do you implement that on a Propeller cog?
USB Host? Bluetooth works in some configurations.
USB Device? Serial port, no problem. Others likely ok.
How? Search the forums.
It has it's own forum
I'm not sure about using only one cog. It might take more.
Way to go. Now I just have to get some better hardware than the Quickstart.
Internet.Order(BetterStuff[3])
waitcnt(5000000000000000000000 + cnt)
RadioShack.Return(Overpriced_Quickstart_Board)
Thanks!
See here for a screenshot of the ViewPort debugger, it basically offers you what you get with Visual Studio: step modes, breakpoint, memory map, IO pins, edit variables, command interpreter, terminal, profiler, call stack...
Seems to me it's pretty much the same issues you have to deal with either way. If multiple cores or interrupts are working on shared data, you cannot avoid the burden. Once you're dealing with shared data structures beyond a single long you have to understand concurrency issues, locking and semaphores. In fact, the Interrupt on a single CPU is much easier in many ways, as you can be sure only one stream of code is executing at any time. And whether an interrupt is affecting your timing or not depends on who's doing the looking. The code handling the interrupt is very happy to have a (relatively) predictable response time relative to an external event. And what it's not predictable by is say a disabling of the interrupt to ensure data integrity, which you have to do on either platform. On very simple projects the 8 core multiprocessor approach might seem clearer, but as soon as there's some complexity, seems to me it's the same old stuff, with obscure bugs due to race conditions, data contention, and all the goodies.
Anyway .. i came here because I'm hoping that the concept of a standardized hardware platform takes hold. Speaking of the 8 cog modularity, what we need is hardware building block modularity. People who make their own boards don't need that, but it would be very healthy for the Propeller's marketplace "footprint" for the boardmakers to arrive at a sort of standard that could just drop in with existing Arduino shields, with A/D on the same pins, etc. THEN the big Arduino user community has an upgrade path.
analogWrite(AnalogOutPin, Brightnessb)
Thanks!
p.s. I started on a controller for those RGB LED arrays, and it was so easy on the Arduino, that a likely sense of guilt carried me upwind to the Propeller.
analogWrite(Pin, Value)
where:
CON
dutyPeriod = $101_0101
ctrDUTY = 110
PUB analogWrite(pin,duty)
ctra := 0
frqa := dutyPeriod * duty
ctra := ctrDUTY << 26 + pin
But if this uses one of the two Propeller counters, are you limited to one concurrent PWM output using ctra, and then you have to have a separate analogWrite using ctrb, and 2 "analog" outputs is all she wrote ? I can't even control one RGB type LED?
A good way to think of it is that many microcontrollers have dedicated hardware for lots of stuff, but only one main thread. The Propeller has many threads, but very few dedicated hardware peripherals. That's by design - The intention is that you can create the things you need in software on other cores, and many of the objects do tasks normally done by hardware on other chips, but they're not wasting silicon if you aren't using them.
Actually mutual exclusion between threads is not the "burden" I was thinking of. Rather this simple thing:
I have process A running doing something quite time critical. Perhaps A is my entire program with multiple threads of execution going on.
Now I want to add another time critical function B.
If I only have one CPU I have to hook B into an interrupt system or thread scheduler. I have to understand the timing requirements of B and all the other activities in A so that I can figure out if I actually have time to do all of A and B combined. If there is time I have to assign priorities to my interrupts/threads so that everything works out OK. It's notoriously hard to be 100% sure that such a system is always reliable.
However if I have another core on which to run my new functionality B I can just build B into my program and use it without having to know anything about it's timing requirements and with out having to know all about the timing requirements of all the other objects in my code, which I may not have written.
So we see that having multiple cores instead of a single core and interrupts makes life a lot easier when integrating components.
Given that the philosophy of the Prop is to offer the flexibility of implementing peripheral in software rather than dedicated silicon this is very important.
As for the mutual exclusion problems, they will exist wherever you have multiple threads sharing data in memory no matter if it's threads derived from interrupts or actual parallel processing. The Prop offers locks to enable such mutual exclusion but it turns out that in the vast majority of cases they are not required to be used.
I dunno, it's not all that difficult, if you plan ahead, say FORTH-like systems can switch context on every operator return, the NEXT if you will, and it's not very different from a multi-processor system, just a bit slower. To me the race conditions and data access contention are more subtle and tricky. But for retrofitting additional very time-sensitive functions, no question that having spare cogs can be very handy. But I haven't studied the Prop in sufficient detail yet, specifically the interpreter and the Hub. Where can I read about how these work? I thought I read that a cog is dedicated to the interpreter, so where is machine code buffered and when? Are there then really 7 available cogs or 9 total?
Not always. With the Arduino you're stuck with the A2D capabilities it has, on the pins that they're assigned to -- with the Propeller I can decide (by selecting an appropriate A2D chip). Same with serial IO in terms of flexilitly.
There will always be a problem comparing the Arduino to the Propeller; it's like comparing a street car to a Forumula 1 car. Yeah, they're both cars; the street car is more comfortable and "easier" to handle, but doesn't offer a skilled driver the same performance as a racing car. Some of us like racing cars.
By the way, the actor in me -- that enjoys watching human behavior -- finds it fascinating that you want the simplicity and ease of the Arduino and yet refer to interrupts as "not at all difficult." In the hands of a skilled programmer, I agree. That said, I will take multiple cogs over interrupts any day; I'm way past having to re-code interrupts to add a feature to a product and don't ever want to do it again.
And yet, this has not stopped you from criticizing its design....
There are eight total cogs. On power-up, Cog 0 is loaded with the Spin interpreter and runs your program. That program could be as simple as launching another cog (PASM) and then shutting down cog 0. What I find fun for things that are not super timing sensitive is that you can launch another Spin interpreter and it can share Spin methods with the other Spin cogs (it can because Spin code lives in and is executed from the hub).
Here's an example of something I do from time-to-time: I can setup an array of rtc-type variables in the hub and then launch this method into its own cog. The beauty of waitcnt is that the code executes at a specific interval; and yes, Spin is fast enough to run this loop in under 1ms.
pri rtc | t ' start with cognew '' Simple timer/rtc '' -- runs in separate Spin cog t := cnt repeat waitcnt(t += MS_001) ' update every millisecond ms := ++ms // 1000 if (ms == 0) scs := ++scs // 60 if (scs == 0) mns := ++mns // 60 if (mns == 0) hrs := ++hrs // 24 if (hrs == 0) day := ++ day // 7In many applications I will launch a secondary Spin cog to show me the state of critical variables (poor man's debugger). Unless there's a code crunch I just leave this in -- which has come in handy. One customer with a DMX application wanted to see the raw stream values. I showed him how to connect a Prop-Plug to his device and bingo, it was there.
The Propeller is not perfect, but I think when you give it a chance -- unburdened by your desire to make it work like other devices -- you'll find it is quite useful and a joy in may respects.
Besides the forum, and a lot of incredibly skilled people, the possibility to use the obex is a great value.
Some objects are good, others not, but if you spend a little bit of time you'll find you can exploit other's work with little effort.
Being a poor programmer I usually have the main, slow, crappy loop I badly coded in a cog, and quality code from the obex in the spare COGS.
As an example at a price of a COG you can have float, SD card/FAT handling, 4 serial ports with buffer (4 ports in 1 cog!!), VGA, video, servo control over 32 pins and at a price of an extra cog also ramping, and many other nice things.
I have not the skills neither to code nor to understand the mentioned objects, but at no cost they are available, and I can use some/many of them at the same time, even with my limited skills...
That's the ticket!
The next Prop could have some virtual ports that were just used to internally connect flags from prop to prop. That way a wait on pin could be used to synchronize the movement of data between COG as in breaking up digital filters between cogs. That would mean one cog would not have to wait on a HUB memory location to know a sample is ready and external pins would not have to be consumed for internal signaling. Good ideas but maybe off this topic.
Rich
Rich, the Prop 2 does have such a port. Port D is an internally connected port, effectively a register shared by all COGs at once. You can still do this with the Prop 1 by using an I/O pin or using the hub locks. The problem with hub locks is the huge overhead (relatively) in comparison to the I/O pins.