"What specs will entice design engineers to investigate the prop?"
I am not convinced that specifications alone will do the trick. I bought the demo board out of sheer curiosity, and went through the manual. Just as it started to get to the interesting part -- applications -- the book switched over to the command description section. A small handbook like Radio Shack's Engineering Handbooks would be a plus.
The cutesy cap is not conducive to a professional look.
uChip & TI have product seminars at their distributors' offices. Perhaps something like that could be done for the Prop. The first seminar could be "Why in the world should I switch to the Propeller???" Attendees get simple development boards to explore the new micro.
Way back when the different micro manufacturers had comparison charts, basically saying, "All other micros suck at ____" for a number of processes. I was impressed by Nat'l. Semi. when their charts showed that their product was NOT the best at some process or another. (I don't remember which it was, it may have been software multiply or divide, or maybe a block move?)
I think what also needs to be emphasized is the niche Parallax hopes for the Prop to fill. And then show how it is better than any competitive products at doing it.
That approach works very well for other manufacturers. TI has been doing it for years with their 430 days for the MSP430, held around the 30th April every year around the world. I remember when Atmel launched their ARM7TDMI chip that way, and the other purveyor of parallel processing to the masses did it very successfully when their first device was launched a couple of years ago. I often run into someone I haven't seen for years at events like those, which is nice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Dave Hein: There is always the tile renderer option for both of those resolutions within the Prop2 hub/cog memory. For the full framebuffer bitmap mode you'll certainly need external memory, and it'll need to be fast. I suspect the external memory setup on Prop2 will be fast enough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I've always been in two minds about that cutesy Propeller Beanie.
On the one hand it's might come over a frivolous and "not business like". Which I might have thought of as negative point if you want to play with the "professionals".
On the other hand, I am now holding in my hands 400 Euros worth of technology which is selling around the world in millions. Guess what? The logo associated with the user interface software is a green alien looking robot and that of the OS kernel is a cartoon caricature of a penguin bloated on herring. An awful lot of big shots have had a hand in that system from IBM downwards, despite the juvenile logos. The logos don't seem to stop a world full of developers jumping on the bandwagon.
Actually I just got an invite to the Embedded Live conference at London's Earls Court where they featuring seminars on using Android (green space robot) for embedded systems that need displays and such.
My conclusion: The Propeller beanie is quite acceptable anywhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Roy Eltham said...
Dave Hein: There is always the tile renderer option for both of those resolutions within the Prop2 hub/cog memory. For the full framebuffer bitmap mode you'll certainly need external memory, and it'll need to be fast. I suspect the external memory setup on Prop2 will be fast enough.
A tile renderer wouldn't be adequate for the type of applications I have in mind.· However, it sounds like the Prop II would support 1080p30 with external memory.· The updated requirements list is now
Prop I
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
Prop II
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
- Single cycle multiply
- Support 1024x768 24-bit graphics
- Support 1080p
- Glueless interface to DDR memory
Missing features
- HDMI input and output
- High-speed instruction and data cacheing
- Low cost
Does DMA mean Direct Memory Access as in access to external memory in general or the normal notion of memory shared with some peripheral block, on chip or otherwise?
Any kind of instruction/data caching is not conducive to 100% deterministic timing of code execution. If an app really insists on caches for, whatever reason, or can tolerate the timing chaos they cause then Prop or chips like it are not targeted at that problem domain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The reason the prop caught my eye is that it is an implementation of the 683XX
with the embedded {embedded} core capability, and some easy video.
It sure does triple back flips in the lab, but I don't know how I'd sell them in quantity.
I think the next level will go to the company that exposes the metal to the programmer
ala FPGA in a simpler subset of SystemC etc; without all the FPGA headaches.
This hardware is available now, but the NRE is the current killer.
I'm sure that the Engineering Community at Parallax has seen this, but may be as
stumped as me as to it's (practical) implementation.
I guess I'd say: Chip, if you've got spare gates, push an array of them up for me, somehow.
I always understood DMA to mean stuff like data transfers between memory and peripherals taking place independently of the CPU. I can't see how that will work on the Propeller, as it has no peripherals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Leon: so do I normally, but in the Prop world every thing is topsy turvy [noparse]:)[/noparse]
jrjr: Yes, that's a great idea, a hand full of logic blocks, somewhat like in FPGAs, that could be "wired" up from software configuration as is done for the timers now but more flexible.
With a carefully chosen set of logic functions, shifters, registers, counters, LUTs etc I bet an awful lot of high speed logic work could be taken out of pure PASM code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have always felt that the Propeller was somewhat influenced by the SX chip, in that their goal was to implement functions in software that are normally done in hardware. And while FPGAs do this as well, they go about it in a totally different manner, but in the end, the results are the same.
Back to the original question in this thread, here is a recent thought of mine: With the deterministic nature of the prop, and it's inherent redundancy capability, I think it could do well marketed towards time sensitive/mission critical systems such as medical devices, automotive/aerospace, etc., or as a device that sort of fits between typical microcontrollers, and FPGAs/CLPDs.
FPGAs don't implement functions in software that are normally done in hardware. They are configured by the user to perform the desired hardware function. Very fast processors, much faster than the Propeller, with far more I/O, can replace FPGAs in some applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Nice idea but sadly having all your processors on one chip like the Prop is of no use in the world of "sensitive/mission critical" applications. You still have a single point of failure for many essential functions like: power supply, clock, system counter, access to hub RAM, locks...Simply having shared HUB RAM implies that one failed PASM process can bring down all the others by scribbling over any data they are using there.
As a device in the no man's land between typical processor solutions and FPGA's. Yes definitely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Funny thing about FPGA's. Now that hey have got so big and difficult to manage, is that it's quite common to put a CPU core into the hardware description and use normal software running on that to manage the thing at a high level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The DMA that I am referring to is the ability to move chunks of data around in memory, and moving data between memory and the I/O ports.· A DMA engine can be implemented in a cog to perform these functions.· The main thing is that it does not impact the main processor.
Sorry to carry this on in this thread - probably should start another. But it is an interesting subject despite the "bias" towards Another Company by some participants
heater said...
That "software specialization" as mostly know today is just a way of dealing with the limited Von Newman style hardware we have. It is a subset of the world where David May and the CSP guys have been living for thirty years.
I think you just keep making my point for me over and over. After thirty years, it should surely be clear that trying to solve the problems of parallelism simply by offering new and novel hardware is (to say the least) being bravely optimistic.
There are quite strong parallels here with the limited success rate cognitive scientists have had in trying to model the brain (another massively parallel system) using neural networks. Sounds great in theory - trouble is it just doesn't appear to be much use in practice. In neural science you can tackle the problem from below (neural networks) or from above (expert systems) - the abject failure of both approaches seems to indicate that there is a bunch of really complex stuff going on in the middle that we simply don't "get" yet (but of course neither side will ever admit!).
Continuing to use the terms lower and upper (rather than hardware and software), INMOS failed because it took the lower approach, but there were very few uses for their technology - certainly no cost-effective ones! The upper approach, on the other hand, is the one embodied by the various systems and languages developed since that implement pure software models of parallelism - often independent of the hardware on which they run. I agree that none of these models are particularly good - but they are well understood, and they do quite useful things.
(NOTE: Getting back to Leon's original assertion - do hardware engineers understand the lower models better than software engineers? Well, does it really matter since they aren't particularly useful to other people anyway? Do hardware engineers understand the upper models better than software engineers? There's no evidence to suggest any such thing!)
That the successor to INMOS now uses hardware based on FPGAs instead of Transputers is a bit irrelevant - this may help them bring the price per unit of hardware down, but their success does not depend on that - it depends on whether they can get their XC language to make effective use of their hardware. Why? Because most engineers (hardware and software) are already using the various upper or software-oriented models of parallelism quite happily. They either can't or don't want to use the lower ones.
Finally - to make a Sisyphean attempt to bring this thread back on topic - I think Parallax's success to date is because SPIN is quite a useful upper approach to parallelism - i.e. parallelism that can actually be effectively used by us mere mortals. Parallax's future success (just like the-company-that-dare-not-speak-its-name) will depend not on better hardware, but on putting this same power in the hands of the massive volume of users out there who are (for whatever reason) either unable or unwilling to use SPIN.
Whew!
</SeriouslyOffTopic>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH said...
That the successor to INMOS now uses hardware based on FPGAs instead of Transputers is a bit irrelevant - this may help them bring the price per unit of hardware down, but their success does not depend on that - it depends on whether they can get their XC language to make effective use of their hardware. Why? Because most engineers (hardware and software) are already using the various upper or software-oriented models of parallelism quite happily. They either can't or don't want to use the lower ones.
Ross, the part of your quote that I highlighted is also applicable to the Propeller.
I'm not sure how "parallel" the Propeller really is. Many of the discussions here point to limited scalability of the design. So compared to a BS2, it's super parallel. Compared to something like say, CUDA, not so much.
Now, I'm not saying that my statement is correct, but if we assume that it has merit, and that the Propeller lives in some computing space between non-parallel and highly-parallel, then the question becomes "How many design engineers work in that computing space, and how do you reach them?"
The challenge in reaching these engineers is that they can start with non-parallel and scale upwards, or highly-parallel and scale downwards, and arrive at roughly the same location that the Propeller sits at.
Post Edited (Kevin Wood) : 7/21/2010 6:14:01 AM GMT
Yes, I agree. I know not everyoune shares my opinion, but for me the big selling point of the Prop is that it offers simple - and very elegant - access to parallelism.
And the really big advantage the Prop has over anything else out there is that (provided you're willing to stick to SPIN) it does it without a complex operating system and via a very simple language.
I think that getting the same simplicity into C (but without going the non-standard XC route) could be the next "big thing" for the Prop. Actually, the more I look into it, the more I am coming to the view that for the Propeller, Cilk may be the answer.
Ross.
P.S. Technically, I guess the the Prop is an 8-way "symmetric multiprocessor" (SMP) rather than the "multi-core" processor (which is a term we often bandy about). But there's no doubt it is true parallelism.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yep. Use of the "multi-core" term dilutes the product, IMHO. I like the word concurrent here too.
The simple, low overhead SPIN is fantastic. There is a pretty ugly drop off after that though. Look at all these efforts to reach level II. Perhaps some more effort will yield some middle ground for those who need more.
I've made the point before that C is not very different from Spin. Both languages work at a similar level and both have very similar functionality including parameters passing by value (with C's use of arrays and structures passed by reference being a special case of pass by value). It wouldn't take much to have a C compiler generate Spin bytecodes with very little in the way of changes or extensions needed. Obviously, an interpreter optimized for C would do better.
Most of what functionally differentiates Spin from C could be implemented either using C macros if there was a C statement or pragma to generate Spin bytecodes directly. Many of the Spin operators could be added to C as a kind of "syntactic sugar" while maintaining C compatibility (other than the acceptance of those extensions).
The big difference is that C comes with a very large library of subroutines and functions that are part of the standard. You can force the compiler to not use the library, but it's not pretty and not the default and it makes a lot of assumptions about what hardware is available. A really good optimizing compiler can minimize what gets dragged in, but the C user has to be careful about how things are written.
One area where hardware and software have evolved together and become a widely accepted form of massive parallelism is shaders for graphics cards on PC/Mac/Consoles. Instead of writing a single program that does all of the parallel work, you write programs that just focus on one piece (vertex, primitive, or pixel fragment) and the hardware takes care of running many instances (100s or 1000s) of that program in parallel for you. With recent generations of hardware and software they have moved pretty much fully into the general purpose realm instead of being graphics centric.
Also, over the last 3-4 years my job has moved from building code that runs on single core machines in one or two threads, to code that runs on dual and quad core machines with 8 to 16 (or even more) threads. We "do it the hard way" and just split up our tasks in such a way that they can run semi-independantly in a thread. Like doing character animations. Each character can be processed independantly so we can spawn threads to process several at a time. Simlarly with particle effects, or processing the scripts (lua) for non-player character behaviors, or loading in data from disk. Of course we do all this in C++ and there are a lot of hassles you havbe to deal with like mutex/semephores, avoiding race conditions between threads, starvation and so on.
It's not unlike with the Prop where you load up different cogs with different code/drivers for whatever you want. The main bonus with the Prop is there is a lot less of the hassles involved compared with threading on the PC/Mac/Console CPUs.
One of the key features that makes it easier on the prop is how the hub and cogs interact. Only one cog at a time can access the shared hub memory, and it happens in order at a specific rate. It makes it trivial to coordinate.
Anyway, the more I think about it, the more I dislike trying to cram C into a Prop. For any decently sized/complex project, anyone willing to spend a small amount of time to learn spin/pasm will produce better results with less code and less time spent overall.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Something like a Prop2 with FPGA attributes thrown in would
be incredible. I so want to get my feet wet with FPGA tech.
I got a book but it really sucks :-( either that or it's just too
much for me to figure out.
This thread is really starting to get interesting.
I have been thinking that the Prop might make a nice controller
for missile guidance or to help with the load in a RPV. They are
certainly cheap compared to some of the processors used in such
things. I think they could hold their own in guidance systems. The
heat/cold extremes test Parallax did was impressive and shows that
the Prop can handle a harsh environment well. I wonder how they could
stand up to moderate levels of EMP. Perhaps they could do so if the
I/O was all optically isolated so there would not be such long leads to
act as antennae?
As for Parallax making it really BIG with the Prop and Prop2 it might
come down to one single person somewhere out there that decides to
use it in a large volume product. If millions of Props started to move
then Parallax would have the resources to play in the big leagues.
Goodness I love this stuff
Israel got the OK a few days ago to integrate their
own control systems and comm stuff into the F35... everyone here
was talking about it the last 2 days...makes me really wish I was an EE.
No way they would let me work on that stuff.
@Mike Green
I really enjoy coding in C, It sounds like you do as well. I'm always glad
though that I can go in and tweak the compiled C at the asm level..that
has helped me out several times when using gcc for the AVR. Now we have
Catalina and we can do the same thing since it's open source...although I
have barely played with Catalina so far... I need lots more free time, darn it.
This thread seems destined to be one that presses all my buttons!
The point you make comes up quite regularly (and no, not just from you!). It's certainly true that C and SPIN share some superficial syntax, and that C is undoubtedly one of the simplest of the high-level languages (some people would dispute that C is "high level" at all). However, C is a significantly more complex language than SPIN. And it is not just the "core" language. The ANSI C standard specifies a rich set of data types, complex preprocessing capabilities, library management, internal and external linkage requirements, visibility and scope rules, standard C libraries, etc etc - all things that are completely missing from SPIN. Also, with the added complexities come peripheral things that you can get away without in SPIN, but which you must have with C - such as source level debuggers.
Yes, you can implement a C compiler in SPIN byte codes, but the fact that no-one has seriously attempted to do so - including those who continue to insist how "easy it would be" - speaks much louder than anything I could say on the subject.
In the last year or so we have had at least 3 different versions of C developed for the Prop independently - one commercial, one open source, and one hobbyist. All take significantly different approaches to C, but I think you'll probably find that all three gave at least some thought to using the SPIN byte codes (I certainly did!) and I think all three probably dismissed it as being impractical (again, I certainly did!).
However, one way or another we're going to find out "real soon now", since I believe Parallax is making a serious attempt even as we speak to implement such a beast (i.e. "Parallax Micro C" or some variation thereof).
The one thing that it absolutely clear to me is that whatever the result is (i.e how well or poorly it performs), it must be ANSI C - not a hybrid that is merely C-like - that wouldn't benefit anyone. And that means all the C libraries as well.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Since I started my asm blog for newbies I have been considering
adding a C blog as well. When I introduce projects for the ATmega1284p
I will be programming it mostly in gcc with asm speeding up some
interrupt routines. If I add a C blog perhaps I will find the time to
put up posts using Catalina on the Prop. I sure hope Parallax does not
try to introduce a non standard flavor of C for the Prop, IMO that would
be a serious mistake.
Another feature of the "other" architecture that it shares with the transputer is scalability: arbitrary numbers of devices may be connected together via very high speed links for more processing power, and I/Os. It is unique, AFAIK.
Ultimately, the reason why the transputer didn't succeed in the market place was nothing to do with non-acceptance of the device, it was very popular, but because the T9000 successor to the T414 and T800 proved difficult to make. It really pushed the technology available at the time and ST simply couldn't afford to keep pouring money into the project.
Artificial neural nets aren't, in the main, used to model brains, but to carry out much more mundane tasks like recognising the number plates of speeding motorists, and the identification of malignant cells; a job they do very well.
BTW, the other device isn't based on FPGA technology, it's just another MCU. Because of its performance, and the large number of I/Os it can replace FPGAs in many applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
The Beanie: Keep it. Take a look at the Apple logo!
Parallel CPU's:
We are not really talking about multiple cores like Intel and AMD. The prop is a micro and the parallel nature solves the problems of off-loading the I/O and configuring the counters, etc to make Intelligent Peripherals. We still tend to see a single main program.·The Intelligent Peripherals tend to be·performing DMA (in the real sense of how DMA works) by taking data from hub and passing it out the peripheral, or visa versa. We have SD drivers, TV drivers, Keyboard drivers, and some new USB possibilities here too. This is how we are using the prop, and it is a great advantage to be able to offload the intelligence to a seperate cpu, all without the requirements of interrupts.
Noone has yet (to my knowledge anyway) come up with a true multicore application. We have discussed methods and indeed tried some (heater tried with ZiCog). Could they be made to work. No doubt they could, but currently lets push waht we have done, not what may be possible.
Once we go back to a big main thread and Intelligent Peripherals, the picture is quite clear. The main program for the professional is going to initially be C although anyone who bothers to lean spin (which is easy) could quite likely use spin easier. Let me note that spin will be slower, but speed may not be important once the time critical I/O is removed from the equation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Is C really going to be fast enough for professional users, though? Won't they have to get into assembler for many applications that they would be able to write in C on the chips they have used previously? I can't see many professional users getting into Spin.
They will expect libraries for all the peripherals they are used to having in hardware, of course, like I2C and SPI.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Yes, it is already fast enough - especially since you can so easily distribute your application across all 8 cogs. And many embedded C programmers are used to having to code some parts of their applications in assembly (drivers etc) - either for speed or space reasons. This occurs less and less as time goes on and processors get faster - but even so, in embedded applications it would not be seen as at all unusual.
Ross.
P.S. Cluso99 - Of course there's a true multicore (or more accurately SMP) application for the Propeller - the "dining philosophers" example provided with Catalina! It runs symmetrically on 5 cogs, using the others for peripherals (primarily the display). While it does indeed have a "main" cog, it would be fairly simple to reprogram the example to also use the main cog and therefore run symmetrically on 6 cogs. Ok, it's not a very useful application - but you never said it had to be
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Leon said...
Is C really going to be fast enough for professional users, though? Won't they have to get into assembler for many applications that they would be able to write in C on the chips they have used previously?
Yes (and no), and here's why:
As Ross has pointed out many times before, if you are writing some code that will be significantly bigger that what can fit in a COG then you are forced by the Prop architecture to use overlays or LMM or an interpreter like Spin. There is no way around that it's fundamental to the Prop architecture and the 512 LONG COG space.
Further, if that program uses data that will not fit in COG (It almost certainly does as there was no room for code already) then you are doing a lot of [noparse][[/noparse]rd|wr][noparse][[/noparse]long|word|byte] to access that data in HUB.
The conclusion is that for this big (on the COG scale of things) program you are already hobbled by the need for HUB code and data access, the messing with LMM/overlays/interpreter. Your program will never approach anything like the 20 MIPs that you might expect if the whole thing could somehow magically fit in COG.
It does not matter if you use a high level language like C or Spin or if you use hand crafted assembler. Those severe road blocks are still in place.
As Ross maintains, for large programs LMM is pretty much down to the metal native for the Prop. So like any other CPU if your program is large you will want to use a high level language like C instead of hand crafting your own LMM program.
For such "big" programs compiling to raw COG PASM does not help.
Of course for such "big" programs our mythical "professional" MCU developer may just sneer and say "the Prop is too slow" compared to other micro X,Y,Z. And in many cases he'd be right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I am not convinced that specifications alone will do the trick. I bought the demo board out of sheer curiosity, and went through the manual. Just as it started to get to the interesting part -- applications -- the book switched over to the command description section. A small handbook like Radio Shack's Engineering Handbooks would be a plus.
The cutesy cap is not conducive to a professional look.
uChip & TI have product seminars at their distributors' offices. Perhaps something like that could be done for the Prop. The first seminar could be "Why in the world should I switch to the Propeller???" Attendees get simple development boards to explore the new micro.
Way back when the different micro manufacturers had comparison charts, basically saying, "All other micros suck at ____" for a number of processes. I was impressed by Nat'l. Semi. when their charts showed that their product was NOT the best at some process or another. (I don't remember which it was, it may have been software multiply or divide, or maybe a block move?)
I think what also needs to be emphasized is the niche Parallax hopes for the Prop to fill. And then show how it is better than any competitive products at doing it.
--Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 8:49:12 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
On the one hand it's might come over a frivolous and "not business like". Which I might have thought of as negative point if you want to play with the "professionals".
On the other hand, I am now holding in my hands 400 Euros worth of technology which is selling around the world in millions. Guess what? The logo associated with the user interface software is a green alien looking robot and that of the OS kernel is a cartoon caricature of a penguin bloated on herring. An awful lot of big shots have had a hand in that system from IBM downwards, despite the juvenile logos. The logos don't seem to stop a world full of developers jumping on the bandwagon.
Actually I just got an invite to the Embedded Live conference at London's Earls Court where they featuring seminars on using Android (green space robot) for embedded systems that need displays and such.
My conclusion: The Propeller beanie is quite acceptable anywhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Prop I
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
Prop II
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
- Single cycle multiply
- Support 1024x768 24-bit graphics
- Support 1080p
- Glueless interface to DDR memory
Missing features
- HDMI input and output
- High-speed instruction and data cacheing
- Low cost
Any kind of instruction/data caching is not conducive to 100% deterministic timing of code execution. If an app really insists on caches for, whatever reason, or can tolerate the timing chaos they cause then Prop or chips like it are not targeted at that problem domain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
with the embedded {embedded} core capability, and some easy video.
It sure does triple back flips in the lab, but I don't know how I'd sell them in quantity.
I think the next level will go to the company that exposes the metal to the programmer
ala FPGA in a simpler subset of SystemC etc; without all the FPGA headaches.
This hardware is available now, but the NRE is the current killer.
I'm sure that the Engineering Community at Parallax has seen this, but may be as
stumped as me as to it's (practical) implementation.
I guess I'd say: Chip, if you've got spare gates, push an array of them up for me, somehow.
jr
(sic em' Leon)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
jrjr: Yes, that's a great idea, a hand full of logic blocks, somewhat like in FPGAs, that could be "wired" up from software configuration as is done for the timers now but more flexible.
With a carefully chosen set of logic functions, shifters, registers, counters, LUTs etc I bet an awful lot of high speed logic work could be taken out of pure PASM code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Back to the original question in this thread, here is a recent thought of mine: With the deterministic nature of the prop, and it's inherent redundancy capability, I think it could do well marketed towards time sensitive/mission critical systems such as medical devices, automotive/aerospace, etc., or as a device that sort of fits between typical microcontrollers, and FPGAs/CLPDs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 10:59:25 PM GMT
As a device in the no man's land between typical processor solutions and FPGA's. Yes definitely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Dave
Sorry to carry this on in this thread - probably should start another. But it is an interesting subject despite the "bias" towards Another Company by some participants
I think you just keep making my point for me over and over. After thirty years, it should surely be clear that trying to solve the problems of parallelism simply by offering new and novel hardware is (to say the least) being bravely optimistic.
There are quite strong parallels here with the limited success rate cognitive scientists have had in trying to model the brain (another massively parallel system) using neural networks. Sounds great in theory - trouble is it just doesn't appear to be much use in practice. In neural science you can tackle the problem from below (neural networks) or from above (expert systems) - the abject failure of both approaches seems to indicate that there is a bunch of really complex stuff going on in the middle that we simply don't "get" yet (but of course neither side will ever admit!).
Continuing to use the terms lower and upper (rather than hardware and software), INMOS failed because it took the lower approach, but there were very few uses for their technology - certainly no cost-effective ones! The upper approach, on the other hand, is the one embodied by the various systems and languages developed since that implement pure software models of parallelism - often independent of the hardware on which they run. I agree that none of these models are particularly good - but they are well understood, and they do quite useful things.
(NOTE: Getting back to Leon's original assertion - do hardware engineers understand the lower models better than software engineers? Well, does it really matter since they aren't particularly useful to other people anyway? Do hardware engineers understand the upper models better than software engineers? There's no evidence to suggest any such thing!)
That the successor to INMOS now uses hardware based on FPGAs instead of Transputers is a bit irrelevant - this may help them bring the price per unit of hardware down, but their success does not depend on that - it depends on whether they can get their XC language to make effective use of their hardware. Why? Because most engineers (hardware and software) are already using the various upper or software-oriented models of parallelism quite happily. They either can't or don't want to use the lower ones.
Finally - to make a Sisyphean attempt to bring this thread back on topic - I think Parallax's success to date is because SPIN is quite a useful upper approach to parallelism - i.e. parallelism that can actually be effectively used by us mere mortals. Parallax's future success (just like the-company-that-dare-not-speak-its-name) will depend not on better hardware, but on putting this same power in the hands of the massive volume of users out there who are (for whatever reason) either unable or unwilling to use SPIN.
Whew!
</SeriouslyOffTopic>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross, the part of your quote that I highlighted is also applicable to the Propeller.
I'm not sure how "parallel" the Propeller really is. Many of the discussions here point to limited scalability of the design. So compared to a BS2, it's super parallel. Compared to something like say, CUDA, not so much.
Now, I'm not saying that my statement is correct, but if we assume that it has merit, and that the Propeller lives in some computing space between non-parallel and highly-parallel, then the question becomes "How many design engineers work in that computing space, and how do you reach them?"
The challenge in reaching these engineers is that they can start with non-parallel and scale upwards, or highly-parallel and scale downwards, and arrive at roughly the same location that the Propeller sits at.
Post Edited (Kevin Wood) : 7/21/2010 6:14:01 AM GMT
Yes, I agree. I know not everyoune shares my opinion, but for me the big selling point of the Prop is that it offers simple - and very elegant - access to parallelism.
And the really big advantage the Prop has over anything else out there is that (provided you're willing to stick to SPIN) it does it without a complex operating system and via a very simple language.
I think that getting the same simplicity into C (but without going the non-standard XC route) could be the next "big thing" for the Prop. Actually, the more I look into it, the more I am coming to the view that for the Propeller, Cilk may be the answer.
Ross.
P.S. Technically, I guess the the Prop is an 8-way "symmetric multiprocessor" (SMP) rather than the "multi-core" processor (which is a term we often bandy about). But there's no doubt it is true parallelism.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The simple, low overhead SPIN is fantastic. There is a pretty ugly drop off after that though. Look at all these efforts to reach level II. Perhaps some more effort will yield some middle ground for those who need more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Most of what functionally differentiates Spin from C could be implemented either using C macros if there was a C statement or pragma to generate Spin bytecodes directly. Many of the Spin operators could be added to C as a kind of "syntactic sugar" while maintaining C compatibility (other than the acceptance of those extensions).
The big difference is that C comes with a very large library of subroutines and functions that are part of the standard. You can force the compiler to not use the library, but it's not pretty and not the default and it makes a lot of assumptions about what hardware is available. A really good optimizing compiler can minimize what gets dragged in, but the C user has to be careful about how things are written.
Also, over the last 3-4 years my job has moved from building code that runs on single core machines in one or two threads, to code that runs on dual and quad core machines with 8 to 16 (or even more) threads. We "do it the hard way" and just split up our tasks in such a way that they can run semi-independantly in a thread. Like doing character animations. Each character can be processed independantly so we can spawn threads to process several at a time. Simlarly with particle effects, or processing the scripts (lua) for non-player character behaviors, or loading in data from disk. Of course we do all this in C++ and there are a lot of hassles you havbe to deal with like mutex/semephores, avoiding race conditions between threads, starvation and so on.
It's not unlike with the Prop where you load up different cogs with different code/drivers for whatever you want. The main bonus with the Prop is there is a lot less of the hassles involved compared with threading on the PC/Mac/Console CPUs.
One of the key features that makes it easier on the prop is how the hub and cogs interact. Only one cog at a time can access the shared hub memory, and it happens in order at a specific rate. It makes it trivial to coordinate.
Anyway, the more I think about it, the more I dislike trying to cram C into a Prop. For any decently sized/complex project, anyone willing to spend a small amount of time to learn spin/pasm will produce better results with less code and less time spent overall.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Your post is brilliant!
Something like a Prop2 with FPGA attributes thrown in would
be incredible. I so want to get my feet wet with FPGA tech.
I got a book but it really sucks :-( either that or it's just too
much for me to figure out.
This thread is really starting to get interesting.
I have been thinking that the Prop might make a nice controller
for missile guidance or to help with the load in a RPV. They are
certainly cheap compared to some of the processors used in such
things. I think they could hold their own in guidance systems. The
heat/cold extremes test Parallax did was impressive and shows that
the Prop can handle a harsh environment well. I wonder how they could
stand up to moderate levels of EMP. Perhaps they could do so if the
I/O was all optically isolated so there would not be such long leads to
act as antennae?
As for Parallax making it really BIG with the Prop and Prop2 it might
come down to one single person somewhere out there that decides to
use it in a large volume product. If millions of Props started to move
then Parallax would have the resources to play in the big leagues.
Goodness I love this stuff
Israel got the OK a few days ago to integrate their
own control systems and comm stuff into the F35... everyone here
was talking about it the last 2 days...makes me really wish I was an EE.
No way they would let me work on that stuff.
@Mike Green
I really enjoy coding in C, It sounds like you do as well. I'm always glad
though that I can go in and tweak the compiled C at the asm level..that
has helped me out several times when using gcc for the AVR. Now we have
Catalina and we can do the same thing since it's open source...although I
have barely played with Catalina so far... I need lots more free time, darn it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
justasm.blogspot.com/
This thread seems destined to be one that presses all my buttons!
The point you make comes up quite regularly (and no, not just from you!). It's certainly true that C and SPIN share some superficial syntax, and that C is undoubtedly one of the simplest of the high-level languages (some people would dispute that C is "high level" at all). However, C is a significantly more complex language than SPIN. And it is not just the "core" language. The ANSI C standard specifies a rich set of data types, complex preprocessing capabilities, library management, internal and external linkage requirements, visibility and scope rules, standard C libraries, etc etc - all things that are completely missing from SPIN. Also, with the added complexities come peripheral things that you can get away without in SPIN, but which you must have with C - such as source level debuggers.
Yes, you can implement a C compiler in SPIN byte codes, but the fact that no-one has seriously attempted to do so - including those who continue to insist how "easy it would be" - speaks much louder than anything I could say on the subject.
In the last year or so we have had at least 3 different versions of C developed for the Prop independently - one commercial, one open source, and one hobbyist. All take significantly different approaches to C, but I think you'll probably find that all three gave at least some thought to using the SPIN byte codes (I certainly did!) and I think all three probably dismissed it as being impractical (again, I certainly did!).
However, one way or another we're going to find out "real soon now", since I believe Parallax is making a serious attempt even as we speak to implement such a beast (i.e. "Parallax Micro C" or some variation thereof).
The one thing that it absolutely clear to me is that whatever the result is (i.e how well or poorly it performs), it must be ANSI C - not a hybrid that is merely C-like - that wouldn't benefit anyone. And that means all the C libraries as well.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Since I started my asm blog for newbies I have been considering
adding a C blog as well. When I introduce projects for the ATmega1284p
I will be programming it mostly in gcc with asm speeding up some
interrupt routines. If I add a C blog perhaps I will find the time to
put up posts using Catalina on the Prop. I sure hope Parallax does not
try to introduce a non standard flavor of C for the Prop, IMO that would
be a serious mistake.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
justasm.blogspot.com/
Another feature of the "other" architecture that it shares with the transputer is scalability: arbitrary numbers of devices may be connected together via very high speed links for more processing power, and I/Os. It is unique, AFAIK.
Ultimately, the reason why the transputer didn't succeed in the market place was nothing to do with non-acceptance of the device, it was very popular, but because the T9000 successor to the T414 and T800 proved difficult to make. It really pushed the technology available at the time and ST simply couldn't afford to keep pouring money into the project.
Artificial neural nets aren't, in the main, used to model brains, but to carry out much more mundane tasks like recognising the number plates of speeding motorists, and the identification of malignant cells; a job they do very well.
BTW, the other device isn't based on FPGA technology, it's just another MCU. Because of its performance, and the large number of I/Os it can replace FPGAs in many applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/21/2010 5:39:29 AM GMT
Parallel CPU's:
We are not really talking about multiple cores like Intel and AMD. The prop is a micro and the parallel nature solves the problems of off-loading the I/O and configuring the counters, etc to make Intelligent Peripherals. We still tend to see a single main program.·The Intelligent Peripherals tend to be·performing DMA (in the real sense of how DMA works) by taking data from hub and passing it out the peripheral, or visa versa. We have SD drivers, TV drivers, Keyboard drivers, and some new USB possibilities here too. This is how we are using the prop, and it is a great advantage to be able to offload the intelligence to a seperate cpu, all without the requirements of interrupts.
Noone has yet (to my knowledge anyway) come up with a true multicore application. We have discussed methods and indeed tried some (heater tried with ZiCog). Could they be made to work. No doubt they could, but currently lets push waht we have done, not what may be possible.
Once we go back to a big main thread and Intelligent Peripherals, the picture is quite clear. The main program for the professional is going to initially be C although anyone who bothers to lean spin (which is easy) could quite likely use spin easier. Let me note that spin will be slower, but speed may not be important once the time critical I/O is removed from the equation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
They will expect libraries for all the peripherals they are used to having in hardware, of course, like I2C and SPI.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/21/2010 6:46:30 AM GMT
Yes, it is already fast enough - especially since you can so easily distribute your application across all 8 cogs. And many embedded C programmers are used to having to code some parts of their applications in assembly (drivers etc) - either for speed or space reasons. This occurs less and less as time goes on and processors get faster - but even so, in embedded applications it would not be seen as at all unusual.
Ross.
P.S. Cluso99 - Of course there's a true multicore (or more accurately SMP) application for the Propeller - the "dining philosophers" example provided with Catalina! It runs symmetrically on 5 cogs, using the others for peripherals (primarily the display). While it does indeed have a "main" cog, it would be fairly simple to reprogram the example to also use the main cog and therefore run symmetrically on 6 cogs. Ok, it's not a very useful application - but you never said it had to be
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes (and no), and here's why:
As Ross has pointed out many times before, if you are writing some code that will be significantly bigger that what can fit in a COG then you are forced by the Prop architecture to use overlays or LMM or an interpreter like Spin. There is no way around that it's fundamental to the Prop architecture and the 512 LONG COG space.
Further, if that program uses data that will not fit in COG (It almost certainly does as there was no room for code already) then you are doing a lot of [noparse][[/noparse]rd|wr][noparse][[/noparse]long|word|byte] to access that data in HUB.
The conclusion is that for this big (on the COG scale of things) program you are already hobbled by the need for HUB code and data access, the messing with LMM/overlays/interpreter. Your program will never approach anything like the 20 MIPs that you might expect if the whole thing could somehow magically fit in COG.
It does not matter if you use a high level language like C or Spin or if you use hand crafted assembler. Those severe road blocks are still in place.
As Ross maintains, for large programs LMM is pretty much down to the metal native for the Prop. So like any other CPU if your program is large you will want to use a high level language like C instead of hand crafting your own LMM program.
For such "big" programs compiling to raw COG PASM does not help.
Of course for such "big" programs our mythical "professional" MCU developer may just sneer and say "the Prop is too slow" compared to other micro X,Y,Z. And in many cases he'd be right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/21/2010 8:02:47 AM GMT