It can generate video in software, no hardware support is required (apart from the usual resistors). The resolution will be limited, though, without external memory, as there is only 64k of RAM per core. I don't think that anyone has bothered with NTSC or PAL, although our own Ale has written code for VGA:
He just uses a buffer chip and a few resistors. Quite a lot of code is needed, of course, as there is no hardware support.
Each core has eight hardware threads that switch in one (400 MHz) clock. Assigning code to threads and cores isn't any harder than using cogs on the Propeller.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Leon, if XMOS is capable of generating video in software the guys who make the chip don't seem to be aware of it. Maybe you should let them know that it would be a good idea to mention it on their website. It seems like a much more complicated architecture if you want to do stuff like that, since you've got to do something about those stolen clocks and threads being switched rather than having a slower but totally dedicated and timing-determinant core devoted to the task. Here there are no complicated considerations; you go to the obex and there are ten video drivers with different capabilities, any of which a total n00b can download for free and get running on his $25 protoboard in about half an hour. You can even run two or three of them at the same time. Also, a 400 MHz part is going to use a lot more power than an 80 MHz 350 nm part, making it much less suited for portable and battery powered applications. (Look how fast the batteries die on smart phones with CPU's in that range.) So while the XMOS does target some of the Prop's capabilities, I see it as a more complicated solution aimed at a market with much higher end needs than Parallax is targeting.
On edit: Followed Leon's link. Generating video does require a dedicated core as I guessed, meaning you need a minimum 2-core chip. The only way to get those for prices comparable to a P8X32A seems to be to buy several hundred of them. And as for plugging 3 resistors into your breadboard to make a second video channel for debugging ... LOL.
Post Edited (localroger) : 2/7/2010 4:10:10 PM GMT
The XMOS chips are completely software-driven, making them usable in virtually any application. They can even be used to replace FPGAs because of their speed and 100% deterministic operation, with programs written in XC. Applications are scalable - if one chip hasn't got enough processing power one just adds one or more chips, with cores and threads communicating via very fast XLinks.
I don't know what you mean by "stolen clocks", and why is switching threads bad? Threads can access memory without any delays, unlike Propeller cogs, and switch much faster, in a single clock.
I agree that XMOS devices are intended for high-end applications, but there are lots of hobbyists and students using them, including many Propeller users. The XC and C compilers are very efficient, there isn't usually any need to use assembler as is often the case with the Propeller.
Most people using graphics with the XMOS chips use an LCD panel, driving it directly. They are mainly used in deeply embedded systems and that sort of display makes a lot more sense than a large TV or monitor.
A video channel isn't needed for debugging, just a $50 XTAG-2 JTAG interface whch contains a single-core XMOS chip communicating with the PC using high-speed USB (480 Mbit/s). Debugging XMOS programs is *much* easier than on the Propeller - one can single step through the program, and examine variables, etc. without using up any on-chip resources or having to load any software.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
The XMOS thread switching is done in hardware so there is no traditional overhead of context switching.
The down side is that if you create an object (thread) that requires the full power of a core then adding any other threads to that core will cause your object to fail as the execution time has to be shared. In this way just grabbing a useful looking piece of code and throwing it in is not as easy as grabbing something from OBEX and throwing it at a COG. This will remain true until XMOS ramps up to 8 or more cores in a device.
Now if I understand correctly Chip is going to add a similar hardware scheduled threading capability to the Prop II Cogs.
Really, though, we've been through this debate a few time already. Prop and XMOS just live in different worlds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So, is the design for the Prop II proceeding with 3 banks of I/O pins (plus 8 boot/communications-related pins) as announced back in December during the list of "final specifications" (which seemed quite ideal), or has there been a change? Maybe I didn't get the memo (missed a thread). Beua's comment seems to suggest that we're down to 64 (from the 96), unless he's leaving out a bank of 32 that is handled differently, somehow, which seems doubtful...as Chip had said that all of the full banks would be handled the same. Prior to this thread, I was assuming 24 I/O pins per side (on average), for a total of 96, not counting the boot/comm pins. Naturally, I'm referring to just one Prop II, not two of them tied together. It's great that we'll be able to do high-speed communication between Prop II's, but I thought one of the reasons for having 96 I/O's was to generally obviate the need for multiple CPUs, allowing simpler designs. Of course, if dropping down to two banks is the only way to get the chip out on time or at all, then so be it (but those "extra" 32 I/O's would really come in handy, especially for certain video applications). Who knows, maybe there's been some kind of a package change. Anyway, I figured the Forum would jump all over mctrivia's question about this, so I waited a half day to post hoping this would get resolved. But, seeing that it's Super Bowl Sunday and the fact that XMOS education is apparently required reading for Prop users, there's been no resolution so far. Perhaps tomorrow.
I think that a simple video system could be implemented in a couple of threads.
Threads can only run at 100/50 MIPS. Adding another thread shouldn't affect an existing one.
Yes, it looks like the Propeller II will have hardware threads as well. Chip was impressed by the XMOS XLink communication technique, but I don't think he will be implementing that.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
The guy who wrote the XMOS video driver says it requires a dedicated core. That is 50% of the capacity of a chip that is considerably more expensive than the P8X32A. The P8X32A requires 12% of its capacity to generate video, and can generate more than one video feed if you want, using considerably less code because of the built-in hardware support. It would appear that the answer to my original question is NO, even XMOS does not do all the stuff I specified at the price the Propeller does. XMOS is probably closer than anything else out there, but at the Prop's price point it can't do what the Prop does. (It can do other things the Prop can't, such as emulate USB. Credit where credit is due.)
Also, it appears that resistor only video out draws more current from the XMOS output pins than they are technically rated for. It is within the design current capacity of Prop pins.
I am here because of the YBOX2, in turn via hackaday.com. This device crammed the core functionality of a broad class of I/O devices I see every day into an Altoids tin using a commodity display. When I saw what was possible with so little hardware and such simple software, I instantly realized that it changed everything. It has allowed me to build custom hardware for many jobs at a fraction of the cost of commodity industrial controls that don't work as well and are harder to program and work on. While XMOS has its own obvious strengths, it can't do for me what the Propeller does.
Every few months I take a look at Xmos... I must admit all those MIPS are tempting.
BUT
I then look at the increased development AND deployment complexity (SMT).
The higher "barrier to entry" software wise (their compiler) AND development tool wise.
Bottom line: I'd use Xmos if a client required it, or if I had an application that cried out for it.
Until then, I will continue to wring even more out of the Propeller - and wait for Propeller II. I think Propeller (1) will do extremely well even Propeller 2 is out, because you simply cannot beat the simplicity of a 40 pin DIP, an 8 pin dip, and a crystal (ok, and a couple of bypass caps) - that can with just a few resistors do NTSC/PAL, VGA, PS/2 keyboard and mouse, audio, and much more.
Not to mention Parallax's excellent support and this forum!
localroger said...
The guy who wrote the XMOS video driver says it requires a dedicated core. That is 50% of the capacity of a chip that is considerably more expensive than the P8X32A. The P8X32A requires 12% of its capacity to generate video, and can generate more than one video feed if you want, using considerably less code because of the built-in hardware support. It would appear that the answer to my original question is NO, even XMOS does not do all the stuff I specified at the price the Propeller does. XMOS is probably closer than anything else out there, but at the Prop's price point it can't do what the Prop does. (It can do other things the Prop can't, such as emulate USB. Credit where credit is due.)
Also, it appears that resistor only video out draws more current from the XMOS output pins than they are technically rated for. It is within the design current capacity of Prop pins.
I am here because of the YBOX2, in turn via hackaday.com. This device crammed the core functionality of a broad class of I/O devices I see every day into an Altoids tin using a commodity display. When I saw what was possible with so little hardware and such simple software, I instantly realized that it changed everything. It has allowed me to build custom hardware for many jobs at a fraction of the cost of commodity industrial controls that don't work as well and are harder to program and work on. While XMOS has its own obvious strengths, it can't do for me what the Propeller does.
I came over to the Prop from AVRs, which per core have about the same grunt. I was getting nowhere slowly with ethernet stuff and saw a reference to the Propeller in the YBOX2. I have a drawfull of lonely AVRs now. The inbuilt functions of the Prop will never suit all, but WOW, doesn't it get close to 99% of the hobbyist's/small manurfacturer's everyday problems.
Fantastic specifications only stay fantastic until the next best thing comes along, so until I get to learn half of this chips capabilities I am staying away from the "better stuff" ( unless that Xilinx rep comes over with that Virtex5/6 dev bd )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
It only took two threads on one core and there is plenty of memory left. There are other demos, including one running on an XS1-L1. The chap with a bald head is Prof. David May, FRS, who is responsible for the XMOS architecture.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
It only took two threads on one core and there is plenty of memory left. There are other demos, including one running on an XS1-L1. The chap with a bald head is Prof. David May, FRS, who is responsible for the XMOS architecture.
Leon
...but it required an external DAC chip.·
Leon,
You know why a lot of people here react to you the way they do when you bring up XMOS?· It's because you bring it up ALL the time.· I can't even remember a thread you were involved in that didn't have you bringing up the XMOS chip.· This is a Propeller forum run by the company that makes the Propeller. We come here to discuss the Propeller. The rare mention of other MCUs is fine, but you seem to look for every possible chance you can find to bring up XMOS chips. It get's old. Just because someone says something that you think could be replied to with something about XMOS chips doesn't mean you should do it here. Perhaps you could PM the person with a suggestion if they are seeking other MCUs.
I think it's great that you like the XMOS chips, and it's awesome that you want to discuss them with people. However, I would prefer you picked a more appropriate forum for that.
· Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Leon, that xcores demo is clearly using an external DAC. My whole point is that the Prop does not need active external components at all to generate not one but multiple streams of either VGA or NTSC video.
I obviously can't say that XMOS *can't* generate multiple video streams per core, but based on what I've seen I think I can say that it's a lot more complicated than doing the same thing with the Prop. To generate video you have to feed data out in a very measured way, very quickly. That is not consistent with the idea of thread switching, even if you switch threads in hardware very fast. Obviously there are "event driven" ways to switch threads very quickly, but as Bill says it doesn't look like you can just toss the video driver in there and expect it to play nice with other random processes. And on the Prop, you can.
localroger: When we speak of switching threads in hardware in XMOS and I believe also for the Prop II it does not mean the traditional "do some instructions from one thread, then do some instructions from another, with a bit of a gap between the two for context switching".
Rather it means two or more thread running with their instruction executions interleaved and each with its own set of registers. So apart from the fact that two threads may run half as fast as one, they have timing determinism.
I'm quite looking forward to this on Prop II as it makes it easier to combine tasks that don't require so much speed into a single COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm one of the guys who has actually built an Xmos board with a VGA video output and to clarify things the video was generated in two threads driving a R-2R DAC (similar way to the propeller) and not an external chip. The same video software engine drives a NTSC TV output when used with a 28.63636 MHz oscillator (we would have PAL as well if we could find a 35.46895 MHz oscillator). I'm not pushing Xmos but my blog has various pics of the Xmos boards doing their stuff.
TonyD,
Sorry for my mistake. It was really hard to tell with the low quality video, and I was going by the text in the blog that just said something like "I had the DAC hooked up backwards" which led me to believe it was a DAC chip. In any case the video shows what looks like a lot more than 8 resisters and a VGA port hooked up to the xmos board (which I looked up on their site as being $149, and the cheapest one they had was $99).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
heater, if you are talking about context switching you are talking about context switching. The XMOS pitch is that they can do context switching very fast, but they still have to do context switching because the core can only do one thing at a time, and if it's running one of its other threads it's not running yours. Now they could have some very fancy tricks to switch threads in fast enough to do video, but that would be *very* fancy. In the Prop there is no context switching at all; each process gets its own dedicated CPU. It is completely independent of what the other 7 CPUs are doing. This is obviously NOT how the XMOS works, and it is a very specific goal of Chip Gracey's design that makes this 80 MHz chip able to not just hold its own but do things that a 400 MHz chip cannot do.
I do not believe the XMOS is doing the kind of interleaved thing you are talking about because that would just murder its performance. It does take a clock to switch context, according to XMOS' own documentation, so the last thing you'd want to do is trigger such a switch on every single instruction. Rather it appears that XMOS provides a variety of triggers, some of them very fast, for triggering context switches. A system like that is very powerful but it's also very possible to get yourself in deep trouble in high-performance situations. Stuff like that tends to work itself out in much more obvious ways on the Prop.
Post Edited (localroger) : 2/7/2010 10:32:16 PM GMT
That code would run on the $50 XS1-L1 SFE board, with the buffer and the resistors on the prototyping area.
The XMOS architecture ensures that each thread behaves just like a separate processor. No fancy tricks are required for switching threads, it's dealt with completely transparently by the hardware, in round-robin fashion. I don't see how one can get oneself into trouble even with very high-performance systems, applications can be simulated and timings analysed and tested with the free software that XMOS provides. The 100% determinism, coupled with the very high performance, is why they can be used to replace FPGAs, with development times of a few days compared to several weeks for a typical FPGA application. The large number of I/Os - 64 per core - helps, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Leon, you do not appear to understand the significance of the idea of determinant timing. If your code is interrupted the timing is not determinant. Period. A major design point of the Propeller is that it does not support any kind of code interruption at all, which is a radical departure from the current state of the art. And context switching, even if you can do it in one clock cycle, is an interruption.
The time slice for each thread is known: "Thread execution is deterministic and hence each thread can implement a hard real-time I/O task, regardless of the behaviour of other threads." That includes inter-core and intra-core communication via channels and XLinks. The chips wouldn't be much use if that wasn't the case. Here is a good summary:
The title of this thread is "FUTURE PROPELLER CHIPS". It is not for a comparison of XMOS chips.
I am sick and tired of Leon raising the XMOS chip at every single opportunity. I have said before, Leon, what is your affiliation with XMOS?
It is one thing to discuss comparisons of chips and that another chip can do a certain function better. But this always degenerates into an XMOS chip can do this better, and it is always instigated by Leon.
Leon, please leave this thread.
Parallax: Please warn Leon. I am sick and tired of him promoting XMOS on our propeller forum, and hijacking our propeller discussions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The title of this thread is "<FONT color=red>FUTURE PROPELLER CHIPS". It is not for a comparison of XMOS chips.
I am sick and tired of Leon raising the XMOS chip at every single opportunity. I have said before, Leon, what is your affiliation with XMOS?
It is one thing to discuss comparisons of chips and that another chip can do a certain function better. But this always degenerates into an XMOS chip can do this better, and it is always instigated by Leon.
Leon, please leave this thread.
Parallax: Please warn Leon. I am sick and tired of him promoting XMOS on our propeller forum, and hijacking our propeller discussions.
You made me laugh, because this seems like children. You can not just ignore it?
If you think Leon is a "Troll" simply do not give food.
...Chip was impressed by the XMOS XLink communication technique, but I don't think he will be implementing that...
Leon, I don't know what you are talking about, but you might be right. I'm forgetting things faster than I'm learning them these days. Did you PM me about the XMOS link a while back? I seem to remember talking to you about this, but currently, I have no knowledge in my head of how it works.
For the next Propeller, there is·a chip-to-chip comm scheme that uses one pin/wire per direction, with some chip providing the master clock for everybody. It should run at about 320Mb/s - not that fast by todays LVDS standards, but useful for a lot of things.
Ignoring a troll is the correct thing to do up to a point - but it is also appropriate to suggest additional measures when they threaten to spoil the enjoyment of the forums for others. I think you can tell from Cluso's tone that he is annoyed. I also considered posting something similar, but refrained due to the reaction it normally generates.
However, I also get annoyed at Leon's persistence in promoting XMOS above and beyond what is necessary to answer the question at hand. I accept that it may be just Leon's enthusiasm for XMOS that gets him carried away, but Cluso is right - I also read this thread because I am interested in "Future Propeller Chips" in it - not stuff about XMOS. If I was interested in XMOS I'd read their forums. But even if I ignore Leon's posts, I waste time opening the thread whenever anyone responds to Leon's posts. And of course, I've now wasted everybody else's time by posting this - sorry about that.
Having the Forum moderators issue an occasional polite and generic warning to keep threads on-subject may indeed help in this case, and stop us all having to post such things again.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
localroger said...
Leon, you do not appear to understand the significance of the idea of determinant timing. If your code is interrupted the timing is not determinant.
I disagree. If your code is interrupted, but you know precisely when it is going to be interrupted (as you would in a case of round-robin threads in a deterministic fashion) then you are still deterministic. You will *always* know precisely when something is going to occur.
Now, on the other hand, the dsPIC I've been playing with has an odd quirk where interrupt response latency can vary by 1 cycle depending on if the chip has any other interrupts or exceptions pending. This *could* be deterministic if I was 100% sure that when I expect an interrupt I know precisely what the other code is doing, but it's far harder to make it so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
But if your code can be interrupted at all (even according to some predefined and deterministic round-robin schedule), then in practice it can be very difficult to figure out the timing between any two given instructions. With the Prop you just look at the instructions themselves and you have your answer - and it is constant. You don't have to worry about what other tasks are doing, or the scheduling parameters (time slice etc), or figure out how long it is to the next interrupt.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
But if your code can be interrupted at all (even according to some predefined and deterministic round-robin schedule), then in practice it can be very difficult to figure out the timing between any two given instructions. With the Prop you just look at the instructions themselves and you have your answer - and it is constant. You don't have to worry about what other tasks are doing, or the scheduling parameters (time slice etc), or figure out how long it is to the next interrupt.
Yes, it can be difficult, but then so can timing an initial hub window hit. You learn to mitigate the corner cases on any architecture you use.
Saying the XMOS is not deterministic because it uses a thread scheduler is simply not correct. It might be easier to determine your timing chain on a Propeller, but that does not make the other solution invalid.
All CPU's are deterministic, it's just that sometimes the outcome is harder to determine than others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Back to the main program, after a rude commercial at a particularly vulnerable point in propeller development.
A while back, well over a year ago, Ken put out the question about weather we would want a PortB prop (64io prop 1) in a few months, or the Prop2 sooner and skip the PortB prop, most people said in effect "forge ahead on the Prop2 and forget the PortB prop" . I for one, wish it had gone the other way. Some of the expensive external memory solutions would not have been so expensive, and many things that take 2 props now because of shortage of pins, would only take one. I don't know if anything has been done to fix the software limitation that was halting the development of the portB prop, but I sure would like one(or a dozen) 64io props right about now....or a year ago. Since the portB prop would use less power than the prop2, I hope that they eventually come out with one, although I reserve my right to change my mind when/if I see the Prop 2.
Comments
www.xmoslinkers.org/node/135
He just uses a buffer chip and a few resistors. Quite a lot of code is needed, of course, as there is no hardware support.
Each core has eight hardware threads that switch in one (400 MHz) clock. Assigning code to threads and cores isn't any harder than using cogs on the Propeller.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/7/2010 3:57:24 PM GMT
On edit: Followed Leon's link. Generating video does require a dedicated core as I guessed, meaning you need a minimum 2-core chip. The only way to get those for prices comparable to a P8X32A seems to be to buy several hundred of them. And as for plugging 3 resistors into your breadboard to make a second video channel for debugging ... LOL.
Post Edited (localroger) : 2/7/2010 4:10:10 PM GMT
I don't know what you mean by "stolen clocks", and why is switching threads bad? Threads can access memory without any delays, unlike Propeller cogs, and switch much faster, in a single clock.
I agree that XMOS devices are intended for high-end applications, but there are lots of hobbyists and students using them, including many Propeller users. The XC and C compilers are very efficient, there isn't usually any need to use assembler as is often the case with the Propeller.
Most people using graphics with the XMOS chips use an LCD panel, driving it directly. They are mainly used in deeply embedded systems and that sort of display makes a lot more sense than a large TV or monitor.
A video channel isn't needed for debugging, just a $50 XTAG-2 JTAG interface whch contains a single-core XMOS chip communicating with the PC using high-speed USB (480 Mbit/s). Debugging XMOS programs is *much* easier than on the Propeller - one can single step through the program, and examine variables, etc. without using up any on-chip resources or having to load any software.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/7/2010 4:56:43 PM GMT
The down side is that if you create an object (thread) that requires the full power of a core then adding any other threads to that core will cause your object to fail as the execution time has to be shared. In this way just grabbing a useful looking piece of code and throwing it in is not as easy as grabbing something from OBEX and throwing it at a COG. This will remain true until XMOS ramps up to 8 or more cores in a device.
Now if I understand correctly Chip is going to add a similar hardware scheduled threading capability to the Prop II Cogs.
Really, though, we've been through this debate a few time already. Prop and XMOS just live in different worlds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think that a simple video system could be implemented in a couple of threads.
Threads can only run at 100/50 MIPS. Adding another thread shouldn't affect an existing one.
Yes, it looks like the Propeller II will have hardware threads as well. Chip was impressed by the XMOS XLink communication technique, but I don't think he will be implementing that.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/7/2010 5:25:28 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Also, it appears that resistor only video out draws more current from the XMOS output pins than they are technically rated for. It is within the design current capacity of Prop pins.
I am here because of the YBOX2, in turn via hackaday.com. This device crammed the core functionality of a broad class of I/O devices I see every day into an Altoids tin using a commodity display. When I saw what was possible with so little hardware and such simple software, I instantly realized that it changed everything. It has allowed me to build custom hardware for many jobs at a fraction of the cost of commodity industrial controls that don't work as well and are harder to program and work on. While XMOS has its own obvious strengths, it can't do for me what the Propeller does.
Every few months I take a look at Xmos... I must admit all those MIPS are tempting.
BUT
I then look at the increased development AND deployment complexity (SMT).
The higher "barrier to entry" software wise (their compiler) AND development tool wise.
Bottom line: I'd use Xmos if a client required it, or if I had an application that cried out for it.
Until then, I will continue to wring even more out of the Propeller - and wait for Propeller II. I think Propeller (1) will do extremely well even Propeller 2 is out, because you simply cannot beat the simplicity of a 40 pin DIP, an 8 pin dip, and a crystal (ok, and a couple of bypass caps) - that can with just a few resistors do NTSC/PAL, VGA, PS/2 keyboard and mouse, audio, and much more.
Not to mention Parallax's excellent support and this forum!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Fantastic specifications only stay fantastic until the next best thing comes along, so until I get to learn half of this chips capabilities I am staying away from the "better stuff" ( unless that Xilinx rep comes over with that Virtex5/6 dev bd )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
This was done in an evening:
xcores.org/blog/2009/08/21/its-alive/
It only took two threads on one core and there is plenty of memory left. There are other demos, including one running on an XS1-L1. The chap with a bald head is Prof. David May, FRS, who is responsible for the XMOS architecture.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/7/2010 9:15:00 PM GMT
Leon,
You know why a lot of people here react to you the way they do when you bring up XMOS?· It's because you bring it up ALL the time.· I can't even remember a thread you were involved in that didn't have you bringing up the XMOS chip.· This is a Propeller forum run by the company that makes the Propeller. We come here to discuss the Propeller. The rare mention of other MCUs is fine, but you seem to look for every possible chance you can find to bring up XMOS chips. It get's old. Just because someone says something that you think could be replied to with something about XMOS chips doesn't mean you should do it here. Perhaps you could PM the person with a suggestion if they are seeking other MCUs.
I think it's great that you like the XMOS chips, and it's awesome that you want to discuss them with people. However, I would prefer you picked a more appropriate forum for that.
· Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I obviously can't say that XMOS *can't* generate multiple video streams per core, but based on what I've seen I think I can say that it's a lot more complicated than doing the same thing with the Prop. To generate video you have to feed data out in a very measured way, very quickly. That is not consistent with the idea of thread switching, even if you switch threads in hardware very fast. Obviously there are "event driven" ways to switch threads very quickly, but as Bill says it doesn't look like you can just toss the video driver in there and expect it to play nice with other random processes. And on the Prop, you can.
Rather it means two or more thread running with their instruction executions interleaved and each with its own set of registers. So apart from the fact that two threads may run half as fast as one, they have timing determinism.
I'm quite looking forward to this on Prop II as it makes it easier to combine tasks that don't require so much speed into a single COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
Post Edited (TonyD) : 2/7/2010 10:01:39 PM GMT
Sorry for my mistake. It was really hard to tell with the low quality video, and I was going by the text in the blog that just said something like "I had the DAC hooked up backwards" which led me to believe it was a DAC chip. In any case the video shows what looks like a lot more than 8 resisters and a VGA port hooked up to the xmos board (which I looked up on their site as being $149, and the cheapest one they had was $99).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I do not believe the XMOS is doing the kind of interleaved thing you are talking about because that would just murder its performance. It does take a clock to switch context, according to XMOS' own documentation, so the last thing you'd want to do is trigger such a switch on every single instruction. Rather it appears that XMOS provides a variety of triggers, some of them very fast, for triggering context switches. A system like that is very powerful but it's also very possible to get yourself in deep trouble in high-performance situations. Stuff like that tends to work itself out in much more obvious ways on the Prop.
Post Edited (localroger) : 2/7/2010 10:32:16 PM GMT
The XMOS architecture ensures that each thread behaves just like a separate processor. No fancy tricks are required for switching threads, it's dealt with completely transparently by the hardware, in round-robin fashion. I don't see how one can get oneself into trouble even with very high-performance systems, applications can be simulated and timings analysed and tested with the free software that XMOS provides. The 100% determinism, coupled with the very high performance, is why they can be used to replace FPGAs, with development times of a few days compared to several weeks for a typical FPGA application. The large number of I/Os - 64 per core - helps, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/7/2010 10:50:07 PM GMT
www.xmos.com/technology/xcore
If you still don't get it, look at this presentation:
www.youtube.com/MyXMOS#p/a/u/0/RSwWpPobA_0
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/8/2010 12:13:31 AM GMT
The title of this thread is "FUTURE PROPELLER CHIPS". It is not for a comparison of XMOS chips.
I am sick and tired of Leon raising the XMOS chip at every single opportunity. I have said before, Leon, what is your affiliation with XMOS?
It is one thing to discuss comparisons of chips and that another chip can do a certain function better. But this always degenerates into an XMOS chip can do this better, and it is always instigated by Leon.
Leon, please leave this thread.
Parallax: Please warn Leon. I am sick and tired of him promoting XMOS on our propeller forum, and hijacking our propeller discussions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
You made me laugh, because this seems like children. You can not just ignore it?
If you think Leon is a "Troll" simply do not give food.
For the next Propeller, there is·a chip-to-chip comm scheme that uses one pin/wire per direction, with some chip providing the master clock for everybody. It should run at about 320Mb/s - not that fast by todays LVDS standards, but useful for a lot of things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Ignoring a troll is the correct thing to do up to a point - but it is also appropriate to suggest additional measures when they threaten to spoil the enjoyment of the forums for others. I think you can tell from Cluso's tone that he is annoyed. I also considered posting something similar, but refrained due to the reaction it normally generates.
However, I also get annoyed at Leon's persistence in promoting XMOS above and beyond what is necessary to answer the question at hand. I accept that it may be just Leon's enthusiasm for XMOS that gets him carried away, but Cluso is right - I also read this thread because I am interested in "Future Propeller Chips" in it - not stuff about XMOS. If I was interested in XMOS I'd read their forums. But even if I ignore Leon's posts, I waste time opening the thread whenever anyone responds to Leon's posts. And of course, I've now wasted everybody else's time by posting this - sorry about that.
Having the Forum moderators issue an occasional polite and generic warning to keep threads on-subject may indeed help in this case, and stop us all having to post such things again.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 2/8/2010 2:17:43 AM GMT
I disagree. If your code is interrupted, but you know precisely when it is going to be interrupted (as you would in a case of round-robin threads in a deterministic fashion) then you are still deterministic. You will *always* know precisely when something is going to occur.
Now, on the other hand, the dsPIC I've been playing with has an odd quirk where interrupt response latency can vary by 1 cycle depending on if the chip has any other interrupts or exceptions pending. This *could* be deterministic if I was 100% sure that when I expect an interrupt I know precisely what the other code is doing, but it's far harder to make it so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
But if your code can be interrupted at all (even according to some predefined and deterministic round-robin schedule), then in practice it can be very difficult to figure out the timing between any two given instructions. With the Prop you just look at the instructions themselves and you have your answer - and it is constant. You don't have to worry about what other tasks are doing, or the scheduling parameters (time slice etc), or figure out how long it is to the next interrupt.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, it can be difficult, but then so can timing an initial hub window hit. You learn to mitigate the corner cases on any architecture you use.
Saying the XMOS is not deterministic because it uses a thread scheduler is simply not correct. It might be easier to determine your timing chain on a Propeller, but that does not make the other solution invalid.
All CPU's are deterministic, it's just that sometimes the outcome is harder to determine than others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
A while back, well over a year ago, Ken put out the question about weather we would want a PortB prop (64io prop 1) in a few months, or the Prop2 sooner and skip the PortB prop, most people said in effect "forge ahead on the Prop2 and forget the PortB prop" . I for one, wish it had gone the other way. Some of the expensive external memory solutions would not have been so expensive, and many things that take 2 props now because of shortage of pins, would only take one. I don't know if anything has been done to fix the software limitation that was halting the development of the portB prop, but I sure would like one(or a dozen) 64io props right about now....or a year ago. Since the portB prop would use less power than the prop2, I hope that they eventually come out with one, although I reserve my right to change my mind when/if I see the Prop 2.