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).
Fooey. There's nothing stopping you from connecting another ADC chip to an Arduino via I2C or SPI. Just because it has that capability built-in doesn't mean you can't supplement it with external capability.
You know what, the Prop 1 is what it is, if you don't like it, don't use it. I'm tired of seeing people criticize the Prop 1 for what it is or isn't. It ain't gonna change for the foreseeable future, so either get behind it or get out of the way. If you don't like the parameters that are dictated by the Prop 1 design, then go find your favorite chip and use it instead. I just hate seeing useless debate for the sake of vomiting words.
I didn't say you couldn't; I was stating (the flipping obvious) that for what's built in you're stuck with what it can do. Of course you can add external chips -- that's my choice. I prefer that the Propeller is not burdened by peripherals that I may not use or cannot be configured to my liking.
Fooey. There's nothing stopping you from connecting another ADC chip to an Arduino via I2C or SPI. Just because it has that capability built-in doesn't mean you can't supplement it with external capability.
LOL.. yeah.. I've been thinking the same thing.. Wouldn't all this effort be better spent coming up with some new objects, projects, tutorials?
OBC
Too true OBC!
We waste so much time trying to educate others on how simple the prop is to use. We have a few who always chime in to rubbish the prop (and I am sick of it Leon) and sometimes others.
Just to explain a few features...
D2A: The prop can do this on any I/O pin. PWM is mostly used (it can be done in software) and IIRC can be left to run on counters without intervention. Each cog has 2 counters so can do 2 D2A pins. We have 8 cogs, so theoretically we can have 16 PWM D2A outputs. The cogs can still be used for other code as it is only a register that needs to be changed if the D2A needs to be changed. Alternately, we can use a cog to perform multiple PWM channels purely by software.
A2D: The prop is a little bit harder here. The prop needs the support of a few resistors and capacitors and an extra pin to do this. Here you really need to see the App Note. It is not a simple matter of just connecting a pin up as the caps need to be at the pins (or close), not on a separate breadboard. Of course they can be on any I/O pins and we are not limited into how many pins we can have. Remember we have 16 counters.
Each counter has many modes of operation to do many other things. Best to see the AppNotes.
We also have a 32bit system counter that increments every clock. Using waitcnt we can synchronise to this, or with a little less accuracy check it in a loop. there are lots of uses for this counter.
And I am going to state it here... We have not exploited all the other (unknown) uses of the VGA and TV generation circuitry yet!
BTW...
Kuroneko is the master of the counters
Ahle2 is the master of audio output from the prop (see his SIDcog examples)
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.
...
And yet, this has not stopped you from criticizing its design....
Jon, I wasn't criticizing the design. I was criticizing the platform. And by that I mean what a new user encounters in evaluating the option of using an Arduino vs one of the Propeller boards. For the Prop to gain market share, which I presume we can agree is a good thing, by broadening the user base etc, Prop people have to make some orientation decisions. It's well and fine for every developer to blow his horn a la "I don't need no stinkin' reference designs, I make my own stuff", but it narrows the user base, which would be far better served by people making modules. I'm looking at what board to get, and the number of incompatible choices is unwelcome. Because I want to use building blocks to expedite the task. I'm not designing a washing machine, I'm doing special purpose stuff. It's not that I don't know how to design and build hardware, I've been doing it since before 6800 days. It's not that I don't know how to write a compiler or RTOS. But I have had my fill, and I'd rather concentrate on what is specific to the task at hand.
The constantly-repeated argument about the benefits of the multi-cog CPU relies on the modularity of the Object library. If you had to write pages of assembler glue code to use a software UART, and everybody's code demanded a different and specific interface, it wouldn't be very useful, would it? It's even more true with hardware, as software can be "cut and tried" faster than hardware. It takes a specific mind set to think modular from the get go, and that's what the Arduino team has done. Unless we measure it by short term profits, we can likely agree that the results are nothing short of impressive. It also takes a specific mind set to do it the cowboy way. On their own, Parallax itself has released enough incompatible boards to ensure the limited use of the Prop chip in a marketplace that the Arduino has amply and repeatedly proved viable. 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. So what we want, and I include myself among the lazy, is modules that we can inexpensively acquire and connect into that higher level object where our attention is focused. How much detailing, interfacing and glue is necessary depends on a lot of factors, but the ideal is a collection that grows, Lego-like, by each participant's experience. Like the Object Exchange. In hardware.
So what I was "criticizing" is the mind-set that Parallax has embraced: coding that is clever and of lesser use in rapid teaching (= market $hare), and hardware that is ad-hoc without an overall compatibility (= market $hare) interfacing plan. Make sense? Now, why would I care? Because I want more building blocks for rapid prototyping. If a prototype leads to small scale production, I want to be able to pick the make-buy ratio.
Fernand,
You raise some good points, but your criticism skirts one of the major differences between the Arduino and the Propeller, namely that the Propeller is a microprocessor chip while the Arduino is a platform / board that happens to be based on another microprocessor. It's natural that the Arduino would be a single board design with a matching development environment that has, over time, expanded to a huge library of modules (sketches) and hardware add-ons. One can start comparing the Arduino with one or more Propeller boards including Martin Hodge's Propeller ASC board which is mechanically and mostly electrically compatible with the Arduino. Other Propeller boards have different features including some of Cluso99's and the Mikronaut boards which have large amounts of parallel RAM and can run large C programs with some speed penalty, but still reasonably.
I think you'll find Parallax settling down with the Propeller Board of Education for educational use and the QuickStart board for commercial development. The mass of educational information that's accumulated over the years for the Basic Stamp will be functionally duplicated for the PropBOE and I think you'll see the Propeller chip start to achieve the same kind of educational market penetration as the Stamp BOE.
Mike, exactly! The Propeller is a processor and Parallax wants to sell Propellers. The Arduino ecosystem is populated by at least 3 different micro-architectures and several different models of the same AVR, within the same platform (Uno, Mega, etc).
There is 1 Propeller and a bunch of boards. I would love to see some plugin type development architecture where you pick peripherals from a library and they all have well defined and consistent interfaces. It takes a while to get proficient enough with the Propeller to kind of make this for yourself.
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.
When you say "loads a block of 512 longs from shared RAM", what does it do with it? Does it copy contents (starting where?) to private RAM, or set a pointer or? When a Cog is to run machine code, what is the program counter set to, and how much of what memory is available to that cog?
If a cog is starting to run SPIN code, is the interpreter itself executing in that cog's memory or out of common memory? how big is the interpreter to fit in a Cog's RAM? And the SPIN tokens that constitute the program for that cog are where?
@Fernand: As has been pointing out, the Propeller is a single chip and there is a complete, official manual and datasheet for it. Many of the questions you're asking are documented by Parallax. If you're using the Propeller Tool these documents are available from the Help menu.
When you say "loads a block of 512 longs from shared RAM", what does it do with it? Does it copy contents (starting where?) to private RAM, or set a pointer or? When a Cog is to run machine code, what is the program counter set to, and how much of what memory is available to that cog?
If a cog is starting to run SPIN code, is the interpreter itself executing in that cog's memory or out of common memory? how big is the interpreter to fit in a Cog's RAM? And the SPIN tokens that constitute the program for that cog are where?
Jon is right - this info is available in the Prop manual, but because I know, and it's quick...
When you launch a Cog, you provide the address of a label in a DAT section. Starting from that address, 512 longs of data are copied into the private memory of the cog starting at location zero, and its execution begins at cog memory location zero. This is why asm code for the Prop starts with a DAT directive, the "org 0" directive (labels are now relative to that start anchor), some assembly instructions, and then any data you wish to be copied along with it. (the cog program counter always starts at zero). The cog has direct access to all of those 512 longs in its private memory, or slower access to the 32Kb of hub memory through the hub read/write instructions. In addition to that, you have access to the 32Kb ROM that includes sin, log, and antilog tables, the interpreter, the bootloader, and the ROM font that's used by TVText and other display objects.
When you launch a SPIN interpreter, the interpreter itself is a built-in ASM function, subject to the exact details I just described, so it has to be under 512 longs in total for the code. The token code that it executes lives in the 32Kb hub memory, and is read via the hub read instructions as it is interpreted.
You raise some good points, but your criticism skirts one of the major differences between the Arduino and the Propeller, namely that the Propeller is a microprocessor chip while the Arduino is a platform.
I think you'll find Parallax settling down with the Propeller Board of Education for educational use and the QuickStart board for commercial development. The mass of educational information that's accumulated over the years for the Basic Stamp will be functionally duplicated for the PropBOE and I think you'll see the Propeller chip start to achieve the same kind of educational market penetration as the Stamp BOE.
I'm enjoying hearing all the arguments, but I'm not religious about "environments", and I was hoping we might agree on the desirability of hardware modularization.
The microprocessor/platform distinction in practice is fairly academic, I think . The $8 minimum cost on a Prop is good, but it needs external memory to even boot up, a $4 AVR chip does not. The parts count to create a minimal booting controller is about the same, and I can get ATmega328 or ATmega2560 chips with a bootloader. So maybe we can define Arduino as a microprocessor family with a compiled library (a platform) and a Lowest Common Denominator I/O standard that is adhered to in a set of reference boards and expanders. The Propeller is a microprocessor with an interpreter and a library, a "platform", but, and that's what I'm not liking, no common standard reference boards and no connector or I/O standards, creating a (needless?) barrier to wider adoption.
I don't know who buys what for which institution, and the BOE has a lot of nice peripherals, but it looks like a $130 board that is expandable only through specific items, like the RF modules. I don't see a schematic. Bolted down in a middle school class it looks nice, but for High School and up, it looks a bit dead-end, if that term makes sense. If I had to choose, I think I'd rather see each student get a $30 Arduino Uno with a protoboard, and start with learning C and not SPIN.
Commercial development you understand as embedded controllers for thousand quantity++ appliances? Then on day one maybe the Quickstart is fine, but any functioning minimal CPU + program memory + exposed I/O could work, since I'd be designing everything anyway. But if you mean I need a USB loader port etc, then the Quickstart is not something I find very attractive for low volume development, because I think I'd want some of the peripherals and expander options that are available on an Arduino. I think the ACS is perhaps a better idea for that reason. It seems the market is voting Arduino, and my point is the Prop should get on the train.
Thank you kindly, Jason, that makes sense. I'm looking at the datasheet and, forgive me, not finding everything crystal clear as yet. A single paragraph for each of these issue is not a lot. I was told I would get help with any questions here, can I ask just a couple more?
Q1. If the interpreter is in the cog's private RAM to optimize execution speed, my assembly code would need to be there too, so how much is left over for my assembly code?
Q2. If I understand correctly, my SPIN program is not limited to the cog's private RAM, as it resides and is stepped by the interpreter directly in shared (hub-managed) memory? So is there a mechanism to swap units of assembly code in and out of private RAM if it won't fit, or are we limited to what you answered to Q1 above?
The Spin interpretter fills an entire COG. When it runs it fetches your compiled Spin byte codes from the shared HUB RAM and executes them. There is no room in a COG running the interpretter for it fetch and run any of your PASM.
Your PASM code has to be loaded into another COG where it runs. Done with COGNEW/COGINIT. See examples in the manual.
If you think about it this is quite amazing. The whole Spin interpretter fits in 496 longs!
Re: Q2. Yes. No.
However it is quite possible for your PASM code running in COG to fetch chunks of PASM code from HUB and run them. The good old fashioned 'overlay' technique. Search for Cluso's overlay loader here. This is not really a technique for beginners.
I thought I would also mention that I have a debugger that uses a quirk to hide the interpreter within the cog unused space (shadow ram) - I call it the zero-footprint debugger. It can trace spin and/or pasm code, but because it is stepping the code it is quite slow. Jazzed has a debugger that I think is based on the work I did, but adds some other functions.
As heater explained, the spin interpreter lives and fills all the cog memory (496 longs). The shadow memory I mentioned shadows the 16 registers that complete the list to 512 longs. The interpreter is written in pasm but is quite convoluted to fit into the space.
When you write a program for a cog, you choose either spin or pasm, but not both. Your spin code lives in hub, and your pasm code lives in (and executes from) cog memory although it is initially loaded from hub memory via the coginit or cognew command.
For the advanced users, Dave has modified the interpreter to be able to execute LMM pasm. I have a faster interpreter too that uses some hub space for a vector table.
Did we also mention heater wrote a 8080/Z80 interpreter and with 64KB SRAM (or more) we can run CPM2.2 at a little faster than the old 4MHz Z80? We use the microSD as the disk drives. We have 8 drives mapped. They are mostly 8MB with one 32MB large drive.
Fernand,
One of the things about standardization as typified by the Arduino's reference designs vs. what seems to be a lack of an "official" reference design for the Propeller is that of premature standardization. Most standards come very late in the development process. If they come too early, the standard will ossify innovation and either the platform will die or there will be competing unapproved "standards" that will supercede the official standard and become the de-facto standard. The earliest reference design for the Propeller has been the Demo Board which is still sold, used, and referred to as an example. On the other hand, since the Demo Board was developed, a number of major peripheral functions have been developed, most significantly the use of SD cards for mass storage using 4 I/O pins. Other major developments have been the various incarnations of specialized interpreters including the Z80 emulator and the Large Memory Model (LMM) interpreters and their variants that use caches and sometimes large external memory to execute code. None of this was implemented or well understood regarding the Propeller at the time the Demo Board was developed. Now we're beginning to see newer and very different reference designs from Parallax (QuickStart and PropBOE) for different markets although with some crossover.
In my mind the 40 pin DIP Propeller is the reference platform.
Bear with me...
With a power supply and a couple of caps I have a working Prop system. Assuming I have a Prop plug, which anyone would if they are using Props, and a bread board / perf board to mount it on. To start program development I don't even need a crystal or EEPROM.
How simple could it be? That's exactly how I started with the Prop and believe me I like quick and simple.
I'm new to the propeller and have never looked closely at Arduino but I can't help but think that what Gadget Gangster has is very close to the arduino concept of stackable boards. Also there are very small stackable boards available from Australia (sorry but I forget the name now). Bottom line is that there are easy and flexible options for the prop!
Interestingly, there was a cock-up with the original Arduino PCB layout that has persisted to the present day - two of the connectors were placed 0.05" apart instead of 0.1", making it difficult to use it with standard perf board and Vero board.
I'm new to the propeller and have never looked closely at Arduino but I can't help but think that what Gadget Gangster has is very close to the arduino concept of stackable boards. Also there are very small stackable boards available from Australia (sorry but I forget the name now). Bottom line is that there are easy and flexible options for the prop!
That's right. If somebody wants an Arduino-like stackable system take a look at Gadget Gangster or Martin Hodge's ASC.
Mike pointed out above that our efforts around the Propeller Board of Education put all of the hardware into a single place in a form factor already familiar to our customers. Beyond our key hobby and educational initiatives most of our customers know that designing and selling chips as we are doing requires a company to sell millions of them to recover R&D expenses, design fees, fabrication and packaging setup costs, etc. I can tell you that in all of the volume applications for the P8X32A there has never been mention of an Arduino as an alternative by our customers. The closest any of the commercial customers get to Arduino is in their quest for C support from Parallax, mostly because they don't want existing engineers to learn a new language. PropGCC for the Propeller 1 will soon be in beta and will immediately be ported to Propeller 2 when we have working silicon. The Propeller 2 architecture is more ideal for the PropGCC model with larger memory and no built-in interpreter.
Ideally, at some point our commercial chip business will enable our educational business to be almost free to our customers and very low-cost to the hobbyist. Now and in the future we'll span this whole customer base with our product line, making sure they're all served the way they want to be. Delivering this kind of technology for each customer type is a challenge, as noted above.
I did just a bit of research before choosing either the Arduino or Prop. Yes, the Arduino is VERY simplistic in it's standards. Get a PCB. Hook it to voltage. Program. Done. The propeller, even in it's minimal parts to get going has a LOT more options, and that reflects the creativity and freedom of the developer using it. If you are the kind of person that leans toward programming, and not so much the electronics part of it, Arduino is an obvious choice since everything you buy for it (for the most part) comes pre-assembled. This is not to say that some of the folks out here go for the pre-assembled Demo and quick start boards. On the other hand, the propeller is wide open to creativity. Look at some of the things that have been done with it... While there is no one "Standard", everyone here after a little bit of working with things easilly finds the SDFS drivers for SD.... Simplistic TV and VGA outputs... I guess you could call them standards, but they are more stepping stones than a concrete way of doing things.
making sure they're all served the way they want to be
I just have to add... that was the deciding factor for me. I had some experience with the BS2, and everything from the manuals, to the forums, and that additude right there brings me back. Keep up the good work, and for god's sake buy Chip and company a coffee. They deserve at least that.
I thought I would also mention that I have a debugger that uses a quirk to hide the interpreter within the cog unused space (shadow ram) - I call it the zero-footprint debugger. It can trace spin and/or pasm code, but because it is stepping the code it is quite slow. Jazzed has a debugger that I think is based on the work I did, but adds some other functions.
I used your stepper code and gave you credit for it and some other non-trivial functional parts.
Other than that the PASM debugger is entirely different.
Interestingly, there was a cock-up with the original Arduino PCB layout that has persisted to the present day - two of the connectors were placed 0.05" apart instead of 0.1", making it difficult to use it with standard perf board and Vero board.
That wasn't a mistake, and was done intentionally -- despite some revisionist histories floating around. It's to prevent people plugging in shields backwards. This has been a problem going back to stacking SBCs of the 80s.
As the current R3 hardware and Arduino 1.0 software demonstrate, the Arduino developers are not afraid of making breaking changes. The mixed spacing was present well before there were even a few hundred mostly hand-made single-sided boards. They fixed things like backward USB pinouts, they could have fixed this in a heartbeat if it were truly a mistake.
no common standard reference boards and no connector or I/O standards
By default any board Parallax sells is a reference design. Most Propeller boards are for protoyping, in keeping with the company's history of offering similar products for the BASIC Stamp lineup. So they either have solder pads or solderless breadboards already attached to them. This is their design concept, for better or worse.
There are numerous incompatible reference designs for the Arduino, including ones they didn't create but they support (LilyPad, Boarduino, SparkFun's Pro Minis). These last boards aren't even even sold with connectors, as they're made for adapting into some prototype. You have to solder pins to them in whatever orientation you need. There's equally no connector or I/O standardization except among a fairly narrow set of designs, led by the Uno.
And this is a good thing, because it provides greater selection and option. I just ordered another Pro Mini 5V because I need it for a project. I couldn't use an Uno. (And, in an interesting twist, the observant ones in the crowd will notice that the Pro Mini's pinouts are the same as a BASIC Stamp 2. Talk about a reference design!)
Your overall grouse of ad hoc and incomplete examples for the Propeller is a valid one; I'm just not sure some of these supporting arguments hold much water. All anyone can say is what's been said before, that there's an active push by Parallax to greatly improve and extend the examples for the Propeller. You can see evidence of it already. But whether that push comes in time for your needs only you can decide.
Well, hats off to Chip, it's a very interesting design.
But, Heater, what are you talking about? A Mega328P has non-volatile programmable memory and can run my app standalone.
Very glad to see Parallax gradually coming over to the "open" concept. I don't know the numbers, but would imagine some people who start out with Arduinos end up being pros. The best engineers I've hired were self-taught. So my point about making the Prop more approachable for the peasants may be relevant.
Since people here have been so honest and forthcoming about their preferences, allow me to "share". I'm sitting here and wondering. I have a few projects I'd like to implement. I can do these a number of ways, from a handful of chips to some all-in-one boards programmed in whatever. I'd sort of like to settle on a standard, and a Prop ASC looks good. It took me one day to be productive in the Arduino environment. The docs were clear enough I didn't have to do a lot of digging, and the community is very responsive. I have spent several days with the Prop, the old-fashioned way, getting the tools to work, scraping through datasheets etc. 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. Now what's the prognosis on moving quickly with the Prop? What is going on here? The assumption seems to be that if I'm pointing out the strengths of the Arduino "standards", I'm one of the peasants, and am I making an erroneous assumption that most people who've acquired a specialized knowhow on a specific device WANT to see more people "on-board"?
Can someone PLEASE direct me to the best information on the Prop memory model. Questions like: Is private memory mapped into a specific section of the address space? How big is the directly addressable address space? When SPIN code in HUB memory is being interpreted by the interpreter in Cog 0, where are global variables (HUB RAM?), where are local variables (the private 512 longs? how much is left/available?), how big can that tokenized SPIN code be, what happens when I start another Cog running SPIN (or can I), where is the interpreter for that running (another copy in that cog?), how does that SPIN code see the overall memory? what about assembly in a new Cog, how is the memory space mapped for it, etc etc. Please, I would rather not waste another day doing detective work when there's so much know-how here. What's the best place to read up on these topics? Thank you.
I used your stepper code and gave you credit for it and some other non-trivial functional parts.
Other than that the PASM debugger is entirely different.
Thanks Steve. I was not sure what you did and didn't use and certainly wasn't meaning you did not give me credit for the bits you used. I did want to mention your debugger because it is another one and as far as I recall, you put a good interface on it.
Comments
Fooey. There's nothing stopping you from connecting another ADC chip to an Arduino via I2C or SPI. Just because it has that capability built-in doesn't mean you can't supplement it with external capability.
And please don't get me started on Arudino I2C
LOL.. yeah.. I've been thinking the same thing.. Wouldn't all this effort be better spent coming up with some new objects, projects, tutorials?
OBC
We waste so much time trying to educate others on how simple the prop is to use. We have a few who always chime in to rubbish the prop (and I am sick of it Leon) and sometimes others.
Just to explain a few features...
D2A: The prop can do this on any I/O pin. PWM is mostly used (it can be done in software) and IIRC can be left to run on counters without intervention. Each cog has 2 counters so can do 2 D2A pins. We have 8 cogs, so theoretically we can have 16 PWM D2A outputs. The cogs can still be used for other code as it is only a register that needs to be changed if the D2A needs to be changed. Alternately, we can use a cog to perform multiple PWM channels purely by software.
A2D: The prop is a little bit harder here. The prop needs the support of a few resistors and capacitors and an extra pin to do this. Here you really need to see the App Note. It is not a simple matter of just connecting a pin up as the caps need to be at the pins (or close), not on a separate breadboard. Of course they can be on any I/O pins and we are not limited into how many pins we can have. Remember we have 16 counters.
Each counter has many modes of operation to do many other things. Best to see the AppNotes.
We also have a 32bit system counter that increments every clock. Using waitcnt we can synchronise to this, or with a little less accuracy check it in a loop. there are lots of uses for this counter.
And I am going to state it here... We have not exploited all the other (unknown) uses of the VGA and TV generation circuitry yet!
BTW...
Kuroneko is the master of the counters
Ahle2 is the master of audio output from the prop (see his SIDcog examples)
Jon, I wasn't criticizing the design. I was criticizing the platform. And by that I mean what a new user encounters in evaluating the option of using an Arduino vs one of the Propeller boards. For the Prop to gain market share, which I presume we can agree is a good thing, by broadening the user base etc, Prop people have to make some orientation decisions. It's well and fine for every developer to blow his horn a la "I don't need no stinkin' reference designs, I make my own stuff", but it narrows the user base, which would be far better served by people making modules. I'm looking at what board to get, and the number of incompatible choices is unwelcome. Because I want to use building blocks to expedite the task. I'm not designing a washing machine, I'm doing special purpose stuff. It's not that I don't know how to design and build hardware, I've been doing it since before 6800 days. It's not that I don't know how to write a compiler or RTOS. But I have had my fill, and I'd rather concentrate on what is specific to the task at hand.
The constantly-repeated argument about the benefits of the multi-cog CPU relies on the modularity of the Object library. If you had to write pages of assembler glue code to use a software UART, and everybody's code demanded a different and specific interface, it wouldn't be very useful, would it? It's even more true with hardware, as software can be "cut and tried" faster than hardware. It takes a specific mind set to think modular from the get go, and that's what the Arduino team has done. Unless we measure it by short term profits, we can likely agree that the results are nothing short of impressive. It also takes a specific mind set to do it the cowboy way. On their own, Parallax itself has released enough incompatible boards to ensure the limited use of the Prop chip in a marketplace that the Arduino has amply and repeatedly proved viable. 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. So what we want, and I include myself among the lazy, is modules that we can inexpensively acquire and connect into that higher level object where our attention is focused. How much detailing, interfacing and glue is necessary depends on a lot of factors, but the ideal is a collection that grows, Lego-like, by each participant's experience. Like the Object Exchange. In hardware.
So what I was "criticizing" is the mind-set that Parallax has embraced: coding that is clever and of lesser use in rapid teaching (= market $hare), and hardware that is ad-hoc without an overall compatibility (= market $hare) interfacing plan. Make sense? Now, why would I care? Because I want more building blocks for rapid prototyping. If a prototype leads to small scale production, I want to be able to pick the make-buy ratio.
You raise some good points, but your criticism skirts one of the major differences between the Arduino and the Propeller, namely that the Propeller is a microprocessor chip while the Arduino is a platform / board that happens to be based on another microprocessor. It's natural that the Arduino would be a single board design with a matching development environment that has, over time, expanded to a huge library of modules (sketches) and hardware add-ons. One can start comparing the Arduino with one or more Propeller boards including Martin Hodge's Propeller ASC board which is mechanically and mostly electrically compatible with the Arduino. Other Propeller boards have different features including some of Cluso99's and the Mikronaut boards which have large amounts of parallel RAM and can run large C programs with some speed penalty, but still reasonably.
I think you'll find Parallax settling down with the Propeller Board of Education for educational use and the QuickStart board for commercial development. The mass of educational information that's accumulated over the years for the Basic Stamp will be functionally duplicated for the PropBOE and I think you'll see the Propeller chip start to achieve the same kind of educational market penetration as the Stamp BOE.
There is 1 Propeller and a bunch of boards. I would love to see some plugin type development architecture where you pick peripherals from a library and they all have well defined and consistent interfaces. It takes a while to get proficient enough with the Propeller to kind of make this for yourself.
When you say "loads a block of 512 longs from shared RAM", what does it do with it? Does it copy contents (starting where?) to private RAM, or set a pointer or? When a Cog is to run machine code, what is the program counter set to, and how much of what memory is available to that cog?
If a cog is starting to run SPIN code, is the interpreter itself executing in that cog's memory or out of common memory? how big is the interpreter to fit in a Cog's RAM? And the SPIN tokens that constitute the program for that cog are where?
Jon is right - this info is available in the Prop manual, but because I know, and it's quick...
When you launch a Cog, you provide the address of a label in a DAT section. Starting from that address, 512 longs of data are copied into the private memory of the cog starting at location zero, and its execution begins at cog memory location zero. This is why asm code for the Prop starts with a DAT directive, the "org 0" directive (labels are now relative to that start anchor), some assembly instructions, and then any data you wish to be copied along with it. (the cog program counter always starts at zero). The cog has direct access to all of those 512 longs in its private memory, or slower access to the 32Kb of hub memory through the hub read/write instructions. In addition to that, you have access to the 32Kb ROM that includes sin, log, and antilog tables, the interpreter, the bootloader, and the ROM font that's used by TVText and other display objects.
When you launch a SPIN interpreter, the interpreter itself is a built-in ASM function, subject to the exact details I just described, so it has to be under 512 longs in total for the code. The token code that it executes lives in the 32Kb hub memory, and is read via the hub read instructions as it is interpreted.
I'm enjoying hearing all the arguments, but I'm not religious about "environments", and I was hoping we might agree on the desirability of hardware modularization.
The microprocessor/platform distinction in practice is fairly academic, I think . The $8 minimum cost on a Prop is good, but it needs external memory to even boot up, a $4 AVR chip does not. The parts count to create a minimal booting controller is about the same, and I can get ATmega328 or ATmega2560 chips with a bootloader. So maybe we can define Arduino as a microprocessor family with a compiled library (a platform) and a Lowest Common Denominator I/O standard that is adhered to in a set of reference boards and expanders. The Propeller is a microprocessor with an interpreter and a library, a "platform", but, and that's what I'm not liking, no common standard reference boards and no connector or I/O standards, creating a (needless?) barrier to wider adoption.
I don't know who buys what for which institution, and the BOE has a lot of nice peripherals, but it looks like a $130 board that is expandable only through specific items, like the RF modules. I don't see a schematic. Bolted down in a middle school class it looks nice, but for High School and up, it looks a bit dead-end, if that term makes sense. If I had to choose, I think I'd rather see each student get a $30 Arduino Uno with a protoboard, and start with learning C and not SPIN.
Commercial development you understand as embedded controllers for thousand quantity++ appliances? Then on day one maybe the Quickstart is fine, but any functioning minimal CPU + program memory + exposed I/O could work, since I'd be designing everything anyway. But if you mean I need a USB loader port etc, then the Quickstart is not something I find very attractive for low volume development, because I think I'd want some of the peripherals and expander options that are available on an Arduino. I think the ACS is perhaps a better idea for that reason. It seems the market is voting Arduino, and my point is the Prop should get on the train.
Q1. If the interpreter is in the cog's private RAM to optimize execution speed, my assembly code would need to be there too, so how much is left over for my assembly code?
Q2. If I understand correctly, my SPIN program is not limited to the cog's private RAM, as it resides and is stepped by the interpreter directly in shared (hub-managed) memory? So is there a mechanism to swap units of assembly code in and out of private RAM if it won't fit, or are we limited to what you answered to Q1 above?
Your PASM code has to be loaded into another COG where it runs. Done with COGNEW/COGINIT. See examples in the manual.
If you think about it this is quite amazing. The whole Spin interpretter fits in 496 longs!
However it is quite possible for your PASM code running in COG to fetch chunks of PASM code from HUB and run them. The good old fashioned 'overlay' technique. Search for Cluso's overlay loader here. This is not really a technique for beginners.
As heater explained, the spin interpreter lives and fills all the cog memory (496 longs). The shadow memory I mentioned shadows the 16 registers that complete the list to 512 longs. The interpreter is written in pasm but is quite convoluted to fit into the space.
When you write a program for a cog, you choose either spin or pasm, but not both. Your spin code lives in hub, and your pasm code lives in (and executes from) cog memory although it is initially loaded from hub memory via the coginit or cognew command.
For the advanced users, Dave has modified the interpreter to be able to execute LMM pasm. I have a faster interpreter too that uses some hub space for a vector table.
Did we also mention heater wrote a 8080/Z80 interpreter and with 64KB SRAM (or more) we can run CPM2.2 at a little faster than the old 4MHz Z80? We use the microSD as the disk drives. We have 8 drives mapped. They are mostly 8MB with one 32MB large drive.
One of the things about standardization as typified by the Arduino's reference designs vs. what seems to be a lack of an "official" reference design for the Propeller is that of premature standardization. Most standards come very late in the development process. If they come too early, the standard will ossify innovation and either the platform will die or there will be competing unapproved "standards" that will supercede the official standard and become the de-facto standard. The earliest reference design for the Propeller has been the Demo Board which is still sold, used, and referred to as an example. On the other hand, since the Demo Board was developed, a number of major peripheral functions have been developed, most significantly the use of SD cards for mass storage using 4 I/O pins. Other major developments have been the various incarnations of specialized interpreters including the Z80 emulator and the Large Memory Model (LMM) interpreters and their variants that use caches and sometimes large external memory to execute code. None of this was implemented or well understood regarding the Propeller at the time the Demo Board was developed. Now we're beginning to see newer and very different reference designs from Parallax (QuickStart and PropBOE) for different markets although with some crossover.
Bear with me...
With a power supply and a couple of caps I have a working Prop system. Assuming I have a Prop plug, which anyone would if they are using Props, and a bread board / perf board to mount it on. To start program development I don't even need a crystal or EEPROM.
How simple could it be? That's exactly how I started with the Prop and believe me I like quick and simple.
That's right. If somebody wants an Arduino-like stackable system take a look at Gadget Gangster or Martin Hodge's ASC.
Mike pointed out above that our efforts around the Propeller Board of Education put all of the hardware into a single place in a form factor already familiar to our customers. Beyond our key hobby and educational initiatives most of our customers know that designing and selling chips as we are doing requires a company to sell millions of them to recover R&D expenses, design fees, fabrication and packaging setup costs, etc. I can tell you that in all of the volume applications for the P8X32A there has never been mention of an Arduino as an alternative by our customers. The closest any of the commercial customers get to Arduino is in their quest for C support from Parallax, mostly because they don't want existing engineers to learn a new language. PropGCC for the Propeller 1 will soon be in beta and will immediately be ported to Propeller 2 when we have working silicon. The Propeller 2 architecture is more ideal for the PropGCC model with larger memory and no built-in interpreter.
Ideally, at some point our commercial chip business will enable our educational business to be almost free to our customers and very low-cost to the hobbyist. Now and in the future we'll span this whole customer base with our product line, making sure they're all served the way they want to be. Delivering this kind of technology for each customer type is a challenge, as noted above.
Ken Gracey
I just have to add... that was the deciding factor for me. I had some experience with the BS2, and everything from the manuals, to the forums, and that additude right there brings me back. Keep up the good work, and for god's sake buy Chip and company a coffee. They deserve at least that.
I used your stepper code and gave you credit for it and some other non-trivial functional parts.
Other than that the PASM debugger is entirely different.
That wasn't a mistake, and was done intentionally -- despite some revisionist histories floating around. It's to prevent people plugging in shields backwards. This has been a problem going back to stacking SBCs of the 80s.
As the current R3 hardware and Arduino 1.0 software demonstrate, the Arduino developers are not afraid of making breaking changes. The mixed spacing was present well before there were even a few hundred mostly hand-made single-sided boards. They fixed things like backward USB pinouts, they could have fixed this in a heartbeat if it were truly a mistake.
-- Gordon
By default any board Parallax sells is a reference design. Most Propeller boards are for protoyping, in keeping with the company's history of offering similar products for the BASIC Stamp lineup. So they either have solder pads or solderless breadboards already attached to them. This is their design concept, for better or worse.
There are numerous incompatible reference designs for the Arduino, including ones they didn't create but they support (LilyPad, Boarduino, SparkFun's Pro Minis). These last boards aren't even even sold with connectors, as they're made for adapting into some prototype. You have to solder pins to them in whatever orientation you need. There's equally no connector or I/O standardization except among a fairly narrow set of designs, led by the Uno.
And this is a good thing, because it provides greater selection and option. I just ordered another Pro Mini 5V because I need it for a project. I couldn't use an Uno. (And, in an interesting twist, the observant ones in the crowd will notice that the Pro Mini's pinouts are the same as a BASIC Stamp 2. Talk about a reference design!)
Your overall grouse of ad hoc and incomplete examples for the Propeller is a valid one; I'm just not sure some of these supporting arguments hold much water. All anyone can say is what's been said before, that there's an active push by Parallax to greatly improve and extend the examples for the Propeller. You can see evidence of it already. But whether that push comes in time for your needs only you can decide.
-- Gordon
But, Heater, what are you talking about? A Mega328P has non-volatile programmable memory and can run my app standalone.
Very glad to see Parallax gradually coming over to the "open" concept. I don't know the numbers, but would imagine some people who start out with Arduinos end up being pros. The best engineers I've hired were self-taught. So my point about making the Prop more approachable for the peasants may be relevant.
Since people here have been so honest and forthcoming about their preferences, allow me to "share". I'm sitting here and wondering. I have a few projects I'd like to implement. I can do these a number of ways, from a handful of chips to some all-in-one boards programmed in whatever. I'd sort of like to settle on a standard, and a Prop ASC looks good. It took me one day to be productive in the Arduino environment. The docs were clear enough I didn't have to do a lot of digging, and the community is very responsive. I have spent several days with the Prop, the old-fashioned way, getting the tools to work, scraping through datasheets etc. 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. Now what's the prognosis on moving quickly with the Prop? What is going on here? The assumption seems to be that if I'm pointing out the strengths of the Arduino "standards", I'm one of the peasants, and am I making an erroneous assumption that most people who've acquired a specialized knowhow on a specific device WANT to see more people "on-board"?
Can someone PLEASE direct me to the best information on the Prop memory model. Questions like: Is private memory mapped into a specific section of the address space? How big is the directly addressable address space? When SPIN code in HUB memory is being interpreted by the interpreter in Cog 0, where are global variables (HUB RAM?), where are local variables (the private 512 longs? how much is left/available?), how big can that tokenized SPIN code be, what happens when I start another Cog running SPIN (or can I), where is the interpreter for that running (another copy in that cog?), how does that SPIN code see the overall memory? what about assembly in a new Cog, how is the memory space mapped for it, etc etc. Please, I would rather not waste another day doing detective work when there's so much know-how here. What's the best place to read up on these topics? Thank you.